大規模機器集羣-故障自動處理(二)

本篇開始介紹具體的實現過程，爲表述方便，先定義一些名詞，

• _AutoRepairSystem: _故障自動維修系統, 縮寫爲ARS

• 原子操做：任務的最小操做，機器任務一般是指重啓、重裝

• 運維人員：運維工程師= SRE = OP，系統工程師 = sys

• 遠程管理工具： 遠程控制操做物理機器的工具，如ipmi、ilo

先來看ARS的總體視圖和流程圖，

 

 

 

ARS的工做流程，

1. 故障檢測: 每5分鐘發起一次故障檢測，獲取當前時刻整個集羣的故障機器列表，推送到工做流子系統

2. 安全策略: 遍歷故障機器列表，依次執行安全策略，過濾不符合要求的機器，獲得一個可安全執行重啓、重裝的機器列表

3. 服務離線: 遍歷可安全操做的機器列表，執行服務離線

4. 故障維修: 服務離線後，發起重啓、維修操做，輪詢機器狀態，直至重啓成功或維修完成

5. 環境初始化: 執行環境初始化，保證機器環境符合業務需求

6. 服務上線: 恢復服務，檢查服務達到可服務狀態，流程結束

接下來將介紹工做流子系統，這是全部具體操做任務執行的基礎；

再依次介紹上述流程中的關鍵環節： 服務上下線，故障檢測，安全策略，維修工具及SLA;

而後經過一個線上例子，說明總體的工做流程；

最後分享系統上線後的運行數據。

2.1 工做流子系統

工做流最基本的功能，是驅動一系列預約義任務順序執行，達到明確的結束狀態；在機器故障自動處理這個問題域裏，對工做流還有閉環、擴展性的要求(詳見第一篇的分析).

通過分析統計機器相關的操做任務， 好比機器重啓、重裝、初始化環境、啓動/中止服務、查看信息等，抽象出機器操做的任務模型，即」對一組機器執行相同的任務，且任務能夠進一步拆分爲一系列更小的原子操做組合」，如圖所示，

上圖表示對一組機器執行相同的任務，下圖表示，這個任務具體有4個原子操做。

由此，咱們能夠定義工做流的幾個關鍵類，以及他們的關係，

注：爲了簡化表述，這裏只列出和流程執行、任務分支、通用性相關的字段和邏輯，工做流子系統的完整信息，後續會另寫文章介紹。

• Job，定義了任務類型以及要操做的目標集合

• Task，定義了一個具體的操做目標，以及action_tree的root節點

• Action，定義了業務邏輯的內容和加載方式

• Scheduler, 調度Job的運行

• Monitor, 監控 Job、Task、Action 的狀態

• Executor, 控制Job下的task/action 的執行順序、併發等

接下來重點看看工做流系統是如何達到前文提到的擴展性、閉環要求的。

第一點，擴展性。

擴展性需求，最初來自於不一樣服務上下線操做的差別，主要是有狀態服務。

它們之間的差別，體如今操做步驟的數量和順序不一樣。例如，

• 推薦模型服務，要求先尋找可用的機器資源，在新資源上部署相同版本的服務，啓動服務加載數據，判斷數據加載進度，直到達到某個閾值，纔算是完成「遷移」，此時才達到可維修的狀態

• Docker服務，相對簡單，只需向docker發起遷移命令，等待docker返回遷移進度，遷移完成後便可維修

• Hadoop服務，主要痛點在磁盤故障上，要求維修過程當中不能長時間停服，因此維修邏輯很複雜，要先中止本機服務，umount故障磁盤，啓動服務，維修故障磁盤，修復以後再停服，起服，讓Hadoop從新使用這塊磁盤

• 其餘無狀態服務相對簡單，一般直接維修便可

可見，不一樣服務的差別化是不可窮舉的，若是ARS要介入具體的維修邏輯，無異於「攬屎上身」，最終陷入泥潭裏沒法自拔。

咱們的思路是： 對外提供一套機制，能簡易地將維修邏輯嵌入工做流子系統，實現步驟以下，

1. 將複雜任務拆解成多個原子操做，每一個原子操做實現爲一個python方法，返回值格式固定

2. 定義原子操做的執行順序以及分支

只要知足上述條件，系統就能支持任意數量、任意順序的原子操做集合。

原子操做的python實現以下圖所示，

action1爲原子操做名字，do_hard_work()方法由業務sre 完成，工做流子系統只負責調用， is_succ代表本次操做是否執行成功，result一般是操做結果信息。

只要按照這個約定編寫的任務，均可註冊到系統裏被執行，哪怕提交人只是用python 包了一坨 shell 腳本，也是可嵌入系統的，雖然咱們在review的時候會「建議」他重寫。

有了原子操做的實現，就能夠定義它們的執行順序，咱們使用了「樹」的概念，以下圖json配置示例所示，

