JP2008517358A - ストレージ管理を容易にするための装置、システム、および方法 - Google Patents

Abstract

【課題】ストレージ・リソースの編成を通じてストレージ管理を容易にするための、装置、システム、および方法を提供すること。
【解決手段】この装置は、各論理エンティティが他方の論理エンティティの動作をミラーリングし、直接通信するように、第１の論理エンティティおよび第２の論理エンティティをピア・ツー・ピア領域内で互いに対話するように構成する、構成モジュールを含む。情報モジュールは、ローカル・リソースが管理ノードからの管理コマンドのターゲット・リソースとして使用可能なように、第１の論理エンティティのローカル・リソースおよび第２の論理エンティティのローカル・リソースを、管理ノードに公開する。アドレス・モジュールは、管理ノードからの管理コマンドを、管理コマンドのタイプによって決定された第１の論理エンティティのローカル・リソースあるいは第２の論理エンティティのローカル・リソースまたはその両方に向かって、選択的にアドレッシングする。
【選択図】 図２

Description

本発明は、データ・ストレージ・コンピュータ・システムに関する。具体的に言えば、本発明は、ストレージ・リソースの編成を通じてストレージ管理を容易にするための装置、システム、および方法に関する。

コンピュータおよび情報技術は、その機能および複雑さにおける向上および成長を続けている。特にデータ・ストレージ・システムは、物理データ・ストレージ・システムならびにそのハードウェア、ソフトウェア、および様々な他のコンポーネントの信頼性、可用性、および保守性に対する増え続ける需要を満たすために、進化を続けている。データ・ストレージ・システムは、しばしば主幹業務データを処理する。したがってデータ・ストレージ・システムは、２４時間毎日（２４／７）のスケジュールに従ってオンラインを維持し、使用可能であることが期待される。さらにデータ・ストレージ・システムは、ホストからのデータの入力／出力（Ｉ／Ｏ）を処理するための信頼性および可用性を大幅に損なうことなく、電源およびサービスの停止、ハードウェアおよびソフトウェア障害、さらにはルーチン・システム保守までをも、処理することが期待される。

図１は、従来のデータ・ストレージ・システム１００を示す図である。システム１００は、ストレージ・エリア・ネットワーク（ＳＡＮ）１０６などのネットワーク１０６によってストレージ・サブシステム１０４に接続された、１つまたは複数のホスト１０２を含む。ホスト１０２は、データＩ／Ｏをストレージ・サブシステム１０４に送る。ホスト１０２は当分野で周知であり、データＩ／Ｏをストレージ・サブシステム１０４に送るように構成された任意のコンピュータ・システムを備える。

本発明と共に使用するのに好適なストレージ・サブシステム１０４の一例が、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシンズ・コーポレーション（ＩＢＭ）から入手可能な、ＩＢＭ Ｅｎｔｅｒｐｒｉｓｅ Ｓｔｏｒａｇｅ Ｓｅｒｖｅｒ（Ｒ）である。信頼性、可用性、および冗長性を提供するために、ストレージ・サブシステム１０４は、別々のチャネルを介してＳＡＮ １０６に接続された複数のホスト・アダプタ（図示せず）を含む。ホスト・アダプタ１０８は、ファイバー・チャネルなどの高速通信プロトコルをサポートすることができる。もちろん、様々な他のホスト・アダプタ１０８を使用して、Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｉｎｔｅｒｆａｃｅ（ｉＳＣＳＩ）、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ ｏｖｅｒ ＩＰ（ＦＣＩＰ）、Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍｓ Ｃｏｎｎｅｃｔｉｏｎ（ＥＳＣＯＮ）、ＩｎｆｉｎｉＢａｎｄ、およびＥｔｈｅｒｎｅｔを含むが、これらに限定されることのない、他のプロトコルをサポートすることができる。ストレージ・サブシステム１０４は、直接アクセス・ストレージ・デバイス、テープ・ストレージ・デバイスなどであるが、これらに限定されることのない、１つまたは複数の大容量ストレージ・デバイス１０８を使用して、データの格納および取り出しを行う。

ハードウェアのコストが下がったため、データ・ストレージ・システム１００は、冗長ハードウェアおよびハードウェア・サブシステムを含めることによってさらに複雑になってきた。ハードウェア・コンポーネントは、しばしば障害を受けやすい。したがって、ストレージ・サブシステム１０４は、１つまたは複数のプロセッサ、電子メモリ・デバイス、ホスト・アダプタ、などを含むことができる。

典型的には、冗長ハードウェアを最も生産的に使用するために、ハードウェアは複数の論理ノード間で明確に割り振られるかまたは共有される。論理ノード１１０は、各論理ノード１１０が、他の論理ノード１１０とは独立にオペレーティング・システム（ＯＳ）１１２を実行できるような、ストレージ・サブシステム１０４のコンピューティング・ハードウェア・リソースの割り振りを表す。加えて各論理ノード１１０は、アプリケーション１１４の独立セットを動作させる。論理ノード１１０は、ホスト１０２に対して別の物理コンピューティング・システムとして現れる。

調整モジュール１１６はハイパーバイザ（ＰＨＹＰ）１１６とも呼ばれ、２つまたはそれ以上の画定された論理ノード１１０間での、専用および共有のハードウェア・リソースの使用を調整する。ＰＨＹＰ １１６は、専用プロセッサ上のファームウェアに実装することができる。通常、論理ノード１１０はメモリを共有する。ＰＨＹＰ １１６は、論理ノード１１０がメモリの不適切なセクションにアクセスしないように保証する。

ストレージ・サブシステム１０４を複数の論理ノード１１０内に分離することによって、より高度な信頼性が得られる。ソフトウェアまたはハードウェア問題によって１つの論理ノード１１０にクラッシュ／障害が発生した場合、１つまたは複数の他の論理ノード１１０を使用して、クラッシュした論理ノード１１０によって実行されていたタスクを続行または再開することができる。

複数の論理ノード１１０の管理、制御、およびサービス提供は難題である。いずれの管理、制御、保守、監視、トラブルシューティング、またはサービス・オペレーションも、不断のＩ／Ｏ処理によって調整されるはずであるため、ストレージ・サブシステム１０４の２４時間毎日の可用性が損なわれることはない。通常、管理コンソール１１８は、Ｉ／Ｏチャネルとは分離された制御通信（ここでは「アウト・オブ・バンド通信」と呼ばれる）を介してストレージ・サブシステム１０４を管理する。

ストレージ・サブシステム１０４は、イーサネット・カードなどのアウト・オブ・バンド通信用のネットワーク・アダプタを含むことができる。管理コンソール１１８は、別のＯＳおよび管理アプリケーションのセットを実行するワークステーションなどの、別のコンピュータ・システムを備えることができる。管理コンソール１１８は、管理者がＰＨＹＰ １１６とインターフェースして、論理ノード１１０を開始（作成）、停止、および構成できるようにする。

残念ながら、管理コンソール１１８の管理機能はかなり制限されている。特に、論理ノード１１０は完全に独立し、無関係である。したがって、たとえばストレージ・スペースの割り当てを設定するために複数の論理ノード１１０を管理する場合、管理者は各ノードに別々にログインし、変更を行い、その後ログアウトしなければならない。このプロセスは非常に面倒であり、動作に関連する論理ノード１１０の数が増加するほど、エラーにつながる可能性がある。現在、２つまたはそれ以上の論理ノード１１０を同時に管理する方法はない。ノード１１０は１回に１つずつ、逐次管理される。

信頼性および可用性の特典により、各ノード１１０が他方のノードのすべての動作をアクティブにミラーリングするように、２つまたはそれ以上の論理ノード１１０を関連付けることが望ましい。この様式では、一方のノード１１０に障害／クラッシュが発生した場合、他方のノードが引き継ぎ、Ｉ／Ｏ要求の処理を続行する。また、関連付けられた論理ノード１１０を単一のエンティティとして、または単一の管理ノードからの必要に応じて個々に、まとめて管理することも望ましい。しかしながら、現時点では、論理ノード１１０間には何の関係もなく、複数の論理ノード１１０を一度に同時に管理する方法はない。

ノード１１０がかなり均一であり、名前のように比較的重要でない属性によって構成が異なる可能性のある、ストレージ・サブシステム１０４内では、管理の反復性およびサービスの変化がさらに悪化する。ストレージ機構は、１つまたは複数の一般的に構成されたノード１１０に様々な組み合わせのポリシー、属性、または制約を適用しようとする可能性もある。現時点でこれを実行するには、管理者は、ポリシーを実施および維持できるように、ノード１１０間の類似点および相違点を別々に追跡しなければならない。ノード１１０のサブセットに適用されるいずれのポリシーも、実施および維持するのは困難であり、時間がかかる。

