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.

Wenn der High Availability Manager für einen Anwendungsserverprozess aktiviert bleiben muss, sollten Sie überlegen, ob der Prozess einen der folgenden Services des High Availability Manager benötigt:
  • Replikation zwischen Speichern
  • Singleton-Failover
  • Workload-Management-Routing
Fehler vermeiden Fehler vermeiden: Viele internen Komponenten verwenden die Infrastruktur des High Availability Manager oder nutzen interne Services, die den High Availability Manager verwenden. Aus diesem Grund stellen die aufgelisteten High-Availability-Manager-Services nicht unbedingt eine alles umfassende Liste der Services dar, die von der Inaktivierung des High Availability Manager betroffen sind. Außerdem kann sich die Liste ändern, weil jederzeit weitere Services dahingehend geändert werden können, dass sie den High Availability Manager verwenden.gotcha
Bewährtes Verfahren Bewährtes Verfahren: Anstatt den High Availability Manager zu inaktivieren, sollten Sie mehrere Zellen erstellen oder die Zelle in mehrere Stammgruppen partitionieren und Brücken erstellen. Selbst wenn Sie derzeit keine Komponente verwenden, für die der High Availability Manager erforderlich ist, ist es möglich, dass Sie eine solche Komponente zu einem späteren Zeitpunkt benötigen. bprac

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][IBM i]Singleton-Failover ist ein clusterbasierter Service. Der High Availability Manager muss in den folgenden Fällen auf allen Membern eines Cluster aktiviert werden:
  • 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.

[z/OS]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

Das Workload-Management (WLM) gibt die folgenden Klassen oder Typen der Routing-Informationen weiter:
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.

Beispiel:
  • 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.

Fehler vermeiden Fehler vermeiden: Ein Proxy-Server-Cluster verfügt nicht über dieselbe Funktionalität wie ein Cluster von Anwendungsservern.

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.

gotcha

Beispielausgabe:

myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_ham_required
Dateiname:crun_ha_ham_required.html