RoCE-Technologie im High-Performance-Computing: Einblicke und Anwendungen

Die Entwicklung von HPC-Netzwerken und das Entstehen von RoCE

In der Anfangszeit von HPC-Systemen (High-Performance-Computing) wurden spezialisierte Netzwerklösungen wie Myrinet, Quadrics und InfiniBand in der Regel dem Ethernet vorgezogen. Diese benutzerdefinierten Netzwerke beseitigten effektiv die Einschränkungen von Ethernet-Lösungen und boten eine höhere Bandbreite, geringere Latenzzeiten, eine verbesserte Staukontrolle und besondere Funktionen. Im Jahr 2010 führte die IBTA den Protokolltechnologiestandard RoCE (RDMA over Converged Ethernet) ein, gefolgt von der Veröffentlichung des Protokolltechnologiestandards RoCEv2 im Jahr 2014, der eine erhebliche Steigerung der Bandbreite brachte. Die bemerkenswerten Verbesserungen der Ethernet-Leistung haben ein zunehmendes Interesse an Hochleistungs-Netzwerklösungen geweckt, die mit herkömmlichem Ethernet kompatibel sind. Diese Veränderung hat den rückläufigen Trend der Ethernet-Nutzung in HPC-Clustern, unterbrochen und dem Ethernet ermöglicht, eine herausragende Position in der Rangliste zu behalten (in den Top 500).

Während Myrinet und Quadrics von der Bildfläche verschwunden sind, spielt InfiniBand weiterhin eine entscheidende Rolle in Hochleistungs-Netzwerken. Darüber hinaus spielen auch die proprietären Netzwerkserien von Cray, Tianhe und Tofulseries eine wichtige Rolle.

Einführung in das RoCE-Protokoll

Das RoCE-Protokoll dient als Clusternetzwerk-Kommunikationsprotokoll, das Remote Direct Memory Access (RDMA) über Ethernet ermöglicht. Dieses Protokoll überträgt Aufgaben zum Senden und Empfangen von Paketen an die Netzwerkkarte, sodass das System nicht in den Kernel-Modus wechseln muss, wie es für das TCP/IP-Protokoll typisch ist. Dadurch wird der mit dem Kopieren, Einkapseln und Entkapseln verbundene Overhead reduziert, was zu einer erheblichen Verringerung der Latenzzeit bei der Ethernet-Kommunikation führt. Darüber hinaus wird die Auslastung der CPU-Ressourcen während der Kommunikation minimiert, die Überlastung des Netzwerks verringert und die effiziente Nutzung der Bandbreite verbessert.

Das RoCE-Protokoll besteht aus zwei Versionen: RoCE v1 und RoCE v2. RoCE v1 arbeitet mit dem Sicherungsschicht-Protokoll (auch „Link-Layer-Protokoll“) und erfordert, dass sich beide kommunizierenden Parteien im selben Schicht-2-Netzwerk befinden. Im Gegensatz dazu arbeitet RoCE v2 als Vermittlungsschicht-Protokoll (auch „Network-Layer-Protokoll“), sodass RoCE v2-Protokollpakete auf Schicht 3 weitergeleitet werden können, was eine bessere Skalierbarkeit ermöglicht.

RoCE V1 Protocol

Das RoCE-Protokoll behält die Schnittstelle, die Transportschicht und die Vermittlungsschicht von InfiniBand (IB) bei, ersetzt aber die Sicherungsschicht und die Bitübertragungsschicht von IB durch die Sicherungsschicht und die Vermittlungsschicht von Ethernet. Im Sicherungsschicht-Datenframe eines RoCE-Datenpakets ist der Wert des Ethertype-Feldes von der IEEE mit 0x8915 spezifiziert, wodurch es eindeutig als RoCE-Datenpaket identifiziert wird. Da das RoCE-Protokoll jedoch die Ethernet-Vermittlungsschicht nicht übernimmt, fehlt den RoCE-Datenpaketen ein IP-Feld. Folglich ist ein Routing auf der Vermittlungsschicht für RoCE-Datenpakete nicht möglich, sodass ihre Übertragung auf das Routing innerhalb eines Schicht-2-Netzwerks beschränkt ist.

RoCE V2 Protocol

