一、遷移背景
服務器出了問題,導致整個cm server界面呈現出不可用的狀態,也就是獲取不到各個大數據組件以及主機相關的狀態的信息,整個cm server的前端界面處於癱瘓的狀態,不可用,剛開始懷疑是存放元數據的mysql有問題,但是經過驗證,一點問題也沒有,後面發現登陸服務器很卡頓,但是發現cpu和內存都沒怎麼使用,查看/var/log/messages日誌,發現很多MCE錯誤,網上都說只有硬件有問題纔會出現這樣的錯誤,後來重啓機器,看看這樣還會不會繼續報錯,重啓電腦也不能解決問題,暫時判定服務器硬件有問題:這樣的話影響到了很多的服務,主要有CM server,datanode,nodemanager,JournalNode等,由於CM server和JournalNode很重要,所以考慮遷移到其他的機器。
/var/log/messages報錯信息如下:
Jan 31 17:13:13 lgh kernel: sbridge: HANDLING MCE MEMORY ERROR Jan 31 17:13:13 lgh kernel: CPU 36: Machine Check Exception: 0 Bank 10: cc002003000800c1 Jan 31 17:13:13 lgh kernel: TSC 0 ADDR 1200417000 MISC 90000b00374068c PROCESSOR 0:406f1 TIME 1612084393 SOCKET 0 APIC 13 Jan 31 17:13:13 lgh kernel: [Hardware Error]: Machine check events logged Jan 31 17:13:14 lgh kernel: EDAC MC1: CE row 0, channel 0, label "CPU_SrcID#0_Ha#0_Channel#0_DIMM": 128 Unknown error(s): memory scrubbing on FATAL area OVERFLOW:
cpu=36 Err=0008:00c1 (ch=1), addr = 0x1200417000 => socket=0, ha=0, Channel=0(mask=1), rank=0 Jan 31 17:13:14 lgh kernel: Jan 31 19:37:31 lgh kernel: sbridge: HANDLING MCE MEMORY ERROR Jan 31 19:37:31 lgh kernel: CPU 39: Machine Check Exception: 0 Bank 10: cc002003000800c1 Jan 31 19:37:31 lgh kernel: TSC 0 ADDR 1200417000 MISC 90000b00374068c PROCESSOR 0:406f1 TIME 1612093051 SOCKET 0 APIC 19 Jan 31 19:37:31 lgh kernel: [Hardware Error]: Machine check events logged Jan 31 19:37:32 lgh kernel: EDAC MC1: CE row 0, channel 0, label "CPU_SrcID#0_Ha#0_Channel#0_DIMM": 128 Unknown error(s): memory scrubbing on FATAL area OVERFLOW:
cpu=39 Err=0008:00c1 (ch=1), addr = 0x1200417000 => socket=0, ha=0, Channel=0(mask=1), rank=0 Jan 31 19:37:32 lgh kernel:
幾經查看,基本確定是內存出現了問題,但是不完全是故障,就是有隱患。
二、遷移步驟
官方網址:https://docs.cloudera.com/documentation/enterprise/latest/topics/cm_ag_restore_server.html
其實查看官方的遷移步驟很簡單,但是有些情況不適合我們的集羣,官方遷移的方式只適合只安裝了自帶組件的,如果通過jar包安裝了streamsets和spark2等,這些服務就會出現問題,所以需要做一些響應的處理,整個遷移的過程整理如下;
1、選擇一臺合適的機器安裝cloudera manager server服務,這裏我們使用的是yum源的方式安裝,首先配置好yum源,然後使用如下命令安裝:
安裝官方網址:https://docs.cloudera.com/documentation/enterprise/latest/topics/install_cm_cdh.html
yum install –y cloudera-manager-daemons cloudera-manager-server
2、將原來的機器(原來的CM server主機)目錄/var/lib/cloudera-scm-server/下的所有文件複製到新的主機的相同的目錄下,並保持原有的權限
scp –r root@source_ip:/var/lib/cloudera-scm-server/* /var/lib/cloudera-scm-server/
chown –R cloudera-scm: cloudera-scm /var/lib/cloudera-scm-server/
3、這一步是自己調整的,官網沒說很清楚,符合自己的集羣,因爲我們有streamsets和spark2服務,操作如下,在/opt/cloudera下有如下目錄:(這些都是在cm server的機器上)
所以要把這兩個目錄也複製到新cm server機器上的相同目錄下:
scp -r root@source_ip:/opt/cloudera/csd /opt/cloudera
scp -r root@source_ip:/opt/cloudera/parcel-repo /opt/cloudera
#然後進行權限修改
chown -R cloudera-scm:cloudera-scm csd parcel-repo
chmod 644 csd/*
4、數據庫的配置(可選,如果原來數據庫沒問題,就跳過這一步,因爲數據庫沒問題,所以這步是沒有操作的)
安裝完畢後,把原來的是數據庫備份還原到新的數據庫(這裏只說cm相關的元數據庫)
5、修改新機器cm server的配置/etc/cloudera-scm-server/db.properties,把裏面的數據庫的信息進行修改成原來的數據庫或者是新安裝備份還原過後的數據庫。
6、修改原來所有cm agent機器的/etc/cloudera-scm-agent/config.ini配置,只要修改指向爲新的cm server機器就好。如果是新建的數據,並且沒有石油備份還原的方式,則還需要刪除/var/lib/cloudera-scm-agent/cm_guid,修改配置後,重啓agent
service cloudera-scm-agent restart
7、關停掉原先的cm server
service cloudera-scm-server stop
8、啓動新的cm server
service cloudera-scm-server start
9、重新安裝相關服務
到這裏爲止cm server算是遷移完了,但是當自己登陸cm前端的時候,發現cm相關的所有服務還是不可用,因爲這些服務還是安裝在原來有問題的機器上,比如Activity Monitor、Alert Publisher、Event Server、Host Monitor、Reports Manager、Service Monitor。所以整個cm前端頁面還是癱瘓不可用的狀態。其實仔細想想,這些個服務其實就是用來做監控,收集信息的一些服務,所以最終選擇的方案就是:
把這些服務從有問題的機器上進行刪除操作,然後再在新的機器上重新安裝這些所有的服務,然後啓動起來,就ok了。