為了應對大規(guī)模數(shù)據(jù)中心的網(wǎng)絡(luò)配置自動下發(fā)、運維效率提升、混合云網(wǎng)絡(luò)實時打通等需求，UCloud團隊研發(fā)上線了物理網(wǎng)絡(luò)編排器(以下簡稱編排器)。它是網(wǎng)絡(luò)運維自動化建設(shè)的基礎(chǔ)應用系統(tǒng)，為網(wǎng)絡(luò)運維人員提供一個簡單易用的網(wǎng)絡(luò)設(shè)備配置工具，使之從繁瑣的交換機命令編寫中獲得解放，并具備足夠的準確性、穩(wěn)定性和安全性。

基于此系統(tǒng)，數(shù)據(jù)中心建設(shè)時上萬規(guī)模級別IDC的網(wǎng)絡(luò)建設(shè)周期由原先的2-3天縮短至2-3小時，且上線成功率也從此前的80%提高到99%。上線至今，該系統(tǒng)已成功服務于3000余臺交換機，維護了100條以上的運營商專線。其所承載的網(wǎng)絡(luò)接入吞吐達200G，DCI(數(shù)據(jù)中心內(nèi)部互聯(lián))吞吐接近2T左右，并能支持混合云業(yè)務在用戶控制臺的網(wǎng)絡(luò)實時打通等(物理接線除外)。

難點分析

傳統(tǒng)網(wǎng)絡(luò)部署主要通過人工配置的方式實現(xiàn)。當網(wǎng)絡(luò)達到一定規(guī)模時，采用人力堆砌的方式效率低下不說，大量的配置命令，也容易導致較高的上線錯誤率。結(jié)合公司目前的情況，在分析業(yè)界開源的配置下發(fā)方案后，我們決定采用基于Python with NAPALM (Python module)方案自建一套業(yè)務配置下發(fā)系統(tǒng)，這套系統(tǒng)的內(nèi)部Codename為XUANWU(中文玄武)。

NAPALM模塊底層的配置下發(fā)系統(tǒng)(比如Ansible、Paramiko、Salt)雖然是通用的，但目前只有主流的廠家才支持對應的庫，一些二線品牌的廠家支持的并不完善，需要自研。寄希望廠家提供豐富和標準的配置下發(fā)API是不太切實的奢望，我們要結(jié)合業(yè)務開發(fā)一套適用于UCloud的配置下發(fā)系統(tǒng)。

通過分析，我們發(fā)現(xiàn)，如果要開發(fā)一套基于業(yè)務的網(wǎng)絡(luò)編排器，必須要解決以下障礙：

1. 同一個底層，命令不同的設(shè)備廠家提供的配置命令不一樣。如創(chuàng)建一條靜態(tài)路由，同樣一個需求，銳捷的命令是“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. 同一款設(shè)備型號，由于軟件版本不同，實現(xiàn)同一個功能的命令組合不同。如華為的CE6851-48S6Q-HI設(shè)備，同樣實現(xiàn)tunnel創(chuàng)建這功能，當版本<=V1R2時，tunnel口需要綁定一個service_type為tunnel的聚合口來激活，而之后的版本，就不需要綁定了;

3. 不同廠家設(shè)備，實現(xiàn)同一個需求的配置模式不一樣。如將交換機物理口劃入某聚合口配置需求下，華為只需要將物理口綁定抽象出來的聚合口即可繼承聚合口下所有屬性，而H3C則要在物理口下將聚合口的屬性配置再配置一遍。

4. ……

這些形形色色、大大小小的人能解決的問題卻讓自動化舉步維艱，要想實現(xiàn)網(wǎng)絡(luò)配置自動化，首先必須將這些問題總結(jié)抽象成具體的場景，然后通過分級歸類來規(guī)避差異。

編排器架構(gòu)及業(yè)務模型搭建

經(jīng)過內(nèi)部多次的討論和歸納，我們發(fā)現(xiàn)真正業(yè)務調(diào)用網(wǎng)絡(luò)的，是一個一個具體的場景，這些場景能夠?qū)崒嵲谠跐M足具體需求，如一個業(yè)務的需求是打通托管到公有云的路由，那么實際上網(wǎng)絡(luò)實現(xiàn)的就是靜態(tài)路由的下發(fā)，靜態(tài)路由下發(fā)就成了一個配置場景。

