飛天5K實戰經驗：大規模分布式系統運維實踐

2013年，雲梯1實作空間優化與跨機房叢集擴充，雲梯2單叢集規模從1500台更新到5000台，同時跨叢集擴充的5k項目順利取得階段性成果，阿裡成為第一個獨立研發擁有這類大規模通用計算平台的公司。當時，雲梯1、雲梯2，再加上已上線的生産叢集，阿裡整體叢集規模已超過萬台。迄今為止，全球範圍内，隻有少數幾家公司擁有如此規模的自主知識産權的叢集。我們非常幸運，能夠運維和管理如此大規模的生産叢集。但短時間大規模快速膨脹的現狀，确實也為運維工作帶來了巨大的挑戰。面對這些挑戰，我們不僅迅速實作了自動化運維，還進行了資料化管理的轉型。

傳統的運維人員通常隻面對幾十或者上百台的伺服器，規模不會太大，而且相對應用來說，每台機器都是一個獨立節點。但在大規模分布式叢集中，工作任務明顯不同：首先，運維人員面臨的伺服器動辄就是三五千台甚至上萬台，量級大幅提升；其次，分布式作業系統提供存儲、cpu排程能力、記憶體使用、網絡等功能，是基本資源的包裝整合，從邏輯上看，相當于一台計算機；第三，基于分布式系統開發的應用相當于一個分布式資料倉庫，使用者可以在上面做etl處理、sql查詢、資料導入導出等基本操作，以及實作一些matlab、統計軟體等功能。是以，與傳統運維相比，大資料運維人員要有更強大的整體把控能力，包括對機房網絡、帶寬、硬體、伺服器的性能進行優化，熟悉飛天和hadoop的上層應用，實作資料分析等，做到對各個方面的情況了如指掌。

以飛天5k項目為例，由于單叢集的伺服器規模是5000台，基本已獨占1個機房，是以需要對整體機房的狀況（包括網絡、空調、維修和現場應急狀态響應等），伺服器，作業系統和上層應用進行全面的掌握。為了實作這個目标，我們先是做了多次演練來驗證叢集的穩定性，包括部分網絡裝置關機，整機架伺服器斷電，master伺服器随機挑選一台斷電等。準備充分後，又做了一次“史無前例”的failover測試――整體機房斷電。演習當天，飛天及maxcompute的恢複過程大概曆時3個小時，整個演習過程中無資料丢失。經過這次壓力測試，我們全面了解了系統的穩定性情況，鍛煉了運維團隊在最短時間内恢複整個叢集的協作能力，積累了更好的保障使用者穩定運作的寶貴經驗。

在做5k項目測試時，一個測試作業由于使用者使用不當導緻盤古存儲伺服器檔案數突增3000萬個，造成存儲master伺服器繁忙，整體系統處理能力大幅降低，對系統造成了不小的沖擊。雖然我們發現這一問題後立刻做了相應的限制處理，但此類問題還是引發了我們的思考。一般來說，出現如此問題時，開發人員和設計人員會将原因歸結為使用者不會使用或使用不當。言下之意就是，産品層面很難避免，也無法徹底解決。但站在運維角度來看，應該有更好的解決方案，一方面不能因為使用者的一個作業失常而停止服務；另一方面，也不能總是依靠“人肉“救火。系統應該具備自我保護能力，這也是産品要努力的方向之一。

此外，大規模分布式系統選用的都是低成本伺服器，裝置損壞很常見。要實作對整個系統（包括飛天、maxcompute、linux、硬體和網絡等）的運維，就需要做好“軟硬體故障成為常态”的準備，一旦發生異常情況，能立即實作自動閉環處理，無需人工幹預。為此，阿裡的運維和開發團隊合作研發了一套異常故障自動化處理系統――華佗。目前華佗系統已具備自動處理基本硬體和服務異常等常見問題的閉環處理能力，并且還在持續完善當中（具體可參閱《走近華佗，解析自動化故障處理系統背後的秘密》一文）。