たとえノード１１０が関係付けられていても、管理者は各ノード１１０に別々にログインしなければならず、管理操作を完了するためには、異なる管理コンソール１１８マシンに物理的に移動しなければならない可能性がある。関係ノード１１０は、冗長Ｉ／Ｏ動作を提供する場合がある。しかしながら、関係ノード１１０の管理は困難であり、時間がかかる。それぞれを個別に管理しなければならない多数のノード１１０は、管理者の実効性を制限する。

したがって、本発明は、当分野における前述の欠点の多くまたはすべてを克服する単一の管理モジュールを介して、論理ノードの管理を容易にするための装置、システム、および方法を提供する。

本発明の一態様に従った装置は、構成モジュール、情報モジュール、およびアドレス・モジュールを含む。構成モジュールは、各論理エンティティが他方の論理エンティティの動作をミラーリングし、他方の論理エンティティと直接通信するように、ピア・ツー・ピア領域内で互いに対話するための第１の論理エンティティおよび第２の論理エンティティを構成する。

ピア・ツー・ピア領域は、１つのエンティティによって実行されるＩ／Ｏおよび管理動作が他方のエンティティによって自動的に実行されるように関係付けられた、２つまたはそれ以上の論理エンティティを含むことができる。２つまたはそれ以上の論理エンティティは、それぞれの論理エンティティ専用のハードウェアの冗長性を提供するために関係付けることができる。論理エンティティは、論理ノード、仮想マシン、論理区画（ＬＰＡＲ）、ストレージ機能イメージ（ＳＦＩ）、ストレージ・アプリケーション・イメージ（ＳＡＩ）などに対応することができる。ピア・ツー・ピア領域の論理エンティティは、それぞれ互いに監視および管理するために実質的に同等の権限を有することができる。一実施形態では、ピア・ツー・ピア領域内の第１の論理エンティティおよび第２の論理エンティティが、論理エンティティのうちの１つの障害に応答して他方の論理エンティティの動作を引き継ぐように構成される。動作可能な論理エンティティは、障害が発生した論理エンティティがオフラインになってからの変更のセットをログに記録し、障害が発生した論理エンティティがオンラインに戻るのに応答して変更のセットを復元することができる。

情報モジュールは、第１の論理エンティティのローカル・リソースおよび第２の論理エンティティのローカル・リソースを管理ノードに公開する。ローカル・リソースは、第１の論理エンティティおよび第２の論理エンティティのローカル・リソースが、管理ノードからの管理コマンドのターゲット・リソースとして使用可能なように公開される。情報モジュールは、第１の論理エンティティのローカル・リソースおよび第２の論理エンティティのローカル・リソースを、管理ノードにブロードキャストすることができる。別の方法では、情報モジュールは、第１の論理エンティティのローカル・リソースおよび第２の論理エンティティのローカル・リソースを、管理ノードがアクセス可能な中央リポジトリ内に登録することができる。

管理ノードは、第１の論理エンティティおよび第２の論理エンティティと管理関係にあるものとすることができる。管理関係は、管理ノードが論理エンティティを管理および監視できる管理領域を定義する。しかしながら、論理エンティティは管理ノードを管理または監視することができない。

ある実施形態では、管理領域は、互いにピア・ツー・ピア領域内にある論理エンティティの第１のセットと、互いにピア・ツー・ピア領域内にある論理エンティティの第２のセットとを備える。各論理エンティティのローカル・リソースは、管理コマンドのターゲット・リソースとして使用するために管理ノードに公開することができる。さらに、各セットの論理エンティティは、他方のセットの論理エンティティと通信できない場合がある。管理コマンドは、両方のセット、１つのセット、あるいは、どちらかまたは両方のセットの個々の論理エンティティをターゲットとすることができる。

他の実施形態では、管理領域が、管理ピア・ツー・ピア領域内の管理ノードと対話するように構成された第２の管理ノードを備える。管理ピア・ツー・ピア領域は、いずれかの管理ノードが、管理ノードのうちの１つの障害に応答して管理動作を監視および引き継ぐことを可能にする。

ある実施形態では、同期化モジュールが、第１の論理エンティティまたは第２の論理エンティティによってローカル・リソースに対して行われた修正に応答して、第１の論理エンティティおよび第２の論理エンティティのローカル・リソースを代表するリソース定義を同期化する。

第１の論理エンティティおよび第２の論理エンティティは、共通ハードウェア・プラットフォームの論理区画（ＬＰＡＲ）を備えることができる。ＬＰＡＲは、各ＬＰＡＲが共通ハードウェア・プラットフォームの別々の中央電子複合システム（ＣＥＣ）上で実行するように構成される。第１の論理エンティティおよび第２の論理エンティティは、独立に管理可能なストレージ機能イメージ（ＳＦＩ）を定義することができる。管理モジュールは、管理領域内の複数のＳＦＩに管理コマンドを送信するように構成することができる。別の方法では、または加えて、独立に管理可能なストレージ・アプリケーション・イメージ（ＳＡＩ）内に論理エンティティのペアが定義される。

ストレージ・リソースの編成を通じてストレージ管理を容易にするための動作を実行するように構成されたマシン読み取り可能命令を含む、本発明の信号担持媒体も提示される。一実施形態では、この動作は、各論理エンティティが他方の論理エンティティの動作をミラーリングし、他方の論理エンティティと直接通信するように、ピア・ツー・ピア領域内で互いに対話するために第１の論理エンティティおよび第２の論理エンティティを構成するための動作を含む。他の動作は、第１の論理エンティティおよび第２の論理エンティティのローカル・リソースが、管理ノードからの管理コマンドのターゲット・リソースとして使用可能なように、第１の論理エンティティのローカル・リソースおよび第２の論理エンティティのローカル・リソースを管理ノードに公開する。最後に、管理ノードからの管理コマンドを、第１の論理エンティティのローカル・リソースおよび第２の論理エンティティのローカル・リソースに向けて選択的にアドレッシングするために、動作が実行される。

本発明は、コンポーネントとほぼ同じ機能と、装置および方法に関して上記で説明したステップを含む、システム、方法、および装置として配置構成された、諸実施形態も含む。

したがって、本発明の諸実施形態では、ストレージ管理を容易にするための装置、システム、および方法が提供される。有利なことに、こうした装置、システム、および方法は、必要に応じて単一のエンティティとして、または別個に、２つまたはそれ以上の関係ノードを自動的に管理する。同様に、この装置、システム、および方法は、グループ間のセキュリティは維持されるが、異なるポリシーが容易に実施および維持できるように、関係ノードのグループの管理をサポートする。さらにこの装置、システム、および方法は、たとえば異なるノードのグループに関するストレージ・サブシステムなどの、複数のハードウェア・プラットフォームの管理をサポートする。この装置、システム、および方法は、複数の関係あるいは無関係またはその両方のノードをアクティブに管理するための冗長管理ノードを可能にする。

次に、本発明の諸実施形態について、添付の図面を参照しながら単なる例として説明する。

本発明の例示的実施形態は、全体を通じて同じ部分が同じ数字で指定された図面を参照することによって、最も良く理解されるであろう。以下の説明は単なる例であることが意図され、本明細書に記載された発明と一致するデバイス、システム、およびプロセスのある選択された実施形態を示すものに過ぎない。

図２は、ストレージ管理を容易にする管理ストラクチャ２００の論理的表現を示す図である。ある実施形態では、第１の論理エンティティ２００および第２の論理エンティティ２０４がピア・ツー・ピア関係２０６を共有する。本明細書で使用される場合、「論理エンティティ」とは、関係を共有する２つまたはそれ以上の物（論理的または物理的）を表すための任意の論理構造を指す。したがって、本明細書全体を通じて使用される論理エンティティは、論理ノード、仮想マシン、論理区画（ＬＰＡＲ）、ストレージ機能イメージ（ＳＦＩ、以下でより詳細に考察）、ストレージ・アプリケーション・イメージ（ＳＡＩ、以下でより詳細に考察）などを備えることができる。

ピア・ツー・ピア関係２０６によって関係付けられた論理エンティティのペア２０２、２０４は、有利である。一実施形態では、論理エンティティ２０２、２０４は、ホスト１０２がアクセス可能な複数の論理ストレージ・デバイスを定義するストレージ・エンティティとしての働きをすることができる。言い換えれば、ストレージ・デバイス上のストレージ・スペースを各論理デバイスに割り振り、ホスト１０２が使用するための論理ストレージ・デバイスを提示するように構成することができる。

好ましくは、第１の論理エンティティ２０２は、第２の論理エンティティ２０４とほぼ同じに構成される。各論理エンティティ２０２、２０４は、一方のエンティティ２０２、２０４に障害が発生した場合、他方のエンティティ２０２、２０４がいかなる中断もなくＩ／Ｏ通信の処理をさらに続行することができるように、Ｉ／Ｏ通信をアクティブに処理することができる。論理エンティティ２０２、２０４は、互いに「ホット」（アクティブ）バックアップとして働く。一方の論理エンティティ２０２、２０４または、一方の論理エンティティに障害が発生した場合は他方２０２、２０４を使用する際に、遅延はない。一方の論理エンティティ２０２、２０４の障害にホスト１０２が気付かないことが望ましいため、論理エンティティ２０２、２０４は同じサイズ、パラメータ、および他の属性で構成される。

