Data Center Bridging DCB

Kommentieren Drucken
Teil 29 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Möchte man über ein konvergiertes Ethernet Speicherdaten, die aus einem FC-Umfeld stammen, übertragen, ist als Besonderheit zu berücksichtigen, dass der FC-Speicherverkehr davon ausgehen kann, dass das Fibre Channel Netz niemals Pakete verwirft. Also muss man die Grundqualität des Ethernets anheben, um die gewünschte I/O-Konvergenz zu erreichen. Das geschieht im Rahmen der durch die IEEE-Arbeitsgruppen unter dem Namen DCB definierten zusätzlichen Funktionen.

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, so dass es in den meisten Implementierungen einfach abgeschaltet wird. Insgesamt kann es auch gegen Paketverlust wenig ausrichten.

Abbildung 1 zeigt nochmals die gegensätzliche Arbeitsweise von FC und Ethernet.

In einem herkömmlichen Netz wird man das in L4 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.

IEEE DCB (Data Center Bridges): Überblick

Die DCB-Funktionen umfassen:

  • Staubenachrichtigung und rückwärts gerichtete Staubehebung
  • Prioritäts-basierte Flusskontrolle
  • Erweiterte Verkehrssteuerung
  • System zum Informationsaustausch der beteiligten Switches hinsichtlich der von ihnen unterstützten Funktionen

Die Funktionen wurden definiert, um der Idealvorstellung eines „lossless Ethernet“ möglichst nahe zu kommen. Diese zusätzliche Eigenschaft eines Ethernets wird dann benötigt, wenn man FCoE mittels FC-BB-5/FC-BB_E implementieren möchte.

Insgesamt sind die Funktionen aber auch sehr nützlich, wenn man gar kein FCoE benutzt. Sie führen letztlich zu einem Netz ganz neuer Qualität. In Abbildung 2 sehen wir die grundsätzliche Sichtweise eines RZs nach IEEE

DCB Congestion Notification und Congestion Control

Konventionelle Ethernet-Switches haben die unangenehme Eigenschaft, Pakete zu verwerfen, wenn die Eingangswarteschlangen in ihrer Summe so lang werden, dass der Switch annehmen muss, diese Warteschlangen nicht mehr sinnvoll abarbeiten zu können. Mögliche Gründe für das Auftreten dieser Situation sind:

  • Schlecht und mit zu hoher Überbuchung konstruiertes Netz
  • Zu kleine Speicher in den Switches
  • Defekt im Switch
  • Zu hohe Belastung des Switches aus multiplen Quellen

DCB Congestion Control arbeitet so, dass im Falle des bald zu erwartenden Auftretens einer Stausituation von den betroffenen Eingangsports (meist ist dies nur einer) eines betroffenden Switches eine Congestion Notification an den Auslöser der Überlast geschickt wird. Dieser senkt dann seine Datenrate. Die Hoffnung ist, dass sich die Stausituation dadurch auflöst.

Dabei ist zu bemerken, dass Congestion Control nur dann funktionieren kann, wenn die NIC des zu viel Verkehr erzeugenden Gerätes auch die entsprechenden Funktionen zur Senkung der Datenrate besitzt. Generell ist das vergleichbar mit der Senkung der Datenrate bei WLANs, wenn sich die Umgebungsbedingungen verschlechtern.

Praktisch ist DCB Congestion Control also auf die Endsysteme beschränkt, die das unterstützen. Das sind z.Zt. nur ganz moderne Server mit entsprechend eingerichteter Virtualisierungssoftware und einer I/O-Implementierung, die die Einschränkungen differenziert an die Virtuellen Maschinen weitergibt.

An den ersten drei Punkten kann DCB Congestion Control nichts ausrichten, sondern lediglich am letzten. Das sollte man aber auch nicht übertreiben, IEEE 802.1 sagt selbst, dass Simulationen gezeigt hätten, dass ein Verlust von Paketen durch die Congestion Control nicht völlig vermeidbar ist. Das Verfahren ist überdies nicht deterministisch.

Aufgrund der Erfahrung und der zukünftigen Anforderungen wird man ein neues Netz direkt so designen, dass man auf Überbuchung verzichtet und es insgesamt blockierungsfrei auslegt.

