WebSphere Virtual Enterprise, Version 6.1.1
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows


エディションのロールアウトの実行

エディションのロールアウトを実行すると、アクティブ・エディションが新規エディションに置き換えられます。新規エディションは、アプリケーションに対する単純な変更である場合も、より実質的な変更を含む場合もあります。 新規エディションに後方互換性がある限り、既存のクライアントに影響を与えることなく、ロールアウトを実行して、アクティブ・エディションを置き換えることができます。新規エディションのロールアウトを実行するには、まず新規のエディション情報を持つアプリケーション・エディションをインストールする必要があります。

始める前に

ロールアウトを実行するには、アプリケーション・エディションがインストールされ、開始されている必要があり、さらにコンフィギュレーター または管理者 の特権が必要です。
問題の回避: 2 つの管理コンソール上の 2 人のユーザー ID で平行してロールアウトを実行しようとすると、そのロールアウトは失敗します。gotcha
問題の回避: デプロイメント・マネージャーの要求タイムアウト値が、 システムでのロールアウトの実行とデプロイメント・マネージャーの再始動に必要な合計時間より大きくなるように、SOAP コネクターのプロパティーをチューニングしてください。 このプロパティーを設定しないと、requestTimeout 値の期限が切れたときに、ロールアウト・プロセスが失敗する可能性があります。 設定値を見積もるための式は、 ロールアウトするグループの数 * (ドレーン間隔 + 内部静止タイムアウト (およそ 5 分) + アプリケーションまたはサーバーの再始動時間 (およそ 10 分)) です。 あるいは、この値をゼロに設定して、タイムアウトを無効にすることができます。
  • wsadmin ツールを使用してロールアウトを実行する場合には、 デプロイメント・マネージャー・プロファイルの soap.client.props で com.ibm.SOAP.requestTimeout プロパティーを設定することによって、 要求タイムアウトの値を調整します。 デフォルト値は 180 秒ですが、十分に増やしてください。
  • 管理コンソールを使用してロールアウトを実行する場合には、 「システム管理」 > 「デプロイメント・マネージャー」 > 「管理サービス」 > 「JMX コネクター」 > 「SOAPConnector」 > 「カスタム・プロパティー」 > 「requestTimeout」をクリックすることによって、 要求タイムアウトの値を調整します。 デフォルト値は 600 秒ですが、十分に増やしてください。
詳しくは、 『Java Management Extensions コネクター・プロパティー』を参照してください。 gotcha

管理コンソール内でロールアウトを実行する場合には、 管理コンソールのセッション有効期限に、ロールアウト・プロセス全体の終了に必要な時間より大きい値を設定します。 要求タイムアウトの値に、ロールアウトで処理されるグループの数を掛けてください。 詳しくは、 『コンソール・セッション有効期限の変更』を参照してください。

[Version 6.1.1 and later] 問題の回避: ロールアウトを実行するには、その前に、 インストールした新しい各エディションに対して、マルチクラスター・ルーティング・ポリシーを定義する必要があります。 管理用タスクを使用して、新しいエディションのマルチクラスター・ルーティング・ポリシーを追加します。 詳しくは、ODR ルーティング・ポリシー・ルールの管理用タスク を参照してください。 gotcha

このタスクについて

Compute Grid コンポーネントを使用していて、Compute Grid アプリケーション のロールアウトを実行する場合にも、アプリケーション・エディション・マネージャーを使用できます。これらのアプリケーションは、グリッド・プログラミング・モデルの 1 つに準拠する Java™ Enterprise Edition 5 (Java EE 5) アプリケーションです。

