Einfacheres Management und geringere Kosten

SAN-Zukunft Fibre Channel over Ethernet FCoE

22.08.2011 von Steffen Jansen
Für moderne und flexible Rechenzentren entpuppt sich Fibre Channel over Ethernet (FCoE) immer mehr als Schlüsseltechnik. Wir zeigen, was für FCoE spricht und wie die Kommunikation im Netzwerk stattfindet.

Vereinfacht ausgedrückt, trägt FCoE zu einer homogeneren und damit vorteilhafteren Netzstruktur bei: Physisch und technisch getrennte Storage und Local Area Networks (SANs und LANs) können so über eine gemeinsame Infrastruktur transportiert werden. Die Konsequenzen sind nicht nur niedrige Kosten oder bessere Administration, sondern erstrecken sich bis in den Bereich der RZ-Virtualisierung.

Von den Gremien der IEEE und INCITS-T11 entwickelt, ist FCoE seit Juni 2009 standardisiert (FC-BB-5 [FC-BB_E]). Mit Hilfe des Protokolls soll das in SANs weit verbreitete Fibre Channel (FC) problemlos über eine angepasste Ethernet-Struktur laufen. Ziel ist dabei eine Input-Output-(I/O-)Konsolidierung. Hierzu musste das seit vielen Jahren bewährte Ethernet weiterentwickelt werden, um als Transportmedium für das bezüglich bestimmter Parameter hochanspruchsvolle Fibre Channel genutzt zu werden. Es entstand das Converged Enhanced Ethernet (CEE).

Fibre Channel und seine Anforderungen

Um zu verstehen, warum das bestehende Ethernet weiterentwickelt werden muss, ist es hilfreich, Fibre Channel näher kennen zu lernen. FC wurde in den 1990er Jahren entwickelt, um den parallelen Übertragungsstandard Small Computer System Interface (SCSI) netzfähig zu machen. SCSI stellt als omnipräsente Schnittstelle für Peripheriekomponenten aller Art höchste Ansprüche an die Qualität der Datenübertragung. Gehen hier Daten verloren, werden sie typischerweise nicht erneut nachgesendet, wie das bei TCP-Anwendungen der Fall ist. Sollte es in einem SCSI-Kabel doch zu einem Datenverlust kommen, so wird die gesamte Kommunikation abgebrochen und alles erneut gesendet.

Anspruchsvoll: Kein Jitter, kein Delay - FibreChannel stellt hohe Anforderungen an das Netz.

Des Weiteren kommt es in einem SCSI-Kabel kaum vor, dass einzelne Frames sich gegenseitig überholen können, eine Auslieferung in falscher Reihenfolge (Out-of-Order-Delivery) wie im Internet ist kein Thema. Ebenso hatte SCSI nicht mit dem Problem der Verzögerung, dem Delay, zu kämpfen, denn die Kabellängen waren stets eher kurz (beispielsweise drei Meter für Ultra-SCSI, 1992). Auch variable Delays oder Jitter kamen nicht vor.

All diese Eigenschaften, praktisch kein Datenverlust, extrem niedriger Delay, kein Jitter, In-Order-Delivery, stellten seinerzeit - heute übrigens auch noch - hohe Ansprüche an das Netz. Ethernet und TCP/IP waren damals für diese Rolle nicht geeignet, weshalb ein eigenes Speichernetzprotokoll entwickelt wurde. Seit dieser Zeit hat sich FC in den SANs behauptet und bildet das Rückgrat der anspruchsvollsten Speichernetze weltweit.

FC benötigt allerdings eigene Hardware, und die war nie billig. Die Netzkarten heißen nicht Network Interface Cards (NICs), sondern Host Bus Adapter (HBAs). Relativ teure FC-Switches verbinden die HBAs der Server mit den Storage Controller genannten Schnittstellen der Speichermedien, seien es Disk/Raid-Systeme, (Virtual) Tapes oder JBODs (Just a Bunch of Disks).

Die dedizierte Hardware, die spezialisierten Anwendungen und die hohen Ansprüche an Sicherheit und Hochverfügbarkeit machen Rechenzentren komplex und teuer - in der Anschaffung und im Unterhalt. Spezialisierte Hersteller mit eigenen Supportstrukturen sowie teure Spezialisten tun ihr Übriges, dass Anwender mehr denn je über Vereinheitlichungen in diesem wichtigen IT-Sektor nachdenken.

Converged Enhanced Ethernet (CEE)

