今天我們來聊一個很高階的話題:如何設計一個大規模遠端命令執行系統

NO IMAGE

640?wx_fmt=gif&wxfrom=5&wx_lazy=1

作者簡介

運小宇    百度高階研發工程師

640?wx_fmt=png&wxfrom=5&wx_lazy=1

負責基礎運維元件相關開發工作,致力於運維基礎設施的建設,夙興夜寐,只為提高裝置操作的便利性,一橋飛架南北,天塹變通途。

前文回顧

今天我們來聊一個很基礎的話題:如何執行一條命令

乾貨概覽

書接前文,在上一篇文章中我們介紹了大規模命令執行的意義以及所面對的問題和困難,簡單介紹了百度叢集控制系統(Cluster Control System,以下簡稱CCS系統)通過構建兩級資料模型四級排程模型三級代理執行的方式解決了這些問題,在本篇文章中,我們將續接前文,繼續對CCS系統的設計實現進行詳細剖析。

兩級資料模型

設計考量

回顧前文,在面臨的需求中我們提到,需要在大規模的伺服器上執行命令並且能夠靈活控制。為了滿足這樣的需求,建立資料模型時,只有執行資訊是不夠的,還要有控制資訊,如路由、併發度、暫停點等,兩者組合在一起,構成了CCS系統中的資料模型。

控制資訊

控制資訊包括命令傳遞所需的“路由”資訊和排程過程的控制資訊,如下:

  • 目標機器:命令執行的目標伺服器列表,可以是IP,也可以是Hostname。

  • 併發程度:分組併發執行時每組的機器數量,用於控制分組執行,避免系統升級時所有伺服器同時升級造成業務中斷。

  • 暫停節點:指定執行到第幾臺伺服器時暫停執行,方便先操作幾臺伺服器並確認沒問題後再繼續執行,若有問題也可將問題控制在小範圍內。

執行資訊

執行資訊是指命令到達目標機器後開始執行時所必需的資訊,如下:

  • 認證資訊:標示執行者是誰的資訊,用來確認執行者的合法性,如不合法則拒絕執行。

  • 鑑權資訊:標示執行者所持有的許可權,如果許可權不夠也要拒絕執行。

  • 命令資訊:真正要在目標機執行的命令,也是資料模型這個包裝盒中最有價值的資訊。

除去控制資訊和執行資訊這兩個關鍵資訊外,還有一些輔助資訊如任務型別、任務建立/結束時間、任務超時時間等也是資料模型實際應用中的必要資訊,但並非關鍵,不再詳述。

四級排程模型

設計考量

在排程模型設計上,考慮到伺服器的地域分佈特點、任務排程與業務的強相關性、單機環境的複雜性以及傳輸過程的穩定性要求,我們將傳輸模型分為四層,自頂向下分別是統一接入層、分級排程層、機房匯聚層、代理執行層,分別負責全域性業務接入、按業務等級的分級排程、機房內伺服器的任務管理、單機層面的任務執行。同時為保障可用性,每一層均要保證足夠的冗餘度(通過無狀態叢集/多機熱備實現)與資料容災性(通過在每層設定快取與持久層實現)。 

各層介紹

  • 統一接入層:統一接入層的目的之一是為使用者提供一致的接入體驗,要達到這個目的有很多種方案,目前在CCS系統中,是通過VIP的方式實現。統一接入層的目的之二是通過Quota與Block對使用者流量進行控制,在實現使用者分賬的同時,避免突發流量將CCS系統後端沖垮。 

  • 分級排程層:分級排程層是任務排程的核心層,起到承上啟下的作用,在通訊上各節點與機房執行層建立邏輯上的Full-Mesh連線,如圖1所示,使每一個節點都有能力將命令送達百度內部的每一臺伺服器。這裡還要注意分級排程層中的分級概念,分級通過區分不同業務的重要程度,獨佔或混用此層的某個排程節點,而通過各節點之間互相隔離,可做到重要業務間互不干擾。通過設立分級排程層,在保證全網排程能力的同時,可以有效區分不同等級的業務,使業務間相互隔離,互不干擾。

640?wx_fmt=png

圖1  分級排程層與機房匯聚層的Full-Mesh連線

  • 機房匯聚層:在網路基礎設施中,有網路匯聚層的概念,起到本地流量匯聚的作用。機房匯聚層與之類似,負責本機房所有機器的狀態看護、命令下發、結果收集。機房匯聚層通過心跳訊息(由各伺服器上的執行代理定時上報)與下層進行通訊,心跳訊息有兩方面的作用,一是保活,二是命令批量下發與結果回收,業務資訊藉助週期性的心跳訊息搭車傳遞,既減少了訊息量,又避免了複雜的實現邏輯。通過建立機房匯聚層,將一個機房內的機器統一管理,避免了內部大量的心跳訊息傳播到其他機房,在保障通訊可靠性的同時還可減少公網頻寬佔用。

640?wx_fmt=png

圖2  機房匯聚層通過心跳與執行代理層通訊

  • 執行代理層:這裡是命令傳輸的終點,也是命令執行的起點,命令資訊通過部署在伺服器上的執行客戶端(以下簡稱CCS-Agent)與機房匯聚之間的一次次心跳被拉取到目標機器,在通訊層面上來說,命令資訊到這裡就結束了,但執行代理的功能不止於此,相關內容在下一節中詳細介紹。

三級代理執行

設計考量

