【智能案例】阿裏百萬級服務器自動化運維系統StarAgent揭秘

論文類別:計算機論文 > 互聯網研究論文
上傳時間:2017/12/4 14:50:27

  (免費論文下載中心訊)還記得那些年我們半夜爬起來重啟服務器的黑暗歷史嗎?雙11期間,阿裏巴巴百萬量級主機管理能安全、穩定、高效,如絲般順滑是如何做到的?阿裏巴巴運維中臺技術專家宋意,首次直播揭秘阿裏IT運維的基礎設施StarAgent,詳細分析StarAgent是如何支持百萬級規模服務器管控?如何像生活中的水電煤一樣,做好阿裏運維的基礎設施平臺?

  嘉賓介紹

  宋健(宋意):阿裏巴巴運維中臺技術專家。工作10年一直專註在運維領域,對於大規模運維體系、自動化運維有著深刻的理解與實踐。2010年加入阿裏巴巴,目前負責基礎運維平臺。加入阿裏後曾負責:從零建立支付寶基礎監控體系、推動整個集團監控體系整合統一、運維工具&測試PE團隊。

  StarAgent

  從雲效2.0智能化運維平臺(簡稱:StarOps)產品的角度來看, 可以將運維劃分為兩個平臺,基礎運維平臺和應用運維平臺。基礎運維平臺是統一的,叫StarAgent,它可以當之無愧的說是阿裏巴巴IT運維的基礎設施。

  從1萬臺服務器發展到10萬臺,又逐步達到百萬級服務器,基礎設施重要性並不是一開始就被意識到的,是逐漸被發現的過程。無論是運維系統穩定性、性能、容量顯然已經無法滿足服務器數量和業務的快速增長。在2015年我們做了架構升級,StarAgent系統成功率從90%提升到了99.995%,單日調用量也從1000萬提升到了1億多。

  服務器規模達到百萬級的企業,在全球應該也是屈指可數的,而且很多企業內部又按業務做了拆分,各業務管理自己的服務器,一套系統管理百萬臺機器的場景應該更少,因此我們沒有太多可以借鑒的東西,大部分情況都是自己在摸索中前進,我們的系統也是在這個過程中一步步演變成今天這個樣子。

  產品介紹

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  如上圖所示,StarAgent分了三層:主機層、運維層、業務層,各團隊按分層的方式進行協作,通過這個圖可以大致了解StarAgent產品在集團所處的位置,是集團唯一官方默認的Agent。

  • 主機層:指所有服務器,每臺機器上默認安裝了我們的Agent。

  • 運管層:指運維管控系統,包括應用運維體系、數據庫運維體系、中間件運維體系、安全體系,各專業領域產品有獨立Portal,通過StarAgent來實現對服務器的操作。

  • 業務層:指各個BU的業務,大部分BU會直接使用運維層的管控系統,但有的BU可能會有些個性的需求,所以也會有基於下層能力封裝出面向自己業務的一個專用運維portal。

  應用場景

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  StarAgent貫穿整個服務器的生命周期:

  • 資產核對:服務器上架後會設置為網絡啟動,然後會加載一個mini的OS在內存中運行,這個OS中就已經包含了我們的Agent,OS啟動後就可以下發指令來采集服務器的硬件信息做資產核對,如CPU、內存、磁盤的廠商及大小信息等。

  • OS安裝:交付業務前會先安裝OS,安裝什麽樣的OS也是向這個內存中的Agent下發命令實現的。

  • 環境配置:OS安裝完成後像機器上的賬號、通用運維腳本、定時任務等基礎環境的初始化。

  • 應用發布:應用配置與軟件包的上線發布。

  • 運行監控:上線後應用與業務的監控腳本、監控Agent的安裝。

  • 日常運維:登錄服務器、單機、批量等日常運維操作,包括業務下線前的清理工作等

  產品數據

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  這也是我們產品在阿裏內部的一些數據,每天有上億次的服務器操作,1分鐘可以操作50萬臺服務器,插件有150多個,管理服務器規模在百萬級,Agent資源占有率也特別低,支持Linux/Windows主流發行版。

  產品功能

  StarAgent核心功能可以總結為兩大塊:管控通道和系統配置。這與開源的

  saltstack/puppet/ansible等配置管理產品類似,我們做的更精細一些。

  • 管控通道:所有運維操作最終都會轉化為命令到服務器上去執行,這個命令通道是全網唯一的,這裏會有相應的用戶權限控制、操作審計、高危命令攔截等能力。

  • 系統配置:公共運維腳本、定時任務、系統賬號、監控Agent等等,這些配置會在Agent啟動後自動初始化,OS中默認打包有Agent,所以可以做到開機後全自動完成服務器運維基礎環境的初始化。

  產品功能:

  按照Portal、API、Agent細分後的功能列表,Portal主要給一線開發與運維同學使用, API更多是給到上層運維系統來調用,Agent代表每臺機器上直接可以使用的能力。

  Portal

  • 運維市場:也叫插件平臺,類似於手機中的應用市場。各個業務的負責人在市場中如果發現了一些不錯的小工具,點下安裝就可以自動安裝到業務對應的機器上,業務如果新擴容了服務器也會自動地安裝這些小工具。小工具的開發也是來自於一線的同學,大家都可以把自己開發的工具上傳到運維市場,分享給其他人使用。

  • WEB終端:在Portal上點下一臺機器後會自動彈出一個終端,和SSH登錄到服務器的效果完全一樣,基於當前登錄人信息全自動鑒權,這個終端還可以通過JS的方式嵌入到任何其它網頁中。

  • 文件分發:比較好理解就不展開介紹了。

  • 定時任務:與crontab類似,不過我們支持秒級並且可以打散執行,比如對一批機器增加每分鐘執行一次的定時任務,用crontab所有機器會固定的在每分鐘第1秒執行,我們在保證每分鐘執行一次的同時每臺機器上的執行時間不一樣。

  • 主機賬號:包括三塊功能:個人登錄服務器的賬號、機器上admin等公共賬號、一臺機器與其它機器之間打通SSH通道。

  • API賬號:與右邊的API功能是緊密相關的,如果要使用右邊這些能力,必須先申請一個API賬號。

  API

  • CMD:調用時傳入目標機器與命令信息,就可以實現讓指定臺機器執行命令,登錄機器上執行的命令都可以通過CMD接口來調用。

  • Plugin:對應前面的運維市場,如果通過運維市場把一些腳本安裝到機器上,可以通過plugin的方式來直接執行這些腳本。

  • File/Store:兩者都是做文件分發,區別是file依賴下載源,store可以在調用HTTP API時直接把腳本內容POST過來。File基於P2P實現,在阿裏內部有一個叫蜻蜓的產品專門做文件下載,好處是幾百臺、幾千臺機器同時下載時只會回源一次,對源的壓力非常小,機器之間能夠互相共享下載,目前蜻蜓已經開源。

  • Action:對以上功能組裝使用,例:先用file去下載腳本,下載完成後再用cmd來執行,並且中間支持and or的條件判斷,下載成功才會用cmd執行。

  Agent

  • Hostinfo:提供采集服務器的主機名、IP、SN等信息。

  • 數據通道:在每臺機器上執行的命令或腳本的輸出直接丟到這裏,會自動把數據上傳到中心,然後在中心消費這些數據。

  • 增量日誌和P2P文件:都是第三方來開發的,在運維市場通過插件的方式安裝到每臺機器上。

  右邊是批量執行命令的功能,先選中一批機器,在這個頁面輸入的命令都會發到這一批機器上。

  系統架構

  邏輯架構

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  我們的系統是三層架構,Agent安裝在每臺機器上,與channel建立長連接,然後channel定期把連接自己的agent信息上報到中心,中心會維護完整的agent與channel關系數據。分享兩個流程:

  1.Agent註冊

  Agent有一個默認配置文件,啟動後首先連接ConfigService,連接時會上報本機的IP、SN等必要信息,ConfigService計算出應該連哪個channel集群,返回給channel列表,收到結果後斷開與ConfigService的連接,然後與channel建立起長連接。

  2.下發命令

  外部系統都是調用proxy來下發命令,proxy收到請求後會根據目標機器查出對應channel,然後把任務下發給channel,channel再把命令轉發到agent去執行。

  部署架構

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  最下面是每個IDC,channel會在每個IDC中部署一套集群,Agent會隨機在其中的一臺建立長連接。上面就是中心,中心做了雙機房容災部署,同時在線提供服務,其中一個機房掛掉對業務是沒有影響的。

  問題&挑戰

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

