Facebook藉助零接觸配置框架擴展骨幹網！

作者：Joe Hrbek、BrandonBennett、 DavidSwafford和James Quinn

來源：Facebook 開源博客

十多年來，Facebook一直在擴大全球性廣域骨幹網路和邊緣網路入網點（POP）。今天，這些網路橫跨多個大陸，包括城域網、長途光纖網路以及兩個並行的IP骨幹網。所有這些網路在迅速擴大規模，不僅支持迅速增加的發往互聯網的出站流量，還支持內部更龐大的機器到機器流量需求。

Facebook以前的網路配置系統不足以應對構建這些網路的規模和複雜性，於是用零接觸配置（Zero Touch Provisioning）自行開發了全面靈活的工作流程系統。這個新框架已經幫助Facebook的工程師加快行動步伐，更創造性地解決問題，並採用一種高度迭代的方法來構建Facebook的網路和網路部署工具。

快速增長帶來的挑戰

構建Facebook這等速度和規模的骨幹網給Facebook的網路工程師帶來了前所未有的獨特的技術挑戰。地域分散的IP和光纖骨幹網路本來就具有異構特性，不容易適合常常用於同構數據中心網路中的傳統的網路構建自動化方法。

多年來，Facebook的網路工程師應對骨幹網增長方面的這些挑戰採取的方法與同行並沒有什麼不同。雖然開發了工具來支持網路工程師的工作，但總體方法還是編寫文檔（MOP即程序法），聘請更多的工程師，以便在步伐迅速加快的部署工作中遵循這些日益詳細的MOP。這些工具只是長篇MOP中的對應行，供工程師手動執行。

光自動化還不夠，隨後出現了新方法：VendingMachine

Facebook快速增長的骨幹網流量需求很難跟上步伐，光靠手動方法無濟於事。要求更迅速地構建網路導致錯誤增加，進而影響了服務。需要改用一種更加以軟體為中心的方法來構建骨幹網，並使MOP實現自動化。

起初，骨幹網團隊嘗試使用一套十多年前的老式Facebook系統（通過控制台/串列連接進行交互），以構建數據中心伺服器和架頂式交換機。這種基於控制台的方法在當時是最先進的，不過通過控制台進行配置並不總是很快速或穩定。對於遍布全球的骨幹網來說，這種方法更脆弱不堪。

這個配置系統一開始規模小、針對性強，但久而久之，逐漸添加了許多新的網路使用場景、平台和角色，都在if/else條件的單一代碼路徑當中。頂峰時期，這個單一配置系統用於構建幾乎所有的Facebook網路設備，從架頂式交換機一直到複雜的骨幹網MPLS和BGP對等路由器。隨著代碼越來越複雜，排查故障、壞掉後解決問題或者克服新挑戰變得更難了。

最終，這些挑戰促使Facebook的網路工程師為網路部署工作流程開發出了一種全新的方法。稱之為Vending Machine（自動售貨機），這個名稱源自售賣糖果和軟飲料的機器。拿Facebook的Vending Machine來說，輸入是設備角色、位置和平台，輸出是剛配置的網路設備，準備提供生產流量。

使用Python代理的ZTP

這個新型Vending Machine系統面臨的一個特別重大的挑戰是，為自動化設備配置本身尋找一種方法來替代不可靠的控制台。隨著數據中心交換機供應商開始支持零接觸配置（ZTP）功能，使用DHCP用於網路平台，我們開始與骨幹網IP路由器和設備供應商合作，以支持類似的功能。這種方法讓我們得以重複使用當初為自己的伺服器構建的DHCP自動配置基礎設施，並通過可靠得多的乙太網管理連接來配置網路設備。

雖然基本的ZTP方法只是針對網路設備進行配置和升級軟體，我們採用了一種更可靠、更靈活的獨特方法：下載由網路設備執行的一段特殊的Python代碼，作為設備端代理。一旦ZTP進程啟動了網路設備端的Facebook Python代理，代理就執行這幾項功能：

1. 它從我們的Vending Machine伺服器下載指令包，這些指令可能針對該特定的平台、角色和位置，甚至針對特定的設備。

2. 它遵循這些指令來：

1）執行任何指定的初始命令；

2）下載相關文件，包括配置、固件、補丁或任何其他定製包（比如Facebook的Open/R軟體）；以及

3）執行進一步的操作（載入配置、升級代碼和重啟設備等）。

