Mobile-Menu

Die (R)Evolution der Rechenzentren; Teil 32 Fibre Channel over Ethernet (FCoE) – Motivation und Grundkonzepte

Autor / Redakteur: Dr. Franz-Joachim Kauffels / Dipl.-Ing. (FH) Andreas Donner

FCoE wurde von INCITS T11 im Rahmen des FC-BB-5-Standards entwickelt. Die FCoE-Protokollspezifikation bildet FC unmittelbar auf Ethernet ab und ist unabhängig von der eigentlichen Ethernet Forwardíng Funktion. Er erlaubt eine wesentliche Weiterentwicklung hinsichtlich der I/O-Konsolidierung, weil er alle Eigenschaften des FC bewahrt, für die gleiche (geringe) Latenz sorgt, die Vorzüge des FC in Sicherheit und Verkehrsmanagement stützt und somit alle Investitionen in Fibre Channel Systeme, Tools, Training und SANs bewahrt.

Firmen zum Thema

FCoE: typische Topologie bei Einsatz im Access-Layer; Bild: wikipedia / Abisys
FCoE: typische Topologie bei Einsatz im Access-Layer; Bild: wikipedia / Abisys
( Archiv: Vogel Business Media )

FCoE bewahrt Fibre Channel als das dominante Protokoll für das Ansprechen von Speichersystemen im Rechenzentrum und ermöglicht gleichzeitig einen Weg zur Konsolidierung, wie wir gleich an ein paar Beispielen noch näher diskutieren werden.

FCoE vereinfacht die Netzwerkumgebung des Anwenders durch die Verwendung von Ethernet und erspart es letztlich der Industrie, ein anderes Netzwerkprotokoll für die dringend notwendige I/O-Konsolidierung „erfinden“ zu müssen.

Der aktuelle Vorschlag, wie er durch das INCITS T11 Normungsgremium zunächst vorgeschlagen wurde, sollte sozusagen einen moralischen Druck auf die Hersteller ausüben, wirkliches „lossless Ethernet“ zu implementieren, bewahrt das operationelle Modell des Fibre Channels und enthält ein neues Frame Format. FCoE ist nicht an 10 GbE gebunden, sondern kann auch auf anderen entsprechend schnellen Netzwerken laufen. Außerdem braucht man FCoE nicht zu erneuern, wenn die nächsten Stufen der Ethernet-Evolution mit 40 und 100 Gbit/s. erreicht werden.

Um es direkt vorweg zu nehmen: Hersteller und IEEE 802 haben das Ziel nicht erreicht, ein wirklich verlustfrei arbeitendes Ethernet in deterministischer Art und Weise zu definieren. Statt dessen musste INCITS T11 den FC-BB_E-Teilstandard so ausformulieren, dass FCoE auch mit einem Ethernet klar kommt, welches zwar gegenüber der Normalausführung erheblich angereichert wurde, aber dennoch nicht wirklich immer und dauerhaft verlustfrei arbeitet.

Konzeptionell kann FCoE in drei Bereiche herunter gebrochen werden:

  • Einkapselung nativer Fibre Channel Frames in Ethernet Frames
  • Die Erweiterung von Ethernet zu „Lossless Ethernet“
  • Den Ersatz einer FC-Verbindung mit ihren MAC-Adressen im Rahmen einer Lossless Ethernet Fabric

Damit es nachher keine Missverständnisse gibt, schauen wir uns einmal die Ziele der Standardisierung an, damit ganz klar wird, was FCoE ist – und was es nicht ist.

weiter mit: Die Ziele der FCoE Standardisierung

Die Ziele der FCoE Standardisierung

  • Die Verbindung zu einer physikalischen FC Fabric wird nicht verlangt, muss aber möglich sein
  • FCoE Fabrics werden mit FCoESwitches gebaut, das sind Switches mit EthernetPorts, die FCoE-Funktionen und -Dienste bieten sowie Switches, die die Funktionen traditioneller FC-Switches enthalten; Standard-Ethernet-Switches können in der Fabric ebenfalls existieren, aber Switches mit FCoE-Fähigkeiten müssen zwingend vorhanden sein.

Dazu ist Folgendes zu bemerken: die Einkapselung eines FC-Frames via FCoE in einen Ethernet Frame bzw. zurück kann in einem FCoE Endpunkt (wie z.B. einem FCoE-fähigen Host) geschehen, muss aber nicht. So kann z.B. ein Speicher, der mit einem FCoE-fähigen Host kommunizieren möchte, keine FCoE, sondern nur eine FC-Fähigkeit besitzen und somit das erste Stück der Verbindung über einen ganz normalen FC zurücklegen. Wird dann irgendwann in eine FCoE-Umgebung oder FCoE Fabric übergegangen, muss die Umwandlung an einem entsprechend ausgerüsteten Switch vorgenommen werden. Nur so kann sichergestellt werden, dass auch bestehende FC-Geräte ohne weitere Modifikation über eine FCoE-Infrastruktur kommunizieren können. Wir haben dazu später ein Beispiel, in dem genau dieser Fall klargemacht wird.

