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

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

     服務器數量激增，要求提升全局掌控能力

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

     以飛天5K項目為例，由于單集群的服務器規模是5000臺，基本已獨占1個機房，所以需要對整體機房的 狀況（包括網絡、空調、維修和現場應急狀態響應等），服務器，操作系統和上層應用進行全面的掌握。為了實現這個目標，我們先是做了多次演練來驗證集群的穩 定性，包括部分網絡設備關機，整機架服務器斷電，Master服務器隨機挑選一臺斷電等。準備充分后，又做了一次“史無前例”的Failover測試―― 整體機房斷電。演習當天，飛天及ODPS的恢復過程大概歷時3個小時，整個演習過程中無數據丟失。經過這次壓力測試，我們全面了解了系統的穩定性情況，鍛 煉了運維團隊在最短時間內恢復整個集群的協作能力，積累了更好的保障用戶穩定運行的寶貴經驗。

     實現系統的自我保護和自動化修復

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

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

     大規模與精細化的平衡

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

     提升系統化的基礎環境管理能力

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

     大規模集群快速自動化部署

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

     自研的簡單日志服務SLS

     我們現在面對的大規模分布式系統比以往任何系統都要復雜，系統本身有非常多的組件，每個組件又有各自的 Log數據，而很多Log之間又相互關聯，量大且目標多。在飛天5000臺服務器的環境下，大約有5000多個并發作業需要實時計算并發度、運行狀態、使 用Quota等指標。從輸入的源數據來看，整個集群需要實時分析的性能數據產出速度大約為65MB / s，日志數據的量更會提升一個數量級。需要同時匯聚的種類和維度很多，大到機器，小到作業和文件都需要有不同的視角能切入探索，定位細節根源。而且這些 Log都是分布在每臺Slave機器上的，需要統一地匯總收集進行分析。為此，我們使用了阿里云自研的簡單日志服務（SLS）來滿足這些復雜的需求。 SLS的主要功能有以下幾點。

     ■實時收集AuditLog，監控所有操作的QPS和執行結果。

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

     ■監控每個文件、請求和Session客戶端執行生命周期。

     ■通過FileID、文件名和操作類型進行實時分析，對整個文件的操作生命周期監控。

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

     a)整個集群是否有特定錯誤；

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

     通過SLS的各項指標和Log分析，對集群的整體性能、QPS和流量等是否符合預期、作業 / 文件 / Slave上的存儲單元的生命周期是怎樣的，這些宏觀狀態和微觀細節都有完整的把握, 進而幫助我們全面掌握分布式系統的情況。

     這項簡單日志服務SLS不久前已通過阿里云對外公測，每個用戶可以免費創建1個項目，并能使用不超過10M / s的寫入流量（感興趣的讀者可以登錄http: //www.aliyun.com/product/sls了解使用）。

     不斷完善的AliMonitor監控系統

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

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

     開發和運維需要更加緊密合作

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

     結語

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

作者： 大舞
來自：http://lingyun.aliyun.com/4/tech-fly.html