同様に構成された論理エンティティ２０２、２０４も、エンティティ２０２、２０４がその構成において他のエンティティ２０２、２０４との同期を維持するように、同じコマンドを使用して管理するべきである。本発明は、論理エンティティ２０２、２０４をピア・ツー・ピア領域２０８内に編成する。ピア・ツー・ピア領域２０８は、１つまたは複数のエンティティ２０２、２０４の論理グループ化を表す。各論理エンティティ２０２、２０４は、一方のエンティティ２０２、２０４で実行される動作は、自動的に他方のエンティティ２０２、２０４でも実行されるように、他方の論理エンティティ２０２、２０４と通信している。第２のピア・ツー・ピア領域２１０も、ピア・ツー・ピア関係２０６にある第３の論理エンティティ２１２および第４の論理エンティティ２１４を有するように定義することができる。好ましくは、第１のピア・ツー・ピア領域２０８のメンバは、第２のピア・ツー・ピア領域２１０のメンバへの通信、これらの監視、または制御が阻止されており、その逆もまた同様である。ここでは、ピア・ツー・ピア領域２０８およびローカル・エンティティ２０２、２０４について言及する。当業者であれば、この説明がピア・ツー・ピア領域２１０ならびに第３の論理エンティティ２１２および第４の論理エンティティ２１４にも容易に適用できることを理解されよう。

好ましくは、ピア・ツー・ピア領域２０８は、ピア・ツー・ピア領域２０８の論理エンティティ２０２、２０４の間に直接通信（中継なし）を提供する。もちろん、ピア・ツー・ピア領域２０８は２つより多くの論理エンティティ２０２、２０４を含むことができる。

２つまたはそれ以上の論理エンティティ２０２、２０４をピア・ツー・ピア領域２０８内に配置することにより、通常は、論理エンティティ２０２、２０４から使用可能なリソースの可用性がより高くなる。一方のエンティティ２０２、２０４に障害が発生した場合、他方は動作を続行する。しかしながら前述のように、管理ノード２１６が個々に各論理エンティティ２０２、２０４に接続し、それらを管理する必要があった場合、論理エンティティ２０２、２０４の従来の管理では困難な可能性がある。

本発明では、ピア・ツー・ピア領域２０８のグループ化により、一方のエンティティ２０２、２０４によって実行されるＩ／Ｏ動作および管理動作が他方のエンティティ２０２、２０４上でミラーリングされることが保証される。ある実施形態では、ピア・ツー・ピア領域２０８の第１のメンバ（すなわち、最初にオンラインになったメンバ）がピア・リーダとなる。管理ノード２１６は、ピア・ツー・ピア領域２０８のいずれかのメンバへ、あるいは直接ピア・リーダへ、管理コマンドを送る２１８。エンティティ２０２、２０４がピア・リーダでない場合、コマンドはピア・リーダに転送することができる。ピア・リーダはコマンドを解釈する。ピア・ツー・ピア領域２０８内のすべてのメンバに適用可能であれば、コマンドはすべてのメンバ間でミラーリングされる。この様式では、単一の管理コマンドをピア・ツー・ピア領域２０８内の単一のエンティティ２０２、２０４に発行することが可能であり、ピア・ツー・ピア領域２０８のすべてのメンバに対して変更が行われる。同じく、第２のピア・ツー・ピア領域２１０も同様に動作する。

エンティティ２０２、２０４をピア・ツー・ピア領域２０８内に編成することにより、管理者は、互いに冗長自動バックアップとして働くストレージ・エンティティなどの同様のエンティティをグループ化することができる。管理ノード２１６は必要に応じて各エンティティ２０２、２０４と通信２１８できるが、管理ノード２１６は単一の管理コマンドを単一のエンティティ２０８としてのピア・ツー・ピア領域２０８に向けて送ることもできる。この様式では、管理の負荷／オーバヘッドが削減される。

管理ノード２１６は、１つまたは複数のエンティティ２０２、２０４、２１２、２１４の動作を監視および管理する、物理または論理コンピューティング・デバイスである。好ましくは、管理ノード２１６はアウト・オブ・バンド通信チャネル２１８を使用して、エンティティ２０２、２０４、２１２、２１４との対話および監視を行う。管理ノード２１６と通信２１８するエンティティ２０２、２０４、２１２、２１４は、管理領域２２０を画定する。

管理領域２２０は、少なくとも１つの管理ノード２１６および少なくとも１つの被管理エンティティを備える。管理ノード２１６は状況照会または構成変更などの管理コマンドを、被管理エンティティ２０２、２０４、２１２、２１４に送信する。

ある監視および管理コマンドは、管理ノード２１６が、各エンティティ２０２、２０４に対して定義されたリソース２２２、２２３にアクセスできることを必要とする。本明細書で使用される「リソース」とは、論理エンティティ２０２、２０４、２１２、２１４に対して物理的に割り振られるかまたは論理的に定義された、ファームウェア、ソフトウェア、ハードウェア、および論理エンティティを指す。リソースの例には、物理および論理ストレージ・デバイス、ストレージ・デバイス・コントローラ、Ｉ／Ｏデバイス、Ｉ／Ｏデバイス・ドライバ、メモリ・デバイス、メモリ・コントローラ、プロセッサ、対称型マルチプロセッサ・コントローラ、ファームウェア・デバイス、ファームウェア実行可能コード、オペレーティング・システム、アプリケーション、プロセス、スレッド、オペレーティング・システム・サービス、などが含まれる。

ピア・ツー・ピア領域２０８内の各エンティティ２０２、２０４のリソース２２２、２２３は同じとすることができる。別の方法では、領域２０８、２１０にかかわらず、すべてのエンティティ２０２、２０４、２１２、２１４にまたがるリソース２２２、２２３は、同じであるかまたは異なるとすることができる。図３に関してより詳細に説明するように、本発明は、管理領域２２０内のすべてのエンティティ２０２、２０４、２１２、２１４のリソース２２２、２２３を公開する。管理ノード２１６はリソース２２２、２２３に関する情報を使用して、管理コマンドのターゲットを、ターゲット・リソース２２２、２２３とも呼ばれる特定のリソース２２２、２２３とする。典型的には、ターゲット・リソースは管理コマンドの対象であり、全エンティティ２０２を含むことができる。

図２は、管理領域２２０内のピア・ツー・ピア領域２０８、２１０への、エンティティ２０２、２０４、２１２、２１４の１つの潜在的配置構成を示す図である。もちろん、他の構成も可能である。たとえば、第３の論理エンティティ２１２は、ピア・ツー・ピア領域２０８内に配置し、第１のエンティティ２０２および第２のエンティティ２０４との直接ピア・ツー・ピア関係２０６を有することが可能である。エンティティを管理領域２２０内のピア・ツー・ピア領域２０８、２１０でグループ化することにより、同種の論理エンティティ２０２、２０４のペアを単一のエンティティ（ピア・ツー・ピア領域２０８）として管理できるようになる。さらに編成は、エンティティ２０２、２０４の目的、機能、または地理的場所を含む様々な要素に従って、エンティティ２０２、２０４をグループ化することができる。ピア・ツー・ピア領域２０８、２１０は、セキュリティおよびプライバシーの目的で分けながらも、依然として単一の管理ノード２１６を介して管理することができる。

一実施形態では、第１のエンティティ２０２および第２のエンティティ２０４が、第１のピア・ツー・ピア領域２０８のピア・ツー・ピア関係２０６にある、論理エンティティ２０２、２０４の第１のセットを備える。第３のエンティティ２１２および第４のエンティティ２１４が、第２のピア・ツー・ピア領域２１０のピア・ツー・ピア関係２０６にある、論理エンティティ２１２、２１４の第２のセットを備える。好ましくは、論理エンティティ２０２、２０４の第１のセットと論理エンティティ２１２、２１４の第２のセットとの間には通信が存在しない。論理エンティティ２０２、２０４の第１のセット、論理エンティティ２１２、２１４の第２のセット、および管理ノード２１６はまとめて、管理領域２２０を形成する。管理ノード２１６がいずれかのセットのリソース２２２、２２３をターゲットとする管理コマンドを送信できるように、論理エンティティ２０２、２０４の第１のセットおよび論理エンティティ２１２、２１４の第２のセットのリソース２２２、２２３が管理ノード２１６に公開される。

この様式では、論理エンティティ２０２、２０４の第１のセットおよび論理エンティティ２１２、２１４の第２のセットは互いに分離される。しかしながら、管理ノード２１６は、単一エンティティとしてのセットのうちの１つへ、個々のエンティティへ、または両方のセットにまとめて、管理コマンドを送信することができる。こうした編成は、特に、２つまたはそれ以上のエンティティのセットを単一ユニットとして管理することができるため、柔軟性が与えられる。前述のように、セットのピア・リーダに送信された管理コマンドは、必要に応じて、セットの関係エンティティへと適宜ルーティングされる。管理ノード２１６は、第１セット、第２セット、または、第１セットおよび第２セットの両方へ、コマンドを送信することができる。

