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

前言

大規模集羣，一般是一家公司通過多年發展積累起來的，機器規模達到數萬臺，服務類型涉及接入、web、業務邏輯、cache、大數據、機器學習等，有如下特色，

特色	現象&問題
機器規模大, 過保機器多，故障率高	數萬臺機器的集羣，過保機器超過30%，硬件故障率約1.3%，其中磁盤故障率約7.5%
業務模塊數目多，上下游關聯複雜	處理機器問題須要同步處理上下游關係，包括監控、變動系統、狀態同步等
機器環境差別大，故障處理、環境部署方式各異	環境設置不同，包括系統、內核參數，基礎環境依賴等
機器利用率不合理	A業務機器資源緊缺，B業務機器空閒，卻沒法快速調配使用
機器歸屬管理困難	不一樣業務的機器，借用、歸還、環境清理、過保下架等流程冗長，溝通成本高
機器自動化處理工具不具有通用性，複用性低	A業務機器的自動處理工具，沒法直接在B業務使用，運維工程師重複開發，無沉澱

 

這些問題，存在於整個機器生命週期裏，從上架通電到下架報廢，不按期製造業務故障，例如因機器故障致使的部署失敗、版本不一致、讀寫異常、性能陡降等；平常消耗一線運維10%～20%的時間，還形成大量的機器、機架資源浪費，得不到有效利用。

 

本系列文章目錄以下，講述瞭解決這些問題的方案和實現，實際效果，踩過的坑，但願對讀者有幫助。

 

1. 機器運維相關的數據

2. 機器運維模式的思考

3. 機器故障自動處理

4. 機器基礎環境管理

5. 大規模集羣機器快速交付

6. 機器平常運維效率

 

注： 運維工程師= SRE = OP，這三個名詞有各自的定義，爲表述方便，這裏簡單地認爲是同義詞。

 

 

1. 機器運維相關的數據

 

一切從一次機器「摸底排查」開始。

 

排查的結果是: 數萬臺機器的集羣，過保機器約佔30%，硬件故障率約1.3%，其中磁盤故障率約7.5%，這意味着近千臺整機，幾千塊磁盤處於故障狀態，還有數量不小的過保機器、無主機器無人跟進處理，機器資源浪費嚴重。

 

同時，咱們訪談了各業務線運維同事，從前端web到後端存儲，從在線到離線，詢問「關於機器運維存在什麼問題」，獲得了各式各樣沒法量化的「苦水」；

 

• 「Oncall 每週都要重啓、報修十幾臺機器，又摘服務又傳數據又恢復服務什麼的，煩死了」

• 「上線部署時，總是有一些機器部署失敗，都是些死機、根目錄讀寫失敗的，處理這些長尾要幾個小時」

• 「此次case study 是機器壞了修好後忘了同步程序，版本不一致，部署時把老版本程序帶起來了，這太坑了！」

• 「喂，鍵盤仔，limits參數沒改，服務起不來啊」

• 「你這自動處理系統不行啊，把有數據的機器重裝了，數據丟了，你發故障報告吧!」「誰叫你不認真看個人文檔啊，我這是前端機器故障處理系統，你有業務數據就不能用! 你發!」

• 「業務緊急擴容，借咱們50臺機器吧」, 1個小時過去了，sre還在確認這些機器上各個服務都是誰的，要停服

• …

 

這個苦水列表還能夠再列好多條，我反問他們爲何平時不反饋出來，緣由大致都是：

這些問題都是零碎的，平時這幾臺機器死機，那幾臺機器掉塊盤，還有些機器處於薛定諤狀態，內存報CE\UE信息, 不知道何時會出問題；

反饋出來，經理強調一下，你們集中處理一波，故障數量暫時下去以後，積攢一段時間又上來，如此反覆，endless。

 

經過統計機器故障、細化機器操做任務耗時、歷史故障case的方式，咱們獲得瞭如下數據：

• 過保機器約佔30%，硬件故障率約1.3%，其中磁盤故障率約7.5%

• 機器運維任務佔一線運維工程師總時間的20%左右

