Low Latency Networks im Überblick, Teil 6 Low Latency Messaging in High Performance Networks

In den letzten Artikeln haben wir die unterschiedlichen Architekturen kennen gelernt, die zur Schaffung latenzarmer Netze hinreichender Skalierbarkeit benutzt werden können. In diesem Teil vertiefen wir das noch in ein paar Richtungen. Zunächst sehen wir uns Möglichkeiten, Wirkungen und Konstruktionsformen latenzarmer Messaging-Mechanismen in Theorie, Praxis und Beispielen an, die eine hervorragende Basis für die Implementierung leistungsfähiger Inter-Prozess-Kommunikation darstellen.

Anbieter zum Thema

ICP Deutschland GmbH

Lenovo Global Technology Germany GmbH

Paessler AG

ComConsult Akademie

ComConsult Beratung und Planung GmbH

Völlig unabhängig davon, ob Anwendungen virtualisiert sind oder nicht, kann es notwendig sein, dass sie ein zuverlässiges Messaging-System für die IPC benutzen können. Viel Öffentlichkeit haben in diesem Zusammenhang Anwendungen für das Finanzwesen bekommen, aber es gibt auch andere.

Geringe Latenz ist eine verschärfte Anforderung an derartige Lösungen. Insgesamt müssen sie Folgendes können:

• Hohe Leistung mit extrem geringer Latenz im Sub-Millisekundenbereich
• Unterstützung einer extrem hohen Nachrichtenrate von mehreren Millionen Nachrichten pro Sekunde
• Flexibilität beim Ausliefern von Nachrichten: PtP Unicast Messaging, PtMP sowie MPtoMP Broadcasting
• Zuverlässige Auslieferung von Nachrichten mit granulierter Kontrolle der tatsächlichen Message-Auslieferung
• Hohe Verfügbarkeit zur Bereitstellung von System Service Levels und zum Schutz der Integrität des Nachrichtenstroms beim Ausfall von Komponenten
• Schutz der Integrität der Nachrichten in Übertragungsgeschwindigkeit für das Wiederherstellen von Nachrichten und das Auditing, Realisierung üblicherweise durch eine geeignete Verschlüsselungstechnik
• Monitoring und Congestion Control, um mögliche Engpässe frühzeitig erkennen zu können
• Filterungsmöglichkeiten für Messages in hoher Geschwindigkeit, um Multiplexing und effiziente Segmentierung von Daten zu ermöglichen.

Viele Leser, die sich noch nicht näher mit RDMA befasst haben, sind sicher der Ansicht, dass es sich dabei lediglich um eine weitere Art einfacher Schnittstellen handelt. Vom Prinzip her ist das korrekt, die Frage ist aber, was man daraus machen kann. Üblicherweise setzt man auf RDMA einen Messaging-Service. Das ist ein anwendungsorientierter Kommunikationsmechanismus, der streng genommen in die Schicht 7 des ISO-OSI-Modells gehört, genau wie File Transfer.

Ein guter Messaging Service hat daher eine Reihe von Funktionen, wie weit über das hinausgehen, was z.B. ein TCP/IP-Stack kann. Letzterer kann allerdings von einem Messaging Service auch mitbenutzt werden. Es gibt natürlich bereits viele Messaging Services, die Frage ist aber, wie sie es mit der Latenz halten.

Statt aller Theorie sehen wir uns ein konkretes Produkt mit großem Leistungsumfang an. Den IBM „WebSphere MQ Low Latency Messaging“-Service (MQLLM).

WebSphere MQ Low Latency Messaging“-Service (MQLLM)

Das Produkt wurde entwickelt, um den erhöhten Anforderungen in verschiedenen Bereichen, besonders bei Finanztransaktionen, Rechnung zu tragen. Als Peer-to-Peer-Lösung unterstützt es die Verbindungsformen PtP, PtMP und MPtMP. Außerdem wird die IP Multicast-Infrastruktur letztlich um Realzeitfähigkeiten erweitert. Das bedeutet, dass MQLLM nicht nur auf unterschiedlichen Arten von LANs (GbE, IB), sondern auch im Weitverkehrsbereich eingesetzt werden kann, wobei natürlich dort die Latenz maßgeblich durch die Signalverzögerung bestimmt wird.

Die sog. Open Fabrics Enterprise Distribution liefert eine Anzahl von Librarys für die Implementierung von RDMA auf standardbasierten Industriekomponenten für 1GbE, 10 GbE und IB. Neben hoher Flexibilität wurde bei der Entwicklung Wert darauf gelegt, alles mit einer möglichst geringen CPU-Belastung zu realisieren.

MQLLM kann alleine benutzt werden oder ein eine weitere Architektur, wie z.B. in die IBM WebSphere DataPower Appliance eingebettet werden. DataPower ist im Grunde genommen eine unternehmensweite Service-Busarchitektur, also eine erweiterte Form des „Netz als Systembus“-Gedankens. Das ist insgesamt sehr interessant, wir konzentrieren uns hier aber weiter auf MQLLM.

MQLLM benutzt eine proprietäre Batching-Technologie und ein kompaktes Header-Format, um die anfallenden Daten schnell, zuverlässig und mit geringem Aufwand in einen Message-Strom zu überführen. Leistungstests für IB haben einen möglichen Durchsatz von bis zu 91 Millionen Messages pro Sekunde bei einer durchschnittlichen Latenz von unter 5 µs gezeigt. WebSphere MQLLM kann Shared Memory als Transportsystem benutzen. Das nutzt die Möglichkeiten der neueren Multi-Core Prozessor Chips und die Strategien zur sog. „Co-Location“ aus. Diese Strategien beziehen sich zusammenfassend ausgedrückt auf die Vermeidung unnötig langer Wege zwischen Komponenten. Tests haben bewiesen, dass man auf diese Weise die Latenz sogar unter 1 µs senken kann.

Nicht alle Anwendungen werden immer die allerhöchsten Anforderungen haben. Neben dem PtP-RDMA bietet MQLLM zunächst einen schnellen Multicast-Transport mit UDP und Receiver Feedback. Neben dem zuverlässigen Multicast-Mechanismus gibt es noch einen weiteren lightweight-Mechanismus für PtP. Dieser basiert ebenfalls auf UDP mit Feedback und Möglichkeiten der Verkehrskontrolle.

Um das Design der Messaging-Infrastruktur zu vereinfachen, können mehrere Unicast- oder Multicast-Destinationen zu einem sog. „Transmitter Topic“ zusammengefasst werden. Schließlich gibt es noch einen zuverlässigen PtP-Unicast-Kommunikationsmechanismus über TCP/IP, wobei Zuverlässigkeit und Verkehrskontrolle hauptsächlich von TCP gewährleistet werden. So bekommt man einen Datenstrom auch zuverlässig durch ein WAN oder durch Firewalls. Die Abbildungsmöglichkeiten der Datenströme auf die TCP-Kommunikation sind vielfältig. Allerdings sind die TCP-Verbindungen „schwergewichtige“ Objekte, so dass man sie nur sparsam einsetzen sollte.

Es gibt in MQLLM verschiedene Methoden zur Gewährleistung der Zuverlässigkeit, die wir hier nicht weiter besprechen wollen. Zwischen einem „Fire-and-Forget-Ansatz“ und einer Zuverlässigkeit, die über die Möglichkeiten eines normalen TCP hinausgeht, gibt es ein hinreichendes Spektrum. Insgesamt ist es auch ohne TCP in der Lage, verlorengegangene Pakete oder Pakete, die sich der Reihenfolge entzogen haben, erneut zu beschaffen bzw. richtig einzusortieren.

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

(ID:2049006)