FCoE und ANSI FC-BB-5

Kommentieren Drucken
Teil 28 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

FCoE ist ein Standard, der von INCITS T11 im Rahmen des FC-BB-5-Standards entwickelt wurde. 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.

FCoE bewahrt Fibre Channel als das dominante Protokoll für das Ansprechen von Speichersystemen im Rechenzentrum und ermöglicht gleichzeitig einen Weg zur Konsolidierung. FCoE vereinfacht die Netzwerkumgebung des Anwenders durch die Verwendung von Ethernet und erspart letztlich der Industrie ein anderes Netzwerkprotokoll für die dringend notwendige I/O-Konsolidierung „erfinden“ zu müssen.

Konzeptionell kann FCoE in drei Bereiche heruntergebrochen 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 nicht ist.

Ziele der FCoE Standardisierung

  • die Verbindung zu einer physikalischen FC Fabric wird nicht verlangt, muss aber möglich sein
  • FCoE Fabrics werden mit FCoE Switches gebaut, das sind
    • Switches mit Ethernet Ports, die FCoE-Funktionen und -Dienste bieten
    • Switches, die die Funktionen traditioneller FC-Switches enthalten.
    • Standard-Ethernet-Switches können in der Fabric ebenfalls existieren, aber die 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 dies 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 sagen wir 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 weiter unten ein Beispiel, in dem genau dieser Fall klar gemacht 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, der dann die Konversion der FC-Pakete in FCoE-Ethernet Pakete vornehmen muss, gestalten. So muss man nichts am Host ändern. Das gilt sinngemäß natürlich auch für alle anderen Geräte.

  • FCoE Fabrics müssen nahtlos mit echten FC-Fabrics funktionieren
  • Der Übergang zwischen FCoE Fabrics und physikalischen FC-Fabrics muß 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
    • 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, der FCoE implementieren soll, sind. Zu diesen Eigenschaften muss noch die Fähigkeit hinzutreten, an den Ports, die es betrifft, 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.

  • Die Entwicklung von FCoE sollte neuere Erweiterungen von Ethernet, wie sie in IEEE 802.1 diskutiert werden, berücksichtigen, und zwar besonders
    • Prioritätsbasierende Flusskontrolle PFC
    • 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 Ethernet CEE bezeichnet.
Wir werden in der nächsten Folge darauf eingehen.

Der Standard überlässt aber die Implementierung derartiger Funktionen den Herstellern und macht keine weiteren Vorgaben.

  • FCoE muss eine DIREKTE Abbildung von FC auf ein Ethernet Netzwerk darstellen
  • FCoE muss 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 usf. gehören zu Ethernet und müssen unterhalb von FCoE liegen
  • FCoE muss einen EVOLUTIONÄREN Ansatz zur Konsolidierung von FC Fabrics bieten:
    • Die FC N_Port, F_Port und E_Port-Konstrukte müssen beibehalten werden können
    • Mit FCoE können Ports mit logischen Ethernet-Verbindungen untereinander verbunden werden. Auch wenn sie dabei durch unterschiedliche Ethernet-Switches laufen, werden sie durch ein Paar MAC-Adressen an den Endpunkten identifiziert.
    • Physikalische Ethernet-Verbindungen können physikalische FC-Verbindungen ersetzen
  • Physikalische Ethernet-Verbindungen können den gesamten Ethernet-Verkehr einschließlich der FCoE-Verbindungen befördern, aber der gesamte kombinierte Verkehr muss den CEE-Anforderungen genügen.
  • Es sind „Combo FCoE-Switches denkbar, die normales Ethernet, FCoE und FC unterstützen
  • FCoE-Lösungen sollten dem in FC erfahrenen Benutzer als FC-Lösungen erscheinen
  • FCoE muss den Betrieb von Fibre Channel Operationen unabhängig vom Ethernet-Forwarding halten
    • Das vereinfacht Management und Troubleshooting
    • Gemeinsame physikalische, aber getrennte logische Strukturen
  • Das Storage Management musss so bleiben, wie es ist
  • Schließlich: FCoE ist KEIN ERSATZ für FCIP oder iFCP, denn diese beiden laufen auf TCP/IP und werden für die Inter-Switch-Verbindungen jenseits des Rechenzentrums benötigt.

