JP2005530240A - 分散計算システムの管理システム及び方法 - Google Patents

Abstract

【課題】 複数の資源（２０８）を持つ分散計算システムを管理するためのシステム（２００）及び方法を提供する。
【解決手段】 システム（２００）は、複数の資源（２０８）と通信可能に接続された一対のシステム管理サーバー（１１６）を含む。システム管理サーバー（１１６）は、ユーザ（２０２）から計算システムの所望の機能又は特性を表す計算システムの要求されたビューを受取る。さらに、サーバー（１１６）は、計算システムの実際の状態又は特性を表す計算システムの実現されたビューを監視する。サーバー（１１６）は、実現されたビューと要求されたビューとを比較して、実現されたビューが一貫して要求されたビューを満足するように複数のシステム資源（２０８）を自動的且つダイナミックに構成する。

Description

本発明は、一般に、計算システムに関し、より詳細には、高度にスケーラブルな分散計算システムの管理システム及び方法に関する。本発明は、ユーザが選択したある機能及び性能特性に合わせるためにシステム資源を自動的に供給し、そしてユーザが選択した特性の修正及び／又はシステム資源の変化に適合するようにシステム資源を動的に構成して割当てる。

従来の分散計算システムを管理するために、システム管理者は、システムがある機能と性能特性を供給するように、システム資源を特別に構成して割当てることが要求されている。例えば、分散ファイル・システムの管理は、管理インターフェイスを介して新ファイル・システムを定義し、ファイル・システムのための資源を供給し、そしてアクセスのためにファイル・システムを可能化（もし、システムがシャットダウンされたならば、その後のシステム開始時及び供給後の両方）することを含む。また、管理は管理インターフェイスを介してファイル・システムを削除することを要求し、アクセスからファイル・システムを使用不可能にし（例えば、削除が要求された時又はシステム・シャットダウンが要求された時）、そして削除されたファイル・システムに対して供給された資源を解放することを含む。さらに、システム管理者は、故障、システム資源の追加又は修正の際、機能及び性能要求の変化を満足するため及び／又はある機能と性能特性を維持するために、システム資源の再割当て及び再構成を要求される。

従来の計算システムでは、前述の全ての管理機能は典型的にはシステム管理者により実行される。これはシステム管理者の絶え間の無い注意と努力を必要とする。特に、システム管理者は絶えず、所望の結果を達成して維持するためにシステム資源を監視し、供給し、構成し、そして修正しなければならない。これは計算システムを管理し維持するために必要な費用と時間を好ましくなく増加させる。

従って、システム管理者にある機能及び性能特性（例えば、所望の結果）を指定又は選択することのみを要求し、管理者に所望の結果を達成及び維持するためにシステム資源の供給と構成を要求しない、分散計算システムの維持のためのシステムを提供することが望まれる。従って、本発明は、ユーザが選択したある機能及び性能特性に合わせるためにシステム資源を自動的に構成し、そしてユーザが選択した特性の修正に適合するように及び／又はシステム資源の状態の変化に適合するようにシステム資源を動的に構成して割当てる、分散計算システムを管理するためのシステムを提供する。

本発明の限定的ではない１つの長所は、システム管理者がある機能及び性能特性を入力することを可能にして、所望の結果を達成するために自動的にシステム資源を供給する分散計算システムを管理するためのシステムを提供する。

本発明の別の限定的ではない１つの長所は、所望の機能の修正に適合するため及び／又はシステム資源の状態の変化に適合するために、自律的にシステム資源を再構成する分散計算システムを管理するためのシステムを提供する。

本発明の別の限定的ではない１つの長所は、所望の結果を達成するためにシステム管理者が単にある機能及び性能特性を入力することを可能にして、管理者が結果を得るためにシステム資源を特に供給することを必要としない。システムは、資源がどのように使用されているかを報告し視覚化することを提供できるが（例えば、システム開発及び監視目的のため、及び／又はカスタマー視認のため）、このような報告及び視覚化は、システムの管理及び通常の使用を必要としない。

本発明の別の限定的ではない長所は、ファイル・システムの資源を管理するシステム及び方法を提供することである。システムは、広い範囲の処理能力要件を持ち、広い範囲の平均ファイル・サイズを持ち、潜在的に大きい及び小さいのが混合した多数のファイル・システムを支援する。システムはさらに、管理者がサービス・レベル契約で普通に使用される性能特性（容量、処理能力及び応答時間など）の値を選択できるように、サービスの指定された品質の支援を供給する。

本発明の別の限定的ではない長所は、管理者に指定されるようなシステムの所望の状態又は性能を表す要求されたビューをシステム管理者が入力できるインターフェイスを提供する。インターフェイスはさらに、システムの実際の状態又は性能を反映する実現されたビューを表示できる。実現されたビューは、新規に生成されたファイル・システムの供給など、進行中であるがまだ完了していない変化を反映できる。また、それは、要求されたビューが変化しない場合でも、資源が負荷をシステム上でより良くバランスするためにそして部品の故障から回復するために再割当て又は移動される時、時々に変化する。システムは絶えず自動的に実現されたビューが要求されたビューに最良に一致するようにシステム資源を駆動する。

本発明の１つの観点によると、複数の資源を持つ分散計算システムを管理するためのシステムが提供される。システムは、複数の資源に通信可能に接続された少なくとも１つのサーバーを含み、ユーザからの分散計算システムの要求された特性を受取ることができるように構成されていて、そして要求された特性を満足するために自動的及び動的に複数の資源を構成する。

本発明の第２の観点によると、複数の資源を持つ分散ファイル・システムを管理するためのシステムが提供される。システムは、ユーザが、ファイル・システムの少なくとも１つの所望の特性を表す、ファイル・システムの要求されたビューを入力できるように構成されたインターフェイスと、第１部分はファイル・システムの少なくとも１つの実際の特性を表すファイル・システムの実現されたビューを監視するために構成され、第２部分は要求されたビューと実現されたビューとを記憶するように構成され、第１部分と第２部分と複数の資源に通信可能に接続された少なくとも１つのサーバーとを含み、少なくとも１つのサーバーは要求されたビューと実現されたビューとを比較して、実現されたビューが要求されたビューと一致するように複数の資源を自動的且つ動的に修正するように構成されている。

本発明の第３の観点によると、分散計算システム中の複数の資源を管理するための方法が提供される。方法は、分散計算システムの少なくとも１つの要求された特性を表す、分散計算システムの要求されたビューを受取り、分散計算システムの少なくとも１つの実際の特性を表す、分散計算システムの実現されたビューを監視し、要求されたビューと実現されたビューを比較し、そして、実現されたビューが要求されたビューを首尾一貫して満足することを確保するように複数の資源を自動的且つ動的に構成する、各ステップを含む。

本発明のこれらと他の長所及び特徴は、添付図面を参照した以下の説明から明らかとなる。

