(57)【特許請求の範囲】
【請求項１】
サービスをサポートするハードウェアプラットフォームと、
複数の階層レベルを含む階層的なフレームワークにおいて前記サービスの可用性をサポートする、分散配置される可用性管理（ＡＭ）ソフトウェアエンティティであって、
第１階層レベルにおいて関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部、
第２階層レベルにおいて関連する第２のＡＭ機能セットを有する第１の複数のローカルＡＭＣ（ＡＭＣｌ）部、
並びに、第３階層レベルにおいて前記サービスの可用性をサポートするために前記第１及び第２のＡＭ機能セットを供給される第１の複数のＡＭＣコンポーネント、
を含む前記ＡＭソフトウェアエンティティと、
関連する第３のＡＭ機能セットを有する第１のＡＭ拡張部であって、前記ＡＭＣｇ部により供給される前記第１のＡＭ機能セットを補うプラグインソフトウェアエンティティである当該第１のＡＭ拡張部と、
を有し、
前記第１のＡＭ拡張部は、前記第１階層レベルに位置し、前記第３のＡＭ機能セットは、前記第１及び第２のＡＭ機能セットと相互排他的である、
システム。
【請求項２】
前記第３階層レベルにおいて提供される前記第１の複数のＡＭＣコンポーネントは、前記複数のローカルＡＭＣ部のうちの対応する１つによりそれぞれ管理され、前記第１のＡＭ拡張部に冗長性を提供する、請求項１に記載のシステム。
【請求項３】
前記第１のＡＭ機能セットは、少なくとも、
（ａ）前記ＡＭＣｇ部により管理されるエンティティの調子を監視する機能、
（ｂ）依存するエンティティに対して依存される側のエンティティの状態を通知する機能、
（ｃ）前記エンティティのライフサイクルを管理する機能、
（ｄ）サービスの役割を割当てる機能、
（ｅ）役割を引き受ける機能、
（ｆ）前記第１のＡＭ拡張部と通信する機能、
並びに、（ｇ）前記ＡＭＣｇ部及び前記第１のＡＭ拡張部のうち少なくとも１つを再起動する機能
のうちの１つを含む、請求項１に記載のシステム。
【請求項４】
前記第３のＡＭ機能セットは、少なくとも、
（ａ）前記ＡＭＣｇ部による前記第１のＡＭ拡張部のライフサイクル制御を可能とする機能、
（ｂ）前記ＡＭＣｇ部と通信する機能、
（ｃ）複数のサービスの役割のうちの１つに応じて動作する機能、
及び、（ｄ）前記第１のＡＭ拡張部の機能と関連付けられるアプリケーションプログラムインタフェース（ＡＰＩ）を提供する機能、
のうちの１つを含む、請求項１に記載のシステム。
【請求項５】
前記第１のＡＭ拡張部と関連付けられる前記第３のＡＭ機能セットは、前記第１のＡＭ機能セットによりサポートされない冗長化モデルを提供する、請求項１に記載のシステム。
【請求項６】
前記第１のグローバル可用性管理コア（ＡＭＣｇ）部、前記第１の複数のローカルＡＭＣ（ＡＭＣｌ）部、及び前記第１の複数のＡＭＣコンポーネントは、全て第１の仮想的なクラスターと関連付けられており、
前記システムは、さらに第２の仮想的なクラスターを有し、当該クラスターは、
前記第１階層レベルにおいて関連する第４のＡＭ機能セットを有する第２のグローバル可用性管理コア（ＡＭＣｇ）部、
前記第２階層レベルにおいて関連する第５のＡＭ機能セットを有する第２の複数のローカルＡＭＣ（ＡＭＣｌ）部、
並びに、前記第３階層レベルにおいて前記サービスの可用性をサポートするために前記第４及び第５のＡＭ機能セットを供給される第２の複数のＡＭＣコンポーネント、
を含む、
請求項１に記載のシステム。
【請求項７】
前記システムは、関連する第６のＡＭ機能セットを有する第２のＡＭ拡張部、をさらに有し、
前記第３階層レベルにおいて提供される前記第２の複数のＡＭＣコンポーネントは、前記第２の複数のローカルＡＭＣコンポーネントのうちの対応する１つによりそれぞれ管理され、前記第２のＡＭ拡張部を冗長的に提供する、
請求項６に記載のシステム。
【請求項８】
前記第２のＡＭ拡張部に関連付けられる前記第６のＡＭ機能セットは、前記第４のＡＭ機能セットによりサポートされない役割統合機能を提供する、請求項７に記載のシステム。
【請求項９】
前記システムは、
前記第１及び第２の仮想的なクラスターと通信して当該第１及び第２の仮想的なクラスターの間で可用性管理を統合する、前記第１階層レベルよりも上位の階層レベルに配置されるシステムレベルＡＭＣｇ、
をさらに有する、請求項６に記載のシステム。
【請求項１０】
ハードウェアプラットフォームによりサービスを提供するステップと、
複数の階層レベルを含む階層的なフレームワークにおいて前記サービスの可用性をサポートする可用性管理（ＡＭ）ソフトウェアエンティティを分散配置するステップと、
を含む方法であって、
分散配置される前記ＡＭソフトウェアエンティティは、
第１階層レベルにおいて関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部、
第２階層レベルにおいて関連する第２のＡＭ機能セットを有する第１の複数のローカルＡＭＣ（ＡＭＣｌ）部、
並びに、第３階層レベルにおいて前記サービスの可用性をサポートするために前記第１及び第２のＡＭ機能セットを供給される第１の複数のＡＭＣコンポーネント、
を有し、
前記方法は、関連する第３のＡＭ機能セットを有する第１のＡＭ拡張部であって、前記ＡＭＣｇ部により供給される前記第１のＡＭ機能セットを補うプラグインソフトウェアエンティティである当該第１のＡＭ拡張部、を提供するステップ、をさらに含み、
前記第１のＡＭ拡張部は、前記第１階層レベルに位置し、前記第３のＡＭ機能セットは、前記第１及び第２のＡＭ機能セットと相互排他的である、
方法。
【請求項１１】
前記第３階層レベルにおいて提供される前記第１の複数のＡＭＣコンポーネントは、前記複数のローカルＡＭＣ部のうちの対応する１つによりそれぞれ管理され、前記第１のＡＭ拡張部に冗長性を提供する、請求項１０に記載の方法。
【請求項１２】
前記第１のＡＭ機能セットは、少なくとも、
（ａ）前記ＡＭＣｇ部により管理されるエンティティの調子を監視する機能、
（ｂ）依存するエンティティに対して依存される側のエンティティの状態を通知する機能、
（ｃ）前記エンティティのライフサイクルを管理する機能、
（ｄ）サービスの役割を割当てる機能、
（ｅ）役割を引き受ける機能、
（ｆ）前記第１のＡＭ拡張部と通信する機能、
並びに、（ｇ）前記ＡＭＣｇ部及び前記第１のＡＭ拡張部のうち少なくとも１つを再起動する機能
のうちの１つを含む、請求項１０に記載の方法。
【請求項１３】
前記第３のＡＭ機能セットは、少なくとも、
（ａ）前記ＡＭＣｇ部による前記第１のＡＭ拡張部のライフサイクル制御を可能とする機能、
（ｂ）前記ＡＭＣｇ部と通信する機能、
（ｃ）複数のサービスの役割のうちの１つに応じて動作する機能、
及び、（ｄ）前記第１のＡＭ拡張部の機能と関連付けられるアプリケーションプログラムインタフェース（ＡＰＩ）を提供する機能、
のうちの１つを含む、請求項１０に記載の方法。
【請求項１４】
前記第１のＡＭ拡張部と関連付けられる前記第３のＡＭ機能セットは、前記第１のＡＭ機能セットによりサポートされない冗長化モデルを提供する、請求項１０に記載の方法。
【請求項１５】
前記第１のグローバル可用性管理コア（ＡＭＣｇ）部、前記第１の複数のローカルＡＭＣ（ＡＭＣｌ）部、及び前記第１の複数のＡＭＣコンポーネントは、全て第１の仮想的なクラスターと関連付けられており、
前記方法は、さらに第２の仮想的なクラスターを提供するステップ、を含み、
当該第２の仮想的なクラスターは、
前記第１階層レベルにおいて関連する第４のＡＭ機能セットを有する第２のグローバル可用性管理コア（ＡＭＣｇ）部、
前記第２階層レベルにおいて関連する第５のＡＭ機能セットを有する第２の複数のローカルＡＭＣ（ＡＭＣｌ）部、
並びに、前記第３階層レベルにおいて前記サービスの可用性をサポートするために前記第４及び第５のＡＭ機能セットを供給される第２の複数のＡＭＣコンポーネント、
を有する、
請求項１０に記載の方法。
【請求項１６】
前記方法は、関連する１つ以上の第６のＡＭ機能セットを有する第２のＡＭ拡張部を提供するステップ、さらに含み、
前記第３階層レベルにおいて提供される前記第２の複数のＡＭＣコンポーネントは、前記第２の複数のローカルＡＭＣコンポーネントのうちの対応する１つによりそれぞれ管理され、前記第２のＡＭ拡張部を冗長的に提供する、
請求項１５に記載の方法。
【請求項１７】
前記第２のＡＭ拡張部に関連付けられる前記第６のＡＭ機能セットは、前記第４のＡＭ機能セットによりサポートされない役割統合機能を提供する、請求項１６に記載の方法。
【請求項１８】
前記方法は、
前記第１及び第２の仮想的なクラスターと通信して当該第１及び第２の仮想的なクラスターの間で可用性管理を統合する、前記第１階層レベルよりも上位の階層レベルに配置されるシステムレベルＡＭＣｇ、
を提供するステップ、をさらに有する、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、高可用性システム（ハードウェア及びソフトウェア）に関し、より具体的には、そうした高可用性システムと関連付けられるプラットフォーム管理に関する。
【背景技術】
【０００２】
高可用性（high−availability）システム（ＨＡシステムとしても知られる）は、主にシステムが提供するサービスの可用性を向上させる目的で実現されるシステムである。可用性は、システム又はサービスが稼動（“ｕｐ”）している時間の割合として表され得る。例えば、９９．９９９％の可用性（所謂“ファイブナイン（５つの９）可用性”）のために設計されるシステムとは、ひと月に約０．４４分、一年に約５．２６分のみの停止時間を有するシステム又はサービスを指している。
【０００３】
高可用性システムは、求められる可用性のレベルを達成するために、システムコンポーネントがエラーを起こしたときにサービスの提供に使用される冗長化ノードを備えている。例えば、特定のアプリケーションを実行しているサーバがクラッシュした場合、ＨＡシステムは、クラッシュを検知し、他の冗長化ノード上でアプリケーションを再起動する。ＨＡシステムにおいては、様々な冗長化モデルを使用することができる。例えば、Ｎ＋１冗長化モデルでは、（プライマリノードの数に対して）余分な１つのノードが供給され、そのノードが、エラーを起こしたノードの役割を引き受けるためにオンライン化される。しかしながら、単一のＨＡシステムが多くのサービスを管理する状況においては、専用の１つのノードだけでは、エラーをハンドリングするために十分な冗長性を有するとは言えない。そうした状況では、例えば、１つ以上の（Ｍ個の）利用可能なスタンバイノードが含まれるＮ＋Ｍ冗長化モデルが使用され得る。
【０００４】
ファイル共有、顧客向けインターネットポータル又はデータベースなどのような重要なサービスをサポートするためにＨＡシステムがより当たり前のものとなるにつれ、そうしたシステムの設計のための標準的なモデル及び方法論が提供されることが望まれている。例えば、サービス可用性フォーラム（Service  Availability  Forum：ＳＡＦ）では、移植可能で可用性の高いアプリケーションの開発のための支援をするアプリケーションインタフェースサービス（Application  Interface  Services：ＡＩＳ）の標準化が行われた。図１の概念的なアーキテクチャスタックに示されているように、ＡＩＳ１０は、互いに独立したＨＡアプリケーション１４とＨＡミドルウェア１６との間の標準化されたインタフェースを提供することを意図して設けられている。後に説明するように、ＡＩＳの一連の機能性は、それぞれオペレーティングシステム２０及びハードウェアプラットフォーム２２に関連付けられる。なお、ＡＩＳの標準仕様についてのさらなる情報は、アプリケーションインタフェース仕様（ＡＩＳ）バージョンＢ．０２．０１（www.saforum.orにて入手可能）を参照することで得ることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本出願の特に興味深い点は、ＡＩＳ仕様の中で定義されたソフトウェアエンティティ（entity：構成要素）である可用性管理フレームワーク（Availability  Management  Framework：ＡＭＦ）である。ＡＩＳ仕様によれば、ＡＭＦは、クラスター内の冗長化資源を協調させることによるサービスの可用性を提供するための標準化された仕組みであって、１つのエラー箇所も伴わないシステムを実現することを目的としている。ＡＭＦは、特に、クラスター内のコンポーネントの状態及びそれらコンポーネントの調子（health）を判定するための一連のアプリケーションプログラムインタフェース（Application  Program  Interfaces：ＡＰＩ群）を提供する。また、それらコンポーネントには、ＡＭＦに対してその状態に関する情報を問合せるための機能が提供される。ＡＭＦのＡＰＩ群を使用して開発され、ＡＭＦのシステムモデルに従ったアプリケーションは、そのサービスの可用性を管理することによる負荷をＡＭＦに委ねることができる。従って、そうしたアプリケーションは、コンポーネントのエラー又はメンテナンスなどに関連する動的な再構成という課題を扱わなくてよい。
【０００６】
上述した標準仕様において規定されているように、各ＡＭＦ（ソフトウェアエンティティ）は、図２に示したような多数のクラスターノード及びコンポーネントにより構成される単一の論理的クラスターについての可用性のサポートを提供する。例えば、第１のクラスターＡは、それ自身のＡＭＦ２４、２つのＡＭＦノード２６及び２８、並びに４つのＡＭＦコンポーネント３０〜３６を含む。同様に、第２のクラスターＢは、それ自身のＡＭＦ３８、２つのＡＭＦノード４０及び４２、並びに４つのＡＭＦコンポーネント４４〜５０を含む。コンポーネント３０〜３６及びコンポーネント４４〜５０は、それぞれＡＭＦ２４及び３８により管理される一連のハードウェア資源及びソフトウェア資源を表す。物理的な意味においては、各コンポーネントは、ＨＡアプリケーションのプロセスとして実現される。ノード２６、２８、４０及び４２は、それぞれ物理的なノードに対応する論理的なエンティティを表す。そして、各ノード上でＡＭＦコンポーネントとして管理されるそれぞれのプロセスが実行されると共に、それらノードの可用性を管理するための冗長化要素が割当てられる。
【０００７】
運用時には、各クラスターは、それ自体が障害区域（fault  zone）として扱われ、従って、ＡＭＦ  Ａ２４及びＡＭＦ  Ｂ３８は互いに独立して動作する。いくつかのアプリケーションについては、独立したＡＭＦソフトウェアエンティティが提供されることにより問題が生じることはない。しかしながら、例えば、１つのクラスターのノードが複数のハードウェアプラットフォームをまたがって実行されるような仮想化が導入された場合には、図２に示したＡＭＦアーキテクチャは問題となる。例えば、１つのＡＭＦが、監視の対象のサーバであって異なるクラスターに関連付けられた仮想的なノードを含むサーバを再起動させることを決定したとする。その場合、その仮想的なノードについて責任を持つ他のＡＭＦは、その再起動をエラーとして検知し、（潜在的に不適切な）復旧のためのアクションを開始するかもしれない。
【０００８】
従って、上述した問題点及び欠点を回避するＨＡアプリケーションのためのプラットフォーム管理システム及び方法が提供されることが望ましい。
【課題を解決するための手段】
【０００９】
ある一例としての実施形態によれば、あるシステムは、サービスをサポートするハードウェアプラットフォームを含む。そして、可用性管理（ＡＭ）ソフトウェアエンティティが、上記サービスの可用性をサポートする。可用性管理（ＡＭ）ソフトウェアエンティティは分散配置され、第１階層レベルにおいて関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部、第２階層レベルにおいて関連する第２のＡＭ機能セットを有する第１の複数のローカルＡＭＣ（ＡＭＣｌ）部、並びに、第３階層レベルにおいて上記サービスの可用性をサポートするために上記第１及び第２のＡＭ機能セットを供給される第１の複数のＡＭＣコンポーネント、を含む。
【００１０】
他の一例としての実施形態によれば、あるシステムは、サービスをサポートするハードウェアプラットフォームを含む。そして、可用性管理（ＡＭ）ソフトウェアエンティティが、上記サービスの可用性をサポートする。可用性管理（ＡＭ）ソフトウェアエンティティは、関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部、及び、関連する１つ以上のＡＭ機能の第２のセットを有する第１のＡＭ拡張部であって、上記ＡＭＣｇ部により供給される上記第１のＡＭ機能セットを補うプラグインソフトウェアエンティティである当該第１のＡＭ拡張部、を含む。
【００１１】
他の一例としての実施形態によれば、ある方法は、ハードウェアプラットフォームによりサービスを提供するステップと、上記サービスの可用性をサポートする可用性管理（ＡＭ）ソフトウェアエンティティを分散配置するステップと、を含む。そして、分散配置される上記ＡＭソフトウェアエンティティは、第１階層レベルにおいて関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部、第２階層レベルにおいて関連する第２のＡＭ機能セットを有する第１の複数のローカルＡＭＣ（ＡＭＣｌ）部、並びに、第３階層レベルにおいて上記サービスの可用性をサポートするために上記第１及び第２のＡＭ機能セットを供給される第１の複数のＡＭＣコンポーネント、を有する。
【００１２】
さらに他の一例としての実施形態によれば、ある方法は、ハードウェアプラットフォームによりサービスを提供するステップと、可用性管理（ＡＭ）ソフトウェアエンティティにより上記サービスの可用性をサポートするステップと、を含む。そして、上記ＡＭソフトウェアエンティティは、関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部、及び、関連する１つ以上のＡＭ機能の第２のセットを有する第１のＡＭ拡張部であって、上記ＡＭＣｇ部により供給される上記第１のＡＭ機能セットを補うプラグインソフトウェアエンティティである当該第１のＡＭ拡張部、を有する。
【図面の簡単な説明】
【００１３】
本明細書の一部をなす添付図面は、１以上の実施形態を描いたものであり、その記述と共にそれら実施形態を説明するものである。
【００１４】
【図１】アプリケーションインタフェースサービス（ＡＩＳ）に関連付けられる概念的なアーキテクチャスタックを示している。
【図２】従来の可用性管理フレームワーク（ＡＭＦ）のためのクラスターのアーキテクチャを示している。
【図３】複数のクラスターについてプラットフォーム管理を提供する一例としての仕組みを示している。
【図４】一実施形態に係る分散型のプラットフォーム管理の一例を示している。
【図５】他の実施形態に係る分散型のプラットフォーム管理の一例を示している。
【図６】一実施形態に係る分散型のプラットフォーム管理を提供するための方法の一例を表すフローチャートである。
【図７】他の実施形態に係る分散型のプラットフォーム管理を提供するための方法の一例を表すフローチャートである。
【発明を実施するための形態】
【００１５】
本発明に係る一例としての実施形態について、添付図面を参照しながらこれ以降に説明する。異なる図面についての同一の符号は、同一の又は同様の要素を特定するものである。これ以降の詳細な記述は、本発明の範囲を限定するものではない。その代わりに、本発明の範囲は、添付された特許請求の範囲により定義される。
【００１６】
上述したような可用性管理が対象とする範囲は、ＳＡＦにより公表されているように、固有のＡＭＦソフトウェアエンティティを伴うそれぞれのクラスター、即ち互いに独立したクラスターを供給することに限られている。これに対し、仮想化の導入に関連付けられる課題を解決するためには、とりわけ、図３に概念的に示したような全てのシステムコンポーネントを監視するグローバルＡＭＦ５２の導入が１つの解決策となり得る。しかしながら、全てのクラスターにとって全ての可能性のあるＡＭＦの機能が必要となるわけではない。即ち、状況によって、特定のＡＭＦクラスターによりプロセス又はハードウェアの高可用性をサポートするために、基本的な冗長性のみが提供されればよい場合もある。
【００１７】
従って、そうした場合に対処するため及び他の理由のために、グローバルＡＭＦ５２の代わりに、図４に例示したように、一実施形態において分散型の可用性管理の形態が提供され得る。そこでは、可用性管理エンティティ４００は、分散型の機能性のための複数のレベルを含む。かかる例においては、階層内の３つのレベルが示されている。しかしながら、いわゆる当業者は、これら実施形態に係る分散型のプラットフォーム管理において、より多くのレベル又はより少ないレベルが用いられてもよいことを理解するであろう。図４の第１レベルにおいて、グローバル可用性管理コア（ＡＭＣｇ：global  Availability  Management  Core）４０２は、自ら（即ち、管理用の拡張機能（Management  Extension）（ＡＭＥ）４０３を考慮することなく）第２レベルの各ローカル可用性管理コア（ＡＭＣｌ：local  Availability  Management  Cores）４０４、４０６及び４０８を含む第１の可用性管理機能セットを提供するために動作するソフトウェアエンティティである。ＡＭＣｇ４０２及びＡＭＣｌ４０４、４０６及び４０８は、一体として、第３レベルのＡＭＣコンポーネント４１２、４１４及び４１６に第２のあるいは基本的な可用性管理機能セットを提供する。
【００１８】
ＡＭＣｇ４０２により提供される第１の可用性機能（availability  functions）セットは、分散型の階層内でＡＭＣｇと同じレベルに位置する可用性管理の拡張機能（ＡＭＥ）４０３によって拡大されることができる。ＡＭＥ４０３は、ＡＭＣｇ４０２によって提供される主要な機能（core  functions）を補うように動作するプラグインである。第１の機能セット及び第３の機能セットに属し得る特有の機能の例は、後に提示される。ＡＭＥ４０３は、ＡＭＣコンポーネント４１２、４１４又は４１６のうちの１つ（本例ではＡＭＣコンポーネント４１２）により供給される。ＡＭＣコンポーネント４１２、４１４又は４１６は、それぞれＡＭＥ４０３を供給可能である。そのため、ＡＭＥ４０３により提供される第３の機能セットは、分散型プラットフォーム管理４００において冗長的にサポートされる。
【００１９】
上述したように、ＡＭＣｇ４０２により提供される第１の可用性機能セット及びＡＭＥにより提供される第３の可用性機能セットは、ＡＭＣｇ４０２によって、分散型可用性管理エンティティ４００の第２レベルに位置する、それ自身のローカル可用性管理コア（ＡＭＣｌ）ソフトウェアエンティティ４０４、４０６及び４０８に供給される。第１、第２及び第３の可用性管理機能セットの組み合わせは、拡張された可用性を求める（図４に示されていない）コンポーネントの拡張された可用性管理をサポートする第４の可用性管理機能セットによって特徴付けられることができる。単一クラスター環境においては、ＡＭＣｇをクラスターに関連付けることができる一方、異なるＡＭＣｌ群を例えば異なる（仮想的な）ノード群に関連付けることもできる。後者の場合においては、ＡＭＣｌ４０４、４０６及び４０８を介して供給される第４の可用性管理機能セットは、ＳＡＦにより定義されているような、コンポーネントの可用性管理のために使用され得る。また、複合クラスター環境においては、ＡＭＣｇをシステムプラットフォームに関連付けることができる一方、各ＡＭＣｌを異なる（仮想的な）クラスターノード群に関連付けることもできる。その場合、その（仮想的な）ノードとは、ＡＭＣコンポーネントである。そうした複合クラスター環境の（仮想的な）クラスター内のプロセスのための可用性管理を提供するためには、これら２つの環境を組み合わせることが求められる。
【００２０】
ＡＭＣｇとＡＭＣｌとを同じ場所に配置することにより、本発明の一例としての実施形態に従って、どういった数の階層レベル数も提供されることができる。ソフトウェアエンティティの各セットの視点からは、より下位のエンティティは、すぐ上のエンティティを自身にとってのグローバルＡＭＣであるとみなす。ＡＭＣｇ及びＡＭＣｌ（又は分散したＡＭＣ）の各セットは、１つ以上の可用性管理のための拡張機能（ＡＭＥ）によって拡張されてもよい。そのようなＡＭＣｇ及びＡＭＣｌのいずれか１つのセットの中で、ＡＭＥによって提供される機能セットは、拡大するＡＭＣによって提供される可用性管理機能セットに対して互いに排他的である。この分散型の可用性管理（ＡＭ）機能をより具体的に説明するために、次の例は、サポートされる物理的なシステムとしての分散型のプラットフォーム管理ソフトウェアエンティティを描いている。
【００２１】
図５において、高可用性のためにサポートされるシステムの物理的な表現が図中左側に描かれ、そのサポートを提供するために使用される、関連する分散型ＡＭの各部の論理的な表現が図中右側に描かれている。左側から説明を開始すると、例えばサーバシステムなどのシステム６０は、本例において物理ノードＡ６２及び物理ノードＢ６４として示されている複数の物理ノードを含むことができる。１つの純粋に説明のための例として、物理ノードＡ及びＢは、システム６０に関連付けられるプロセッサコアであってもよい。物理ノードＡ６２は、それぞれ関連付けられる２つの異なる実行環境（例えば、オペレーティングシステムのインスタンス）６６及び６８を有する。各実行環境６６及び６８は、それら自身のプロセス７０及び７２をそれぞれ管理及び実装する。物理ノードＢ６４もまた、図の簡明さのために図示されていない同様の実行環境とプロセスのセットを有していてもよい。
【００２２】
本実施形態に係るシステム６０及びそのコンポーネント６２〜７２の可用性をサポートする分散型のＡＭソフトウェアエンティティは、図５の左側に論理的に描かれている。そこでは、グローバルＡＭＣ部７４が、複数の仮想的なクラスターにＡＭ機能のコアとなるセットを提供する。本例において、２つの論理的なクラスター（Ａ及びＢ）が示されているが、いわゆる当業者であれば、他の実施形態として１つのグローバルＡＭＣ部７４によりサポートされる３つ以上の仮想的なクラスターが含まれてもよいことを理解するであろう。グローバルＡＭＣ７４により提供され得るコア機能のセットの具体的な例については、後に説明する。仮想的なクラスターＡのＡＭＣｌ部７６は、仮想的なクラスターＡにおいて、グローバルＡＭＣ７４と物理ノード６２及び６４をそれぞれ表すＡＭＣコンポーネント８２及び８４との間の通信を統合する。なお、例えばクラスターＡについては、（ブロック７６の括弧により示されているように）、ローカルＡＭＣ７６は、分散型の階層内のより下位レベルに位置するエンティティ、例えばＡＭＣコンポーネント８２及び８４の視点からは、クラスターＡのためのグローバルＡＭＣＡとみなされ得る。同様に、それらコンポーネント８２及び８４は、同じ視点からは、クラスターＡに属す実行環境（例えばノード６２についての実行環境６６）を表すローカルＡＭＣＡ部としてみなされ得る。
【００２３】
ローカルＡＭＣＡ部８２及び８４は、ＡＭＣＡコンポーネント７８及び８０の可用性を管理する。上述したように、図４における同様の構造の観点からは、ＡＭＣＡコンポーネント７８及び８０は、本例における冗長化マネージャである後述するＡＭＥ８６を冗長的にサポートする。ＡＭＣＡコンポーネント７８及び８０は、システム６０と関連付けられるプロセスによって実装される。図５においては、プロセス７０のみが特に表されており、当該プロセスは、ＡＭＣＡコンポーネント７８として可用性管理の目的のためのプロセスであって、クラスターＡにおけるＡＭＣＡエンティティ群に冗長化マネージャとしての機能性を（図５に示された時点において）提供する。
【００２４】
上述したように、グローバルＡＭＣ部７４は、グローバルＡＭＣ７４により管理される各クラスターに供給されるＡＭ機能セットを包含する。一実施形態によれば、このＡＭ機能セットは、それらが割当てられる特定の物理的要素及びプロセスの可用性をサポートするために、全てのクラスターにより使用されることが予期される機能を含む。例えば、その機能セットは、（ａ）グローバルＡＭＣ部７４により管理されるエンティティの調子を監視する機能（監視役（watch−dog）機能）、（ｂ）依存するエンティティに対して依存される側のエンティティの状態を通知する機能（ｃ）例えば、エンティティのインスタンス化、終了及び修復のためのエンティティの起動と停止など、グローバルＡＭＣ部７４により管理されるエンティティのライフサイクルを管理する機能、（ｄ）例えば、決定ロジックのためのプラグインを伴う形での、サービスの役割を割当てる機能、（ｅ）例えば、アクティブ、スタンバイ及びスペアなどの様々な役割のためのやはりプラグインを伴う形での、役割を引き受ける機能、（ｆ）例えば、共に遠隔的／代替的ロケーション及び下位レベルに対するトンネル通信のためのプラグイン機能を伴う形で、同レベル（peer）のエンティティ及び／又は下位レベル（subordinate）エンティティを相手としてＡＭ拡張部と通信する機能、（ｇ）グローバルＡＭＣ部７４及び／又はＡＭ拡張部を再起動する機能（例えばブートストラップシーケンスなど）、などである。なお、他の実施形態によれば、グローバルＡＭ部７４は、上に掲げた全ての機能よりも少ない機能のみを含んでもよい。
【００２５】
上述したＡＭ拡張部は、グローバルＡＭＣＡ部７６の拡張についてのものである。例えば、図５のクラスターＡ及びクラスターＢなどの各クラスター又は仮想的なクラスターは、そのクラスターによりサポートされる特定の物理的要素の可用性管理をサポートするために必要とされるやり方で各ＡＭＣ７６、８８のＡＭ機能性を拡張する固有のＡＭ拡張部を有してもよい。例えば、図５の仮想的なクラスターＡについて検討する。ここで、仮想的なクラスターＡによりその可用性がサポートされるＨＡサービスＣが、グローバルＡＭＣ部７６によりサポートされるモデルよりも複雑な冗長化モデル（例えばＭ＋Ｎ）を要求しているとする。この純粋な説明のための例において、ＡＭＣコンポーネント７８は、仮想的なクラスターＡのＡＭＣＡ部７６と通信するＡＭ拡張部８６を提供することにより、本実施形態に係る分散型のＡＭ構造内でのより複雑な冗長化モデルの管理をサポートする。仮想的なクラスターＡのＡＭＣＡ部７６は、例えば、役割の割当て及びＡＭＣＡコンポーネント７９及び８１により表されるＨＡサービスＸを提供するコンポーネントのライフサイクルについての決定を行うために、ＡＭ拡張部８６の出力を用いることができる。ＡＭ拡張８６により扱われる冗長化モデルは、全てのクラスターのＡＭオペレーションをサポートすることを求められてはいないため、（本例においては）グローバルＡＭＣ部７４により提供される機能セットには含められておらず、その代わりにクラスターレベルで拡張又はプラグインとして局所的に供給される。
【００２６】
次に、図５の仮想的なクラスターＢを参照すると、仮想的なクラスターＡについて上述した論理的な構造と同様の構造が示されている。ここでは、仮想的なクラスターＢのローカルＡＭＣ部８８は、グローバルＡＭＣ部７４とＡＭＣコンポーネント９４及び９６との間の通信をプラットフォーム管理レベルで統合する。本例においては、（クラスターレベルで）仮想的なクラスターＢのＡＭＣＢ部８８は、２つの仮想的なノード９４及び９６を含む。仮想的なノード９４は、例えば、物理的な実行環境６８に相当する。この仮想的なノード（あるいはローカルＡＭＣＢ）９４は、順にＡＭＣＢコンポーネント９０を管理し、ローカルＡＭＣＢ９６は、ＡＭＣＢコンポーネント９２を管理する。これらコンポーネントは、ＡＭＣＡコンポーネント７８及び８０に関連する機能とは相違し得る特定のアプリケーション機能をカプセル化するものである。本例において、ＡＭＣＢコンポーネント９０（及びＡＭＣＢコンポーネント９２）は、ＡＭＥ９８の可用性をそれらの間の矢印で示しているようにサポートする。ＡＭＣＢコンポーネント９０及び９２は、システム６０に関連する異なるプロセスを表している。例えば、ＡＭＣＢコンポーネント９０は、ローカルＡＭＣＢ部８８の管理下にあるプロセス７２を表している。
【００２７】
従って、図５の実施形態では、可用性管理機能に関連付けられた２つの異なる仮想的なクラスター（仮想的なクラスターＡ及び仮想的なクラスターＢ）が１つの物理ノード（物理ノード６２）と関連付けられる例が提示されており、本実施形態に係るプラットフォーム管理が特に有益である特有のシナリオが描かれていることが理解されるであろう。もちろん、いわゆる当業者であれば、本発明は図５に描かれた物理的又は論理的構造に限定されず、その代わりに多くの代替的な実施形態に適用可能であることも理解するであろう。
【００２８】
仮想的なクラスターＡと比べて、本実施形態におけるＡＭＣＢ機能自体は、ローカルＡＭＣＢ部９４及び９６により提供されない、あるＡＭ機能を必要とする。より具体的には、本例において、ＡＭＣＢは、ローカルＡＭＣＢ９４及び９６に対して相対的にグローバルＡＭＣＢとしての役割を担うべき特定のローカルＡＭＣＢ部９４及び９６の選択について交渉する交渉（arbiter）機能を必要とする。この交渉機能は、グローバルＡＭＣＢの提供に先立って各ローカルＡＭＣＢを拡張するため、ＡＭＣコンポーネント９０及び９２の可用性は、各ローカルＡＭＣ部９４及び９６のみに基づいて、拡張なしで局所的に管理される。
【００２９】
上述した内容により、一実施形態に係る分散型の階層的プラットフォームによる可用性管理システムが提供される。しかしながら、他の実施形態をより一般的な形で表現することができる。例えば、それら実施形態によれば、可用性管理（ＡＭ）ソフトウェアエンティティは、ハードウェアプラットフォームにより提供されるサービスの可用性管理をサポートする。そして、その分散配置されるＡＭソフトウェアエンティティは、関連する第１のＡＭ機能セットを有する第１階層レベルにおける第１のグローバル可用性管理コア（ＡＭＣｇ）部と、関連する第２のＡＭ機能セットを有する第２階層レベルにおける第１の複数のローカルＡＭＣ（ＡＭＣｌ）部と、サービスの可用性をサポートするために上記第１及び第２のＡＭ機能セットが供給される第３の階層レベルにおける第１の複数のＡＭＣコンポーネントと、を含む。それに加えて、ある実施形態では、ＡＭ拡張により拡大されたＡＭ機能セットを有する１つ以上のＡＭエンティティの組み合わせが考慮されてもよい。例えば、そのような実施形態の表現として、サービス及びサービスの可用性を管理するための可用性管理（ＡＭ）ソフトウェアエンティティをサポートするためのハードウェアプラットフォームであって、当該ＡＭソフトウェアエンティティには、関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部と、関連する１つ以上のＡＭ機能の第２のセットを有する第１のＡＭ拡張部と、が含まれ、上記第１のＡＭ拡張部は、上記ＡＭＣｇ部により供給される第１のＡＭ機能セットを補うプラグインソフトウェアエンティティである。
【００３０】
この後者の点では、グローバルＡＭＣ部を、複数のクラスターに供給可能な基本的なＡＭ機能セットを有するルートノードと見ることができると共に、ＡＭ拡張部を、追加的なＡＭ機能によりルートノードの機能性を拡大させるためのルートノードに接続される葉（leaf）ノードとみることができる。また、実施形態は、仮想的なクラスターをサポートするものに限定されず、かつグローバルＡＭＣ部７４にサポートされる各クラスター又は仮想的なクラスターは、関連する固有のＡＭ拡張を持たなくてもよい。例えば、１つのハードウェアであるエンティティに関連付けられるＡＭクラスター又は仮想的なクラスターの可用性のニーズは、グローバルＡＭ部７４により提供されるＡＭ機能セットにより完全に充足され得るため、その場合にはＡＭ拡張部は必要とされない。
【００３１】
従って、一実施形態に係る可用性管理を提供するための一般的なプロセスは、図６のフローチャートにより表される。そこでは、ステップ１００において、１つ以上のサービスがハードウェアプラットフォームにより提供される。これらサービスの可用性をサポートするために、可用性管理（ＡＭ）ソフトウェアエンティティは、次のように分散配置される（ステップ１１０）。即ち、（ａ）第１階層レベルにおいて、関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部を提供する（ステップ１２０）。（ｂ）第２階層レベルにおいて、関連する第２のＡＭ機能セットを有する第１の複数のローカルＡＭＣ（ＡＭＣｌ）部を提供する（ステップ１３０）。（ｃ）サービスの可用性をサポートするために上記第１及び第２のＡＭ機能セットが供給される第３の階層レベルにおける第１の複数のＡＭＣコンポーネントを提供する。
【００３２】
他の実施形態によれば、可用性管理を提供するための一般的なプロセスは、図７のフローチャートに表された各ステップを含む。そこでは、ステップ２００において、１つ以上のサービスがハードウェアプラットフォームにより提供される。これらサービスの可用性をサポートするために、可用性管理（ＡＭ）ソフトウェアエンティティは、関連する第１のＡＭ機能セットを有する第１のグローバル可用性管理コア（ＡＭＣｇ）部を提供する（ステップ２１０）。また、可用性管理（ＡＭ）ソフトウェアエンティティは、関連する１つ以上のＡＭ機能の第２のセットを有する第１のＡＭ拡張部を提供する（ステップ２２０）。ここで、上記第１のＡＭ拡張部は、上記ＡＭＣｇ部により供給される上記第１のＡＭ機能セットを補うプラグインソフトウェアエンティティである。
【００３３】
ここまで、図５の実施形態に関連して、ＡＭ拡張部として提供され得る複数のＡＭ機能の例について説明した。しかしながら、いわゆる当業者であれば、ＡＭ拡張部として他のＡＭ機能が提供されてもよいことを理解するであろう。例えば、これら実施形態に係るプラットフォーム管理システム及び方法によりサポートされるサービスインスタンス又はシステム上で実行されるアプリケーションの間の依存性を計算するような他の形態のＡＭ拡張が提供されてもよい。より一般的には、ＡＭ拡張部は、典型的には、次のような機能を有する。即ち、（ａ）グローバルシステムＡＭＣ部による第１のＡＭ拡張部のライフサイクル制御を可能とする機能、（ｂ）グローバルＡＭＣ部と通信するための機能、（ｃ）サービスの複数の役割の１つに応じて動作する機能、及び（ｄ）第１のＡＭ拡張部の機能に関連するアプリケーションプログラムインタフェース（ＡＰＩ）を提供するための機能である。こうした実施形態によれば、ＡＭ拡張部を独立して動作し得るプロセスとして実装することができ、それによりＡＭＣのアップグレードの必要性が最小化される。
【００３４】
本発明の一例としての実施形態についてのこれまでの記述は、実例と説明とを提供しているものの、網羅的な説明を意図したものではなく、開示された通りの形態に本発明が限定されるものではない。上記内容を考慮して修正又は変形を行うことは可能であり、それらは本発明の実施によってもたらされ得る。本発明の範囲は、次の特許請求の範囲及びその均等の範囲により定義される。
【図１】
0005398542.tif 000002
【図２】
0005398542.tif 000003
【図３】
0005398542.tif 000004
【図４】
0005398542.tif 000005
【図５】
0005398542.tif 000006
【図６】
0005398542.tif 000007
【図７】
0005398542.tif 000008