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


アプリケーション・エディション・マネージャーの概念

アプリケーション・エディション・マネージャーのバージョンとエディションの違い、アプリケーションのデプロイ方法とアップグレードの方法、およびエディションの妥当性検査と互換性について理解することで、アプリケーションのデプロイメントを管理するのに、アプリケーション・エディション・マネージャーをフルに活用できるようになります。

非管理対象 Web アプリケーションは、エディションを使用して定義できます。ただし、それらのアプリケーションの場合、ロールアウトを実行することも、妥当性検査モードにすることもできません。非管理対象 Web アプリケーションはサポートされてはいますが、補助ライフサイクル管理のアプリケーションとしての性格上、すべての機能を使用できるわけではありません。

バージョンとエディション

バージョン およびエディション という用語により、開発とビルドの環境で起こることと、デプロイメントと操作の環境で起こることを区別できます。バージョンとはインターフェース、機能、実装、またはアプリケーション全体などの連続した世代のことです。バージョンは開発とビルドの概念ともいえます。

エディションとは連続したデプロイメントの世代であり、例えば、バージョンの成果物の特定のセットのデプロイメントです。エディションは、デプロイメントと操作に関する概念ともいえます。

アプリケーション・エディション

アプリケーション・エディション とは、特定のアプリケーションの固有のデプロイメントのことです。 WebSphere® Application Server の管理環境において、アプリケーション・エディションとは、アプリケーション名とエディション名の組み合わせで一意的に識別されるアプリケーションです。同じアプリケーションの複数のエディションには、同一のアプリケーション名が付けられますが、エディション名は異なります。 エディション名には、1.02.0 などの数値を使用することも、 first editionblue edition などの記述的なものを使用することもできます。

ベース・エディション

ベース・エディション とは、関連するエディション情報のない、デプロイ済みアプリケーションのことです。 例えば、製品セルにアプリケーション・エディション・マネージャー・サポートを 追加する前にインストールされたアプリケーションは、アプリケーション・エディション・マネージャーでは ベース・エディションとして表示されます。

エディションのアクティベーション

エディションのアクティベーション では、アプリケーションのエディションが保持できる 2 つの状態を区別します。 あるエディションは、最初のインストール時には非アクティブ 状態になっています。アクティブ 状態になっているエディションしか開始できません。非アクティブからアクティブへの移行を、アクティブ化 と呼びます。

並行したアクティベーション

並行したアクティベーション という状態になるのは、同じアプリケーションの複数のエディションが同時にアクティブになり、開始された場合です。並行してアクティブなエディションでは、あるユーザーが 1 つ目のエディションにアクセスし、別のユーザーが他のエディションにアクセスすることが可能になります。 例えば、あるアプリケーションの新規エディションの導入時に、 選択したユーザーのグループのみにそのエディションをテストさせ、 すべてのユーザーにはアクセスを提供しない場合などです。並行したアクティベーションでは、エディションにアクセスするユーザーを区別するように、ルーティング・ポリシー を設定する必要があります。 ルーティング・ポリシーは、アプリケーションの構成メタデータの一部として保管されています。また、ルーティング・ポリシーにより、あいまいさを排し、制御を受け取るエディションを判別します。 以下の例は、並行してアクティブになっているエディションの図です。

図 1. 並行してアクティブになっているエディション 図 1 は、並行してアクティブ化された同一アプリケーションの複数エディションを示しています

アプリケーションのアップグレードおよびデプロイメント

多くのビジネス・アプリケーションには、一定の可用性が必要です。 アプリケーションの可用性に関する標準では、 アプリケーションがアプリケーション・サーバー・クラスターにデプロイされるものと表明されています。 クラスターの冗長性は、連続可用性を提供する上で不可欠です。 中断のないアプリケーションのアップグレード とは、アプリケーションの連続可用性を維持しながらアップグレードを実行する機能を意味します。 アプリケーションのアップグレード中にも、アプリケーションのユーザーにサービスが提供されます。

エディション・ロールアウト

エディションのロールアウト を実行すると、アクティブ・エディションが新規エディションに置き換えられます。中断のないアプリケーションのアップグレードを行えるように、エディションのロールアウトの実行時には、以下のことが行われます。
  • そのサーバーが新しい要求を受信できないようにする。
  • 特定のサーバーでのアプリケーションに対する要求を静止する。
  • 現在アクティブのエディションを停止する。
  • 新規エディションを開始する。
  • そのエディションに対して要求のフローを再開する。
アプリケーション・サーバー・クラスター全体を通じてエディションのロールアウトを実行する場合、そのクラスター内の一連のサーバー全体を通じて次のアクティビティーを完了します。

グループ・ロールアウト

ターゲット・クラスターのロールアウトを実行する場合、そのクラスターをグループに分割し、同時に処理するノードの数を指定するグループ・サイズを定義することができます。グループのロールアウトを実行すると、結果的に、各グループ内のサーバーの新規エディションへのアップグレードが同時に実行されることになります。そのグループ内の各サーバーは、静止状態となり、停止されて、さらにリセットされます。管理コンソールでは、一度に 1 つのグループにしかロールアウトを実行できません。新規エディションの任意のメンバーが使用可能になると、すべての要求 が新規エディションにルーティングされます。

