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.
- 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.

- 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.

- 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.