如何建設(shè)一個云原生數(shù)據(jù)中心的網(wǎng)絡(luò)？

干我們這行免不了要閱讀大量資料，但這個行業(yè)又存在大量細分的領(lǐng)域，我們的時間是有限的，現(xiàn)代人能投入讀書的時間更是少之又少，一個問題是我們到底應(yīng)該深入閱讀還是廣泛閱讀?

最近讀到 Shopify 某個開發(fā)團隊前負責(zé)人 Simon Eskildsen 的采訪[1]。Simon Eskildsen 只是一個高中生，卻在 gap year 加入創(chuàng)業(yè)期的 Shopify 并跟隨公司一同成長為技術(shù)管理者。沒有任何學(xué)位的他表示，自己是靠著大量閱讀來學(xué)習(xí)計算機和管理的知識。Simon Eskildsen 在采訪中提到自己努力成為T 型人才：在一個領(lǐng)域深入，但在多個領(lǐng)域有廣博的知識面。

之前的文章中，我們聊過分布式計算、存儲、協(xié)調(diào)等主題，唯獨網(wǎng)絡(luò)方面沒有談過。在《SRE：Google運維解密》中有一句令我影響深刻的話：“UNIX 系統(tǒng)內(nèi)部細節(jié)和1～3層網(wǎng)絡(luò)知識是Google最看重的兩類額外的技術(shù)能力?！?/p>

本身我的網(wǎng)絡(luò)知識也比較薄弱，恰好最近工作設(shè)計一些網(wǎng)絡(luò)架構(gòu)相關(guān)的知識，于是從10月開始我停了下來，開始閱讀一些現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)的知識。讀者可以和我一起思考，如果新的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)讓你來設(shè)計，你會怎么做?

這在 O REILLY 的新書《Cloud Native Data Center Networking》(中文《云原生數(shù)據(jù)中心網(wǎng)絡(luò)》)中有解答。我本來讀的原版，可是沒法理解書中一些英文網(wǎng)絡(luò)詞匯。最近中文版出版，正好找來對照著讀一下，并記此筆記。

為什么需要一個新的網(wǎng)絡(luò)架構(gòu)

如果應(yīng)用一層不變，那我們就沒有必要進行討論了。我們談云原生數(shù)據(jù)中心網(wǎng)絡(luò)，那這個架構(gòu)就是要為現(xiàn)代云原生應(yīng)用而設(shè)計的。所以，現(xiàn)代云原生應(yīng)用有什么特點?

書中提到，“應(yīng)用-網(wǎng)絡(luò)”架構(gòu)的演進經(jīng)歷了如下圖的四個階段。

1.單體應(yīng)用

運行在大型機上 網(wǎng)絡(luò)流量小，協(xié)議是私有的

2.客戶端-服務(wù)器(C/S)架構(gòu)

工作站和 PC 興起 LAN 開始崛起，網(wǎng)絡(luò)流量增加，以太網(wǎng)、Token Ring 和 FDDI 是最流行的連接，速度最高為 100Mbps。最后，以太網(wǎng)和 TCP/IP 贏了

3.Web 應(yīng)用

隨著計算能力不斷提高，CPU 性能過剩，應(yīng)用開始運行在虛擬機中，Windows 成為主流，Linux還不夠成熟 千兆以太網(wǎng)成為企業(yè)網(wǎng)絡(luò)互聯(lián)標準

4.微服務(wù)

Google 分布式系統(tǒng)帶來歷史性轉(zhuǎn)變，南北向(客戶端和服務(wù)器之間)流量主導(dǎo)轉(zhuǎn)變成東西向(服務(wù)器之間)流量主導(dǎo)。Linux 成熟，云的興起，進入微服務(wù)和容器時代 萬兆網(wǎng)成為主流，網(wǎng)絡(luò)速度不斷提高

可見，分布式應(yīng)用發(fā)生巨變，網(wǎng)絡(luò)被打了個措手不及。傳統(tǒng)網(wǎng)絡(luò)為什么“跟不上節(jié)奏”?

上圖是傳統(tǒng)網(wǎng)絡(luò)，這種網(wǎng)絡(luò)設(shè)計被稱為“接入-匯聚-核心(access-aggregation-core)”架構(gòu)。計算機連接到接入交換機，之上是一對分布式的匯聚交換機，匯聚交換機連接到核心網(wǎng)絡(luò)，從而使接入層連接到外網(wǎng)。

“接入-匯聚-核心”網(wǎng)絡(luò)嚴重依賴于橋接(Bridging)技術(shù)，原因有三：

