Netztopologien für die Interoperation über einen IBM MQ-Link

Diese Beispiele zeigen einen Bereich von Netztopologien (einfache bis komplexe Topologien), die WebSphere Application Server die Interoperation mit IBM MQ über einen IBM MQ-Link ermöglichen.

Dieser Artikel beschreibt ein breites Spektrum von Topologien, einschließlich Clustertopologien und Topologien mit hoher Verfügbarkeit. Beachten Sie, dass Sie für das Clustering und die Hochverfügbarkeit die Network-Deployment-Version oder die z/OS-Version des Produkts verwenden müssen.

Einzelner WebSphere Application Server-Anwendungsserver, der mit einem einzelnen IBM MQ-Warteschlangenmanager verbunden ist

In diesem Basisszenario verbindet ein IBM MQ-Link einen einzigen WebSphere Application Server-Anwendungsserver mit einem IBM MQ-Warteschlangenmanager. Die Messaging-Engine von WebSphere Application Server, die mit IBM MQ über einen IBM MQ-Link verbunden ist, wird als Gateway-Messaging-Engine bezeichnet. Der IBM MQ-Warteschlangenmanager bzw. die Gruppe mit gemeinsamer Warteschlange, mit dem bzw. der ein IBM MQ-Link verbunden ist, wird als Gateway-Warteschlangenmanager bezeichnet.

Abbildung 1. Einzelner Anwendungsserver, der mit einem Gateway-Warteschlangenmanager verbunden wird
Ein WebSphere Application Server-Anwendungsserver enthält eine Gateway-Messaging-Engine, die eine Verbindung zu einem Gateway-Warteschlangenmanager herstellt.

IBM MQ-Links verwenden immer TCP/IP-Verbindungen, selbst wenn der IBM MQ-Warteschlangenmanager auf demselben Host wie der Anwendungsserver ausgeführt wird. Sie müssen den Transporttyp "Client" oder "Bindungen" für die Verbindung nicht angeben, wie es der Fall ist, wenn IBM MQ als Messaging-Provider verwendet wird.

Der IBM MQ-Link setzt sich aus einem oder mehreren Nachrichtenkanälen zusammen, über die Nachrichten an IBM MQ gesendet und/oder Nachrichten von IBM MQ empfangen werden können. Jeder Nachrichtenkanal verwendet eine TCP/IP-Verbindung.

Die Nachrichtenkanäle unterstützen Punkt-zu-Punkt-Messaging zwischen WebSphere Application Server-Anwendungen und IBM MQ-Anwendungen. Außerdem können Sie eine Publish/Subscribe-Brücke im IBM MQ-Link für das Publish/Subscribe-Messaging zwischen WebSphere Application Server-Anwendungen und IBM MQ-Anwendungen konfigurieren. Weitere Einzelheiten zum IBM MQ-Link und dessen Nachrichtenkanälen finden Sie im Artikel Nachrichtenaustausch über einen IBM MQ-Link.

WebSphere Application Server-Zelle, die mit einem IBM MQ-Netz verbunden ist

Ein einzelner IBM MQ-Link kann einen vollständigen Service Integration Bus (SIB) von WebSphere Application Server, der mehrere Anwendungsserver darstellt, mit mehreren IBM MQ-Warteschlangenmanagern verbinden. Die zwischen den beiden Netzen ausgetauschten Nachrichten werden alle über den IBM MQ-Link übertragen, der eine Gateway-Messaging-Engine in WebSphere Application Server und einen Gateway-Warteschlangenmanager in IBM MQ miteinander verbindet. Die Gateway-Messaging-Engine und der Gateway-Warteschlangenmanager verteilen die Nachrichten, bei denen sich um Punkt-zu-Punkt- oder Publish/Subscribe-Nachrichten handeln kann, an die entsprechenden Anwendungsserver und Warteschlangenmanager in den jeweiligen Netzen.

