JP2010526362A - クラスタ化されたソフトウェアエンティティのための動的ｃｌｉマッピング - Google Patents

Abstract

可用性マネジメント（ＡＭ）機能を、ソフトウェアのインストール場所にマッピングするための技術が説明される。可用性マネジメント機能（ＡＭＦ）は、コンポーネント種類を探索し、当該コンポーネントと関連付けられたソフトウェアを特定することができる。選択されたＡＭＦノードのために、ＡＭＦソフトウェアエンティティは次に、当該ソフトウェアに関連付けられたパス名プレフィックスを特定することができる。パス名プレフィックスは次に、様々なＡＭ機能、例えば新たなコンポーネントまたはサービスユニットのインスタンス化のために用いられうる。
【選択図】図３

Description

本発明は、一般的には高可用性（high availability）システム（ハードウェアおよびソフトウェア）に関し、特に、そのような高可用性システムに関連するプラットフォーム管理（platform management）に関する。

高可用性システム（ＨＡシステムとしても知られる）は、本来、システムが提供するサービスの可用性を改善するという目的のために実装されるシステムである。可用性は、システムまたはサービスが“ｕｐ”である時間のパーセンテージとして説明することができる。例えば、９９．９９９％可用性（いわゆる“５つの９”可用性）に合わせて設計されたシステムは、およそ０．４４分／月または５．２６分／年のダウンタイムしかないシステムまたはサービスを指す。

高可用性システムは、システムコンポーネント（system components）に障害が発生した（fail）ときにサービスを提供するために用いられる、冗長（redundant）ノードを採用することにより、意図された可用性のレベルを提供する。例えば、サーバがある特定の（particular）アプリケーションクラッシュを起こした場合、ＨＡシステムはクラッシュを検出して、別の冗長ノードでアプリケーションを再起動させるであろう。ＨＡシステムにおいては、様々な冗長性モデルが用いられうる。例えば、Ｎ＋１冗長性モデルは、障害が発生したノードの役割を引き継ぐためにオンライン接続された、単一のエクストラノード（多数の主ノード（primary nodes）に関連付けられる）を提供する。しかしながら、単一ＨＡシステムが多くのサービスを管理している状況において、障害を処理するための単一の専用ノードは十分な冗長性を提供しないであろう。そのような状況において、例えば、１より多い（Ｍ）待機ノード（standby nodes）が含まれかつ利用可能である、Ｎ＋Ｍ冗長性モデルが用いられるであろう。

ＨＡシステムが、ファイル共有、インターネットカスタマーポータル、データベースその他のような重要なサービスのサポートのために、よりありふれたものになるにつれて、そのようなシステムの設計のための規格化された（standardized）モデルおよび方法論を提供することが望ましいとされるようになった。例えば、サービス可用性フォーラム（ＳＡＦ：Service Availability Forum）は、移植可能で（portable）、可用性がより高いアプリケーションの開発における支援のための、アプリケーションインタフェースサービス（ＡＩＳ：application interface services）を規格化した。図１の概念的なアーキテクチャスタックにおいて示されているように、ＡＩＳ１０は、ＨＡアプリケーション１４とＨＡミドルウェア１６との間に規格化されたインタフェースを提供するように意図されており、それによってそれらをお互いに独立させる。後述するように、ＡＩＳの一連の機能性はそれぞれ、オペレーティングシステム２０およびハードウェアプラットフォーム２２に関連付けられる。ＡＩＳ標準仕様書に関するさらなる情報に興味がある読者は、ここで参照によって取り入れられる事項の開示であって、www.saforum.orgにおいて利用可能な、アプリケーションインタフェース仕様書（ＡＩＳ：Application Interface Specifications）バージョンＢ．０２．０１を参照されたい。

本願にとって特に興味深いのは、ＡＩＳ仕様書内で定義されているソフトウェアエンティティである、可用性管理フレームワーク（ＡＭＦ：Availability Management Framework）である。ＡＩＳ仕様書によれば、ＡＭＦは、単一障害点（single point of failure）のないシステムを実現するために、クラスタ内の冗長リソースを連携させる（coordinating）ことによって、サービス可用性を提供するための、規格化されたメカニズムである。ＡＭＦは、とりわけクラスタ内のコンポーネントの状態、およびそれらのコンポーネントの健全性を測定する、一連のアプリケーションプログラムインタフェース（ＡＰＩ：application program interfaces）を提供する。コンポーネントはまた、それらの状態についての情報のために、ＡＭＦに問い合わせをする機能とともに提供される。ＡＭＦ ＡＰＩを用いて開発され、ＡＭＦシステムモデルに従うアプリケーションは、そのサービスの可用性管理の負担をＡＭＦに委ねる。それゆえ、このようなアプリケーションは、コンポーネント障害や、メンテナンスなどに関係する動的再配置（dynamic reconfiguration）問題に対処する必要がない。