Wird ein neues Netz mit neuen RZ-Core- bzw. Campus-Switches so konstruiert, dass es frei von Überbuchungen ist und blockierungsfrei arbeitet, ist die DCB Congestion Control völlig überflüssig.

Das einzige Problem, was in einem solchen Netz noch auftauchen kann, ist ein technischer Defekt in Line Card oder Switch. Dagegen kann aber DCB Congestion Control ohnehin nichts machen, es ist in diesem Zusammenhang eine konstruktive Aufgabe, das Netz auf hinreichende Redundanz für solche Fälle auszulegen.

Das wäre die ideale Welt. In der realen Welt gibt es keine wirklich perfekten Netze, besonders dann, wenn man, wie sehr oft üblich ältere und neuere Komponenten mehr oder minder wild mischt.

DCB Priority Based Flow Control

Ein weiterer Mechanismus, um Staupunkte möglichst im Vorfeld zu vermeiden, ist die Priority-based Flow Control. Das ist im Grunde genommen eine Erweiterung von 802.1p mit der Möglichkeit der Differenzierung der Prioritätensteuerung auf die einzelnen Elemente eines zusammengesetzten Verkehrsstroms.

Bevor wir dies weiter analysieren, blicken wir einmal darauf, wie sich herkömmliche Priorisierung und PBFC im Switch konstruktiv unterscheiden. Pakete, die weitervermittelt werden sollen, kommen in den Eingangswarteschlangen an, werden von der Switchmatrix verarbeitet und an die Ausgangswarteschlangen weitergeleitet. In bestimmten Situationen kann es notwendig werden, Pakete in einem Puffer zwischen zu speichern.

Eine einfache, undifferenzierte Priorisierung wird technisch einfach so realisiert, dass Pakete hoher Priorität von einer Komponente, die wir „Priorisierer“ nennen und die entsprechend im Switch implementiert wird, einfach in den Eingangswarteschlangen nach vorne gesetzt werden und somit vor Paketen niedriger Priorität bearbeitet werden.

In einem konvergenten Netz kommen auf einer Leitung hoher Leistung unterschiedliche Datenströme auf einen Switchport zu. Diese Datenströme sind mittels ETS organisiert und haben definierte Anteile an der Gesamt-Übertragungsleistung einer Leitung. Möchte man diese Organisation im Switch nicht verlieren, sondern die definierten Qualitäten auch über mehrere Switches und Verbindungen hinweg schützen und aufrechterhalten, reicht die Bearbeitung mit einfacher Priorisierung nicht aus. Im konvergierten Fall benötigt man Eingangswarteschlangen für jeden definierten Verkehrsstrom. Das sind nicht unendlich viele, sondern höchstens 8, in der Praxis eher 3-4.

Diese Warteschlangen müssen dann durch einen Scheduler nach den Vorgaben durch ETS entleert werden.

Man sieht hier ganz deutlich, welche Aufgaben auf die Hersteller zukommen, wenn sie PBFC in ihren Switches implementieren wollen und dass dies auch nicht durch einen einfachen Software-oder Firmware-Upgrade zu leisten ist.

Um die mögliche Wirkung zu untersuchen, greifen wir weiter hinten in diesem Kapitel auf eine Warteschlangenanalyse zurück. Die Ergebnisse dieser Analyse sind:

PBFC ist ein wertvolles Instrument zur Beherrschung von Lastspitzen. Es sorgt dafür, dass ein System über einen größeren Lastbereich funktionsfähig und steuerbar bleibt. Die Einschränkungen, die im unteren Lastbereich durch PBFC entstehen, liegen unter 10% Zuschlag gegenüber einem ungesteuerten System und tragen demnach nicht messbar zu einer Erhöhung der durchschnittlichen Latenz bei.

Allerdings sehen wir auch, dass eine Last von über 80% zu einem unbeherrschbaren System führt. Es ist also beim generellen Netzdesign darauf zu achten, dass diese Last NIE auftreten kann.

DCB-ETS und DCBX

