Wir haben ein Design für ein Rechenzentrumsnetzwerk entwickelt, das es ermöglicht, Rechencluster mit über 100.000 Servern und einer Spitzenbandbreite von mehr als einem Petabyte pro Sekunde zu betreiben.
Aus dem Vortrag von Dmitri Afanasjew erfahren Sie die grundlegenden Prinzipien des neuen Designs, die Skalierung von Topologien, die dabei auftretenden Probleme, mögliche Lösungen, sowie die Besonderheiten der Datenweiterleitung und der Skalierung der Funktionen moderner Netzgeräte in „dicht“ verbundenen Topologien mit einer Vielzahl von ECMP-Routen. Zudem gab Dima einen kurzen Überblick über die Organisation der externen Anbindung, die physikalische Ebene, das Kabelsystem und Möglichkeiten zur weiteren Kapazitätserweiterung.
— Guten Tag zusammen! Mein Name ist Dmitri Afanasjew, ich bin Netzwerkarchitekt bei Yandex und beschäftige mich hauptsächlich mit dem Design von Rechenzentrumsnetzen.
Mein Vortrag handelt vom aktualisierten Rechenzentrumsnetz von Yandex. Es ist weitgehend eine Evolution des Designs, das wir hatten, aber es gibt auch einige neue Elemente. Dies ist eine Übersichtspräsentation, da wir eine Menge Informationen in kurzer Zeit unterbringen mussten. Wir beginnen mit der Auswahl der logischen Topologie. Danach folgt ein Überblick über den Steuerungsbereich und die Probleme mit der Skalierbarkeit des Datenbereichs, die Entscheidung darüber, was auf der physikalischen Ebene geschehen soll, und wir betrachten einige Besonderheiten der Geräte. Außerdem werden wir kurz die Entwicklungen im Rechenzentrum mit MPLS ansprechen, über das wir vor einiger Zeit gesprochen haben.
Was ist Yandex aus der Sicht von Lasten und Diensten? Yandex ist ein typischer Hyperscaler. Wenn man sich die Benutzer anschaut, geschieht zunächst die Verarbeitung von Benutzeranfragen. Außerdem gibt es verschiedene Streaming-Dienste und die Bereitstellung von Daten, da wir auch Speicher-Dienste haben. Wenn man sich mehr auf den Backend konzentriert, erscheinen dort Infrastrukturlasten und -dienste wie verteilte Objektspeicher, Datenreplikation und natürlich persistente Warteschlangen. Eine der Hauptlastarten sind MapReduce und ähnliche Systeme, Streaming-Verarbeitung, maschinelles Lernen usw.
Wie ist die Infrastruktur aufgebaut, auf der all dies geschieht? Wiederum sind wir ein ziemlich typischer Hyperscaler, auch wenn wir uns vielleicht ein wenig näher an dem Ende des Spektrums befinden, wo kleinere Hyperscaler angesiedelt sind. Aber wir haben alle Attribute. Wir verwenden Commodity-Hardware und horizontale Skalierung überall dort, wo es möglich ist. Wir haben umfangreiche Ressourcen-Pooling: Wir arbeiten nicht mit einzelnen Maschinen oder Racks, sondern fassen sie in einem großen Pool austauschbarer Ressourcen zusammen, unterstützt von zusätzlichen Diensten, die sich mit Planung und Zuordnung befassen, und arbeiten mit diesem gesamten Pool.
Daher entsteht die nächste Ebene — das Betriebssystem auf der Ebene des Rechenzentrums-Clusters. Es ist sehr wichtig, dass wir den Technologie-Stack, der bei uns verwendet wird, vollständig kontrollieren. Wir kontrollieren die Endpunkte (Hosts), das Netzwerk und den Software-Stack.
Wir haben mehrere große Rechenzentren in Russland und im Ausland. Diese sind durch einen Backbone verbunden, der die MPLS-Technologie verwendet. Unsere interne Infrastruktur basiert nahezu vollständig auf IPv6, aber da wir den externen Traffic, der immer noch hauptsächlich über IPv4 hereinkommt, bedienen müssen, müssen wir irgendwie die Anfragen, die über IPv4 eintreffen, an das Frontend liefern,Server, und wir müssen auch ein wenig ins externe IPv4-Internet gehen — zum Beispiel für die Indizierung.
Die letzten Iterationen des Rechenzentrumsnetzwerkdesigns verwenden mehrstufige Clos-Topologien, und sie verwenden ausschließlich L3. Wir haben vor einiger Zeit L2 hinter uns gelassen und aufatmen können. Schließlich umfasst unsere Infrastruktur Hunderttausende von Berechnungs- (Server-) Instanzen. Die maximale Clustergröße lag vor einiger Zeit bei etwa 10.000 Servern. Dies ist zu einem großen Teil darauf zurückzuführen, wie die Betriebssysteme auf Clusterebene arbeiten können, einschließlich Scheduler, Ressourcenallokation usw. Da es im Bereich der Infrastruktur-Software Fortschritte gegeben hat, ist die Zielgröße nun etwa 100.000 Server in einem Rechenzentrums-Cluster, und wir stehen vor der Aufgabe, Netzwerkfabriken zu schaffen, die ein effektives Ressourcen-Pooling in einem solchen Cluster ermöglichen.
Was wollen wir also von einem Rechenzentrumsnetzwerk? Vor allem viel günstige und ausreichend gleichmäßig verteilte Bandbreite. Denn das Netzwerk ist die Grundlage, mit der wir Ressourcen bündeln 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, da bei einer so großen Infrastruktur genug Kopfschmerzen durch einfach nur zufällige Ereignisse entstehen, und wir möchten nicht, dass uns auch noch der Control Plane Kopfschmerzen bereitet. Gleichzeitig möchten wir den Zustand darin minimieren. Je weniger Zustand, desto besser und stabiler funktioniert alles, desto einfacher ist die Diagnose.
Natürlich benötigen wir Automatisierung, denn ein manuelles Management einer solchen Infrastruktur ist nicht möglich, und das war vor einiger Zeit schon nicht mehr möglich. Wir benötigen, soweit es geht, Unterstützung im operativen Betrieb und Unterstützung für CI/CD, soweit dies möglich ist.
Bei solch großen Rechenzentren und Clustern steht die Aufgabe der Unterstützung von inkrementellen Bereitstellungen und Erweiterungen ohne Unterbrechung des Dienstes bereits ziemlich akut im Raum. Wenn man Cluster mit einer Größe von tausend Maschinen hat, vielleicht sogar bis zu zehntausend Maschinen, kann man sie noch als eine Operation implementieren – das heißt, wir planen die Erweiterung der Infrastruktur, und mehrere tausend Maschinen werden als eine Operation hinzugefügt. Ein Cluster mit einer Größe von fast hunderttausend Maschinen entsteht jedoch nicht sofort so, sondern wird über einen bestimmten Zeitraum aufgebaut. Und es wäre wünschenswert, dass während dieser gesamten Zeit die bereits ausgebaute Infrastruktur, die bereitgestellt wurde, verfügbar bleibt.
Und eine Anforderung, die wir hatten und die weggefallen ist: die Unterstützung von Multitenancy, also von Virtualisierung oder Netzwerksegmentierung. Jetzt müssen wir das nicht mehr auf der Ebene der Netzwerkinfrastruktur machen, denn die Segmentierung wurde auf die Hosts verlagert, was uns die Skalierung erheblich erleichtert hat. Dank IPv6 und des großen Adressraums mussten wir in der internen Infrastruktur keine doppelten Adressen verwenden, die gesamte Adressierung war ohnehin einzigartig. Und da wir die Filterung und Segmentierung des Netzwerks auf die Hosts verlagert haben, müssen wir keine virtuellen Netzwerkeinheiten in den Rechenzentrumsnetzen schaffen.
Eine sehr wichtige Sache ist das, was wir nicht brauchen. Wenn bestimmte 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. Außerdem vereinfacht es die Diagnose erheblich.
Was brauchen wir also nicht, auf was konnten wir verzichten, nicht immer mit Freude, als es geschah, aber mit großer Erleichterung, als der Prozess abgeschlossen war?
In erster Linie der Verzicht auf L2. Wir benötigen kein reales oder emuliertes L2. Es wird in erheblichem Maße nicht genutzt, weil wir den Anwendungsstapel kontrollieren. Unsere Anwendungen skalieren horizontal, sie arbeiten mit L3-Adressierung und machen sich keine großen Sorgen, wenn eine einzelne Instanz ausfällt. Sie rollen einfach eine neue aus, die nicht unter der alten Adresse bereitgestellt werden muss, da es eine separate Ebene für Service Discovery und Monitoring der Maschinen im Cluster gibt. Wir übertragen diese Aufgabe nicht auf das Netzwerk. Die Aufgabe des Netzwerks besteht darin, Pakete von Punkt A nach Punkt B zu liefern.
Wir haben auch keine Situationen, in denen Adressen innerhalb des Netzwerks umgezogen werden müssen, und das verfolgt werden muss. In vielen Designs ist das in der Regel erforderlich, um die VM-Mobilität zu unterstützen. Wir verwenden die Mobilität virtueller Maschinen innerhalb der internen Infrastruktur von Yandex nicht, und darüber hinaus sind wir der Meinung, dass, selbst wenn dies geschieht, es nicht mit Unterstützung des Netzwerks geschehen sollte. Wenn es unbedingt notwendig ist, sollte dies auf Host-Ebene geschehen, und Adressen, die migrieren können, sollten in Overlay-Netzen untergebracht werden, um nicht zu viele dynamische Änderungen im Routing-System der eigentlichen Unterlage (Transportnetz) vorzunehmen.
Eine weitere Technologie, die wir nicht nutzen, ist Multicast. Ich kann gerne im Detail erklären, warum. Es erleichtert das Leben erheblich, denn wenn jemand damit zu tun hatte und gesehen hat, wie die Steuerungsebene von Multicast aussieht – in allen Instanzen, außer den einfachsten, ist das ein großes Kopfschmerzenproblem. Außerdem ist es schwierig, eine gut funktionierende Open-Source-Implementierung zu finden.
Und schließlich entwerfen wir unsere Netzwerke so, dass darin nicht zu viele Änderungen auftreten. Wir können davon ausgehen, dass der Fluss externer Ereignisse im Routing-System gering ist.
Welche Probleme und Einschränkungen müssen berücksichtigt werden, wenn wir ein Rechenzentrumsnetzwerk entwickeln? Die Kosten, natürlich. Skalierbarkeit, bis zu welchem Niveau wir wachsen möchten. Die Notwendigkeit, ohne Serviceunterbrechung zu skalieren. Bandbreite, Verfügbarkeit. Die Sichtbarkeit dessen, was im Netzwerk passiert, für Überwachungssysteme und Betriebsteams. Unterstützung von Automatisierung - wiederum, so viel wie möglich, da unterschiedliche Aufgaben auf unterschiedlichen Ebenen gelöst werden können, einschließlich der Einführung zusätzlicher Schichten. Und die Unabhängigkeit von Anbietern - obwohl diese Unabhängigkeit in verschiedenen historischen Perioden, abhängig von der Betrachtungsebene, leichter oder schwieriger erreichbar war. Wenn wir den Bereich von Netzwerkintegrationen betrachten, konnte man bis vor kurzem sehr условно von der Unabhängigkeit der Anbieter sprechen, wenn wir auch Chips mit hoher Bandbreite wollten.
Nach welcher logischen Topologie werden wir unser Netzwerk aufbauen? Es wird ein mehrstufiges Clos sein. Tatsächlich gibt es im Moment keine realen Alternativen. Und die Clos-Topologie ist ausreichend gut, selbst im Vergleich zu anderen fortgeschrittenen Topologien, die sich momentan eher im Bereich des akademischen Interesses befinden, vorausgesetzt, wir haben Switches mit einer großen Radix.
Wie ist ein mehrstufiges Clos-Netzwerk ungefähr aufgebaut und wie heißen die verschiedenen Elemente darin? Zuerst einmal, der Windrose, um sich zu orientieren, wo Norden, Süden, Osten und Westen sind. Solche Netzwerke werden normalerweise von denen gebaut, die sehr viel Verkehr von West nach Ost haben. Was die anderen Elemente betrifft, so ist oben ein virtueller Switch abgebildet, der aus kleineren Switches zusammengesetzt ist. Das ist die grundlegende Idee des rekursiven Aufbaus von Clos-Netzwerken. 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 noch mehr erforderlich ist, kann der Vorgang wiederholt werden.
In Fällen wie zum Beispiel bei zweistufigen Clos-Netzwerken, in denen man klar die vertikalen Komponenten auf meinem Diagramm unterscheiden kann, werden diese als Ebenen bezeichnet. Wenn wir Clos mit drei Ebenen von Spine-Switches (alle, die nicht grenzwertig oder ToR-Switches sind und die nur für Transit verwendet werden) bauen würden, würden die Ebenen komplexer aussehen, bei zweistufigen sehen sie so aus. Der Block von ToR- oder Leaf-Switches und die dazugehörigen Spine-Switches der ersten Ebene nennen wir Pod. Die Spine-Switches der Ebene Spine-1 oben im Pod sind das Top of Pod, die Spitze des Pods. Die Switches, die sich ganz oben im gesamten Netzwerk befinden, bilden die oberste Schicht des Fabriknetzwerks, das Top of Fabric.
Natürlich stellt sich die Frage: Clos-Netzwerke bestehen schon eine Weile, die Idee stammt ursprünglich aus der klassischen Telefonie und TDM-Netzen. Vielleicht gibt es etwas Besseres, vielleicht kann man es besser machen? Sowohl ja als auch nein. Theoretisch ja, aber praktisch in naher Zukunft sicher nicht. Denn es gibt einige interessante Topologien, ein Teil davon wird sogar in der Produktion verwendet, zum Beispiel wird Dragonfly in HPC-Anwendungen eingesetzt; es gibt auch interessante Topologien wie Xpander, FatClique, Jellyfish. Wenn man sich die Vorträge auf Konferenzen wie SIGCOMM oder NSDI in letzter Zeit anschaut, kann man eine ziemlich große Anzahl von Arbeiten zu alternativen Topologien finden, die bessere Eigenschaften (in einer oder anderer Hinsicht) als Clos haben.
Aber all diese Topologien haben eine interessante Eigenschaft. Diese erschwert ihre Implementierung in Rechenzentren, die wir mit Commodity-Hardware bauen und die zu einem vernünftigen Preis erhältlich sind. In all diesen alternativen Topologien ist ein großer Teil der Bandbreite leider nicht über die kürzesten Wege verfügbar. Daher verlieren wir sofort die Möglichkeit, den traditionellen Control Plane zu nutzen.
Theoretisch ist die Lösung des Problems bekannt. Zum Beispiel Modifikationen von Link-State mit Verwendung von k-kürzesten Wegen, aber auch hier gibt es keine Protokolle, die in der Produktion implementiert und weit verbreitet 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 die Steuerebene modifizieren, um alle diese Wege auszuwählen (und übrigens ist das ein deutlich größeres Zustandsbild in der Steuerebene). Wir müssen auch die Weiterleitungsebene modifizieren, und in der Regel werden mindestens zwei zusätzliche Funktionen benötigt. Das ist die Möglichkeit, alle Entscheidungen über die Weiterleitung von Paketen einmal zu treffen, zum Beispiel auf dem Host. Tatsächlich handelt es sich um Source Routing, was manchmal in der Literatur über Interconnection Networks als All-at-once Forwarding Decisions bezeichnet wird. Und außerdem ist adaptives Routing eine Funktion, die wir auf Netzwerkgeräten benötigen, die darin besteht, den nächsten Hop basierend auf Informationen über die geringste Belastung der Warteschlange auszuwählen. Als Beispiel sind andere Varianten möglich.
Somit ist die Richtung interessant, aber leider können wir sie gerade jetzt nicht anwenden.
Okay, wir haben uns auf die logische Clos-Topologie geeinigt. Wie werden wir sie skalieren? Lassen Sie uns anschauen, wie sie aufgebaut ist und was wir tun können.
In einem Clos-Netz gibt es zwei Hauptparameter, die wir irgendwie variieren können, um unterschiedliche Ergebnisse zu erzielen: die Radix der Elemente und die Anzahl der Ebenen im Netzwerk. Ich habe schematisch dargestellt, wie beides die Größe beeinflusst. Ideal kombinieren wir beides.
Es ist zu sehen, dass die endgültige Breite des Clos-Netzes das Produkt aller Ebenen der Spine-Switches des südlichen Radix ist, also wie viele Links wir nach unten haben, wie es verzweigt. So skalieren wir die Größe des Netzwerks.
Was die Kapazität betrifft, insbesondere bei ToR-Switches, gibt es hier zwei Skalierungsoptionen. Entweder können wir, die gesamte Topologie beibehaltend, schnellere Links verwenden oder wir können eine größere Anzahl von Ebenen hinzufügen.
Wenn wir uns die ausgeklappte Version des Clos-Netzes (in der rechten unteren Ecke) ansehen und zu diesem Bild mit dem Clos-Netz unten zurückkehren...
... dann ist das genau dieselbe Topologie, aber auf diesem Slide wurde sie kompakter zusammengefasst und die Fabrikebenen übereinander gelegt. Es ist dasselbe.
Wie sieht die Skalierung des Clos-Netzes in Zahlen aus? Hier gebe ich Daten an, wie breit das Netzwerk maximal sein kann, wie viele Racks, ToR-Switches oder Leaf-Switches wir abhängig davon erhalten können, welches Radix von Switches wir für die Spine-Ebenen verwenden und wie viele Ebenen wir nutzen.
Hier wird aufgeführt, wie viele Racks wir haben können, wie viele Server und ungefähr wie viel das alles bei einer Annahme von 20 kW pro Rack verbrauchen könnte. Ich habe bereits erwähnt, dass wir eine Clustergröße von etwa 100.000 Servern anstreben.
Es ist zu erkennen, dass in dieser ganzen Konstruktion zwei einhalb Varianten von Interesse sind. Es gibt eine Variante mit zwei Schichten Spines und 64-Port-Switches, die etwas unterperformt. Danach gibt es hervorragend passende Optionen für 128-Port (mit Radix 128) Spine-Switches mit zwei Ebenen oder Switches mit Radix 32 mit drei Ebenen. In allen Fällen, in denen der Radix und die Anzahl der Ebenen größer sind, kann ein sehr großes Netzwerk geschaffen werden, aber wenn man sich den erwarteten Verbrauch ansieht, reden wir in der Regel von Gigawatt. Kabel kann man verlegen, aber so viel Strom an einem Standort werden wir wohl kaum bekommen. Wenn man sich die Statistiken anschaut, sind öffentliche Daten zu Rechenzentren — nur sehr wenige Rechenzentren existieren mit einer berechneten Leistung von über 150 MW. Was darüber hinausgeht, sind in der Regel Rechenzentrumscampusse, mehrere große Rechenzentren, die relativ nah beieinander liegen.
Es gibt noch einen wichtigen Parameter. Wenn Sie sich die linke Spalte ansehen, dort ist die verwendbare Bandbreite angegeben. Es ist nicht schwer zu erkennen, dass in einem Clos-Netzwerk ein erheblicher Teil der Ports darauf entfällt, Switches miteinander zu verbinden. Nutzbare Bandbreite ist die Bandbreite, die man nach außen, in Richtung Server, abgeben kann. Natürlich spreche ich von den fiktiven Ports und tatsächlich von der Bandbreite. In der Regel sind die Links innerhalb des Netzwerks schneller als die Links in Richtung Server, aber auf eine Einheit Bandbreite, die wir nach außen an unsere Serverausrüstung abgeben können, entfällt noch eine gewisse Bandbreite innerhalb des Netzwerks selbst. Je mehr Ebenen wir machen, desto höher sind die spezifischen Kosten, um diese Bandbreite nach außen bereitzustellen.
Darüber hinaus ist selbst diese zusätzliche Bandbreite nicht ganz gleich. Solange die Distanzen kurz sind, können wir etwas wie DAC (Direct Attach Copper, also Twinax-Kabel) oder Multimode-Optik verwenden, die noch einigermaßen zu akzeptablen Preisen erhältlich sind. Sobald wir jedoch auf längere Distanzen umschalten – in der Regel ist das Singlemode-Optik, und die Kosten für diese zusätzliche Bandbreite steigen deutlich.
Und nochmals, zurück zum vorherigen Slide, wenn wir ein Clos-Netzwerk ohne Neuauslegung erstellen, ist es nicht schwer, das Schema zu betrachten und zu sehen, wie das Netzwerk aufgebaut wird – indem wir jede Ebene der Spine-Switches hinzufügen, wiederholen wir die gesamte Bandbreite, die unten war. Plus eine Ebene – plus all die gleiche Bandbreite, noch so viele Ports an den Switches, noch so viele Transceiver. Daher ist es sehr wünschenswert, die Anzahl der Spine-Switch-Ebenen zu minimieren.
Aus diesem Bild lässt sich ablesen, dass wir dringend auf etwas wie Switches mit Radix 128 aufbauen möchten.
Hier ist im Prinzip alles dasselbe, was ich gerade erzählt habe, diese Folie ist eher zur späteren Betrachtung gedacht.
Welche Optionen haben wir, was können wir als solche Switches auswählen? Eine sehr erfreuliche Nachricht für uns ist, dass solche Netzwerke jetzt endlich auf Ein-Chip-Switches aufgebaut werden können. Und das ist großartig, sie bringen viele angenehme Eigenschaften mit sich. Zum Beispiel fehlt es ihnen fast an interner Struktur. Das bedeutet, dass sie einfacher ausfallen. Sie fallen aus, wie könnte es anders sein, aber glücklicherweise komplett. Bei modularen Geräten gibt es eine große Anzahl von Fehlern (sehr unangenehm), wenn es für Nachbarn und den Control Plane so aussieht, als würde es funktionieren, aber zum Beispiel ein Teil der Fabrik verloren gegangen ist und es nicht die volle Kapazität hat. Der Verkehr wird basierend auf der Annahme ausgewogen, dass es vollständig funktional ist, und wir können eine Überlastung erhalten.
Oder zum Beispiel treten Probleme mit dem Backplane auf, weil es in einem modularen Gerät auch Hochgeschwindigkeits-SerDes gibt – es ist tatsächlich komplex im Inneren aufgebaut. Oder die Tabellen zwischen den Forwarding-Elementen synchronisieren sich oder synchronisieren sich nicht. Im Allgemeinen enthält jedes leistungsfähige modulare Gerät, das aus vielen Elementen besteht, in der Regel das gleiche Clos-Netzwerk, dessen Diagnose jedoch sehr schwierig ist. Häufig ist es sogar für den Anbieter schwierig, die Fehlerdiagnose durchzuführen.
Es gibt eine Vielzahl von Fehlerszenarien, in denen das Gerät degradiert, jedoch nicht vollständig aus der Topologie herausfällt. Da wir ein großes Netzwerk haben, das aktiv das Load Balancing zwischen identischen Elementen nutzt und sehr regelmäßig ist, bedeutet das, dass ein Pfad, auf dem alles in Ordnung ist, sich nicht von einem anderen Pfad unterscheidet. Daher ist es für uns vorteilhafter, einfach einen Teil der Geräte aus der Topologie zu verlieren, als in eine Situation zu geraten, in der einige von ihnen anscheinend funktionieren, andere dagegen nicht.
Ein weiteres erfreuliches Merkmal von Ein-Chip-Geräten ist, dass sie sich besser und schneller weiterentwickeln. Außerdem haben sie in der Regel eine bessere Kapazität. Wenn man sich große montierte Konstruktionen ansieht, die wir haben, ist die Kapazität pro Rack-Einheit über Ports derselben Geschwindigkeit fast doppelt so hoch wie bei modularen Geräten. Geräte, die um einen einzigen Chip herum gebaut sind, sind deutlich günstiger als modulare und verbrauchen weniger Energie.
Das hat natürlich auch seine Nachteile. Erstens haben sie praktisch immer einen kleineren Radix als modulare Geräte. Wenn wir ein Gerät, das um einen Chip herum gebaut ist, mit 128 Ports bekommen können, können wir ein modulares Gerät mittlerweile ohne besondere Probleme mit mehreren Hundert Ports erreichen.
Dies führt zu einer deutlich kleineren Größe der Forwarding-Tabellen und in der Regel zu allem, was die Skalierbarkeit des Data Plane betrifft. Flache Puffer. Und in der Regel eine ziemlich begrenzte Funktionalität. Es stellt sich jedoch heraus, dass, wenn man diese Einschränkungen kennt und rechtzeitig darauf achtet, sie zu umgehen oder einfach zu beachten, das nicht so schlimm ist. Der kleinere Radix ist bei den neu auf den Markt gekommenen Geräten mit einem Radix von 128 kein Problem mehr; wir können uns in zwei Schichten von Spines aufbauen. Mit nur einer Ebene ergeben sich sehr kleine Cluster. Selbst unsere vorherigen Designs und Anforderungen übertrafen sie trotzdem.
In der Tat gibt es, falls eine Entscheidung irgendwo an der Grenze steht, noch eine Möglichkeit zur Skalierung. Da die letzte (oder erste) unterste Ebene, an die die Server angeschlossen werden, ToR-Switches oder Leaf-Switches sind, sind wir nicht verpflichtet, nur ein Rack daran anzuschließen. Deshalb kann man, wenn eine Entscheidung in etwa um das Doppelte nicht ausreicht, darüber nachdenken, einfach einen Switch mit einem größeren Rucksack auf der untersten Ebene zu verwenden und beispielsweise zwei bis drei Racks an einen Switch anzuschließen. Das ist auch eine Option, hat seine eigenen Kosten, funktioniert aber ganz gut und kann eine gute Lösung sein, wenn man irgendwo die Größe um das Doppelte erreichen muss.
Zusammenfassend bauen wir auf einer Topologie mit zwei Spinnenebenen und acht Fabrikschichten auf.
Was passiert mit der Physik? Sehr einfache Berechnungen. Wenn wir zwei Spinnenebenen haben, haben wir insgesamt drei Switch-Ebenen, und wir erwarten, dass es im Netzwerk drei Kabelsegmente geben wird: von den Servern zu den Leaf-Switches, zu Spine 1, zu Spine 2. Die Optionen, die wir verwenden können, sind Twinax, Multimode, Single Mode. Hierbei muss berücksichtigt werden, welche Bandbreite verfügbar ist, wie viel das kosten wird, welche physischen Abmessungen es hat, welche Spannweiten wir überwinden können und wie wir aufrüsten werden.
In Bezug auf die Kosten kann alles in einer Linie dargestellt werden. Twinax-Kabel sind deutlich günstiger als aktive Optik, günstiger als Multimode-Transceiver, wenn man von Ende zu Ende betrachtet, etwas günstiger als ein 100-Gigabit-Port eines Switches. Und er kostet, Achtung, weniger als Single-Mode-Optik, denn in Bereichen, wo Single-Mode gefordert ist, macht es aus verschiedenen Gründen Sinn, CWDM in Rechenzentren zu verwenden, und die Verwendung von parallelem Single-Mode (PSM) ist nicht besonders praktisch, da sehr große Bündel von Fasern entstehen, und wenn man sich auf diese Technologien stützt, ergibt sich etwa eine solche Hierarchie der Preise.
Ein weiterer Hinweis: Leider lässt sich die Zerlegung von 100 auf 4x25-Multimode-Ports nicht sehr gut umsetzen. Aufgrund der Konstruktionsdetails sind SFP28-Transceiver nicht viel günstiger als QSFP28 für 100 Gbit. Und diese Zerlegung funktioniert für Multimode nicht besonders gut.
Eine weitere Einschränkung besteht darin, dass aufgrund der Größe der Rechencluster und der Anzahl der Server unsere Rechenzentren physisch groß sind. Das bedeutet, dass wir zumindest einen Abschnitt mit Singlemode machen müssen. Auch aufgrund der physischen Größe der Pods ist es nicht möglich, zwei Abschnitte mit Twinax (Kupferkabel) zu bewerkstelligen.
Letztendlich, wenn wir es preislich optimieren und die Geometrie dieser Konstruktion berücksichtigen, erhalten wir einen Abschnitt mit Twinax, einen Abschnitt mit Multimode und einen Abschnitt mit Singlemode unter Verwendung von CWDM. Dies berücksichtigt mögliche Upgrade-Pfade.
So sieht es ungefähr aus, was kürzlich war, wohin wir uns bewegen und was möglich ist. Es ist klar, zumindest wie man in Richtung 50-Gigabit-SerDes für sowohl Multimode als auch Singlemode vorankommt. Darüber hinaus, wenn man sich die derzeit verfügbaren Singlemode-Transceiver ansieht und in die Zukunft für 400G blickt, kann es häufig passieren, dass, wenn 50G SerDes mit elektrischer Seite kommen, in die Optik bereits 100 Gbps pro Lane ausgegeben werden können. Daher ist es sehr gut möglich, dass anstelle des Umstiegs auf 50 ein Umstieg auf 100-Gigabit-SerDes und 100 Gbps pro Lane stattfindet, denn nach den Versprechen vieler Anbieter wird ihre Verfügbarkeit bald erwartet. Der Zeitraum, in dem 50G SerDes die schnellsten waren, wird wahrscheinlich nicht sehr lange dauern, da die ersten 100G SerDes schon im nächsten Jahr auf den Markt gebracht werden. Und eine Zeit danach könnten sie möglicherweise wieder zu vernünftigen Preisen erhältlich sein.
Ein weiterer Punkt zur Auswahl der Physik. Grundsätzlich können wir bereits jetzt 400- oder 200-Gigabit-Ports mit 50G SerDes verwenden. Aber es stellt sich heraus, dass das keinen besonderen Sinn macht, denn wie ich bereits zuvor erzählt habe, wollen wir einen ausreichend großen Radix in den Switches, natürlich im vernünftigen Rahmen. Wir streben 128 an. Wenn jedoch die Kapazität des Chips begrenzt ist und wir die Linkgeschwindigkeit erhöhen, sinkt der Radix natürlich, es gibt keine Wunder.
Und die allgemeine Kapazität können wir durch Ebenen erhöhen, und dabei entstehen keine besonderen Kosten, wir können die Anzahl der Ebenen erhöhen. Wenn wir jedoch den Radix verlieren, müssen wir eine zusätzliche Ebene einführen, weshalb sich bei den aktuellen Rahmenbedingungen und der derzeit maximal verfügbaren Kapazität pro Chip herausstellt, dass es effizienter ist, 100-Gigabit-Ports zu verwenden, da sie einen größeren Radix ermöglichen.
Die nächste Frage ist, wie die physikalische Infrastruktur organisiert ist, jedoch aus der Sicht der Kabelinfrastruktur. Es stellt sich heraus, dass sie ziemlich unterhaltsam organisiert ist. Das Kabel zwischen Leaf-Switches und ersten Level-Spines – dort gibt es nicht so viele Links, alles ist relativ einfach aufgebaut. Wenn wir jedoch eine Ebene betrachten, muss alles innerhalb dieser Ebene so verbunden werden, dass alle ersten Level-Spines mit allen zweiten Level-Spines verbunden sind.
Außerdem gibt es in der Regel bestimmte Wünsche, wie das Innere des Rechenzentrums aussehen sollte. Beispielsweise wollten wir die Kabel gerne in Bündeln zusammenfassen und so verlegen, dass ein Hochdichte-Patchpanel vollständig in ein anderes Patchpanel geht, um keine Zoo von Längen zu haben. Wir haben es geschafft, dieses Problem zu lösen. Wenn man sich die logische Topologie zu Beginn ansieht, wird deutlich, dass die Ebenen unabhängig sind; jede Ebene kann für sich selbst aufgebaut werden. Aber wenn wir ein solches Bundling hinzufügen und das gesamte Patchpanel in ein Patchpanel ziehen möchten, müssen wir innerhalb eines Bundes verschiedene Ebenen mischen und eine Zwischenstruktur in Form von optischen Cross-Connects einführen, um sie von der Art, wie sie in einem Segment zusammengestellt wurden, in die Art, wie sie in einem anderen Segment zusammengestellt werden, umpacken. Dadurch erhalten wir eine angenehme Eigenschaft: die gesamte komplexe Verkabelung bleibt innerhalb der Racks. Wenn es notwendig ist, etwas sehr stark zu verflechten, „die Ebenen zu entfalten“, wie es manchmal in Clos-Netzen genannt wird, konzentriert sich das alles innerhalb eines Racks. Wir haben keine stark auseinandergezogenen, bis hin zu individuell verknüpften, Verbindungen zwischen den Racks.
So sieht es aus der Sicht der logischen Organisation der Kabelinfrastruktur aus. Auf dem Bild links stellen die bunten Blöcke die Blöcke der ersten Level-Spine-Switches dar, in Gruppen von acht, und die vier Kabelbündel, die von ihnen ausgehen, überqueren sich mit den Bündeln, die von den Spine-2-Switch-Blöcken ausgehen.
Die kleinen Quadrate markieren die Schnittpunkte. Oben links befindet sich die Darstellung jedes dieser Schnittpunkte. Tatsächlich handelt es sich um ein Cross-Connect-Modul mit 512 auf 512 Ports, das die Kabel so umpackt, dass sie komplett in ein Rack kommen, wo nur eine Ebene Spine-2 vorhanden ist. Rechts ist die Darstellung dieses Bildes etwas detaillierter in Bezug auf mehrere Pods auf der Ebene Spine-1 und wie dies im Cross-Connect verpackt wird, wie es zur Ebene 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 sichtbar. Diese gesamte Konstruktion wird gerade jetzt in einem unserer großen Rechenzentren, das sich erweitert, aufgebaut. Es ist ein Arbeitsprozess, es wird schöner aussehen, es wird besser gefüllt sein.
Eine wichtige Frage: Wir haben die logische Topologie gewählt und die physische aufgebaut. Was wird mit dem Control Plane passieren? Aus der Betriebserfahrung ist gut bekannt, dass es eine bestimmte Anzahl von Erfahrungen gibt, dass Link-State-Protokolle gut sind und angenehm zu bedienen, aber leider skalieren sie auf eng verbundenen Topologien schlecht. Und es gibt einen Hauptfaktor, der dem entgegenwirkt – so funktioniert das Fluten in Link-State-Protokollen. Wenn man einfach den Flooding-Algorithmus betrachtet und sieht, wie unser Netzwerk aufgebaut ist, erkennt man, dass es bei jedem Schritt sehr großen Fan-Out geben wird, was einfach den Control Plane mit Updates überfluten wird. Solche Topologien in Kombination mit dem traditionellen Flooding-Algorithmus in Link-State-Protokollen vermischen sich sehr schlecht.
Die Wahl – BGP zu verwenden. Wie man es richtig vorbereitet, ist in RFC 7938 über die Verwendung von BGP in großen Rechenzentren beschrieben. Die grundlegenden Ideen sind einfach: Mindestanzahl an Präfixen pro Host und generell die Mindestanzahl an Präfixen im Netzwerk, Aggregation verwenden, wenn möglich, und die Pfadhatzdämpfung unterdrücken. Wir möchten eine sehr vorsichtige, sehr kontrollierte Verbreitung von Updates, das, was als valley free bezeichnet wird. Wir möchten, dass Updates beim Durchlaufen des Netzwerks genau einmal entfaltet werden. Wenn sie unten originieren, gehen sie nach oben und entfalten sich nicht mehr als einmal. Es sollte keine Zickzack-Bewegungen geben. Zickzack-Bewegungen sind sehr schlecht.
Um dies zu erreichen, verwenden wir ein relativ einfaches Schema, um die grundlegenden BGP-Mechanismen zu nutzen. Das heißt, wir verwenden eBGP, das auf Link-Local arbeitet, und die autonomen Systeme werden folgendermaßen zugewiesen: ein autonomes System auf dem ToR, ein autonomes System für den gesamten Block von Spine-1-Switches eines Pods und ein gemeinsames autonomes System für das gesamte Top of Fabric. Es ist nicht schwierig zu sehen und zu bestätigen, dass selbst das normale Verhalten von BGP uns die Verbreitung der Updates gibt, die wir uns wünschen.
Natürlich müssen wir die Adressierung und Aggregierung so gestalten, dass sie mit der Art und Weise, wie das Routing aufgebaut ist, kompatibel ist, um die Stabilität des Control Plane zu gewährleisten. Die L3-Adressierung im Transport hängt von der Topologie ab, denn ohne dies kann keine Aggregierung erzielt werden; ohne dies werden individuelle Adressen in das Routing-System eindringen. Und noch eine Sache ist, dass die Aggregierung leider nicht sehr gut mit Multi-Path kombiniert werden kann, denn wenn wir Multi-Path haben und Aggregierung besteht, ist alles gut, solange das gesamte Netzwerk funktioniert und keine Ausfälle hat. Leider, sobald es im Netzwerk Ausfälle gibt und die Symmetrie der Topologie verloren geht, können wir an einen Punkt gelangen, von dem aus das Aggregat angekündigt wurde, von dem aus wir nicht weiter zu dem gelangen können, was wir brauchen. Daher ist es am besten, dort zu aggregieren, wo es keine weiteren Multi-Paths gibt; in unserem Fall sind das die ToR-Switches.
Tatsächlich kann man aggregieren, aber vorsichtig. Wenn wir kontrollierte Deaggregation bei Auftreten von Ausfällen im Netzwerk vornehmen können. Aber das ist eine ziemlich komplizierte Aufgabe; wir haben uns sogar überlegt, ob es möglich ist, zusätzliche Automatisierung zu implementieren und Automaten zu verwenden, die BGP korrekt anstoßen, um das gewünschte Verhalten zu erzielen. Leider ist die Bearbeitung von Randfällen sehr unklar und komplex, und durch den Anschluss von externen BGP-Geräten wird dieses Problem nicht gut gelöst.
In dieser Hinsicht wurde sehr interessante Arbeit im Rahmen des RIFT-Protokolls geleistet, über das im nächsten Vortrag berichtet wird.
Eine weitere wichtige Sache ist, wie sich Data Plane in dichten Topologien skalieren, in denen es eine große Anzahl alternativer Pfade gibt. Dabei werden mehrere zusätzliche Datenstrukturen verwendet: ECMP-Gruppen, die wiederum Gruppen von Next Hops beschreiben.
In einem normal funktionierenden Netzwerk, ohne Ausfälle, ist es in der Clos-Topologie ausreichend, nur eine Gruppe zu verwenden, da alles, was nicht lokal ist, durch die Standardeinstellung beschrieben wird, und man kann nach oben gehen. Wenn wir von oben nach unten nach Süden gehen, sind alle Pfade keine ECMP-Pfade, sondern Einwegpfade. Alles ist in Ordnung. Das Problem und die Besonderheit der klassischen Clos-Topologie ist, dass, wenn wir auf den Top of Fabric schauen, jeder Knoten einen Pfad zu jedem Knoten unten hat. Wenn auf diesem Pfad Ausfälle auftreten, wird genau dieses Element oben im Fabric ungültig für die Präfixe, die den kaputten Pfad betreffen. Für die anderen ist es jedoch gültig, und wir müssen die ECMP-Gruppen aufschlüsseln und einen neuen Status einführen.
Wie sieht die Skalierbarkeit des Data Plane auf modernen Geräten aus? Wenn wir LPM (Longest Prefix Match) durchführen, funktioniert alles ziemlich gut, über 100k Präfixe. Wenn wir über Next Hop-Gruppen sprechen, sieht es schlechter aus, etwa 2-4 Tausend. Wenn wir über die Tabelle sprechen, die die Beschreibung der Next Hops (oder Adjacencies) enthält, liegt dies irgendwo zwischen 16k und 64k. Und das kann ein Problem werden. Hier gelangen wir zu einem interessanten Exkurs: Was ist mit MPLS in den Rechenzentren passiert? Im Grunde wollten wir es einführen.
Es sind zwei Dinge passiert. Wir haben eine Mikroselektion auf den Hosts gemacht, und wir mussten das nicht mehr im Netzwerk tun. Die Unterstützung von verschiedenen Anbietern war nicht sehr gut, besonders nicht mit offenen Implementierungen auf White Boxes mit MPLS. Außerdem passt MPLS, zumindest seine traditionellen Implementierungen, leider sehr schlecht zu ECMP. Und das erklärt es.
So sieht die Struktur des ECMP-Forschungsprozesses für IP aus. Eine große Anzahl von Präfixen kann dieselbe Gruppe und denselben Block von Next Hops (oder Adjacencies, in unterschiedlichen Dokumentationen für verschiedene Geräte kann das unterschiedlich benannt werden) verwenden. Der Sinn besteht darin, dass dies als ausgehender Port und die Anweisung, welche MAC-Adresse umgesetzt werden soll, um den richtigen Next Hop zu erreichen, beschrieben wird. Für IP sieht alles einfach aus, man kann für eine sehr große Anzahl von Präfixen dieselbe Gruppe und denselben Block von Next Hops verwenden.
Die klassische MPLS-Architektur sieht vor, dass die Bezeichnung je nach ausgehendem Interface auf unterschiedliche Werte umgeschrieben werden kann. Daher müssen wir für jede eingehende Bezeichnung eine Gruppe und einen Block von Next Hops aufrechterhalten. Und das skaliert leider nicht.
Es ist nicht schwer zu sehen, dass wir in unserer Konstruktion etwa 4000 ToR-Switches benötigten, mit einer maximalen Breite von 64 ECMP-Pfaden, wenn wir von Spine-1 zu Spine-2 wechseln. Wir können nur mit Mühe in eine ECMP-Gruppentabelle passen, wenn nur ein Präfix mit ToR ausgeht, und wir passen überhaupt nicht in die Tabelle der Next Hops.
Es ist nicht alles hoffnungslos, denn Architekturen wie Segment Routing implizieren globale Labels. Formal könnten wir all diese Blöcke der Next Hops wieder zusammenfassen. Dazu wäre eine Operation wie Wildcard erforderlich: ein Label nehmen und es ohne spezifischen Wert auf das gleiche zurückschreiben. Leider ist das in den verfügbaren Implementierungen nicht wirklich vorhanden.
Und schließlich müssen wir externen Verkehr ins Rechenzentrum bringen. Wie machen wir das? Früher wurde der Verkehr von oben in Clos-Netzwerke eingeführt. Es gab also Randrouter, die mit allen Geräten am Top of Fabric verbunden waren. Diese Lösung funktioniert ziemlich gut in kleinen und mittleren Größen. Leider, um den Verkehr symmetrisch durch das gesamte Netzwerk auf diese Weise einzuführen, muss man gleichzeitig auf alle Elemente des Top of Fabric zugreifen, und wenn es mehr als hundert werden, stellt sich heraus, dass wir auch einen großen Radix an den Randroutern benötigen. Das kostet Geld, weil Randrouter funktionaler sind, die Ports darauf teurer sind, und es ergibt sich eine nicht sehr schöne Konstruktion.
Eine andere Möglichkeit ist, solchen Verkehr von unten zuzuführen. Es ist nicht schwer zu erkennen, dass die Clos-Topologie so aufgebaut ist, dass der von unten, also von der Seite des ToR, eingehende Verkehr gleichmäßig auf die Ebenen des gesamten Top of Fabric über zwei Iterationen verteilt wird und das gesamte Netzwerk belastet. Deshalb führen wir einen speziellen Typ von Pod ein, den Edge Pod, der die externe Konnektivität ermöglicht.
Es gibt noch eine Option. So macht es zum Beispiel Facebook. Dies wird bei ihnen Fabric Aggregator oder HGRID genannt. Es wird eine zusätzliche Spine-Ebene eingeführt, um mehrere Rechenzentren zu verbinden. Diese Konstruktion ist möglich, wenn wir an den Übergängen keine zusätzlichen Funktionen oder Inkapselung wechseln. Wenn dies der Fall ist, gibt es zusätzliche Touchpoints, was kompliziert ist. In der Regel entstehen mehr Funktionen und eine Art Membran, die verschiedene Teile des Rechenzentrums trennt. Eine solche Membran sollte nicht zu groß sein, aber wenn sie unbedingt benötigt wird, macht es Sinn, sie zu verlagern, so breit wie möglich zu gestalten und auf Hosts zu übertragen. So machen es viele Cloud-Anbieter. Sie haben Overlays, die von Hosts aus starten.
Welche Entwicklungsmöglichkeiten sehen wir? In erster Linie die Verbesserung der Unterstützung des CI/CD-Pipelines. Wir möchten so fliegen, wie wir testen, und so testen, wie wir fliegen. Das funktioniert nicht gut, da die Infrastruktur groß ist und es unmöglich ist, sie für Tests zu duplizieren. Wir müssen herausfinden, wie wir Testelemente in die Produktionsinfrastruktur einführen können, ohne diese zu beeinträchtigen.
Bessere Instrumentierung, besseres Monitoring sind fast immer von Vorteil. Die Frage ist das Gleichgewicht zwischen Aufwand und Ertrag. Wenn es mit angemessenem Aufwand möglich ist, ist das sehr gut.
Offene Betriebssysteme für Netzwerkgeräte. Die besten Protokolle und besten Routing-Systeme, zum Beispiel RIFT. Es sind auch Studien über den Einsatz der besten Methoden zur Congestion Control erforderlich und möglicherweise die Einführung, zumindest an einigen Punkten, der Unterstützung von RDMA innerhalb des Clusters.
Wenn wir mit Blick auf eine fernere Zukunft schauen, sind fortschrittliche Topologien erforderlich und möglicherweise Netzwerke, die einen geringeren Overhead verwenden. Neueste Entwicklungen umfassen kürzlich veröffentlichte Technologien für HPC Cray Slingshot, die auf Commodity Ethernet basieren, jedoch die Möglichkeit bieten, wesentlich kürzere Header zu verwenden. Dadurch wird der Overhead verringert.
Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher. Komplexität ist der Feind der Skalierbarkeit. Einfachheit und regelmäßige Strukturen sind unsere Freunde. Wenn irgendwo ein Scale-out möglich ist – tun Sie es. Und überhaupt, es macht jetzt Spaß, sich mit Netzwerktechnologien zu beschäftigen. Es passiert viel Interessantes. Danke.
Quelle: habr.com
