JP4508554B2 - 複製ボリュームを管理するための方法と装置 - Google Patents

Description

【発明の属する技術分野】
【０００１】
本発明はデータ記憶システムに係わり、特にデータ記憶システムにおける複製（「ミラー」）ボリュームの管理に関する。
【従来の技術】
【０００２】
企業におけるデータプロセシングシステムでは、大量のデータ記憶装置を必要とするのが普通である。顧客データや企業内部でユーザにより作られたデータが、このデータ記憶装置の大変大きな部分を占めている。このようなデータの損失あるいは損傷は破滅的であって、ビジネスの成功に厳しい衝撃を与える。確固としたデータプロセシングシステムは、このような損失を防止するためにデータのバックアップコピーを提供する。さらにデータを保護するために、いくつかのデータプロセシングシステムは、バックアップコピーを作るという作業を発展させて、災害リカバリーを提供している。
【０００３】
災害リカバリーシステムでは、データのバックアップコピーはプライマリ記憶装置の設置場所（データの性格、すなわち記憶されているプロダクションデータなどを反映するために、時々は「プロダクション」記憶装置の場所などで呼ばれる）からは遠方のサイトに保持される。もし災害がプライマリ記憶装置の設置場所に発生すると、データは、リモートサイトにあるバックアップコピーから回復される。
【０００４】
災害からの保護の既知の方法は、リモート記憶サイトにプライマリ記憶データをミラーするか、シャドーすることである。リモート二重コピーあるいはリモートデータ二重化は、このデータミラーリングソリューションの一形式である。リモート二重コピーにおいては、データプロセシングシステムに、リモート記憶デバイスが設定され、プライマリデータのコピーがリモート記憶デバイスに書き込まれる。
【０００５】
記憶デバイスは相互に結合されて二重化ペアを形成し、各二重化ペアはプライマリ記憶デバイスとセカンダリ記憶デバイスで構成される。 データがプロダクションボリューム（「プライマリ記憶デバイス」とも呼ばれる）に書き込まれると、データプロセシングシステムは、自動的にデータをミラーボリューム（または「セカンダリ記憶デバイス」）にコピーする。ミラーボリュームは、プロダクションボリュームの正確な物理イメージあるいはミラーを持つ。一般には、プロダクションボリュームとミラーボリュームは、プロダクションボリュームと同じように構成されフォーマットされた、同じ物理的な形態を持っている。
【０００６】
ミラーボリュームがプライマリボリュームと共にローカルに置かれている、「ローカル」ミラーリングが、バックアップやリカバリーのために用いられることは注目に値する。一般には、ローカルミラーリングは、バックアップやリカバリーのために用いられ、リモートミラーリングは、災害リカバリーのために用いられる。
【０００７】
従来のテープによるバックアップと比較すると、ローカルミラーリングはずっと高速だが、しかしながらより高価である。
【０００８】
企業におけるデータ記憶装置の容量が増大するに従い、記憶装置の管理業務がより複雑に、そしてより難しくなってくる。記憶システムに、新しいボリュームを定義する（または割り当てる）ことは、企業のデータの需要に追随するために、記憶装置の管理にとって最重要業務の一つである。データ記憶システムが増大すると、プライマリ（「プロダクション」）記憶ボリュームやバックアップミラーボリュームを管理するデータ記憶マネージャサブシステムの複雑さも増大する。しかしながら、大型のデータ記憶装置では、ミラーするボリュームを選ぶのがかなり難しい。理由は次のとおりである。
１．候補のミラーボリュームは使用中であってはならない。
２．候補のミラーボリュームは、適正に選択されるべきである、たとえば、
（１） 候補のボリュームは、ミラーされるプロダクションボリュームと同じ物理ディスクにあってはいけない。もし物理ディスクが障害を起こすと、プロダクションボリュームとミラーボリュームの双方が失われる。
（２） 候補のボリュームは、ミラーされるプロダクションボリュームを構成する物理ディスクと同等の性能と信頼特性を持つ物理ディスク内であるべきである。
（３） （２）は基本ルールであって、デフォルトとして適用されるべきであるが、候補のボリュームの性能と信頼性は、ユーザによって選択されるべきである。
（４） 候補のボリュームを負荷の重い物理ディスクで構成すべきでない。たとえば、もし物理ディスクがプロダクションボリュームとして割り当てられたボリュームを含む場合は、このようなディスクはミラーボリュームとして割り当てるべきではない。
【０００９】
ユーザがミラー用のボリュームを見付けた後は、ユーザは「ミラー生成」と呼ばれる操作を行わなければならない。換言すれば、ユーザはプライマリボリュームとミラーボリュームとの間のミラーリング動作を開始しなければならない。これは、たとえば、次のようなコマンドを入力するか、あるいは他の方法で指定することにより、コマンドラインインターフェイスで実行される。すなわち、ｃｒｅａｔｅｍｉｒｒｏｒ ｖｏｌ１ ｖｏ１２ここで、Ｖｏｌ１はプロダクションボリュームであり、Ｖｏｌ２はそのミラーボリュームである。
【００１０】
もしユーザが多くのミラーを生成する必要がある場合は、上記のコマンドをタイプするために時間がかかる。たとえば、現実の世界の設定では、数百ギガバイト以上の記憶容量を消費するデータベースは普通であり、イメージとかビデオのデータベースはテラバイトのオーダーの記憶容量を消費する。一般的にこのような大型の記憶装置を利用するには、プロダクションボリュームの数十倍あるいは数百倍の容量が必要になる。たとえば、５０個のボリュームの構成は、次の５０個のコマンドの入力が必要になる。
【００１１】
ｃｒｅａｔｅｍｉｒｒｏｒ ｖｏｌ１ ｖｏｌ２
ｃｒｅａｔｅｍｉｒｒｏｒ ｖｏｌ３ ｖｏｌ４
ｃｒｅａｔｅｍｉｒｒｏｒ ｖｏｌ５ ｖｏｌ６
ｃｒｅａｔｅｍｉｒｒｏｒ ｖｏｌ９９ ｖｏｌ１００
【発明が解決しようとする課題】
【００１２】
大きな連携データオブジェクト（「アプリケーションオブジェクト」、「データセット」など）を持つアプリケーションは、ミラーリング技術から恩恵を受ける。アプリケーションの一つは、連想データオブジェクトが大型データベースの複数のボリュームに展開しているデータベースアプリケーションである。たとえば、データベースのインスタンス（たとえば、オラクルのデータベース）のようなデータオブジェクトは、多くのプライマリボリュームにまたがって展開された、複数のデータファイルで構成されている場合がある。データの回復を確実にするため、データオブジェクトを集合的に記憶しているプライマリボリュームは、ミラーされる必要がある。データベースアプリケーションはデータベースの多くのインスタンスを定義出来るので、システム管理上の観点からは、データベースの特定のインスタンスを記憶するこれらの物理ボリュームのみをミラー出来るようにするのが望ましい。
【００１３】
ベリタスソフトウエア株式会社で製造、販売しているＶｘＶＭのような、時々、論理ボリュームマネージャＬＶＭ（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ Ｍａｎａｇｅｒ）と呼ばれる、もうひとつのアプリケーションは、物理プライマリボリュームの潜在的で一般的には異なる集まりの論理的な視界をユーザに提供する。重ねてであるが、エラー回復は、プライマリボリュームのミラーリングにより可能になる。複数の論理ボリュームがプライマリボリューム上で定義出来るので、特定の論理ボリュームを構成するこれらのプライマリボリュームだけをミラーするように出来ることが望ましい。したがって、このタイプのソフトウエアについては、「データオブジェクト」は、ユーザに提供される論理ボリュームであると考えられる。
【００１４】
米国特許５，４５９，８５７と５，５４４，３４７は、リモートミラーリング技術を開示している。離れた場所にある二つのディスクシステムは、リモートリンクで接続されている。ペアの生成が指示されると、ローカルディスクシステムはローカルディスクにあるデータをコピーする。ホストがディスクにあるデータを更新すると、ローカルディスクシステムは、リモートリンク経由でそのデータをリモートディスクシステムに転送する。このように、二つのボリュームのミラーを維持するのに、ホストの動作は不要である。
【００１５】
米国特許５，９３３，６５３は、ローカルディスクシステムとリモートディスクシステム間のデータ転送方法のタイプについて開示している。同期モードの転送に於いては、ローカルディスクシステムは、ホストからの書き込みリクエストを完了する前に、リモートディスクシステムにデータを転送する。半同期モードに於いては、ローカルディスクシステムは、書き込みリクエストを完了してから、次にリモートディスクシステムに書き込みデータを転送する。前のデータ転送が完了するまで次の書き込みリクエストは処理されない。適応コピーモードでは、リモートディスクシステムへの待ちデータはメモリーに記憶され、ローカルディスクシステム及び／あるいはリモートリンクがコピー作業のために利用出来るようになると、リモートディスクシステムに転送される。
【課題を解決するための手段】
【００１６】
本発明に対応する実施例は、ボリュームプールを提供する方法と装置を含むものである。ユーザ指定のプライマリ（プロダクション）ボリュームのミラーリングを行うために、ボリュームプールから１個ないしはそれ以上のミラーボリュームが選択される。特定のミラーボリュームは、人手によるユーザ、または機械によるユーザのいずれであっても、ユーザによっては指定されない。
【発明の実施の形態】
【００１７】
図１は、本発明に対応する、データ記憶システム１０におけるボリュームプールを管理するデータ記憶管理システムの実施例を説明する高レベルブロックダイアグラムである。ボリュームプールマネージメント（ＶＰＭ）サーバ１００は、ＶＰＭエンジン１０１を有し、そしてＶＰＭテーブル１０２とシステムコンフィギュレーションテーブル１０３を含む各種の情報を記憶している。図１に示す実施例では、ＶＰＭユーザインターフェイス１２１がクライアントマシン１２０に設けられている。適応するＩ／Ｏデバイス１２３が、ＶＰＭユーザインターフェイスにインフォメーションチャンネルを提供している。クライアントマシンは、たとえばＴＣＰ／ＩＰネットワーク標準のような、適応したコミュニケーションチャンネルを経由してサーバと通信状態にあることが示されている。
【００１８】
ＶＰＭサーバ１００は、適切に構成されたサーバマシーンであり得る。一般に、サーバはコンピュータ装置であって、ＣＰＵ（または複数ＣＰＵ構成）、ダイナミックメモリー、大容量記憶機能、その他の適当なハードウエアコンポーネントなどの通常のコンポーネント有している。別の形としては、サーバマシーンは、分散型コンピュータアーキテクチャを有することができる。また、予期されるシステム負荷、性能基準などのファクターによっては、他の既知のアーキテクチャが適当かもしれない。
【００１９】
ＶＰＭサーバ１００上で実行するソフトウエアコンポーネントは、ＵＮＩＸ ＯＳのようなサーバに適したオペレーティングシステムおよび本発明に応じて各種の機能を集合的に提供するアプリケーションソフトウエアコンポーネントを含むことができる。ソフトウエアコンポーネントは、高級プログラミング言語のソースコードからコンパイルされたマシンコードで構成されるソフトウエアモジュールを含むことも可能である。ソフトウエアモジュールは、たとえばＵＮＩＸのシェルスクリプトなどのインタープリタコードであっても良い。
【００２０】
クライアントマシン１２０は、同様に、適当なコンピュータマシンであって良い。ＶＰＭユーザインターフェイス１２１は、外部環境とデータ記憶システム１０との間のボリュームプールマネージメントに関連する情報を交換するための経路を提供する。ＶＰＭユーザインターフェイスは、本発明の機能性を提供する単一のソフトウエアモジュールであって良い。別のものとしては、ＶＰＭユーザインターフェイスは、本発明に対応する機能を共同して提供するコンパイルされたコード、シェルスクリプトなどの集まりであっても良い。
【００２１】
ＶＰＭユーザインターフェイス１２１は、外部環境とデータ記憶システム１０との間でマネージメント関連の情報を交換することを促進する何らかの方法で自らを明らかにすることができる。たとえば、ＶＰＭユーザインターフェイスは、Ｉ／Ｏデバイス１２３としてビデオターミナルデバイス上に設けられた、単純なコマンドラインインターフェイス（ＣＬＩ）であっても良い。
【００２２】
同様に、ＶＰＭユーザインターフェイスは、顧客がデータ記憶装置マネージメントシステムと相互に通信出来るように、各種のグラフィカルな要素を提供する、適当なディスプレーデバイス上に表示されたグラフィカルユーザインターフェイス（ＧＵＩ）であっても良い。
【００２３】
ＣＬＩとＧＵＩの場合には、情報の交換は、一般に外部環境としての人手のユーザになる傾向がある。しかしながら、外部の環境がマシン「ユーザ」であり得ることは、本発明の範囲内のことである。ＶＰＭユーザインターフェイスが他のマシンまたはソフトウエアコンポーネントに機能的に結合するように、適切なマシンインターフェイスが提供可能である。たとえば、アドミニストレーション形式のソフトウエアがＶＰＭユーザインターフェイスと相互に通信が出来るように、適切なアプリケーションプログラミングインターフェイス（ＡＰＩ）を定義することが可能である。マシンインターフェイスの別の例として、Ｉ／Ｏデバイス１２３は、適当なディジタル信号プロトコルあるいはアナログ信号プロトコルを経由して、外部マシンと交信するための、コミュニケーションチャンネルであることも可能である。
【００２４】
データ記憶システム１０はさらに、１ないしはそれ以上のアプリケーションサーバ１１０を含む。これらは、単一のコンピュータ装置と適当なサポートハードウエアで、あるいは複数コンピュータアーキテクチャーで構成されている、ＶＰＭサーバ１００と変わることないサーバであり得る。ＶＰＭサーバとアプリケーションサーバ間のコミュニケーションチャンネル１３０は、既知である多くの在来技術で提供可能である。コミュニケーションチャンネルは、イントラネット接続（たとえばイーサーネット経由で）、及びワイドエリアネットワーク接続等であり得る。
【００２５】
アプリケーションサーバ１１０は、ユーザに各種のサービスを提供する在来型のサーバである。たとえば、大企業で普通にみられるアプリケーションはデータベースアプリケーションである。根底にある物理記憶構造の詳細は抜きで、ユーザに記憶システムの概要を提供し、物理ボリュームと論理ボリューム間のマッピングを提供する、論理ボリュームマネージャであり得る。ビジネスによっては、他のアプリケーションも提供される可能性がある。
【００２６】
１ないしはそれ以上のＶＰＭエージェント１１１が、１ないしはそれ以上のアプリケーションサーバ１１０上で稼働しているアプリケーションについての特定の情報を提供し、そしてこの情報をＶＰＭサーバ１００に伝達する。本発明の一実施例によると、ＶＰＭエージェントとアプリケーションサーバ間の対応は１対１の関係では無い可能性があるが、各アプリケーションサーバに関連したＶＰＭエージェント１１１がある。
【００２７】
関係する情報により、アプリケーションのデータセットの実例が保存されているプライマリボリュームが指定される。データセット（アプリケーションオブジェクトおよびデータオブジェクトとも呼ばれる）は、アプリケーションで定義される「オブジェクト」に関連したこれらのファイルを指す抽象的な概念である。たとえば、データベースアプリケーションにおけるデータベースの例は、「データオブジェクト」または「アプリケーションオブジェクト」であって、一般的には、複数のプライマリボリュームにわたって記憶することが可能な各種のファイルで構成される。他の例として、論理ボリュームマネージメントソフトウエアによりユーザに提供される論理ボリュームは、「データオブジェクト」である。
【００２８】
論理ボリュームは、１ないしはそれ以上のプライマリボリュームにより提供される記憶空間で構成されることもある。ＶＰＭエージェント１１１により提供されるマッピング情報は、関係するデータオブジェクトが保存されているこれらのプライマリボリュームを識別するか、あるいは示す。
【００２９】
各アプリケーションは、それぞれのやり方でマッピング情報を提供することが可能である。たとえば、一般的な多くのアプリケーションは、これ、及びその他のアドミニストレーション形式の情報にアクセスするシステムユーティリティーを持っている。適切に構成されたＶＰＭエージェント１１１は、マッピング情報にアクセスするためにアプリケーションと相互に通信をすることが出来る。他のアプリケーションは、ファイルに記憶されているコンフィギュレーションテーブルにマッピング情報を記憶することもある。この場合は、適切に構成されたＶＰＭエージェントを、ファイルの内容を単純に分析することによって情報を得るように生成することが出来る。
【００３０】
例として、データベースアプリケーションのオラクルは、データベースのインスタンスに対してプライマリボリューム情報を提供することが出来る。したがって、ＶＰＭエージェント１１１は、次のＳＱＬステートメントを発行することによりテーブルスペースの情報を得ることが出来る。すなわち、
【００３１】
ＳＱＬ＞ ＳＥＬＥＣＴ ｔ．ｎａｍｅ "Ｔａｂｌｅｓｐａｃｅ"， ｆ．ｎａｍｅ "Ｄａｔａｆｉｌｅ"
２＞ ＦＲＯＭ ｖ＄ｔａｂｌｅｓｐａｃｅ ｔ， ｖ＄ｄａｔａｆｉｌｅ ｆ
３＞ ＷＨＥＲＥ ｔ．ｔｓ＃ ＝ ｆ．ｔｓ＃
４＞ ＯＲＤＥＲ ＢＹ ｔ．ｎａｍｅ；
Ｔａｂｌｅｓｐａｃｅ Ｄａｔａｆｉｌｅ
【００３２】
次に、オラクルは、プライマリボリューム名を得るために、収集し解析することが出来る、次の情報を返す。
【００３３】
ＳＹＳＴＥＭ ／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿０１．ｆ
ＳＹＳＴＥＭ ／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿０２．ｆ
ＳＹＳＴＥＭ ／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿０３．ｆ
ＴＢＳ＿１／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿１１．ｆ
ＴＢＳ＿１／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿１２．ｆ
ＴＢＳ＿２／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿２１．ｆ
ＴＢＳ＿２／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿２２．ｆ
ＴＢＳ＿２／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿２３．ｆ
ＴＢＳ＿２／ｖｏｂｓ／ｏｒａｃｌｅ／ｄｂｓ／ｔｂｓ＿２４．ｆ
【００３４】
より詳細については、「Ｏｒａｃｌｅ ８ｉ， Ｂａｃｋｕｐ ａｎｄ Ｒｅｃｏｖｅｒｙ Ｇｕｉｄｅ」を参照のこと。
【００３５】
図１の続きであるが、データ記憶システムは、記憶サブシステム１５０も含んでいる。図に示された構成は、従来から数多く用いられてきた記憶システムの構成の一つである。ここでは、各アプリケーションサーバ１１０はそれ自身の記憶サブシステム１５０を持つ。記憶サブシステムは、適当なコミュニケーションチャネル１３０を介してアプリケーションサーバに接続される。これらのコミュニケーションチャネルは、データ転送に適した適当な媒体であり、たとえばファイバーチャンネルプロトコルを用いるファイバーチャンネル、ＳＣＳＩ（スモールコンピュータシステムインターフェイス）プロトコルを用いるＳＣＳＩ、及びＣＫＤプロトコルを用いるＥＳＣＯＮとＦＩＣＯＮは一般的によく知られている例である。図に見られるように、本発明に係わる記憶サブシステムについてのある種の情報は、アプリケーションサーバに関連するＶＰＭエージェント１１１により得ることが出来る。情報の種類についてはさらに論じる。
【００３６】
記憶サブシステム１５０は、一般的にアプリケーションデータを記憶する１台ないしはそれ以上の物理ディスク１５１で構成される。たとえば、本発明の受託者によって製造、販売され、Ｌｉｇｈｔｎｉｎｇ ９９００として知られている記憶システムなどのような記憶システムは、１台ないしはそれ以上の物理ディスクに複数のボリュームを有することができる。このシステムは各々が７２ＧＢの容量の物理ディスク４台で構成され、９ＧＢサイズのボリュームを２４個包含するように構成可能である。本発明では、ディスク１５１は記憶システム１５０の中の物理ディスクを意味し、「ボリューム」は、ディスク１５１から生成され、論理アドレスを定義してホストに見えるように（利用可能に）した論理ボリュームを意味する。
【００３７】
しばし図５を参照していただきたい。この図は、本発明の側面を説明するために適したデータ記憶アーキテクチャの構成の説明である。以上の論議から、如何なるデータ記憶アーキテクチャでも本発明の構成要素に適応が可能であるということが認識される。
【００３８】
論理ボリューム５４０は、アプリケーションへ提供される記憶オブジェクトである。もしボリュームマネージャソフトウエアが使用されている場合は、それはディスクグループ５３０から作られる。ボリュームマネージャソフトウエアは、物理ボリューム５２０からディスクグループ５３０を作り出し、そして論理ボリューム５４０をディスクグループから作る。このようにして、論理ボリューム５４０は、ディスクグループ５３０の薄片のように見ることが出来、ボリュームマネージャソフトウエアが決めるように、１ないしはそれ以上の物理ボリューム５２０の一部で構成することが出来る。もしボリュームマネージャが使用されない場合は、各論理ボリュームは、物理ボリューム５２０と１対１の対応をする。
【００３９】
言及したように、ディスクグループ５３０は、一般的に物理ボリューム５２０のセットで構成される。ボリュームマネージャソフトウエアは、論理ボリューム５４０上のアドレスを物理ボリューム５２０上のアドレスにマップする。通常、このアドレス変換はユーザやアプリケーションでは意識しない。このメカニズムを使用して、ボリュームマネージャは、より高い性能と信頼性のためにストライピングやリダンダンシー、及び管理を容易にするためのボリュームの再構成、の様なボリュームマネージメント機能を提供する。
【００４０】
物理ボリューム５２０は、オペレイティングシステムが認識しアクセスするボリュームである。物理ボリュームを使用可能にするためには、アプリケーションサーバ１１０が物理ボリュームにアクセス可能になるように、アドレスを物理ボリュームと関連づけなければならない。アドレスが付けられた物理ディスク５１０は物理ボリュームと呼ばれる。物理ボリュームは、時にはＬＵ（論理ユニット）と呼ばれる。
【００４１】
物理ディスク５１０は、アドレスを付けて、アプリケーションサーバ１１０に見えるようにしたユニットであり、記憶システム１５０内で管理される。もし物理ディスク５１０が見えるならば、対応する物理ボリューム５２０がアプリケーションサーバ１１０上に存在する。物理ディスク５１０は、１台ないしはそれ以上のＨＤＤにいろいろな手法で展開され、その実行は与えられた記憶システムの細目に依存し、そしてアプリケーションサーバには明白である。通常、物理ディスクは、記憶システム内で固有に番号付けされる。
【００４２】
ＲＡＩＤグループ５５０は、物理ディスク５１０が展開されているＨＤＤ１５１のセットで構成される。ＲＡＩＤグループは数台の物理ディスクを含んでいてもよい。本発明の一実施例では、物理ディスクは１つのＲＡＩＤグループ５５０に属するものとして取り扱われることができる。
【００４３】
図２は、本発明の他の実施例によるデータ記憶システム２０の例を示す。図１に示した機能コンポーネントの多くは、ソフトウエアコンポーネントまたはモジュールで構成される。したがって、本発明の機能的な側面が、他の構成での、コンピューティングコンポーネントの中に分散され得ることが認識できる。たとえば、図２に示すように、ＶＰＭインターフェイス１２１は、ＶＰＭサーバ１００の中に組み込まれている。図２は、また、ＶＰＭサーバが、ネットワーク接続１３０を通して記憶システム１５０と直接通信が可能なことを示している。
【００４４】
ストレージエリアネットワーク（ＳＡＮ）は、アプリケーションサーバ１１０に記憶設備を提供するために使用出来る。したがって、記憶システム１５０は異なったＳＡＮ施設であるかもしれない。ＶＰＭサーバ１００からのネットワーク接続１３０は、ＳＡＮを構成する物理ボリュームに接続することが可能である。この構成に於いては、ＶＰＭサーバは物理ボリュームに直接アクセスが出来る。ネットワーク結合ストレージ（ＮＡＳ）アーキテクチャを、同様のやり方で使用しアクセスすることが可能である。結果として、ＶＰＭエージェント１１１は、ＶＰＭサーバ１００のために、記憶システム１５０に対するインターフェイスコンポーネントとして機能する必要はない。代わりに、ＶＰＭサーバは、関連した情報を得るために記憶システム１５０に直接のアクセスが可能である。
【００４５】
図３Ａから図３Ｆは、本発明の説明のための実施例による、システムコンフィギュレーションテーブル１０３（図１）を構成する各種のデータテーブルを示す。これらのテーブルはＶＰＭエンジン１０１で初期化が出来る。
【００４６】
図３Ａは、ある種のシステムレベル情報を含むサーバインフォメーションテーブル３５０を示す。単に例としては、サーバテーブルは、サーバの名前を含むサーバネームフィールド３５１を含むことができる。ＩＰアドレスフィールド３５２は、このサーバのＩＰアドレスを提供する。コミュニケーションプロトコルによっては、追加のアドレッシングに関連した情報が必要になるかもしれない。他のサーバ情報３５３は、プロダクトフィールドとベンダーフィールドを含むことが出来る。
【００４７】
図３Ｂはアプリケーションインフォメーションテーブルにおけるエントリー３００を示す。アプリケーションインフォメーションテーブルは、アプリケーションオブジェクト（データオブジェクト）と、アプリケーションオブジェクトを構成するファイルが記憶されるプライマリボリューム（物理ボリューム）のマッピングを提供するのに使われる。図はアプリケーションインフォメーションテーブルの一つのエントリーを示している。データミラーリングを希望する各アプリケーションについては、そのアプリケーションで生成される各アプリケーションオブジェクト毎のエントリーがある。データベースアプリケーションを考える。企業は、たとえば販売データベース、製造グループが製造のための部品の在庫を追跡するためのデータベースなど、多くのデータベースを有しているであろう。各データベースはアプリケーションオブジェクトを構成する。このように、エントリー３００は、データベースアプリケーションで保持される各データベースに対するアプリケーションインフォメーションテーブルに存在する。
【００４８】
各エントリー３００は、アプリケーション（たとえば、オラクルデータベースアプリケーション）を表示する情報と、アプリケーションのデータオブジェクトの具体例を含むアプリケーションネームフィールド３０１を含む。インスタンス識別子フィールド３０２は、たとえばデータベースの、データオブジェクトを表示する情報を記憶する。各エントリー３００はまた、データオブジェクトの構成データファイルを表示する情報を記憶するために、マッピングインフォメーションフィールド３０３を含むことが出来る。上記で論じたように、この情報はアプリケーションに特化した形で得ることが出来る。一般には、このような情報は、アプリケーションの開発者により提供される、管理コマンドを経由して利用可能である。
【００４９】
図３Ｃは、ファイル・システムインフォメーションテーブルエントリー３２０を示す。このテーブルは、各ファイル・システム名を、使用されているファイル・システムによって様々である支援情報を含んでいる、論理ボリュームにマップする。情報は、ファイル・システムが展開されるボリュームの「ボリューム名」を含むことが出来る。ファイル・システムのマウントポイントと特定する「マウントポイント」データがあってもかまわない。
【００５０】
たとえば、これはユニックス形式のファイル・システム設計に於いては関係がある。ファイル・システムのバージョンを表示する、「バージョン」フィールドがあっても良い。「総記憶容量」フィールドと「使用された記憶容量」フィールドを、ファイル・システムのディスクの使用状況を表示するために使用することも可能である。ユニックスシステムでは、この情報は、たとえば次のコマンドを入力して得ることが出来る。すなわち、
ｄｆ−ｋ ｆｉｌｅｎａｍｅ
ここで、ｆｉｌｅｎａｍｅは、図３Ｂのアプリケーションインフォメーションテーブルにおいて識別されたファイルの名称である。
【００５１】
図３Ｄはボリュームマネージャインフォメーションエントリー３１０を示す。ボリュームマネージャインフォメーションテーブルは、論理ボリューム（５４０、図５）を、論理ボリュームが駐在する１ないしはそれ以上の物理ボリューム（５２０、図５）にマップする。「ボリュームマネージャネーム」３１１は、論理ボリュームを提供しているボリュームマネージメントソフトウエアを表す情報を含む。
【００５２】
データ記憶システム１０（図１）は、複数のベンダから提供されるボリュームマネージメントソフトウエアを使用することが出来る。「ディスクグループ情報」フィールド３１２は、論理ボリュームを１ないしはそれ以上の物理ボリューム（デバイス）にマッピングするのに適した情報を含んでいる。したがって、たとえば図に示したエントリーは、論理ボリューム「／ｄｅｖ／ｖｘ／ｄｓｋ／ＶＧ０１／ｖｏｌ０１」と「／ｄｅｖ／ｖｘ／ｄｓｋ／ＶＧ０１／ｖｏｌ０２」が、物理ボリューム「ｃ２ｔ０ｄｌ」と「ｃ２ｔ０ｄ２」、および「ｃ３ｔ１ｄ０」に定義されていることを示す。アプリケーションサーバ１１０上で幾つかのディスクグループ（５３０、図５）が定義されている場合は、２ないしはそれ以上の「ディスクグループ情報」フィールドがあり得る。
【００５３】
ボリュームマネージャ情報エントリー３１０に基づいて、ファイル・システム情報テーブルエントリー３２０からの論理ボリューム５４０は、その対応する１ないしはそれ以上の物理ボリューム（５２０、図５）にマップされることが可能である。
【００５４】
図３Ｅは、オペレーティングシステム情報テーブル３３０を示す。これは、オペレーティングシステム（フィールド３３１）とＯＳベンダー（フィールド３３２）のような情報を含んでいる。
【００５５】
図３Ｆは物理ボリューム情報テーブルエントリー３４０を示す。物理ボリューム情報テーブルは、物理ボリューム（５２０、図５）をＲＡＩＤグループ（５５０、図５）にマップするのに適した情報を含んでいる。開示される実施例は説明の目的であることを想起されたい。前述の説明から、ＲＡＩＤアーキテクチャ以外の物理レベルのデバイスが同様に適していることも明らかである。
【００５６】
各物理ボリューム情報テーブルエントリー３４０は、物理ボリュームを表す情報を含む「ボリュームネーム」フィールド３４１を含む。「物理ディスク情報」フィールド３４２は、物理ボリュームに関連した、物理ディスク（５１０、図５）に係わる情報を含む。物理ディスク情報は、記憶システム１５０のベンダー名、記憶システム（製品）名、記憶システムのシリアル番号、物理ディスクのボリュームＩＤ、物理ディスクが展開されているＲＡＩＤグループ（５５０、図５）のＲＡＩＤグループＩＤ、およびＲＡＩＤグループの使用中率（ビジーレート）で構成されている。ＲＡＩＤグループビジーレート情報は、ＲＡＩＤグループの使用中の率を示す。この情報は記憶システムから得ることが出来る。この情報は定期的にモニタすることが可能で、対応する物理情報テーブルエントリー３４０において更新される。
【００５７】
物理ボリューム情報テーブルエントリー３４０はまた、１個ないしはそれ以上の「ミラー情報」フィールド３４３も含む。エントリーは、ミラー動作が物理ボリューム上で始動された時に生成される。「ミラー情報」エントリーは、「物理ディスク情報」フィールド３４２と同じ情報を含むことが可能である。さらに、ミラー情報フィールドは、ミラーされた物理ボリューム５２０のセットを特定する「ミラーネーム」を含んでいる。通常は、ユーザは相関のあるミラーのセット（たとえば、アプリケーションオブジェクトのセット）を定義し、それに関係したミラー名をつける。これにより、ユーザは、直感的であり理解しやすいミラー名で、ミラーのセットを操作することが可能になる。特定の物理ボリューム情報テーブルエントリー３４０に係わる物理ボリュームに、物理ディスク（５１０、図５）があるように、「ミラー情報」フィールドには多くのエントリーがある。
【００５８】
図４は、ボリュームプールマネージメント（ＶＰＭ）テーブル４００（１０２、図１）を示す。ボリュームプールは、ミラーボリュームとして使用するために選択できるボリュームのリストを含む。ＶＰＭテーブルはボリュームに関連する情報を記憶する。ミラーボリュームがそこから選ばれる１ないしはそれ以上のボリュームプールが存在できる。「ボリュームプールネーム」フィールド４０１は、ミラーボリュームとして選択可能なボリュームの特定のプールを識別するために提供される。「特権」フィールド４０２は、ボリュームプールにアクセスするための特権設定を定義する。
【００５９】
たとえば、特権には、ボリュームプールの「オーナ」、ユーザグループに所属するメンバー、および他のメンバーに対する設定を含み、これらのカテゴリーはユニックスシステムで一般的に見られるユーザカテゴリーと同様である。「Ｒ」の設定により、ボリュームプールの参照が可能になる。「Ｕ」の設定により、プールからボリュームの割り当てが可能になる。もちろん、追加の、あるいは代替えの特権設定が、ボリュームプールへのアクセスを制御するために提供可能である。
【００６０】
ＶＰＭテーブル４００は、さらに、ボリュームプールのメンバーである各ボリューム（たとえば、物理ボリューム５２０あるいは物理ディスク５１０、図５）に対するエントリー４０３を含む。各エントリーは、「性能レベル」表示、「信頼性レベル」表示、「ベンダーネーム」、ディスクシステムの「システムネーム」、「シリアル番号」表示、「ボリューム識別子」、「物理ディスクグループ識別子」、および「サイトネーム」フィールドを含む。性能レベルは、ディスクの性能能力の大まかな予測を提供する。信頼性レベルは、ディスクの信頼性の表示を提供する。
【００６１】
サイトネームは、ディスクの地理的な場所を識別する。ミラーボリュームとして使用されるディスクは、プライマリボリュームのサイトから離れた場所にあるかもしれない。これは、別の部屋、別の建物、別の都市などである。プライマリサイトで災害が発生した場合には、ミラーされるプライマリボリュームからミラーボリュームを離しておくと、データが生き残る可能性が増える。その結果、分かるように、ミラーボリュームはその場所に基づいて選択することが望ましい。エントリー４０３は、ボリュームがミラーボリュームとして割り当てられているか否かを表示する「使用中」フィールドも含む。
【００６２】
上記で注意したように、ユーザインターフェイスは、特定のインターフェイス状況に見合う適切なインターフェイス技術のどれでもよい。本発明の一実施例に応じた実行は、コマンドラインインターフェイスによる。たとえば、ユニックス形式のコマンドラインラインインターフェイスは、次のようなコマンドを含む。すなわち
【００６３】
ｃｒｅａｔｅｍｉｒｒｏｒ ｍｉｒｒｏｒ＿ｎａｍｅ
[−ｖｏｌ ｐｖｏｌ１[ｐｖｏｌ２]．．．ｐｖｏｌ１ｎ]]
[−ａｐｐ ａｐｐｎａｍｅ ｉｎｓｔｎａｍｅ]
[−ｈｏｓｔ ｈｏｓｔｎａｍｅ]
[−ｐｏｏｌ ｐｏｏｌ＿ｎａｍｅ]
[−ｐｌｅｖｅｌ ｐｅｒｆｏｒｍａｎｃｅ＿ｌｅｖｅｌ]
[−ｒｌｅｖｅｌ ｒｅｌｉａｂｉｌｉｔｙ＿ｌｅｖｅｌ]
[−ｓｉｔｅ ｓｉｔｅｎａｍｅ]
【００６４】
ｃｒｅａｔｅｍｉｒｒｏｒは、特定のプライマリボリュームのミラーリング動作を開始させる。このコマンドは、１個ないしはそれ以上のプライマリボリュームをミラーするために、ミラーボリュームとして使用するために、ボリュームプール（図４）からミラーボリュームの選択を開始させる。ミラー名は、ミラーボリュームのグループを指定する。コマンドアーギュメント（オプション）は以下を含む。
【００６５】
−ｖｏｌ：このアーギュメントにより、ユーザはミラーされるべき特定のプライマリボリュームを識別出来る。１個ないしはそれ以上のプライマリボリューム（ｐｖｏｌ１ − ｐｖｏｌｎ）を指定出来る。
【００６６】
−ａｐｐ：このアーギュメントにより、ユーザは、アプリケーション（たとえば、データベースアプリケーション、ボリュームマネージャ、など）とアプリケーションに関連するデータオブジェクトのインスタンス（「ｉｎｓｔｎａｍｅ」）を指定することが出来る。このアーギュメントは、データオブジェクトの１個ないしはそれ以上のプライマリボリュームへのマッピングを開始する。
【００６７】
次に、ミラーリングオペレーションが、マップされたプライマリボリューム上で行われる。データオブジェクトの性質はアプリケーションに依存する。たとえば、コマンド：
ｃｒｅａｔｅｍｉｒｒｏｒ −ａｐｐ Ｏｒａｃｌｅ ＰＲＯＤ１
は、データベースアプリケーションであるオラクルをアプリケーションとして指定する。その結果、データオブジェクトは、ＰＲＯＤ１と呼ばれるデータベースである。もう一つの例としては、コマンド：
【００６８】
ｃｒｅａｔｅｍｉｒｒｏｒ −ａｐｐ ＶｘＶＭ ＶＧ０１
【００６９】
は、ボリュームマネージメントアプリケーションであるＶｘＶＭをアプリケーションとして指定し、この場合のデータオブジェクトは論理ボリュームである。コマンドが実行されることにより、アプリケーションの形式を単に参照し、次に、データオブジェクトをプライマリボリュームにマップするためにマッピング情報にアクセスするように、特定のソフトウエアルーチンなどにアクセスすることにより、データオブジェクトからプライマリボリュームへの変換がどのようになされるのかを理解する事が出来る。上記で論じたように、オラクルではプライマリボリューム情報を得るために、ＳＱＬシーケンスを発行することが出来る。ＶｘＶＭに於いては、ｖｘｐｒｉｎｔのような管理コマンドを、特定の論理ボリュームについてのプライマリボリューム情報を得るために、ＶｘＶＭ管理ソフトウエアへ発行することが出来る。
【００７０】
−ｈｏｓｔ：このアーギュメントにより、ユーザは特定のプライマリボリュームが存在するホスト名を指定することが出来る。たとえば、図１では、このアーギュメントはミラーするプライマリボリュームを含むのはアプリケーションサーバ１１０のどれかを特定するために用いることが出来る。デフォルトのホストが使用可能である。たとえば、ユーザがログオンしているマシンがデフォルトホストである。
【００７１】
−ｐｏｏｌ： このアーギュメントにより、ユーザはミラーボリュームが選択されるボリュームプールを指定することが出来る。もしこのアーギュメントが指定されないときには、デフォルトのボリュームプールが使用される。
【００７２】
−ｐｌｅｖｅｌ： このアーギュメントにより、ユーザはプライマリボリュームをミラーするために使用されるミラーボリュームの特定の性能レベル（基準）を指定することが出来る。もしこのアーギュメントが指定されないときは、ミラーボリュームは性能レベルには関わりなく選択される。
【００７３】
−ｒｌｅｖｅｌ： このアーギュメントにより、ユーザはプライマリボリュームをミラーするために使用されるミラーボリュームの特定の信頼性レベル（基準）を指定することが出来る。もしこのアーギュメントが指定されないときは、ミラーボリュームは信頼性レベルには関わりなく選択される。
【００７４】
−ｓｉｔｅｎａｍｅ： このアーギュメントにより、ユーザは、プライマリボリュームをミラーするためにミラーボリュームが選択される、特定のサイト名（基準）を指定することが出来る。もしこのアーギュメントが指定されない場合は、ミラーボリュームはミラーボリュームの場所に関わりなく選択される。
【００７５】
ほかの基準も含まれることは自明である。列挙した基準により、ミラーボリュームの選択はユーザ指定の基準により決められるという事実をを説明した。
【００７６】
ｓｕｓｐｅｎｄｍｉｒｒｏｒ ｍｉｒｒｏｒ＿ｎａｍｅ
[−ｈｏｓｔ ｈｏｓｔｎａｍｅ]
【００７７】
ｓｕｓｐｅｎｄｍｉｒｒｏｒは、ｍｉｒｒｏｒ＿ｎａｍｅで識別されたミラーリンググループの全てのミラーボリュームのミラーリング動作を停止する。ｄｅｌｍｉｒｒｏｒコマンドと異なり、このコマンドは単にミラーリング動作を止めるが、止めたミラーボリュームをボリュームプールへは戻さない。コマンドアーギュメント（オプション）は以下を含む。
【００７８】
−ｈｏｓｔ：このアーギュメントにより、ユーザはミラーリングオペレーションを止めるホストネームを指定することが出来る。たとえば、図１では、このアーギュメントは、ミラーするプライマリボリュームを含むのはアプリケーションサーバ１１０のどれかを特定することができる。デフォルトのホストが使用可能である。たとえば、ユーザがログオンしているマシンがデフォルトホストである。
【００７９】
ｄｅｌｍｉｒｒｏｒ ｍｉｒｒｏｒ＿ｎａｍｅ
[−ｈｏｓｔ ｈｏｓｔｎａｍｅ]
[−ｐｏｏｌ ｐｏｏｌｎａｍｅ]
【００８０】
ｄｅｌｍｉｒｒｏｒは、ｍｉｒｒｏｒ＿ｎａｍｅで識別されたミラーリンググループの全てのミラーボリュームのミラーリング動作を停止する。ミラーリング動作を止めるほかに、このコマンドは、止めたミラーボリュームをボリュームプールに戻し、これらのミラーボリュームが他のプライマリボリュームをミラーするために割り当て可能にする。アーギュメントは以下を含む：
【００８１】
−ｈｏｓｔ： このアーギュメントにより、ユーザはミラーリングオペレーションを止めるホストネームを指定することが出来る。たとえば、図１では、このアーギュメントは、ミラーするプライマリボリュームを含むのはアプリケーションサーバ１１０のどれかを特定することができる。デフォルトのホストが使用可能である。たとえば、ユーザがログオンしているマシンがデフォルトホストである。
【００８２】
−ｐｏｏｌ： このアーギュメントにより、ユーザは止めたミラーボリュームを戻すボリュームプールを指定することが出来る。もしこのアーギュメントが指定されないときは、ミラーボリュームはユーザに関連するデフォルトのボリュームプールへ戻すことが可能である。
【００８３】
ｐｏｏｌｃｒｅａｔｅ ｐｏｏｌ＿ｎａｍｅ
【００８４】
ｐｏｏｌｃｒｅａｔｅは、指定されたプール名を持つボリュームプールを生成する。このコマンドは、ＶＰＭテーブル４００（図４）に単にエントリーを生成する。
【００８５】
ｐｏｏｌａｔｔｒ ｐｏｏｌ＿ｎａｍｅ ｇｒｐｎａｍｅ ［＋｜−］ ［Ｒ｜Ｕ｜ＲＵ］］
【００８６】
ｐｏｏｌａｔｔｒは、指定したプール名を持つボリュームプールについて、「ｇｒｐｎａｍｅ」により識別されるグループのグループ属性を変更する。ユーザは、「＋」または「−」を指定して、読み出し（Ｒ）、割り当て（Ｕ）、または双方の特権を、それぞれ追加あるいは削除を行う。このコマンドは、ＶＰＭテーブル４００（図４）において特権フィールド４０２を変更する。
【００８７】
ｐｏｏｌａｄｄｖｏｌ ｐｏｏｌ＿ｎａｍｅ ［＋｜−］ ｖｏｌ１ ［ｖｏｌ２ ．．． ｖｏｌｎ］
【００８８】
ｐｏｏｌａｄｄｖｏｌは、プール名で指定されたボリュームプールにボリュームを追加する。１ないしはそれ以上のボリューム（ｖｏｌ１ ― ｖｏｌｎ）を追加出来る。本発明の実施例における特定の具体化では、ボリュームは物理ボリューム５２０（図５）である。ユーザは、指定したボリュームを追加あるいは削除するために、それぞれ「＋」あるいは「−」を指定することができる。
【００８９】
図６は、どのようにしてシステムコンフィギュレーションテーブル１０３（図１）を初期化出来るのかを説明する高レベルのフロー図を示す。ＶＰＭエンジン１０１が起動すると、ステップ６０１では、メッセージが全てのアプリケーションサーバ１１０に送られ、それらのシステム構成情報を得る。さらに、に新しく追加されたアプリケーションサーバが知らされると、ＶＰＭエンジンはそのアプリケーションサーバにメッセージを送り、そのシステム構成情報を得る。
【００９０】
各アプリケーションサーバ１１０に於いては、サーバ上で実行中のアプリケーションについての情報が、ステップ６０２で、ＶＰＭエージェント１１１により取得される。これは、ＣＬＩとかＡＰＩなど、いろいろなやり方で行われ、アプリケーションに強く依存する。アプリケーションは、オラクル、ＳＱＬサーバ、エクスチェンジ、ＳＡＰ Ｒ／３、ピープルソフト、ＢＡＡＮ等のソフトウエアを含んでいる。上述のように、関心のある情報は、たとえばデータベースのようなアプリケーションの特定のデータオブジェクトあるいはアプリケーションオブジェクトを記憶するために用いられるプライマリボリュームを識別する、ある形式のマッピング情報を含んでいる。
【００９１】
このように、たとえば、データベースインスタンスに関わるデータファイルを記憶するために用いられる全てのプライマリボリュームを識別する、アプリケーションサーバにおけるデータベースアプリケーションによって保持されるデータベース（データオブジェクト）の各インスタンスに対するマッピング情報が得られる。
【００９２】
同様のステップ６０３では、ＶＰＭエージェント１１１は、ボリュームマネージャがアプリケーションサーバ１１０上で実行中であれば、そのボリュームマネージャについての情報を得ることが出来る。代表的なボリュームマネージメント製品は、ベリタス・エキステンデド・マネージャＶｅｒｉｔａｓ Ｅｘｔｅｎｄｅｄ Ｖｏｌｕｍｅ Ｍａｎａｇｅｒ（ＶｘＶＭ）である。ステップ６０１で示したように、ボリュームマネージャ情報は、ソフトウエアにより提供される方法で取得出来る。このように、論理ボリュームで構成されるプライマリボリュームを識別するマッピング情報を取得するために、ｖｘｐｒｉｎｔコマンドを使うことが出来る。ＶＰＭエージェント１１１は、ＶｘＶＭと相互作用をして、ユーザがｖｘｐｒｉｎｔコマンドをタイプし、出力を受信するように見えるように構成することが出来る。次に、出力を解析し、希望した情報を得る。
【００９３】
次に、ステップ６０４では、アプリケーションサーバ１１０によりアクセスすることが出来る物理ボリュームに関する情報（たとえば、物理ディスク情報３４２、図３Ｆ）が得られる。これは、特定の記憶システム１５０に適した方法で行うことが可能である。たとえば、ＳＣＳＩインターフェイスは、情報を取得するため、ｉｎｑｕｉｒｙのようなＳＣＳＩコマンドを受信することが出来る。他の例としては、ＳＮＭＰのようなネットワークプロトコルが適しているかもしれない。ある記憶システムのベンダは、情報にアクセスするためにＣＬＩやＡＰＩを提供している。どの場合でも、ＶＰＭエージェント１１１は、記憶システムと相互動作して情報を取得するように、プログラムする、あるいはその他の構成にすることが出来る。
【００９４】
ステップ６０５では、サーバ自身についての情報が取得される。情報は、ファイルシステム、オペレーティングシステムなどを含んでいる。情報は、ＣＬＩあるいはＡＰＩを用いて取得出来る。
【００９５】
ステップ６０６では、ステップ６０２から６０５で得た情報が、ＶＰＭエンジン１０１へそれぞれのアプリケーションサーバ１１０により、伝達される。ＶＰＭエンジン１０１は、ステップ６０７で、各アプリケーションサーバ１１０から受信した情報を集め、データを編集し、図３Ａから図３Ｆに示したシステムコンフィギュレーションテーブルにデータを駐在させる。
【００９６】
図７は、本発明の実施例による特定の実施例において、どのようにミラー生成が行われるかを説明する高レベルのフローチャートを示す。ＶＰＭサーバ１００（図１）が、ＶＰＭユーザインターフェイス１２１（図１と図２）からｃｒｅａｔｅｍｉｒｒｏｒコマンドを示す情報を受信すると、その情報と付随するパラメータ情報（たとえば、コマンドアーギュメント）は、ステップ７０１でＶＰＭエンジン１０１に伝えられる。パラメータ情報は、デフォルト値を決めるために役立つ、ユーザの識別情報を含むことが出来る。ＶＰＭエンジンは、たとえばアーギュメントを識別するためにコマンドラインを解析するなどにより、パラメータ情報を識別するために情報を調べる。
【００９７】
ステップ７０２では、もし−ｖｏｌアーギュメントが指定されていると、パラメータ情報の中にプライマリボリュームのリストが提供される。しかしながら、もし−ａｐｐアーギュメントが指定されていると、ＶＰＭエンジン１０１は、システムコンフィギュレーションテーブル（図３Ａから図３Ｆ）を参照することにより、指定されたアプリケーションオブジェクトが記憶されているプライマリボリュームを識別する情報のリストを取得する。
【００９８】
アプリケーションオブジェクトの名前が与えられると、ＶＰＭエンジン１０１は、そのオブジェクトの論理的および物理的な展開を見付けることが出来る。たとえば、図３Ａ−図３Ｆに示すサンプルの情報の場合は、もしアプリケーションオブジェクト（ｔａｂｌｅｓｐａｃｅ ＴＢＳ１）が与えられると、ＴＢＳ１の展開を次の方法で見つけることができる：
【００９９】
アプリケーション情報エントリー３００から、ＴＢＳ１は、／ｕ０１／ｏｒａ／ｄａｔａ／ｔｂｓ０１．ｏｒａと／ｕ０１／ｏｒａ／ｄａｔａ／ｔｂｓ００．ｏｒａと呼ばれる２個のファイルで構成されている事が分かる。適切なＣＬＩまたはＡＰＩを用いることで、たとえばコマンドｄｆ−ｋ／ｕ０１／ｏｒａ／ｄａｔａ／ｔｂｓ０１．ｏｒａを発行することにより、２個のファイルが駐在する論理ボリューム５４０を確定することが出来る。二つのファイルが、／ｄｅｖ／ｖｘ／ｄｓｋ／ＶＧ０１／ｖｏｌ０１上にあると仮定する。
【０１００】
ボリュームマネージャ情報エントリー３１０から、／ｄｅｖ／ｖｘ／ｄｓｋ／ＶＧ０１／ｖｏｌ０１の論理ボリューム５４０は、３個の物理ボリューム５２０、すなわちｃ２ｔ０ｄ１とｃ２ｔ０ｄ２とｃ３ｔ１ｄ０の上にあることが示される。ファイル・システム情報エントリー３２０から、／ｄｅｖ／ｖｘ／ｄｓｋ／ＶＧ０１／ｖｏｌ０１の論理ボリューム５４０は、／ｕ０１／ｏｒａ／ｄａｔａ／ 上にマウントされ、そしてＶｘＦＳファイル・システムを使用することがわかる。物理ボリューム情報テーブル３４０から、ｃ２ｔ０ｄｌの物理ボリューム５２０は、ストレージ社の「ハイエンドストレージ」と呼ばれ（両方とも、単に説明するための仮想の名前）、シリアル番号６０２３３で、物理ディスクグループＩＤ２００の記憶システム上にあることがわかる。
【０１０１】
ステップ７０３では、ＶＰＭエンジン１０１は、ボリュームプールから候補となるミラーボリュームのセットを取得する。もし−ｐｏｏｌアーギュメントが指定されないと、デフォルトのボリュームプールがアクセスされる。これは、ユーザＩＤとボリュームプールマネージメントテーブル（図４）の「ネーム」フィールドとの一致を取ることで行うことが出来る。一方では、パラメータ情報は、候補のミラーボリュームが選択されるボリュームプールを識別する、ボリュームプール名を含んでいる。ユーザ指定のプールから実際にミラーボリュームを割り当てる前に、特権が十分であるかの初期確認がされる。
【０１０２】
ステップ７０４では、各プライマリボリュームに対して候補のミラーボリュームが選択される。もし基準アーギュメントのどれかが指定されると（たとえば、性能、信頼性、サイト名）、一致する基準を持つミラーボリュームのみが、候補のミラーボリュームが選択されるボリュームプールを形成する。本発明の実施例の特定の実施例では、次の基準がＲＡＩＤシステムを含め考慮される。他のディスクアーキテクチャに対しては、追加の、あるいは代わりの考慮が適切であるかもしれないこと、そしてこれらの基準が、どのようにミラーボリュームが選択されるかということを説明する目的のみに提供されるものである、ということは理解されることである。
【０１０３】
（３５） ミラーボリューム５２０（または物理ディスク５１０、図５）は、プライマリボリュームを含む同じＲＡＩＤグループには無いこと。この制約は、システムコンフィギュレーションテーブル１０３の中で、物理ディスク情報３４２のＲＡＩＤグループＩＤフィールドを調べることにより、容易になる。
（２５） ミラーボリュームは、ビジー状態のＲＡＩＤグループに有ってはならない。さらに、この制約は、システムコンフィギュレーションテーブル１０３の中で、物理ディスク情報３４２のＲＡＩＤグループビジーレートを調べることにより、容易になる。
（１５） −ｐｌｅｖｅｌと−ｒｌｅｖｅｌアーギュメントが規定されるところでは、ミラーボリュームは、指定の性能レベルと信頼性レベルを満たすこと。
（１０） −ｐｌｅｖｅｌと−ｒｌｅｖｅｌアーギュメントが規定されないところでは、ミラーボリュームは、ミラーされるプライマリボリュームの性能レベルと信頼性レベルと出来るだけ近い同じ性能レベルと信頼性レベルを持つこと。
（５） ミラーボリュームは、他のプライマリボリュームを含むＲＡＩＤグループに有ってはならない。
【０１０４】
ミラーボリュームの選択について他に考慮することは、上に列挙したそれぞれの基準に重み付けを適用することである。ＶＰＭエンジン１０１は、条件の全てを満たす最良のミラーボリュームを選ぶように試みることが出来る。もしそれが出来なくても、次善のボリュームを選ぶことも出来る。一つの方法は、ボリュームにより満たされる基準の重み付けを集計して、各々の利用可能なボリュームに対し点数を作ることである。最高の点数を持つボリュームが候補のボリュームとして選択される。
【０１０５】
全ての候補ボリュームが選択されると、ステップ７０５では、各候補ボリュームの特性情報とともに、リストをユーザに認可のために伝達することが可能である。候補のミラーボリュームのリストは、各候補をプライマリボリュームと関連付ける情報を含む。ユーザの認可が要求される場合があるということが、ミラーボリュームが「候補」ボリュームと呼ばれる理由であるということが認識されるものである。
【０１０６】
ＶＰＭエンジン１０１は、ユーザから認可の回答を選択的に要求するように構成することが出来る。たとえば、もし候補ボリュームに対する点数が閾値を越える場合は、認可を必要としないことは、設計的に決定されるであろう。アーギュメントを通して、ユーザが、閾値をコマンドに設定することが出来る。他の技術は、認可が必要か否かを指定するアーギュメントを提供する事かもしれない。
【０１０７】
もし候補ボリュームに対する認可の回答を受信したときは、次に、ステップ７０６では、ＶＰＭエンジン１０１は、ＶＰＭエージェント１１１に、ミラーリング動作を開始するための情報を伝達する。各ＶＰＭエージェント１１１は、割り当てられたミラーボリュームを用いて、アプリケーションサーバ１１０に関連したプライマリボリュームのミラーリングを開始するために、記憶システム１５０と交信する。他の構成では（たとえば図２）、ＶＰＭエンジン自身が、ミラーリング動作を開始するために、記憶システムと交信するかもしれない。
【０１０８】
ミラーボリュームの各々に対して、その関連した「使用中」フィールド（図４）は、使用中を意味する値に設定され、割り当てられないようにする。最後に、割り当てられたミラーボリュームは、「ミラーネーム」パラメータで示される活動状態のミラーボリュームのミラーリンググループに追加される。
【０１０９】
図８は、どのようにしてミラーリンググループが削除出来るかを説明する高レベルのフローチャートである。ステップ８０１では、ＶＰＭエンジン１０１は、ＶＰＭユーザインターフェイス１２１から、ミラーリング動作を行っているミラーボリュームのグループであるミラーリンググループを削除するためのコマンドを示す情報を受け取る。ステップ８０２では、削除するミラーボリュームを含んでいるアプリケーションサーバ１１０は、ＶＰＭエンジンからコマンドを受信する。もし−ｈｏｓｔアーギュメントが指定されると、ホストネームにより識別されるアプリケーションサーバ上のミラーリングは停止される。ＶＰＭエージェント１１１は、ミラーリング動作を停止させるために記憶システム１５０と相互に通信する。他の構成では（たとえば 図２）、ＶＰＭエンジン自身が、ミラーリング動作を停止させるために、記憶システムと相互に通信するかもしれない。
【０１１０】
ステップ８０３では、ＶＰＭエンジン１０１は、ミラーボリュームをボリュームプールに「復帰」させる。もし−ｐｏｏｌアーギュメントが指定されない場合は、ミラーボリュームは、当初そこから割り当てられたボリュームプールへ「復帰」させられる。
【０１１１】
このようにして、特定の開示された実施例に応じて、復帰するミラーボリュームの各々に関わる「使用中」フィールドは、ｃｒｅａｔｅｍｉｒｒｏｒコマンドにおいて再割り当てが出来ることを表示するように設定される。 もし−ｐｏｏｌアーギュメントが指定されていると、ミラーボリュームは、プールネームで指定されたボリュームプールへ戻される。これには、指定ボリュームプールへのユーザによる適切なアクセスが必要である。もしアクセスが許可されると、現在ミラーボリュームを含んでいるＶＰＭテーブル４００にあるボリュームエントリー４０３は、前のＶＰＭテーブルからエントリーを削除することを含む、ユーザが指定したＶＰＭテーブルに移動される。
【０１１２】
ミラーボリュームは、バックアップと回復、障害回復、二重化データベースの生成など、各種のソリューションに使用することが可能である。幾つかのデータベースシステムとボリュームマネージャソフトウエアにより、ユーザはデータオブジェクトの構成を動的に変更することが出来る。たとえば、ボリュームマネージャは、１個ないしはそれ以上の物理ボリューム５２０を追加することで、そのディスクグループ５３０（図５）を再構成することが出来る。結果として、新しく追加された物理ボリュームはミラーされなければならない。そうでない場合は、ミラーボリューム上のディスクグループ５３０は、アプリケーションサーバ１１０による再構成およびアクセスが出来ない。
【０１１３】
アプリケーションサーバで構成の変更が発生すると、この事象は適切に構成されたＶＰＭエージェント１１１により検知される。図９は、どのようにしてＶＰＭサーバ１００が更新されるのかを示す。ステップ９０１では、ＶＰＭエージェントは、追加または削除されたプライマリボリューム、あるいは追加または削除されたミラーボリュームなどの、ボリュームミラーリング動作に影響を及ぼす構成の変更を検知する。別のアーキテクチャでは、ＶＰＭサーバ自身が、その事象を検出可能であるかもしれない。このような事象が検出された場合は、ステップ９０２で、ＶＰＭエージェントは、この事象を示す情報をＶＰＭエンジン１０１に伝えることが出来る。つぎに、ＶＰＭエンジンは、図３Ａ−図３Ｆに示す各種のテーブルに、必要な更新を実施するために前述の動作を行う事が出来る。
【発明の効果】
【０１１４】
ユーザは、アプリケーションと対応したデータオブジェクトを参照してプライマリボリュームを指定することが出来る。ユーザは、ミラーボリュームが選択されるボリュームプールを指定することが出来る。本発明は、ローカルミラーリングコンフィギュレーションと、リモートミラーリングコンフィギュレーションに適用可能である。本発明の特徴、利点、新奇性は、付図と共に提供される以下の発明の説明で明確になるものである。
【図面の簡単な説明】
【０１１５】
【図１】図１は、本発明の解説のための実施例に対応するデータマネージメントコンポーネントを持つデータ記憶システムの高レベルシステムダイアグラムを示す。
【図２】図２は本発明の他の解説のための実施例に対応するデータマネージメントコンポーネントを持つデータ記憶システムの高レベルシステムダイアグラムを示す。
【図３Ａ】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｂ】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｃ】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｄ】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｅ】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｆ】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図４】本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図５】図５は、単に本発明の実施例の特徴を説明する目的の、データ記憶システムアーキテクチャの例を説明する
【図６】図３Ａ−図３Ｆに示すシステムコンフィギュレーションテーブルを生成するための処理ステップの例を説明する、高レベルのジェネラルフローチャートである。
【図７】図７は、本発明の実施例に対応する、ミラー動作を始動するための処理ステップの例を説明する、高レベルのジェネラルフローチャートである。
【図８】本発明の実施例に対応するミラーの削除の例を説明する高レベルのジェネラルフローチャートである。
【図９】データ記憶装置の構成が変わったときに、システムテーブルの更新を説明する高レベルのジェネラルフローチャートである。
【符号の説明】
【０１１６】
１００・・・ＶＰＭサーバ、１０１・・・ＶＰＭエンジン、１０２・・・ＶＰＭテーブル、１０３・・・システムコンフィギュレーションテーブル、１２０・・・ユーザエキスプローラ、１２１・・・ＶＰＭユーザインターフェイス、１１０・・・アプリケーションサーバ、１１１・・・ＶＰＭエージェント、１５０・・・記憶システム

