雙11黑科技,阿里百萬級服務器自動化運維繫統StarAgent揭祕

摘要:
還記得那些年咱們半夜爬起來重啓服務器的黑暗歷史嗎?雙11期間,阿里巴巴百萬量級主機管理能安全、穩定、高效,如絲般順滑是如何作到的?阿里巴巴運維中臺技術專家宋意,首次直播揭祕阿里IT運維的基礎設施StarAgent,詳細分析StarAgent是如何支持百萬級規模服務器管控?如何像生活中的水電煤同樣,作...

導讀:還記得那些年咱們半夜爬起來重啓服務器的黑暗歷史嗎?雙11期間,阿里巴巴百萬量級主機管理能安全、穩定、高效,如絲般順滑是如何作到的?阿里巴巴運維中臺技術專家宋意,首次直播揭祕阿里IT運維的基礎設施StarAgent,詳細分析StarAgent是如何支持百萬級規模服務器管控?如何像生活中的水電煤同樣,作好阿里運維的基礎設施平臺?

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

StarAgent

從雲效2.0智能化運維平臺(簡稱:StarOps)產品的角度來看, 能夠將運維劃分爲兩個平臺,基礎運維平臺和應用運維平臺。基礎運維平臺是統一的,叫StarAgent,它能夠當之無愧的說是阿里巴巴IT運維的基礎設施。
從1萬臺服務器發展到10萬臺,又逐步達到百萬級服務器,基礎設施重要性並非一開始就被意識到的,是逐漸被發現的過程。不管是運維繫統穩定性、性能、容量顯然已經沒法知足服務器數量和業務的快速增加。在2015年咱們作了架構升級,StarAgent系統成功率從90%提高到了99.995%,單日調用量也從1000萬提高到了1億多。
服務器規模達到百萬級的企業,在全球應該也是屈指可數的,並且不少企業內部又按業務作了拆分,各業務管理本身的服務器,一套系統管理百萬臺機器的場景應該更少,所以咱們沒有太多能夠借鑑的東西,大部分狀況都是本身在摸索中前進,咱們的系統也是在這個過程當中一步步演變成今天這個樣子。

產品介紹
0ebe898e55a9866e6669130c5cb7ebd5c2426bc9

如上圖所示,StarAgent分了三層:主機層、運維層、業務層,各團隊按分層的方式進行協做,經過這個圖能夠大體瞭解StarAgent產品在集團所處的位置,是集團惟一官方默認的Agent。

  • 主機層:指全部服務器,每臺機器上默認安裝了咱們的Agent。
  • 運管層:指運維管控系統,包括應用運維體系、數據庫運維體系、中間件運維體系、安全體系,各專業領域產品有獨立Portal,經過StarAgent來實現對服務器的操做。
  • 業務層:指各個BU的業務,大部分BU會直接使用運維層的管控系統,但有的BU可能會有些個性的需求,因此也會有基於下層能力封裝出面向本身業務的一個專用運維portal。

應用場景

78b939985c087cf5350f22549d09cf1217de137c

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

  • 資產覈對:服務器上架後會設置爲網絡啓動,而後會加載一個mini的OS在內存中運行,這個OS中就已經包含了咱們的Agent,OS啓動後就能夠下發指令來採集服務器的硬件信息作資產覈對,如CPU、內存、磁盤的廠商及大小信息等。
  • OS安裝:交付業務前會先安裝OS,安裝什麼樣的OS也是向這個內存中的Agent下發命令實現的。
  • 環境配置:OS安裝完成後像機器上的帳號、通用運維腳本、定時任務等基礎環境的初始化。
  • 應用發佈:應用配置與軟件包的上線發佈。
  • 運行監控:上線後應用與業務的監控腳本、監控Agent的安裝。
  • 平常運維:登陸服務器、單機、批量等平常運維操做,包括業務下線前的清理工做等。

產品數據
e5cb76440fd14268610ce3ff2cebd941027b5657

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

產品功能
3277278992de386edd863707523393f4b0280c45

StarAgent核心功能能夠總結爲兩大塊:管控通道和系統配置。
這與開源的saltstack/puppet/ansible等配置管理產品相似,咱們作的更精細一些。

  • 管控通道:全部運維操做最終都會轉化爲命令到服務器上去執行,這個命令通道是全網惟一的,這裏會有相應的用戶權限控制、操做審計、高危命令攔截等能力。
  • 系統配置:公共運維腳本、定時任務、系統帳號、監控Agent等等,這些配置會在Agent啓動後自動初始化,OS中默認打包有Agent,因此能夠作到開機後全自動完成服務器運維基礎環境的初始化。
