ADVA Optical Networking tritt Brocade Developer Program bei

Durchbruch bei der Vereinfachung der RZ-Fernkopplung

30.03.2011 | Autor / Redakteur: Dr. Franz-Joachim Kauffels / Andreas Donner

ADVA Optical und Brocade gehen eine viel versprechende Entwicklungspartnerschaft ein
ADVA Optical und Brocade gehen eine viel versprechende Entwicklungspartnerschaft ein

Viele der im Zusammenhang mit RZ-Netzen verwendeten Übertragungssysteme und Steuerungsverfahren eignen sich nur für geringe Distanzen, also für die Anwendung innerhalb des Rechenzentrums. Auf der anderen Seite gibt kaum ein RZ, das nicht auch in die Fernkommunikation eingebunden ist. Nun hat sich ADVA Optical, erfahrener Spezialist mit hohem Innovationspotenzial, dem Entwicklungsprogramm des führenden Herstellers von Lösungen für RZ-Netze, Brocade, angeschlossen. Dies wird letztlich zu sehr eleganten Lösungen für die RZ-Fernkommunikation führen.

Besonders evident wird die Problematik der Weitverkehrsvernetzung von Rechenzentren dann, wenn ein Unternehmen oder eine Organisation mehrere Data Center unterhält – was natürlich auch der Ausfallsicherheit dienen soll. Die heute diesbezüglich installierten Lösungen sind oft deutlich hinter dem aktuellen Stand der Entwicklung zurück. Andererseits werden die Anforderungen an RZ-Netze, wie wir sie immer wieder beschreiben, an den physikalischen Grenzen eines RZs nicht Halt machen.

Dabei gibt es extrem elegante Lösungen für flexible und latenzarme Fernkommunikation, die aber oft nicht richtig verstanden werden.

Ein wesentliches Thema in RZ-Netzen ist die Konvergenz zwischen normalem Daten- und Speicherverkehr z.B. mittels FCoE oder iSCSI. Für einen Betreiber bleiben aber verschiedene Fragestellungen übrig.

Durch FC-BB-5 haben wir die Konvergenz von FC und Ethernet via FCoE/FC-BB_E erreicht. Jeder gängige Speicherverkehr kann mittels iSCSI oder FCoE auf angereichertes Ethernet (CEE/DCE/DCB) in Grenzen abgebildet und hier konvergiert übertragen werden.

Was aber ist mit den Kanälen ESCON, FICON und Infiniband (IB)?

Kann die Konvergenz auch auf die Kanalarchitekturen ausgeweitet werden, z.B. für eine konvergierte Übertragung zu einem Ausweich-RZ ? Und, noch viel gravierender: klappt das auch mit dem Speicherverkehr?

Kein Standard

Um es klar zu sagen: bis jetzt hat sich kein Standardisierungsgremium dieser Frage angenommen. Für die Verlängerung von ESCON, FICON und IB gibt es Lösungen von verschiedenen Herstellern, die sich hauptsächlich hinsichtlich Preis und Leistung unterscheiden und auf diversen technischen Grundlagen basieren.

Innerhalb des RZs herrscht angesichts der vielfältigen neuen Switchprodukte, die alle auch DCB und FCoE anbieten sozusagen Friede, Freude, Eierkuchen.

Schon fast penetrant bleibt aber die Frage übrig, wie sich die Situation außerhalb des RZs darstellt. Es gibt hier einen weiten Bereich von Anforderungen vom einfachen asynchronen Backup bis hin zum vollständigen synchronen Betrieb eines Ausweichrechenzentrums abzudecken. Dadurch ergeben sich natürlich hinsichtlich der einzusetzenden Technologien Unmengen von Alternativen für die jeweiligen Zwecke.

Diese Diskussion können wir gerne führen, aber nicht hier und jetzt. Ab einer gewissen Ansammlung von Anforderungen und Leistungsmerkmalen ist ohnehin am Ende der Wellenlängenmultiplex (DWDM oder CWDM) die einzige Lösung. Bei einer solchen Replikationslösung spielen neben den Speicherschnittstellen ja auch noch andere Schnittstellen eine Rolle, wie ESCON-Kanalverlängerungen, deren Existenz man auch heute noch nicht unterschätzen sollte.

