Low Latency Messaging in High Performance Networks

Anbieter zum Thema

ALE Deutschland GmbH

Aagon GmbH

Vitel GmbH

ComConsult Akademie

ComConsult Beratung und Planung GmbH

Die fundamentale Grenze für die Zuverlässigkeit eines Messaging Systems

Eine fundamentale Grenze für die Zuverlässigkeit eines Messaging Systems ist die Größe des „History Buffers“, der dazu benötigt wird, Pakete, die vom Empfänger vermisst wurden, wieder erneut auszuliefern. Langsame Messaging Systeme können den Puffer durch Swappen auf eine Festplatte vergrößern. Bei Low Latency ist das aber nicht möglich, da die Verarbeitungsgeschwindigkeit der Nachrichtenübertragungsgeschwindigkeit entsprechen muss. Der Speicher kann auch für das Wiederaufsetzen kleinerer Prozeduren, die abgestürzt sind, verwendet werden. Der Message Store bei WebSphere MQLLM entspricht prinzipiell dem, was in Kapitel 2 über die Speicher, die in einem Switch-ASIC verwendet werden, gesagt wurde. Der Speicher lässt sich in vielfacher Weise für Wiederherstellungs-, Kontroll- und Multiplexing-Aufgaben verwenden.

Die Zuverlässigkeit des Messaging-Dienstes kann bei bestimmten Anwendungen oder Unternehmen Bestandteil des Auditings sein. Der WebSphere MQLLM Message Store unterstützt eine Anzahl von Hochverfügbarkeitskonfigurationen zum Schutz gegenüber Komponenten- und Anwendungsfehlern, um definierte Anforderungen hinsichtlich der Zuverlässigkeit nachweisbar durchzusetzen.

Viele Anwendungen bekommen Probleme, wenn das Volumen der zu bewältigenden Messages in einem kurzen Zeitraum zu hoch wird. Congestion Facilities in WebSphere MQLLM helfen dabei, die Infrastuktur auch dann zuverlässig weiter laufen zu lassen, wenn die Anwendungen überbeschäftigt sind. Sowohl Multicast- als auch Unicast-Transporte beinhalten Methoden, um den Verkehr zu beobachten (Übertragungsrate, Verluste, Retransmissionen, Latenz), die Anwendungen von bevorstehenden Problemen zu informieren und die Probleme durch Umgehung langsamer Empfänger oder das Herabregeln von Sendern zu umgehen.

Normalerweise ist die Bestimmung der Latenz von Ende-zu-Ende-Verbindungen problematisch, weil die Maschinen nicht über eine einheitliche Synchronisation verfügen. WebSphere MQLLM hat aber ab Version 2.3 eine nachrichtenbasierte Synchronisationstechnologie. So kann man innerhalb der Reichweite des Produkts präzise Messungen vornehmen.

Es gibt noch eine Reihe weiterer Funktionen. Normalerweise arbeitet MQLLM Übertragungsanfragen der Reihe nach so schnell wie möglich ab. Man kann aber auch Regeln eingeben, die letztlich einer Priorisierung entsprechen. Genauso gut ist es möglich, bestimmte Grenzen anzugeben, wie z.B. den maximalen Anteil einer Nachricht am MessageStore, ACK/NACK-Limits und weitere Schwellwerte, dynamische Akkumulationstechnologie mit Label-Switching und Filter für alles Mögliche.

Ein Nachrichtenstrom wird dazu in mehreren Schichten bearbeitet, bevor er die Anwendung erreicht. WebSphere MQLLM unterstützt einen weitreichenden Filtermechanismus, der dem in Java Message Service (JMS) nicht unähnlich ist.

Stream Failover und weitere Hochverfügbarkeitsmechanismen runden das Funktionsspektrum ab, siehe Abbildung 1.

Ein weiteres Element in diesem Zusammenhang ist RCMS (Reliable and Consistent Message Streaming), welches die gesamten Möglichkeiten angewandt auf Applikationsbeziehungen systematisch nutzt, siehe Abbildung 2.

