エディションのロールアウトを実行すると、アクティブ・エディションが新規エディションに置き換えられます。新規エディションは、アプリケーションに対する単純な変更である場合も、より実質的な変更を含む場合もあります。
新規エディションが前のバージョンと互換である場合、
既存のクライアントに影響を与えることなく、ロールアウトを実行してアクティブ・エディションを
置き換えることができます。新規エディションのロールアウトを実行するには、まず新規のエディション情報を持つアプリケーション・エディションをインストールする必要があります。
始める前に
ロールアウトを実行するには、アプリケーション・エディションがインストールされ、開始されている必要があり、さらに
コンフィギュレーター または
管理者 の特権が必要です。
- 2 つの管理コンソール上の 2 人のユーザー ID で平行してロールアウトを実行しようとすると、そのロールアウトは失敗します。
- デプロイメント・マネージャーの要求タイムアウト値が、
システムでのロールアウトの実行とデプロイメント・マネージャーの再始動に必要な合計時間より大きくなるように、SOAP コネクターのプロパティーをチューニングしてください。
このプロパティーを設定しないと、requestTimeout 値の期限が切れたときに、ロールアウト・プロセスが失敗する可能性があります。
設定値を見積もるための式は、
ロールアウトするグループの数 * (ドレーン間隔
+ 内部静止タイムアウト (およそ 5 分) + アプリケーションまたはサーバーの再始動時間 (およそ 10 分)) です。
あるいは、この値をゼロに設定して、タイムアウトを無効にすることができます。
- 管理コンソール内でロールアウトを実行する場合には、
管理コンソールのセッション有効期限に、ロールアウト・プロセス全体の終了に必要な時間より大きい値を設定します。
要求タイムアウトの値に、ロールアウトで処理されるグループの数を掛けてください。
管理コンソールのセッション有効期限について詳しくは、
『コンソール・セッション有効期限の変更』を参照してください。
- ロールアウトを実行するには、その前に、
インストールした新しい各エディションに対して、マルチクラスター・ルーティング・ポリシーを定義する必要があります。
管理用タスクを使用して、新しいエディションのマルチクラスター・ルーティング・ポリシーを追加します。
マルチクラスター・ルーティング・ポリシーについて詳しくは、
『ODR ルーティング・ポリシー・ルールの管理用タスク』を参照してください。
このタスクについて
バッチ・アプリケーションへのロールアウトを実行したい場合にも、
アプリケーション・エディション・マネージャーを使用できます。これらのアプリケーションは、バッチ プログラミング・モデルの 1 つに準拠する Java Enterprise Edition 5 (Java EE
5) アプリケーションです。
手順
- 新規エディションをインストールします。 『アプリケーション・エディションのインストール』に説明されている
のと同じステップを使用しますが、新規エディションの情報を指定してください。例えば、「アプリケーション・エディション」フィールドに 2.0 と入力し、「アプリケーション記述」フィールドに Second edition と入力します。現行エディションに使用したものと同じデプロイメント・ターゲットを選択します。
- 保存し、ノードを同期します。
- ロールアウト設定を指定します。 をクリックします。新規エディション (例えば、2.0) を選択し、「ロールアウト」をクリックします。
エンタープライズ・アプリケーションまたはその他のミドルウェア・アプリケーションの場合は次の設定を指定します。
- 「アトミック」または「グループ化」ロールアウト・タイプを選択します。
1 グループ内のターゲット・ クラスターのメンバーのエディションを置き換えるには、「グループ・ロールアウト」を使用します。
グループ・ロールアウトは最も標準的な選択であり、クラスターに 4 つ以上のメンバーが含まれる場合に便利です。
代わりに、スクリプトを使用して、指定したグループ・サイズでグループ・ロールアウトを行うこともできます。
グループ・ロールアウトについて詳しくは、
『アプリケーション・エディション管理の管理用タスク』を参照してください。グループ・ロールアウト中に新規エディションが使用可能になると、すべての要求は新規エディション
に送信されます。
クラスターの半数で、同時にあるエディションを別のエディションと置き換えるには、「アトミック・ロールアウト」を使用します。
このロールアウト・タイプでは、すべてのユーザー要求が一貫性のあるアプリケーションのエディションで処理されます。
すべてのユーザー要求は一貫性のあるエディションで処理されるため、クラスターは半分のキャパシティーで稼働します。
クラスターに 4 つ以上のメンバーがある場合、グループ・ロールアウトを実行して、クラスターをより小さいグループに分割することを考えてください。また、アトミック・モードは、単一サーバーのデプロイメント・ターゲットでも使用します。
単一サーバーのデプロイメント・ターゲットでは、クラスターの残り半分に対して実行されるアクションは省略されます。アトミック・ロールアウトの開始前に、デプロイメント・ターゲットを停止した場合、選択したリセット・ストラテジーに関係なく、新規エディションがアクティブ・エディションに置き換わる時点で、そのデプロイメント・ターゲットが開始されます。
この手順を用いると、ロールアウト期間に処理される要求により高い可用性がもたらされます。
トラブルの回避 (Avoid trouble): アトミック・ロールアウトを実行する前に、ターゲット・サーバー・クラスターの負荷能力を判別してください。
アトミック・ロールアウトを実行すると、まずクラスターの半分で新規エディションがアクティブ化され、次にクラスターの残り半分のエディションがアクティブ化されます。クラスターの最初の半分がオフラインになり、更新されると、アプリケーション要求は、クラスターの残り半分にルーティングされます。クラスターの残り半分がロールアウト期間の負荷全体に対処できるか確認してください。
gotcha
- リセット・ストラテジーを選択します。 リセット・ストラテジーは、アプリケーション・エディション・マネージャーに対し、
各デプロイメント・ターゲットが実行時のサーバーに新規エディションをロードする方法を指示します。
ソフト・リセット・ストラテジーを使用すると、クラスター内の各サーバーで旧エディションが次のエディションで置き換えられるときに、そのサーバー内のアプリケーションを停止または再始動することによりアプリケーションをリセットします。ソフト・リセットは、稼働中のアプリケーション・サーバー内のアプリケーションをリサイクルすることで新規エディションをロードするので、アプリケーションのリセット実行に最も標準的で、最適な選択です。サーバーはこのプロセスの間、稼働します。ソフト・リセットの場合、ネイティブ・ライブラリーはメモリーからアンロードされません。
通常、ソフト・リセットは、ネイティブ・ライブラリーを使用していないアプリケーションの場合に安全です。
ソフト・リセットを実稼働環境で使用する場合は、アプリケーション・サーバー・プロセスをモニターして、十分な仮想メモリーがあることを確認してください。
ハード・リセット・ストラテジーは、サーバーで次のエディションが以前のエディションに置き換えられるときに、アプリケーションにより使用されるプロセス・メモリーおよびネイティブ・ライブラリーをリフレッシュし、そのクラスターのアプリケーション・サーバー全体をリサイクルします。
このストラテジーにより、仮想ストレージを使い果たすことを防ぎ、新規バージョンのネイティブ・ライブラリーをロードできます。
新規バージョンのネイティブ・ライブラリーに依存するか、アプリケーション・サーバー全体をリサイクルすることによってのみ更新される他の依存関係に依存するエディションのロールアウトを実行する際、またはジャストインタイム (JIT) コンパイルに多量のメモリーを消費する大規模なアプリケーションがある場合、リセット・ストラテジーとしてハード・リセットを選択します。
- 処理待機間隔 (秒) を設定します。 処理待機間隔は HTTP セッションに対して、アプリケーションまたはサーバーがリセットされる前に完了する時間を提供します。
処理待機間隔で、リセット・ストラテジーが開始される前にアプリケーション・エディション・マネージャーが待機する時間を指定します。
Intelligent Management に知らされていないアフィニティー (トランザクション、アクティビティー、および補償範囲など) およびアクティビティーでは、それらの作業単位が完了するまでサーバーを停止できないため、有効処理待機間隔が延長されます。Intelligent Management に知らされていないアクティビティーがあるアプリケーションは、AppEditionManager MBean 静止で
起動される通知をトリガーとして使用してシャットダウン処理を開始し、そのシャットダウンが
完了するまでの期間として処理待機間隔を使用することができます。このプロセスは、例えばデータベースで支援されるか、VMware 分散型リソース・スケジューラー (DRS) によって複製されるような持続セッションでは必要ありませんが、一時的な (メモリー内) セッションでは重要です。
処理待機間隔の目標は、アフィニティーを持つ要求および転送中の要求を完了できるようにすることです。
一時的なセッションの損失を避けるために、アプリケーション・セッション・タイムアウト間隔
を超えるように処理待機間隔を設定します。ロールアウトが開始された後、各サーバーが更新されるとそのサーバーは新規セッションを開始できないというマーク付けがされます。
転送中のすべての要求についてセッションが完了するまで待機する場合は、この値を 0 に設定します。転送中のすべての要求について処理待機間隔またはセッションが完了するまで待機するには、処理待機間隔を 0 より大きい値に設定します。
アプリケーション・エディションの静止マネージャーは、処理待機間隔いっぱいまで待機しない場合があります。サーバー上のアクティブなすべての要求が静止されたかどうかを静止マネージャーが判別するために、Performance Monitoring Infrastructure (PMI) 統計が使用可能です。処理待機間隔が切れるまでにすべての要求が静止された場合、アプリケーション・エディションの静止マネージャーは、処理待機間隔いっぱいまで待機する必要はありません。ソフト・リセットの実行を処理待機間隔いっぱいまで待つよう強制するためには、デプロイメント・マネージャーで appedition.rollout.softreset.fulldrainageinterval システム・プロパティーを true に設定することができます。
処理待機間隔により、既存のセッションが完了できるようになります。ただし、処理待機間隔の終わりには、転送中の要求がまだ到着することのできる一定の期間があります。
このような場合、オンデマンド・ルーター (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) アプリケーションの場合は、次の設定を指定します。- 静止ストラテジーを選択します。 静止ストラテジーは、現在のエディションをホスティングする古いサーバーまたはクラスター・メンバーを除去する方法を指定します。
この設定は、ロールアウトされている新規エディションには影響しません。
- すべてのアクティブ・セッションまたはダイアログが完了した後、サーバーまたはクラスター・メンバーを静止する。
- そのサーバーまたはクラスター・メンバーのすべてのアクティブ・セッションおよびダイアログが完了すると、サーバーまたはクラスター・メンバーを除去します。
- 指定された間隔の後、サーバーまたはクラスター・メンバーを静止する。
- 指定された時間が経過した後で、サーバーまたはクラスター・メンバーを除去します。
時間の量は、秒数、分数、または時間数で指定します。
重要: ロールアウトの実行は、静的クラスターから変換された動的クラスターにデプロイされている SIP アプリケーションについてはサポートされていません。
- ロールアウトを開始します。 「OK」をクリックします。このアクションにより、旧エディションと新規エディションとの中断のない置き換えが開始されます。
タスクの結果
妥当性検査モードではないエディションについては、ロールアウトの完了後、新規エディションが現行エディションと置き換わります。
妥当性検査モードのエディションは、オリジナルのデプロイメント・ターゲットでロールアウトし、複製された環境は削除されます。
ルーティング・ルールが更新されて、新規エディションへのルーティングが開始されます。
アプリケーション・ロールアウト・プロセスの間、ターゲットの最初のグループで発生するエラーは、その後のグループで発生するエラーとは異なる方法で処理されます。アトミック・ロールアウトでは、最初のグループは、新しいエディションがアクティブ化される、ターゲットの最初の半分です。グループ・ロールアウトでは、最初のグループは、新しいエディションがアクティブ化される、ターゲットの最初のグループを指します。
ターゲットの最初のグループでロールアウト中にエラーが発生した場合 (例えばアプリケーションやサーバーが始動しないなど)、ロールアウト・プロセスは失敗します。この場合、現行のアプリケーション・エディションはアクティブ状態のままとなります。
ターゲットの最初のグループでロールアウト後にエラーが発生した場合、ロールアウト・プロセスは正常に完了します。この場合、新しいアプリケーション・エディションがアクティブ状態になります。古いアプリケーション・エディションは非アクティブ状態へ移行します。
次のタスク
結果を検証するには、をクリックします。新規エディションは、デプロイメント・ターゲット上のアクティブ・エディションです。新規のエディションは、実行中のエディションを置き換えるため、自動的に開始されます。
妥当性検査モードのエディションのロールアウトを実行すると、バインディング名が元の値に戻されます。例えば、/clusters/cluster1-validation/jdbc/CustomerData は、/clusters/cluster1/jdbc/CustomerData に戻します。