JP4744955B2 - データ管理システム - Google Patents

Description

本発明は、データを記憶するシステムに係わり、さらに詳細には多数のハードディスクドライブあるいは他のストレージメディアにデータを分散させるストレージシステムに係わる。

一般のデータストレージネットワークでは、多くの異なったアプリケーションからのデータが記憶され検索され、記憶された全てのデータについてその関係を追跡することは困難である。たとえば、電子メールシステムでは、電子メールサーバがオリジナルデータを生成し、それをストレージシステムへ提供する。アーカイブサーバはデータの一部をストレージシステムの異なった箇所に、あるいは異なったストレージシステムにアーカイブする。同時に、レプリケーションサーバはオリジナルデータを異なったストレージにレプリケーションし、そのデータはバックアップサーバにより更なるストレージにバックアップされることもある。これらのデータ処理プロセスのおのおのが適切な手法の処理により関連するデータについて処理を行う一方で、アーカイブサーバとレプリケーションサーバとバックアップサーバはそれぞれ独自に処理を行う。それぞれが、どのようにデータを記憶し検索するかを管理する独自のカタログあるいは他のメカニズムを持っている。システムの分散化される性質や確立されたカタログが無いことにより、ストレージシステムのユーザは一般にそのストレージシステムのどこにデータがあるのかということを十分な信頼性の基に理解することはできない。

さらに、ストレージシステムの複雑さが間違いの可能性を増やす。今説明した例において、オリジナルデータの一部はオリジナルのストレージには記憶されず、代わりにアーカイブストレージに記憶されている。その結果、オリジナルデータのレプリケーションはアーカイブデータを含まない。このように、バックアップデータもまたアーカイブデータを含まない。したがって、ユーザがバックアップからデータを復元させる時には、バックアップデータがオリジナルデータの完全なバックアップでないため、全てのオリジナルデータを復元することにならない。この複雑さにより、データを一貫した方法で管理することが困難になり、かつ間違いを起こしやすくなる。

ストレージシステムにおいてデータの管理を支援するいくつかのツールがある。しかしながら、これらのツールは上記の問題の解決の役には立たない。データストレージシステムの管理に用いられる市販のツールはＶｅｒｉｔａｓ（ＴＭ）により提供され、「ＳＡＮＰｏｉｎｔ Ｃｏｎｔｒｏｌ」と呼ばれている。このシステムはストレージエリアネットワークにおいてハードウエアデバイスとそれらの関係の追跡を連続して行うことを可能にしている。もう一つの市販のツールは「ＡｐｐＩＱ」により提供され、ストレージオーソリティースイートとして知られている。このシステムはホストやバスアダプターやスイッチやディスクサブシステムなどを含むストレージシステムにおけるハードウエアに関する情報を提供する。たとえば「Ｏｒａｃｌｅ」のデータベースやファイルサーバなどのストレージシステム上で実行される特定のアプリケーションを管理する能力も提供している。

ストレージシステムに用いられるもう一つの市販のツールは「Ａｐｔａｒｅ ＳｔｏｒａｇｅＣｏｎｓｏｌｅ」である。このアプリケーションソフトウエアはストレージシステムにおいてバックアップと復元処理の信頼性を向上させる。Ｎｉｒｖａｎａの提供する「Ｓｔｏｒａｇｅ Ｒｅｓｏｕｒｃｅ Ｂｒｏｋｅｒ」はシステムのユーザが様々な場所に記憶されているファイルを共有し管理することを可能にするソフトウエアである。それにより、大きなデータストレージユニットの様々な場所に記憶されている特定のファイルや情報をユーザが見つけることができるように探索や提示の機能を提供している。

したがって、エラーの可能性を減らしデータ管理の能率を向上するために、システムのユーザが、データ処理プロセスと、データ管理のプロセスの間の関連を完全に観察ができるようにするシステムが求められている。

本発明によるシステムは、異なった形式のデータアプリケーションからデータとデータ処理プロセスについての情報を集める方法を提供するものである。本発明はシステムのユーザがデータ間の関係を識別することを可能にするものである。これによりデータはシステムビューの中で表示され、グラフィカルユーザインタフェースを用いてシステムの中に記憶されているデータ間の関係を説明することができる。情報を記憶するための一連のストレージデバイスを持つストレージシステムにおいて、本発明によるデータマネージャがそこに記憶されたデータやファイルの間の関係について情報を収集するものであり、そのことをユーザに提示しようとするものである。

本発明の好適な一実施例においては、グラフィカルユーザインタフェースは、データ処理プロセスの３種類の異なった表示から選択をするオプションをユーザに提供するものである。これらは、たとえば、特定のファイルがどこにアーカイブされ、レプリケーションされ、あるいはバックアップされているかを表示することにより、どのようにデータが相互に関連しているかを説明するデータビューを含んである。システムはまた、たとえばストレージシステムのどのボリュームがオリジナルデータやアーカイブされたデータやレプリケーションされたデータやバックアップされたデータを持っているかを表示して、どのようにデータボリュームが関連しているかを説明するストレージビューを提供するものである。

ストレージシステムにおける情報の第３のビューはパスビューと呼ばれるものである。パスビューは、たとえばどのポートやスイッチやストレージが特定のファイルや他のデータを扱っているかを表示することなどの様々なデータ処理プロセスによりどのようにしてデータがシステムを通して転送されるかを説明している。さらに、本発明によるシステムはバックアップデータの量をオリジナルデータの量と比較することによりバックアップデータの構成の誤りを検出する方法を提供する。

一実施例では、レプリケーションサーバとバックアップサーバとアーカイブサーバを持つストレージシステムはさらに３種類のアプローチのうち、少なくとも２種類において記憶されたデータを追跡するデータマネージャを含んでいる。ひとつのアプローチにおいては、記憶されたデータのレプリケートされた、バックアップされた、あるいはアーカイブされたコピーのなかでのファイル名の関係を提示することで、記憶されたデータを追跡する。第２のアプローチにおいては、たとえばボリュームという単位で、ストレージシステム内の物理的な位置が提示される。第３のアプローチでは、ストレージ位置にデータを到着させる処理について述べたパス情報が記憶されたデータのレプリケートされた、あるいはバックアップされた、あるいはアーカイブされたコピーについて提供される。

図１は複雑なコンピュータ環境において見られるであろう仮想した一般のストレージシステムを説明するブロックダイアグラムである。図１に示すシステムのコンポーネントの大部分はよく知られているものであり、したがってここでは簡単な説明とする。しかしながら、データマネージャ１１１はよく知られてはいないので、以下詳細に説明する。

図１に示すシステムは２台のアプリケーションサーバ１０１と１０２を含んでいる。これらのサーバはシステム全体のユーザにコンピューティング資源を提供するためにコンピュータプログラム１０１ａと１０２ａを実行する。記憶されたプログラムを実行することで、アプリケーション１０１ａと１０２ａは図１に示すシステムに記憶されるデータを生成する。

レプリケーションサーバ１０３はよく知られたミラーリング機能を提供するためにストレージシステム内で異なるストレージシステムあるいはボリュームにデータをレプリケーションする。レプリケーションサーバは以下に論じるように、レプリケーションカタログ１０６を保持する。同様に、バックアップサーバ１０４は、後のデータにハードウエア、ソフトウエアあるいは設備不良が万一発生した場合に備え、データの復元を可能にするためのデータバックアップ機能を提供する。以下同様に論じるように、バックアップカタログ１０７はバックアップ動作の記録を保持する。