如上圖:是我們前年在做系統重構時遇到的問題:

  前三個問題有點類似,主要是任務由狀態導致,1.0的manager可以理解為2.0中的proxy,server等同於channel,每時每刻線上都有大量系統在下發命令,在1.0中如果把manager/server/agent任何一個角色重啟,那麽在這條鏈路上的任務都會失敗,比如server重啟後與它相連的agent都會斷開,因為鏈路斷了,當時經過這臺server下發的命令就拿不到結果了。重啟server又會引發第六個負載不均的問題,假設一個IDC中有一萬臺機器,兩臺server各連了5000臺,重啟後這一萬臺就全連到了一臺server上。

  用戶如果調用API下發命令失敗就會找過來讓我們查原因,有的時候確實是系統的問題,但也有很多是本身的環境問題,比如機器宕機、SSH不通、負載高、磁盤滿等等,百萬級規模的服務器,每天百分之一的機器也有一萬臺,由此帶來的答疑量可想而知。當時我們非常痛苦,團隊每天一半的人員在做答疑,半夜有斷網演練還需要爬起來去重啟服務來恢復。

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  面對這些問題如何解決呢?我們將問題分為系統問題和環境問題兩大類。

  系統問題

  我們把系統做了一次徹底的重構,采用分布式消息架構,還是以下發命令為例,每次下發是一次任務,在2.0中對每個任務增加了狀態,proxy在收到下發命令請求後,會先記錄並把狀態置為收到任務,然後再向agent下發,agent收到任務後會立即響應,proxy收到agent的響應後會把狀態置為執行中,agent執行完成後主動上報結果,proxy收到結果後再把狀態置為執行完成。

  整個過程中proxy與agent之間的消息都有確認機制,沒有得到確認就會進行重試,這樣任務執行過程中涉及角色如果重啟,對任務本身就沒有太大影響了。

  2.0中channel集群內的機器之間會互相通信,定期報告自己連的agent數量等信息,結合收到的信息與自己的信息,如果自己連的agent過多,會自動斷開近期無任務執行的機器,通過這樣的方式解決負載均衡的問題。中心節點與所有channel都有長連接,同時保存有每臺channel連接的agent數量,當發現某個機房有channel異常或者容量過高時,會自動觸發擴容或者從其它機房臨時借調channel,在容量恢復後又會自動剔除擴容的channel。

  環境問題

  在2.0中proxy/channel/agent每一層都有詳細的錯誤碼,通過錯誤碼可以直觀判斷是什麽原因導致的任務出錯。

  針對機器本身的問題,與監控系統中的數據打通,任務失敗後會觸發環境檢查,包括宕機、磁盤空間、負載等,如果有相應問題API會直接返回機器有問題,並且把機器的負責人也一並返回,這樣用戶一看結果就知道什麽原因該找誰處理。同時還會把這些診斷能力用釘釘機器人的方式開放出來,這樣大家平時可以直接在群裏@機器人來做檢查確認。