Abbildung 2. Mehrere Anwendungsserver, die mit mehreren Warteschlangenmanagern verbunden sind
Eine WebSphere Application Server-Zelle enthält mehrere Anwendungsserver, die mit dem Anwendungsserver in der Zelle verbunden sind, der die Gateway-Messaging-Engine enthält. Die Gateway-Messaging-Engine ist mit dem Gateway-Warteschlangenmanager in den IBM MQ-Netzen verbunden, der jeweils mit weiteren Warteschlangenmanagern verbunden ist.
In dieser Topologie endet die Interoperation, wenn eine der folgenden Bedingungen eintritt:
  • Der WAS-Anwendungsserver, der die Gateway-Messaging-Engine enthält, fällt aus.
  • Der Host, auf dem der WAS-Anwendungsserver ausgeführt wird, fällt aus.
  • Der IBM MQ-Gateway-Warteschlangenmanager fällt aus.
  • Der Host, auf dem der IBM MQ-Gateway-WS-Manager ausgeführt wird, fällt aus.
In diesen Situationen kann keiner der Anwendungsserver in der Zelle von WebSphere Application Server mit einem der Warteschlangenmanager in IBM MQ kommunizieren. Beim Auftreten eines Fehlers werden die Nachrichten wie folgt in die Warteschlange eingereiht:
  • Wenn die Gateway-Messaging-Engine in WebSphere Application Server ausfällt oder nicht mehr mit IBM MQ kommunizieren kann, werden Nachrichten, die bereits in die Warteschlange der Gateway-Messaging-Engine, die Speicher- und Weiterleitungsfunktionen besitzt, eingereiht wurden, dort gespeichert und gesendet, wenn die Interoperation wiederhergestellt ist.
  • Wenn die Gateway-Messaging-Engine in WebSphere Application Server ausfällt, werden Nachrichten, die in den Warteschlangen der Messaging-Engines anderer Anwendungsserver eingereiht wurden, in diesen Messaging-Engines gespeichert und gesendet, wenn die Gateway-Messaging-Engine wieder in Betrieb ist.
  • Wenn der Gateway-Warteschlangenmanager in IBM MQ ausfällt oder nicht mehr mit WebSphere Application Server kommunizieren kann, werden Nachrichten, die bereits in die Warteschlange des Gateway-Warteschlangenmanagers eingereiht wurden, gesendet, wenn die Interoperation wiederhergestellt ist.
  • Wenn der Gateway-Warteschlangenmanager in IBM MQ ausfällt, werden Nachrichten, die in den Warteschlangen anderer Warteschlangenmanager eingereiht wurden, gesendet, wenn der Gateway-Warteschlangenmanager in Betrieb ist.

Sie können die Leistungsfähigkeit dieser Topologie verbessern und eine größere Verfügbarkeit einführen, indem Sie Frameworks für Hochverfügbarkeit in WebSphere Application Server und IBM MQ konfigurieren.

Hochverfügbarkeit für eine WebSphere Application Server-Zelle, die mit einem IBM MQ-Netz verbunden ist

Das Framework für hohe Verfügbarkeit in WebSphere Application Server schaltet Single Points of Failure aus und unterstützt das Peer-to-Peer-Failover für Anwendungen und Prozesse, die in WebSphere Application Server ausgeführt werden. Dieses Framework ermöglicht auch die Integration von WebSphere Application Server in eine Umgebung, in der andere Frameworks für hohe Verfügbarkeit, wie z. B. High Availability Cluster Multi-Processing (HACMP), eingesetzt werden, um Ressourcen zu verwalten, die keine Ressourcen von WebSphere Application Server sind.