〔実施の形態の詳細な説明〕
当業者が本発明を実施できるように、本発明の例を示した添付図面を参照して、本発明を詳細に説明する。本発明は、当業者には明らかなように、ソフトウェア、ハードウェア、及び／又はファームウェア、又はそれらのどんな組合わせを使用して実現できる。本発明の好適な実施の形態を、分散計算システムのファイル・システムの例示的な実現を参照してここに詳細に説明する。しかし、本発明は、この例示的な実現に限定されるものではなく、ある機能、性能特性及び／又は結果を提供するために供給されて構成される複数の資源を含んだいずれの計算システムにおいて実現できる。

Ｉ．一般システム・アーキテクチャ
図１を参照すると、本発明の１つの実施の形態による、システム資源を管理する方法及びシステムを組み込んだ、例示的に高度にスケーラブルな、分散計算システム１００が示されている。分散計算システム１００は、サービス・ノード１３０ａ−１３０ｎ及びシステム管理サーバー（ＳＭＳ）／ブート・サーバー対１１６ａ、１１６ｂを含む、複数の資源を有する。また、システム１００は、複数の分配されず割当てられていない資源（図示しない）を含むことができる。各ＳＭＳサーバー１１６ａ、１１６ｂは、通常のサーバー、計算システム又はこれらの装置の組合わせを含むことができる。各ＳＭＳサーバー１１６ａ、１１６ｂは、以下により詳しく完全に説明されるファイル・システムの要求された及び実現されたビューを含む、システム１００に関する状態及び構成情報を記憶する構成データベース（ＣＤＢ）１１４ａ、１１４ｂを含む。ＳＭＳサーバー対１１６ａ、１１６ｂの１つは（例えば、ＳＭＳサーバー１１６ａ）、主ＳＭＳサーバーとして機能し、他は（例えば、ＳＭＳサーバー１１６ｂ）、バックアップとして機能し、主ＳＭＳサーバーが利用不可能な場合に主ＳＭＳサーバーと同じ機能を実行するように構成されている。ＳＭＳサーバー対１１６ａ、１１６ｂの各々は、システム管理サービスを実行するように構成されたＳＭＳサーバー対の上に搭載されたハードウェア、ソフトウェア及び／又はファームウェアを含んだＳＭＳモニターを含む。これらのサービスは、ユーザの選択したある性能特性及び機能を提供することを確保するためにシステムがシステム資源を自律的且つ動的に供給して修正することを含む。さらに、ＳＭＳサーバー対１１６ａ、１１６ｂは、サービスノードの開始、停止、及び再ブートなどの他の管理サービス、及び新規に活性化されたノードへのソフトウェアのローデイングについて責任を持つ。別の実施の形態では、ＳＭＳサーバー対１１６ａ、１１６ｂは、前述した機能の１つ又は複数を実行する追加の別個の装置を含むことができる（例えば、別個のブート専用サーバー）ことが理解される。以下の説明では、ＳＭＳサーバー対１１６ａ、１１６ｂは集合的にＳＭＳモニター１１６と呼ばれ、そしてＣＤＢ対１１４ａ、１１４ｂは集合的にＣＤＢ１１４と呼ばれる。さらに、１つのコンポーネントを指す数“ｎ”が異なるコンポーネントの数“ｎ”とは必ずしも等しくないため、“ｎ”項はここでは不定の複数を指すために使用される。例えば、サービスノード１３０ａ−１３０ｎの数は、サービス１２０ａ−１２０ｎの数と等しい必要はないが、等しくても良い。

システム１００内の各サービスノードは、インターフェイス（例えば、１６０ａ１−１６０ａｎ、１６０ｂ１−１６０ｂｎ、１６０ｎ１−１６０ｎｎ）を用いて、例えば、限定的ではなく、スイッチド・インターネット・プロトコル（ＩＰ）ベース・ネットワーク、バス、無線ネットワーク、又は、他の適当な相互接続機構を含んだ、少なくとも一対のスイッチング・ファブリック１１０ａ−１１０ｎに接続される。スイッチング・ファブリック１１０ａ−１１０ｎは、どんな数のサービスノード、ブートサーバー、及び／又はＳＭＳモニター１１６、管理エンティテイなどの機能専用サーバーへの接続を提供する。

さらに、システム１００は、システムのさまざまなノードに接続されて（例えば、サービスノード１３０ａ−１３０ｎ及びＳＭＳサーバー１１６ａ、１１６ｂへ）、ノードへ「ハード故障」及びリセット制御と共に外部電力接続を供給する複数の遠隔電力制御ユニット１１５を含む。特に、遠隔電力制御ユニット１１５は、ＳＭＳモニター１１６が、各コンポーネントの外側の位置から、選択的にノードを停止させ、又は、ノードを開始又はリセットすることを可能にする。特に、ＳＭＳモニター１１６は、選択的に制御信号を電力制御ユニット１１５へ通信して、ユニットがそれぞれのノードを選択的に停止又はリセットさせる。各電力制御ユニット１１５は、冗長経路を介してスイッチング・ファブリック１１０ａ−１１０ｎへ接続されて、これにより、単一経路が故障した場合でも、ＳＭＳモニター１１６がノードを制御することを可能にする。

好適な実施の形態では、システム１００内の各サービス・ノード１３０ａ−１３０ｎは、例えば、限定的ではなく、ゲートウェイ・プロセス、メタデータ・プロセス、又は、ファイル・システムの記憶プロセスであってよい、少なくとも１つのサービス・プロセス１０３ａ−１０３ｎを含むことができる。各サービスノード１３０ａ−１３０ｎは、単一サービス・インスタンス（例えば、サービスノード１３０ａ又は１３０ｂ）、又は主サービス・インスタンス（例えば、サービスノード１３０ｃ１又は１３０ｄ１）及び１つ又は複数のバックアップ・サービス・インスタンス（例えば、サービスノード１３０ｃ２又は１３０ｄ２）であることができる。主サービス・インスタンス及びその１つ又は複数のバックアップ・サービス・インスタンスは大抵の場合、独立の故障を確保するために物理的に別個のマシーンに存在し、これにより、主サービス・インスタンス及びその１つ又は複数のバックアップ・サービス・インスタンスが一緒に故障することを防止する。単一サービス・インスタンス又は主及びバックアップ・サービス・インスタンスを提供するかどうかに関わらず、サービス１２０ａ−１２０ｎは典型的に、分散計算システム内で異なる機能を提供する。例えば、限定的ではなく、１つのサービスは、分散されたスケーラブルな耐故障メタデータ・サービス（ＭＤＳ）を提供し、別のは、分散されたスケーラブルなゲートウェイ・サービス（ＧＳ）、分散されたスケーラブルなビットファイル記憶サービス（ＢＳＳ）、又はいくつかの他のサービスを提供する。メタデータ、ゲートウェイ、及び記憶サービスの例が、本出願人に譲渡され、ここに参照により全体が組み込まれた、米国特許出願シリアル番号０９／７０９，１８７、発明の名称「スケーラブルな記憶システム」、に記載されている。