Mit dem RoCE v2-Protokoll kommen wesentliche Verbesserungen. Es baut auf der Grundlage des RoCE-Protokolls auf. RoCEv2 wandelt die vom RoCE-Protokoll verwendete InfiniBand (IB)- Vermittlungsschicht um, indem es die Ethernet- Vermittlungsschicht und eine Transportschicht, die das UDP-Protokoll verwendet, einbezieht. Es nutzt die DSCP- und ECN-Felder innerhalb des IP-Datagramms der Ethernet- Vermittlungsschicht zur Implementierung der Staukontrolle. Dadurch können die Pakete des RoCE v2-Protokolls einem Routing unterzogen werden, was eine bessere Skalierbarkeit gewährleistet. Da RoCEv2 das ursprüngliche RoCE-Protokoll vollständig ersetzt, beziehen sich Referenzen auf das RoCE-Protokoll im Allgemeinen auf das RoCE v2-Protokoll, es sei denn, es wird ausdrücklich als die erste Generation von RoCE bezeichnet.

Verlustfreie Netze und RoCE-Staukontrollmechanismen

Die Gewährleistung einer nahtlosen Übertragung des RoCE-Datenverkehrs ist in RoCE-Protokoll-basierten Netzwerken von zentraler Bedeutung. Bei der RDMA-Kommunikation ist es unerlässlich, dass die Datenpakete ihr Ziel ohne Verlust und in der richtigen Reihenfolge erreichen. Jeder Paketverlust oder jede Ankunft in falscher Reihenfolge erfordert eine Go-back-N-Neuübertragung. Zudem sollten nachfolgende Datenpakete, deren Ankunft erwartet wird, nicht im Cache gespeichert werden.

Das RoCE-Protokoll implementiert einen zweifachen Staukontrollmechanismus: eine Anfangsphase, in der DCQCN (Datacenter Quantized Congestion Notification) für eine graduelle Verlangsamung genutzt wird und eine anschließende Übertragungspausenphase, in der PFC (Priority Flow Control) zum Einsatz kommt. Obwohl sie strenggenommen als Staukontrollstrategie bzw. als Datenverkehrssteuerungsstrategie eingestuft werden, werden sie üblicherweise als die beiden Stufen der Staukontrolle betrachtet.

In Szenarien mit Mehrfachkommunikation innerhalb eines Netzwerkes kommt es häufig zu Überlastungen, die sich in einem raschen Anstieg der Gesamtgröße der anstehenden Sendepuffer-Nachrichten an einem Port des Switches zeigen. Unkontrollierte Situationen können zu einer Pufferüberlastung führen, was einen Paketverlust zur Folge hat. Daher markiert der Switch in der Anfangsphase, wenn er feststellt, dass die Gesamtgröße der anstehenden Übertragungspuffer-Nachrichten an einem Port einen bestimmten Schwellenwert erreicht, das ECN-Feld der IP-Schicht im RoCE-Datenpaket. Wenn der Empfänger beim Empfang dieses Pakets das vom Switch markierte ECN-Feld bemerkt, überträgt er ein Congestion Notification Packet (CNP) an den Absender zurück und fordert diesen auf, seine Übertragungsgeschwindigkeit zu verringern.

Entscheidend ist, dass nicht alle Pakete markiert werden, wenn der Schwellenwert für das ECN-Feld erreicht ist. Zwei Parameter, Kmin und Kmax, spielen bei diesem Prozess eine Rolle. Wenn die Länge der Warteschlange unter Kmin liegt, erfolgt keine Markierung. Wenn die Länge der Warteschlange zwischen Kmin und Kmax liegt, steigt die Wahrscheinlichkeit einer Markierung mit einer längeren Warteschlange. Wenn die Länge der Warteschlange Kmax übersteigt, werden alle Pakete markiert. Der Empfänger überträgt nicht für jedes empfangene ECN-Paket ein CNP-Paket, sondern sendet in einem Intervall ein CNP-Paket, wenn er Pakete mit ECN-Markierungen erhält. Dieser Ansatz ermöglicht es dem Sender, seine Übertragungsgeschwindigkeit an die Anzahl der empfangenen CNP-Pakete anzupassen.

