高可用性 (HA) デプロイメント・マネージャー機能は、ファイル共有システムを使用して構成されます。 この構成オプションが選択されると、複数のデプロイメント・マネージャーが構成されます。 HA デプロイメント・マネージャー機能の利点は、 セル管理の Single Point of Failure としてデプロイメント・マネージャーを除去することです。 これは、アプリケーションのデプロイメントおよびサーバーのモニターを含む、自動化されたオペレーションに 著しく依存している環境では重要です。
デプロイメント・マネージャーは対等機能として存在します。 1 つはアクティブであるとみなされ、1 次としても認識され、セルの管理機能をホストします。 それ以外は待機モードになっているバックアップです。アクティブなマネージャーが失敗すると、待機マネージャーが引き継ぎ、新規のアクティブ・デプロイメント・マネージャー に指定されます。 WebSphere® Extended Deployment では、追加のデプロイメント・マネージャーにオリジナル・セルのデプロイメント・マネージャーを複製するための新規のコマンド行ユーティリティーが提供されています。 それぞれのデプロイメント・マネージャーは、別の物理コンピューターまたは論理コンピューター上で実行するためにインストールされ、構成されます。 デプロイメント・マネージャーは同種の作動プラットフォーム上でホストされる必要はありませんが、 同様なプラットフォームが推奨されます。 それぞれのデプロイメント・マネージャーは、 同一インスタンスのマスター構成リポジトリーおよびワークスペース領域を共有します。 これらは、ファイル共有システムに配置されている必要があります。
ファイル・システムは高速のロック・リカバリーをサポートしなければなりません。 IBM® General Parallel File System™ (GPFS™) が推奨されますが、Network File System (NFS) バージョン 4 もオプションとして提供されます。NFS バージョン 4 の使用中に、AIX バージョン 5.3 で高可用性デプロイメント・マネージャーを使用する場合、バージョン 5.3.0.60 以降の bos.net.nfs.client が必要です。
通常のオペレーションでは、少なくとも 2 つのデプロイメント・マネージャーの開始を組み込みます。 高可用性の新しいデプロイメント・マネージャー・コンポーネントは、 各デプロイメント・マネージャー内で実行され、どのデプロイメント・マネージャーをアクティブなものとして選択するかを制御します。 構成内の他のすべてのデプロイメント・マネージャーは待機モードとなります。 WebSphere Extended Deployment オンデマンド・ルーター (ODR) は、管理コンソール、 wsadmin ツール、およびスクリプト作成のための通信エンドポイントで構成されます。 ODR は、どのデプロイメント・マネージャーのインスタンスがアクティブであるかを認識し、 すべての管理コミュニケーションをアクティブのインスタンスに送付します。 HA デプロイメント・マネージャー機能は、 JMX SOAP コネクターの使用のみをサポートします。 JMX RMI コネクターはこの構成ではサポートされません。
デプロイメント・マネージャーは、最初は同一のコア・グループ内に構成されます。 ODR に公開されたルーティング情報をすべてのデプロイメント・マネージャーで一貫性のあるものにするためには、 デプロイメント・マネージャーを同一のコア・グループに構成することが重要です。 デプロイメント・マネージャーがそれぞれ別のコア・グループ内に置かれる場合、 コア・グループはコア・グループのブリッジと接続されている必要があります。
HA デプロイメント・マネージャーの標準構成は、異なるワークステーションに存在する 2 つのデプロイメント・マネージャーからなっています。これらのデプロイメント・マネージャーは、SAN FS にあるマスター・リポジトリーを共有します。管理オペレーションはすべて、選択されたアクティブのデプロイメント・マネージャーで実行されます。 待機中のデプロイメント・マネージャーは、完全に初期化され、作動可能状態にありますが、管理機能としては使用できません。 これは、現在、管理機能が同じ構成に書き込む複数の並行サーバー・プロセスをサポートしていないためです。 したがって、待機モードではログインおよび JMX 要求を拒否します。
ただし、アクティブのデプロイメント・マネージャーに停止または障害が発生した場合、 高可用性のデプロイメント・マネージャー・コンポーネントは、アクティブのデプロイメント・マネージャーの喪失を認識し、 待機モードからアクティブ・モードに動的に切り替え、失われたデプロイメント・マネージャーを 引き継ぎます。 アクティブおよび待機は、ワークスペースを共有します。 デプロイメント・マネージャーの引き継ぎが発生した場合、ODR が新規アクティブのデプロイメント・マネージャーの選択を自動的に認識し、 管理の要求を新規アクティブのデプロイメント・マネージャーに転送するため、作業内容は失われません。 ただし、1 分間の代理期間があり、この間、2 次デプロイメント・マネージャーへのフェイルオーバーが完了するまでデプロイメント・マネージャーは使用できませんので注意してください。
次の図は、新規のアクティブ・デプロイメント・マネージャーへのフェイルオーバーを示しています。
HA デプロイメント・マネージャー・コンポーネントはデプロイメント・マネージャーの障害を検出し、
引き継ぎを開始できますが、各デプロイメント・マネージャーが自分がアクティブのデプロイメント・マネージャーであると一時的に確信してしまう周辺条件があります。このような状況が発生しないようにするために、アクティブのデプロイメント・マネージャーがファイル共有システムで
ファイル・ロックを保持します。
このため、待機によるアクティブのデプロイメント・マネージャーの引き継ぎには、
共有ファイル・システムがアクティブのデプロイメント・マネージャーの損失を検出してロックを解放するのに
掛かる時間とほぼ等しい、短い時間がかかります。
SAN FS および NFS の両方で、ロック解放モデルを使用し、障害のあるロック・ホルダーについて
ロックを解放するために構成可能な時間があります。
これは、SAN FS では 10 秒に構成できます。