WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

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

Gestalten Sie Ihr Brokernetz so, dass WebSphere MQ-Warteschlangen verwendet werden, wenn dies für Ihre Geschäftsanforderungen sinnvoll ist.

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

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:19:46


TaskthemaTaskthema | Version 8.0.0.5 | ac00365_