在單機執行方案的設計上,最重要的問題就是執行端的穩定性,萬分之一發生率的問題,部署在幾十萬臺伺服器上後也會對業務造成嚴重影響。為了實現這樣的超穩態,我們設計瞭如圖3所示的單機執行架構,將最重要的命令執行邏輯從CCS-Agent中分離出來,組成獨立的通用執行層,在CCS-Agent中只保留認證、鑑權、備份、命令組裝這些非執行邏輯。同時為了保證通用執行層各使用者程序間的異常隔離,我們又將執行層分為執行代理程序執行端程序使用者程序三部分,每一個執行端程序與一個使用者程序對應,負責使用者程序的啟停控制與結果收集。 

640?wx_fmt=png

圖3  執行代理層 

詳細介紹

  • CCS-Agent:在執行層面,如前所述,主要負責使用者認證/使用者鑑權/資料備份/命令組裝等命令執行前的準備工作,在前文中有讀者對認證與鑑權提出疑問,這兩個功能也是CCS-Agent最主要的功能,這裡著重講一下。CCS系統有著嚴格的認證/鑑權機制,畢竟線上上伺服器執行命令是一項高危操作。在CCS系統中,使用者的許可權控制不是基於Linux系統的賬號系統,而是基於身份與角色,如zhangsan想要在機器A上執行一條命令,當命令下發到目標機器時,CCS-Agent就會首先對zhangsan這個使用者進行身份認證,確認身份的合法性,如身份合法則還要對此身份所屬的角色(如RD、QA、OP等,RD與QA具有線上系統的檢視許可權,OP具有變更許可權)進行驗證,只有身份合法,角色適當,才可以執行相應的命令。

  • 通用執行層:如前所述,通用執行層分為執行代理程序、執行端程序和使用者程序,除了可以隔離使用者程序異常,帶來穩定性的提升外,還有一個好處——無損升級。當執行代理需要升級時,可以將執行代理程序直接停止,由於此時已經執行的任務由執行端程序控制,結果可以正常回傳,不受影響,已經下發到執行代理還沒來得及執行的任務,在執行代理重新啟動後CCS-Agent會重新下發,也不會受影響。當執行端需要升級時則更簡單,可以直接升級執行端,升級完成以後,舊的執行端會繼續執行到結束,新的任務則會啟動新的執行端。 

異常處理

在系統執行過程中,免不了會發生各種問題,此處我們將設計與實踐中遇到的一些問題以及相應解決方案拿出來與大家一起探討。 

容量不足

自CCS系統上線以來,由容量問題引起的系統異常是最多的,當前的CCS系統特性有很多都是以前的經驗與教訓的總結,最突出的就是統一接入層的加入和分級排程理念的引入。

統一接入層除了給使用者提供一致的體驗外,更重要的一層意義是統一分級Quota與Block,通過設定分級流量配額和閾值,可以給不同使用者不同的訪問配額,在必要時還可以暫停某個使用者的任務下發,避免CCS系統後端因突發流量被拖垮。

如果說統一接入層的加入消除了突發任務的影響,那麼分級排程理念的引入則保障了重要任務不受影響。未引入分級排程之前,不同重要等級的任務混合在一起排程,曾經發生過因某一任務資料結構異常引起整個排程節點掛死的慘案。在這之後,通過對排程節點分級,對任務分級並將任務從統一接入層分級導流的方式,解決了重要任務得不到保障的問題。

網路抖動

網路抖動對CCS系統最直接的影響就是丟訊息。在任務排程過程中,單純的Client端拉取執行進度訊息與Server端主動推送執行進度訊息都有各自的弊端,前者可靠性高但時延不好控制,後者時延低但穩定性不足。為了保障CCS系統的高可用性,在通訊模型的層間採用推拉結合的方式,Client端拉取資訊時通過降低拉取頻率降低效能消耗,此時的時延上升由Server端主動推送來彌補。

單機執行異常

在統一執行代理沒有誕生的史前時代,命令單機執行過程中我們遇到過數不清的異常,典型的三方軟體Bug型(如Python Bug導致的程式hung住),資源耗盡型(作業系統PID耗盡導致的新命令無法執行),作業系統Bug型(如核心Bug導致的伺服器突然重啟),不可抗力型(如電力故障導致的批量伺服器斷電等情況)等。

為了保證異常不丟任務、異常快速恢復,我們在設計中主要遵循了以下兩點:

  • 備份優先:執行端收到任務的第一步不是考慮如何執行,而是考慮如何備份,即使後續執行端出現異常,也可以用備份資訊重新執行。

  • 單執行緒優先:單執行緒優先主要是為了使執行端的邏輯儘量簡化,避免複雜的多執行緒操作,畢竟越簡單越容易保證穩定,這也是執行端使用epoll執行代理程序 多執行端程序模式的主要原因。

遵循以上原則設計和實現的統一執行層,在百度內部的所有伺服器上部署,在長時間的執行中體現出了極高的穩定性。 

總結

通過構建CCS系統,我們解決了命令在大量伺服器上規模執行的問題,目前已在百度內部廣泛使用。但回顧從設計到上線執行至今的使用者反饋及故障處理,還有很多不完美的地方,如命令傳輸的時效性現在只達到了秒級,目前我們正在嘗試優化,多機熱備方案是否必要,我們也在著手分析,希望一段時間以後,我們可以拿出更優的方案與大家分享。

相關文章

今天我們來聊一個很基礎的話題:如何執行一條命令

640?wx_fmt=jpeg

640?wx_fmt=png

↓↓↓ 點選”閱讀原文” 【瞭解更多精彩內容】