[AIX Solaris HP-UX Linux Windows][z/OS]

エディションの妥当性検査

エディションの妥当性検査とは、新規エディションが使用可能で、実動環境に移って現行エディションを置き換えられるようになっているかどうかを判別するプロセスです。ご使用の実動アプリケーション・エディションが要求の処理を続行しながら、現実に近い条件の下で新規エディションをインストールし、妥当性検査できます。

始める前に

  • アプリケーションのすべてのモジュールが同じデプロイメント・ターゲットにデプロイされていることを確認します。
  • エディション 2.0 の固有のルーティング・ルールを定義します。ルーティング・ルールにより、エディションが並行して実行できるようになり、また妥当性検査のエディションを対象とした HTTP 要求がエディション 1.0 に干渉されることなく、妥当性検査のターゲットに正しくルーティングされます。このシナリオでは、my_application アプリケーションを使用します。両方のアプリケーション・エディション 1.0 および 2.0 を dynamic_cluster_1 動的クラスターにインストールします。ルーティング・ルール について詳しくは、『アプリケーション・エディション用ルーティング・ポリシーの作成』を参照してください。
  • 複製された妥当性検査クラスターの動作モードを、実動クラスターと異なるモードに設定するには、管理コンソールで VALIDATION_OPERATIONALMODE カスタム・プロパティーを作成します。作成しなかった場合は、妥当性検査クラスターは、その作成後に実動クラスターと同じ動作モードに設定されます。値は、automaticmanual、または、supervised に設定します。その他の値を指定するか、または値を指定しなかった場合は、妥当性検査動的クラスターは手動モードに設定されます。
    制約事項: 妥当性検査モードでは、2 つのクラスター・メンバーのみを使用または作成できます。 妥当性検査モードのアプリケーションにルーティング・ポリシーおよびサービス・ポリシーをマップできますが、 開始して処理を維持するクラスター・メンバーは 2 つ以内です。この設定は、妥当性検査クラスターを作成した後で、動的クラスターの最大および最小インスタンス数を変更することにより、上書きできます。
  • モニターまたはオペレーターのロールを持つユーザーの 場合、表示できるのはアプリケーション・エディション・マネージャー情報 のみです。コンフィギュレーターまたは管理者のロールを持つユ ーザーの場合は、アプリケーション・エディション・マネージャーのすべて の構成特権があります。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): エディションの妥当性検査を行う前に、 ブラウザーを再始動します。ブラウザーを再始動することによって、前のセッションの有効期限が切れること、 および、妥当性検査されるアプリケーションに要求がルーティングされることを 確実にできます。gotcha
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 妥当性検査が失敗する可能性があるため、妥当性検査されるアプリケーションが Web サーバーにデプロイされていないことを確認してください。 アプリケーションは、適切な妥当性検査のために、アプリケーション・サーバーにデプロイされる必要があります。gotcha

このタスクについて

エディションでどのように妥当性検査が実行されるかの例として、次のシナリオを考えてください。エディション 1.0 のアプリケーションが動的クラスターにインストールされ、アクティブであり、実行中です。エディション 2.0 が妥当性検査エディションの候補であり、非アクティブ状態で同じデプロイメント・ターゲットにインストールされています。 エディション 2.0 の妥当性検査を行うと、エディション 2.0 のデプロイメント・ターゲットが複製されます。例えば、妥当性検査で新規動的クラスター (DC-Validation 動的クラスターなど) が作成され、エディション 2.0 がこの新規クラスターにマップされることがあります。クローンのクラスターは、クローンのサーバーを作成するためのサーバー・テンプレートとして、 既存のクラスター・メンバーを使用します。

妥当性検査のクローン・ターゲットが作成されると、edition 2.0 がアクティブ化され、ルーティング・ルールが定義されます。 そのエディションを開始、停止、および再構成することができます。

