當前位置︰首頁 > 新聞資訊 > 正文

聯通大數據 5000 台規模集群故障自愈實踐2019-08-28 09:32:15 | 編輯︰hely | 查看︰ | 評論︰0

筆者親身經歷就是過年連懶覺都睡不成,集群故障了,一個電話過來立馬清醒,然後默默地恢復故障。這樣的經歷我覺得每個運維人都含著淚經歷過。

背景

作為運維人員,做得最多的工作就是日常巡檢、故障恢復。公司集群規模越龐大,故障發生率和故障實例數也在成倍增加。每天來到公司,第一件事兒就是要看看有哪些機器壞了?壞哪兒了?集群存儲還夠嗎?底層數據存儲是否均衡?然後針對每個故障逐一解決。筆者親身經歷就是過年連懶覺都睡不成,集群故障了,一個電話過來立馬清醒,然後默默地恢復故障。這樣的經歷我覺得每個運維人都含著淚經歷過。

改變

通過采集分析 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︰

♦ plan(制定平衡計劃)

可執行參數︰

–bandwidth ︰平衡帶寬,默認單位 M/S
–out ︰計劃輸出目錄
–v: 輸出計劃

♦ execute(執行計劃)
♦ query(查詢進度)
♦ 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()

集群自愈也是大規模集群治理工作的一項重要環節,遵循降本增效、安全至上的原則,能減少運維人員的大量常規工作量,也能及時有效地恢復故障,減少小故障引發集群大事故的可能性。

作者介紹︰

余澈,中國聯通大數據技術部平台組核心技術負責人,項目管理高級工程師,具有多年大數據平台運維管理及開發優化經驗。管理過多個上千節點集群,擅長對外多租戶平台的維護開發。信科院大數據性能測試、功能測試主力,大廠 PK 獲得雙項第一。

上一篇︰10+ JavaScript 數據可視化庫 淺談“完美無瑕”的分布式系統下一篇︰

公眾平台

搜索"raincent"或掃描下面的二維碼

?