iSCSI ist von sich aus darauf ausgelegt, mit einem „normalen“ Ethernet zurechtzukommen. Also wird es auch dann gut funktionieren, wenn das Ethernet durch eine CWDM oder DWDM-Lösung nachgebildet wird.

Anders sieht die Situation für FCoE aus. Manche werden denken: „fein, wenn FC auf Ethernet abgebildet wird, kann ich das ja nicht nur im RZ nutzen, sondern auch auf meinem ganzen Corporate Backbone.“

FCoE: Verwendung nur in RZ-Switching-Fabrics

Das ist definitiv unrichtig. Zunächst einmal muss man deutlich klarstellen, dass FCoE von der Standardisierung durch SNIA und INTICS ausschließlich für die Verwendung in Switching Fabrics innerhalb des RZs gedacht ist. Es kann nun sein, dass ein Vertriebsbeauftragter eines Herstellers irgendwie zu viel Optimismus getankt hat und diesen Punkt übersieht. Kein seriöser Hersteller wird jedoch bewusst diese falsche Darstellung verfolgen.

Um es zusammenzufassen: schickt man einen FCoE Datenstrom auf ein ausgedehntes normales Ethernet, wird der mit diesem zu übermittelnde SCSI-Datenstrom langsam aber sicher zugrunde gehen.

Das glauben Sie mir jetzt natürlich nicht ohne weitere Erläuterung. Dazu muss ich aber leider erst ein paar Begriffe klären, damit es verständlich wird.

Exkurs in die Begrifflichkeiten

Um die Details des Speicherverkehrs richtig zu verstehen, ist es wichtig, die Begriffe synchron, asynchron und plesiochron auseinanderzuhalten.

In einer Menge synchroner Signale geschehen die digitalen Transitionen innerhalb der Signale exakt mit der gleichen Taktrate. Es darf aber eine Phasendifferenz zwischen den Transitionen der zwei Signale geben, solange sie innerhalb spezifizierter Grenzen liegt. Diese Phasendifferenzen können durch Verzögerungen in der Ausbreitung des Signals oder durch Jitter, der im Übertragungsnetz entsteht, hervorgerufen werden.

In einem synchronen Netz können alle Uhren (Takte) auf eine zentrale Referenzuhr (Takt) PRC zurückgeführt werden. Die Genauigkeit der PRC ist höher als +/-1 in 10 exp. 11 und wird von einer Cäsium-Atomuhr abgeleitet.

Bei zwei plesiochronen Signalen geschehen die Transitionen meist mit der gleichen Rate, wobei jede Abweichung in Grenzen liegen muss. Das tritt z.B. dann auf, wenn zwei Netze zusammenarbeiten müssen, die auf verschiedenen Referenzuhren basieren. Obwohl diese Uhren extrem genau sind, gibt es Unterschiede zwischen ihnen. Dies ist als plesiochrone Differenz bekannt. Man kann sich das auch anders merken: im Altgriechischen heißt plesiochron „vieluhrig“.

Bei asynchronen Signalen müssen die Transitionen der Signale nicht notwendigerweise in den gleichen Nominalraten geschehen. Asynchron bedeutet in diesem Fall, dass die Differenz zwischen zwei Uhren wesentlich größer ist als im plesiochronen Fall. Das ist .B. der Fall, wenn zwei Uhren von verschiedenen freilaufenden Quarzoszillatoren abgeleitet werden.

SCSI-Informationsstrom zwischen Speicher und Server

Zwischen Speichern und Servern wollen wir einen SCSI-Informationsstrom laufen lassen. SCSI ist ein Übertragungsprotokoll, welches ursprünglich auf einem möglichst breiten Systembus innerhalb eines einzigen Rechners oder eines Racks lief. Diese Umgebung zeichnet sich dadurch aus, dass sie entweder synchron (in einem Rechner) oder plesiochron (getrennte Geräte in einem Rack) ist. Möchte man also einen SCSI-Informationsstrom auf etwas anderes abbilden, muss man dies berücksichtigen.