たとえば、論理エンティティ２１２、２１４の第２のセット上でサービス・プロシージャが必要な場合、管理ノード２１６は、両方の論理エンティティ２１２、２１４上で自動的に、キューに入れられたＩ／Ｏを処理し、任意の他のＩ／Ｏ通信処理を停止する、単一の静止ストレージ・コマンドを発行することができる。その後、サービス・プロシージャは、論理エンティティ２１２、２１４を（再度単一のコマンドを使用して）オフラインにするなどの、追加の管理コマンドを含むことができる。

前述のように、システムの物理および論理エンティティの冗長性により、コンピューティング・システムに高度な可用性、信頼性、および保守性が提供される。冗長リソース２２２、２２３のユーザが、使用不可のエンティティに気付くことなくリソース２２２、２２３の使用を続行するように、一方の冗長エンティティが使用不可であり、他方が使用可能な場合がある。

一実施形態では、冗長管理ノード２２４は管理ノード２１６の動作をミラーリングする。管理ノード２１６、２２４は、ピア・ツー・ピア関係２０６で対話することができる。管理ノード２１６、２２４はまとめて、管理ノード２１６、２２４のうちの１つの障害に応答して、管理ノード２１６、２２４のいずれかが、複数のピア・ツー・ピア領域２０８、２１０に関する管理動作を監視および引き継げるようにする、管理ピア・ツー・ピア領域２２６を形成する。管理ピア・ツー・ピア領域２２６は、管理ノード２１６、２２４のみを含み、管理ノード２１６、２２４が互いに監視し合い、必要に応じてプロシージャの引継ぎを実施できるようにする。この様式では、システムの信頼性、保守性、および可用性をさらに向上させるために、冗長管理を提供することができる。

図３は、ストレージ管理を容易にするための装置３００の一実施形態を示す図である。装置３００は、コンピュータ・システム管理者が、ユニバーサル領域３０６内に定義されたその他の形で解体（disorganize）された複数のエンティティ３０２および管理ノード３０４に対して、編成および配列（order）を適用できるようにする。編成の必要性および物理ハードウェアに応じて、ユニバーサル領域３０６内のエンティティの数は２つから数百の範囲内とすることができる。エンティティ３０２またはそのリソース２２２、２２３を管理コマンドの宛先またはターゲットとして識別することは、いくつかの編成形式なしでは困難な場合がある。編成が冗長同種エンティティの実装を希望する場合、問題はさらに複雑である。本発明の装置３００は、いくつかの配列および編成を実施し、特に相互のミラーリングおよびバックアップすることが意図されたエンティティについて、管理を容易化および自動化するために、エンティティ間通信に関する一定の規則を遵守させる。したがって、異なる論理エンティティに対処する重複管理コマンドの必要性が少なくなる。加えて、配列および編成が、２つまたはそれ以上の同様に構成されたエンティティ３０２間の区別を容易にする。

装置３００は、構成モジュール３０８、情報モジュール３１０、および同期化モジュール３１２を含むことができる。構成モジュール３０８は、第１の論理エンティティ３１４を、ピア・ツー・ピア領域２０８内の第２の論理エンティティ３１６と対話するように構成する。第１の論理エンティティ３１４は、第２の論理エンティティ３１６の動作と直接通信し、これをミラーリングする。言い換えれば、第１の論理エンティティ３１４および第２の論理エンティティ３１６はピア・ツー・ピア関係２０６を有する。

一実施形態のピア・ツー・ピア領域２０８では、論理エンティティ３１４、３１６が互いに監視および管理するために実質的に同等の権限を有する。これにより、論理エンティティ３１４、３１６のいずれかがピア・リーダとして働き、他方の論理エンティティ３１４、３１６に管理コマンドを渡すことができる。したがって、本発明の異なるシステムおよびサブシステムで提供される冗長性を用いれば、単一ポイントの障害は存在しない。好ましくは、各コンポーネントが冗長な対応コンポーネントを有することから、高可用性が提供される。

一実施形態では、論理エンティティ３１４、３１６は、各ＬＰＡＲにコンピュータ・ハードウェア（プロセッサ、メモリ、Ｉ／Ｏ、ストレージ）の独立セットが割り振られた、コンピュータ・システムの論理区画（ＬＰＡＲ）を備える。ピア・ツー・ピア領域２０８は、冗長性が提供されるようにＬＰＡＲのペアを含むことができる。

一実施形態では、構成モジュール３０８は、各論理エンティティが、ピア・ツー・ピア領域２０８内の他の論理エンティティ３１４、３１６の動作のミラーリングおよび管理のみを実行するように、論理制御通信および論理エンティティ３１４、３１６のミラーリングを定義する。たとえば、１つの論理エンティティ３１４、３１６をピア・リーダとして指定することができる。ピア・ツー・ピア領域２０８に送信されたすべての管理コマンドは、ピア・リーダを介してルーティングされる。管理コマンドおよびＩ／Ｏ通信は、必要に応じて各論理エンティティ３１４、３１６にミラーリングすることができる。

情報モジュール３１０は、第１の論理エンティティ３１４および第２の論理エンティティ３１６のローカル・リソース２２２を、管理ノード３１８に公開する。一実施形態では、情報モジュール３１０は、ローカル・リソース２２２を定義する情報を、各管理ノード３１８に関して事前に決定された通信アドレスを使用して、管理領域２２０内の各管理ノード３１８にブロードキャストする。情報モジュール３１０は、ローカル・リソース２２２を定義する初期情報、ならびにローカル・リソース２２２を定義する情報に対して行われた修正を、ブロードキャストすることができる。各管理ノード３１８はこの情報を受け取り、この情報を適切なエンティティ３１４、３１６の識別子に関連付けることができる。

別の方法では、情報モジュール３１０は、論理エンティティ３１４、３１６に関するローカル・リソース２２２を中央リポジトリ３２２に登録する。情報モジュール３１０は、初期情報を登録することができる。その後論理エンティティは、必要に応じて情報に対する更新を登録する。ターゲット・リソース２２２の中央リポジトリ３２２は、ターゲット・リソース２２２が適切な論理エンティティ３１４、３１６に関連付けられたデータベースを備えることができる。別の方法では、中央リポジトリ３２２は、ローカル・リソース２２２を論理エンティティ３１４、３１６に関連付け、管理ノード３１８がアクセス可能な、ファイルまたは任意の他のデータ・ストラクチャを備えることができる。

ある実施形態では、管理ノード３１８は、管理ノードおよび論理エンティティが属性および方法の両方を含むソフトウェア・オブジェクトによって表される、オブジェクト指向フレームワークを使用して、論理エンティティ３１４、３１６を管理する。属性はオブジェクトに関するデータを格納する。方法は、オブジェクトに関する一定の機能を実施するように特別に構成された論理を含む。オブジェクト指向フレームワークは、リソース２２２に関する情報へのアクセスを制御することができる。たとえば管理ノード３１８が許可マネージャの場合、エンティティ３１４、３１６を表すソフトウェア・オブジェクトは、アクセス方法がローカル・リソースに関する情報を報告することを許可できる。言い換えれば、通常は、オブジェクトに関するプライベートな属性あるいは方法またはその両方を構築することになる情報を、管理ノード３１８を表すソフトウェア・オブジェクトが使用できるようにすることが可能である。

同期化モジュール３１２は、ローカル・リソース２２２を表すリソース定義を同期化する。リソース定義は、中央リポジトリ３２２内に格納することができる。同期化モジュール３１２は、論理エンティティ３１４、３１６によって、または管理ノード３１８によって直接、ローカル・リソース２２２に対して修正が実行された後に、リソース定義を同期化する。修正は、構成変更、更新済みバージョン情報、リソース２２２の定義または削除などを含むことができる。ある実施形態では、同期化モジュール３１２あるいはその一部またはそれらの両方が、論理エンティティ３１４、３１６あるいは管理ノード３１８またはその両方に常駐することができる。

一実施形態では、装置３００は、管理ノード３１８に常駐するアドレス・モジュール３２４を含む。ある実施形態では、アドレス・モジュール３２４あるいはその一部またはそれらの両方が、論理エンティティ３１４、３１６あるいは管理ノード３１８またはその両方に常駐することができる。アドレス・モジュール３２４は、管理ノード３１８から論理エンティティ３１４、３１６のローカル・リソース２２２へと、管理コマンドを選択的にアドレッシングする。前述のように、および本明細書で使用される場合、ローカル・リソース２２２は、論理エンティティ３１４、３１６に関連付けられた様々な物理および論理コンポーネント、あるいはエンティティ３１４、３１６自体を表すことができる。たとえばローカル・リソース２２２は、ルートとしての論理エンティティ、ならびに下層としての様々な論理および物理オブジェクトを有する、リソースの階層を備えることができる。