In Fällen, in denen sich die Netzüberlastung verschlimmert und der Switch feststellt, dass die Länge der Warteschlange eines bestimmten Ports einen höheren Schwellenwert erreicht, sendet der Switch einen Pause Flow Control Frame (PFC) an den Upstream-Sender der Nachrichten. Dadurch wird die Datenübertragung unterbrochen, bis die Überlastung des Switches behoben ist. Sobald die Überlastung behoben ist, sendet der Switch einen PFC-Control-Frame an den Upstream, um die Wiederaufnahme der Übertragung zu signalisieren. Die PFC-Flusssteuerung unterstützt die Unterbrechung auf verschiedenen Datenverkehrskanälen und ermöglicht die Anpassung des Bandbreitenverhältnisses für jeden Kanal an die Gesamtbandbreite. Diese Konfiguration ermöglicht die Unterbrechung der Datenverkehrsübertragung auf einem Kanal, ohne die Datenübertragung auf anderen Kanälen zu beeinträchtigen.

ROCE & Soft-RoCE

Obwohl die meisten Hochleistungs-Ethernet-Karten das RoCE-Protokoll inzwischen unterstützen, kommt es immer noch vor, dass bestimmte Karten keine Unterstützung bieten. Um dieses Problem zu beheben, wurde in Zusammenarbeit mit IBIV, Mellanox und anderen Partnern das Open-Source-Projekt Soft-RoCE ins Leben gerufen. Diese Initiative richtet sich an Netzwerkknoten, die mit nicht unterstützten RoCE-Protokollkarten ausgestattet sind und ermöglicht ihnen die Nutzung von Soft-RoCE für die Kommunikation mit Knoten, die mit RoCE-unterstützten Karten ausgestattet sind (siehe Abbildung). Dies erhöht zwar nicht die Leistung der ersteren, erleichtert es aber den letzteren, ihre Leistungsmöglichkeiten voll auszuschöpfen. Insbesondere in Szenarien wie Rechenzentren kann ein strategisches Upgrade, das sich auf Speicherserver mit hoher E/A-Leistung und RoCE-unterstützten Ethernet-Karten beschränkt, die Gesamtleistung und Skalierbarkeit erheblich steigern. Darüber hinaus erweist sich die Kombination von RoCE und Soft-RoCE als anpassungsfähig an die Anforderungen schrittweiser Cluster-Upgrades, wodurch die Notwendigkeit eines gleichzeitigen, umfassenden Upgrades entfällt.

Herausforderungen bei der Implementierung von RoCE in HPC-Umgebungen

Grundlegende Anforderungen an HPC-Netzwerke

Wie von FS dargelegt, sind HPC-Netzwerke von zwei grundlegenden Voraussetzungen abhängig: (1.) niedrige Latenzzeiten und (2.) die Fähigkeit, niedrige Latenzzeiten bei sich schnell entwickelnden Verkehrsmustern aufrechtzuerhalten.

RoCE wurde speziell entwickelt, um das Problem der niedrigen Latenzen (1.) zu lösen. Wie bereits erwähnt, verlagert RoCE die Netzwerkoperationen effizient auf die Netzwerkkarte, was zu einer niedrigen Latenz und einer geringeren CPU-Auslastung führt.

Um eine niedrige Latenz bei sich dynamisch ändernden Datenverkehrsmustern aufrechtzuerhalten (2.), liegt das Hauptaugenmerk auf der Staukontrolle. Die Komplexität hochdynamischer HPC-Datenverkehrsmuster stellt eine Herausforderung für RoCE dar und führt in dieser Hinsicht zu suboptimaler Leistung.

ROCEs geringe Latenz

Im Gegensatz zu herkömmlichen TCP/IP-Netzwerken umgehen sowohl InfiniBand als auch RoCEv2 den Kernel-Protokoll-Stack, was zu einer erheblichen Verbesserung der Latenzleistung führt. Empirisch bewiesene Tests haben gezeigt, dass die Umgehung des Kernel-Protokoll-Stacks die End-to-End-Latenz auf der Anwendungsschicht innerhalb desselben Clusters von 50 Mikrosekunden (TCP/IP) auf 5 Mikrosekunden (RoCE) oder sogar 2 Mikrosekunden (InfiniBand) reduzieren kann.

RoCE-Paketstruktur

