OcNOS 7.1 Roadmap · Durchgängig · Aufbauend auf DLB

Global Load Balancing: Fabric-weites adaptives Routing

DLB trifft die richtige Entscheidung an einem Hop; GLB trifft die richtige Entscheidung über die gesamte Fabric hinweg. Auf der OcNOS 7.1 Roadmap erweitert Global Load Balancing adaptives Routing von einer Per-Port-Sicht auf eine durchgängige Pfadqualität und schließt die Multi-Hop-Hotspot-Lücke auf dreistufigen Clos-KI-Fabrics bis zur 16,384-GPU-Obergrenze. GLB baut auf DLB auf, statt es zu ersetzen.

OcNOS 7.1GLB Zieltermin
End-to-EndPath-Scoring, nicht lokaler Hop
16,384GPU-Obergrenze, Referenzdesign
Auf DLB aufgesetzterweitert, ersetzt nie
Durchgängige Pfad-Telemetrie

Bewertung des gesamten Pfads, nicht nur des lokalen Hops

Ein dreistufiger Clos-Ausschnitt (Leaf, Spine, Super-Spine), der GPU-AllReduce überträgt. Jede Ebene streamt Telemetrie zu Queue-Belegung und Link-Auslastung zurück zu den Ingress-Leaves. GLB wählt den Pfad mit dem besten durchgängigen Score, nicht mit dem besten lokalen Egress-Score, sodass ein sauberer Uplink, der auf einem überlasteten Downlink landet, nicht mehr blind ausgewählt wird.

Global Load Balancing über eine 3-stufige Clos-AI-Fabric Dreistufige Clos-AI-Fabric. Zwei Super-Spines oben, vier Spines in der Mitte, zwei Leaves unten. Telemetrie-Pfeile verlaufen nach oben und wieder zurück nach unten, sodass das Ingress-Leaf die durchgängige Pfadqualität sieht. Eine Spine-zu-Super-Spine-Verbindung ist überlastet und wird zugunsten eines alternativen durchgängigen Pfads umgangen. durchgängige Telemetrie Super-Spine-1TH5 · 51.2T Super-Spine-2TH5 · 51.2T Spine-1e2e ok Spine-2e2e ok Spine-3Uplink ausgelastet Spine-4e2e ok Ingress-LeafGLB · ranks paths Egress-LeafZiel-Rack GLB · END-TO-END PATH SCORING · MULTI-HOP CONGESTION AWARENESS · OcNOS 7.1
Wo die lokale Sicht versagt

DLB und GLB, nach Reichweite der Pfadentscheidung

DLB bewertet jeden ECMP-Next-Hop anhand der lokalen Egress-Queue-Tiefe, was auf einer zweistufigen Leaf-Spine optimal ist. Skaliert man auf eine dreistufige Clos, kann man eine Spine mit sauberem Uplink wählen und trotzdem auf einer Super-Spine landen, deren Downlink zurück zum Egress-Leaf überlastet ist. Die lokale Sicht ist korrekt; die durchgängige Sicht ist falsch. Bei Fabrics mit 1,024 GPUs und mehr, wo dreistufige Clos mit Super-Spines zum Standard werden, ist dies die dominierende verbleibende Quelle von Tail-Latenz-Ausreißern.

Axis DLBlokal, heute verfügbar GLBglobal, OcNOS 7.1 Roadmap
Reichweite der EntscheidungPer-Hop: Jeder Switch bewertet seine eigenen ECMP-Next-Hops.Durchgängig: Ingress-Leaves bewerten vollständige Leaf-zu-Leaf-Pfade.
Signal usedLokale Egress-Queue-Tiefe und Link-Auslastung auf diesem Switch.Überlastungs-Telemetrie, aggregiert aus jeder Ebene, zurück zum Ingress.
Beste PassungZweistufige Fabrics und der Leaf-zu-Spine-Hop in dreistufigen.Dreistufige Clos mit Super-Spines, bis zur 16,384-GPU-Obergrenze.
Erkannter HotspotNur lokale Egress-Überlastung.Downstream-Hotspots, die der lokale Hop nicht sehen kann.
RebindingFlowlet-ausgerichtet, In-Order für RoCEv2 und TCP.Flowlet-ausgerichtet, dieselbe In-Order-Garantie, Eingabe über die gesamte Fabric.
HardwareTH4 und TH5 heute.Dieselbe TH4- und TH5-Hardware, kein neues Silizium.
RelationshipUnabhängige Entscheidung an jedem Switch.Baut auf DLB auf; ersetzt es nicht.
Wie GLB sie schließt