どのローカル・リソース２２２がアドレッシングされるかは、管理コマンドの性質および意図される作用によって異なる。たとえば、１メガバイトの追加メモリを各論理エンティティ３１４、３１６の論理メモリ・デバイス「Ｄ」に割り振るなどの、ピア・ツー・ピア領域２０８内のグローバル変更が実行されると想定する。管理コマンドを、論理エンティティ３１４、３１６へ直接アドレッシングすることはできない。その代わりに、各論理エンティティ３１４、３１６の論理メモリ・デバイス「Ｄ」は、管理コマンドを受け取る必要がある場合がある。従来は、別々のコマンドが各論理エンティティ３１４、３１６の論理メモリ・デバイス「Ｄ」に送られることになった。しかしながら、論理エンティティ３１４、３１６が共通のピア・ツー・ピア領域２０８内にあり、それぞれが論理メモリ・デバイス「Ｄ」を有するため、管理ノード３１８は、論理メモリ・デバイス「Ｄ」へとアドレッシングされた単一の管理コマンドを、ピア・リーダに送る。その後ピア・リーダは、管理コマンドをピア・ツー・ピア領域２０８内の他のピアへとリレーする。

当業者であれば、特定のリソース２２２をターゲットとする管理コマンドの送信に使用可能な、様々なアドレッシング技法を理解されよう。たとえばリソース２２２は、リソース２２２、論理エンティティ３１６、およびピア・ツー・ピア領域２０８に関する固有の識別子を含む、固有の識別子と共に登録することができる。本明細書で使用される場合、特定のリソースをターゲットとすること、またはターゲットとされたリソースという言い方は、管理コマンドがその特定のリソース上で働くこと、および管理コマンドを実行するための引数としてリソース２２２をリストすることの、両方を意味する。どちらのインスタンスでも、管理ノード３１８は、リソース２２２を定義する情報を正確に参照できなければならない。

一実施形態では、アドレス・モジュール３２４は、オブジェクト指向メッセージングを使用して、管理コマンドをターゲット・リソース２２２へとアドレッシングする。アドレス・モジュール３２４は、ピア領域２０８のリストを維持することができる。アドレス・モジュール３２４は、特定の論理エンティティ３１４への特定のハードウェア・コマンドなどの管理コマンドを実行できるように、ピア領域２０８のメンバと管理領域２２０のメンバとの間の関連も維持することができる。

アドレス・モジュール３２４は、オブジェクト指向フレームワークを利用して、管理コマンドを所望の論理エンティティ３１４、３１６あるいはローカル・リソース２２２またはその両方へ送信することができる。とりわけ、ピア・ツー・ピア領域２０８は、オブジェクト指向フレームワーク内で固有の名前／識別子によって固有に識別されたソフトウェア・オブジェクトによって表すことができる。領域２０８に対する論理エンティティの関連を参照することにより、アドレス・モジュール３２４は、論理エンティティ３１４を表すソフトウェア・オブジェクトを直接参照することができる。オブジェクト指向フレームワークは、その後、ターゲットとされる管理コマンドを、特定の論理エンティティ３１４あるいはローカル・リソース２２２またはその両方にリレーする。これは、管理ノード３１８がどのようにローカル・リソース２２２をターゲットとすることができるかの一例に過ぎない。

第１の論理エンティティ３１４および第２の論理エンティティ３１６は、管理ノード３１８との管理関係３２６を有する。管理関係３２６は、管理ノード３１８が（管理コマンドを介して）エンティティ３１４、３１６の動作を監視および管理できるようにする。しかしながらエンティティ３１４、３１６は、管理ノード３１８を管理または監視することができない（したがって、単方向の矢印は管理権限を表す）。エンティティ３１４、３１６をまとめて含む管理ノード３１８およびピア・ツー・ピア領域２０８は、管理領域２２０を備える。

図４は、ストレージ管理を容易にするためのシステム４００を実装するのに好適な、システム・ハードウェアを示す図である。前述のように、より安価なハードウェアが単一の物理エンクロージャに組み込まれるにつれて、データ処理システムはより複雑になっていく。その後、ハードウェアは、物理的に、論理的に、または物理および論理区画の組み合わせのいずれかで、複数の論理エンティティ２０２、２０４に区分される（図２を参照）。重複ハードウェアを使用することで、論理エンティティ２０２、２０４などの冗長サブコンポーネントを含めることによって、より高い可用性が可能になる。

ストレージ・サブシステムとして使用するのに好適な一実施形態では、システム４００は、共通ハードウェア・プラットフォーム４０２によって結合された少なくとも２つの物理的に別々の中央電子複合システム（ＣＥＣ）を含む。共通ハードウェア・プラットフォーム４０２は、単純な物理エンクロージャを備えることができる。

ＣＥＣとは、ＰＨＹＰ １１６（図１を参照のこと）などの、共通調整モジュール１１６に接続された物理コンピューティング・デバイスの独立した集まりのことである。ＣＥＣは、プロセッサ複合システム４０４、複数の電子メモリ・デバイス４０６、複数の直接アクセス・ストレージ・デバイス（ＤＡＳＤ）４０８、ホスト・アダプタ４１０などの複数のネットワークＩ／Ｏインターフェース・デバイス４１０、およびネットワーク・アダプタ４１２などの複数の管理インターフェース・デバイス４１２に編成された、複数の対称型マルチプロセッサを含む。ＣＥＣは、独立型電力結合および電力インフラストラクチャ、ならびに換気および冷却システムを含むことができる。各ＣＥＣは、独立に電力循環（power cycle）させることができる。一定のサブシステムは、ＣＥＣの他の部分の性能に影響を与えることなく、電力循環させることまでもが可能である。もちろん、当業者であれば、前述のあるハードウェア・デバイスはサブシステムへの編成が可能であり、本発明には関連しないが、ＣＥＣが複数の論理ノード２０６をサポートできるようにする、様々なコントローラを含むことが可能であることを理解されよう。

一実施形態では、システム４００は第１のＣＥＣ ４１４および第２のＣＥＣ ４１６を含む。好ましくは、第２のＣＥＣ ４１６は、第１のＣＥＣ ４１４とほぼ同じ量、タイプ、ブランド、および構成のハードウェアを含む。共通のハードウェアを有することで、問題が発生した場合のトラブルシューティングに関連する変数（variables）が減少する。一実施形態では、第１のＣＥＣ ４１４および第２のＣＥＣ ４１６を、ネットワーク・アダプタ４１２を介して接続された単一のハードウェア管理コンソール（ＨＭＣ）によって管理および制御することができる。一実施形態では、ＨＭＣ ４１８は、ＬＩＮＵＸオペレーティング・システムおよび好適な管理アプリケーションを実行する、パーソナル・コンピュータなどの専用ハードウェア管理デバイスである。

たとえ単一のＣＥＣ内であっても、ハードウェアのこうした複合システム４００を管理することは、非常に困難な場合があることに留意されたい。したがってＨＭＣ ４１８は、最高水準の可用性が維持できるように、管理者がＣＥＣを処理する際に指針となる複合的なサービスおよび保守のスクリプトおよびルーチンを含む。１つのミスが劇的な結果を招く可能性がある。ある実施形態では、管理論理は複数のリソース・マネージャ内で具体化される。様々なリソース・マネージャは、ＥＳＳの様々なハードウェアおよびソフトウェアのサブシステムの正常性を監視およびチェックする。ソフトウェア・モジュールおよびスクリプトは、問題の診断および修正ならびに予防的保守の実行の際に、サービス技術者およびシステムを指導する。通常、これらのルーチンは、ハードウェア・コンポーネントがオンラインのままで、サブコンポーネントあるいはシステムまたはその両方を適切にシャットダウン（電力循環）する。

図５は、図４のハードウェア・システム４００を示し、ハードウェア上で動作するソフトウェアおよび論理エンティティを含む。システム４００は、共通ハードウェア・プラットフォーム４０２内に第１のＣＥＣ ４１４および第２のＣＥＣ ４１６を含む。一実施形態では、ＣＥＣ ４１４、４１６は完全に独立しており、ストレージ・サブシステム内で動作する。

システム４００は、第１の論理区画（ＬＰＡＲ）５０２、第２のＬＰＡＲ ５０４、第３のＬＰＡＲ ５０６、および第４のＬＰＡＲ ５０８を含む。あるシステム４００は、図に示されたよりも多くのＬＰＡＲを備えることができる。各ＬＰＡＲ ５０２〜５０８は、１つまたは複数のプロセッサ５１０、１つまたは複数のＩ／Ｏチャネル５１２、および永続あるいは非永続またはその両方のメモリ５１４を含む、コンピューティング・リソースの割り振りを含む。あるコンピューティング・ハードウェアは共有され、他のハードウェアは特定のＬＰＡＲ専用とすることができる。本明細書で使用される場合、ＬＰＡＲとは、各ＬＰＡＲが他のＬＰＡＲとは独立のオペレーティング・システムを実行できるような、１つまたは複数のプロセッサ、メモリ、およびＩ／Ｏ通信の管理および割り振りを指す。ＬＰＡＲを記述するために一般的に使用される他の用語には、仮想マシンおよび論理エンティティ２０２、２０４（図２を参照のこと）が含まれる。