上記の規格において定められているように、それぞれのＡＭＦ（ソフトウェアエンティティ）は、図２においてその一例が示されている、多数のクラスタノードおよびコンポーネントから成る単一の論理クラスタ（logical cluster）のための可用性サポートを提供する。ここで、第１のクラスタＡは、それ自身のＡＭＦ２４、２つのＡＭＦノード２６，２８および４つのＡＭＦコンポーネント３０〜３６を含む。同様に、第２のクラスタＢは、それ自身のＡＭＦ３８、２つのＡＭＦノード４０，４２および４つのＡＭＦコンポーネント４４〜５０を備える。コンポーネント３０〜３６および４４〜５０は、それぞれ、ＡＭＦ２４および３８によって管理されている一連のハードウェアおよびソフトウェアリソースを表す。物理的な意味においては、コンポーネントはＨＡアプリケーションのプロセスとして実現される。ノード２６，２８，４０，４２はそれぞれ、それらのノードの可用性を管理するために割り当てられる冗長要素（redundancy elements）だけではなく、ＡＭＦコンポーネントとして管理されるそれぞれのプロセスが実行されている物理的ノードに相当する論理エンティティ（logical entity）をも表す。

ＡＩＳ規格はまた、一連のコンポーネントを統合し（aggregates）、これによって、それらの個別の機能性をより高いレベルのサービスを提供するために結合する論理エンティティとして、サービスユニット（ＳＵ：service unit）を定義する。サービスユニットはコンポーネントをいくつでも含むことができるが、ある特定のコンポーネントは１つのサービスユニットしか構成できない。ＡＭＦの観点からすれば、それぞれのコンポーネントは常にサービスユニットに含まれるため、サービスユニットは、冗長な方法、すなわち１回より多くインスタンス化され（instantiated）うる最小の論理エンティティであるという意味においては、冗長性の増分単位（incremental unit of redundancy）と考えることができる。サービスユニットおよびコンポーネントを含む、ＡＭＦの別の例が、以下で図３として提供される。

このモデルの葉の部分（leaves）において、それぞれのコンポーネント３０〜３６および４０〜４４は、対応するソフトウェアのインストールが位置する場所を特定する属性を備える。より具体的には、この属性は、対応するサービスユニットがインスタンス化されるときに用いられるパスプレフィックスを特定する。しかしながら、このパスプレフィックスは、コンポーネントが常に同じノードでインスタンス化される、または、コンポーネントが、同じパスを持つ場所にソフトウェアのインストールがあるノードでインスタンス化されると仮定する。現在のクラスタでは、この後半の特徴は一般的にあてはまる。すなわち、インストールのパスはノードのすべてにおいて常に同じである。しかしながら、この仮定が必ずしも当てはまらない場合、例えば、いくつかのクラスタがディスクレス（例えばＲＡＭディスクを用いる）で、他のノードは組み込みディスクを用いるか、ローカルディスクを備える、異種（heterogeneous）クラスタにおいて（または、ノードが異なったオペレーティングシステムを実行している場合）、結果としてインスタンス化は失敗するであろう。

従って、例えば柔軟なサービスユニットのインスタンス化を可能にすることによって、上記の問題および欠点を回避する、ＨＡアプリケーションのためのプラットフォーム管理システムおよび方法を提供することが望ましいであろう。

例示的な実施形態によれば、リモートノード上で、ローカルノードからコンポーネントをインスタンス化するための方法は、上記ローカルノードにおいて、インスタンス化されるべき上記コンポーネントの種類識別子（type identifier）を取得するステップと、上記ローカルノードにおいて、上記種類識別子から、上記コンポーネントに対応するソフトウェア識別子（software identifier）を特定するステップと、上記ローカルノードにおいて、上記ソフトウェア識別子に対応するソフトウェアがインストールされている、複数のリモートノードを特定するステップと、上記ローカルノードにおいて、上記複数のリモートノードから、上記コンポーネントがインスタンス化されるべき上記リモートノードを特定するステップと、上記ローカルノードにおいて、上記コンポーネントの種類および上記ソフトウェア識別子を用いて、上記リモートノード上の特定の（specific）ソフトウェアのインストール場所を取得するステップと、を含む。

別の例示的な実施形態によれば、可用性管理フレームワーク（ＡＭＦ）論理ノードがリモートノード上でコンポーネントをインスタンス化するために用いられ、上記ＡＭＦ論理ノードは、探索（lookup）モジュールを含み、上記探索モジュールは、上記ローカルノードにおいてインスタンス化されるべき上記コンポーネントの種類識別子を受信し、上記種類識別子から、上記コンポーネントに対応するソフトウェア識別子を特定し、上記ソフトウェア識別子に対応するソフトウェアがインストールされている複数のリモートノードを特定し、上記複数のリモートノードから、上記コンポーネントがインスタンス化されるべき上記リモートノードを特定し、上記コンポーネントの種類および上記ソフトウェア識別子を用いて、上記リモートノード上の特定のソフトウェアのインストール場所を取得する。