WebSphere Application Server-Anwendungsserver und IBM MQ-Warteschlangenmanager können in Clustern angeordnet werden, sodass beim Ausfall einer Komponente die anderen Komponenten weiter ausgeführt werden können. In der hier gezeigten Netztopologie enthält die WebSphere Application Server-Zelle, die den Service Integration Bus enthält, jetzt einen WebSphere Application Server-Cluster, der als Backup für die Gateway-Messaging-Engine dient. Wenn die Gateway-Messaging-Engine ausfällt, kann sie in einem anderen Anwendungsserver im Cluster erneut gestartet werden und anschließend den IBM MQ-Link zum Gateway-Warteschlangenmanager erneut starten. Analog dazu ist der Gateway-Warteschlangenmanager Teil eines IBM MQ-Hochverfügbarkeitsclusters.

Abbildung 3. Hohe Verfügbarkeit für mehrere Anwendungsserver, die mit mehreren Warteschlangenmanagern verbunden sind
Eine WebSphere Application Server-Zelle enthält mehrere Anwendungsserver, die mit dem Anwendungsserver in der Zelle verbunden sind, der die Gateway-Messaging-Engine enthält. Der Anwendungsserver, der die Gateway-Messaging-Engine enthält, ist Teil eines Clusters von WebSphere Application Server, zusammen mit einem anderen Anwendungsserver, der eine Gateway-Messaging-Engine für das Failover enthält. Das IBM MQ-Netz enthält einen Hochverfügbarkeitscluster, der mehrere Gateway-Warteschlangenmanager hat. Beim Ausfall der Gateway-Messaging-Engine stellen die Anwendungsserver in der Zelle von WebSphere Application Server eine Verbindung zur Gateway-Messaging-Engine für Failover her, die mit dem Gateway-Warteschlangenmanager auf dieselbe Weise wie die ursprüngliche Gateway-Messaging-Engine verbunden ist.

Damit WebSphere Application Server und IBM MQ in dieser Netztopologie interagieren können, müssen Sie die Unterstützung für Änderungen der IP-Adresse hinzufügen. Der IBM MQ-Gateway-Warteschlangenmanager verwendet eine einzige IP-Adresse, um die Gateway-Messaging-Engine von WebSphere Application Server zu erreichen, und die Gateway-Messaging-Engine von WebSphere Application Server verwendet eine einzige IP-Adresse, um den IBM MQ-Gateway-Warteschlangenmanager zu erreichen. Wenn die Gateway-Messaging-Engine in einer Hochverfügbarkeitskonfiguration von einem anderen Anwendungsserver übernommen wird (Failover) oder wenn der Gateway-Warteschlangenmanager ausfällt und durch einen Gateway-Warteschlangenmanager für Failover ersetzt wird, geht die Verbindung zur ursprünglichen IP-Adresse für die ausgefallene Komponente verloren. Sie müssen sicherstellen, dass beide Produkte in der Lage sind, ihre Verbindung zur Komponente an der neuen Position wiederherzustellen.