Der größte Teil dieser Ziele ist darauf ausgerichtet, den nativen FC unter allen Umständen zu erhalten. Warum ist das so wichtig? Die Argumentation liegt hauptsächlich in den Bereichen Administration, Management und Bereitstellung von Diensten.

Einkapselung

Die Einkapselung des FC Frames geschieht durch das Mapping von FC auf Ethernet. FC und traditionelle Netze haben Protokollstacks, bei denen jede Schicht eine Menge von Funktionen repräsentiert. Der Fibre Channel ist in fünf Schichten FC-0 bis FC-4 definiert, während Ethernet die unteren zwei OSI-Schichten abdeckt. FCoE schafft die Möglichkeit des Transports der FC-2-Schicht über die Ethernet-Schicht. Dadurch fallen die FC-0 und die FC-1-Schicht weg und die FC-Schichten 2 bis 4 werden durch die IEEE 802.3 Ethernet-Schichten unterstützt. Genau diese Abbildung erlaubt den FC-Verkehr über Ethernet. Die Abbildung 1 zeigt die Grundidee

In Abbildung 2 sehen wir das entsprechende Frame-Format nach dem INCITS T11.3-Standard.

Die ersten und zweiten jeweils 48 Bits spezifizieren die Quell- und Ziel-MAC-Adressen. Das 32-Bit IEEE 802.1Q Tag hat die gleiche Funktion wie in VLANs und erlaubt den Betreib unterschiedlicher logischer Netze auf einer gemeinsamen Infrastruktur. FCoE hat seinen eigenen „Ether-Typ“, der in den nächsten 16 Bits angezeigt wird, gefolgt vom 4 Bit langen Versionsfeld. Die nächsten 100 Bits sind reserviert. Nach ihnen kommt der 8 Bit Start of Frame und dann der eigentliche FC Frame. Auf den 8 Bit End of Frame Delimiter folgen 24 reservierte Bits. Der Frame endet wie immer mit 32 Bits für die FCS.

Der eingekapselte FC Frame besteht aus dem originalen 24 Byte langen FC Header und den Daten, die transportiert werden sollen, einschließlich der Fibre Channel CRC. Der Header wird deshalb unverändert übernommen, damit es bei der Verbindung von einem traditionellen FC-SAN mit einem FCoE-Switch nicht zu Irritationen kommen kann. Dadurch ist die Integration kein Problem.

Ein weiterer Faktor ist die Frame Größe. Ein typischer FC Daten Frame hat 2112 Byte Payload, einen Header und eine CRC. Ein klassischer Ethernet Frame ist höchstens 1500 Byte groß. Um eine gute Performance zu erzielen, muss man vermeiden, dass ein FCoE Frame in zwei Ethernet Frames zerlegt und anschließend wieder zusammengebaut werden muss. Also muss man einen Jumbo-Frame oder den „Baby-Jumbo“ benutzen, der zwar nicht standardisiert ist, aber von verschiedenen Herstellern angeboten wird.

Der durch FCoE anfallende Overhead besteht aus konstant 56 Bytes. Bei einer maximalen FC-Paketlänge wären das grob gerechnet 3%, bei einer mittleren FC-Paketlänge 5-6%. Anders gerechnet ergäbe ein 10 GbE-Kanal eine maximale FC-Übertragungsrate von ca. 9,7 Gigabit/s.

FC-BB-5: der Durchbruch für FCoE

