背景

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

改變

通過采集分析 Prometheus 里的告警數(shù)據(jù)，利用 fabric 或 ansible 等多線程安全并發(fā)遠(yuǎn)程連接工具，執(zhí)行相關(guān)角色實(shí)例的恢復(fù)工作。

 

 

fabric 建立連接執(zhí)行恢復(fù)命令。

 

 

目前集群規(guī)模將近 5000 臺(tái)，其中兩個(gè)大規(guī)模的集群節(jié)點(diǎn)數(shù)均為一千多臺(tái)。

目前自動(dòng)化恢復(fù)涉及的集群日常運(yùn)維操作有：

計(jì)算節(jié)點(diǎn)檢測(cè)出使用 swap 交換分區(qū)，將會(huì)自動(dòng)清理 swap 分區(qū)并關(guān)閉 swap 分區(qū);

計(jì)算節(jié)點(diǎn)檢測(cè)出時(shí)鐘偏差，將會(huì)自動(dòng)糾偏時(shí)鐘偏差;

Cloudera Manager 代理掛掉，將會(huì)自動(dòng)重啟;

主機(jī)檢測(cè)出有壞盤，壞盤更換完成后，自動(dòng)恢復(fù);

角色實(shí)例檢測(cè)出異常掉線，自動(dòng)恢復(fù)上線(如 NameNode、DataNode、ResourceManager、NodeManager 等);

集群存在多個(gè)節(jié)點(diǎn)多塊磁盤存儲(chǔ)剩余空間不足，自動(dòng)進(jìn)行磁盤級(jí)別的數(shù)據(jù) Balancer;

集群存儲(chǔ)達(dá)到閾值，自動(dòng)進(jìn)行節(jié)點(diǎn)級(jí)別的數(shù)據(jù) Balancer。

自動(dòng)化恢復(fù)的適用場(chǎng)景很多，但一定要做到嚴(yán)謹(jǐn)?shù)貙?duì)癥下藥，并且要考慮清楚問題的嚴(yán)重性和普遍性。

以上 7 點(diǎn)自動(dòng)恢復(fù)是集群常見故障，該類故障頻發(fā)且影響范圍較小，并不會(huì)影響集群的可用性，因此可以實(shí)施自動(dòng)化恢復(fù)。

對(duì)于平臺(tái)罕見故障，且該故障有一定概率會(huì)對(duì)平臺(tái)造成部分功能性能影響的，最好的辦法是做好告警和應(yīng)急處理。

下面分享幾個(gè)自動(dòng)化恢復(fù)實(shí)踐：

1)計(jì)算節(jié)點(diǎn)檢測(cè)出使用 swap 交換分區(qū)，將會(huì)自動(dòng)清理 swap 分區(qū)并關(guān)閉 swap 分區(qū)。

根據(jù)監(jiān)控?cái)?shù)據(jù)，獲取 swap 開啟的計(jì)算機(jī)點(diǎn)，遠(yuǎn)程連接進(jìn)行 swap 分區(qū)關(guān)閉。

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 代理掛掉，將會(huì)自動(dòng)重啟。

根據(jù)監(jiān)控?cái)?shù)據(jù)，獲取 agent 異常下線的計(jì)算節(jié)點(diǎn)，遠(yuǎn)程連接進(jìn)行 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)計(jì)算節(jié)點(diǎn)檢測(cè)出時(shí)鐘偏差，將會(huì)自動(dòng)糾偏時(shí)鐘偏差。

由于集群資源每天有將近 16 小時(shí)處于打滿狀態(tài)，容易造成集群部分計(jì)算節(jié)點(diǎn)負(fù)載過高，導(dǎo)致節(jié)點(diǎn)上的 DN、NM 掉線。這時(shí)候需要重啟計(jì)算節(jié)點(diǎn)，但重啟節(jié)點(diǎn)會(huì)造成機(jī)器時(shí)鐘偏差，通過監(jiān)控告警我們檢測(cè)到了時(shí)鐘偏差，接下來通過讀取 Prometheus 中的時(shí)鐘偏差節(jié)點(diǎn)信息，來進(jìn)行時(shí)鐘源同步操作。

 

 

具體時(shí)鐘偏差恢復(fù)的代碼實(shí)例如下：

�pfrom 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)集群角色異常退出。

如下圖：監(jiān)控告警發(fā)現(xiàn) NodeManager 實(shí)例發(fā)生故障實(shí)踐在 2019-08-12 04:28:02，一般這個(gè)時(shí)間段，運(yùn)維人員都在深度睡眠。這時(shí)自愈程序?qū)⒏鶕?jù)告警自動(dòng)恢復(fù)角色實(shí)例，恢復(fù)實(shí)踐周期在 5 分鐘之內(nèi)，于 2019-08-12 04:32:02 DN 實(shí)例和 NM 實(shí)例恢復(fù)上線。

 

 

 

 

當(dāng)前集群使用的 CDH5.13.1 版本，可以直接通過 CM_API 實(shí)現(xiàn)角色實(shí)例自愈，如果是手工搭建版本，可以使用 fabric 或者 Paramiko 連接到節(jié)點(diǎn)啟動(dòng)相應(yīng)角色實(shí)例。

「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)

