Hinzufügen eines Warteschlangenmanagers, der eine Warteschlange enthält

Fügen Sie einen weiteren WS-Manager zum Cluster hinzu, um eine weitere INVENTQ -Warteschlange zu hosten. Anforderungen werden abwechselnd an die Warteschlangen in den einzelnen Warteschlangenmanagern gesendet. Es müssen keine Änderungen an dem vorhandenen INVENTQ -Host vorgenommen werden.

Vorbereitungen

Hinweis: Damit Änderungen an einem Cluster im gesamten Cluster weitergegeben werden können, muss mindestens ein vollständiges Repository verfügbar sein. Stellen Sie sicher, dass Ihre Repositorys verfügbar sind, bevor Sie diese Task starten.
Szenario:
  • Der INVENTORY Cluster wurde wie in Hinzufügen eines Warteschlangenmanagers zu einem Cluster beschrieben eingerichtet. Es enthält drei Warteschlangenmanager; LONDON und NEWYORK enthalten beide vollständige Repositorys, PARIS enthält ein Teilrepository. Die Bestandsanwendung wird auf dem System in New York ausgeführt und ist mit dem NEWYORK -Warteschlangenmanager verbunden. Die Anwendung wird durch den Eingang von Nachrichten in der INVENTQ -Warteschlange gesteuert.
  • In Toronto wird ein neues Geschäft aufgebaut. Um zusätzliche Kapazitäten bereitzustellen, möchten Sie die Inventaranwendung auf dem System in Toronto sowie in New York ausführen.
  • Die Netzkonnektivität besteht zwischen allen vier Systemen.
  • Das Netzprotokoll ist TCP.
Hinweis: Der Warteschlangenmanager TORONTO enthält nur ein Teilrepository. Wenn Sie einen Full-Repository-Warteschlangenmanager zu einem Cluster hinzufügen möchten, lesen Sie den Abschnitt Verschieben eines Full-Repository zu einem anderen Warteschlangenmanager.

Informationen zu dieser Task

Führen Sie die folgenden Schritte aus, um einen WS-Manager hinzuzufügen, der eine Warteschlange enthält.

Verfahren

  1. Entscheiden Sie, auf welches vollständige Repository TORONTO zuerst verweist.

    Jeder WS-Manager in einem Cluster muss sich auf einen oder einen anderen der vollständigen Repositorys beziehen. Es sammelt Informationen über den Cluster aus einem vollständigen Repository und erstellt so ein eigenes Teilrepository. Es ist nicht besonders wichtig, welches Repository Sie auswählen. In diesem Beispiel wählen Sie NEWYORK aus. Sobald der neue WS-Manager dem Cluster beigetreten ist, kommuniziert er mit beiden Repositorys.

  2. Definieren Sie den Kanal CLUSRCVR .
    Jeder WS-Manager in einem Cluster muss einen Clusterempfängerkanal definieren, auf dem er Nachrichten empfangen kann. Definieren Sie unter TORONTO einen CLUSRCVR -Kanal:
    DEFINE CHANNEL(INVENTORY.TORONTO) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(TORONTO.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-receiver channel for TORONTO')

    Der TORONTO -Warteschlangenmanager macht seine Verfügbarkeit für den Empfang von Nachrichten von anderen WS-Managern im INVENTORY -Cluster mit Hilfe seines Clusterempfängerkanals bekannt.

  3. Definieren Sie einen CLUSSDR -Kanal auf Warteschlangenmanager TORONTO.
    Jeder Warteschlangenmanager in einem Cluster muss einen Clustersenderkanal definieren, auf dem er Nachrichten an sein erstes vollständiges Repository senden kann. Wählen Sie in diesem Fall NEWYORK aus. TORONTO benötigt die folgende Definition:
    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-sender channel from TORONTO to repository at NEWYORK')
  4. Optional: Falls Sie einem Cluster einen Warteschlangenmanager hinzufügen, der zuvor aus demselben Cluster entfernt wurde, überprüfen Sie, ob er jetzt als Cluster-Member angezeigt wird. Ist dies nicht der Fall, führen Sie die folgenden zusätzlichen Schritte aus:
    1. Geben Sie den Befehl REFRESH CLUSTER auf dem Warteschlangenmanager aus, den Sie hinzufügen.
      Dieser Schritt stoppt die Clusterkanäle und gibt Ihrem lokalen Clustercache eine neue Gruppe von Folgenummern, die sichergestellt werden, dass sie im Rest des Clusters für das Up-to-Datum konfiguriert werden.
      REFRESH CLUSTER(INVENTORY) REPOS(YES)
      Hinweis: Bei großen Clustern kann die Verwendung des Befehls REFRESH CLUSTER zu Unterbrechungen des Clusters führen, während er in Bearbeitung ist, und danach in 27-Tage-Intervallen, wenn die Clusterobjekte automatisch Statusaktualisierungen an alle interessierten Warteschlangenmanager senden. Siehe Aktualisierung in einem großen Cluster kann sich auf die Leistung und Verfügbarkeit des Clusters auswirken.
    2. Starten Sie den CLUSSDR-Kanal erneut.
      (z. B. mit dem Befehl START CHANNEL )
    3. Starten Sie den CLUSRCVR-Kanal erneut.
  5. Überprüfen Sie die Bestandsanwendung auf Nachrichtenaffinitäten.

    Bevor Sie fortfahren, stellen Sie sicher, dass die Inventaranwendung keine Abhängigkeiten von der Reihenfolge der Verarbeitung von Nachrichten hat und die Anwendung auf dem System in Toronto installiert.

  6. Definieren Sie die Clusterwarteschlange INVENTQ.
    Die INVENTQ -Warteschlange, die bereits vom NEWYORK -Warteschlangenmanager gehostet wird, befindet sich ebenfalls in TORONTO. Definieren Sie sie auf dem TORONTO -Warteschlangenmanager wie folgt:
    DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)

Ergebnisse

Abbildung 1 zeigt den INVENTORY -Cluster, der von dieser Task eingerichtet wurde.
Abb. 1. Der INVENTORY -Cluster mit vier Warteschlangenmanagern
Das Diagramm zeigt den Cluster INVENTORY mit den vier verbundenen Warteschlangenmanagern TORONTO, LONDON, NEW YORK und PARIS. INVENTQ wird sowohl auf NEW YORK als auch auf TORONTO gehostet. Die Inventaranwendung wird in NEW YORK und LONDON gehostet.

Die INVENTQ -Warteschlange und die Inventaranwendung werden jetzt auf zwei Warteschlangenmanagern im Cluster gehostet. Dies erhöht die Verfügbarkeit, beschleunigt den Durchsatz von Nachrichten und ermöglicht die Verteilung der Auslastung zwischen den beiden Warteschlangenmanagern. Nachrichten, die entweder von TORONTO oder NEWYORK an INVENTQ gestellt werden, werden, wenn möglich, von der Instanz auf dem lokalen WS-Manager bearbeitet. Nachrichten, die von LONDON oder PARIS gestellt werden, werden abwechselnd an TORONTO oder NEWYORK weitergeleitet, so dass die Auslastung ausgeglichen ist.

Diese Änderung am Cluster wurde ausgeführt, ohne dass die Definitionen in den Warteschlangenmanagern NEWYORK, LONDON und PARIS geändert werden müssen. Die vollständigen Repositorys in diesen Warteschlangenmanagern werden automatisch mit den Informationen aktualisiert, die sie benötigen, um Nachrichten an INVENTQ in TORONTO senden zu können. Die Inventaranwendung funktioniert weiterhin, wenn einer der NEWYORK oder der WS-Manager von TORONTO nicht mehr verfügbar ist und die Kapazität ausreicht. Die Bestandsanwendung muss in der Lage sein, ordnungsgemäß zu arbeiten, wenn sie an beiden Standorten gehostet wird.

Wie Sie im Ergebnis dieser Task sehen können, können Sie dieselbe Anwendung in mehr als einem Warteschlangenmanager ausführen. Sie können das Clustering gleichmäßig auf die Verteilungsauslastung verteilen.

Eine Anwendung ist möglicherweise nicht in der Lage, Datensätze an beiden Standorten zu verarbeiten. Angenommen, Sie möchten eine Abfrage zum Kunden-Account hinzufügen und die Anwendung, die in LONDON und NEWYORK ausgeführt wird, hinzufügen. Ein Accountendatensatz kann nur an einem Ort gehalten werden. Sie können die Verteilung von Anforderungen mit Hilfe eines Datenpartitionierungsverfahrens steuern. Sie können die Verteilung der Datensätze aufteilen. Sie können die Hälfte der Datensätze anordnen, z. B. für die Kontonummern 00000-49999, die in LONDON gehalten werden sollen. Die andere Hälfte (im Bereich 50000-99999 ) wird in NEWYORK gehalten. Anschließend können Sie ein Exitprogramm für die Clusterauslastung schreiben, um das Accountfeld in allen Nachrichten zu untersuchen und die Nachrichten an den entsprechenden Warteschlangenmanager weiterzuleiten.

Nächste Schritte

[z/OS]Nachdem Sie nun alle Definitionen abgeschlossen haben, starten Sie, falls noch nicht geschehen, den Kanalinitiator auf IBM® MQ for z/OS®.

Starten Sie auf allen Plattformen ein Listenerprogramm auf dem Warteschlangenmanager TORONTO. Das Listenerprogramm wartet auf eingehende Netzanforderungen und startet den Clusterempfängerkanal, wenn er benötigt wird.