Wie funktionieren Cluster?
An dieser Stelle werden das Konzept der Cluster und ihre Funktionsweise erläutert.
Ein Cluster ist ein Netz aus Warteschlangenmanagern, die logisch miteinander verbunden sind. Physisch können die Warteschlangenmanager eines Clusters getrennt sein. Sie können zum Beispiel die Filialen einer international vertretenen Geschäftskette darstellen und sich in verschiedenen Ländern befinden. Jeder Cluster innerhalb eines Unternehmens muss einen eindeutigen Namen haben.
In der Regel enthält ein Cluster Warteschlangenmanager, die auf irgendeine Weise logisch in Verbindung stehen und bestimmte Daten oder Anwendungen gemeinsam verwenden. Denkbar wäre zum Beispiel ein Warteschlangenmanager pro Unternehmensabteilung, der die für die jeweilige Abteilung typischen Daten und Anwendungen verwaltet. Diese Warteschlangenmanager könnten zu einem Cluster zusammengefasst werden, damit deren Daten der Buchhaltungsanwendung zur Verfügung stehen. Ebenso wäre ein Warteschlangenmanager pro Filiale einer Geschäftskette möglich, der die Warenbestände und andere Informationen der jeweiligen Filiale verwaltet. Wenn diese Warteschlangenmanager zu einem Cluster zusammengefasst werden, können sie alle auf die gleichen Vertriebs- und Einkaufsanwendungen zugreifen. Diese werden möglicherweise zentral bereitgestellt, zum Beispiel durch den Warteschlangenmanager der Hauptniederlassung.
Nach der Einrichtung eines Clusters können die Warteschlangenmanager ohne zusätzliche Kanaldefinitionen oder Definitionen für ferne Warteschlangen miteinander kommunizieren.
Einen Cluster können Sie aus einem bestehenden Netz aus Warteschlangenmanagern konvertieren oder bei der Einrichtung eines neuen Netzes erstellen.
Die Verbindung eines IBM® WebSphere MQ-Clients mit einem Warteschlangenmanager eines Clusters erfolgt auf die gleiche Weise wie bei jedem anderen Warteschlangenmanager.
Cluster können auch für den Lastausgleich verwendet werden. Weitere Informationen finden Sie im Abschnitt Cluster für Workload-Management verwenden.
Weiterleitung von Nachrichten in einem Cluster
Wenn Ihnen IBM WebSphere MQ und die verteilte Steuerung von Warteschlangen vertraut sind, können Sie sich einen Cluster wie ein Netz aus Warteschlangen vorstellen, das von einem gewissenhaften Systemadministrator verwaltet wird. Sobald Sie eine Clusterwarteschlange definieren, erstellt der Systemadministrator automatisch auf den anderen Warteschlangenmanagern die benötigten Definitionen für die ferne Warteschlange.
Definitionen für Übertragungswarteschlangen müssen nicht erstellt werden, da IBM WebSphere MQ auf jedem Warteschlangenmanager des Clusters eine Übertragungswarteschlange bereitstellt. Über diese Übertragungswarteschlange können Nachrichten an jeden anderen Warteschlangenmanager des Clusters übertragen werden. Sie müssen sich nicht auf die Verwendung nur einer einzelnen Übertragungswarteschlange beschränken. Ein Warteschlangenmanager kann mehrere Übertragungswarteschlangen verwenden, um die Nachrichten, die an die einzelnen Warteschlangenmanager in einem Cluster gesendet werden, voneinander zu trennen. In der Regel verwendet ein Warteschlangenmanager eine einzelne Clusterübertragungswarteschlange. Durch die Änderung des Warteschlangenmanager-Attributs DEFCLXQ können Sie festlegen, dass ein Warteschlangenmanager für jeden Warteschlangenmanager in einem Cluster eine andere Clusterübertragungswarteschlange verwenden soll. Clusterübertragungswarteschlangen können auch manuell definiert werden.
Alle Warteschlangenmanager, die einem Cluster beitreten, sind sich über diese Art der Zusammenarbeit einig. Sie geben Informationen über sich selbst und die von ihnen bereitgestellten Warteschlangen nach außen und erhalten ihrerseits Informationen über die anderen Mitglieder des Clusters.
Diese Informationen werden in Repositorys gespeichert. Die meisten Warteschlangenmanager behalten nur die Informationen, die sie tatsächlich benötigen, also Informationen über Warteschlangen und Warteschlangenmanager, mit denen sie kommunizieren. Jeder Warteschlangenmanager speichert diese Informationen in einem Teilrepository. Einige designierte Warteschlangenmanager speichern ein vollständiges Repository mit sämtlichen Informationen zu allen Warteschlangenmanagern des Clusters.
Für den Anschluss an einen Cluster benötigt ein Warteschlangenmanager zwei Kanäle: einen Clustersenderkanal und einen Clusterempfängerkanal.
Ein Clustersenderkanal ist ein einem Senderkanal entsprechender Kommunikationskanal. Den Clustersenderkanal müssen Sie auf jedem Warteschlangenmanager manuell erstellen, um den Warteschlangenmanager mit einem vollständigen Repository des Clusters zu verbinden.
Ein Clusterempfängerkanal ist ein einem Empfängerkanal entsprechender Kommunikationskanal. Sie müssen manuell einen Clusterempfängerkanal erstellen. Dieser Kanal wird als Mechanismus für den Empfang der Clusterkommunikation durch den Warteschlangenmanager genutzt.
Alle anderen Kanäle, die zusätzlich für die Kommunikation zwischen diesem Warteschlangenmanager und den anderen Mitgliedern des Clusters erforderlich sind, werden automatisch erstellt.
Warteschlangenmanager auf Plattformen, die Cluster unterstützen, müssen jedoch kein Teil eines Clusters sein. Neben oder anstatt Clustern können Sie nach wie vor Techniken für die verteilte Steuerung von Warteschlangen verwenden.
Beispiel für einen Cluster
- Dieser Cluster enthält die drei Warteschlangenmanager QM1, QM2 und QM3.
- QM1 und QM2 enthalten Repositorys mit Informationen zu allen Warteschlangenmanagern und clusterrelevanten Objekten des Clusters. Sie werden als Warteschlangenmanager mit vollständigem Repository bezeichnet. Die Repositorys sind in der Abbildung durch schattierte Zylinder dargestellt.
- QM2 und QM3 enthalten einige Warteschlangen, die den anderen Warteschlangenmanagern des Clusters zur Verfügung stehen. Warteschlangen, die für alle anderen Warteschlangenmanager im Cluster zugänglich sind, werden als Clusterwarteschlangen bezeichnet. Die Clusterwarteschlangen sind in der Abbildung schattiert dargestellt. Auf die Clusterwarteschlangen kann standortunabhängig im gesamten Cluster zugegriffen werden. Der Clustering-Code von IBM WebSphere MQ stellt sicher, dass für Clusterwarteschlangen auf jedem Warteschlangenmanager, der mit diesen arbeitet, entsprechende Definitionen für ferne Warteschlangen erstellt werden.
Wie bei der verteilten Steuerung von Warteschlangen verwendet eine Anwendung den Aufruf MQPUT, um eine Nachricht in eine Clusterwarteschlange auf einem beliebigen Warteschlangenmanager des Clusters einzureihen. Zum Abrufen von Nachrichten aus einer Clusterwarteschlange verwendet eine Anwendung den Aufruf MQGET (dieser Aufruf wird nur für den Warteschlangenmanager ausgegeben, auf dem sich die Warteschlange befindet).
- Jeder Warteschlangenmanager verfügt über eine manuell erstellte Definition für die Empfangsseite des Kanals (Clustername.Warteschlangenmanager), über die er Nachrichten empfängt. Auf dem empfangenden Warteschlangenmanager ist Clustername.Warteschlangenmanager ein Clusterempfängerkanal. Ein Clusterempfängerkanal ist vergleichbar mit einem Empfängerkanal, wie er bei der verteilten Steuerung von Warteschlangen verwendet wird. Über ihn empfängt der Warteschlangenmanager die für ihn bestimmten Nachrichten. Zusätzlich erhält der Warteschlangenmanager über diesen Kanal auch Informationen über den Cluster.
- Abbildung 1. Warteschlangenmanagercluster
- In Abbildung 2 verfügt jeder Warteschlangenmanager auch über eine Definition für die Sendeseite des Kanals. Darüber wird die Verbindung zum Clusterempfängerkanal auf einem der Warteschlangenmanager mit vollständigem Repository hergestellt. Auf dem sendenden Warteschlangenmanager ist Clustername.Warteschlangenmanager ein Clustersenderkanal. Die Clustersenderkanäle von QM1 und QM3 sind mit CLSTR1.QM2 verbunden (gepunktete Linie
2
).Der Clustersenderkanal von QM2 ist mit CLSTR1.QM1 verbunden (gepunktete Linie
3
). Ein Clustersenderkanal ist vergleichbar mit einem Senderkanal, wie er bei der verteilten Steuerung von Warteschlangen verwendet wird. Über ihn werden Nachrichten an den empfangenden Warteschlangenmanager gesendet. Zusätzlich versendet der Warteschlangenmanager über diesen Kanal auch Informationen über den Cluster.Sobald die Clusterempfänger- und die Clustersenderseiten eines Kanals definiert sind, wird der Kanal automatisch gestartet.
Wie funktioniert Clustering?
Durch die Definition eines Clustersenderkanals auf dem lokalen Warteschlangenmanager wird dieser Warteschlangenmanager bei einem der Warteschlangenmanager mit vollständigem Repository registriert. Dieser passt die Informationen in seinem vollständigen Repository entsprechend an. Danach erstellt er automatisch einen Clustersenderkanal zum neu registrierten Warteschlangenmanager und sendet diesem Informationen über den Cluster. Auf diese Weise erhält ein Warteschlangenmanager alle erforderlichen Informationen über den Cluster und der Cluster erhält alle erforderlichen Informationen über den neuen Warteschlangenmanager.
Sehen Sie sich Abbildung 1 noch einmal an. Nehmen Sie an, dass eine mit Warteschlangenmanager QM3 verbundene Anwendung Nachrichten an die Warteschlangen auf QM2 senden möchte. Beim ersten Zugriff des Warteschlangenmanagers QM3 auf diese Warteschlangen erhält er die hierzu erforderlichen Informationen aus einem vollständigen Repository. In diesem Fall wird QM2 als vollständiges Repository verwendet. Der Zugriff darauf erfolgt über den Senderkanal CLSTR1.QM2. Mithilfe der Informationen aus dem Repository kann er automatisch Definitionen für diese fernen Warteschlangen erstellen. Dieser Mechanismus funktioniert auch, wenn sich die Warteschlangen auf QM1 befinden, da QM2 ein vollständiges Repository ist. Ein vollständiges Repository verfügt über einen vollständigen Datensatz aller Objekte im Cluster. In diesem Fall würde QM3 aber automatisch auch einen Clustersenderkanal zum Clusterempfängerkanal von QM1 erstellen, wodurch eine direkte Kommunikation zwischen den beiden Warteschlangenmanagern ermöglicht wird.
Konzept