當運維的伺服器達到數千台甚至上萬台時會遇到諸多挑戰，如硬體配置的差異化、使用者數和任務數的急劇膨脹、大壓力下的邊界效應、小機率事件被觸發等。在這個前提下，我們依然成功滿足了諸如快速部署、自動化運維、監控報警、log分析和精細化計量等運維要求，主要從以下三點着手。

<b>提升系統化的基礎環境管理能力</b>

這個問題看起來很簡單，就是要保證線上幾萬台機器的環境一緻或是能實作我們想要的配置。但如果不提供底層的應用（如bios、fw等），僅是作業系統層面（如網卡驅動版本、系統參數的配置、基礎軟體的版本等），衆多品類就很難統一，尤其是當硬體基礎發生變化的時候。舉個簡單的例子，假如一台機器的某塊硬碟壞掉了，系統應用需要能夠自動将損壞的硬碟下線。背景的監控程式會進行輪詢，直到發現這塊壞盤，并将這塊盤從系統裡下線，進行修複處理後，再嘗試能否加回叢集。如果不能，就說明這個盤可能徹底壞了無法修複，系統就會自動送出報修工單，整個過程無需人為幹預。現場從業人員接到報修工單後，可以從容安排時間，統一更換壞盤。新的硬碟裝好後，系統會自動識别并添加到服務中。如果故障的是系統盤，隻要完成更換，系統就會自動觸發安裝和部署。同時要保證所有的驅動版本、fw、系統參數和軟體版本等做到同步一緻地去push。可見，在這個故障的整個處理過程中，隻有更換硬碟這個動作需要人工介入。如果有伺服器重裝的需求，我們會每周或每月定期整理，啟動自動化的部署觸發，對整台機器進行初始化處理，讓系統處于應用部署狀态，機器就會找到自己的兄弟節點去做一次克隆，恢複成跟線上的“兄弟姐妹”一模一樣的狀态，然後再上線。這個過程也是全自動完成的，唯一的人工介入就是點選觸發指令。

<b>大規模叢集快速自動化部署</b>

大家知道在運維工作中有很大一部分是部署更新。而對于大規模叢集來說部署更新這部分工作尤其重要。在飛天5k項目中，叢集機器數量短期内由1000多台直接擴充到5000台。這時，發現老的部署方式基本無法自動完成5000台伺服器部署。同時按老的方式做一次冷更新需要4~5個小時，這是應用無法接受的。于是，我們在分布式部署工具大禹上也做了許多工作，提高了飛天部署效率，支援運維人員定制自己的部署流程，管理叢集的基本資訊，同時還提供了豐富的工具集，包括檔案分發工具、遠端執行工具、叢集資訊管理工具和叢集縮容擴容等。我們重新定義了應用binaryconf的目錄結構，同時分離配置和binary部署，為配置中心統籌所有配置留出接口；分離應用binary和資料結構，在確定版本快速切換同時，保證了應用資料連貫性提供快速復原的方案；輕量化對資料庫的依賴，角色資源資訊采用讀取本地緩存方式；子產品化部署，同時支援互動式與非互動式部署。而且最主要的是，在部署時，我們對應用binany分包傳輸方式做了調整，新開發了一套多點分布并發傳輸工具，由以前單點傳輸速度越快越好，轉變為多點精确控制流量下按預期傳輸。最終在整個5k項目結項時，整個叢集冷部署更新時能夠将服務停止時間控制在20~30分鐘。

<b>自研的簡單日志服務sls</b>

我們現在面對的大規模分布式系統比以往任何系統都要複雜，系統本身有非常多的元件，每個元件又有各自的log資料，而很多log之間又互相關聯，量大且目标多。在飛天5000台伺服器的環境下，大約有5000多個并發作業需要實時計算并發度、運作狀态、使用quota等名額。從輸入的源資料來看，整個叢集需要實時分析的性能資料産出速度大約為65mb / s，日志資料的量更會提升一個數量級。需要同時彙聚的種類和次元很多，大到機器，小到作業和檔案都需要有不同的視角能切入探索，定位細節根源。而且這些log都是分布在每台slave機器上的，需要統一地彙總收集進行分析。為此，我們使用了阿裡雲自研的簡單日志服務（sls）來滿足這些複雜的需求。sls的主要功能有以下幾點。

