我們開發了一種資料中心網路設計，允許部署超過 100 萬台伺服器的運算集群，峰值二分頻寬超過每秒 XNUMX PB。
從 Dmitry Afanasyev 的報告中，您將了解新設計的基本原理、擴展拓撲、由此產生的問題、解決這些問題的選項、「密集連接」中現代網路設備的路由和擴展轉發平面功能的特性具有大量ECMP 路由的拓樸。此外，迪馬還簡要介紹了外部連接的組織、實體層、佈線系統以及進一步增加容量的方法。
- 大家午安！我叫 Dmitry Afanasyev，是 Yandex 的網路架構師，主要設計資料中心網路。
我的故事將是關於 Yandex 資料中心的更新網路。這在很大程度上是我們設計的演變，但同時也有一些新元素。這是一個概述演示，因為需要在很短的時間內包含大量資訊。我們將從選擇邏輯拓撲開始。然後將概述控制平面和資料平面可擴展性問題，選擇物理層級將發生的情況，並且我們將研究設備的一些功能。讓我們稍微了解一下使用 MPLS 的資料中心發生的情況，我們之前已經討論過。
那麼，Yandex 的負載和服務如何？ Yandex 是典型的超大規模供應商。如果我們看用戶，我們主要處理用戶請求。還有各種串流服務和資料傳輸，因為我們也有儲存服務。如果靠近後端，那麼基礎設施負載和服務就會出現在那裡，例如分散式物件儲存、資料複製，當然還有持久性佇列。主要的工作負載類型之一是MapReduce和類似的系統、串流處理、機器學習等。
發生這一切的基礎建設如何？同樣，我們是一個非常典型的超大規模企業，儘管我們可能更接近較小的超大規模企業。但我們擁有所有的屬性。我們盡可能使用商品硬體和水平擴展。我們擁有完整的資源池：我們不使用單獨的機器、單獨的機架，而是將它們組合成一個可互換資源的大型池，並提供一些處理規劃和分配的附加服務，並使用整個資源池。
所以我們有了下一個層級——計算叢集層級的作業系統。我們完全控制我們使用的技術堆疊非常重要。我們控制端點（主機）、網路和軟體堆疊。
我們在俄羅斯和國外擁有多個大型資料中心。它們透過使用 MPLS 技術的主幹網路連接在一起。我們的內部基礎設施幾乎完全建構在IPv6 上，但由於我們需要服務仍然主要透過IPv4 傳輸的外部流量，因此我們必須以某種方式將透過IPv4 傳輸的請求傳遞到前端伺服器，並將更多請求傳輸到外部IPv4-Internet - 用於例如，用於索引。
資料中心網路設計的最後幾次迭代使用了多層 Clos 拓撲，並且僅限於 L3。離開L2不久，我們鬆了一口氣。最後，我們的基礎設施包括數十萬個運算（伺服器）實例。前段時間叢集規模最大是10萬台伺服器左右。這主要是由於那些相同的叢集級作業系統、排程器、資源分配等如何運作。由於基礎設施軟體方面已經取得了進展，現在的目標規模是一個運算叢集中大約有 100 萬台伺服器，而我們有一個任務－能夠建構網路工廠，在這樣的叢集中實現高效率的資源池。
我們希望從資料中心網路得到什麼？首先，有大量廉價且分佈相當均勻的頻寬。因為網路是骨幹網，透過網路可以匯集資源。新的目標規模是一個叢集中大約有100萬台伺服器。
當然，我們也想要一個可擴展且穩定的控制平面，因為在如此龐大的基礎設施上，即使是簡單的隨機事件也會引起很多令人頭痛的問題，而且我們不希望控制平面也給我們帶來麻煩。同時，我們希望最小化其中的狀態。病情越小，一切就越好、越穩定，也越容易診斷。
當然，我們需要自動化，因為手動管理這樣的基礎設施是不可能的，而且已經有一段時間是不可能的了。我們需要盡可能多的營運支持，以及盡可能提供的 CI/CD 支援。
對於如此規模的資料中心和集群，支援增量部署和擴展而不中斷服務的任務變得相當緊迫。如果在一千台機器規模的集群上，也許接近一萬台機器，它們仍然可以作為一個操作來推出——也就是說，我們正在計劃擴展基礎設施，並且添加數千台機器作為一個操作，那麼十萬台機器規模的集群不會像這樣立即出現，它是經過一段時間建立起來的。我們希望一直以來已經抽出的東西、已經部署的基礎設施都應該可用。
我們曾經提出並留下的一項要求是：支援多租戶，即虛擬化或網路分段。現在我們不需要在網路結構層級執行此操作，因為分片已經轉移到主機，這使得擴充對我們來說非常容易。由於 IPv6 和龐大的位址空間，我們不需要在內部基礎設施中使用重複的位址；所有尋址都已經是唯一的。並且由於我們對主機進行了過濾和網路分段，因此我們不需要在資料中心網路中建立任何虛擬網路實體。
非常重要的一點是我們不需要什麼。如果可以從網路中刪除某些功能，那么生活就會變得更加輕鬆，並且通常會擴大可用設備和軟體的選擇範圍，從而使診斷變得非常簡單。
那麼，什麼是我們不需要的，什麼是我們能夠放棄的，在事情發生時並不總是充滿喜悅，但在過程完成時卻感到極大的寬慰？
首先，放棄L2。我們不需要 L2，無論是真實的還是模擬的。未使用主要是因為我們控制應用程式堆疊。我們的應用程式是水平可擴展的，它們使用L3尋址，它們不太擔心某些單獨的實例已經消失，它們只是推出一個新的實例，不需要在舊地址上推出，因為有一個位於集群中的機器的單獨級別的服務發現和監視。我們不會將此任務委託給網路。網路的工作是將封包從 A 點傳送到 B 點。
我們也不存在地址在網路內移動的情況，這需要進行監控。在許多設計中，這通常需要支援虛擬機器移動性。我們不會在大型 Yandex 的內部基礎架構中使用虛擬機器的移動性，而且，我們認為即使這樣做，也不應該在網路支援的情況下發生。如果確實需要這樣做，則需要在主機層級進行，並將可以遷移到覆蓋層的位址推送，以免對底層本身的路由系統（傳輸網路）進行接觸或進行太多動態變更。
我們不使用的另一種技術是多播。如果你願意的話，我可以詳細告訴你原因。這使生活變得更加容易，因為如果有人處理過它並準確地查看了多播控制平面的外觀，除了最簡單的安裝之外，這將是一個非常令人頭痛的問題。更重要的是，例如，很難找到功能良好的開源實作。
最後，我們設計我們的網絡，使其不會發生太大變化。我們可以相信，路由系統中的外部事件流很小。
我們在開發資料中心網路時會遇到哪些問題以及需要考慮哪些限制？當然是成本。可擴展性，我們想要成長到的水準。需要在不停止服務的情況下進行擴展。頻寬、可用性。監控系統和營運團隊可以了解網路上發生的情況。自動化支援——同樣，盡可能多，因為不同的任務可以在不同的層面上解決，包括引入額外的層。嗯，[可能]不依賴供應商。儘管在不同的歷史時期，取決於你看哪個部分，這種獨立性是更容易或更難實現的。如果我們看一下網路設備晶片的橫截面，那麼直到最近，如果我們也想要具有高吞吐量的晶片，那麼談論獨立於供應商是非常有條件的。
我們將使用什麼邏輯拓撲來建立我們的網路？這將是一個多層的 Clos。事實上，目前沒有真正的替代方案。如果我們有一個大的基數開關，即使與現在更受學術興趣的各種先進拓撲相比，Clos 拓撲也相當不錯。
多層 Clos 網路的大致結構是怎麼樣的？其中不同的元素分別是什麼？首先，風起，給自己定位哪裡是北，哪裡是南，哪裡是東，哪裡是西。這種類型的網路通常是由東西向流量非常大的網路建立的。至於其餘的元素，頂部則是由較小交換器組裝而成的虛擬交換器。這就是遞歸建構Clos網路的主要想法。我們採用某種基數的元素並將它們連接起來，這樣我們得到的東西就可以被認為是具有更大基數的開關。如果您需要更多，可以重複此過程。
例如，在使用兩級 Clos 的情況下，當可以清楚地識別圖中垂直的組件時，它們通常稱為平面。如果我們要建造一個具有三級骨幹交換機的 Clos（所有這些交換機都不是邊界或 ToR 交換機，僅用於傳輸），那麼平面會看起來更複雜；兩級交換機看起來就像這樣。我們將 ToR 塊或葉子交換器以及與它們關聯的第一級主幹交換器稱為 Pod。 Pod 頂部的 spin-1 等級的 Spine Switch 是 Pod 的頂部，即 Pod 的頂部。位於整個工廠最頂層的交換器是工廠的頂層，Top of Fabric。
當然，問題出現了：Clos 網路已經建立了一段時間；這個想法本身通常來自經典電話、TDM 網路時代。也許更好的事情已經出現，也許有些事情可以做得更好？是和不是。理論上是的，在不久的將來實踐中肯定不會。因為有很多有趣的拓撲，其中一些甚至在生產中使用，例如，Dragonfly 用於 HPC 應用程式；還有一些有趣的拓撲，例如 Xpander、FatClique、Jellyfish。如果您最近查看 SIGCOMM 或 NSDI 等會議上的報告，您會發現相當多的關於替代拓撲的工作，這些拓撲具有比 Clos 更好的屬性（一個或另一個）。
但所有這些拓撲都有一個有趣的特性。它阻止了它們在資料中心網路中的實施，我們正試圖在商品硬體上建立這些網絡，並且花費相當合理的資金。遺憾的是，在所有這些替代拓撲中，大部分頻寬無法透過最短路徑存取。因此，我們立即失去了使用傳統控制平面的機會。
理論上，問題的解決方案是已知的。例如，這些是使用 k-最短路徑修改鏈路狀態，但是，同樣，沒有這樣的協定可以在生產中實現並在設備上廣泛使用。
此外，由於大部分容量無法通過最短路徑訪問，因此我們需要修改的不僅僅是控制平面來選擇所有這些路徑（順便說一句，這在控制平面中明顯有更多狀態）。我們仍然需要修改轉送平面，並且通常至少需要兩個附加功能。這是一次性做出有關資料包轉送的所有決策的能力，例如在主機上。事實上，這就是來源路由，有時在互連網路的文獻中這被稱為一次性轉送決策。自適應路由是我們在網路元素上需要的功能，例如，歸結為我們根據佇列上最小負載的資訊選擇下一跳。作為範例，其他選項也是可能的。
因此，這個方向很有趣，但是，遺憾的是，我們現在還不能應用它。
好的，我們確定了 Clos 邏輯拓樸。我們將如何擴展它？讓我們看看它是如何工作的以及可以做什麼。
在 Clos 網路中，我們可以透過某種方式改變兩個主要參數並獲得某些結果：元素的基數和網路中的層數。我有一張示意圖，說明兩者如何影響尺寸。理想情況下，我們將兩者結合起來。
可以看出，Clos網路的最終寬度是南基數各級脊椎交換器的乘積，我們有多少個鏈路，它如何分支。這就是我們擴展網路規模的方式。
關於容量，特別是在 ToR 交換器上，有兩個擴充選項。我們可以在保持一般拓撲的同時使用更快的鏈路，或者可以添加更多平面。
如果你看一下 Clos 網路的擴展版本（在右下角）並回到下面這張 Clos 網路的圖片...
……那麼這是完全相同的拓撲，但在這張幻燈片上，它折疊得更緊湊，並且工廠的平面相互疊加。這是相同的。
從數字上看，Clos 網路的擴展是什麼樣的？在這裡，我提供了有關可以獲得的網絡最大寬度的數據，以及機架、ToR 交換器或葉子交換機的最大數量（如果它們不在機架中），我們可以獲得的數據取決於我們用於脊柱級別的交換器基數，以及我們使用了多少等級。
以下是我們可以擁有的機架數量、伺服器數量，以及基於每個機架 20 kW 計算的所有這些設備的大約消耗量。早些時候我提到我們的目標是叢集規模約 100 萬台伺服器。
可以看出，在整個設計中，有兩個半選項值得關注。有一個帶有兩層主幹和 64 埠交換器的選項，但有點不足。然後，還有適合兩級 128 連接埠（基數 128）主幹交換器或三級基數 32 交換器的完美選擇。在所有情況下，如果有更多的基數和更多的層，您可以建立一個非常大的網絡，但如果您考慮預期的消耗，通常有千兆瓦。鋪設電纜是可能的，但我們不太可能在一個地點獲得那麼多的電力。如果你查看資料中心的統計數據和公開數據，你會發現很少有資料中心的估計容量超過150兆瓦。較大的通常是資料中心園區，幾個大型資料中心彼此距離很近。
還有一個重要參數。如果您查看左欄，您會發現可用頻寬列在那裡。很容易看出，在 Clos 網路中，很大一部分連接埠用於將交換器相互連接。可用頻寬，即有用的頻寬，是可以向外部提供給伺服器的東西。當然，我談論的是條件端口，特別是頻段。通常，網路內的連結比通往伺服器的連結更快，但是對於每單位頻寬，只要我們可以將其發送到我們的伺服器設備，網路本身仍然有一些頻寬。我們製作的層數越多，向外部提供該條紋的具體成本就越大。
而且，即使是這個額外的頻帶也不完全相同。雖然跨度很短，但我們可以使用 DAC（直接連接銅纜，即雙芯電纜）或多模光學元件，這些元件的成本或多或少是合理的。一旦我們轉向更長的跨度 - 通常，這些都是單模光學元件，並且這種額外頻寬的成本會顯著增加。
再次回到上一張投影片，如果我們創建一個沒有超額訂閱的 Clos 網絡，那麼很容易查看圖表，了解網絡是如何構建的 - 添加每一級主幹交換機，我們重複位於底部。 Plus 等級 - 加上與上一級相同的頻段、交換器上相同數量的連接埠以及相同數量的收發器。因此，非常需要最小化主幹交換器的等級數量。
根據這張圖，很明顯我們確實希望建立基數為 128 的開關之類的東西。
這裡原則上和我剛才說的都是一樣的，這是一個幻燈片，供以後考慮。
我們可以選擇哪些選項作為此類開關？對我們來說，這是一個非常令人高興的消息，現在這樣的網路終於可以建立在單晶片交換器上。這非常酷，它們有很多不錯的功能。例如，它們幾乎沒有內部結構。這意味著它們更容易斷裂。它們以各種方式斷裂，但幸運的是它們完全斷裂。在模組化設備中，存在大量故障（非常令人不快），從鄰居和控制平面的角度來看，它似乎正在工作，但例如，部分結構已丟失並且無法工作滿載運轉。而它的流量是基於它功能齊全的事實來平衡的，我們可能會過載。
或者，例如，背板出現問題，因為模組化設備內部還有高速SerDes - 內部非常複雜。轉送單元之間的符號要麼同步，要麼不同步。一般來說，任何由大量元件組成的生產性模組化設備通常在其內部包含相同的 Clos 網絡，但診斷起來非常困難。通常，即使是供應商本身也很難診斷。
它有大量的故障場景，其中設備效能下降，但並未完全脫離拓撲。由於我們的網路很大，所以會積極使用相同元素之間的平衡，網路非常規則，也就是說，一條路徑上的一切都井然有序，與另一條路徑沒有什麼不同，對我們來說，簡單地失去一些元素會更有利可圖。拓撲中的設備，而不是最終陷入其中一些設備似乎可以工作，但有些設備卻不能工作的情況。
單晶片設備的下一個優點是它們發展得更好更快。他們也往往有更好的能力。如果我們將大型組裝結構圍成一圈，那麼相同速度的每個機架單元的連接埠容量幾乎是模組化設備的兩倍。圍繞單晶片構建的設備明顯比模組化設備便宜且消耗更少的能量。
但是，當然，這都是有原因的，也有缺點。首先，基數幾乎總是小於模組化設備的基數。如果我們能夠獲得一款圍繞一個晶片構建的具有 128 個端口的設備，那麼我們現在就可以毫無問題地獲得具有數百個端口的模組化設備。
這是轉發表的明顯較小的尺寸，並且通常與資料平面可擴展性相關的所有內容。淺緩衝區。而且，通常，功能相當有限。但事實證明，如果您了解這些限制並及時注意規避它們或只是將它們考慮在內，那麼這並不那麼可怕。事實上，基數更小的事實在最近終於出現的基數為 128 的設備上不再是問題；我們可以構建兩層脊柱。但仍然不可能建造出任何我們感興趣的小於兩個的東西。透過一級，可以獲得非常小的簇。甚至我們之前的設計和要求仍然超越了他們。
事實上，如果解決方案突然瀕臨崩潰，仍然有辦法擴展。由於連接伺服器的最後（或第一個）最低等級是 ToR 交換器或葉子交換機，因此我們不需要將一個機架連接到它們。因此，如果解決方案達不到一半左右，您可以考慮簡單地在較低層級使用基數較大的交換機，並將例如兩個或三個機架連接到一個交換機中。這也是一種選擇，它有其成本，但效果很好，當您需要達到大約兩倍的大小時，它可能是一個很好的解決方案。
總而言之，我們正在建造一個具有兩層主幹和八個工廠層的拓撲。
物理學會發生什麼事？非常簡單的計算。如果我們有兩級主幹，那麼我們只有三級交換機，我們預計網路中將存在三個電纜段：從伺服器到葉交換機、到主幹 1、到主幹 2。用途包括雙軸、多模、單模。在這裡，我們需要考慮哪些帶材可用、成本是多少、物理尺寸是多少、我們可以覆蓋的跨度以及我們將如何升級。
從成本上來說，一切都可以排隊。雙軸比主動光學器件便宜得多，比多模收發器便宜，如果您從末端每次飛行都使用它，比 100 Gb 交換器連接埠便宜一些。而且，請注意，它的成本低於單模光學器件，因為在需要單模的航班上，在資料中心，由於多種原因，使用CWDM 是有意義的，而並行單模(PSM) 工作起來不太方便獲得的纖維非常大，如果我們專注於這些技術，我們大約會得到以下價格等級。
另請注意：不幸的是，不太可能使用拆卸的 100 至 4x25 多模連接埠。由於SFP28收發器的設計特點，它並不比28 Gbit QSFP100便宜多少。而且這種針對多模的反組譯效果不太好。
另一個限制是，由於計算叢集的規模和伺服器的數量，我們的資料中心的實體規模很大。這意味著至少一次飛行必須使用單一模組完成。同樣，由於 Pod 的物理尺寸，無法運行兩個跨距的雙軸（銅纜）。
因此，如果我們優化價格並考慮到該設計的幾何形狀，我們將使用 CWDM 獲得一跨雙軸、一跨多模和一跨單模。這考慮了可能的升級路徑。
這就是最近的情況，我們的前進方向和可能性。至少，如何向多模和單模邁向 50 吉比特 SerDes 是很清楚的。此外，如果您看看現在和未來 400G 的單模收發器中的內容，通常即使 50G SerDes 從電氣側到達，每通道 100 Gbps 也已經可以進入光學。因此，很可能不會過渡到 50 個，而是過渡到 100 Gigabit SerDes 和每通道 100 Gbps，因為根據許多供應商的承諾，預計它們很快就會上市。 50G SerDes 最快的時期似乎不會很長，因為第一批 100G SerDes 幾乎將於明年推出。一段時間後，它們可能會值合理的錢。
關於物理選擇的另一個細微差別。原則上，我們已經可以使用 400G SerDes 來使用 200 或 50 個千兆埠。但事實證明這沒有多大意義，因為正如我之前所說，我們希望開關上有一個相當大的基數，當然這是在合理的範圍內。我們想要128。如果我們的晶片容量有限並且我們提高了鏈路速度，那麼基數自然會減小，沒有奇蹟。
我們可以使用飛機來增加總容量，並且沒有特殊成本；我們可以增加飛機的數量。如果我們失去了基數，我們將不得不引入一個額外的級別，因此在當前情況下，在每個晶片當前最大可用容量的情況下，事實證明使用 100 Gb 連接埠更有效，因為它們允許您以獲得更大的基數。
下一個問題是物理是如何組織的，但從電纜基礎設施的角度來看。事實證明，它的組織方式相當有趣。葉交換機和第一級主幹之間的佈線 - 那裡沒有太多鏈接，一切都構建得相對簡單。但如果我們採用一個平面，內部發生的情況是我們需要將第一層的所有脊椎與第二層的所有脊椎連接起來。
另外，通常，人們對資料中心內部的外觀有一些期望。例如，我們真的很想將電纜捆成一束，然後將它們拉起來，以便將一個高密度配線架完全納入一個配線架中，這樣就不會產生長度問題。我們設法解決了這個問題。如果您最初查看邏輯拓撲，您會發現各個平面是獨立的，每個平面都可以單獨建造。但是，當我們添加這樣的捆綁並希望將整個配線架拖入配線架時，我們必須將不同的平面混合在一個捆綁中，並引入光交叉連接形式的中間結構，以將它們從組裝方式重新包裝在一個網段上，如何在另一個網段上收集它們。因此，我們獲得了一個很好的功能：所有複雜的切換都不會超出機架。當您需要將某些東西非常牢固地交織在一起時，「展開平面」（有時在克洛斯網路中稱為「展開平面」），所有東西都集中在一個機架內。我們沒有高度拆卸、細化到單一連結、在機架之間進行切換。
這就是從電纜基礎設施的邏輯組織的角度來看的情況。在左圖中，彩色塊描繪了第一級主幹交換機塊，每塊八塊，以及來自它們的四束電纜，這些電纜與來自主幹 2 交換機塊的電纜束相交。 。
小方塊表示交叉點。左上角是每個此類交叉點的細分，這實際上是一個 512 x 512 連接埠交叉連接模組，它重新包裝電纜，使它們完全進入一個機架，其中只有一個 spin-2 平面。右邊這張圖的掃描更詳細一點，涉及到spine-1級別的幾個Pod，以及它是如何打包在交叉連接中的，如何到達spine-2級別的。
這就是它的樣子。尚未完全組裝的 spin-2 支架（左）和交叉連接支架。不幸的是，那裡沒什麼好看的。整個結構目前正在我們正在擴建的大型資料中心之一中部署。這是一項正在進行中的工作，它會看起來更好，也會填滿得更好。
一個重要的問題：我們選擇了邏輯拓樸並建構了物理結構。控制平面會發生什麼事？從操作經驗來看，有許多報告表明鏈路狀態協定很好，很高興與它們合作，但不幸的是，它們在密集連接的拓撲上不能很好地擴展。有一個主要因素可以防止這種情況發生——這就是鏈路狀態協定中洪氾的工作原理。如果您僅採用洪氾演算法並查看我們的網路結構，您會發現每一步都會有非常大的扇出，並且它只會用更新淹沒控制平面。具體來說，這種拓撲與鏈路狀態協定中的傳統洪氾演算法的混合非常差。
選擇是使用 BGP。關於在大型資料中心使用 BGP 的 RFC 7938 中描述如何正確準備。基本概念很簡單：每個主機的前綴數量最少，通常網路上的前綴數量最少，如果可能，使用聚合，並抑制路徑搜尋。我們想要非常仔細、非常受控的更新分發，這就是所謂的「Valley Free」。我們希望更新在通過網路時一次部署。如果它們起源於底部，它們就會上升，展開的次數不會超過一次。不應有鋸齒狀。鋸齒形非常糟糕。
為此，我們使用足夠簡單的設計來使用底層 BGP 機制。也就是說，我們使用運行在鏈路本地上的eBGP，自治系統分配如下：ToR上的自治系統，一個Pod的整個spine-1交換機塊上的自治系統，以及整個Top上的一般自治系統織物。不難看出，即使 BGP 的正常行為也能為我們提供所需的更新分發。
當然，尋址和位址聚合的設計必須與路由的建構方式相容，從而確保控制平面的穩定性。傳輸中的 L3 位址與拓樸緊密相關，因為如果沒有拓撲，就不可能實現聚合；否則，各個位址將滲入路由系統。不幸的是，另一件事是聚合與多路徑不能很好地混合，因為當我們有多路徑並且有聚合時，一切都很好，當整個網路健康時，其中不會出現故障。不幸的是，一旦網路中出現故障並且拓撲的對稱性丟失，我們就可以到達宣布該單元的點，從這裡我們無法進一步到達我們需要去的地方。因此，最好在沒有更多多路徑的地方進行聚合，在我們的例子中，這些是 ToR 交換器。
事實上，可以聚合，但要小心。如果我們能夠在網路故障發生時進行受控分解。但這是一項相當困難的任務，我們甚至想知道是否可以做到這一點，是否可以添加額外的自動化和有限狀態機來正確地啟動 BGP 以獲得所需的行為。不幸的是，處理極端情況非常不明顯且複雜，並且透過將外部附件附加到 BGP 並不能很好地解決此任務。
在 RIFT 協議框架內已經完成了這方面非常有趣的工作，這將在下一份報告中討論。
另一件重要的事情是資料平面如何在密集拓撲中擴展，在密集拓撲中我們有大量的替代路徑。在這種情況下，使用了幾個附加的資料結構：ECMP 組，它們依序描述下一跳組。
在正常工作的網路中，沒有故障的情況下，當我們上Clos拓撲時，只使用一組就足夠了，因為所有非本地的東西都默認描述了，我們就可以上去。當我們從上到下向南走時，所有路徑都不是 ECMP，它們是單一路徑路徑。一切都好。問題是，經典 Clos 拓撲的獨特之處在於，如果我們查看結構的頂部，在任何元素處，只有一條路徑可以到達下面的任何元素。如果沿著這條路徑發生故障，那麼工廠頂部的這個特定元素對於位於損壞路徑後面的那些前綴來說將變得無效。但對於其餘的它是有效的，我們必須解析 ECMP 組並引入一個新的狀態。
現代設備上的資料平面可擴展性是什麼樣的？如果我們進行 LPM（最長前綴匹配），一切都很好，超過 100k 前綴。如果我們談論的是下一跳組，那麼一切都會更糟，有 2-4 千個。如果我們討論的是包含下一跳（或鄰接）描述的表，則該值介於 16k 到 64k 之間。這可能會成為一個問題。這裡我們談到一個有趣的題外話：資料中心中的 MPLS 發生了什麼事？原則上，我們想這麼做。
發生了兩件事。我們在主機上進行了微分段；我們不再需要在網路上進行此操作。不同供應商的支援並不是很好，尤其是在帶有 MPLS 的白盒上開放實現。不幸的是，MPLS（至少其傳統實現）與 ECMP 的結合非常差。這就是原因。
這就是 IP 的 ECMP 轉送結構的樣子。大量前綴可以使用相同的群組和相同的下一跳區塊（或鄰接，這在不同裝置的不同文件中可能有不同的稱呼）。重點是，這被描述為傳出端口以及將 MAC 位址重寫到的端口，以便到達正確的下一跳。對於 IP，一切看起來都很簡單，您可以為同一組、同一下一躍點區塊使用大量前綴。
經典的MPLS架構意味著，根據傳出接口，標籤可以重寫為不同的值。因此，我們需要為每個輸入標籤保留一個群組和一個下一跳區塊。可惜的是，這無法擴充。
很容易看出，在我們的設計中，如果我們從脊椎 4000 轉向脊椎 64，我們需要大約 1 個 ToR 交換機，最大寬度為 2 個 ECMP 路徑。如果只有一個帶有 ToR 的前綴消失，我們幾乎無法進入一張 ECMP 群組表，而且我們根本無法進入下一跳表。
這並非全無希望，因為像分段路由這樣的架構涉及全域標籤。從形式上來說，有可能再次崩潰所有這些下一跳塊。為此，您需要一種通配符類型操作：取得一個標籤並將其重寫為相同的標籤，而無需特定值。但不幸的是，這在可用的實現中並不存在。
最後，我們需要將外部流量引入資料中心。怎麼做？此前，流量是從上方引入 Clos 網路的。也就是說，有邊緣路由器連接到結構頂部的所有設備。此解決方案適用於中小型尺寸。不幸的是，為了以這種方式將流量對稱地發送到整個網絡，我們需要同時到達所有結構頂部元素，並且當它們超過一百個時，事實證明我們還需要一個大的基數邊緣路由器。一般來說，這是要花錢的，因為邊緣路由器功能更多，其上的連接埠會更貴，而且設計也不是很美觀。
另一種選擇是從下面啟動此類流量。很容易驗證 Clos 拓撲的建構方式，即來自下方（即來自 ToR 側）的流量在兩次迭代中均勻分佈在整個結構頂部的各個層級之間，從而加載整個網路。因此，我們引入了一種特殊類型的 Pod，即 Edge Pod，它提供外部連接。
還有一種選擇。例如，Facebook 就是這麼做的。他們稱之為 Fabric Aggregator 或 HGRID。正在引入額外的主幹層級來連接多個資料中心。如果我們沒有額外的功能或介面處的封裝變化，這種設計是可能的。如果它們是額外的接觸點，那就很困難。通常，資料中心有更多的功能和一種分隔不同部分的膜。將這樣的膜做得很大是沒有意義的，但如果由於某種原因確實需要它，那麼考慮將其拿走、使其盡可能寬並將其轉移到宿主的可能性是有意義的。例如，許多雲端運營商就是這樣做的。他們有覆蓋層，他們從主機開始。
我們看到了哪些發展機會？首先，改進對 CI/CD 管道的支援。我們希望以我們測試的方式飛行並測試我們的飛行方式。這效果不太好，因為基礎設施很大，不可能複製它進行測試。您需要了解如何將測試元素引入生產基礎設施而不放棄它。
更好的儀器和更好的監控幾乎從來都不是多餘的。整個問題是努力和回報的平衡。如果你能透過合理的努力添加它，那就太好了。
網路設備的開放作業系統。更好的協定和更好的路由系統，例如 RIFT。還需要研究使用更好的擁塞控制方案，並可能至少在某些時候在叢集內引入 RDMA 支援。
展望未來，我們需要先進的拓撲，可能還需要使用更少開銷的網路。在新鮮事物中，最近有關於 HPC Cray Slingshot 結構技術的出版物，該技術基於商用以太網，但可以選擇使用更短的接頭。結果，減少了開銷。
一切都應該盡量簡單，但不能太簡單。複雜性是可擴展性的敵人。簡單和規則的結構是我們的朋友。如果你可以在某個地方進行橫向擴展，那就去做吧。總的來說，現在參與網路技術是一件很棒的事。有很多有趣的事情正在發生。謝謝。
來源： www.habr.com