Claims (7)

1. クライアントマシンと通信する第１のサーバと、１ないしそれ以上の物理ディスクで構成された複数のボリュームを有する１ないしそれ以上の記憶サブシステムと、前記第１のサーバに第１のコミュニケーションチャネルを介して接続されているとともに、前記記憶サブシステムに第２のコミュニケーションチャネルを介して接続された１ないしそれ以上の第２のサーバとを備え、前記記憶サブシステムは、前記複数のボリュームとして、プロダクションボリュームと、当該プロダクションボリュームと二重化ペアを形成するためのミラーボリュームを有するデータ記憶システムにおける記憶管理方法であって、
   前記第１のサーバが、ミラーリング動作を開始させるためのコマンドを前記クライアントマシンから受信する第１のステップと、
   前記第１のサーバが、前記受信したコマンドに付随するパラメータ情報のうち前記プロダクションボリュームを識別するための情報に基づいて、少なくとも１個の前記プロダクションボリュームを識別する第２のステップと、
   前記第１のサーバが、前記受信したコマンドに付随するパラメータ情報のうち前記ミラーボリュームの特定の性能レベルを指定するための選択基準に基づいて、前記ミラーボリュームとして使用するために選択できるボリュームのリストを含むボリュームプールから、前記識別したプロダクションボリュームに対して候補記憶ボリュームを選択する第３のステップと、
   前記第１のサーバが、前記選択した候補記憶ボリュームを前記ミラーボリュームとして、前記プロダクションボリュームのミラーリング動作を開始するための情報を前記第２のサーバに伝達する第４のステップと、
   前記第２のサーバが、前記ミラーボリュームを用いて、前記プロダクションボリュームのミラーリング動作を開始するために、前記第１のサーバから受信した情報を基に前記記憶サブシステムと交信する第５のステップと
   を備え、
   前記選択基準は、前記物理ディスクの性能能力を示す性能レベルと、前記物理ディスクの信頼性を示す信頼性レベルを含む
   ことを特徴とする記憶管理方法。
