English 
简体中文 
繁體中文 
Русский 
Español 
Deutsch 
Français 
Português 
Italiano 
Türkçe 
Polski 
Nederlands 
日本語 
한국어 
Bahasa Indonesia 
Bahasa Melayu 
العربية 
हिन्दी 
Tiếng Việt 
ภาษาไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی Grundlagen der InfiniBand-Fabric
Eine InfiniBand-Fabric verhält sich anders als ein Ethernet-Netzwerk, und zwar auf eine Weise, die bei der Diagnose eines Links wichtig ist. Diese Seite behandelt die Konzepte, denen ein Optik-Ingenieur begegnet: den Subnet-Manager, verlustfreie Flusssteuerung, Topologien und wie sich ein fehlerhafter Link zeigt.
Der Subnet-Manager
Jedes IB-Subnetz hat einen aktiven Subnet Manager (SM). Er entdeckt alle Ports und Switches, weist lokale Bezeichner (LIDs) zu, berechnet Forwarding-Tabellen und programmiert sie in jeden Switch. Wenn ein Link flappt, durchsucht der SM die Fabric erneut – eine grenzwertige Optik verliert also nicht nur einen Link, sondern löst fabric-weite Rerouting-Ereignisse aus, die jeder bemerkt.
Verlustfrei durch Credits
IB-Links verwerfen im Normalbetrieb nie Pakete: Ein Sender überträgt nur, wenn der Empfänger Puffer-Credits gemeldet hat. Überlastung führt daher zu Backpressure statt zu Verwerfen, und ein degradierter Link (steigende Symbolfehler, FEC-Korrekturen) verlangsamt den gesamten Job, der davon abhängt – das Problem des „einen langsamen Links" bei kollektiven Operationen.
Topologien
- Fat-Tree (Clos) – der Standard: Leaf-Switches verbinden Hosts, Spine-Switches verbinden Leafs, mit genug Uplinks, um non-blocking zu sein. Die meisten Links sind Leaf-Spine-Optik.
- Dragonfly+ und Torus-Varianten kommen in den größten Systemen vor, um Switches und Kabel zu sparen.
- Rail-optimierte Designs für KI platzieren die NIC jeder GPU auf einer eigenen „Rail“ der Fabric, sodass GPUs mit demselben Rang über Server hinweg einen Hop voneinander entfernt sind – siehe GPU-Fabric-Topologien.
RDMA und GPUDirect
Anwendungen nutzen RDMA-Verbs, um Daten zwischen Node-Speichern ohne CPU-Kopien zu verschieben; GPUDirect RDMA erweitert dies auf GPU-Speicher. Das Ergebnis ist, dass ein Fabric-Fehler für Anwendungen als Stall oder Timeout in einer kollektiven Operation sichtbar wird, oft lange bevor ein Operator einen ausgefallenen Port sieht.
Wie ein fehlerhafter Link aussieht
| Symptom in der Fabric | Zu prüfende Physical-Layer-Ursache |
|---|---|
| Steigende Symbolfehler / FEC-korrigierte Blöcke auf einem Port | verschmutztes MPO, grenzwertige Rx-Leistung, degradierende Lane |
| Link bleibt bei geringerer Breite oder Geschwindigkeit hängen | FEC-Mismatch, Modul meldet nicht die erwartete Rate |
| Port „Not supported“, kein Link | nicht erkannte Modulidentität – Herstellersperre |
| Wiederholte SM-Durchläufe | irgendwo ein flappender Link – über Fehlerzähler je Port aufspüren |
Der üblichen Diagnoseleiter folgen: Pegel → reinigen → tauschen → Kabel.
In CodingBox
Ein verdächtiges IB-Modul auf der Werkbank auslesen: Rx/Tx und Bias je Lane auf dem Bildschirm DDM zeigen, ob eine Lane eines SR4/DR4-Moduls ausfällt, und die Identitätsfelder zeigen, ob die Fabric einen Ersatz akzeptieren wird.
Die Protokollschichten, Queue Pairs und Subnet-Manager-Funktionen im Detail: IB-Protokoll & -Transport; die Fabric nach Generation und Reichweite verkabeln: IB-Verkabelung.