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

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

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

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

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

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

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

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

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

1.單體應(yīng)用

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

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

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

3.Web 應(yīng)用

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

4.微服務(wù)

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

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

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

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

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

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

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

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

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

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

1.不可擴(kuò)展性

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

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

3.失效域(Failure Domain)。容易發(fā)生粗粒度的失效，比如：?jiǎn)蝹€(gè)鏈路的失效造成帶寬減半

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

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

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

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

Clos 拓?fù)?p>Clos 拓?fù)浣Y(jié)構(gòu)以其發(fā)明者 Charles Clos 命名，如下圖所示，該拓?fù)湟卜Q(chēng)為 leaf-spine 拓?fù)?或 spine-leaf 架構(gòu))。

上圖中：

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

Clos 拓?fù)湓谌魏蝺膳_(tái)服務(wù)器之間都有兩條以上的路徑，產(chǎn)生了一個(gè)高容量網(wǎng)絡(luò)支持東西向流量。對(duì)比傳統(tǒng)網(wǎng)絡(luò)，Clos 架構(gòu)還有著很好的水平擴(kuò)展性：

增加 leaf 交換機(jī)和服務(wù)器來(lái)擴(kuò)展系統(tǒng)容量 增加 spine 交換機(jī)擴(kuò)展帶寬

而“接入-匯聚-核心”只能換成性能更強(qiáng)的匯聚交換機(jī)來(lái)進(jìn)行垂直擴(kuò)展。

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

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

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

路由作為基本的互連模式

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

3.Clos 收斂比

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

4.鏈路速率

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

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

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

6.細(xì)粒度失效域

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

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

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

拓展后的三層 Clos 拓?fù)渥钌蠈咏粨Q機(jī)稱(chēng)為“超級(jí) spine 交換機(jī)”。

兩種模型的優(yōu)缺點(diǎn)對(duì)比：

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

Clos 拓?fù)浣Y(jié)構(gòu)帶來(lái)如下影響：

重新思考故障和排錯(cuò)。交換機(jī)固定且單一，故障類(lèi)型簡(jiǎn)單，可以直接替換故障交換機(jī) 布線。Clos 拓?fù)湫枰芾泶罅烤€纜，可以使用線纜驗(yàn)證技術(shù)：PTM 或 Ansible 來(lái)驗(yàn)證線纜 固定樣式的交換機(jī)可以簡(jiǎn)化庫(kù)存管理 由于存在大量交換機(jī)，不再可能手動(dòng)配置網(wǎng)絡(luò)，網(wǎng)絡(luò)自動(dòng)化必不可少

Clos 拓?fù)涞囊恍﹥?yōu)秀實(shí)踐：

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

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

書(shū)中提到，LinkedIn 和 Dropbox 就后悔使用不一致的交換機(jī)。

本文題目：如何建設(shè)一個(gè)云原生數(shù)據(jù)中心的網(wǎng)絡(luò)？
當(dāng)前路徑：http://bm7419.com/news/202971.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、企業(yè)建站、網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、企業(yè)網(wǎng)站制作、小程序開(kāi)發(fā)

廣告

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