【智能案例】阿里百万级服务器自动化运维系统StarAgent揭秘

  穩定

  通過前面的介紹可以看到我們其實是運維的基礎設施,就像生活中的水電煤一樣,大家所有對服務器的操作強依賴我們。當我們出現故障的時候,如果線上業務也出現了嚴重故障,這時候業務故障只能幹等著,因為操作不了服務器,做不了發布和變更,所以對系統穩定性的要求非常高,做到了同城雙機房、異地多中心容災部署,依賴的存儲有mysql/redis/hbase,這些存儲本身就有高可用保障,在這個之上我們又做了存儲間的冗余,確保任何一個單一存儲故障不會影響到業務,相信整個業內很少有系統會做到這個程度。

  安全

  1分鐘可以操作50萬臺服務器,輸入命令敲回車就這麽一瞬間,就可以操作數萬臺機器,如果是個惡意的破壞性操作,影響可想而知。所以做了高危命令阻斷的功能,對於一些高危操作自動識別與攔截。整個調用鏈路也是經過加密與簽名,確保第三方無法破解或篡改。針對API賬號可能存在的泄露問題,還開發了命令映射的功能,把操作系統中的命令用映射的方式改掉,比如執行reboot命令,可能要傳入a1b2才行,每個API賬號的映射關系都是不一樣的。

  環境

  機器宕機這類環境問題,通過與監控數據打通解決,前面已經講過,網絡隔離的問題也不再過多陳述。這裏重點說明下CMDB中錄入的數據與Agent采集的數據不一致的問題,主要是SN、IP這些基礎信息,因為大家在使用的時候都是先從CMDB取出機器信息,再來調用我們的系統,如果不一致就會導致調用直接失敗,為什麽會出現SN/IP不一致的問題?

  CMDB中的數據一般由人工或者其它系統觸發錄入,而Agent是從機器上真實采集的,有的機器主板沒燒錄SN、有的機器有很多塊網卡等,環境比較復雜各種情況都有。

  這種情況就是通過建立規範來解決,分別制定SN、IP采集規範,允許機器上自定義機器的SN/IP,配合規範還提供有采集工具,不僅是我們的Agent,所有其它采集機器信息的場景都可以使用這個采集工具,當規範發生更新時我們會同步更新小工具,以此實現對上層業務的透明化。(來源:雲棲社區 編選:中國電子商務研究中心)

下载论文

論文《【智能案例】阿裏百萬級服務器自動化運維系統StarAgent揭秘》其它版本

互聯網研究論文服務

網站聲明 | 聯系我們 | 網站地圖 | 論文下載地址 | 代寫論文 | 作者搜索 | 英文版 | 手機版 CopyRight@2008 - 2017 免費論文下載中心 京ICP备17062730号