Storage-Netzwerke
DCB / PFC / ETS
Data Center Bridging (DCB) ist ein Satz von IEEE-802.1-Erweiterungen, die Ethernet verlustarm und konvergenzfähig machen; PFC, ETS und DCBX sind seine Kernbausteine.
- Verlustarmes, konvergentes Ethernet
- PFC pausiert je Priorität
- ETS teilt Bandbreite zu
- DCBX handelt aus (LLDP)
- IEEE 802.1 (in 802.1Q)
Data Center Bridging (DCB) ist kein einzelner Standard, sondern eine Familie von IEEE-802.1-Erweiterungen, die das von Haus aus verlustbehaftete Ethernet verlustarm und konvergenzfähig machen, sodass Storage- und LAN-Verkehr über dieselbe Fabric laufen können. Erst DCB ermöglicht Protokolle wie FCoE und RoCE auf Ethernet.
Dieser Artikel erklärt die Bausteine PFC, ETS, DCBX und QCN, das Zusammenspiel mit ECN und DCQCN für die Stauvermeidung bei RoCE, die Puffer- und Deadlock-Problematik sowie welche Protokolle DCB voraussetzen und welche darauf verzichten.
1. Wozu verlustarmes Ethernet
Normales Ethernet darf bei Überlast Frames verwerfen; höhere Schichten wie TCP gleichen das aus. Für Speicherprotokolle wie FCoE und für RDMA (RoCE) ist Paketverlust aber teuer oder fatal. DCB macht Ethernet deshalb so verlustarm, dass diese Protokolle darüber laufen, ohne den Aufbau eines separaten Storage-Netzes (etwa Fibre Channel) zu erfordern.
2. Die Bausteine
DCB bündelt mehrere IEEE-802.1-Erweiterungen, inzwischen in den Hauptstandard 802.1Q eingearbeitet:
| Baustein | Funktion |
|---|---|
| PFC (802.1Qbb) | Priority Flow Control: pausiert gezielt einzelne der 8 Prioritäten statt des ganzen Links (verlustarm je Klasse) |
| ETS (802.1Qaz) | Enhanced Transmission Selection: teilt Verkehrsklassen garantierte Bandbreitenanteile zu |
| DCBX (in 802.1Qaz) | handelt PFC- und ETS-Parameter zwischen Switch und NIC automatisch aus (über LLDP) |
| QCN (802.1Qau) | Layer-2-Staubenachrichtigung; in der Praxis kaum genutzt, durch ECN/DCQCN abgelöst |
3. PFC: pausieren statt verwerfen
Das Herzstück ist PFC. Statt wie der alte Ethernet-Pause-Mechanismus den ganzen Link einzufrieren, kann PFC einzelne der acht Prioritätsklassen anhalten. Droht der Puffer der RDMA- oder FCoE-Klasse überzulaufen, sendet der Switch einen Pause-Frame nur für diese Priorität; anderer Verkehr läuft weiter. So bleibt genau die empfindliche Klasse verlustarm. PFC wirkt dabei immer nur zwischen zwei direkt verbundenen Geräten (hop-by-hop).
4. Stau vermeiden, bevor PFC eingreift: ECN und DCQCN
PFC ist der Notnagel, aber kein gutes Mittel zur laufenden Steuerung, weil ausgedehnte Pausen Folgeprobleme erzeugen. Für RoCEv2 kommt deshalb ECN (Explicit Congestion Notification) hinzu, ergänzt durch DCQCN: Switches markieren Pakete schon bei beginnendem Stau, der Empfänger meldet das zurück, und der Sender drosselt seine Rate, bevor PFC überhaupt nötig wird. PFC bleibt nur die letzte Sicherheitslinie. Die Puffer (Headroom) müssen dabei je Port und Priorität ausreichend dimensioniert sein.
5. Das Deadlock-Risiko
Die größte Gefahr von DCB liegt in PFC selbst: Pausieren sich Switches über mehrere Hops gegenseitig in einem Zyklus, entsteht ein PFC-Deadlock, bei dem sich nichts mehr bewegt, obwohl gar keine echte Überlast mehr besteht. Verwandt ist das Head-of-Line-Blocking, bei dem eine pausierte Klasse andere mitzieht. Gegenmittel ist ein PFC-Watchdog, der festhängende Warteschlangen erkennt und auflöst, allerdings herstellerspezifisch und nicht genormt. Daraus folgt die wichtigste Betriebsregel: DCB muss über die gesamte Fabric konsistent konfiguriert sein.
Ein einziger Switch im Pfad ohne korrekte PFC-Konfiguration bricht das Lossless-Versprechen. DCB ist eine Fabric-weite Disziplin, keine Einstellung pro Gerät.
6. Wer DCB braucht und wer nicht
Nicht jedes Storage-Protokoll setzt DCB voraus:
- Zwingend FCoE braucht verlustarmes Ethernet als Grundvoraussetzung.
- Stark empfohlen RoCEv2 und damit NVMe/RDMA über RoCE laufen nur mit verlustarmem Netz zuverlässig.
- Nützlich, nicht nötig iSCSI profitiert von ETS-Bandbreitengarantien, läuft aber auch ohne DCB, weil TCP Verluste abfängt.
- Ohne DCB NVMe/TCP und iWARP brauchen kein verlustarmes Netz.
Begriffe der Hersteller
DCB wurde von Herstellern auch CEE (Converged Enhanced Ethernet) oder DCE (Data Center Ethernet) genannt. Gemeint ist derselbe IEEE-Standard-Stack; normativ korrekt ist „DCB“.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Ermöglicht Storage und RDMA über ein Ethernet (Converged) | fabric-weite, konsistente Konfiguration zwingend |
| PFC hält gezielt eine Klasse verlustarm | PFC-Deadlocks und Head-of-Line-Blocking als Risiken |
| ETS garantiert Bandbreite je Verkehrsklasse | Puffer-/Headroom-Dimensionierung fehleranfällig |
| DCBX automatisiert die Abstimmung Switch/NIC | PFC-Watchdog herstellerspezifisch, nicht genormt |
| Grundlage für FCoE und RoCE/NVMe-RDMA | keine Verschlüsselung; FCoE rückläufig, NVMe/TCP DCB-frei |
Häufige Fragen zu DCB / PFC / ETS
Der klassische Ethernet-Pause-Mechanismus (802.3x) hält den gesamten Link an. PFC (802.1Qbb) kann gezielt einzelne der acht Prioritätsklassen pausieren: Droht der Puffer der Storage- oder RDMA-Klasse überzulaufen, wird nur diese pausiert, während anderer Verkehr weiterläuft. So bleibt genau die empfindliche Klasse verlustarm.
Nein. FCoE setzt verlustarmes Ethernet zwingend voraus, RoCEv2 (und NVMe/RDMA darüber) praktisch ebenso. iSCSI profitiert von DCB, läuft aber auch ohne. NVMe/TCP und iWARP brauchen gar kein DCB, weil TCP Paketverluste abfängt. Wer den DCB-Aufwand scheut, kann das in die Protokollwahl einbeziehen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
DCB / PFC / ETS im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.