bd12e6556e69b10166e41e2e35a67c8f29c72ee7

按照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文件:都是第三方來開發的,在運維市場經過插件的方式安裝到每臺機器上。

68788b9e82a48168d67bdbab3d4fb7774e8ace14
圖:左邊是Web終端,自動鑑權並且能夠經過JS的方式嵌到任何web頁面裏面。
右邊是批量執行命令的功能,先選中一批機器,在這個頁面輸入的命令都會發到這一批機器上。

系統架構

邏輯架構
151181d0d72d998530187c8e30d107917fe15de5

咱們的系統是三層架構,Agent安裝在每臺機器上,與channel創建長鏈接,而後channel按期把鏈接本身的agent信息上報到中心,中心會維護完整的agent與channel關係數據。分享兩個流程:
1.Agent註冊

Agent有一個默認配置文件,啓動後首先鏈接ConfigService,鏈接時會上報本機的IP、SN等必要信息,ConfigService計算出應該連哪一個channel集羣,返回給channel列表,收到結果後斷開與ConfigService的鏈接,而後與channel創建起長鏈接。
2.下發命令

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

部署架構
f45f4b58a7cba328318a117a267fff2ab37ba3bb

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

問題&挑戰
b6dc55b4a54bf42530c6742d34f18c0051920e58

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

前三個問題有點相似,主要是任務由狀態致使,1.0的manager能夠理解爲2.0中的proxy,server等同於channel,每時每刻線上都有大量系統在下發命令,在1.0中若是把manager/server/agent任何一個角色重啓,那麼在這條鏈路上的任務都會失敗,好比server重啓後與它相連的agent都會斷開,由於鏈路斷了,當時通過這臺server下發的命令就拿不到結果了。重啓server又會引起第六個負載不均的問題,假設一個IDC中有一萬臺機器,兩臺server各連了5000臺,重啓後這一萬臺就全連到了一臺server上。
用戶若是調用API下發命令失敗就會找過來讓咱們查緣由,有的時候確實是系統的問題,但也有不少是自己的環境問題,好比機器宕機、SSH不通、負載高、磁盤滿等等,百萬級規模的服務器,天天百分之一的機器也有一萬臺,由此帶來的答疑量可想而知。當時咱們很是痛苦,團隊天天一半的人員在作答疑,半夜有斷網演練還須要爬起來去重啓服務來恢復。

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

d051de2d76434b10ee48da0e5da8157dc1518856

系統問題

咱們把系統作了一次完全的重構,採用分佈式消息架構,仍是如下發命令爲例,每次下發是一次任務,在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會直接返回機器有問題,而且把機器的負責人也一併返回,這樣用戶一看結果就知道什麼緣由該找誰處理。同時還會把這些診斷能力用釘釘機器人的方式開放出來,這樣你們平時能夠直接在羣裏@機器人來作檢查確認。

af76c23fd176ca1fa1dc0e9e048651c2d88b2d69
穩定

經過前面的介紹能夠看到咱們實際上是運維的基礎設施,就像生活中的水電煤同樣,你們全部對服務器的操做強依賴咱們。當咱們出現故障的時候,若是線上業務也出現了嚴重故障,這時候業務故障只能乾等着,由於操做不了服務器,作不了發佈和變動,因此對系統穩定性的要求很是高,作到了同城雙機房、異地多中心容災部署,依賴的存儲有mysql/redis/hbase,這些存儲自己就有高可用保障,在這個之上咱們又作了存儲間的冗餘,確保任何一個單一存儲故障不會影響到業務,相信整個業內不多有系統會作到這個程度。

安全

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

環境

機器宕機這類環境問題,經過與監控數據打通解決,前面已經講過,網絡隔離的問題也再也不過多陳述。這裏重點說明下CMDB中錄入的數據與Agent採集的數據不一致的問題,主要是SN、IP這些基礎信息,由於你們在使用的時候都是先從CMDB取出機器信息,再來調用咱們的系統,若是不一致就會致使調用直接失敗,爲何會出現SN/IP不一致的問題?
CMDB中的數據通常由人工或者其它系統觸發錄入,而Agent是從機器上真實採集的,有的機器主板沒燒錄SN、有的機器有不少塊網卡等,環境比較複雜各類狀況都有。
這種狀況就是經過創建規範來解決,分別制定SN、IP採集規範,容許機器上自定義機器的SN/IP,配合規範還提供有采集工具,不只是咱們的Agent,全部其它採集機器信息的場景均可以使用這個採集工具,當規範發生更新時咱們會同步更新小工具,以此實現對上層業務的透明化。
相關文章
相關標籤/搜索