Clustering: Anwendungsisolation mit mehreren Clusterübertragungswarteschlangen

Sie können die Nachrichtenflüsse zwischen Warteschlangenmanagern in einem Cluster isolieren. Sie können Nachrichten, die von verschiedenen Clustersenderkanälen transportiert werden, in verschiedene Clusterübertragungswarteschlangen stellen. Sie können den Ansatz in einem einzelnen Cluster oder mit überlappenden Clustern verwenden. Das Thema enthält Beispiele und einige bewährte Verfahren, die Sie bei der Auswahl eines zu verwendenden Ansatzes führen.

Wenn Sie eine Anwendung implementieren, haben Sie die Wahl, welche IBM® MQ -Ressourcen sie mit anderen Anwendungen gemeinsam nutzt und welche Ressourcen sie nicht gemeinsam nutzt. Es gibt eine Reihe von Typen von Ressourcen, die gemeinsam genutzt werden können, wobei die Haupttypen der Server selbst, der Warteschlangenmanager, die Kanäle und die Warteschlangen sind. Sie können Anwendungen mit weniger gemeinsam genutzten Ressourcen konfigurieren. Sie können separate Warteschlangen, Kanäle, Warteschlangenmanager oder sogar Server für einzelne Anwendungen zuordnen. Wenn Sie dies tun, wird die Gesamtsystemkonfiguration größer und komplexer. Die Verwendung von IBM MQ-Clustern reduziert die Komplexität der Verwaltung von mehr Servern, Warteschlangenmanagern, Warteschlangen und Kanälen, führt aber eine weitere gemeinsam genutzte Ressource ein, die Cluster-Übertragungswarteschlange SYSTEM.CLUSTER.TRANSMIT.QUEUE.

Abbildung 1 ist ein Ausschnitt aus einer umfangreichen IBM MQ -Bereitstellung, der die Bedeutung der gemeinsamen Nutzung von SYSTEM.CLUSTER.TRANSMIT.QUEUEveranschaulicht. Im Diagramm ist die Anwendung Client App mit dem Warteschlangenmanager QM2 im Cluster CL1 verbunden. Eine Nachricht von Client App wird von der Anwendung Server App verarbeitet. Die Nachricht wird von Server App aus der Clusterwarteschlange Q1 auf dem Warteschlangenmanager QM3 in CLUSTER2abgerufen. Da sich die Client- und Serveranwendungen nicht in demselben Cluster befinden, wird die Nachricht vom Gateway-Warteschlangenmanager QM1 übertragen.

Der normale Weg zur Konfiguration eines Cluster-Gateways besteht darin, den Gateway-Warteschlangenmanager zu einem Mitglied aller Cluster zu machen. Auf dem Gateway-WS-Manager werden Clusteraliasnamen für Clusterwarteschlangen in allen Clustern definiert. Die Aliasnamen für Clusterwarteschlangen sind in allen Clustern verfügbar. Nachrichten, die an die Clusterwarteschlangenaliasnamen gestellt werden, werden über den Gateway-Warteschlangenmanager an ihr korrektes Ziel weitergeleitet. Der Gateway-Warteschlangenmanager reiht Nachrichten, die an die Aliase der Clusterwarteschlangen gesendet werden, in die allgemeine SYSTEM.CLUSTER.TRANSMIT.QUEUE unter QM1 ein.

Die Hub-und Spoke-Architektur erfordert alle Nachrichten zwischen Clustern, die über den Gateway-Warteschlangenmanager übergeben werden. Das Ergebnis ist, dass alle Nachrichten durch die Warteschlange des einzelnen Clusters auf QM1, SYSTEM.CLUSTER.TRANSMIT.QUEUE fließen.

Aus einer Leistungsperspektive ist eine einzelne Warteschlange kein Problem. Eine allgemeine Übertragungswarteschlange stellt in der Regel keinen Leistungsengpass dar. Der Nachrichtendurchsatz auf dem Gateway wird weitgehend durch die Leistung der Kanäle bestimmt, die eine Verbindung zu ihm herstellen. Der Durchsatz wird in der Regel nicht von der Anzahl der Warteschlangen oder der Anzahl der Nachrichten in den Warteschlangen, die die Kanäle verwenden, beeinflusst.

