Mobile-Menu

Low Latency Networks im Überblick, Teil 5

Dr. Franz-Joachim Kauffels

Seite: 3/3

Firmen zum Thema

Ein Zwischenfazit

Weitere Themen auf dem Weg zu einer latenzarmen Netz-Infrastruktur sind die Eliminierung von Congestion und die Reduktion der Latenz von Transportprotokollen.

Die Eliminierung von Congestion ist zweigeteilt zu betrachten. Zum einen spielt die generelle Netzauslegung hier eine gewichtige Rolle. Kurz gesagt: Geiz wird mit Congestions bestraft. Es gibt hier wenig allgemein gültige Empfehlungen. Einerseits muss man natürlich immer ein Auge darauf haben, was die Anwendungen tatsächlich machen, andererseits ist das natürlich immer nur eine Momentaufnahme.

In einem Netz kann und wird es immer Congestions geben. Die Frage ist, wie die Komponenten damit umgehen. Aus allem, was wir wissen, kann man sagen, dass eine Congestion Control und ein Congestion Management, wie es bei IEEE 802.1 DCB festgelegt wird, nach aktuellem Stand der Technik einfach zu langsam ist. Die Vermeidung von Congestions im Vorfeld durch systematische Anwendung der Möglichkeiten einer prioritätsbasierten Flusskontrolle ist hier wesentlich wirkungsvoller. Schließlich spielt es noch eine gewichtige Rolle, wie die einzelnen Komponenten mit Congestions umgehen.

Letztlich erscheint nur folgender Mechanismus wirklich wirkungsvoll: Verteilte Anwendungen auf VMs definieren Qualitätsmerkmale für ihre Kommunikationsanforderungen, die dann Ende-zu-Ende vermöge einer automatischen, intelligenten, flexiblen und schnellen Netzsteuerung durchgesetzt werden, wie wir das bei der Scale-Out Software von Voltaire gesehen haben.

Wir haben ja bereits gesehen, dass zu wenig Speicher in einem Switch wenig hilfreich ist. Das ist aber wieder so ein Geiz-Problem, weil der benötigte schnelle Speicher relativ teuer ist.

Hersteller können hier aber offensichtlich lernen. In einem Vergleichstest von Tolly aus dem September 2010 war z.B. der G8124-Switch von IBM, der ja in einem früheren Artikel vorgestellt wurde, dem Cisco 5010 deutlich überlegen, auch hinsichtlich des Verhaltens bei Congestions. Hier hat der Hersteller BNT wohl einen Weg gefunden, die Switch-Architektur, die bei diesem Switch auf ASICs auf der Grundlage von Speichern beruht, durch zusätzlichen Speicher so anzureichern, dass die Fähigkeit, auch bei Congestions einen hohen Goodput zu liefern, erreicht wird, ohne auf die extrem geringe Latenz verzichten zu müssen. Natürlich bleibt der G8124 ein Switch mit fester Portzahl ohne weitere Skalierbarkeit.

Auch Arista hat sich Gedanken gemacht, diese führten zum Switch-Modell 7500. Das ist ein mittelgroßer modularer Switch mit konservativen Schnittstellen aber extrem geringer Latenz. In Verbindung mit den ToR-Switches im Rahmen einer Fat-Tree-Architektur ergibt sich auch hier ein wesentlich verbessertes Leistungsbild bei Congestions. Nach wie vor behauptet Arista übrigens, dass es überhaupt keine Microbursts gibt.

Wie auch immer, es ist eine extreme Bewegung im Markt und in den nächsten Monaten werden wir noch viele Neuheiten sehen. Das Congestion Problem wurde jetzt so hochgespült, dass sich kein Hersteller mehr erlauben wird, einen neuen Switch herauszubringen, der damit nicht umgehen kann. Von daher erledigt es sich sozusagen zum Teil von selbst.

Wesentlich gravierender für zukünftige Entscheidungen sind das grundsätzliche Strukturmodell und der Betrieb der so entstehenden Netze.

Der breite Markt bewegt sich eindeutig in Richtung Fat Tree. Sogar innovative Hersteller wie Arista, die das zu Beginn lange nicht wollten, bauen jetzt exakt eine solche Struktur auf. Netze mit tiefer Staffelung sind also strukturell mausetot. Sie kommen auch nicht wieder.

Allerdings ist die Frage, ob eine Fat-Tree-Struktur mit ebenso fetten Core-Switches wirklich die Zukunft ist.

In der Natur haben sich Systeme, die auf dem Gedanken der kooperativen Autonomie beruhen, immer gegen zentralistische Systeme durchsetzen können. Bei Servern und Speichern ist das „Scale-Out“ ein wichtiges modernes und sehr erfolgreiches Konstruktionsprinzip. Warum also nicht auch bei Netzen?

Gegen fette Core-Switches, ob nun im Fat Tree oder in Form von Virtual Chassis spricht einfach der Preis. Solche Core-Switches werden immer in so geringer Stückzahl hergestellt, dass sie nicht von den Gesetzmäßigkeiten des Massenmarktes profitieren können und somit eigentlich immer viel zu teuer für das sind, was sie tun.

Eine Scale-Out-Struktur auf der Grundlage standardisierter kleinerer Switches in großer Stückzahl hat hier von Beginn an bessere Karten.

Wichtig dafür ist es allerdings, dass die notwendige Software hier die entsprechenden Funktionen ausweist, im Grunde so, wie es Voltaire vormacht.

Scale-Out wird aber nicht nur von diesem Hersteller unterstützt. Für andere Scale-Out-Bereiche wie Speicher gibt es durchaus unabhängige Systemhäuser, die eine Scale-Out-Software schreiben, die dann eben für eine gewisse Gruppe zertifizierter Systeme gilt.