| FCoE - Was es ist und was es bringt |
 |
Die Konsolidierungswelle rollt und wächst. Durch die Verbreitung von Virtualisierungslösungen getrieben, wird seit geraumer Zeit - genauer gesagt seit Ende 2007 - auch an einer Lösung zur Konsolidierung von I/Os gearbeitet. Der Heilsbringer heißt hier Fibre-Channel-over-Ethernet (FCoE).
|
|
| von Marco DeLuca, Brocade |
|
|
Einer der wichtigsten Aspekte von FCoE ist, dass hier Fibre-Channel und Ethernet zusammentreffen und eine neue konvergierte Technologie entsteht, die es ermöglicht, sowohl Fibre-Channel-Daten wie auch IP-Daten über diesen Transportmechanismus zu übertragen. Dies bringt viele Vor- aber auch Nachteile. Aber fangen wir erst mal vorne an.
Fibre-Channel (FC) ist heute ein akzeptiertes und weit verbreitetes Protokoll zum Transport von SCSI-Daten und -Befehlen zwischen Servern und Speichersystemen.
|
|
|
FC wurde für diese Aufgabe entwickelt und bringt dementsprechend spezielle Mechanismen hierfür mit. Es ist zum Beispiel verbindungsorientiert und Sender und Empfänger bauen eine permanente Verbindung zueinander auf - und auch wieder ab, wenn diese nicht mehr benötigt wird.
|
|
|
Ein Mechanismus namens »Buffer-to-Buffer Credits« erlaubt, verlustfrei FC-Frames zu übertragen. Hierbei werden zum Beispiel an den FC-Switchports Daten in Puffern zwischengelagert, bevor sie ausgeliefert werden. Sind die Puffer voll, wird der Sender benachrichtigt und es werden keine weiteren Frames mehr verschickt, bis wieder Puffer zur Verfügung stehen. Ein Verlust von Frames wäre im FC-Umfeld ein großes Problem und würde schnell zu einem Server-Ausfall führen oder den Absturz einer wichtigen Applikation verursachen.
|
|
| Zwei Protokolle für unterschiedliche Anforderungen verheiraten |
|
|
Auf der anderen Seite haben wir Ethernet und die darauf aufsetzenden Protokolle. Ethernet ist zirka 30 Jahre alt und wurde ursprünglich zur Vernetzung von Ressourcen wie Rechner und Drucker entwickelt. Es musste günstig sein und ein Ausfall hatte keine massiven Folgen auf die unternehmensweite IT.
|
|
|
Technisch wurde Ethernet für ganz andere Anforderungen entwickelt, die mit denen von Fibre-Channel nicht mithalten können. Ethernet wurde auf Basis einer so genannten Collision-Domain realisiert, an die verschiedene Ressourcen mittels eindeutiger MAC-Adresse angeschlossen wurden. Alle Stationen im Netz waren mehr oder weniger gleichberechtigt und konnten alle Datenpakete empfangen. Anhand der MAC-Adresse war jede Station in der Lage, die an ihre Adresse gesendeten Daten herauszufiltern.
|
|
Bild 1: Die unterschiedlichen Schichten von Ethernet und Fibre-Channel. Grafik: Brocade
Wie man nun aus beiden kurzen Erläuterungen oben bemerkt, treffen hier quasi zwei Welten aufeinander. Fibre-Channel als sehr zuverlässiges Transportmittel, das als verlustfrei gilt, und auf der anderen Seite Ethernet, welches keine Probleme mit dem Verlust oder der Auslieferung von Paketen außerhalb der Sendereihenfolge hat.
|
|
|
Damit man nun Fibre-Channel-Pakete über ein Ethernet-Transport-Protokoll verschicken kann, haben sich verschiedene Hersteller von Speicherlösungen und Netzwerkkomponenten zusammengesetzt und einen Vorschlag zum FCoE-Standard entwickelt. Dieser wurde beim INCITS (ANSI) T11 Komitee eingereicht, welches auch den FC-Standard entwickelt hat.
|
|
|
FCoE legt fest, wie man Fibre-Channel-Daten verlustfrei transportieren kann. Dieses »Lossless Ethernet« besteht aus zwei Protokollen: Einmal das Protokoll zum Transport der Daten, FCoE genannt, und zweitens das Protokoll zur Kontrolle der FCoE-Verbindungen, FIP (FCoE Initialisation Protocol) genannt. FIP kümmert sich zum Beispiel um das Login und Logout von Geräten in einem FCoE-Netzwerk.
|
|
Bild 2: So wird Legacy-Ethernet zum Converged-Enhanced-Ethernet. Grafik: Brocade
FCoE verpackt den FC-Frame in einen Ethernet-Header und verschickt diesen dann über Ethernet, wobei nun aber kein so genanntes Legacy-Ethernet (traditionelles Ethernet) mehr zum Einsatz kommt, sondern eine verbesserte Variante, genannt »Converged Enhanced Etherent« (CEE), bzw. »Data Center Ethernet« (DCE).
|
|
Bild 3: Format eines FCoE-Frames. Grafik: Brocade
Wie in Bild 2 zu erkennen, wird zwischen den FC-Services-Schichten eine Enkapsulierung (FCoE) eingefügt und die Transportschichten auf Layer 1 und Layer 2 werden FC-tauglich gemacht, indem man normales Ethernet zum Converged-Enhanced-Ethernet verbessert.
|
|
| FCoE-Standard seit Juni 2009 verabschiedet |
|
Um Ethernet nun verlustfrei arbeiten zu lassen, sind weitere Protokolle nötig, die von anderen Standardisierungsgremien entwickelt werden. Zu diesen gehören sowohl IETF (Internet Engineering Task Force) wie auch IEEE (Institute of Electrical and Electronics Engineers). IEEE arbeitet an vier Protokollen, die den Datenfluss und die Prioritäten im Ethernet-Transport regeln. Dazu zählen:
• 802.1Qbb Priority Flow Control (PFC),
• 802.1Qaz Enhanced Transmission Selection (ETS),
• DCBX (Data Center Bridging Exchange protocol für 802.1Qaz),
• 802.1Qau Congestion Notification.
|
|
Bild 4: Prioritäten innerhalb von PFC. Grafik: Brocade
Da zukünftig verschiedene Protokolle über das Converged-Enhanced-Ethernet fließen sollen, ist zu regeln, welches Protokoll welche Prioritäten bekommt. Dazu verwendet PFC Prioritäten von 0 bis 7, denen sich verschiedene Protokolle zuordnen lassen. Diese können anschließend zu Prioritätsgruppen zusammengebunden werden. Für jede Prioritätsgruppe kann eine unterschiedliche Bandbreite gelten.
|
|
|
Neben diesen beiden Protokollen arbeitet IEEE auch an DCBX. Das Protokoll »Data Center Bridging Exchange« ist für das »Abstecken« der CEE-Umgebung zuständig. Es überprüft, wo die Grenzen zum normalen 10-Gbit/s-Ethernet sind und markiert somit, wo FCoE-Daten noch fließen können und wo nur noch IP-Daten weitergereicht werden können.
Congestion Notification ist ein weiteres Protokoll, welches innerhalb der CEE-Wolke für das Erkennen von Verstopfungen zuständig ist. Speziell hier wird noch am Standard gearbeitet, dieser hat jedoch noch nicht den Status »Implementation agreed«. Dies bedeutet, dass diese Funktionalität noch nicht in die aktuell erhältlichen Produkte integriert ist. Bisher liegt kein Vorschlag für eine Umsetzung vor.
|
|
|
Neben IEEE ist zusätzlich noch die Standard-Organisation IETF für das TRILL-Protokoll (Transport of Information over Lots of Links) zuständig. Dieses Protokoll stellt das Multipathing innerhalb einer Ethernet-Wolke (Lossless) sicher und soll in CEE das alte Spanning-Tree-Protokoll überflüssig machen.
|
|
| Zukünftig nur ein Protokoll und nur ein Switch |
|
|
Zusammengefasst bedeutet das, dass wir zukünftig mit CEE/FCoE zwei wichtige Protokolle wie IP und FC über nur ein Medium, sprich Kabel, fahren können. Des Weiteren wird auch nur ein Switch benötigt, der CEE und FCoE unterstützt und somit den Transport beider Protokolle möglich macht. Daraus ergeben sich vielfältige Vorteile in der Verkabelung, weniger Switches, die Vereinfachung von Administrationsaufgaben und weniger Energiebedarf. Es kann auch mit geringeren Kosten gerechnet werden, sobald diese Technologie einmal ein akzeptables Preisniveau erreicht hat.
|
|
|
Dagegen steht eine komplexere Technologie, die im Falle von Problemen sicher schwieriger zu beherrschen sein wird. Außerdem gehören FCoE-Switches halb zu Fibre-Channel und halb zu IP. Um die Kontrolle dieser Switches wird sicherlich ein politisches Gerangel zwischen den Abteilungen beim Anwender stattfinden. Es gibt viele weitere Vor- und Nachteile, letztendlich wird der Endanwender entscheiden, ob die FCoE-Technologie erfolgreich sein wird oder nicht.
|
|
| Fazit: Freunden Sie sich mit der Technologie langsam an |
|
|
Bis dahin wird allerdings noch einiges an Zeit vergehen, da erst Mitte/Ende 2010 mit der Fertigstellung aller notwendigen Protokoll-Standards zu rechnen ist und ein produktiver Einsatz in Betracht kommt. Dementsprechend sollte man sich mit dieser Technologie langsam anfreunden und deren Entwicklung beobachten. Sind aber aktuell Neuanschaffungen notwendig, ist ein kompletter Umstieg auf diese neue Technologie nicht sinnvoll. Sowohl die Kosten als auch die Zuverlässigkeit aktueller Komponenten sind im Moment noch die bessere Anlage und aktuelle Produkte können maximal als so genannte Top-of-Rack-Switches zur Anbindung von Rack-Servern genutzt werden. Damit wäre man auf zukünftige konvergierte Netzwerke vorbereitet und könnte gleichzeitig schon 10-Gbit/s-Ethernet-Technologie zur Serveranbindung einsetzen.
|
|
|
|