多くの大型のストレージシステムはまた階層的なストレージマネージャあるいはアーカイブサーバ１０５を含んでいる。サーバ１０５は、システムの性能を向上し、低コストのメディア上にデータを保持してコストを低減するために、小さな使用済みのデータをプライマリストレージエリアからセカンダリストレージエリアにアーカイブする。他のサーバと同様に、アーカイブサーバ１０５は、以下でさらに説明するように、アーカイブカタログ１０８を保持する。サーバ１０１から１０５はそれぞれがあたかも独立したハードウエア設備であるかのように論じてきたが、これは必要ではない。サーバは単一の大規模コンピュータ上で実行される別個のプロセスとして実行するか、あるいは接続されたコンピュータのアレイ内の別個のプロセッサー上で実行される別個のプロセスとして実行される。

図１に示されるシステムはストレージエリアマネージャ１０９も含む。ストレージエリアマネージャは、好適には、サーバとストレージシステム１１５と１１６と１１７を含む、図１に示された全ネットワークを管理する管理サーバである。ストレージエリアマネージャは以下でも論じるデバイスカタログ１１０を保持する。要は、ストレージエリアマネージャは、スイッチ１１４やサーバ１０１−１０５やアプリケーション１０１ａと１０２ａから情報を検索することができる。図１に示したようなストレージエリアマネージャはしばしば「ＤＭＴＦ」の「ＣＩＭ」のような標準的なプロトコルを用いて運用される。ストレージエリアマネージャを運用するもう一つの方法は、エージェントをサーバ上に設定し、そのエージェントにサーバの局所についての情報を集めさせ、それをストレージエリアマネージャに提供するものである。

図１に示すように、システムを相互接続するために一般に用いられる技術は種々あるが、スイッチ１１４がますます一般的な接続技術になってきている。これらのスイッチは一般的にはファイバチャネル（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）やイーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））あるいはブロードバンド技術を基本にしたスイッチである。

システムのサーバ動作の結果システムが受け取ったあるいは生成したデータはストレージシステム１１５や１１６や１１７のようなストレージシステムに記憶される。このようなストレージシステムのそれぞれには、ディスクコントローラ１１８と１１９と１２０がデータを記憶するハードディスクドライブ１１８ａ−１２０ｂと同様にそれぞれ含まれている。簡単にするため、図１ではストレージシステム当たりに２台のディスクドライブのみが示されている。しかしながら従来の運用では、ストレージシステムにおいては数百台のディスクドライブが使用されているかもしれない。ディスクコントローラ１１８と１１９と１２０は、データをハードディスクドライブに記憶し、またそこから検索するためにサーバから発行される入出力リクエストを制御する。

説明のために、図１には３種類の異なった形式のストレージシステムが示されている。ストレージシステム１１５はエンタプライズ・ファイバチャネル・ストレージシステムである。このようなシステムは一般的にサーバとストレージシステムとの間のデータプロトコルとしてＳＣＳＩをサポートする。ニアラインＰＣ（ＮｅａｒｌｉｎｅＰＣ）ストレージシステム１１６は、しかしながら、ＡＴＡフォーマットのハードディスクドライブを用いて同様に動作する。最後に、ネットワーク結合ストレージ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）システム１１７はファイルプロトコルとして「ＮＦＳ」と「ＣＩＦＳ」をサポートする。このように、図１で示したように、本発明のシステムはいかなる形式のストレージシステムにも適用可能である。

図１に示すコンポーネントとシステムは二つの技術を用いて相互に接続されている。ネットワーク１００は、たとえばＴＣＰ／ＩＰ／イーサネット（登録商標）に基づいて「バンド外の」通信を行うために提供される。しかしながら、ストレージシステムに関する主たるデータ処理については、特定の動作を実行するために必要となる所望のコンポーネント間の相互接続を可能にするスイッチ１１４により提供される。

本発明のシステムは、図１のシステム全体に対して、ここではデータマネージャと呼ばれる追加のコンポーネントを加えている。このデータマネージャはローカルエリアネットワーク１００とスイッチ１１４を経由して他のコンポーネントと交信する。データマネージャはアプリケーションとデータアプリケーションからデータ処理プロセス情報を取得し、その結果をユーザに提供するように機能する。一般的には、結果はコンソール１１３上で稼働中のグラフィカルユーザインタフェースを通して提供される。データマネージャはデータカタログを保持する。データカタログにより、データマネージャはストレージシステムの各種の「ビュー」をユーザに提供することができる。たとえば、データマネージャ１１１とデータカタログの双方により、ユーザが、各種のファイルが記憶されている物理的位置や情報が記憶されるパスやストレージシステム１１５、１１６および１１７に記憶されているデータ間の他の関係についての情報を見ることができる。データマネージャ１１１はデータ記述子や、関係記述子やディスカバリーデータテーブル（下記で論じる）やディスカバリー関係テーブル（これも下記で論じる）を生成し管理する。一般的にこれらのテーブルは、データマネージャに接続されたローカルストレージあるいはネットワークストレージに記憶される。データマネージャは下記に論じるディスカバリー構成テーブルも使用する。データマネージャ自身はコンソール１１３により構成されることもできる。データマネージャは図１に示されるシステムを通して生成され保存されたカタログに依存する。これらのカタログは次に論じる。

図２はアーカイブプロファイルに対するアーカイブカタログを説明する図である。このカタログは図１に示すカタログ１０８内に含まれている。図２に示すカタログ２００は、どのデータを、何時、どのストレージにアーカイブするかを説明している。図２に示す例では、データはもし３０日以内にアクセスされない場合は、アーカイブされる。アーカイブ予定のデータは「Ｆｏｌｄｅｒ」として記述され、それをアーカイブするメディアは「Ａｒｃｈｉｖｅ Ｍｅｄｉａ」としてリストされる。

図３はメディア情報に関するアーカイブカタログを説明する。このカタログはまた図１に示すカタログ１０８内に含まれる。図３の例においては、「Ａｒｃｈｉｖｅ Ｍｅｄｉａ」は実際には特定のサーバに関連した特定のアドレスを持つ「Ａｒｃｈｉｖｅ Ｆｏｌｄｅｒ」であることを説明する。図３はまた「Ｆｏｌｄｅｒ」がそこに示されたような最大容量を持つことを説明する。

図４はアーカイブデータに対するアーカイブカタログを説明する図である。このカタログは図１に示すカタログ１０８内に含まれている。図４の例においては、示された「Ｓｏｕｒｃｅ Ｄａｔａ」は、図４に示す「Ａｒｃｈｉｖｅ Ｔｉｍｅ」において「Ａｒｃｈｉｖｅ Ｓｔｒｅａｍ」として指定されたメディアにアーカイブされているとして表示されている。

図５から図７は、図１のカタログ１０７として記憶されているバックアップカタログを説明する。図５においては、バックアッププロファイルに対するバックアップカタログの例が示されている。このカタログはデータがどのようにして、何時バックアップされるべきかを説明している。説明された例においては、「Ｓｏｕｒｃｅ」により指定されたフォルダーにあるファイルは決められた「Ｂａｃｋｕｐ Ｔｉｍｅ」において「Ｂａｃｋｕｐ Ｍｅｄｉａ」にバックアップされることになる。「Ｂａｃｋｕｐ Ｔｙｐｅ」は全てのファイルがバックアップされることを示し、一方「Ｎｅｘｔ Ｂａｃｋｕｐ Ｔｉｍｅ」は次のバックアップ動作の日時を示す。

