(57)【要約】このコンピュータによって実施されるソフトウェアの発明は、サービス・アベイラビリティを最大にし、サービスへのオンデマンド式及び無停止のアクセスを提供し、故障によるダウン時間を最小にするということを目的とした、ネットワーク化されたシステム・リソースを管制する。リソースの状態及びアクティビティを調整し、アベイラビリティ・ロールを割り当て、故障からの回復を行い、システム全体のポリシーを実施するのは、クラスタ全体のソリューションである。これを行うために、クラスタ全体のソリューションは、システムの物理的且つ論理的構成のシステムモデルを維持すると共に、システム・リソースの状態、ロール、及び関係の拡張表現を供給する管理対象オブジェクトを用いてリソースをモデル化する。
2004512610.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク化されたコンピュータシステムサービスへのオンデマンド式及び無停止のアクセスを維持する方法であって、
ａ）どのようなクラスタ・リソースがネットワークに存在しているかを判断し、管理対象オブジェクトアブストラクションを供給することによって、前記クラスタ・リソースを表すステップと、
ｂ）前記リソース間における従属関係の有向グラフを確立するステップと、
ｃ）前記クラスタに対し、アベイラビリティ・マネージャとしての特定ノードを選択するステップと、
ｄ）待機アベイラビリティ・マネージャとしての別のノードを選択するステップと、
ｅ）前記アベイラビリティ・マネージャ、前記待機アベイラビリティ・マネージャ、あらゆる非マネージャ・ノード、及び、前記リソースを表す前記管理対象オブジェクト間における通信リンクを確立するステップと、
ｆ）システム状態及び状況の変更に対する所望のクラスタ・リソース応答を決定するポリシーを確立するステップと、
ｇ）必要に応じてリソース・ロールを再割り当てすることによって、前記システム状態及び状況の変更に応答するステップと、
を含む前記方法。
【請求項２】
前記クラスタ・リソースが、ハードウェアコンポーネント、アプリケーション、ミドルウェア、及びオペレーティングシステムを含む、請求項１に記載の方法。
【請求項３】
ＡＰＩ、コンソール・コマンド、及びＳＮＭＰエージェントを介して、前記クラスタ・リソースへの一貫した一様なインタフェースを提供するステップをさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本出願には、２０００年１０月１６日に出願された米国仮特許出願第６０／２４１，０３１号の恩典が与えられる。
【０００２】
本出願の本発明は、同時係属ＰＣＴ出願、即ち、２００１年８月１７日に出願された「複数ノードを含むクラスタを管理するシステム及び方法（Ａ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｍａｎａｇｉｎｇ Ｃｌｕｓｔｅｒｓ Ｃｏｎｔａｉｎｉｎｇ Ｍｕｌｔｉｐｌｅ Ｎｏｄｅｓ）」という発明の名称である第ＰＣＴ／ＵＳ０１／２５８３５号、並びに、２００１年４月２日に出願された「有向グラフを用いてロールを管理するコンポーネント管理データベースの構成（Ｃｏｎｓｔｒｕｃｔｉｎｇ ａ Ｃｏｍｐｏｎｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａｂａｓｅ ｆｏｒ Ｍａｎａｇｉｎｇ Ｒｏｌｅｓ Ｕｓｉｎｇ ａ Ｄｉｒｅｃｔｅｄ Ｇｒａｐｈ）」という発明の名称である第ＰＣＴ／ＵＳ０１／１０７２６号の発明に関連し、この発明を補足するものである。これらの出願は、参照により、その全体が本明細書中に組み込まれる。
【０００３】
本発明は、広く、ネットワーク化されたコンピュータシステムの分野に関する。より詳細には、コンポーネント（構成要素）故障、アプリケーションエラー、ミドルウェアエラー、又はオペレーティングシステムエラーが生じた場合にこれらのシステムの動作を維持する方法に関する。
【０００４】
【従来の技術及び発明が解決しようとする課題】
コンピュータを使用する多くの分野において、コンピュータネットワークの動作を維持することは、ますます重要になってきている。通信、銀行業務、インターネットサーバ、及びその他の２４時間サービスは、持続性且つ信頼性のあるコンピュータ処理に頼ることによって、うまく機能する。初期に有効だったシステムの１つとしては、固定方式で実行されるプロセッサを複数用いた障害許容システムがあり、これらのプロセッサは、連続的に出力を比較して、２つの出力間に相違がある場合にはそれを「障害」とみなし、処理を別のプロセッサセルに切り替えていた。他にも、業者が純粋にハードウェアの障害許容システムを用いる方式がある。しかし、多くの故障はソフトウェアに関連した問題により生じているので、これらのタイプの故障を処理することができると共に、故障したソフトウェアの業務を他の実行中のソフトウェアに途切れることなく且つ迅速に切り替えることができるプロセスを有することが重要である。現在の技術により、特許権を持ついくつかのシステムが提供されているが、これらのシステムは、特定のオペレーティングシステムにおいて実行されるように設計されており、特定タイプのネットワークリソースをサポートする。本発明は、様々なオペレーティングシステムにわたって組み込むことのできる柔軟性を有しており、複数タイプのリソース及びリソースアプリケーションをサポートするように構成することができる。
【０００５】
【課題を解決するための手段】
要約すれば、本発明は、コンピュータ・ノードのネットワーク化されたシステムのオンデマンド式及び無停止のアベイラビリティ（可用性）を維持する方法から成る。コンピュータ・ノードのネットワーク化されたシステムには、いくつかのハードウェア及びソフトウェア・リソースが含まれる。このようなリソースの動作を維持するには、又はもはや機能を実行することのできないリソースの責務を移すには、どのようなリソースがネットワーク化されたシステム上に存在するかを判断することが、まず必要である。リソースが識別されると、そのリソースの機能、メソッド、及び従属関係を表す、アブストラクションが生成され得る。リソースを管理するために、それらの存在、機能、及び従属関係が決定されると、特定ノードが管理ノードとして選択される。また、別のノードがその管理ノードの予備として選択される。マネージャ、待機マネージャ、非マネージャ・ノード、及びその他のリソース間において、通信リンクが確立される。これらのマネージャ及び待機マネージャは、システム状態及び状況の変更に応じて、システムの高アベイラビリティを維持するのに必要な、ポリシーを備える。このようなシステム状態及び状況の変更に応答して、マネージャは、必要に応じて、リソース・ロール（資源役割）の再割当てを行う。
【０００６】
【発明の実施の形態】
本発明及びそのさらなる利点については、以下の説明を添付の図面と合わせて参照することにより、最も良く理解することができるであろう。
【０００７】
用語解説
・属性
管理対象オブジェクトの現在の状態を定義するデータ値のセット。管理対象オブジェクトに対して許容される属性は、管理対象オブジェクトクラスによって定義される。
【０００８】
・アベイラビリティ管理サービス（ＡＭＳ：Ａｖａｉｌａｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ）
アベイラビリティ・マネージャ、及び、それに関連した、クラスタにおけるリソースに対するアプリケーション・インタフェース・ライブラリによって提供される、アベイラビリティ（可用性）機能一式。このアベイラビリティ管理サービスには、アベイラビリティ・マネージャ、その予備（スタンバイ）、システムモデル、及びそのアクセスＡＰＩ（アプリケーション・プログラム・インタフェース）が含まれる。
【０００９】
・アベイラビリティ・マネージャ
クラスタ・マネージャ・ノードにおけるアベイラビリティ・プロセス内で実行される（ランする）このマネージャは、クラスタ中のリソースにアベイラビリティ・サービスを提供する。サポート可能なリソースのタイプの一例としては、図２に注目されたい。これらのリソースとしては、ネットワーク２００自体、通信切り替えカードを含み得るカードシャーシ２０２、カード自体２０４、アプリケーション２０６、及びオペレーティングシステム２１４が挙げられる。クラスタ毎に、１インスタンスのアベイラビリティ・マネージャと、１つのアベイラビリティ・マネージャ予備とがある。
【００１０】
・アベイラビリティ・マネージャ・システムモデル
アベイラビリティ管理サービスによる管理下にある、クラスタの全リソースの論理表現。このアベイラビリティ・マネージャ・システムモデルは、これらのリソースの状態及び関係の拡張表現であり、管理対象オブジェクトの階層的で従属関係に基づいたネットワークの形態を取る。これらの管理対象オブジェクトは、実際のリソースを表し、対応するリソースの実際の状態を表す属性値を有する。
【００１１】
・発見
アベイラビリティ・マネージャを用いてリソースを記録して管理対象オブジェクトを生成するレジストラによって、リソースが発見され識別されるプロセス。
【００１２】
・インタフェース・リポジトリ
図２に示されているようなインタフェース・リポジトリ２１２とは、システムにおいて構成される使用可能な管理対象オブジェクトクラスの定義である。
【００１３】
・管理対象オブジェクト
システムにおける所定のリソースに対する１インスタンスの論理表現。この管理対象オブジェクトは、管理対象オブジェクトクラスをテンプレートとして用いるアベイラビリティ・マネージャによって生成され、アベイラビリティ・マネージャ・システムモデルに記憶される。この定義は、「オブジェクト」と省略されることが多い。
【００１４】
・管理対象オブジェクトクラス
管理対象オブジェクト・インスタンスが生成されるテンプレート。管理対象オブジェクトクラス７１０は、アベイラビリティ・マネージャとリソースとの間のインタフェースを定義する。この管理対象オブジェクトクラスは、リソースの動作状態を示す属性と、リソースを操作して制御するメソッドとを供給する。管理対象オブジェクトクラスは、サブクラスに分類されてもよく、このサブクラスでは、他のクラスによって定義された属性及びメソッドが継承される。アベイラビリティ・マネージャは、継承と多相性（ｐｏｌｙｍｏｒｐｈｉｓｍ）との両方をサポートする。管理対象オブジェクトクラスは、さらに、状態機械、ウェブページ、及び拡張障害管理を供給してもよい。
【００１５】
・管理対象オブジェクトの供給
この管理対象オブジェクトの供給は、システムの初期化において行われてもよいし、その後のユーザコマンドに応答する実行時において行われてもよい。図２の供給された管理対象オブジェクト２１０は、関連するリソース表示を有していてもいなくてもよい。また、アベイラビリティ・マネージャ・システムモデルには、さらに、管理対象オブジェクトクラス、サービスグループ、及びタスクを供給してもよい。
【００１６】
・管理対象オブジェクト状態
アベイラビリティ・マネージャは、状態値を、管理対象オブジェクト属性値として記憶する。この管理対象オブジェクト状態には、管理対象オブジェクトがシステムにおいて動作機能を果たすことができるかどうかを定義する動作状態（ｏｐＳｔａｔｅ： ｏｐｅｒａｔｉｏｎａｌ ｓｔａｔｅ）、管理対象オブジェクトが管理目的で「ロック」又は「ロック解除」されるかどうかを定義する管理状態（ａｄｍｉｎＳｔａｔｅ： ａｄｍｉｎｉｓｔｒａｔｉｏｎ ｓｔａｔｅ）、及び、基本リソースの調子（ｈｅａｌｔｈ）を定義するリソース状態（ｒｅｓｏｕｒｃｅＳｔａｔｅ： ｒｅｓｏｕｒｃｅ ｓｔａｔｅ）が含まれる。
【００１７】
・メソッド
１つのオブジェクトに関して呼び出され得る一連の手続き。
【００１８】
・オブジェクト・リソース・ロケータ（ＯＲＬ：Ｏｂｊｅｃｔ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）
管理対象オブジェクトを独自に識別するオブジェクト参照ストリング（名）。
【００１９】
・レジストラ
１）リソースを発見し、２）管理対象オブジェクトを生成し、３）管理対象オブジェクトを削除する、拡張機構又はアプリケーションのコード。このレジストラは、通常、開発者が生成した本発明の拡張機構又はアプリケーションによって供給され、管理対象オブジェクトクラスに分けられる。レジストラは、この管理対象オブジェクトクラスに対して、管理対象オブジェクトを生成する。
【００２０】
・遠隔動作メソッド
関連するオブジェクトが１つのプロセスにあり、メソッドの実施は別のプロセスにおいて行われるような遠隔メソッド。
【００２１】
・リソース
実際の管理対象コンポーネント。例えば、サーバ、カード、ファン、スイッチ、又はアプリケーション。
【００２２】
・拡張機構
管理対象オブジェクトクラスをプロセスに追加するための受け渡し機構。
【００２３】
・サービスグループ
１セットの同種の管理対象オブジェクトによって用いられる冗長モデル及びポリシーを定義し、ＩＳＯ用語の「保護グループ」に相当する。「グループ」と省略されることが多い。このサービスグループは、切替えポリシー及びそのパラメータを定義して、ロール割当て、管理対象オブジェクト故障、及び切替え事象を効果的に統率する。
【００２４】
本発明は、その作用及び実施形態について説明するのに、アベイラビリティ管理サービス（ＡＭＳ）という用語を用いる。このＡＭＳの目的は、サービス・アベイラビリティが最大になるように、プロセッサ・ノードのクラスタを管理することである。ユーザの観点からすると、サービス・アベイラビリティとは、以下のことを意味する。
・オンデマンド・サービス−システムの稼動率が９９．９９９％。つまり、１年当たり５分間以下の時間を除いて、システムがずっと稼動している。稼動率が９９．９９９％以上のシステムは、通常、可用度が高いと言われる。
・無停止サービス−個々のリソース故障に関わらず、停止することなく、顧客との接続が維持される。
【００２５】
本明細書中において、「システム」という語は、ハードウェア及びソフトウェアを含めて用いられる。ハードウェアもソフトウェアも、人であるか他の装置であるか、いずれにしてもコンシューマ（消費者）にサービスを提供するので、論理的に１つにまとめられる。１つのシステムが複数のサービスを提供してもよいし、複数のシステムを組み合わせることによって機能性を高めることもよく行われる。
【００２６】
ＡＭＳによって、システムは、稼動率を９９．９９９％以上にすることができる。ダウン時間は、サービスに影響を及ぼす故障の頻度（平均故障間隔（ＭＴＢＦ： Ｍｅａｎ−Ｔｉｍｅ−Ｂｅｔｗｅｅｎ−Ｆａｉｌｕｒｅ））と、そのような故障が起きてから作動するようになるまでにかかる時間（平均修理時間（ＭＴＴＲ： Ｍｅａｎ−Ｔｉｍｅ−Ｔｏ−Ｒｅｐａｉｒ））との両方を減少させることによって、最小に抑えられる。さらに、ＡＭＳは、システムのリソースを管理して、障害管理シナリオ中のトランザクション状態を保存する。
【００２７】
リソース
システムリソースには、ハードウェア、ソフトウェア、及びデータがあり、これらがシステムを構成している。リソースとは、システムのあらゆる部分であり、個別に管理される。インフラストラクチャ装置では、リソースとして以下のようなものが挙げられる。
・ハードウェア−ディスクドライブ、ボード、ファン、スイッチ、ケーブル、シャーシ、ライト、電源。
・ソフトウェア−オペレーティングシステム、ドライバ、サーバ、コンテント、アプリケーション。
・論理エンティティ−データベース、ネットワーク・トポロジー、ルート、地理的領域、クラスタ、サービス。
【００２８】
多くのシステムでは、冗長リソースを用いることによって、ダウン時間の短縮を促進させる。例えば、電気通信及びデータ通信サイトでは、冗長ネットワークが広く用いられている。このような冗長性は、ソフトウェアレベルであってもよい。例えば、万一活動アプリケーションが故障した場合、待機アプリケーションがすぐにそれを引き継ぐことができる。
【００２９】
機能概観
サービス・アベイラビリティを最大にするという目的を達成するために、ＡＭＳは以下のようないくつかの機能を行う。
・システムデータベースを維持して、システムにおける全てのリソースを追跡する。このデータベースには、リソースの構成、状態、関係、及び従属性が含まれる。
・システムリソースの状態及びアクティビティを調整することによって、アベイラビリティ・ロール（例えば、活動中（ａｃｔｉｖｅ）や待機中（ｓｔａｎｄｂｙ））を割り当て、故障又は計画的なダウン時間により必要とされる切り替えを管理し、システム全体のポリシーを実施する。
・１セットのアクセス及び操作ＡＰＩを提供して、システムデータベースを制御する。
・Ｎ＋１又はＡｃｔｉｖｅ／Ａｃｔｉｖｅというような、待機関係を介して協働するリソースの集合である、サービスグループを制御する。
・ＡＭＳ自体を管理する。例えば、アベイラビリティ・マネージャは、万一アベイラビリティ・マネージャが故障した場合にその責務を負う、待機マネージャを有する。
【００３０】
ＡＭＳは、障害管理サービスと密に統合することによって、強力な障害及びアベイラビリティ管理ソリューションを提供する。障害管理サービスは、管理対象オブジェクトの故障を検出し、ＡＭＳに通知する。すると、ＡＭＳは、回復を管理する。この回復には、待機中の管理対象オブジェクトへの切り替えが含まれる。
【００３１】
規格
アベイラビリティ・マネージャは、ＩＳＯ　Ｘ．７３１の状態管理機能規格のサブセットをサポートする。この規格は、管理及び動作状態、並びに、制御及びアベイラビリティ状況属性を示している。サポートされるその他の規格としては、ＸＭＬ　１．０、ＨＴＴＰ　１．１、及びＳＮＭＰ　ｖ３が挙げられる。
【００３２】
本発明のアベイラビリティ管理サービスは、システム全体のアベイラビリティを管理する、クロスプラットフォームで、ヘテロジニアスで、スケーラブルで、且つ効率的な集中型マネージャである。このサービスの設計目標としては、以下の点をサポートすることが挙げられる。
・９９．９９９％のアベイラビリティ−障害管理及び適切な冗長リソースと共に用いれば、このアベイラビリティ・マネージャは、最小のダウン時間で、故障を検出し、診断し、分離し、回復させ、「修理」する。
・頑強性−アベイラビリティが９９．９９９％のプラットフォームを提供するには、アベイラビリティ・マネージャ自体はさらに信頼性が高くなければならず、その設計目標は９９．９９９９％であり、これは５０，０００時間のＭＴＢＦに相当する。
・拡張性−ベースクラスは、そのままで使用すれば、ある程度の機能性を提供する。また、このベースクラスは、サブクラスに分類することによって、ＯＭＳを用いたプロセスにおいて又は別個のアプリケーションにおいて実行される拡張機構における動作を拡張することができる。
・拡張可能ポリシー−アベイラビリティ・マネージャは、開発者は補足及び／又はオーバーライドを行うことによってＡＭＳの動作をカスタマイズしてもよい、というポリシーによって統率される。
・統合及びモジュール性−アベイラビリティ管理サービスは、クラスタ管理サービス（Ｃｌｕｓｔｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ）、ＳＮＭＰ、及びその他の技術と統合することによって、１つに統合された管理フレームワークを生成する。ＡＭＳはモジュール方式であるため、サーバ又はクライアント機能を別々に備えてもよい。また、アベイラビリティ管理を必要としないシステムでは、ＡＭＳは除外してもよい。
・コンパクトなサイズ及びクロスプラットフォーム−組込みシステムにおいてメモリのフットプリントを最小に抑えるために、ＡＭＳは、他の拡張機構を含む既存の技術をできるだけ多く再使用する。フットプリントが小さいほど、ＡＭＳを組み込み得るデバイスの母集団は大きくなる。このような様々な母集団にアドレスするために、ＡＭＳは、オペレーティングシステム及びプロセッサ・アーキテクチャの中性点（ｎｅｕｔｒａｌ）として設計される。
・制御及び管理−アベイラビリティ・マネージャは、管理インタフェースを提供することにより、ＡＰＩ、ＳＮＭＰ、及びウェブべースのインタフェースを介して、動作を開始させ制御することができる。このアベイラビリティ・マネージャは、診断機能を有し、リアルタイムにおいても履歴においても、故障の根本的原因及びシステムのアベイラビリティに関連する影響を判定する。
・寿命の長いシステム−アベイラビリティ・マネージャは、機能及び基本命令を提供することによって、リソース、ノード、及びクラスタ全体のアップグレード・ストラテジーを実施する。
・多種多様なデバイス−ＡＭＳは、メモリのフットプリントが最小になるように、且つ、オペレーティングシステム及びプロセッサ・アーキテクチャの中性点となるように設計される。さらに、ＡＭＳは、多数の異なるタイプのリソースを管理することができる。
・幅広い適用性−クロスプラットフォーム及びクロスランゲージ機能により、ＡＭＳは、多数の異なるオペレーティングシステム、ハードウェア・プラットフォーム、プロセッサ・アーキテクチャ、及びプログラミング言語と共に用いることができる。
・高性能−アベイラビリティ・マネージャを用いて実施されるシステムが、５秒間より短い時間でホストシステムプロセッサの切り替えができなければならない、というプラットフォーム全体のアベイラビリティ目標を、ＡＭＳはサポートする。アベイラビリティ・マネージャは、同時に起きたコンフリクト（衝突）しない動作を並行して行うことのできる、高効率で密に結合されたマルチスレッドの装備であることにより、この目標を達成する。
【００３３】
アーキテクチャ
概観
ＡＭＳは、分散型でクライアントとサーバが組になった拡張機構であり、ネットワーク上の異なるノードにおける別々のプロセスを実行する。関与するプロセスは全て、専用ネットワーク上で実行されているものとする。さらに、ＡＭＳは、ネットワーク化されていない単一独立型システムにおいて実行されてもよい。この場合、冗長ハードウェア（例えば、プロセッサ又はディスク）及び冗長ソフトウェア（活動及び待機アプリケーション）は、あってもよいし、なくてもよい。いずれの場合にも、ＳＲＰは、局所的に又は遠隔的に実行されるアプリケーションと、それらのアプリケーションにリンクされたＡＭＳライブラリを介して通信する。
【００３４】
管理対象オブジェクト及びレジストラ
ＡＭＳは、故障又は計画的なダウン時間が生じたリソースを管理する。このタスクを行うために、ＡＭＳアーキテクチャは、２つの重要なアブストラクション（ａｂｓｔｒａｃｔｉｏｎ）、即ち、管理対象オブジェクト及びレジストラをサポートする。
【００３５】
管理対象オブジェクトは、各リソースに対し共通の管理インタフェースを提供する、ソフトウェア・エンティティである。管理対象オブジェクトは、１セットの属性及びメソッドが付与された多種多様な異なるリソースを表しており、これらの属性及びメソッドは、後にそのリソースと対話するのに用いられる。
【００３６】
管理対象オブジェクトは、管理対象オブジェクトクラスから生成される（ｉｎｓｔａｎｔｉａｔｅｄ）。管理対象オブジェクトクラスによって、多数の異なるリソースは、１セットの属性及びメソッドを通して、共通する方式で示すことができるものとされる。メソッドとは、１クラスのオブジェクト全てが提供しなければならない、プログラムに基づいた機能性である。管理対象オブジェクトクラスは、サブクラスに分類することによって、関連するリソースの動作をより適切にモデル化してもよい。
【００３７】
ＡＭＳからは独立しているが、レジストラは、リソースのライフサイクルを管理する。図２に示されているようなレジストラ２０８は、リソースを検出し、それらのリソースを表すような管理対象オブジェクトを生成し、それらの管理対象オブジェクトを削除する。このアーキテクチャは、リソース・マネージャ、アプリケーション、及びトランザクション・マネージャ（ＡＭＳ）を含む、トランザクション処理システムと同様である。
【００３８】
ＡＭＳは、アベイラビリティ・エンジン又はプロセッサ、つまり、いずれのシステムにおいても同じ動作を有する標準コンポーネントと考えてよい。レジストラは、リソース特有のものであるので、システムによって異なる。
【００３９】
アベイラビリティ
システムは、アベイラビリティ・マネージャ自体の故障を含む、あらゆる故障（カタストロフィ（破局）を除く）を切り抜けなければならない。この必要性により、ウォッチドッグを用いるプロセスといくつかの点で似ている、活動アベイラビリティ・マネージャ／待機アベイラビリティ・マネージャ構造がもたらされる。
【００４０】
ダウン時間を最小に抑えるには、障害をできるだけ迅速に検出しなければならない。理想的には、潜在している障害を、実際のリソース故障となる前に検出して取り除くのがよい。潜在している障害をこのように事前に取り除くと、複合故障（活動及び待機故障）で機能停止となる前に故障を修復できることにより、アベイラビリティが上昇する。
【００４１】
ＡＭＳアーキテクチャは、潜在障害検出に対する障害管理の使用をサポートすることによって、可用度の高いシステムを構成することができる。
【００４２】
ハードウェア及びソフトウェアのフェイルオーバーは、複数の活動リソースに対して１つの待機リソース（Ｎ＋１）というような、業界標準トポロジーを通して管理される。さらに、アップグレードやその他の保守アクティビティを目的とした個々のリソースの計画的なダウン時間を、サービス・アベイラビリティが損失されないように管理するには、人間／デバイス・インタフェースが用いられる。
【００４３】
ＡＭＳには、信頼性のあるメッセージ送信システム「アンダー・ザ・フード（ｕｎｄｅｒ ｔｈｅ ｈｏｏｄ）」があるものとする。例えば、メッセージの送信は、もしうまくいかなかった場合、再試行されない。
【００４４】
拡張性
ＡＭＳは、アベイラビリティの高い完全なシステムを構築するのに必要とされる機能性のほとんどを提供する。ＡＭＳは、一般的な機能を供給する一方で、独自性のあるシステム特有の動作を設計するための機能を開発者らに提供する。例えば、開発者らは、独自のシステムモデルを生成しなければならないが、それを生成するのにＡＭＳ・ＡＰＩを用いる。
【００４５】
同様に、ＡＭＳはフェイルオーバー・ポリシー（Ｎ＋１など）を提供するが、これらが十分ではない場合もある。開発者らは、独自のハードウェア制約があるような場合には、これらのポリシーを補足するか又は取り替えなければならない。
【００４６】
一般的には、ＳＲＰアーキテクチャは、コンテントを追加することによって、管理ソリューションが管理ウェブページであっても障害検出器であっても、その動作を拡張又は修正する多くの機会を提供する。標準のアベイラビリティ・ポリシー・モジュールを取り替えることによって、特定のサービス・アベイラビリティ状況に対して適応させたポリシーを提供することができる。
【００４７】
管理性
ＡＭＳアーキテクチャは、シンプル化ネットワーク管理プロトコル（ＳＮＭＰ：Ｓｉｍｐｌｉｆｉｅｄ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）のような既存の管理パラダイムと協働する。これらが統合することによって、既存の管理コンソール及びＳＮＭＰマネージャは、ＡＭＳを組み込んでいるシステムを制御することができる。また、技術者らは、サイトでこのようなシステムにアクセスしなければならないことが多く、局所的にユーザを制御するための機構を必要とする。
【００４８】
これらの必要性を満たすために、ＡＭＳは、それと並列のクラスタシステムに接続する既存の技術を再使用する。
【００４９】
アップグレード
アップグレードをサポートするには、ＡＭＳ機能を用いて、定期的なアップグレードを行っている間システムを管理することによって、サービスを維持することができる。アップグレード機能も、ＡＭＳが基礎にしている技術の多くに拡張する。例えば、データベース・スキーマは、実行時においてアップグレード可能でなければならず、より古いクラスタリング・ソフトウェアが、より新しいソフトウェアと相互作用することによって、古いノードが、オンライン状態となりアップグレードされてもよい。
【００５０】
スケール、フットプリント、及び性能
設計目標は全て、メモリのフットプリント又はＣＰＵを過度に消費することなく達成されなければならない。一般的な組込みシステムでは、管理機能に対して、使用可能メモリの３％〜５％以下、及びＣＰＵサイクルの２％〜３％以下という、使用量の計画が立てられる。ＡＭＳは、何千ものリソースを備えたシステムを管理して、二次エラーを検出し回復を開始させる。
【００５１】
マネージャ及びクライアント
クラスタにわたって分散されているいくつかのコンポーネントが、アベイラビリティ管理サービスを構成する（図１参照）。このコンポーネントとは、以下の３つである。
・アベイラビリティ・マネージャ
・待機アベイラビリティ・マネージャ
・ＡＭＳクライアント
【００５２】
図１に示されているように、アベイラビリティ・マネージャ１００は、マルチスレッドのアベイラビリティ・エンジンであり、並行動作をサポートし、解決機構を提供することによって、同時に行われる動作がコンフリクトを確実に避けるようにする。アベイラビリティ・マネージャは、細粒度（ファイングレイン）のスレッドロック機構を用いることによって、動作の並行処理を高度に行う。効率的なスレッド生成を確実に行うために、アベイラビリティ・マネージャは、必要に応じて、スレッドプールからスレッドを用いる。
【００５３】
また、アベイラビリティ・マネージャがトランザクション機能を提供することによって、動作をタグ付けし、１セットの管理対象オブジェクトにわたって動作を原子的に行ってもよい。これらのトランザクションは、待ち行列を作って、優先順位を付けることができる。トランザクション優先順位は、所定のトランザクションが未決のトランザクション待ち行列のどこに位置するかを決定する一方で、そのトランザクションが必要とする予約を得ようとする。
【００５４】
アベイラビリティ・マネージャは、クラスタ・マネージャと同じクラスタノードにおいて実行され、クラスタ・マネージャと密に統合することによって、クラスタ全体のアベイラビリティ・サービスを提供する。アベイラビリティ・マネージャは、クラスタにおける全てのノードにわたるリソースに対して、アベイラビリティ・サービスを提供する。
【００５５】
前述したように、リソースの管理は、リソースを表す管理対象オブジェクトを介して行われる。ＡＭＳは、レジストラの要請によって管理対象オブジェクトクラスのオブジェクトを生成し、それらをメモリに記憶し、それらをディスクに残すことにより、管理対象オブジェクト・データベースを維持する。
【００５６】
待機アベイラビリティ・マネージャ１１４は、アベイラビリティ・マネージャに対し、そのマネージャが故障した場合、ホットスタンバイを提供する。この待機アベイラビリティ・マネージャは、アベイラビリティ・マネージャから、管理対象オブジェクト状態の全ての変更を受信することによって、最小の遅延又は状態損失でアベイラビリティ・サービスを負うことができる。
【００５７】
活動及び待機アベイラビリティ・マネージャは、クラスタ管理サービス１１２に従属することによって、互いにハートビート（ｈｅａｒｔｂｅａｔ）を確認し、互いの状況に関するタブを保持する。
【００５８】
活動及び待機アベイラビリティ・マネージャのロールは、（構成ファイルを用いて）静的に構成してもよいし、実行時において決定してもよい。待機マネージャが故障した場合には、活動マネージャが新しい待機マネージャを見つける。活動マネージャが故障し、待機マネージャがそれを引き継ぐ（活動マネージャとなる）場合には、システムが新しい待機マネージャを見つけようとする。クライアント・ノードは、マネージャロールの候補とみなしてもよいし、構成ファイル又は動的ポリシーモジュールによって決定されるようなクライアント専用機能を有していてもよい。
【００５９】
図１に示されているようなＡＭＳクライアント１１６は、アプリケーションにリンクされたアベイラビリティ・マネージャ・ライブラリ１１８を介して、アベイラビリティ・マネージャと通信する。このライブラリは、図２に示されているような分散型手続き呼出し（ＤＰＣ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌｓ）２２０を用いることによって、クラスタ・マネージャ・ノードにおけるアベイラビリティ・マネージャに実行要求を送信し、そのアベイラビリティ・マネージャからメソッド呼出しを受信する。クライアントアプリケーションは、アベイラビリティ・マネージャと同じノードにあってもよいし、違うノードにあってもよい。
【００６０】
クラスタ・マネージャの統合
ＡＭＳは、システムの初期化時及び作動中において、クラスタ管理サービスと統合する。初期化の際、クラスタ管理サービスは、クラスタ・マネージャとして及びアベイラビリティ・マネージャとして機能するノードを選択する。そのノード及び全てのクラスタノードを表すために、クラスタ・マネージャは、ノードに組み込まれるものの一部として、管理対象オブジェクトを生成する。待機クラスタ・マネージャを選択するために、サービス・アベイラビリティ・グループが生成される。また、管理ネットワークを表すためにも、管理対象オブジェクトが生成される。
【００６１】
リソース
システムは、多数の様々な「リソース」を有し、これらのリソースは、ハードウェア、ソフトウェア、又は論理的コンポーネントであってもよい。例としては、ファン、ＣＰＵ、ネットワーク、通信カード、アプリケーション、又はデータベースが挙げられる。これらのリソースは、状態を有し、統合方式で管理及び制御される必要がある。アベイラビリティ管理サービスは、フレームワークを提供することによって、様々なセットのリソースを一貫した一様な方式で管理する一方で、各リソースの独自の態様を提供する。
【００６２】
リソースは、いずれのクラスタノードに分散されてもよく、集中型アベイラビリティ・マネージャと遠隔的に対話してもよい。ここで留意すべき点は、ＡＭＳはリソースと直接的に協働するわけではない、という点である。つまり、リソースとの対話は全て、リソースを表す管理対象オブジェクトを通して行われる。アプリケーションのようなリソースは、組込み型の「管理コンポーネント」を有していてもよいし、別個の「管理コンポーネント」を有していてもよい。１つのプロセスは、１つのリソースに対する「管理コンポーネント」として機能してもよいし、複数のリソースに対する「管理コンポーネント」として機能してもよい。この「管理コンポーネント」は、リソースと局所状態にあってもよいし、アベイラビリティ・マネージャと局所状態にあってもよいし、アベイラビリティ・マネージャ及びリソースの両方と遠隔状態にあってもよい。管理対象リソースは、クラスタの内側にあっても外側にあってもよい。
【００６３】
設計記述
システムモデルとは、リソース機能、インタフェース、関連データ構造、及び対話の抽象的な記述である。このアブストラクションは、
・システムモデルの異なる部分を、管理対象オブジェクト、レジストラ、及び従属関係のようなＡＭＳ要素にマッピングする
・これらの要素を生成して管理するコードを書き込む
ことにより、使用可能となる。
【００６４】
この設計についての論議は、ＡＭＳ要素を記述することによって、システムモデルの生成及びソフトウェアにおけるその実現を容易にする。図２参照。
【００６５】
ＡＭＳ要素
アベイラビリティ管理サービスは、以下の要素を含む。
・アベイラビリティ・マネージャ及び待機アベイラビリティ・マネージャ
・ロール
・管理対象オブジェクト
・管理対象オブジェクトクラス
・サービスグループ
・トランザクション
・遠隔動作メソッド
・ハートビート
・レジストラ
・供給オブジェクト
・従属関係
【００６６】
図２において、リソース及び遠隔動作メソッド以外の要素はクラスタ・マネージャ・ノードにあり、リソース及び遠隔動作メソッドはクラスタ全体に分散している。管理対象オブジェクトクラス及び管理対象オブジェクトは常に、クラスタ・マネージャ及びアベイラビリティ・マネージャと同じノードにある。遠隔動作メソッドとの通信は、ネットワークを介するＤＰＣを通して行われる。
【００６７】
アベイラビリティ・マネージャ
アベイラビリティ・マネージャは、ＡＭＳシステムモデルを生成して維持する。アベイラビリティ・マネージャは、管理対象オブジェクトクラスを含むインタフェース・リポジトリ２１２を呼び込むことによって、リソースを表す管理対象オブジェクト・インスタンスを生成する。オブジェクトを、それに対応するクラスを用いずに生成しようとすると、エラーとなる。
【００６８】
アベイラビリティ・マネージャは、これらの管理対象オブジェクトを、システム全体の現在状態（カレントステート）を定義するデータベースに保管する。管理対象オブジェクトに関する呼出しは全て、アベイラビリティ・マネージャによって処理され、アベイラビリティ・マネージャは、トランザクションを用いることによって、システムモデルへの同時アクセスを調整する。呼出しは、局所的であっても遠隔的であってもよい。後者の場合、呼出しは「ワイヤを介して」行われるので、クラスタ管理サービス及び分散型メッセージ送信サービスによって提供される故障検出サービスが用いられる。
【００６９】
アベイラビリティ・マネージャは、そのサービスへのＡＰＩレベルのアクセスを、クラスタ・マネージャにおける本発明のプロセス内部の局所的アクセスと、クラスタにわたる遠隔的アクセスとの両方に提供する。
【００７０】
アベイラビリティ管理サービスは、アプリケーション内にロードされるか又はリンクされる３つの拡張機構として実施される。この拡張アーキテクチャによって、さらなる機能性又はコンテントを、実行時においてＳＲＰ内にロードすることができる。
【００７１】
アベイラビリティ管理サービスの、この３つの拡張機構とは、以下のものである。
・ａｍｓＣｌｉｅｎｔ−アベイラビリティ・マネージャへのクライアント・インタフェース・ＡＰＩを含む。
・ｓｔａｎｄｂｙ−待機アベイラビリティ・マネージャに対する論理を含む。
・ａｍｓＭｇｒ−アベイラビリティ・マネージャに対する論理を含む。
【００７２】
ＡＭＳがこのようなモジュール方式で実施されることによって、ＳＲＰは、必要とする拡張機構のみをロードする。例えば、非クラスタ・マネージャ・ノードは、ａｍｓＣｌｉｅｎｔ拡張機構のみをロードする。
【００７３】
ＡＭＳアプリケーションは、ライブラリに対してリンクし、アベイラビリティ・マネージャ拡張機構をロードするべきである。これにより、アベイラビリティ・マネージャと通信するためのインタフェース論理が提供される。ライブラリが、ＡＭＳクライアントアプリケーション又はリソースの遠隔動作メソッドに、実行時サポートを提供することによって、アベイラビリティ・マネージャが、遠隔動作メソッド及び管理対象オブジェクトメソッドを呼び出すことができるようになるか、又は、クライアントアプリケーションが、使用可能なアベイラビリティ・マネージャ・ＡＰＩを呼び出すことができるようになる。
【００７４】
待機アベイラビリティ・マネージャ
既存の待機アベイラビリティ・マネージャ設計は、以下のような４つの段階に分けることができる。
・待機アベイラビリティ・マネージャを選択する。
・待機アベイラビリティ・マネージャを、活動アベイラビリティ・マネージャに対して追いつかせる（ｇｅｔ ｃｕｒｒｅｎｔ ｗｉｔｈ）（「立ち上がらせる（ｕｐ ｔｏ ｓｐｅｅｄ）」）。
・アベイラビリティ・マネージャのチェックポイントデータを、待機アベイラビリティ・マネージャによって受信して処理する。
・検出された活動アベイラビリティ・マネージャの故障（フェイルオーバー）又は活動アベイラビリティ・マネージャからの方向（切り替え）に基づいて、待機アベイラビリティ・マネージャをフェイルオーバー又は切り替え処理する。
【００７５】
これらの段階はそれぞれ、ノード又はノード上のアベイラビリティ管理サービスの寿命中の異なる時点で生じる。これらの段階については、以下に説明する。
【００７６】
待機アベイラビリティ・マネージャの選択
待機アベイラビリティ・マネージャは常に、待機クラスタ・マネージャと同じ場所に位置する。従って、実際には、待機アベイラビリティ・マネージャの選択は、待機クラスタ・マネージャに対する選択処理によって決定される。待機クラスタ・マネージャの選択は、２セットのデータに基づいて決定される。第１のセットは、クラスタノードのａｐｐ．ｘｍｌファイル内の優先ロール設定値である。この優先ロールは、待機マネージャ又はマネージャでなければならず、可能な待機マネージャと考えられるノードとしては、ブリッジングされていないＩＰノードでなければならない。これらの優先ロールを有する非ブリッジングＩＰノードは、（１つの）待機クラスタ・マネージャを選択するために、ＣＭＳ管理対象オブジェクトを、クラスタ・マネージャ・サービス・アベイラビリティ・グループに設定する。ＡＭＳは、選択されたノードのＣＭＳ管理対象オブジェクトにおける「待機」メソッドを呼び出すことによって、ポリシー選択をその管理対象オブジェクトに伝達する。この「待機」メソッドによって、正しいノードにおけるＣＭＳは、待機クラスタ・マネージャとなるように告げられる。ＣＭＳコードは、待機クラスタ・マネージャとなるのに必要とする動作を行い、次に、同じノードにおける待機アベイラビリティ・マネージャ処理を開始する。
【００７７】
処理全体の主な問題としては、ポリシーがオープンである点と、処理全体がクラスタの形成（アベイラビリティ・マネージャの起動を含む）後に行われる点と、アベイラビリティ・マネージャが常にクラスタ・マネージャと同じ場所に位置する点とがある。
【００７８】
待機アベイラビリティ・マネージャの「立ち上げ」
待機アベイラビリティ・マネージャの選択後、待機アベイラビリティ・マネージャが行わなければならない最初のステップは、活動アベイラビリティ・マネージャ（通常「アベイラビリティ・マネージャ」と呼ばれる）に追いつくようにすることである。この動作の目的は、待機アベイラビリティ・マネージャに、活動アベイラビリティ・マネージャによって維持されているシステムモデルの「現コピー」を所有させることである。これには、アベイラビリティ・マネージャと待機アベイラビリティ・マネージャとの間において、以下のものを伝達することが含まれる。
・システムモデルにおける全てのオブジェクト及びそれらの複製された属性
・順調に行われた全てのトランザクションの起動及び停止
・所定のトランザクションに対してスケジュールされた全てのＡＰＩ後の（ポストＡＰＩ）機能
・記録された全てのリモート・アダプタ
【００７９】
待機アベイラビリティ・マネージャは、このデータを用いることによって、システムモデルのコピーを局所的に構築する。オブジェクトがＡＭＳにおいて生成され、それらの属性値が関連付けられる。局所クラス・リポジトリにアクセスすることによって、管理対象オブジェクトに対して必要とされるクラス分けが行われる。構築されるデータ構造は、アベイラビリティ・マネージャにおいてシステムモデルに対して用いられるデータ構造と全く同じものである。同様のプロセスが、トランザクションに対しても行われる。記録ステップが順調に完了したトランザクションが、待機アベイラビリティ・マネージャにおいて生成される。実際には、予約は行われない。所定のトランザクションに対してスケジュールされたポストＡＰＩ機能は、チェックポインティングされ、待機アベイラビリティ・マネージャにおいても生成される。最後に、待機アベイラビリティ・マネージャは、記録されたリモート・アダプタに関する情報を維持する。このリモート・アダプタは、部分的にのみ生成される。
【００８０】
待機マネージャがアベイラビリティ・マネージャから「立ち上がり」データを受信すると、活動マネージャは、その管理対象オブジェクトを、進行中のチェックポイントデータの生成を必要とするものとしてマーキングする。このプロセスは、「立ち上がり」処理によって、アベイラビリティ・マネージャのシステムモデルにおける全ての処理のロックアウトは必要とされない、ということを意味する。その代わりに、オブジェクト毎の処理は、接触時に各オブジェクトを保護するのに用いられる通常の並行処理制御ロックによって行うことができる。これにより、アベイラビリティ・マネージャにおける破壊が最小に抑えられると共に、依然として待機アベイラビリティ・マネージャのシステムモデルをアベイラビリティ・マネージャのシステムモデルと一致させることができる。この「立ち上がり」処理は、システムモデルの管理対象オブジェクトを、それらの関係に基づいた特定の順序では処理しない。その代わりに、オブジェクトは、ランダムな順序（処理順序）で効果的に処理される。存在しない管理対象オブジェクトを従属物（ｄｅｐｅｎｄｅｎｔ）、フォロア、リーダ、シャットダウン・リーダ、又はＯＲＬ先祖として参照するオブジェクトが訪問された場合、その参照オブジェクトは、「ゾンビー」オブジェクトとして生成される。この「ゾンビー」オブジェクトは、「立ち上がり」処理において実際に訪問されると、実オブジェクトとなる。
【００８１】
この「立ち上がり」処理及び進行中のチェックポイント処理によって、生成される全ての管理対象オブジェクト及びトランザクションは、アベイラビリティ・マネージャにおけるものと同じオブジェクトハンドルを用いて同じオブジェクトとして生成される。このことは、これらのハンドルがＡＭＳ・ＡＰＩを介して見ることのできるアプリケーションであるという理由により必要とされる。待機マネージャが「立ち上がる」前に活動マネージャが故障した場合、待機マネージャは、その供給された記憶装置からそのシステムモデルをロードして、全てのレジストラに初期化を指示する。全てのＡＭＳクライアントアプリケーションは、初期化の指示を受信した後、既知のハンドルを廃棄しなければならない。
【００８２】
チェックポイントデータの受信及び処理
管理対象オブジェクト又はトランザクションが待機アベイラビリティ・マネージャにおいて「立ち上がる（ｂｒｏｕｇｈｔ ｕｐ ｔｏ ｓｐｅｅｄ）」と、アベイラビリティ・マネージャは、進行中のチェックポイントストリームを維持することによって、管理対象オブジェクト又はトランザクションが、アベイラビリティ・マネージャにおけるバージョンと一致した状態を確実に維持するようにする。このチェックポイントストリームには、アベイラビリティ・マネージャにおける全てのオブジェクト変更に関する情報が含まれる。さらに、このチェックポイントストリームには、ＡＰＩとシステムモデルに対して行われるメソッドとに関する情報も含まれる。この情報は、万一故障が生じた際に動作のうちの１つが進行中であった場合に、それらの動作を完全に行うために用いられる。このチェックポイントデータは、待機アベイラビリティ・マネージャはアプリケーションに戻ってきた全ての情報を認識すべきである、というガイドラインを用いて、活動アベイラビリティ・マネージャから待機アベイラビリティ・マネージャへ送信される。このことは、チェックポイントデータは、いずれのアプリケーション開始ＡＰＩを戻す前にも、待機アベイラビリティ・マネージャにフラッシングされる、ということを意味する。このフラッシングは、待機アベイラビリティ・マネージャがアベイラビリティ・マネージャに完全に追いついているということを保証するわけではないが、不一致のウィンドウをできるだけ小さくしようとする。
【００８３】
チェックポイントデータの処理は、前の処理と同様のストラテジーにおいて行われる。この動作は、待機アベイラビリティ・マネージャにより、その独自のデータ構造において、局所的に行われる。待機アベイラビリティ・マネージャは、大きく遅延することなくアベイラビリティ・マネージャとなるのに十分な情報を維持していることが期待される。
【００８４】
フェイルオーバー及び切り替え処理
待機クラスタ・マネージャが、（活動）クラスタ・マネージャを（ハートビート故障によって）故障したものとして検出すると、フェイルオーバー処理が開始される。待機クラスタ・マネージャは、依然として活動的にハートビートに応答しているノードに基づいて、クラスタを「再形成」する。これをサポートするために、待機クラスタ・マネージャは、設定された全てのノード及びオープンＤＭＳルート接続への活動ハートビートを有する。従って、コンテキストのほとんどが設定されるので、そのフェイルオーバー処理は最小である。待機クラスタ・マネージャは、待機アベイラビリティ・マネージャを起動させる。
【００８５】
待機アベイラビリティ・マネージャは、「立ち上がって」、チェックポイントデータをアベイラビリティ・マネージャにおいて生じた動作として受信することが期待される。アベイラビリティ・マネージャの起動を完了させるには、待機アベイラビリティ・マネージャは、以下のようなことをしなければならない。
・クライアントに、フェイルオーバーが進行中であることを通知する。
・あらゆる未決のチェックポイントデータが確実に適用されるようにする。
・チェックポインティングされたシステムモデルを存続させて、その存続システムモデルと局所システムとが一致することを保証する。
・既存の予約を有した全てのトランザクションに対して、予約を設定する。
・全てのＡＭＳクライアントアプリケーションへのＤＰＣプラミングを再設定する。
・全てのリモート・アダプタへのＤＰＣプラミングを再設定する。
・クライアントに、フェイルオーバーが完了したことを通知する。−これには、新しい待機アベイラビリティ・マネージャが活動していることを全てのクライアントに知らせるメッセージの公布が含まれる。
・チェックポインティングに用いられたあらゆるデータ構造を除去する。
【００８６】
ＡＭＳクライアントアプリケーション及び拡張機構も、何らかの動作を行って、フェイルオーバーに対し適切に反応しなければならない。この動作は、アプリケーション・ＡＰＩ・スタブにおいて処理されるので、顧客コードの管理下にはない。アプリケーション・ＡＰＩ・スタブにおけるコードの効果は、以下のとおりである。
・ネットワーク故障から生じるあらゆるタイムアウトＡＰＩ要求を、再試行に変換する。スタブコードは、待機マネージャの存在を検出して、その待機マネージャが安定した局所システムモデルを有する場合には、その新しいアベイラビリティ・マネージャに対して要求を再試行する。このことは、起動している待機アベイラビリティ・マネージャからの通知によって識別される。
・待機アベイラビリティ・マネージャの起動通知を、要求の再送信となるように処理する。
【００８７】
拡張ＡＰＩスタブにおけるコードの効果は、待機アベイラビリティ・マネージャがその起動及び局所システムモデルの安定化を完了させる前に生じる、あらゆるＡＰＩ要求をロックすることである。局所システムモデルの安定化通知に基づいて、ブロックされたＡＰＩが進行される。
【００８８】
ロール
アベイラビリティ・マネージャは、サービスグループにおける管理対象オブジェクトに対して動作ロールの割当てを行うと共に、管理対象オブジェクトを駆動することによって、必要に応じて、システム状態及び状況の変化やロールの再割当てに対し応答する。管理対象オブジェクト故障が生じると、アベイラビリティ・マネージャは、ダウン時間又はサービスの中断なしに、待機リソースを迅速に作動させる。
【００８９】
アベイラビリティ・マネージャによって割当てが行われると、管理対象オブジェクトは、以下のロールのうちの１つを担う。
・活動
・待機
・割当てなし
【００９０】
適切なＡＰＩを呼び出すことによって、そのリソースを表す管理対象オブジェクトが修正され、これにより、そのリソースのロールが変更される。管理対象オブジェクトは、リソースへの伝達及びリソースの制御という責務を負うことによって、所望の動作を確実にする。ロールの変更は、ロールの割当てと呼ばれ、さらに以下に論じられる。
【００９１】
また、ロールは、管理対象オブジェクトのフォロアであるオブジェクトに基づいて割り当てることもできる。この場合、フォロアのロールは、それが無効でない限り、そのリーダのロールの変更を追跡する。フォロアでもなくサービスグループのメンバでもないオブジェクトには、それが有効である場合、活動ロールが付与される。無効である場合には、ロールは割当てなしに変更される。
【００９２】
管理対象オブジェクト
管理対象オブジェクトとは、ＡＭＳ内におけるリソースの管理ソフトウェア表現である。管理の観点からすると、管理対象オブジェクトはリソースである。
【００９３】
必要とされるクラスの管理対象オブジェクト・インスタンスは、管理下における各リソースに対して生成される。リソースの状態及び構成は、管理対象オブジェクト属性の読取り及び書込みにより調査及び制御してもよく、リソースは、リソース・メソッドを呼び出すことにより操作してもよい。
【００９４】
管理対象オブジェクトとは、ＡＭＳのオブジェクト・エンジンによって供給された、オブジェクトクラス７００のサブクラスである。管理対象オブジェクトは、以下のセマンティクス（意味論）を提供する。
・ＩＳＯ　Ｘ．７３１をＡＭＳがサポートすることによって表される状態動作の具体化
・オブジェクトを活動、待機、又は割当てなしと表すためのロール・セマンティクスの具体化
・管理対象オブジェクト間の従属関係の具体化
・オブジェクトと指定サービスグループとの間のサービスグループ帰属関係の具体化
・管理対象オブジェクトに別の管理対象オブジェクトのロール割当てを追跡させるためのリーダ追従セマンティクスの具体化
・管理対象オブジェクトの調子を観察するためのハートビート機構の具体化
・全ての状態エンジン関連動作に対するトランザクション予約の順守の具体化
【００９５】
人間が読取り可能なオブジェクト・リソース・ロケータ（ＯＲＬ）は、独自に管理対象オブジェクトを識別する。例えば、次のようなＯＲＬがある。
／ｍｙＣｌｕｓｔｅｒＮａｍｅ／ｓｅｒｖｅｒ３／ｃａｒｒｉｅｒＣａｒｄ０／Ｐｍｃ０／ａｐｐ０
【００９６】
このＯＲＬは、サーバ３におけるキャリヤカードの一部であるＰＭＣにおいて実行されるアプリケーションを表す、管理対象オブジェクトを指定している。ＵＲＬと同様、ＯＲＬは同じようなスラッシュで区切られたフォーマットに従っており、このフォーマットにおいて、各セグメントは管理対象オブジェクトに対応している。スペース、「＋」、又は「＆」という文字は、ＯＲＬでは許容されていない。
【００９７】
ＯＲＬは、エイリアスを用いることによって、共通オブジェクトを都合よく参照することができる。アベイラビリティ・マネージャ・ＡＰＩは、ＯＲＬエイリアスを、それらの対応する全定義に自動的に拡張する。この被定義エイリアスとしては、以下のようなものが挙げられる。
・〜ｌｏｃａｌｈｏｓｔ　局所ノードに対するＯＲＬを表す。
・〜ｃｌｕｓｔｅｒ　現クラスタに対するＯＲＬを表す。
【００９８】
管理対象オブジェクトクラス
管理対象オブジェクトクラス７１０とは、管理対象オブジェクトが生成されるテンプレートである。管理対象オブジェクトクラスは、システムにおけるリソース状態及び動作を効果的にモデル化するのに必要なサポートを提供する。管理対象オブジェクトクラスは、１セットの属性を定義することによって、リソースの状態及びアクセス・メソッドをモデル化して、リソースを制御する。管理対象オブジェクトクラスは、さらに、アベイラビリティ管理に直接的には関連しないその他のコンテントを提供してもよい。例えば、このコンテントとしては、管理ユーザインタフェースに組み込むためのウェブページや、障害管理のための障害検出器が挙げられる。
【００９９】
管理対象オブジェクトクラスは、インタフェース・リポジトリにおいて、開発者が、属性及びメソッドＸＭＬ記述ファイルの位置や、クラスを含む本発明の拡張機構の名称というような、クラスの完全な詳細を特定するｓｒＡｍｓＣｒｅａｔｅＣｌａｓｓ・ＡＰＩを用いることによって定義される。或いは、このクラスは、ｃｌａｓｓｅｓ．ｘｍｌファイルを用いて静的に構成されてもよい。
【０１００】
管理対象オブジェクトクラス拡張機構は全て、活動若しくは待機アベイラビリティ・マネージャを含む又は含み得るクラスタにおける、全てのＳＲＰによってロードされる必要がある。管理対象オブジェクトクラスを含むこの拡張機構をロードすることによって、クラスは、レジストラがそれを必要とするときには、確実にインスタンス生成に使用可能となる。
【０１０１】
管理対象オブジェクトクラスは、システム拡張機構としてパッケージ化されて受け渡しされる。システム拡張機構は、１つの拡張機構において、１つのクラスを供給してもよいし、多数のクラスを供給してもよい。実行時において、必要に応じて拡張機構を動的にロードすることにより、クラスがロードされ、管理対象オブジェクト・インスタンスが生成される。これにより、「プラグ・アンド・プレイ（ｐｌｕｇ−ａｎｄ−ｐｌａｙ）」スタイルの機構が可能となり、この機構では、クラスは、関連リソースがそれらの存在を必要とする場合のみロードされる。
【０１０２】
この論議では、管理対象オブジェクトクラスが親クラスに追加する属性及びメソッドのような、追加動作に焦点を当てている。その親クラスと同様に、管理対象オブジェクトクラスも、クラスメソッド又は属性を有していない。従って、この論議は、クラス自体から生成された各オブジェクトに当てはまる。
【０１０３】
管理対象オブジェクトクラスは、以下のような要素から構成される。
・スーパークラス
・属性
・メソッド
・任意の管理ユーザインタフェース
・任意の拡張障害管理
【０１０４】
スーパークラス
クラスとは、システムのリソースのオブジェクト指向アブストラクションである。クラスは、他のクラス（それらのスーパークラス）から機能を継承することができる。このクラス階層構造は、以下の点により特徴付けることができる。
・単一継承
・サブクラスがベースメソッドをオーバーライドすることによってクラス動作を取り替え又は増加させ得る多相性
【０１０５】
例えば、イーサネット（Ｒ）カードに対する既存クラスからサブクラスを生成することや、新しい属性及びメソッドを追加することにより特定タイプのイーサネット（Ｒ）カードに対するクラスを生成して、その追加特性を制御することが可能である。
【０１０６】
クラスがｓｒＡｍｓＣｒｅａｔｅＣｌａｓｓ・ＡＰＩを介して生成されると、そのクラスに対するスーパークラスが特定される。スーパークラスの属性及びメソッドには、ｓｒＡｍｓＧｅｔＡｔｔｒｉｂｕｔｅ・ＡＰＩ、ｓｒＡｍｓＳｅｔＡｔｔｒｉｂｕｔｅｓ・ＡＰＩ、及び「ＳＲ＿ＳＵＰＥＲ」マクロをそれぞれ用いてアクセスしてもよい。
【０１０７】
ＡＭＳスーパークラスには、以下のようなものがある。
・ｍａｎａｇｅｄＯｂｊｅｃｔ７１０
・ｒｅｍｏｔｅＯｂｊｅｃｔ７４０
・ｄｉｒｅｃｔｏｒｙ７３０
・ｓｅｒｖｉｃｅＧｒｏｕｐ７２０
・ｕｓｅｒ ｄｅｆｉｎｅｄ ｏｂｊｅｃｔ７５０
【０１０８】
ベースクラスであるｍａｎａｇｅｄＯｂｊｅｃｔは、全ての管理対象オブジェクトクラスが継承しなければならない基礎属性及びメソッドを供給する。ｒｅｍｏｔｅＯｂｊｅｃｔ７４０、ｄｉｒｅｃｔｏｒｙ７３０、及びｓｅｒｖｉｃｅＧｒｏｕｐ７２０のクラスは、それらのスーパークラスとして、ｍａｎａｇｅｄＯｂｊｅｃｔ７１０を有する。
【０１０９】
属性
属性とは、オブジェクトの現在状態を定義するデータ値のセットである。クラスは、属性ＸＭＬ定義ファイルによって、デフォルト値を有する１セットの属性を定義する。そのクラスのメンバは、これらの属性と、あらゆる特定スーパークラスの全ての属性とを所有する。属性はｓｒｋＶａｌｕｅ＿ｔタイプであり、このタイプには、ストリング、整数、倍長整数（６４ビット）、文字（８ビット）、又はブロブ（バイナリ・ラージ・オブジェクト）が含まれ得る。ＡＭＳは、値がブロブである属性に対して異質なサポートを提供しない、ということには注意されたい。
【０１１０】
属性は、「観察」、「存続」、「読取り専用」、「複製」、又は「保護」のうちの１つ以上として示すことができる。観察された属性は、それらを操作するために、ゲット・アンド・セット（ｇｅｔ ａｎｄ ｓｅｔ：取得及び設定）・メソッドを呼び出す。存続属性は、記憶装置へ保管され、それらの値をシステムの再ブートを通じて保存する。読取り専用属性は、それらの値を修正しなくてもよい。複製された属性は、それらの値を待機アベイラビリティ・マネージャに対して自動的にチェックポインティングする。保護された属性は、それらの値をシステム・マネージャによってのみ修正してもよい。本発明の２．０は、このような保護表示を強制しない。
【０１１１】
新しい属性は、サブクラスによって定義されてもよい。サブクラスが前の属性と同じ名称の属性を定義した場合には、後の属性が元の属性をシャドーイングする。シャドーイングとは、前の属性が、デフォルトの視点からは隠れているが、その属性にアクセスするときに定義クラス名を明示的に指名することによって、依然としてアクセス可能である、ということを意味する。このことは、サブクラスが同じ名称の属性を定義してもよいかどうかに関係なく、常にその属性にアクセスすることができる、ということをクラスが保証するのに有用である。また、システム・マネージャは、ＡＰＩを提供することによって、オブジェクトの属性を取得し、設定し、列挙する。
【０１１２】
属性値を読み取るには、ｓｒＡｍｓＧｅｔＡｔｔｒｉｂｕｔｅ・ＡＰＩが用いられる。この呼出しは、属性を定義するクラスの名称（又はシステムにクラスを決定させるＮＵＬＬ（ヌル））を用いることによって、関連属性を特定する。同様に、属性の値を設定するためのＡＰＩもある。属性は、実行時において静的にロードすることもできる（供給オブジェクト）。
【０１１３】
下線で始まる属性名は、本発明によって使用するために予約される。
【０１１４】
メソッド
メソッドとは、必要に応じてオブジェクトを通じて呼び出すことによって、リソースにアクセスしてそれを制御できるようにする機能である。クラスメソッドは、在来のＣ言語手続きとして表現され、クラスに対するメソッドＸＭＬ定義ファイルに記述される。（注：このクラスとＸＭＬ定義ファイルとは、どうしても一致しなければならないというものではない。ＸＭＬ定義ファイルは、インタフェース列挙ＡＰＩをサポートするためだけに用いられる。）本発明は、遠隔動作メソッドスタブを生成するインタフェース記述言語（ＩＤＬ：Ｉｎｔｅｒｆａｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）コンパイラも提供する。
【０１１５】
メソッドは、具体化されたベースメソッドがないアブストラクト（ａｂｓｔｒａｃｔ）として定義されてもよい。サブクラスは、具体化されたメソッドを供給しなければならない。
【０１１６】
サブクラスが、スーパークラスにおいて定義された名称と同じ名称のメソッドを定義する場合には、新しいメソッドが、スーパークラスメソッドをオーバーライドする。前の定義をシャドーイングする属性とは異なり、メソッドは、前のメソッド定義をオーバーライドすることによって、多相性を実現する。このことは、ベースクラスがメソッドを呼び出すと、元のベースメソッドではなく、オーバーライドされたメソッド・バージョンが呼び出される、ということを意味する。これにより、サブクラスは、ベースクラスによって提供された機能性を増加又は取り替えできるので、このことは非常に有用である。
【０１１７】
メソッドは、ＳＲ＿ＭＥＴＨＯＤマクロを介してＣインタフェースを呼び出すことにより、静的に呼び出すことができる。ＡＰＩが定義されることによって、メソッドが列挙されると共に、所定のオブジェクト・インスタンスに対するメソッドの詳細が読み出される。メソッドは、整数戻りコードを定義するだけでもよい。しかし、任意タイプのデータ項目を戻すには、いずれのメソッド・パラメータを用いてもよい。
【０１１８】
メソッドの動作には、「局所動作」、「遠隔動作」、及びこれらの両方を組み合わせた動作という、３つの異なる方式がある。局所動作とは、メソッドが同一プロセスにおいて呼び出されて実行される、ということを意味する。遠隔動作メソッドとは、（メソッドが呼び出された場所に関係なく、）メソッド自体が、オブジェクトが存在するプロセスとは異なるプロセスにおいて実行されるメソッドである。これらの両方を組み合わせた動作は、「遠隔動作」メソッド論理が呼び出される前又は呼び出された後に、何らかの処理が局所的に生じた場合、行うことができる。
【０１１９】
リソースを制御するための論理は、管理対象オブジェクトクラスにおいてアベイラビリティ・マネージャと共に中央に存在してもよいし、遠隔動作メソッド（遠隔動作メソッドに関する以下の論議を参照）において遠隔的に存在してもよい。制御論理を配置する場所に関する設計決定は、その論理がアベイラビリティ・マネージャに近接すべきか、リソースに近接すべきか、ということによって影響されるべきである。
【０１２０】
下線で始まるメソッドは、本発明のために予約される。
【０１２１】
ＡＭＳ状態エンジンによって用いられるメソッドは、ネットワークエラーによる故障の際のエンジン応答性、又はその他の例外的な遅延応答に影響を与え得る。この主な例としては、リモート・アダプタを損失した遠隔動作メソッドがある。ＡＭＳは、ネットワークエラーが検出されると、管理対象オブジェクトの遠隔動作メソッドを無効にすることによって、これに対処する。それ以降に行われるリモート・アダプタにおける遠隔動作メソッドへの呼出しは、このメソッドが再度有効にされるまで、ワイヤ上を通過しない。遠隔動作メソッドの有効化及び無効化は、ｓｒＡｍｓＥｎａｂｌｅＲｅｍｏｔｅＭｅｔｈｏｄｓ・ＡＰＩ及びｓｒＡｍｓＤｉｓａｂｌｅＲｅｍｏｔｅＭｅｔｈｏｄｓ・ＡＰＩを介して、明示的に行うことができる。
【０１２２】
管理ユーザインタフェース
管理対象オブジェクトクラスは、ウェブべースのユーザインタフェースを提供することにより、コンソールに接続して、管理対象オブジェクトを管理、観察、及び制御してもよい。これら３つの管理対象オブジェクトクラス定義のフォーマットが、管理ユーザインタフェースに対するホームページのＵＲＬに提供されるべきである。
【０１２３】
拡張障害管理
本発明は、複雑な障害及び状況を検出して診断することのできる障害検出器の階層構造を生成可能にするような、包括的な障害管理サービスを有する。この機能をアベイラビリティ・マネージャと統合することによって、統合しなければ通知されなかったであろう障害を、管理対象オブジェクトに知らせることができる。
【０１２４】
サービスグループ
アベイラビリティ・マネージャは、冗長リソースに対する管理対象オブジェクトを、サービスグループと呼ばれる論理サービスに分類する。サービスグループとは、ＩＳＯ用語の「保護グループ」に相当する。アベイラビリティ・マネージャは、冗長ポリシーを管理し、管理対象オブジェクトの動作状態及び冗長グループポリシーに従って、動作ロールを各管理対象オブジェクトに割り当てる。
【０１２５】
サービスグループが生成され、その管理対象オブジェクトが現出すると、これらの管理対象オブジェクトは、そのｓｅｒｖｉｃｅＧｒｏｕｐ属性を設定することにより、関連付けることができる。他の管理対象オブジェクトと同様に、サービスグループは、供給することによって生成されてもよいし、実行時においてレジストラによって生成されてもよい。
【０１２６】
サービスグループの一例としては、図５に示されているようなシャーシへの電力がある。複数の電源５５０及び５６０が協働することによって、確実に停電にならないようにする。これらの電源は、交換可能である、つまり、同一サービスを提供しているので、管理目的で一緒に分類される。他のリソースは使用可能である電力に依存しているが、動作中である個々の電源のいずれにも従属して「いない」。従って、他の管理対象オブジェクトが従属しているのは、複数の電源が一緒に提供しているサービス（サービスグループ）である。図５には、電力５４０とカード５３０とカードキャリヤ５３０との間の従属関係も示されている。通信ソフトウェア５１０、カードキャリヤ５２０、並びに、電力５４０及び電源５５０を含むグループ帰属関係も示されている。
【０１２７】
ロール割当て
アベイラビリティ・マネージャは、サービスグループポリシーに従って、ロールを管理対象オブジェクトに割り当てる。各サービスグループは、独自のポリシーを有していてもよい。ＡＭＳは、ユーザが取り替え可能な１セットのポリシーを提供する。ロールを割り当てるには、ＡＭＳが、管理対象オブジェクトにおけるメソッドを呼び出してロールを設定する。管理対象オブジェクトは、リソースと通信することによって、動作（例えば、リソースのオン又はオフ）を実際に行わなければならない。
【０１２８】
特定のリソースは、システムにおいて、「活動」、「待機」、又は「割当てなし」ロールを担う。リソースが活動又は待機となるには、そのリソースが「有効」動作状態でなければならない。活動とは、リソースがサービス提供に活動的に従事していることを意味し、待機とは、リソースが稼動せずに引継ぎを待っていることを意味する。割当てなしは、活動でも待機でもないリソースに適用される。「有効」又は「無効」オブジェクトは、割当てなしロールを有することができる。
【０１２９】
活動オブジェクトが故障すると、アベイラビリティ・マネージャは、待機オブジェクトが活動ロールを引き継ぐように促す。アベイラビリティ・マネージャは、Ｎ＋１、Ｎ＋Ｍ、及び手動というようないくつかのサービスポリシーを提供する。サービスグループに、サービスグループポリシーが必要とする数より多くのオブジェクトがある場合、それらのオブジェクトには、割当てなしロールが適用される。ポリシーがＮ＋Ｍである場合、これらの割当てなしオブジェクトは、不十分なリソースがあるときに活動又は待機ロールとされるので、より高い保護レベルを提供する。活動ロールの管理対象オブジェクトの数が、ユーザの定義した閾値を下回ると、サービスグループは故障と表される。
【０１３０】
管理対象オブジェクトにｐｒｅｆｅｒｒｅｄＲｏｌｅ属性を設定すると、そのロール割当て（活動が選択される場合のみ）に影響が及ぼされる。アベイラビリティ・マネージャは、ロール割当てを行う際、全ての優先ロールを満たそうとする。特定のリソースがそのロールに最も適している場合には、優先活動オブジェクトを指定するのが有用であることが多い。優先ロールを設定すれば、標準ポリシーが現在の満たされた割当てを変更することはない。
【０１３１】
管理対象オブジェクトは、そのロールを別の管理対象オブジェクトのロールに追従させることによって、そのロール割当てを変更してもよい。この変更は、例えばフィールド交換可能ユニットの場合のような、１セットのオブジェクトが常に同じロールを有していなければならない場合に有用である。この変更を行うために、オブジェクトは、その「リーダ」属性のロールを定義する管理対象オブジェクトのＯＲＬを特定する。
【０１３２】
アベイラビリティ・マネージャは、ラウンドロビン冗長平衡化ポリシーを用いることによって、待機管理対象オブジェクトが活動管理対象オブジェクトにわたって平均的に分散されるように、待機割当てを平衡化する。一度この平衡化が行われれば、故障が生じない限り、一度割り当てられた待機オブジェクトに対して、再度割付けが行われることはない。所定の１つの活動オブジェクトは、たった１つの待機オブジェクトを有する。１つの待機オブジェクトは、０以上の活動オブジェクトをサービスしてもよい。活動オブジェクトと待機オブジェクトとの間で異なるマッチング動作が必要とされる場合、その動作はカスタムポリシーを通して提供される。
【０１３３】
管理
サービスグループは、管理対象オブジェクトと同じように、ＯＲＬ階層構造においてモデル化される。各サービスグループに対して１つの管理対象オブジェクトが生成され、これらの管理対象オブジェクトは、管理対象オブジェクトが他の管理対象オブジェクトに従属するのと同じように、これらのサービスグループに従属する。１つの管理対象オブジェクトは、一度に１つのサービスグループにのみ従属してもよい。管理対象オブジェクトは、適切な属性を設定することにより、実行時において、サービスグループに加入してもよいし、サービスグループから離脱してもよい。
【０１３４】
サービスグループは、そのサービスポリシー（活動オブジェクトの閾値数）が満たされている限り、「有効」である。例えば、Ｎ＋１（閾値０）のサービスグループ（Ｎ＝２）は、サービスグループにおいて２つの管理対象オブジェクトが故障した場合にのみ、「無効」となる。
【０１３５】
サービスグループは、そのメンバに対して必要とされるクラスタイプを特定する。多相性により、異なるクラスの、サブクラスに分類された管理対象オブジェクトが、サービスグループに加入することができる。例えば、ネットワーク・サービスグループを定義することによって、クラスタに冗長ネットワークサービスを提供することができる。このサービスグループによって、メンバがＥｔｈｅｒｎｅｔ（Ｒ）クラスでなければならない、ということを特定することができる。Ｅｔｈｅｒｎｅｔ（Ｒ）がｍｙＥｔｈｅｒｎｅｔ（Ｒ）のベースクラスであれば、Ｅｔｈｅｒｎｅｔ（Ｒ）クラスである一般的なイーサネット（Ｒ）カードと、ｍｙＥｔｈｅｒｎｅｔ（Ｒ）クラスである製造業者のイーサネット（Ｒ）カードとは、いずれも同じサービスグループのメンバになり得る。
【０１３６】
図３．サービスグループ
サービスグループが図３に表されている。Ｃｏｍｍｓサービスグループは、Ｃａｒｒｉｅｒ１及びＣａｒｒｉｅｒ２という２つのメンバを有しており、この冗長モデルは、Ｎ＋１である。このＣｏｍｍｓサービスグループは、これらのＣａｒｒｉｅｒ管理対象オブジェクトが無効にされた場合、無効にされる。
【０１３７】
従属関係の破壊又はサービスグループに対するその他の変更は、そのサービスグループ内においてサービスを提供しているメンバには影響を与えない。しかし、そのサービスグループの動作状態は、サービスグループのアベイラビリティ・パラメータを満たすのに十分なサービスをメンバが提供しているかどうかに基づいて算出される。
【０１３８】
ロール割当て通知
管理対象オブジェクトに対するロールを変更するために、アベイラビリティ・マネージャは、管理対象オブジェクトにおける様々なメソッドを呼び出す。これらのメソッドは、ｍａｎａｇｅｄＯｂｊｅｃｔベースクラスの一部として定義される。これらのメソッドには、以下のようなものがある。
・ａｃｔｉｖａｔｅ（起動）−リソースがサービスの提供を開始するように命令。
・ｓｔａｎｄｂｙ（待機）−リソースが１つ以上の活動リソースに対する待機リソースとして機能するように命令。
・ｕｎａｓｓｉｇｎ（割当てなし）−リソースをサービスから除去。つまり、活動中でもなければ、活動リソースを引き継ぐ準備中でもない。
・ｓｗｉｔｃｈｏｖｅｒ（切り替え）−待機ロールから活動ロールへの移行。
【０１３９】
これらのメソッドは、同期的に実行される。ＡＭＳが呼出しを行うと生じる実際の動作は、メソッドの実施に従属している。リソースの中には、動作が全く実施されなくてもよいリソースもある。
【０１４０】
ＡＭＳは、活動オブジェクト及び待機オブジェクトに対して、ロールを変更している特定オブジェクトを通知するだけでなく、活動オブジェクトと待機オブジェクトとの関連も通知する。これは、以下のようなメソッドを介して行われる。
・ｒｅｍｏｖｅＡｃｔｉｖｅ（活動除去）−待機オブジェクトを訪問して、活動オブジェクトがその待機オブジェクトから分離されたことを通知。
・ｒｅｍｏｖｅＳｔａｎｄｂｙ（待機除去）−活動オブジェクトを訪問して、待機オブジェクトがその活動オブジェクトから分離されたことを通知。
・ａｄｄＡｃｔｉｖｅ（活動追加）−待機オブジェクトを訪問して、活動オブジェクトがその待機オブジェクトと関連付けられたことを通知。
・ａｄｄＳｔａｎｄｂｙ（待機追加）−活動オブジェクトを訪問して、待機オブジェクトがその活動オブジェクトと関連付けられたことを通知。
・ｕｐｄａｔｅＡｃｔｉｖｅＳｔａｎｄｂｙ（活動／待機更新）−全てのフォロアオブジェクトを訪問し、それらのリーダオブジェクトに対して活動又は待機の結合が変更されたことを通知。
【０１４１】
構成可能なロール割当てポリシー
アベイラビリティ・マネージャが、ロール割当てに対しいくつかのポリシーを提供するが、開発者らは、独自のロール割当てポリシーを提供してもよい。このことは、以下のような場合に必要とされることがある。
・ロール割当ての際、管理対象オブジェクトが、他の管理対象オブジェクトに組み合わされる又は割り当てられる必要がある場合。
・より複雑なロール割当てポリシーが必要とされる場合。
・優先ロール属性だけでは満たすことのできない非均一ロール割当て条件を有するリソースがある場合。
【０１４２】
ロール割当て機能は、サービスグループ・オブジェクトのｐｏｌｉｃｙメソッドによって提供される。各サービスグループは、このポリシーを提供するこの機能の名称である属性を有する。
【０１４３】
ロール割当てに対するカスタムポリシーは、このメソッドを所望のｐｏｌｉｃｙメソッドでオーバーライドすることによって提供される。このｐｏｌｉｃｙメソッドは、メンバ・オブジェクトに対するｒｏｌｅ属性を修正し、次に、関連するロール割当てメソッド（例えば、ａｃｔｉｖａｔｅ）を呼び出すことによりメンバ・オブジェクトにロールを通知することによって、ロール割当てを行う。このｒｏｌｅ属性は、保護されるため、ｓｒＡｍｓＳｅｔＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅを呼び出すことによって修正することはできない。ｐｏｌｉｃｙメソッドは、ｓｒＡｍｓＡｓｓｉｇｎＯｂｊｅｃｔＲｏｌｅを呼び出すことによって、管理対象オブジェクトにロールを割り当て、関連するオブジェクト・メソッドを呼び出すことによりそのオブジェクトにロールを通知するべきである。
【０１４４】
トランザクション
ｓｒＡｍｓＳｔａｒｔＴｒｎ・ＡＰＩを呼び出すことによってトランザクションが開始されると、管理対象オブジェクト及びサービスグループのリストが、アクセスを排他的にするために予約される。このような予約によって、これらのオブジェクトに従属する全ての管理対象オブジェクトは「使用中（ｂｕｓｙ）」と表される。それ以降の、既に使用中と表された管理対象オブジェクトを特定するトランザクションは、最初のトランザクションとコンフリクトするので、継続することはできない。
【０１４５】
トランザクションによって予約される管理対象オブジェクトとしては、トランザクションに対してリストされたオブジェクト（Ｌ）、及びリストされた各オブジェクトに対する以下のようなオブジェクトがある。
・リストされた各オブジェクトの従属物、及びこれらの従属物に従属する全ての従属物（Ｄ）
・リストされたオブジェクト（Ｌ）又は従属オブジェクト（Ｄ）を含むサービスグループ（Ｓ）
・上記（Ｓ）に含まれる全てのサービスグループのグループメンバ（Ｍ）
・上記（Ｍ）に含まれる全てのグループメンバ（Ｍ）のフォロア
・上記（Ｌ）又は（Ｄ）における全てのオブジェクトのリーダ
・上記（Ｌ）又は（Ｄ）における全てのオブジェクトのフォロア
注：サービスグループが、リストされたオブジェクトである場合、サービスグループを予約しても、そのメンバは予約されない。
【０１４６】
アベイラビリティ・マネージャは、この同期化機構を用いることによって、複数の同時トランザクションの並行処理を制御する。トランザクションが、既に「予約」されたオブジェクトを特定すると、ｓｒＡｍｓＳｔａｒｔＴｒｎは、ＡＰＩ呼出しの際に供給されるフラグに依って、エラーコードを戻すか、或いはトランザクション待ち行列において待機する。待機モードが特定されると、トランザクションは、必要な予約を得ることができるまで、又はクライアントアプリケーションが切断されるまで、待ち行列を作る。
【０１４７】
ｓｒＡｍｓＳｔａｒｔＴｒｎ・ＡＰＩの呼出し元は、トランザクション及び呼出し元自体を独自に識別し、例えば、記述、ＩＤ、及びリクエスタ名であるような、いくつかのパラメータを提供する。ＡＰＩは、他のＡＰＩによってトランザクションを操作するのに用いることができるトランザクション・ハンドルを戻す。全ての関連するアベイラビリティ・マネージャ・ＡＰＩが、パラメータとしてこのトランザクション・ハンドルを渡すことによって、リクエスタ及びその他のトランザクション詳細の識別にアクセスすることができる。
【０１４８】
トランザクションは、ＡＭＳ状態エンジンに影響を与えるあらゆる操作を行うことが必要とされる。これには、以下のようなものが含まれる。
・オブジェクト状態に直接的に影響を与える動作（例えば、ロック又はテスト動作）。
・オブジェクトを生成又は削除する動作。
・関係（例えば、従属関係、リーダ、フォロア、又はサービスグループ帰属関係）を変更する動作。
・サービスグループのアベイラビリティ特性を変更する動作。
【０１４９】
トランザクションは、以下のように開始されなければならない。
・オブジェクト状態に直接的に影響を与える動作は、その影響されたトップレベルのオブジェクトを予約しなければならない。結果として、正しいオブジェクトが予約される。
・オブジェクトを生成又は削除する動作は、親オブジェクトを予約しなければならない。
・関係（例えば、従属関係、リーダ、フォロア、又はサービスグループ帰属関係）を変更する動作は、変更されているオブジェクト及び参照オブジェクトを予約しなければならない。
・サービスグループのアベイラビリティ特性を変更する動作は、サービスグループ及びそのメンバを予約しなければならない（サービスグループをロックしても、そのメンバは予約されない）。
【０１５０】
トランザクション及びＡＭＳに関して最後に一点あげると、ＡＭＳは、トランザクションを自動的には生成しない。デフォルト例外ハンドラがいくつかは備えられているが、この設計の基本的なアーキテクチャでは、アベイラビリティ・マネージャは、トランザクション又は動作を開始させない。従って、例えば、ハートビート故障においては、顧客が提供したハンドラ又はこのデフォルトハンドラが、オブジェクトを実際に故障させた原因である。
【０１５１】
遠隔動作メソッド
アベイラビリティ・マネージャは、リソースを、それらの対応する管理対象オブジェクトを通して管理する。メソッドは、完全に局所的に作動することもできるし、局所的及び遠隔的に作動することもできるし、単に遠隔的に作動することもできる。メソッドの遠隔的に作動する部分を、遠隔動作メソッドと呼ぶ。
【０１５２】
遠隔動作メソッドは、アベイラビリティ・マネージャの外部で、且つ、一般的にはリソースに近接したところで実行される。遠隔動作メソッドの論理選択の１つとしては、リソースをホストするクラスタノードにおける選択がある。ハードウェア・リソースに関しては、この遠隔動作メソッドは、一般的には、ハードウェアと通信するアプリケーションに備わる。アプリケーション・リソースに関しては、この遠隔動作メソッドは、アプリケーション自体に備わることが多い。ＡＭＳは、単一プロセスからの多数のリソースを管理するプロキシ・アプリケーションを含む、これらの及びその他のアーキテクチャをサポートする。
【０１５３】
ＡＭＳ・ＡＰＩの観点からすると、遠隔動作メソッドのコンテナは、図１のリモート・アダプタ１０８である。このリモート・アダプタは、所定の管理対象オブジェクトを明示的に割り付けられ、それと関連付けられる。リモート・アダプタは、アプリケーション・プロセスに存在し得る。次に、遠隔動作メソッドは、所定のリモート・アダプタのコンテキストに記録される。
【０１５４】
遠隔動作メソッドを含むプロセスは、リモート・アダプタを割り付けて遠隔メソッドを追加するＡＭＳライブラリ・ＡＰＩを用いて、遠隔動作メソッドを初期化する。初期化されると、この遠隔動作メソッドがアベイラビリティ・マネージャの要求、ハートビート、及び状態変化を呼び出すことによって、アベイラビリティ・マネージャは、リソースと情報を交換する。ＡＭＳ・ＡＰＩを呼び出すことによって、遠隔動作メソッドは、リソース状態における非同期的変更をアベイラビリティ・マネージャに伝達する導管にもなる。遠隔動作メソッドは局所メソッドと同様にして呼び出される、ということには注意されたい。
【０１５５】
リソースがアベイラビリティ・マネージャを備えるノードにある（つまり、アベイラビリティ・マネージャと局所状態にある）場合、アベイラビリティ・マネージャは切り替えられると別のクラスタノードに移るので、遠隔動作メソッドは依然として必要であってもよく、リソースとの通信は無停止状態を継続するべきである。ＡＭＳは、基本的な通信機構を用いることによって、別の装置におけるプロセスが活動リモート・アダプタの役割を引き継ぐ場合でさえ、遠隔動作メソッドを実行するプロセスとの通信を確実に維持するようにする。
【０１５６】
図６は、アベイラビリティ・マネージャから、リソースを操作する遠隔動作メソッドへの、要求及びデータの流れを示している。情報は、分散型メッセージ送信サービス６２０、分散型手続き呼出し６１０、管理対象オブジェクトスタブ６３０を通って流れる。
【０１５７】
ハートビート
アベイラビリティ・マネージャは、管理対象オブジェクトのハートビートを確認することによって、それらの対応するリソースの調子及び保全性を確認する。このハートビート機構は、組み込まれたＤＭＳハートビート機能を活用し、特定間隔でリソースの動作を監査し、リソースが故障している場合には、状況をアベイラビリティ・マネージャに報告する。ハートビートが故障している場合には、アベイラビリティ・マネージャは、故障したオブジェクトを所属させるための例外処理を立ち上げる。ベース・アベイラビリティ・マネージャは、構造的にオブジェクト自体を故障させることができない。しかし、デフォルト例外ハンドラが、ベースシステムの一部として備えられている。
【０１５８】
ハートビートは、タイムアウト値及び再試行値を設定することにより構成される。この２つの値の組み合わせが、ハートビートがどのぐらいの頻度で送られるかを決定する。オブジェクトは、１列において再試行値より多くのハートビートが損失された場合、故障したとみなされる。長時間にわたるプログラム（例えば、いくつかの診断）は、マルチスレッド化（多重化）するか、何らかの他の機構を用いることによって、確実にハートビート応答が適時行われるようにしなければならない。
【０１５９】
ＡＭＳのハートビートは、待ち時間が短く頻度が高くなるように設計されている。クラスタ・マネージャとＡＭＳとが同じノードでない場合、クラスタ・マネージャではなく、遠隔動作メソッドと局所状態にあるＡＭＳが、リソースのハートビートを送出する。ネットワークを介する通信は、ハートビートが故障した場合にのみ行われる。故障が生じると、通知がアベイラビリティ・マネージャに送られる。（クラスタ・マネージャが全てのノードのハートビートを確認している、ということには注意されたい。クラスタのハートビート確認速度が、管理対象オブジェクト故障の検出速度に影響を与える。具体的には、ハートビート確認は、アベイラビリティ・マネージャによって、ノードから目標ノードへ、及び目標ノードから目標ノードのリモート・アダプタへと行われる。）
【０１６０】
ハートビート確認期間は、管理対象オブジェクトのｈｅａｒｔｂｅａｔＴｉｍｅｏｕｔ属性によって制御される。この期間中における再試行の数は、管理対象オブジェクトのｈｅａｒｔｂｅａｔＲｅｔｒｉｅｓ属性によって決定される。各ハートビート確認の際には、ｈｅａｒｔｂｅａｔメソッドが呼び出される。このメソッドは、アベイラビリティ・マネージャ内及びリモート・アダプタのホスト・アプリケーションにおいて呼び出される。次に、このアプリケーションは、リソースの保全性をテストし、真又は偽の戻り値を有してメソッド呼出しから戻ることにより応答してもよい。このようにハートビートを管理対象オブジェクトクラスに露わにすることによって、このハートビート確認は、リソースへのネットワークルートの保全性を単にテストするという域を越えることができる。それどころか、このハートビート確認によって、終端間の保全性チェックを完全に行うことができる。
【０１６１】
管理対象オブジェクトはハートビートを有していなくてもよい、ということには注意されたい。ユーザがハートビート・タイムアウトを定義しなければ、管理対象オブジェクトはハートビートを得ることはない。
【０１６２】
レジストラ
管理対象オブジェクトクラスは、アベイラビリティ・マネージャとリソースとの間のインタフェースを提供するが、リソースを検出する又は管理対象オブジェクトを生成するためのコードは提供しない。そのジョブは、図２に示されているような「レジストラ」２０８の役割である。このレジストラは、リソースを検出して識別し、次に、必要とされるクラスの管理対象オブジェクトを生成することによって、そのリソースを表さなければならない。
【０１６３】
レジストラは、管理対象オブジェクトのライフサイクルに対する責務を負う。レジストラが管理対象オブジェクトを生成してもよいし、或いは、オブジェクトは静的に供給されてもよい。後者の場合、レジストラが最初にアベイラビリティ・マネージャと通信するときには、管理対象オブジェクトは既に存在している。次に、レジストラは、この管理対象オブジェクトを、対応するリソースに「接続」しなければならない。この「接続」プロセスは、レジストラがリソースを発見したときに行われる動作である。また、レジストラは、必要であれば、管理対象オブジェクトの削除に対しても責務を負う。
【０１６４】
レジストラは、ＡＭＳライブラリを用いて、アベイラビリティ・マネージャが管理対象オブジェクト生成要求を受信できる状態になったときに呼び出される状況メソッドを記録するｓｒＡｍｓＡｄｄＲｅｇｉｓｔｒａｒを呼び出すことにより、レジストラ自体を初期化する。レジストラは、管理対象オブジェクトクラスとは別のエンティティであるが、便宜上、管理対象オブジェクトクラスと共に１つの拡張機構にパッケージ化されてもよい。
【０１６５】
アベイラビリティ管理サービスはレジストラを提供しないが、開発者らは独自のレジストラを容易に生成することができる。レジストラは、リソースの存在をポーリングしてもよいし、新しいリソースの存在に関する非同期通知を受信してもよい。これらのレジストラは、協働してリソースを管理するように設計されなければならない。このような協働設計によって、２つのレジストラが、同じリソースの管理対象オブジェクトを生成しようとするのを回避することができる。２つのレジストラが同じリソースの管理対象オブジェクトを生成してしまうと、２つ目のレジストラがエラーを受信することとなる。
【０１６６】
オブジェクトを生成するレジストラは、適切な順序でオブジェクトを生成することに対して責務を負う。他の管理対象オブジェクトは、管理対象オブジェクトが存在するまでそれを参照することができない。例えば、存在しない管理対象オブジェクトの従属物を有することや、まだ存在していない親管理対象オブジェクトの管理対象オブジェクトを生成することは、エラーである。
【０１６７】
供給オブジェクト
アベイラビリティ・マネージャのシステムデータベースを供給することによって、「所望の」システム構成を表すことができる。図２に示されているような供給オブジェクト２１０は、存続を要求するフラグを有するｓｒＡｍｓＣｒｅａｔｅＯｂｊｅｃｔ・ＡＰＩを用いて生成される。供給オブジェクトは実行時においても生成され、存続されたデータ記憶は関連ソリューションの一部となる。
【０１６８】
リソースが検出されたということをアベイラビリティ・マネージャに通知するレジストラは、供給オブジェクトを発見する。レジストラは、リソース状態をｎｏＲｅｓｏｕｒｃｅ以外の何かに設定することによって、この発見を行う。
【０１６９】
従属関係
アベイラビリティ・マネージャは、そのシステムデータベースを、二重接続されたインメモリ有向グラフとして維持する。この有向グラフにおいて、各管理対象オブジェクトは、それが従属している全ての管理対象オブジェクトにリンクされると共に、それに従属している全ての管理対象オブジェクトにリンクされる。このようなデータ表現によって、トラバース（横断）が非常に高速になり、必要とされる従属関係が複雑なシステムを効果的にモデル化することができる。
【０１７０】
親／子関係
ＯＲＬにおける親／子関係は、単なる親と子の名称関係以上の関係を表す。ＯＲＬは、親／子関係を介して、包含関係を表す。図３に示されているように、階層構造の起点であるルート３３０、キャリヤカードを含むボックスであるシャーシ３２０、及び、ドーター・カード３００（ＰＣＢ）をサポートするキャリヤカード３１０自体がある。
【０１７１】
親とは単に、ＯＲＬにおいてその名称が子の名称の左側にあるオブジェクトのことである。例えば、「／Ｃｈａｓｓｉｓ ３２０／Ｃａｒｒｉｅｒ ｃａｒｄ ３１０／ｃａｒｄ ３００」というＯＲＬでは、「シャーシ３２０」が「キャリヤカード３１０」の親である、ということに注意されたい。
【０１７２】
子は、その親の存在及び調子に従属することによって、システムにおいて、作業が割り当てられるようになる。ルートから指定の管理対象オブジェクトまでの経路をたどることにより、親／子関係をコード化するＯＲＬが形成される。
【０１７３】
サービス従属関係
図４に示されているようなサービス従属関係４４０とは、第１管理対象オブジェクト（親）が「有効化」された動作状態（ｏｐＳｔａｔｅ）となってから、第２管理対象オブジェクト（子）を「有効化」することができるという、管理対象オブジェクト間の関係である。アプリケーション４　４２０とサーバ２　４１０との間には物理的従属関係４５０があるのに対し、アプリケーション１　４３０とアプリケーション４　４２０との間にはサービス従属関係４４０がある。アベイラビリティ・マネージャのシステムモデルには、従属関係が含まれており、この従属関係において、管理対象オブジェクトは、サービスグループを含む他のいずれの管理対象オブジェクトに従属してもよい。サービス従属関係４４０は、動的であり、管理対象オブジェクトクラスにより、いつでもｓｒＡｍｓＳｅｔＯｂｊｅｃｔＤｅｐｅｎｄｅｎｃｉｅｓ・ＡＰＩを呼び出すことによって生成される。
【０１７４】
１つのリソースが別のリソースに従属しており、順に第１リソースに（又は、より複雑な従属関係となるように）従属していく、ループが可能である。ＡＭＳは、所定の管理対象オブジェクトのみがその従属関係有向グラフ内の従属要素により無効にされるときを決定することにより、これらのループを検出して解決する。
【０１７５】
ループには、リソース従属関係を効果的にモデル化することを要求してもよい。アベイラビリティ・マネージャは、状態変化の影響を伝播する際、訪問済のオブジェクトをマーキングすることによって、ループを１回だけトラバースする。ループとは一般的な従属関係グラフの通常部分であり、アベイラビリティ・マネージャが意図的なループと非意図的なループとを区別することは不可能である。いずれの場合においても、アベイラビリティ・マネージャは、ループを１回だけトラバースする。
【０１７６】
チェックポインティング
チェックポインティング１１６の目的は、待機リソース１１２、１１４を、できるだけ活動リソース１００の状態及びデータに追いついた状態に保つことである。複製データベースを用いることによって、記憶に基づいたチェックポインティングを実施することができる。
【０１７７】
故障検出
ハートビート故障の結果として、リソース故障が生じると、アベイラビリティ・マネージャは、その管理対象オブジェクトに対して例外通知をする。例外ハンドラが、その管理対象オブジェクトの機能を停止させたり再開させたりする責務を負う。
【０１７８】
障害検出器を用いることによって、そのリソース特別の障害検出を行ってもよい。障害検出器が障害を識別すると、その管理対象オブジェクトを故障と表し得る指定された回復ポリシーが呼び出される。
【０１７９】
リソースへのアクセス及びリソースの制御
アベイラビリティ・マネージャは、ＳＮＭＰエージェントを用いてＳＮＭＰ接続全体を完全に制御することのできる、包括的ＡＰＩを提供する。同様に、ウェブインタフェースを用いることによって、アベイラビリティ・マネージャを表示して制御することもできる。コンソールは、ウェブベースの標準インタフェースを提供することによって、アベイラビリティ・マネージャ及び全ての管理対象オブジェクトを視覚化して制御する。
【０１８０】
管理対象オブジェクトクラス
管理対象オブジェクトクラスは、ｓｒＡｍｓＣｒｅａｔｅＣｌａｓｓ・ＡＰＩを用いて、インタフェース・リポジトリにおいて定義される。このＡＰＩは、属性及びメソッドＸＭＬ記述ファイルの位置や、クラスを含む拡張機構というような、クラスの完全な詳細を特定するか、或いは、クラスの完全な詳細をｃｌａｓｓｅｓ．ｘｍｌファイルにおいて定義する。
【０１８１】
図７．アベイラビリティ・マネージャ・クラスの階層構造
図７に示されている標準クラスは、次のとおりである。
・ｏｂｊｅｃｔ７００−ＯＭＳによってもたらされるルートクラス。
・ｍａｎａｇｅｄＯｂｊｅｃｔ７１０−アベイラビリティ管理を必要とする全てのオブジェクトに対する主要ベースクラス。
・ｄｉｒｅｃｔｏｒｙ７３０−オブジェクト組織目的の標準ベースクラス。
・ｒｅｍｏｔｅＯｂｊｅｃｔ７４０−遠隔動作メソッドに対する標準ベースクラス。
・ｓｅｒｖｉｃｅＧｒｏｕｐ７２０−全てのサービスグループに対するベースクラス。
・Ｅｘａｍｐｌｅ ｕｓｅｒ−ｄｅｆｉｎｅｄ ｏｂｊｅｃｔ７５０−可能なユーザ定義オブジェクトクラス。いずれのｍａｎａｇｅｄＯｂｊｅｃｔ導出クラスから導出してもよい。
【０１８２】
管理対象オブジェクトに対するデフォルトクラスは、ｍａｎａｇｅｄＯｂｊｅｃｔである。しかし、好適な実施形態では、いずれの特定クラスも必要としない管理対象オブジェクトに対して定義されるＳＲ＿ＡＭＳ＿ＤＥＦＡＵＬＴ＿ＣＬＡＳＳを用いることによって、ハードコードするｍａｎａｇｅｄＯｂｊｅｃｔ以外の属性又はメソッドがクラスとして供給されるべきである。
【０１８３】
各クラスの属性は、以下のような修飾子を有することができる。
・Ｐｅｒｓｉｓｔｅｎｔ（存続）−システムの再ブートを通して属性値を保存する。
・Ｒｅｐｌｉｃａｔｅｄ（複製）−故障の場合に属性値をチェックポインティングする。
・Ｒｅａｄ−ｏｎｌｙ（読取り専用）−属性値を修正しなくてもよい。
・Ｏｂｓｅｒｖｅｄ（観察）−セット・アンド・ゲット・メソッドによって操作される。
・Ｐｒｏｔｅｃｔｅｄ（保護）−アベイラビリティ・マネージャによってのみ修正されてもよい。
【０１８４】
ｏｂｊｅｃｔクラス
「Ｏｂｊｅｃｔ」クラスとは、全てのオブジェクトに対するルートクラスである。このｏｂｊｅｃｔクラスは、従属関係、並びに、オブジェクト・バージョン及び属性を供給する。
【０１８５】
ｍａｎａｇｅｄＯｂｊｅｃｔクラス
ｍａｎａｇｅｄＯｂｊｅｃｔクラスとは、アベイラビリティ・マネージャによって管理される全てのオブジェクトに対する必須ベースクラスである。このｍａｎａｇｅｄＯｂｊｅｃｔクラスは、ｏｂｊｅｃｔクラスをサブクラスに分類し、ＩＳＯ状態モデル、サービスグループ帰属関係、ウェブベース管理、及び供給に対するサポートを追加する。
【０１８６】
アベイラビリティ・マネージャは、ＩＳＯ　Ｘ．７３１状態モデルをサポートする１セットの属性を維持する。これには、以下のような属性が含まれる。
・管理状態（ａｄｍｉｎｉｓｔｒａｔｉｏｎ ｓｔａｔｅ）−ａｄｍｉｎＳｔａｔｅ
・動作状態（ｏｐｅｒａｔｉｏｎａｌ ｓｔａｔｅ）−ｏｐＳｔａｔｅ
・使用状態（ｕｓａｇｅ ｓｔａｔｅｓ）−ｕｓａｇｅ
・アベイラビリティ状況（ａｖａｉｌａｂｉｌｉｔｙ ｓｔａｔｕｓ）−ａｖａｉｌＳｔａｔｕｓ
・制御状況（ｃｏｎｔｒｏｌ ｓｔａｔｕｓ）−ｃｏｎｔｒｏｌＳｔａｔｕｓ
【０１８７】
アベイラビリティ・マネージャは、属性を追加して、より包括的な管理対象オブジェクト及びリソース状態モデルを供給することによって、ＩＳＯモデルを拡張する。アベイラビリティ・マネージャは、アベイラビリティ・マネージャ・ＡＰＩの呼出しに応答して、ＩＳＯ状態と拡張状態との両方を更新する。これにより、様々なリソース・メソッドが呼び出されて、そのリソースと対話するようになり得る。状態エンジン（例えば、有効、無効）の一部を表すメソッドは、いくつかの故障状況においては、２回呼び出すことができる。
【０１８８】
状態エンジン・メソッドは、故障にも関わらず常に前進復帰する。例えば、無効メソッドがネットワークエラーを戻した場合でも、状態エンジンは、開始していたどんな動作も取り消そうとはしない。それどころか、その動作を完了させる。遠隔動作メソッドが故障した場合には、そのメソッドを無効にすることによって、状態エンジン処理中におけるさらなるタイムアウトが回避される。
【０１８９】
ｓｅｒｖｉｃｅＧｒｏｕｐクラス
図７に示されているようなｓｅｒｖｉｃｅＧｒｏｕｐクラス７２０とは、全てのサービスグループ管理対象オブジェクトに対するベースクラスである。このｓｅｒｖｉｃｅＧｒｏｕｐクラスは、ｍａｎａｇｅｄＯｂｊｅｃｔクラスをサブクラスに分類し、名称、ポリシー、及び、サービスグループを統率するパラメータに対するサポートを追加する。
【０１９０】
サービスグループは、そのｒｅｓｏｕｒｃｅＳｔａｔｅを、ポリシーパラメータの充足度に基づいて算出する。標準ポリシーは、活動サービスグループメンバの数がそのサービスグループに対する閾値よりも少ない場合、例外処理を立ち上げる。ｓｒＡｍｓＣａｌｃＳｅｒｖｉｃｅＧｒｏｕｐＳｔａｔｅを呼び出すことによって応答するデフォルト例外ハンドラが備えられていることにより、ｒｅｓｏｕｒｃｅＳｔａｔｅ属性が「故障中」に変更される。閾値が満たされると、新しい例外処理が立ち上げられて、ｒｅｓｏｕｒｃｅＳｔａｔｅが「正常（ｈｅａｌｔｈｙ）」に変更される。管理対象オブジェクトは、サービスグループオブジェクトに従属することができる。サービスグループのｏｐＳｔａｔｅは、標準ルールに基づいて算出されるため、ｒｅｓｏｕｒｃｅＳｔａｔｅの設定は、直接的な効果を与える。サービスグループの無効化は、サービスグループとメンバとの間に従属関係がない限り（このような従属関係があることは非一般的）、サービスの提供を続けるそのメンバに直接的に影響を与えることはない。
【０１９１】
サービスグループを別のオブジェクトに従属させても、サービスグループのメンバに有意な影響を与えることはない。メンバは、可能であれば、サービスグループが従属関係によって無効にされた場合でも、サービスの提供を続ける（サービスグループとそのメンバとの間には（顧客が定義した）直接的な従属関係は無いものとする）。
【０１９２】
ｓｅｒｖｉｃｅＧｒｏｕｐクラスは、以下のような属性を供給する。
【０１９３】
ｍａｎａｇｅｄＯｂｊｅｃｔメソッドに加えて、ｓｅｒｖｉｃｅＧｒｏｕｐクラスは、以下のようなメソッドを追加する。
【０１９４】
ｄｉｒｅｃｔｏｒｙクラス
ｄｉｒｅｃｔｏｒｙクラス７３０が供給されることによって、オブジェクトを、ＯＲＬツリー内の論理グループにおいて組織することができる。このｄｉｒｅｃｔｏｒｙクラスは、ｍａｎａｇｅｄＯｂｊｅｃｔクラスをサブクラスに分類するが、独自のメソッド又は属性は供給しない。
【０１９５】
ｒｅｍｏｔｅＯｂｊｅｃｔクラス
ｒｅｍｏｔｅＯｂｊｅｃｔクラス７４０とは、全てのメソッド呼出しを、全てのｍａｎａｇｅｄＯｂｊｅｃｔメソッドに対する遠隔動作メソッドに回すクラスである。このｒｅｍｏｔｅＯｂｊｅｃｔクラスは、ｍａｎａｇｅｄＯｂｊｅｃｔクラスをサブクラスに分類する。このｒｅｍｏｔｅＯｂｊｅｃｔクラスは、１つのクラスに対して用いることができ、追加属性又はメソッドは必要としないが、ｍａｎａｇｅｄＯｂｊｅｃｔクラスメソッドが遠隔動作メソッドであることを必要とする。
【０１９６】
アベイラビリティ・マネージャとの作業
クラスタ・トポロジー
アベイラビリティ・マネージャは、クラスタ・マネージャと同じノードにおいて実行される。構成及びロール管理を１つの場所において行うことによって、多くのアベイラビリティ問題が単純化される。別々の場所でも一貫して使用できるように、アベイラビリティ・マネージャは、クラスタ・マネージャ・ノードとクライアント・ノードとの両方における管理対象オブジェクトに対して、ＡＰＩインタフェースを提供する。
【０１９７】
待機アベイラビリティ・マネージャは、クラスタ予備ノードにおいて実行されると共に、ホットスタンバイとして実行される。アベイラビリティ・マネージャが実行しているノードが故障した場合には、待機アベイラビリティ・マネージャが、状態又は構成を全く損失させずに、アベイラビリティ管理を行う。ＡＭＳクライアントにはフェイルオーバーが通知され、ＡＭＳクライアントは、待機アベイラビリティ・マネージャが活動ロールを行うまで、アベイラビリティ・マネージャ・ＡＰＩの呼出しを一時停止する。そのときまで、アベイラビリティ・マネージャ・ＡＰＩは、アベイラビリティ・マネージャの準備が完了するのを待機している状態を遮断する。アベイラビリティ・マネージャがその準備状況を変更すると、ＡＭＳ・ＡＰＩのスタブは、新しいマネージャに対して動作の再試行を行う。
【０１９８】
アプリケーション又はリモート・アダプタは、記録を行うことによって、ｓｒＡｍｓＡｄｄＲｅｇｉｓｔｒａｒ・ＡＰＩを用いて、マネージャ状況の変更に関するコールバックを受信することができる。
【０１９９】
標準クラスタオブジェクト及びクラスタサービスグループに用いられるクラスは、オーバーライドすることができる。これにより、ソリューションは、非標準動作又はポリシーを提供することができる。
【０２００】
クラスの拡張及び新しいメソッドの追加
アベイラビリティ・マネージャ・サービスによって、新しいクラスを、顧客定義メソッドで定義することができる。標準クラスは、これらの導出クラスに対するベースクラスとして用いることができる。新しいメソッドは、そのメソッドをクラス初期化の一部として記録することによって、定義することができる。また、新しいメソッドは、分散型手続き呼出しサービスを用いることによって、遠隔動作メソッドとなることも可能である。
【０２０１】
ＡＰＩ論議
【０２０２】
Ｃ機能
【０２０３】
結論
アベイラビリティ管理サービスの目的は、故障又は計画的な停止によるダウン時間を最小に抑えることである。アベイラビリティ管理サービスは、管理対象オブジェクトを通してリソースを管理することによって、この目的を達成する。クラスタ全体の又は独立型のソリューションであるアベイラビリティ・マネージャは、クラスタ・マネージャ・ノード及びクライアント・ノードにおける管理対象オブジェクトにインタフェースを提供する。アベイラビリティ・マネージャは、サービスグループにおける管理対象オブジェクトに対してロール割当てを行い、必要に応じて、システム状況の変更やロールの再割当てに応答する。
【０２０４】
アベイラビリティ・マネージャは、システムの構成に関する包括的なシステム記述を維持する。アベイラビリティ・マネージャは、リソースに関する完全な状態情報を維持して、クラス属性及びメソッドのオブジェクト指向方式を提供する。
【０２０５】
図８に示されているように、ステップには、クラスタにおけるリソースを見つけるステップ８００と、従属連鎖を確立するステップ８１０と、アベイラビリティ・マネージャとしてのノードを選択するステップ８２０と、（バックアップとしての）待機アベイラビリティ・マネージャを選択するステップ８３０と、アベイラビリティ・マネージャ、待機アベイラビリティ・マネージャ、非マネージャ・ノード、及び、リソースを表すその他の管理対象オブジェクト間の通信リンクを確立するステップ８４０と、所望の応答を決定するためのポリシーを確立するステップ８５０と、システム状態の変更に応答してリソースを割り当てるステップ８６０とが含まれる。
【０２０６】
好適な実施形態に従ってマルチモード・クラスタの可用度を高くするシステム及び方法に関する上記の説明は、本質的には単なる例にすぎず、本発明又はその応用又はその使用を限定することは全く意図していない。さらに、上記の説明では、用いられる方法及びシステムに関する多数の細目を述べることによって、本発明をより完全に理解できるようにしている。しかしながら、当業者には、本発明はこのような特定細目を用いずに実施してもよい、ということは明白であろう。他の例では、周知のプロセスの特性及び機能については説明されていないので、本発明が不明瞭となることはない。
【図面の簡単な説明】
【図１】
アベイラビリティ・マネージャの一般的なトポロジーを示す図である。
【図２】
アベイラビリティ・マネージャのアーキテクチャを示す図である。
【図３】
親／子関係の例を示す図である。
【図４】
リソース間における物理的従属関係及びサービス従属関係を示す図である。
【図５】
リソースとサービスグループとの間における関係を示す図である。
【図６】
メッセージ送信サービス及び遠隔手続き呼出しを含む、アベイラビリティ・マネージャのアーキテクチャを示す図である。
【図７】
アベイラビリティ・マネージャ・クラスの階層構造を示す図である。
【図８】
アベイラビリティ・マネージャのプロセスを示すフローチャートである。
【図１】
2004512610.tif 000003
【図２】
2004512610.tif 000004
【図３】
2004512610.tif 000005
【図４】
2004512610.tif 000006
【図５】
2004512610.tif 000007
【図６】
2004512610.tif 000008
【図７】
2004512610.tif 000009
【図８】
2004512610.tif 000010
【国際公開パンフレット】
2004512610.tif 000011
2004512610.tif 000012
2004512610.tif 000013
2004512610.tif 000014
2004512610.tif 000015
2004512610.tif 000016
2004512610.tif 000017
2004512610.tif 000018
2004512610.tif 000019
2004512610.tif 000020
2004512610.tif 000021
2004512610.tif 000022
2004512610.tif 000023
2004512610.tif 000024
2004512610.tif 000025
2004512610.tif 000026
2004512610.tif 000027
2004512610.tif 000028
2004512610.tif 000029
2004512610.tif 000030
2004512610.tif 000031
2004512610.tif 000032
2004512610.tif 000033
2004512610.tif 000034
2004512610.tif 000035
2004512610.tif 000036
2004512610.tif 000037
2004512610.tif 000038
2004512610.tif 000039
2004512610.tif 000040
2004512610.tif 000041
2004512610.tif 000042
2004512610.tif 000043
2004512610.tif 000044
2004512610.tif 000045
2004512610.tif 000046
2004512610.tif 000047
2004512610.tif 000048
2004512610.tif 000049
2004512610.tif 000050
2004512610.tif 000051
2004512610.tif 000052
2004512610.tif 000053
2004512610.tif 000054
2004512610.tif 000055
2004512610.tif 000056
2004512610.tif 000057
2004512610.tif 000058
2004512610.tif 000059
2004512610.tif 000060
2004512610.tif 000061
2004512610.tif 000062
2004512610.tif 000063
2004512610.tif 000064
2004512610.tif 000065
2004512610.tif 000066
【国際公開パンフレット（コレクトバージョン）】
2004512610.tif 000067
【国際調査報告】
2004512610.tif 000068