また、システム１００中の各サービス・ノード１３０ａ−１３０ｎは、ライフ・サポートサービス（ＬＳＳ）プロセス１０２ａ−１０２ｎを含むことができる。ＬＳＳプロセスは、分散計算システム１００のサービス及びコンポーネントの状態及び動作を監視する。この状態及び動作の情報は、ＳＭＳモニター１６へ通信されて、この情報をユーザが選択した性能特性及び機能を達成するためにどのようにシステム資源を割当てて修正すべきかを決定するために使用される。ＬＳＳシステムの機能は、本出願人に譲渡され、ここに参照により全体が組み込まれた、同時係属の米国特許出願、発明の名称「分散計算システム中のコンポーネントの状態及び動作を監視するためのシステム及び方法」、に記載されている。

また、システム１００中の各サービスノード１３０ａ−１３０ｎは、サービスノードを遠隔的に管理するため（例えば、サービスノードの開始、停止、及び再ブート）、ＳＭＳモニター１１６により使用される管理エンティテイである、ＳＭＳエイジェント・プロセス１０１ａ−１０１ｎを含む。各エイジェントは、ノードへソフトウェアをロードするためにＳＭＳモニター１１６により遠隔的に指示できる耐故障ソフトウェア・ローディング機構を含むことができる。１つの実施の形態では、全ノードについてのソフトウェアは、ＳＭＳモニター１１６の２つの別個のブートサーバー部分中に記憶されている。

本発明は、サービスノードのコンポーネントがＳＭＳモニター１１６及びスイッチング・ファブリック１１０ａ−１１０ｎを介して他のコンポーネントから直接にメッセージを受取ることを可能にする。又は、代替的に、このようなメッセージは、既知の又は適当な仲介スキームにより、通信ソフトウェア１０４ａ−１０４ｎの別の層により仲介される。

本発明の原理によると、前述のノード及びサービスは、説明の目的のためにのみ与えられたものであり、限定するものではない。システム１００の資源は、どんな機能又はサービスに対して使用できる。例えば、限定的ではなく、高度にスケーラブルなサービス及び耐故障サービスである。さらに、３つのサービス（すなわち、サービス１２０ａ、１２０ｂ、１２０ｎ）及び２つのＳＭＳ／ブートサーバー（すなわち、サーバー１１６ａ、１１６ｂ）のみが示されたが、本発明によりより多くのこれらのサービス及びサーバーの各々がスイッチング・ファブリックを経由して互いに接続されることができる。

ＩＩ．システムの操作
図２を参照すると、本発明の１つの実施の形態による、システム１００などの分散計算システム内の資源を管理するためのシステム２００の一般的な操作を説明するブロック図が示されている。システム２００のユーザ２０２は、システム管理者であってよい。図２に示すように、ユーザ２０２は、インターフェイス２０４を使用することにより、計算システムの所望及び／又は必要なある機能及び／又は性能特性をＳＭＳモニター１１６中に入力する。ユーザ２０２は、単にある機能及び性能特性を入力し（例えば、所望の結果）、そして従来のシステムで結果を得るためにシステム資源を供給するために必要とされる特定の手順又は命令を入力しない。例えば、ファイル・システム応用では、ユーザ２０２は、平均ファイル大きさ、ファイル数、スペース制限、帯域幅、及び／又は、秒当たりの操作などの特性を入力できる。ＳＭＳモニター１１６は、これらの所望の特性を反映又は表す、ファイル・システムの要求されたビューを生成するためにこれらの特性を使用する。

さらに、ＳＭＳモニター１１６は、ファイル・システムが所望の結果を達成するために、自動的にシステム資源２０８を供給する。さらに、ＳＭＳモニター１１６は、システムの実際の状態又は性能を反映するファイル・システムの実現されたビューを生成する。一般に、実現されたビューは、新規に生成されたファイル・システムの供給など、進行中であるがまだ完了していない変化を反映する。また、要求されたビューが変化しない場合でも、システム上での負荷のより良いバランスのため及びコンポーネントの故障からの回復のために、資源が再割当て又は移動される時、実現されたビューは、時々に変化する。

ＳＭＳモニター１１６は、絶えず、ファイル・システムの実現されたビューを要求されたビューと比較して、実質的に実現されたビューが要求されたビューと一致又はミラーするように、システム資源２０８を再割当て及び／又は再構成する。例えば、もし、ユーザ２０２が要求されたビューを変えると、ＳＭＳモニター１１６は更新された所望の結果を与えるためにシステム資源２０８を修正、再割当て及び／又は再構成する（もし、必要ならば）。同様に、もし、システム資源２０８の修正、追加、問題又は故障があると、ＳＭＳモニター１１６は実現されたビューが絶えず実質的に要求されたビューと一致又は満足するように、システム資源２０８を修正、再割当て、及び／又は再構成する（もし、必要ならば）。

この自動的「再供給」機能を提供するため、ＳＭＳモニター１１６は資源の割当てと状態とを識別する記録を維持する（例えば、ＣＤＢ１１４内に）。ＳＭＳモニター１１６が、１つ又は複数のシステム資源中の状態の変化の通知を受取る時（例えば、ＬＳＳプロセスから）、ＳＭＳモニター１６は関連の割当てを見て、所望の状態が現在の状態に一致するかどうかを決定する。もし、状態の変化がシステム資源の故障を表している場合、ＳＭＳモニター１１６は資源を再開始又は再ブートすることを試みる。もし、資源がまだ適当に機能しなければ、ＳＭＳモニター１１６は、実現されたビューが再び実質的に要求されたビューと一致するようにシステム資源を修正及び／又は再割当てするための修正サブルーチンを開始する。システム資源を修正するためにＳＭＳモニター１１６により実行されるさまざまな手順は、下のＩＩ．Ｅ．３節により詳細に記載されている。

要求されたビューと実現されたビューとは、別々であるが、並列に記録の組に記憶される（例えば、ＣＤＢ１１４内に）。最初の生成時の実現されたビューは要求されたビューのコピーであり、オブジェクト・タイプに依存して満たされるいくつかの追加のフィールドを持つ。更新に対しては、特定のフィールドがコピーされるが、実行可能と決定されたシステムの実行状態への更新に必要なもののみである。

Ａ．ユーザ・インターフェイス
システム２００は、システム管理者などのユーザがファイル・システム及びそれらのそれぞれの性能パラメータを生成して修正できる通常のユーザ・インターフェイスを使用する。また、インターフェイス２０４は、システム開発及び監視目的のため及びカスタマ視認のために、資源がどのように使用されているかの視覚化及び報告を提供する。しかし、このような報告及び視覚化は、システムの通常の使用と管理には必要でない。ユーザ・インターフェイス２０４は、コマンドライン・インターフェイス（ＣＬＩ）、ウェブサーバー・インターフェイス、ＳＮＭＰサーバー・インターフェイス、及び／又はグラフィカル・ユーザ・インターフェイス（ＧＵＩ）を含む。図３は、本発明に使用できるグラフィカル・ユーザ・インターフェイスの修正画面３００の例示的な実施の形態を示す。インターフェイス画面３００は、ユーザがファイル・システム・パラメータを更新又は修正することを可能にする。例えば、インターフェイス画面３００は、ユーザが名前、仮想ＩＰアドレス、スペース制限、平均ファイル大きさ、ファイル数、帯域幅、及び、ファイル・システムの一秒当たりの操作を変更することを可能にするフィールドを含む。図４は、ユーザがファイル・システムの実際の性能を見ることができる画面４００の例示的な実施の形態を示す。ユーザは、容量、自由スペース、使用、一秒当たりの操作（ＮＦＳ Ｏｐｓ／秒）、一秒当たりの平均読出し及び書込み操作（例えば、ＫＢ／Ｓｅｃ）、及び他の関連の性能パラメータなどの性能パラメータを見ることを要求できる。代替的な実施の形態では、その他の適当な性能パラメータを表示できる。好適な実施の形態では、グラフィカル・ユーザ・インターフェイスが、ユーザにファイル・システムの生成、可能化、不可能化、及び削除を可能にし、システムの使用と他の報告の生成を可能にし、そして、その他の適当な管理機能の実行を可能にするための追加の画面も含むことができる。

