手動によるアプリケーション・ロールアウトでは、ワークロード・ルーティングは、
更新されるクラスター・メンバーが常駐するアプリケーション・サーバーを停止することによって制御します。
これによって、サーバーが静止します。
既にサーバーに存在しているすべての要求は完了することができますが、
新規要求は受け入れられません。
シスプレックス・ディストリビューターおよび WebSphere® Application Server Web サーバー・プラグインのルートは、静止サーバーから切り離して作業します。すべての作業の完了後、このサーバーでアプリケーション更新処理を開始します。
始める前に
更新が必要なクラスター・メンバーをホストするアプリケーション・サーバーを決定します。
このタスクについて
更新を手動で制御する高可用性アプリケーションがある場合には、このプロセスを使用するか、または MVS™ Modify コマンドを使用して、影響するアプリケーション・サーバーに対するリスナーを休止します。
高可用性アプリケーションを手動で更新するためのアプリケーション・サーバーの停止に関する資料を参照してください。
HA 環境におけるアプリケーション・ロールアウトおよびワークロード・ルーティングを手動で制御するには、
次のようにします。
手順
- セル内のすべてのノードにあるすべての形式の自動同期を使用不可にし、変更を保存します。 次のプロセスの 1 つを実行し、このステップを完了します。
- 管理コンソールで以下を実行します。
- 「node_agent_name」>「ファイル同期サービス」をクリックします。
- 「自動同期」および「始動同期」オプションを選択解除します。
- 「変更をノードと同期する」オプションを選択します。
- 「保存」をクリックします。
- wsadmin スクリプトを使用し、次のコマンドを指定し、
影響を受けたすべてのノード・エージェントを再始動します。
set node NODE
set na_id [$AdminConfig getid /Node:$node/Server:nodeagent/]
set syncServ [$AdminConfig list ConfigSynchronizationService $na_id]
$AdminConfig modify $syncServ {{autoSynchEnabled false}}
$AdminConfig modify $syncServ {{synchOnServerStartup false}}
$AdminConfig save
set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*]
$AdminControl invoke $nodeSync sync
トラブルの回避 (Avoid trouble): 実稼働環境では、
自動同期を使用不可にした状態で、
常にノード・エージェントを実行しておくのが合理的です。
ただし、ノード・エージェントが停止したときに起こる構成の更新を取得できるように、
ノード・エージェント用に始動同期を使用可能にしておくことをお勧めします。
アプリケーション更新処理中に、手動で、自動化により、または自動再始動マネージャーによりノード・エージェントを再始動しないのが確かな場合、始動同期は使用可能なままに残すことができます。
gotcha
- デプロイメント・マネージャー・サーバーのマスター構成リポジトリーでアプリケーションを更新します。 次のプロセスの 1 つを実行し、このステップを完了します。
- 管理コンソールで以下を実行します。
- 「アプリケーション」>「エンタープライズ・アプリケーション」とクリックします。
- 更新するアプリケーションを選択します。
- アプリケーション更新処理を完了します。
- 変更をマスター構成に保管します。「変更をノードと同期する」オプションを選択 しない でください。
- wsadmin スクリプトを使用して、次のコマンドを実行します。
set app_loc /path/to/app
set app_options {application options ie: -appname app}
set options [list -update] lappend options $app_options
$AdminApp install $app_loc $options
$AdminConfig save
この時点で、
マスター構成には更新済みのアプリケーションのバージョン (次の図の App v2) があります。
ただし、アプリケーションの元のバージョン (次の図の App v1) は、
LPAR1 および LPAR2 にクラスター・メンバーがある
クラスターで依然稼働しています。
図 1. アプリケーション更新のインストール.
この図は、HA 環境のアプリケーション更新の最初の段階を示しています。
- LPAR1 の Application Server を停止し、
手動でノードをアプリケーションの更新済みバージョンに同期化します。 シャットダウン前に、
サーバーは現在割り当てられている作業項目のすべてが完了するのを待つ必要があるため、
このステップは完了するのに時間がかかる可能性があります。
次のプロセスの 1 つを実行し、このステップを完了します。
- ノードを同期化します。 次のプロセスの 1 つを実行し、このステップを完了します。
次の図に示すとおり、アプリケーションの更新済みバージョン (App v2) は現在、
LPAR1 のノードにあります。
図 2. LPAR1 のノードを更新します。.
この図は、2 つの LPAR とともに HA 環境のアプリケーション更新の最初の段階を示しています。
- LPAR1 のサーバーを再始動します。 次のプロセスの 1 つを実行し、このステップを完了します。
- 管理コンソールで以下を実行します。
- の順でクリックします。
- 開始したいサーバーを選択し、「開始」をクリックします。
- wsadmin スクリプトを使用して、次のコマンドを実行します。
set node NODE
set server SERVER
$AdminControl startServer $server $node
- MVS コンソールから次のコマンドを実行します。
START procname,JOBNAME=server_short_name.ENV=cell_short_name.node_short_name.server_short_name
以下に例を示します。START BBO6ACR,JOBNAME=BBOS001,ENV=PLEX1.SY1.BBOS001
このサーバーがバックアップされると、アプリケーションの新規バージョン (App v2) が実行されます。図 3. LPAR1 のサーバーの再始動.
この図は、HA 環境におけるアプリケーション更新の最初の段階の完了を示しています。
- LPAR1 で稼働しているアプリケーションの最新バージョンで、
クラスターの他の LPAR で次の 3 つのステップを繰り返し、
アプリケーションの新規バージョンでこれらを更新します。 次の図は、2 つの LPAR クラスターにおけるご使用の構成を示しています。
図 4. LPAR2 のノードの更新.
この図は、HA 環境のアプリケーション更新の 2 番目の段階を示しています。
タスクの結果
アプリケーションの新規バージョンがクラスター内のすべてのクラスター・メンバーで稼働したときに、
アプリケーション更新処理が完了します。
次の図は、LPAR2 におけるサーバーの再始動後の 2 つの LPAR クラスターを示しています。
図 5. LPAR2 のサーバーの再始動.
この図は、
LPAR2 におけるサーバーの再始動後の 2 つの LPAR クラスターを示しています。