Wir haben ein Netzwerkdesign für Rechenzentren entwickelt, das die Bereitstellung von Rechenclustern mit mehr als 100.000 Servern und einer Spitzen-Bisection-Bandwidth von über einem Petabit pro Sekunde ermöglicht.
In Dmitri Afanasevs Bericht erfahren Sie die grundlegenden Prinzipien des neuen Designs, die Skalierung von Topologien, die dabei auftretenden Probleme, mögliche Lösungen sowie die Besonderheiten der Routenführung und der Skalierung der Funktionen des Forwarding-Planes moderner Netzwerkgeräte in dicht verbundenen Topologien mit einer hohen Anzahl an ECMP-Routen. Außerdem gibt Dima einen kurzen Überblick über die Organisation der externen Konnektivität, die physikalische Schicht, das Kabelsystem und Möglichkeiten zur weiteren Kapazitätserhöhung.
— Guten Tag zusammen! Mein Name ist Dmitri Afanasev, ich bin Netzwerkarchitekt bei Yandex und beschäftige mich hauptsächlich mit dem Design von Rechenzentrumsnetzwerken.
Ich werde über das aktualisierte Netzwerk der Yandex-Rechenzentren sprechen. Dies ist weitgehend eine Evolution des Designs, das wir zuvor hatten, aber es gibt auch einige neue Elemente. Dies ist eine Übersichtspräsentation, da viel Information in kurzer Zeit vermittelt werden musste. Wir beginnen mit der Auswahl der logischen Topologie. Dann folgt ein Überblick über den Control Plane und die Skalierbarkeitsprobleme des Data Plane, sowie die Auswahl der physischen Ebenen und einen Blick auf einige Eigenschaften der Geräte. Auch werden wir kurz die Entwicklungen im Rechenzentrum mit MPLS ansprechen, über das wir vor einiger Zeit gesprochen haben.
Was bedeutet Yandex in Bezug auf Lasten und Services? Yandex ist ein typischer Hyperscaler. Aus der Perspektive der Benutzer konzentrieren wir uns vor allem auf die Verarbeitung von Benutzeranfragen. Dazu kommen verschiedene Streaming-Dienste und die Bereitstellung von Daten, denn auch Storage-Dienste bieten wir an. Aus Sicht des Backends entstehen infrastrukturelle Lasten und Services, wie verteilte Objekt-Speichersysteme, Datenreplikation und natürlich persistente Warteschlangen. Einer der Hauptlasttypen ist MapReduce und ähnliche Systeme, Stream-Verarbeitung, Machine Learning usw.
Wie ist die Infrastruktur aufgebaut, auf der all das basiert? Auch wir sind ein typischer Hyperscaler, wenn auch vielleicht ein wenig näher an dem Punkt auf dem Spektrum, wo sich die kleineren Hyperscaler befinden. Dennoch besitzen wir alle erforderlichen Eigenschaften. Wir setzen auf Commodity-Hardware und horizontale Skalierung, wo immer es möglich ist. Bei uns gibt es einen vollumfänglichen Ressourcen-Pooling-Ansatz: Wir arbeiten nicht mit einzelnen Maschinen oder Racks, sondern bündeln sie in einen großen Pool austauschbarer Ressourcen, ergänzt durch zusätzliche Services, die für Planung und Zuweisung zuständig sind, um mit diesem Pool zu arbeiten.
So entsteht die nächste Ebene – das Betriebssystem eines Rechenzentrums. Es ist sehr wichtig, dass wir den gesamten Technologiestack, den wir verwenden, vollständig kontrollieren. Wir kontrollieren die Endpunkte (Hosts), das Netzwerk und den Software-Stacks.
Wir verfügen über mehrere große Rechenzentren in Russland und im Ausland. Diese sind durch ein Backbone verbunden, das auf MPLS-Technologie basiert. Unsere interne Infrastruktur ist nahezu vollständig auf IPv6 ausgelegt, jedoch müssen wir aufgrund des externen Traffics, der nach wie vor hauptsächlich über IPv4 erfolgt, sicherstellen, dass Anfragen, die über IPv4 eingehen, zum Frontend geliefert werden.Server, und wir müssen auch ein wenig im externen IPv4-Internet navigieren – zum Beispiel für das Crawlen.
In den letzten Iterationen des Designs von Rechenzentrumsnetzwerken wurden mehrschichtige Clos-Topologien verwendet, die ausschließlich L3 einsetzen. Wir haben uns seit einiger Zeit von L2 entfernt und sind erleichtert. Schließlich umfasst unsere Infrastruktur Hunderttausende von Recheninstanzen (Servern). Die maximale Clustergröße betrug vor einiger Zeit etwa 10.000 Server. Dies hängt stark mit den Betriebsystemen auf Clusterebene, den Scheduling-Tools und der Ressourcenallokation zusammen. Da es in der Infrastruktur-Software Fortschritte gegeben hat, ist die Zielgröße nun etwa 100.000 Server in einem Rechencluster, und wir stehen vor der Herausforderung, Netzwerkfabriken zu bauen, die eine effiziente Ressourcenzuteilung in solch einem Cluster ermöglichen.
Was erwarten wir von einem Rechenzentrumsnetzwerk? Zunächst einmal viel kostengünstige und relativ gleichmäßig verteilte Bandbreite. Denn das Netzwerk ist die Grundlage, auf der wir Ressourcen pooling durchführen können. Die neue Zielgröße liegt bei etwa 100.000 Servern in einem Cluster.
Natürlich wünschen wir uns auch einen skalierbaren und stabilen Control Plane, denn bei einer so umfangreichen Infrastruktur kann es schon von zufälligen Ereignissen zu erheblichen Problemen kommen. Wir möchten nicht zusätzlich durch den Control Plane belastet werden. Dabei streben wir an, den Zustand im Control Plane so gering wie möglich zu halten. Je weniger Zustand vorhanden ist, desto besser und stabiler läuft alles und die Diagnose wird einfacher.
Natürlich benötigen wir Automatisierung, denn eine manuelle Verwaltung einer solchen Infrastruktur ist unmöglich und das ist schon seit geraumer Zeit der Fall. Wir sind auf Unterstützung für den operativen Betrieb und CI/CD angewiesen, soweit dies möglich ist.
Angesichts der Größe der Rechenzentren und Cluster ist die Unterstützung für inkrementelle Bereitstellung und Erweiterung ohne Serviceunterbrechung ein zentrales Anliegen geworden. Bei Clustern mit einer Größe von etwa tausend Maschinen, möglicherweise nahe zehntausend Maschinen, ist es noch möglich, die Erweiterung als einen einzigen Vorgang durchzuführen — das heißt, wir planen die Infrastruktur zu erweitern und fügen mehrere Tausend Maschinen in einem Schritt hinzu. Bei einem Cluster mit fast hunderttausend Maschinen kommt es jedoch nicht sofort dazu; dieser wird über einen bestimmten Zeitraum hinweg aufgebaut. Es ist wünschenswert, dass während dieser Zeit die bereits implementierte Infrastruktur stets verfügbar bleibt.
Eine Anforderung, die wir hatten und die nun nicht mehr besteht, ist die Unterstützung von Multitenancy, also der Virtualisierung oder Segmentierung von Netzwerken. Jetzt müssen wir das nicht mehr auf Ebene der Netzwerkfabric machen, denn die Segmentierung findet auf den Hosts statt, was uns das Skalieren erheblich erleichtert. Dank IPv6 und des großen Adressraums mussten wir in der internen Infrastruktur keine doppelten Adressen verwenden; die gesamte Adressierung war ohnehin einzigartig. Da wir die Filterung und Segmentierung des Netzwerks auf die Hosts verlagert haben, müssen wir keine virtuellen Netzwerke in den Rechenzentrumsnetzen mehr erstellen.
Ein weiterer wichtiger Punkt ist, dass wir das nicht mehr benötigen. Wenn Funktionen aus dem Netzwerk entfernt werden können, erleichtert das das Leben erheblich und erweitert in der Regel die Auswahl an verfügbarer Hardware und Software, was die Diagnostik wesentlich vereinfacht.
Was ist also das, auf das wir verzichten konnten? Manchmal geschah das nicht ohne Widerwillen, aber nach Abschluss des Prozesses fühlten wir uns stark erleichtert.
Zunächst einmal verzichten wir auf L2. Wir benötigen kein reales oder emuliertes L2. Es wird kaum genutzt, da wir den Anwendungsstack kontrollieren. Unsere Anwendungen sind horizontal skalierbar und arbeiten mit L3-Adressen. Sie kümmern sich nicht sehr darum, dass eine bestimmte Instanz ausgefallen ist – einfach einen neuen bereitstellen, und dies muss nicht auf der alten Adresse geschehen, da es eine separate Ebene für Service Discovery und das Monitoring der im Cluster befindlichen Maschinen gibt. Wir übertragen diese Aufgabe nicht auf das Netzwerk. Die Aufgabe des Netzwerks ist es, Pakete von Punkt A nach Punkt B zu transportieren.
Bei uns gibt es auch keine Situationen, in denen Adressen innerhalb des Netzwerks verschoben werden müssen. In vielen Designs ist dies normalerweise erforderlich, um die Mobility von virtuellen Maschinen zu unterstützen. Wir nutzen die Mobilität virtueller Maschinen nicht in der internen Infrastruktur des großen Yandex und sind zudem der Meinung, dass, selbst wenn dies erforderlich ist, es ohne Netzwerkunterstützung nicht geschehen sollte. Sollte es absolut notwendig sein, sollte dies auf der Ebene der Hosts erfolgen, indem Adressen, die migrieren können, in Overlays platziert werden, um zu vermeiden, dass zu viele dynamische Änderungen im Routing-System des eigentlichen Underlay (Transportnetzwerk) vorgenommen werden.
Eine weitere Technologie, die wir nicht einsetzen, ist Multicast. Gerne kann ich dazu detailliert erklären, warum. Dies erleichtert vieles, denn wer sich damit beschäftigt hat und sieht, wie das Control Plane von Multicast aussieht – in sämtlichen Installationen, außer den einfachsten, ist es ein großes Problem. Darüber hinaus ist es schwierig, eine gut funktionierende Open-Source-Implementierung zu finden.
Und schließlich gestalten wir unsere Netzwerke so, dass sie nicht zu vielen Veränderungen unterworfen sind. Wir können darauf bauen, dass der Umfang externer Ereignisse im Routing-System gering ist.
Welche Probleme und Einschränkungen müssen wir berücksichtigen, wenn wir ein Rechenzentrumsnetzwerk entwerfen? Kosten, natürlich. Skalierbarkeit, bis zu welchem Maß wir wachsen wollen. Die Notwendigkeit, ohne Unterbrechungen des Dienstes erweitern zu können. Bandbreite, Verfügbarkeit. Die Sichtbarkeit dessen, was im Netzwerk geschieht, für Überwachungssysteme und Betriebsteams. Unterstützung von Automatisierung – wiederum so weit wie möglich, da unterschiedliche Aufgaben auf verschiedenen Ebenen gelöst werden können, einschließlich der Einführung zusätzlicher Abstraktionsebenen. Und nicht-[je nach Möglichkeit]-Abhängigkeit von Anbietern. Obwohl diese Unabhängigkeit je nach historischen Perioden und dem betrachteten Fokus leichter oder schwieriger erreichbar war. Wenn wir uns den Bereich von Netzwerkgerät-Chips ansehen, war es bis vor kurzem sehr bedingt möglich, von einer Unabhängigkeit von Anbietern zu sprechen, insbesondere wenn wir auch Chips mit hoher Bandbreite wollten.
Welche logische Topologie werden wir für unser Netzwerk verwenden? Es wird eine mehrstufige Clos-Topologie sein. Tatsächlich gibt es momentan nicht viele echte Alternativen. Und die Clos-Topologie ist ziemlich gut, selbst im Vergleich zu verschiedenen fortgeschrittenen Topologien, die derzeit eher akademisches Interesse hervorrufen, sofern wir Switches mit größerem Radix haben.
Wie ist ein mehrstufiges Clos-Netzwerk ungefähr aufgebaut und wie werden die verschiedenen Elemente darin benannt? Zunächst einmal die Himmelsrichtungen, um sich zu orientieren, wo Norden, Süden, Osten und Westen liegen. Netzwerke dieser Art werden normalerweise von denen aufgebaut, die sehr hohen Traffic in Richtung Westen und Osten haben. Was die anderen Elemente angeht, oben ist ein virtueller Switch dargestellt, der aus kleineren Switches zusammengesetzt ist. Das ist die Hauptidee des rekursiven Aufbaus von Clos-Netzen. Wir nehmen Elemente mit einem bestimmten Radix und verbinden sie so, dass das Ergebnis als Switch mit einem größeren Radix betrachtet werden kann. Wenn es noch mehr benötigt wird, kann der Vorgang wiederholt werden.
In Fällen wie bei zweistufigen Clos, wo die Komponenten klar in vertikalen Anordnungen zu erkennen sind, werden sie als Ebenen bezeichnet. Wenn wir ein Clos mit drei Ebenen von Spine-Switches (alle, die nicht grenzwertig oder ToR-Switches sind und die nur für den Transit verwendet werden) aufbauen würden, würden die Ebenen komplexer aussehen, während die zweistufigen genau so aussehen. Der Block der ToR- oder Leaf-Switches sowie die damit verbundenen Spine-Switches der ersten Ebene werden als Pod bezeichnet. Die Spine-Switches der Ebene Spine-1 ganz oben im Pod werden als Top of Pod, Spitze des Pods, bezeichnet. Die Switches, die sich an der Spitze der gesamten Fabrik befinden — sind die oberste Schicht der Fabrik, Top of Fabric.
Natürlich stellt sich die Frage: Clos-Netzwerke werden bereits seit einiger Zeit aufgebaut; die Idee stammt ursprünglich aus der klassischen Telefonie und TDM-Netzen. Gibt es vielleicht etwas Besseres, oder kann man es auf andere Weise verbessern? Ja und nein. Theoretisch ja, aber in der Praxis wird das in naher Zukunft definitiv nicht der Fall sein. Es gibt einige interessante Topologien; einige werden sogar im Produktiveinsatz verwendet, beispielsweise Dragonfly in HPC-Anwendungen. Es gibt auch interessante Topologien wie Xpander, FatClique und Jellyfish. Wenn man die Vorträge auf Konferenzen wie SIGCOMM oder NSDI in letzter Zeit betrachtet, entdeckt man eine Vielzahl von Arbeiten zu alternativen Topologien, die bestimmte Vorteile im Vergleich zu Clos bieten.
Aber all diese Topologien haben ein bemerkenswertes Merkmal: Es behindert ihre Einführung in die Rechenzentrumsnetze, die wir auf handelsüblicher Hardware aufbauen und die zu einem angemessenen Preis angeboten werden. In all diesen alternativen Topologien ist der Großteil der Bandbreite leider nicht über die kürzesten Pfade verfügbar. Daher verlieren wir sofort die Möglichkeit, den traditionellen Control-Plane zu nutzen.
Theoretisch ist die Lösung des Problems bekannt. Dies sind beispielsweise Modifikationen des Link-State-Protocols unter Verwendung von k-kürzesten Pfaden. Aber, wie gesagt, es gibt keine Protokolle, die in der Produktion implementiert und weit verbreitet auf Geräten verfügbar sind.
Darüber hinaus, da der Großteil der Kapazität nicht über die kürzesten Wege verfügbar ist, müssen wir nicht nur den Control-Plane modifizieren, damit er all diese Wege auswählt (und das ist übrigens ein erheblich umfangreicherer Zustand im Control-Plane). Wir müssen auch den Forwarding-Plane anpassen, und in der Regel sind mindestens zwei zusätzliche Funktionen erforderlich. Erstens die Fähigkeit, alle Entscheidungen über das Forwarding von Paketen gleichzeitig zu treffen, zum Beispiel auf einem Host. Tatsächlich handelt es sich hierbei um Source Routing, was in der Literatur über Interconnection Networks manchmal als All-at-once Forwarding Decisions bezeichnet wird. Und zusätzlich das adaptive Routing — das ist eine Funktion, die wir an den Netzwerkelementen benötigen, die beispielsweise darin besteht, dass wir den nächsten Hop basierend auf Informationen über die geringste Warteschlangenlast auswählen. Es gibt auch andere mögliche Optionen.
Somit ist die Richtung interessant, aber leider können wir sie im Moment nicht umsetzen.
Okay, wir haben uns also auf die logische Clos-Topologie geeinigt. Wie werden wir sie skalieren? Schauen wir uns an, wie sie aufgebaut ist und was wir tun können.
In einem Clos-Netzwerk gibt es zwei Hauptparameter, die wir variieren können, um unterschiedliche Ergebnisse zu erzielen: die Anzahl der Elemente und die Anzahl der Ebenen im Netzwerk. Ich habe schematisch dargestellt, wie beides die Größe beeinflusst. Idealerweise kombinieren wir beides.
Deutlich ist, dass die endgültige Breite des Clos-Netzes das Produkt aller Spinalschalter-Ebenen des südlichen Radix ist, sowie die Anzahl der Links nach unten, wie es sich verzweigt. So skalieren wir die Größe des Netzwerks.
In Bezug auf die Kapazität, insbesondere bei ToR-Switches, gibt es zwei Optionen zur Skalierung. Entweder können wir, während wir die Topologie beibehalten, schneller Links verwenden oder wir fügen mehr Ebenen hinzu.
Wenn wir uns die ausgeklappte Variante des Clos-Netzes (unten rechts) ansehen und zu diesem Bild der Clos-Topologie zurückkehren…
… dann ist das genau die gleiche Topologie, aber auf dieser Folie ist sie kompakter zusammengefasst und die Fabrikebenen sind übereinandergelegt. Es ist dasselbe.
Wie sieht die Skalierung eines Clos-Netzwerks in Zahlen aus? Hier finden Sie Daten darüber, welche maximale Bandbreite ein Netzwerk erreichen kann und wie viele Racks, ToR-Switches oder Leaf-Switches wir je nach Radix-Switches, die für die Spine-Ebenen verwendet werden, und wie viele Ebenen wir nutzen können, erhalten können.
Hier ist aufgeführt, wie viele Racks wir haben können, wie viele Server und ungefähr wie viel Strom wir bei einer Leistung von 20 kW pro Rack benötigen. Ich erwähnte zuvor, dass wir auf eine Clustergröße von etwa 100.000 Servern abzielen.
Es zeigt sich, dass in diesem Konstrukt zwei und ein halbes Szenario von Interesse sind. Es gibt eine Variante mit zwei Ebenen von Spine-Switches und 64-Port-Switches, die etwas hinter der Leistung zurückbleibt. Dann gibt es die hervorragend geeigneten Optionen für 128-Port-Spine-Switches mit zwei Ebenen oder Switches mit einem Radix von 32 mit drei Ebenen. In allen Fällen, in denen ein höherer Radix und mehr Ebenen vorhanden sind, kann ein sehr großes Netzwerk aufgebaut werden. Wenn man jedoch den erwarteten Verbrauch betrachtet, liegen die Zahlen in der Regel im Gigawattbereich. Die Verkabelung lässt sich umsetzen, doch so viel Strom auf einer Fläche werden wir kaum erhalten. Betrachtet man die Statistik, so gibt es in den öffentlichen Daten zu Rechenzentren sehr wenige Einrichtungen mit einer berechneten Leistung von mehr als 150 MW. Alles, was darüber hinausgeht, sind in der Regel Rechenzentrum-Campus, also mehrere große Rechenzentren, die relativ nah beieinander liegen.
Es gibt noch einen wichtigen Parameter. Wenn Sie sich die linke Spalte ansehen, finden Sie die nutzbare Bandbreite. Es ist nicht schwer zu erkennen, dass in Clos-Netzen ein erheblicher Teil der Ports dazu verwendet wird, die Switches miteinander zu verbinden. Die nutzbare Bandbreite ist das, was nach außen, zu den Servern, weitergegeben werden kann. Selbstverständlich spreche ich von den sogenannten Ports und genau von der Bandbreite. In der Regel sind die Links innerhalb des Netzwerks schneller als die Links zu den Servern, aber pro Einheit Bandbreite, die wir an unser Serverequipment weitergeben können, müssen wir auch einen Teil der Bandbreite innerhalb des Netzwerks berücksichtigen. Und je mehr Ebenen wir schaffen, desto mehr steigen die spezifischen Kosten, um diese Bandbreite nach außen bereitzustellen.
Darüber hinaus ist diese zusätzliche Bandbreite nicht ganz gleichmäßig. Solange die Strecken kurz sind, können wir etwas wie DAC (Direct Attach Copper, also Twinax-Kabel) oder Multimode-Optik verwenden, die noch relativ bezahlbar ist. Sobald wir jedoch zu längeren Strecken übergehen – in der Regel handelt es sich dabei um Single Mode-Optik – steigen die Kosten für diese zusätzliche Bandbreite deutlich an.
Und noch einmal, zurück zu der vorherigen Folie: Wenn wir ein Clos-Netzwerk ohne Überzeichnung erstellen, ist es einfach, das Diagramm zu betrachten und zu sehen, wie das Netzwerk aufgebaut ist. Indem wir jede Ebene von Spine-Switches hinzufügen, wiederholen wir die gesamte Bandbreite, die wir unten hatten. Jede Ebene fügt eine zusätzliche Bandbreite hinzu, die der auf der vorherigen Ebene entspricht, einschließlich der Ports auf den Switches und der Transceiver. Daher ist es äußerst wünschenswert, die Anzahl der Ebenen von Spine-Switches zu minimieren.
Aus diesem Bild geht hervor, dass wir unbedingt auf etwas wie Switches mit einem Radix von 128 aufbauen möchten.
Hier ist im Prinzip alles das Gleiche wie das, was ich gerade erklärt habe. Diese Folie dient eher als späterer Referenzpunkt.
Welche Optionen haben wir zur Auswahl für solche Switches? Es ist eine sehr erfreuliche Neuigkeit für uns, dass solche Netzwerke jetzt endlich mit Ein-Chip-Switches aufgebaut werden können. Das ist großartig, sie haben viele positive Eigenschaften. Zum Beispiel haben sie fast keine interne Struktur. Das bedeutet, dass sie einfacher kaputtgehen. Sie gehen kaputt, das lässt sich nicht vermeiden, aber glücklicherweise geschieht das komplett. Bei modularen Geräten gibt es viele (sehr unangenehme) Defekte, bei denen aus Sicht der Nachbarn und des Control Plane alles zu funktionieren scheint, aber beispielsweise ein Teil des Switches ausgefallen ist, und es nicht die volle Kapazität erreichen kann. Und der Traffic wird auf der Basis balanciert, dass es vollständig funktionsfähig ist, womit wir eine Überlastung riskieren können.
Oder zum Beispiel treten Probleme mit dem Backplane auf, da es im Inneren des modularen Geräts auch hochgradige SerDes gibt – die interne Struktur ist wirklich komplex. Es kann sein, dass die Tabellen zwischen den Forwarding-Elementen synchronisiert sind oder nicht. Insgesamt enthält ein leistungsstarkes modulares Gerät, das aus einer Vielzahl von Elementen besteht, in der Regel ein Clos-Netzwerk, das jedoch schwer zu diagnostizieren ist. Oft fällt es selbst dem Anbieter schwer, dies zu diagnostizieren.
Und es gibt eine Vielzahl von Fehlerszenarien, bei denen das Gerät degradiert, aber nicht vollständig aus der Topologie herausfällt. Da unser Netzwerk groß ist und aktiv die Last zwischen identischen Elementen verteilt wird, ist das Netzwerk sehr regelmäßig. Das bedeutet, dass ein Pfad, auf dem alles in Ordnung ist, sich nicht von einem anderen Pfad unterscheidet. Es ist für uns vorteilhafter, einfach einen Teil der Geräte aus der Topologie zu verlieren, als in die Situation zu geraten, in der einige von ihnen anscheinend funktionieren, während andere das nicht tun.
Ein weiterer angenehmer Vorteil von Ein-Chip-Geräten ist, dass sie schneller evolvieren. Ihre Kapazität ist in der Regel ebenfalls besser. Wenn wir uns die größeren Systeme anschauen, die wir haben, zeigt sich, dass die Kapazität pro Rack-Einheit bei gleichen Geschwindigkeiten fast doppelt so gut ist wie bei modularen Geräten. Geräte, die um einen einzigen Chip herum gebaut sind, sind deutlich günstiger als modulare Lösungen und verbrauchen weniger Energie.
Natürlich kommen auch Nachteile mit diesen Geräten. Erstens haben sie in der Regel einen deutlich geringeren Radix als modulare Geräte. Wenn wir ein Gerät mit 128 Ports um einen einzelnen Chip herum realisieren können, lässt sich ein modulares Gerät schon ohne große Probleme mit mehreren hundert Ports erstellen.
Dies ist eine deutlich geringere Größe der Forwarding-Tabellen und im Allgemeinen alles, was die Skalierbarkeit des Datenverkehrs betrifft. Flache Puffer. Und im Allgemeinen eine recht eingeschränkte Funktionalität. Es stellt sich jedoch heraus, dass es nicht so schlimm ist, wenn man sich dieser Einschränkungen bewusst ist und rechtzeitig Maßnahmen ergreift, um sie zu umgehen oder einfach zu berücksichtigen. Dass Radix kleiner ist, stellt mit den kürzlich erschienenen Geräten mit Radix 128 kein Problem mehr dar, wir können uns in zwei Schichten von Spines aufbauen. Und weniger als zwei können wir sowieso nichts Interessantes für unsere Größe aufbauen. Mit nur einer Ebene entstehen sehr kleine Cluster. Selbst unsere vorherigen Designs und Anforderungen haben sie immer noch übertroffen.
Falls die Lösung irgendwo an ihre Grenzen stößt, gibt es noch eine Möglichkeit zur Skalierung. Da die letzte (oder erste) und tiefste Ebene, an die die Server angeschlossen werden, die ToR-Switches oder Leaf-Switches sind, sind wir nicht verpflichtet, diese mit einem einzelnen Rack zu verbinden. Sollte die Lösung also in bestimmten Bereichen um das Doppelte hinterherhinken, könnte man in Erwägung ziehen, einfach einen Switch mit größerem Radix auf der untersten Ebene zu verwenden und beispielsweise zwei oder drei Racks an einen Switch anzuschließen. Das ist ebenfalls eine Option, die ihre eigenen Kosten hat, aber durchaus funktioniert und eine praktikable Lösung darstellen kann, wenn es nötig ist, die Größe in bestimmten Bereichen zu verdoppeln.
Zusammengefasst bauen wir ein zweistufiges Spine-Topologie-Modell mit acht Fabriksäulen auf.
Was wird aus der Physik? Es lassen sich sehr einfache Berechnungen anstellen. Wenn wir zwei Spine-Ebenen haben, haben wir insgesamt drei Ebenen von Switches. Wir erwarten, dass es im Netzwerk drei Kabelsegmente gibt: von den Servern zu den Leaf-Switches, zu Spine 1 und zu Spine 2. Die Optionen, die wir nutzen können, sind Twinax, Multimode und Single Mode. Hierbei müssen wir beachten, welche Bandbreite verfügbar ist, wie hoch die Kosten sind, welche physikalischen Abmessungen relevant sind, welche Entfernungen wir überbrücken können und wie wir upgradieren werden.
In Bezug auf die Kosten lässt sich alles in einer Reihe anordnen. Twinax-Kabel sind erheblich günstiger als aktive Optik, günstiger als Multimode-Transceiver, wenn man nach der Distanz am Ende geht, und etwas günstiger als ein 100-Gigabit-Port eines Switches. Und das ist interessant, denn es kostet weniger als Single-Mode-Optik, weil in den Rechenzentren aus mehreren Gründen bei Strecken, wo Single Mode erforderlich ist, oft CWDM sinnvoll eingesetzt wird. Die gleichzeitige Nutzung von Single Mode (PSM) ist nicht besonders praktisch, da man zu große Bündel von Fasern erhält, und wenn man bei diesen Technologien bleibt, ergibt sich eine Preihierarchie wie folgt.
Ein weiterer Punkt: Leider ist die Nutzung von aufgeteilten 100 auf 4x25 Multimode-Ports nicht ideal. Aufgrund der Konstruktion der SFP28-Transceiver liegen die Kosten nur geringfügig unter denen von QSFP28 für 100 Gbit. Außerdem funktioniert diese Aufteilung für Multimode nicht gut.
Ein weiteres Einschränkung ist, dass unsere Rechenzentren aufgrund der Größe der Rechencluster und der Anzahl der Server physisch großen Raum benötigen. Das bedeutet, dass mindestens ein Abschnitt mit Single-Mode durchgeführt werden muss. Auch aufgrund der physischen Größe der Pods ist es nicht möglich, zwei Abschnitte mit Twinax-Kabeln zu verlegen.
Insgesamt, wenn wir die Kosten optimieren und die Geometrie dieser Konstruktion berücksichtigen, erhalten wir einen Abschnitt mit Twinax, einen Abschnitt mit Multimode und einen Abschnitt mit Single-Mode unter Verwendung von CWDM. Dies berücksichtigt mögliche Upgrade-Pfade.
So könnte es aussehen, was kürzlich war, wohin wir gehen und was möglich ist. Es ist klar, wie wir in Richtung 50-Gigabit-SerDes für Multimode und Singlemode vorankommen können. Darüber hinaus, wenn man sich die derzeitigen Singlemode-Transceiver und die Perspektiven für 400G ansieht, stellt man oft fest, dass, selbst wenn 50G-SerDes von der elektrischen Seite kommen, die Optik bereits 100 Gbps pro Lane erreichen kann. Daher könnte es durchaus sein, dass anstelle eines Übergangs zu 50 ein Wechsel zu 100-Gigabit-SerDes und 100 Gbps pro Lane erfolgt, da viele Anbieter ihre Verfügbarkeit in naher Zukunft erwarten. Die Zeit, in der 50G-SerDes die schnellsten waren, scheint nicht sehr lang zu dauern, da die ersten Modelle der 100G-SerDes möglicherweise bereits im nächsten Jahr auf den Markt kommen. Und irgendwann nach dieser Einführung könnten sie möglicherweise zu einem vernünftigen Preis erhältlich sein.
Ein weiterer Aspekt bei der Auswahl der physikalischen Infrastruktur. Im Grunde können wir bereits jetzt 400- oder 200-Gigabit-Ports mit 50G SerDes verwenden. Allerdings stellt sich heraus, dass dies nicht besonders sinnvoll ist, denn wie ich bereits zuvor erklärt habe, wünschen wir einen ausreichend großen Radix auf den Switches, wobei dies im vernünftigen Rahmen bleiben sollte. Wir streben 128 an. Wenn jedoch die Kapazität des Chips begrenzt ist und wir die Linkgeschwindigkeit erhöhen, sinkt der Radix zwangsläufig – das ist keine Magie.
Die Gesamtkapazität können wir durch zusätzliche Ebenen erhöhen, wobei keine nennenswerten Kosten entstehen; die Anzahl der Ebenen kann einfach erhöht werden. Sollten wir jedoch den Radix verlieren, müssen wir eine zusätzliche Ebene einführen. Daher zeigt sich, dass es unter den aktuellen Bedingungen und der maximal verfügbaren Kapazität pro Chip effektiver ist, 100-Gigabit-Ports zu verwenden, da diese einen höheren Radix ermöglichen.
Die nächste Frage betrifft die physische Infrastruktur, diesmal aus der Perspektive der Kabelinfrastruktur. Dabei zeigt sich, dass sie auf eine interessante Weise organisiert ist. Die Verkabelung zwischen den Leaf-Switches und den First-Level-Spines ist nicht sehr komplex; alles ist relativ einfach strukturiert. Wenn wir jedoch eine Plane betrachten, muss man alle First-Level-Spines mit allen Second-Level-Spines verbinden.
Darüber hinaus gibt es in der Regel bestimmte Wünsche hinsichtlich des Aussehens im Rechenzentrum. Zum Beispiel haben wir großen Wert darauf gelegt, die Kabel in Bündel zu organisieren und so zu verlegen, dass ein Patchpanel mit hoher Dichte vollständig in ein anderes Patchpanel führt, um ein Durcheinander bei den Längen zu vermeiden. Wir konnten diese Herausforderung bewältigen. Wenn wir uns die logische Topologie zunächst anschauen, zeigen sich die Flächen als unabhängig, jede Fläche kann für sich selbst konstruiert werden. Doch wenn wir eine solche Bündelung hinzufügen und ein Patchpanel vollständig in ein anderes einführen wollen, müssen wir innerhalb eines Bündels verschiedene Flächen mischen und eine Zwischenkonstruktion in Form von optischen Cross-Connects einführen, um sie neu zu verpacken, so wie sie in einem Segment montiert wurden, hin zu der Art, wie sie in einem anderen Segment montiert werden. Dadurch erhalten wir einen angenehmen Vorteil: die gesamte komplexe Verkabelung bleibt innerhalb der Racks. Wenn es notwendig ist, etwas stark zu verdrahten oder die Flächen zu „entfalten“, wie es manchmal in Clos-Netzwerken genannt wird, konzentriert sich alles innerhalb eines Racks. Es gibt keine stark zerlegten Verkabelungen, bis hin zu individuellen Links, zwischen den Racks.
So sieht es aus, wenn man die logische Organisation der Kabelinfrastruktur betrachtet. Auf dem linken Bild sind farbige Blöcke dargestellt, die die ersten Level-Spine-Switch-Blöcke symbolisieren, jeweils acht Stück, und vier Kabelbündel, die von ihnen ausgehen und sich mit den Bündeln kreuzen, die von den Spine-2-Switch-Blöcken ausgehen.
Die kleinen Quadrate kennzeichnen die Schnittstellen. Oben links ist eine Erweiterung jeder dieser Schnittstellen zu sehen, es handelt sich tatsächlich um ein Cross-Connect-Modul mit 512 auf 512 Ports, das die Kabel so umpackt, dass sie vollständig in einem Rack ankommen, wo nur eine Ebene des Spine-2 vorhanden ist. Rechts ist eine etwas detailliertere Darstellung dieses Bildes, bezogen auf mehrere Pods auf der Ebene des Spine-1, und wie dies im Cross-Connect verpackt wird, wie es auf die Ebene des Spine-2 gelangt.
So sieht es aus: ein noch nicht vollständig montiertes Spine-2-Rack (links) und ein Cross-Connect-Rack. Leider ist dort nicht viel zu sehen. Diese gesamte Konstruktion wird gerade in einem unserer großen Rechenzentren, das erweitert wird, eingerichtet. Es ist ein laufender Prozess, es wird schöner aussehen und besser gefüllt sein.
Eine wichtige Frage: Wir haben die logische Topologie gewählt und die physische aufgebaut. Was passiert mit dem Control Plane? Aus den Erfahrungen im Betrieb ist gut bekannt, dass Link-State-Protokolle gut funktionieren und angenehm zu handhaben sind, allerdings skalieren sie bei dicht verkabelten Topologien schlecht. Ein entscheidender Faktor, der dies behindert, ist, wie das Flooding in Link-State-Protokollen funktioniert. Wenn man sich den Flooding-Algorithmus anschaut und unsere Netzwerkstruktur betrachtet, erkennt man, dass es in jedem Schritt zu einem sehr großen Fanout kommt, was dazu führt, dass das Control Plane mit Updates überflutet wird. Solche Topologien vertragen sich sehr schlecht mit dem traditionellen Flooding-Algorithmus in Link-State-Protokollen.
Die Wahl fällt auf die Verwendung von BGP. Wie man es korrekt einrichtet, wird in RFC 7938 über die Verwendung von BGP in großen Rechenzentren beschrieben. Die grundlegenden Ideen sind einfach: eine minimalistische Anzahl von Präfixen pro Host und generell eine minimale Anzahl von Präfixen im Netzwerk, sowie die Nutzung von Aggregation, wenn möglich, und die Unterdrückung von Path-Hunting. Wir streben eine sehr kontrollierte Verbreitung von Updates an, das nennt man valley free. Wir möchten, dass Updates, die durchs Netzwerk gehen, genau einmal ausgeführt werden. Wenn sie an einem Punkt entstehen, gehen sie nach oben und werden nicht mehr als einmal verteilt. Zickzackbewegungen sind zu vermeiden. Zickzackbewegungen sind äußerst ungünstig.
Um dies zu erreichen, verwenden wir ein recht einfaches Schema, um die grundlegenden Mechanismen von BGP zu nutzen. Das heißt, wir verwenden eBGP, das auf Link-Local operiert, und die autonomen Systeme werden wie folgt zugewiesen: ein autonomes System am ToR, ein autonomes System für den gesamten Block von Spine-1-Switches eines Pods und ein gemeinsames autonomes System für den gesamten Top of Fabric. Es ist nicht schwierig zu erkennen, dass selbst das normale Verhalten von BGP uns die gewünschte Verbreitung von Updates ermöglicht.
Natürlich muss die Adressierung und Aggregation so gestaltet werden, dass sie mit der Routing-Struktur kompatibel ist, um die Stabilität der Control Plane zu gewährleisten. Die L3-Adressierung im Transport ist an die Topologie gebunden, da ohne diese Aggregation nicht erreicht werden kann und individuelle Adressen sonst in das Routing-System eindringen. Ein weiterer Punkt ist, dass Aggregation leider nicht gut mit Multi-Path harmoniert, denn wenn wir Multi-Path und Aggregation haben, funktioniert alles gut, solange das gesamte Netzwerk in Betrieb ist und es keine Ausfälle gibt. Leider, sobald es im Netzwerk Störungen gibt und die Symmetrie der Topologie verloren geht, können wir an einen Punkt gelangen, von dem das Aggregat angekündigt wurde, von dem aus wir nicht weiter dorthin gelangen können, wo wir hin müssen. Deshalb ist es am besten, dort zu aggregieren, wo kein Multi-Path mehr vorhanden ist, in unserem Fall sind das die ToR-Switches.
Tatsächlich ist Aggregation möglich, erfordert jedoch Vorsicht. Wenn wir eine kontrollierte Deaggregation bei Netzwerkausfällen durchführen können. Aber das ist eine anspruchsvolle Aufgabe; wir haben sogar überlegt, ob es möglich ist, zusätzliche Automatisierung und endliche Automaten zu implementieren, die BGP korrekt anstoßen, um das gewünschte Verhalten zu erzielen. Leider ist die Verarbeitung von Sonderfällen sehr unklar und kompliziert, und die Anbindung externer Geräte an BGP löst dieses Problem nicht wirklich.
Eine sehr interessante Arbeit wurde in diesem Zusammenhang im Rahmen des RIFT-Protokolls geleistet, das im nächsten Vortrag behandelt wird.
Ein weiterer wichtiger Aspekt ist, wie der Datenverkehr in dichten Topologien skaliert, in denen es eine große Anzahl alternativer Pfade gibt. Hierbei werden mehrere zusätzliche Datenstrukturen verwendet: ECMP-Gruppen, die wiederum Gruppen von Next Hop beschreiben.
In einem stabilen Netzwerk, das ohne Unterbrechungen funktioniert, reicht es aus, nur eine Gruppe zu verwenden, wenn wir in der Clos-Topologie nach oben gehen, da alles, was nicht lokal ist, durch den Standard beschrieben wird. Wenn wir jedoch von oben nach unten in Richtung Süden gehen, sind alle nicht-ECMP-Pfade einfache Pfade. An sich ist das in Ordnung. Das Problem, und das Besondere an der klassischen Clos-Topologie ist, dass wenn wir auf die Spitze der Fabrik schauen, jeder Knoten genau einen Pfad zu jedem anderen Knoten unten hat. Wenn auf diesem Pfad Ausfälle auftreten, wird genau dieser Knoten oben in der Fabrik ungültig für die spezifischen Präfixe, die hinter dem defekten Pfad liegen. Für die anderen bleibt er gültig, und wir müssen die ECMP-Gruppen auflösen und einen neuen Zustand einführen.
Wie sieht die Skalierbarkeit von Data Plane auf modernen Geräten aus? Bei der Durchführung von LPM (Longest Prefix Match) funktioniert alles ziemlich gut, bei über 100.000 Präfixen. Wenn wir über Next Hop-Gruppen sprechen, sieht es jedoch schlechter aus, 2.000 bis 4.000. Für die Tabelle, die die Beschreibung der Next Hops (oder Adjacencies) enthält, liegt es irgendwo zwischen 16.000 und 64.000. Das kann ein Problem werden. Hier kommen wir zu einer interessanten Abweichung: Was ist mit MPLS in Rechenzentren passiert? Im Grunde genommen wollten wir es implementieren.
Es sind zwei Dinge passiert. Wir haben Mikrosementierung auf Hosts umgesetzt, wodurch es nicht mehr notwendig war, dies im Netzwerk durchzuführen. Die Unterstützung verschiedener Anbieter und insbesondere die offenen Implementierungen auf White Boxes mit MPLS waren nicht optimal. Zudem lässt sich MPLS, zumindest in seinen traditionellen Implementierungen, leider sehr schlecht mit ECMP kombinieren. Und genau das ist der Grund.
So sieht die Struktur des ECMP-Forwardings für IP aus. Eine große Anzahl an Präfixen kann dieselbe Gruppe und denselben Block Next Hops (oder Adjacencies; in unterschiedlichen Dokumentationen für verschiedene Geräte werden möglicherweise unterschiedliche Begriffe verwendet) nutzen. Der Sinn besteht darin, dass dies als ausgehender Port beschrieben wird und wie die MAC-Adresse umgeschrieben werden sollte, um den richtigen Next Hop zu erreichen. Für IP ist alles recht einfach; es können sehr viele Präfixe für dieselbe Gruppe und denselben Block Next Hops verwendet werden.
Die klassische MPLS-Architektur sieht vor, dass je nach ausgehendem Interface das Label auf unterschiedliche Werte umgeschrieben werden kann. Deshalb müssen wir für jede Eingangsmarke eine Gruppe und einen Block Next Hops bereitstellen. Und das lässt sich leider nicht skalieren.
Es ist nicht schwer zu erkennen, dass wir in unserer Konstruktion etwa 4000 ToR-Switches benötigten, mit einer maximalen Breite von 64 ECMP-Pfaden, wenn wir von Spine-1 in Richtung Spine-2 gehen. Wir quälen uns gerade so in eine ECMP-Gruppentabelle, falls nur ein Präfix mit ToR verschwindet, und wir passen überhaupt nicht in die Next Hops-Tabelle.
Es gibt Hoffnung, denn Architekturen wie Segment Routing beinhalten globale Labels. Formal könnte man all diese Next Hop-Blöcke wieder zusammenfassen. Dafür wäre eine Wild Card-Operation nötig: Ein Label zu nehmen und es ohne einen spezifischen Wert erneut zu schreiben. Leider ist dies in den verfügbaren Implementierungen nicht weit verbreitet.
Zu guter Letzt müssen wir externen Traffic ins Rechenzentrum bringen. Wie geht das? Früher wurde der Traffic von oben in Clos-Netze eingespeist. Das heißt, es gab Edge-Router, die an alle Geräte an der Top-of-Fabric angeschlossen waren. Diese Lösung funktioniert in kleinen und mittleren Größenordnungen recht gut. Leider erfordert es, um den Traffic symmetrisch in das gesamte Netzwerk einzuspeisen, dass wir gleichzeitig alle Elemente der Top-of-Fabric erreichen, und wenn es mehr als hundert werden, stellt sich heraus, dass wir auch große Radix für die Edge-Router benötigen. Das ist teuer, da Edge-Router funktionaler sind, und die Ports auf ihnen werden teurer sein, was zu einer nicht besonders eleganten Konstruktion führt.
Eine weitere Möglichkeit besteht darin, den Verkehr von unten zu generieren. Es lässt sich leicht erkennen, dass die Clos-Topologie so konstruiert ist, dass der von unten, also von der ToR-Seite kommende Verkehr gleichmäßig über die Ebenen des gesamten Top of Fabric verteilt wird, und zwar in zwei Iterationen, wodurch das gesamte Netzwerk ausgelastet wird. Daher führen wir einen speziellen Pod-Typ ein, den Edge Pod, der die externe Konnektivität gewährleistet.
Es gibt noch eine weitere Option. So handelt es beispielsweise Facebook. Dies wird dort als Fabric Aggregator oder HGRID bezeichnet. Es wird eine zusätzliche Spine-Ebene eingeführt, um mehrere Rechenzentren zu verbinden. Eine solche Konstruktion ist möglich, wenn wir an den Übergaben keine zusätzlichen Funktionen oder einen Wechsel der Kapselung haben. Wenn diese vorhanden sind, entstehen zusätzliche Touchpoints, was die Sache komplizierter macht. In der Regel gibt es mehr Funktionen und eine Art Membran, die verschiedene Teile des Rechenzentrums voneinander trennt. Eine solche Membran sollte nicht zu groß sein, aber wenn sie aus einem bestimmten Grund unbedingt benötigt wird, macht es Sinn, zu überlegen, ob man sie erweitern und so weit wie möglich auf die Hosts übertragen kann. Dies geschieht beispielsweise bei vielen Cloud-Anbietern. Sie haben Overlays, die bei den Hosts beginnen.
Welche Entwicklungsmöglichkeiten sehen wir? An erster Stelle steht die Verbesserung der Unterstützung für den CI/CD-Pipeline. Wir möchten so fliegen, wie wir testen, und so testen, wie wir fliegen. Das funktioniert derzeit nicht besonders gut, da die Infrastruktur groß ist und nicht für Tests dupliziert werden kann. Wir müssen herausfinden, wie wir Testelemente in die Produktionsinfrastruktur integrieren können, ohne deren Stabilität zu gefährden.
Besseres Monitoring und bessere Instrumentierung ist praktisch immer von Vorteil. Es geht darum, das richtige Gleichgewicht zwischen Aufwand und Nutzen zu finden. Wenn es möglich ist, dies mit vertretbarem Aufwand zu erreichen – umso besser.
Offene Betriebssysteme für Netzwerkgeräte. Die besten Protokolle und die besten Routing-Systeme, wie zum Beispiel RIFT. Zudem sind Forschungen zur Anwendung der besten Congestion-Control-Methoden erforderlich, und möglicherweise sollte in einigen Punkten die Unterstützung von RDMA innerhalb des Clusters eingeführt werden.
Wenn man an die weiterführende Zukunft denkt, sind fortschrittliche Topologien und möglicherweise Netzwerke erforderlich, die weniger Overhead nutzen. Neueste Veröffentlichungen behandeln die Technologie von Fabriken für HPC Cray Slingshot, die auf handelsüblichem Ethernet basiert, jedoch mit der Option, deutlich kürzere Header zu verwenden. Dadurch wird der Overhead verringert.
Alles sollte so einfach wie möglich, aber nicht einfacher gemacht werden. Komplexität ist der Feind der Skalierbarkeit. Einfachheit und regelmäßige Strukturen sind unsere Verbündeten. Wo immer möglich, skalieren Sie nach außen – tun Sie es. Und überhaupt, es ist großartig, sich mit Netzwerktechnologien zu beschäftigen. Es gibt viele interessante Entwicklungen. Danke.
Quelle: habr.com