Eine Entscheidung, informiert durch die gesamte Fabric

GLB nutzt die Adaptive-Routing-Mechanik wieder, die Betreiber bereits einsetzen, und ergänzt sie um ein Fabric-weites Bewusstsein. Es baut direkt auf DLB und RoCEv2 auf und bleibt auf die Entwicklungsrichtung von Ultra Ethernet abgestimmt.

Builds on

Die DLB-Entscheidung

GLB erweitert die DLB Flowlet-Entscheidung, statt sie zu ersetzen. Gemischte Fabrics funktionieren korrekt: Nicht-GLB-Switches steuern während eines rollierenden Upgrades einfach eine rein lokale Pfadqualität bei.

Runs over

Eine verlustfreie RoCEv2-Fabric

GLB bindet an Flowlet-Grenzen um und bewahrt die In-Order-Zustellung, die RoCEv2 RDMA benötigt. Der Transport bleibt produktionsreif; nur die Pfadeingabe wird intelligenter.

Abgestimmt auf

Ultra Ethernet-Signalisierung

Die Pfadqualitäts-Ebene wird so konzipiert, dass sie mit Ultra Ethernet Consortium-Signalisierung interoperiert, sobald die UEC-NIC-Ökosysteme reifen, sodass die Roadmap vorwärtskompatibel bleibt.

Innerhalb von OcNOS 7.1

Wie die geplante GLB-Implementierung zusammenpasst

GLB wird durch OcNOS als Netzwerkbetriebssystem auf offener Broadcom-basierter Hardware ermöglicht. Das Design hält die Control Plane ruhig und liefert Betreibern die Telemetrie, die sie benötigen, um den Entscheidungen der Fabric zu vertrauen.

Telemetrie-Ebene

Path-Quality-Publish

Jede Spine und Super-Spine veröffentlicht Per-Port-Queue-Belegung und Auslastungs-Deltas an eine Fabric-weite Nachbarschaft. Updates erfolgen im Sub-Millisekunden-Bereich über bestehende In-Band-Signalisierung, ohne zusätzlichen Control-Plane-Overhead.

Path-Scoring

Durchgängige Aggregation

Ingress-Leaves kombinieren die lokale Egress-Qualität mit Downstream-Telemetrie zu einem Gesamt-Score pro Kandidatenpfad. Der schlechteste Hop dominiert den Score, dieselbe Intuition, die Betreiber bei der Fehlersuche nutzen.

Selection

Flowlet-aligned

Wie DLB bindet GLB an Flowlet-Grenzen neu und bewahrt dabei die In-Order-Zustellung für RoCEv2 und TCP. Der Unterschied liegt in der Entscheidungsgrundlage: die Qualität des gesamten Fabrics, nicht die des lokalen Ports.

Backwards-compatible

Auf DLB aufgesetzt

GLB erweitert die DLB-Entscheidung; es ersetzt sie nicht. Gemischte Fabrics mit GLB-fähigen und reinen DLB-Switches verhalten sich korrekt, sodass Brownfield-Upgrades von 7.0 sicher sind.

Skalieren

Bis zur Obergrenze von 16k GPU

Referenzdesigns verwenden 256 Spine-Switches und 128 Super-Spine-Switches, jeweils ein 64x800G Tomahawk 5, dimensioniert auf die architektonische 16,384-GPU-Obergrenze.

Telemetrie-Ausgabe

gNMI für das Ops-Team

Per-Pfad-Scores, Rebind-Ereignisse und Worst-Hop-Zuordnung werden über gNMI und OpenConfig gestreamt, sodass SREs Fabric-Entscheidungen ohne Blackbox mit dem Verhalten von xCCL-Kollektivjobs korrelieren können.

Roadmap und Verfügbarkeit

Was Sie erwartet, wenn GLB erscheint

