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

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

之前的文章中，我們聊過分布式計算、存儲、協調等主題，唯獨網絡方面沒有談過。在《SRE：Google運維解密》中有一句令我影響深刻的話：“UNIX 系統內部細節和1～3層網絡知識是Google最看重的兩類額外的技術能力。”

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

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

為什么需要一個新的網絡架構

如果應用一層不變，那我們就沒有必要進行討論了。我們談云原生數據中心網絡，那這個架構就是要為現代云原生應用而設計的。所以，現代云原生應用有什么特點?

書中提到，“應用-網絡”架構的演進經歷了如下圖的四個階段。

1.單體應用

運行在大型機上 網絡流量小，協議是私有的

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

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

3.Web 應用

隨著計算能力不斷提高，CPU 性能過剩，應用開始運行在虛擬機中，Windows 成為主流，Linux還不夠成熟 千兆以太網成為企業網絡互聯標準

4.微服務

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

可見，分布式應用發生巨變，網絡被打了個措手不及。傳統網絡為什么“跟不上節奏”?

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

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

數據轉發芯片的出現，這種硬件技術最初僅支持橋接 企業專有的網絡軟件棧，除 IP 協議外還有別的協議 交換網絡零配置的承諾，路由網絡相對橋接網絡來說很難配置，而人為配置錯誤不是導致網絡故障的第一大原因，就是第二大原因

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

盡管傳統網絡取得很大成功，但橋接網絡依然有以下限制：

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

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

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

1.不可擴展性

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

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

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

4.不可預測性。許多組件會導致網絡變得不可預測，增加故障定位難度

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

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

云原生數據中心基礎設施想建立一個可大規模擴展的網絡架構，Clos 就是這個架構。

Clos 拓撲

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

上圖中：

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

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

增加 leaf 交換機和服務器來擴展系統容量 增加 spine 交換機擴展帶寬

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

深入探討 Clos 架構

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

2.leaf、spine 可以使用同類、較小的交換機來構建網絡

路由作為基本的互連模式

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

3.Clos 收斂比

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

4.鏈路速率

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

5.一些現實的限制

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

6.細粒度失效域

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

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

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

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

兩種模型的優缺點對比：

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

Clos 拓撲結構帶來如下影響：

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

Clos 拓撲的一些優秀實踐：

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

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

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

名稱欄目：如何建設一個云原生數據中心的網絡？
轉載來于：http://vcdvsql.cn/news21/202971.html

成都網站建設公司_創新互聯，為您提供商城網站、微信小程序、微信公眾號、電子商務、企業建站、虛擬主機

廣告

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