Suchen

Netzwerk-Grundlagen – Rechenzentrumsnetze im Umbruch, Teil 9 Data Center Bridges (DCB) – Funktionalität nahe am Lossless Ethernet

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

Das Projekt DCB wird im Markt oft nur im Zusammenhang mit FCoE und „Lossless Ethernet“ gesehen. Das ist schade, denn DCB ist viel mehr. Es bietet elegante Möglichkeiten, den in einem RZ-Netz nunmehr konvergierten Datenstrom zu steuern und dadurch Netze einer ganz anderen Qualität als heute zu bauen. Dieser Artikel fasst die Ergebnisse zusammen, die vom Autor und ComConsult Research im Rahmen aufwändiger Untersuchungen erzielt wurden.

Firmen zum Thema

Die Funktionen von DCB erlauben ein punktgenaues Netzwerkmanagement; Bild: Dr. Franz-Joachim Kauffels
Die Funktionen von DCB erlauben ein punktgenaues Netzwerkmanagement; Bild: Dr. Franz-Joachim Kauffels
( Archiv: Vogel Business Media )

Die DCB-Funktionen umfassen Staubenachrichtigung und rückwärts gerichtete Staubehebung, Prioritäts-basierte Flusskontrolle und erweiterte Verkehrssteuerung sowie Systeme zum Informationsaustausch der beteiligten Switches hinsichtlich der von ihnen unterstützten Funktionen.

DCB bedeutet „Data Center Bridges“. 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.

Bildergalerie

Wir untersuchen die Funktionen der Reihe nach.

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 konstruierte Netze
  • Zu kleine Speicher in den Switches
  • Defekte 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 betroffenen 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 zuviel 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 es unterstützen. Das sind zurzeit aber 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 auch 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.

Durch das neue IS-IS-basierte und von der IETF standardisierte Strukturierungsverfahren TRILL stehen hier ganz andere Möglichkeiten für das Design von Netzen zur Verfügung, weil redundante Ersatzwege nicht mehr wie bei Spanning Tree einfach ausgeschaltet, sondern aktiv mitbenutzt werden. Dies kann man deshalb jetzt endlich mit den seit Jahrzehnten existierenden Erkenntnissen aus der Theorie der Mehrstufenmehrfachverbindungsnetzwerke, wie z.B. dem Clos Netz, kombinieren und kommt damit zu völlig neuartigen, optimierten und vor allem völlig blockierungsfreien Netz-Designs. Dies ist hier aber nicht das Thema.

Wir können festhalten

Wird ein neues Netz mit neuen Core-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.

weiter mit: DCB Priority Based Flow Control

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.

Um die Unterschiede zwischen 802.1p und DCB PBFC herauszuarbeiten, wurde eine detaillierte Warteschlangenanalyse vorgenommen. Die Ergebnisse lauten kurz gefasst:

  • In einem Lastbereich zwischen 0 und 60 – 65% der Nominal-Last funktioniert der Switch wunderbar. Eine Priorisierung ist eigentlich überflüssig.
  • In einem Lastbereich zwischen 65 und 80% Nominal-Last erhalten wir durch die differenzierte Priorisierung die Möglichkeit, Verkehrsströme soweit wie möglich durchzuschleusen, allerdings höchstens zwei. Dies geschieht um den Preis der starken Herabsetzung der Leistung der anderen Verkehrsströme. Dennoch erhalten wir in diesem Bereich dadurch die Möglichkeit, das System wenigstens zum Teil lebensfähig zu erhalten. Das ist der akzeptable Bereich.
  • In einem Lastbereich jenseits der 80% Nominal-Last erhalten wir ein völlig inakzeptables Systemverhalten – mit oder ohne prioritätsbasierte Flusskontrolle.

Insgesamt bedeutet dies, dass PBFC ein wertvolles Instrument zur Beherrschung von Lastspitzen ist. 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 oder durch Konfiguration darauf zu achten, dass diese Last nie auftreten kann.

DCB-ETS und DCBX

ETS 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 gerade eben erwähnten Erkenntnisse 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 kann es aber einfach austricksen, indem man schlicht 20% für einen Verkehr reserviert, den es gar nicht gibt! Das System setzt dann durch, dass diese 20% für diesen nicht existierenden Verkehr immer frei bleiben. So kann sich der andere Verkehr immer nur zu einem Verkehr von höchstens 80% zusammenrotten. Eleganter geht es nicht.

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. Kurz:

ETS ist eine extrem sinnvolle Funktion, deren Nutzen sich umso mehr entfaltet, je 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.

weiter mit: Eine Bewertung

Eine Bewertung

Die Implementierung von DCB-Funktionen ist ein wesentliches Kriterium bei der Auswahl zukünftiger Core Switches.