數(shù)據(jù)轉(zhuǎn)發(fā)芯片的出現(xiàn)，這種硬件技術(shù)最初僅支持橋接 企業(yè)專有的網(wǎng)絡(luò)軟件棧，除 IP 協(xié)議外還有別的協(xié)議 交換網(wǎng)絡(luò)零配置的承諾，路由網(wǎng)絡(luò)相對橋接網(wǎng)絡(luò)來說很難配置，而人為配置錯誤不是導(dǎo)致網(wǎng)絡(luò)故障的第一大原因，就是第二大原因

路由和橋接的區(qū)別：橋接工作在 OSI 網(wǎng)絡(luò)模型第二層即鏈路層，交換機或網(wǎng)橋根據(jù) MAC 地址來交換數(shù)據(jù)，鏈路層交換的是數(shù)據(jù)幀(frame)。路由工作在 OSI 第三層即網(wǎng)絡(luò)層，路由器根據(jù) IP 地址來找到目標地址，網(wǎng)絡(luò)層交換的是數(shù)據(jù)包。

盡管傳統(tǒng)網(wǎng)絡(luò)取得很大成功，但橋接網(wǎng)絡(luò)依然有以下限制：

廣播風(fēng)暴和生成樹協(xié)議(STP)的影響 泛洪帶來負擔(dān) IP 層的冗余設(shè)計，為了使匯聚交換機高可用，需要支持兩臺交換機使用同一個IP地址，但同一時間只有一臺路由器支持，為此又發(fā)明了 FHRP 協(xié)議來支持。

在轉(zhuǎn)發(fā)網(wǎng)絡(luò)中，每個數(shù)據(jù)包都攜帶兩個 MAC 地址：源地址和目標地址。網(wǎng)橋會在自身的 MAC 地址表中查找目標 MAC 地址。如果不知道，它將數(shù)據(jù)包發(fā)送到除接收數(shù)據(jù)包的接口以外的所有其他接口。當(dāng)網(wǎng)橋在自身的 MAC 地址表中找不到待轉(zhuǎn)發(fā)數(shù)據(jù)包的目的 MAC 地址，而向所有端口發(fā)送該數(shù)據(jù)包的行為稱為泛洪(flooding)。

“接入-匯聚-核心”很適合客戶端-服務(wù)器應(yīng)用架構(gòu)這種南北向流量為主的模式，如今服務(wù)器-服務(wù)器架構(gòu)越來越多，應(yīng)用規(guī)模顯著變大，“接入-匯聚-核心”存在以下問題：

1.不可擴展性

泛洪(Flooding)不可避免 VLAN 最多為 4096 個的限制 ARP 的負擔(dān)，匯聚交換機需要應(yīng)答大量ARP，導(dǎo)致CPU過高 交換機和STP的局限。理論上增加匯聚交換機能夠提升東西向帶寬，但是STP不支持兩個以上的匯聚交換機

2.復(fù)雜性。橋接網(wǎng)絡(luò)需要很多協(xié)議支持：STP、FHRP、鏈路失效偵測、供應(yīng)商私有協(xié)議(如 VTP)

3.失效域(Failure Domain)。容易發(fā)生粗粒度的失效，比如：單個鏈路的失效造成帶寬減半

4.不可預(yù)測性。許多組件會導(dǎo)致網(wǎng)絡(luò)變得不可預(yù)測，增加故障定位難度

缺乏敏捷。云計算領(lǐng)域，不停地有租戶使用資源或銷毀資源，而 VLAN 需要網(wǎng)絡(luò)中每個節(jié)點都正確配置了 VLAN 信息才能正常工作，添加或移除 VLAN 是一個費時費力的過程。

橋接技術(shù)的支持者沒有放棄，針對這些問題提出了許多解決方案，但在當(dāng)代企業(yè)數(shù)據(jù)中心少有使用。

云原生數(shù)據(jù)中心基礎(chǔ)設(shè)施想建立一個可大規(guī)模擴展的網(wǎng)絡(luò)架構(gòu)，Clos 就是這個架構(gòu)。

Clos 拓撲

Clos 拓撲結(jié)構(gòu)以其發(fā)明者 Charles Clos 命名，如下圖所示，該拓撲也稱為 leaf-spine 拓撲(或 spine-leaf 架構(gòu))。

上圖中：

spine 交換機。目的只有一個：連接不同的 leaf 交換機，計算節(jié)點永遠不會連接到 spine 交換機 leaf 交換機。服務(wù)器通過 leaf 交換機連接到網(wǎng)絡(luò)，leaf 之間不直連，而是通過 spine 交換機互相連接

Clos 拓撲在任何兩臺服務(wù)器之間都有兩條以上的路徑，產(chǎn)生了一個高容量網(wǎng)絡(luò)支持東西向流量。對比傳統(tǒng)網(wǎng)絡(luò)，Clos 架構(gòu)還有著很好的水平擴展性：

增加 leaf 交換機和服務(wù)器來擴展系統(tǒng)容量 增加 spine 交換機擴展帶寬

而“接入-匯聚-核心”只能換成性能更強的匯聚交換機來進行垂直擴展。

