Suchen

Die (R)Evolution der Rechenzentren; Teil 37

FCoE nach FC-BB-5 – Modelle für die Funktionalität von FC-BB_E

Seite: 2/2

Firmen zum Thema

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.

Bildergalerie
Bildergalerie mit 5 Bildern

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.