Suchen

Die (R)Evolution der Rechenzentren; Teil 22 Techniken für konvergente Netze – Congestion Management & Control

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

Eine Möglichkeit, die in der letzten Folge vorgestellte „Lossless“-Übertragungseigenschaft auch in einem Ethernet durchzusetzen, sehen viele Hersteller im Mechanismus des Congestion Management verbunden mit der Congestion Control. Dabei soll letztlich jeder Switch eine drohende Stausituation an die sendenden Switches melden, sodass diese entsprechend darauf reagieren können. Eine solche Technik gibt es bei Fernnetzen, aber ist sie auch in einem RZ-Netz sinnvoll?

Firmen zum Thema

Priority Based Flow Control ist eine Maßnahme um Stausituationen in konvergierten Netzten beherrschbar zu machen; Bild: Dr. Franz-Joachim Kauffels
Priority Based Flow Control ist eine Maßnahme um Stausituationen in konvergierten Netzten beherrschbar zu machen; Bild: Dr. Franz-Joachim Kauffels
( Archiv: Vogel Business Media )

Um zu erreichen, dass kein Paket weggeworfen wird, setzen Hersteller und Standardisierung auf die so genannte Congestion Control. Wenn in einem Switch ein Problem entsteht, sollen dabei alle anderen Switches benachrichtigt werden können und daraufhin die Aussendung von Paketen komplett unterlassen oder einschränken. Sowohl Hersteller als auch Standardisierung arbeiten in einem solchen Fall mit priorisierten Warteschlangen. Wir werden noch sehen, wohin das führt.

Sowohl von z.B. Cisco als auch von IEEE gibt es nun Äußerungen dazu, wie ein Lossless Ethernet trotzdem funktionieren soll, und zwar auf Basis der so genannten Congestion Control.

Bildergalerie

Bildergalerie mit 8 Bildern

O-Text Cisco: „Die Cisco IOS Congestion Management Eigenschaften erlauben Ihnen, die Stausituation dadurch zu kontrollieren, dass die Reihenfolge von Paketen, die über eine Schnittstelle ausgesendet werden, durch Prioritäten, die diesen Paketen zugeordnet werden, bestimmt wird.“

O-Text IEEE 802.3ar Congestion Management: „Es wird ein Verfahren entwickelt, das für die Verbreitung von Staumeldungen sorgt und gleichzeitig eine Begrenzung des Verkehrs auf Ethernet-Strecken erlaubt, ohne dass sich am MAC/PLS Interface etwas ändert.“ Und das machen sie dann auch mit priorisierten Warteschlangen.

Sowohl bei Cisco als auch bei IEEE gibt es damit verschiedene, abgestufte Verfahren, aber:alle diese Verfahren sind nicht deterministisch und benachteiligen nachrangig priorisierte Pakete.

Zusammenwachsende Ansätze

Die Verfahren von Cisco und IEEE unterscheiden sich heute noch leicht. Es ist aber kein Grund zu sehen, warum sie nicht in absehbarer Zeit zu einem vereinheitlichten, standardisierten System konvergieren sollten. Wir brauchen die Unterschiede hier nicht zu differenzieren, sondern betrachten zur generellen Funktionsweise einfach einmal ein Beispiel, siehe Abbildungen 1 bis 5.

Zur Erläuterung brauchen wir von einem Switch folgende Komponenten: Eingangswarteschlangen, Ausgangswarteschlangen, eine Switchmatrix und einen Puffer, siehe Abbildung 1.

In Abb. 2 sehen wir den Staubeginn. Die Kommunikationsrichtung ist von links nach rechts. Am Zielswitch gibt es ein Problem, so dass dieser seine Eingangswarteschlange nicht mehr entleeren kann. Also sendet er dem Quell-Switch ein PAUSE-Signal, damit dieser mit der Übertragung über seine Ausgangsschnittstelle aufhört.

Da wegen der PAUSE-Nachricht die Ausgangsleitung nicht mehr benutzt werden kann, muss der Switch die Datenpakete in einen Puffer umleiten, weil sie ja sonst verloren gehen würden, was wiederum nicht sein darf. Mit der Zeit wird der Puffer immer voller. Bei einer 10 GbE-Schnittstelle kommen 1,25 Gbyte pro Sekunde zusammen. Das kann der Switch nicht unbegrenzt fortsetzen, siehe Abb. 3.

Ist der Puffer weit genug vollgelaufen, hat der Switch selbst ein schwerwiegendes Problem und es bleibt ihm gar nichts anderes übrig, als selbst seine Eingangsleitungen zu sperren, und zwar alle, da er ja nicht weiß, welche Kommunikationsverbindung nun zu dem eigentlichen Problem geführt hat. Das sehen wir in Abb. 4. das Bild stellt einen Linksschwenk entgegen der Kommunikationsrichtung zu den Switches dar, die „vor“ dem bislang betrachteten Switch liegen.

Die ganzen in Kommunikationsrichtung zurückliegenden Switches (Bild 5) müssen nun ebenfalls ihre Ausgangswarteschlangen in Puffer umleiten, da sonst ja Pakete verloren gehen könnten. Wenn diese Puffer voll sind, müssen sie ebenfalls ihre Eingangspuffer sperren und der Effekt schlägt immer weiter nach hinten durch – so lange, bis das ganze Netz steht!

Das Beispiel hat gezeigt, dass es vollkommen unerheblich ist, ob ein Stau in einem Switch nun in einer einzelnen „normalen“ Warteschlange entsteht oder innerhalb einer Warteschlange in einer Gruppe von Eingangswarteschlangen. Zwei Switches „nach hinten“ ist der Unterschied nicht mehr differenzierbar. Der Standard IEEE 802.3ar möchte erreichen, dass die Switches einer Switching Fabric sofort informiert werden, wenn irgendwo ein Stau ist. Erstens ist das aber gar nicht so einfach, zweitens ist es ja schön, dass die Switches das dann wissen, die Frage ist nur, ob es etwas nützt.

weiter mit: Priority Bases Flow Control

Artikelfiles und Artikellinks

(ID:2050701)