能夠看到，整棵樹有多棵子樹組成，每棵子樹指向一個nodes list，每一個node就是一個action, action的數量和順序能夠在nodes list裏任意配置擴展。

在example_trees裏， action1～action6就是原子操做，執行的順序有兩種可能分支，

action1-> action2 (true)--> action3->action4->結束;

action1-> action2 (false)--> action5->action6->結束;

假設如今業務有一個大的改動，須要在action2以前增長一個操做action7, 並在action6以後，增長一個分支action8,  這隻需在配置上小改動便可實現，

example_trees 會被保存在Action類的action_definition字段裏，這個配置記錄了執行邏輯的python 文件，類和方法; 工做流在運行時，會動態加載相應的類，根據方法名調用方法，以下圖所示，

憑藉這些特性，業務sre能夠靈活多變的定義本身的任務樹，其中公共部分，由平臺sre編寫，與業務相關部分由業務sre編寫。

第二點，閉環。

以無狀態的 web機器的宕機自動處理流程爲例，(這裏爲了方便表述，作了簡化)

1. 檢測宕機的機器

2. 重啓機器

3. 若是能起來，檢查程序版本，啓動web 服務，流程結束

4. 若是不能起來，則報修硬件故障

5. 若是能修復，回到第3步

6. 若是不能修復，則檢查是否過保，若是是，則下架機器，流程結束

其流程樹的配置以下，

能夠看到，reboot_host、check_host_alive、repair_host等action爲原子操做；

這棵樹有兩個分支節點，

若是 reboot_host以後 check_host_alive爲Ture, 則執行online_service 分支，流程結束；

若是爲false, 則執行repair_host 分支，若是能修好，則回到 tree2 ，最後也達到 online_service的狀態,  流程結束；（只要是沒過保，都能修好）

若是修很差，那麼則進入 off_rack 下架流程，流程結束。（一般是機器過保）

這裏之因此反覆強調任務分支，是由於有了任務分支，就能夠在各個可能執行失敗的環節，指定下一步的操做，最終將目標操做到一個可預期的狀態(機器要麼被修好從新投入使用，要麼修很差被下架)，造成閉環，不用人工介入，真正提升自動化程度。

同時，因爲在一開始就設定了維修只有兩種操做:重啓，重裝，這兩種操做都由sys來保證交付時間，因此這棵樹能保證流程是閉環的。

在ARS上線以前，早期的自動工具發起重啓命令以後，機器起不來，一般是人工通知sys 報修，報修以後 sys 再根據機器是否過保來給sre 反饋維修狀態，這個過程，如同黑洞，吞噬了rd-sre-sys-機房外包四方大量的溝通時間, 如圖所示，

工做流子系統還涉及狀態機、併發控制、重試、任務重入、超時、執行進度等，後續另寫文章介紹。

在下一節裏，將介紹故障檢測、安全策略等內容。

2.2故障檢測

故障檢測的完整性、正確性是故障維修自動化的前提。

經過分析歷史機器故障類型，可將故障分爲5個層次，以下表，基本覆蓋了sre平常處理的故障。

 

ARS主要覆蓋了機器層、系統層，下面分別作說明。

磁盤故障

磁盤故障率高的業務類型不少， 如hadoop、索引服務、分佈式文件系統服務、機器學習模型訓練服務等，這些服務的機器，磁盤塊數最高多達36塊，大量讀寫磁盤，形成磁盤故障率很高。

常見的磁盤故障類型有掉盤、讀寫錯誤(Input/Output Error)、漂盤、掛載錯誤、 read-only錯誤、性能劇降(ls /disk/ 超過10分鐘無反應)；

磁盤故障的積累，有可能會致使數據丟失，以及拖慢整個系統的性能，因此要儘早檢測到儘早處理。

宕機故障

宕機故障分爲徹底死機，假死。

徹底死機(指連續3個小時失去心跳，而且主動ssh 探測失敗的機器)，這種狀況容易處理，直接進入自動重啓流程；

假死，有以下類型，

l  Connection timed out

l  Connection closed by remotehost

l  Connection reset by peer

l  Connection refused

l  Connection closed by

這些假死狀態，可能會形成業務受損。

好比機器假死，服務端口還能鏈接，但實際業務進程內部沒法正常工做，若是是前端web機器出現這種狀況，會致使業務5xx監控飆升；此時，想手動重啓，ssh已經沒法鏈接，只能經過ilo重啓，或者緊急聯繫機房，處理耗時每每超過半小時。

內存故障

