Infiniband
InfiniBand ist ein verlustfreier Interconnect mit eigenem Protokollstapel für HPC- und KI-Cluster, spezifiziert von der IBTA seit 1999.
Herkunft
InfiniBand entstand 1999 aus der Zusammenlegung der konkurrierenden Entwürfe Future I/O (Compaq, IBM, HP) und Next Generation I/O (Intel, Microsoft, Sun). Ursprüngliches Ziel war ein universeller System-I/O-Bus als Ersatz für PCI. Dieses Ziel verfehlte die Technik; als Cluster-Interconnect für Supercomputer setzte sie sich ab etwa 2003 durch. Die InfiniBand Trade Association (IBTA) pflegt die Spezifikation bis heute und definiert darin auch RoCE.
Architektur
InfiniBand ist kein Ethernet-Derivat, sondern ein vollständiger eigener Stack von der Bitübertragung bis zum Transport. Alle Schichten sind auf verlustfreie Übertragung mit niedriger Latenz ausgelegt.
- Physical Layer: serielle Lanes, gebündelt zu 1x-, 4x- oder 12x-Links. Marktüblich sind 4x-Links.
- Link Layer: Adressierung per LID (Local Identifier, 16 Bit), Virtual Lanes für Dienstgüte, kreditbasierte Flusskontrolle.
- Network Layer: Routing zwischen Subnetzen per GID (Global Identifier, 128 Bit) und Global Route Header. In der Praxis selten genutzt; fast alle Fabrics sind ein einziges Subnetz.
- Transport Layer: Queue Pairs, Dienstklassen RC/UC/UD, RDMA-Operationen. Identisch mit dem Transport von RoCE (siehe RDMA).
Komponenten sind Host Channel Adapter (HCA) im Server, Switches und der Subnet Manager. Router für Subnetzübergänge existieren, spielen aber kaum eine Rolle.
Flusskontrolle
InfiniBand vermeidet Paketverluste durch Credits (Kredite): Ein Sender darf nur so viele Daten schicken, wie der Empfänger zuvor Pufferplatz zugesichert hat. Die Kredite werden pro Virtual Lane vergeben, sodass ein blockierter Verkehrsstrom die anderen nicht aufhält. Dieses Verfahren ist Teil des Standards und muss nicht wie bei RoCEv2 über PFC und ECN nachgebildet werden. Es ist der wesentliche Grund, warum InfiniBand-Fabrics ohne Feinabstimmung der Switches stabil laufen.
Subnet Manager
Jedes InfiniBand-Subnetz braucht genau einen aktiven Subnet Manager (SM), weitere können im Standby laufen. Der SM erkennt die Topologie, vergibt LIDs, berechnet die Weiterleitungstabellen aller Switches und lädt sie per Management Datagram (MAD) hoch. Switches selbst treffen keine Routing-Entscheidungen. Der SM läuft auf einem Server (OpenSM aus rdma-core) oder auf einem Managed Switch.
Routing-Algorithmen des SM (Min-Hop, Up/Down, Fat-Tree, Adaptive Routing) bestimmen, wie gut eine Topologie ausgelastet wird. Für Fat-Tree-Cluster gibt es dedizierte Algorithmen, die Blockierungsfreiheit sicherstellen.
Datenraten
| Generation | Rate pro Lane | 4x-Link | Kodierung | Spezifikation |
|---|---|---|---|---|
| SDR | 2,5 Gb/s | 10 Gb/s | 8b/10b | 2000 |
| DDR | 5 Gb/s | 20 Gb/s | 8b/10b | 2005 |
| QDR | 10 Gb/s | 40 Gb/s | 8b/10b | 2008 |
| FDR | 14,0625 Gb/s | 56 Gb/s | 64b/66b | 2011 |
| EDR | 25,78125 Gb/s | 100 Gb/s | 64b/66b | 2014 |
| HDR | 50 Gb/s (PAM4) | 200 Gb/s | 64b/66b | 2017 |
| NDR | 100 Gb/s (PAM4) | 400 Gb/s | 64b/66b | 2020 |
| XDR | 200 Gb/s (PAM4) | 800 Gb/s | 64b/66b | 2023/2024 |
Die Rate pro Lane entspricht ab FDR nicht mehr glatt der Nutzdatenrate, weil 64b/66b-Kodierung und FEC einfließen. Ab HDR nutzt InfiniBand PAM4-Signalisierung wie Ethernet; die physikalischen Schnittstellen (QSFP56, OSFP, QSFP-DD) und Kabel (DAC, AOC) sind mit denen von 200G/400G/800G-Ethernet weitgehend baugleich. Volume 1 Release 1.8 (September 2024) spezifiziert XDR mit 800 Gb/s über QSFP und 1600 Gb/s über QSFP-DD/OSFP für Switch-zu-Switch-Verbindungen.
Die Latenz eines Switch-Hops liegt bei aktuellen Generationen unter 200 ns, Ende-zu-Ende zwischen zwei HCAs unter 1 µs.
Topologien
Übliche Cluster-Topologien sind Fat-Tree (Clos) in zwei oder drei Stufen sowie Dragonfly+ für sehr große Systeme. Für KI-Cluster hat sich die Rail-optimized-Variante des Fat-Tree etabliert, bei der jede GPU eines Servers an einen eigenen Leaf-Switch angebunden ist. Die maximale Größe eines Subnetzes ist durch den 16-Bit-LID-Raum auf rund 48.000 Endpunkte begrenzt.
Abgrenzung zu RoCEv2 und Ultra Ethernet
InfiniBand und RoCEv2 nutzen dasselbe Transportprotokoll und dieselbe Verbs-API. Anwendungen laufen ohne Änderung auf beiden. Der Unterschied liegt in den unteren Schichten: InfiniBand bringt Verlustfreiheit und zentrales Routing mit, RoCEv2 verlangt dafür ein sorgfältig konfiguriertes Ethernet. Dem stehen bei RoCEv2 Herstellervielfalt, Standard-Werkzeuge und die Integration ins übrige Rechenzentrumsnetz gegenüber.
Ultra Ethernet zielt darauf, die Vorteile von InfiniBand (Skalierung, Multipath, Sicherheit) auf Ethernet zu bringen, ohne dessen Verlustfreiheit vorauszusetzen.
Markt
Nach dem Ausstieg von Intel (Omni-Path, heute Cornelis Networks) und der Übernahme von Mellanox durch NVIDIA 2020 stammen HCAs und Switches praktisch nur noch von NVIDIA. Diese Abhängigkeit von einem Hersteller ist der wichtigste Grund, warum Hyperscaler und das Ultra Ethernet Consortium auf Ethernet-basierte Alternativen setzen.
Normen und Quellen
- IBTA: InfiniBand Architecture Specification Volume 1, Release 1.8 (September 2024)
- IBTA: InfiniBand Architecture Specification Volume 2, Release 1.5
- IBTA: InfiniBand Roadmap, infinibandta.org
- IBTA: Pressemitteilung zu Vol. 1 Release 1.8, 10. September 2024
- OpenSM: github.com/linux-rdma/rdma-core (Dokumentation zu Routing-Algorithmen)
- Zahavi et al.: Optimized InfiniBand Fat-Tree Routing for Shift All-to-All Communication Patterns, 2010