さらに別の例示的な実施形態によれば、可用性管理フレームワーク（ＡＭＦ）ノードに関連するコンポーネントのために、コマンドラインインタフェース（ＣＬＩ）コマンドを実行するための方法は、上記コンポーネントに関連付けられた種類を探索するステップと、上記種類に基づいて、上記コンポーネントに関連付けられたソフトウェアを識別するステップと、上記識別されたソフトウェアのためのパス名プレフィックスを探索するステップと、上記ＣＬＩコマンドを実行するために上記パス名プレフィックスを用いるステップと、を含む。

さらに別の例示的な実施形態によれば、コンポーネントを可用性管理フレームワーク（ＡＭＦ）ノードにマッピングするための方法は、上記コンポーネントの種類を特定するステップと、上記特定された種類に基づいて、上記コンポーネントに関連付けられたソフトウェアのためのソフトウェア識別子を特定するステップと、上記コンポーネントがマッピングされるべき上記ＡＭＦノードを選択するステップと、上記特定された種類および上記特定されたソフトウェア識別子を用いたＡＭＦ属性から、上記ＡＭＦノード上の上記ソフトウェアについてのノード固有のインストール場所を特定するステップと、を含む。

別の例示的な実施形態によれば、コンピュータ読み取り可能な媒体は命令を含み、上記命令は、コンピュータまたはプロセッサ上で実行されたときに、上記コンポーネントに関連付けられた種類を探索するステップと、上記種類に基づいて、上記コンポーネントに関連付けられたソフトウェアを識別するステップと、上記識別されたソフトウェアのためのパス名プレフィックスを探索するステップと、上記ＣＬＩコマンドを実行するために上記パス名プレフィックスを用いるステップと、を実行する。

別の例示的な実施形態によれば、システムは、サービスをサポートするためのハードウェアプラットフォーム、および上記サービスの可用性をサポートする可用性管理機能（ＡＭＦ：availability management function）ソフトウェアエンティティを含み、上記ＡＭＦソフトウェアは、上記コンポーネントに関連付けられた種類を探索する機能と、上記種類に基づいて、上記コンポーネントに関連付けられたソフトウェアを識別する機能と、上記識別されたソフトウェアのためのパス名プレフィックスを探索する機能と、上記コンポーネントのインスタンス化のために、上記パス名プレフィックスを用いる機能と、を実行することを含む、上記サービスに関連するコンポーネントのライフサイクル機能性（lifecycle functionality）を管理する。

明細書に組み込まれてその一部を構成する添付図面は、１またはそれ以上の実施形態を示し、また、記述とともにこれらの実施形態を説明する。

アプリケーションインタフェースサービス（ＡＩＳ）に関連する概念的なアーキテクチャスタックを示す。 可用性管理フレームワーク（ＡＭＦ）クラスタアーキテクチャを示す。 サービスユニットおよびコンポーネントを含む、ＡＭＦで管理される例示的なシステムを示す。 １つのサービスユニットがターミネートされ、他のサービスユニットが例示的な実施形態に従ってインスタンス化された、図３のＡＭＦで管理される例示的なシステムを示す。 例示的な実施形態に係る可用性管理フレームワーク（ＡＭＦ）ノードに関連付けられたコンポーネントのためのコマンドラインインタフェース（ＣＬＩ）コマンドを実行するための方法を示すフローチャートである。 例示的な実施形態に係るシステムのノード／部分の説明図である。 他の例示的な実施形態に係るリモートノード上で、コンポーネントをインスタンス化するための方法を示すフローチャートである。

以下の本発明の例示的な実施形態の説明は、添付図面を参照する。異なる図面における同一の参照番号は、同一または類似の要素を特定する。以下の詳細な説明は、発明を限定するものではない。代わりに、発明の範囲は添付の請求の範囲によって定義される。

この考察のためのいくつかの追加の背景を提供するために、図３において示されるような、他の例示的なＡＭＦで制御されたシステムを検討する。その中で、４つのノード（Ａ，Ｂ，ＣおよびＤ）は２つのサービスグループ（ＳＧ１およびＳＧ２）に関連している。サービスグループは、特定のサービスの１またはそれ以上のインスタンスのために、サービス可用性を提供する、サービスユニット（ＳＵ）のグループである。例えば、ＳＧ１は、この例においてはｅ−ｍａｉｌサービス（ハードウェアおよびソフトウェア）の１つのインスタンスをサポートするＳＵ１およびＳＵ２を含み、ＳＧ２は、ＦＡＸサービス（ハードウェアおよびソフトウェア）の２つのインスタンスをサポートするＳＵ３、ＳＵ４およびＳＵ５を含む。ＳＧ１によってサポートされるｅ−ｍａｉｌサービスインスタンスのために、ＳＵ１はアクティブ状態（active state）を割り当てられ、ＳＵ２は待機状態（standby state）を割り当てられる。

