Das Netzwerk wird zum Systembus: hin zur Matrix der kürzesten Wege!

Kommentieren Drucken

Stark vereinfacht formuliert entstehen im Rechenzentrum Anforderungen aus einer Kombination aus Latenz und Bandbreite. Dabei ist wichtig, zu verstehen, dass mehr Bandbreite nicht auch mehr Latenz produziert. Dies ist ein im Markt weit verbreitetes Missverständnis (so im Sinne von „100 GbE ist schneller als 1GbE“, was aber natürlich Unsinn ist). Wir haben auf dem Forum einfache Beispielrechnungen mit 1GbE, 10 GbE und 100 GbE-Netzwerken vorgelegt, die sofort klar gemacht haben, dass die Leistung der einzelnen Switch-Systeme selber und die Art ihrer Verschaltung eine entscheidende Rolle für Latenz spielen. Die aus dieser Analyse resultierenden Anforderungen sind relativ einfach zu formulieren:

  • Die Switchlatenz pro Switch muss möglichst niedrig sein, hier gibt es bei den Highend-Systemen erste Produkte, die mit 5 Mikrosekunden switchen.
  • Die Anzahl der in der Kommunikation zu durchlaufenden Switch-Systeme muss minimal sein. Es muss eine Matrix der kürzesten Wege geben. Tatsächlich ist der Begriff „Matrix der kürzesten Wege“ der Schlüssel zum Verständnis des Netzwerk-Designs im Rechenzentrum der Zukunft.

Steigt man hier tiefer ein (das sprengt den Rahmen dieses Geleits), dann wird klar, dass hier neue Switching-Verfahren gefordert sind, um diese Matrix der kürzesten Wege umzusetzen. Dies wird auch zwangsläufig mit Redundanz kombiniert werden, wobei die Redundanz-Performance selber nicht im Vordergrund steht sondern die Optimierung der System-Latenz.

Wir haben auf dem Forum die beiden in der Entwicklung befindlichen Standards für Shortest Path Bridging der IETF und der IEEE diskutiert und diese auch gegenüber gestellt. Die IETF hat momentan mit dem TRILL-Verfahren die Nase deutlich vorne. Bei der IEEE haben wir die Situation, dass die sehr langsame Arbeit an dem Standard gut dazu führen kann, dass dieser Standard zu spät kommt. Auf dem Netzwerk-Redesign Forum 2010 haben sich dann auch alle anwesenden Hersteller klar zu TRILL bekannt. Cisco betreibt eine proprietäre Form von Shortest Path Bridging bereits jetzt, hat sich auf dem Forum aber auch klar zu TRILL bekannt (was nicht wirklich überraschend ist) und den Upgrade seiner jetzigen Lösung auf TRILL angekündigt (TRILL wurde im April 2010 weitestgehend verabschiedet).

Shortest Path Bridging und das Streben nach der Matrix der kürzesten Wege führen zu neuen Netzwerk-Designs, zu einer neuen Form der Verschaltung von Switch-Systemen. Frau Borowka und Herr Pflüger (Cisco) haben auf dem Forum sehr interessante Denkanstöße in diese Richtung gegeben.

Die sinnlose Auseinandersetzung zwischen der IETF und IEEE ist für den End-anwender ärgerlich, im Endeffekt wird sie auch von Hersteller-Interessen produziert. Wie auch immer, mit dieser Entwicklung ist die Zeit von Spanning Tree endgültig vorbei. Das neue Verfahren ist deutlich besser, deutlich flexibler und skaliert bis in mittelgroße Layer-2-Netzwerke gut. Im Kern arbeitet es wie die MESH-Netzwerke aus den Wireless LANs mit IS-IS.

Da TRILL mit einer Header-Erweiterung arbeitet, entsteht die Frage der Hardware-Kompatibilität mit vorhandenen Komponenten. Diese Frage konnte auf dem Forum nicht geklärt werden, wir arbeiten aber für die Sommerschule an der Klärung dieser sehr wichtigen Frage. Es kann auch gut sein, dass vorhandene Hardware aufgerüstet werden kann, dabei aber etwas an Leistung verliert (weil in der Verarbeitung ein weiterer Zugriff auf den Header erforderlich wird, vergleichbar mit dem Problem der IPv6-Performance).

Die Frage der Hardware-Kompatibilität ist eine der Kernfragen für alle Anwender. Neben TRILL stellt auch DCB erhebliche Anforderungen an die Hardware, speziell um Priority Based Flow Control durch eine Switching Fabric zu signalisieren. Hier wurde auf dem Forum deutlich, dass viele der im Markt vorhandenen Produkte nicht auf DCB aufgerüstet werden können.

zugeordnete Kategorien: Klassiker
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.

*

.