Wann sollte ein High Availability Manager verwendet werden?
Ein High Availability Manager verbraucht wertvolle Systemressourcen, z. B. CPU-Zyklen, Heapspeicher und Sockets. Diese Ressourcen werden vom High Availability Manager und von Produktkomponenten verwendet, die die vom High Availability Manager bereitgestellten Services nutzen. Die Menge der vom High Availability Manager und diesen Produktkomponenten verbrauchten Ressourcen nimmt nicht linear mit der Größe einer Stammgruppe zu.
Für große Stammgruppen kann der Ressourcenverbrauch erheblich sein. Durch Inaktivieren des High Availability Manager werden diese Ressourcen freigeben. Bevor Sie den High Availability Manager inaktivieren, sollten Sie jedoch die aktuellen und künftigen Erfordernisse Ihres Systems sorgfältig prüfen, um sicherzustellen, dass durch Inaktivierung des High Availability Manager nicht auch andere Funktionen inaktiviert werden, die Sie verwenden und die den High Availability Manager benötigen. Beispielsweise muss der High Availability Manager sowohl für die Replikation zwischen Speichern als auch für den Remote Request Dispatcher (RRD) aktiviert sein.
Die Möglichkeit, den High Availability Manager zu inaktivieren, ist besonders hilfreich für Topologien, in denen keiner der vom High Availability Manager bereitgestellten Services verwendet wird. In bestimmten Topologien verwenden nur einige Prozesse die vom High Availability Manager bereitgestellten Services. In diesen Topologien können Sie den High Availability Manager auf Prozessbasis aktivieren, was den Ressourcenverbrauch des High Availability Manager optimiert.
Sie sollten den High Availability Manager für Verwaltungsprozesse, z. B. Node Agents und den Deployment Manager, nur dann inaktivieren, wenn der High Availability Manager in allen Anwendungsserverprozessen in dieser Stammgruppe inaktiviert ist.
Einige der vom High Availability Manager bereitgestellten Services sind clusterbasiert. Cluster-Member müssen homogen sein. Wenn Sie den High Availability Manager in einem Member eines Cluster inaktivieren, müssen Sie ihn deshalb in allen Membern dieses Cluster inaktivieren.
- Replikation zwischen Speichern
- Singleton-Failover
- Workload-Management-Routing


Replikation zwischen Speichern
Die Replikation zwischen Speichern ist ein clusterbasierter Service, den Sie auf Anwendungsserverebene konfigurieren bzw. aktivieren. Wenn die Replikation zwischen Speichern in einem Cluster-Member aktiviert ist, muss der High Availability Manager in allen Member dieses Cluster aktiviert sein. Die Replikation zwischen Speichern wird automatisch aktiviert, wenn
- die Replikation zwischen Speichern für HTTP-Sitzungen des Web-Containers aktiviert ist.
- die Cachereplikation für den dynamischen Cache-Service aktiviert ist.
- das Failover für EJB-Stateful-Session-Beans für einen Anwendungsserver aktiviert ist.
Singleton-Failover
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Der Cluster ist so konfiguriert, dass der High Availability Manager für die Verwaltung der Wiederherstellung von Transaktionsprotokollen verwendet wird.
- Mindestens eine Instanz des Standard-JMS-Providers ist für die Ausführung im Cluster konfiguriert. Der mit dem Produkt bereitgestellte Standard-Messaging-Provider wird auch als Service-Integration-Bus bezeichnet.
Singleton-Failover ist ein clusterbasierter Service.
Der High Availability Manager muss auf allen Member eines Cluster aktiviert werden, wenn mindestens eine Instanz
des Standard-JMS-Providers für die Ausführung im Cluster konfiguriert ist.
Der Standard-Messaging-Provider ist die Messaging-Engine, die mit
dem Produkt bereitgestellt wird.
Workload-Management
Routing-Informationen für Enterprise-Bean-IIOP-Datenverkehr
- Routing-Informationen für die Standardengine für Messaging, die auch als Service-Integration-Bus bezeichnet wird
- Routing von HTTP-Anforderungen durch den Proxy-Server von IBM® WebSphere Application Server
- Routing von Web-Service-Adressierungsanforderungen durch den Proxy-Server von IBM WebSphere Application Server.
- Routing von SIP-Anforderungen (Session Initiation Protocol)
WLM verwendet den High Availability Manager, um die Routing-Informationen weiterzugeben und sie hoch verfügbar zu machen. WLM-Routing-Informationen werden zwar normalerweise auf Clusterressourcen angewendet, können aber auch auf Nicht-Clusterressourcen, z. B. eigenständige Messaging-Engines, angewendet werden. Gewöhnlich müssen Sie den High Availability Manager in allen Anwendungsservern aktiviert lassen, die IIOP-Routing-Informationen bzw. Routing-Informationen der Messaging-Engine erstellen oder verwenden.
- Die Routing-Informationen werden von einer Enterprise-Bean-Anwendung, die sich in Cluster 1 befindet, erstellt.
- Der Konsument der Routing-Informationen ist ein Servlet, das sich in Cluster 2 befindet.
Wenn das Servlet in Cluster 2 die Enterprise-Bean-Anwendung in Cluster 1 aufruft, muss der High Availability Manager auf allen Servern in beiden Clustern aktiviert werden.
Die Workload-Management-MBeans ClusterMgr und Cluster können Basisinformationen zu einem Cluster zurückgeben. Wird der High Availability Manager jedoch an einer Stelle in Ihrer Topologie inaktiviert, ist es nicht möglich, die aktuellen Einstellungen zu ändern und die Änderungen an alle Clustermember weiterzugeben.
Workload-Management stellt eine Option für das statische Erstellen und Exportieren von Routentabellen in das Dateisystem bereit. Verwenden Sie diese Option, um die Abhängigkeit vom High Availability Manager zu beseitigen.

Weil es zwischen den Membernn eines Proxy-Clusters keine Datenreplikation gibt, wird beispielsweise kein Failover zwischen den Proxy-Servern im Cluster unterstützt. Wenn ein Proxy-Server ausgefallen ist, fallen alle aktiven Verbindungen des Proxy-Servers weg und eingehende Anforderungen scheitern. Allerdings unterstützen sowohl die Proxy-Server als auch die Proxy-Cluster die hohe Verfügbarkeit und das Failover von Back-End-Servern, sodass der Proxy-Server erkennen kann, ob ein Back-End-Server inaktiv ist und die Anforderungen an einen Server weiterleiten kann, auf dem die Sitzung repliziert ist.
gotchaBeispielausgabe:
myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)