Aus einigen anderen Perspektiven hat die Verwendung einer einzelnen Übertragungswarteschlange für mehrere Anwendungen Nachteile:
  • Sie können den Fluss von Nachrichten nicht in ein Ziel vom Nachrichtenfluss zu einem anderen Ziel eingrenzen. Sie können die Speicherung von Nachrichten nicht trennen, bevor sie weitergeleitet werden, selbst wenn sich die Ziele in verschiedenen Clustern auf verschiedenen Warteschlangenmanagern befinden.

    Wenn eine Cluster-Destination nicht mehr verfügbar ist, werden Nachrichten für diese Zieladresse in der einzelnen Übertragungswarteschlange, und schließlich füllen sie die Nachrichten aus. Sobald die Übertragungswarteschlange voll ist, stoppt sie Nachrichten, die in die Übertragungswarteschlange für ein beliebtes Clusterziel gestellt werden.

  • Es ist nicht einfach, die Übertragung von Nachrichten an verschiedene Cluster-Destinations zu überwachen. Alle Nachrichten befinden sich in der einzelnen Übertragungswarteschlange. Wenn Sie die Länge der Übertragungswarteschlange anzeigen, wird wenig darüber informiert, ob Nachrichten an alle Zieladressen übertragen werden.
Abb. 1. In Hub-und Peripheriearchitektur implementierte Client-Server-Anwendung unter Verwendung von IBM MQ -Clustern
Das Diagramm zeigt zwei ü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 SYSTEM.CLUSTER.TRANSMIT.QUEUE im Gateway-Warteschlangenmanager. Die Nachricht wird von einer Aliaswarteschlange im Gateway-Warteschlangenmanager weitergeleitet. Die Definition der Aliaswarteschlange ist in allen Clustern gruppiert. Sie richtet sich an eine Warteschlange in einem der Cluster. Warteschlangenmanager-Aliasnamen im Gateway-Warteschlangenmanager verweisen auf die realen Warteschlangenmanager in jedem Cluster.
Hinweis Die Pfeile in Abbildung 1 und den folgenden Abbildungen haben unterschiedliche Typen. Feste Pfeile stellen Nachrichtenflüsse dar. Bei den Beschriftungen auf festen Pfeilen handelt es sich um Nachrichtenkanalnamen. Bei den grauen festen Pfeilen handelt es sich um potenzielle Nachrichtenflüsse aus dem SYSTEM.CLUSTER.TRANSMIT.QUEUE auf Clustersenderkanäle. Schwarze gestrichelte Linien verbinden Beschriftungen mit ihren Zielen. Graue gestrichelte Pfeile sind Referenzen, z. B. von einem MQOPEN Aufruf von Client App an die Clusteraliaswarteschlangendefinition Q1A.

In Abbildung 1öffnen Clients von Server App die Warteschlange Q1A. Nachrichten werden unter QM2 in SYSTEM.CLUSTER.TRANSMIT.QUEUE eingereiht, unter QM1 in SYSTEM.CLUSTER.TRANSMIT.QUEUE übertragen und anschließend unter QM3 in Q1 übertragen, wo sie von der Anwendung Server App empfangen werden.

Die Nachricht von Client App wird über die Clusterübertragungswarteschlangen des Systems durch QM2 und QM1übergeben. In Abbildung 1besteht das Ziel darin, den Nachrichtenfluss auf dem Gateway-Warteschlangenmanager von der Clientanwendung zu isolieren, sodass seine Nachrichten nicht in SYSTEM.CLUSTER.TRANSMIT.QUEUEgespeichert werden. Sie können Flüsse auf einem der anderen Clusterwarteschlangenmanager isolieren. Sie können auch Flüsse in die andere Richtung isolieren, zurück an den Client. Um die Beschreibungen der Lösungen kurz zu halten, betrachten die Beschreibungen nur einen einzigen Nachrichtenfluss von der Clientanwendung.

Lösungen für die Isolierung des Clusternachrichtenverkehrs auf einem Cluster-Gateway-Warteschlangenmanager

