Mellanox kauft Voltaire – die Bedeutung für die Netzwerke im Überblick Low-Latency-Adapter und schnellste Switches aus einer Hand

Am 1.12.2010 hat der Spezialist für ultralatenzarme Host-Adapter Mellanox den Hersteller der momentan schnellsten Switches auf dem Netzwerkmarkt, Voltaire, gekauft. Die wirtschaftlichen Einzelheiten der Übernahme passen in die Börsennachrichten. Doch, was dies für die Konstruktion ultra-latenzarmer Netze bedeutet, ist die spannende Frage für IP-Insider.

Anwendungs- oder systemorientierte Lasten, die auf einer verteilten Systemarchitektur bewältigt werden sollen, sind grundsätzlich empfindlich gegenüber zu hoher Latenz. Jede Transaktion einer solchen Workload spannt eine große Anzahl von Interaktionen zwischen den Stellen auf, an denen die Leistung erbracht wird. Im Extremfall können das Hunderte von virtuellen Maschinen und Speicherkomponenten sein. Einige Beispiele:

• beim elektronischen Börsenhandel übernehmen Maschinen Marktdaten von anderen Maschinen, treffen aufgrund ihrer Algorithmen Kauf- oder Verkaufsentscheidungen und lassen diese von wieder anderen Maschinen ausführen. Selbst etwas vergleichsweise Langsames, wie der Goldpreis, schafft es, innerhalb einer Sekunde um mehr als 10 US-Dollar pro Feinunze zu springen. Beim Einkauf einer Tonne können Bruchteile dieser Sekunde daher bereits den Gegenwert eines Einfamilienhauses bedeuten.
• In HPC-Systemen werden Tausende Server geclustert, um komplexe Berechnungen und Simulationen durchführen zu können.
• In Web-basierten Cloud Anwendungen (oder sogar bei schlichten Suchvorgängen) können Workloads auf Tausenden dynamischer geclusterter Server laufen und mehrstufige Verarbeitungsmechanismen implementieren, die sich durch PetaBytes von Daten wühlen.

Moderne Unternehmen sind vielfach mit dem Web und den dortigen Dienstleistungen eng verwoben. Es ist ganz schlecht für den Netzwerker, wenn man ihm nachweisen kann, dass unerträgliche Antwortzeiten genau in dem durch ihn zu verantwortenden Netz entstehen.

Um die systemweite Antwortzeit zu verbessern, müssen Berechnungszeit und Netzlatenz minimiert werden. Bei üblichen Servern sind die Einflussmöglichkeiten aber eher gering. Hat man einen Server mit dichter und schneller Multicore-Architektur, dazu passenden Speichern und Caches sowie entsprechende periphere Kommunikationsmöglichkeiten unterstützt dieser Server eben eine bestimmte Anzahl von VMs und Transaktionen bis zu einer gewissen Grenze. War er von Anfang an optimal konfiguriert, kann man diese Grenze nur unwesentlich beeinflussen und neue Hardware muss her.

Der diskrete Charme der Virtualisierung ist aber, dass man die Leistung der – nennen wir es einmal – lokalen Cloud durch Hinzufügung neuer Hardware (Server und Speicher) praktisch beliebig steigern kann. Also liegt der „schwarze Peter“ wieder beim Netz.

Latenzminimierung

Um eine „Fabric-weite“ Latenzminimierung durchzuführen, muss die Latenz im Grunde genommen entlang folgender vier Achsen minimiert werden:

• Reduktion der Latenz jedes einzelnen Knotens im Netz
• Reduktion der Anzahl von Knoten, die zwischen Quelle und Ziel durchlaufen werden müssen
• Eliminierung von Congestion
• Reduktion der Latenz von Transportprotokollen

Es gibt eine Reihe latenzarmer Switches mit Schaltzeiten unterhalb einer Mikrosekunde, z.B. von Arista, Blade Networks (jetzt IBM) oder Juniper. Ein typisches gemeinsames Merkmal all dieser Switches ist die feste Portzahl.

Natürlich gibt es mittlerweile auch Core-Switches mit extrem geringer Latenz.

