Infiniband: die Welle rollt!

Kommentieren Drucken

Mellanox, der weltweit nach Umsatz führende Infiniband-Hersteller, hat seinen Gewinn im letzten Quartal erheblich gesteigert. Der Gewinn stieg um das 15-fache (!) gegenüber dem 2Q2011. Primärer Umsatzträger sind die SwitchX-ASICs und die dazu passenden ConnectX Adapter. Die Markteinführung des FDR-IB (FDR = Fourteen Data Rate 56 Gbit/s.) kann nur als grandios bezeichnet werden. Die Aussichten für die nächsten Quartale sind sogar noch besser. Spannend ist aber auch, dass der Besitzer konvergenter Ethernets von den IB-Qualitäten profitieren kann.

Mellanox hat ganz klar dadurch Boden gut gemacht, dass zwar viel über 40 und 100 GbE geredet wird, die Lösungen dann aber oft für die Betreiber, die das wirklich benötigen, zu spät kommen. IB ist schon seit vielen Jahren fest im HPC-Umfeld verankert, aber die Anwendungsbereiche sind dabei, sich deutlich auszudehnen.

Besitzer von DB-Clustern, Clustered Storage und Cloud Provider wissen die hohe Leistung zu schätzen. Aber IB ist nicht nur auf solche Umgebungen beschränkt. Mit dem XEON E5-2600 hat Intel einen Prozessor mit unmittelbarer FDR-IB-Anbindung auf den Markt gebracht. FDR treibt die PCIe-Architektur zwar an ihre Grenzen, aber es funktioniert. Erweiterungen von PCIe für mehr Leistung stehen auf der Roadmap der PCI-SIG. Der für den September angekündigte Windows Server 2012 von Microsoft wird neben anderen auch eine Schnittstelle für FDR-IB beinhalten.

Im Ethernet-Bereich führt man seit langem eine Diskussion über die Anbindung von VMs. Diese hat zu einer langen Liste von Standards wie VEB, VEPA und Port-Extendern, herstellerspezifischen Vorschlägen wie VXLAN bzw. völlig inakzeptablen Softswitches geführt. Dabei wurde die Tatsache, dass eine VM letztlich ein Prozess ist, irgendwie in den Hintergrund gedrängt. Und Prozesse benötigen Inter-Prozess-Kommunikation IPC, darum heißt sie so. Aus der bisherigen Entwicklung der Virtualisierung haben wir gelernt, dass bestimmte Funktionen nur mit einer passenden Hardware-Unterstützung erfolgreich implementiert werden können. Ohne die Hardware-Unterstützung des virtuellen Speichers für die VMs würden wir heute kaum mehr über VMs reden, sie wären einfach zu langsam.

Mit SR-IOV gibt es eine Hardware-Unterstützung für die asynchrone I/O. Die ganzen Experimente im Ethernet-Bereich kommen eigentlich daher, dass man mehr oder minder verzweifelt versucht, einen VM-IPC-Mechanismus über die I/O umzubiegen. Das geht auch, wenn man keine oder nur wenig Leistung benötigt.

Das Faszinierende an IB ist, dass seine gesamte Architektur direkt auf einen IPC-Mechanismus ausgerichtet ist, nämlich RDMA.

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 Speicher 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 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 zu der ü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 durch das Aufsetzen eines Kanals zwischen der auslösenden Anwendung und der Anwendung, mit der kommuniziert wird, 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 in den 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. Bild 1 zeigt, wie es 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 Bild 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 2 ** 31 Bytes 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.

RDMA für Ethernet-Fans

2011 gab es eine kleine Sensation: die IBTA hat eine Ergänzung zu den IB-Standards formuliert, die die unteren zwei Schichten der 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.

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.

Mellanox hat schon 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!

Auch schon in früheren Bildern aus dem DCB-Umfeld sehen Sie oft einen reservierten Bereich für IPC. Auch im Fall von RoCE sind die DCB-Funktionen der Schlüssel zum Erfolg.

Der Vollständigkeit halber sei erwähnt, dass es noch einen weiteren Standard für RDMA über Ethernet gibt, nämlich iWARP der IETF. iWARP benutzt allerdings TCP oder SCTP-Transport und muss, um genauso schnell laufen zu können wie RoCE, ebenfalls komplett in Hardware implementiert werden. Dazu habe ich aber noch kein auffälliges Produkt gesehen, kann aber noch kommen.

Fazit

Wem das ganze Gewimmel zur VM-Kommunikation via Ethernet zu dumm ist, sollte sich ernsthaft mit RDMA und IB als Alternative beschäftigen. Wer sich von seinem Ethernet auch im RZ nicht trennen möchte, könnte RoCE oder iWARP benutzen. Schließlich gibt es noch die Möglichkeit, mit einem IB-Netz ein konvergiertes Ethernet „nachzumachen“, wie es Mellanox mit seinen Komponenten anbietet. Dadurch, dass jeder namhafte Hersteller im HPC-Umfeld mitspielen möchte, ist die allgemeine Unterstützung sehr breit, also z.B. auch Cisco bietet für seine UCS-Server durchaus IB-Komponenten und –Support an.

Die nächste Ausbaustufe von IB ist 100 Gbit/s. und wird im nächsten Jahr kommen. Die Bezeichnung dafür ist dann Enhanced Data Rate EDR. Der Bruch mit den bisher „krummen“ Datenraten ist dadurch zu erklären, dass die Switch-ASICs weiterhin so entwickelt werden, dass sie sowohl Converged Ethernet als auch IB einheitlich unterstützen.

Aktueller Kongress zum Thema

ComConsult Rechenzentrum Infrastruktur-Redesign Forum 2012
Unsere Rechenzentren befinden sich in einer der größten Redesign-Phasen der letzten 20 Jahre. Die Entwicklung der letzten Monate hat gezeigt, dass hier eine völlig neue Form der Kommunikation und Zusammenarbeit zwischen Systembausteinen entsteht.
Das ComConsult Rechenzentrum Infrastruktur-Redesign Forum 2012 stellt sich diesen herausragenden Themen.
Zum Kongress »

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

*

.