Künstliche Intelligenz (KI) und Hochleistungs-Computing (HPC) erfahren derzeit ein beträchtliches Wachstum, das durch Fortschritte in den Bereichen maschinelles Lernen, Verarbeitung natürlicher Sprache, generative KI, Robotik und autonome Systeme angetrieben wird.
Das Kernelement dieser Innovationen sind große verteilte Trainingsmodelle, die oft Milliarden oder sogar Billionen von auf mehrere GPUs aufgeteilten Parametern umfassen. Während des Trainingsprozesses tauschen diese Nodes erhebliche Mengen an zu synchronisierenden Daten und Gradienten über die KI-Ethernet-Fabric im Backend aus. Paketverluste können jedoch die Synchronisierung stark beeinträchtigen, was zur erneuten Übertragung oder zum Abbruch der Kommunikation führt, was wiederum eine erhöhte Latenz, längere Job-Abschlusszeiten (Job Completion Times, JCT) und eine ineffiziente Nutzung teurer GPU-Ressourcen zur Folge hat.
Die Herausforderung: Stille Paketverluste in der KI-Datencenter-Fabric
JCT ist eine wichtige Metrik, und moderne KI-Workloads, insbesondere umfangreiche Trainings- und Inferenzaufgaben, sind auf eine reibungslose Synchronisierung zwischen Clustern angewiesen. Schon ein einziges verlorenes Paket kann die Leistung erheblich beeinträchtigen und die Betriebskosten erhöhen.
So können RoCE-v2-Pakete etwa in der KI-Ethernet-/IP-Fabric verworfen werden, wenn die Switch-Puffer aufgrund von Verkehrsüberlastung überlaufen. Diese verlorenen Pakete müssen erneut übertragen werden, was zu Verzögerungen führt und den Ablauf des Trainings oder der Inferenz unterbricht.
Explizite Überlastungsbenachrichtigung (Explicit Congestion Notification, ECN) zeigt zwar eine Überlastung durch Markierung von Bits im IP-Header auf, gibt aber keine Auskunft darüber, welche spezifischen Pakete aufgrund von Überlastung verworfen wurden und daher erneut gesendet werden müssen.
Die Lösung: DCN (Drop Congestion Notification, Benachrichtigung über Paketverlust durch Überlastung)
Um dieses Problem zu lösen, hat Juniper die Benachrichtigung über Paketverlust durch Überlastung eingeführt, eine neue Engpassmanagement-Funktion, die in der Softwareversion 23.4x100d40 von Junos OS(TM) Evolved für die Tomahawk 5-Chip-basierten Ethernet/IP-Plattformen QFX5240-OD- und QFX5240-QD – 64 x 800GbE verfügbar ist.
Wenn eine Überlastung auftritt, sendet der Switch Benachrichtigungen über verworfene Pakete, indem er die Paketnutzlast reduziert und diese Information über eine Warteschlange mit hoher Priorität an den empfangenden Host weiterleitet. Die Transit-Switches im Netzwerk erkennen diese gestutzten, mit DCN markierten, verworfenen Pakete und leiten sie an die Warteschlange mit hoher Priorität weiter.
Infolgedessen muss der Endhost die gestutzten DCN-Pakete verarbeiten, feststellen, welche Pakete explizit aufgrund von Überlastung verworfen wurden, und umgehend eine erneute Übertragung dieser verlorenen Pakete von der Quelle anfordern.
Die gestutzten Pakete werden jedoch nicht an den Speicher des Zielservers gesendet, sondern stattdessen verwendet, um genau zu ermitteln, welche Pakete eine selektive Neuübertragung erfordern – so kann ein längerer Standard-Neuübertragungsprozess vermieden und folglich eine bessere End-to-End-Latenz für die Job-Durchführung erreicht werden.
Die folgende Abbildung zeigt eine simplifizierte Topologie, bei der Pakete, die in den ersten Switch gelangen, im Falle einer extremen Überlastung (oberhalb der ECN-Schwellenwerte) nicht verworfen, sondern stattdessen gestutzt und an die NIC-Karte des Ziel-GPU-Servers gesendet werden. Während der erste Switch den Zuschneidevorgang durchführt, können die Transit-Switches den zugeschnittenen Frame ebenfalls erkennen und ihn sofort über die hochpriorisierte Warteschlange an die ausgehende Schnittstelle weiterleiten. Sobald das zugeschnittene Paket die Ziel-NIC-Karte erreicht, wird die Anforderung zur erneuten Übertragung des Pakets an den Ursprungsserver gesendet.
Abbildung 1: Drop Congestion Notification (DCN)
Bei den Switches QFX5240-OD und QFX5240-QD werden DCN-bezogene Pakete über eine eigene, von Datenpaketen getrennte Warteschlange verarbeitet. Diese Trennung ermöglicht es Benutzern, die DCN-Paketen zugewiesene Latenz und Bandbreite effektiver zu verwalten.
Beispielkonfigurationen:
- Konfiguration, um die benutzerdefinierte L4-UDP-Portnummer als DCN-Protokollnummer festzulegen, die der Switch zur Identifizierung der DCN-Pakete verwendet. Diese Konfiguration ist UNBEDINGT erforderlich, um DCN zu aktivieren.
set class-of-service drop-congestion-notification udp-port <0.65535>
- Konfiguration, um die Ausgangswarteschlange für alle DCN-Drop-Pakete festzulegen. Dies ist eine globale Konfiguration. Die Warteschlange sollte eine der Unicast-Warteschlangen sein. Es wird erwartet, dass der Benutzer diese Warteschlange mit strenger hoher Priorität konfiguriert. Es wird auch empfohlen, die Warteschlange ausschließlich für DCN zu verwenden. Wie bei anderen COS-Funktionen wird die Warteschlange mit „Forwarding Class“ angegeben. Diese Konfiguration ist ebenfalls UNBEDINGT erforderlich, um DCN zu aktivieren.
set class-of-service drop-congestion-notification forwarding-class <FC-Name>
- Wenn QFX5240 nur als DCN-Transit fungieren soll, sind die beiden oben genannten Konfigurationen (Protokoll und Forwarding Class) ausreichend. Der Begriff „Transit“ bezieht sich hier nur auf die Identifizierung von DCN-Paketen und die Übertragung in einer Warteschlange mit hoher Priorität. Damit der QFX5240 im Falle einer Überlastung DCN-Drop-Pakete erstellen kann, ist neben den oben genannten Konfigurationen eine individuelle DCN-Konfiguration auf Portebene erforderlich.
- Konfiguration zur Aktivierung von DCN auf einzelnen Ports. Wenn DCN auf dem Port aktiviert ist, löst jeder über den Port eingehende DCN-Datenverkehr, der aufgrund von Überlastung in der MMU verworfen wird, ein DCN-Drop-Paket aus.
set class-of-service interface <Eingangsschnittstellenname> drop-congestion-notification
- Wenn der Benutzer DCN auf allen Ports aktivieren möchte, muss er einen Platzhalter verwenden, um die obige Konfiguration anzuwenden.
set class-of-service interface et-* drop-congestion-notification
- Die Konfiguration mit aktivierter DCN wird nur auf einer physischen Schnittstelle und auf dem übergeordneten AE unterstützt.
set class-of-service drop-congestion-notification forwarding-class dcn
set class-of-service drop-congestion-notification udp-port 13742
set class-of-service interface et-0/0/0 drop-congestion-notification
Befehl für DCN-Drop-Paketwerte anzeigen
root@QFX5240# run show interfaces queue et-0/0/0 forwarding-class dcn
Physical interface: et-0/0/0, up, Physical link is Down
Interface index: 1205, SNMP ifIndex: 503
Forwarding classes: 12 supported, 9 in use
Egress queues: 10 supported, 9 in use
Queue: 7, Forwarding classes: dcn
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
Tail-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
ECN-CE packets : 0 0 pps
ECN-CE bytes : 0 0 bps
Fazit:
Die Aufrechterhaltung einer gleichbleibenden Leistung und synchronisierter Abläufe ist bei KI-Ethernet-Fabrics von entscheidender Bedeutung, insbesondere wenn Workloads über verteilte GPU-Cluster hinweg skaliert werden. DCN schließt hier eine wichtige Lücke, indem es Echtzeitvisibilität für Paketverluste bei schweren Überlastungen bietet. Durch die Benachrichtigung der Endgeräte über verlorene Pakete ermöglicht DCN eine schnellere Wiederherstellung, minimiert versteckte Verzögerungen und hilft, KI-Job-Abschlusszeiten (JCTs) einzuhalten.
Letztendlich schließt DCN die Visibilitätslücke zwischen Netzwerk-Fabric und KI-Workloads und ist damit eine wichtige Voraussetzung für den Aufbau einer skalierbaren, leistungsstarken KI-Infrastruktur.
Weitere Informationen zu den KI/ML Datencenter-Funktionen finden Sie im Benutzerhandbuch.