Ein Ethernet arbeitet grundsätzlich völlig asynchron. Bleibt das Ethernet, wie im RZ, räumlich klein, gibt es kaum Laufzeitprobleme und Jitter. Ist dann auch noch die Schaltgeschwindigkeit der Switches so ausgelegt, dass ein Ethernet-Paket gar nicht merkt, ob es nun grade über eine Leitung oder durch einen Switch läuft, kann man die Übertragung auch als plesiochron klassifizieren. Moderne Switches haben damit kaum ein Problem. Es ist ja lediglich notwendig, dass die Switching-Latenz in einem vernünftigen Verhältnis zur Daten- bzw. Paketrate steht.

Fibre Channel hat sich genau das zunutze gemacht. FC wurde für geringe Entfernungen, breite Übertragungswege und schnelle Switches mit vergleichsweise wenigen Ports definiert. FC ist somit ein „unechtes“ plesiochrones System. So kann man denn auch FCoE in diesem Zusammenhang sinnvoll betreiben, wenn die plesiochrone Qualität durch die Konstruktion der Switching Fabric gegeben ist.

Der SCSI-Informationsstrom verträgt zwar Unterbrechungen, aber keinesfalls ein zu großes Delay oder gar eine große Delayvarianz zwischen den einzelnen Teilen eines zu übertragenden Blocks, der Grundeinheit für diese Technik.

FCoE hat aber von sich aus absolut keine Mittel, um Delay oder Delay-Varianz zwischen den einzelnen FCoE-Ethernet-Paketen zu verhindern. Wachsen diese Werte in einem großen und/oder verzweigten Netz zu stark an, kann sich FCoE nicht dagegen wehren und als Konsequenz reißt der SCSI-Informationsstrom mit einem Fehler ab, obwohl alle Pakete übertragen wurden.

Lossless

Damit kommen wir auf den Begriff „Lossless“. Wir haben in den Untersuchungen der letzten Jahre ja schon gesehen, dass es relativ mühsam ist, „Lossless“ in einer sehr überschaubaren Umgebung innerhalb des RZs zu implementieren. In einem verzweigten und/oder ausgedehnten Ethernet ist dies mit den bisher verfügbaren Hilfsmitteln praktisch ausgeschlossen. Außerdem sehen wir jetzt, dass „Lossless“ für FCoE eine notwendige, aber keinesfalls hinreichende Voraussetzung ist.

Wenn Sie tatsächlich FCoE über eine größere Distanz übertragen möchten, mussten Sie bis jetzt SONET mit ANSI „Ethernet over SDH“ nehmen. Das klappt gut, weil SONET ein plesiochrones System ist und Sie für diesen Zweck dort einige der permanent umlaufenden Transportcontainer nutzen können, die natürlich auch lossless arbeiten. Aber das ist sozusagen von hinten durch die Brust ins Auge: FC-Abbildung auf Ethernet via FCoE, danach Ethernet-Abbildung auf SONET-Ocx via ANSI EoSDH und zurück. Da soll nochmal einer etwas über die Komplexität von iSCSI sagen.

FCIP – FC over IP

Es gibt ja auch noch FCIP, also FC over IP. Wenn Sie mich fragen, halte ich das für extremen Kokolores. SCSI-Daten sind letztlich Kanaldaten, würden also im ISO-Referenzmodell auf der Schicht 1 und der unteren Hälfte der Schicht 2 angeordnet. Man liftet dann diesen Datenstrom auf die Schicht 4, um es sozusagen als Anwendungs-Datenstrom unter TCP/IP laufen zu lassen. Das mag technisch funktionieren, ist aber ein extremer Exot. Außerdem kritisieren die Befürworter von FCIP immer wieder iSCSI, da passiert aber genau das Gleiche. Nur hat iSCSI eine derart breite Basis, weil es ja auch für kleinere und preiswertere Systeme konzipiert ist, dass man davon ausgehen kann, dass der durch iSCSI verursachte Overhead einfach durch einen integrierten Offload-Prozessor abgearbeitet wird, wie man das bspw. bei der neuesten Generation von Broadcom-Switching-Chips findet. Eine solche Entwicklung ist bei FCIP nicht zu erwarten.

weiter mit: Die Alternative: extrem latenzarme optische Verbindungen

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 2050649 / Rumours, Facts & Visions)