2. 請求項１に記載の方法であって、
   前記パラメータ情報は、
   アプリケーションプログラムを表し、
   前記アプリケーションプログラムは、
   複数のデータオブジェクトと関連し、
   前記第２のステップでは、
   １個ないしはそれ以上の前記データオブジェクトで構成される全てのデータファイルに対して集合的に記憶領域を提供するプロダクションボリュームを識別する
   ことを特徴とする記憶管理方法。
3. 請求項１に記載の方法であって、
   前記パラメータ情報は、
   アプリケーションプログラムを表し、
   前記アプリケーションは、
   データベースアプリケーションであり、
   前記データオブジェクトの各々は、
   データベースのインスタンスを構成するデータファイルを表し、
   前記データファイルは、
   １個ないしはそれ以上のプロダクションボリュームに記憶されている
   ことを特徴とする記憶管理方法。
4. 請求項１に記載の方法であって、
   前記パラメータ情報は、
   アプリケーションプログラムを表し、
   前記アプリケーションは、
   記憶ボリュームマネージャであり、
   前記データオブジェクトの各々は、
   論理ボリュームを表しており、
   前記論理ボリュームは、
   １個ないしはそれ以上のプロダクションボリュームで構成される
   ことを特徴とする記憶管理方法。
5. 請求項１乃至請求項４のうち何れか１項に記載の方法であって、
   前記第３のステップでは、
   さらに、その後の選択の際において、前記候補記憶ボリュームが選択されないように、前記候補記憶ボリュームがミラーボリュームとして使用中であることを指定する
   ことを特徴とする記憶管理方法。