手順

  1. 「アプリケーション」 > 「エディション・コントロール・センター」とクリックし、アプリケーションに 2 つのインストール済みのエディションがあり、その 1 つのみがアクティブなエディションであることを確認します。
  2. オプション: ご使用の実動クラスターとは異なる動作モードの妥当性検査クラスターを作成する場合は、その実動クラスターに VALIDATION_OPERATIONALMODE カスタム・プロパティーを定義できます。妥当性検査クラスターをサービス統合バス (SIB) に追加します。 このカスタム・プロパティーを定義しない場合は、妥当性検査クラスターの動作モードは実動クラスターと同じになります。
  3. Enterprise JavaBeans (EJB) 参照バインディングを更新して、新規クラスター名を指定します。アプリケーションを妥当性検査クラスターからロールアウトする前に、バインディングを変更して元の値に戻す必要があります。
  4. my_application アプリケーションをクリックします。
  5. 「edition 2.0」を選択して、「妥当性検査」をクリックします。 妥当性検査の状況ページには、dynamic_cluster_1 動的クラスターを妥当性検査するための各ステップ、および edition 2.0 をクローン・クラスターへデプロイするための各ステップが表示されます。アプリケーション・エディション・コントロール・センターには、エディションの 1 つが妥当性検査モードにあることが示され、「エディションの管理」ページには、エディション 2.0 のターゲットが dynamic_cluster_1-Validation 動的クラスターになっていることが示されます。「動的クラスター」ページには、dynamic_cluster_1-Validation 動的クラスターが作成され、「サーバー」ページには、クローン・サーバーが表示されます。
    ヒント: ロールアウトの実行後に妥当性検査クラスターを保存する場合、妥当性検査クラスターで saveClonedCluster カスタム・プロパティーを作成できます。このプロパティーを作成しないと、 エディションのロールアウト実行後、または妥当性検査ターゲットのすべてのアプリケーションで妥当性検査の取り消し後に、妥当性検査ターゲットが削除されます。例えば、妥当性検査ターゲットに 2 つのアプリケーションがデプロイされている場合、そのうちの 1 つのアプリケーションが妥当性検査され、ロールアウトされても、残りのアプリケーションが妥当性検査されない限り、妥当性検査ターゲットは削除されません。 saveClonedCluster カスタム・プロパティーは、動的クラスターだけに適用されます。詳しくは、『アプリケーション・エディション・マネージャーのカスタム・プロパティー』を 参照してください。
  6. 妥当性検査が正しく開始されたことを確認します。 「アプリケーション」 > 「エンタープライズ・アプリケーション」または「アプリケーション」 > 「すべてのアプリケーション」をクリックします。「my_application-edition2.0」アプリケーションを編集します。
    • PHP および WebSphere® Application Server Community Edition アプリケーションの場合:

      コンテキスト・ルート、デプロイメント・ターゲットなどがクローン・クラスターを指していることを確認します。

    • エンタープライズ (Java™ Platform, Enterprise Edition (Java EE)) アプリケーションの場合:

      「モジュールの管理」を選択します。エディション 2.0 が妥当性検査クラスターにマップされていることを確認します。 「Enterprise JavaBeans (EJB) 参照を Bean にマップ」の詳細ビューで、Java Naming and Directory Interface (JNDI) 名が新規のクローン・ターゲット名のために調整されていることを確認します。

      元のデプロイメント・ターゲット名に基づいた完全修飾のバインディングがあるアプリケーション・エディションを、 妥当性検査のデプロイメント・ターゲットで正常に作動させるためには、そのバインディング名を、 妥当性検査のデプロイメント・ターゲット名に 基づいた完全修飾のバインディング名を反映するよう変更する必要があります。例えば、/clusters/clusterb1/jdbc/CustomerData にバインドされたリソース参照があるアプリケーションでは、デプロイメント・ターゲットのクローンで実行するようにアプリケーションを準備する際に、そのバインディングを /clusters/cluster1-validation/jdbc/CustomerData に変更しておく必要があります。

  7. 妥当性検査クラスターの作成の詳細にナビゲートして、内容を確認します。
    「動的クラスター」 > 「DC_Name」> 「構成」タブとクリックします。妥当性検査クラスターで以下の設定がコピーされていることに注目してください。
    • クラスター・インスタンスの最小数
    • ノード上のインスタンスの垂直スタッキング
    • メンバーシップ・ポリシー
    以下の詳細情報に注意してください。
    • クラスター・インスタンスの最大数が「2」に設定されています。 これは、妥当性検査クラスターの制限です。
    • 分離設定はコピーされず、デフォルトに設定されます。
    • 動作モードはコピーされますが、VALIDATION_OPERATIONALMODE カスタム・プロパティーによってオーバーライドすることができます。
    • 動的クラスターのカスタム・プロパティーは妥当性検査クラスターにコピーされません。
      注: 実動クラスターのカスタム・プロパティーは、妥当性検査クラスターに伝搬されません。 動的クラスターのカスタム・プロパティーで必要なものがある場合には、妥当性検査クラスターの作成後に設定してください。
  8. 新規エディションをテストします。 妥当性検査クラスターを始動し、適切なルーティング・ルールを適用して、edition 2.0 エディションに要求負荷を送り、そのエディションをテストします。edition 1.0 エディションは実動状態のままです。

次のタスク

edition 2.0 エディションのテストが正常に完了したら、edition 1.0 エディションを edition 2.0 エディションで置き換えることができます。テスト中にエラーが発生した場合、妥当性検査モードを取り消すことができます。
  • edition 1.0edition 2.0 で置き換えるには、以下を実行します。
    1. 妥当性検査ターゲット (例えば、dynamic_cluster_1-Validation) を停止します。
    2. edition 2.0 に固有のルーティング・ルールを削除し、アプリケーションに対するすべての要求を単一のエディションにルーティングするようにします。
    3. 変更を保存し、ノードを同期します。
    4. 新規エディションのロールアウトを実行します。「アプリケーション」 > 「エディション・コントロール・センター」 > application_nameをクリックします。「edition 2.0」を選択し、「ロールアウト」をクリックします。ロールアウト時には、edition 2.0 が元のデプロイメント・ターゲット (例えば、dynamic_cluster_1) に再ターゲットされます。エディションの状態は、妥当性検査からアクティブに遷移します。
  • edition 2.0 にエラーがある場合、妥当性検査モードを取り消して、edition 2.0 を元の非アクティブ状態に戻すことができます。その結果として、妥当性検査用に作成された重複動的クラスターは除去されます。 妥当性検査モードの取り消しについて詳しくは、『アプリケーションの妥当性検査の取り消し』を 参照してください。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twve_appedval
ファイル名:twve_appedval.html