一. 遷移背景：
由于種種原因，線上cdh叢集的管理服務Cloudera Manager所在主機不能正常使用，Cloudera Manager相關的服務需要遷移到新的主機運作，且生産遷移不能影響任何生産環境的使用。
二. 遷移準備
本次遷移主要涉及到的是Cloudera Manager相關的管理服務，下面我們回顧一下Cloudera Manager整體技術架構以及各個元件的核心作用和對應的資料存儲。
從Cloudera Manager整體技術架構我們可以發現，其核心點就是server部分，本次我們需要遷移的真是server部分，server部分包含的元件及作用具體如下：
1.1 Cloudera Manager Server
預設支援兩個存儲方式，嵌入式 PostgreSQL 資料庫和外部MySQL、PostgreSQL 或 Oracle 資料庫用來存儲資料，此部分的存儲資料對于叢集很重要的，其中包括，叢集、服務、角色的配置以及定義 Cloudera Manager 及其托管主機部署的其他必要資訊。所有這部分的存儲需要及時的備份和監控。
說明：這部分我們線上曆史使用的是嵌入式 PostgreSQL 資料庫，且和server部分部署在同一個節點，是以也做了從嵌入式 PostgreSQL 資料庫遷移資料到外部PostgreSQL 資料庫。此部分本文不做詳解，可自行參考對應資料。
1.2 Activity Monitor
此部分一般也會選用資料庫來存儲，主要存儲的是 MapReduce 作業的監控資料，預設的存儲時間是14天，這部分我們可以根據實際使用情況進行自定義配置，具體詳情會在安裝錄屏課中做詳細的講解. 經驗來說保持預設值即可。
1.3 Service Monitor
預設的存儲路路徑在主機的 /var/lib/cloudera-service-monitor/ ，這個服務元件主要監控收集有關叢集中已配置角色和服務的名額，并運作主動健康測試。這些運作狀況測試與空閑和使用時間無關，因為它們總是相關的。無論叢集中的活動水準如何，服務螢幕都會收集名額和運作狀況測試結果。即使在空閑叢集中，這些資料也會繼續增長。預設值也是10G左右，也可以在配置項中自定義更改。
1.4Host Monitor
預設的存儲路徑/var/lib/cloudera-host-monitor/，預設的存儲也是占用10G大小，主機螢幕收集有關主機級感興趣項目的名額（例如：磁盤空間使用情況、RAM、CPU 使用情況、交換等），并通知主機健康測試。無論叢集中的活動水準如何，主機螢幕都會收集名額和運作狀況測試結果。即使在空閑叢集中，這些資料也會繼續相當線性地增長。
1.5 Event Server
預設的本地存儲路徑：/var/lib/cloudera-scm-eventserver/，
事件伺服器是一個托管的 Lucene 索引，它收集叢集内發生的相關事件，例如健康測試的結果、當日志條目與一組用于識别感興趣消息的規則比對時建立的日志事件，并使它們可用于搜尋、過濾和附加操作。您可以在 Cloudera Manager 管理控制台的診斷>事件頁籤上檢視和過濾事件。您還可以使用 Cloudera Manager API 輪詢此資料。
三. 開始遷移
整個的遷移分兩部分來完成， cloudera-manager-server部分和Cloudera Management Service部分。下面是cloudera-manager-server部分的遷移（此部分是遷移的重點）。
1.cloudera-manager-server遷移流程如下
第一步：确定安裝 Cloudera Manager 的新主機。并将新主機添加到現有的cm管理的叢集中（具體步驟參考 cm添加agent的詳細步驟）
第二步：在新的節點安裝Cloudera Manager Server服務。
重要的：需要確定目标主機上的 Cloudera Manager Server 版本必須與源主機上的版本比對。
第三步：需要将/opt/cloudera/parcel-repo，/opt/cloudera/csd，/var/lib/cloudera-scm-server/路徑下的所有資料從老節點拷貝到新的主機對應的路徑下。
重要的：確定檔案目錄的權限為cloudera-scm。
第四步：更新/etc/cloudera-scm-server/db.properties檔案中包含資料庫名稱、資料庫執行個體名稱、使用者名和密碼。
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=ds_scm
com.cloudera.cmf.db.password=ds_scm 重點：如果資料庫不可用，需要遷移資料到新的資料庫中，具體的可以參考資料庫遷移的資料。
特别注意，如果使用的是mysql進行資料的存儲，不要遺漏了對應路徑下依賴jar包：/usr/share/cmf/lib/mysql-connector-java.jar
第五步：更改所有所有主機的agent相關的配置檔案，然後重新開機所有agent服務。
補充說明：
這一部分的操作可以使用腳本批量化操作，這裡給大家分享一個我們自己使用的ansible的批量執行的Playbooks 的配置檔案。
cat change_agent_ip.yml
---
- hosts: all_agents
gather_facts: F # 跳過gather_facts環節
remote_user: root
tasks:
- name: "修改cm_agent配置檔案的server-ip選項"
lineinfile:
path: /etc/cloudera-scm-agent/config.ini
regexp: '{{ item.regexp }}'
line: '{{ item.line }}'
state: present
with_items:
- regexp: "^server_host"
line: "server_host=10.90.48.134"
notify:
- restart cloudera-scm-agent
handlers:
- name: restart cloudera-scm-agent
service:
name: cloudera-scm-agent
state: restarted 自動擷取cm中所有agent節點ip的腳本
cat ds_get_agent.py
#!/bin/python2.7
# -*- coding:utf-8 -*-
import json,requests
if __name__ == '__main__':
"""
配置叢集cm_web IP和admin使用者的登入密碼
"""
cdh_list = [{'url': 'cm_web的ip+端口', 'name': "cm的登入使用者", "password": "cm登入使用者密碼"}]
for cdh in cdh_list:
datas = json.loads(requests.get("http://{0}/api/v13/hosts".format(cdh.get("url")),auth=(cdh.get("name"),cdh.get("password"))).content.decode('utf-8'))
head_txt ='''[all:vars]
ansible_ssh_port=57522
[all_agents]
'''
with open("agent.hosts", "w") as f:
f.write(head_txt)
for hosts in datas.get("items"):
with open("agent.hosts", "a") as f:
f.write(hosts.get('ipAddress'))
f.write('\n') 執行操作腳本：
cat run.sh
Python2 ds_get_agent.py #擷取所有agent主機寫入agent.hosts檔案
ansible-playbook -i agent.hosts change_agent_ip.yml -f 30 #執行更換ip和重新開機操作 第六步：啟動新節點的Cloudera Manager Server
重點：如果遷移過程中沒有遷移資料庫，在啟動新的Cloudera Manager Server服務前需要關閉老的Cloudera Manager Server，否則會出現Cloudera Manager Server腦裂的問題，當然也可以在Cloudera Manager Server配置檔案中添加對應的參數來規避。同時下面配置檔案中關于jvm記憶體的配置，也需要和老節點保持一緻。
cat /etc/default/cloudera-scm-server
export CMF_JAVA_OPTS="-Xmx4G -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dcom.cloudera.server.cmf.components.scmActive.killOnError=false" 上述步驟操作完成，新節點的cm web 即可正常打開，此時需要重新開機一下Cloudera Management Service。
2. Cloudera Management Service部分遷移
這一部分的遷移主要是叢集cm控制台進行操作，相對來說比較簡單，對應服務的資料因為都是監控類型的資料，是以如果想要保留，把對應的目錄資料同步到新節點即可，如果不保留，将現有的服務元件删除，在新節點上重新添加即可。具體細節這裡不在贅述。
四. 遷移後驗證
在完成步驟三中的所有操作之後，等待5分鐘左右，如果沒有問題，cm頁面上會恢複到健康狀态。這時還是需要手動驗證幾個點，看是不是有異常。
- 1.觀察服務和主機的監控名額資料，是否正常更新展示。
- 2.找一個slave節點，對其操作重新開機操作，看是否可以正常完成。
- 3.修改某個服務的非核心配置檔案，看頁面上是否有配置變更的提示，然後再頁面上分發配置，看是否可正常完成。
- 4.如有條件，也可添加一個新的節點到叢集，驗證是否可以正常添加節點。
本文由滌生大資料強哥分享，強哥前百度資深大資料運維，現任某上市公司大資料運維專家崗，運維叢集數十個，節點上千台，是資深的cdh運維專家，在cdh運維這塊有着豐富的經驗和深入的了解。
滌生大資料運維課程全部基于生産标準伺服器錄制課程，實戰使用，目前十幾家中小公司買我們的運維課程拿過去直接就可以用，目前也在幫外部公司外包運維。大資料運維課程老師阿裡樹哥，前百度強哥，包括我都是管理上千節點叢集的人，此外課程還由騰訊，美團小夥伴合作錄制。
- 1.大資料運維在職的人進階，進一步提升拿高薪
- 2.準備轉行大資料運維的人（試不試需要評估，因為運維相對難度大）
- 3.大資料開發儲備學習準備去中小公司的人：既懂開發也懂運維去小公司很吃香，做管理層，大資料架構。