Angenommen, wir wollen 1 Byte Daten mit RoCE senden, dann sind die zusätzlichen Aufwendungen für die Verkapselung dieses 1-Byte-Datenpakets wie folgt:

Ethernet-Sicherungsschicht: 14 Byte MAC-Header + 4 Byte CRC

Ethernet IP-Schicht: 20 Bytes

Ethernet UDP-Schicht: 8 Bytes

IB-Transportschicht: 12 Bytes Basis-Transport-Header (BTH)

Insgesamt: 58 Bytes

Angenommen, wir wollen 1 Byte Daten mit IB senden, dann sind die zusätzlichen Aufwendungen für die Verkapselung dieses 1-Byte-Datenpakets wie folgt:

IB-Sicherungsschicht: 8 Byte Local Routing Header (LHR) + 6 Byte CRC

IB-Vermittlungsschicht: 0 Bytes (Wenn es nur ein Schicht-2-Netzwerk gibt, kann das Link Next Header (LNH) Feld in der Sicherungsschicht angeben, dass das Paket keine Vermittlungsschicht hat)

IB-Transportschicht: 12 Bytes Basis-Transport-Header (BTH)

Insgesamt: 26 Bytes

Handelt es sich um ein kundenspezifisches Netzwerk, kann die Paketstruktur weiter vereinfacht werden. Der Mini-Packet (MP) Header von Tianhe-1A besteht zum Beispiel aus 8 Bytes.

Daraus ist ersichtlich, dass die schwerfällige Grundstruktur von Ethernet eines der Hindernisse für die Anwendung von RoCE auf HPC ist.

Ethernet-Switches in Rechenzentren müssen oft über viele andere Funktionen verfügen, deren Implementierung zusätzliche Kosten verursacht, wie z. B. SDN, Qos und so weiter.

Sind Ethernet und RoCE mit diesen Funktionen kompatibel? Beeinträchtigen diese Funktionalitäten die Leistung von RoCE?

Herausforderungen bei der RoCE-Staukontrolle

Die Staukontrollmechanismen in beiden Teilen des RoCE-Protokolls stellen besondere Herausforderungen dar, die die Aufrechterhaltung einer niedrigen Latenz bei dynamischen Datenverkehrsmustern behindern können.

Die Priority Flow Control (PFC) stützt sich auf Pausen-Control-Frames, um den Empfang einer übermäßigen Anzahl von Paketen zu verhindern, eine Strategie, die anfällig für Paketverluste ist. Im Gegensatz zu credit-basierten Methoden führt PFC tendenziell zu einer geringeren Puffernutzung, was insbesondere für Switches mit begrenzten Puffern eine Herausforderung darstellt, die häufig mit einer geringeren Latenz einhergeht. Umgekehrt bieten credit-basierte Ansätze eine präzisere Pufferverwaltung.

Data Center Quantized Congestion Notification (DCQCN) in RoCE, das der InfiniBand-Staukontrolle ähnelt, verwendet Backward Notification, d. h. die Überlastungsinformationen werden an das Ziel übermittelt und dann zur Ratenbegrenzung an den Sender zurückgegeben. Während RoCE einem festen Satz von Formeln für Verlangsamungs- und Beschleunigungsstrategien folgt, erlaubt InfiniBand anpassbare Strategien, die mehr Flexibilität bieten. Zwar werden in der Regel Standardkonfigurationen verwendet, doch ist die individuelle Anpassung vorzuziehen. Bei den Tests in der genannten Veröffentlichung wurde höchstens ein Congestion Notification Packet (CNP) alle N=50 Mikrosekunden generiert. Noch ist es nicht sicher, ob dieser Wert weiter reduziert werden kann. In InfiniBand kann der CCTI_Timer auf bis zu 1,024 Mikrosekunden eingestellt werden, obwohl die praktische Umsetzung eines so kleinen Wertes ebenfalls nicht sicher ist.

Ein idealer Ansatz wäre die direkte Rückmeldung von Überlastungsinformationen vom Überlastungspunkt an die Quelle, die so genannte Forward Notification. Während die Einschränkungen von Ethernet aufgrund der Spezifikationen bekannt sind, wirft die Begründung, warum InfiniBand diesen Ansatz nicht übernimmt, Fragen auf.