Um sicherzustellen, dass die Verbindung zu einer Ausweich-Gateway-Messaging-Engine von WebSphere Application Server wiederhergestellt wird, wählen Sie eine der folgenden Optionen aus:
  1. Wenn Sie eine Version von IBM MQ verwenden, die älter ist als Version 7.0.1, installieren Sie SupportPac MR01 für IBM MQ. Dieses SupportPac stellt dem IBM MQ-Warteschlangenmanager eine Liste mit alternativen IP-Adressen und Ports bereit, damit der Warteschlangenmanager die Verbindung zur Gateway-Messaging-Engine von WebSphere Application Server herstellen kann, nachdem die Messaging-Engine nach einem Ausfall von einer anderen IP-Adresse und einem anderen Port übernommen wurde. Sie müssen in WebSphere Application Server eine Hochverfügbarkeitsrichtlinie des Typs "Eins von N" für die Gateway-Messaging-Engine festlegen. Weitere Informationen zu IBM MQ MR01 SupportPac finden Sie unter MR01: Creating a HA Link between IBM MQ and a Service Integration Bus.
  2. Wenn Sie IBM MQ Version 7.0.1 verwenden, verwenden Sie den Verbindungsnamen (CONNAME), um eine Verbindungsliste anzugeben. Obwohl gewöhnlich nur ein einziger Maschinenname erforderlich ist, können Sie mehrere Maschinennamen angeben, um mehrere Verbindungen mit denselben Eigenschaften zu konfigurieren. Die Verbindungen werden in der Reihenfolge ausprobiert, in der sie in der Verbindungsliste angegeben sind, bis eine Verbindung hergestellt werden. Wenn keine Verbindung hergestellt werden kann, beginnt der Kanal mit der Wiederholungsverarbeitung. Geben Sie bei Verwendung dieser Option den Verbindungsnamen (CONNAME) in Form einer durch Kommas getrennten Liste mit Namen von Maschinen für den angegebenen Transporttyp an und stellen Sie dabei sicher, dass die IP-Adressen aller Cluster-Member von WebSphere Application Server direkt im Verbindungsnamen (CONNAME) aufgelistet sind. Weitere Informationen zur Verwendung des Verbindungsnamens (CONNAME) finden Sie im Information Center von IBM MQ.
    Anmerkung: IBM MQ Version 7.0.1 erfordert SupportPac MR01 nicht, weil dieses Release eine äquivalente Funktion zu der in SupportPac MR01 für frühere Releases bereitgestellten Funktion enthält. Die Möglichkeit, mit dem Verbindungsnamen (CONNAME) eine Verbindungliste anzugeben, wurde im Rahmen der Unterstützung mehrerer Instanzen von Warteschlangenmanagern in IBM MQ Version 7.0.1 hinzugefügt, kann aber auch als alternative Option für die Wiederherstellung der Verbindung zu einer Ausweich-Gateway-Messaging-Engine von WebSphere Application Server verwendet werden.
  3. Verwenden Sie ein externes Framework für hohe Verfügbarkeit wie HACMP, um eine Ressourcengruppe zu verwalten, die die Gateway-Messaging-Engine enthält. Wenn Sie ein externes Framework für hohe Verfügbarkeit verwenden, kann die IP-Adresse von der Maschine übernommen werden, auf der der Anwendungsserver ausgeführt wird, auf den die Gateway-Messaging-Engine verschoben wurde. Gehen Sie wie folgt vor, um die IP-Adresse ordnungsgemäß zu verarbeiten:
    • Definieren Sie eine Hochverfügbarkeitsrichtlinie des Typs "Verhinderung der Operation" für die Messaging-Engine, sodass das externe Framework für hohe Verfügbarkeit steuert, wann und wo die Messaging-Engine ausgeführt wird.
    • Erstellen Sie Ressourcen für die Messaging-Engine und ihre IP-Adresse in der Ressourcengruppe, die vom externen Framework für hohe Verfügbarkeit verwaltet wird.
    • Ziehen Sie in Betracht, den Datenspeicher der Messaging-Engine in dieselbe Ressourcengruppe zu übernehmen wie die Ressource, die die Messaging-Engine darstellt.
Um sicherzustellen, dass die Verbindung zu einem IBM MQ-Gateway-Warteschlangenmanager für Failover wiederhergestellt wird, wählen Sie eine der folgenden Optionen aus:
  1. Warteschlangenmanager mit mehreren Instanzen in IBM MQ konfigurieren, wie im Information Center von IBM MQ beschrieben. Wählen Sie in Ihrer Definition für den Senderkanal des IBM MQ-Links die Option Mehrere Verbindungsnamenslisten aus und geben Sie die Hostnamen (oder IP-Adressen) und Ports für die Server an, in denen sich die aktiven und Bereitsschaftswarteschlangenmanager befinden. Wenn der aktive Gateway-Warteschlangenmanager ausfällt, verwendet der Service Integration Bus diese Informationen, um die Verbindung zum Standby-Gateway-Warteschlangenmanager wiederherzustellen.
  2. IBM MQ-Hochverfügbarkeitscluster unter Verwendung eines externen Hochverfügbarkeitsframeworks wie HACMP erstellen, das die Übernahme von IP-Adressen unterstützt. Die Übernahme von IP-Adressen gewährleistet, dass der Gateway-Warteschlangenmanager an seiner neuen Position für den Service Integration Bus unverändert bleibt.

