Mobile-Menu

Low Latency Networks im Überblick, Teil 5 Dr. Franz-Joachim Kauffels

Redakteur: Dipl.-Ing. (FH) Andreas Donner

Verschiedene Hersteller bezweifeln, dass Methoden wie Fat Trees und Virtual Chassis für die Strukturierung von Low Latency Networks ausreichen und bevorzugen daher einen konstruktiven Ansatz, der allgemein als „Scale-Out“ bezeichnet wird. Die Anwendung von Scale-Out auf Netzwerke ist eine Revolution.

Firmen zum Thema

Ein Vergleich von Ethernet, CEE und InfiniBand – die enge Feature-Verwandtschaft von IB und Converged Enhanced Ethernet ist offensichtlich
Ein Vergleich von Ethernet, CEE und InfiniBand – die enge Feature-Verwandtschaft von IB und Converged Enhanced Ethernet ist offensichtlich
( Archiv: Vogel Business Media )

Scale-Out steht für ein völliges Umdenken bei Netzen. Traditionelle Netze sind eher nach dem Grundgedanken des „Scale-Up“ aufgebaut, bei dem immer größer werdende monolithische Switches die wesentlichen Hauptaufgaben übernehmen. Das führt zu sehr schönen skalierbaren Netzen, allerdings auch zu fulminanten Kosten für diese Core-Switches und ihren Betrieb.

Bei Scale-Out werden kleinere, standard-basierte Switches mit einer speziellen Software geclustert. Das Konzept ist heute in RZs bei Speichersystemen und geclusterten Web-Servern bekannt und beliebt. Es gibt nun Hersteller, die diesen Ansatz bevorzugen. IDC sieht in Scale-Out einen wichtigen Weg für die Zukunft von Rechenzentren.

Scale-Up bedeutet, die Aufgaben immer größeren monolithischen Maschinen, wie z.B. schweren Core-Switches in Netzen, zu übertragen. Eigentlich wissen wir schon, dass das nicht der richtige Weg ist. Neben Skalierungsproblemen kommen Kostenexplosion und Management-Probleme auf uns zu.

Scale-Out bedeutet die horizontale Skalierung durch Clustering multipler kleinerer Maschinen.

In einem Scale-Out Design werden viele Elemente, die nach Industriestandards arbeiten, mit einer Clustering-Software zu einem größeren Gebilde zusammengebunden, die für eine vereinheitlichte Systemsicht sorgt. Da kleinere Komponenten nach Industriestandards viel schneller hergestellt werden können als große monolithische Switches, dauert es bei einem solchen Design längst nicht so lange, bis neue Industriestandards auch in Form von Produkten bei den Kunden ankommen.

Spannend ist aber auch, dass die Summe kleinerer Systeme immer erheblich preisgünstiger ist als ein großes System – egal bei welchem Hersteller.

Denken Sie jetzt einmal an ein Fat Tree Design, wie wir es im letzten Beitrag besprochen haben und die Kosten, die dadurch entstehen, dass es auf der Spine-Ebene große Core-Switches geben muss und man zu den Kosten der Ports an den Leaf-Switches, die die eigentliche Versorgung der Server vornehmen, noch die Kosten für die Ports der gesamten Infrastruktur hinzurechnen muss. Wie viele Ports man im Rahmen der Infrastruktur braucht, hängt vom Konzentrationsgrad auf den Leitungen ab. Da dieser individuell verschieden ist, können wir hier nicht weiter rechnen, aber mit dieser Anleitung können Sie das für Ihr Netz ja selbst.

Die Diskussion der Folgekosten durch Platzbedarf der Core-Switches, Stromversorgung und Kühlung unterlassen wir jetzt, aber da ist auch Potential drin.

Scale-Out ist In

Es gibt viele Beispiele für Scale-Out-Lösungen im RZ wie Cluster von Web-Servern, geclusterte Anwendungen und Datenbanken sowie geclusterte File- oder Blockspeicher. Sie alle zeigen, dass Scale-Out ein erfolgreiches konstruktives Konzept ist. Alle diese Beispiele verbessern Leistung und Kapazität mit weniger Ressourcen. Der Erfolg einer Cluster-Lösung hängt von ihrer Software-Architektur ab. Dabei stehen folgende Fragen im Vordergrund:

  • Wie nahe kommt das Verhalten des Clusters einem monolithischen System?
  • Wie steht es um die Linearität der Skalierbarkeit und deren Grenzen?
  • Wie verhält sich das geclusterte System bei Fehlern?