Ｂ．ファイル・システムの要求されたビュー
好適な実施の形態では、ファイル・システムの要求されたビューは、システム性能及び機能情報など、ユーザにより管理可能な情報を含むことができる。もし、特性がユーザにより管理できなければ、ユーザに見える必要がなく（しかし、見えても良く）、ＣＤＢの「要求されたビュー」の部分の一部である必要がない（しかし、あっても良い）。

好適な実施の形態では、要求されたビューは、完全なファイル・システムを表す“ｆｉｌｅｓｙｓｔｅｍ”エンティテイを含む。“ｆｉｌｅｓｙｓｔｅｍ”エンティテイが完了したと見なされる前に、全ての必要な特性が設定されなければならない。ユーザは、要求されたビュー内の“ｆｉｌｅｓｙｓｔｅｍ”エンティテイを生成、修正、開始、停止、及び、削除できる。“ｆｉｌｅｓｙｓｔｅｍ”エンティテイを削除することは、エンティテイにより定義されるファイル・システムの削除の要求を表す。要求は、ファイル・システムがファイル・システムの実現されたビューから消滅するまでは完了しない。

また、“ｆｉｌｅｓｙｓｔｅｍ”エンティテイは、作成、削除、開始、停止、及び修正の各々について、対応する状態特性と進行及び故障情報報告特性を持つ。状態特性は、「開始されていない」、「進行中」、「完了」、又は、「故障」を示し、そして、進行及び故障情報報告特性はこれらの状態値に利用可能などんな理由を示すことができる。特に、「進行中」状態は、その活動の段階を示す情報報告を持つことができる。「故障」状態は、普通は、資源の制限又は割当ての枯渇である、理由を示す情報報告を持つことができる。

要求されたビューは、状態特性の更新を除き、システムによりそれ自身で変更されることはない。もし、更新が実現できなければ（例えば、所望のサービスレベル契約（ＳＬＡ）が資源の不足のために満たすことができないため）、これは状態に示される（及び、長いメッセージに基づいた警告により）。

たとえ、更新が最初は成功したとしても、資源が後で失われて、サービスレベル契約（ＳＬＡ）に合うことがもはや実行不可能となることもあり得る。両方の場合において、システムは、現在実現されたビューが、ある程度、要求されたビューを反映していないことを示す。管理インターフェイスによる要求されたビューに対する同期的更新は、いくつかの一貫性及び実現可能性検査を実行できるが、検査は非同期事象（資源の予期されない損失など）により常に無効化されることに注意する。すなわち、ＳＭＳモニター１１６は、不可能な要求を拒絶することを試みるが、全ての場合で後の非同期故障を回避することはできないため、アーキテクチャは両方の故障モデルを支援しなければならない。

顧客（例えば、ユーザ又はシステム管理者）、ユーザ設定、及び、ファイル・システムは、管理ソフトウェアにより最初に処理される時、独特な識別子を割当てられることができる。もし、ファイル・システムが、要求されたビューから削除され、そして同じ名前を持つ新規なファイル・システムが要求されたビュー内に生成された場合、２つのファイル・システムは異なる（そして、第１のファイル・システム内のいずれのデータは削除時に失われる）。

Ｃ．ファイル・システムの実現されたビュー
好適な実施の形態では、ファイル・システムの実現されたビューは、例えば、ユーザ又は顧客には見えない領域中の、ＣＤＢ１１４のシステム・プライベート領域中に記憶できる。ファイル・システムの実現されたビュー・エンティテイは、ＣＤＢ１１４のトップ・レベル“＿ｆｉｌｅｓｙｓｔｅｍｓ”の下に記憶できる。実現されたビュー内の各ファイル・システム・エンティテイは、ファイル・システムの顧客／ユーザ独特ＩＤを指定する属性を含むことができる。もしあれば、ファイル・システムに対する要求されたビューを見るために顧客独特ＩＤ及びファイル・システム独特ＩＤを使用できる。

実現されたビューは、生成、修正、開始、停止、及び、シャットダウンに関するファイル・システムの状態を表すために使用される追加の属性を含むことができる。もしあれば、それは供給された資源を記録する属性も含むことができる。

Ｄ．状態マシーン管理
好適な実施の形態では、システム２００は、与えられた操作中のさまざまなステップを内在的に順序付ける状態マシーンとして、ファイル・システム（例えば、システム１００）上のさまざまな操作をモデルする。好適な実施の形態では、ＳＭＳモニター１１６は、限定的ではなく、ファイル・システム生成、修正、削除、開始及び停止などの全ての必要なファイル・システム機能に対して状態マシーンを含む。いくつかの場合、故障の発生など、ある状態マシーンは中間状態で別の状態マシーンを開始後に終了する。例えば、もし、ファイル・システム生成中のいくつかのステップの第２が故障した場合、それは生成状態マシーンを終了して、その最終状態から２つのステップの状態マシーンの削除を開始する（既に生成が完了しているそれらのステップを単に反転するため）。また、ファイル・システムが最初にシャット・ダウンされることが必要な、削除などの状態マシーンがシャット・ダウン状態マシーンを開始して、そしてその状態マシーンの完了をトリガーする。

ＳＭＳモニター１１６は、状態マシーンを管理して、あるエラー及び早熟な終了状態に対する動作を含む、それを状態シーケンスに組み込む。状態値はシンボリック形式で報告でき、２進形式で記憶される。ファイル・システムに対する状態特性は実現された及び要求されたビューの両方において繰返される（要求されたビュー中に状態特性を設定する試みは無視されることに注意する）。

状態マシーンは、２つの状態、「準備」及び「動作」において実行できる。「準備」状態は、外部事象に対する同期点としての機能を果たし、そして、「動作」状態は所望のファイル・システム機能（例えば、生成、修正、開始、停止等）を実行する。「準備」クラスの状態に対して、ＳＭＳモニター１６は、状態マシーンの早熟な終了を導く状態を検査し（生成、開始、又は修正されている最中のファイル・システムの削除の要求など）、状態を適当に変更する（例えば、生成時に削除が要求された場合には「ＳＭＳ故障」状態へ）。このような状態が存在しない場合、それは自動的に状態を「動作」クラスの対応する状態へ進めて、そして、どんな外部動作にもかかわらず、完了を実行する。この時点で、状態は次の状態の「準備」クラスへ進む。この「準備」及び「動作」クラスの使用は、操作が最終的に失敗する場合に時間と資源を節約する、ファイル・システム操作からの早期の終了機会を与える。

