Websphere MQ Clustering

Question

Ich bin ziemlich neu in der Websphere MQ, also bitte verzeihen Sie mir, wenn ich nicht die richtigen Bedingungen verwende. Wir machen ein Projekt, in dem wir einen MQ-Cluster für Hochverfügbarkeit einrichten müssen.

Die Clientanwendung verwaltet einen Verbindungspool mit dem Warteschlangenmanager für Abonnenten und Herausgeber. Angenommen, wir haben zwei Warteschlangenmanager in einem Cluster, in dem die Warteschlangen mit denselben Namen gehostet werden. Jede der Warteschlangen hat ihren eigenen Satz von Abonnenten und Herausgebern, die von der Client-Anwendung zwischengespeichert werden. Wenn einer der Warteschlangenmanager ausfällt, werden die Abonnenten und Herausgeber der Warteschlangen in diesem Warteschlangenmanager sterben, wodurch die Objekte in der Clientanwendung nicht mehr funktionieren.

In diesem Fall können die folgenden Szenarien berücksichtigt werden?

1] Als erstes Queuemanager Abstürze, die Nachrichten auf seiner anderen Warteschlangen Queuemanager im Cluster übertragen werden

2] Wenn Queuemanager wieder kommt, gibt es einen Mechanismus, um die Verlage und Abonnenten wiederherzustellen. Derzeit haben wir in der Client-Anwendung einen automatisierten Wiederherstellungs-Thread geschrieben, der versucht, die fehlgeschlagenen Publisher und Abonnenten erneut zu verbinden. Im Falle eines Cluster-Setups befürchten wir jedoch, dass sich die Publisher und Abonnenten wieder mit dem anderen laufenden qmanager verbinden. Und wenn der abgestürzte Warteschlangenmanager wiederhergestellt wird, gibt es keine Verleger und Abonnenten.

Kann mir bitte jemand erklären, wie man sich um zwei Szenarien kümmert?

Answer 1

Um Shashis Antwort hinzuzufügen, benötigen Sie einen Netzwerksprung zwischen Sender und Empfänger von Nachrichten, um das WMQ-Clustering optimal zu nutzen. Beim WMQ-Clustering geht es darum, wie QMgrs untereinander kommunizieren. Es hat nichts damit zu tun, wie Client-Apps mit QMgrs kommunizieren und keine Nachrichten replizieren. Wenn in einem Cluster eine Nachricht von einem QMgr zu einem anderen gesendet werden muss, ermittelt der Cluster, wohin er ihn leiten soll. Wenn mehrere Cluster-Instanzen einer einzelnen Zielwarteschlange vorhanden sind, kann die Nachricht an einen von ihnen weitergeleitet werden. Wenn kein Netzwerksprung zwischen Sendern und Empfängern stattfindet, müssen Nachrichten das lokale QMgr nicht verlassen und daher wird das WMQ-Clustering-Verhalten nie aufgerufen, obwohl die beteiligten QMgrs am Cluster teilnehmen können.

In einer herkömmlichen WMQ-Clusterarchitektur hören alle Empfänger mehrere Instanzen der gleichen Warteschlange mit demselben Namen ab, die auf mehrere QMgrs verteilt sind. Die Absender haben einen oder mehrere QMgrs, wo sie Verbindungen herstellen und Anfragen senden können (fire-and-forget) und möglicherweise auf Antworten warten (Anfrage-Antwort). Da die Empfänger der Nachrichten einen Dienst bereitstellen, rufe ich ihre QMgrs "Dienstanbieter QMgrs" auf. Die QMgrs, in denen die Absender von Nachrichten leben, sind "Service Consumer" QMgrs, weil diese Apps Diensteabonnenten sind.

Die folgende Folie stammt aus einer Präsentation, die ich bei WMQ Architecture Consulting-Engagements verwende.

Hinweis, dass die Verbraucher von Dienstleistungen - die Anfragenachrichten zu senden Dinge - Failover. Dinge, die auf Serviceendpunktwarteschlangen hören und Dienste bereitstellen, führen kein Failover durch. Dies liegt daran, dass sichergestellt werden muss, dass jede aktive Dienstendpunktwarteschlange immer bedient wird. In der Regel enthält jede Anwendungsinstanz ein Eingabehandle für zwei oder mehr Warteschlangeninstanzen. Auf diese Weise kann ein QMgr untergehen und alle App-Instanzen bleiben aktiv. Wenn eine App-Instanz ausfällt, wird eine andere App-Instanz weiterhin ihre Warteschlangen bereitstellen. Diese Affinität von Dienstanbietern zu bestimmten QMgrs ermöglicht, falls erforderlich, XA-Transaktionalität.

