從零建設(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 物理網(wǎng)絡(luò)團(tuán)隊已有一代數(shù)據(jù)中心建設(shè)系統(tǒng),，隨著業(yè)務(wù)和架構(gòu)的演進(jìn),，上一代系統(tǒng)的一些缺點逐漸暴露出來 :

l  對多平面的 Fabric 數(shù)據(jù)中心網(wǎng)絡(luò)支持不夠靈活

l  架構(gòu)規(guī)則描述不靈活，網(wǎng)絡(luò)設(shè)計版本迭代后需要再次投入大量研發(fā)人力適配,，且存在需要研發(fā)理解網(wǎng)絡(luò)業(yè)務(wù)設(shè)計的強(qiáng)耦合問題

l  原子命令庫方式組織的配置模板不直觀,，人工難以預(yù)測其生成的配置，導(dǎo)致維護(hù)成本過高,，且修改后無測試,，容易出錯

l  在建設(shè)海外機(jī)房時，由于網(wǎng)絡(luò)延遲過高,，基于編排器的配置下發(fā)方式出現(xiàn)了失敗率快速攀升的問題

通過對上述挑戰(zhàn)和缺點的分析不難得出推論,，我們需要這樣一款建設(shè)系統(tǒng)工具 :

l  靈活適配多版本、多形態(tài),、多平面的數(shù)據(jù)中心網(wǎng)絡(luò)

l  網(wǎng)絡(luò)架構(gòu)迭代不應(yīng)需研發(fā)同學(xué)介入

l  可以直觀的修改配置模板,，修改后可以自動化的低成本的進(jìn)行測試

l  低網(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 數(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．2 Automate or die

不難發(fā)現(xiàn)，整個開局過程中有大量繁復(fù)的計算和操作工作，諸如：

l  繁雜的接線分配,、IP 地址分配工作

l  重復(fù)的配置文件的翻譯工作

l  服務(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)的三個組件 :

規(guī)劃 - 架構(gòu)規(guī)劃庫

類似《GB 50017-2017 鋼結(jié)構(gòu)設(shè)計標(biāo)準(zhǔn)》,， 這是一個抽象的實施規(guī)范

如 UCloud 可支撐單可用區(qū) 320，000 服務(wù)器的數(shù)據(jù)中心網(wǎng)絡(luò)系統(tǒng)設(shè)計 分配 - 資源分配器

類似有建設(shè)需求后,， 拿到了一塊地開始計算需要哪些物料,，分配各項資源

分配各種資源，并抽象的生成連接圖 建設(shè) - 配置生成及刷入

類似拿著圖紙進(jìn)行施工,，直到把樓蓋好交付

生成出所有設(shè)備的配置文件,，刷入設(shè)備中

這樣做的好處 :

耦合松散，每一個模塊只完成一個或幾個功能,，彼此通過結(jié)構(gòu)化的信息進(jìn)行流轉(zhuǎn),，彼此屏蔽了內(nèi)部細(xì)節(jié)。 當(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ù)洌?/h2>

這要求我們描述一個圖結(jié)構(gòu) :

l  點：有哪些設(shè)備

l  線：設(shè)備物理上是怎么互聯(lián)的

l  點及線的屬性：IP

基于此,，我們再進(jìn)行一次抽象，把具體每個設(shè)備的抽象為角色,，把具體的 IP 變?yōu)榭煞峙涞?IP 段,。然后得到我們需要描述的內(nèi)容：

l  有哪些角色（設(shè)備）

l  有哪些 IP 段可供分配

l  角色之間是如何互聯(lián)的

l  角色本身（如 loopback 口）要使用哪些 IP 段

l  互聯(lián)要使用哪些 IP 段

這五個信息點。

因為：

l  一個較小的 IP 段肯定是由一個更大的 IP 段拆分而來,，分出來的子 IP 段有關(guān)聯(lián),。

l  我們需要多個角色通力合作才能連同網(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ī)上的命令可以分為三大類 :

全局一致的配置，如 AAA 配置,、安全策略配置等 與角色自身屬性有關(guān)的配置 角色之間的互聯(lián)配置,，如 BGP peer address、BGP AS ,、三層口 IP 等

一個配置例子：

hostname LAS.xxxxxx

#

interface HundredGigabitEthernet 0/1

no switchport

description To_LCS

ip address 10.68.176.53 255.255.255.254

可以發(fā)現(xiàn),，配置實際上是由一些固定的模板及變量組合而成的。而這些變量肯定來自于資源分配器的連接圖中,，點自身的屬性,，或者線的屬性，又或者是與點連接的另外的點的屬性,。所以,，只需要寫好模板，再遍歷連接圖,，我們就可以很輕松地得到整個機(jī)房所有設(shè)備的配置,。

上文的配置在模版中的表現(xiàn)形式 ：

hostname {{ device_name }}

#

interface {{ pair["local_interface_name"] }}

no switchport

description {{ conn["peer_device"]["device_name"] }}

ip address {{ ip["ip"] }} {{ ip["mask"] }}

我們使用 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 啟動并運行,？

這里我們使用目前各主流廠商均支持的 “零配置啟動” 功能 :

定義

ZTP（Zero Touch Provisioning）是指新出廠或空配置設(shè)備上電啟動時采用的一種自動加載版本文件（包括系統(tǒng)軟件,、配置文件、License 文件,、補(bǔ)丁文件,、自定義文件）的功能。

目的

在部署網(wǎng)絡(luò)設(shè)備時,，設(shè)備硬件安裝完成后,，需要管理員到安裝現(xiàn)場對設(shè)備進(jìn)行軟件調(diào)試。當(dāng)設(shè)備數(shù)量較多,、分布較廣時,，管理員需要在每一臺設(shè)備上進(jìn)行手工配置，既影響了部署的效率,，又需要較高的人力成本,。

設(shè)備運行 ZTP 功能，可以從 U 盤或文件服務(wù)器獲取版本文件并自動加載,，實現(xiàn)設(shè)備的免現(xiàn)場配置,、部署，從而降低人力成本,，提升部署效率,。

實際運行中，我們會在新建的數(shù)據(jù)中心部署一臺 PC ( 一個致密熾熱的奇點