一実施形態では、第１のＬＰＡＲ ５０２および第２のＬＰＡＲ ５０４が同種であるため、プロセッサ５１０、Ｉ／Ｏ ５１２、およびメモリ５１４の構成は同一である。同様に、メモリ５１４内で実行するソフトウェアも同種とすることができる。ＬＰＡＲ ５０２、５０４、メモリ５１４はそれぞれ、同じＯＳ ５１６およびリソース・マネージャ５１８を実行することができる。

好ましくは、リソース・マネージャ５１８は、特定のＬＰＡＲ ５０２、５０４に対する管理コマンドを処理するための論理を備える。リソース・マネージャ５１８は、同期化モジュール５２０を含むことができる。同期化モジュール５２０は、図３に関して説明した同期化モジュール３１２とほぼ同じ論理を備えることができる。

一実施形態では、第１のＣＥＣ ４１４上で動作する第１のＬＰＡＲ ５０２が、第２のＣＥＣ ４１６上で動作する第２のＬＰＡＲ ５０４とのピア・ツー・ピア関係５２４で動作する。第１のＬＰＡＲ ５０２および第２のＬＰＡＲ ５０４はまとめて、ストレージ機能イメージ（ＳＦＩ）５２６を定義する。好ましくは、ＳＦＩ ５２６は、図２に関して説明したピア・ツー・ピア領域２０８のグループ化、特徴、および機能にほぼ対応する。ある実施形態では、ピア・ツー・ピア２０８が２つまたはそれ以上のＬＰＡＲ５０２、５０４を有することができる場合、一実施形態では、ＳＦＩ ５２６は２つのＬＰＡＲ ５０２、５０４に限定することができるため、ＳＦＩ ５２６はピア・ツー・ピア領域２０８のサブセットを備えることができる。

ＳＦＩ ５２６は、データの格納および取り出しのための冗長論理リソースを提供する。すべてのデータ・ストレージ処理は、通常、ＬＰＡＲ ５０２とＬＰＡＲ ５０４との間で論理的に分割され、１つのＬＰＡＲが使用不可の場合、残りのＬＰＡＲがすべての作業を処理する。好ましくは、ＳＦＩ ５２６は、第２のＬＰＡＲ ５０４の物理ハードウェアとは完全に独立の、物理ハードウェア上で動作する１つのＬＰＡＲ ５０２を含む。したがって、好ましい実施形態では、ＳＦＩ ５２６はハードウェアの物理区分を有する。この様式では、１つのＣＥＣ ４１６がオフラインまたは物理的に電源オフとなり、ＳＦＩ ５２６をオンラインのままとすることができる。ＣＥＣ ４１６がオンラインに戻ると、第２のＬＰＡＲ ５０４が第１のＬＰＡＲ ５０２と再度一致するように、リソース・マネージャ５１８はメモリ５１４およびストレージを同期化する。

ＳＦＩ ５２６は、さらに論理ストレージ・デバイスに分割することができる。ＳＦＩ ５２６は、論理ストレージ・デバイスを管理するための仮想化ドライバ・ソフトウェアも含むことができる。ＳＦＩ ５２６は、データの格納および取り出しに必要なソフトウェアのみを含む。たとえば、１つのＳＦＩ ５２６が、データの格納および取り出しを可能にするＯＳ内のファイル・システムを備える。

システム４００は、ピア・ツー・ピア関係５２４にある第３のＬＰＡＲ ５０６および第４のＬＰＡＲ ５０８からなる、ストレージ・アプリケーション・イメージ（ＳＡＩ）５２８も含むことができる。好ましくは、ＳＡＩ ５２８を定義するＬＰＡＲ ５０６、５０８は、同じＯＳ ５１６および同じリソース・マネージャ５１８を含む。ある実施形態では、ＳＦＩ ５２６のＯＳ ５１６あるいはリソース・マネージャ５１８またはその両方は、ＳＡＩ ５２８のＯＳ ５１６あるいはリソース・マネージャ５１８またはその両方と異なるものとすることができる。ある実施形態では、ＳＡＩ ５２８は、図２に関して説明したピア・ツー・ピア領域２０８のグループ化、特徴、および機能にほぼ対応する。ある実施形態では、ピア・ツー・ピア領域２０８が２つまたはそれ以上のＬＰＡＲ ５０２、５０４を有することが可能な場合、一実施形態では、ＳＡＩ ５２８は２つのＬＰＡＲ ５０２、５０４に限定することが可能であるため、ＳＡＩ ５２８は、ピア・ツー・ピア領域２０８のサブセットを備えることができる。

好ましくは、ピア・ツー・ピア領域２０８、２１０は互いに別々に維持される。複数のピア・ツー・ピア領域２０８、２１０のメンバ間でピア・ツー・ピア関係が望ましい場合、複数のピア・ツー・ピア領域２０８、２１０は、単一のピア・ツー・ピア領域２０８を形成するように組み合わせられる。したがって、２つのＳＦＩ ５２６あるいはＳＡＩ ５２８またはその両方は、互いにピア・ツー・ピア領域２０８内に存在しないことになる。ストレージとの関連において、ストレージ機能イメージはストレージ・アプリケーション・イメージとは異なる目的を処理するため、これが有利な場合がある。言い換えれば、ＳＦＩ ５２６上およびＳＡＩ ５２８上で実行されるＩ／Ｏ動作と管理動作との間には、ほとんど関係がないか、またはまったくない可能性がある。

ＳＡＩ ５２８は、ストレージ・アプリケーションを、ＳＦＩ ５２６の論理および物理ストレージ・デバイス４０８（図４を参照のこと）とは独立に管理可能な、単一の論理ユニットに編成する。ＳＡＩ ５２８は、第３のＬＰＡＲ ５０６および第４のＬＰＡＲ ５０８が互いのデータ処理をミラーリングする場合の冗長性も含む。好ましくは、ＳＦＩ ５２６は、第４のＬＰＡＲ ５０８の物理ハードウェアからは完全に独立した物理ハードウェア上で動作する第３のＬＰＡＲ ５０６を含む。したがって、好ましい実施形態では、ＳＡＩ ５２８はハードウェアの物理区画を備える。この様式では、１つのＣＥＣ ４１６がオフラインまたは物理的に電源オフであり、ＳＡＩ ５２８がオンラインを維持することができる。ＳＡＩ ５２８のストレージ・アプリケーション５３０は、特にデータの格納および取り出しを管理するためのアプリケーションを備える。ストレージ・アプリケーションの例には、ＩＢＭのＴｉｖｏｌｉ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｒ、データベース管理システムなどが含まれる。

管理モジュール５３２は、管理コマンドをＳＦＩ ５２６あるいはＳＡＩ ５２８またはその両方（ピア・ツー・ピア領域）に選択的に送るように構成される。別の方法では、または加えて、管理モジュール５３２は、管理コマンドを必要に応じて個々のＬＰＡＲ ５０２〜５０８に直接送信することができる。ＬＰＡＲ ５０２〜５０８の公開されたローカル・リソース５３３は、管理モジュール５３２が、特定のリソース５３３に管理コマンドを送信すること、あるいは、ある管理コマンドに特定のリソース５３３の引数を含めること、またはその両方を、可能にする。

管理モジュール５３２は、図３に関して説明した構成モジュール３０８、情報モジュール３１０、およびアドレス・モジュール３２４とほぼ同じ機能を含む、構成モジュール５３４、情報モジュール５３６、およびアドレス・モジュール５３８を含む。具体的にいえば、情報モジュール５３６またはそのコンポーネントは、ＳＦＩ ５２６あるいはＳＡＩ ５２８またはその両方のローカル・リソース５３３を定義する情報をブロードキャストすることができる。別の方法として、情報モジュール５３６またはそのコンポーネントは、ＳＦＩ ５２６あるいはＳＡＩ ５２８またはその両方のローカル・リソース５３３を定義する情報を、管理モジュール５３２がアクセス可能なデータベースなどの中央リポジトリに登録することができる。

ある実施形態では、情報モジュール５３６は、定期的ポーリングを通じて、ローカル・リソースを定義する情報をＬＰＡＲ ５０２〜５０８から取り出す。別の方法では、情報モジュール５３６は、ＬＰＡＲ ５０２〜５０８からの信号に基づいて、ローカル・リソースを定義する情報を取り出すことができる。有利なことに、管理モジュール５３２は、単一のＳＦＩ ５２６を表す複数のＬＰＡＲ ５０２、５０４の細部を要約し、各ＬＰＡＲ ５０２、５０４への特定の変更が実行されるという確信をもって、ユーザが管理コマンドを全ＳＦＩ ５２６にアドレッシングできるようにする。

