Interoperation, wenn WebSphere-Anwendungsserver und IBM MQ-Warteschlangenmanager in einem Cluster zusammengefasst sind

IBM MQ-Warteschlangenmanager werden gewöhnlich zu einem Cluster zusammengefasst, um die Nachrichtenlast zu verteilen und um sicherzustellen, dass beim Ausfall eines Warteschlangenmanagers die anderen weiter ausgeführt werden können.

Anmerkung: In diesem Artikel bezieht sich der Begriff "Anwendungsserver" auf einen Anwendungsserver, der in WebSphere Application Server ausgeführt wird, und der Begriff "Warteschlangenmanager" bezieht sich auf einen Warteschlangenmanager, der in IBM MQ ausgeführt wird.
Es stehen zwei Topologieoptionen zur Verfügung:
  • Die Warteschlangenmanager werden auf anderen Hosts als die Anwendungsserver ausgeführt
  • Die Warteschlangenmanager werden auf denselben Hosts wie die Anwendungsserver ausgeführt

Die Warteschlangenmanager werden auf anderen Hosts als die Anwendungsserver ausgeführt

Erläuterung zur folgenden Abbildung:

  • Die Anwendungsserver 1, 2 und 3 sind in einem Cluster von WebSphere Application Server zusammengefasst.
  • Die Anwendungsserver 1 und 3 werden auf Host 1 ausgeführt.
  • Der Anwendungsserver 2 wird auf Host 2 ausgeführt.
  • Die Warteschlangenmanager 1, 2 und 3 sind Teil desselben IBM MQ-Clusters.
  • Der Warteschlangenmanager 1 wird auf Host 3 ausgeführt.
  • Der Warteschlangenmanager 2 wird auf Host 4 ausgeführt.
  • Der Warteschlangenmanager 3 wird auf Host 5 ausgeführt.
  • Der Warteschlangenmanager 3 ist für die Verteilung der Nachrichten auf die Clusterwarteschlangen im Lastausgleichsverfahren verantwortlich.
  • Eine Verbindung ist mit "Client" angegeben, wenn der Anwendungsserver und der Warteschlangenmanager auf verschiedenen Hosts ausgeführt werden. Dies ist eine TCP/IP-basierte Netzverbindung für die Kommunikation mit dem Warteschlangenmanager. Eine Clientverbindung wird auch als "Socketzuordnung" bezeichnet.
    • Die Anwendungsserver 1 und 2 stellen eine Verbindung im Modus "Client" zum Warteschlangenmanager 1 her.
    • Die Anwendungsserver 3 stellt eine Verbindung im Modus "Client" zum Warteschlangenmanager 2 her.
Abbildung 1. Clustering in WebSphere Application Server: Zuordnung im Modus "Client" zu Warteschlangenmanagern
Die Anwendungsserver 1 und 3 werden auf Host 1 ausgeführt. Der Anwendungsserver 2 wird auf Host 2 ausgeführt. Der Warteschlangenmanager 1 wird auf Host 3 ausgeführt, der Warteschlangenmanager 2 wird auf Host 4 ausgeführt, und der Warteschlangenmanager 3 wird auf Host 5 ausgeführt. Die Anwendungsserver 1 und 2 stellen eine Verbindung im Modus "Client" zum Warteschlangenmanager 1 her. Server 2 wird im Clientmodus Warteschlangenmanager 1 zugeordnet. Die Warteschlangenmanager 1, 2 und 3 sind Teil desselben IBM MQ-Clusters. Warteschlangenmanager 3 ist für die Verteilung der Nachrichten an die Clusterwarteschlangen im Lastausgleichsverfahren verantwortlich.
Wenn Anwendungsserver 1 ausfällt:
Der Anwendungsserver 2 kann die Workload des ausgefallenen Anwendungsservers übernehmen, weil beide dem Warteschlangenmanager 1 zugeordnet sind.
Wenn Anwendungsserver 2 ausfällt:
Der Anwendungsserver 1 kann die Workload des ausgefallenen Anwendungsservers übernehmen, weil beide dem Warteschlangenmanager 1 zugeordnet sind.
Wenn Anwendungsserver 3 ausfällt:
Sie müssen den Warteschlangenmanager aus folgenden Gründen so schnell wie möglich erneut starten:
  • Andere Anwendungsserver im Cluster können die externe Workload des Warteschlangenmanagers übernehmen, aber kein anderer Anwendungsserver kann die IBM MQ-Workload des Warteschlangenmanagers übernehmen, weil kein anderer Anwendungsserver Warteschlangenmanager 2 zugeordnet ist. Die von Anwendungsserver 3 generierte Workload nimmt ab.
  • Der Warteschlangenmanager 3 setzt die Verteilung von Anforderungen an Warteschlangenmanager 1 und Warteschlangenmanager 2 fort, selbst wenn die für Warteschlangenmanager 2 eingehende Workload von Anwendungsserver 1 bzw. 2 nicht verarbeitet werden kann.
