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

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

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

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

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

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

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

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

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

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

1.單體應用

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

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

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

3.Web 應用

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

4.微服務(wù)

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

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

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

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

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

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

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

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

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

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

1.不可擴展性

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

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

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

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

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

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

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

Clos 拓撲

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

上圖中：

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

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

• 增加 leaf 交換機和服務(wù)器來(lái)擴展系統容量
• 增加 spine 交換機擴展帶寬

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

深入探討 Clos 架構

1.Clos 架構還有以下特性：

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

路由作為基本的互連模式

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

3.Clos 收斂比

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

4.鏈路速率

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

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

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

6.細粒度失效域

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

擴展 Clos 架構

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

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

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

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

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

Clos 拓撲的影響和優(yōu)秀實(shí)踐

Clos 拓撲結構帶來(lái)如下影響：

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

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

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

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

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

原文鏈接：https://mp.weixin.qq.com/s/dCmv0SdXB-ZB1Ned9tYh4A