このトピックでは、活動中のエディションを新規のエディションに置き換える方法について説明します。
新規エディションには、バグ修正などのアプリケーションに対する単純な変更や、より実質的な変更があります。
新規エディションが後方互換である限り、既存のクライアントに影響を与えることなく、ロールアウトして活動中のエディションと置き換えることができます。
新規エディションをロールアウトするには、最初に新規のエディション情報のアプリケーション・エディションをインストールする必要があります。
Before you begin
任意のアプリケーション・エディションがインストール済みであり、開始されていることを事前に確認してください。
Why and when to perform this task
エディションをロールアウトするには、以下を実行します。
- 「アプリケーション」>「新規アプリケーションのインストール」をクリックします。
- インストール対象である新規の EAR ファイルを指定し、「次へ」をクリックします。
- 「Application Edition」フィールドで、新規エディションの情報を指定します。
例えば、2.0 と入力します。
- 「Application Description」フィールドで、インストール対象である新規エディションのタイプを指定します。
例えば、Second edition と入力します。
- 残りのフィールドに入力し、「次へ」をクリックします。
アプリケーション・インストール・ウィザードの使用について詳しくは、WebSphere Application Server インフォメーション・センターを参照してください。
- 「サーバーにモジュールをマップ」ページで、「クラスターおよびサーバー」リストから、現行のエディションで使用されていた同じデプロイメント・ターゲットを選択します。
デプロイメント・ターゲットのタイプ (動的クラスター、静的クラスター、またはスタンドアロン・サーバー) に関係なく、同じ基本的手順がエディションのロールアウトに適用されます。
この解説では、動的クラスター「BTDC1」をクリックします。
- 「Clone existing work classes from this application edition 」リストから、「エディション 1.0」作業クラスを選択し、「次へ」をクリックします。
アプリケーション・エディションをインストールすると、デフォルトの作業クラスが割り当てられます。
作業クラスにより、そのアプリケーション・エディションに対するデフォルトのルーティング・ルールが設定されます。
アプリケーションの作業クラスは、そのアプリケーションのルーティング・ポリシーを構成します。
後続のエディションのインストール時には、選択に応じて作業クラスを割り当てることができます。
ただし、エディションをロールアウトする場合には、同じ作業クラス情報を保持することが推奨されます。
それぞれのエディションには、独立した作業クラス定義があります。
この解説では、エディション 1.0 の作業クラスのクローンを作成し、エディション 2.0 の作業クラスを設定します。
- インストール・ウィザードを完了します。
- 保管し、ノードを同期します。
- 「アプリケーション」>「Edition control center」をクリックします。
- 新規エディション edition 2.0 を選択し、「Rollout」をクリックします。
「Atomic」または「Grouped」を選択します。
そのグループ内のターゲット・クラスターのメンバーのエディションを置き換えるには、グループ・ロールアウトを使用します。
代わりに、スクリプトを使用して、指定したサイズでグループ・ロールアウトを行うこともできます。
詳しくは、アプリケーション・エディション管理のための AdminTask
を参照してください。グループ・ロールアウト時には、新旧のエディションが完全に置き換わるまで、ユーザーはいずれかのエディションにより処理されます。
同時にクラスターの半数で新旧エディションの置き換えを行うには、アトミック・ロールアウトを使用します。
これにより、すべてのユーザー要求が一貫性のあるアプリケーションのエディションで処理されます。
ただし、この時は、クラスターが半分の能力で実行されることになります。
ご使用のクラスターが大規模である場合は、グループ・ロールアウトの使用がより適している可能性があります。
また、アトミック・モードは、単一サーバーのデプロイメント・ターゲットでも使用できますが、
省略されている残り半分のクラスター に対してアクションが実行されます。
リセット・ストラテジーを選択します。
リセット・ストラテジーは、アプリケーション・エディション・マネージャーに対し、
各デプロイメント・ターゲットが実行時のサーバーに新規エディションをロードする方法を指示します。
ソフト・ストラテジーを使用すると、クラスター内の各サーバーで旧エディションが次のエディションで置き換えられるときに、そのサーバー内のアプリケーションを停止または再始動することによりアプリケーションをリセットします。
ソフト・リセットの場合、ネイティブ・ライブラリーはメモリーからアンロードされません。
通常、ソフト・リセットは、ネイティブ・ライブラリーを使用していないアプリケーションの場合に安全です。
ソフト・リセットを実稼働環境で使用する場合は、アプリケーション・サーバー・プロセスをモニターして、十分な仮想メモリーがあることを確認する必要があります。
ハード・リセットは、アプリケーションで使用されているプロセス・メモリーおよびすべてのネイティブ・ライブラリーの両方をリフレッシュして、アプリケーション・サーバー全体をリサイクルします。
これにより、仮想ストレージの使い果たしが防止され、新規バージョンのネイティブ・ライブラリーをロードできます。
依存する新規バージョンのネイティブ・ライブラリーが付随するアプリケーション・エディションをロールアウトする場合は、リセット・ストラテジーとしてハード・リセットを選択する必要があります。
ハード・ストラテジーを使用すると、クラスター内の各サーバーで前のエディションが次のエディションで置き換えられるときに、そのサーバーを停止または再始動することによりアプリケーションをリセットします。
- 処理待機間隔 (秒) を設定します。
処理待機間隔は、ロールアウトの処理が開始されてからリセット・ストラテジーが開始されるまでの、アプリケーション・サーバーがそのサーバーとアフィニティーがあるクライアントにサービスを提供する時間を指定します。
WebSphere Extended Deployment に知らされていないアフィニティー (トランザクション、アクティビティー、および補償範囲など) およびアクティビティーでは、それらの作業単位が完了するまでサーバーを停止できないため、有効処理待機間隔が延長されます。
Extended Deployment に知らされていないアクティビティーがあるアプリケーションは、トリガーとして AppEditionManager MBean の静止で起動される通知を使用してシャットダウンの処理を開始し、そのシャットダウンが完了するまでの期間として待機処理間隔を活用します。
- 「OK」をクリックします。 これにより、中断のない edition 1.0 から edition 2.0 への置き換えが起動されます。
Result
妥当性検査中のエディションがオリジナルのデプロイメント・ターゲットにロールアウトされ、クローンの環境が削除されます。
ロールアウト時に障害が発生した場合は、アプリケーション・エディション・マネージャーにより、実行されたアクションが元に戻されます。
例えば、3 つのメンバーのクラスターの 3 つのサーバーのうちの 2 つでは edition 1.0 が edition 2.0 に置き換えられたものの、3 番目のサーバーでのエディションの置き換え時に障害が発生した場合には、アプリケーション・エディション・マネージャーにより、最初と 2 番目のサーバーの edition 2.0 が edition
1.0 に置き換わります。
What to do next
この結果を表示するには、エディション・コントロール・センターに戻り、ご使用のアプリケーションを選択して「
Manage edition deployments」をクリックします。
Edition 2.0 が
1.0 を置き換え、デプロイメント・ターゲット
BTDC1 の活動中のエディションになります。
新規のエディションは、実行中のエディションを置き換えるため、自動的に開始されます。
妥当性検査モードのアプリケーション・エディションがロールアウトされる場合は、バインディング名をオリジナルに戻す必要があります。
例えば、/clusters/cluster1-validation/jdbc/CustomerData は、/clusters/cluster1/jdbc/CustomerData に戻します。