ＳＭＳモニター１１６は、状態マシーンを管理するためのさまざまな機能を含むことができる。これらの状態マシーンのさまざまな状態を列挙するために、状態マシーンの列挙のための定義された記号が存在する。この方法では、ＳＭＳモニター１１６は、各状態マシーンについて状態のシーケンス、そして、各状態に対して、その状態のエラーの場合に強制される状態マシーン値、及び、非標準状態遷移を強制するその他の特性を定義する内部テーブルを維持できる。

ＳＭＳモニター状態マシーン・エンジンは、ＳＭＳモニター１１６のトップレベル・ループの一部として実行され、さまざまなサービス・マスターに特有なハンドラー・ルーチンを呼出す。ＳＭＳモニター１１６において、サービス・マスターは、別々のプロセス又はスレッドではなく、関連した機能の集まりである。エンジンは、状態特性値を自動的に設定することにより、状態マシーンを新しい状態へ進める。

状態マシーンと共に各エンティテイは、要求された及び実現されたビューの両方において、各状態マシーンについて状態特性を持つことができる。状態特性は、ストリング値、その現在状態を提供する。

また、ＳＭＳモニター状態マシーン・エンジンは、一致しないＣＤＢデータを一致する状態に強制するように構成できる。エンジンは、どんなＣＤＢ更新エラーをサーバーについて致命的であるとして取扱うことができる。バックアップ・システム上の回復が可能ならば進行するように、ローカルＣＤＢコピーをサスペクトとしてフラグすることを試みる。もし、全てのＣＤＢコピーがサスペクトと印を付けられたならば、ＳＭＳモニター１１６は最新のコピーと共に進むことを試みる。もし、その試みが失敗した場合、ＳＭＳモニター１１６は故障通知を配達することを試みて、それ以上の更新の試みを終える。１つの実施の形態では、システム２００は、冗長ＣＤＢ情報をメタデータ・サービス（ＭＤＳ）とビットファイル記憶システム（ＢＳＳ）インスタンスと共に記憶し、この情報をＣＤＢ１１４を再構築するために使用する。代替的に、ＣＤＢ１１４は手動で再構築される。

Ｅ．資源管理
ファイル・システム又はその他の計算システムを供給するため、ＳＭＳモニター１１６は、与えられたクラスの利用可能な資源を決定して、そして与えられた資源を与えられたエンティテイ又はサービスへ割当てる（例えば、ファイル・システムは、ＭＤＳ、ＢＳＳ及びゲートウェイ・サービス又はエンティテイを持つ）。例えば、生成されるファイル・システムにＭＤＳパーティションを供給するために、ＳＭＳモニターは、各々が十分な余裕の処理能力と、メインメモリと、ＭＤＳパーティションの要件を収容するためのディスク空間とを持つゲートウェイ／ＭＤＳクラス・マシーンの一対を見つけるためにＭＤＳサービス・マスタを使用する。

大きな数のゲートウェイ／ＭＤＳマシーンを必要とせずにいくつかの小さなファイル・システムを処理するために、一般に、ＳＭＳモニター１１６は、マシーン全体よりも少なく割当てる。一方、システムはあるエンティテイの資源要求について制限された知識だけを持つことができ、資源測定のために小さな範囲の値を使用することができる。

１．割当て単位
ＳＭＳモニター１１６は、システム性能特性又は資源値が認定できる測定可能単位を定義する。単位のタイプと大きさは、実現されるシステムのタイプとシステムの機能及び性能特性に基づき、変化する。好適な実施の形態では、ＳＭＳモニター１１６は、処理能力（ＣＰＵ）、メモリ、容量、一秒当たりの操作、応答時間、スループットなどの特性を測定するために、単位を定義する。これらの単位の限定的でない例のいくつかが以下にリストされる。

ＣＰＵ単位：１ＧＨＺｘ８６タイプ・プロセッサの０．００１（“１ＭＨＺ”）
メモリ単位：１ＭＢ
ディスク容量単位：１ＭＢ
ディスク操作単位：一秒当たり１ランダムＩ／Ｏ
ディスク・スループット単位：一秒当たり１ＭＢ

上述の単位は任意であり、ＣＰＵやディスク装置などの特定のシステム資源に割当てられた値は、近似である。資源の断片化を最小にするために、割当ては、重要な数ビットへ割当てユーティリテイ・ルーチンにより丸められる。

ＳＭＳモニター１１６はさらに、論理的及び物理的スイッチポート及びゲートウェイの帯域幅を測定して管理するように構成されている。ある実施の形態では、これはさまざまなアップリンクの既知の性能に基づいた手動のプロセスである。

２．資源要件
好適な実施の形態では、上述の単位で測定され認定されるさまざまなサービスの測定は、要求されたビュー及び実現されたビューの特性として含まれる。例えば、ファイル・システム特性は、平均ファイル大きさ推定（バイトで）、一秒当たりのネットワーク・ファイル・システム（“ＮＦＳ”）操作推定、典型的応答時間推定（マイクロ秒で）、及び、一秒当たりのバイト推定が含まれ、これらの全ては全体としてシステム又は顧客から受け継がれるデフォルトを含む。これらの資源に対する実現されたビューが要求されたビューに実質的に一致さない時（例えば、要求されたビューの資源要件がもはや合わない時）、ＳＭＳモニター１６は実現されたビューが要求されたビューと一致するように自動的にシステム資源を再構成する。特に、ＳＭＳモニター１１６は、実現されたビューの特性が要求されたビューの要件を満足することを確保するために、ファイル・システムを再構成する修正状態マシーンを開始する。

３．システム資源の修正
ＳＭＳモニター１６は、実現されたビューが要求されたビューの要件を満足することを確保するため、システム資源を自動的に修正する。修正活動又は状態マシーンは、いくつかの異なる環境下でＳＭＳモニター１１６により開始される。例えば、限定的ではなく、修正状態マシーンは、ユーザが要求されるビューを変更する時、システム資源の状態が変化する時（例えば、資源が故障又は動作不能になる時）、ＳＭＳモニター１１６がシステム上で好ましくない負荷のバランスの乱れを検出した時、そして、資源がシステムに加えられた時、に修正状態マシーンが開始される。