GLB steht auf der OcNOS 7.1 Roadmap. Es zielt auf dieselbe Hardware und Lizenzierung ab, die Betreiber bereits einsetzen, sodass die Einführung ein Upgrade statt eines Komplettaustauschs ist.

  • OcNOS 7.1 Roadmap. GLB zielt auf den 7.1 OcNOS-DC-Zweig ab, auf derselben TH4- und TH5-Hardware, die heute DLB ausführt. Zeitplan und Funktionsumfang unter OcNOS-Releases-Seite.
  • Gleiche SKU. Geplant für OcNOS-DC PLUS: keine Paywall pro Funktion, keine neuen Lizenzschlüssel zum Upgrade-Zeitpunkt.
  • In-Place-Upgrade. Das Brownfield-Upgrade von 7.0 auf 7.1 wird unterstützt; Fabrics mit gemischten Versionen funktionieren mit reinem DLB-Verhalten während des Upgrade-Fensters weiter.
  • UEC-aligned. Die Pfadqualitäts-Ebene wird so konzipiert, dass sie mit der Signalisierung des Ultra Ethernet Consortium interoperiert, sobald die UEC-NIC-Ökosysteme reifen. Siehe Ultra Ethernet (UEC).
  • Architektur-Review verfügbar. Wenn Sie eine Fabric mit mehr als 1,000 GPUs dimensionieren, führen wir eine Sizing-Analyse durch, die die GLB-Telemetrie-Ebene einbezieht. Erhalten Sie einen ersten Leaf-Spine-Entwurf mit der AI Fabric Design Suite.
Die Sichtweise von IP Infusion

DLB ist heute die Basis, GLB hebt als Nächstes die Obergrenze

Adaptives Routing löst reale Tail-Latenz bereits im zweistufigen Maßstab. GLB trägt dieselbe Disziplin hinauf in die dreistufigen Fabrics, in denen die größten Cluster beheimatet sind, auf offener Hardware, die Sie bereits validieren.

DLB löst den Regelfall

Auf zweistufiger Leaf-Spine und beim Leaf-zu-Spine-Hop beseitigt lokales adaptives Routing bereits die meisten ECMP-Kollisionen. Das ist heute auf TH4 und TH5 verfügbar.

GLB löst den Skalierungsfall

Ab 1,024 GPUs werden Multi-Hop-Hotspots zum dominierenden Ausreißer. GLB bewertet vollständige Pfade, sodass das Ingress-Leaf nicht länger einem sauberen Uplink in einen überlasteten Downlink folgt.

OcNOS ist der Enabler

Ein NOS, eine Feature-Roadmap: DLB heute, GLB als Nächstes, durchgängig RoCEv2- und UEC-abgestimmt, auf validierter offener Hardware statt auf einer Single-Vendor-Fabric.

FAQ

Global Load Balancing, erklärt

Worin unterscheidet sich GLB von DLB?
DLB bewertet jeden Next-Hop anhand der lokalen ausgangsseitigen Queue-Tiefe eines einzelnen Switches, was auf einem zweistufigen Leaf-Spine optimal ist. GLB aggregiert Congestion-Telemetrie aus jeder Stufe, sodass Ingress-Leafs vollständige Leaf-zu-Leaf-Pfade bewerten und nachgelagerte Hot-Spots erkennen, die der lokalen Sicht auf dreistufigen Clos-Fabrics entgehen.
Wann ist GLB verfügbar?
GLB steht auf der OcNOS 7.1 Roadmap und zielt auf den OcNOS-DC-Zweig ab, auf derselben Tomahawk 4- und 5-Hardware, die heute DLB ausführt. Es ist für den OcNOS-DC PLUS SKU geplant, ohne neue Lizenzschlüssel zum Upgrade-Zeitpunkt.
Muss ich DLB ersetzen, um GLB zu nutzen?
Nein. GLB setzt auf der DLB-Entscheidung auf, statt sie zu ersetzen. Gemischte Fabrics arbeiten korrekt: Switches ohne GLB-Fähigkeit steuern lediglich rein lokale Pfadqualität bei, und Brownfield-Upgrades ab 7.0 werden unterstützt.
Wie große Fabrics unterstützt GLB?
Referenzdesigns verwenden 256 Spine-Switches und 128 Super-Spine-Switches, jeweils ein 64x800G Tomahawk 5, dimensioniert auf die architektonische 16,384-GPU-Obergrenze.

Sie dimensionieren eine Fabric mit mehreren Tausend GPUs? Lassen Sie uns die Zahlen gemeinsam durchrechnen

Nennen Sie uns den Workload und die GPU-Größenordnung, und ein IP Infusion Engineer dimensioniert gemeinsam mit Ihnen die GLB-Telemetrie-Ebene, oder beginnen Sie mit einem ersten Leaf-Spine-Entwurf in der AI Fabric Design Suite.