WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Eingebetteter globaler Cache

Den mit WebSphere Message Broker bereitgestellten globalen Cache können Sie zum Speichern von Daten verwenden, die Sie wiederverwenden möchten.

Der globale Cache ist in den Broker eingebettet. Standardmäßig ist der Cache inaktiviert. Wählen Sie zur Verwendung des Cache eine entsprechende Cacherichtlinie aus. Die Standardcacherichtlinie erstellt eine Standardtopologie aus Cachekomponenten in einem einzelnen Broker. Die Alternativen zur Standardrichtlinie bestehen darin, auf eine Richtlinie zu verzichten, um die eigene Topologie selbst verwalten zu können, indem Cacheeigenschaften für die Ausführungsgruppen festgelegt werden, oder eine XML-Richtliniendatei zu verwenden, um den Cache für mehrere Broker zu aktivieren.

Die Standardtopologie

Standardmäßig befindet sich in einer einzigen Ausführungsgruppe im Broker ein Katalogserver. Der Katalogserver steuert die Ablage von Daten und überwacht den Zustand von Container-Servern. In maximal drei anderen Ausführungsgruppen desselben Brokers befinden sich Container-Server. Ein Container-Server ist eine Komponente, die in die Ausführungsgruppe eingebettet ist, in der eine Untermenge der Cachedaten enthalten ist. Der Katalogserver und Container-Server werden beim Start des Brokers dynamisch in Ausführungsgruppen platziert. Alle Ausführungsgruppen können mit dem globalen Cache kommunizieren, unabhängig davon, ob sie Katalogserver, Container-Server oder keinen dieser Server enthalten. Jede Ausführungsgruppe umfasst einen Cache-Manager, der die in der betreffenden Ausführungsgruppe eingebetteten Cache-Komponenten verwaltet. Eine Beschreibung der Cachekomponenten finden Sie im Abschnitt Terminologie des Datencaching.

Die Position des Katalogservers wird bei einem Neustart des Brokers zurückgesetzt. Der Broker legt standardmäßig eine Gruppe von zu verwendenden Ports fest, aber Sie können eine eigene Portgruppe angeben. Wenn Sie die Ausführungsgruppe stoppen, die den Katalogserver enthält, ist der globale Cache nicht mehr verfügbar. Wenn Sie Ausführungsgruppen, die Container-Server enthalten, stoppen und erneut starten, werden die Container-Server dynamisch neu zugeordnet. Vorhandene Cachedaten bleiben erhalten und werden automatisch neu verteilt, sofern Sie nicht alle Container-Server stoppen. Ausführungsgruppen werden in folgender Reihenfolge konfiguriert:
  • Die erste zu startende Ausführungsgruppe besteht aus einem Katalogserver und einem Container-Server. Diese Ausführungsgruppe verwendet die ersten vier Ports des Portbereichs.
  • Die zweite zu startende Ausführungsgruppe besteht nur aus einem Container-Server; sie verwendet die nächsten drei Ports des Portbereichs (Ports 5 bis 7).
  • Bei der dritten und vierten zu startenden Ausführungsgruppe handelt es sich nur um Container-Server, die die Ports 8 bis 10 bzw. 11 bis 13 des Portbereichs verwenden.
  • Wenn weitere Ausführungsgruppen gestartet werden, enthalten sie keine Komponenten des globalen Cache. Allerdings können alle Ausführungsgruppen als Clients mit dem globalen Cache kommunizieren.
  • Wenn Sie die Ausführungsgruppe stoppen, die den Katalogserver enthält, ist der globale Cache nicht mehr verfügbar.
  • Wenn Sie die zweite, dritte oder vierte Ausführungsgruppe stoppen, wird der Container-Server der gestoppten Ausführungsgruppe der nächsten Ausführungsgruppe, die gestartet wird, zugeordnet.
Wenn Sie die Ausführungsgruppe erneut starten, die als Host für den Katalogserver dient, findet keine Kommunikation mit den Container-Servern in anderen Ausführungsgruppen mehr statt. Obwohl diese Container-Server noch immer ausgeführt werden, sind sie kein Teil des Cache mehr und die zugehörigen Daten gehen verloren. Deshalb müssen Sie auch die Ausführungsgruppen neu starten, in denen sich die Container-Server befinden. Alternativ dazu führen Sie einen Neustart des Brokers aus, um alle Cachekomponenten zurückzusetzen.