Anmerkung: Wenn Sie sich entscheiden, keinen Neustart durchzuführen, können Sie in dieser Situation eine Entlastung erreichen, indem Sie die Warteschlange 1 im Warteschlangenmanager 2 so konfigurieren, dass die Möglichkeit, Nachrichten in die Warteschlange einzureihen, unterbunden wird. Dies führt dazu, dass alle Nachrichten an den Warteschlangenmanager 1 gesendet werden, wo sie von den anderen Anwendungsservern verarbeitet werden.
Wenn Warteschlangenmanager 1 ausfällt:
Sie müssen den Warteschlangenmanager aus folgenden Gründen so schnell wie möglich erneut starten:
  • Wenn Warteschlangenmanager 1 ausfällt, werden die in ihm befindlichen Nachrichten so lange nicht verarbeitet, bis Sie Warteschlangenmanager 1 erneut starten.
  • Es werden keine neue Nachrichten von IBM MQ-Anwendungen an Warteschlangenmanager 1 gesendet. Stattdessen werden neue Nachrichten an Warteschlangenmanager 2 gesendet und von Anwendungsserver 3 konsumiert.
  • Da die Anwendungsserver 1 und 2 dem Warteschlangenmanager 2 nicht zugeordnet sind, können sie dessen Workload nicht übernehmen.
  • Da die Anwendungsserver 1, 2 und 3 zum selben Cluster von WebSphere Application Server gehören, wird die Workload, die nicht von IBM MQ stammt, weiterhin auf diese Anwendungsserver verteilt, selbst wenn die Anwendungsserver 1 und 2 IBM MQ nicht verwenden können, weil Warteschlangenmanager 1 ausgefallen ist.

Diese Netztopologie bietet zwar Verfügbarkeit und Skalierbarkeit, aber die Beziehung zwischen den Workloads verschiedener Warteschlangenmanager und den Anwendungsservern, denen sie zugeordnet sind, ist komplex. Expertenratschläge erhalten Sie von Ihrem IBM® Ansprechpartner.

Die Warteschlangenmanager werden auf denselben Hosts wie die Anwendungsserver ausgeführt

Erläuterung zur folgenden Abbildung:

  • Die Anwendungsserver 1, 2 und 3 gehören zum selben WAS-Cluster.
  • Die Anwendungsserver 1 und 3 werden auf Host 1 ausgeführt.
  • Der Anwendungsserver 2 wird auf Host 2 ausgeführt.
  • Die Warteschlangenmanager 1, 2 und 3 sind Teil desselben IBM MQ-Clusters.
  • Der Warteschlangenmanager 1 wird auf Host 1 ausgeführt.
  • Der Warteschlangenmanager 2 wird auf Host 2 ausgeführt.
  • Der Warteschlangenmanager 3 wird auf Host 3 ausgeführt.
  • Der Warteschlangenmanager 3 ist für die Verteilung der Nachrichten auf die Clusterwarteschlangen im Lastausgleichsverfahren verantwortlich.
  • Der Transporttyp für die Verbindung wird mit "Bindungen" angegeben. Eine Verbindung ist mit Bindungen angegeben, wenn der Anwendungsserver und der Warteschlangenmanager auf demselben Host ausgeführt werden. Dies ist eine speicherübergreifende Verbindung, die für die Kommunikation mit einem Warteschlangenmanager verwendet wird. Eine Verbindung vom Typ "Bindungen" wird auch als "Aufrufzuordnung" bezeichnet.
    • Die Anwendungsserver 1 und 3 stellen eine Verbindung zum Warteschlangenmanager 1 im Modus "Bindungen" her.
    • Der Anwendungsserver 2 stellt eine Verbindung zum Warteschlangenmanager 2 im Modus "Bindungen" her.
