從零建設一個可容納萬臺服務器的數據中心網絡需要多久？

類比“要把大象裝冰箱，總共分幾步？”，從零開局一個數據中心，將網絡從建設到交付的過程更像“開荒”。傳統(tǒng)依賴工程師人工編寫繁瑣的網絡設備命令費時又費力，且交期與質量均無法得到保障。

為此我們設計了一款數據中心網絡建設系統(tǒng) —— Big Bang，將數據中心網絡開局這一任務切分為“架構規(guī)劃” - “資源分配” - “配置生成及下發(fā)”三個步驟。每一步之間耦合松散而內部又高度內聚，實現低成本適配不同版本架構迭代、不同規(guī)模機房的小時級快速部署目標。

Big Bang 上線后支持了自建的烏蘭察布大規(guī)模數據中心網絡建設開局，至今已完成海內外多個機房的快速、高質量交付。

The Big Bang Theory : 宇宙是由一個致密熾熱的奇點于一次大爆炸后膨脹形成的。

1.上一代建設系統(tǒng)的不足

在 Big Bang 之前 UCloud 物理網絡團隊已有一代數據中心建設系統(tǒng)，隨著業(yè)務和架構的演進，上一代系統(tǒng)的一些缺點逐漸暴露出來 :

l  對多平面的 Fabric 數據中心網絡支持不夠靈活

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

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

l  在建設海外機房時，由于網絡延遲過高，基于編排器的配置下發(fā)方式出現了失敗率快速攀升的問題

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

l  靈活適配多版本、多形態(tài)、多平面的數據中心網絡

l  網絡架構迭代不應需研發(fā)同學介入

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

l  低網絡依賴，弱網條件下依然能好用

2．Big Bang 設計概要
2．1 人肉運維之痛

在談設計之前，我們先來談一下人工建設一個數據中心會遇到哪些挑戰(zhàn)？

考察一個簡單的兩級 CLOS 架構 : 4 個 Spine， 32 個 Leaf 共 36 臺設備構成一個業(yè)務專區(qū)，這在 UCloud 數據中心中是很常見的 POD 規(guī)模。

建設這樣一個網絡，首先需要給出設備接線表交由現場的同學進行布線。這張接線表要表達 “spine01.p1 接 leaf01.p49， 使用 QSFP28 100G 線纜” 這樣的信息。 對于這個 POD 便產生了 4 * 32 = 128 個互聯關系。

給出布線規(guī)則后，我們再來考慮 IP 分配的問題。

圖中每一條線均需要一對互聯地址，除此之外設備還需要分配管理地址、業(yè)務地址等。一個 POD 便需要 128 個互聯網段、32 個業(yè)務網段、幾十個管理地址。這些地址都需要工程師到 IP 管理系統(tǒng)中占用，并與設備 (互聯關系) 一一對應。

可以看到，在 CLOS 架構下進行的互聯計算、資源分配工作非常繁復，并且數量會隨著網元數量、接口數量的增加而急劇增加。

除此之外，還有一些要求會使這些挑戰(zhàn)變得更加復雜：部分角色指定接線規(guī)則，如何分配端口？跨機房設備的線纜 / 模塊如何選取對應物料？

至此只解決了“互聯”和“資源”的問題，接下來考察實際的配置。

有些配置是所有角色共有的，如生成樹配置、AAA 配置等。而有些配置又會根據設備角色的不同而有所區(qū)分，如 DSCP 標記、三層接口等。

而當引入了多設備廠商的問題后，情況會變得更復雜：接口名是 100GE 還是 HundredGigabitEthernet ？ slot/interface/index 是從 0 開始還是 1 開始？去使能某個功能的關鍵字是用 undo 還是 no ？

建設團隊的工程師會維護多角色、多廠商配置模版文件，一般以 Excel / 文本文件的形式呈現。對某一特定設備開局時需要跳轉多個文件，進行不斷的 copy /paste 來完成一個設備的配置編寫。

如此，完成一個幾百臺網絡設備的數據中心網絡開局，可能需要 1 - 2 個人 / 周投入，這顯然不能滿足業(yè)務快速擴展的需求。

2．2 Automate or die

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

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

l  重復的配置文件的翻譯工作

l  服務于架構角色的配置區(qū)分

人進行這些繁復的工作效率很低且容易出錯，而這正是程序擅長的。

2．3 系統(tǒng)分層設計

回到之前的問題：就像要把大象塞冰箱，建設一個新的數據中心網絡總共分幾步？