深入探討 Clos 架構(gòu)

1.Clos 架構(gòu)還有以下特性：

2.leaf、spine 可以使用同類、較小的交換機來構(gòu)建網(wǎng)絡(luò)

路由作為基本的互連模式

Clos 不使用STP，只在單個機架內(nèi)直接支持橋接，跨機架橋接使用更現(xiàn)代的網(wǎng)絡(luò)虛擬化解決方案(例如VXLAN)

3.Clos 收斂比

1:1 收斂比的網(wǎng)絡(luò)也稱為非阻塞網(wǎng)絡(luò)，即上行鏈路帶寬等于下行鏈路帶寬。如果 spine 和 leaf 都是 n 口交換機，1:1 收斂比的 Clos 拓撲可連接的大服務(wù)器數(shù)量為 n^2/2

4.鏈路速率

如果交換機鏈路使用比服務(wù)器鏈路更高的速率，則可以用更少的 spine 交換機來支持相同的收斂比

5.一些現(xiàn)實的限制

受到制冷、機柜、散熱、服務(wù)器擺放等限制，以上理論并不能原封不動落實到數(shù)據(jù)中心，單個機柜一般是20或40臺服務(wù)器。導(dǎo)致spine端口數(shù)量較多而leaf端口數(shù)量較少，設(shè)備廠商一般會提供不同的spine和leaf交換機

6.細粒度失效域

如果有兩個以上的 spine 交換機，單個鏈路故障不會帶來災(zāi)難 leaf 到 spine 的一條鏈路故障，其余部分仍可以繼續(xù)使用全部帶寬，故障影響范圍盡可能小 系統(tǒng)性的控制平面故障可能會影響整個網(wǎng)絡(luò)，但不會出現(xiàn)”接入-匯聚-核心“網(wǎng)絡(luò)中系統(tǒng)性故障(如廣播風(fēng)暴) 擴展 Clos 架構(gòu)

如果你想要構(gòu)建一個支持數(shù)萬或數(shù)十萬臺服務(wù)器的超大數(shù)據(jù)中心，還要拓展出三層 Clos 拓撲，如下圖所示，有兩種擴展方法：

虛擬機箱模型(Facebook)，對應(yīng)上圖(b) pod 模型(Microsoft、Amazon)，對應(yīng)上圖(c)

拓展后的三層 Clos 拓撲最上層交換機稱為“超級 spine 交換機”。

兩種模型的優(yōu)缺點對比：

考慮應(yīng)用與網(wǎng)絡(luò)模型匹配： 虛擬機箱模型均為5跳，適合運行單個應(yīng)用，故 Facebook 采用此模型; pod模型同一pod平均3跳，而到其他pod為5跳，適合提供云服務(wù)，故Microsoft 和 Amazon 采用模型; 考慮數(shù)據(jù)中心擴建，對于給定的容量兩種模型所需交換機數(shù)量相同，但： 虛擬機箱模型上兩層交換機數(shù)量必須滿足收斂比，還要提供足夠的 leaf 交換機 pod 模型如果開始流量都在 pod 內(nèi)部，可以先只部署較少的超級 spine 交換機 Clos 拓撲的影響和優(yōu)秀實踐

Clos 拓撲結(jié)構(gòu)帶來如下影響：

重新思考故障和排錯。交換機固定且單一，故障類型簡單，可以直接替換故障交換機 布線。Clos 拓撲需要管理大量線纜，可以使用線纜驗證技術(shù)：PTM 或 Ansible 來驗證線纜 固定樣式的交換機可以簡化庫存管理 由于存在大量交換機，不再可能手動配置網(wǎng)絡(luò)，網(wǎng)絡(luò)自動化必不可少

Clos 拓撲的一些優(yōu)秀實踐：

保持 spine-leaf 單鏈路，不要使用多個鏈路增加帶寬，而是添加更多 spine 或 leaf 來增加帶寬(例如：多個鏈路可能會導(dǎo)致 BGP 出錯)

spine 交換機只用于連接 leaf 節(jié)點，額外的工作會使spine交換機收到超過預(yù)定流量份額的流量(保持簡單是優(yōu)勢而不是劣勢) spine 和 leaf 使用同樣的盒式交換機，不要使用端口更多的框式交換機作為spine節(jié)點，原因：1、不好擴展成3層Clos;2、資產(chǎn)管理變得復(fù)雜;3、故障原因更復(fù)雜。

書中提到，LinkedIn 和 Dropbox 就后悔使用不一致的交換機。

名稱欄目：如何建設(shè)一個云原生數(shù)據(jù)中心的網(wǎng)絡(luò)？
轉(zhuǎn)載來于：http://www.muchs.cn/news21/202971.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、微信小程序、微信公眾號、電子商務(wù)、企業(yè)建站、虛擬主機

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)