WebSphere MQ-Clusterwarteschlangen für Eingabe und Ausgabe verwenden

Bei der Gestaltung des WebSphere MQ-Netzwerkes, das Ihrer WebSphere Message Broker-Brokerdomäne zugrundeliegt, sollten Sie sich überlegen, ob Sie Cluster nutzen möchten.

Die Verwendung von Warteschlangenmanager-Clustern hat folgende wesentliche Vorteile:

  1. Reduzierte Systemverwaltung

    Cluster benötigen nicht so viele Definitionen für den Aufbau eines Netzwerkes. Sie können Ihr Netzwerk schneller und einfacher installieren.

  2. Verbesserte Verfügbarkeit und besserer Lastausgleich

    Wenn Instanzen derselben Warteschlange auf mehrere Warteschlangenmanager definiert werden, haben Sie den Vorteil, dass die Auslastung durch die Cluster verteilt wird.

Sie sollten folgende Punkte berücksichtigen, wenn Sie Cluster mit WebSphere Message Broker, verwenden:

Für SYSTEM.BROKER-Warteschlangen:
SYSTEM.BROKER-Warteschlangen werden bei der Erstellung von WebSphere Message Broker-Komponenten für Sie definiert, jedoch nicht als Clusterwarteschlangen. Sie sollten dieses Attribut nicht ändern.
Für Broker, Konfigurationsmanager- und Benutzernamensserver-Konnektivität:
Bei der Definition der Warteschlangenmanager, die Ihre Broker, den Konfigurationsmanager und den Benutzernamensserver zu einem Cluster unterstützen, können Sie von der vereinfachten Verwaltung der WebSphere MQ-Cluster profitieren. Dies kann bei Brokern in einem Brokerverbund von besonderer Bedeutung sein, die alle WebSphere MQ-Zwischenverbindungen haben müssen.
Für Nachrichtenfluss-Eingabewarteschlangen:
Wenn Sie eine Eingabewarteschlange als Clusterwarteschlange definieren, sollten Sie berücksichtigen, welche Auswirkungen dies auf die Reihenfolge der Nachrichten bzw. die Segmente einer segmentierten Nachrichten hat. Dies hat die gleichen Auswirkung wie für jede andere WebSphere MQ-Clusterwarteschlange. Insbesondere muss die Anwendung sicherstellen, dass beim Senden segmentierter Nachrichten alle Segmente von derselben Zielwarteschlange und somit von derselben Instanz des Nachrichtenflusses im gleichen Broker verarbeitet werden.
Für Nachrichtenfluss-Ausgabewarteschlangen:
  • WebSphere Message Broker definiert beim Öffnen einer Ausgabewarteschlange immer MQOO_BIND_AS_Q_DEF. Wenn Sie erwarten, dass segmentierte Nachrichten in eine Ausgabewarteschlange gestellt werden oder eine Serie von Nachrichten von derselben Verarbeitung behandelt werden soll, müssen Sie bei der Definition dieser Warteschlange DEFBIND(OPEN) angeben. Damit stellen Sie sicher, dass alle Segmente einer einzelnen Nachricht bzw. alle Nachrichten in einer Folge in dieselbe Zielwarteschlange eingereiht und von derselben Instanz der empfangenden Anwendung verarbeitet werden.
  • Wenn Sie Ihre eigenen Sendeknoten erstellen, müssen Sie beim Öffnen der Ausgabewarteschlange MQOO_BIND_AS_Q_DEF angeben und DEFBIND(OPEN), wenn Sie die Warteschlange definieren, die Reihenfolge der Nachrichten garantieren oder ein einzelnes Ziel für segmentierte Nachrichten sicherstellen möchten.
Für Publish/Subscribe:
  • Handelt es sich bei der Zielwarteschlange einer Veröffentlichung um eine Clusterwarteschlange, müssen Sie den Nachrichtenfluss des Publish/Subscribes in allen Brokern auf den Warteschlangenmanagern im Cluster implementieren. Ein Cluster stellt jedoch keine Failover-Funktionen für die Topologie und Funktionen der Brokerdomäne zur Verfügung. Wenn ein Broker, auf den eine Nachricht veröffentlicht wird bzw. bei dem sich ein Subskribent registriert, nicht verfügbar ist, wird die Verteilung der Veröffentlichung oder Registrierung nicht von einem 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
Nachrichtenfluss entwerfen
Gemeinsam genutzte Warteschlangen in WebSphere MQ für Eingabe und Ausgabe (z/OS) verwenden
Einen Nachrichtenfluss erstellen
Nachrichtenflussinhalt definieren
Zugehörige Verweise
Integrierte Knoten
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 18.05.2006
ac00365_