Storage-Netzwerke
FCoE
FCoE (Fibre Channel over Ethernet) kapselt FC-Frames in Ethernet, um SAN und LAN konvergent zu führen; es setzt verlustarmes Ethernet (DCB) voraus.
- Fibre Channel in Ethernet
- Konvergente Adapter (CNA)
- Setzt DCB voraus
- INCITS T11 (FC-BB-5/6)
- Rückläufig am Markt
FCoE (Fibre Channel over Ethernet) verfolgt eine naheliegende Idee: Statt ein separates Fibre-Channel-Netz und ein Ethernet-LAN parallel zu betreiben, kapselt FCoE die Fibre-Channel-Frames in Ethernet und führt beide Verkehrsarten über eine konvergente Infrastruktur. Die FC-Frames bleiben dabei unverändert, alle FC-Dienste laufen weiter.
Dieser Artikel erklärt die Kapselung und ihre EtherTypes, die zwingende Voraussetzung eines verlustarmen Ethernets (DCB), die Rollen von konvergentem Adapter (CNA) und FCoE-Switch (FCF), das Initialisierungsprotokoll FIP, die übliche Single-Hop-Topologie sowie die ehrliche Einordnung, warum FCoE sich nicht durchgesetzt hat.
1. FC-Frames in Ethernet
FCoE nimmt einen vollständigen Fibre-Channel-Frame und packt ihn in einen Ethernet-Frame, ohne IP und ohne TCP. Es ist also ein reines Layer-2-Verfahren mit eigenen EtherTypes: 0x8906 für die FCoE-Daten und 0x8914 für das Steuerprotokoll FIP. Weil kein IP im Spiel ist, ist FCoE nicht routbar und auf ein Layer-2-Segment beschränkt.
2. Voraussetzung: verlustarmes Ethernet
Fibre Channel verträgt keinen Paketverlust, normales Ethernet darf aber verwerfen. FCoE setzt deshalb zwingend verlustarmes Ethernet über Data Center Bridging voraus (eigener Artikel): Priority Flow Control hält die FCoE-Verkehrsklasse verlustarm, ETS sichert ihr Bandbreite, DCBX stimmt die Parameter ab. Jeder Switch auf dem FCoE-Pfad muss DCB beherrschen; ein gewöhnlicher Switch ohne DCB kann FCoE nicht verlustarm tragen.
3. CNA, FCF und FIP
Am Server steckt ein Converged Network Adapter (CNA), der LAN-NIC und FC-HBA in einer Karte vereint und dem System sowohl eine Ethernet-Schnittstelle als auch virtuelle FC-Ports zeigt. Im Netz übernimmt ein FCoE Forwarder (FCF), ein Switch mit FC-Fabric-Diensten (Zoning, Name Server), die Kapselung und Entkapselung zum nativen FC. Das FCoE Initialization Protocol (FIP, EtherType 0x8914) erledigt vorab Discovery und Login und baut die virtuellen FC-Ports auf; es läuft getrennt vom eigentlichen Datenpfad.
4. MTU: das Baby-Jumbo-Thema
Ein FC-Frame trägt bis zu 2112 Byte Nutzlast. Mit FC- und Ethernet-Headern wächst der gekapselte Frame auf mindestens rund 2180, in der Praxis oft 2240 Byte. Die Standard-Ethernet-MTU von 1500 Byte reicht also nicht; FCoE-Pfade brauchen eine erhöhte MTU (oft als „Baby Jumbo“ bezeichnet, in der Praxis werden auch echte Jumbo Frames genutzt). Wie bei DCB gilt: Die MTU muss auf jedem Hop konsistent sein, sonst entstehen schwer auffindbare Frame-Verluste.
5. In der Praxis: Single-Hop
Durchgesetzt hat sich FCoE fast ausschließlich als Single-Hop-Lösung: Der Server spricht per FCoE mit dem Top-of-Rack-Switch (dem FCF), der dann über native Fibre-Channel-Uplinks ans bestehende SAN angebunden ist. FCoE läuft also nur auf der letzten Strecke, das SAN-Backbone bleibt natives FC. Prominentes Beispiel sind Blade-Systeme, deren Fabric-Interconnects FCoE intern nutzen und nach außen wie natives FC wirken. Ende-zu-Ende-FCoE über die ganze Fabric wurde zwar standardisiert, aber kaum eingesetzt.
6. Warum FCoE sich nicht durchgesetzt hat
Die versprochene Konvergenz brachte in der Praxis selten echte Einsparungen: FCoE-fähige Switches und CNAs waren teuer, und die DCB-Anforderung band an spezielle Hardware. Hinzu kam, dass die Betriebskulturen von LAN (verlusttolerant, IP) und SAN (verlustempfindlich, SCSI) sich schwer zusammenführen ließen. Heute dominieren für Block-Speicher klassisches Fibre Channel (für Bestand und höchste Ansprüche), iSCSI und vor allem NVMe/TCP, das ohne DCB auf Standard-Ethernet läuft. FCoE ist entsprechend rückläufig.
FCoE war technisch sauber, aber wirtschaftlich selten überlegen. Für neue Umgebungen ist es kaum noch die Antwort; dort gewinnen DCB-freie Ethernet-Wege wie NVMe/TCP.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Weniger Adapter und Kabel am Server (ein CNA) | nicht routbar (reines Layer 2) |
| FC-Frames unverändert, FC-Dienste bleiben erhalten | setzt durchgängig DCB-fähige Switches voraus (oft Vendor-Bindung) |
| Bestehendes FC-SAN muss nicht umgebaut werden | MTU-Konsistenz auf jedem Hop nötig |
| Herstellerneutral standardisiert (INCITS T11) | keine inhärente Verschlüsselung |
| Bewährt in Single-Hop-/Blade-Szenarien | Markt rückläufig; bei Neubauten meist FC, iSCSI oder NVMe/TCP |
Häufige Fragen zu FCoE
Selten. FCoE hat sich nie breit durchgesetzt und ist rückläufig, weil die Konvergenz selten echte Kosteneinsparungen brachte und teure, DCB-fähige Hardware verlangt. Für neue Block-Storage-Umgebungen sind klassisches Fibre Channel, iSCSI oder vor allem NVMe/TCP, das ohne verlustarmes Netz auf Standard-Ethernet läuft, meist die bessere Wahl.
Weil Fibre Channel keinen Paketverlust toleriert, normales Ethernet aber bei Überlast Frames verwirft. FCoE setzt deshalb Data Center Bridging voraus: Priority Flow Control hält die FCoE-Verkehrsklasse verlustarm. Ein gewöhnlicher Switch ohne DCB kann FCoE-Verkehr nicht zuverlässig tragen, und jeder Hop im Pfad muss DCB beherrschen.
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
FCoE 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.