好ましくは、管理モジュール５３２は、管理コマンドをＳＦＩ ５２６およびＳＡＩ ５２８へ、ならびに管理モジュール５３２およびＬＰＡＲ ５０２〜５０８を論理的にリンクする管理サブシステム５４０を介して、ＬＰＡＲ ５０２〜５０８へと送る。本発明に従って修正可能なサブシステムの一例が、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシンズ・コーポレーション（ＩＢＭ）から入手可能な、リソース監視および制御（ＲＭＣ）サブシステムである。当業者であれば、本発明をサポートする管理サブシステム５４０が、その起源である従来のＲＭＣサブシステムと同じでないことを理解されよう。

ＲＭＣベースの管理サブシステム５４０は、典型的にはＡＩＸなどのオペレーティング・システムに組み込まれた機能モジュールである。もちろん、管理サブシステム５４０は、ＬＩＮＵＸ、ＵＮＩＸ、Ｗｉｎｄｏｗｓ、などを含む他のオペレーティング・システムでも実施可能である。管理サブシステム５４０の補足コンポーネントは、管理モジュール５３２およびＬＰＡＲ ５０２〜５０８の両方に常駐することができる。

管理サブシステム５４０は、ディスク・スペース、プロセッサ使用率、デバイス・ドライバ、アダプタ・カード状況などのリソースを監視する。管理サブシステム５４０は、事前に定義された条件に応答してアクションを実行するように設計される。しかしながら、従来のＲＭＣは、ピア・ツー・ピア領域２０８（ＳＦＩ ５２６またはＳＡＩ ５２８）内のＬＰＡＲ ５０２〜５０８のペアと同時にインターフェースすることはできない。その代わりに、従来のＲＭＣサブシステムは、１回に１つのＬＰＡＲと通信する。

本発明のある実施形態では、ピア・ツー・ピア領域２０８内での管理および監視を可能にすること、ならびにＬＰＡＲが他のピア・ツー・ピア領域２０８内のＬＰＡＲを管理または監視できないようにすること、が実行可能な、修正済み管理サブシステム５４０を作成するように、従来のＲＭＣサブシステムが拡張および修正される。修正済み管理サブシステム５４０は、管理モジュール５３２などの管理ノードが、２つまたはそれ以上のピア・ツー・ピア領域２０８、２１０を管理できるようにすることもできる。

修正済み管理サブシステム５４０は、１つまたは複数のＬＰＡＲ ５０２〜５０８の各管理可能リソースを表すオブジェクトを備える、オブジェクト・モデルを含むことができる。オブジェクトとは、物理および論理リソースの特徴および属性の代表である。オブジェクトは、通信アドレス、バージョン情報、特徴情報、互換性情報、動作状況情報、などの情報を格納することができる。

管理サブシステム５４０は、リソース・マネージャ５１８のセットをさらに含む。一実施形態におけるリソース・マネージャ５１８は、管理コマンドを解釈し、オブジェクト・モデル内に定義されたリソース５３３に適用する。ある実施形態では、リソース・マネージャ５１８は、各ＬＰＡＲ ５０２〜５０８上で実行している既存のＲＭＣモジュールのソフトウェア拡張である。リソース・マネージャ５１８は、オブジェクト指向ＲＭＣモジュールまたはプロシージャ的に設計されたＲＭＣモジュールを拡張することができる。

ある実施形態では、管理モジュール５３２が、複数のＳＦＩ ５２６、ＳＡＩ ５２８、およびそれらの中に定義された関連付けられたＬＰＡＲ ５０２〜５０８に関する管理の中心点として働く。管理モジュール５３２は、アウト・オブ・バンド通信ネットワークを介して複数のハードウェア・プラットフォーム５４２へと結合することができる。管理モジュール５３２は、好ましくは１つまたは複数の管理コマンドを、複数のプラットフォーム５４２をまたがって分散されたＳＦＩ ５２６およびＳＡＩ ５２８へと送信するように構成される。さらに、各ＳＦＩ ５２６あるいはＳＡＩ ５２８またはその両方は、異なるＯＳ ５１６あるいはアプリケーション５３０のセットまたはその両方を備えることができる。ＳＦＩ ５２６あるいはＳＡＩ ５２８またはその両方は、地形、または共通目的の機能、あるいは他の特徴に従って、共通管理領域５４４内に編成することができる。管理領域５４４は、複数のハードウェア・プラットフォーム５４２を含むことができることに留意されたい。管理モジュール５３２は、ＳＦＩ ５２６、ＳＡＩ ５２８、またはＳＦＩ ５２６およびＳＡＩ ５２８の組み合わせを含む、ピア・ツー・ピア領域２０８、２１０を選択するために、コマンドを発行することができる。

さらに図５を参照すると、管理サブシステム５４０およびリソース・マネージャ５１８は、好ましくは、ＬＰＡＲ ５０２、５０４のうちの１つの障害に応答して、第１のＬＰＡＲ ５０２が第２のＬＰＡＲ ５０４の動作を引き継ぐことになる、ならびにその逆もまた同様になるように、構成される。ピア・ツー・ピア領域２０８は、各ＬＰＡＲ ５０２、５０４が他方の動作をミラーリングするように通信チャネルを提供することによって、これを可能にする。ある実施形態では、ピア・ツー・ピア領域２０８の１つのＬＰＡＲ ５０２、５０４に障害が発生した場合、管理サブシステム５４０は、障害が発生したＬＰＡＲがオフラインになった後に障害の発生していないＬＰＡＲ上で行われた変更のセットをログに記録することができる。加えて、管理サブシステム５４０は、障害が発生したＬＰＡＲがオンラインに戻ってきた場合、アクティブなＬＰＡＲのリソース・マネージャ５１８が変更のセットを復元するのを支援することができる。

ピア・ツー・ピア領域２０８は、各ＬＰＡＲ ５０２、５０４が他方をモニタリングできるようにする。したがってＬＰＡＲ ５０２、５０４は、他方のＬＰＡＲがオフラインになるなどのエラー条件を有することを検出する、論理を含むことができる。エラー条件が検出されると、ログ記録を開始することができる。ＬＰＡＲがオンラインに戻り、変更のセットの復元をトリガすると、同じモニタが信号を発信することができる。この様式では、ホスト１０２がピア・ツー・ピア領域２０８全体（あるいはＳＦＩ ５２６またはＳＡＩ ５２８）を利用可能な状態が維持されるような、リアルタイムの冗長性が提供される。

図６は、一実施形態に従った、ストレージ・リソースの編成を通じてストレージを容易にするための方法６００を示す流れ図である。方法６００は、管理者が、管理領域２２０内で、論理エンティティ２０２、２０４、２１２、２１４および管理ノード２１６、２２４を１つまたは複数のピア・ツー・ピア領域２０８、２１０に編成する（図２を参照のこと）ことを望むと、開始される６０２。たとえば管理者は、一方のＬＰＡＲが他方のＬＰＡＲに関する冗長アクティブ・バックアップであるように、ＬＰＡＲのペアをＳＦＩ ５２６などのピア・ツー・ピア領域２０８内に編成することができる。加えて、管理者は、単一の管理ノード２１６から、複数のハードウェア・プラットフォーム５４２をまたがって、複数のＳＦＩ ５２６を制御および管理することを望む場合がある。１つまたは複数のピア・ツー・ピア領域２０８、２１０を管理領域２２０内で編成することにより、ピア・ツー・ピア領域２０８、２１０のリソースまたはピア・ツー・ピア領域２０８内のＬＰＡＲを、単一の管理コマンドでアドレッシングすることができる。

最初に管理者は、各論理エンティティ２０２、２０４が他方の動作をミラーリングするように、２つまたはそれ以上の論理エンティティ２０２、２０４をピア・ツー・ピア領域２０８内に構成する６０４。通常、これは、各論理エンティティ２０２、２０４がピア・ツー・ピア領域２０８内のあらゆる他の論理エンティティ２０２、２０４と直接通信するように、２つまたはそれ以上の論理エンティティ２０２、２０４間にある通信チャネルおよびプロトコルが確立されることを意味する。好ましくは、論理エンティティ２０２、２０４を論理的にリンクするために、専用管理チャネルが使用される。

次に、情報モジュール３１０は、単一の管理領域２２０の１つまたは複数のピア・ツー・ピア領域２０８、２１０内の各論理エンティティ３１４、３１６のローカル・リソース２２２を公開する６０６。前述のように、ローカル・リソース２２２を管理コマンドにおけるターゲット・リソース３２２として使用できるように、管理ノード３１８にローカル・リソース２２２について伝える際に使用可能な、様々な技法がある。加えて、情報モジュールは他の管理サブシステムと協働して、ローカル・リソース２２２が更新および修正された場合に、ターゲット・リソース３２２を維持することができる。

