Suchen

Die (R)Evolution der Rechenzentren; Teil 21 Techniken für konvergente Netze – Das Lossless Ethernet

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

Möchte man Speicherdaten aus einem FC-Umfeld über ein konvergiertes Ethernet leiten, muss bedacht werden, dass ein Fibre Channel Netz niemals Pakete verwirft und der FC-Speicherverkehr dieses „Feature“ zwingend erwartet. Ein „normaler“ Ethernet-Switch verwirft Pakete, die er weder zwischenspeichern noch abarbeiten kann und eignet sich daher nicht für FCoE. Switches, die via Ethernet Pakete eines FC-Speicherverkehrs übertragen sollen, müssen daher über eine erweiterte Funktionalität verfügen.

Firmen zum Thema

Die Zahl der Paketverluste beim Routing in großen Provider-Netzen steigt mit der Auslastung rasant an; Bild: Dr. Franz-Joachim Kauffels
Die Zahl der Paketverluste beim Routing in großen Provider-Netzen steigt mit der Auslastung rasant an; Bild: Dr. Franz-Joachim Kauffels
( Archiv: Vogel Business Media )

Der grundsätzliche Unterschied in der Arbeitsweise von FC und Ethernet ist folgender: zwischen FC-Sender und FC-Empfänger gibt es einen Credit-Mechanismus. Bevor ein Sender etwas senden darf, muss er Credits vom Empfänger bekommen haben. Er darf dann nur so viele Pakete senden, wie es Credits gibt. Sind diese verbraucht, muss der Sender warten, bis es neue gibt. Das kann man natürlich auch in einem Sliding Window Prozess organisieren. So kann der Empfänger sich jederzeit vor Überlastung schützen. Kommt er in eine Situation, in der er keine weiteren Pakete mehr versenden kann, gibt er einfach keine Credits mehr. Das funktioniert wunderbar.

FC-Geräte verlassen sich nun darauf, dass dieser Mechanismus immer wirkt und es keinerlei Paketverluste gibt.

Ein konventionelles Ethernet hingegen kann durchaus Pakete verlieren. Ein Sender schickt Pakete über eine Leitung an den nächsten Empfänger, z.B. ein Endgerät oder einen Switch, in der optimistischen Annahme, dass diese immer verarbeitet werden können. Ist das nicht der Fall, verwirft das Ziel-Gerät die Pakete und sie gehen für immer verloren. Die einzige Möglichkeit, in einem Ethernet den Verkehrsstrom abzustellen, ist das undifferenzierte PAUSE-Kommando nach IEEE 802.3x. Es gibt eine Reihe betrieblicher Bedenken gegen den Einsatz des PAUSE-Kommandos, sodass es in den meisten Implementierungen einfach abgeschaltet wird. Insgesamt kann es auch gegen Paketverlust wenig ausrichten. Abbildung 1 zeigt die gegensätzliche Arbeitsweise von FC und Ethernet.

In einem herkömmlichen Netz würde man derartige Probleme in Layer 4 z.B. mit TCP auffangen. FC-Geräte können aber kein TCP/IP.

Betrachtet man alle möglichen Alternativen für den Speicherverkehr, gibt es dieses Problem nur mit FC-Verkehr. iSCSI benutzt den TCP/IP-Stack, verloren gegangene Pakete werden einfach erneut angefordert. Genauso verhält es sich mit NFS.

Die Unklarheiten rund um den Begriff „Lossless“

Zunächst einmal erscheint die Konvergenz mit FCoE schön und gut, aber bei „Lossless“ geht es schon mit dem Begriff selbst los. Der Begriff ist nicht sauber definiert. Es handelt sich nicht um Verlustfreiheit bei der Bitübertragung. Üblicherweise werden Übertragungssysteme so definiert, dass sie ca. im Bereich von 10 exp -15 bis 10 exp -18 für die Bitfehlerwahrscheinlichkeit liegen. Derartige Verluste können über Prüfsummen kompensiert werden.

Es handelt sich zudem nicht um Verlustfreiheit bei der Ablage von Bits in Speichermedien (oder von den Speichermedien zu Hosts), denn diese wird üblicherweise durch fehlererkennende und -korrigierende Codes implementiert.

Es handelt sich einfach darum, dass alle zur Übertragung anstehenden Datenpakete auch heil durch die Switching Fabric laufen, ohne dass ein einziges weggeworfen wird – was Ethernet Switches in Überlastsituationen gerne machen. Das hört sich trivial an, ist es aber nicht!

Und dann wären da noch die Fragen, ob es sich wirklich um alle Datenpakete dreht, oder ob man doch einzelne Verluste hinnehmen kann? Und wenn ja, wie viele bezogen auf die Gesamtzahl zu übertragender Pakete?

Momentan fühlt sich irgendwie niemand dafür zuständig, „lossless“ wirklich zu definieren. Das liegt hauptsächlich daran, dass der Begriff jeweils in einem gewissen Kontext gesehen werden muss. Ein Hersteller wie Cisco z.B. positioniert den Begriff momentan noch im Zusammenhang mit Ethernet auf den Server-Speicher-Verbindungen, ohne aber auch hier konkret zu sagen, wievielte Pakete denn nun verloren gehen dürfen, um dennoch von „lossless“ sprechen zu können.

Wir können uns der Thematik aber anders nähern und finden dann auch konkrete Aussagen – allerdings müssen wir dafür den Bereich völlig wechseln, nämlich vom RZ-Netz zu einem Provider-Netz.

weiter mit: SONET als Beispiel

Artikelfiles und Artikellinks

(ID:2050700)