Eine Möglichkeit, das Problem zu lösen, besteht darin, WS-Manager-Aliasnamen oder ferne Warteschlangendefinitionen zu verwenden, um eine Brücke zwischen Clustern zu schlagen. Erstellen Sie eine Clusterdefinition für ferne Warteschlangen, eine Übertragungswarteschlange und einen Kanal, um jeden Nachrichtenfluss auf dem Gateway-Warteschlangenmanager zu trennen; siehe Definition einer fernen Warteschlange hinzufügen, um Nachrichten zu isolieren, die von einem Gateway-Warteschlangenmanager gesendet werden.

Ab IBM WebSphere® MQ 7.5 sind Clusterwarteschlangenmanager nicht auf eine einzelne Clusterübertragungswarteschlange beschränkt. Sie haben zwei Möglichkeiten:

  1. Definieren Sie zusätzliche Clusterübertragungswarteschlangen manuell und definieren Sie, welche Clustersenderkanäle Nachrichten aus jeder Übertragungswarteschlange übertragen. Weitere Informationen finden Sie unter Clusterübertragungswarteschlange hinzufügen, um den Clusternachrichtenverkehr zu isolieren, der von einem Gateway-Warteschlangenmanager gesendet wird.
  2. Ermöglichen Sie dem WS-Manager, zusätzliche Clusterübertragungswarteschlangen automatisch zu erstellen und zu verwalten. Sie definiert eine andere Clusterübertragungswarteschlange für jeden Clustersenderkanal. Weitere Informationen hierzu finden Sie im Abschnitt Standardeinstellung in separate Clusterübertragungswarteschlangen ändern, um den Nachrichtenverkehr zu isolieren.

Sie können manuell definierte Clusterübertragungswarteschlangen für einige Clustersenderkanäle kombinieren, wobei der Warteschlangenmanager den Rest verwaltet. Die Kombination von Übertragungswarteschlangen ist die Methode, die unter Clusterübertragungswarteschlange hinzufügen, um den Clusternachrichtenverkehr zu isolieren, der von einem Gateway-Warteschlangenmanager gesendet wirdbeschrieben wird. In dieser Lösung verwenden die meisten Nachrichten zwischen Clustern SYSTEM.CLUSTER.TRANSMIT.QUEUE allgemein. Eine Anwendung ist kritisch, und alle ihre Nachrichtenflüsse werden von anderen Nachrichtenflüssen isoliert, indem eine manuell definierte Clusterübertragungswarteschlange verwendet wird.

Die Konfiguration unter Clusterübertragungswarteschlange zum Isolieren des Clusternachrichtenverkehrs hinzufügen, der von einem Gateway-Warteschlangenmanager gesendet wird ist begrenzt. Der Nachrichtendatenverkehr, der in eine Clusterwarteschlange auf demselben WS-Manager in demselben Cluster wie eine andere Clusterwarteschlange läuft, wird nicht getrennt. Sie können den Nachrichtenverkehr mit Hilfe der Definitionen der fernen Warteschlange, die Teil der verteilten Steuerung von Warteschlangen sind, in einzelne Warteschlangen aufteilen. Bei Clustern, die mehrere Clusterübertragungswarteschlangen verwenden, können Sie den Nachrichtenverkehr trennen, der zu verschiedenen Clustersenderkanälen führt. Mehrere Clusterwarteschlangen im selben Cluster teilen sich auf demselben Warteschlangenmanager einen Clustersenderkanal gemeinsam. Nachrichten für diese Warteschlangen werden in derselben Übertragungswarteschlange gespeichert, bevor sie vom Gateway-WS-Manager weitergeleitet werden. In der Konfiguration unter Cluster-und Clusterübertragungswarteschlange hinzufügen, um den Clusternachrichtenverkehr zu isolieren, der von einem Gateway-Warteschlangenmanager gesendet wirdwird die Einschränkung seitlich abgestuft, indem ein weiterer Cluster hinzugefügt und der Warteschlangenmanager und die Clusterwarteschlange zum Mitglied des neuen Clusters gemacht werden. Der neue Warteschlangenmanager kann der einzige WS-Manager im Cluster sein. Sie können dem Cluster weitere Warteschlangenmanager hinzufügen und denselben Cluster verwenden, um Clusterwarteschlangen auf diesen Warteschlangenmanagern zu isolieren.