// 根據(jù)集群名稱，服務(wù)實(shí)例名稱獲取相對(duì)應(yīng)的角色實(shí)例列表
role_response = roles_api_instance.read_roles(cluster.name, hdfs.name, view='FULL')
// 獲取狀態(tài)為 bad 的 dn 角色實(shí)例（手工搭建集群可以通過讀取 prometheus 的告警數(shù)據(jù)進(jìn)行掉線角色實(shí)例的恢復(fù)。）
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)
// 重啟角色實(shí)例
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, ")")

執(zhí)行完成后，返回執(zhí)行結(jié)果：

 

 

5)集群個(gè)別節(jié)點(diǎn)上的磁盤存儲(chǔ)超過 90% 的閾值。

背景：集群節(jié)點(diǎn)數(shù)過多后，默認(rèn)的數(shù)據(jù)落盤策略為輪訓(xùn)，由于部分節(jié)點(diǎn)存儲(chǔ)異構(gòu)，會(huì)導(dǎo)致有部分節(jié)點(diǎn)存儲(chǔ)打滿，這時(shí)我們可以修改數(shù)據(jù)落盤策略為剩余空間策略，即根據(jù)節(jié)點(diǎn)剩余存儲(chǔ)空間的多少來決定數(shù)據(jù)優(yōu)先落盤的順序。

但是，即使這樣解決了節(jié)點(diǎn)存儲(chǔ)的均衡，也不能解決個(gè)別磁盤的存儲(chǔ)打滿，在 Apache 社區(qū)的 Hadoop3 版本中 dfs.disk.balancer 才可以使用。在 CDH5.13.1 的 Hadoop2.6.0 版本，已經(jīng)可以使用該功能。但是磁盤何時(shí)快打滿無(wú)法預(yù)測(cè)，并且在大規(guī)模集群中，往往多了一個(gè)賬期的數(shù)據(jù)，就會(huì)有大量的磁盤達(dá)到存儲(chǔ)告警閾值。當(dāng) HDFS 集群?jiǎn)喂?jié)點(diǎn)內(nèi)部多塊數(shù)據(jù)硬盤數(shù)據(jù)傾斜時(shí)，會(huì)造成熱點(diǎn)硬盤使用量激增，甚至打滿，此時(shí)集群 balance 是無(wú)用的，就需要用 DiskBalancer，這時(shí)我們就可以根據(jù)告警信息來自動(dòng)化的進(jìn)行磁盤數(shù)據(jù)均衡。

開啟方法：

修改 hdfs-site.xml 文件。

 

 

true 表示開啟 DiskBalancer。

命令：

hdfs diskbalancer -[command] [options]

command：

♦ plan(制定平衡計(jì)劃)

可執(zhí)行參數(shù)：

–bandwidth ：平衡帶寬，默認(rèn)單位 M/S
–out ：計(jì)劃輸出目錄
–v: 輸出計(jì)劃

♦ execute(執(zhí)行計(jì)劃)
♦ query(查詢進(jìn)度)
♦ cancel(取消計(jì)劃)

實(shí)例：

DN 節(jié)點(diǎn) lf-319-sq210 發(fā)生數(shù)據(jù)傾斜。

 

 

登陸到 lf-319-sq210 主機(jī)，切換至 HDFS 用戶。

制定平衡計(jì)劃：

hdfs diskbalancer -plan lf-319-sq210.plan.json --out ~/2019-Jul-20-15-25-29 --thresholdPercentage 10

 

 

執(zhí)行平衡計(jì)劃：

hdfs diskbalancer -execute /var/lib/hadoop-hdfs/2019-Jul-20-15-25-29/lf-319-sq210.plan.json

 

 

查詢計(jì)劃：

hdfs diskbalancer -query lf-319-sq210

 

 

圈中部分為正在進(jìn)行，PLAN_DONE 為完成。

過一段時(shí)間觀察 lf-319-sq210 磁盤情況：

 

 

可以清晰的看出，磁盤已經(jīng)開始平衡了。

以上是磁盤級(jí)別的數(shù)據(jù)平衡操作步驟，以下是通過 fabric 進(jìn)行遠(yuǎn)程命令的執(zhí)行，以實(shí)現(xiàn)自動(dòng)化恢復(fù)。

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()

集群自愈也是大規(guī)模集群治理工作的一項(xiàng)重要環(huán)節(jié)，遵循降本增效、安全至上的原則，能減少運(yùn)維人員的大量常規(guī)工作量，也能及時(shí)有效地恢復(fù)故障，減少小故障引發(fā)集群大事故的可能性。

作者介紹：

余澈，中國(guó)聯(lián)通大數(shù)據(jù)技術(shù)部平臺(tái)組核心技術(shù)負(fù)責(zé)人，項(xiàng)目管理高級(jí)工程師，具有多年大數(shù)據(jù)平臺(tái)運(yùn)維管理及開發(fā)優(yōu)化經(jīng)驗(yàn)。管理過多個(gè)上千節(jié)點(diǎn)集群，擅長(zhǎng)對(duì)外多租戶平臺(tái)的維護(hù)開發(fā)。信科院大數(shù)據(jù)性能測(cè)試、功能測(cè)試主力，大廠 PK 獲得雙項(xiàng)第一。

標(biāo)簽： 聯(lián)通大數(shù)據(jù)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。