図６はメディア情報に関するバックアップカタログを説明する図である。図３と同様な方法で、指定された特定のメディアの物理位置を容量と併せて説明している。

図７はバックアップデータに関するバックアップカタログを説明している。このカタログはデータがどのようにして、何時バックアップされるべきかを説明している。示されている例では、「Ｄａｔａ Ｓｏｕｒｃｅ」により指定された２個のファイルが示された時刻に「Ｂａｃｋｕｐ Ｍｅｄｉａ」にバックアップされている。

図８はストレージシステムにおいて２台の装置の間のレプリケーション関係を説明する図であって、レプリケーションカタログと呼ばれている。この図は図１のレプリケーションカタログ１０６に関して追加の情報を提供する。レプリケーションカタログは、ストレージシステムにおいて一般に「ＬＤＥＶ」として知られる２個のデータストレージ位置の間の関係を説明している。図８に示すように、プライマリストレージのデータはセカンダリストレージ位置へレプリケートされる。「Ｍｏｄｅ」はバックアップが同期方式か非同期方式かを表示する。

図９はボリュームに関するデバイスカタログを説明する図であって、図１０から図１３は他のデバイスカタログを説明し、これら全ては図１のカタログ１１０に収容されている。図９に示すボリュームカタログ２０７はボリュームのＩＤ、名称、アドレス、ポート、論理ユニットナンバーなどを含んでいる。

図１０はストレージに関するデバイスカタログ２０８を説明する。このカタログはストレージシステムに関する情報を提供する。図に示されているように、カタログはＩＤや名称やアドレスや容量やストレージに結合しているポートに関する情報などを含んでいる。

図１１はファイルシステムに関するカタログ２２０を説明している。そこに示されているように、カタログはＩＤや物理ボリューム位置やファイルシステムの形式や空き領域などについての情報を含んでいる。同様に図１２はパス２２１についてのデバイスカタログを説明している。このカタログはＩＤ情報とワールドワイドの名称ＩＤを含んでいる。

図１３はアプリケーションについてのデバイスカタログ２２２である。図１３に示すように、カタログはＩＤとアプリケーション形式とホスト名と関連したデータファイルを含んでいる。

図１４と１５はメッセージベースのアーカイブについてのアーカイブカタログを説明している。（図２から図４はファイルベースのアーカイブについてのアーカイブカタログを説明している。）メッセージベースのアーカイブにおいて、アーカイブはアプリケーションレベルで実行される。たとえば、電子メールサーバはメッセージをデータファイルに記憶し、つぎにアーカイブサーバは電子メールサーバと交信し、データファイルの代わりにメッセージ自身をアーカイブする。これらの環境においては、アーカイブプロファイルはまたサーバの名称とアプリケーションの名称を示す。

図１４は今説明したケースについてアーカイブプロファイルに関するアーカイブカタログ２２３を説明している。示されているように、アプリケーションはＡとしてメディア名ＭＮやメディアとタイミング情報とともに示される。メディア情報自身は図３に関連して説明されたのと同じ方法でアーカイブされる。

図１５はアーカイブデータに関するアーカイブカタログ２２４を説明している。上述のように、「Ｓｏｕｒｃｅ Ｄａｔａ」はファイルに代わる特定のメッセージを指定する。「Ｓｅｒｖｅｒ Ｎａｍｅ」とメディア、データ、時刻についての情報もまた提供される。

図１６は、説明を明確にするための例としてこのアプリケーションの残りにおいて用いられているシステム構成の例を説明している。図１６に示すように、いくつかのサーバ２３０は図の上部の横方向で表され、アプリケーションサーバとアーカイブサーバとバックアップサーバとレプリケーションサーバを含んでいる。サーバの２台はイーサネット（登録商標）リンクで接続されている。図の中央部では、２台のスイッチ２３１は各種のサーバを各種のストレージシステム２３２に結合する。レプリケーションサーバは「Ｅｎｔｅｒｐｒｉｓｅ Ｓｔｏｒａｇｅ Ａ」に結合して、そのストレージシステムでレプリケーションを可能にしている。アプリケーションサーバ２３０はデータをＬＤＥＶ１に記憶し、一方アーカイブサーバはデータのいくつかをＬＤＥＶ２にアーカイブする。レプリケーションサーバはストレージユニットＡにＬＤＥＶ１からＬＤＥＶ３にレプリケーションをするように要求し、それに応じて処理が行われる。バックアップサーバはデータをＬＤＥＶ３からＬＤＥＶ４にバックアップする。

図１に関連して説明したデータマネージャを持たない従来システムでは、上記に説明した各種カタログは全て別々であり、ユーザはストレージシステムにより管理されているデータとファイルの全体的な関係を見ることができない。しかしながら、データマネージャを付加することにより、たとえばスクリプトや他のよく知られたインタフェースを用いることで各種サーバとデータマネージャ間の交信ができるようになる。データマネージャと各種サーバとの間の交信により、次に論じるように、これらの関係が見つかりユーザに提供される。

図１７はデータ記述子テーブル２４０の例を説明している。このテーブルはデータマネージャ１１１（図１参照）がストレージシステムとサーバにより処理されているデータについて集めた情報を説明している。図１７に示すように、データ記述子テーブルはディスカバードデータの特定のユニットについての重要な情報を含んでいる。それは、たとえばそのデータに関連するホスト名やパス名やデータの「オーナ」やデータへのアクセスや書き換えに関する何らかの制約や大きさや生成時刻や修正時刻や最後のアクセスの時刻やアクセスの回数などを含む、データについての論理情報も含んでいる。データ記述子はまたマウントポイント（データが位置している）やデータに関連したファイルシステムの形式やそのファイルシステムの最大の大きさについての情報を含んでいる。最後に、データ記述子は、ストレージシステムのブランド名（Ｌｉｇｈｔｎｉｎｇ ９９００）やそのＩＰアドレスやそのＬＤＥＶなどを含むデータについての物理情報を含んでいる。物理情報はまた、最大ボリュームの大きさやＲＡＩＤプロテクションのレベルなどを含むことができる。

一般的に言えば、論理情報は、どのサーバがデータを持っており、そのサーバ内における論理位置とアクセスコントロール情報を、大きさや記憶されたデータについての他のパラメータと同様に含んでいる。また一般的には、ファイルシステム情報はデータが記憶されているファイルシステムの形式を記述する。物理情報は、特定のファイルシステムが生成されているストレージシステムとＬＤＥＶについて記述する。

図１８から図２２はストレージシステムに記憶されたデータ間の関係を設定することに役立つ関係記述子テーブルを説明している。図１８はアーカイブに関する関係記述子テーブル２４１の例である。テーブルは記述子のＩＤやそのオリジナルデータとの関係やオリジナルデータ記述子やアーカイブデータ記述子やアーカイブ時刻や保存期間などについての情報を含んでいる。関係記述子はディスカバードデータがどのように関係しているかを示し、固有のＩＤ（ＲＩＤ）を割り当てる。

図１９はそこに示されたように、バックアップのための関係記述子を提供している。テーブル２４２は特定のアドレスのオリジナルデータがそのアドレスにおいて指定されたデータとしてバックアップされていることを説明している。バックアップの日付、時刻、速度やその他のパラメータもまた保持される。