Der beste Weg, die ich gefunden habe WMQ HA zu erklären, ist eine Folie aus der Konferenz IMPACT:

Ein WebSphere MQ-Cluster stellt sicher, dass ein Dienst zur Verfügung steht, auch wenn eine Instanz eines gruppierten Die Warteschlange ist möglicherweise nicht verfügbar. Neue Nachrichten im Cluster werden an die verbleibenden Warteschlangeninstanzen weitergeleitet. Ein Hardware-Cluster oder Multi-Instanz-QMgr (MIQM) bietet Zugriff auf vorhandene Nachrichten. Wenn eine Seite des aktiven/passiven Paares ausfällt, gibt es einen kurzen Ausfall auf dem QMgr nur, während der Failover auftritt, dann übernimmt der sekundäre Knoten und macht alle Nachrichten in den Warteschlangen wieder verfügbar. Ein Netzwerk, das sowohl WMQ-Cluster als auch Hardware-Cluster/MIQM kombiniert, bietet die höchste Verfügbarkeitsstufe.

Beachten Sie, dass in keiner dieser Konfigurationen Nachrichten über Knoten hinweg repliziert werden. Eine WMQ-Nachricht hat immer einen einzelnen physischen Speicherort. Weitere Informationen zu diesem Aspekt finden Sie unter Thoughts on Disaster Recovery.

Answer 2

WMQ-Clustering ist ein erweitertes Thema. Sie müssen zuerst eine gute Menge von WMQ lesen und verstehen, was Clustering in WMQ Welt bedeutet, bevor Sie etwas versuchen.

WMQ Cluster unterscheidet sich in vielerlei Hinsicht von den traditionellen Clustern. Im Gegensatz zu herkömmlichen Clustern, z. B. in einem Aktiv/Passiv-Cluster, werden Daten zwischen aktiven und passiven Instanzen einer Anwendung geteilt. Zu jedem Zeitpunkt verarbeitet die aktive Instanz der Anwendung Daten. Wenn die aktive Instanz ausfällt, übernimmt die passive Instanz und beginnt mit der Verarbeitung. Dies ist in WMQ-Clustern nicht der Fall, wenn Warteschlangenmanager in einem Cluster eindeutig sind und Warteschlangen/Themen, die von diesen Warteschlangenmanagern gehostet werden, nicht gemeinsam genutzt werden. Sie haben möglicherweise die gleichen Warteschlangen/Themen in beiden Warteschlangenmanagern, aber da sich die Warteschlangenmanager unterscheiden, werden Nachrichten, Themen, Abonnements usw. nicht freigegeben.

Beantworten Sie Ihre Fragen.
1) Nein. Nachrichten, wenn sie persistent sind, verbleiben im abgestürzten Warteschlangenmanager. Sie werden nicht an einen anderen Warteschlangenmanager übertragen. Da der Warteschlangenmanager selbst nicht verfügbar ist, kann nichts getan werden, bis der Warteschlangenmanager aufgerufen wird.
2) Nein. Der Warteschlangenmanager kann das nicht tun. Es ist die Aufgabe der Anwendung, die Verfügbarkeit des Warteschlangenmanagers zu überprüfen und die Verbindung wiederherzustellen. WMQ bietet eine Funktion zur automatischen Clientwiederherstellung, bei der die WMQ-Clientbibliotheken automatisch eine Verbindung mit dem Warteschlangenmanager herstellen, wenn sie fehlerbehaftete Verbindungen erkennen. Diese Funktion ist ab WMQ v7.x mit C- und Java-Clients verfügbar. Der C# -Client unterstützt die Funktion ab Version 7.1.

Für Ihre Hochverfügbarkeitsanforderung können Sie die Multi Instanz-Warteschlangenmanager-Funktion von WMQ verwenden. Diese Funktion aktiviert aktive/passive Instanzen desselben Warteschlangenmanagers, die auf zwei verschiedenen Computern ausgeführt werden. Die aktive Instanz des Warteschlangenmanagers verarbeitet Clientverbindungen, während sich die passive Instanz im Energiesparmodus befindet. Beide Instanzen teilen Daten und Protokolle. Sobald die aktive Instanz ausfällt, wird die passive Instanz aktiv. Sie haben Zugriff auf alle persistenten Nachrichten, die sich in den Warteschlangen befanden, bevor der aktive Warteschlangenmanager ausgefallen ist.

Lesen Sie das WMQ InfoCenter für weitere Informationen zum Multi-Instanzen-Warteschlangenmanager.