對整個建設的故事進行考察和思索，我們將這個“萬丈高樓平地起”的過程抽象為如下三個過程，對應大爆炸系統(tǒng)的三個組件 :

規(guī)劃 - 架構規(guī)劃庫

類似《GB 50017-2017 鋼結構設計標準》， 這是一個抽象的實施規(guī)范

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

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

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

類似拿著圖紙進行施工，直到把樓蓋好交付

生成出所有設備的配置文件，刷入設備中

這樣做的好處 :

耦合松散，每一個模塊只完成一個或幾個功能，彼此通過結構化的信息進行流轉，彼此屏蔽了內部細節(jié)。 當其中的一小部分發(fā)生變化時，只需要修改發(fā)生變化的部分。如機房現場需要更換接線表的格式，只需要發(fā)布一個新版的資源分配器，上下游不需要感知資源分配器發(fā)生了變化。 3．架構規(guī)劃庫

如果需要程序來幫助我們的計算需要的設備、互聯圖、IP 段等信息，首先需要考慮的是:“應該如何抽象的表達一個架構？”

先退一步，我們應該如何描述一個機房的拓撲？

這要求我們描述一個圖結構 :

l  點：有哪些設備

l  線：設備物理上是怎么互聯的

l  點及線的屬性：IP

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

l  有哪些角色（設備）

l  有哪些 IP 段可供分配

l  角色之間是如何互聯的

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

l  互聯要使用哪些 IP 段

這五個信息點。

因為：

l  一個較小的 IP 段肯定是由一個更大的 IP 段拆分而來，分出來的子 IP 段有關聯。

l  我們需要多個角色通力合作才能連同網絡，角色之間有關聯。

基于上面這些假設，我們可以抽象出兩顆樹 ———— 設備樹和 IP 段樹，這二棵樹各自扇出（fan out） ，最后在葉子節(jié)點上建立關聯。

至此，我們已經表達了

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

這三個信息點。

還剩下：

角色之間是如何互聯的 角色之間的互聯要使用哪個 IP 段

這兩個信息點。

在數據中心網絡演進到多平面的 Fabric 網絡后，互聯關系的種類呈現指數級上升。如何準確、易理解、低成本、低耦合的描述這些互聯關系成為了擺在我們面前的巨大難題。

我們想到的第一個方案：預定義套餐，即預先定義出所有可選的互聯方案。將這些邏輯固化到代碼中去。如：笛卡爾積式互聯，間隔互聯，交叉互聯等等。

我們迅速否決了這個方案，因為：

極高的理解成本：工程師很難從名字和描述等處獲得足夠的信息，需要配套大量的文檔，相當于回退到了文檔描述的時代。 極高的研發(fā)成本：每當新加一種互聯類型，都需要大量研發(fā)資源投入適配，也需要研發(fā)同學深入的理解每種互聯方案，再加上每種互聯方案有大量的可調參數，如間隔互聯可調間隔數量等等。 嚴重的跨模塊耦合：當架構規(guī)劃信息在 “” 架構規(guī)劃庫 “ 和 “資源分配器” 之間傳遞時，需要為每個互聯方案設計一種數據結構，相當于要求「架構規(guī)劃庫」和「資源分配器」都需要完全理解每一種互聯方案。

我們從 tcpdump 工具中得到啟發(fā)，當要描述特定領域內的復雜邏輯的時，可以嘗試設計一種領域特定語言（DSL）來解決。我們設計了一種描述互聯的 DSL —— UCLOUD DC CONNECT LANG。語言短小精悍，說明文檔約一頁，描述一種互聯關系只需要 10 個左右的字符，實踐中，新員工只需要大約 1 天就可以理解這個語言，這個方案完全解決了預定義套餐產生的問題：

極低的理解和維護成本：只要理解了這個語言，就理解了所有的互聯方案。 極低的研發(fā)成本：只需要實現了這個語言的邏輯，就可以覆蓋所有的互聯方案。所以，“資源分配器” 只需要實現一次語言邏輯，終身免維護。 極低的耦合：架構規(guī)劃庫直接向資源分配器按 string 傳遞 DSL 原文即可，不再需要多種數據結構。

回到之前的“兩棵樹”上，給角色之間補充上互聯信息和互聯需要使用哪些 IP 地址段的信息。

至此，我們通過兩棵樹和一個三角形已經完整的表達了之前提到的五個信息點。