ＳＧ１におけるそれぞれの例示的なサービスユニットは、それらに関連付けられた２つのコンポーネントを有する。コンポーネントは、ＡＭＦ３００がエラーの検出および分離、回復、ならびに修復を実行する最小の論理エンティティである。それゆえ、コンポーネントは一般的に、エラーの封じ込めまたは分離の目的のために、はっきりとは切り離せない機能のすべてを含む。これらのコンポーネントはさらに、ｅ−ｍａｉｌサービスの可用性の提供に関連する冗長性をもたらす保護グループ（protection groups）にグループ化されうる。例えば、ｅ−ｍａｉｌサービスインスタンスに関連して、コンポーネントＣ１およびＣ３は第１の保護グループを形成することができ、コンポーネントＣ２およびＣ４は第２の保護グループを形成することができる。それゆえ、コンポーネントＣ１に障害が発生した場合、ＡＭＦ３００はコンポーネントＣ３をアクティブ状態に切り替えることができ、また同様に、コンポーネントＣ２に障害が発生した場合、ＡＭＦ３００はコンポーネントＣ４をアクティブ状態に切り替えることができる。

サービスグループＳＧ２は、ＦＡＸサービスの２つのインスタンスが、３つのサービスユニットＳＵ３，ＳＵ４およびＳＵ５によってサポートされている、わずかに異なる構成（configuration）を示している。例えば、ＳＵ３およびＳＵ４は、ＦＡＸサービスの１つのインスタンスをそれぞれがサポートするようなアクティブ状態をそれぞれ割り当てられ、一方ＳＵ５は、待機状態を割り当てられ、これらの冗長バックアップとして動作することができる。この場合において、コンポーネントＣ５およびＣ７は、２つのＦＡＸサービスインスタンスの一方に関連付けられた１つの保護グループを形成し、コンポーネントＣ６およびＣ７は、２つのＦＡＸサービスインスタンスの他方に関連付けられたもう１つの保護グループを形成するであろう。以下で説明するように実行されるであろう、コンポーネントライフサイクル処理（component lifecycle handling）、例えばインスタンス化および関連する機能を除いて、ＡＭＦソフトウェアエンティティ３００は、上記参照により取り入れられたＡＩＳ規格において説明されているように動作するであろう。

上記のように、例示的な実施形態は、ＡＭＦエンティティが、新たなサービスユニットおよび関連付けられたコンポーネントをインスタンス化する状況を処理する（または、その他のライフサイクルタスクを実行する）。図３の例の状況において、サービスユニットＳＵ４に関連付けられたコンポーネントＣ６に障害が発生したと仮定する。この場合において、障害の状況を通知されたとき、ＡＭＦ３００は、もう一方のＦＡＸサービスインスタンスの可用性を維持するために、ＳＵ５を待機状態からアクティブ状態に切り替えるであろう。しかしながら、ＡＭＦ３００はまた、ＳＵ５により空いてしまった待機の役割を果たすために必要なソフトウェアとともに、新たなサービスユニットおよび関連付けられたコンポーネントをインスタンス化することを決定するであろう。例えば、図４において示されているように、ＡＭＦ３００は、ＳＵ４／Ｃ６を終了させ、もう一方のＦＡＸサービスインスタンスのための新たな待機の役割を担うＳＵ６／Ｃ８をインスタンス化することを決定する。このインスタンス化を実行するために、ＡＭＦ３００は、他ならぬこのＦＡＸサービスを実行するコンポーネントについて、必要なソフトウェアに関連付けられたパス名が常に同じであろうと想定する代わりに、これらの例示的な実施形態によれば、このパス情報（追加して、コンポーネントライフサイクルコマンドに関する他の情報も同様に）を、以下で説明するように、他ならぬこのコンポーネント種類が存在する（running）ノードの１つから取得することができる。