CEE ist ein weiterentwickeltes Ethernet auf Basis von (derzeit) 10-Gigabit-Ethernet. Es kann als Standard der Zukunft betrachtet werden. Seine neuen Eigenschaften haben Vorzüge, die nicht nur für den Transport von FC unerlässlich sind, sondern Ethernet auf eine höherwertige Entwicklungsstufe stellen, von der alle Anwendungen und Protokolle profitieren können. Zudem ist CEE rückwärtskompatibel aufgebaut. Aber noch sind nicht alle CEE-Komponenten standardisiert.

Konvergenz: Erst mit moderner Netztechnik kann auf ein eigenes Speichernetz verzichtet werden.

CEE wird häufig auch als "lossless Ethernet" bezeichnet. Diese Bezeichnung soll eine Eigenschaft des "besseren" Ethernets griffig verdeutlichen - seine Fähigkeit, durch geeignete Flusskontrolle den Verlust von Frames zu verhindern. Nun, wenn man genau sein will, dann lassen sich Verluste während des Transports über eine Leitung dieser Welt nie vollständig vermeiden. Das Entscheidende ist, dass im CEE eine Reihe von Maßnahmen festgelegt sind, die dazu führen, dass Mechanismen eingebaut sein müssen, die eine bestimmte Quality of Service (QoS) garantieren. Dadurch ist CEE in der Lage, auch anspruchsvollste Anwendungen wie etwa FC sachgerecht zu transportieren.

CEE-Details

Im Einzelnen sind bei CEE folgende Verfahren vorgesehen:

PFC definiert die nach 802.1p (Class of Service = CoS) differenzierte Nutzung der PAUSE-Funktion zwischen zwei Ethernet-Knoten. Die PAUSE-basierende Flusskontrolle existiert schon lange im Ethernet (IEEE 802.3x), ist aber zum einen in der Regel ausgeschaltet und differenziert zum anderen nicht zwischen verschiedenen Traffic-Klassen. PFC fordert von einer CEE-kompatiblen Schnittstelle (von Endgeräten ebenso wie von Switchen), dass nach dem bekannten QoS-Standard des OSI-Layer 2, IEEE 802.1p, acht verschiedene Traffic-Klassen zu differenzieren sein müssen, was durch eine Markierung ("Tag") im VLAN-Feld des Ethernet-Frames geschieht. PAUSE wird dann bei Erreichen bestimmter Schwellwerte klassenspezifisch zum Sender zurückgemeldet, so dass der Traffic dieser Klasse, etwa FC-Traffic, nicht weitergesendet wird, um eventuelle Verluste auf der Empfängerseite zu vermeiden.

In den konsolidierten OSI-Layer-2- (also Ethernet-)Netzen der Zukunft werden sehr viele verschiedene Traffic-Klassen um Bandbreite konkurrieren. ETS beschreibt die genauen Mechanismen, wie den verschiedenen Traffic-Klassen an Schnittstellen zum einen unterschiedlich viel Bandbreite zugesprochen werden kann, zum anderen es aber auch stets möglich sein muss, dass ungenutzte Bandbreite unter bestimmten Klassen für kurzfristige Bursts geteilt werden darf.

Auch wenn PFC und ETS bereits wichtige Grundsätze zur Vermeidung von Verlusten in Ethernet-Umgebungen definieren, bedarf es noch weiterer Maßnahmen, um Ethernet den Weg in eine konsolidierte Zukunft zu ebnen. Während PFC und ETS sich um die Geschehnisse auf und um einen Link kümmern, definiert die Congestion Notification einen expliziten Rückmeldemechanismus über den Link hinaus zum Originalsender eines Stau-verursachenden Datenflusses, getreu dem Motto: "Beseitige das Übel an der Wurzel."

Als letzter, allerdings zentraler Bestandteil der CEE-Definitionen soll die Forderung nach einer klar abgrenzbaren Data-Center-Bridging-Domäne erwähnt werden. Ihre Grenzen werden gegenüber dem "normalen" Ethernet durch ein DCBX-Protokoll abgesteckt. Mit Hilfe dieses speziellen Protokolls werden zusätzlich auch die Fähigkeiten des Nachbarn und mögliche Interaktionen ausgelotet. Basis dieses neuen Protokolls soll das bereits standardisierte LLDP (Link Layer Discovery Protocol, IEEE 802.1AB) sein.

FCoE-Details

Auf welchen Mechanismen beruht nun FCoE genau? Von Bedeutung ist der Aufbau eines Ethernet-Frames, das FCoE transportiert. Zum einen setzt FCoE direkt auf Ethernet auf und ist somit völlig unabhängig von IP. IPv4 wird durch den EtherType 0x0800, IPv6 durch 0x86dd und FCoE nun eben durch einen eigenen EtherType im Ethernet-Header angekündigt: 0x8906.

