WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

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

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

始める前に

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

このタスクについて

手動で制御する更新を持つ高可用性アプリケーションがある場合には、 このプロセスを使用するか、または MVS Modify コマンドを使用して、 影響するアプリケーション・サーバーに対するリスナーを休止します

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

プロシージャー

  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 
      重要: 実稼働環境では、 自動同期を使用不可にした状態で、 常にノード・エージェントを実行しておくのが合理的です。 ただし、ノード・エージェントが停止したときに起こる構成の更新を取得できるように、 ノード・エージェント用に始動同期を使用可能にしておくことをお勧めします。 アプリケーション更新処理中に自動化、または自動再始動マネージャーを介して、 手動でノード・エージェントを再始動しないのが確かな場合、 始動同期は使用可能なままに残すことができます。
  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. アプリケーション更新のインストール. この図は、高可用性環境のアプリケーション更新の最初の段階を示しています。 アプリケーション更新のインストール
  3. LPAR1 の Application Server を停止し、 手動でノードをアプリケーションの更新済みバージョンに同期化します。 シャットダウン前に、 サーバーは現在割り当てられている作業項目のすべてが完了するのを待つ必要があるため、 このステップは完了するのに時間がかかる可能性があります。

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

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

結果

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



関連概念
高可用性環境でのアプリケーション更新手順
高可用性構成
関連タスク
高可用性シスプレックス環境のセットアップ
アプリケーション・サーバー・リスナーの一時停止による高可用性アプリケーションの手動更新
更新の高可用性アプリケーションへの自動ロールアウト
高可用性環境のセットアップ
タスク・トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/trun_ha_approllout.html