例えば、それぞれのコンポーネント、例えばＣ１〜Ｃ７は、ＡＭＦ３００によって読み取りまたは探索されうる属性として関連付けられているコンポーネント種類を有するであろう。コンポーネント種類は、今度は、特定のコンポーネントの機能性、すなわち、割り当てられたサービスユニットにおいてサポートするサービスの一部、を有効にするために必要なソフトウェアを識別するソフトウェア識別子を参照するであろう。さらに、それぞれのＡＭＦノード、例えば図３および４におけるノードＡ〜Ｄは、どのソフトウェアパッケージがインストールされているかを示すものと関連付けられた属性を有するであろう。これらの属性および識別子は、オブジェクトとして、例えば、データベース（図示せず）において、例えば、情報モデル管理サービス（ＩＭＭ：Information Model Management）と呼ばれるＳＡＦサービスによって格納されうる。ＡＭＦ３００は、その結果、ＩＭＭに格納された対応するオブジェクトから、上記の情報を取得することができる。異なったシステムは、ＩＭＭデータベースを異なった方法において実装するかもしれないが、しかしながらＡＭＦ３００は、それを介してこれらの例示的な実施形態に係る、格納された属性／識別子情報を検索することができるインタフェースとともに提供されるであろう。代替的には、ＡＭＦの実装は、それ自身のためのこの情報の複製を保持してもよい。この構成情報（configuration data）の読み取りおよび設定のためのＳＮＭＰアクセスを提供するこの情報モデルに基づく管理情報ベース（ＭＩＢ：management information base）がシステムとともに提供されてもよい。この情報が格納および検索される特定の方法にかかわらず、ＡＭＦ３００はこの情報を、例えば、図５のフローチャートにおいて示されている例示的な実施形態に従って、図４における新たなサービスユニット／コンポーネントの組み合わせＳＵ６／Ｃ８をインスタンス化するために用いるであろう。

ステップ５００において、ＡＭＦ３００は、コンポーネント、例えば図３および４の例におけるコンポーネントＣ６に関連付けられた種類を探索する。種類の値は、今度は、ステップ５０２において、ＡＭＦ３００がコンポーネントＣ６に関連付けられたソフトウェアを識別できるようにする、ソフトウェア識別子の値を提供する。ソフトウェア識別子を得て、その結果、ＡＭＦ３００は、ステップ５０４において、ＳＵ６／Ｃ８のインスタンス化のために選ばれたＡＭＦノード、例えば図３および４の例におけるＡＭＦノードＡのための、パス名プレフィックスを探索することができる。ＳＵ６／Ｃ８のインスタンス化のために利用できるノードの中から、特定のＡＭＦノードが選ばれるためには、様々な方法がある。例えば、サービスユニットまたはサービスグループの利用可能な属性、例えばＩＭＭからのものは、特定のＳＵまたはサービスグループのＳＵがインスタンス化されうるノードグループを示してもよい。このような情報が利用可能であれば、ＡＭＦ３００は、例えばノードが配列されている順番に基づいて、ＡＭＦノードの結果リストから選択することができる。そうでなければ、ＡＭＦ３００は、例えば負荷に基づいて、クラスタにおけるどのノードも、サービスユニット／コンポーネントをインスタンス化するために選択することができる。

パス名プレフィックスは、ＡＭＦノード固有かつソフトウェア固有のプレフィックスであり、コンポーネントの種類と関連付けられた、コマンドごとの相対パス名（per-command relative pathname）と結合されたとき、コマンドラインインタフェース（ＣＬＩ：Command Line Interface）コマンドのためのパス名を定義する。この結合は、ＡＭＦ３００によって取得されたパス名プレフィックスが、ステップ５０６において、例えば新たなサービスユニット／コンポーネントをインスタンス化するためのコマンドのようなＣＬＩコマンドを実行するために、どのように用いられうるかの一例である。なお、これらの例示的な実施形態は、インスタンス化および対応するＣＬＩコマンドに焦点を合わせているが、それに限定されるものではない。代わりに、これらの例示的な実施形態は、ターミネート（termination）、クリーンアップ（cleanup）、ＡＭ開始（AM_start）およびＡＭ停止（AM_stop）と関連付けられるような、コンポーネントライフサイクルと関連する、他のＣＬＩコマンドを容易にするために用いられてもよい。ターミネートコマンドは、コンポーネントおよびコンポーネントによって提供されるサービスを停止し、コンポーネントをインスタンス化されていない状態にするために用いられる。クリーンアップコマンドもまた、コンポーネントをインスタンス化されていない状態にし、ＡＭＦ３００がエラーから回復する時に用いられる。ＡＭ開始コマンドは、コンポーネントが無事にインスタンス化された後、またはコンポーネントの健全性を定期的に評価するためコンポーネントの監視を続けるために、ＡＭＦ３００により実行されうる。ＡＭ停止コマンドは、特定のコンポーネントの監視を停止するために、ＡＭＦ３００によって実行されうる。

図６を参照すると、本発明の例示的な実施形態に係るデータ処理のためのシステムおよび方法は、例えばサーバ６０１の一部であって、記憶装置６０２に含まれる命令の配列を実行する、１またはそれ以上のプロセッサ６００によって実行されうる。このような命令は、二次データ記憶装置６０４のような、他のコンピュータ読み取り可能な媒体から記憶装置６０２に読み込まれてもよい。記憶装置６０２に含まれる命令の配列の実行は、プロセッサ６００に例えば上記のような操作をさせる。代替的な実施例において、組み込みの（hard-wire）回路構成が、本発明を実装するために、ソフトウェア命令に代えて、または組み合わせて用いられてもよい。

