Suchen

Die (R)Evolution der Rechenzentren; Teil 28 DCB-Funktionen auf RZ-Core- und Campus-Switches – Analyse-Fazit

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

Den Lesern, die bis hier „dabeigeblieben“ sind, möchte ich für ihre Geduld danken. Wenn man aber fundamentale Fakten herausarbeiten möchte, die über das allgemeine Werbegeblubber der Hersteller hinausgehen, wird es immer etwas aufwändiger. Die Belohnung ist, dass wir die Thesen verifizieren können und daraus unmittelbare Konsequenzen für die Anforderungen an Switches für das RZ-Umfeld ableiten können.

Firmen zum Thema

DCB-Funktionen sind nicht nur in RZ-Switches wie dem EX4500 von Juniper sondern auch für Campus-Geräte wichtig.
DCB-Funktionen sind nicht nur in RZ-Switches wie dem EX4500 von Juniper sondern auch für Campus-Geräte wichtig.
( Archiv: Vogel Business Media )

Beginnen wir direkt mit der ersten These: „Die Implementierung von DCB-Funktionen ist ein wesentliches Kriterium bei der Auswahl zukünftiger RZ-Core Switches.“

Betrachtet man die DCB-Funktionen zusammen, ist einzig die Congestion Control in einem normalen Lastbereich 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.

Bildergalerie

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 bei Netzen, die nicht vollständig designoptimiert sind, einen dauerhaft stabilen Netzbetrieb sicherzustellen.

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.

Die erste These ist damit verifiziert. Kommen wir zur nächsten.

Die zweite These

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

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 aus dem Provider-Bereich liegt. 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 an die Hand, die für eine stabile und dauerhafte Sicherung eines weitgehend störungsfreien Betriebs nötig sind.

Die zweite These ist korrekt und visionär! Bleibt also nur noch die Latenz.

weiter mit: Das Problem der Latenz

Das Problem der Latenz

Die These: „Für das Problem der Latenz in RZ-Netzen ist der Wechsel der Datenrate von 10 GbE auf 100 GbE von untergeordneter Bedeutung. Bezogen auf eine produktbedingte Latenz von Switchmodellen ist die Wirkung der Erhöhung der Datenrate gering. Ausschlaggebend für die Gesamt-Latenz ist vielmehr die produktbedingte Switch-Latenz.“

Auf dem ComConsult-Forum wurde diese These von Dr. Suppan anhand von Tabellen dargelegt, die die Einflüsse von Switchlatenz und Datenrate auf die Latenz eines Netzes darstellen. Da die Tabellen unterschiedliche Werte für minimale und maximale Paketlängen angeben, ist anzunehmen, dass sie auf einem statischen Berechnungsmodell basieren; siehe Abbildung 1 und 2.

Während der Schritt von 1 GbE auf 10 GbE sehr viel für die Latenz bringt, wirkt sich der Schritt von 10 GbE auf 100 GbE hier eher marginal aus. Allgemein kann man also nicht sagen, dass mehr Bandbreite automatisch entsprechend weniger Latenz bringt.

Durch die Kleinrock’sche Unabhängigkeitsannahme können die Ergebnisse der Analysen im Hauptteil dieses Artikels durch einfache Summierung auf zusammengesetzte Netze übertragen werden. Dabei zeigt sich eine starke Übereinstimmung mit den Werten in der Tabelle. Außerdem konnte, anders als auf den Tafeln, zusätzlich nachgewiesen werden, dass die Switches mit einer Latenz von nur 5 µs bereits nahe der theoretischen Grenze arbeiten. Dadurch ergibt sich folgende Konsequenz:

Die dritte These ist korrekt und unabhängig vom Berechnungsmodell! Grade diese Unabhängigkeit verstärkt die These erheblich in ihrem Gewicht.

Konsequenzen für die Auswahl von Core-Switches

Ein Core-Switch der nächsten Generation, der nach seiner Anschaffung fünf bis sieben Jahre in Betrieb bleiben soll, muss folgende Eigenschaften haben:

  • 100G-ready (das war immer unstrittig)
  • Unterstützung von DCB
  • Geringe Latenz nahe der theoretischen Grenze
  • Unterstützung von TRILL (unstrittig)

Erfüllt er nur eine der geforderten Eigenschaften nicht, kann nicht sichergestellt werden, dass der Switch 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.

Abschließend sei noch erwähnt, dass ich diese Analyse hauptsächlich deshalb durchgeführt habe, um die Notwendigkeit von DCB zu widerlegen. Die sorgfältig durchgeführte Analyse hat mich aber dann vom genauen Gegenteil überzeugt. Warteschlangen lügen nicht!