図５は、本発明の１つの実施の形態により、ユーザがシステムの要求されたビューを変更した時、修正状態マシーンを開始するために使用される例示的な方法５００を示す。方法５００は、ステップ５１０に示すように、ユーザが入力パラメータを変更した時に開始する（例えば、インタフェイス２０４を使用して）。変更された入力パラメータは、ＳＭＳモニター１１６へ送られて、ステップ５２０に示すように、所望の変更に対応するように要求されたビューを改訂する。そして、ＳＭＳモニター１１６は、ステップ５３０に示すように、改訂された要求されたビューを実現されたビューと比較する。次に、ＳＭＳモニター１１６は、ステップ５４０に示すように、現在実現されたビュー（すなわち、システムの現在の状態又は性能）が要求されたビュー（すなわち、システムの所望の状態又は性能）に実質的に一致するか又は満足するかを決定する。システムの現実の構成が性能標準又は使用の増加を実現及び満足するために設計されているため、要求されたビューのある変化はシステム資源の修正を開始又はトリガーしないかもしれない。したがって、もし、実現されたビューが改訂された要求されたビューと一致又は満足する場合、ステップ５５０に示すように、方法は終了する。もし、実現されたビューが改訂された要求されたビューと一致又は満足しない場合、ステップ５６０に示すように、ＳＭＳモニター１１６は修正状態マシーンを開始する。

図６は、本発明の１つの実施の形態による、システム資源が故障又は動作不能になった時など、システム資源の状態が変化した時に修正状態マシーンを開始するために使用される例示的な方法６００を示す。方法６００は、ステップ６１０に示すように、ＳＭＳモニター１１６がＬＳＳから故障通知を受取る時に開始する（ＬＳＳからの１つ又は複数のシステム資源の故障状態を示すメッセージ）。また、ＳＭＳモニター１１６は再開始の際に故障通知を得ることができる。特に、再開始の際、ＳＭＳモニター１１６はそれが割当てたいずれの資源が故障したか又はもはや利用可能でないかどうかを検査する。故障通知（又は、その他の割当てられた資源が故障したことを発見した際）の受信の際、ステップ６２０に示されるように、ＳＭＳモニター１１６は故障資源の再開始を試みる。例えば、ＳＭＳモニター１１６は対応する遠隔電源ユニット１１５へ信号を送信して、影響を受けた資源の再開始を電源ユニット１１５へ指示する。そして、ＳＭＳモニター１１６は、再開始が成功して資源が適正に動作しているかどうかを判断するために資源の動作を観察する。例えば、ＳＭＳモニター１１６は資源が適正に動作しているかを判断するためにＬＳＳを使用する。もし、再開始が成功したならば、ステップ６４０に示すように、方法６００は終了する。もし、再開始が成功しなければ、ステップ６５０に示すように、ＳＭＳモニター１１６は修正状態マシーンを開始する。システムが修正されて、そして問題のある資源が交換された後、ステップ６６０に示すように、ＳＭＳモニター１１６は交換された資源を削除してそれを実現されたビューから取り除く。

図７は、本発明の１つの実施の形態による、システム上に負荷のバランスが失われた時に修正状態マシーンを開始するために使用される例示的な方法７００を示す。方法７００は、ステップ７１０で、ＳＭＳモニター１１６がさまざまなシステム資源上にある負荷を監視するところから開始する。ステップ７２０で、ＳＭＳモニター１１６が観測された使用について許容できない負荷のバランスのくずれがあるかどうかを判断する。特に、ＳＭＳモニター１１６は、使用がある所定の許容レベル又は量を越えたかどうかを判断するためにさまざまシステム資源の使用を観測する（又は、代替的に、使用がある所定の許容レベル又は量の下に落ちたかどうか）。もし、許容できない負荷のバランスのくずれがある場合、ＳＭＳモニター１１６は、ステップ７３０に示すように、修正状態マシーンを開始する。

好適な実施の形態では、修正状態マシーンが開始される時、ＳＭＳモニター１１６は、ファイル・システム（例えば、メタデータ・サービス（ＭＤＳ）、ビットファイル記憶サービス（ＢＳＳ）、及び、ゲートウェイ・サービス（ＧＳ））のエンティテイ又は各部分についての修正ルーチンを個別に実行できる。図８は、本発明の１つの実施の形態による、例示的な修正ルーチン又は方法８００を示す。修正方法８００は、ステップ８１０で、ＳＭＳモニター１１６が必要とされる資源を決定するところで開始される（例えば、割当ての所定の単位で）。ＳＭＳモニター１１６は、現在の要求されたビュー及び／又はシステム上の負荷のバランスのくずれの存在と大きさに基づいて、必要とされる資源を決定してもよい。例えば、ＳＭＳモニター１１６は、所望の容量又は性能要件が超過している程度を決定するために現在の入力パラメータと実際のシステム性能をレビューする。ＳＭＳモニター１１６は、割当ての所定の単位を用いて、この観測を測定可能な値に定量化する。ＳＭＳモニター１１６は、１つ又は複数のマッピング関数を用いてこの定量化を実行できる。これらのマッピング関数は、例えば、同様な資源を持つ同様な計算システム（例えば、ファイル・システム）の性能及び動作の前もっての測定及び解析などによる、前もっての試験と実験とにより決定できる。必要な性能及び／又は超過している必要な性能の量を入力することにより、記憶されたマッピング関数は割当ての所定の単位で必要とされる資源の量を出力できる。例えば、関数はファイル・システム・サービス又はコンポーネントに必要とされる性能特性を与えるために必要な単位数を与えることができる。

ステップ８２０で、ＳＭＳモニター１１６は、システム中で現在利用可能な資源を決定する。特に、ＳＭＳモニター１１６は、利用可能な割当ての単位量及びこれらの単位の分配を決定するために利用可能な資源を走査する。この走査は、システムに追加されたかもしれないどんな新資源又はホスト・エンティテイを含む。好適な実施の形態では、ＳＭＳモニター１１６は、１つ又は複数のリレーショナル・テーブル（例えば、ＣＤＢ１１４中に）中に全ての資源情報を記憶して更新する。例えば、マシーンがシステムに追加された時、ＳＭＳモニター１１６は、そのマシーンの各特性の量又は資源値を判定した後、マシーンを「ホスト」リストへ追加して、ＣＤＢ１１４中に特性について適正な値（割当ての単位で）を記憶する。資源の部分が割当てられる時、ＳＭＳモニター１１６は、そのマシーンについて使用及び未使用の資源値又は特性の現在の状態を反映するためにリスト又はテーブルを改訂する。図９は、限定的ではない１つの例の、異なる大きさ及び異なる使用の資源９１０−９６０を持つ、分散計算システム９００のブロック図である。この例では、ＳＭＳモニター１１６は、資源９１０−９６０を走査して、各資源について使用済み（斜線ハッチで示される）の割当ての単位量と利用可能な（空白で示される）割当ての単位量を決定する。また、ＳＭＳモニター１１６は、各ホスト・エンティテイについて、メンバーが１つ又は複数のサービス・クラスを含んだ「割当て組」特性を記憶する。例えば、ＭＤＳ割当てを作る時、ＭＤＳサービスの使用のためにラベルが付けられたマシーンのみが考慮される。マシーンがシステムに追加される時、ＳＭＳモニター１１６は、マシーンをそれが使用できるサービスのタイプに関して分類するためにハード符号化規則を使用する。ファイル・システムの限定的ではない例では、ＳＭＳモニター１１６は、次のイニシャルのクラスを定義する。“ＳＭＳ”、“ＭＤＳ”、“ＧＳ”及び“ＢＳＳ”である。“ＳＭＳ”は、ブート・サーバー、ホスト・ロギング、ＬＳＳモニター・ホスト、ウェブ・サーバー管理ホスト、及びＳＭＳモニター・ホストを含む。