これらの例示的な実施形態が実装される特定の方法にかかわらず、これらの例示的な実施形態に係るＡＭＦソフトウェアエンティティが、コンピュータ読み取り可能な媒体に格納された探索ソフトウェアモジュールを含み、コンピュータまたはプロセッサ上で実行されたとき、図７のフローチャートにおいて示されるステップを実行する命令を含みうることが理解されるであろう。この中で、ステップ７００において、探索モジュールは、ローカルノードにおいてインスタンス化されるべきコンポーネントの種類識別子を受信する。次に、ステップ７０２において、探索モジュールは、種類識別子から、インスタンス化されるべきコンポーネントに対応するソフトウェア識別子を特定する。ステップ７０４において、探索モジュールは、ソフトウェア識別子に対応するソフトウェアがインストールされた複数のリモートノードを特定し、それから、ステップ７０６において、複数のリモートノードからコンポーネントがインスタンス化されるべきリモートノードを特定する。リモートノード上の特定のソフトウェアのインストール場所は、ステップ７０８において、コンポーネントの種類およびソフトウェア識別子を用いて取得される。

例示的な実施形態によれば、それぞれのＡＭＦノードに関連し、そこにインストールされたソフトウェアおよびその場所を示す属性は、例えばソフトウェアがノード上にインストールされたとき、新たなソフトウェア情報によって更新されうる。このようにして、ＡＭＦソフトウェアエンティティは、管理されるノードのいずれかにＣＬＩコマンドをマッピングするためのシークをするときに、最新の情報を入手するであろう。さらに、ＡＭＦノードは、それ自身が論理エンティティであって、潜在的に異なる物理ノード（例えば、クラスタメンバーシップ（ＣＬＭ：Cluster Membership）ノード）にマッピングされうるため、上記と同様のＣＬＩマッピングが、システムモデルの異なった階層上で再帰的に実行されうる。これは、このマッピングが、ＣＬＭノードがオペレーティングシステムインスタンスにマッピングされるとき、および、ＡＭＦノードがＣＬＭノードにマッピングされるときに実行されうるということである。

上記について、以下の例を考察する。新たなハードウェアノードが、ＡＭＦで管理される（AMF-managed）ＨＡシステムに追加されると仮定する。このシステムは、例えば、２つのクラスタノードおよび１つのＡＭＦノードをそれぞれ提供することができる。それゆえ、ＡＭＦ階層においては２つのノードが追加される（または、それらが異なるＡＭＦクラスタに属していれば、それぞれのクラスタに１つのノード）。しかしながら、この例示的なシステムにおいては、ディスクには１つの物理ノードしかなく、完全に１つのクラスタノードの専用にされるか、または２つの間で共有などされるであろう。それぞれの異なる構成は、ディスクの物理記憶上のＡＭＦノードのソフトウェアの異なったマッピングを意味するであろう。ノードが異なるクラスタに属する場合には、２つの異なったソフトウェアイメージが存在できるように、イメージを分離するための要求はさらに厳しくなるであろう。ＡＭＦノードがインスタンス化されるとき、つまり、同じように上記のコンポーネントに関しては異なるノード上にインスタンス化されるとき、ＡＭＦノード上で利用可能であってＡＭＦノード階層において構成されるソフトウェアを見つけ出すことを可能にするための、これらの例示的な実施形態に係るマッピングが提供されるであろう。

動的ＣＬＩマッピングもまた、ＡＭＦで管理されるシステムにおけるより高い階層に対して実行されうる。例えば、ＡＭＦで管理されるシステムにおいて、オペレーティングシステムによって直接実行されないコンポーネント（Ｊａｖａ（登録商標），Ｃ＋＋，その他）を統合する（integrate）ために用いられうるコンテナコンポーネント（container components）もまた、上記の技術から利益を得る。例えば、含まれているいくつかのコンポーネントのライフサイクルを管理するコンテナコンポーネントがノード上に置かれた場合に、コンテナが特定のノードから（または、特定のノードについての）パス情報を取得する必要があるとき、このようなコンテナは、上記の、ＣＬＩコマンドのためのＡＭＦのためのマッピングを実行するであろう。

上記の本発明の例示的な実施形態の説明は、図面および説明を提供したが、網羅的なものであったり、開示された通りの形に発明を限定したりすることを意図したものではない。例えば、コンポーネント自身が、そのソフトウェアのインストール場所に関するパス情報の一部を提供してもよい。上記の教示、または発明の実施から習得されるところに照らせば、修正および変形が可能である。続く請求の範囲およびその均等物が、発明の範囲を定義する。

Claims (26)

