Überlegen Sie beim Entwerfen des
WebSphere MQ-Netzes, das
Ihrer
WebSphere Message Broker-Brokerdomäne zu Grunde liegt, ob Cluster verwendet
werden sollen.
Die Verwendung von Warteschlangenmanager-Clustern hat folgende wesentliche Vorteile:
- Geringerer Aufwand für Systemverwaltung
Cluster benötigen weniger Definitionen für den
Aufbau eines Netzes, d. h., Sie können Ihr Netz schneller und einfacher konfigurieren und ändern.
- Erhöhte Verfügbarkeit und verbesserter Lastausgleich
Sie können diesen Vorteil nutzen, indem
Sie Instanzen derselben Warteschlange für mehrere Warteschlangenmanager definieren, um die
Auslastung auf die Cluster zu verteilen.
Beachten Sie Folgendes, wenn Sie Cluster mit WebSphere Message Broker
verwenden:
- Für SYSTEM.BROKER-Warteschlangen:
- Die SYSTEM.BROKER-Warteschlangen werden automatisch definiert, wenn Sie
WebSphere Message Broker-Komponenten erstellen. Sie werden nicht als
Clusterwarteschlangen definiert. Lassen Sie dieses Attribut unverändert.
- Für Broker-, Konfigurationsmanager- und
Benutzernamensserver-Konnektivität:
- Wenn Sie die Warteschlangenmanager zur Unterstützung Ihrer Broker, des
Konfigurationsmanagers und des Benutzernamensservers für
einen Cluster definieren, können Sie von der vereinfachten Verwaltung, die von
WebSphere MQ-Clusters geboten wird, profitieren. Dies kann vor allem
für die Broker in einem Brokerverbund wichtig sein, die alle über
WebSphere MQ-Verbindungen verfügen müssen.
- Für Eingabewarteschlangen von Nachrichtenflüssen:
- Beachten Sie beim Definieren einer Eingabewarteschlange als Clusterwarteschlange die
Auswirkungen auf die Reihenfolge der Nachrichten bzw. der Segmente einer segmentierten Nachricht.
Es sind dieselben Auswirkungen wie für jede
WebSphere MQ-Clusterwarteschlange. Vor allem muss die Anwendung
sicherstellen, dass beim Senden segmentierter Nachrichten alle Segmente von derselben
Zielwarteschlange verarbeitet werden, d. h. von derselben Instanz des Nachrichtenflusses auf
demselben Broker.
- Für Ausgabewarteschlangen von Nachrichtenflüssen:
-
- WebSphere Message Broker gibt immer MQOO_BIND_AS_Q_DEF an, wenn es eine
Warteschlange für Ausgaben öffnet. Wenn Sie davon ausgehen, dass in eine Ausgabewarteschlange
segmentierte Nachrichten gestellt werden, oder wenn Sie möchten, dass eine Folge von Nachrichten
vom selben Prozess bearbeitet wird, müssen Sie beim Definieren dieser Warteschlange DEFBIND(OPEN)
angeben. Dadurch wird sichergestellt, dass alle Segmente einer einzelnen Nachricht bzw. alle
Nachrichten in einer Folge von Nachrichten in dieselbe Zielwarteschlange gestellt und von derselben
Instanz der empfangenden Anwendung verarbeitet werden.
- Wenn Sie eigene Sendeknoten erstellen, geben Sie QOO_BIND_AS_Q_DEF beim Öffnen der
Ausgabewarteschlange und DEFBIND(OPEN) beim Definieren der Warteschlange an, falls Sie die
Nachrichtenreihenfolge garantieren müssen oder um sicherzustellen, dass es für segmentierte
Nachrichten nur ein einziges Ziel gibt.
- Für Publish/Subscribe:
-
- Wenn es sich bei der Zielwarteschlange für eine Veröffentlichung um eine Clusterwarteschlange
handelt, müssen Sie den Publish/Subscribe-Nachrichtenfluss in allen
Brokern auf Warteschlangenmanagern im Cluster einsetzen. Der Cluster stellt jedoch keine der
Übernahmefunktionen für die Brokerdomänentopologie und -funktion zur Verfügung. Wenn ein
Broker, für den eine Nachricht veröffentlicht wird oder bei dem sich ein Subskribent registriert,
nicht verfügbar ist, wird die Verteilung der Veröffentlichung bzw. die Registrierung von keinem
anderen Broker übernommen.
- Wenn ein Client eine Subskription bei einem Broker registriert, der
auf einem Warteschlangenmanager aktiv ist, der Mitglied eines Clusters ist,
übersendet der Broker eine Proxy-Registrierung an seine Nachbarstationen
innerhalb der Brokerdomäne. Die Details der Registrierung werden dabei
nicht für andere Mitglieder des Clusters zugänglich gemacht.
- Ein Client kann zu einem in Gruppen zusammengefassten Subskribenten werden, so dass seine Subskribentenwarteschlange eine aus einer Gruppe von in Gruppen zusammengefassten Warteschlangen ist, die jede gegebene Publikation empfangen. In diesem Fall sollten Sie beim Registrieren einer Subskription den Namen eines "imaginären" Warteschlangenmanagers verwenden, der dem Cluster zugeordnet ist; dabei sollte es sich nicht um den Warteschlangenmanager handeln, an den die Publikation gesendet wird, sondern um einen Aliasnamen, den der Broker verwendet. Als administrative Aktion wird für diesen Warteschlangenmanager eine leere Definition für einen Warteschlangenmanager-Aliasnamen in dem Broker erstellt, der diese Subskription für alle in Gruppen zusammengefassten Subskribenten erfüllt. Wenn der Broker in einer Warteschlange für Teilnehmerberechtigungen veröffentlicht, die diesen Warteschlangenmanager namentlich nennt, führt die Auflösung des WS-Managernamens dazu, dass die Veröffentlichung an einen Warteschlangenmanager gesendet wird, der als Host für die Subskribent-Clusterwarteschlange fungiert, und dass nur ein in Gruppen zusammengefasster Subskribent die Veröffentlichung empfängt.
Beispiel: Wenn die Warteschlange des in Gruppen zusammengefassten Subskribenten SUBS_QUEUE und der "imaginäre" Subskribent-Warteschlangenmanager CLUSTER_QM heißen,
lautet die Brokerdefinition wie folgt:
DEFINE QREMOTE(CLUSTER_QM)
RQMNAME(' ') RNAME(' ')
Diese Definition sendet Brokerveröffentlichungen für SUBS_QUEUE in CLUSTER_QM an eine Instanz der Clusterwarteschlange SUBS_QUEUE an einem beliebigen Standort im Cluster.
Weitere Informationen zu Clustern und den Auswirkungen von Clusterwarteschlangen finden Sie Handbuch WebSphere MQ Queue
Manager Clusters.