UCloud大規模資料中心網路管理系統建設之路
為了應對大規模資料中心的網路配置自動下發、運維效率提升、混合雲網絡實時打通等需求，UCloud團隊研發上線了物理網路編排器（以下簡稱編排器）。它是網路運維自動化建設的基礎應用系統，為網路運維人員提供一個簡單易用的網路裝置配置工具，使之從繁瑣的交換機命令編寫中獲得解放，並具備足夠的準確性、穩定性和安全性。
基於此係統，資料中心建設時上萬規模級別IDC的網路建設週期由原先的2-3天縮短至2-3小時，且上線成功率也從此前的80%提高到99%。上線至今，該系統已成功服務於3000餘臺交換機，維護了100條以上的運營商專線。其所承載的網路接入吞吐達200G，DCI（資料中心內部互聯）吞吐接近2T左右，並能支援混合雲業務在使用者控制檯的網路實時打通等（物理接線除外）。
難點分析
傳統網路部署主要通過人工配置的方式實現。當網路達到一定規模時，採用人力堆砌的方式效率低下不說，大量的配置命令，也容易導致較高的上線錯誤率。結合公司目前的情況，在分析業界開源的配置下發方案後，我們決定採用基於Python with NAPALM (Python module)方案自建一套業務配置下發系統，這套系統的內部Codename為XUANWU（中文玄武）。
NAPALM模組底層的配置下發系統（比如Ansible、Paramiko、Salt）雖然是通用的，但目前只有主流的廠家才支援對應的庫，一些二線品牌的廠家支援的並不完善，需要自研。寄希望廠家提供豐富和標準的配置下發API是不太切實的奢望，我們要結合業務開發一套適用於UCloud的配置下發系統。
通過分析，我們發現，如果要開發一套基於業務的網路編排器，必須要解決以下障礙：
1. 同一個底層，命令不同的裝置廠家提供的配置命令不一樣。如建立一條靜態路由，同樣一個需求，銳捷的命令是“ip route 0.0.0.0 0.0.0.0 1.1.1.1”，而華為的命令是“ip route-static 0.0.0.0 0.0.0.0 1.1.1.1”；
2. 同一款裝置型號，由於軟體版本不同，實現同一個功能的命令組合不同。如華為的CE6851-48S6Q-HI裝置，同樣實現tunnel建立這功能，當版本<=V1R2時，tunnel口需要繫結一個service_type為tunnel的聚合口來啟用，而之後的版本，就不需要綁定了；
3. 不同廠家裝置，實現同一個需求的配置模式不一樣。如將交換機物理口劃入某聚合口配置需求下，華為只需要將物理口繫結抽象出來的聚合口即可繼承聚合口下所有屬性，而H3C則要在物理口下將聚合口的屬性配置再配置一遍。
4. ……
這些形形色色、大大小小的人能解決的問題卻讓自動化舉步維艱，要想實現網路配置自動化，首先必須將這些問題總結抽象成具體的場景，然後通過分級歸類來規避差異。
編排器架構及業務模型搭建
經過內部多次的討論和歸納，我們發現真正業務呼叫網路的，是一個一個具體的場景，這些場景能夠實實在在滿足具體需求，如一個業務的需求是打通託管到公有云的路由，那麼實際上網路實現的就是靜態路由的下發，靜態路由下發就成了一個配置場景。
這裡，需要注意的是場景是不關心裝置廠家的，因此就會衍生出兩個問題：1、配置命令的差異；2、配置模式的差異。我們需要將這兩層抽象出來處理，經過測試和抽象，我們設計了業務模型的網路配置下發系統：
圖1：UCloud基於場景的網路配置下發系統架構圖
第一步：構建原子命令類。由廠商，裝置型號，型號版本，版本補丁構成一個原子命令的類，該類原子命令為一個錄入模板。
第二步：原子命令錄入。先錄入功能，再錄入功能對應的原始裝置命令。
第三步：建立模板。將一個或者多個原子命令拖拽構建成能對應業務需求的模板。
第四步：建立API。為模板建立對應的KEY值，使其能夠為靈活的以API的方式被業務呼叫。
以一個具體的API建立過程為例，首先錄入裝置的軟硬體版本，將軟體和硬體組合為一個單位，按照原子命令規範抽象出一層GROUP組，每一個GROUP為一個原子命令錄入標準，接下來按照命令功能為單位關聯一條或者多條原子命令。
具體構成關係圖如下:
圖2：命令功能-原子命令-版本group-軟硬體裝置對應表
圖3：API-場景-模板-命令功能對應表
場景中涉及到的命令功能建立完成後，通過前端編排建立模板，並結合實際屬性自動生成場，由此K-V的API模型基本就落成了。但是此時的建立只能關聯一個具體的裝置型別的場景，如果其它場景有其它裝置，API就無法生效了。因此還需要將多個關聯了GROUP組的場景加入大場景組中以大API的方式暴露出去，至此該API就能相容多廠家的配置命令了。
設計與優化實踐
考慮到現網的特殊性，需要編排器具備較高的準確性、穩定性和安全性。為滿足以上特性，整個系統在架構設計、程式碼開發過程中也做了系列調優實踐。
1. 基於Kafka的命令執行佇列設計
編排器需要面向公司所有在用機房按照一定的業務應用場景（以下簡稱場景）進行交換機配置命令的下發。以IDC機房作為空間維度，配置命令的執行先後順序作為時間維度，每個場景的執行必須做好時序控制，兼顧空間和時間維度。
為了保障配置指令的準確執行到位，我們採用了基於Kafka的命令執行佇列設計，Kafka訊息佇列的主題（Topic）分類特性和訊息佇列生產消費特性可以很好的兼顧指令下發佇列模組對時序控制的需求。主題分類特性可用於處理IDC機房的空間維度，訊息佇列生產消費特性則對應指令執行的時間維度。
在實際應用過程中，通過對業務場景進行解析，將交換機配置指令按照IDC機房生產至對應的Kafka主題，同一個IDC機房的配置指令將以交換機為單位，按照執行的先後順序生產至對應的主題。
圖4：基於Kafka的命令執行佇列設計
通過利用Kafka的兩大特性，結合系統的業務場景解析邏輯，我們最終實現了交換機配置指令的時空維度控制，確保指令的準確送達。系統上線後執行至今，未出現過配置指令誤發、錯發的情況。
2. 叢集、主備與主主設計的應用
作為網路運維自動化建設的基礎系統，後期將面向更多部門開放部分或全部功能，因此，編排器服務的穩定性尤為重要。系統考慮了在使用叢集化等高可用技術上的各種環節，制定了以下穩定性提升設計方案：
1. Zookeeper叢集（基本操作）；
2. Kafka叢集（基本操作）；
3. Kafka消費者叢集：在每個IDC機房部署Kafka消費者叢集，確保配置指令訊息的穩定消費並執行；
4. MySQL資料庫1主2備：資料庫讀寫分離，主庫只接受寫操作，從庫只接受讀操作，降低主庫負載，提高資料庫服務穩定性；
5. Webserver主主：提供兩臺web後臺伺服器，通過Nginx代理實現負載均衡，結合資料庫的雙備設計，實現API請求及資料庫讀操作的均衡分配。
通過叢集化、主備、主主設計，編排器提供的Web服務變得更加穩定，配置指令訊息佇列也更加可靠。系統上線後執行至今，未出現過因web伺服器或訊息佇列宕機導致的服務不可用情況。
3. 許可權設計
系統涉及現網交換機的變更操作，每個業務場景的執行均會對現網產生影響，適當的許可權管理也非常重要。系統從2個層面對操作者許可權進行限制，並啟用後端token認證：
1. API許可權：涉及資料庫的增、刪、改、查，以及業務場景的下發（回滾）操作，通過1對1的API許可權劃分進行管理；
2. 選單許可權：涉及選單層級的UI介面操作，對前端操作頁面的選單項進行許可權劃分和管理；
3. Token認證：後端呼叫API時將進行Token認證，Token與操作者一一對應，責任到人。
圖5：token認證流程
通過許可權認證，可以規範了使用者的操作習慣，強化使用者的安全意識，最終提高整個系統的安全性。
4. 指令下發實時反饋
傳統人工配置模式下，每一位網路運維工程師必須要登入到對應的交換機才能進行配置指令下發，同時觀察交換機回顯資訊進行指令執行結果確認。為了重現這一過程並提供更友好的資訊提示效果，系統集成了指令執行結果實時展示功能，並提供執行結果詳細資訊查詢，供網路運維工程師參考決策。
具體實現方式為，編排器前端介面在業務場景執行過程中，系統提供兩種方式的執行結果資訊展示：
1. 執行狀態：將每一條指令的執行狀態分為下發成功、下發失敗、即將回滾、回滾成功、回滾失敗以及登入失敗6種，並在業務場景下發過程中通過不同邊框顏色進行實時展示。
圖6：指令執行狀態說明
圖7：指令執行狀態顯示介面
2. 指令執行回顯資訊：大部分指令執行之後交換機都會有回顯資訊提示，系統自動抓取交換機回顯資訊並反饋到前端，為操作者提供參考。
圖8：指令執行回顯資訊展示
這種圖形顏色及回顯資訊展示，可以實時反饋配置指令的執行效果，為網路運維工程師提供參考，在提高自動化水平的同時提升操作反饋體驗。
5. 原子命令庫的建立
公司在用交換機主要有HW、H3C和RUIJIE三大品牌，各大品牌交換機之間配置指令存在較大差別。同時，每個品牌下面的交換機又可分為若干型號，不同型號之間部分指令也存在一定的區別。
為了相容公司在用的所有交換機，需要對所有交換機型號進行統一管理，同時根據不同交換機型號進行配置指令錄入，做好分類管理。基於以上背景及需求，系統搭建了原子命令庫，原子命令庫包括以下幾個子庫：
a. 交換機裝置庫：以廠商、型號、版本、補丁為分類欄位，將公司在用的所有交換機進行歸類整理；
b. 交換機裝置組庫：在交換機裝置庫的基礎上進行分組，將配置指令相同的裝置劃分到同一組；
c. 原子命令庫：基於交換機裝置組進行原子命令錄入，同時從原子命令功能維度進行分類；
d. 原子命令功能模板庫：用於錄入交換機命令的功能模板；
e. 原子命令引數模板庫：用於錄入交換機命令的各類引數模板。
通過建立原子命令庫，可以將公司所有在用交換機及其適用的配置指令進行了統一分類管理。而交換機組的設計，可以將配置指令相同的交換機歸入同一組，同組裝置共享原子命令，極大減少了錄入原子命令的工作量。此外，通過建立原子命令功能、引數模板庫，可以將原子命令錄入方式標準化，為業務場景編排打好基礎。
6. API開放和二次開發
系統提供了原子粒度的交換機操作API，不僅支援現有的網路運維操作，也可作為外部呼叫元件支援相關的二次系統開發。同時，通過提供統一且精細分類的API入口，可以實現現網交換機操作的集中管理，提高現網安全性。目前已為盤古系統（UCloud伺服器自動交付系統）、UXR專案提供底層呼叫API，支撐系統開發及相關業務開展。
最後
經過聯調測試，我們已將該系統應用到多個業務場景中，且都有不錯的表現。通過網路自動編排系統，我們將資料中心建設業務中，上萬規模級別IDC的網路建設週期從原先的天縮短為小時。此外，上線成功率也從原先的80%提高到99%。在混合雲業務打通中，虛擬網路的業務邏輯也能通過使用者的控制檯操作實時打通（物理接線除外）。
— END —