Es gibt sogar die These, dass die bisherigen Scale-Up-Lösungen bald an konstruktive Grenzen stoßen werden. Die Core-Switches müssen einerseits immer mehr Aufgaben übernehmen, andererseits wachsen Datenrate und Konzentrationsgrad laufend, das heißt, die Mehraufgaben müssen immer schneller erledigt werden. Irgendwann wird auch noch so parallelisiertes CMOS dabei an Grenzen stoßen. Also muss man auf einen anderen VLSI-Herstellungsprozess zurückgreifen, wie etwa GaAs. Dadurch werden die Core-Switches wahrscheinlich noch mal deutlich schneller, aber bestimmt auch noch mal wesentlich teurer, ganz abgesehen vom Energieverbrauch.

Dieser Scale-Up Ansatz ist eigentlich nur eine Krankheit von Ethernet. Bei anderen Netztypen wie InfiniBand und in gewissem Umfang Fibre Channel hat man schon früh erkannt, dass es so nicht geht und das Scale-Out Konzept angewendet. Eine typische InfiniBand-Umgebung besteht üblicherweise aus einer sehr leichtgewichtigen Switching-Struktur, die folgende Eigenschaften aufweist:

  • Fähigkeit der Arbeit in fast beliebigen Mesh-Topologien
  • Unterstützung paralleler, multipler Wege
  • Fabric- und I/O-Partitionierung
  • Zentrale Discovery
  • Policy Management

In den letzten Jahren hat IEEE aber an Verbesserungen von Ethernet gearbeitet, die dem Ethernet in Form des Converged Enhanced Ethernet InfiniBand-ähnliche Eigenschaften verleihen, wie wir das ja schon oft diskutiert haben. Das Teaserbild macht dies eigentlich ohne weitere Erläuterung klar. Der hervorgehobene Kasten zeigt die enge Verwandtschaft der Möglichkeiten von IB und CEE.

An Differenzen bleibt, dass IB immer schneller sein wird als Ethernet, während Ethernet jetzt bei 40/100 GbE steht, wird IB bald jenseits der 300 Gbps angekommen sein. Zudem unterstützt IB kein IP-Routing, weil es für die klassischen Anwendungsbereiche von IB viel zu langsam wäre und somit nicht benötigt wird. Dafür können Ethernet-Netze räumlich größer werden.

Für das, was wir hier diskutieren, spielt das aber alles keine Rolle. Vielmehr ist es hoch interessant, dass CEE jetzt von IB so viele Eigenschaften übernommen hat, dass eine Anwendung des Scale-Out Prinzips denkbar und erfolgversprechend ist.

weiter mit: Voltaire Scale-Out Data Center Fabric Architecture

Voltaire Scale-Out Data Center Fabric Architecture

Grundsätzlich funktioniert die Architektur mit IB oder CEE. Der Unterschied liegt nach Angaben des Herstellers Voltaire darin, dass CEE sehr gut ist, für allerhöchste Anforderungen aber nach wie vor IB benutzt werden muss. Wir betrachten jetzt hier nur den CEE-Teil.

Die CEE-Scale-Out Architektur ist gedacht für

  • Konsolidierung im RZ
  • Extensive Benutzung der Server-Virtualsierung
  • Hohe Packungsdichte in Racks voller leistungsfähiger CPUs
  • Service-Orientierung an Automation und Cloud Computing

Technisch basiert die Konstruktion auf Switches hoher Dichte mit vielen Wire-Speed 10-GbE-Ports ohne Überbuchung. Die Switch-Architektur beinhaltet verschiedene Funktionen für die Verkehrsverwaltung, die es letztlich ermöglichen, dass die systembedingte Latenz unter 1 µs bleibt. Je nach gewählter Verkehrsklasse wird lossless Arbeitsweise gewährleistet. Mit dem Vantage 8500 haben wir ja schon einen entsprechenden Switch kennen gelernt, es gibt auch kleinere von diesem Hersteller. In ihren Herzen sind das allesamt InfiniBand-Switches, die nach außen hin nur so tun, als seien sie Ethernet-Switches aber, weil sie eine so schön geringe Latenz haben und außerdem wirklich verlustfrei arbeiten können, soll uns das an dieser Stelle egal sein.

Ein weiterer Vorzug dieser Switches ist es, dass man sie praktisch beliebig zu großen Topologien vermaschen kann, ohne dass sie ihre Grundqualitäten verlieren.

Durch die Architektur und die passende Software sieht die Menge der mit Scale-Out strukturierten Switches von außen wie ein großer monolithischer Ethernet-Switch aus. Das erleichtert die Integration in gemischte Umgebungen, wo man z.B. einen Teil des Netzes so lassen möchte, wie es bisher war, und alle neuen Teile mit Scale-Out aufbaut.

