04.01.2008 | Autor / Redakteur: Scott G. Kipp / Nico Litzel
Die klassische Fabric ist auf einen Adressbereich von „nur” 15 Millionen Ports beschränkt und für das Enterprise optimiert. FCoE muss eine komplexere Infrastruktur benutzen, in der priorisierte Services und redundante Pfadfunktionen wesentlich schwerer umzusetzen sind. Viel Feintuning ist deshalb noch notwendig, um einen ähnlich hochverfügbaren Datenzugriff wie beim FC zu erzielen. Gelingt die Umsetzung, haben die mit FC produzierten Insellösungen allerdings ein Ende.
Die Kanaleigenschaften (Channel Attributes) und speicherspezifischen Services des Fibre Channel lassen sich nicht nahtlos auf die Ethernet-Netzwerk-Infrastruktur übertragen. Fibre Channel over Ethernet (FCoE) benötigt deshalb umfangreiche Erweiterungen der herkömmlichen und der integrierten Services. Discovery, Notification und Name Services, mit denen der Status jeder Infrastrukturkomponente abgefragt werden, können wie auch Sicherheitsfunktionen und andere erweiterte Speicherdienste im Ethernet fehlen.
Erst mit der Umsetzung dieser und anderer wichtiger Funktionen, die den robusten Betrieb einer Kanalinfrastruktur im Rechenzentrum erlauben, wird FCoE eine gleichwertige Lösung zu den stabilen FC-Insellösungen werden. Erst dann nämlich lassen sich einfache Lösungen aufsetzen, um Fibre-Channel-Frames in Ethernet-Pakete zu verkapseln, die entweder als Kanal einen Ende-zu-Ende-Zugriff (FCoE-Initiatoren zu FCoE-Targets) ermöglichen oder für die Frame-Übersetzung in andere Protokolle (FCoE-Initiatoren und Fibre-Channel-Targets, Fibre-Channel-Initiatoren zu Fibre-Channel-Targets über Data Center Ethernet Backbone). Um für einen transparenten Einsatz beim Endbenutzer geeignet zu sein, muss allerdings das ganze umfangreiche Spektrum der erweiterten Fibre Channel Fabric Services erhalten bleiben.
Die primäre Herausforderung bei der FCoE-Entwicklung ist die Replizierung der von den Buffer-to-Buffer Credits in Fibre Channel geleisteten Flusskontrolle. Ethernet-Switches haben keinen vergleichbaren Puffer-Mechanismus. Dafür unterstützen die Ethernet-Standards Media Access Control, den sogenannten MAC-Frame, mit dem eingehender Datenverkehr schrittweise verarbeitet werden kann.
Der Flusskontroll-Standard IEEE 802.3x basiert auf einem Pause-Frame, der dafür sorgt, dass der Sender die nächste Übertragung für eine bestimmte Zeit zurückhält. Wird der Empfangspuffer geleert, bevor diese Zeitspanne vergangen ist, schickt der Empfänger einen weiteren Pause-Frame mit Pausezeit 0 (null), mit dem signalisiert wird, dass der Sender bis zum nächsten Pause-Frame weiter Daten verschicken soll.
Weil FCoE-Transaktionen gleichzeitige Lese- und Schreibvorgänge von Speicherdaten unterstützen müssen, ist es notwendig, dass alle Endgeräte und Ethernet-Switches in den Speicherpfaden des Netzwerks bidirektionales 802.3x unterstützen. Pause-Frames sind zwar die technisch schlechtere Lösung einer Paket-Zwischenspeicherung, sie bieten aber durch die schrittweise Verarbeitung des Speicherdatenverkehrs eine vergleichbare Funktionalität und tragen dazu bei, den durch Pufferüberläufe verursachten Frame-Verlust (Frameloss) zu minimieren.
Innerhalb der IEEE arbeiten die IEEE 802.3ar Congestion Management Study Group und die IEEE 802.1au Congestion Notification Group an Funktionen, um das Ethernet-Überlastungs-Management weiter zu verbessern. Speziell für Speichertransaktionen wäre es vorteilhaft, die Datenübertragungsmechanismen um Quality-of-Service-Level (QoS-Level) zu erweitern. Ähnlich wie bei Voice over IP (VoiP) könnten so besonders kritische Datenströme priorisiert werden.
Die Hochverfügbarkeitsmerkmale von Fibre-Channel-SANs basieren in der Regel auf flachen oder Core-Edge-Topologien. Redundante Pfade zwischen den Initiatoren (Servern) und den Targets (Speichersystemen) lassen sich auf solchen Infrastrukturen leichter realisieren. Beim Verlust eines einzelnen Host-Bus-Adapters (HBA), einer Verbindung, eines Switch-Ports, eines kompletten Switches oder eines Speicher-Ports wird automatisch ein Failover von primären zu sekundären Pfaden ausgelöst. Bei manchen Implementierungen sind auch beide Pfade gleichzeitig aktiv, sodass durch Lastverteilung eine bessere Ressourcennutzung möglich wird. In Fibre-Channel-Fabrics werden mithilfe des Fabric-Shortest-Path-First-Protokolls (FSPF) die optimalen Pfade zwischen Fabric-Switches ermittelt. Das geschieht in Abhängigkeit der Bandbreite und Datenlast der einzelnen Inter-Switch-Links (ISLs).
Die Fähigkeiten eines Failovers bei Infrastrukturausfällen sind für Speicheranwendungen auch in einer Ethernet-Infrastruktur unverzichtbar. In einer Full-Mesh-Topologie wird dazu das IEEE 802.1D Rapid Spanning Tree Protocol (RSTP) eingesetzt, um primäre Pfade durch das Netzwerk festzulegen. Zu vermeiden sind Schleifen, in denen Frames endlos kreisen könnten und redundante Pfade, die identische Hardware-Komponenten benutzen. Aktive Bridging-Ports zwischen den Switches werden auf Weiterleiten gesetzt (forwarding state), inaktive Failover-Brückenports gesperrt (blocking state).
Eine gesperrte Verbindung kann aber nicht für die Datenübertragung verwendet werden, sodass jede gesperrte Verbindung im Mesh-Netzwerk eine ungenutzte, im Leerlauf befindliche Ressource darstellt. Das Rapid-Spanning-Tree-Protokoll (RSTP) überwacht den Zustand aller Brückenports über Control-Frames oder Bridge Protocol Data Units (BPDUs). Beim Ausfall einer Verbindung, eines Brückenports oder Switches aktiviert das RSTP die Reserve-Brückenports für einen Failover. Dadurch werden alternative Pfade im Netzwerk bereitgestellt.
Eine zusätzliche Erweiterung betrifft alternative Pfade in Ethernet-Netzwerken. Diese wurde im IEEE 802.1s Multiple Spanning Tree Protocol (MSTP) definiert und inzwischen in die Spezifikation IEEE 802.1Q-2003 für virtuelle LANs (VLANs) aufgenommen. Analog zum Hard-Zoning in Fibre Channel ermöglicht VLAN-Tagging die gleichzeitige Existenz von bis zu 4.096 separaten Gruppen von Knoten (Nodes) in einer gemeinsamen Ethernet-Infrastruktur. Die MSTP-Erweiterung zu Spanning Tree erlaubt einen separaten Spanning Tree für jede VLAN-Gruppe. Ein Brückenport kann somit mehrere Anforderungen bedienen. Ist der Brückenport beispielsweise für ein bestimmtes VLAN gesperrt (blocking state), kann er trotzdem für ein anderes VLAN auf Weiterleiten (forwarding state) gesetzt sein, sodass die Netzwerkdurchleitungen insgesamt besser genutzt werden.
Aber auch mit MSTP-Erweiterungen führt die Abhängigkeit von RSTP von der einfachen Vergabe der beiden Zustände „blocking“ und „forwarding“ dazu, dass die Netzwerkverbindungen niemals wirklich optimal genutzt werden. Das funktioniert nur bei komplexeren Layer-3-Routing-Protokollen wie Open Shortest Path First (OSPF), die optimale Pfade zwischen den Endknoten auf der Grundlage des hop counts (Anzahl der Sprünge), der Bandbreite, der Latenz und anderen Faktoren berechnen können. Weiterhin können sie eine Lastverteilung (load balancing) über mehrere Pfade durchführen. Als Layer-2-Protokoll kann RSTP diese höherwertige Funktionalität nicht bieten, solange die Abwärtskompatibilität zu wahren ist.
Auf Layer 2 sind also weiter gehende Entwicklungen erforderlich, um vergleichbare Layer-3-Routing-Funktionen wie Lastverteilung (load balancing), Broadcast, Multicast und mehrfachen Anschluss in Layer-2-Ethernet-Netzwerken (multiple points of attachment, zum Beispiel einen einzelnen Node mit zwei aktiven Links zum gleichen Ethernet-Segment) zu ermöglichen. Für Fibre-Channel-Infrastrukturen gibt es Funktionen wie Bündelung (trunking), Lastverteilung (load balancing) und mehrfachen Anschluss (multiple points of attachment) schon seit langem. Bei RSTP besteht insofern erheblicher Nachholbedarf, um Ethernet speicherfreundlicher zu machen.
Im Montag erscheinenden dritten Teil geht es um Protokollkonvertierung, Mapping und Grenzen von iSCSI.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009843)
