FCoE Fibre Channel over Ethernet V1.5 (c) Stor IT Back 2026
Es wird ein Fibre Channel Paket in ein Ethernet-Paket verpackt und zusammen mit anderen Netzwerkdaten über
einen 10 Gbit/s oder 100 Gbit/s FCoE Adapter und einen 10 Gbit/s bzw. 100 GBit/s FCoE Switch verschickt. Jetzt
wird also nur noch eine konsolidierte Infrastruktur benötigt. Dies spart
Kosten, Platz, Energie und verringert die Komplexität.
Und genau das ist Fibre Channel over Ethernet. Fibre Channel in Ethernet verpackt und zusammen mit dem LAN Verkehr transportiert. Ganz so einfach ist es aber
nicht. Ethernet bzw. TCP/IP bietet viele Features nicht, die Fibre Channel benötigt bzw. was FC eigentlich ausmacht. Und
das wird im FCoE in einem speziell angepassten Ethernet Protokoll ermöglicht. Man benötigt also spezielle FCoE Hardware oder LAN Switche mit den benötigten
Protokoll-Erweiterungen.
Jeder Server hat zur Redundanz zwei FCoE Adapter, die jeweils an einen FCoE Switch angeschlossen sind. Am FCoE Switch werden die Storage-Daten zum Fibre Channel RAID Storage geleitet und Anwendungsdaten zu den Ethernet-Switches.
Da schauen wir uns doch mal die vorhandenen Protokolle und deren Nachteile kurz an.
Fibre Channel ist sehr performant
(geringe Latenzzeit, hoher Nutzdatendurchsatz), eine sehr stabile Hardware, jeder Hersteller unterstützt
es, aber es ist relativ teuer und man benötigt eine komplett eigenständige
Hardware für das Speichernetzwerk. Also mehr Energieverbrauch, mehr Klimaanlagenleistung
und auch mehr Einarbeitung bei der Anschaffung und mehr Betreuungsaufwand im
laufenden Betrieb.
Dann iSCSI, recht kostengünstige Hardware, universelle
Unterstützt, Nutzung von Standard-Ethernet-Hardware und bis zur Hochverfügbarkeit
zu projektieren. Aber mit dem Nachteil, die Performance ist durch Ethernet begrenzt
und die Latenzzeit ist meist recht hoch.
Stand Anfang 2026:
Unternehmen mit dem klaren Fokus auf Performance und Sicherheit bleiben weiter bei Fibre Channel bzw. nutzen NVMe-oF. Gerade mit 32 Gbit/s FC
und der geringen Latenzzeit bleibt Fibre Channel stark im Markt. Die FCoE Switche sind zwar bei nahezu allen großen Herstellern verfügbar,
aber dabei ist FCoE nicht das bestimmende Kriterium.
Ethernet entwickelt sich zu immer höhere Geschwindigkeiten, was vor kurzem noch 10 GBit/s war, das ist heute 100 Gbit/s. Und damit kann
iSCSI deutlich mehr leisten, als noch mit 10 Gbit/s oder gar 1 Gbit/s. Es fällt heute häufiger die Wahl auf iSCSI mit 40 Gigabit oder
gar 100 Gigabit und gegen FCoE.
Diese Tendenz merken auch die Software-Hersteller. Mehrere große Plattformen haben Software-FCoE zurückgefahren, was ein starkes Signal für
geringe Nutzung ist. Red Hat hat Software-FCoE (fcoe.ko) entfernt und nennt als Grund ausdrücklich die fehlende Industry-Adoption für softwaregemanagtes FCoE.
VMware hat Software-FCoE ab vSphere 7 als deprecated markiert und in vSphere 8 sind Software-FCoE-Profile nicht mehr unterstützt
(bzw. die Option praktisch weg). Das reduziert FCoE-Attraktivität gerade in typischen Enterprise-VM-Umgebungen deutlich.
Ein Hardware-FCoE-Adapter wird aber weiterhin unterstützt, da dieser einen FC-HBA und eine Netzwerkkarte bereitstellt. Das Betriebssystem sieht also
einen FC-Port und einen Netzwerk-Port.
Der große Vorteil von FCoE ist die Konsolidierung der Übertragungsnetze
in einem Rechenzentrum. Über eine Netzwerkkarte und einen Switch können
sämtliche Speicherdaten und Ethernet-Verbindungen übertragen werden.
Dies spart zum einen Platz im Rechenzentrum, vereinfacht die Verkabelung der
Server und schont Ressourcen. Ist nur ein zentraler Switch vorhanden, so verbraucht
auch nur ein Switch Energie und erzeugt Abwärme. Auch die Hochverfügbarkeit
ist einfach zu erreichen, zwei FCoE Netzwerkkarten pro Server und zwei zentrale
FCoE Switche. Eine überschaubare und leicht zu administrierende Umgebung,
auch dies spart Kosten ein.
Für alle diese Einsatzbereiche wäre auch iSCSI passend. Sind die Anforderungen
an die Performance des Storage-Netzes aber besonders doch, so werden hohe Übertragungsraten
und sehr geringe Latenzzeiten benötigt. Dies kann iSCSI nicht mehr leisten.
Dort kommt FCoE zu Einsatz, mit ähnlichen Übertragungsraten wie Fibre Channel
und nahezu gleich kleinen Latenzzeiten.
Erst einmal sind dies die Netzwerkkarten und die Switche. Eine FCoE Netzwerkkarte
wird vom Betriebssystem einmal wie eine normale Ethernet-Netzwerkkarte erkannt,
die Standard-Netzwerkprotokolle können darüber gefahren werden. Zusätzlich
stellt sich die Karte aber auch als Storage-HBA da, d.h. das Betriebssystem
kann über diese Karte Festplatten ansprechen, und zwar als vollwertige
Blockdevices. Eine Mindesttransferrate von 10 Gbit/s ist für die Karten notwendig.
Der FCoE Switch stellt neben den normalen Ethernet-Diensten zusätzlich
auch noch die Verwaltung des FCoE Transportes und evtl. die Ausschleusung der
Fibre Channel Daten auf spezielle FC Ports sicher. Einige weitere Features und
Unterprotokolle, z.B. FCoCEE (Fibre Channel over Convergence Enhanced Ethernet),
kümmern sich um die passende Priorität und möglichst geringe
Latenzzeiten
Eine direkte Anbindung der Storage-Systeme (RAID-Controller, Tape-Libraries) an FCoE ist möglich und wird sicherlich auch realisiert. Zurzeit gibt es FCoE Switches, die mit zusätzlichen Fibre Channel Ports die Ansteuerung der FC-Storage Hardware ermöglicht. Solange die FC-Ports am FCoE Switch ausreichend sind, oder die Storage-Hardware FCoE direkt nutzt, kann man komplett auf Fibre Channel Switches verzichten und nur dann macht ein FCoE Netzwerk Sinn.
Das Ethernet Protokoll musste für FCoE angepasst werden. So können zum Beispiel einzelne Frames
verloren gehen. Die höheren Protokollschichten (TCP/IP) sorgen trotzdem für eine
sichere Übertragung (durch Paketwiederholung oder -neuanforderung). Dies Verfahren ist
für Storage-Daten nicht geeignet und führt zu großen Verzögerungen.
Daher wurde das Enternet-Protokoll
um einige Funktionen erweitert:
- kein Frame-Verlust (PAUSE oder Nicht-PAUSE)
- Traffic Management 802.1au
- Priorisierung von FC-Daten gegenüber nicht-FC-Daten 802.1Q
- gleiche Frame-Latenz wir beim Fibre Channel
So werden die Ethernet-Daten mit dem PAUSE Befehl angehalten, der bei FCoE
um "Per priority PAUSE" erweitert wurde. Also ist ein reines Anhalten von LAN Daten
möglich, so dass FC(oE) Daten ungehindert übertragen werden können.
Weiterhin wird durch die Nutzung von Jumbo-Frames eine Fragmentierung der 2 kB großen FC Frames
vermieden, eine Voraussetzung für FCoE.
Der geringere Overhead im Vergleich zu iSCSI wird durch die Kapselung der FC Frames in Ethernet Frames
erreicht. Bei iSCSI werden SCSI Frames in TCP verpackt. Durch die direkte Verpackung der FC Pakete
wird eine Unterstützung von Zoning, Multipathing und der WWN-Adressierung weiterhin
ermöglicht. FCoE bleibt also auch im Handling Fibre Channel sehr ähnlich.
Was ist FCoE und wofür wird es eingesetzt?
FCoE steht für Fibre Channel over Ethernet und transportiert Fibre-Channel-Datenverkehr über ein Ethernet-Netz. Ziel ist, Storage- und Datenverkehr auf einer gemeinsamen physikalischen Infrastruktur zu bündeln, ohne komplett auf klassische Fibre-Channel-Mechanismen zu verzichten. Für Hosts und Storage wirkt FCoE häufig wie ganz normales Fibre Channel, nur dass die Frames über Ethernet laufen. Typische Einsatzfelder sind Rechenzentren mit starker Server-Virtualisierung und Wunsch nach weniger Kabeln, Ports und Adapterkarten.
Wie unterscheidet sich FCoE von klassischem Fibre Channel und von iSCSI?
Klassisches Fibre Channel nutzt ein eigenes FC-Netz mit FC-Switches; FCoE nutzt Ethernet als Transport, bleibt aber im Fibre-Channel-Protokollmodell. iSCSI dagegen kapselt SCSI in TCP/IP und läuft auf normalem Ethernet/IP, das macht es flexibel, aber stärker abhängig von IP-Stack und Netzwerklast. FCoE setzt auf ein verlustarmes Ethernet, damit Storage-Daten nicht durch Paketverluste ausgebremst werden. Ein praktisches Bild: FCoE ist FC-Verhalten auf Ethernet, iSCSI ist Storage als IP-Anwendung.
Warum braucht FCoE spezielles Ethernet (lossless Ethernet)?
Fibre Channel ist historisch darauf ausgelegt, dass Frames im Normalbetrieb nicht einfach verloren gehen. Ethernet ist dagegen traditionell best-effort: Wenn es eng wird, können Frames verworfen werden, und höhere Protokolle regeln das. FCoE braucht deshalb Mechanismen, die Verluste für den Storage-Verkehr vermeiden, weil sonst Latenz und Stabilität leiden. Diese Mechanismen werden oft unter dem Begriff Data Center Bridging (DCB) zusammengefasst. Tipp: Wenn ein Anbieter FCoE über normales Ethernet verspricht, sollte man sehr genau nachfragen, wie Verlustfreiheit und Priorisierung garantiert werden.
Was ist DCB und welche Teile davon sind für FCoE entscheidend?
DCB ist eine Sammlung von Ethernet-Erweiterungen für Rechenzentren, um Traffic kontrollierter zu transportieren. Wichtig für FCoE ist vor allem Priority Flow Control (PFC): Es kann den Datenfluss pro Prioritätsklasse pausieren, statt Frames zu verwerfen. Ebenfalls relevant ist ETS (Enhanced Transmission Selection), das Bandbreite zwischen Traffic-Klassen fairer aufteilt. Für Entscheider ist die Kernaussage: FCoE funktioniert zuverlässig, wenn das Ethernet-Netz Storage-Verkehr bevorzugt behandelt und Drops vermeidet. Praxis-Tipp: Plane DCB nicht nur im Switch, sondern Ende-zu-Ende (Host ↔ Switch ↔ Switch ↔ FCF/Storage).
Was ist ein CNA und wie unterscheidet er sich von einer klassischen NIC oder HBA?
Ein CNA (Converged Network Adapter) ist eine Netzwerkkarte, die sowohl klassischen Ethernet-Verkehr als auch FCoE/FC-Funktionen bereitstellen kann. Damit kann ein Server mit weniger Karten und Kabeln auskommen, weil ein Adapter zwei Welten bedient. Im Betrieb erscheinen dann typischerweise virtuelle Schnittstellen: eine für Ethernet, eine für Fibre Channel (über FCoE). Tipp: Achten Sie auf Treiber-/Firmware-Kompatibilität (z. B. mit deinem Hypervisor), denn bei CNAs hängen Stabilität und Performance stark an sauberen/aktuellen Versionen.
Was ist ein FCF (Fibre Channel Forwarder) und warum brauche ich ihn?
Ein FCF (Fibre Channel Forwarder) ist vereinfacht ein Switch bzw. eine Funktion im Switch, die FCoE-Verkehr wie Fibre Channel weiterleitet und in eine Fibre-Channel-Fabric integrieren kann. Er sorgt dafür, dass FCoE-Teilnehmer (z.B. Server) mit klassischen FC-Targets (Storage) kommunizieren können. Ohne eine solche Instanz bleibt FCoE meist auf ein Segment begrenzt und kann nicht sauber in eine FC-Umgebung eingebunden werden. Praxisbeispiel: Server hängen per FCoE an einem Top-of-Rack-Switch mit FCF, der dann per klassischem FC an das Storage-SAN angebunden ist.
Wann ist FCoE eine gute Idee – und wann eher nicht?
FCoE ist attraktiv, wenn im Rack Kabel, Ports und Adapter konsolidiert werden und ohnehin ein Data-Center-Ethernet mit passenden Switches geplant wird. Es passt besonders gut in Umgebungen mit vielen Servern, hoher VM-Dichte und standardisierten Racks. Weniger sinnvoll ist FCoE, wenn kein DCB-fähiges Netz geplant ist, das Team wenig Erfahrung mit DCB/Converged Design hat oder wenn bewusst eine harte Trennung zwischen LAN und SAN bevorzugst wird. Tipp für Entscheider: FCoE lohnt sich oft dann, wenn der Betriebs- und Hardware-Komponenten (Ports, Kabel, Karten) ein echter Kostentreiber ist – nicht nur als Technologie-Upgrade.
Wie sieht ein typisches FCoE-Referenzdesign im Rechenzentrum aus?
Gängig ist ein Top-of-Rack-Switch pro Rack, der DCB kann und als FCF arbeitet. Server nutzen CNAs und führen Ethernet- und FCoE-Traffic über redundante Links zu zwei Switches (für Ausfallsicherheit). Von dort geht Storage-Traffic entweder in eine FC-Core-Fabric oder direkt zu Storage-Ports, je nach Architektur. Tipp: Plane Redundanz wie im FC-SAN: zwei getrennte Pfade/Fabrics (logisch und physisch), damit Wartung und Ausfälle abgefangen werden.
Wie wirkt sich FCoE auf Performance und Latenz aus?
Richtig gebaut kann FCoE sehr gute Latenzen liefern, weil es ohne TCP/IP-Overhead auskommt und nah an FC bleibt. In der Praxis ist Performance aber stark davon abhängig, ob DCB korrekt konfiguriert ist und ob du Engpässe sauber vermeidest (z.B. Oversubscription an Uplinks). Wenn PFC oder ETS falsch gesetzt sind, kann es zu Staus kommen, die sich wie unklare Storage-Latenzspitzen äußern. Tipp: Miss nicht nur Durchsatz, sondern vor allem Latenz und Drop-/Pause-Statistiken auf Switchports, um Probleme früh zu erkennen.
Ist FCoE sicher – und wie trenne ich Storage- vom normalen Datenverkehr?
FCoE wird üblicherweise über eigene VLANs und klar getrennte Prioritätsklassen geführt, damit normaler Datenverkehr Storage nicht stört. Zusätzlich gelten ähnliche Prinzipien wie im FC-SAN: Zugriff wird über Zoning/Mapping geregelt, nur eben mit zusätzlichen Netzwerk-Konzepten auf Ethernet-Seite. Wichtig ist, dass Management-Zugriffe (Switch/Storage) getrennt und gut abgesichert sind, weil eine Fehlkonfiguration weitreichend sein kann. Tipp: Behandle das converged Netz wie kritische Infrastruktur: Change-Management, Reviews und klare Rollentrennung sind wichtiger als immer das neuste Feature.
Ist FCoE heute noch zukunftssicher, oder sollte ich eher iSCSI/NVMe-oF planen?
Das hängt stark von der Umgebung ab: Wenn bereits FC/SAN vorhanden ist und eine konsolidierte Host-Anbindung gewünscht wird, kann FCoE weiterhin sinnvoll sein. Viele Strategien gehen aber auch Richtung Ethernet-only mit iSCSI oder moderneren Protokollen wie NVMe-oF, weil sich damit Netzwerke stärker vereinheitlichen lassen. Entscheidend ist weniger Hype, sondern ob das Team Betrieb und Troubleshooting zuverlässig beherrscht und ob eine vorhandene Storage-/Switch-Plattformen klar unterstützt wird. Tipp: Bewerte pragmatisch: Welche Roadmap hat der Hersteller, welche Skills hat das Team, und welche Workloads profitieren wirklich von der gewählten Technologie?
