Low Latency Networks im Überblick, Teil 3

Latenzarme Switches und Adapterkarten

17.12.2010 | Autor / Redakteur: Dr. Franz-Joachim Kauffels / Andreas Donner

Der Blade Network Technologies (IBM) Rack-Switch G8124-E gehört zu den latenzarmen High-Performance Switches
Der Blade Network Technologies (IBM) Rack-Switch G8124-E gehört zu den latenzarmen High-Performance Switches

Den Grundaufbau latenzarmer Switches haben wir ja bereits kennengelernt. Vollständige Produkte können noch mehr als die Summe der einzelnen Switch-Chips. Wegen der grundsätzlich unterschiedlichen Möglichkeiten betrachten wir Switchmodelle mit Switch-Chips auf Basis von Speichern und solche mit Switch-Chips auf Basis von angereicherten Cross-Bars getrennt.

Ein typischer Vertreter der Klasse „Switches mit Switch-ASICs auf Basis von Speichern“ ist der G8124-E von Blade Network Technologies, sprich IBM. Der G8124-E ist ein 24-Port 10 GbE Ethernet Rack-Switch mit SFP+ Schnittstellen. Das Spektrum der optischen Übertragungstechnik von SR bis LR kann man mittels Plugin-Transceivern nutzen.

Die Gesamtleistung beträgt 480 Gbps Full Duplex Non Blocking.

Die Latenz dieses Switches liegt bei 700 ns. Hier nur ein kleiner Auszug aus der Liste der unterstützten Funktionen:

  • Volles DCB mit PBFC, ETS, DCBX und FCoE sowie CEE
  • Trunking LAPC, EtherChannel, weitere ladbar
  • Struktur: MSTP, RSTP, PVRSTP+, weitere ladbar
  • L3: RIP, OSPF, BGP, Multicast IGMP, PIM
  • Hochverfügbarkeit: VRRP, Uplink Failure Detection und weitere
  • Sicherheit: RADIUS, TACACS, SCP, SSH, HTTPS und weitere

Dieser Switch demonstriert sehr eindrucksvoll, dass geringe Latenz keineswegs den Verzicht auf komplexere Funktionalität bedeuten muss.

Ich hatte bei FCoE immer Bedenken, dass eine Implementierung der notwendigen Funktionen zwangsläufig zu einer erheblichen Erhöhung der Latenz führen muss. Ich lasse mich aber gerne vom Gegenteil belehren. Da, wie bereits dargestellt, latenzarme Switches ohnehin in enger Symbiose mit den DCB-Funktionen leben, ist die Implementierung der weiteren Elemente von FC-BB_E offensichtlich unproblematisch. Ganz besonders interessant sind auch Zusatzfunktionen, die der besseren Kommunikation mit Virtualisierungssoftware dienen. Dazu kommen wir aber auch in einem späteren Abschnitt. Das Erscheinungsbild des Switches ist nicht besonders überraschend. Er benötigt nur eine einzige Höheneinheit.

Der Stromverbrauch liegt ja nach Schnittstellenbestückung zwischen 116 und 170 W, nach Tolly ist das etwa die Hälfte des Cisco Calatyst 4900M oder anderer Switches vergleichbarer Bauart mit wesentlich höherer Latenz. Die Kosten liegen unter 500 US-Dollar pro Port.

Es ist übrigens nicht so, dass es keine Auswahl gäbe: der EX 2500 von Juniper Networks hat einen praktisch identischen Leistungsumfang bei 700 ns Latenz, der Hersteller schweigt sich aber hinsichtlich DCB und FCoE aus. Dafür gibt es eine nahtlose Integration in die gesamte Produktfamilie dieses Herstellers.

Weitere ultra-latenzarme Switches kommen von Arista. Ein typisches gemeinsames Merkmal all dieser Switches ist die feste Portzahl.

Switches mit Switch-ASICs auf Basis angereicherter Cross-Bars

Nexus 5000 von Cisco Systems umfasst eine Familie von Switches unterschiedlicher Größe. Alle Elemente der Familie bieten eine sehr weit reichende Unterstützung aller Ethernet Standard-Protokolle sowie DCB und FCoE. Die Latenz liegt bei 3,2 µs. Für HPC-Anwendungen, die noch schneller sein müssen, empfiehlt Cisco den Einsatz von IB.

Bis jetzt haben wir Switches mit fester Portzahl betrachtet, weil sich das natürlich aus den Switch-ASICs auf der Basis von Speichern unmittelbar ergibt.

Natürlich gibt es mittlerweile auch Core-Switches mit extrem geringer Latenz, wie das Modell Vantage 8500 von Voltaire. Dieser Switch wurde in einem anderen Artikel, indem es primär um die Wirkung des Kaufes von Voltaire durch Mellanox ging, bereits vorgestellt.

Vergleich der Konzepte

Um einen fairen Vergleich der beiden Konzepte durchführen zu können, müssen wir kurz in das Problem der Microbursts einsteigen.