1. リモートノード上で、ローカルノードからコンポーネントをインスタンス化するための方法であって、前記方法は：
   −前記ローカルノードにおいて、インスタンス化されるべき前記コンポーネントの種類識別子を取得するステップと；
   −前記ローカルノードにおいて、前記種類識別子から、前記コンポーネントに対応するソフトウェア識別子を特定するステップと；
   −前記ローカルノードにおいて、前記ソフトウェア識別子に対応するソフトウェアがインストールされている、複数のリモートノードを特定するステップと；
   −前記ローカルノードにおいて、前記複数のリモートノードから、前記コンポーネントがインスタンス化されるべき前記リモートノードを特定するステップと；
   −前記ローカルノードにおいて、前記リモートノード上の特定のソフトウェアのインストール場所を、前記コンポーネントの種類および前記ソフトウェア識別子を用いて取得するステップと；
   を含む方法。
2. 前記方法は：
   −前記複数のリモートノードのいずれかに新たなソフトウェアがインストールされる度に、前記ローカルノードにおいて、前記特定のソフトウェアのインストール場所を更新するステップ
   をさらに含む、請求項１に記載の方法。
3. リモートノード上でコンポーネントをインスタンス化するために用いられる、可用性管理フレームワーク（ＡＭＦ）論理ノードであって、前記ＡＭＦ論理ノードは：
   探索モジュールであって、前記探索モジュールは：
   −前記ローカルノードにおいて、インスタンス化されるべき前記コンポーネントの種類識別子を受信し；
   −前記種類識別子から、前記コンポーネントに対応するソフトウェア識別子を特定し；
   −前記ソフトウェア識別子に対応するソフトウェアがインストールされた複数のリモートノードを特定し；
   −前記複数のリモートノードから、前記コンポーネントがインスタンス化されるべき前記リモートノードを特定し；
   −前記リモートノード上の特定のソフトウェアのインストール場所を、前記コンポーネントの種類および前記ソフトウェア識別子を用いて取得する；
   探索モジュール
   を含む、ＡＭＦ論理ノード。
4. 可用性管理フレームワーク（ＡＭＦ）ノードに関連付けられたコンポーネントのためのコマンドラインインタフェース（ＣＬＩ）コマンドを実行するための方法であって、前記方法は：
   −前記コンポーネントに関連付けられた種類を探索することと；
   −前記種類に基づく、前記コンポーネントに関連付けられたソフトウェアを識別することと；
   −前記識別されたソフトウェアのためのパス名プレフィックスを探索することと；
   −前記ＣＬＩコマンドを実行するために前記パス名プレフィックスを用いることと；
   を含む方法。
5. 前記ＣＬＩコマンドは：
   前記コンポーネントのインスタンス化、前記コンポーネントのターミネート、前記コンポーネントのクリーンアップ、前記コンポーネントのＡＭ開始および前記コンポーネントのＡＭ停止
   のうちの１つを実行するために用いられるコマンドである、請求項４に記載の方法。
6. 前記コンポーネントは、
   ＡＭＦエンティティが、エラー検出および分離、回復および修復を実行するサービスに関連する最小の論理エンティティである、請求項４に記載の方法。
7. 前記ソフトウェアは、
   前記コンポーネントが割り当てられるサービスユニットによって提供されるサービスの提供に関連するソフトウェアである、請求項４に記載の方法。
8. 前記パス名プレフィックスは、
   ＡＭＦノード固有かつソフトウェア固有のプレフィックスであって、前記コンポーネントの種類と関連付けられたコマンドごとの相対パス名と結合されたとき、コマンドラインインタフェース（ＣＬＩ）コマンドのためのパス名を定義する、請求項４に記載の方法。
9. コンポーネントを可用性管理フレームワーク（ＡＭＦ）ノードにマッピングするための方法であって、前記方法は：
   −前記コンポーネントの種類を特定することと；
   −前記特定された種類に基づいて、前記コンポーネントに関連付けられたソフトウェアのためのソフトウェア識別子を特定することと；
   −前記コンポーネントがマッピングされるべき前記ＡＭＦノードを選択することと；
   −前記特定された種類および前記特定されたソフトウェア識別子を用いて、ＡＭＦ属性から、前記ＡＭＦノード上の前記ソフトウェアのためのノード固有のインストール場所を特定することと；
   を含む方法。
10. 前記コンポーネントは、
    ＡＭＦエンティティがエラー検出および分離、回復および修復を実行するサービスに関連する最小の論理エンティティである、請求項９に記載の方法。
11. 前記コンポーネントが割り当てられるサービスユニットによって提供されるサービスの提供に関連するソフトウェアである、請求項９に記載の方法。
12. 前記パス名プレフィックスは、である
    前記パス名プレフィックスは、
    ＡＭＦノード固有かつソフトウェア固有のプレフィックスであって、前記コンポーネントの種類に関連付けられたコマンドごとの相対パス名と結合されたとき、コマンドラインインタフェース（ＣＬＩ）コマンドのためのパス名を定義する、請求項９に記載の方法。
