JP2004252934A

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

Info

Publication number: JP2004252934A
Application number: JP2003167259A
Authority: JP
Inventors: Kenji Yamakami; 憲司山神; Chiyokuki Watanabe; 直企渡辺
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-06-12
Filing date: 2003-06-12
Publication date: 2004-09-09

Abstract

【課題】大型の広域に分散している記憶システムを有効に管理し、複製ボリュームの作成と管理を容易にする。
【解決手段】ユーザ指定のプライマリ（またはプロダクション）ボリュームのミラーリングを行なうために、ミラーボリュームのプールが提供され、ミラーボリュームプールから１個ないしそれ以上のボリュームが選択されミラーリングされる。ユーザ基準の提供により、ミラーリングのための候補ボリュームの選択を制約することが出来る。
【選択図】図１

Description

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

・ボリュームの属性ユーザはボリューム属性を手動で設定出来る。
一方、ＶＰＭサーバまたは記憶システムもまた、属性を自動的に収集することが出来る。テーブル３は標準的な属性が含むものである。
＞ユーザのタイプ
＞重要性（損失を許さない、多少の損失は許容する、１日に１回程度）、性能
＞アプリケーションのタイプ

【図面の簡単な説明】
【図１】図１は、本発明の解説のための実施例に対応するデータマネージメントコンポーネントを持つデータ記憶システムの高レベルシステムダイアグラムを示す。
【図２】図２は本発明の他の解説のための実施例に対応するデータマネージメントコンポーネントを持つデータ記憶システムの高レベルシステムダイアグラムを示す。
【図３Ａ】図３Ａは本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｂ】図３Ｂは本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｃ】図３Ｃは本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｄ】図３Ｄは本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｅ】図３Ｅ本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｆ】図３Ｆ本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図３Ｇ】図３Ｇ本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図４】図４は本発明の実施例に対応するインフォメーションテーブルの解説のための実行例を示す。
【図５】図５は、単に本発明の実施例の特徴を説明する目的の、データ記憶システムアーキテクチャの例を説明する。
【図６】図６は、図３Ａから図３Ｆに示すシステムコンフィギュレーションテーブルを生成するための処理ステップの例を説明する、高レベルのジェネラルフローチャートである。
【図７】図７は、本発明の実施例に対応する、ミラー動作を始動するための処理ステップの例を説明する、高レベルのジェネラルフローチャートである。
【図８】図８は、本発明の実施例に対応するミラーの削除の例を説明する高レベルのジェネラルフローチャートである。
【図９】図９は、データ記憶装置の構成が変わったときに、システムテーブルの更新を説明する高レベルのジェネラルフローチャートである。
【図１０Ａ】図１０Ａは本発明の実例的な実施例によるデータマネージメントコンポーネントを持つリモートコピーアーキテクチャの構成例を示す。
【図１０Ｂ】図１０Ｂは本発明の実例的な実施例によるデータマネージメントコンポーネントを持つリモートコピーアーキテクチャの構成例を示す。
【図１０Ｃ】図１０Ｃは本発明の実例的な実施例によるデータマネージメントコンポーネントを持つリモートコピーアーキテクチャの構成例を示す。
【図１１】図１１は、記憶システムを照会する一般的なステップを示す。
【図１２】図１２は、ドメインを見つける手順と、それらの連結性を強調するジェネラルフローチャートである。
【図１３】図１３は本発明の他のアスペクトによるミラーボリュームを生成する一般的な処理を説明する。
【符号の説明】
１００・・・ＶＰＭサーバ、１０１・・・ＶＰＭエンジン、１０２・・・ＶＰＭテーブル、１０３・・・システムコンフィギュレーションテーブル、１２０・・・ユーザエキスプローラ、１２１・・・ＶＰＭユーザインターフェース、１１０・・・アプリケーションサーバ、１１１・・・ＶＰＭエージェント、１５０・・・記憶システム、３５０、サーバ情報、３５１・・・サーバ名、３５２・・・ＩＰアドレス

Claims