図２０はレプリケーションに対する関係記述子テーブル２４３である。このテーブルは、提供されている他の情報に追加して、それらの世界的なＩＤに基づいてオリジナルデータとレプリケーションされたデータの間の関係を保持している。

図２１はアプリケーションに対する関係記述子テーブル２４４である。このテーブルに示すように、Ｔｒｉｎｉｔｙサーバの電子メールサーバは指定された世界的なＩＤナンバーにより特定されたデータソースを持っている。

図２２のテーブル２４５に示すように、メッセージベースシステムにはアーカイブに対する関係記述子がある。各メッセージについてデータ記述子と関係記述子を生成すると資源を消費してしまうので、メッセージベースのアーカイビングではオリジナルデータとアーカイブされたデータとの間の関係のみが識別される。もちろん、必要であれば、データ記述子は生成可能である。

データマネージャ１１１はまたサーバとの相互作用に基づいて、いくつかのテーブルを生成する。これらのテーブルはここでは図２３に示すディスカバリー構成テーブル２８０や、図２４に示すディスカバードデータテーブル４２０や図２５に示すディスカバード関係テーブル４３０を指すものである。これらのテーブルは次に議論される。

図２３に示すディスカバード構成テーブル２８０はデータマネージャがどのアプリケーションとデータアプリケーションから情報を集めたかを示している。テーブルの行で構成されている各エントリーは、ディスカバードデータの形式や、情報の収集元のサーバや、アプリケーションあるいはデータアプリケーションの名称や、必要に応じてアクセスを行うためのＩＤとパスワード情報を指定する。たとえば、テーブル２８０の第１行では、アプリケーションプログラムはアプリケーション「ＳＡＭＳｏｆｔ」を使用してサーバＥから情報を集め、これには行の末尾に示されたＩＤとパスワード用いてアクセスすることができる。

図２４はディスカバードデータテーブル４２０を説明する。このテーブルはディスカバードデータについての管理情報を提供する。このテーブルで示すように、データはストレージシステムとＬＤＥＶと相対パス名の組み合わせで個別に識別される。ストレージシステムに記憶されるファイルはファイルシステムを用いて記憶されている。ファイルシステムがサーバのフォルダー上にマウントされているときは、相対パス名としては、パス名の代わりにファイルシステム内のパス名を提供する。たとえば、ＬＤＥＶ１がサーバの＼ｆｏｌｄｅｒ１にマウントされていると仮定する。また、＼ｆｏｌｄｅｒ２＼ｆｉｌｅＡというパス名のファイルがあると仮定する。このようにして、相対パス名はＦｉｌｅＡとなる。

図２５はディスカバード関係テーブル４３０を説明している。このテーブルはディスカバード関係の識別について管理をする。説明された例では、「ＲＩＤ ０００２」により識別された関係はバックアップ関係であり、列の「Ｓｏｕｒｃｅ」に表示されているＧＩＤを持つファイルは「Ｄｅｓｔｉｎａｔｉｏｎ」の列により識別されるデータとしてバックアップされている。バックアップやアーカイブやレプリケーション動作が２カ所の位置のデータに係わるのに対し、アプリケーション自身はソースデータを持つのみである。したがって、「Ｄｅｓｔｉｎａｔｉｏｎ」は適用できない。

上記で論じたテーブルの全てと生成された各種の関係を用いて、下記で詳細に論じる方法においては、システムは関連したストレージシステムに記憶されたデータ間の関係に関する総合的な展望を提供することができる。ストレージシステムのユーザにこれらの関係を提示するためのグラフィカルユーザインタフェースの例が図２６、２７および２８に示されている。ストレージシステムにおけるデータをよりよく理解できるように他のグラフィカルユーザインタフェース（ＧＵＩ）を生成してユーザに提示できることは当然理解されることである。これらのインタフェースは、一般的にはデータ管理システムの管理者にとって、最も役に立つものである。一般的には、これらのインタフェースは図１に示すコンソール１１３上に提示されるものである。一般的なＧＵＩは次で論じる。

図２６は「データビュー」ＧＵＩ２５０を説明している。このＧＵＩの例では、データマネージャはデータ自身に関連したビューを提示している。説明した実施例では、ＧＵＩは図の左側のデータ指定パネルと右側の情報パネルの２個のパーツを持っている。データ指定パネルはこれのアプリケーションで使用されているシステムの全てのアプリケーションと全てのデータを示している。たとえば、図２６においては、指定パネルは電子メールアプリケーションとこれらのアプリケーションの中の電子メールサーバをリストする。その電子メールサーバは、この例では、Ａ、ＢおよびＣとして示されているいくつかのファイルを持っている。ユーザはファイルＡを選択する。それに応じて、ＧＵＩは図２６に示す右側のパネルにあるそのファイルについての情報を説明する。パネルはファイルＡに関連したデータについて関係情報を説明する。パネルの最上部に示すように、サーバとファイルの位置は、アーカイブされ、レプリケートされ、バックアップされたそのファイルの全てのコピーと同様に示される。説明されたように、ファイルＡは指示された位置でサーバＢによりアーカイブされ、指示された位置でサーバＣによりレプリケーションされ、指示された位置でサーバＤによりバックアップされる。「Ｄｅｔａｉｌｓ」の指示をクリックして、ユーザはシステムにそのデータについて「より深い」情報、たとえばその大きさや、イベントの時刻や、上記で論じた記述子テーブルの中で提供されている他の情報などを検索させ、そのデータはＧＵＩ上で提供される。

図２７はデータの「ｓｔｏｒａｇｅ ｖｉｅｗ」についてＧＵＩを説明している。図２７に示す左側のパネルは、図２６で論じたものに対応し、ユーザが特定のファイルを選択できるようにしている。そこで説明されたのと同じ方法で、ユーザはファイルＡを選択し、ストレージビュー２６０の右側のパネルはファイルＡに関する情報を説明する。このパネルはオリジナルデータが記憶されているＬＤＥＶとストレージシステムと、オリジナルデータに関係するデータの全てと、これらの位置の間の関係を示す。たとえば、右側のパネルの上側部分に示したように、レプリカやアーカイブやバックアップ関係が説明されている。

図２８は第３のＧＵＩであってこれによりユーザはストレージシステムにおける各種のデータの位置とデータが処理されるパスをより容易に理解することができる。図２８は「パスビュー」ＧＵＩを説明している。上記図２６と２７において、ＧＵＩ２７０の左側によりユーザは特定のファイルを選択することができ、右手側はオリジナルデータおよびオリジナルデータに関連したデータに対するサーバやスイッチやストレージシステムやＬＤＥＶのトポロジーマップを説明する。この図はまたトポロジーにおいてデータがどのように転送されるかを説明している。図を簡略化するために、図２８の右側のパネルの上側部分の横方向は「ボタン」の連続である。これらのボタンの１個をクリックすると、画面は指定された関係によりデータが転送されるパスを示す。

先の議論ではデータマネージャ１１１により生成され使用される各種のテーブルとシステムのユーザにそのデータを提示するグラフィカルユーザインタフェースについて論じた。この明細書の残りの部分は、システムがこれらのテーブルを設定するために作動し、グラフィカルユーザインタフェースを提示する手法について論じる。

