Suchen

Die (R)Evolution der Rechenzentren; Teil 37 FCoE nach FC-BB-5 – Modelle für die Funktionalität von FC-BB_E

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

Schon in der letzten Folge haben wir Aufbau, Funktionen und Möglichkeiten von FC-BB_E näher betrachtet und entsprechende Schlüsse gezogen. Das Verständnis von FC-BB_E ist wesentlich für sichere Entscheidungen bei Planung, Konfiguration und Aufbau konvergierter RZ-Netze. Heute geht es um die Definition der Funktionalität und damit um die Modelle für die gewünschte Funktionalität von Controllern.

Firmen zum Thema

Das FCF-Funktionalmodell; Bild: Dr. Franz-Joachim Kauffels
Das FCF-Funktionalmodell; Bild: Dr. Franz-Joachim Kauffels
( Archiv: Vogel Business Media )

Der Standard definiert Modelle für die gewünschte Funktionalität von Controllern. Wir fassen dies hier insoweit zusammen, wie es für das Verständnis wichtig ist. Insgesamt entsteht dadurch ein schönes geschlossenes Gesamtbild.

Funktionsmodell für einen ENode

Abbildung 1 zeigt das Modell. Die in Klammern gesetzten Elemente sind optional. Ein ENode besteht mindestens aus einer Lossless Ethernet MAC und einer FCoE Controller Funktion.

Bildergalerie
Bildergalerie mit 5 Bildern

Hier sehen wir sog. LEPs. Das sind FCoE Link End Points. Der zu einem ENode gehörende und mit der betreffenden MAC-Adresse assoziierte FCoE-Controller muss die Schaffung mindestens einer Instanz eines VN_Port/FCoE-LEP-Paares unterstützen. Der Controller ist eine Funktionaleinheit, die das FCoE Initialisierungs-Protokoll FIP durchführt und Instanzen von VN_Port/LEP-Paaren erzeugt und auflöst. Weitere Aufgaben sind:

  • Optionale Initialisierung des FIP VLAN-Discovery Protocols, welches FCoE-VLANs entdecken kann.
  • Initiierung des FIP-Discovery Protokolls, welches alle am gleichen Lossless Ethernet angeschlossenen FCF-MACs entdeckt, die in der Lage sind, VF-Ports zu unterstützen.
  • Initialisierung so genannter FIP FLOGI-Informationsaustausch-Prozeduren, und Schaffung eines VN_Port/LEP-Paares, wenn der FLOGI-Austausch mit einer VF_Port-fähigen FCF-MAC erfolgreich war oder wenn man einen expliziten Fabric Logout benötigt
  • Das Gleiche mit dem FIP NPIV FDISK Exchange-Protokoll für eine VF-Port-fähige FCF-MAC
  • Auflösung von Instanzen, wenn ein VN_Port sich bei der Fabric ausloggt oder wenn ein FIP Clear Virtual Link Befehl kommt
  • Aussendung periodischer FIP Keep Alive Nachrichten
  • Beobachtung des Zustandes der Instanzen von VN_Port/FCoE-LEP-Paaren
  • Monitoring der VF-Ports, an die Instanzen von VN_Port/LEP-Paaren eingeloggt sind

Die LEP ist diejenige Funktionaleinheit, die FC-Frames in FCoE-Pakete einpackt und ankommende FCoE-Frames wieder auspackt. An diese Funktion kann man einige Kontrollfunktionen hängen. So kennt die LEP nicht nur die „eigene“ MAC, sondern auch die des Zielpunktes. Sie kann bei einem ankommenden FCoE-Paket also prüfen, ob das auch von der richtigen Stelle kommt. Für eine FCoE-LEP auf einem ENode ist die MAC-Adresse des lokalen Link-Endpunktes diejenige, die mit dem VN_Port assoziiert ist, auf dem die LEP arbeitet. Die MAC-Adresse des entfernten Link-Endpunktes ist dagegen die FCF-MAC-Adresse des entfernten VF_Ports. Die VN_Ports sind Instanzen des FC-2V Sublevels des FC-Protokollstacks, der als N_Port arbeitet. Sie werden nach erfolgreichem Abschluss der FIP FLOGI und FIP NPIV FDISK Protokolle erzeugt. Ein VN_Port kann eine oder mehrere Arbeitseinheiten der FC-4-Protokollschicht unterstützen.