次に、管理ノード３１８によって管理コマンドが発行された場合、アドレス・モジュール３２４は、ピア・ツー・ピア領域２０８に関連付けられたローカル・リソース２２２に向けて、管理コマンドを選択的にアドレッシングする６０８。別の方法では、アドレス・モジュール３２４は、ピア・ツー・ピア領域２０８の第２の論理エンティティ３１４または第２の論理エンティティ３１６へ、管理コマンドをアドレッシングする６０８。管理コマンドがどのリソース２２２に向けて送られるかは、部分的に、管理コマンドのタイプに依存する。高水準の（ハードウェア・デバイスに関係付けられていないことを意味する）管理コマンドは、エンティティ３１４、３１６間で共通のリソース２２２のペアに送信することができる。低水準の（ハードウェア・デバイスに関係付けられていることを意味する）管理コマンドは、特定のエンティティ３１４、３１６の特定のリソース２２２に送信することができる。様々なアドレッシング技法が使用可能である。

次に、論理エンティティ３１４またはＬＰＡＲ ５０２がオフラインであるかどうかが判別される６１０。ＬＰＡＲ ５０２をサービスまたはトラブルシューティングのために肯定的にオフラインとするか、あるいはＬＰＡＲ ５０２がエラー条件によって非自発的にオフラインになる場合がある。ＬＰＡＲ ５０２がオフランの場合、ピア・ツー・ピア領域２０８を定義する論理（すなわちエンティティ３１４、３１６上で実行しているログ記録モジュール）は、ピア・ツー・ピア領域２０８の１つまたは複数のオンラインＬＰＡＲ ５０４に対して実行された変更のセットの、ログ記録を開始する６１２。オフラインＬＰＡＲ ５０２がオンラインに戻ると、ログ記録された変更のセットをＬＰＡＲ ５０２に適用することによって、論理はＬＰＡＲ ５０２を復元することができる。通常、オンラインのままのＬＰＡＲ ５０４が、復元されたＬＰＡＲ ５０２への更新の適用を実行する。

論理エンティティ３１４、３１６、またはＬＰＡＲ ５０２、５０４のいずれもオフラインでない場合、管理領域２２０の論理エンティティ３１４、３１６に対して複数の管理コマンドが保留となっているかどうかが判別される６１４。保留となっている場合、方法６００は、次の管理コマンドをアドレッシングする６０８ために戻る。保留となっていない場合、方法６００は終了する６１６。

当業者であれば、本発明によって提供される潜在的な特典を即時に理解されよう。ＳＦＩ ５２６およびＳＡＩ ５２８（ピア・ツー・ピア領域２０８全体）を個別に管理する機能、あるいは個々のＬＰＡＲ ５０２〜５０８を管理する機能、またはその両方の機能が、管理者の時間を大幅に節約し、エラーおよび誤りの可能性を大幅に削減する。加えて、複数の管理ノード２１６、２２４を、管理ピア・ツー・ピア領域２２６内で関係付けることができる。論理エンティティ２０２と同様に、管理ノード２１６、２２４は、一方に障害が発生した場合に、障害の発生した管理ノード２１６がオフのままで他方が管理コマンドのセットの実施を続行できるように、互いに監視および管理することができる。したがって、本発明により、ＳＦＩ ５２６およびＳＡＩ ５２８の形成に関係付けることが可能な論理エンティティの管理が改善される。本発明は、ＬＰＡＲレベルおよび管理ノード・レベルでの冗長性を提供する。最終的に本発明は、典型的には冗長性の目的で同様に構成された論理エンティティに関する管理上の負担を軽減する。

本発明は、その不可欠な特徴から逸脱することなく、他の特定の形で具体化することが可能である。説明された諸実施形態は、すべての点において、限定的ではなく単に例示的であるとみなされるべきである。したがって本発明の範囲は、前述の説明ではなく添付の特許請求の範囲によって示される。特許請求の範囲の意味および等価性の範囲内にあるすべての変更は、その範囲内に包含されるものとする。

本明細書で説明された多くの機能単位は、それらの実施の非依存性を特に強調するために、モジュールとしてラベル付けしてきた。たとえばモジュールは、カスタムＶＬＳＩ回路またはゲート・アレイ、論理チップなどの既製の半導体、トランジスタ、または他の離散的コンポーネントを備える、ハードウェア回路として実施することができる。モジュールは、フィールド・プログラム可能ゲート・アレイ、プログラム可能アレイ論理、プログラム可能論理デバイスなどの、プログラム可能ハードウェア・デバイス内で実施することもできる。

モジュールは、様々なタイプのプロセッサによって実行されるソフトウェアでも実施可能である。たとえば、実行可能コードの識別されたモジュールは、たとえばオブジェクト、プロシージャ、関数、または他の構成として編成可能な、コンピュータ命令の１つまたは複数の物理または論理ブロックを含む。それにもかかわらず、識別されたモジュールの実行可能コードは、物理的にまとめて配置する必要はないが、論理的に一緒に結合された場合、モジュールを含み、モジュールに関して規定された目的を達成する、異なる場所に格納された異種命令を含むことができる。

実際、実行可能コードのモジュールは、単一の命令または多くの命令とすることが可能であり、いくつかの異なるコード・セグメントにわたって、異なるプログラム間で、およびいくつかのメモリ・デバイスにまたがって、分散することも可能である。同様に、運用（operational）データは、本明細書ではモジュール内に識別および図示することが可能であり、任意の好適な形で具体化することおよび任意の好適なタイプのデータ構造内で編成することが可能である。運用データは、単一のデータ・セットとしてまとめることが可能であるか、または異なるストレージ・デバイスにわたることを含む、異なる場所にわたって分散することが可能であり、さらに、少なくとも部分的に、システムまたはネットワーク上の単なる電子信号として存在することが可能である。

本明細書全体を通じて、「選択実施形態」、「一実施形態」、または「実施形態」という言い方は、その実施形態に関連して説明された特定の機能、構造、または特徴が、本発明の少なくとも一実施形態に含まれることを意味する。したがって、本明細書全体を通じて、様々な箇所で「選択実施形態」、「一実施形態では」、または「実施形態では」という句が出現する場合、すべてが同じ実施形態を言い表すとは限らない。

さらに、説明された機能、構造、または特徴は、１つまたは複数の実施形態において任意の好適な方法で組み合わせることが可能である。以下の説明では、本発明の諸実施形態を完全に理解するために、プログラミング、ソフトウェア・モジュール、ユーザ選択、ユーザ・インターフェース、ネットワーク・トランザクション、データベース照会、データベース・ストラクチャ、ハードウェア・モジュール、ハードウェア回路、ハードウェア・チップなどの例など、多数の特定の細部が提供される。しかしながら当業者であれば、本発明が、１つまたは複数の特定の細部なしに、または他の方法、コンポーネント、材料などを使用して、実施可能であることを理解されよう。他のインスタンスでは、周知のストラクチャ、材料、または動作については、本発明の諸態様を不明瞭にすることを避けるために、詳細には図示または説明していない。

複数の無関係な独立した論理ノードを管理する、従来システムを示すブロック図である。 本発明の実施形態に従った、ストレージ・リソースの編成を通じてストレージ管理を容易にするためのエンティティの編成を示す論理ブロック図である。 本発明の任意の実施形態に従った、ストレージ・リソースの編成を通じてストレージ管理を容易にするための装置の一実施形態を示す論理ブロック図である。 本発明のある実施形態を実装するために好適な代表的システムを示す、概略ブロック図である。 本発明の一実施形態に従った、図４に示されたシステム・コンポーネントを利用するエンティティの論理的表現を示す概略ブロック図である。 ストレージ・リソースの編成を通じてストレージ管理を容易にするための方法を示す、概略流れ図である。

Claims (29)

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. 前記第１の論理エンティティの前記ローカル・リソースおよび前記第２の論理エンティティの前記ローカル・リソースを、前記管理ノードにブロードキャストするステップをさらに公開する、請求項２１に記載の方法。
27. 前記第１の論理エンティティの前記ローカル・リソースおよび前記第２の論理エンティティの前記ローカル・リソースを、前記管理ノードがアクセス可能な中央リポジトリに登録するステップをさらに公開する、請求項２１に記載の方法。
28. 前記第１の論理エンティティまたは前記第２の論理エンティティによって実行される前記ローカル・リソースに対する修正に応答して、前記第１の論理エンティティの前記ローカル・リソースおよび前記第２の論理エンティティの前記ローカル・リソースを代表するリソース定義を同期化するステップをさらに含む、請求項２１に記載の方法。
29. 請求項２１から請求項２８のうちのいずれか一項に記載の前記方法のすべてのステップを実行するためのコンピュータ実行可能命令を含む、コンピュータ・プログラム。

Images