內存故障時，一般機器尚未死機，(在/var/log/message 裏顯示CE error on CPU#1Channel#2_DIMM#1)

rd認爲機器還能跑，不肯意停服務；

若是積攢到多臺機器出現相似錯誤，極有可能在短期內出現連續死機，致使服務容量忽然減小，服務性能大幅降低的業務故障，因此對於一些敏感服務，出現這種故障，仍是要看成死機來處理。

電源故障

雙電源是忽然斷電、市政施工的保障，若是電源壞了不修，在這種狀況下，機器會斷電關機，若是積攢多了，服務容量會突減，影響業務。

風扇故障

不會立刻形成死機，可是會產生連鎖反應。風扇故障會致使cpu溫度升高，引起死機。

上述故障檢測的實現，主要是經過 Falcon監控系統 + scripts 實現，涉及了 ping/ssh/ipmi/dmesg/proc/sar…等大量系統命令和系統信息。

Falcon 運行這些scripts，檢測故障，外部應用就能夠從接口裏查詢故障列表信息，以下，

ARS從Falcon拉取當前時刻集羣內全部故障機器的列表，附帶了相應的故障信息，推送到工做流裏，進行維修。

2.3 安全策略

對機器的操做，一般是重裝、重啓、root環境修改、部署基礎agent等；此類操做每每不可逆且沒法暫停，因此須要嚴格的安全策略保證機器操做不影響線上服務或影響最小。

通過「故障檢測」這個環節後，獲得一個當前時刻全部故障機器列表，安全策略會對這個列表進行分析過濾，下表是咱們使用的安全策略列表，

 

這個安全策略表，是總結分析多個業務線的歷史case study得出來的， 在線上運行以來，未出現過誤判，保證了自動任務的安全性。

每個安全策略，實現爲工做流裏的一個原子操做，即action，結合上述重啓的例子，json配置以下，(維修的流程也可使用這些安全策略，這裏再也不單獨列出)

這些策略，可複用也可自由組合、調整順序，這對於接入不一樣業務的機器進行自動維修，有很大的便利性和靈活性，同時下降了接入成本。

若是業務有本身的安全策略需求，只需按照上述的action 方法規範，本身寫一個安全策略方法，在配置裏指定便可使用。

2.4 維修工具及SLA

機器硬件故障維修，是真實世界中的事件，這個過程須要人去到機房現場，從倉庫拿出配件，走到機架旁邊，拆卸機器，裝配硬件。

因此這個環節是「不可抗力」產生的地方，好比配件備貨不足；節假日廠商人員放假，沒法趕赴機房；遇上大會，機房封禁，不讓進入等各類問題。

1  交付時間

爲了達到流程閉環，咱們(甲方)和機器廠商(乙方)約定機器維修交付時間， 一般是36小時交付(不一樣公司、廠商可能不同)，至於怎麼解決上述「不可抗力」，由乙方負責。

2  遠程管理工具可用率

遠程管理工具是機器操做自動化的必備工具，reboot_host/repair_host底層調用的就是ipmi;

爲了儘量地減小機房現場人員操做，咱們要求sys保證遠程管理工具可用率達到 99.9%，好比，ilo，ipmi

有了這兩個SLA，咱們能夠認爲 reboot_host、repair_host 這兩個原子操做的最長耗時爲36小時，因此維修流程是必定能夠閉環的，避免了因任務中斷致使的人工介入。

固然，有了這些，也只是修復了硬件，還有系統參數設置、環境初始化、基礎agent的問題，這個內容比較多，在下一篇講。

將上述說起的技術細節彙總，獲得ARS的完整視圖，

最後，看一個自動重啓的例子，

能夠看到任務樹定義的actions 是怎麼執行的，先是執行一系列的 filter_*安全策略，而後屏蔽報警，執行服務離線，發起重啓，而後輪詢機器狀態，直到任務結束。

2.5 系統運行數據

ARS上線後，覆蓋數萬臺機器的故障自動處理，死機數量保持在10臺左右，全部硬件故障總數量保持在100臺如下，這對於一個數萬臺機器的集羣來講，是很是理想的狀態了。

人力方面，對於20人的sre 團隊，機器故障只須要 0.5人力維護系統正常運轉，例如新服務的接入、業務要求緊急修復之類的狀況；當機器規模增加時，人力並不須要相應的增長。

2.6 總結

最後，總結一下幾個關鍵點，

• 標準，定義了有哪些類型的故障，什麼故障執行什麼樣的修復，修復的標準流程

• 閉環，對於機器的操做，用任務分支覆蓋操做成功或失敗的狀況，用SLA約束廠商在約定時間內交付機器，保證流程可達到明確的結束狀態，避免人工介入

• 安全，10個安全策略組成的過濾鏈，並支持低成本的增長新策略，保證自動化任務是安全的

在本文中，有一個重要的事項沒有提到，就是環境初始化，這個再下一篇文章講述。

---

排列文字，重組感覺。

我是曲行人，平常寫碼，閒時寫點兒文字，

若是你以爲有點意思，或者有點用，能夠關注我，

我將在大腦裏的思惟原子作布朗運動時，輸出文字。

公衆號: qxren7

二維碼: