Cluster und Cluster-Übertragungswarteschlange hinzufügen, um den Datenverkehr der Clusternachrichten zu isolieren, die von einem Gateway-Warteschlangenmanager gesendet werden

Ändern Sie die Konfiguration von überlappenden Clustern, die einen Gateway-Warteschlangenmanager verwenden. Nachdem die Änderungsnachrichten von dem Gateway-Warteschlangenmanager an eine Anwendung übertragen wurden, ohne dieselbe Übertragungswarteschlange oder Kanäle wie andere Clusternachrichten zu verwenden. Die Lösung verwendet einen zusätzlichen Cluster, um die Nachrichten auf eine bestimmte Clusterwarteschlange zu isolieren.

Vorbereitungen

Die Schritte in der Task werden geschrieben, um die in Abbildung 1dargestellte Konfiguration zu ändern.

  1. Der Gateway-Warteschlangenmanager muss sich unter IBM® MQbefinden.
  2. Erstellen Sie die überlappenden Cluster, die in Client-Server-Anwendung in Hub-and-Spoke-Architektur unter Verwendung von IBM MQ in Erstellen von zwei überlappenden Clustern mit einem Gateway-Warteschlangenmanager gezeigt werden, indem Sie die Schritte in dieser Aufgabe ausführen.
  3. Führen Sie die Schritte in Abbildung 1 unter Hinzufügen einer Cluster-Sendewarteschlange zum Isolieren des von einem Gateway-Warteschlangenmanager gesendeten Clusternachrichtenverkehrs aus, um die Lösung ohne den zusätzlichen Cluster zu erstellen. Verwenden Sie diese Option als Basis für die Schritte in dieser Task.

Informationen zu dieser Task

Die Lösung zum Isolieren des Nachrichtenverkehrs für eine einzelne Anwendung unter Clusterübertragungswarteschlange hinzufügen, um den Clusternachrichtenverkehr von einem Gateway-Warteschlangenmanager zu isolieren funktioniert, wenn die Zielclusterwarteschlange die einzige Clusterwarteschlange auf einem Warteschlangenmanager ist. Wenn dies nicht der Fall ist, haben Sie zwei Möglichkeiten. Verschieben Sie die Warteschlange entweder in einen anderen Warteschlangenmanager oder erstellen Sie einen Cluster, der die Warteschlange aus anderen Clusterwarteschlangen auf dem Warteschlangenmanager isoliert.

Diese Task führt Sie durch die Schritte zum Hinzufügen eines Clusters zum Isolieren der Zielwarteschlange. Der Cluster wird zu diesem Zweck hinzugefügt. In der Praxis ist es die Aufgabe, bestimmte Anwendungen systematisch zu isolieren, wenn Sie Cluster-und Clusterbenennungsschemata entwerfen. Wenn Sie einen Cluster jedes Mal hinzufügen, wenn eine Warteschlange isoliert wird, kann die Isolation möglicherweise mit vielen Clustern enden. In dieser Task ändern Sie die Konfiguration unter Clusterübertragungswarteschlange zum Isolieren des Clusternachrichtenverkehrs hinzufügen, der von einem Gateway-Warteschlangenmanager gesendet wird , indem Sie einen Cluster hinzufügen CL3 , um Q1 unter QM3zu isolieren. Anwendungen werden während der gesamten Änderung weiterhin ausgeführt.

Die neuen und geänderten Definitionen sind in Abbildung 1hervorgehoben. Die Zusammenfassung der Änderungen lautet wie folgt: Erstellen Sie einen Cluster. Dies bedeutet, dass Sie auch ein neues vollständiges Clusterrepository erstellen müssen. Im Beispiel wird QM3 zu einem der vollständigen Repositorys für CL3 gemacht. Erstellen Sie Clustersenderkanäle und Clusterempfängerkanäle für QM1 , um den Gateway-WS-Manager dem neuen Cluster hinzuzufügen. Ändern Sie die Definition von Q1 , um sie in CL3 zu wechseln. Ändern Sie die Clusternamensliste auf dem Gateway-Warteschlangenmanager, und fügen Sie eine Clusterübertragungswarteschlange hinzu, um den neuen Clusterkanal zu verwenden. Schalten Sie schließlich den Warteschlangenalias Q1A in die neue Clusternamensliste ein.

IBM MQ kann keine Nachrichten aus der Übertragungswarteschlange XMITQ.CL2.QM3 , die Sie in Clusterübertragungswarteschlange zum Isolieren des Clusternachrichtenverkehrs hinzufügen, der von einem Gateway-Warteschlangenmanager gesendet wird zur neuen Übertragungswarteschlange XMITQ.CL3.QM3hinzugefügt haben, automatisch übertragen. Es kann Nachrichten nur dann automatisch übertragen, wenn beide Übertragungswarteschlangen vom selben Clustersenderkanal bedient werden. Stattdessen beschreibt die Task eine Möglichkeit, den Switch manuell auszuführen. Dies kann für Sie geeignet sein. Wenn die Übertragung abgeschlossen ist, haben Sie die Möglichkeit, die Standard-Clusterübertragungswarteschlange für andere CL2 -Clusterwarteschlangen unter QM3 zu verwenden. Oder Sie können XMITQ.CL2.QM3 weiterhin verwenden. Wenn Sie sich dafür entscheiden, auf eine Standard-Cluster-Übertragungswarteschlange zurückzusetzen, verwaltet der Gateway-Warteschlangenmanager den Switch automatisch für Sie.

Abb. 1. Verwenden eines zusätzlichen Clusters zum Trennen des Nachrichtenverkehrs im Gateway-Warteschlangenmanager, der zu einer Anzahl von Clusterwarteschlangen auf demselben Warteschlangenmanager wechselt
Das Diagramm zeigt drei überlappende Cluster, die durch einen Gateway-Warteschlangenmanager verbunden sind. Eine Nachricht fließt aus einer Anwendung in einem Cluster in den anderen Cluster über die Übertragungswarteschlange XMITQ.CL3.QM3 im Gateway-Warteschlangenmanager. Die
Nachricht wird von einer Aliaswarteschlange im Gateway-Warteschlangenmanager weitergeleitet. Die Aliaswarteschlange t ist in allen Clustern gruppiert. Es richtet sich an eine Warteschlange in CL3. Warteschlangenmanager-Aliasnamen im Gateway-Warteschlangenmanager verweisen auf die realen Warteschlangenmanager in jedem Cluster.

Verfahren

  1. Ändern Sie die Warteschlangenmanager QM3 und QM5 , um sie zu Repositorys für CL2 und CL3zu machen.

    Um einen Warteschlangenmanager zu einem Member mehrerer Cluster zu machen, muss er eine Clusternamensliste verwenden, um die Cluster zu identifizieren, zu der er gehört.

    *... On QM3 and QM5
    DEFINE NAMELIST(CL23) NAMES(CL2, CL3) REPLACE
    ALTER QMGR REPOS(' ') REPOSNL(CL23)
    
  2. Definieren Sie die Kanäle zwischen den Warteschlangenmanagern QM3 und QM5 für CL3.
    *... On QM3
    DEFINE CHANNEL(CL3.QM5) CHLTYPE(CLUSSDR) CONNAME('localhost(1415)') CLUSTER(CL3) REPLACE
    DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSRCVR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE
    
    *... On QM5
    DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSSDR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE
    DEFINE CHANNEL(CL3.QM5) CHLTYPE(CLUSRCVR) CONNAME('localhost(1415)') CLUSTER(CL3) REPLACE
    
  3. Fügen Sie den Gateway-Warteschlangenmanager zu CL3hinzu.

    Fügen Sie den Gateway-WS-Manager hinzu, indem Sie QM1 als Teilrepository zu CL3 hinzufügen. Erstellen Sie ein Teilrepository, indem Sie Clustersenderkanäle und Clusterempfängerkanäle zu QM1 hinzufügen.

    Fügen Sie außerdem CL3 zur Namensliste aller Cluster hinzu, die mit dem Gateway-WS-Manager verbunden sind.

    *... On QM1
    DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSSDR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE
    DEFINE CHANNEL(CL3.QM1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1411)') CLUSTER(CL3) REPLACE
    ALTER NAMELIST(ALL) NAMES(CL1, CL2, CL3)
    
  4. Fügen Sie eine Clusterübertragungswarteschlange für Nachrichten an CL3 unter QM3zum Gateway-Warteschlangenmanager QM1hinzu.

    Stoppen Sie zunächst den Clustersenderkanal, der Nachrichten aus der Übertragungswarteschlange überträgt, bis Sie bereit sind, Übertragungswarteschlangen zu wechseln.

    *... On QM1
    DEFINE QLOCAL(XMITQ.CL3.QM3) USAGE(XMITQ) CLCHNAME(CL3.QM3) GET(DISABLED) REPLACE
    
  5. Nachrichten aus der vorhandenen Clusterübertragungswarteschlange bereinigen XMITQ.CL2.QM3.

    Diese Unterprozedur dient dazu, die Reihenfolge der Nachrichten in Q1 beizubehalten, damit sie mit der Reihenfolge übereinstimmt, in der sie im Gateway-Warteschlangenmanager angekommen sind. Bei Clustern ist die Nachrichtenreihenfolge nicht vollständig gewährleistet, ist aber wahrscheinlich. Wenn eine garantierte Nachrichtenreihenfolge erforderlich ist, müssen Anwendungen die Reihenfolge der Nachrichten definieren; siehe Die Reihenfolge, in der Nachrichten aus einer Warteschlange abgerufen werden.

    1. Ändern Sie die Zielwarteschlange Q1 unter QM3 von CL2 in CL3.
      *... On QM3
      ALTER QLOCAL(Q1) CLUSTER(CL3)
      
    2. Überwachen Sie XMITQ.CL3.QM3 , bis Nachrichten zugestellt werden.

      Die Zustellung von Nachrichten an XMITQ.CL3.QM3 wird gestartet, wenn der Wechsel von Q1 in CL3 an den Gateway-Warteschlangenmanager weitergegeben wird.

      *... On QM1
      DISPLAY QUEUE(XMITQ.CL3.QM3) CURDEPTH
      
    3. Überwachen Sie XMITQ.CL2.QM3 , bis keine Nachrichten mehr an Q1 unter QM3zugestellt werden.
      Hinweis: XMITQ.CL2.QM3 speichert möglicherweise Nachrichten für andere Warteschlangen unter QM3 , die Member von CL2sind. In diesem Fall wird die Länge möglicherweise nicht auf null gesetzt.
      *... On QM1
      DISPLAY QUEUE(XMITQ.CL2.QM3) CURDEPTH
      
    4. Abrufen aus der neuen Clusterübertragungswarteschlange aktivieren, XMITQ.CL3.QM3
      *... On QM1
      ALTER QLOCAL(XMITQ.CL3.QM3) GET(ENABLED)
      
  6. Entfernen Sie die alte Clusterübertragungswarteschlange XMITQ.CL2.QM3, wenn sie nicht länger erforderlich ist.

    Nachrichten für Clusterwarteschlangen in CL2 auf QM3 werden auf die Verwendung der Standard-Cluster-Übertragungswarteschlange auf dem Gateway-WS-Manager QM1 zurückgesetzt. Die Standard-Cluster-Übertragungswarteschlange ist entweder SYSTEM.CLUSTER.TRANSMIT.QUEUE oder SYSTEM.CLUSTER.TRANSMIT.CL2.QM3. Welche davon abhängt, ob der Wert des Warteschlangenmanagerattributs DEFCLXQ in QM1 SCTQ oder CHANNEL ist. Der Warteschlangenmanager überträgt Nachrichten automatisch von XMITQ.CL2.QM3 , wenn der Clustersenderkanal CL2.QM3 als Nächstes gestartet wird.

    1. Ändern Sie die Übertragungswarteschlange XMITQ.CL2.QM3von einer Clusterübertragungswarteschlange in eine normale Übertragungswarteschlange.

      Dadurch wird die Zuordnung der Übertragungswarteschlange zu beliebigen Clustersenderkanälen unterbrochen. Als Antwort überträgt IBM MQ automatisch Nachrichten von XMITQ.CL2.QM3 an die Standardclusterübertragungswarteschlange, wenn der Clustersenderkanal als Nächstes gestartet wird. Bis dahin werden die Nachrichten für CL2 unter QM3 weiterhin auf XMITQ.CL2.QM3 gesetzt.

      *... On QM1
      ALTER QLOCAL(XMITQ.CL2.QM3) CLCHNAME(' ')
      
    2. Stoppen Sie den Clustersenderkanal CL2.QM3.

      Wenn Sie den Clustersenderkanal stoppen und erneut starten, wird die Übertragung von Nachrichten von XMITQ.CL2.QM3 in die Standardübertragungswarteschlange des Clusters eingeleitet. In der Regel müssen Sie den Kanal manuell stoppen und starten, um die Übertragung zu starten. Die Übertragung wird automatisch gestartet, wenn der Kanal nach dem Abschließen des Unterbrechungsintervalls erneut gestartet wird.

      *... On QM1
      STOP CHANNEL(CL2.QM3)
      

      Die Antwort ist, dass der Befehl akzeptiert wird:


      AMQ8019: Stop IBM MQ channel accepted.
    3. Überprüfen, ob der Kanal CL2.QM3 gestoppt wurde

      Wenn der Kanal nicht gestoppt wird, können Sie den Befehl STOP CHANNEL erneut mit der Option FORCE ausführen. Ein Beispiel für die Einstellung der Option FORCE wäre, wenn der Kanal nicht gestoppt wird, und Sie können den anderen Warteschlangenmanager nicht erneut starten, um den Kanal zu synchronisieren.

      *... On QM1
      DISPLAY CHSTATUS(CL2.QM3)
      

      Die Antwort ist eine Zusammenfassung des Kanalstatus.


      AMQ8417: Display Channel Status details.
      CHANNEL(CL2.QM3)                        CHLTYPE(CLUSSDR)
      CONNAME(127.0.0.1(1413))                CURRENT
      RQMNAME(QM3)                            STATUS(STOPPED)
      SUBSTATE(MQGET)                         XMITQ(XMITQ.CL2.QM3)

    4. Starten Sie den Kanal CL2.QM3.
      *... On QM1
      START CHANNEL(CL2.QM3)
      

      Die Antwort ist, dass der Befehl akzeptiert wird:


      AMQ8018: Start IBM MQ channel accepted.
    5. Überprüfen Sie, ob der Kanal gestartet wurde
      *... On QM1
      DISPLAY CHSTATUS(CL2.QM3)
      

      Die Antwort ist eine Zusammenfassung des Kanalstatus:

      AMQ8417: Display Channel Status details.
      CHANNEL(CL2.QM3)      CHLTYPE(CLUSSDR)
      CONNAME(127.0.0.1(1413))  CURRENT
      RQMNAME(QM3)        STATUS(RUNNING)
      SUBSTATE(MQGET)      XMITQ(SYSTEM.CLUSTER.TRANSMIT. QUEUE|CL2.QM3)
      
    6. Überwachen Sie das Fehlerprotokoll des Gateway-Warteschlangenmanagers auf die Nachricht AMQ7341The transmission queue for channel CL2.QM3 is SYSTEM.CLUSTER.TRANSMIT. QUEUE|CL2.QM3 .
    7. Löschen Sie die Clusterübertragungswarteschlange XMITQ.CL2.QM3.
      *... On QM1
      DELETE QLOCAL(XMITQ.CL2.QM3)
      

Nächste Schritte

Testen Sie die separate Clusterwarteschlange, indem Sie eine Nachricht von QM2 an Q1 auf QM3 unter Verwendung der Warteschlangenaliasdefinition Q1A senden.

  1. Führen Sie das Beispielprogramm amqsput unter QM2 aus, um eine Nachricht einzureihen.

    C:\IBM\MQ>amqsput Q1A QM2
    Sample AMQSPUT0 start
    target queue is Q1A
    Sample request message from QM2 to Q1 using Q1A

    Sample AMQSPUT0 end

  2. Führen Sie das Beispielprogramm amqsget aus, um die Nachricht von Q1 unter QM3 abzurufen

    C:\IBM\MQ>amqsget Q1 QM3
    Sample AMQSGET0 start
    message <Sample request message from QM2 to Q1 using Q1A>
    no more messages
    Sample AMQSGET0 end