Clusterthemen

Themen lassen sich auf ähnliche Weise wie Clusterwarteschlangen in Gruppen zusammenfassen, wobei ein Themenobjekt jedoch jeweils nur Mitglied eines einzigen Clusters sein kann. Ein Thema (Topic) wird zu einem Cluster-Topic, indem im Themenobjekt der Name des Clusters, der das Thema enthalten soll, und der Mechanismus zur Clusterweiterleitung, der für Publikationen in diesem Thema verwendet werden soll, festgelegt werden.

Es gibt zwei Optionen zum Weiterleiten von Publikationen über einen Publish/Subscribe-Cluster: direktes Routing und Topic-Host-Routing. Sie wählen das Nachrichtenrouting aus, das im Cluster verwendet werden soll, indem Sie die Eigenschaft CLROUTE des verwalteten Topic-Objekts auf einen der folgenden Werte setzen:
  • DIRECT
  • TOPICHOST

Standardmäßig hat das Topic-Routing den Wert DIRECT. Vor IBM® MQ Version 8.0 war dies die einzige Option. Wenn Sie ein direkt geroutetes Cluster-Topic in einem Warteschlangenmanager konfigurieren, werden sämtliche Warteschlangenmanager im Cluster aller anderen Warteschlangenmanager im Cluster gewahr. Beim Ausführen von Publish/Subscribe-Operationen wird dann jeder Warteschlangenmanager direkt mit allen anderen Warteschlangenmanagern verbunden.

In IBM MQ Version 8.0 können Sie Topic-Routing stattdessen mit dem Wert TOPICHOST konfigurieren. Wenn Sie Topic-Host-Routing verwenden, werden sämtliche Warteschlangenmanager im Cluster der Clusterwarteschlangenmanager gewahr, auf denen die Definitionen des gerouteten Topic gehostet werden. Beim Ausführen von Publish/Subscribe-Operationen werden Warteschlangenmanager im Cluster nur mit diesen Topic-Host-Warteschlangenmanagern und nicht direkt miteinander verbunden. Die Topic-Host-Warteschlangenmanager sind für das Routing von Publikationen aus Warteschlangenmanagern verantwortlich, in denen Publikationen für Warteschlangenmanager mit übereinstimmenden Subskriptionen veröffentlicht werden.

Ein über einen Topic-Host gerouteter Publish/Subscribe-Cluster bietet folgende Vorteile:
  • Verbesserte Skalierbarkeit größerer Cluster. Nur die Topic-Host-Warteschlangenmanager müssen eine Verbindung zu allen anderen Warteschlangenmanagern im Cluster herstellen können. Aus diesem Grund stehen zwischen Warteschlangenmanagern weniger Kanäle zur Verfügung und das Volumen an administrativem Publish/Subscribe-Datenverkehr zwischen den Warteschlangenmanagern ist geringer als beim direkten Routing. Wenn sich die Subskriptionen in einem Warteschlangenmanager ändern, müssen nur die Topic-Host-Warteschlangenmanager informiert werden.
  • Mehr Kontrolle über die physische Konfiguration. Beim direkten Routing setzen alle Warteschlangenmanager sämtliche Rollen voraus und müssen daher gleichermaßen befähigt sein. Beim Topic-Host-Routing wählen Sie explizit die Topic-Host-Warteschlangenmanager aus. Damit können Sie sicherstellen, dass diese Warteschlangenmanager auf entsprechend leistungsfähigen Systemen aktiv sind, und die anderen Warteschlangenmanager auf weniger leistungsfähigen Systemen installieren.

Auswirkung des Definierens eines lokalen Themas sowie eines Cluster-Topics

Sie definieren ein lokales Topic-Objekt, wenn Publisher-Anwendungen, die mit einem Warteschlangenmanager verbunden sind, nur für lokal verbundene Subskribenten veröffentlichen sollen. Die lokale Definition eines Topics überschreibt stets alle Cluster-Topic-Definitionen in fernen Warteschlangenmanagern.

Anmerkung: Zudem müssen Sie den Veröffentlichungsbereich eines Warteschlangenmanagers für das lokale Topic-Objekt angeben. Wenn der Veröffentlichungsbereich in Alle aufgelöst wird, werden an ferne Subskribenten auch Veröffentlichungen gesendet, die für das in diesem Warteschlangenmanager definierte Topic veröffentlicht wurden.

Mehrere Cluster-Topic-Definitionen in einem Cluster mit direktem Routing

In einem Cluster mit direktem Routing definieren Sie ein Cluster-Topic für gewöhnlich nicht in mehreren Clusterwarteschlangenmanagern, da das Topic über das direkte Routing allen Warteschlangenmanagern im Cluster zur Verfügung steht.

Zudem ist es nicht erforderlich, dass der einzige Host-Warteschlangenmanager ununterbrochen zur Verfügung steht, da die Definition des Cluster-Topics vom vollständigen Warteschlangenmanager-Repository und von allen anderen Warteschlangenmanagern in ihren partiellen Clusterrepositorys zwischengespeichert wird. Dadurch ist eine Verfügbarkeit von mindestens 60 Tagen sichergestellt, wenn der Host-Warteschlangenmanager nicht verfügbar ist.

Wenn Sie die Definition eines Cluster-Topics ändern müssen, achten Sie darauf, sie in dem Warteschlangenmanager zu ändern, in dem sie auch definiert wurde.

Mehrere Cluster-Topic-Definitionen in einem Cluster mit Topic-Host-Routing

In einem Cluster mit Topic-Host-Routing wird das gesamte Publish/Subscribe-Messaging über die Topic-Hosts geroutet. Um die Skalierbarkeit und Verfügbarkeit sicherzustellen, wird daher für gewöhnlich ein Cluster-Topic in mehreren Warteschlangenmanagern definiert und die mehrfachen Cluster-Topic-Definitionen sind in der Regel identisch.


Konzept Konzept

Feedback

Timestamp icon Letzte Aktualisierung: 6. Februar 2018
http://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.explorer.doc/com.ibm.mq.explorer.doc/e_clustertopics.htm