Betrachtet man die DCB-Funktionen zusammen, erscheint einzig die Congestion Control etwas sinnlos. Die anderen Funktionen haben jedoch mehr Potential, als man ihnen auf den ersten Blick zutraut. Es konnte durch die Warteschlangentheorie eindeutig nachgewiesen werden, dass die prioritätsbasierte Flusskontrolle ein sehr wirkungsvolles Instrument für den Betrieb eines Netzes im höheren Lastbereich ist.

Da wir wegen der grundsätzlich geänderten Ausgangslage hinsichtlich der Netzlast durch die Virtualisierung und die Web-Architekturen Lastspitzen nicht mehr so einfach wie früher abschätzen können, ist dieses Instrument besonders wertvoll. Im Zusammenhang mit ETS gelingt es sogar, auch bei Netzen, die nicht vollständig designoptimiert sind, einen dauerhaft stabilen Netzbetrieb sicherzustellen. Die Congestion Control ist zwar irgendwie überflüssig, schadet aber auch nicht und ist eben Bestandteil des „DCB-Pakets“.

Natürlich lassen sich Situationen, die dadurch entstehen, dass ein Netz in einem höheren Lastbereich läuft, auch immer dadurch bereinigen, dass man Überkapazität spendiert. Die Erfahrung lehrt aber, dass die meisten Corporate-Betreiber ein Netz immer recht sparsam auslegen, einfach auch deswegen, weil die Kosten für Schnittstellen mit der Zeit immer weiter sinken. Dadurch kommt es immer wieder zu Situationen, in denen ein Netz für eine gewisse Zeit höher belastet wird, als das eigentlich vertretbar ist, bis es denn endlich hochgerüstet wird. Grade für diese Zeiten sind die DCB-Funktionen wertvoll und unabdingbar.

Man kann aber noch weiter gehen und sagen, dass die Implementierung von DCB-Funktionen ein wesentliches Kriterium bei der Auswahl zukünftiger Campus-Switches ist.

Diese These erscheint auf den ersten Blick relativ absurd. DCB heißt „Data Center Bridges“ und wurde auch genau für diesen Hintergrund entwickelt, sozusagen als Stütze für FCoE. FCoE selbst ist, wie ich schon mehrfach dargestellt habe, aufgrund inhärenter Plesiochronität nicht für einen Betrieb auf längeren Strecken geeignet. Das wissen auch Schöpfer und Hersteller von FCoE. Auf längeren Strecken können die anderen im FC-BB-5-Standard definierten Verfahren wie FCIP, Generic Packet oder Pseudowire zum Einsatz kommen. Was soll also DCB im Campus?

Nun, die grundsätzlichen positiven Eigenschaften von DCB bleiben auch im Campus erhalten, es gibt keine Funktion in DCB, die wie FCoE einer Beschränkung hinsichtlich des Wirkradius unterworfen wäre.

Wir können überhaupt noch nicht abschätzen, welche Anwendungen, Verkehrsströme und Lasten im Campus in Zukunft auf uns zukommen. Hier spielen Einflussfaktoren von der Einführung der Desktop-Virtualisierung über die Schaffung großer L2-Bereiche bis hin zur Notwendigkeit einer dichteren WLAN-Flächendeckung für neue Endgerätetypen eine unangenehme Rolle. Der Autor ist der festen Überzeugung, dass die Zukunft eines Campus-Netzes in der Einführung von Funktionen liegt, die es im Provider-Bereich gibt. Dazu muss es allerdings auch von der Basistechnologie her erheblich aufgerüstet werden.

Bis es soweit ist (bei Campus Netzen mit geringeren bis mittleren Anforderungen vielleicht nie) bekommen wir mit den DCB-Funktionen genau die Instrumente in die Hand, die für eine stabile und dauerhafte Sicherung eines weitgehend störungsfreien Betriebs nötig sind.

Konsequenzen für die Auswahl von Core-Switches

Ein Core-Switch der nächsten Generation, der nach seiner Anschaffung 5-7 Jahre in Betrieb bleiben soll, muss folgende Eigenschaften mitbringen:

  • 100G ready
  • Unterstützung von DCB
  • Geringe Latenz nahe der theoretischen Grenze
  • Unterstützung von TRILL

Erfüllt er nur eine der geforderten Eigenschaften nicht, kann nicht sichergestellt werden, dass er zukunftsfest ist. Natürlich kann man darüber hinaus noch weitere Anforderungen stellen, aber diese sind entweder ohnehin Standard (z.B. VLAN-Unterstützung) oder individuelle Geschmackssache (z.B. Unterstützung von Virtual Chassis)

Bis auf die Unterstützung von 100 G ist das Ergebnis auch auf Campus-Switches übertragbar.

Weiter mit Teil 10

Zurück zu Teil 8