図２９は図１に示すデータデータマネージャによるデータディスカバリープロセスの実施例を説明するフローチャートである。プロセスは図１に示すコンソール１１３でユーザにより開始される。最初のステップ２９０で、データマネージャは、もしエントリーがレプリケーションエントリーでなければ、図２３に示すディスカバリー構成テーブルからエントリーを検索する。もし非レプリケーションエントリーがある場合は、フローは図２９に示すように直ちに下方に向かう。一方では、新しいエントリーが無い場合は、データディスカバリープロセスは、ステップ２９６に示すように、レプリケーションエントリーをディスカバリー構成テーブルから検索する。新しいエントリーがあるとした場合に、データマネージャはサーバの形式をチェックし、図２９のループが示すように、サーバの形式によって三つの手順のうちの一つを実行する。そのエントリーが検索されると、プロセスはステップ２９０に戻り、サーバの全てからエントリーの全てを検索するために必要な回数だけ繰り返される。特定の「ｇｅｔ ｄａｔａ」手順２９３、２９４あるいは２９５の詳細は以下で論じられる。一旦これらの手順が完了すると、システムは元に戻り、ステップ２９６で示されるレプリケーションエントリーをチェックする。レプリケーションエントリーがあると想定した場合は、手順はのちに下記で論じるステップ２９８に移行する。ステップ２９７に示すように一旦全てのエントリーが検索されると、データディスカバリープロセスは完了する。

図３０は図２９のブロック２９３により示されるアプリケーションからデータを取得するプロセスフローをより詳細に説明している。データマネージャはネットワークを経由して、まずＳＡＭサーバに接続する。これはコネクション３００についてディスカバリー構成テーブルのＩＤとパスワードを用いる。つぎにそれはＳＡＭサーバ３０１からアプリケーションのリストを検索し、各アプリケーションについてはステップ３０２に示すようにそのサーバからデータファイルのリストを検索する。ステップ３０３に示すように、そのリスト上の各データファイルについて、データマネージャは、そのＳＡＭサーバにデータファイルが記憶されているファイルシステム名を取得する。つぎに図３０４で示すように、各ファイルシステムに関して、ストレージ名とファイルシステムが生成されているＬＤＥＶもまたＳＡＭサーバから検索される。つぎに、各個別のセット（ストレージシステムの名称、ＬＤＥＶ、データファイル相対パス名）に関連して、データマネージャはディスカバードデータテーブルに新しいエントリーを生成し、そのセットにまだエントリーが無かった場合には、それに新しい世界的なＩＤを割り当てる。ステップ３０６に示すように、このようなＧＩＤのそれぞれにはデータ記述子が生成される。つぎに、ステップ３０７に示すように、各データ記述子について、データマネージャは論理情報やファイルシステム情報や物理情報をSAMサーバから検索し、その情報をデータ記述子テーブルにファイルする。つぎに、ステップ３０８に示すように、各アプリケーションについて、ディスカバード関係テーブルの新しいエントリーが生成され、そのアプリケーションにエントリーが無い場合は、新しいＲ＿ＩＤが与えられる。最後に、ステップ３０９に示すように、各ＲＩＤについて、アプリケーションの関係記述子とファイル情報が続いて生成される。一旦これらのステップが完了すると、プロセスフローは図２９に示す図に戻る。

図３１は、ステップ２９４として図２９で説明されるように、バックアップサーバからデータを検索するプロセスを説明している。一旦このプロセスが呼び出されると、動作は図３０で説明されるものと同様になる。特に、データマネージャはネットワークを経由してまずバックアップサーバに接続する。それは、ステップ３２０に示すように、接続のためにディスカバリー構成テーブルからのＩＤとパスワード情報を使用する。ステップ３２１に示すように、それはまた同じ方法でＳＡＭサーバに接続する。ステップ３２２では、データマネージャはバックアップサーバからバックアッププロファイルのリストを検索する。ステップ３２３で示されるように、そのような各バックアッププロファイルについて、データマネージャはバックアップサーバからバックアップデータのリストを取得する。つぎに、ステップ３２４では、各バックアップデータについて、データマネージャはバックアップストリームが記憶されているファイルシステムをバックアップサーバから検索する。つぎにステップ３２５で示すように、各個別のファイルシステムに関して、ストレージ名とファイルシステムが生成されているＬＤＥＶが、ＳＡＭサーバから検索される。つぎに、ステップ３２６では、各個別のセット（名称とＬＤＥＶとバックアップストリーム相対パス名）について、そのセットにまだエントリーが無い場合には、ディスカバードデータテーブルに新しいエントリーが生成され、新しいＧＩＤが割り当てられる。つぎに、セット３２７では、各ＧＩＤについて、データ記述子が生成される。つぎに、ステップ３２８に示すように、各データ記述子論理情報について、ファイルシステム情報とＳＡＭサーバからの物理情報が検索され、データ記述子テーブルへ渡される。

図３２はステップ３２８に続くプロセスを説明している。図３２に示すように、各バックアップデータについて、データマネージャはステップ３２９でバックアップサーバからデータソースのリストを取得する。つぎに、各個別のデータソースについて、データソースが記憶されているファイルシステムがステップ３３０でバックアップサーバから検索される。ステップ３３１では、各個別のファイルシステムについて、データマネージャはストレージ名とファイルシステムが生成されているＬＤＥＶを同じサーバから検索する。つぎに、ステップ３３２では、各ストレージ名とＬＤＥＶとデータソース相対パス名の個別のセットについて、そのセットにまだエントリーが無い場合には、ディスカバードデータテーブルに新しいエントリーが生成され、新しいＧＩＤが割り当てられる。つぎに、ステップ３３３では、各ＧＩＤについて、データ記述子が生成される。ステップ３３４では、各データ記述子について、論理情報とファイルシステム情報と物理情報が同じサーバから検索されデータ記述子テーブルに記載される。つぎに、ステップ３３６では、各バックアップデータについて、もしそのバックアップデータにまだエントリーがない場合は、ディスカバード関係テーブルに新しいエントリーが生成され、新しいＲＩＤが割り当てられる。最後に、各ＲＩＤに対するステップ３３７では、バックアップ情報に対する関係記述子が生成され、これがディスカバードデータテーブルへ記載される。そのステップは図２９のステップ２９４で概要を説明した、バックアップからデータを取得するステップについての動作を締めくくるものである。

図３３は、図２９のステップ２９５で代表される、アーカイブからデータを取得するステップの背後の詳細を説明している。上記で説明したように、これらの動作は前述のいくつかの図で論じた他のデータ取得の動作と同様である。プロセスはデータマネージャがＩＤとパスワード情報を使用してアーカイブサーバに接続するステップ３４０で開始される。それはまたステップ３４１に示されるＩＤとパスワード情報を用いて同じサーバに接続する。ステップ３４３ではアーカイブプロファイルのリストを取得し、ステップ３４４では各アーカイブプロファイルについてアーカイブデータを取得する。ステップ３４５では、それは、各アーカイブデータついて、アーカイブストリームが記憶されているファイルシステムをアーカイブサーバから検索する。つぎに、ストレージ名とＬＤＥＶとアーカイブストリーム相対パス名の各個別のセットについて、そのセットにまだエントリーが無い場合には、ディスカバードデータテーブルに新しいエントリーが生成され、新しいＧＩＤが割り当てられる。つぎに、ステップ３４８では、各ＧＩＤについて、データ記述子が生成され、最後にステップ３４９では、このような各データ記述子について、ファイルシステム情報からの論理情報とＳＡＭサーバからの物理情報がデータ記述子テーブルに記載される。つぎに、プロセスは図３４により継続する。

