このトピックでは、アプリケーション・エディションの妥当性検査の方法について説明します。
妥当性検査モードでは、あるエディションをインストールし、実動のアプリケーション・エディションと並行して、
実際の条件でそのエディションをテストできます。
以下の例では、アプリケーションのエディション 1.0 が動的クラスターにインストールされ、活動中であり、実行されています。
エディション 2.0
が妥当性検査エディションの候補であり、非アクティブ状態で同じデプロイメント・ターゲットにインストールされています。
エディション 2.0 の妥当性検査では、エディション 2.0 ターゲットのクローンの作成、新規の動的クラスターの作成
(例えば、DC-Validation)、およびこの新規クラスターへのエディション 2.0 のマッピングを実行します。
クローンのクラスターは、クローンのサーバーを作成するためのサーバー・テンプレートとして、
既存のクラスター・メンバーを使用します。
Before you begin
新規のクローンのクラスターを開始する前に、エディション 2.0
用に固有のルーティング・ルールを定義する必要があります。
ルーティング・ルールにより、両方のエディションが並行して実行できるようになり、また妥当性検査のエディションを対象とした HTTP 要求がエディション 1.0 に干渉されることなく、妥当性検査のターゲットに正しくルーティングされます。
このシナリオでは、
BeenThere アプリケーションを使用します。
両方のアプリケーション・エディション 1.0 および 2.0 をターゲット
BTDC1 にインストールします。
動的クラスター・カスタム・プロパティー
saveClonedCluster=true を設定して、
エディションのロールアウト後に妥当性検査ターゲットを保存します。この設定をしないと、
エディションのロールアウト後に、妥当性検査ターゲットは削除されます。
RestrictionColonSymbol 妥当性検査モードでは、2 つのクラスター・メンバーのみを使用または作成できます。
妥当性検査モードのエンタープライズ・アプリケーションにルートおよびサービス・ポリシーをマップできますが、
開始して処理を維持するクラスター・メンバーは 2 つ以内です。
Why and when to perform this task
妥当性検査のクローン・ターゲットが作成されると、edition 2.0
が活動化され、ルーティング・ルールが定義されます。
そのエディションを開始、停止、および再構成することができます。
- 「アプリケーション」>「Edition control center」とクリックし、アプリケーションに
2 つのインストール済みのエディションがあり、その 1 つのみが活動中のエディションであることを確認します。
- 「BeenThere」をクリックします。
- エディション 2.0 を選択し、「Validate」をクリックします。
妥当性検査の状況ページに、BTDC1 動的クラスターの妥当性検査、およびエディション
2.0 のクローン・クラスターへのデプロイメントの各ステップが表示されます。
「edition control center」には、
エディションの 1 つが妥当性検査モードにあることが示され、「manage editions」ページには、エディション
2.0 のターゲットが動的クラスター BTDC1-Validation- になっていることが示されます。
「動的クラスター」ページには、新規の動的クラスター BTDC1-Validation
が作成されたことが示され、「アプリケーション・サーバー」ページには、クローン・サーバーが表示されます。
- 「アプリケーション」>「エンタープライズ・アプリケーション」とクリックします。
「BeenThere-edition2.0」を編集し、「サーバーにモジュールをマップ」を選択します。
エディション 2.0 が妥当性検査クラスターにマップされていることを確認します。
「EJB 参照を Bean にマップ」の詳細ビューで、Java Naming and Directory Interface (JNDI)
名が新規のクローン・ターゲット名のために調整されていることを確認します。
元のデプロイメント・ターゲット名に基づいた完全修飾のバインディングがあるアプリケーション・エディションを、
妥当性検査のデプロイメント・ターゲットで正常に作動させるためには、そのバインディング名を、
妥当性検査のデプロイメント・ターゲット名に
基づいた完全修飾のバインディング名を反映するよう変更する必要があります。
例えば、/clusters/clusterb1/jdbc/CustomerData にバインドされたリソース参照があるアプリケーションでは、デプロイメント・ターゲットのクローンで実行するようにアプリケーションを準備する際に、そのバインディングを /clusters/cluster1-validation/jdbc/CustomerData に変更しておく必要があります。
- 妥当性検査のクラスターを開始して、ご使用のルーティング・ルールを適用し、edition 2.0
にテスト負荷をかけて、実動の edition
1.0 でそれをテストします。
edition 2.0 のテストが完了し、edition 1.0 を 2.0
で置き換える場合は、以下を実行します。
- 妥当性検査ターゲット (例えば、BTDC1-Validation) を停止します。
- edition 2.0 に固有のルーティング・ルールを削除し、
BeenThere アプリケーションに対するすべての要求を単一のエディションにルーティングするようにします。
変更を保管し、ノードを同期します。
- 「アプリケーション」>「Manage editions」とクリックします。
- BeenThere アプリケーションの edition 2.0 を選択し、
「Rollout」をクリックします。
Result
これにより、中断のない edition 1.0 から edition 2.0
への置き換えが起動されます。 ロールアウト時には、edition
2.0 が元のデプロイメント・ターゲット (例えば、BTDC1)
に再ターゲットされ、その状態は、妥当性検査から活動中に遷移します。
What to do next
エディションの妥当性検査のテストが正常に完了したら、エディションのロールアウトを使用して、
新規エディションを実稼働環境にロールアウトします。