Nehmen wir das Modell Vantage 8500 von Voltaire. Dieser Hersteller hat sich schon seit vielen Jahren einen sehr guten Namen als Spezialist für InfiniBand-Lösungen gemacht. Natürlich wird hier IB auch weiterentwickelt, aber Voltaire sieht einen „Bedarf für erhöhte Qualität und Reaktionsfähigkeit bei Kunden, die bisher erhebliche Investitionen in Ethernet-Infrastrukturen getätigt haben“. Außerdem habe „das Ethernet im Laufe der Zeit eine Reihe von IB-Qualitäten gelernt“ und „sei in seiner konvergierten Form eine Alternative zu IB für diejenigen, die die absolute Leistungsspitze von IB nicht benötigen“.

weiter mit: Der Vantag 8500 IB-Switch im Detail

Der Vantag 8500 IB-Switch im Detail

Konstruktiv und von seinem Geiste her gesehen ist der Vantage 8500 ein IB-Switch mit Ethernet-Schnittstellen. Dadurch ergibt sich ein wirklich beeindruckendes Leistungsspektrum.

Eine aggregate Gesamtleistung von 11,52 Tbps sorgt für die Unterstützung von bis zu 288 Full Duplex Non Blocking 10-GbE-Ports. 12 Slots fassen sogar Line-Boards mit jeweils bis zu 24 10-GbE-Schnittstellen oder Fabric Boards, von denen es bis zu vier geben kann.

An Protokollen und Verfahren unterstützt dieser Core-Switch beispielsweise:

• Schnittstellen SR, LR, LRM, Twinax
• L2: 4K 802.1Q VLANs, 9K Jumbo, IGMP, 802.1p QoS, STP, RSTP, MSTP, LLDP, 802.3ad LAG, 802.3x
• DCB: Qbb PFC, Qau QCN, Qaz ETS, VEB
• L2, L3, L4 ACLs

Mit diesen Grundfunktionen unterstützt der Switch FCoE, Ethernet Muli-Pathing, I/O-Virtualisierung sowie Fabric-weite Congestion Control und Management.

Die Latenz liegt dabei zwischen 600 und 1.200 ns.

Ein voll ausgebauter Core-Switch verbraucht bis zu 3 kW, insgesamt kann man also sagen, grob 10 W pro 10 GbE-Schnittstelle.