13. 前記方法は：
    −前記ソフトウェアのための前記ノード固有の場所を用いて、前記コンポーネントをインスタンス化すること
    をさらに含む、請求項９に記載の方法。
14. 前記方法は：
    複数のノードのいずれかに、前記ソフトウェアの新たなバージョンがインストールされる度に、前記ソフトウェアのノード固有のインストール場所を更新すること
    をさらに含む、請求項９に記載の方法。
15. 命令が入っているコンピュータ読み取り可能な媒体であって、コンピュータまたはプロセッサ上で実行されたとき、前記命令は：
    −前記コンポーネントに関連付けられたタイプを探索するステップと；
    −前記種類に基づいて前記コンポーネントに関連付けられたソフトウェアを識別するステップと；
    −前記識別されたソフトウェアのためのパス名プレフィックスを探索するステップと；
    −前記ＣＬＩコマンドを実行するために前記パス名プレフィックスを用いるステップと；
    を実行する、コンピュータ読み取り可能な媒体。
16. 前記ＣＬＩコマンドは：
    前記コンポーネントのインスタンス化、前記コンポーネントのターミネート、前記コンポーネントのクリーンアップ、前記コンポーネントのＡＭ開始および前記コンポーネントのＡＭ停止のうちの１つを実行するために用いられるコマンドである、請求項１５に記載のコンピュータ読み取り可能な媒体。
17. 前記コンポーネントは、
    ＡＭＦエンティティがエラー検出および分離、回復および修復を実行するサービスに関連する最小の論理エンティティである、請求項１５に記載のコンピュータ読み取り可能な媒体。
18. 前記ソフトウェアは、
    前記コンポーネントが割り当てられるサービスユニットによって提供されるサービスの提供に関連するソフトウェアである、請求項１５に記載のコンピュータ読み取り可能な媒体。
19. 前記パス名プレフィックスは、
    ＡＭＦノード固有かつソフトウェア固有のプレフィックスであって、前記コンポーネントの種類に関連付けられたコマンドごとの相対パス名と結合されたとき、コマンドラインインタフェース（ＣＬＩ）コマンドのためのパス名を定義する、請求項１５に記載のコンピュータ読み取り可能な媒体。
20. 前記コンピュータ読み取り可能な媒体は：
    −複数のノードのいずれかに、前記ソフトウェアの新たなバージョンがインストールされる度に、前記ソフトウェアのインストール場所を更新すること
    をさらに含む、請求項１５に記載のコンピュータ読み取り可能な媒体。
21. システムであって、前記システムは：
    −サービスをサポートするためのハードウェアプラットフォームと；
    −前記サービスの可用性をサポートする可用性管理機能（ＡＭＦ）ソフトウェアエンティティと；
    を含み、
    前記ＡＭＦソフトウェアは、前記サービスに関連するコンポーネントのライフサイクル機能性を管理し、
    前記ＡＭＦソフトウェアは：
    −前記コンポーネントに関連付けられた種類の探索と；
    −前記種類に基づく、前記コンポーネントに関連付けられたソフトウェアの識別と；
    −前記識別されたソフトウェアのためのパス名プレフィックスの探索と；
    −前記コンポーネントをインスタンス化するための前記パス名プレフィックスの使用と；
    の機能を実行することを含むシステム。
22. 前記ライフサイクル機能性は：
    前記コンポーネントのインスタンス化、前記コンポーネントのターミネート、前記コンポーネントのクリーンアップ、前記コンポーネントのＡＭ開始および前記コンポーネントのＡＭ停止の、少なくとも１つを含む、請求項２１に記載のシステム。
23. 前記コンポーネントは、
    ＡＭＦエンティティがエラー検知および分離、回復および修復を実行するサービスに関連する最小の論理エンティティである、請求項２１に記載のシステム。
24. 前記ソフトウェアは、
    前記コンポーネントが割り当てられるサービスユニットによって提供されるサービスの提供に関連するソフトウェアである、請求項２１に記載のシステム。
25. 前記パス名プレフィックスは、
    ＡＭＦノード固有かつソフトウェア固有のプレフィックスであって、前記コンポーネントの種類と関連付けられたコマンドごとの相対パス名と結合されたとき、コマンドラインインタフェース（ＣＬＩ）コマンドのためのパス名を定義する、請求項２１に記載のシステム。
26. 前記ＡＭＦソフトウェアは、
    複数のノードのいずれかに、前記ソフトウェアの新たなバージョンがインストールされる度に、前記ソフトウェアのインストール場所を更新する、請求項２１に記載のシステム。
    

Images