Bei Verwendung der Standardtopologie sind die Cacheeigenschaften für einzelne Ausführungsgruppen schreibgeschützt; ein Versuch, sie zu ändern, führt zur Ausgabe eines Fehlers. Wenn Sie die Standardtopologie verwenden, können Sie den Portbereich, den der Cache-Manager verwendet, und den Empfangsprogrammhost, der von den Cachekomponenten verwendet wird, angeben. Wenn Ihr Computer über mehrere Hostnamen verfügt, wird durch die Festlegung des Empfangsprogrammhosts sichergestellt, dass die Cachekomponenten den richtigen Hostnamen verwenden. Wenn Sie bestimmte Eigenschaften für die Ausführungsgruppe festlegen möchten, müssen Sie die Cacherichtlinieneigenschaft zuerst in none ändern. Die Ausführungsgruppeneigenschaften, die zuletzt von der Richtlinie auf Brokerebene festgelegt wurden, werden als Ausgangspunkt für die Anpassung beibehalten.

Cachetopologien mit mehreren Brokern

Damit Daten auf mehreren Brokern gemeinsam genutzt werden können oder die Cacheverfügbarkeit verbessert werden kann, müssen Sie eine Richtliniendatei erstellen. Bei der Richtliniendatei handelt es sich um eine XML-Datei, die der Cache-Manager verwendet, um die Caches mehrerer Broker miteinander zu verbinden. Definieren Sie die Cacherichtlinie als vollständig qualifizierten Namen der Richtliniendatei. Geben Sie in der Richtliniendatei die Namen der Broker, die die Cachedaten gemeinsam nutzen, die Anzahl der Katalogserver in den einzelnen Brokern sowie den zu verwendenden Portbereich und Empfangsprogrammhost für die einzelnen Broker an. Im Installationsverzeichnis stehen einige Beispielrichtliniendateien zur Verfügung. Sie können diese Richtliniendateien kopieren und für Ihr eigenes System anpassen. In den XML-Beispieldateien werden die folgenden Konfigurationen beschrieben:
  • Ein einzelner Broker mit zwei Katalogservern; wenn ein Katalogserver fehlschlägt, wechselt der globale Cache zum anderen Server.
  • Zwei Broker mit einem gemeinsamen Katalogserver, der auf dem ersten Broker bereitgestellt wird.
  • Zwei Broker, die jeweils einen Katalogserver bereitstellen; wenn ein Katalogserver fehlschlägt, wechselt der globale Cache zum Katalogserver auf dem anderen Broker.
Sie finden weitere Informationen hierzu in den Abschnitten Globalen Cache für mehrere Broker konfigurieren.

Eingebettete Topologie anpassen

Sie können für jede Ausführungsgruppe explizit Eigenschaften festlegen. So können Sie beispielsweise bestimmte Ausführungsgruppen angeben, die die Katalog- und Container-Server bereitstellen sollen, sodass Sie die Brokerleistung optimieren können. Wenn die Cacherichtlinie auf none gesetzt wird, verwendet der Cache-Manager in jeder Ausführungsgruppe die von Ihnen festgelegten Werte. Die Ausführungsgruppeneigenschaften, die zuletzt von der Richtlinie auf Brokerebene festgelegt wurden, werden als Ausgangspunkt für die Anpassung beibehalten.

Wenn Sie die Ausführungsgruppe stoppen, die den Katalogserver enthält, ist der Cache nicht mehr verfügbar und die Daten im Cache gehen verloren. Bei einer Inaktivierung der Standardtopologie müssen Sie deshalb sicherstellen, dass Sie den Katalogserver richtig positionieren. Wenn Sie die Ausführungsgruppe, die den Katalogserver bereitstellt, erneut starten, kann er nicht mehr mit den Container-Servern in anderen Ausführungsgruppen kommunizieren. Obwohl diese Container-Server noch aktiv sind, sind sie nicht mehr Teil des Cache und Ihre Daten gehen verloren. Daher müssen Sie auch die Ausführungsgruppen erneut starten, die die Container-Server bereitstellen. Sie können auch den Broker erneut starten, um alle Cachekomponenten zurückzusetzen.