Microbursts sind Verkehrsmuster, die in einem Netz kurzfristige Congestions hervorrufen. Das passiert in Phasen hoher Aktivität, während derer Endpunkte relativ plötzlich viele Pakete ins Netz schicken. Bei einem Netzwerk für Finanztransaktionen kann das z.B. eine Zeitspanne betreffen, in der der Markt sehr volatil ist, z.B. beim Eintritt eines besonderen Ereignisses oder als Reaktion auf relativ unerwartete Geschäftszahlen. Grade dann ist es aber natürlich besonders wichtig, dass das Netz gut funktioniert.

Dummerweise werden Microbursts von herkömmlichen Tools, die den Verkehr beobachten, oftmals gar nicht wahrgenommen und spielen daher wenn überhaupt nur eine untergeordnete Rolle bei der Netzplanung.

In der Abbildung 2 sehen wir, wie das passieren kann. Ein herkömmliches Tool schaut sich den Verkehr nur etwa einmal pro Sekunde an. Es würde einen Alarm auslösen, wenn der Schwellwert für eine Congestion überschritten würde. Die Eigenheit von Microbursts ist es aber, viel schneller zu entstehen und dann auch wieder zu verschwinden. Im unteren Teil der Abbildung sehen wir, dass es ganz offensichtlich viele Microbursts gab, diese aber nur dann auffallen, wenn man das Betrachtungsintervall deutlich verkürzt. Bei einer Betrachtung alle 5 Millisekunden sieht man deutlich, dass der Schwellwert ganz oft erheblich überschritten wurde.

Jetzt kann man lange darüber diskutieren, ob man nicht einfach bessere Tools einsetzen sollte. Das Problem ist nur, dass diese nichts nutzen. Tatsache ist, dass die Microbursts so extrem schnell auftauchen, dass es überhaupt keine Möglichkeit gibt, hier jetzt irgendwie von außen einzugreifen.

Auch eine noch so tief in die Hardware integrierte Congestion Control kann mit diesen Lastspitzen nicht umgehen. Bevor die Congestion Control überhaupt irgendeine Aktion einleiten konnte, ist der Microburst schon wieder vorbei.

Der Stand der Technik ist:

  • es gibt Microbursts
  • man kann nichts gegen sie unternehmen
  • Microbursts führen zu kurzfristiger, starker Congestion

Die Frage ist also lediglich: wie gehen unterschiedliche Switch-Bauarten mit den Microbursts um? Das ist einfach zu beantworten:

  • Switches mit ASICs auf der Basis von Speichern können im Fall eines Microbursts nur noch Pakete verwerfen, wenn ihr Speicher voll ist. Je stärker die Microbursts zuschlagen, desto schlimmer ist der Effekt. Die Latenz wird steigen. Vor allem wird aber der Goodput erheblich sinken. Dadurch wird für einen nennenswerten Prozentsatz der Pakete die Latenz in den Bereich der Retransmissionsverzögerung fallen, weil sie neu geschickt werden müssen.
  • Switches mit ASICs auf der Basis angereicherter Crossbars haben im Falle des Mircrobursts einen Puffer zur Verfügung, in dem sie die Pakete, die nicht sofort bearbeitet werden können, kurzfristig zwischenlagern. Dadurch steigt bezogen auf die davon betroffenen Pakete die Latenz zwar an, da aber der Goodput relativ hoch bleibt, kommen kaum Pakete in den zweifelhaften Genuss der Retransmission.

Die Universitäten Stanford und Carnegie-Mellon (CMU) haben einen so genannten Incast-Test entworfen. Ein Incast ist ein zu Messzwecken böswillig herbeigeführter Microburst. In der Abbildung 3 sehen wir ein Testszenario: 23 Server kommen auf einmal auf die „Idee“, dem Client etwas zu schicken, und zwar mit voller Line Rate. Der Switch muss es ausbaden.

Insgesamt können wir festhalten:

  • Switches mit ASICs auf der Basis von Speichern haben den Vorteil einer extrem geringen Latenz, sofern sie in einem Umfeld verbaut werden, wo keine Congestions in Form der angesprochenen Microbursts auftreten können. Ein gutes Beispiel dafür sind Blade-Switches. Bei größeren Konfigurationen haben diese aber den Nachteil, dass mehrere Stufen verwendet werden müssen, was die Latenz wieder steigen lässt.
  • Switches mit ASICs auf der Basis angereicherter Cross-Bars haben zunächst den Nachteil, dass ihre Latenz systembedingt höher ist. Sie können aber besser mit Microbursts umgehen. Bei größeren Konfigurationen haben sie den Vorteil, dass konstruktionsbedingt die Latenz nicht weiter steigt, sondern bei einer Skalierung konstant bleibt. Ihre Infrastruktureignung ist also besser.

Zusammenfassend kann man sagen, dass Switches mit ASICs auf der Basis angereicherter Cross-Bars ab 512 Ports die Latenz von Switches mit ASICs auf der Basis von Speichern einholen und bei einer weiteren Steigerung der Portzahl deutlich besser sind.

weiter mit: Latenzarme Adapterkarten

 

ComConsult Netzwerk-Redesign Forum 2011

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 2048941 / Low Latency Networking)