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