ETS (Enhanced Transmission Selection) ist eine Funktion zur Steuerung der relativen Anteile von differenzierten Verkehrsarten an einem Gesamtstrom. Solche Funktionen gibt es in Providernetzen und vor allem bei optischen Netzen schon längst und ETS war eigentlich für den LAN-Bereich erheblich überfällig. Das Protokoll hat eine sehr nützliche Gesamtfunktionalität, vor allem, wenn wir an die Ergebnisse des letzten Teils denken. Wir haben ja das Problem, dass das Gesamt-Verkehrsaufkommen 80% der Nominal-Leistung nicht übersteigen sollte. Die Berücksichtigung dieser Grenze im Rahmen eines Netzdesigns ist möglich und sinnvoll, aber nur bei ganz neuen Netzen möglich. Im Zusammenhang mit bestehenden Netzen, die nur teilweise aufgerüstet werden, ist sie ein frommer Wunsch, außer man hat ETS.

ETS definiert relative Anteile, also z.B. 40% für SAN-Verkehr, 40% für LAN-Verkehr und 20% für IPC. Man darf nicht unterschätzen, welche Wirkung man durch den geschickten Einsatz von derartigen Funktionen auch in verzweigten, großen L2-Bereichen erzielen kann, wenn die Funktionen an allen Switchen zur Verfügung stehen. Man kann das schön in den Abbildungen 5 und 6 sehen.

Möchte man ein konvergentes Netz betreiben, muss man sich überlegen, wie groß die relativen Anteile der Verkehrsströme an der Gesamtkapazität sein sollen. ETS bietet dann die Möglichkeit, das entsprechend einzustellen.

ETS ist eine extrem sinnvolle Funktion, deren Nutzen sich umso mehr entfaltet, desto geschickter man sie einsetzt!

DCBX geht jetzt schnell: in einem größeren Netz werden mit der Zeit Switches unterschiedlicher Hersteller, Bauarten und/oder Release-Ständen eingesetzt. Es ist unbedingt notwendig, dass sich diese Switches automatisch untereinander über den Grad der Unterstützung der Funktionen abstimmen können. Der Standard für DCBX hat für meine Begriffe genügend Reserven für die Aufnahme weiterer Funktionen, die es vielleicht in Zukunft gibt.

Einfache Priorisierung vs. PBFC

Der wesentliche Unterschied ist zunächst, dass eine einfache Priorisierung den Anforderungen der Steuerung eines definierten konvergierten Verkehrsstroms technisch schlicht nicht genügt. Überdies kann man die Nachteile einer einfachen Priorisierung an drei Punkten festmachen:

  • Es kann Betriebssituationen mit mehr als 100 % Last geben. Einfache Priorisierung fehlt jegliche Möglichkeit, in diesem Fall stabilisierend einzuwirken.
  • Wie ältere Analysen zeigen, benachteiligt die simple Priorisierung bei Hochlast die gering oder nicht priorisierten Datenströme erheblich
  • In der Praxis gibt es für einfache Netze einen protokollabhängigen Überlastschutz durch Sliding Window-Verfahren auf Layer 3. Kritisch sind aber die Protokolle, die das nicht haben (UDP).

DCB schafft hier erhebliche Vorteile:

  • Eine Überlast kann primär konstruktiv und in Ausnahmefällen durch eine gezielte Bremsung von Sendern vermieden werden. Die differenzierte Priorisierung ermöglicht einen geregelten Betrieb auch in einer Hochlastphase und gibt damit der Congestion Control die notwendige Zeit, Lastquellen entsprechend herunter zu regeln, wenn diese die notwendigen Voraussetzungen dafür erfüllen. Die Norm liefert nur die Basismechanismen. Alles Weitere ist abhängig von der Implementierung, hier gibt es ein weites Spektrum.
  • Durch ETS und Congestion Control können speziell die Auswirkungen der kritischen Protokolle eingegrenzt werden.
  • Durch ETS-Einstellungen kann eine unangemessene Benachteiligung niedrig priorisierter Verkehrsströme vermieden werden.

Insgesamt ermöglichen die DCB-Funktionen die Durchsetzung der vom Benutzer via ETS definierten Anforderungen an die Qualität der Behandlung eines Datenstroms in einem konvergierten Netz von Ende-zu-Ende in einer kontrollierten Form!

« Teil 28: FCoE und ANSI FC-BB-5Teil 30: DC-History (1): die geordneten 70er »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.