• 因機器故障致使的業務故障，平均每月有1～3次

 

因此咱們要從業務穩定性、運維效率、硬件成本出發，解決這些問題。

 

1. 機器運維模式的思考

 

 

在傳統的運維模式裏，機器歸屬自然是按業務來分的，即某個業務的運維工程師負責本業務機器的運維工做。這種劃分方式存在如下問題，

1. 1. 重複投入人力，如機器故障維修，各業務工程師都要作故障檢測、服務離線、硬件維修、環境初始化、服務上線等相同流程的工做，且因爲業務的差別(如無狀態的web服務，有狀態的存儲、模型計算服務)，實現的方案不具有通用性
   2. 工程師的主要工做是業務運維，沒有精力去解決機器任務長尾、自動化安全性、通用性、擴展性問題，已實現的方案沒法複用，機器運維效率沒有真正提升

 

 

 

 

針對傳統運維模式存在的問題， 咱們在運維人員和機器之間加入了「機器管理系統」，消除機器環境、故障修復流程等差別，統一提供故障管理、環境管理、歸屬管理、任務管理、統計管理的功能組件，向運維工程師屏蔽機器運維細節，提升機器運維操做效率、機器資源利用率；

同時考慮了可擴展性、通用性，即新業務機器可低成本地歸入管理、不一樣業務類型的處理邏輯可經過插件的方式集成到系統中，有利於自動化程度的提高，工具的複用，自動化任務的沉澱。

經過這種方式，逐步提升機器運維效率，減小故障機器的積攢，而故障機器的減小，間接提升了穩定性。

 

 

2. 機器故障自動處理

 

咱們從最大的痛點開始，一線運維平常要花費大量人力處理機器故障，以下圖所示，

 

 

監控系統監控到硬件故障、任務系統執行失敗、rd使用機器時的異常，都須要運維工程師來處理。

 

爲何作不到自動化？咱們圍繞如下4方面來分析。

1. 通用性與差別化
2. 通用設計與具體實現的關聯
3. 自動化與安全
4. 流程、閉環、擴展性

 

 

通用性與差別化

在不一樣的環境裏，故障自動處理過程的差別化是很是大的。

1. 若是是無狀態服務，好比 nginx web服務、java application服務，一般只須要重啓機器、重刷環境、從新部署服務就能夠，若是是硬件故障，能夠直接報修，不用處理上下游。

 

2. 若是是有狀態服務，好比索引服務、推薦服務、模型訓練服務，業務方是但願儘量在不重啓機器的狀況下修復，更不能直接報修重裝，由於這涉及上下游關係更新、部署系統摘除、數據遷移等一系列工做，耗時從幾個小時到幾天都有可能。

 

3. 對於不一樣故障，不一樣業務的處理方式也不同。例如，

內存、cpu、風扇這些硬件故障，不必定會立刻死機，但存在宕機風險，無狀態服務能夠接受一旦出現這些風險就直接停服報修，而有狀態服務不容許；

對於系統故障，好比文件系統異常，出現 Input/Output Error，此時系統已經異常，基礎agent 已經沒法正常工做，部署、執行任務都會失敗，但服務還正常跑着，因此業務不但願停機；

對於基礎環境文件缺失，業務更是但願不停機。

 

4. 機器修復後，服務恢復的方式也不同，無狀態服務只要保證和線上版本一致就行； 而有狀態服務，涉及從哪裏拷數據，拷完後啓動加載數據，確認加載完以後，才能引流。

 

能夠看到，這麼多的差別，是各業務線的機器運維工具沒法複用的緣由，

若是仍然按現有模式來作自動維修，能夠預見的結果是，新系統也會陷入一大堆的複雜修復邏輯的泥潭裏，因此咱們第一個要解決的就是通用性問題。

 

通過分析抽象不一樣業務的維修流程，獲得一個通用的維修流程：故障檢測、服務離線、故障維修、環境初始化、服務上線，以下圖，

 

 

 

 

這個流程，不論是有狀態服務，仍是無狀態服務，以何種方式維修，均可以覆蓋。

 

 