Der Gateway-Warteschlangenmanager und die Gateway-Messaging-Engine speichern Statusinformationen, die sie verwenden, um den Verlust und die Duplizierung von Nachrichten zu verhindern, wenn sie die Kommunikation nach einem Fehler erneut starten. Das bedeutet, dass die Gateway-Messaging-Engine die Verbindung immer zum selben Gateway-Warteschlangenmanager wiederherstellen muss.

Wenn Sie IBM MQ for z/OS-Gruppen für gemeinsame Nutzung verwenden, können Sie den IBM MQ-Link so konfigurieren, dass er gemeinsam genutzte Kanäle für die Verbindung verwendet. Gemeinsam genutzte Kanäle bieten im Vergleich mit den Clusteringoptionen für hohe Verfügbarkeit, die auf anderen IBM MQ-Plattformen bereitgestellt werden, eine höhere Verfügbarkeit, weil die gemeinsam genutzten Kanäle für die Wiederstellung der Verbindung einen anderen Warteschlangenmanager in derselben Gruppe für gemeinsame Nutzung verwenden können. Die Verbindungswiederherstellung in derselben Gruppe mit gemeinsamer Warteschlange ist gewöhnlich schneller, als auf den Neustart desselben Warteschlangenmanagers an derselben oder einer anderen Position zu warten.

Obwohl die in diesem Abschnitt beschriebene Netztopologie Verfügbarkeit und Skalierbarkeit bietet, ist die Beziehung zwischen der Workload in anderen Warteschlangenmanagern und WAS-Anwendungsservern, mit denen sie verbunden werden, komplex. Expertenratschläge erhalten Sie von Ihrem IBM® Ansprechpartner.

Mehrere WebSphere Application Server-Zellen, die mit einem IBM MQ-Netz verbunden sind

In diesem Beispielszenario hat ein Geschäft zwei geografisch voneinander getrennte WebSphere Application Server-Zellen und möchte sie mit demselben unternehmensweiten IBM MQ-Netz verbinden. Jeder Service Integration Bus hat eine eigene Gateway-Messaging-Engine, die über einen IBM MQ-Link mit einem nahen IBM MQ-Gateway-Warteschlangenmanager verbunden ist.

Abbildung 4. Geografisch voneinander getrennte Anwendungsserver, die mit demselben IBM MQ-Netz verbunden sind
Zwei Zellen von WebSphere Application Server enthalten jeweils mehrere Anwendungsserver, die mit dem Anwendungsserver in jeder Zelle verbunden sind, die die Gateway-Messaging-Engine für die Zelle enthält. Die Gateway-Messaging-Engines in den Zellen von WebSphere Application Server sind mit separaten Gateway-Warteschlangenmanagern im IBM MQ-Netz verbunden. Die Gateway-Warteschlangenmanager sind mit derselben Gruppe weiterer Warteschlangenmanager im IBM MQ-Netz verbunden.

In dieser Netztopologie können WebSphere Application Server-Anwendungen, die in einer der WebSphere Application Server-Zellen ausgeführt werden, Punkt-zu-Punkt- oder (über eine Publish/Subscribe-Brücke) Publish/Subscribe-Nachrichten mit IBM MQ-Anwendungen austauschen. Außerdem können sie die Funktionen des unternehmensweiten IBM MQ-Netzes verwenden, um Nachrichten mit WebSphere Application Server-Anwendungen auszutauschen, die in der anderen WebSphere Application Server-Zelle ausgeführt werden. Wie im vorherigen Szenario kann das Geschäft Frameworks für hohe Verfügbarkeit in WebSphere Application Server und IBM MQ verwenden, um eine erhöhte Verfügbarkeit und Skalierbarkeit zu bieten.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_mq_top03
Dateiname:cmm_mq_top03.html