Der Deployment Manager mit hoher Verfügbarkeit wird mit einem gemeinsam genutzten Dateisystem konfiguriert. Wenn diese Konfigurationsoption ausgewählt wird, werden mehrere Deployment Manager konfiguriert. Der Nutzen des Deployment Manager mit hoher Verfügbarkeit besteht darin, dass er den Deployment Manager als Single Point of Failure für die Zellverwaltung ausschließt. Dies ist wichtig in Umgebungen, die stark auf automatisierten Operationen einschließlich Anwendungsimplementierung und Serverüberwachung basieren.
Die Deployment Manager existieren als Peers. Ein Peer, auch als primärer Peer bezeichnet, gilt als aktiv und beinhaltet die Verwaltungsfunktion der Zelle, während andere Peers als Backups im Bereitschaftsmodus fungieren. Wenn der aktive Manager fehlschlägt, übernimmt ein Standby-Deployment-Manager seine Funktion und wird als neuer aktiver Deployment Manager definiert. Mit WebSphere Extended Deployment wird ein neues Befehlszeilendienstprogramm bereitgestellt, das die Möglichkeit bietet, den Original-Deployment-Manager der Zelle mehrfach zu klonen. Jeder Deployment Manager wird so konfiguriert, dass er auf einem anderen physischen oder logischen System ausgeführt werden kann. Die Deployment Manager müssen nicht in homogenen Betriebsumgebungen bereitgestellt werden, obwohl dies empfohlen wird. Alle Deployment Manager nutzen dieselbe Instanz des Master-Konfigurations-Repository und denselben Arbeitsbereich. Beide müssen sich in einem gemeinsam genutzten Dateisystem (SFS, Shared File System).
Das Dateisystem muss eine schnelle Wiederherstellung nach Sperren unterstützen. In diesem Zusammenhang wird IBM® General Parallel File System™ (GPFS™) empfohlen. Eine weitere Option ist Network File System Version 4 (NFS). Wenn Sie den Deployment Manager mit hoher Verfügbarkeit unter AIX Version 5.3 verwenden und NFS Version 4 einsetzen, muss "bos.net.nfs.client" die Version 5.3.0.60 oder höher haben.
Der normale Betrieb beinhaltet das Starten von mindestens zwei Deployment Managern. In jedem Deployment Manager wird eine neue, hoch verfügbare Deployment-Manager-Komponente ausgeführt, um zu steuern, welcher Deployment Manager als aktiv ausgewählt wird. Jeder andere Deployment Manager in der Konfiguration befindet sich im Bereitschaftsmodus. Der On Demand Router (ODR) von WebSphere Extended Deployment wird mit den Kommunikationsendpunkten für die Administrationskonsole, das Tool "wsadmin" und Scripting konfiguriert. Der ODR erkennt, welche Deployment-Manager-Instanz aktiv ist und leitet die gesamte verwaltungsbezogene Kommunikation an diese Instanz weiter. Der Deployment Manager mit hoher Verfügbarkeit unterstützt nur die Verwendung des JMX-SOAP-Connector. Der JMX-RMI-Connector wird in dieser Konfiguration nicht unterstützt.
Die Deployment Manager werden anfangs in derselben Stammgruppe konfiguriert. Die Konfiguration der Deployment Manager in derselben Stammgruppe ist wichtig, damit die Routing-Informationen, die dem ODR bereitgestellt werden, in allen Deployment Managern dieselben sind. Wenn die Deployment Manager in separaten Stammgruppen platziert werden, müssen die Stammgruppen mit einer Stammgruppenbrücke verbunden werden.
Eine typische Deployment-Manager-Konfiguration mit hoher Verfügbarkeit besteht aus zwei Deployment Managern, die sich auf separaten Workstations befinden. Die Deployment Manager nutzen gemeinsam ein Master-Repository, das sich auf einem SAN FS befindet. Alle Verwaltungsoperationen werden über den ausgewählten aktiven Deployment Manager ausgeführt. Der Standby-Deployment-Manager ist vollständig initialisiert und betriebsbereit, kann jedoch nicht für die Verwaltung verwendet werden. Dies liegt daran, dass die Verwaltungsfunktion gegenwärtig nicht mehrere gleichzeitig ablaufende Serverprozesse, die Schreibzugriffe auf dieselbe Konfiguration ausführen, unterstützt. Daher weist der Standby-Deployment-Manager alle Anmelde- und JMX-Anforderungen zurück.
Wenn der aktive Deployment Manager gestoppt wird oder fehlschlägt, erkennt der Deployment Manager mit hoher Verfügbarkeit den Ausfall des aktiven Deployment Manager und schaltet den Standby-Deployment-Manager dynamisch in den aktiven Modus, damit er die Funktion des ausgefallenen Deployment Manager übernehmen kann. Der aktive Deployment Manager und der Standby-Deployment-Manager nutzen Arbeitsbereiche gemeinsam. Wenn die Übernahme des Deployment Manager stattfindet, gehen keine Arbeitsvorgänge verloren, da der ODR automatisch die Auswahl des neuen aktiven Deployment Manager erkennt und die Verwaltungsanforderungen an den neuen aktiven Deployment Manager weiterleitet. Beachten Sie, dass der Deployment Manager kurze Zeit (weniger als 1 Minute) nicht verfügbar ist, bis die Übernahme durch den sekundären Deployment Manager abgeschlossen ist.
Die Übernahme durch den neuen aktiven Deployment Manager wird im folgenden Diagramm veranschaulicht:
Der Deployment Manager für hohe Verfügbarkeit ist zwar in der Lage, einen Ausfall des Deployment
Manager festzustellen und das Failover einzuleiten, es gibt jedoch Grenzfälle, in
denen jeder Deployment Manager die Information haben könnte, dass er der aktive
Deployment Manager ist. Um solche Situationen zu vermeiden, hält der aktive Deployment Manager eine
Dateisperre im gemeinsam genutzten Dateisystem. Aufgrund dieser Sperre nimmt die Übernahme des
aktiven Deployment Manager durch den Standby-Deployment-Manager einen kurzen Zeitraum in
Anspruch, die etwa dem Zeitraum entspricht, den das gemeinsam genutzte Dateisystem benötigt, um den
Verlust des aktiven Deployment Manager festzustellen und die Sperre aufzuheben. SAN FS
und NFS verwenden beide ein Modell mit Sperrzugangsberechtigung und ermöglichen die
Konfiguration von Zeiträumen für die Aufhebung von Sperren für fehlerhafte Deployment
Manager, die Sperren halten. In SAN FS kann die Zeitspanne auf 10 Sekunden reduziert werden.