Wir haben ein Netzwerkdesign für Rechenzentren entwickelt, das den Einsatz von Rechenclustern mit mehr als 100 Servern und einer Spitzenhalbierungsbandbreite von über einem Petabyte pro Sekunde ermöglicht.
Aus dem Bericht von Dmitry Afanasyev erfahren Sie mehr über die Grundprinzipien des neuen Designs, die Skalierung von Topologien, die damit verbundenen Probleme, Lösungsmöglichkeiten, die Merkmale des Routings und die Skalierung der Weiterleitungsebenenfunktionen moderner Netzwerkgeräte in „dicht verbundenen“ Netzwerken. Topologien mit einer großen Anzahl von ECMP-Routen. Darüber hinaus sprach Dima kurz über die Organisation der externen Konnektivität, die physikalische Schicht, das Verkabelungssystem und Möglichkeiten zur weiteren Kapazitätssteigerung.
- Guten Abend allerseits! Mein Name ist Dmitry Afanasyev, ich bin Netzwerkarchitekt bei Yandex und entwerfe hauptsächlich Rechenzentrumsnetzwerke.
In meiner Geschichte geht es um das aktualisierte Netzwerk der Yandex-Rechenzentren. Es ist eine Weiterentwicklung des Designs, das wir hatten, aber gleichzeitig gibt es einige neue Elemente. Dies ist eine Übersichtspräsentation, da viele Informationen in kurzer Zeit zusammengefasst werden mussten. Wir beginnen mit der Auswahl einer logischen Topologie. Dann gibt es einen Überblick über die Steuerungsebene und Probleme mit der Skalierbarkeit der Datenebene, eine Auswahl dessen, was auf der physischen Ebene passieren wird, und wir werden uns einige Funktionen der Geräte ansehen. Lassen Sie uns kurz darauf eingehen, was in einem Rechenzentrum mit MPLS passiert, worüber wir vor einiger Zeit gesprochen haben.
Was ist Yandex also in Bezug auf Lasten und Dienste? Yandex ist ein typischer Hyperscaler. Wenn wir auf die Nutzer schauen, bearbeiten wir in erster Linie Nutzeranfragen. Auch diverse Streaming-Dienste und Datenübertragung, da wir auch über Speicherdienste verfügen. Wenn es näher am Backend liegt, erscheinen dort Infrastrukturlasten und Dienste, wie z. B. verteilte Objektspeicherung, Datenreplikation und natürlich persistente Warteschlangen. Eine der Hauptarten von Workloads ist MapReduce und ähnliche Systeme, Stream-Verarbeitung, maschinelles Lernen usw.
Wie ist die Infrastruktur, auf der das alles passiert? Auch hier sind wir ein ziemlich typischer Hyperscaler, obwohl wir vielleicht etwas näher an der weniger hyperskalierenden Seite des Spektrums liegen. Aber wir haben alle Eigenschaften. Wir verwenden, wo immer möglich, handelsübliche Hardware und horizontale Skalierung. Wir verfügen über ein vollständiges Ressourcen-Pooling: Wir arbeiten nicht mit einzelnen Maschinen oder einzelnen Racks, sondern kombinieren sie zu einem großen Pool austauschbarer Ressourcen mit einigen zusätzlichen Diensten, die sich mit der Planung und Zuweisung befassen, und arbeiten mit diesem gesamten Pool.
Wir haben also die nächste Ebene – das Betriebssystem auf der Ebene des Computerclusters. Es ist sehr wichtig, dass wir den von uns verwendeten Technologie-Stack vollständig kontrollieren. Wir kontrollieren die Endpunkte (Hosts), das Netzwerk und den Software-Stack.
Wir verfügen über mehrere große Rechenzentren in Russland und im Ausland. Sie sind durch ein Backbone verbunden, das die MPLS-Technologie nutzt. Unsere interne Infrastruktur ist fast vollständig auf IPv6 aufgebaut, aber da wir externen Datenverkehr bedienen müssen, der immer noch hauptsächlich über IPv4 kommt, müssen wir Anfragen, die über IPv4 kommen, irgendwie an die Frontend-Server weiterleiten und etwas mehr an externes IPv4 – das Internet – gehen zum Beispiel zur Indizierung.
Die letzten paar Iterationen von Rechenzentrumsnetzwerkdesigns verwendeten mehrschichtige Clos-Topologien und basieren nur auf L3. Wir haben L2 vor einiger Zeit verlassen und atmeten erleichtert auf. Schließlich umfasst unsere Infrastruktur Hunderttausende Recheninstanzen (Serverinstanzen). Die maximale Clustergröße betrug vor einiger Zeit etwa 10 Server. Dies liegt vor allem daran, wie dieselben Betriebssysteme, Planer, Ressourcenzuweisungen usw. auf Clusterebene funktionieren können. Da auf der Seite der Infrastruktursoftware Fortschritte erzielt wurden, liegt die Zielgröße nun bei etwa 100 Servern in einem Rechencluster Wir haben die Aufgabe, Netzwerkfabriken aufzubauen, die eine effiziente Ressourcenbündelung in einem solchen Cluster ermöglichen.
Was erwarten wir von einem Rechenzentrumsnetzwerk? Erstens gibt es jede Menge günstige und einigermaßen gleichmäßig verteilte Bandbreite. Denn das Netzwerk ist das Rückgrat, über das wir Ressourcen bündeln können. Die neue Zielgröße liegt bei etwa 100 Servern in einem Cluster.
Natürlich wollen wir auch eine skalierbare und stabile Kontrollebene, denn in einer so großen Infrastruktur bereiten selbst einfache Zufallsereignisse große Probleme, und wir wollen nicht, dass uns auch die Kontrollebene Kopfschmerzen bereitet. Gleichzeitig wollen wir den Zustand darin minimieren. Je kleiner die Erkrankung, desto besser und stabiler funktioniert alles und desto einfacher ist die Diagnose.
Natürlich brauchen wir Automatisierung, denn es ist unmöglich, eine solche Infrastruktur manuell zu verwalten, und das ist schon seit einiger Zeit unmöglich. Wir benötigen so viel operative Unterstützung wie möglich und CI/CD-Unterstützung im Umfang, der bereitgestellt werden kann.
Bei solchen Größen von Rechenzentren und Clustern ist die Aufgabe, eine inkrementelle Bereitstellung und Erweiterung ohne Dienstunterbrechung zu unterstützen, sehr dringend geworden. Wenn auf Clustern mit einer Größe von tausend Maschinen, vielleicht fast zehntausend Maschinen, diese immer noch als ein Vorgang ausgerollt werden könnten – das heißt, wir planen eine Erweiterung der Infrastruktur und mehrere tausend Maschinen werden als ein Vorgang hinzugefügt, Dann entsteht ein Cluster in der Größe von hunderttausend Maschinen nicht sofort, sondern wird über einen längeren Zeitraum hinweg aufgebaut. Und es ist wünschenswert, dass das, was bereits abgepumpt wurde, die bereitgestellte Infrastruktur, die ganze Zeit über verfügbar ist.
Und eine Anforderung, die wir hatten und verließen: Unterstützung für Mandantenfähigkeit, also Virtualisierung oder Netzwerksegmentierung. Jetzt müssen wir dies nicht mehr auf der Ebene der Netzwerkstruktur tun, da das Sharding auf die Hosts verlagert wurde und dies die Skalierung für uns sehr einfach gemacht hat. Dank IPv6 und einem großen Adressraum mussten wir in der internen Infrastruktur keine doppelten Adressen verwenden; die gesamte Adressierung war bereits eindeutig. Und dank der Tatsache, dass wir Filterung und Netzwerksegmentierung auf die Hosts übertragen haben, müssen wir in Rechenzentrumsnetzwerken keine virtuellen Netzwerkeinheiten erstellen.
Eine sehr wichtige Sache ist, was wir nicht brauchen. Wenn einige Funktionen aus dem Netzwerk entfernt werden können, erleichtert dies das Leben erheblich und erweitert in der Regel die Auswahl an verfügbaren Geräten und Software, wodurch die Diagnose sehr einfach wird.
Was brauchen wir also nicht, worauf konnten wir verzichten, nicht immer mit Freude zu dem Zeitpunkt, als es geschah, aber mit großer Erleichterung, als der Prozess abgeschlossen war?
Zunächst einmal den Verzicht auf L2. Wir brauchen kein L2, weder real noch emuliert. Nicht verwendet, hauptsächlich aufgrund der Tatsache, dass wir den Anwendungsstapel kontrollieren. Unsere Anwendungen sind horizontal skalierbar, sie arbeiten mit L3-Adressierung, sie machen sich keine großen Sorgen, dass eine einzelne Instanz ausgefallen ist, sie führen einfach eine neue aus, es muss nicht an der alten Adresse ausgerollt werden, da es eine gibt Separate Serviceebene zur Erkennung und Überwachung der im Cluster befindlichen Maschinen. Wir delegieren diese Aufgabe nicht an das Netzwerk. Die Aufgabe des Netzwerks besteht darin, Pakete von Punkt A nach Punkt B zu übermitteln.
Es kommt auch nicht vor, dass sich Adressen innerhalb des Netzwerks bewegen und dies überwacht werden muss. In vielen Designs ist dies typischerweise erforderlich, um die VM-Mobilität zu unterstützen. Wir nutzen die Mobilität virtueller Maschinen in der internen Infrastruktur des großen Yandex nicht und sind außerdem der Meinung, dass dies selbst dann nicht mit Netzwerkunterstützung passieren sollte, wenn dies geschieht. Wenn Sie dies wirklich tun müssen, müssen Sie dies auf Host-Ebene tun und Adressen übertragen, die in Overlays migrieren können, um das Routing-System des Underlays selbst (Transportnetzwerk) nicht zu berühren oder zu viele dynamische Änderungen daran vorzunehmen. .
Eine weitere Technologie, die wir nicht verwenden, ist Multicast. Wenn Sie möchten, kann ich Ihnen im Detail erklären, warum. Das macht das Leben viel einfacher, denn wenn sich jemand damit beschäftigt hat und sich genau angeschaut hat, wie die Multicast-Kontrollebene bei allen außer den einfachsten Installationen aussieht, bereitet das große Kopfschmerzen. Darüber hinaus ist es beispielsweise schwierig, eine gut funktionierende Open-Source-Implementierung zu finden.
Schließlich gestalten wir unsere Netzwerke so, dass sie sich nicht zu sehr ändern. Wir können uns darauf verlassen, dass der Fluss externer Ereignisse im Routing-System gering ist.
Welche Probleme treten auf und welche Einschränkungen müssen beim Aufbau eines Rechenzentrumsnetzwerks berücksichtigt werden? Kosten natürlich. Skalierbarkeit, das Niveau, auf dem wir wachsen wollen. Die Notwendigkeit, zu expandieren, ohne den Dienst einzustellen. Bandbreite, Verfügbarkeit. Sichtbarkeit der Vorgänge im Netzwerk für Überwachungssysteme und Betriebsteams. Automatisierungsunterstützung – wiederum so weit wie möglich, da unterschiedliche Aufgaben auf unterschiedlichen Ebenen gelöst werden können, einschließlich der Einführung zusätzlicher Ebenen. Nun ja, [möglicherweise] nicht abhängig von Anbietern. Allerdings war diese Unabhängigkeit in verschiedenen historischen Epochen, je nachdem, welchen Abschnitt man betrachtet, einfacher oder schwieriger zu erreichen. Wenn wir einen Querschnitt der Netzwerkgeräte-Chips betrachten, dann war es bis vor Kurzem sehr bedingt, von Herstellerunabhängigkeit zu sprechen, wenn wir auch Chips mit hohem Durchsatz wollten.
Welche logische Topologie werden wir zum Aufbau unseres Netzwerks verwenden? Dabei handelt es sich um einen mehrstufigen Clos. Tatsächlich gibt es derzeit keine wirklichen Alternativen. Und die Clos-Topologie ist ziemlich gut, selbst im Vergleich zu verschiedenen fortgeschrittenen Topologien, die jetzt eher im Bereich des akademischen Interesses liegen, wenn wir große Basisschalter haben.
Wie ist ein mehrstufiges Clos-Netzwerk grob aufgebaut und wie heißen die verschiedenen Elemente darin? Zunächst einmal stieg der Wind, um sich zu orientieren, wo Norden, wo Süden, wo Osten und wo Westen ist. Netzwerke dieser Art werden in der Regel von Personen aufgebaut, die einen sehr großen West-Ost-Verkehr haben. Bei den übrigen Elementen befindet sich oben ein virtueller Schalter, der aus kleineren Schaltern zusammengesetzt ist. Dies ist die Hauptidee des rekursiven Aufbaus von Clos-Netzwerken. Wir nehmen Elemente mit einer Art Basis und verbinden sie, sodass das, was wir erhalten, als Schalter mit einer größeren Basis betrachtet werden kann. Sollten Sie noch mehr benötigen, kann der Vorgang wiederholt werden.
In Fällen, zum Beispiel bei Clos mit zwei Ebenen, in denen es möglich ist, in meinem Diagramm vertikale Komponenten eindeutig zu identifizieren, werden sie normalerweise als Ebenen bezeichnet. Wenn wir einen Clos mit drei Ebenen von Spine-Switches bauen würden (die alle keine Grenz- oder ToR-Switches sind und nur für den Transit verwendet werden), dann würden die Ebenen komplexer aussehen; die mit zwei Ebenen sehen genau so aus. Wir nennen einen Block von ToR- oder Leaf-Switches und die damit verbundenen Spine-Switches der ersten Ebene einen Pod. Spine-Schalter der Spine-1-Ebene an der Oberseite des Pods sind die Oberseite des Pods, die Oberseite des Pods. Die Schalter, die sich oben in der gesamten Fabrik befinden, bilden die oberste Schicht der Fabrik, die Stoffoberseite.
Da stellt sich natürlich die Frage: Clos-Netze gibt es schon seit längerem, die Idee selbst stammt in der Regel noch aus der Zeit der klassischen Telefonie, den TDM-Netzen. Vielleicht ist etwas Besseres aufgetaucht, vielleicht lässt sich etwas besser machen? Ja und nein. Theoretisch ja, in der Praxis in naher Zukunft definitiv nicht. Da es eine Reihe interessanter Topologien gibt, werden einige davon sogar in der Produktion eingesetzt, beispielsweise wird Dragonfly in HPC-Anwendungen eingesetzt; Es gibt auch interessante Topologien wie Xpander, FatClique, Jellyfish. Wenn Sie sich kürzlich Berichte auf Konferenzen wie SIGCOMM oder NSDI ansehen, können Sie eine ziemlich große Anzahl von Arbeiten zu alternativen Topologien finden, die (die eine oder andere) bessere Eigenschaften als Clos haben.
Aber alle diese Topologien haben eine interessante Eigenschaft. Es verhindert ihre Implementierung in Rechenzentrumsnetzwerken, die wir auf Standardhardware aufzubauen versuchen und die recht vernünftiges Geld kosten. In all diesen alternativen Topologien ist der Großteil der Bandbreite leider nicht über kürzeste Wege zugänglich. Daher verlieren wir sofort die Möglichkeit, die traditionelle Steuerungsebene zu verwenden.
Theoretisch ist die Lösung des Problems bekannt. Dabei handelt es sich beispielsweise um Änderungen des Verbindungsstatus unter Verwendung des k-kürzesten Pfads, aber auch hier gibt es keine derartigen Protokolle, die in der Produktion implementiert und auf Geräten allgemein verfügbar wären.
Da der Großteil der Kapazität nicht über kürzeste Pfade zugänglich ist, müssen wir außerdem mehr als nur die Steuerungsebene modifizieren, um alle diese Pfade auszuwählen (und das bedeutet übrigens deutlich mehr Status in der Steuerungsebene). Wir müssen die Weiterleitungsebene noch ändern und in der Regel sind mindestens zwei zusätzliche Funktionen erforderlich. Dies ist die Möglichkeit, alle Entscheidungen über die Paketweiterleitung einmalig, beispielsweise auf dem Host, zu treffen. Tatsächlich handelt es sich hierbei um Source Routing, in der Literatur zu Verbindungsnetzwerken wird dies manchmal als All-at-once-Forwarding-Entscheidungen bezeichnet. Und adaptives Routing ist eine Funktion, die wir auf Netzwerkelementen benötigen, was beispielsweise darauf hinausläuft, dass wir den nächsten Hop basierend auf Informationen über die geringste Belastung der Warteschlange auswählen. Beispielsweise sind auch andere Optionen möglich.
Daher ist die Richtung interessant, aber leider können wir sie derzeit nicht anwenden.
Okay, wir haben uns für die logische Clos-Topologie entschieden. Wie werden wir es skalieren? Mal sehen, wie es funktioniert und was getan werden kann.
In einem Clos-Netzwerk gibt es zwei Hauptparameter, die wir irgendwie variieren und bestimmte Ergebnisse erzielen können: die Basis der Elemente und die Anzahl der Ebenen im Netzwerk. Ich habe ein schematisches Diagramm, wie sich beide auf die Größe auswirken. Im Idealfall kombinieren wir beides.
Es ist ersichtlich, dass die endgültige Breite des Clos-Netzwerks das Produkt aller Ebenen der Spine-Switches des südlichen Radix ist, wie viele Links wir nach unten haben und wie es sich verzweigt. So skalieren wir die Größe des Netzwerks.
Hinsichtlich der Kapazität, insbesondere auf ToR-Switches, gibt es zwei Skalierungsoptionen. Entweder können wir unter Beibehaltung der allgemeinen Topologie schnellere Verbindungen verwenden oder wir können mehr Ebenen hinzufügen.
Wenn Sie sich die erweiterte Version des Clos-Netzwerks (in der unteren rechten Ecke) ansehen und zu diesem Bild mit dem Clos-Netzwerk unten zurückkehren ...
... dann ist das genau die gleiche Topologie, aber auf dieser Folie ist sie kompakter kollabiert und die Ebenen der Fabrik überlagern sich. Es ist das Gleiche.
Wie sieht die Skalierung eines Clos-Netzwerks in Zahlen aus? Hier stelle ich Daten darüber zur Verfügung, welche maximale Breite ein Netzwerk erhalten kann, wie viele Racks, ToR-Switches oder Leaf-Switches maximal sind, wenn sie sich nicht in Racks befinden, abhängig davon, welche Basis an Switches wir für Spine-Levels verwenden, und wie viele Ebenen wir verwenden.
Hier sehen Sie, wie viele Racks wir haben können, wie viele Server und wie viel das alles ungefähr verbrauchen kann, basierend auf 20 kW pro Rack. Ich habe bereits erwähnt, dass wir eine Clustergröße von etwa 100 Servern anstreben.
Es ist ersichtlich, dass bei diesem gesamten Entwurf zweieinhalb Optionen von Interesse sind. Es gibt eine Option mit zwei Schichten Spines und 64-Port-Switches, die etwas zu kurz kommt. Dann gibt es perfekt passende Optionen für 128-Port (mit Basis 128) Spine-Switches mit zwei Ebenen oder Switches mit Basis 32 mit drei Ebenen. Und in allen Fällen, in denen es mehr Radixe und mehr Schichten gibt, kann man ein sehr großes Netzwerk aufbauen, aber wenn man sich den erwarteten Verbrauch ansieht, sind es typischerweise Gigawatt. Es ist möglich, ein Kabel zu verlegen, aber wir werden wahrscheinlich nicht so viel Strom an einem Standort bekommen. Schaut man sich Statistiken und öffentliche Daten zu Rechenzentren an, findet man nur sehr wenige Rechenzentren mit einer geschätzten Kapazität von mehr als 150 MW. Bei den größeren handelt es sich in der Regel um Rechenzentrumscampusse, bei denen es sich um mehrere große Rechenzentren handelt, die ziemlich nahe beieinander liegen.
Es gibt noch einen weiteren wichtigen Parameter. Wenn Sie sich die linke Spalte ansehen, wird dort die nutzbare Bandbreite aufgeführt. Es ist leicht zu erkennen, dass in einem Clos-Netzwerk ein erheblicher Teil der Ports dazu verwendet wird, Switches miteinander zu verbinden. Nutzbare Bandbreite, ein nutzbarer Streifen, kann nach außen, den Servern hin, zur Verfügung gestellt werden. Natürlich spreche ich von bedingten Ports und insbesondere von der Band. In der Regel sind Verbindungen innerhalb des Netzwerks schneller als Verbindungen zu Servern, aber pro Bandbreiteneinheit, so viel wir an unsere Serverausrüstung senden können, steht im Netzwerk selbst immer noch etwas Bandbreite zur Verfügung. Und je mehr Ebenen wir erstellen, desto höher sind die spezifischen Kosten für die Bereitstellung dieses Streifens nach außen.
Darüber hinaus ist selbst dieses zusätzliche Band nicht genau dasselbe. Während die Spannweiten kurz sind, können wir etwas wie DAC (Direct-Attach-Kupferkabel, also Twinax-Kabel) oder Multimode-Optik verwenden, was sogar mehr oder weniger angemessenes Geld kostet. Sobald wir zu größeren Spannweiten übergehen – in der Regel handelt es sich dabei um Singlemode-Optiken – steigen die Kosten für diese zusätzliche Bandbreite merklich.
Und noch einmal, um zur vorherigen Folie zurückzukehren: Wenn wir ein Clos-Netzwerk ohne Überbelegung erstellen, ist es einfach, sich das Diagramm anzusehen und zu sehen, wie das Netzwerk aufgebaut ist. Durch Hinzufügen jeder Ebene von Spine-Switches wiederholen wir den gesamten Streifen, der vorhanden war unten. Plus-Level – plus das gleiche Band, die gleiche Anzahl an Switch-Ports wie auf dem vorherigen Level und die gleiche Anzahl an Transceivern. Daher ist es äußerst wünschenswert, die Anzahl der Ebenen von Spine-Switches zu minimieren.
Anhand dieses Bildes ist klar, dass wir wirklich auf so etwas wie Schalter mit einer Basis von 128 aufbauen wollen.
Hier ist im Prinzip alles das Gleiche wie das, was ich gerade gesagt habe; dies ist eine Folie zur späteren Betrachtung.
Welche Optionen gibt es, die wir als solche Schalter wählen können? Es ist für uns eine sehr erfreuliche Nachricht, dass solche Netzwerke nun endlich auf Single-Chip-Switches aufgebaut werden können. Und das ist sehr cool, sie haben viele nette Funktionen. Sie haben beispielsweise fast keine innere Struktur. Dadurch brechen sie leichter. Sie gehen auf alle möglichen Arten kaputt, aber glücklicherweise gehen sie komplett kaputt. Bei modularen Geräten gibt es eine große Anzahl von Fehlern (sehr unangenehm), wenn es aus Sicht der Nachbarn und der Steuerungsebene zu funktionieren scheint, aber beispielsweise ein Teil der Struktur verloren gegangen ist und nicht funktioniert bei voller Kapazität. Und der Verkehr dorthin ist aufgrund der Tatsache, dass es voll funktionsfähig ist, ausgeglichen und wir können überlastet werden.
Oder es treten zum Beispiel Probleme mit der Backplane auf, denn im Inneren des modularen Geräts stecken auch Hochgeschwindigkeits-SerDes – im Inneren ist es wirklich komplex. Entweder sind die Vorzeichen zwischen Weiterleitungselementen synchronisiert oder nicht synchronisiert. Im Allgemeinen enthält jedes produktive modulare Gerät, das aus einer großen Anzahl von Elementen besteht, in der Regel dasselbe Clos-Netzwerk in sich, die Diagnose ist jedoch sehr schwierig. Oftmals ist es sogar für den Verkäufer selbst schwierig, eine Diagnose zu stellen.
Und es gibt eine große Anzahl von Fehlerszenarien, bei denen das Gerät zwar schlechter wird, aber nicht vollständig aus der Topologie herausfällt. Da unser Netzwerk groß ist und der Ausgleich zwischen identischen Elementen aktiv genutzt wird, ist das Netzwerk sehr regelmäßig, das heißt, ein Pfad, auf dem alles in Ordnung ist, unterscheidet sich nicht vom anderen Pfad, es ist für uns rentabler, einfach etwas davon zu verlieren die Geräte aus der Topologie, als in eine Situation zu geraten, in der einige von ihnen zu funktionieren scheinen, andere jedoch nicht.
Das nächste nette Merkmal von Single-Chip-Geräten ist, dass sie sich besser und schneller weiterentwickeln. Sie haben tendenziell auch eine bessere Kapazität. Wenn wir die großen zusammengebauten Strukturen, die wir auf einem Kreis haben, nehmen, ist die Kapazität pro Rackeinheit für Ports gleicher Geschwindigkeit fast doppelt so gut wie bei modularen Geräten. Geräte, die auf einem einzigen Chip basieren, sind deutlich günstiger als modulare und verbrauchen weniger Energie.
Aber das hat natürlich alles seinen Grund, es gibt auch Nachteile. Erstens ist die Basis fast immer kleiner als die von modularen Geräten. Wenn wir ein Gerät bekommen, das um einen Chip mit 128 Ports herum aufgebaut ist, dann können wir jetzt problemlos ein modulares Gerät mit mehreren hundert Ports bekommen.
Dies ist eine deutlich geringere Größe der Weiterleitungstabellen und in der Regel alles, was mit der Skalierbarkeit der Datenebene zusammenhängt. Flache Puffer. Und in der Regel eher eingeschränkte Funktionalität. Es stellt sich jedoch heraus, dass dies nicht so beängstigend ist, wenn Sie diese Einschränkungen kennen und rechtzeitig darauf achten, sie zu umgehen oder einfach zu berücksichtigen. Dass die Radix kleiner ist, ist bei Geräten mit einer Radix von 128, die nun endlich erschienen sind, kein Problem mehr; wir können zwei Lagen Spines einbauen. Aber es ist immer noch unmöglich, etwas zu bauen, das kleiner als zwei ist und für uns interessant ist. Mit einer Ebene werden sehr kleine Cluster erhalten. Selbst unsere bisherigen Entwürfe und Anforderungen übertrafen sie noch.
Wenn die Lösung plötzlich irgendwo auf der Kippe steht, gibt es tatsächlich immer noch eine Möglichkeit zur Skalierung. Da die letzte (oder erste) unterste Ebene, auf der Server verbunden sind, ToR-Switches oder Leaf-Switches sind, ist es nicht erforderlich, ein Rack mit ihnen zu verbinden. Wenn die Lösung also um etwa die Hälfte zu kurz kommt, kann man darüber nachdenken, einfach einen Switch mit großer Basis auf der unteren Ebene zu verwenden und beispielsweise zwei oder drei Racks zu einem Switch zu verbinden. Auch das ist eine Option, sie ist mit Kosten verbunden, funktioniert aber recht gut und kann eine gute Lösung sein, wenn Sie etwa die doppelte Größe erreichen müssen.
Zusammenfassend lässt sich sagen, dass wir auf einer Topologie mit zwei Spine-Ebenen und acht Factory-Schichten aufbauen.
Was passiert mit der Physik? Sehr einfache Berechnungen. Wenn wir zwei Ebenen von Spines haben, dann haben wir nur drei Ebenen von Switches, und wir gehen davon aus, dass es drei Kabelsegmente im Netzwerk geben wird: von Servern zu Leaf-Switches, zu Spine 1 und zu Spine 2. Die Optionen, die wir haben Verwendung finden - das sind Twinax, Multimode, Singlemode. Und hier müssen wir überlegen, welches Band verfügbar ist, wie viel es kosten wird, welche Abmessungen es hat, welche Spannweiten wir abdecken können und wie wir es aufrüsten werden.
Kostentechnisch lässt sich alles vereinbaren. Twinaxes sind deutlich günstiger als aktive Optiken, günstiger als Multimode-Transceiver, wenn man es pro Flug vom Ende her betrachtet, etwas günstiger als ein 100-Gigabit-Switch-Port. Und bitte beachten Sie, dass es weniger kostet als Single-Mode-Optiken, denn auf Flügen, bei denen Single-Mode erforderlich ist, ist es in Rechenzentren aus mehreren Gründen sinnvoll, CWDM zu verwenden, während Parallel-Single-Mode (PSM) nicht sehr bequem zu arbeiten ist Dabei werden Fasern in sehr großen Packungen gewonnen, und wenn wir uns auf diese Technologien konzentrieren, erhalten wir ungefähr die folgende Preishierarchie.
Noch ein Hinweis: Leider ist es kaum möglich, zerlegte 100- bis 4x25-Multimode-Ports zu verwenden. Aufgrund der Designmerkmale von SFP28-Transceivern ist es nicht viel günstiger als 28 Gbit QSFP100. Und diese Demontage für Multimode funktioniert nicht sehr gut.
Eine weitere Einschränkung besteht darin, dass unsere Rechenzentren aufgrund der Größe der Rechencluster und der Anzahl der Server physisch groß ausfallen. Das bedeutet, dass mindestens ein Flug mit einem Singlemod durchgeführt werden muss. Auch hier ist es aufgrund der physischen Größe der Pods nicht möglich, zwei Abschnitte von Twinax-Kabeln (Kupferkabeln) zu verlegen.
Wenn wir also den Preis optimieren und die Geometrie dieses Designs berücksichtigen, erhalten wir mit CWDM eine Spanne Twinax, eine Spanne Multimode und eine Spanne Singlemode. Dabei werden mögliche Upgrade-Pfade berücksichtigt.
So sieht es in letzter Zeit aus, wohin die Reise geht und was möglich ist. Es ist zumindest klar, wie der Übergang zu 50-Gigabit-SerDes sowohl für Multimode als auch für Singlemode erfolgen soll. Wenn man sich außerdem anschaut, was jetzt und in Zukunft in Singlemode-Transceivern für 400G steckt, können oft bereits 50 Gbit/s pro Spur in die Optik fließen, selbst wenn 100G-SerDes von der elektrischen Seite eintreffen. Daher ist es durchaus möglich, dass statt auf 50 ein Übergang auf 100 Gigabit SerDes und 100 Gbit/s pro Lane erfolgt, da nach den Versprechungen vieler Anbieter mit deren Verfügbarkeit recht bald zu rechnen ist. Der Zeitraum, in dem 50G-SerDes die schnellsten waren, wird offenbar nicht sehr lange dauern, da die ersten Exemplare von 100G-SerDes fast nächstes Jahr auf den Markt kommen. Und nach einiger Zeit werden sie wahrscheinlich ein angemessenes Geld wert sein.
Noch eine Nuance zur Wahl der Physik. Prinzipiell können wir mit 400G SerDes bereits 200 oder 50 Gigabit-Ports nutzen. Aber es stellt sich heraus, dass das wenig Sinn macht, denn wie ich bereits sagte, wollen wir eine ziemlich große Basis für die Schalter, natürlich im Rahmen des Zumutbaren. Wir wollen 128. Und wenn wir eine begrenzte Chipkapazität haben und die Verbindungsgeschwindigkeit erhöhen, dann nimmt die Basis natürlich ab, es gibt keine Wunder.
Und wir können die Gesamtkapazität durch den Einsatz von Flugzeugen erhöhen, und es fallen keine Sonderkosten an; wir können die Anzahl der Flugzeuge hinzufügen. Und wenn wir den Kern verlieren, müssen wir eine zusätzliche Ebene einführen. In der aktuellen Situation mit der derzeit maximal verfügbaren Kapazität pro Chip stellt sich heraus, dass es effizienter ist, 100-Gigabit-Ports zu verwenden, weil sie es ermöglichen um eine größere Wurzel zu bekommen.
Die nächste Frage ist, wie die Physik organisiert ist, allerdings aus der Sicht der Kabelinfrastruktur. Es stellt sich heraus, dass es ziemlich lustig organisiert ist. Verkabelung zwischen Leaf-Switches und First-Level-Spines – dort gibt es nicht viele Verbindungen, alles ist relativ einfach aufgebaut. Aber wenn wir eine Ebene nehmen, passiert im Inneren, dass wir alle Stacheln der ersten Ebene mit allen Stacheln der zweiten Ebene verbinden müssen.
Außerdem gibt es in der Regel Wünsche, wie es im Inneren des Rechenzentrums aussehen soll. Wir wollten zum Beispiel die Kabel unbedingt zu einem Bündel zusammenfassen und so ziehen, dass ein Patchfeld mit hoher Dichte vollständig in ein Patchfeld passt, sodass es hinsichtlich der Längen keinen Zoo gibt. Es ist uns gelungen, dieses Problem zu lösen. Schaut man sich zunächst die logische Topologie an, sieht man, dass die Ebenen unabhängig sind, jede Ebene kann für sich aufgebaut werden. Wenn wir jedoch eine solche Bündelung hinzufügen und das gesamte Patchfeld in ein Patchfeld ziehen möchten, müssen wir verschiedene Ebenen innerhalb eines Bündels mischen und eine Zwischenstruktur in Form von optischen Querverbindungen einführen, um sie aus der Art, wie sie zusammengebaut wurden, neu zu packen auf einem Segment, wie sie auf einem anderen Segment gesammelt werden. Dadurch erhalten wir ein nettes Feature: Alle komplexen Schaltvorgänge gehen nicht über die Racks hinaus. Wenn Sie etwas sehr stark verflechten müssen, „die Ebenen entfalten“, wie es in Clos-Netzwerken manchmal genannt wird, ist alles in einem Rack konzentriert. Wir haben keine stark zerlegten, bis hin zu einzelnen Gliedern, Wechsel zwischen Racks.
So sieht es aus Sicht der logischen Organisation der Kabelinfrastruktur aus. Im Bild links stellen die mehrfarbigen Blöcke Blöcke von Spine-Switches der ersten Ebene dar, jeweils acht Stück, und vier von ihnen ausgehende Kabelbündel, die sich mit den Bündeln kreuzen, die von den Blöcken von Spine-2-Switches ausgehen .
Kleine Quadrate markieren Kreuzungen. Oben links ist eine Aufschlüsselung jeder dieser Kreuzungen zu sehen. Dabei handelt es sich tatsächlich um ein Cross-Connect-Modul mit 512 x 512 Ports, das die Kabel so umpackt, dass sie vollständig in einem Rack zusammenkommen, in dem es nur eine Spine-2-Ebene gibt. Und auf der rechten Seite ist ein Scan dieses Bildes etwas detaillierter in Bezug auf mehrere Pods auf der Spine-1-Ebene und wie es in einem Cross-Connect verpackt ist und wie es zur Spine-2-Ebene kommt.
So sieht es aus. Der noch nicht fertig montierte Spine-2-Ständer (links) und der Cross-Connect-Ständer. Leider gibt es dort nicht viel zu sehen. Diese gesamte Struktur wird derzeit in einem unserer großen Rechenzentren bereitgestellt, das erweitert wird. Das ist noch in Arbeit, es wird schöner aussehen und besser ausgefüllt sein.
Eine wichtige Frage: Wir haben die logische Topologie gewählt und die Physik aufgebaut. Was passiert mit der Kontrollebene? Aus der Betriebserfahrung ist es ziemlich gut bekannt, dass es eine Reihe von Berichten gibt, dass Link-State-Protokolle gut sind, es eine Freude ist, mit ihnen zu arbeiten, aber leider lassen sie sich nicht gut auf eine dicht verbundene Topologie skalieren. Und es gibt einen Hauptfaktor, der dies verhindert: So funktioniert Flooding in Link-State-Protokollen. Wenn Sie einfach den Flooding-Algorithmus nehmen und sich die Struktur unseres Netzwerks ansehen, können Sie sehen, dass es bei jedem Schritt zu einem sehr großen Fanout kommt und die Steuerungsebene einfach mit Updates überflutet wird. Insbesondere lassen sich solche Topologien nur sehr schlecht mit dem herkömmlichen Flooding-Algorithmus in Link-State-Protokollen kombinieren.
Die Wahl besteht darin, BGP zu verwenden. Wie Sie es richtig vorbereiten, ist in RFC 7938 über den Einsatz von BGP in großen Rechenzentren beschrieben. Die Grundideen sind einfach: minimale Anzahl von Präfixen pro Host und generell minimale Anzahl von Präfixen im Netzwerk, wenn möglich Aggregation verwenden und Pfadjagd unterdrücken. Wir wollen eine sehr sorgfältige, sehr kontrollierte Verteilung von Updates, was als „Valley Free“ bezeichnet wird. Wir möchten, dass Updates genau einmal bereitgestellt werden, während sie das Netzwerk durchlaufen. Wenn sie unten entstehen, steigen sie auf und entfalten sich nur einmal. Es sollten keine Zickzacklinien vorhanden sein. Zickzacklinien sind sehr schlecht.
Dazu verwenden wir ein Design, das einfach genug ist, um die zugrunde liegenden BGP-Mechanismen zu nutzen. Das heißt, wir verwenden eBGP, das auf der lokalen Verbindung läuft, und autonome Systeme werden wie folgt zugewiesen: ein autonomes System auf ToR, ein autonomes System auf dem gesamten Spine-1-Switch-Block eines Pods und ein allgemeines autonomes System auf dem gesamten Top aus Stoff. Es ist nicht schwer zu erkennen, dass selbst das normale Verhalten von BGP uns die gewünschte Verteilung von Updates ermöglicht.
Natürlich müssen Adressierung und Adressaggregation so gestaltet sein, dass sie mit der Art und Weise, wie das Routing aufgebaut ist, kompatibel sind, damit sie die Stabilität der Steuerebene gewährleisten. Die L3-Adressierung im Transport ist an die Topologie gebunden, da ohne diese keine Aggregation möglich ist und sich einzelne Adressen in das Routing-System einschleichen. Und noch etwas ist, dass sich Aggregation leider nicht sehr gut mit Multipath kombinieren lässt, denn wenn wir Multipath und Aggregation haben, ist alles in Ordnung, wenn das gesamte Netzwerk fehlerfrei ist, gibt es keine Fehler darin. Sobald Fehler im Netzwerk auftreten und die Symmetrie der Topologie verloren geht, können wir leider zu dem Punkt gelangen, von dem aus die Einheit angekündigt wurde, von dem aus wir nicht weiter dorthin gelangen können, wo wir hin müssen. Daher ist es am besten, dort zu aggregieren, wo es keinen weiteren Multipfad gibt, in unserem Fall handelt es sich um ToR-Switches.
Tatsächlich ist eine Aggregation möglich, aber vorsichtig. Wenn wir bei Netzwerkausfällen eine kontrollierte Disaggregation durchführen können. Aber das ist eine ziemlich schwierige Aufgabe. Wir haben uns sogar gefragt, ob dies möglich wäre, ob es möglich wäre, zusätzliche Automatisierung und Finite-State-Maschinen hinzuzufügen, die BGP korrekt starten würden, um das gewünschte Verhalten zu erzielen. Leider ist die Verarbeitung von Eckfällen sehr nicht offensichtlich und komplex, und diese Aufgabe lässt sich durch das Anhängen externer Anhänge an BGP nicht gut lösen.
Im Rahmen des RIFT-Protokolls wurden diesbezüglich sehr interessante Arbeiten durchgeführt, die im nächsten Bericht besprochen werden.
Ein weiterer wichtiger Aspekt ist die Skalierung von Datenebenen in dichten Topologien, in denen es eine große Anzahl alternativer Pfade gibt. In diesem Fall werden mehrere zusätzliche Datenstrukturen verwendet: ECMP-Gruppen, die wiederum Next Hop-Gruppen beschreiben.
In einem normal funktionierenden Netzwerk ohne Ausfälle reicht es beim Hochfahren der Clos-Topologie aus, nur eine Gruppe zu verwenden, da alles, was nicht lokal ist, standardmäßig beschrieben wird und wir hochsteigen können. Wenn wir von oben nach unten nach Süden gehen, sind nicht alle Pfade ECMP, sondern Einzelpfadpfade. Alles ist gut. Das Problem ist, und die Besonderheit der klassischen Clos-Topologie besteht darin, dass es, wenn wir auf die Oberseite des Gewebes schauen, bei jedem Element nur einen Pfad zu jedem Element darunter gibt. Wenn auf diesem Pfad Fehler auftreten, wird dieses bestimmte Element an der Spitze der Factory genau für die Präfixe ungültig, die hinter dem unterbrochenen Pfad liegen. Aber im Übrigen gilt es, und wir müssen die ECMP-Gruppen analysieren und einen neuen Zustand einführen.
Wie sieht die Skalierbarkeit der Datenebene auf modernen Geräten aus? Wenn wir LPM (longest prefix match) durchführen, ist alles ziemlich gut, über 100 Präfixe. Wenn wir über Next-Hop-Gruppen sprechen, dann ist alles schlimmer, 2-4. Wenn es sich um eine Tabelle handelt, die eine Beschreibung der nächsten Hops (oder Adjazenzen) enthält, dann liegt diese irgendwo zwischen 16 und 64. Und das kann zum Problem werden. Und hier kommen wir zu einem interessanten Exkurs: Was ist mit MPLS in Rechenzentren passiert? Im Prinzip wollten wir es machen.
Zwei Dinge sind passiert. Wir haben die Mikrosegmentierung auf den Hosts durchgeführt; wir mussten sie nicht mehr im Netzwerk durchführen. Bei der Unterstützung verschiedener Anbieter war es nicht sehr gut, und noch mehr bei offenen Implementierungen auf Whiteboxen mit MPLS. Und MPLS, zumindest seine traditionellen Implementierungen, lässt sich leider nur sehr schlecht mit ECMP kombinieren. Und deshalb.
So sieht die ECMP-Weiterleitungsstruktur für IP aus. Eine große Anzahl von Präfixen kann dieselbe Gruppe und denselben Next Hops-Block (oder Nachbarschaften, dies kann in verschiedenen Dokumentationen für verschiedene Geräte unterschiedlich bezeichnet werden) verwenden. Der Punkt ist, dass dies als ausgehender Port beschrieben wird und wohin die MAC-Adresse umgeschrieben werden muss, um zum richtigen nächsten Hop zu gelangen. Für IP sieht alles einfach aus. Sie können eine sehr große Anzahl von Präfixen für dieselbe Gruppe und denselben Next Hops-Block verwenden.
Die klassische MPLS-Architektur impliziert, dass das Label je nach ausgehender Schnittstelle auf unterschiedliche Werte umgeschrieben werden kann. Daher müssen wir für jedes Eingabelabel eine Gruppe und einen Next Hops-Block behalten. Und das lässt sich leider nicht skalieren.
Es ist leicht zu erkennen, dass wir in unserem Design etwa 4000 ToR-Switches benötigten, die maximale Breite betrug 64 ECMP-Pfade, wenn wir uns von Spine-1 in Richtung Spine-2 bewegen. Wir kommen kaum in eine Tabelle der ECMP-Gruppen, wenn nur ein Präfix mit ToR wegfällt, und wir kommen überhaupt nicht in die Next Hops-Tabelle.
Es ist nicht alles hoffnungslos, denn Architekturen wie Segment Routing beinhalten globale Labels. Formal wäre es möglich, alle diese Next Hops-Blöcke wieder zusammenzubrechen. Dazu benötigen Sie eine Operation vom Typ Platzhalter: Nehmen Sie eine Bezeichnung und schreiben Sie sie ohne einen bestimmten Wert in dieselbe um. Leider ist dies in den verfügbaren Implementierungen nicht sehr vorhanden.
Und schließlich müssen wir externen Datenverkehr in das Rechenzentrum bringen. Wie es geht? Bisher wurde der Verkehr von oben in das Clos-Netzwerk eingeleitet. Das heißt, es gab Edge-Router, die eine Verbindung zu allen Geräten auf der Oberseite der Fabric herstellten. Diese Lösung funktioniert recht gut bei kleinen bis mittleren Größen. Um den Datenverkehr auf diese Weise symmetrisch an das gesamte Netzwerk zu senden, müssen wir leider alle Top-of-Fabric-Elemente gleichzeitig erreichen, und wenn es mehr als hundert sind, stellt sich heraus, dass wir auch eine große Basis benötigen die Edge-Router. Im Allgemeinen kostet dies Geld, da Edge-Router funktionaler sind, die Ports teurer sind und das Design nicht sehr schön ist.
Eine andere Möglichkeit besteht darin, solchen Verkehr von unten zu starten. Es lässt sich leicht überprüfen, dass die Clos-Topologie so aufgebaut ist, dass der von unten, also von der ToR-Seite, kommende Datenverkehr in zwei Iterationen gleichmäßig auf die Ebenen im gesamten Top of Fabric verteilt wird und so das gesamte Netzwerk belastet. Aus diesem Grund stellen wir einen speziellen Pod-Typ vor, den Edge Pod, der externe Konnektivität bietet.
Es gibt noch eine weitere Option. Das macht zum Beispiel Facebook. Sie nennen es Fabric Aggregator oder HGRID. Zur Anbindung mehrerer Rechenzentren wird eine zusätzliche Spine-Ebene eingeführt. Dieses Design ist möglich, wenn wir keine zusätzlichen Funktionen oder Kapselungsänderungen an den Schnittstellen haben. Wenn es zusätzliche Berührungspunkte sind, ist es schwierig. Typischerweise gibt es mehr Funktionen und eine Art Membran, die verschiedene Teile des Rechenzentrums trennt. Es macht keinen Sinn, eine solche Membran groß zu machen, aber wenn sie aus irgendeinem Grund wirklich benötigt wird, ist es sinnvoll, die Möglichkeit in Betracht zu ziehen, sie wegzunehmen, sie so breit wie möglich zu machen und auf die Hosts zu übertragen. Dies wird beispielsweise von vielen Cloud-Betreibern durchgeführt. Sie haben Overlays, sie beginnen bei den Hosts.
Welche Entwicklungsmöglichkeiten sehen wir? Zunächst einmal die Verbesserung der Unterstützung für die CI/CD-Pipeline. Wir wollen so fliegen, wie wir es testen, und wir wollen die Art testen, wie wir fliegen. Dies funktioniert nicht besonders gut, da die Infrastruktur groß ist und es unmöglich ist, sie für Tests zu duplizieren. Sie müssen verstehen, wie Sie Testelemente in die Produktionsinfrastruktur einführen können, ohne sie fallen zu lassen.
Eine bessere Instrumentierung und bessere Überwachung sind fast nie überflüssig. Die ganze Frage ist ein Gleichgewicht zwischen Aufwand und Ertrag. Wenn Sie es mit vertretbarem Aufwand hinzufügen können, sehr gut.
Offene Betriebssysteme für Netzwerkgeräte. Bessere Protokolle und bessere Routing-Systeme wie RIFT. Es besteht auch Forschungsbedarf hinsichtlich des Einsatzes besserer Systeme zur Überlastungskontrolle und möglicherweise der Einführung, zumindest an einigen Stellen, der RDMA-Unterstützung innerhalb des Clusters.
Wenn wir weiter in die Zukunft blicken, brauchen wir fortschrittliche Topologien und möglicherweise Netzwerke, die weniger Overhead verbrauchen. Von den frischen Dingen gab es kürzlich Veröffentlichungen über die Fabric-Technologie für HPC Cray Slingshot, die auf Commodity-Ethernet basiert, aber mit der Option, deutlich kürzere Header zu verwenden. Dadurch wird der Overhead reduziert.
Alles sollte so einfach wie möglich gehalten werden, aber nicht einfacher. Komplexität ist der Feind der Skalierbarkeit. Einfachheit und regelmäßige Strukturen sind unsere Freunde. Wenn Sie irgendwo eine Skalierung durchführen können, tun Sie es. Und im Allgemeinen ist es großartig, sich jetzt mit Netzwerktechnologien zu beschäftigen. Es passieren viele interessante Dinge. Danke.
Source: habr.com