6. 請求項１乃至請求項４のうち何れか１項に記載の方法であって、
   前記第３のステップでは、
   さらに、前記候補記憶ボリュームをミラーボリュームとして使用することの認可を取得する
   ことを特徴とする記憶管理方法。
7. クライアントマシンと通信する第１のサーバと、１ないしそれ以上の物理ディスクで構成された複数のボリュームを有する１ないしそれ以上の記憶サブシステムと、前記第１のサーバに第１のコミュニケーションチャネルを介して接続されているとともに、前記記憶サブシステムに第２のコミュニケーションチャネルを介して接続された１ないしそれ以上の第２のサーバとを備え、前記記憶サブシステムは、前記複数のボリュームとして、プロダクションボリュームと、当該プロダクションボリュームと二重化ペアを形成するためのミラーボリュームを有するデータ記憶システムであって、
   前記第１のサーバは、ミラーリング動作を開始させるためのコマンドを前記クライアントマシンから受信したときに、前記受信したコマンドに付随するパラメータ情報のうち前記プロダクションボリュームを識別するための情報に基づいて、少なくとも１個の前記プロダクションボリュームを識別するととともに、前記受信したコマンドに付随するパラメータ情報のうち前記ミラーボリュームの特定の性能レベルを指定するための選択基準に基づいて、前記ミラーボリュームとして使用するために選択できるボリュームのリストを含むボリュームプールから、前記識別したプロダクションボリュームに対して候補記憶ボリュームを選択し、前記選択した候補記憶ボリュームを前記ミラーボリュームとして、前記プロダクションボリュームのミラーリング動作を開始するための情報を前記第２のサーバに伝達し、
   前記第２のサーバは、前記ミラーボリュームを用いて、前記プロダクションボリュームのミラーリング動作を開始するために、前記第１のサーバから受信した情報を基に前記記憶サブシステムと交信し、
   前記選択基準は、前記物理ディスクの性能能力を示す性能レベルと、前記物理ディスクの信頼性を示す信頼性レベルを含む
   ことを特徴とするデータ記憶システム。

Images