プロシージャー

  1. 新規エディションをインストールします。 エディションのインストール で説明されたステップと同じステップを使用しますが、新規エディションの情報を指定します。例えば、「アプリケーション・エディション」フィールドに 2.0 と入力し、「アプリケーション記述」フィールドに Second edition と入力します。現行エディションに使用したものと同じデプロイメント・ターゲットを選択します。
  2. 保存し、ノードを同期します。
  3. ロールアウト設定を指定します。 「アプリケーション」 > 「エディション・コントロール・センター」 > application_nameをクリックします。新規エディション (例えば、2.0) を選択し、「ロールアウト」をクリックします。

    エンタープライズ・アプリケーションまたはその他のミドルウェア・アプリケーションの場合は次の設定を指定します。

    1. アトミック」または「グループ化」ロールアウト・タイプを選択します。

      1 グループ内のターゲット・ クラスターのメンバーのエディションを置き換えるには、「グループ・ロールアウト」を使用します。 グループ・ロールアウトは最も標準的な選択であり、クラスターに 4 つ以上のメンバーが含まれる場合に便利です。 代わりに、スクリプトを使用して、指定したグループ・サイズでグループ・ロールアウトを行うこともできます。 詳しくは、アプリケーション・エディション管理の管理用タスク についてお読みください。グループ・ロールアウト中に新規エディションが使用可能になると、すべての要求は新規エディション に送信されます。

      クラスターの半数で、同時にあるエディションを別のエディションと置き換えるには、「アトミック・ロールアウト」を使用します。 このロールアウト・タイプでは、すべてのユーザー要求が一貫性のあるアプリケーションのエディションで処理されます。 すべてのユーザー要求は一貫性のあるエディションで処理されるため、クラスターは半分のキャパシティーで稼働します。 クラスターに 4 つ以上のメンバーがある場合、グループ・ロールアウトを実行して、クラスターをより小さいグループに分割することを考えてください。また、アトミック・モードは、単一サーバーのデプロイメント・ターゲットでも使用します。 単一サーバーのデプロイメント・ターゲットでは、クラスターの残り半分に対して実行されるアクションは省略されます。アトミック・ロールアウトの開始前に、デプロイメント・ターゲットを停止した場合、選択したリセット・ストラテジーに関係なく、新規エディションがアクティブ・エディションに置き換わる時点で、そのデプロイメント・ターゲットが開始されます。 この手順を用いると、ロールアウト期間に処理される要求により高い可用性がもたらされます。

      問題の回避: アトミック・ロールアウトを実行する前に、ターゲット・サーバー・クラスターの負荷能力を判別してください。 アトミック・ロールアウトを実行すると、まずクラスターの半分で新規エディションがアクティブ化され、次にクラスターの残り半分のエディションがアクティブ化されます。クラスターの最初の半分がオフラインになり、更新されると、アプリケーション要求は、クラスターの残り半分にルーティングされます。クラスターの残り半分がロールアウト期間の負荷全体に対処できるか確認してください。gotcha
    2. リセット・ストラテジーを選択します。 リセット・ストラテジーは、アプリケーション・エディション・マネージャーに対し、 各デプロイメント・ターゲットが実行時のサーバーに新規エディションをロードする方法を指示します。

      ソフト・リセット・ストラテジーを使用すると、クラスター内の各サーバーで旧エディションが次のエディションで置き換えられるときに、そのサーバー内のアプリケーションを停止または再始動することによりアプリケーションをリセットします。ソフト・リセットは、稼働中のアプリケーション・サーバー内のアプリケーションをリサイクルすることで新規エディションをロードするので、アプリケーションのリセット実行に最も標準的で、最適な選択です。サーバーはこのプロセスの間、稼働します。ソフト・リセットの場合、ネイティブ・ライブラリーはメモリーからアンロードされません。 通常、ソフト・リセットは、ネイティブ・ライブラリーを使用していないアプリケーションの場合に安全です。 ソフト・リセットを実稼働環境で使用する場合は、アプリケーション・サーバー・プロセスをモニターして、十分な仮想メモリーがあることを確認してください。

      ハード・リセット・ストラテジーは、サーバーで次のエディションが以前のエディションに置き換えられるときに、アプリケーションにより使用されるプロセス・メモリーおよびネイティブ・ライブラリーをリフレッシュし、そのクラスターのアプリケーション・サーバー全体をリサイクルします。 このストラテジーにより、仮想ストレージを使い果たすことを防ぎ、新規バージョンのネイティブ・ライブラリーをロードできます。 新規バージョンのネイティブ・ライブラリーに依存するか、アプリケーション・サーバー全体をリサイクルすることによってのみ更新される他の依存関係に依存するエディションのロールアウトを実行する際、またはジャストインタイム (JIT) コンパイルに多量のメモリーを消費する大規模なアプリケーションがある場合、リセット・ストラテジーとしてハード・リセットを選択します。

    3. 処理待機間隔 (秒) を設定します。 処理待機間隔は HTTP セッションに対して、アプリケーションまたはサーバーがリセットされる前に完了する時間を提供します。 処理待機間隔で、リセット・ストラテジーが開始される前にアプリケーション・エディション・マネージャーが待機する時間を指定します。

      WebSphere® Virtual Enterprise に知らされていないアフィニティー (トランザクション、アクティビティー、および補償範囲など) およびアクティビティーでは、それらの作業単位が完了するまでサーバーを停止できないため、有効処理待機間隔が延長されます。WebSphere Virtual Enterprise に知らされていないアクティビティーがあるアプリケーションは、トリガーとして AppEditionManager MBean の静止で起動される通知を使用してシャットダウンの処理を開始し、そのシャットダウンが完了するまでの期間として待機処理間隔を活用します。このプロセスは、例えばデータベースで支援されるか、VMware 分散型リソース・スケジューラー (DRS) によって複製されるような持続セッションでは必要ありませんが、一時的な (メモリー内) セッションでは重要です。

      処理待機間隔の目標は、アフィニティーを持つ要求および転送中の要求を完了できるようにすることです。 一時的なセッションの損失を避けるために、アプリケーション・セッション・タイムアウト間隔 を超えるように処理待機間隔を設定します。ロールアウトが開始された後、各サーバーが更新されるとそのサーバーは新規セッションを開始できないというマーク付けがされます。 この値を 0 に設定してセッションの完了を待たないようにします。

      ソフト・リセットの場合、アプリケーション・エディションの静止マネージャーは、既存のセッションがすべて確実に完了できるよう、処理待機間隔いっぱいまで待機します。その場合、アプリケーション・エディションの静止マネージャーは、処理中のセッションが存在するかどうかに関係なく待機し、また定義された処理待機間隔の前にセッションが完了したとしても待機します。 ハード・リセットの場合、アプリケーション・エディションの静止マネージャーは、処理待機間隔いっぱいまで待機しない場合があります。サーバー上のアクティブなすべての要求が静止されたかどうかを判別できるように、Performance Monitoring Infrastructure (PMI) 統計が静止マネージャーで使用可能になります。 処理待機間隔が切れるまでにすべての要求が静止された場合、アプリケーション・エディション静止マネージャーは、処理待機間隔いっぱいまで待機する必要はありません。

      処理待機間隔により、既存のセッションが完了できるようになります。ただし処理待機間隔の終わりには、一定の時間があり、この間に転送中の要求はまだ到着できます。 このような場合、オンデマンド・ルーター (ODR) は、静止操作を完了するために 60 秒というタイムアウト値を用意しています。60 秒内に要求が終了するか、60 秒が経過すると、アプリケーションまたは (ハード・リセット・ストラテジーの場合は) サーバーが停止します。次に、転送中の要求がまだ完了していない場合、WebSphere Application Server Network Deployment は、60 秒という静止時間を用意します。この時間が経過すると、アプリケーションまたはサーバー・インスタンスが停止します。 ハード・リセット・ストラテジーのために、 WebSphere Application Server Network Deployment では、サーバー・インスタンスを停止する前に、180 秒の静止時間が設けられています。 Web コンテナーが要求の完了を待機する時間を定義するには、com.ibm.ws.webcontainer.ServletDestroyWaitTime カスタム・プロパティーを使用できます。詳しくは Web コンテナーのカスタム・プロパティーを参照してください。

      com.ibm.ejs.sm.server.quiesceTimeout カスタム・プロパティーを使用して、 サーバー・インスタンスが、シャットダウンを開始せずに要求の完了を待つ時間を定義することができます。 詳しくは、 『Java 仮想マシンのカスタム・プロパティー』を参照してください。 アプリケーション・エディションがデプロイされる各サーバー・インスタンスの com.ibm.ws.webcontainer.ServletDestroyWaitTime カスタム・プロパティーと com.ibm.ejs.sm.server.quiesceTimeout カスタム・プロパティーの両方を設定してください。

    セッション開始プロトコル (SIP) アプリケーションの場合は、次の設定を指定します。
    1. 静止ストラテジーを選択します。 静止ストラテジーは、現在のエディションをホストする古いサーバーまたはクラスター・メンバーを除去する方法を指定します。 この設定は、ロールアウトされている新規エディションには影響しません。
      • すべてのアクティブ・セッションまたはアクティブ・ダイアログが完了してからサーバーまたはクラスター・メンバーを静止します。: そのサーバーまたはクラスター・メンバーのすべてのアクティブ・セッションまたはダイアログが完了すると、サーバーまたはクラスター・メンバーを除去します。
      • 指定した間隔の後、サーバーまたはクラスター・メンバーを静止します: 指定した時間が経過した後で、サーバーまたはクラスター・メンバーを除去します。時間の量は、秒数、分数、または時間数で指定します。
      重要: ロールアウトの実行は、静的クラスターから変換された動的クラスターにデプロイされている SIP アプリケーションについてはサポートされていません。
  4. ロールアウトを開始します。OK」をクリックします。このアクションにより、旧エディションと新規エディションとの中断のない置き換えが開始されます。