Bei Verwendung mehrerer Katalogserver lässt sich die Leistung wie folgt verbessern:
  • Stellen Sie statt Ausführungsgruppen für Katalog- und Container-Server zusätzliche Ausführungsgruppen nur für Container-Server bereit.
  • Starten und stoppen Sie die Ausführungsgruppen der Reihe nach, statt sie mit dem Befehl mqsistart bzw. mqsistop alle auf einmal zu starten oder zu stoppen. Starten Sie zum Beispiel zuerst die Ausführungsgruppen mit den Katalogservern und danach die Ausführungsgruppen mit den Container-Servern.

Bei Verwendung eines globale Cache, der mehrere Broker umfasst, muss sichergestellt werden, dass alle in einem eingebetteten Grid zusammengefassten WebSphere eXtreme Scale-Server denselben Domänennamen verwenden. Nur Server mit demselben Domänennamen können demselben Grid angehören. Der Domänenname wird von den WebSphere eXtreme Scale-Clients zur Erkennung und Unterscheidung der eingebetteten Grids verwendet. Wenn Sie in der Richtliniendatei für die Ausführungsgruppe bzw. den Broker keinen Domänennamen angeben, erstellt der Broker basierend auf den Servernamen der Katalogserver einen Namen.

Standardmäßig beginnen alle Server mit einem Domänennamen, der vom Broker abgeleitet wurde. In früheren Versionen von WebSphere Message Broker wurde als Domänenname für alle Server in allen eingebetteten Caches eine leere Zeichenfolge verwendet. Server in verschiedenen Domänen können nicht in dasselbe Grid eingebracht werden. Für einen Cache, der mehrere Broker umfasst, müssen Sie daher diese Broker gleichzeitig migrieren.

Sie können den globalen Cache mit WebSphere Message Broker-Befehlen, mit dem WebSphere Message Broker Explorer oder über die Message Broker-API konfigurieren. Der Abschnitt Eingebetteten globalen Cache konfigurieren enthält weitere Informationen hierzu.

Sie können alle Cachekomponenten im Broker inaktivieren, indem Sie die Cacherichtlinieneigenschaft auf disabled setzen. Die Cacherichtlinie ist standardmäßig auf disabled gesetzt.

Interaktion mit dem globalen Cache

Mithilfe von JavaCompute-Knoten können Sie Daten in einer Zuordnung im globalen Cache speichern und abrufen. Wenn von einem externen Grid eine globale Zuordnung eingeht, stellt die Methode getGlobalMap eine Verbindung zu dem Grid her, sofern noch keine besteht. Der Abschnitt Zugriff auf den globalen Cache mithilfe eines JavaCompute-Knotens enthält weitere Informationen hierzu.

Beim Abruf eines MbGlobalMap-Objekts können Sie außerdem angeben, wie lange die Daten im globalen Cache verbleiben, bis sie automatisch entfernt werden. Diese Zeitspanne wird als Lebensdauer bezeichnet und beginnt ab der letzten Aktualisierung des Zuordnungseintrags. Der Wert gilt für alle Cacheeinträge, die unter Verwendung dieses MbGlobalMap-Objekts in dieser Instanz des Nachrichtenflusses erstellt werden. Daten, die sich bereits in der von Ihnen angegebenen Zuordnung befinden, oder Daten, die von einem anderen MbGlobalMap-Objekt erstellt werden, sind von dem Wert der Lebensdauer nicht betroffen. Sie können mehrere MbGlobalMap-Objekte in verschiedenen Flüssen, Ausführungsgruppen oder Brokern erstellen, die alle in dieselbe Zuordnung im globalen Cache aufgelöst werden, jedoch unterschiedliche Lebensdauerwerte aufweisen.

Die Lebensdauer ist standardmäßig auf null gesetzt, was bedeutet, dass die Daten nie entfernt werden. Wenn Sie eine bestimmte Lebensdauer festlegen möchten, erstellen Sie eine Sitzungsrichtlinie, die Sie über das MbGlobalMap-Objekt referenzieren können. Ausführliche Anweisungen finden Sie im Abschnitt Daten aus dem globalen Cache entfernen.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:22:32


KonzeptthemaKonzeptthema | Version 8.0.0.5 | bc23789_