RoCE-Anwendungen im HPC: Slingshot-Tests und Leistungstests

Die neuesten Supercomputer in den Vereinigten Staaten verfügen über das innovative Slingshot-Netzwerk, eine verbesserte Version von Ethernet. Das Netzwerk nutzt Rosetta-Switches, die mit herkömmlichem Ethernet kompatibel sind und auf die spezifischen Einschränkungen von RoCE eingeht. Erweiterte Funktionen kommen ins Spiel, wenn beide Enden einer Verbindung dedizierte Geräte wie Netzwerkkarten und Rosetta-Switches unterstützen. Zu diesen Funktionen gehören die Minimierung der IP-Paket-Frame-Größe auf 32 Byte, die gemeinsame Nutzung von Warteschlangenbelegungsinformationen mit benachbarten Switches und die Implementierung einer verbesserten Staukontrolle. Die durchschnittliche Switch-Latenz von 350 ns ist zwar mit Hochleistungs-Ethernet-Switches vergleichbar, bleibt aber hinter der niedrigen Latenz zurück, die von InfiniBand (IB) und einigen spezialisierten Supercomputer-Switches erreicht wird, einschließlich der vorherigen Generation der Cray XC-Supercomputer-Switches.

In praktischen Anwendungen zeigt das Slingshot-Netzwerk eine lobenswerte Leistung. In der Arbeit „An In-Depth Analysis of the Slingshot Interconnect“ wird es in erster Linie mit der vorherigen Generation von Cray-Supercomputern verglichen, wobei ein direkter Vergleich mit InfiniBand fehlt.

Darüber hinaus wurden die CESM- und GROMACS-Anwendungen sowohl mit 25G-Ethernet mit niedriger Latenz als auch mit 100G-Ethernet mit höherer Bandbreite getestet. Trotz des vierfachen Bandbreitenunterschieds zwischen den beiden bieten die Ergebnisse wertvolle Einblicke in ihre vergleichbare Leistung.

Fazit

Mit einem kompetenten technischen Team und umfassender Erfahrung in verschiedenen Anwendungsszenarien hat sich FS das Vertrauen und die Wertschätzung der Kunden erworben. FS ist sich jedoch der Herausforderungen bei der Anwendung von RoCE auf High-Performance-Computing (HPC) bewusst, die sich aus den Anforderungen des Marktes und den Erfahrungen bei der Implementierung von Anwenderprojekten ergeben:

• - Ethernet-Switches weisen im Vergleich zu IB-Switches und bestimmten kundenspezifischen HPC-Netzwerk-Switches eine höhere Latenz auf.

• Die Flusssteuerungs- und Staukontrollstrategien von RoCE sind verbesserungswürdig.

• Die Kosten für Ethernet-Switches sind nach wie vor relativ hoch.

Im Kontext der sich schnell entwickelnden Rechenzentrumsnetzwerke ist die Wahl einer geeigneten Lösung von entscheidender Bedeutung. Traditionelle TCP/IP-Protokolle reichen für Anwendungen, die eine hohe Netzwerkleistung erfordern, nicht mehr aus. Die RDMA-Technologie, insbesondere in Form von InfiniBand und RoCE, hat sich zu einer hoch angesehenen Netzwerklösung entwickelt. InfiniBand hat in Bereichen wie High-Performance-Computing und großen GPU-Clustern eine außergewöhnliche Leistung gezeigt. Im Gegensatz dazu bietet RoCE, eine auf Ethernet basierende RDMA-Technologie, mehr Flexibilität bei der Implementierung.

Für diejenigen, die hochleistungsfähige und effiziente Rechenzentrumsnetzwerke suchen, ist die Auswahl der richtigen Netzwerklösung, die auf die spezifischen Anforderungen und Anwendungsszenarien zugeschnitten ist, ein entscheidender Schritt. FS bietet eine Reihe von Produkten an, darunter NVIDIA® InfiniBand Switches, 100G/200G/400G/800G InfiniBand Transceiver and NVIDIA® InfiniBand Adapter. FS hat sich damit als professioneller Anbieter von Kommunikations- und Hochgeschwindigkeits-Netzwerksystemlösungen für Netzwerke, Rechenzentren und die Telekommunikation etabliert.