Die Lösung ist für eine große Anzahl von Plattformen verfügbar, darunter MS Windows, Linux, zLinux, HP-UX Itanium und verschiedene Sun Plattformen mit Solaris und x86.

Ein Praxistest

Wie schon erwähnt, läuft IBM WebSphere MQLLM prima auf IB mit RDMA. Wir wollen aber hier wissen, was passiert, wenn man es mit RoCE über ein latenzarmes Ethernet implementiert und haben daher einen Test aufgebaut: IBM WebSphere MQ Low Latency Messaging mit Arista 7100 10 Gigabit Ethernet-Switch und Mellanox ConnectX-2EN mit RoCE-Adapter.

Das Ziel des hier zitierten Tests war die Bestimmung der Latenz und des Durchsatzes über einen einzelnen Hop einer 10 GbE Fabric für WebSphere MQ Low Latency Messaging WMQLLM mittels des 10 GbE RoCE Industrie-Standard-Protokolls mit zwei passenden Mellanox-Adaptern.

Der Rechner war ein IBM x3650 M2 Quad Core mit 2 X Intel Xeon Quad Core X5570 2,93 GHz, 8 MB Level 2 Cache und 16 GB Speicher. Betriebssystem Linux SuSE 11, Switch Arista 7124S mit SFP+ und LC-zu-LC Fiber Connectoren.

Der Testaufbau besteht aus zwei Maschinen, die durch einen Switch miteinander verbunden sind, siehe Abbildung 3.

Auf Maschine A sendet ein LLM-Transmitter Nachrichten an einen LLM-Empfänger auf Maschine B. Dieser gibt sie sofort an einen LLM-Transmitter auf B weiter, der sie dann zurück über das Netz an einen LLM-Receiver auf Maschine A sendet. Vor der Sendung wurde eine Teilmenge der Nachrichten von A mit einem Zeitstempel versehen. Nach dem kompletten Round-Trip wird dieser Zeitstempel extrahiert und ausgewertet. Die Single Hop Latenz ergibt sich aus der Hälfte der Round Trip Zeit zwischen den Stempeln.

Die Tabelle in Abbildung 4 zeigt die Ergebnisse. Sie sind sehr eindrucksvoll, denn die Hop-Latenz liegt mit statistisch geringer Abweichung bei 4 µs. Erst bei extrem hoher Paketrate steigt sie etwas an.

Ein weiterer Test betraf den Durchsatz. Hier konnte man zeigen, dass ein Durchsatz von über 8,4 Gbps auf LLM-Ebene erzielt werden konnte. Das ist das theoretische Maximum, die Differenz zu 10 Gbps ergibt sich durch den notwendigen LLM-Overhead.

In einem weiteren Test hat man die Skalierbarkeit hinsichtlich von Multicasts ausprobiert. Dazu wurde der Latenz-Test zwischen den Maschinen A und B laufen gelassen und parallel dazu gab es Maschinen C und D, die eine unterschiedliche Zahl von Multicast-Gruppen benutzt haben. Das Ergebnis ist eine Latenz von ca. 12 µs unabhängig von der Anzahl der Multicast Gruppen. Das ist aber eher ein Test hinsichtlich der Leistungsfähigkeit des Switches und weniger der RoCE-Umsetzung.

Da IBM mittlerweile Blade gekauft hat, werden im realen Einsatz wohl keine Arista-Switches mehr verwendet werden, sondern die ebenso schnellen, aber darüber hinaus gegenüber Microbursts stabileren Modelle von Blade zum Einsatz bringen.

Zwischenfazit

Hochwertiges latenzarmes Messaging mit RDMA ist in HPC-Umgebungen schon länger verbreitet, Auch HP hat mit dem sog. Message Passing Interface MPI ein entsprechendes Produkt im Portfolio.