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 und so die
Auslastung auf die Cluster verteilen.
Ziehen Sie folgende Warteschlangen in
Betracht, 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 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. Diese Option stellt sicher, 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 sicherstellen müssen oder um sicherzustellen, dass es für segmentierte
Nachrichten nur ein einziges Ziel gibt.
- Für Publish/Subscribe-Anwendungen:
-
- 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 das Brokernetz und die Brokerfunktion 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
auf einem Warteschlangenmanager registriert, 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 Subskribenten innerhalb eines Clusters werden, sodass seine Subskribentenwarteschlange zu einem Cluster von Warteschlangen gehört, die eine bestimmte 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 Cluster-Subskribenten SUBS_QUEUE und der "imaginäre" Warteschlangenmanager für Subskribenten CLUSTER_QM heißen,
lautet die Brokerdefinition wie folgt:
DEFINE QREMOTE(CLUSTER_QM) RQMNAME(' ')
RNAME(' ')
Diese Konfiguration sendet Brokerveröffentlichungen für SUBS_QUEUE im
CLUSTER_QM an eine Instanz der Clusterwarteschlange SUBS_QUEUE an einem beliebigen Standort im
Cluster.
Weitere Informationen zu Clustern und den
Auswirkungen der Verwendung von Clusterwarteschlangen finden Sie im Abschnitt Queue Manager
Clusters im WebSphere MQ Version 7 Information Center
online.