摘要：如何設(shè)計一個可容納萬臺服務(wù)器的數(shù)據(jù)中心網(wǎng)絡(luò)?UCloud優(yōu)刻得設(shè)計了一款數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)系統(tǒng) —— Big Bang，實現(xiàn)低成本適配不同版本架構(gòu)迭代、不同規(guī)模機(jī)房的小時級快速部署目標(biāo)。目前，已經(jīng)支持烏蘭察布大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)開局，也為海內(nèi)外多個機(jī)房的快速、高質(zhì)量交付提供技術(shù)支持。
從零建設(shè)一個可容納萬臺服務(wù)器的數(shù)據(jù)中心網(wǎng)絡(luò)需要多久?
類比“要把大象裝冰箱，總共分幾步?”，從零開局一個數(shù)據(jù)中心，將網(wǎng)絡(luò)從建設(shè)到交付的過程更像“開荒”。傳統(tǒng)依賴工程師人工編寫繁瑣的網(wǎng)絡(luò)設(shè)備命令費時又費力，且交期與質(zhì)量均無法得到保障。
為此我們設(shè)計了一款數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)系統(tǒng) —— Big Bang，將數(shù)據(jù)中心網(wǎng)絡(luò)開局這一任務(wù)切分為“架構(gòu)規(guī)劃” - “資源分配” - “配置生成及下發(fā)”三個步驟。每一步之間耦合松散而內(nèi)部又高度內(nèi)聚，實現(xiàn)低成本適配不同版本架構(gòu)迭代、不同規(guī)模機(jī)房的小時級快速部署目標(biāo)。
Big Bang 上線后支持了自建的烏蘭察布大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)開局，至今已完成海內(nèi)外多個機(jī)房的快速、高質(zhì)量交付。
The Big Bang Theory : 宇宙是由一個致密熾熱的奇點于一次大爆炸后膨脹形成的。
1.上一代建設(shè)系統(tǒng)的不足
在 Big Bang 之前 UCloud優(yōu)刻得物理網(wǎng)絡(luò)團(tuán)隊已有一代數(shù)據(jù)中心建設(shè)系統(tǒng)，隨著業(yè)務(wù)和架構(gòu)的演進(jìn)，上一代系統(tǒng)的一些缺點逐漸暴露出來 :
>對多平面的 Fabric 數(shù)據(jù)中心網(wǎng)絡(luò)支持不夠靈活
>架構(gòu)規(guī)則描述不靈活，網(wǎng)絡(luò)設(shè)計版本迭代后需要再次投入大量研發(fā)人力適配，且存在需要研發(fā)理解網(wǎng)絡(luò)業(yè)務(wù)設(shè)計的強(qiáng)耦合問題
>原子命令庫方式組織的配置模板不直觀，人工難以預(yù)測其生成的配置，導(dǎo)致維護(hù)成本過高，且修改后無測試，容易出錯
>在建設(shè)海外機(jī)房時，由于網(wǎng)絡(luò)延遲過高，基于編排器的配置下發(fā)方式出現(xiàn)了失敗率快速攀升的問題
通過對上述挑戰(zhàn)和缺點的分析不難得出推論，我們需要這樣一款建設(shè)系統(tǒng)工具 :
>靈活適配多版本、多形態(tài)、多平面的數(shù)據(jù)中心網(wǎng)絡(luò)
>網(wǎng)絡(luò)架構(gòu)迭代不應(yīng)需研發(fā)同學(xué)介入
>可以直觀的修改配置模板，修改后可以自動化的低成本的進(jìn)行測試
>低網(wǎng)絡(luò)依賴，弱網(wǎng)條件下依然能好用
2．Big Bang 設(shè)計概要
2.1 人肉運維之痛
在談設(shè)計之前，我們先來談一下人工建設(shè)一個數(shù)據(jù)中心會遇到哪些挑戰(zhàn)?
考察一個簡單的兩級 CLOS 架構(gòu) : 4 個 Spine， 32 個 Leaf 共 36 臺設(shè)備構(gòu)成一個業(yè)務(wù)專區(qū)，這在 UCloud優(yōu)刻得數(shù)據(jù)中心中是很常見的 POD 規(guī)模。
建設(shè)這樣一個網(wǎng)絡(luò)，首先需要給出設(shè)備接線表交由現(xiàn)場的同學(xué)進(jìn)行布線。這張接線表要表達(dá) “spine01.p1 接 leaf01.p49， 使用 QSFP28 100G 線纜”這樣的信息。 對于這個 POD 便產(chǎn)生了 4 * 32 = 128 個互聯(lián)關(guān)系。
給出布線規(guī)則后，我們再來考慮 IP 分配的問題。
圖中每一條線均需要一對互聯(lián)地址，除此之外設(shè)備還需要分配管理地址、業(yè)務(wù)地址等。一個 POD 便需要 128 個互聯(lián)網(wǎng)段、32 個業(yè)務(wù)網(wǎng)段、幾十個管理地址。這些地址都需要工程師到 IP 管理系統(tǒng)中占用，并與設(shè)備 (互聯(lián)關(guān)系) 一一對應(yīng)。
可以看到，在 CLOS 架構(gòu)下進(jìn)行的互聯(lián)計算、資源分配工作非常繁復(fù)，并且數(shù)量會隨著網(wǎng)元數(shù)量、接口數(shù)量的增加而急劇增加。
除此之外，還有一些要求會使這些挑戰(zhàn)變得更加復(fù)雜：部分角色指定接線規(guī)則，如何分配端口?跨機(jī)房設(shè)備的線纜 / 模塊如何選取對應(yīng)物料?
至此只解決了“互聯(lián)”和“資源”的問題，接下來考察實際的配置。
有些配置是所有角色共有的，如生成樹配置、AAA 配置等。而有些配置又會根據(jù)設(shè)備角色的不同而有所區(qū)分，如 DSCP 標(biāo)記、三層接口等。
而當(dāng)引入了多設(shè)備廠商的問題后，情況會變得更復(fù)雜：接口名是 100GE 還是 HundredGigabitEthernet ? slot/interface/index 是從 0 開始還是 1 開始?去使能某個功能的關(guān)鍵字是用 undo 還是 no ?
建設(shè)團(tuán)隊的工程師會維護(hù)多角色、多廠商配置模版文件，一般以 Excel / 文本文件的形式呈現(xiàn)。對某一特定設(shè)備開局時需要跳轉(zhuǎn)多個文件，進(jìn)行不斷的 copy /paste 來完成一個設(shè)備的配置編寫。
如此，完成一個幾百臺網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)中心網(wǎng)絡(luò)開局，可能需要 1 - 2 個人 / 周投入，這顯然不能滿足業(yè)務(wù)快速擴(kuò)展的需求。
2.2Automate or die
不難發(fā)現(xiàn)，整個開局過程中有大量繁復(fù)的計算和操作工作，諸如：
>繁雜的接線分配、IP 地址分配工作
>重復(fù)的配置文件的翻譯工作
>服務(wù)于架構(gòu)角色的配置區(qū)分
人進(jìn)行這些繁復(fù)的工作效率很低且容易出錯，而這正是程序擅長的。
2.3 系統(tǒng)分層設(shè)計
回到之前的問題：就像要把大象塞冰箱，建設(shè)一個新的數(shù)據(jù)中心網(wǎng)絡(luò)總共分幾步?
對整個建設(shè)的故事進(jìn)行考察和思索，我們將這個“萬丈高樓平地起”的過程抽象為如下三個過程，對應(yīng)大爆炸系統(tǒng)的三個組件 :
1.規(guī)劃 - 架構(gòu)規(guī)劃庫
類似《GB 50017-2017 鋼結(jié)構(gòu)設(shè)計標(biāo)準(zhǔn)》， 這是一個抽象的實施規(guī)范
如UCloud優(yōu)刻得可支撐單可用區(qū) 320，000 服務(wù)器的數(shù)據(jù)中心網(wǎng)絡(luò)系統(tǒng)設(shè)計
2.分配 - 資源分配器
類似有建設(shè)需求后， 拿到了一塊地開始計算需要哪些物料，分配各項資源
分配各種資源，并抽象的生成連接圖
3.建設(shè) - 配置生成及刷入類似拿著圖紙進(jìn)行施工，直到把樓蓋好交付
生成出所有設(shè)備的配置文件，刷入設(shè)備中
這樣做的好處 :
1.耦合松散，每一個模塊只完成一個或幾個功能，彼此通過結(jié)構(gòu)化的信息進(jìn)行流轉(zhuǎn)，彼此屏蔽了內(nèi)部細(xì)節(jié)。
2.當(dāng)其中的一小部分發(fā)生變化時，只需要修改發(fā)生變化的部分。如機(jī)房現(xiàn)場需要更換接線表的格式，只需要發(fā)布一個新版的資源分配器，上下游不需要感知資源分配器發(fā)生了變化。
3．架構(gòu)規(guī)劃庫
如果需要程序來幫助我們的計算需要的設(shè)備、互聯(lián)圖、IP 段等信息，首先需要考慮的是:“應(yīng)該如何抽象的表達(dá)一個架構(gòu)?”
先退一步，我們應(yīng)該如何描述一個機(jī)房的拓?fù)?
這要求我們描述一個圖結(jié)構(gòu) :
>點：有哪些設(shè)備
>線：設(shè)備物理上是怎么互聯(lián)的
>點及線的屬性：IP
基于此，我們再進(jìn)行一次抽象，把具體每個設(shè)備的抽象為角色，把具體的 IP 變?yōu)榭煞峙涞?IP 段。然后得到我們需要描述的內(nèi)容：
>有哪些角色(設(shè)備)
>有哪些 IP 段可供分配
>角色之間是如何互聯(lián)的
>角色本身(如 loopback 口)要使用哪些 IP 段
>互聯(lián)要使用哪些 IP 段
這五個信息點。
因為：
>一個較小的 IP 段肯定是由一個更大的 IP 段拆分而來，分出來的子 IP 段有關(guān)聯(lián)。
>我們需要多個角色通力合作才能連同網(wǎng)絡(luò)，角色之間有關(guān)聯(lián)。
基于上面這些假設(shè)，我們可以抽象出兩顆樹 ———— 設(shè)備樹和 IP 段樹，這二棵樹各自扇出(fan out) ，最后在葉子節(jié)點上建立關(guān)聯(lián)。
至此，我們已經(jīng)表達(dá)了
>有哪些角色
>有哪些 IP 段
>角色本身(如 loopback 口)要使用哪些 IP 段
這三個信息點。
還剩下：
>角色之間是如何互聯(lián)的
>角色之間的互聯(lián)要使用哪個 IP 段
這兩個信息點。
在數(shù)據(jù)中心網(wǎng)絡(luò)演進(jìn)到多平面的 Fabric 網(wǎng)絡(luò)后，互聯(lián)關(guān)系的種類呈現(xiàn)指數(shù)級上升。如何準(zhǔn)確、易理解、低成本、低耦合的描述這些互聯(lián)關(guān)系成為了擺在我們面前的巨大難題。
我們想到的第一個方案：預(yù)定義套餐，即預(yù)先定義出所有可選的互聯(lián)方案。將這些邏輯固化到代碼中去。如：笛卡爾積式互聯(lián)，間隔互聯(lián)，交叉互聯(lián)等等。
我們迅速否決了這個方案，因為：
>極高的理解成本：工程師很難從名字和描述等處獲得足夠的信息，需要配套大量的文檔，相當(dāng)于回退到了文檔描述的時代。
>極高的研發(fā)成本：每當(dāng)新加一種互聯(lián)類型，都需要大量研發(fā)資源投入適配，也需要研發(fā)同學(xué)深入的理解每種互聯(lián)方案，再加上每種互聯(lián)方案有大量的可調(diào)參數(shù)，如間隔互聯(lián)可調(diào)間隔數(shù)量等等。
>嚴(yán)重的跨模塊耦合：當(dāng)架構(gòu)規(guī)劃信息在 “” 架構(gòu)規(guī)劃庫 “ 和 “資源分配器” 之間傳遞時，需要為每個互聯(lián)方案設(shè)計一種數(shù)據(jù)結(jié)構(gòu)，相當(dāng)于要求「架構(gòu)規(guī)劃庫」和「資源分配器」都需要完全理解每一種互聯(lián)方案。
我們從 tcpdump 工具中得到啟發(fā)，當(dāng)要描述特定領(lǐng)域內(nèi)的復(fù)雜邏輯的時，可以嘗試設(shè)計一種 領(lǐng)域特定語言(DSL)來解決。我們設(shè)計了一種描述互聯(lián)的 DSL —— UCLOUD DC CONNECT LANG。語言短小精悍，說明文檔約一頁，描述一種互聯(lián)關(guān)系只需要 10 個左右的字符，實踐中，新員工只需要大約 1 天就可以理解這個語言，這個方案完全解決了預(yù)定義套餐產(chǎn)生的問題：
>極低的理解和維護(hù)成本：只要理解了這個語言，就理解了所有的互聯(lián)方案。
>極低的研發(fā)成本：只需要實現(xiàn)了這個語言的邏輯，就可以覆蓋所有的互聯(lián)方案。所以，“資源分配器” 只需要實現(xiàn)一次語言邏輯，終身免維護(hù)。
>極低的耦合：架構(gòu)規(guī)劃庫直接向資源分配器按 string 傳遞 DSL 原文即可，不再需要多種數(shù)據(jù)結(jié)構(gòu)。
回到之前的“兩棵樹”上，給角色之間補(bǔ)充上互聯(lián)信息和互聯(lián)需要使用哪些 IP 地址段的信息。
至此，我們通過兩棵樹和一個三角形已經(jīng)完整的表達(dá)了之前提到的五個信息點。
>有哪些角色(設(shè)備)
>有哪些 IP 段可供分配
>角色之間是如何互聯(lián)的
>角色本身(如 loopback 口)要使用哪些 IP 段
>角色之間的互聯(lián)要使用哪些 IP 段
當(dāng)然實際上還要稍微復(fù)雜一些，諸如 IP 段上會有業(yè)務(wù)標(biāo)簽，角色上會有端口分配規(guī)則等等。但這些本質(zhì)上只是各個葉子節(jié)點的其他屬性，只需要簡單的加到葉子節(jié)點上即可。
4．資源分配器
架構(gòu)規(guī)劃庫的信息流轉(zhuǎn)到資源分配器后，資源分配器就要來分配資源。
那么第一個問題就是：它需要分配什么資源?
我們的答案：分配那些需要在全網(wǎng)資源池中獲取的，與具體架構(gòu)及具體路由協(xié)議無關(guān)的資源。
這樣做的主要原因是我們希望資源分配器與網(wǎng)絡(luò)架構(gòu)設(shè)計完全解耦，否則會導(dǎo)致：
>要么，需要持續(xù)投入研發(fā)人力跟蹤實現(xiàn)數(shù)據(jù)中心內(nèi)的動態(tài)路由協(xié)議從 OSPF 到 BGP 再到分布式數(shù)據(jù)庫所需的各種資源分配邏輯
>開發(fā)工具的同學(xué)不見得可以低成本、快速的理解網(wǎng)絡(luò)設(shè)計上的細(xì)節(jié)
>又或者，系統(tǒng)能力限制網(wǎng)絡(luò)架構(gòu)設(shè)計，若系統(tǒng)只支持 BGP AS 號分配，那架構(gòu)設(shè)計只能使用 BGP 協(xié)議
那這些協(xié)議相關(guān)的邏輯資源怎么辦?我們借鑒了“變量作用域”的概念。
資源分配器為每個角色分配一組局部(包括但不限于數(shù)據(jù)中心內(nèi)、設(shè)備組內(nèi)等)唯一的 ID 值，我們稱之為 ID 組。在下一步配置生成中再根據(jù) ID 組計算出這些資源。
這樣的設(shè)計保證了：
>局部唯一性
>可計算性，互聯(lián)兩側(cè)角色可以根據(jù)同樣的參數(shù)和算法得到同樣的邏輯資源，使得路由協(xié)議能正確協(xié)商
確定了需要分配的資源后，資源分配器根據(jù)架構(gòu)規(guī)劃庫給出的架構(gòu)信息，人工給出的規(guī)模信息，從 CMDB、IPAM 等資源池中獲取設(shè)備、IP 等資源，并計算出一個描述了整個數(shù)據(jù)中心拓?fù)涞臄?shù)據(jù)文件，稱為連接圖。
連接圖中的信息主要包括兩類：
>設(shè)備信息(點)
>上文提到的 ID 組
>管理 IP
>…
>互聯(lián)信息(線)
>兩側(cè)設(shè)備
>兩側(cè) IP
>兩側(cè)端口
>…
連接圖信息將會繼續(xù)傳遞給配置生成器。
5．配置生成器
至此，我們已經(jīng)有了基于架構(gòu)規(guī)劃庫給出的規(guī)則分配好的資源 (連接圖信息)，這些信息如何轉(zhuǎn)化成交換機(jī)可以理解的配置?
這就是配置生成器做的工作。
5.1配置的生成
實際寫到交換機(jī)上的命令可以分為三大類 :
1.全局一致的配置，如 AAA 配置、安全策略配置等
2.與角色自身屬性有關(guān)的配置
3.角色之間的互聯(lián)配置，如 BGP peer address、BGP AS 、三層口 IP 等
一個配置例子：
可以發(fā)現(xiàn)，配置實際上是由一些固定的模板及變量組合而成的。而這些變量肯定來自于資源分配器的連接圖中，點自身的屬性，或者線的屬性，又或者是與點連接的另外的點的屬性。所以，只需要寫好模板，再遍歷連接圖，我們就可以很輕松地得到整個機(jī)房所有設(shè)備的配置。
上文的配置在模版中的表現(xiàn)形式 ：
我們使用 jinja2 來幫助渲染模板，jinja2 支持模板的繼承和組合，可以避免在每個角色的模板中重復(fù)寫很多通用配置。同時，jinja2 模板非常的直觀，簡潔，所見即所得。替換為 jinja2 后大幅降低了配置命令的錯誤率。
我們還通過 git 管理模板，并圍繞 git 構(gòu)建了模板編寫及修改工作流，引入了自動化測試機(jī)制，保證了對模板的修改有解釋，有 review，且經(jīng)過測試，基本消除模板語法錯誤導(dǎo)致的溝通成本。
5.2 臨門一腳
由前述的資源分配等步驟，至此我們已經(jīng)完成了所有設(shè)備的配置生成工作，IDC 現(xiàn)場的同學(xué)也按系統(tǒng)給出的信息將設(shè)備完成上架、接線、開電。
至此我們只剩整個數(shù)據(jù)中心物理網(wǎng)絡(luò)建設(shè)的 “臨門一腳”，這些配置文件 (以交換機(jī) sn 命名的 txt 文件) 如何下發(fā)到交換機(jī)上，作為 startup config 啟動并運行?
這里我們使用目前各主流廠商均支持的 “零配置啟動” 功能 :
設(shè)備運行ZTP功能，可以從 U 盤或文件服務(wù)器獲取版本文件并自動加載，實現(xiàn)設(shè)備的免現(xiàn)場配置、部署，從而降低人力成本，提升部署效率。
實際運行中，我們會在新建的數(shù)據(jù)中心部署一臺 PC (一個致密熾熱的奇點)， 這臺 PC 上運行了 DHCP、TFTP 服務(wù)以及存放了該數(shù)據(jù)中心所有設(shè)備的配置文件。
類比服務(wù)器的 PXE 裝機(jī)過程，我們利用 DHCP 服務(wù)器下發(fā) TFTP Server 和 Bootfile， 交換機(jī)會自動執(zhí)行該腳本，而后從 TFTP 服務(wù)器下載其所需的配置文件。
在這里我們之前忽略了一個問題：同一數(shù)據(jù)中心內(nèi)采購多廠商的設(shè)備，如何解決生成 / 下發(fā)特定廠商配置文件的問題?
答案是不解決，或者說不在前期考慮這個問題。
配置生成器不感知，也不在乎上架使用的具體設(shè)備型號，而是直接生成出所有可能廠商的配置文件。例如某一特定角色共有 A、B、C 三個廠商的三份配置文件。
在交換機(jī)發(fā)送 DHCP Discover 報文時攜帶其廠牌信息，如此奇點只要根據(jù)其廠牌返回不同的 TFTP 路徑即可完成配置的下發(fā)。
通過以上幾個步驟，在現(xiàn)場完成上架、布線等工作后，我們可以在小時級別將整個數(shù)據(jù)中心內(nèi)的配置拉起，完成開局。
5.3one more thing
完成配置下發(fā)并不是結(jié)束，我們還賦予了“奇點”一些其他功能：因為有了整網(wǎng)的連接圖，我們可以在最終交付給業(yè)務(wù)之前做一些檢查，確認(rèn)我們的數(shù)據(jù)中心網(wǎng)絡(luò)是可靠的。
>通過對所有設(shè)備的連通性檢查，確認(rèn)設(shè)備均已正確上線，管理面均可達(dá)。
>通過比對交換機(jī)的 startup config 與 running config ， 確認(rèn)全部配置下發(fā)正確。
>通過 ZTP 功能，我們可以指定上線設(shè)備的版本信息，由系統(tǒng)自動升級為 DCN 指定的操作系統(tǒng)版本。
>通過比對連接圖中的 peer 關(guān)系與讀取設(shè)備的 LLDP 信息，確認(rèn)全部接線正確。
>在我們實際運行中此處常會檢出一些錯誤：人工依然是不可靠的，而工具可以檢查和避免這種錯誤。
6．總結(jié)
從零建設(shè)一個可容納萬臺服務(wù)器的數(shù)據(jù)中心網(wǎng)絡(luò)需要多久?
幾小時。
但比起 “交付時間壓縮了多少?”，更大的價值更在于我們將目光聚焦在工程師擅長的地方，將其從繁瑣的表格、分配工作中解放出來，花更多精力去理解我們客戶的工作流和關(guān)注點，建造真正能輸出業(yè)務(wù)價值的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。
UCloud優(yōu)刻得物理網(wǎng)絡(luò)團(tuán)隊將繼續(xù)秉承這一理念，堅信“連接的力量”，為各公有云產(chǎn)品、為客戶提供更穩(wěn)定、更高效的網(wǎng)絡(luò)服務(wù)。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