通用設計與具體實現的關聯

 

第二個問題，通用流程如何與具體的差別化邏輯關聯。

 

好比針對「故障維修」這個環節，「磁盤硬件故障修復」和「文件系統異常修復」是不一樣的，如何關聯起來，有兩個思路：

1按現有模式，各自寫一個修復工具，遇到什麼樣的問題，就調用那個修復工具。這種方式，效率、成本、效果都很差，由於總會有新的問題出現，就得寫新的修復工具，寫完後還得從新加載註冊修復工具，設置問題與工具的對應關係，而後還得保證修復工具的成功率，這些都是成本。

 

2 通過運維工程師們討論，最終的修復方法是兩個原子操做：重啓、重裝。

由於，修復工具也有較大的機率修復失敗，當修復工具也修很差時，只能重裝，還不如一開始就選擇重裝。

 

好比磁盤文件系統故障，選擇單盤在線修復從新掛載，這個過程異常艱難，lsof找出佔用磁盤的服務，kill / fuser 停服，umount磁盤，修改fstab，fsck/fdisk，mount，這麼複雜且耗時的操做下來，可能大機率修很差，真是一頓操做猛如虎，一當作功率二點五； 而選擇重裝，無硬件問題的，基本30分鐘內交付，有硬件故障須要更換配件的，也有SLA 約定的交付時間。

 

據此咱們獲得一張「簡單粗暴」的表格，

 

故障類型	處理方式	備註
宕機故障	重啓	若是重啓失敗，看成硬件故障，走重裝
硬件故障	重裝	硬件故障包括：cpu/內存/磁盤/風扇/電源故障

注: 系統部在重裝機器時，會對硬件進行檢測，若是有硬件故障，會先修復再重裝

 

 

 

自動化與安全

 

這個問題，是從穩定性、安全角度考慮的。

若是自動化以後，效率是提升了，可是重啓/重裝錯了機器，那還不如不搞自動化，因此自動任務的安全策略也做爲重點考慮，在真正開始執行自動任務以前，設置多道防線，例如白名單/閾值/服務容量等，更多安全策略細節，將在後續章節中闡述。

 

加入安全策略後的流程：

 

 

 

流程、閉環、擴展性

 

如何把上述流程銜接起來? 工做流自然就是幹這個的。

可是這裏的「銜接」，有運維角度看重的要求： 閉環 和 擴展性。

 

下面這張圖展現了 閉環、擴展性的特性。

 

 

 

 

 

1 閉環

在以往的機器自動化工具中，始終面臨一個棘手問題，就是自動化任務的「中斷」，

好比，

自動任務發起重啓，超過1小時未啓動

發起硬件維修的機器，超過規定時間仍未交付

 

中斷以後，每每沒有後續的處理動做，一般都是機器的使用方催促了，纔去人工介入處理，這使得rd、sre都以爲「自動化工具並不自動，很是挫！」。

 

咱們經過 「任務分支「 來解決「中斷」的問題。

一臺機器出現故障後，是有明確的狀態的，要麼機器修復，恢復上線；要麼機器不可修復(一般是過保)，下架處理；從圖中能夠看到，若是「故障維修」環節沒法完成，則系統能夠執行「機器下架」分支，最終達到流程結束的狀態，而不是「機器發起維修了，可是好久也沒有交付「的中間狀態。

有了任務分支，就無需人工介入，造成閉環，最大程度地保證了自動化。

 

2 擴展性

服務上下線，是一個複雜的過程，涉及新部署一個實例，數據拷貝，從上游摘除等操做， 這就要求系統能方便地、低成本地增長任務節點。

咱們經過任務鏈表來實現，從圖中「服務離線」環節能夠看到，action 是能夠擴展數量和指定順序的，實現細節會在後續章節中闡述。

 

通過上面的分析，可知自動維修系統由幾個關鍵子系統組成，

1 工做流系統

2 故障檢測

3 安全策略

4 維修工具及SLA

 

下一篇開始闡述具體的實現。