Abbildung 2. Clustering in WebSphere Application Server: Zuordnung im Modus "Bindungen" zu Warteschlangenmanagern
Die Anwendungsserver 1 und 3 werden auf Host 1 ausgeführt und stellen eine Verbindung zum Warteschlangenmanager 1 im Modus "Bindungen" her. Der Anwendungsserver 2 wird auf Host 2 ausgeführt und ist mit dem Warteschlangenmanager 2 im Modus "Bindungen" verbunden. Die Warteschlangenmanager 1, 2 und 3 sind Teil desselben IBM MQ-Clusters.Der Warteschlangenmanager 1 wird auf Host 1 ausgeführt, der Warteschlangenmanager 2 wird auf Host 2 ausgeführt, und der Warteschlangenmanager 3 wird auf Host 3 ausgeführt.
Wenn Anwendungsserver 1 ausfällt:
Der Anwendungsserver 3 kann die Workload des ausgefallenen Anwendungsservers übernehmen, weil beide dem Warteschlangenmanager 1 zugeordnet sind.
Wenn Anwendungsserver 3 ausfällt:
Der Anwendungsserver 1 kann die Workload des ausgefallenen Anwendungsservers übernehmen, weil beide dem Warteschlangenmanager 1 zugeordnet sind.
Wenn Anwendungsserver 2 ausfällt:
Sie müssen den Warteschlangenmanager aus folgenden Gründen so schnell wie möglich erneut starten:
  • Da Warteschlangenmanager 2 kein anderer Anwendungsserver zugeordnet ist, kann kein anderer Anwendungsserver seine IBM MQ-Workload übernehmen. Die vom Anwendungsserver 2 generierte Workload wird eingestellt. Andere Anwendungen im Cluster können jedoch seine externe Workload übernehmen.
  • Der Warteschlangenmanager 3 setzt die Verteilung von Anforderungen an Warteschlangenmanager 1 und Warteschlangenmanager 2 fort, selbst wenn die für Warteschlangenmanager 2 eingehende Workload von Anwendungsserver 2 nicht verarbeitet werden kann.
    Anmerkung: Wenn Sie sich entscheiden, keinen Neustart durchzuführen, können Sie in dieser Situation eine Entlastung erreichen, indem Sie die Warteschlange 1 im Warteschlangenmanager 2 so konfigurieren, dass die Möglichkeit, Nachrichten in die Warteschlange 1 einzureihen, unterbunden wird. Dies führt dazu, dass alle Nachrichten an den Warteschlangenmanager 1 gesendet werden, wo sie von den anderen Anwendungsservern verarbeitet werden.
Wenn Warteschlangenmanager 1 ausfällt:
Sie müssen den Warteschlangenmanager aus folgenden Gründen so schnell wie möglich erneut starten:
  • Wenn Warteschlangenmanager 1 ausfällt, werden die in ihm befindlichen Nachrichten so lange nicht verarbeitet, bis Sie Warteschlangenmanager 1 erneut starten.
  • Da die Anwendungsserver 1 und 3 keine Verbindung zu Warteschlangenmanager 2 herstellen, können sie dessen Workload nicht übernehmen.
  • Es werden keine neue Nachrichten von IBM MQ-Anwendungen an Warteschlangenmanager 1 gesendet. Stattdessen werden neue Nachrichten an Warteschlangenmanager 2 gesendet und von Anwendungsserver 2 konsumiert.
  • Da die Anwendungsserver 1, 2 und 3 zum selben Cluster von WebSphere Application Server gehören, wird die Workload, die nicht von IBM MQ stammt, weiterhin auf diese Anwendungsserver verteilt, selbst wenn die Anwendungsserver 1 und 3 IBM MQ nicht verwenden können, weil Warteschlangenmanager 1 ausgefallen ist.

Diese Netztopologie bietet zwar Verfügbarkeit und Skalierbarkeit, aber die Beziehung zwischen den Workloads verschiedener Warteschlangenmanager und den Anwendungsservern, denen sie zugeordnet sind, ist komplex. Expertenratschläge erhalten Sie von Ihrem IBM Ansprechpartner.


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_top02_clustered
Dateiname:cmm_mq_top02_clustered.html