Es gibt ja auch im Ethernet-Bereich eine Reihe von Verbesserungen wie TRILL oder PLSB, die eine mehr oder minder beliebige Vermaschung von Switches erlauben, wobei keine Voraussetzungen hinsichtlich deren Größe gemacht werden. Aber zum einen sind sie noch weit davon entfernt, wirklich vollständig zu sein und zum anderen benötigt man ohnehin neue Switches, weil die alten mit den Erweiterungen des Paketformats, was durch diese Verfahren zwingend bedingt wird, nicht klarkommen.

Software als Kern der Gesamtlösung

Neben den Switches ist eine Software der Kern der Gesamtlösung: der Unified Fabric Manager (UFM) von Voltaire. Zunächst stellt er alle realen und virtuellen Switches im Netzwerk fest. Neben Geräten von Voltaire können das auch zertifizierte Systeme von Fremdherstellern sein. Aus diesen Informationen fügt er dann entlang der Anforderungen der Anwendungen das Netz dynamisch zusammen.

Alle Komponenten des Netzes und alle Verbindungen werden permanent überwacht, nicht nur auf Fehler und Funktionalität, sondern auch hinsichtlich der Einhaltung der Anforderungen aus den Anwendungen.

UFM akzeptiert Anforderungen oder Definitionen virtueller Einheiten und justiert die Policies für diese Anforderungen über alle Switches Ende-zu-Ende dynamisch. Dadurch braucht man als Betreiber eigentlich nicht mehr zu verstehen, wie die physikalischen oder virtuellen Beziehungen aussehen oder wie die Switches untereinander verbunden sind. Insbesondere muss man nichts mehr von Hand konfigurieren.

Das mag zunächst befremdlich erscheinen, aber mit zunehmender Konzentration und Virtualisierung und den schnellen Änderungen in dynamischen Umgebungen, wie sie z.B. durch Web-2.0-Architekturen ausgelöst werden, kann kein Mensch und auch kein Team mehr alle diese Verbindungen kennen, Überwachen oder gar von Hand einstellen. Das muss man wohl oder übel schon einem Automaten überlassen.

Beispiele für verwaltete Endpunkte sind NICs, HBAs oder HCAs realer oder virtueller Maschinen, Storage Elemente (Targets, LUN, Volume oder File Server) sowie Router-/Gateway-Ports oder Uplink-Ports. Multiple Endpunkte können auch gruppiert werden, z.B. wenn eine Menge von Endpunkten in einem virtuellen Netz in der gleichen L2-Domäne verbleiben soll oder wenn ein Anwendungscluster eine Menge von Netzwerk-Schnittstellen enthält.

In einem konvergierten Netz ist es notwendig, Qualitätsklassen für spezifische I/O-Endpunkte festzulegen und an diese spezielle Eigenschaften zu binden. Beispiele wären:

  • Netzwerk-Adapter (NIC, vNIC) mit normalen Ethernet Eigenschaften
  • Storage-Adapter (HBA, vHBA) mit lossless-Anforderung über die Fabric
  • Messaging/HPC-Adapter (HCA, vHCA) mit lossless-Anforderung und geringer Latenz

UFM erlaubt es den Betreibern, Anwendungen, Anwendungs-I/O und Netzwerkanforderungen sowie Flow Requirements (Verbindungen zwischen Anwendungs-Arbeitseinheiten) zu definieren. Der intelligente Betriebsmittel-Verwalter in UFM produziert automatisch die Traffic-Policies, die notwendig sind, um die Anwendungen im gewünschten Maße zu unterstützen. Er optimiert die Benutzung der Betriebsmittel und die Leistung. Vom Hersteller war allerdings nicht zu erfahren, was UFM macht, wenn der Betreiber nicht genügend Switches und Leitungen spendiert hat, um den Anforderungen zu genügen.

UFM überwacht natürlich während des Betriebs laufend, was passiert, berichtet über Engpässe und erstellt Statistiken.

Interessant ist auch noch, dass Voltaire für Messaging Traffic eine Vielzahl von Fabric Protokollen und Protokollerweiterungen bereitstellt, die mit einer Anwendung verbunden werden können und auf Basis eines schnellen IPCs die Kommunikation erheblich beschleunigen. Beispiele sind Beschleuniger für Multicast und Messaging-Queues, Oracle RDS und Speicherzugriff. In einem späteren Kapitel werden wir noch darauf zurückkommen, das ist beeindruckend.

Letztlich prägt Voltaire den Begriff „Fabric as a Service“ (FaaS), der darauf abzielt, das Netzwerk konsequent als Diensterbringer für die Kommunikation virtueller Maschinen zu definieren. Das umfasst auch viele Management-Aspekte, auf die wir nicht hier, sondern in einem gesonderten Kapitel vergleichend eingehen.

weiter mit: Ein Zwischenfazit

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.