Zum anderen ist die Payload, also FCoE (in dem FC steckt, in dem normalerweise SCSI steckt!), größer als 1500 Byte. Die Folge ist, dass jegliche FCoE-Implementierung Jumboframes von mindestens etwa 2300 Byte als MTU-Size unterstützen muss. Für die oben angesprochene PFC-Funktion muss ein FcoE-Adapter (CNA = Converged/Consolidated Network Adapter) eines Hosts dem Frame immer auch ein IEEE-802.1Q-VLAN-Tag mit auf den Weg geben.

Wenn ein normaler FC-Knoten erstmals Kontakt mit seinem FC-Switch aufnimmt, finden einige grundlegende Protokollrituale statt, welche Host und Switch danach in die Lage versetzen, die FC-Infrastruktur ("FC-Fabric") zu nutzen. Hierzu zählt etwa das Fabric Login (FLOGI) zum Zuteilen einer logischen FC-Adresse (FCID) vom FC-Knoten durch den Switch.

Entwirrt: Der Verzicht auf eine eigene Netzinfrastuktur verringert den Verkabelungsaufwand.
Foto: T-Systems

Der FC-BB-5-Standard definiert ENodes (FCoE Nodes) und FCFs (FCoE Forwarder) als die beiden Fibre-Channel-Gesprächspartner, die ihr FC nun auch über Ethernet zu sprechen vermögen. ENodes sind realisiert in CNAs und FCF in entsprechend FcoE- unterstützenden Switchen. Hierbei spielt ein Verhandlungsprotokoll eine besondere Rolle, das FIP (FCoE Initialization Protocol, EtherType 0x8914). Bevor es zu einer FCoE-Kommunikation kommen kann, muss zunächst per FIP geklärt werden, mit welcher MAC-Adresse der ENode künftig kommuniziert, da diese von der burned-in MAC-Adresse (BIA) des CNA verschieden ist. In diesem Zusammenhang wird auch der für FC essenzielle FLOGI-Prozess über FIP realisiert. In der Tat ist die Adresse, die der ENode im SAN tragen wird (die FCID), Bestandteil seiner MAC-Adresse für dieselben Frames, solange diese noch im CEE fließen. Dieses Mapping zwischen logischer Adresse im SAN und MAC-Adresse im LAN nennt man FPMA (Fabric Provided MAC-Address).

Hat FIP erst einmal seine Schuldigkeit getan, laufen alle folgenden FC-Kommunikationen gemäß den FC-Standards ab. Das heißt, solange die FC-Daten in Ethernet-Frames enkapsuliert sind, sendet sie der ENode mit der FPMA als Quell- und der MAC-Adresse des FCF als Ziel-Adresse. Der FCF erhält dieses Frame, deenkapsuliert gemäß derzeitigen Implementierungen den FCoE-Header und sendet das Frame als pures FC-Frame direkt ins SAN.

Normaler (IP-)Traffic des Hosts hingegen wird von dem CNA mit der BIA gesendet und landet nicht in der FCF-Funktion des Switches.

Fazit und Ausblick

Derzeit ist nur eine Implementierung von FCoE als Input-Output-Konsolidierung im Access-Layer von Rechenzentren vorgesehen. Sukzessive kann in entsprechenden Datenbank- und Anwendungs-Servern die vorhandene Doppelbestückung durch NICs und HBAs abgebaut und durch einfache CNAs ersetzt werden. Man spart Karten und damit Geld, Arbeitszeit im laufenden Betrieb und vermeidet Fehlerquellen.

Indem man Adapter spart, spart man auch Kabel, ein nicht zu unterschätzender Vorteil für Aufbau und Betrieb eines Rechenzentrums.

Zudem können nun im Access-Bereich manche FC-Switches eingespart und durch 10- Gigabit/s-CEE-fähige Ethernet-Switches ersetzt werden. Wieder ein Kosten- und Management-Vorteil. Physikalische Topologien vereinfachen sich, eine neue Generation von Administratoren wird FC nur noch als wichtige Anwendung unter vielen kennen. Das freut den Controller, der Kosteneinsparungen beim teuren Personal erkennt.

Einigen mag diese Darstellung der Vorteile als euphorisch erscheinen, da die neue Technik auf absehbare Zeit das SAN und seine Administratoren nicht abschafft und außerdem FCoE selbst ja auch etwas kostet. Nicht zuletzt Weiterbildung und erhöhte Komplexität durch das nun auch noch zu verstehende Fibre-Channel-Protokoll. Und ja, es wird bestimmt einige kleinere und größere Schwierigkeiten bei der Realisierung vor Ort geben, wie immer. Aber die Vorteile überwiegen klar und werden sich letztlich durchsetzen.

Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation Computerwoche. (cvi)