図８を再び参照すると、ステップ８３０で、ＳＭＳモニター１１６は、必要な資源を利用可能な資源に割当てるための最適化戦略を実行する。好適な実施の形態では、ＳＭＳモニター１１６の最適化戦略は２つの考察を含む。最初に、戦略は、必要とされる資源が単一の利用可能な資源（例えば、マシーン）に適合するかどうかを決定することにより、オーバーヘッドを最小にすることを試みる。もし、必要とされる資源が単一の利用可能な資源に適合できる場合、ＳＭＳモニター１１６は、必要とされる資源をその資源へ割当てる。そうでなければ、ＳＭＳモニター１１６は、必要な資源を最小の数の利用可能な資源へ割当てることを試みる。例えば、もし、必要とされる資源が、２０００単位のＭＤＳを表す場合、最適化ルーチンは、ＭＤＳを２つの部分に分割して各部分を利用可能な１５００単位を持つ別々の資源へ割当てるよりは、利用可能な３０００単位を持つホストへＭＤＳを割当てることを「好む」であろう。ファイル・システム・コンポーネントが分割される数を減少することにより、当業者には理解されるように、システム内の全オーバーヘッド（又は、使用不可能空間）を減少する。もし、新しい資源がシステムに付け加えられた場合、ＳＭＳモニター１１６は、全オーバーヘッドを減少するために、前に分割されたファイル・システム・コンポーネント（すなわち、２つ又はそれ以上の資源内に存在するコンポーネント）を新資源内に統合することを選択するであろう。従って、ＳＭＳモニター１１６により実行される修正は、あるコンポーネント又はサービスを異なる又は新しい資源へ移動及び／又は統合することを含むことが理解される。第２に、戦略は、必要とされる資源に対して最良の場所を決定するために「最良適合」分析を実行する。すなわち、戦略は、小さすぎて別の目的又はコンポーネントのために効率的に使用できない未使用空間の相対的に小さい部分が生成されることを防止するために、必要とされる資源を最も近く一致した利用可能な資源又は資源の組に置くことを試みる。

最後に、ＳＭＳモニター１１６が必要とされる資源について最適な割当てを決定した後、ステップ８４０で示されるように、ＳＭＳモニター１１６は、割当てと合うように対応する資源を割当て、修正し、及び／又は、解放する。ＳＭＳモニター１１６は、システム資源の使用及び未使用部分の現在状態を反映するためにＣＤＢ１１４のリレーショナル・テーブル中に、対応する更新を記録する。ファイル・システムが修正又は生成された後、ＳＭＳモニター１１６は、システムをアクセスのために使用可能にする。

このようにして、ＳＭＳモニター１１６は、実現されたビューが一貫して要求されたビューの要件を満足することを保証するために、自動的にシステム資源を修正する。

４．ファイル・システムの生成
前述したように、ユーザは、インターフェイス２０４を使用して（例えば、ファイル・システム又はコンポーネントの名前を付けて、そして所望の機能又は性能特性を割当てることにより）、新ファイル・システム又はコンポーネントを生成できる。新ファイル・システムを生成するためにＳＭＳモニター１１６により行われるステップは、ファイル・システムが修正される時に取られるステップと実質的に同一である。特に、ＳＭＳモニター１１６は、（ｉ）マッピング関数を使用してファイル・システムについて必要な資源を決定し、（ｉｉ）利用可能な割当ての単位の量及びそれらの単位の分配を決定するために、利用可能な資源を走査し、（ｉｉｉ）ファイル・システムについて最良の場所を決定するために最適化ルーチンを実行し、（ｉｖ）ファイル・システムを生成するためにシステム資源を割当て、そして（ｖ）アクセスのためにファイル・システムを使用可能にする。好適な実施の形態では、ＳＭＳモニター１１６は、各ファイル・システム・コンポーネント又はエンティテイ（例えば、ＭＤＳ、ＢＳＳ及びゲートウェイ・コンポーネントに対して）に対して、この方法を別々に実行する。

５．他のファイル・システム操作
本発明の好適な実施の形態では、３節及び４節においてそれぞれ上述されたファイル・システムの修正と生成に加えて、ＳＭＳモニター１１６は、ファイル・システムについて開始、停止、及び削除操作も実行できる。ＳＭＳモニター１１６は、これらの操作を実行するために状態マシーンを実行する。ファイル・システム開始状態マシーンは、選択されたファイル・システム又はファイル・システム・コンポーネントを活動化するように構成されている。ファイル・システム停止状態マシーンは、選択されたファイル・システム又はファイル・システム・コンポーネントを非活動化するように構成されている。そして、ファイル・システム削除状態マシーンは、選択されたファイル・システム又はファイル・システム・コンポーネントを削除するように構成されている。これらの状態マシーンの要素と機能は、業界で既知の開始、停止、及び、削除マシーンと実質的に類似している。

全ての記載された状態マシーン（例えば、生成、修正、開始、停止及び削除）の内、ファイル・システム停止及びファイル・システム削除状態マシーンは故障できない。もし、ファイル・システム生成状態マシーンが故障すると、ＳＭＳモニター１１６は、ファイル・システム削除状態マシーンへ変移して、部分的に生成されたファイル・システムを削除する。もし、ファイル・システム開始状態マシーンが故障すると、ＳＭＳモニター１１６は、ファイル・システム停止状態マシーンへ変移して、操作を停止する。もし、ファイル・システム修正状態マシーンが故障すると、ＳＭＳモニター１１６は、操作を終了して、ファイル・システムを要求されたビューと必ずしも一致しないが、自己矛盾がない安定な状態に残す。

上述したように、ファイル・システム操作（例えば、準備部分の間）から早期に終了する機会を与えるために、状態マシーンは「準備」及び「動作」部分に分割できる。この方法では、ＳＭＳモニターは、操作が最終的に故障した場合に時間と資源を節約する。さらに、状態マシーンは各ファイル・システム・サービス・エンティテイ（例えば、ＭＤＳ、ＢＳＳ、及びＧＳ部分）について、別々の部分に分割できる。

全てのファイル・システム操作に対して、状態変化は「実現されたビュー」内の状態の更新と同じトランザクション中で「要求されたビュー」内に反映される。上述したように、状態の原因を明確にするため（特に、故障の場合）、「要求されたビュー」内に利用可能な状態結果がある。この状態報告は、状態値を更新する同じトランザクションにおいて、実現された及び要求されたビューの両方に記憶できる。