這里，需要注意的是場景是不關(guān)心設(shè)備廠家的，因此就會衍生出兩個問題：1、配置命令的差異;2、配置模式的差異。我們需要將這兩層抽象出來處理，經(jīng)過測試和抽象，我們設(shè)計了業(yè)務模型的網(wǎng)絡(luò)配置下發(fā)系統(tǒng)：

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

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

具體構(gòu)成關(guān)系圖如下:

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

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

設(shè)計與優(yōu)化實踐

考慮到現(xiàn)網(wǎng)的特殊性，需要編排器具備較高的準確性、穩(wěn)定性和安全性。為滿足以上特性，整個系統(tǒng)在架構(gòu)設(shè)計、代碼開發(fā)過程中也做了系列調(diào)優(yōu)實踐。

1. 基于Kafka的命令執(zhí)行隊列設(shè)計

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

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

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

通過利用Kafka的兩大特性，結(jié)合系統(tǒng)的業(yè)務場景解析邏輯，我們最終實現(xiàn)了交換機配置指令的時空維度控制，確保指令的準確送達。系統(tǒng)上線后運行至今，未出現(xiàn)過配置指令誤發(fā)、錯發(fā)的情況。

2. 集群、主備與主主設(shè)計的應用

作為網(wǎng)絡(luò)運維自動化建設(shè)的基礎(chǔ)系統(tǒng)，后期將面向更多部門開放部分或全部功能，因此，編排器服務的穩(wěn)定性尤為重要。系統(tǒng)考慮了在使用集群化等高可用技術(shù)上的各種環(huán)節(jié)，制定了以下穩(wěn)定性提升設(shè)計方案：

1. Zookeeper集群(基本操作);

2. Kafka集群(基本操作);

3. Kafka消費者集群：在每個IDC機房部署Kafka消費者集群，確保配置指令消息的穩(wěn)定消費并執(zhí)行;

4. MySQL數(shù)據(jù)庫1主2備：數(shù)據(jù)庫讀寫分離，主庫只接受寫操作，從庫只接受讀操作，降低主庫負載，提高數(shù)據(jù)庫服務穩(wěn)定性;

5. Webserver主主：提供兩臺web后臺服務器，通過Nginx代理實現(xiàn)負載均衡，結(jié)合數(shù)據(jù)庫的雙備設(shè)計，實現(xiàn)API請求及數(shù)據(jù)庫讀操作的均衡分配。

通過集群化、主備、主主設(shè)計，編排器提供的Web服務變得更加穩(wěn)定，配置指令消息隊列也更加可靠。系統(tǒng)上線后運行至今，未出現(xiàn)過因web服務器或消息隊列宕機導致的服務不可用情況。

3. 權(quán)限設(shè)計

系統(tǒng)涉及現(xiàn)網(wǎng)交換機的變更操作，每個業(yè)務場景的執(zhí)行均會對現(xiàn)網(wǎng)產(chǎn)生影響，適當?shù)臋?quán)限管理也非常重要。系統(tǒng)從2個層面對操作者權(quán)限進行限制，并啟用后端token認證：

1. API權(quán)限：涉及數(shù)據(jù)庫的增、刪、改、查，以及業(yè)務場景的下發(fā)(回滾)操作，通過1對1的API權(quán)限劃分進行管理;

2. 菜單權(quán)限：涉及菜單層級的UI界面操作，對前端操作頁面的菜單項進行權(quán)限劃分和管理;

3. Token認證：后端調(diào)用API時將進行Token認證，Token與操作者一一對應，責任到人。

通過權(quán)限認證，可以規(guī)范了使用者的操作習慣，強化使用者的安全意識，最終提高整個系統(tǒng)的安全性。

4. 指令下發(fā)實時反饋

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

具體實現(xiàn)方式為，編排器前端界面在業(yè)務場景執(zhí)行過程中，系統(tǒng)提供兩種方式的執(zhí)行結(jié)果信息展示：

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

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

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

5. 原子命令庫的建立

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

為了兼容公司在用的所有交換機，需要對所有交換機型號進行統(tǒng)一管理，同時根據(jù)不同交換機型號進行配置指令錄入，做好分類管理?；谝陨媳尘凹靶枨?，系統(tǒng)搭建了原子命令庫，原子命令庫包括以下幾個子庫：

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

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

6. API開放和二次開發(fā)

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

最后

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