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

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

難點(diǎn)分析

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

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

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

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

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

4. ……

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

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

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

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

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

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

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

圖3：API-場(chǎng)景-模板-命令功能對(duì)應(yīng)表

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

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

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

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

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

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

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

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

2. 集群、主備與主主設(shè)計(jì)的應(yīng)用

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

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

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

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

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

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

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

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

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

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

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

3. Token認(rèn)證：后端調(diào)用API時(shí)將進(jìn)行Token認(rèn)證，Token與操作者一一對(duì)應(yīng)，責(zé)任到人。

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

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

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

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

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

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

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

5. 原子命令庫的建立

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

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

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

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

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

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

最后

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