Der Hersteller legt Wert auf die hohe Kooperationsfähigkeit seiner Geräte mit Standard-Switches anderer Hersteller (wobei implizit vorausgesetzt wird, dass diese zur besseren Zusammenarbeit DCB unterstützen sollten.

Doch auch die schönsten schnellen Switches nützen natürlich nichts, wenn die Adapter nicht ebenfalls an der technologischen Grenze arbeiten.

Bewertungskriterien für Adapterkarten

Das Maß für die Bewertung einer Adapterkarte ist die Reaktionszeit. Allgemein gibt es zwei Ausprägungen, nämlich die zwischen dem Auftreten einer Nachricht auf dem Port und der Ankunft in einem Protokollstack (wire to application socket) und natürlich die in der Gegenrichtung zwischen dem Abgang aus einem Protokollstack und der Ankunft auf dem Port (application socket call to wire).

Die Hersteller sprechen gerne von „wire“. Das ist im Allgemeinen bei 10 GbE die „SFP+“-Schnittstelle. Ein auf diese Schnittstelle aufgesteckter optischer Transceiver fügt noch etwas Latenz hinzu – etwa im Bereich von 150 ns.

Doch um die Leistung der Mellanox-Karten würdigen zu können, muss ich Ihnen erst „Rocky“ vorstellen.

Konvergenzfunktionen: DCB, FCoE, RDMA, RoCE

Die DCB-Funktionen sind wie schon dargestellt in zweierlei Hinsicht elementar. Sie sind die Grundlage dafür, dass ULL-Switches überhaupt sinnvoll funktionieren können. Aber es ist auch ganz wesentlich, nicht zu vergessen, dass die DCB-Funktionen eine notwendige Voraussetzung dafür sind, in einem RZ-Netz Komponenten unterschiedlicher Latenzfähigkeit kooperieren zu lassen. Das bedeutet, dass im Hinblick auf die flexible Wachstumsfähigkeit eines RZ-Netzes die DCB-Funktionen für alle Switches unabdingbar sind.

FCoE diskutieren wir schon seit Jahren. Mit den ULL-Switches scheint es wirklich dazu zu kommen, dass man FCoE auch ohne ernst zu nehmende Leistungsverluste implementieren und benutzen kann. Die durch den Standard FC-BB_E gegebenen funktionalen Einschränkungen wie z.B. auf die FC-Klassen 2 und 3 bleiben dabei natürlich bestehen. Dennoch entsteht durch die Verwendung einer konvergierten Anbindung für Server, die gleichermaßen auf Ethernet- und FC-Ressourcen zugreifen müssen, ein erheblicher Kosten- und Management-Vorteil. Es wäre also zu begrüßen, wenn das wirklich so funktioniert.

Es gibt aber noch etwas anderes: die Inter-Process-Kommunikation, IPC. Für hochperformante Umgebungen hat sich hier RDMA (Remote Direct Memory Access) über InfiniBand IB als Standard etabliert.

Wir sprechen zurzeit viel über die I/O virtualisierter Systeme. Dabei gibt es ja ein weites Spektrum von leistungszerstörendem Unfug wie virtuelle Switches, die den Hypervisor so belasten, dass er sonst fast nichts mehr tun kann, über stark diskussionsfördernde Standards wie VEPA bis hin zu sehr schnellen Hardware-unterstützten Lösungen wie SR-IOV, wo man einen Durchsatz von 30 Gbps oder mehr erzielen kann.

SR-IOV ist schon sehr schnell und man kann es auch sehr latenzarm implementieren, aber RDMA ist noch schneller. Da einige Leser hier vielleicht nicht umfassend informiert sind, werde ich die Arbeitsweise von RDMA kurz erläutern.

weiter mit: Die Funktionsweise von RDMA

Die Funktionsweise von RDMA

RDMA ist ein Basismechanismus von IB. Wir haben ja heute eine meist „Netzwerk-zentrische“ Perspektive. Die basiert auf der Vorstellung, dass ein Betriebssystem Ressourcen besitzt und diese den Anwendungen zur Verfügung stellt, wenn sie sie brauchen. Virtualisierung bedeutet eine weitere Abstraktionsstufe dieses Modells. Hier werden die Ressourcen zunächst einmal auf virtuelle Maschinen verteilt, die diese dann wieder an die Anwendungen weiterreichen. So kommen wir z.B. von realen NICs, HBAs und I/O-Schnittstellen zu vNICs, vHBAs und SR-IOV, analog für Speicher und Prozessoren. Die Anwendungen verlassen sich im Gegenzug darauf, dass das auch richtig funktioniert.

Der Ansatz von IB ist anders, sozusagen „Anwendungs-zentrisch“. Hier steht die einfache Frage im Vordergrund: wie kann man es erreichen, dass eine Anwendung auf andere Anwendungen und Speicher so einfach, effizient und direkt wie möglich zugreifen kann? Betrachtet man das I/O-Problem aus dieser Perspektive, sehen Antworten anders aus als aus der Netzwerk-Perspektive. Die Grundidee von IB ist einfach: Versorgung von Anwendungen mit einem einfach zu nutzenden Messaging-Service. Gibt es den einmal, können Anwendungsprozesse ihn dazu benutzen, mit anderen Anwendungsprozessen oder Speichern zu kommunizieren. Das ist die ganze Idee.

Anstatt umständlich beim Betriebssystem anzufragen, kann ein Anwendungsprozess den Messaging-Service direkt benutzen. Da der Messaging Service ein klarer und direkter Dienst ist, kann sich die Anwendung den üblichen Tanz mit den Kommunikations- und Netzwerkkomponenten sparen. Da man Speicherverkehr als Menge von Kontroll- und Datennachrichten auffassen kann, kann man den Messaging Service auch für den Speicherverkehr benutzen.

Die InfiniBand-Architektur

Die InfiniBand-Architektur gibt jeder Anwendung unmittelbaren Zugriff zum Messaging-Service. „Unmittelbar“ bedeutet dabei, dass eine Anwendung das Betriebssystem gar nicht bemühen muss. Diese Idee ist konträr zur üblichen Standard-Umgebung, in der z.B. ein TCP/IP-Stack und die dazu gehörigen NICs einzig dem Betriebssystem gehören und eine Anwendung nicht direkt darauf zugreifen kann. Im Normalfall muss eine Anwendung eine Anfrage an das BS stellen. Die dazu gehörigen Daten aus dem virtuellen Speicher der Anwendung kommen dann in einen Stack, wo alle solche Anfragen und Daten landen. Der Stack wird dann mehr oder minder schnell abgearbeitet, erst z.B. durch TCP/IP und dann in Folge durch die MAC und PHY der Adapterkarte. Nach Durchlaufen des Netzes arbeitet dieser Mechanismus auf der anderen Seite genauso, bis die Daten endlich im virtuellen Speicher der Ziel-Anwendung ankommen.

InfiniBand vermeidet dies durch eine Technik, die als „Stack-Bypass“ bekannt ist. Dabei gibt es den gleichen Grad an Isolation und Schutz der Anwendung, wie das auch bei der „normalen“ Verwendung eines Betriebssystems wäre.

Der Messaging Service wird von InfiniBand

Der Messaging Service wird von InfiniBand durch das Aufsetzen eines Kanals zwischen der auslösenden Anwendung und der Anwendung, mit der kommuniziert, oder dem Dienst, der benutzt werden soll, implementiert. Die Anwendungen, die solche Kanäle benutzen, können Nutzer-Anwendungen aber auch Anwendungen aus dem Systemkern sein.

Die Aufgabe bei der Konstruktion von IB war also die Schaffung dieser isolierten und sicheren Kanäle zwischen virtuellen Adressräumen, die nicht nur auf dem gleichen, sondern auch auf physisch getrennten Rechnern, lokalisiert sein können.

Die Endpunkte eines Kanals heißen Queue-Pairs (QPs). Jedes QP besteht aus einer Send-Queue und einer Receive-Queue. Jedes QP repräsentiert ein Ende des Kanals. Benötigt eine Anwendung mehrere Verbindungen, müssen entsprechend viele QPs erzeugt werden.

Damit die Anwendungen jetzt direkten Zugriff auf die QPs haben, ohne das BS fragen zu müssen, werden die QPs im virtuellen Speicher der Anwendungen abgebildet. So hat die Anwendung an einem Ende einer Verbindung direkten Zugang zu einer Anwendung oder einem Speicher auf der andern Seite des so aufgesetzten Kommunikationskanals. Daher nennt man das Ganze auch Channel I/O. Abbildung 1 zeigt, wie dies gemeint ist:

Es gibt zwei Transfersemantiken, nämlich SEND/RECEIVE (Kanalsemantik) und RDMA (Speichersemantik). Bei der Kanalsemantik wird die Message in der Datenstruktur der empfangenden Anwendung dargestellt. Diese muss sie natürlich beim Aufbau des Kanals publiziert haben. Die Speichersemantik funktioniert anders. Hier definiert die empfangende Anwendung einen Puffer in ihrem virtuellen Speicher und überträgt die Kontrolle über diesen Puffer auf die sendende Seite. Mit den Kommandos RDMA READ und RDMA WRITE kann die sendende Seite dann auf diesen Puffer zugreifen. Konkret wäre also z.B. die sendende Seite eine Anwendung und die empfangende Seite ein Speichersystem.

Diese Semantiken werden zusammen verwendet, wie man am Beispiel einer Speicheroperation leicht verdeutlichen kann. Eine Anwendung, der „Initiator“ in diesem Falle, möchte Daten wegspeichern. Dazu stellt sie die Daten in einen Puffer in ihrem virtuellen Speicher und benutzt eine SEND-Operation, um ein Speichersystem aufzufordern, die Daten abzuholen. Das Speichersystem benutzt dann RDMA READ-Operationen, um die Daten aus dem Puffer des Initiators abzuholen. Sobald das geschehen ist, schickt das Speichersystem dem Initiator mittels des SEND-Kommandos eine Nachricht über die erfolgreiche Beendigung des Vorgangs. Während das Speichersystem liest, kann der Initiator natürlich schon etwas anderes machen.

Der Messaging-Mechanismus stellt die oberen zwei Schichten der IB-Architektur dar, siehe Abbildung 2.

Die IB-Architektur ist natürlich eine vollständige Kommunikationsarchitektur, arbeitet aber auf den einzelnen Schichten anders als ein TCP/IP-Netz. Grundsätzlich sind die Informationseinheiten zwischen den Anwendungen keine Datenpakete sondern Messages. Eine Message kann bis zu 231Bytes umfassen. Im Verlauf der Kommunikation werden sie natürlich herunter gebrochen und wieder zusammengesetzt.

IB hat (wie FC auch) eine eigene Komponentenwelt aus Adaptern, Switches, Kabeln und Steckern. Jedes Einzelteil ist ausschließlich und in höchstem Maße für die latenzarme und schnelle Kommunikation ausgelegt. Diese Komponenten sind normalem Ethernet haushoch überlegen und dennoch nicht überteuert. So kann z.B. IB heute im RZ der preiswerteste Weg zu einer 40 Gbps-Kommunikation sein.

weiter mit: RDMA over Converged Ethernet

RDMA over Converged Ethernet – RoCE oder „Rocky“

Jetzt gibt es aber eine Sensation: die IBTA hat eine Ergänzung zu den IB-Standards formuliert, die die unteren zwei Schichten die IB-Architektur durch konvergentes Ethernet ersetzt. Man ist der Ansicht, dass konvergentes latenzarmes Ethernet diese Aufgaben jetzt in all den Fällen übernehmen kann, wo es nicht auf die allerhöchste Performance ankommt.

Diese Ergänzung heißt RDMA over Converged Ethernet, kurz RoCE, gesprochen „Rocky“.

Es funktioniert genau wie bei FCoE. Bei FCoE werden die beiden unteren Schichten der FC-Architektur durch lossless Ethernet ersetzt, das FC-Paketformat bleibt unangetastet und wird lediglich eingepackt. Dadurch bleiben die gesamte FC-Logik und die Investitionen in FC-Infrastruktur geschützt.

Bei RoCE werden die beiden unteren Schichten der IB-Architektur durch konvergiertes Ethernet (DCB, lossless) ersetzt, es gibt allerdings ein neues Paketformat, in das die IB-Daten direkt eingepackt werden. Die IB-Logik muss nur so erweitert werden, dass statt des normalen IB-Pakets eben ein RoCE-Paket gepackt und verwendet wird. Der Rest der IB-Logik und die Investitionen in IB-Infrastruktur bleiben ebenfalls erhalten; siehe Abbildung 3.

Wegen der extrem stringenten, absolut deterministischen und auf Durchsatz und Latenzminimierung ausgelegten InfiniBand-Protokolle ist die Implementierung von RoCE viel klarer und einfacher als die von FCoE. Prozeduren, die die Kommunikation laufend überwachen und in Fehlerfällen eingreifen, gibt es hier zwar auch, aber sie haben einen wesentlich geringeren Umfang als bei FC-BB_E.

Was RoCE wirklich kann

Voltaire und Mellanox haben bereits gezeigt, was RoCE kann:

RoCE arbeitet auf einem latenzminimierten konvergenten10 GbE mit einer Latenz von 1,3 µs und mit einem zugrundeliegenden 40 GbE-Netz wurden sogar nur 0,8 µs Latenz gemessen.

Es gab zwischen Prozessoren und anderen Komponenten schon immer drei Arten der Kommunikation:

• einfache (asynchrone) I/O
• Speicherverkehr
• IPC

Ethernet konnte ursprünglich nur für die einfache I/O benutzt werden. Mit iSCSI oder FCoE kann der Speicherverkehr integriert werden. RoCE schließlich fügt dem konvergenten Netz endlich auch die Dimension einer Inter-Prozess-Kommunikation hinzu, die diesen Namen auch verdient.

Damit wird die Konvergenz endlich vollständig!