ステップ３５０に示すように、各アーカイブされたデータについて、アーカイブサーバからデータソースのリストが検索される。つぎに、個別のデータソースについて、そのデータソースに対するファイルシステムがステップ３５１に示すようにアーカイブサーバから検索される。つぎに、各個別のファイルシステムについて、ストレージ名とファイルシステムが生成されているＬＤＥＶがＳＡＭサーバから検索される。つぎに、ステップ３５３では、ストレージ名とＬＤＥＶとデータソース相対パス名の個別のセットについて、そのセットにまだエントリーが無い場合には、ディスカバードデータテーブルに新しいエントリーが生成され、新しいＧＩＤが割り当てられる。つぎに、各ＧＩＤについて、新しいデータ記述子が生成され、このような各データ記述子について、ＳＡＭサーバから論理情報とファイルシステム情報と物理情報が検索され、ステップ３５５に示すようにデータ記述子テーブルに記載される。つぎに、各アーカイブされたデータについて、そのデータにエントリーがまだ無い場合は、新しいエントリーがディスカバード関係テーブルに生成され、新しいＲＩＤが割り当てられる。最後に、関係記述子がそのＲＩＤについて生成され、データディスカバリーテーブルに記載される。

レプリケーションサーバからデータを取得するプロセスは上述のものと同様である。そのことは図３５に説明されている。プロセスはレプリケーションサーバにＩＤとパスワードにより接続すること３６０、ＳＡＭサーバに接続すること３６１、およびレプリケーションサーバからレプリケーションプロファイルのリストを取得すること３６２のフローを実行する。つぎに、各レプリケーションプロファイルについて、選択された情報がステップ３６３で検索され、このようなレプリケーションセットの各々について、ステップ３６４ではこれらのボリュームに記憶されているデータの位置が確認される。つぎに、見つかったデータセットの各々について、ディスカバード関係テーブルに新しいエントリーが生成され、情報はステップ３６６でテーブルに記載される。これで最初に図２９で示したプロセスの説明が完了する。つぎは、各種データやストレージやパスビューを示す技術である。データビューを示すステップは、図３６のフローチャートで説明される。データビューを示すには、データマネージャは、ステップ３７０で示すように、ＧＵＩからサーバ名とアプリケーション名とデータファイルを受け取る。上記で論じたように、この選択は一般にユーザがＧＵＩの左側のパネルの適切なエントリーを選ぶことにより行われる。つぎに、ステップ３７１で説明するように、特定のデータについてのＧＩＤがディスカバードデータテーブルから検索され、ステップ３７２では、ＧＩＤを含む全てのＲＩＤについてディスカバード関係テーブルからリストが検索される。何もない場合は、ステップ３７６で示すように、見つかったＧＩＤが表示される。もし、ＲＩＤがある場合は、つぎはこのようなＲＩＤの各々について、ステップ３７４に示すように、ディスカバード関係テーブルからＧＩＤとディスティネーションが検索される。一旦これが完了すると、ステップ３７６に示すように、ディスプレイが表れる。

図３７はＧＵＩでストレージビューを見せるためのステップを説明している。図３６で説明したものと同様の方法で、ユーザはステップ３８０で示したように各種の情報を選択し、指定されたデータについてのＧＩＤがディスカバードデータテーブルから検索される。ステップ３８２、３８３、３８４および３８５の動作のフローは図３６のそれと一致している。つぎに、ステップ３８６では、見つかったＧＩＤの各々について、データマネージャはＧＩＤで指定されたデータが記憶されているストレージシステムとＬＤＥＶを見つけ、ストレージは画面上でストレージアイコンとして、ＬＤＥＶは画面上でＬＤＥＶアイコンとして表示する。つぎに、ステップ３８７で説明するように、ＬＤＥＶアイコンは、発見されたＲＩＤの各々について、関係インディケータにより相互に接続されている。

図３８はパスビューＧＵＩが生成される方法を説明するフローチャートである。ステップ３９０から３９５はデータとストレージビューについて上記で説明したものと同じである。ステップ３９６では、発見されたＧＩＤやＲＩＤの全てについて、関係サーバは、発見されたＧＩＤやＲＩＤにより指定されたデータあるいはデータアプリケーションに関連したスイッチやストレージシステムやＬＤＥＶを探索する。このステップに続いて、発見されたハードウエアコンポーネントの全てについての物理トポロジーマップがステップ３９７で表示され、関係ボタンがステップ３９８で追加される。ステップ３９９では、もしボタンが押されると、システムは、指定されたデータが転送され、ＳＡＭサーバによって情報が提供されるデータパスを示す。

図３９は本発明のシステムにより提供される他の機能について説明をするフローチャートである。図３９はバックアップデータの大きさをオリジナルデータの大きさと比較してデータバックアップの誤構成を検出する技術を提供している。図３９に示すプロセスは、図１に示すストレージコンソール１１３を通してユーザにより起動される。起動すると、システムはステップ４００に示すように、ＧＵＩからサーバ名とアプリケーションとデータファイルを受け取る。つぎに、指定されたデータに関するＧＩＤがディスカバードデータテーブルから検索され、そのＧＩＤを含むＲＩＤのリストがディスカバード関係テーブルから検索される。このプロセスはステップ４０３から４０５で示すように全てのＲＩＤとＧＩＤが検索されるまで繰り返される。ステップ４０６では、バックアップストリームの大きさを決めるために、全バックアップをしながら各ＧＩＤについて計算が実施される。そのアプリケーションについてデータファイルの大きさがステップ４０７で計算される。ステップ４０８では、大きさが一致すれば、「無事終了」のメッセージがステップ４０９で表示され、大きさが一致しない場合はステップ４１０でエラーが表示される。エラーを受け取ると、ユーザはエラー調査のバックアップを再実行し、他の方法でそれを解決する。

説明された技術には多くのアプリケーションがある。これらのアプリケーションはバックアップやアーカイブやレプリケーション等に限定されるものではない。本発明はデータを解析し関係を決定する他のアプリケーションや特注のアプリケーションに適用が可能である。本発明はまたローカルファイルシステムあるいはローカルサーバのファイルに限定されるものではない。むしろ、本発明はストレージシステムにおけるボリュームとオブジェクトベースストレージデバイスにおけるオブジェクトあるいはネットワーク結合ストレージシステムにおけるファイルに適用が可能である。それはボリュームに、および自身でボリュームをレプリケーションするストレージシステムに適用が可能である。このようなアプリケーションにおけるデータマネージャは、ストレージシステムあるいはレプリケーションサーバから、どのようにボリュームをレプリケーションするかを決定し、パス情報なしに各ボリュームについてデータ記述子を生成し、さらにレプリケーション関係を用いて関係記述子を生成することができる。ネットワーク結合ストレージの場合では、データは個別にＩＰアドレスやエクスポートされたファイルシステムや相対パス名によって識別される。