3. 它還通過一條通向HTTP伺服器的REST通信通道將日誌發回VendingMachine伺服器，用於狀態、日誌記錄和調試。

4. 最後，代理向Vending Machine報告構建任務完成的信息，然後自行終止。

所有這些功能都在網路設備上用Facebook網路工程師編寫的Python代碼來執行，這意味著我們可以隨時擴展和調整該代理代碼，另外還能處理我們在網路供應商軟體或我們自己的工作流程中發現的任何錯誤。

Vending Machine接下來的「步驟」

載入網路設備的軟體和配置很重要，但它只允許我們替換MOP的一小部分。許多手動步驟仍然是自動化的。為了淘汰MOP，Vending Machine需要處理每一行。

我們構建Vending Machine的初衷主要是作為一種靈活的工作流程框架，那樣工程師可以並行開發，以迭代方式使構建網路設備涉及的每一個非物理步驟實現自動化。我們開發了Vending Machine，將所有程序拆分成可以用任何編程語言編寫的小型獨立的代碼片段（稱為系統中的步驟即step）。

這些步驟旨在成為僅僅關注一項特定任務的簡單程序。使用這種較簡單的方法，工程師可以在無需更深入地了解整個Vending Machine系統的情況下編寫和調試步驟。這還意味著工程師可以獨立編寫和部署步驟，無需重新部署整個系統，不會對系統中運行的其他步驟或工作流程帶來任何影響，負責編寫和調試系統不同部分的工程師之間基本上不需要協調。

Vending Machine將需要跨一組分散式伺服器執行的步驟排入隊列。每個步驟運行時，它：

讀取用JSON編碼的STDIN（標準輸入），包括識別設備的數據（主機名和IP地址等）以及一般的作業元數據。

執行用針對特定步驟的代碼實現的工作。

將採用標準格式的日誌輸出到STDERR（標準錯誤），與父作業一起存儲起來。

返回表示步驟成功（0）或失敗（任何非零退出代碼）的Unix退出代碼。該行為還發現步驟失敗時出現的任何未處理的異常。

一個步驟失敗時，Vending Machine自動將該步驟排入隊列以便再次執行，從而應對配置過程中出現的任何瞬間故障。

將步驟作為獨立的二進位代碼來構成很簡單，因而網路工程師極容易開發和部署新步驟，也極容易在改進特定網路部署工作流程的同時迭代處理代碼。它還使得整個Vending Machine極其靈活。可迅速改動以支持新的使用場景和功能，無需重寫現有步驟。

我們的網路工程師穩步開發越來越多的自動化Vending Machine步驟，取代過去網路部署中的手動MOP步驟：

對等互聯通知

更新庫存和管理系統

實現運維監控

等待設備重啟

執行地址分配

生成配置

重新生成和推送全局iBGP和MPLS網狀網

執行一系列廣泛的鏈路級、設備級和拓撲級的健康檢查和驗證

調用支持生產流量的耗盡/未耗盡（draining/undraining）的現有工具。

Vending Machine使我們的網路工程師能夠在VendingMachine裡面將這些自動化步驟連起來，連成逐漸更全面的生產網路部署工作流程。這些工作流程定義了步驟運行的順序，以及哪些步驟應與另外哪些步驟並行運行以縮短構建過程。步驟可以在多個工作流程之間共享和重用，也可以隔離到某個特定的設備角色或平台。

這些步驟和工作流程逐漸取代了我們的龐大MOP中的每一行和每個部分，直到MOP只顯示一行：「Run Vending Machine」。或者更確切地說是，vmconfigure 。同樣這個命令可用於我們在Facebook網路中支持的每個網路設備、角色和平台。網路構建的複雜性和變化性隱藏起來，由Vending Machine系統以及在裡面構建的工作流程和步驟來處理。

Vending Machine的下一站是什麼？

Vending Machine讓Facebook大大增強了信心，對於骨幹網部署以及那些部署背後自動化的可靠性有了把握。這種信心已經使我們的工程師得以開始力求實現更宏偉的目標：

協調VendingMachine設備作業組，以構建或重構更龐大的網路拓撲。

使我們重構Express骨幹網中的整個全局平面完全實現自動化。

使我們跨全球骨幹網順暢、無縫地升級軟體版本實現自動化。

使我們以一種健康、系統化的方式持續重構所有網路使實現自動化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！