餘澈，中國聯通大數據技術部平臺組核心技術負責人，項目管理高級工程師，具有多年大數據平臺運維管理及開發優化經驗。管理過多個上千節點集群，擅長對外多租戶平臺的維護開發。信科院大數據性能測試、功能測試主力，大廠PK獲得雙項第一。
背景
作為運維人員，做得最多的工作就是日常巡檢、故障恢復。公司集群規模越龐大，故障發生率和故障實例數也在成倍增加。每天來到公司，第一件事兒就是要看看有哪些機器壞了？壞哪兒了？集群存儲還夠嗎？底層數據存儲是否均衡？然後針對每個故障逐一解決。筆者親身經歷就是過年連懶覺都睡不成，集群故障了，一個電話過來立馬清醒，然後默默地恢復故障。這樣的經歷我覺得每個運維人都含著淚經歷過。
改變
通過採集分析Prometheus裡的告警數據，利用fabric或ansible等多線程安全併發遠程連接工具，執行相關角色實例的恢復工作。
fabric建立連接執行恢復命令。
目前集群規模將近5000臺，其中兩個大規模的集群節點數均為一千多臺。
目前自動化恢復涉及的集群日常運維操作有：
計算節點檢測出使用swap交換分區，將會自動清理swap分區並關閉swap分區；
計算節點檢測出時鐘偏差，將會自動糾偏時鐘偏差；
Cloudera Manager 代理掛掉，將會自動重啟；
主機檢測出有壞盤，壞盤更換完成後，自動恢復；
角色實例檢測出異常掉線，自動恢復上線（如NameNode、DataNode、ResourceManager、NodeManager等）；
集群存在多個節點多塊磁盤存儲剩餘空間不足，自動進行磁盤級別的數據Balancer；
集群存儲達到閾值，自動進行節點級別的數據Balancer。
自動化恢復的適用場景很多，但一定要做到嚴謹地對症下藥，並且要考慮清楚問題的嚴重性和普遍性。
以上7點自動恢復是集群常見故障，該類故障頻發且影響範圍較小，並不會影響集群的可用性，因此可以實施自動化恢復。
對於平臺罕見故障，且該故障有一定概率會對平臺造成部分功能性能影響的，最好的辦法是做好告警和應急處理。
下面分享幾個自動化恢復實踐：
1）計算節點檢測出使用swap交換分區，將會自動清理swap分區並關閉swap分區。
根據監控數據，獲取swap開啟的計算機點，遠程連接進行swap分區關閉。
def recover_HOST_MEMORY_SWAPPING(self,list):
com=("swapoff -a")
for i in range(len(list)):
con = Connection(list[i]['ipAddress'], port=22, user=user, connect_timeout=360, forward_agent=True,
connect_kwargs={'password': self.password})
con.sudo(command=com,password=self.password,shell=False,hide='stderr',encoding='utf-8',pty=True)
con.close
2）Cloudera Manager 代理掛掉，將會自動重啟。
根據監控數據，獲取agent異常下線的計算節點，遠程連接進行agent上線操作。
def recover_HOST_SCM_HEALTH(self,list):
com=("/opt/cm-5.13.1/etc/init.d/cloudera-scm-agent restart")
for i in range(len(list)):
con = Connection(list[i]['ipAddress'], port=22, user=user, connect_timeout=360, forward_agent=True,
connect_kwargs={'password': self.password})
con.sudo(command=com,password=self.password,shell=False,hide='stderr',encoding='utf-8',pty=True)
con.close
3）計算節點檢測出時鐘偏差，將會自動糾偏時鐘偏差。
由於集群資源每天有將近16小時處於打滿狀態，容易造成集群部分計算節點負載過高，導致節點上的DN、NM掉線。這時候需要重啟計算節點，但重啟節點會造成機器時鐘偏差，通過監控告警我們檢測到了時鐘偏差，接下來通過讀取Prometheus中的時鐘偏差節點信息，來進行時鐘源同步操作。
具體時鐘偏差恢復的代碼實例如下：
from fabric import Connection
def recover_HOST_CLOCK_OFFSET(self,list):
com=["systemctl stop ntpd","ntpdate ntp_src","sleep 1","ntpdate ntp_src","sleep 1","ntpdate ntp_src","sleep 1","systemctl start ntpd","/opt/cm-5.13.1/etc/init.d/cloudera-scm-agent restart"]
for i in range(len(list)):
con = Connection(list[i]['ipAddress'], port=22, user=user, connect_timeout=360, forward_agent=True,
connect_kwargs={'password': self.password})
for j in range(len(com)):
con.sudo(command=com[j], password=self.password, shell=False, hide='stderr', encoding='utf-8', pty=True)
con.close
4）集群角色異常退出。
如下圖：監控告警發現NodeManager實例發生故障實踐在2019-08-12 04:28:02，一般這個時間段，運維人員都在深度睡眠。這時自愈程序將根據告警自動恢復角色實例，恢復實踐週期在5分鐘之內，於2019-08-12 04:32:02 DN實例和NM實例恢復上線。
當前集群使用的CDH5.13.1版本，可以直接通過CM_API實現角色實例自愈，如果是手工搭建版本，可以使用fabric或者Paramiko連接到節點啟動相應角色實例。
「CM_API使用說明」參考鏈接：https://cloudera.github.io/cm_api/docs/python-client-swagger/
具體DN角色自愈代碼如下：
import cm_client
api_url = api_host + ':' + port + '/api/' + api_version
api_client = cm_client.ApiClient(api_url)
cluster_api_instance = cm_client.ClustersResourceApi(api_client)
# Lists all known clusters.
api_response = cluster_api_instance.read_clusters(view='SUMMARY')
for cluster in api_response.items:
print (cluster.name, "-", cluster.full_version)
if cluster.full_version.startswith("5."):
services_api_instance = cm_client.ServicesResourceApi(api_client)
services = services_api_instance.read_services(cluster.name, view='FULL')
for service in services.items:
#print (service.name)
if service.type == 'HDFS':
hdfs = service
if cluster.full_version.startswith("5."):
roles_api_instance = cm_client.RolesResourceApi(api_client)
//根據集群名稱，服務實例名稱獲取相對應的角色實例列表
role_response = roles_api_instance.read_roles(cluster.name, hdfs.name, view='FULL')
//獲取狀態為bad的dn角色實例（手工搭建集群可以通過讀取prometheus的告警數據進行掉線角色實例的恢復。）
bad_dn_roles = [role.name for role in role_response.items if (role.type == 'DATANODE' and role.health_summary == 'BAD')]
roles_cmd_api_instance = cm_client.RoleCommandsResourceApi(api_client)
role_names = cm_client.ApiRoleNameList(bad_dn_roles)
//重啟角色實例
cmd_list = roles_cmd_api_instance.restart_command(cluster.name, hdfs.name, body=role_names)
for cmd in cmd_list.items:
print (cmd.name, "(", cmd.id, cmd.active, cmd.success, ")")
執行完成後，返回執行結果：
5）集群個別節點上的磁盤存儲超過90%的閾值。
背景：集群節點數過多後，默認的數據落盤策略為輪訓，由於部分節點存儲異構，會導致有部分節點存儲打滿，這時我們可以修改數據落盤策略為剩餘空間策略，即根據節點剩餘存儲空間的多少來決定數據優先落盤的順序。
但是，即使這樣解決了節點存儲的均衡，也不能解決個別磁盤的存儲打滿，在Apache社區的Hadoop3版本中dfs.disk.balancer才可以使用。在CDH5.13.1的Hadoop2.6.0版本，已經可以使用該功能。但是磁盤何時快打滿無法預測，並且在大規模集群中，往往多了一個賬期的數據，就會有大量的磁盤達到存儲告警閾值。當HDFS集群單節點內部多塊數據硬盤數據傾斜時，會造成熱點硬盤使用量激增，甚至打滿，此時集群balance是無用的，就需要用DiskBalancer，這時我們就可以根據告警信息來自動化的進行磁盤數據均衡。
開啟方法：
修改hdfs-site.xml文件。
true表示開啟DiskBalancer。
命令：
hdfs diskbalancer -[command] [options]
command：
1.plan（制定平衡計劃）
可執行參數：
--bandwidth
--out
--v:輸出計劃
2.execute（執行計劃）
3.query（查詢進度）
4.cancel（取消計劃）
實例：
DN節點lf-319-sq210發生數據傾斜。
登陸到lf-319-sq210主機，切換至HDFS用戶。
制定平衡計劃：
hdfs diskbalancer -plan lf-319-sq210.plan.json --out ~/2019-Jul-20-15-25-29 --thresholdPercentage 10
執行平衡計劃：
hdfs diskbalancer -execute /var/lib/hadoop-hdfs/2019-Jul-20-15-25-29/lf-319-sq210.plan.json
查詢計劃：
hdfs diskbalancer -query lf-319-sq210
圈中部分為正在進行，PLAN_DONE為完成。
過一段時間觀察lf-319-sq210磁盤情況：
可以清晰的看出，磁盤已經開始平衡了。
以上是磁盤級別的數據平衡操作步驟，以下是通過fabric進行遠程命令的執行，以實現自動化恢復。
def recover_DATA_NODE_FREE_SPACE_REMAINING(self,list):
com=("su hdfs -c 'whoami;export JAVA_HOME=/opt/jdk;export CLASSPATH=.:$JAVA_HOME/lib:$CLASSPATH;export PATH=$JAVA_HOME/bin:$PATH;hdfs diskbalancer -plan $HOSTNAME.plan.json --out ~/`date \\'+diskbalancer_%Y_%m_%d\\'` --thresholdPercentage 10;sleep 5;hdfs diskbalancer -execute /var/lib/hadoop-hdfs/`date \\'+diskbalancer_%Y_%m_%d\\'`/$HOSTNAME.plan.json'")
for i in range(len(list)):
con = Connection(list[i]['ipAddress'], port=22, user=user, connect_timeout=360, forward_agent=True,
connect_kwargs={'password': self.password})
con.sudo(command=com,password=self.password,shell=False,hide='stderr',encoding='utf-8',pty=True)
con.close
集群自愈也是大規模集群治理工作的一項重要環節，遵循降本增效、安全至上的原則，能減少運維人員的大量常規工作量，也能及時有效地恢復故障，減少小故障引發集群大事故的可能性。
從過去40年至今，數據庫的形態基本經歷了傳統商業數據庫、開源數據庫到雲原生數據庫的演進過程。雲時代下數據庫將如何革新與創變？金融行業核心數據庫遷移與建設如何安全平穩展開？來Gdevops全球敏捷運維峰會北京站尋找答案：
《All in Cloud 時代，下一代雲原生數據庫技術與趨勢》阿里巴巴集團副總裁/達摩院首席數據庫科學家 李飛飛（飛刀）
《AI和雲原生時代的數據庫進化之路》騰訊數據庫產品中心總經理 林曉斌（丁奇）
《ICBC的MySQL探索之路》工商銀行軟件開發中心 魏亞東
《金融行業MySQL高可用實踐》愛可生技術總監 明溪源
《民生銀行在SQL審核方面的探索和實踐》民生銀行 資深數據庫專家 李寧寧
《OceanBase分佈式數據庫在西安銀行的落地和實踐》螞蟻金服P9資深專家/OceanBase核心負責人 蔣志勇
讓我們9月11日在北京共同眺望數據庫發展變革更長遠的未來！
閱讀更多 楊建榮的學習筆記 的文章