Kontrollprozeduren

Die Kontrollprozeduren mögen zunächst einmal als überflüssiger Overhead erscheinen. Sie sind aber nicht nur die Gewährleistung dafür, dass alle Datenströme auch die richtigen Wege gehen, sondern fangen auch viele mögliche Fehler, die in der Ethernet Switching Fabric passieren können, so wirkungsvoll ab, dass sie sich nicht auf den FC-Verkehr auswirken – wenn man einmal davon absieht, dass er im Extremfall stehen bleiben kann. Das aber wiederum ist in FC ja vorgesehen, dann gibt es eben für eine gewisse Zeit keine neuen BB_Credits.

Es sei allerdings noch bemerkt, dass diese Funktionen unbedingt auf der CEE/DCE/DCB-Ebene des Ethernets die DCBX-Kontrollfunktion benötigen, ohne die das für die Entscheidungen der Prozeduren notwendige Wissen nicht eingeholt werden kann.

weiter mit: Funktionsmodell für eine FCF

Funktionsmodell für eine FCF

Die Abb. 2 zeigt das Modell für einen FCF, wobei die in Klammern gesetzten Funktionen wieder optional sind. Eine FCF besteht aus einem Fibre Channel Switching Element mit wenigstens einer Lossless Ethernet MAC. Jede FCF-MAC muss mit einer FCoE-Controller-Funktion verbunden sein und darf zudem auch mit einem Lossless Ethernet Bridging Element verbunden sein. (Denken Sie immer dran: in der Ethernet-Terminologie sind die Switches Multiport-Brücken). Das FC-Switching Element kann auch eine Verbindung zu einer FC-Fabric-Schnittstelle haben, die über native E_Port und F_Port Connectivity verfügt. Eine FCF forwardet FCoE-Frames, die an eine ihrer FCF-MACs gerichtet sind, basierend auf der Information in der D_ID des enkapsulierten FC-Frames.

Wenn eine FCF Lossless Ethernet Bridging Elemente enthält, kann die FCF-MAC-Adresse von mehreren Ethernet-Ports an der FCF benutzt werden. Der FCoE-Controller, der mit einer FCF-MAC assoziiert ist, muss die Bildung von Instanzen für VE_Port/FCoE-LEP-Paaren oder VF_Port/FCoE-LEP-Paaren unterstützen. Eine FCF-MAC, die VE_Port/LEP-Paare bzw. VF_Port/LEP-Paare unterstützt, wird als VE_- bzw. VF_Port-fähige FCF-MAC bezeichnet. Die Unterstützung beider Arten von Paaren in einer FCF-MAC ist untersagt. Die MAC-Adressen für FCF-MACs müssen andere sein als die für ENode-MACs.

Der FCoE-Controller realisiert die bereits bei den ENodes angesprochenen Funktionen FIP und VLAN-Discovery entsprechend, nur eben auf der anderen Seite, sowie die Bildung und Löschung von Instanzen der Port/LEP-Paare, sodass wir uns die weiteren Einzelheiten hier sparen können.

Es gibt in diesem Zusammenhang auch noch eine Reihe von Ausführungen hinsichtlich der zu verwendenden Adressierungsschemata, die aber für die Bewertung keine wirkliche Rolle spielen.

Aus den Funktionalmodellen ergibt sich aber eine ganz andere, wichtige Konsequenz. Einer vielfach verbreiteten Vorstellung nach kann man Ethernet-Switches „irgendwie“ mit FCoE-Ports und ein bisschen Software (DCB) so aufrüsten, dass diese dann den FC-Verkehr tragen. Das ist unrichtig!

Es ergibt sich vielmehr folgendes Bild: es gibt echte FC-Switches und echte Ethernet-Switches. Möchte man das jetzt miteinander verbinden, reicht es nicht aus, die Ethernet-Switches aufzurüsten. Das muss man ohnehin machen, damit sie die Lossless Eigenschaft so gut unterstützen, wie es eben geht.