ここにおいてはＬＤＥＶがデータの独自性を識別するユーザであるが、他のアプローチが使用されることもある。データマネージャは各データについてハッシュ値を計算をする。つぎに、データマネージャはこのようなデータの論理位置と物理位置をＳＡＭサーバから検索できる。もしデータが異なった位置に関係しているならば、データマネージャはこれらのデータについてデータが同じ（二重のハッシュ値の場合）であると表示する関係記述子を生成できる。これによりユーザはストレージシステム上にどれくらい多くのデータのレプリケーションが存在するかを知り、どのデータを削除できるかを決めることができる。

このデータプロセシングによりデータ間の関係の階層とパフォーマンス情報をチェックすることで、データマネージャはさらに階層のどの位置にパフォーマンスのボトルネックが存在するかを検出することができる。このような場合には、データマネージャは各関係においてパフォーマンス情報を検索し、これらの数値が物理資源で制約されているのか、あるいは他のデータプロセシングあるいはアプリケーションソフトウエアに起因するのかを判定する。データマネージャはまた、ユーザにデータのある部分を指定することによりデータとデータ間の関係を検索する手段を提供する。もしデータマネージャがこのような要求を受け取ると、たとえばグラフィカルユーザインタフェースで説明されているように、データマネージャは指定された情報を含むデータ記述子と関係記述子を見つけ、それを提供できる。

本発明の好適な一実施例に関連して上記に詳細に説明されているが、添付の特許請求の範囲により示されるその範囲を外れることなく発明の実施に際して変形や修正を行うことが可能であることは認められるべきものである。

図１は本発明によるデータマネージャを含む一般的なストレージエリアネットワークについてのシステム構成を説明するブロックダイアグラムである。 図２はアーカイブプロファイルに関するアーカイブカタログを説明する。 図３はメディア情報に関するアーカイブカタログを説明する。 図４はアーカイブされたデータに関するアーカイブカタログを説明する。 図５はバックアッププロファイルに関するバックアップカタログを説明する。 図６はメディア情報に関するバックアップカタログを説明する。 図７はバックアップデータに関するバックアップカタログを説明する。 図８はレプリケーションカタログを説明する。 図９はボリュームに関するデバイスカタログを説明する。 図１０はストレージに関するデバイスカタログを説明する。 図１１はファイルシステムに関するデバイスカタログを説明する。 図１２はパスに関するデバイスカタログを説明する。 図１３はアプリケーションに関するデバイスカタログを説明する。 図１４はアーカイブプロファイルに関するアーカイブカタログを説明する。 図１５はアーカイブされたデータに関するアーカイブカタログを説明する。 図１６はストレージシステムにおける相互接続の一例を示すブロックダイアグラムである。 図１７はデータ記述子を説明する。 図１８はアーカイブされたデータに関する関係記述子を説明する。 図１９はバックアップデータに関する関係記述子を説明する。 図２０はレプリケーションデータに関する関係記述子を説明する。 図２１はアプリケーションデータ関する関係記述子を説明する。 図２２はアーカイブされたデータに関するもう一つの関係記述子を説明する。 図２３はディスカバード構成テーブルを説明する。 図２４はディスカバードデータテーブルの例である。 図２５はディスカバード関係テーブルの例である。 図２６はデータのビューに関するＧＵＩの例である。 図２７はストレージシステムのビューに関するＧＵＩの説明である。 図２８はパス情報のビューに関するＧＵＩの例である。 図２９はデータディスカバリーに関する処理の説明である。 図３０は図２９に示された「Ｇｅｔ Ｄａｔａ Ｆｒｏｍ Ａｐｐ」処理の詳細を説明する。 図３１は図２９に示された「Ｇｅｔ Ｄａｔａ Ｆｒｏｍ Ｂａｃｋｕｐ」処理の詳細を説明する。 図３２は図２９に示された「Ｇｅｔ Ｄａｔａ Ｆｒｏｍ Ｂａｃｋｕｐ」処理のさらに詳細な説明をする。 図３３は図２９に示された「Ｇｅｔ Ｄａｔａ Ｆｒｏｍ Ａｒｃｈｉｖｅ」処理の詳細を説明する。 図３４は図２９に示された「Ｇｅｔ Ｄａｔａ Ｆｒｏｍ Ａｒｃｈｉｖｅ」処理のさらに詳細な説明をする。 図３５は図２９に示された「Ｇｅｔ Ｄａｔａ Ｆｒｏｍ Ｒｅｐｌｉｃａ」処理の詳細を説明する。 図３６はデータビューを示すためのステップを説明するフローチャートである。 図３７はストレージビューを示すためのステップを説明するフローチャートである。 図３８はパスビューを説明するためのステップを説明するフローチャートである。 図３９はバックアップ動作をチェックするためのステップを説明するフローチャートである。

符号の説明

１００……ネットワーク、１０３……レプリケーションサーバ、１０４……バックアップサーバ、１０５……アーカイブサーバ、１０６，２０６……レプリケーションカタログ、１０７，２０３〜２０５……バックアップカタログ、１０８，２００〜２０２，２２３，２２４……アーカイブカタログ、１０９……ストレージエリアマネージャ、１１０……デバイスカタログ、１１１……データマネージャ、１１２……データカタログ、１１３……コンソール、１１５，１１６，１１７……ストレージシステム、１１８ａ，１１８ｂ，１１９ａ，１１９ｂ，１２０ａ，１２０ｂ……ハードディスクドライブ、２０７，２０８，２２０〜２２２……デバイスカタログ，２４０……データ記述子、２４１〜２４５……関係記述子、２５０……データビューＧＵＩ、２６０……ストレージビュー、２７０……パスビューＧＵＩ、２８０……ディスクカバード構成テーブル、４２０……ディスクカバードデータテーブル、４３０……ディスクカバード関係テーブル。

Claims (8)

1. アプリケーションが実装されたアプリケーションサーバと、
   論理的な記憶領域であるＬＤＥＶを有し、前記アプリケーションサーバの前記アプリケーションが生成したファイルを前記ＬＤＥＶ内に記憶するストレージシステムと、
   前記ストレージシステムに記憶された前記ファイルのＬＤＥＶ単位でのレプリケーションを前記ストレージシステム内に生成するレプリケーションサーバと、
   前記ストレージシステムに記憶された前記ファイルを前記ストレージシステムにファイル単位でバックアップするバックアップサーバと、
   前記ストレージシステムに記憶された前記ファイルを前記ストレージシステムにファイル単位でアーカイブするアーカイブサーバと、
   前記アプリケーションサーバ、前記アーカイブサーバ及び前記バックアップサーバの各々からファイル処理プロセスに関する情報を含むファイル処理プロセス情報を収集し、前記レプリケーションサーバからＬＤＥＶ処理プロセスに関する情報を含むＬＤＥＶ処理プロセス情報を収集するデータマネージャと、
   所定のグラフィカルユーザインタフェースを表示するコンソールと
   を備え、
   前記データマネージャは、
   前記アーカイブサーバ、前記バックアップサーバのいずれかから前記ファイル処理プロセス情報を収集する場合、
   収集した前記ファイル処理プロセス情報に基づいて、前記ストレージシステムに記憶されているファイルごとに、当該ファイルが記憶されている前記ストレージシステムの名称と、当該ファイルが記憶されているＬＤＥＶ名称と、相対パス名との組み合わせに対して第１の識別子を割り当て、
   バックアップ元又はアーカイブ元のファイルと、バックアップ先又はアーカイブ先のファイルとの間の関係を表す関係情報に対して固有の第２の識別子を割り当てることによってファイルを管理し、
   前記レプリケーションサーバから前記ＬＤＥＶ処理プロセス情報を収集する場合、
   レプリケーション元と、レプリケーション先とを取得し、
   レプリケーション元のＬＤＥＶに格納されたファイルと、レプリケーション先のＬＤＥＶに格納されたファイルとを取得し、
   当該取得したファイル間の関係を表す前記関係情報に対して固有の前記第２の識別子を割り当てることによってファイルを管理し、
   ユーザによってファイルの開示が指示された場合、
   指定されたファイルに付与された前記第１の識別子を含む前記関係情報に割当てられた前記第２の識別子を取り出し、
   当該取り出した第２の識別子に基づいて、当該指定されたファイルと関係する他のファイルの前記第１の識別子を取得し、
   前記指定されたファイル、前記他のファイル、及び第２の識別子で表される前記指定されたファイルと前記他のファイルとの前記関係情報を、前記グラフィカルユーザインタフェースを介してユーザに提示する
   ことを特徴とするシステム。
