WebSphere MQ-Clusterwarteschlangen für Ein- und Ausgabe verwenden

Ü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:

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

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

Zugehörige Konzepte
Nachrichtenflüsse - Übersicht
Zugehörige Tasks
Einen Nachrichtenfluss entwerfen
Gemeinsam genutzte WebSphere MQ-Warteschlangen für die Ein- und Ausgabe verwenden (z/OS)
Nachrichtenflüsse erstellen
Nachrichtenflussinhalte definieren
Zugehörige Verweise
Integrierte Knoten
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac00365_