有哪些角色（設備） 有哪些 IP 段可供分配 角色之間是如何互聯的 角色本身（如 loopback 口）要使用哪些 IP 段 角色之間的互聯要使用哪些 IP 段

當然實際上還要稍微復雜一些，諸如 IP 段上會有業(yè)務標簽，角色上會有端口分配規(guī)則等等。但這些本質上只是各個葉子節(jié)點的其他屬性，只需要簡單的加到葉子節(jié)點上即可。

4．資源分配器

架構規(guī)劃庫的信息流轉到資源分配器后，資源分配器就要來分配資源。

那么第一個問題就是：它需要分配什么資源？

我們的答案：分配那些需要在全網資源池中獲取的，與具體架構及具體路由協(xié)議無關的資源。

這樣做的主要原因是我們希望資源分配器與網絡架構設計完全解耦，否則會導致：

要么，需要持續(xù)投入研發(fā)人力跟蹤實現數據中心內的動態(tài)路由協(xié)議從 OSPF 到 BGP 再到分布式數據庫所需的各種資源分配邏輯 開發(fā)工具的同學不見得可以低成本、快速的理解網絡設計上的細節(jié) 又或者，系統(tǒng)能力限制網絡架構設計，若系統(tǒng)只支持 BGP AS 號分配，那架構設計只能使用 BGP 協(xié)議

那這些協(xié)議相關的邏輯資源怎么辦？我們借鑒了“變量作用域”的概念。

資源分配器為每個角色分配一組局部（包括但不限于數據中心內、設備組內等）唯一的 ID 值，我們稱之為 ID 組。在下一步配置生成中再根據 ID 組計算出這些資源。

這樣的設計保證了：

局部唯一性 可計算性，互聯兩側角色可以根據同樣的參數和算法得到同樣的邏輯資源，使得路由協(xié)議能正確協(xié)商

確定了需要分配的資源后，資源分配器根據架構規(guī)劃庫給出的架構信息，人工給出的規(guī)模信息，從 CMDB、IPAM 等資源池中獲取設備、IP 等資源，并計算出一個描述了整個數據中心拓撲的數據文件，稱為連接圖。

連接圖中的信息主要包括兩類：

設備信息（點） 上文提到的 ID 組 管理 IP … 互聯信息（線） 兩側設備 兩側 IP 兩側端口 …

連接圖信息將會繼續(xù)傳遞給配置生成器。

5．配置生成器

至此，我們已經有了基于架構規(guī)劃庫給出的規(guī)則分配好的資源 (連接圖信息)，這些信息如何轉化成交換機可以理解的配置？ 

這就是配置生成器做的工作。

5．1 配置的生成

實際寫到交換機上的命令可以分為三大類 :

全局一致的配置，如 AAA 配置、安全策略配置等 與角色自身屬性有關的配置 角色之間的互聯配置，如 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ā)現，配置實際上是由一些固定的模板及變量組合而成的。而這些變量肯定來自于資源分配器的連接圖中，點自身的屬性，或者線的屬性，又或者是與點連接的另外的點的屬性。所以，只需要寫好模板，再遍歷連接圖，我們就可以很輕松地得到整個機房所有設備的配置。

上文的配置在模版中的表現形式 ：

hostname {{ device_name }}

#

interface {{ pair["local_interface_name"] }}

no switchport

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

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

我們使用 jinja2 來幫助渲染模板，jinja2 支持模板的繼承和組合，可以避免在每個角色的模板中重復寫很多通用配置。同時，jinja2 模板非常的直觀，簡潔，所見即所得。替換為 jinja2 后大幅降低了配置命令的錯誤率。

我們還通過 git 管理模板，并圍繞 git 構建了模板編寫及修改工作流，引入了自動化測試機制，保證了對模板的修改有解釋，有 review，且經過測試，基本消除模板語法錯誤導致的溝通成本。

5.2 臨門一腳

由前述的資源分配等步驟，至此我們已經完成了所有設備的配置生成工作，IDC 現場的同學也按系統(tǒng)給出的信息將設備完成上架、接線、開電。

至此我們只剩整個數據中心物理網絡建設的 “臨門一腳”，這些配置文件 (以交換機 sn 命名的 txt 文件) 如何下發(fā)到交換機上，作為 startup config 啟動并運行？

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

定義

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

目的

在部署網絡設備時，設備硬件安裝完成后，需要管理員到安裝現場對設備進行軟件調試。當設備數量較多、分布較廣時，管理員需要在每一臺設備上進行手工配置，既影響了部署的效率，又需要較高的人力成本。

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

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