記憶マネージメントの方法であって、第１の種類のコマンドを受信し、前記コマンドは第１の情報を有し、前記第１の情報に基づいて、少なくとも１個のプロダクションボリュームを識別し、複数の記憶ボリュームから候補記憶ボリュームを選択し、前記候補記憶ボリュームに関して、前述のプロダクションボリュームのミラーリングを開始し、前記の候補記憶ボリュームはミラーボリュームで、少なくとも１個のプロダクションボリュームと１個ないしはそれ以上の候補記憶ボリュームの間の接続性を示す接続情報に基づいて選択するステップからなることを特徴とする記憶マネージメントの方法。
請求項１の方法であって、さらに第１の記憶システムにおいて第２の記憶システムとの通信を試み、もし前記第２の記憶システムとの通信が可能であれば、前記第１の記憶システムと前記第２の記憶システム間で通信することを意味する情報をデータ記憶装置に記憶し、前記情報は接続情報として使用可能であることを備えた前記接続情報を得るステップを含むことを特徴とする記憶マネージメントの方法。
請求項１の方法であって、前記第１の情報はアプリケーションプログラムを表し、前記アプリケーションプログラムはそれに加え複数のデータオブジェクトに関連を持ち、識別をするステップは、１個ないしはそれ以上のデータオブジェクトを有する全てのデータファイルに総合的に記憶装置を提供するプロダクションボリュームを識別することを含むことを特徴とする記憶マネージメントの方法。
請求項３の方法であって、識別を行う前記ステップは、さらにプロダクションボリュームを表す識別情報を得るためにアプリケーションと対話することを含むことを特徴とする記憶マネージメントの方法。
請求項３の方法であって、コマンドは、さらに第１のデータオブジェクトを代表する第２の情報で構成され、識別する段階では、前記の第１のデータオブジェクトで構成される全てのデータファイルに対して集合的に記憶装置を提供するプロダクションボリュームを識別することを含むことを特徴とする記憶マネージメントの方法。
請求項１の方法であって、さらに前記候補記憶ボリュームをミラーボリュームとして用いることの承認を得ることを含むことを特徴とする記憶マネージメントの方法。
請求項１の方法であって、前記第１の情報は複数のプロダクションボリュームを表し、選択を行う前記ステップは各前記プロダクションボリュームの対応する候補記憶ボリュームを決めることを含み、開始を行う前記ステップは前記プロダクションボリュームの各々のミラーリングを対応する候補ミラーボリュームと開始することを含むことを特徴とする記憶マネージメントの方法。
請求項１の方法であって、前記コマンドは、さらに１個ないしはそれ以上の性能レベルと信頼性レベルを表す第２の情報を含み、選択を行う前記ステップは前記第２の情報に基づくことを特徴とする。
請求項１の方法であって、さらに第２の種類のコマンドを受け取る事を含み、前記第２の種類のコマンドは、１ないしはそれ以上のプロダクションボリュームのミラーリングを行うために用いられる１個ないしはそれ以上の記憶ボリュームを表す第２の情報と、前記第２の種類のコマンドを受け取ることにより、１個ないしはそれ以上の前記プロダクションボリュームのミラーリングを終了させること、１個ないしはそれ以上の前記記憶ボリュームが、続く選択のステップで候補ボリュームとして選択される事が可能なように、１個ないしはそれ以上の前記記憶ボリュームが既にミラーボリュームとして使用されていないことを明示することを含むことを特徴とする記憶マネージメントの方法。
データ記憶システムであって、請求項１で説明された方法に応じて動作する、プロダクションボリュームとミラーボリュームとボリュームマネージャを有することを特徴とするデータ記憶システム。
ネットワークエリア記憶システムであって、請求項１の方法に従って動作するボリュームマネージャを有していることを特徴とするネットワークエリア記憶システム。
記憶マネージメントの方法であって、第１の種類のコマンドを受け取り、前記コマンドは第１の情報を有し、前記第１の情報に基づき第１の複数の記憶ボリュームの中から少なくとも１個のプロダクションボリュームを識別し、候補記憶ボリュームを第２の複数の記憶ボリュームの中から選択し、前記第２の記憶ボリュームは、それぞれ前記第１の記憶ボリュームの何れかとの接続性を表している、対応する接続情報に関連し、前記選択のステップは接続情報に基づき、候補の記憶ボリュームについてプロダクションボリュームのミラーリングを開始することからなり、前記候補記憶ボリュームはミラーボリュームであり、取得ステップで取得された前記接続情報は、第１の記憶システムでは、第２の記憶システムと通信を試み、もし前記第２の記憶システムとの通信が可能な場合には、前記第１の記憶システムと前記第２の記憶システム間で通信が行われていることを示す、前記第１の記憶システム情報に関連する記憶ボリュームと関連することを特徴とする。
請求項１２の方法であって、各ミラーボリュームは、ボリュームのグループを示す関連ローカス情報を持ち、第１の情報はさらにローカスを表す情報を含み、さらに選択のステップは前記ローカスに基づくことを特徴とする記憶マネージメントの方法。
請求項１２の方法であって、さらに第２の種類のコマンドを受け取ることを含み、前記第２の種類のコマンドは１個ないしはそれ以上のプロダクションボリュームのミラーリングを行うために用いられる１個ないしはそれ以上の記憶ボリュームを表す第２の情報と、前記第２の種類のコマンドを受け取ることにより、１個ないしはそれ以上の前記プロダクションボリュームのミラーリングを終了させること、１個ないしはそれ以上の前記記憶ボリュームが、続く選択のステップで候補ボリュームとして選択されることが可能なように、１個ないしはそれ以上の前記記憶ボリュームが既にミラーボリュームとして使用されていないことを明示することを含むことを特徴とする記憶マネージメントの方法。
データ記憶システムであって、請求項１２で説明された方法に応じて動作する、プロダクションボリュームとミラーボリュームとボリュームマネージャを有することを特徴とする記憶マネージメントの方法。
複数の記憶ボリュームで構成されるデータ記憶システムで使用するのに適したデータ記憶マネージャであって、該データ記憶マネージャは、ミラーボリューム情報と接続情報を記憶するデータ記憶装置であって、該ミラーボリューム情報がミラーボリュームとして１個ないしはそれ以上の前記記憶ボリュームを表し、該接続情報が１個ないしはそれ以上の前記ミラーボリュームに対するプライマリボリュームへのデータ接続を示しているデータ記憶装置と、コマンドを受信するユーザインターフェースと、データ記憶装置とのデータ通信におけるコマンド処理コンポーネントとで構成されており、前記ユーザインターフェースは、前記コマンド処理コンポーネントに対する前記コマンドを示すコマンド情報を通信することができ、前記コマンド情報が１個ないしはそれ以上のプライマリボリュームを示すプライマリボリューム情報で構成されており、前記コマンド処理コンポーネントは、各プライマリボリュームを前記接続情報に基づき前記ミラーボリュームの一つに関連付け、関連付けたミラーボリュームに各プライマリボリュームのミラーリング動作を有効にする動作が可能であることを特徴とする記憶マネージャ。
請求項１６のデータ記憶マネージャであって、各ミラーボリュームはボリュームのグループを示す関連ローカス情報を持ち、前記第１のコマンドはさらにローカスを表す情報を含み、前記コマンド処理コンポーネントは前記ローカスに基いて候補のミラーボリュームを選択するように動作可能なことを特徴とする記憶マネージャ。
請求項１６のデータ記憶マネージャであって、前記データ記憶システムは、ネットワークエリアストレージコンポーネントを含むことを特徴とする記憶マネージャ。
データ記憶システムであって、プライマリボリュームとして用いられる第１の記憶ボリュームと、ミラーボリュームとして用いられる第２の記憶ボリュームと、請求項１６に記載のデータ記憶マネージャを有することを特徴とするデータ記憶システム。
請求項１６のデータ記憶マネージャであって、ネットワークエリア記憶システムで用いられることを特徴とするデータ記憶マネージャ。