このようにして、本発明は、要求された性能要件又は特性を満足するため及び／又は適合するために自動的及びダイナミックにシステム資源を構成する分散計算システムを管理するシステム及び方法を提供する。このシステム及び方法は、所望の結果を達成するために、管理者が単にある機能及び性能特性を入力することを可能にし、結果を得るためにシステム資源を特に供給する必要が無い。システムは、要求された特性中に形成された変化、システム資源の状態の変化、システム中に発生する負荷のバランスのくずれを満足するために、システム資源を自律的及び動的に修正する。システムは、広い範囲の処理能力要件を持ち、広い範囲のファイル平均ファイル大きさを持ち、潜在的に大きいものと小さいものとが混合した、多数のファイル・システムを支援する。さらに、システムは、管理者がサービス・レベル契約書で普通に使用されるポリシー特性（処理能力や応答時間など）を指定できるように、サービスの指定された品質を支援する設備をサポートする。

本発明が好適な実施の形態を参照して特に説明されたが、当業者には本発明の範囲と精神から逸脱することなく、変形と修正が詳細と形式において可能なことが明らかである。例えば、本発明は図５、６、７及び８に説明された例示的な方法に限定されるものではない。追加の又は異なるステップと手順を方法に含ませることができる。そして、方法のステップはいかなる適当な順番で実行できる。さらに、さまざまな実施の形態は必ずしも排他的ではなく、ある実施の形態の特徴は他の実施の形態の特徴と組合わせられても、本発明の範囲と精神の中に留まることが、当業者に明らかである。

１つの実施の形態の管理システムのシステムと方法を組み込んだ例示的な分散計算システムのブロック図。 図１に示された管理システムの一般的な動作を示すブロック図。 本発明に使用されるグラフィカル・ユーザ・インターフェイスの更新された画面の例示的な実施の形態を示す図。 本発明に使用されるグラフィカル・ユーザ・インターフェイスの監視画面の例示的な実施の形態を示す図。 本発明の１つの実施の形態による要求されたビュー中の変化に応答して修正状態マシーンを開始するための例示的な方法を示すブロック図。 本発明の１つの実施の形態によるシステム資源の状態中の変化に応答して修正状態マシーンを開始するための例示的な方法を示すブロック図。 本発明の１つの実施の形態によるシステム上の負荷のバランスの変化に応答して修正状態マシーンを開始するための例示的な方法を示すブロック図。 本発明の１つの実施の形態による例示的な修正ルーチン又は方法を示すブロック図。 資源の使用の大きさが変化することを示す、分散計算システムの資源のブロック図。

Claims (21)

1. 複数の資源を持つ分散計算システムを管理するシステムであって、
   複数の資源に通信可能に接続され、ユーザから分散計算システムの要求された特性を受取るように構成され、そして、要求された特性を満足するために自動的且つダイナミックに複数のシステム資源を構成する少なくとも１つのサーバーを含むシステム。
2. 少なくとも１つのサーバーが、分散計算システムの実際の性能を要求された特性と比較するため分散計算システムの実際の性能を監視し、そして、実際の性能が一貫して要求された性能を満足することを保証するように複数の資源を自律的且つ動的に修正するようにさらに構成されている請求項１に記載のシステム。
3. 分散計算システムが、ファイル・システムを含む請求項１に記載のシステム。
4. 要求された特性が、ファイル・システムの性能特性を含む請求項３に記載のシステム。
5. 少なくとも１つのサーバーが、主サーバーとバックアップ・サーバーとを含む請求項１に記載のシステム。
6. 複数の資源上にそれぞれ配置されて、少なくとも１つのサーバーの遠隔制御により資源を局地的に管理するように構成された複数のエイジェントをさらに含む請求項１に記載のシステム。
7. 少なくとも１つのサーバーが、少なくとも１つのスイッチング・ファブリックを介して複数の資源に通信可能に接続されている請求項１に記載のシステム。
8. 少なくとも１つのサーバーと複数の資源とに通信可能に接続された複数の遠隔電力制御ユニットをさらに含み、この電力制御ユニットは少なくとも１つのサーバーから受信した制御信号に応答して複数の資源を選択的に停止及びリセットするように構成されている請求項１に記載のシステム。
9. ユーザが分散計算システムの要求された特性を入力及び修正して、少なくとも１つのサーバーに要求された特性を通信することを可能にするように構成されたインターフェイスをさらに含む請求項１に記載のシステム。
10. インターフェイスが、グラフィカル・ユーザ・インターフェイスを含む請求項９に記載のシステム。
11. 複数の資源を持つ分散ファイル・システムを管理するためのシステムであって、
    ユーザが、ファイル・システムの少なくとも１つの所望の特性を表す、ファイル・システムの要求されたビューを入力できるように構成されたインターフェイスと、
    ファイル・システムの少なくとも１つの実際の特性を表す、ファイル・システムの実現されたビューを監視するように構成された第１部分と、
    実現されたビューと要求されたビューとを記憶するように構成された第２部分と、
    第１部分と第２部分と複数の資源とに通信可能に接続されて、要求されたビューと実現されたビューとを比較し、そして、実現されたビューが要求されたビューと一致するように複数の資源を自動的且つダイナミックに修正するように構成された少なくとも１つのサーバーと、
    を含むシステム。
12. 少なくとも１つの所望の特性及び少なくとも１つの実際の特性が、性能特性を含む請求項１１に記載のシステム。
13. 性能特性が、処理能力、メモリー、容量、一秒あたりの動作、応答時間、及び、スループットからなるグループから選択されている請求項１２に記載のシステム。
14. 第２部分が、少なくとも１つのサーバー内に記憶された構成データベースを含む請求項１１に記載のシステム。
15. 第１部分が、ライフ支援サービスを含む請求項１１に記載のシステム。
16. 少なくとも１つのサーバーと複数の資源とに通信可能に接続されて、少なくとも１つのサーバーから受信した制御信号に応答して複数の資源を選択的に停止及びリセットするように構成された複数の遠隔電力制御ユニットをさらに含む請求項１１に記載のシステム。
17. インターフェイスが、グラフィカル・ユーザ・インターフェイスを含む請求項１１に記載のシステム。
18. 分散計算システム中で複数の資源を管理する方法であって、
    分散計算システムの少なくとも１つの要求された特性を表す、分散計算システムの要求されたビューを受取るステップと、
    分散計算システムの少なくとも１つの実際の特性を表す、分散計算システムの実現されたビューを監視するステップと、
    要求されたビューと実現されたビューとを比較するステップと、
    実現されたビューが一貫して要求されたビューを満足することを保証するように複数の資源を自動的且つダイナミックに構成するステップと、
    を含む方法。
19. 複数の資源を自動的且つダイナミックに構成するステップが、
    実現されたビューが要求されたビューを満足するために必要な資源をマッピング関数を用いて決定するステップと、
    利用可能な資源の量及び利用可能な資源の分配を決定するために複数の資源を走査するステップと、
    最適化ルーチンを実行するステップと、
    最適化ルーチンに基づいて複数のシステム資源を構成するステップと、
    をさらに含む請求項１８に記載の方法。
20. 最適化ルーチンが、オーバーヘッドを減少するように構成されている請求項１９に記載の方法。
21. 最適化ルーチンが、最良適合分析を含む請求項２０に記載の方法。

Images