實時收集auditlog，監控所有操作的qps和執行結果。

監控每種操作的等待延時與執行延時。

監控每個檔案、請求和session用戶端執行生命周期。

通過fileid、檔案名和操作類型進行實時分析，對整個檔案的操作生命周期監控。

雖然syslog也做了一系列分析，但由于它散布在各個機器上，查找和定位非常不友善，而通過sls可以像單機一樣查找叢集中的問題：

整個叢集是否有特定錯誤；

每天針對segfault、oom和cgroup進行離線統計，根據具體segfault事件定位具體的内容和機器，如圖1所示。

通過sls的各項名額和log分析，對叢集的整體性能、qps和流量等是否符合預期、作業 / 檔案 / slave上的存儲單元的生命周期是怎樣的，這些宏觀狀态和微觀細節都有完整的把握, 進而幫助我們全面掌握分布式系統的情況。這項簡單日志服務sls不久前已認證阿裡雲對外公測，每個使用者可以免費建立1個項目，并能使用不超過10m / s的寫入流量。

<b>不斷完善的alimonitor監控系統</b>

面對上萬台機器，好幾十個子產品，幾十萬個監控項，想要了解哪些機器監控項缺少、哪些機器監控項異常、今天有哪些監控項報警、報警了多少次、團隊中每個人每天收到多少報警、哪些是可以系統自動處理不報警的等，都需要從監控資料入手，真正對整個平台的監控有直覺而全面的了解，并在資料的指導下持續完善監控系統。

大規模的網際網路公司都極其詳細地定制化監控需求，阿裡也不例外，我們基于多年的運維經驗自主開發了一套監控系統alimonitor，并且根據業務需求不斷進行優化和完善。alimonitor是一套統一的分布式監控平台，支援系統監控、網絡監控、用戶端監控、容量監控、趨勢監控等，能自動添加基本監控，對伺服器、虛拟機、應用vip、網絡裝置、java應用等能提供準實時預警、報警，從資料采集到發出報警僅需要5秒鐘，讓運維人員第一時間掌握服務的健康狀況。同時，它還具備多種故障預測及發現方式、豐富的資料圖表展示、容量規劃和報警，以及視圖的定制等功能。

和傳統的業務系統相比，分布式系統規模大和複雜性高，需要開發和運維更加緊密地合作。從運維人員的角度來看，運維就是對線上生産系統負責，是線上系統的owner，要全面且深入地了解産品。從開發人員的角度來說，如果對運維工作一無所知，那麼也很難開發出可靠的産品。是以，如果開發人員和運維人員之間存在壁壘，顯然會大大影響産品的穩定性。需要注意的是，這不是要模糊開發人員和運維人員的職責，雙方仍然要保持明确的分工，但在技術技能上，雙方應該更加靠近。例如，在飛天5k項目中，運維人員和開發人員緊密合作，用最短的時間開發完成了自有的大規模部署系統（大禹）和異常故障自動化處理系統（華佗）。而且在共同工作中，雙方都收獲甚豐。

對于阿裡這種規模的網際網路公司而言，随着體量越來越大，使用者數量和基礎設施投入都在快速膨脹，資料也在呈幾何倍數增長。是以，在運維工作上已很難找到其他企業的成功經驗來借鑒，但又不能憑空揣測解決方案，因為一旦判斷失誤，就會給公司造成巨大的損失。在這種情況下，我們深刻感受到隻有一條通路：通過對真實資料進行分析和預測，将判斷失誤的機率降到最低。我們相信，隻要資料真實并且挖掘得足夠深入，一定能找到最優的解決方案。例如，在日常運維中，我們已可以收集到不同通道的資料，如伺服器溫度、負載、磁盤、應用狀況等，而且資料種類和數量都在不斷增加。如果能夠找到其中的聯系并快速分析，将會給我們的工作帶來更大變化。而基于技術分析優化運維水準，将是一個值得持續探究的課題，也是我們團隊一個比較大的挑戰。

<a href="https://lingyun.aliyun.com/4/tech-fly.html" target="_blank"><b>原文連結</b></a>