[z/OS]

高可用性アプリケーションを手動で更新するためのアプリケーション・サーバーの停止

手動によるアプリケーション・ロールアウトでは、ワークロード・ルーティングは、 更新されるクラスター・メンバーが常駐するアプリケーション・サーバーを停止することによって制御します。 これによって、サーバーが静止します。 既にサーバーに存在しているすべての要求は完了することができますが、 新規要求は受け入れられません。 シスプレックス・ディストリビューターおよび WebSphere® Application Server Web サーバー・プラグインのルートは、静止サーバーから切り離して作業します。すべての作業の完了後、このサーバーでアプリケーション更新処理を開始します。

始める前に

更新が必要なクラスター・メンバーをホストするアプリケーション・サーバーを決定します。

このタスクについて

更新を手動で制御する高可用性アプリケーションがある場合には、このプロセスを使用するか、または MVS™ Modify コマンドを使用して、影響するアプリケーション・サーバーに対するリスナーを休止します。 高可用性アプリケーションを手動で更新するためのアプリケーション・サーバーの停止に関する資料を参照してください。

HA 環境におけるアプリケーション・ロールアウトおよびワークロード・ルーティングを手動で制御するには、 次のようにします。

手順

  1. セル内のすべてのノードにあるすべての形式の自動同期を使用不可にし、変更を保存します。 次のプロセスの 1 つを実行し、このステップを完了します。
    • 管理コンソールで以下を実行します。
      1. 「システム管理」>「ノード・エージェント」> node_agent_name>「ファイル同期サービス」をクリックします。
      2. 自動同期」および「始動同期」オプションを選択解除します。
      3. 変更をノードと同期する」オプションを選択します。
      4. 保存」をクリックします。
    • 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) トラブルの回避 (Avoid trouble): 実稼働環境では、 自動同期を使用不可にした状態で、 常にノード・エージェントを実行しておくのが合理的です。 ただし、ノード・エージェントが停止したときに起こる構成の更新を取得できるように、 ノード・エージェント用に始動同期を使用可能にしておくことをお勧めします。 アプリケーション更新処理中に、手動で、自動化により、または自動再始動マネージャーによりノード・エージェントを再始動しないのが確かな場合、始動同期は使用可能なままに残すことができます。gotcha
  2. デプロイメント・マネージャー・サーバーのマスター構成リポジトリーでアプリケーションを更新します。 次のプロセスの 1 つを実行し、このステップを完了します。
    • 管理コンソールで以下を実行します。
      1. アプリケーション」>「エンタープライズ・アプリケーション」とクリックします。
      2. 更新するアプリケーションを選択します。
      3. アプリケーション更新処理を完了します。
      4. 変更をマスター構成に保管します。「変更をノードと同期する」オプションを選択 しない でください。
    • 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 環境のアプリケーション更新の最初の段階を示しています。アプリケーション更新のインストール
  3. LPAR1 の Application Server を停止し、 手動でノードをアプリケーションの更新済みバージョンに同期化します。 シャットダウン前に、 サーバーは現在割り当てられている作業項目のすべてが完了するのを待つ必要があるため、 このステップは完了するのに時間がかかる可能性があります。

    次のプロセスの 1 つを実行し、このステップを完了します。

    • 管理コンソールで以下を実行します。
      1. 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」の順でクリックします。
      2. 停止および更新したいクラスター・メンバーを選択します。 このクラスター・メンバーは LPAR1 にある必要があります。
      3. 停止」をクリックします。クラスター内のすべてのサーバーを停止し、 アプリケーションが利用不可になりますので、 Cluster Stop メソッドを使用しないでください。
    • wsadmin スクリプトを使用して、次のコマンドを実行してください。
      set node NODE
      set server SERVER 
      $AdminControl stopServer $server $node 
    • MVS コンソールから次のコマンドを実行します。
       STOP short_server_name
      以下に例を示します。
      STOP BBOS001
  4. ノードを同期化します。 次のプロセスの 1 つを実行し、このステップを完了します。
    • 管理コンソールで以下を実行します。
      1. 「システム管理」>「ノード・エージェント」とクリックします。
      2. 同期化したいノードを選択し、 「Full Resynchronize」を選択します。
    • wsadmin スクリプトを使用して、次のコマンドを実行します。
      set node NODE
      set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*] 
      $AdminControl invoke $nodeSync sync 

    次の図に示すとおり、アプリケーションの更新済みバージョン (App v2) は現在、 LPAR1 のノードにあります。

    図 2. LPAR1 のノードを更新します。. この図は、2 つの LPAR とともに HA 環境のアプリケーション更新の最初の段階を示しています。LPAR1 のノードの更新
  5. LPAR1 のサーバーを再始動します。 次のプロセスの 1 つを実行し、このステップを完了します。
    • 管理コンソールで以下を実行します。
      1. 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」の順でクリックします。
      2. 開始したいサーバーを選択し、「開始」をクリックします。
    • 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 のサーバーの再始動
  6. LPAR1 で稼働しているアプリケーションの最新バージョンで、 クラスターの他の LPAR で次の 3 つのステップを繰り返し、 アプリケーションの新規バージョンでこれらを更新します。 次の図は、2 つの LPAR クラスターにおけるご使用の構成を示しています。
    図 4. LPAR2 のノードの更新. この図は、HA 環境のアプリケーション更新の 2 番目の段階を示しています。LPAR2 のノードの更新

タスクの結果

アプリケーションの新規バージョンがクラスター内のすべてのクラスター・メンバーで稼働したときに、 アプリケーション更新処理が完了します。 次の図は、LPAR2 におけるサーバーの再始動後の 2 つの LPAR クラスターを示しています。
図 5. LPAR2 のサーバーの再始動. この図は、 LPAR2 におけるサーバーの再始動後の 2 つの LPAR クラスターを示しています。LPAR2 のノードの更新

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_ha_approllout
ファイル名:trun_ha_approllout.html