Stattdessen muss man auf der FC-Seite einen echten FC-Switch so aufrüsten, dass er auf der „einen Seite“ echtes, natives FC-Switching unterstützt und auf der „anderen Seite“ FCoE-Ports für den Übergang zur Ethernet-Struktur bereitstellt. Das liegt einfach daran, dass man einem normalen Ethernet Switch unabhängig von seiner Bauform und Leistung nie und nimmer beibringen kann, wie natives FC-Switching vor sich geht.

Ein FCF wird also immer ein Gerät für beide Welten sein, dessen Kern immer ein FC-Switch ist. Bei der modularen Bauart moderner Ethernet-Switches wird es aber in Zukunft kein Problem sein, eine größere Einschubkarte zu konstruieren, deren Herz eben ein von der sonstigen Switching-Plattform unabhängiger FC-Switch ist. Als Einzelgerät gibt es das schon längst. Das System 8000 von Brocade wäre ein Beispiel für einen FCoE-Switch mit FC-Herz. Das ist übrigens alles überhaupt nicht negativ zu beurteilen, denn die Aufrüstung eines ganzen Core Ethernet Switches in der Weise, dass er auch natives FC-Switching unterstützen würde, wäre vollständig mit Kanonen auf Spatzen geschossen.

Der Einfluss auf die Konstruktion der HBAs

Gleichzeitig ebnet der Standard aber den Weg für eine übersichtliche Konstruktion der HBAs und der entsprechenden Adapter auf Speichersysteme. Ausgehend von einer nativen FC-Fähigkeit können sie durch einfache Maßnahmen auf FC (FCoE-HBAs) aufgerüstet werden. Von der technischen Transceiverseite unterscheiden sich 10 GbE-Adapter und 8/10 GFC-Adapter kaum. Da kann man in vielen Fällen eine einheitliche Hardware verwenden, was über die so höhere Stückzahl deren Preis senkt. Für FCoE sind dann nur die entsprechenden Kontrollelemente zu installieren. Hier hat Qlogic bei der Erstellung des Standards sehr gut aufgepasst. Es sind natürlich auch reine FCoE-HBAs denkbar.

FCoE Virtual Links

Die Abb. 3 zeigt, wie das FCF Funktionalmodell Virtual Links zwischen VE_Ports aufbaut. Hier kommt ein weiteres Protokoll zum Tragen, das Exchange Link Parameters (ELP). Es ist Bestandteil von FIP. Nach erfolgreicher Beendigung des ELP-Kontrolldatenaustauschs erzeugen die FCoE-Controller der zwei involvierten FCF-MACs Instanzen von VE_Port/LEP-Paaren. Die Link Endpunkte sind dann die VE_Port-fähigen FCF-MACs.

Die Abbildung 4 zeigt entsprechend die Verbindung zwischen einem ENode und einem FCF. Hier sieht man deutlich mehrere virtuelle Links, die durch die bisher besprochenen Funktionen sehr elegant hergestellt werden können und durch entsprechende MAC-Paare und die damit assoziierten Zuordnungen sowie die Pot/LEP-Paar-Instanzen eindeutig identifiziert und gesteuert werden können.

Es gibt hierzu im Standard wieder eine Reihe von Ausführungen zu Adressierungsmethoden. Stattdessen zeigen wir aber das FCoE-Frameformat, welches Positionen für alle Kontrollnachrichten besitzt, die im Rahmen der bisherigen FC-BB_E-Steuerprotokolle benutzt werden und darüber hinaus noch genügend Platz für spätere Erweiterungen bietet; siehe Abbildung 5.

Es sei noch erwähnt, dass es für die Kontrollprotokolle auch eigene Frames gibt, die sich in ihrem Format vom FCoE-Frame deutlich unterscheiden.

Das Wichtige an diesen Frames ist, dass sie auch in sehr ungünstigen Fällen, in denen ein Ethernet wegen erhöhter Congestion trotz aller Gegenmaßnahmen dazu neigen würde, Pakete wegzuwerfen, so kompakt und unauffällig sind, dass die Wahrscheinlichkeit für ihr Durchkommen extrem nahe 1 ist – vor allem, wenn man sie auf der Ethernet-Ebene noch mit der höchsten Priorität versieht.