2. 前記ファイル処理プロセス情報及びＬＤＥＶ処理プロセス情報は、前記ストレージシステムにおいてファイルが記憶されている位置を示す位置情報を含む
   ことを特徴とする請求項１に記載のシステム。
3. 前記位置情報は、
   前記ファイルについてのレプリケーション位置とアーカイブ位置とバックアップ位置の少なくとも一つの位置を示す情報を含む
   ことを特徴とする請求項２に記載のシステム。
4. 前記ファイル処理プロセス情報及びＬＤＥＶ処理プロセス情報は、
   前記ファイルが格納されている前記ＬＤＥＶへのパスを識別するパス情報を含み、
   前記パス情報は、
   前記ファイルを見つけるためのポートとスイッチ情報を含む
   ことを特徴とする請求項１に記載のシステム。
5. 前記データマネージャは、
   前記ファイルの大きさを前記ファイルのバックアップファイルの大きさと比較して前記関係情報に格納されているファイルの間の関係の誤構成を検出する
   ことを特徴とする請求項１に記載のシステム。
6. 前記コンソールは、前記グラフィカルユーザインタフェースとして、
   前記ストレージシステム内の前記ファイルが記憶されている位置と、前記ファイルが処理されるパスとを提示するパスビューを表示する
   ことを特徴とする請求項１に記載のシステム。
7. 前記コンソールは、前記グラフィカルユーザインタフェースとして、
   前記パスビューの他に前記ファイルについての前記関係情報を提示するデータビューと、前記ファイルが記憶されている前記ストレージシステム及び当該ストレージシステム内の前記ＬＤＥＶと、前記ファイルに関係する他のファイルと、これらのファイルが記憶されている位置の間の関係を提示するストレージビューとを表示でき、前記パスビュー、前記データビュー及び前記ストレージビューのうちのユーザによって選択された前記パスビュー、前記データビュー又は前記ストレージビューを表示する
   ことを特徴とする請求項６に記載のシステム。
8. アプリケーションが実装されたアプリケーションサーバと、
   論理的な記憶領域であるＬＤＥＶを有し、前記アプリケーションサーバの前記アプリケーションが生成したファイルを前記ＬＤＥＶ内に記憶するストレージシステムと、
   前記ストレージシステムに記憶された前記ファイルのＬＤＥＶ単位でのレプリケーションを前記ストレージシステム内に生成するレプリケーションサーバと、
   前記ストレージシステムに記憶された前記ファイルを前記ストレージシステム内にバックアップするバックアップサーバと、
   前記ストレージシステムに記憶された前記ファイルを前記ストレージシステムにファイル単位でアーカイブするアーカイブサーバと、
   前記アプリケーションサーバ、前記アーカイブサーバ及び前記バックアップサーバの各々からファイル処理プロセスに関する情報でなるファイル処理プロセス情報を収集し、前記バックアップサーバからＬＤＥＶ処理プロセスに関する情報でなるＬＤＥＶ処理プロセス情報を収集するデータマネージャと、
   所定のグラフィカルユーザインタフェースを表示するコンソールと
   を備え、
   前記データマネージャが、
   前記ファイルがバックアップされたときの前記ストレージシステムにおいてファイルが記憶された位置、前記ファイルがアーカイブされたときの前記ストレージシステムにおいてファイルが記憶された位置のいずれか一つの位置を記憶し、指定のファイルががバックアップされたときの前記ストレージシステムに記憶されたファイルへのパス、また、指定のファイルがアーカイブされたときの前記ストレージシステムに記憶されたファイルへのパスのいずれかひとつのパスを記録し、指定のファイルがバックアップされたときの前記ファイルとバックアップされ前記ストレージシステムに記憶されたファイルとのファイルの関係を、また、指定のファイルがアーカイブされたときの前記ファイルとアーカイブされ前記ストレージシステムに記憶されたファイルとのファイルの関係を記録する第１のステップと、
   指定のＬＤＥＶがレプリケーションされたときの前記ストレージシステムにおいてＬＤＥＶが記憶された位置及び当該指定されたＬＤＥＶ内に格納された前記ファイルを記憶し、指定のＬＤＥＶがレプリケーションされたときの前記ストレージシステムに記憶されたＬＤＥＶ内に格納された前記ファイルへのパスを記録し、指定のＬＤＥＶがレプリケーションされたときの前記ＬＤＥＶ内に格納された前記ファイルとレプリケーションされ前記ストレージシステムに記憶されたＬＤＥＶ内に格納された前記ファイルとのファイルの関係を記録する第２のステップと、
   前記アーカイブサーバ、前記バックアップサーバのいずれかから前記ファイル処理プロセス情報を収集する場合、第１のステップにおいて記録されたファイルの情報を収集し、収集した前記ファイルに基づいて、前記ストレージシステムに記憶されているファイルごとに、当該ファイルが記憶されている前記ストレージシステムの名称及びＬＤＥＶの名称と、相対パス名との組み合わせに対して第１の識別子を割り当て、さらに、前記第１の識別子に基づいて、前記ファイルがバックアップ又はアーカイブされたファイルのときは、バックアップ元又はアーカイブ元のファイルと、バックアップ先又はアーカイブ先のファイルとの間の関係を表す関係情報に対して固有の第２の識別子を割り当てることによってファイルを管理する第３のステップと、
   前記レプリケーションサーバから前記ＬＤＥＶ処理プロセス情報を収集する場合、第２のステップにおいて記録されたＬＤＥＶ及び当該ＬＤＥＶに格納されたファイルの情報を収集し、前記第１の識別子に基づいて、レプリケーション元の前記ＬＤＥＶに格納されたファイルと、レプリケーション先の前記ＬＤＥＶに格納されたファイルとの間の関係を表す関係情報に対して固有の前記第２の識別子を割り当てることによってファイルを管理する第４のステップと、
   ユーザによってファイルの開示が指示された場合、
   指定されたファイルに付与された前記第１の識別子を含む前記関係情報に割当てられた前記第２の識別子を取り出し、
   当該取り出した第２の識別子に基づいて、当該指定されたファイルと関係する他のファイルの前記第１の識別子を取得し、
   前記指定されたファイル、前記他のファイル、及び第２の識別子で表される前記指定されたファイルと前記他のファイルとの前記関係情報を前記グラフィカルユーザインタフェースを介してユーザに提示する第５のステップと
   を備えることを特徴とするシステム。