結果

妥当性検査モードではないエディションについては、ロールアウトの完了後、新規エディションが現行エディションと置き換わります。 妥当性検査モードのエディションは、オリジナルのデプロイメント・ターゲットでロールアウトし、複製された環境は削除されます。 ルーティング・ルールが更新されて、新規エディションへのルーティングが開始されます。

Compute Grid アプリケーションの場合は、処理待機時間が経過した後で、ジョブ・スケジューラーが、静止されたエンドポイント上でまだ実行している (ロールアウト・アプリケーションの) ジョブを取り消します。

次に実行する作業

結果を検証するには、「アプリケーション」 > 「エディション・コントロール・センター」 > application_nameをクリックします。新規エディションは、デプロイメント・ターゲット上のアクティブ・エディションです。新規のエディションは、実行中のエディションを置き換えるため、自動的に開始されます。

妥当性検査モードのエディションのロールアウトを実行すると、バインディング名が元の値に戻されます。例えば、/clusters/cluster1-validation/jdbc/CustomerData は、/clusters/cluster1/jdbc/CustomerData に戻します。

重要: エディションの妥当性検査は、静的クラスターから変換された動的クラスターにデプロイされているアプリケーションに対しては適切に動作しません。



関連概念
アプリケーション・エディション・マネージャーの概念
関連タスク
エディションのインストール
エディションのロールバックの実行
複数エディションの並行したアクティブ化
エディションの妥当性検査
関連資料
ルーティング・ポリシーおよびサービス・ポリシー
管理のロールと特権
アプリケーション・エディション管理の管理用タスク
タスク・トピック    

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

最終更新: 2009/09/17 16時29分17秒EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/appedition/tappedroll.html