Der Standard macht so wenige Vorgaben wie möglich hinsichtlich der Implementierung an den Endpunkten der Kommunikation. Denkbar sind z.B. 10 GbE Host Adapter, die die FCoE-Einkapselung direkt selbständig vornehmen. In diesem Fall wenden sie sich mit normalen Ethernet Paketen an den Switch, der dann diese Umwandlung nicht mehr machen muss. Andererseits kann man aber auch mit normalen FC-Adaptern ohne weitere Zusatzfunktionalität an einen FCoE-Port eines Switches andocken, der dann die Konversion der FC-Pakete in FCoE-Ethernet Pakete vornehmen muss. So muss man nichts am Host ändern. Das gilt sinngemäß natürlich auch für alle anderen Geräte.

Die weiteren FCoE-Ziele und Vorgaben lauten damit:

  • FCoE Fabrics müssen nahtlos mit echten FC-Fabrics funktionieren
  • Der Übergang zwischen FCoE Fabrics und physikalischen FC-Fabrics muss vollkommen problemlos, effizient und hochperformant sein
  • FC-Dienste müssen auf FC-Fabrics und FCoE-Fabrics gleichermaßen funktionieren
  • FCoE muss alle erweiterten FC-Dienste transparent unterstützen (Virtual Fabrics, IFR, Security...)
  • FCoE erfordert die Implementierung verschiedener Ethernet-Erweiterungen, Lossless Ethernet Switches und Fabrics (z.B. Unterstützung von IEEE 802.3 PAUSE) sowie Jumbo Frames (kein Standard, aber weithin verfügbar)

In Anlehnung an das weiter oben Gesagte bedeutet dies, dass die Eigenschaften „Lossless“ und „Jumbo-Frames“ zwar notwendig, aber nicht hinreichend für einen Switch sind, der FCoE implementieren soll,. Zu diesen Eigenschaften muss noch die Fähigkeit hinzutreten, an den betreffenden Ports eine FC/FCoE/Ethernet-Konversion vornehmen zu können – es sei denn, man kann garantieren, dass die Adapter in den Endpunkten das selbst können, wovon man aber im Normalfall nicht ausgehen kann. Wir diskutieren das ebenfalls später an einem Beispiel.

Die Entwicklung von FCoE sollte zudem neuere Erweiterungen von Ethernet, wie sie in IEEE 802.1 diskutiert werden, berücksichtigen, und zwar insbesondere prioritätsbasierende Flusskontrolle PFC und selektive Transmission.

Diese Funktionen sind wichtig für konsolidierte Datenflüsse auf den Bereichen Messaging, Clustering und Storage. Die Menge dieser Funktionen wird auch als Data Center Ethernet DCE oder Converged Enhanced EthernetCEE bezeichnet. Der Standard überlässt aber die Implementierung derartiger Funktionen den Herstellern und macht keine weiteren Vorgaben.

FCoE muss darüber hinaus eine direkte Abbildung von FC auf ein Ethernet Netzwerk darstellen und in der Schichtenbildung oberhalb von Ethernet angesiedelt sein.

Für das Routing von FCoE-Paketen wird FSPF benutzt. Ethernet-Kernfunktionen wie Spanning Tree oder Rapid Spanning Tree usw. gehören zu Ethernet und müssen daher unterhalb von FCoE liegen.

Hierzu muss man noch etwas sagen. FCoE hat eine etwas ungünstige Positionierung für den wahren Schichten-Ästheten. Eigentlich wäre das Umpacken von Päckchen eine Funktionalität für den MAC-Layer. Da dieser aber von IEEE 802.3 völlig durchstrukturiert ist, kann man ihn nur „von oben“ über die Service-Primitive erreichen. FCoE selbst muss aber unter der FC-Schicht 2 liegen, da – wie wir später noch sehen werden – alle nativen FC-Funktionen und besonders die auf diesen aufsetzenden beliebten Hilfsmittel erhalten bleiben sollen. FCoE hat rein gar keine der gewohnten Layer-3-Funktionalitäten. Der Rheinländer würde sagen, FCoE ist schichtentechnisch ein Knubbel zwischen Ethernet-MAC und FC Layer 2.

Fortsetzung folgt…