Unter Federführung der Hersteller Cisco Systems, Brocade und QLogic wurde von der Task-Group T 11.3 des INCITS, dem Information Technology Industry Council, der Fibre Channel Backbone-Standard mit dem Namen FC-BB-5 entwickelt. Das Dokument wurde am 5.6.2009 verabschiedet und dem American National Standards Institute ANSI zur offiziellen Standardisierung vorgelegt. ANSI ist auch für alle bisherigen Fibre Channel Standards zuständig.

Der Standard definiert Funktionen und Abbildungen für den Transport von FC-Daten über andere Netze. Es werden dabei folgende Abbildungen definiert:

  • FC-BB_IP: FC über TCP/IP
  • Transparente FC-Übertragung mittels
    • FC-BB_GFPT: FC über GFPT (FC über SONET, SDH, OTN oder PDH-Backbone unter Benutzung der GFPT-Adaption)
    • FC-BB_PW: FC über MPLS unter Benutzung der PW-Adaption
  • FC-BB_E: FC über Ethernet

FC über ATM und FC über SONET als unmittelbare Umsetzungstechnologien werden nicht betrachtet. Diese sind im Standard FC-BB-3 enthalten. FC-BB-5 ist also kein vollständiger Ersatz für FC-BB-3.

Das FC-BB_IP-Modell benutzt die Übertragung von FC über IP. Bisher war diese Technik auch unter dem Namen FCIP bekannt. Ein Produktbeispiel dafür wäre das System 48000 von Brocade.

Das FC-BB_GFPT-Modell benutzt die Übertragung von FC mittels der Asynchronous Transparent Generic Framing Procedure GFPT, die in ITU-T G.7041/Y.1303 festgelegt ist. GFPT kann für die Adaption unterschiedlicher Transportmöglichkeiten wie SONET, SDH, OTN und PDH benutzt werden. Die Details der Abbildungen von FC-Verkehr auf derartige Systeme werden bereits in verschiedenen ITU-Standards beschrieben.

Das FC-BB_PW-Modell definiert ein Gateway mit Pseudowire-Funktionalität für die Verbindung zweier nicht in einer Arbitrated Loop befindlichen FC-Switch-Ports. Die Pseudowire-Gateways werden dann über MPLS-Tunnel miteinander verbunden. Die MPLS-Tunnel sind wiederum für viele Netzwerkstrukturen definiert. Das FC-BB_PW-Modell könnte ebenso gut über Carrier Ethernet-Tunnel laufen. Dies ist aber nicht in der aktuellen Version des FC-BB-5-Standards enthalten.

Das FC-BB_E-Modell benutzt die Umsetzung von FC auf Ethernet, die wir seit fast zwei Jahren unter dem Begriff FCoE diskutieren. Der Standard spricht hier direkt von einer Umsetzung auf „Lossless Ethernet“.

Bei der Definition von FCoE musste man leider feststellen, dass es im Rahmen des Ethernet-Transport über die Frage der Verlustfreiheit noch eine Vielzahl anderer unangenehmer Situationen gibt, mit denen FC-Endgeräte definitiv nicht umgehen können. FC_BB_E ist sehr umfangreich und definiert viele Verfahren genau für solche Situationen. Erst damit wurde der Weg frei für die Implementierungen in ASIC-Hardware, die eine Voraussetzung für den wirtschaftlichen Einsatz von FCoE darstellt. Hersteller wie Brocade oder Broadcom haben in 2011 verschiedene Chips für FCoE vorgestellt, bei Broadcom gibt es sogar einen vollständig in einen Switch-ASIC integrierten Kontrollprozessor. Die seit etwa 2007 laufenden Diskussionen darüber, ob eine Realisierung von FCoE überhaupt möglich und sinnvoll sei, wurden damit definitiv beendet.

Betreiber, die heute ein neues RZ-Netz planen, können die I/O-Konsolidierung mit FCoE beruhigt auf ihre ToDo-Liste setzen, sofern das notwendig ist. Alle Investitionen in bestehende SANs werden damit geschützt.

« Teil 27: I/O-KonsolidierungTeil 29: Data Center Bridging DCB »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.