為了應對大規模數據中心的網絡配置自動下發、運維效率提升、混合云網絡實時打通等需求，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、配置模式的差異。我們需要將這兩層抽象出來處理，經過測試和抽象，我們設計了業務模型的網絡配置下發系統：

• 第一步：構建原子命令類。由廠商，設備型號，型號版本，版本補丁構成一個原子命令的類，該類原子命令為一個錄入模板。
• 第二步：原子命令錄入。先錄入功能，再錄入功能對應的原始設備命令。
• 第三步：創建模板。將一個或者多個原子命令拖拽構建成能對應業務需求的模板。
• 第四步：創建API。為模板建立對應的KEY值，使其能夠為靈活的以API的方式被業務調用。

以一個具體的API創建過程為例，首先錄入設備的軟硬件版本，將軟件和硬件組合為一個單位，按照原子命令規范抽象出一層GROUP組，每一個GROUP為一個原子命令錄入標準，接下來按照命令功能為單位關聯一條或者多條原子命令。

具體構成關系圖如下:

圖3：API-場景-模板-命令功能對應表

場景中涉及到的命令功能創建完成后，通過前端編排創建模板，并結合實際屬性自動生成場，由此K-V的API模型基本就落成了。但是此時的創建只能關聯一個具體的設備類型的場景，如果其它場景有其它設備，API就無法生效了。因此還需要將多個關聯了GROUP組的場景加入大場景組中以大API的方式暴露出去，至此該API就能兼容多廠家的配置命令了。

設計與優化實踐

考慮到現網的特殊性，需要編排器具備較高的準確性、穩定性和安全性。為滿足以上特性，整個系統在架構設計、代碼開發過程中也做了系列調優實踐。

1. 基于Kafka的命令執行隊列設計

編排器需要面向公司所有在用機房按照一定的業務應用場景(以下簡稱場景)進行交換機配置命令的下發。以IDC機房作為空間維度，配置命令的執行先后順序作為時間維度，每個場景的執行必須做好時序控制，兼顧空間和時間維度。

為了保障配置指令的準確執行到位，我們采用了基于Kafka的命令執行隊列設計，Kafka消息隊列的主題(Topic)分類特性和消息隊列生產消費特性可以很好的兼顧指令下發隊列模塊對時序控制的需求。主題分類特性可用于處理IDC機房的空間維度，消息隊列生產消費特性則對應指令執行的時間維度。

在實際應用過程中，通過對業務場景進行解析，將交換機配置指令按照IDC機房生產至對應的Kafka主題，同一個IDC機房的配置指令將以交換機為單位，按照執行的先后順序生產至對應的主題。

通過利用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與操作者一一對應，責任到人。

通過權限認證，可以規范了使用者的操作習慣，強化使用者的安全意識，最終提高整個系統的安全性。

4. 指令下發實時反饋

傳統人工配置模式下，每一位網絡運維工程師必須要登錄到對應的交換機才能進行配置指令下發，同時觀察交換機回顯信息進行指令執行結果確認。為了重現這一過程并提供更友好的信息提示效果，系統集成了指令執行結果實時展示功能，并提供執行結果詳細信息查詢，供網絡運維工程師參考決策。

具體實現方式為，編排器前端界面在業務場景執行過程中，系統提供兩種方式的執行結果信息展示：

1. 執行狀態：將每一條指令的執行狀態分為下發成功、下發失敗、即將回滾、回滾成功、回滾失敗以及登錄失敗6種，并在業務場景下發過程中通過不同邊框顏色進行實時展示。

2. 指令執行回顯信息：大部分指令執行之后交換機都會有回顯信息提示，系統自動抓取交換機回顯信息并反饋到前端，為操作者提供參考。

這種圖形顏色及回顯信息展示，可以實時反饋配置指令的執行效果，為網絡運維工程師提供參考，在提高自動化水平的同時提升操作反饋體驗。

5. 原子命令庫的建立

公司在用交換機主要有HW、H3C和RUIJIE三大品牌，各大品牌交換機之間配置指令存在較大差別。同時，每個品牌下面的交換機又可分為若干型號，不同型號之間部分指令也存在一定的區別。

為了兼容公司在用的所有交換機，需要對所有交換機型號進行統一管理，同時根據不同交換機型號進行配置指令錄入，做好分類管理。基于以上背景及需求，系統搭建了原子命令庫，原子命令庫包括以下幾個子庫：

• a. 交換機設備庫：以廠商、型號、版本、補丁為分類字段，將公司在用的所有交換機進行歸類整理;
• b. 交換機設備組庫：在交換機設備庫的基礎上進行分組，將配置指令相同的設備劃分到同一組;
• c. 原子命令庫：基于交換機設備組進行原子命令錄入，同時從原子命令功能維度進行分類;
• d. 原子命令功能模板庫：用于錄入交換機命令的功能模板;
• e. 原子命令參數模板庫：用于錄入交換機命令的各類參數模板。

通過建立原子命令庫，可以將公司所有在用交換機及其適用的配置指令進行了統一分類管理。而交換機組的設計，可以將配置指令相同的交換機歸入同一組，同組設備共享原子命令，極大減少了錄入原子命令的工作量。此外，通過建立原子命令功能、參數模板庫，可以將原子命令錄入方式標準化，為業務場景編排打好基礎。

6. API開放和二次開發

系統提供了原子粒度的交換機操作API，不僅支持現有的網絡運維操作，也可作為外部調用組件支持相關的二次系統開發。同時，通過提供統一且精細分類的API入口，可以實現現網交換機操作的集中管理，提高現網安全性。目前已為盤古系統(UCloud服務器自動交付系統)、UXR項目提供底層調用API，支撐系統開發及相關業務開展。

最后

經過聯調測試，我們已將該系統應用到多個業務場景中，且都有不錯的表現。通過網絡自動編排系統，我們將數據中心建設業務中，上萬規模級別IDC的網絡建設周期從原先的天縮短為小時。此外，上線成功率也從原先的80%提高到99%。在混合云業務打通中，虛擬網絡的業務邏輯也能通過用戶的控制臺操作實時打通(物理接線除外)。