エディションのロールアウトの実行時、クラスター内のサーバーには、旧エディションから新規エディションへ移行しているものもあれば、移行途中のものもあれば、また移行を開始していないものもあります。すべてのアプリケーション要求は、 要求されたアプリケーションの最新のエディションのアクティブなインスタンスが実行され ている任意のサーバーに送信されます。 例えば、エディション 1.0 から 2.0 にロールアウトを実行した場合、エディション 2.0 がサーバーで使用可能になると、すべてのアプリケーション要求はエディション 2.0 によって処理されます。引き続きエディション 1.0 を実行しているすべてのサーバーは、このサーバーが エディション 2.0 に更新されるまで要求を処理しません 。以下の例は、グループ・ロールアウトの図です。

図 2. グループ・ロールアウト
図 2 は、グループ・ロールアウトを実行するときに、ターゲット・クラスターがグループに分かれている状況を示しています

アトミック・ロールアウト

エディションのアトミック・ロールアウトを実行すると、 クラスターの半分のエディションがアプリケーションの一貫性のあるエディションに一度に置き換えられ、すべてのユーザー要求が処理されるようになります。すべてのユーザー要求は旧エディションか新規エディションのいずれかで処理され、ユーザー要求が両方のエディションで処理されることはありません。

アトミック・ロールアウトでは、必ず、すべてのアプリケーション要求が、一貫性のあるエディションで処理されます。 例えば、1.0 または 2.0 のいずれかのエディションで処理され、両方では処理されません。現在使用可能なエディションは、クラスターを構成するサーバーの半数でオフラインになります。それらのサーバーでは新規エディションがアクティブ化され、開始されますが、次のステップが完了するまで、サーバーはオフラインのまま保持されます。 次のステップでは、残りのサーバーで現在アクティブ中のエディションがオフラインになります。 この時点で、サーバーには、アプリケーション要求の処理に使用可能などちらのエディションのインスタンスもありません。 ODR が一時的に、そのアプリケーションに対して受信したすべての要求をキューに入れます。アプリケーションが完全にオフラインになった後、クラスターの最初の半数がオンラインに戻されます。 クラスターの残りの半数は、以前のエディションから次のエディションに移行し、オンラインに戻されます。 以下の例は、アトミック・ロールアウトの図です。

図 3. アトミック・ロールアウト
図 3 は、アプリケーションが完全にオフラインになった後に、ターゲット・クラスターの最初の半数がオンラインに戻され、
クラスターの残りの半数が以前のエディションから次のエディションに移行してオンラインに戻される状況を示しています。

エディションの妥当性検査および互換性

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

エディションの妥当性検査 とは、並行したアクティベーションの特殊なケースであり、 エディションの割り当てられたデプロイメント・ターゲット (例えば、動的クラスター) が複製され、そのエディションが複製されたデプロイメント・ターゲット上で開始できるようにされます。複製されたデプロイメント・ターゲットは、妥当性検査ターゲット と呼ばれます。 ルーティング・ルールを使用して、妥当性検査が実行されているエディションにどのアプリケーション要求を送信するか指定する必要があります。 エディションが妥当性検査中の場合は、妥当性検査モード になっています。

妥当性検査モードにより、現在使用可能なエディションをオフラインにすることなく、アプリケーションの新規エディションがその実稼働環境で確実に機能します。 通常、テストの負荷が妥当性検査モードのエディションに送信され、接続性やデータベース・アクセスなどが予想通り動作するなど、アプリケーション環境の性質およびセットアップを確認します。 エディションの妥当性検査モードのロールアウトを実行すると、その操作は、最初にそのエディションがインストールされたデプロイメント・ターゲットで実行されます。ロールアウトを実行すると、そのエディションは妥当性検査モードを終了します。妥当性検査が完了すると、妥当性検査ターゲットは削除されます。以下の例は、エディションの妥当性検査の図です。

図 4. エディションの妥当性検査
図 4 は、エディションの妥当性検査で、動的クラスターが複製され、複製されたデプロイメント・ターゲット上でそのエディションを開始可能にする状況を示しています

エディションの互換性

アプリケーションの変更は、意識されることがない場合も、エンド・ユーザーから認識される場合もあります。あるアプリケーションのアップグレードによって、少なくとも前回の変更と同じアプリケーション・プログラミング・インターフェースが提供され、本質的な動作に対する意味的な変更がない場合、そのアプリケーション・エディションは以前のバージョンと互換 のアップグレードです。 既存のユーザーは、使用方法を変更することなく、また現行と以前のエディションの違いを認識することなく、アップグレードされたアプリケーションを使用できます。

既存のユーザーがアプリケーションの使用方法を変更する必要があるアプリケーション・アップグレードは、非互換 のアップグレードです。 例えば保守容易性やその他の要因を改善するため、従来の機能の除去、またはインターフェースの変更が必要な場合があります。また、デプロイメント環境へ非互換の変更を導入する場合があります。非互換変更では、既存ユーザーに対する影響を管理するための注意深い計画が必要です。




関連概念
アプリケーション・エディション・マネージャー
関連資料
アプリケーション・エディション・マネージャーの状態
概念のトピック    

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

最終更新: 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/cxappedcon.html