(57)【要約】【課題】  データ価値とストレージコストの双方を考慮して、適切な保存場所を自動的に定めるシステムを提供することが重要である。【解決手段】  メタデータ管理要素、データ価値管理ユニット、及び階層型ストレージ管理要素から成るメタデータサーバは、システム内の各データオブジェクトに対してデータ価値を計算し、システム内の各ストレージ領域に対してストレージコスト値を割り当て、計算されたデータ価値と割り当てられたストレージコスト値を同一の区分になるように正規化し、正規化済データ価値を正規化済ストレージコスト値と比較して、それによりデータオブジェクトを別のストレージ領域に再配置すべきかどうかを決定し、データオブジェクトをデータオブジェクトのデータ価値と同じストレージコスト値を持つストレージ領域に再配置する。【選択図】図１
2006031668.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションサーバと、
ＬＡＮ（ローカルエリアネットワーク）を通して前記複数のアプリケーションサーバに結合するメタデータサーバと、
複数のデータフローパスにより結合する複数のストレージデバイスと、
前記複数のストレージデバイスを前記複数のアプリケーションサーバと前記メタデータサーバに結合するストレージネットワークと、
から成り、
前記メタデータサーバは、メタデータ管理要素、データ価値管理ユニット、及び階層型ストレージ管理要素で成る、
ことを特徴とする階層型ストレージデータ管理システム。
【請求項２】
前記複数のストレージデバイスは、
複数のオンラインストレージデバイス、
複数のニアラインストレージデバイス、
複数のオフラインストレージデバイス、
の少なくとも一つで成る、ことを特徴とする請求項１の階層型ストレージデータ管理システム。
【請求項３】
前記アプリケーションサーバは前記ＬＡＮを通して相互結合し、前記ストレージネットワークを通して前記ストレージデバイスにアクセスし、前記ストレージネットワークと前記ストレージデバイスの各々との間にリンクを形成する、
ことを特徴とする請求項１の階層型ストレージデータ管理システム。
【請求項４】
前記各ストレージデバイスは他のストレージデバイスに直接アクセスするリンクを持ち、自らのメタデータを管理し、更に要求データが自らのシステムに不在の場合には他のストレージデバイスにアクセスする、
ことを特徴とする請求項１の階層型ストレージデータ管理システム。
【請求項５】
前記データ価値管理ユニットは、
前記メタデータ管理要素から複数のデータオブジェクトに対する複数のユーザ利益表示を受信する手段と、
前記複数のユーザ利益表示を解析する手段と、
前記各データオブジェクトのユーザ利益レベルを決定する手段と、
前記ユーザ利益レベルに対応して前記各データオブジェクトにデータ価値を割り当てる手段と、
を有することを特徴とする請求項１の階層型ストレージデータ管理システム。
【請求項６】
前記階層型ストレージ管理要素は、前記データ価値と各ストレージ領域に関るストレージ特性に基づいて、前記データオブジェクトを前記複数のストレージデバイスに保存又は再配置することを特徴とする請求項１の階層型ストレージデータ管理システム。
【請求項７】
前記ユーザ利益表示は前記データオブジェクトへのユーザのアクセスレコードで成ることを特徴とする請求項５の階層型ストレージデータ管理システム。
【請求項８】
前記ユーザのアクセスレコードは、事前指定の期間内でのアクセス回数、又は前記データオブジェクトが保存されてから削除されるまでの寿命である、ことを特徴とする請求項７の階層型ストレージデータ管理システム。
【請求項９】
前記ユーザのアクセスレコードは複数のコマンドタイプで分類され、前記データ価値は前記コマンドタイプの幾つか又は全ての前記ユーザのアクセスレコードの合計である、ことを特徴とする請求項７の階層型ストレージデータ管理システム。
【請求項１０】
前記アクセス回数はアクセス頻度で重み付けすることを特徴とする請求項８の階層型ストレージデータ管理システム。
【請求項１１】
前記ユーザ利益表示は、前記データオブジェクトから抽出したインデックス、書誌情報、及び用語の少なくとも一つを含む、ことを特徴とする請求項５の階層型ストレージデータ管理システム。
【請求項１２】
前記書誌情報は、著者、題目、キーワード、及び製作日を含むことを特徴とする請求項１１の階層型ストレージデータ管理システム。
【請求項１３】
前記データ価値は、前記データオブジェクトが保存されてから削除されるまでの寿命に関して該データオブジェクトに割り当てられた寿命値で成る、ことを特徴とする請求項５の階層型ストレージデータ管理システム。
【請求項１４】
前記メタデータ管理要素は、前記データ価値管理要素からの前記データアクセスレコードに対する要求に答える為のインターフェースを持つことを特徴とする請求項７の階層型ストレージデータ管理システム。
【請求項１５】
前記階層型ストレージ管理要素は、
前記メタデータ管理要素から複数のストレージ領域に対する複数のストレージコスト表示を受信する手段と、
前記複数のストレージコスト表示を解析する手段と、
前記ストレージ領域に対してストレージコストレベルを決定する手段と、
前記ストレージコストレベルに対応して前記ストレージ領域にストレージコスト値を割り当てる手段と、
を有することを特徴とする請求項２の階層型ストレージデータ管理システム。
【請求項１６】
前記ストレージコスト表示は、前記ストレージ領域の平均性能と信頼性で成ることを特徴とする請求項１５の階層型ストレージデータ管理システム。
【請求項１７】
前記ストレージコスト値は、前記ストレージ領域がオンラインストレージデバイス、ニアラインストレージデバイス、オフラインストレージデバイスの何れに存在するかに従って、高から低まで変化する、ことを特徴とする請求項１５の階層型ストレージデータ管理システム。
【請求項１８】
前記メタデータサーバは、前記データ価値の区分を前記ストレージコスト値の区分と同一に設定することによって、前記データ価値管理ユニットで計算された複数のデータオブジェクトのデータ価値と、前記階層型ストレージ管理要素より割り当てられた前記ストレージデバイス内の複数のストレージ領域のストレージコスト値を正規化する、ことを特徴とする請求項１の階層型ストレージデータ管理システム。
【請求項１９】
前記メタデータサーバは、前記データ価値の最大値を前記ストレージコスト値の最大値として使用し、これに従って他のストレージコスト値を調整する、ことを特徴とする請求項１８の階層型ストレージデータ管理システム。
【請求項２０】
前記メタデータサーバは、前記ストレージコスト値の最大値を前記データ価値の最大値として使用し、これに従って他のデータ価値を調整する、ことを特徴とする請求項１８の階層型ストレージデータ管理システム。
【請求項２１】
前記メタデータサーバは、正規化済データ価値を正規化済ストレージコスト値と比較し、前記データオブジェクトを別のストレージ領域に再配置するかどうかを決定する、ことを特徴とする請求項１８の階層型ストレージデータ管理システム。
【請求項２２】
複数のデータオブジェクトとストレージネットワークで結合したストレージデバイス内の複数のストレージ領域を提供するステップと、
前記各データオブジェクトに対してデータ価値を計算するステップと、
前記各ストレージ領域にストレージコスト値を割り当てるステップと、
計算されたデータ価値と割り当てられたストレージコスト値を同一の値区分を持つように正規化するステップと、
正規化済データ価値を正規化済ストレージコスト値と比較して、前記データオブジェクトを別のストレージ領域に再配置すべきかどうかを決定するステップと、
データオブジェクトを、該データオブジェクトのデータ価値と等しいストレージコスト値を持つストレージ領域に再配置するステップと、
で成ることを特徴とする階層型ストレージデータ管理方法。
【請求項２３】
前記計算するステップは、
複数のユーザ利益表示を収集するステップと、
前記複数のユーザ利益表示を解析するステップと、
前記各データオブジェクトに対してユーザ利益レベルを決定するステップと、
前記ユーザ利益レベルに対応して前記各データオブジェクトにデータ価値を割り当てるステップと、
で成ることを特徴とする請求項２２の階層型ストレージデータ管理方法。
【請求項２４】
前記収集するステップは、事前指定の期間内でのアクセス回数又は前記各データオブジェクトが保存されてから削除されるまでの寿命を加算するステップで成る、ことを特徴とする請求項２３の階層型ストレージデータ管理方法。
【請求項２５】
前記各データオブジェクトに対するアクセスは複数のアクセス用コマンドタイプより成り、前記各データ価値は前記コマンドタイプの幾つか又は全ての前記アクセス回数の合計である、ことを特徴とする請求項２４の階層型ストレージデータ管理方法。
【請求項２６】
前記アクセス回数はアクセス頻度で重み付けする、ことを特徴とする請求項２４の階層型ストレージデータ管理方法。
【請求項２７】
前記収集するステップは、前記各データオブジェクトから抽出したインデックス、書誌情報、及び用語の少なくとも一つを収集するステップで成る、ことを特徴とする請求項２３の階層型ストレージデータ管理方法。
【請求項２８】
前記書誌情報は、著者、題目、キーワード、及び製作日で成る、ことを特徴とする請求項２７の階層型ストレージデータ管理方法。
【請求項２９】
前記収集するステップは、前記各データオブジェクトが保存されてから削除されるまでの寿命に関して、該各データオブジェクトに寿命値を割り当てるステップで成る、ことを特徴とする請求項２３の階層型ストレージデータ管理方法。
【請求項３０】
前記割り当てるステップは、
複数のストレージコスト表示を収集するステップと、
前記複数のストレージコスト表示を解析するステップと、
前記各ストレージ領域のストレージコストレベルを決定するステップと、
前記ストレージコストレベルに対応して前記各ストレージ領域にストレージコスト値を割り当てるステップと、
で成る、ことを特徴とする請求項２２の階層型ストレージデータ管理方法。
【請求項３１】
前記収集するステップは、前記各ストレージ領域の平均性能と信頼性のデータを収集するステップで成る、ことを特徴とする請求項３０の階層型ストレージデータ管理方法。
【請求項３２】
前記割り当てるステップは、前記各ストレージ領域がオンラインストレージデバイス、ニアラインストレージデバイス、オフラインストレージデバイスの何れに存在するかに従って、ストレージコスト値を高から低に変化させる、ことを特徴とする請求項３０の階層型ストレージデータ管理方法。
【請求項３３】
前記正規化するステップは、前記データ価値の最大値を前記ストレージコスト値の最大値として使用し、これに従って他のストレージコスト値を調整するステップで成る、ことを特徴とする請求項２２の階層型ストレージデータ管理方法。
【請求項３４】
前記正規化するステップは、前記ストレージコスト値の最大値を前記データ価値の最大値として使用し、これに従って他のデータ価値を調整するステップで成る、ことを特徴とする請求項２２の階層型ストレージデータ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
0001  本発明はデータストレージ及び管理方法とその為のシステムに関連する。より具体的には、本発明は、事前に選択された具体的なパラメータのセットに従いデータを管理しストレージ資源内に配置する、階層型ストレージ管理の為の方法とシステムに関連する。
【背景技術】
【０００２】
0002  ビジネスがデータ量とその多様性を拡大していくに従い、データストレージの物理的な量の拡大、情報への広範なアクセス要求、ストレージ環境の複雑さの拡大、及び新たに出現する技術の採用等に対して組織は対応しなければならなくなった。これらの問題に対して、際限なく資源と時間を割ける会社は極めて少ない。今日では、会社は高性能化、インテリジェントシステム、及び稼動時間を最大にし、データストレージコストを低減しながら、現存データと現存ネットワークを管理する複雑なソフトウェアに基づいた新たなストレージ管理戦略を考慮しなければならない。
【０００３】
0003  階層型ストレージ管理は大量のデータを管理する一つの方法である。ファイル又はデータは、如何に頻繁に又は如何にすみやかに必要とするかに基づいて、各種のストレージ媒体に割り当てられる。データの主要な性質はストレージシステムで評価される。データは使用間隔、頻度又は価値の如き一つ以上の性質に基づいて管理される。ユーザの利益も同じ主要な性質に基づいて評価される。データは、データの生涯に亘るユーザ利益に基づいて管理される。データは又、ストレージコストに基づいて、適切なストレージ資源に配置され得る。
【０００４】
0004  データをその生涯に亘って管理することは挑戦的なタスクである。この主要な挑戦事項は、定常的に増大する大量のデータを如何に管理し、同時にＴＣＯ(Total Cost of Ownership)を極めて小さく維持すべく、データ管理コストを如何にコントロールするかに関っている。
【０００５】
0005  現在可能なテクノロジーによって、望まれる予算の範囲内で大量データを保存し管理するのに成功するストレージシシテム管理の基本的要求は、完全に拡張可能なアーキテクチュアによりデータ管理を最少コストで提供することである。完全に拡張可能なアーキテクチュアは、ストレージシステムの容量を制限することはなく、又ハードウェアアーキテクチュアで実装されるＳＡＮ(Storage Area Network)に関るデータ管理ソフトウェアの管理範囲を制限することもない。最少のＴＣＯは最少の管理タスクで実現される。
【０００６】
0006  ＯＳＤ(Object based Storage Devices)とＲＡＩＮ(Reliable Array of Independent Nodes)は完全に拡張可能なデータ管理を目指すストレージシステムアーキテクチュアの例である。
【０００７】
0007  慣用的方法では、最少のＴＣＯはデータストレージをＨＳＭ(Hierarchical Storage Management：階層型ストレージ管理)システムで管理することにより達成できた。ＨＳＭでは、データファイルを多様なデータストレージ媒体の間で管理することができる。ＨＳＭシステムが遭遇する課題は、使用するストレージ媒体がアクセスタイム、容量、及びコストで相違し、統合管理が大変困難なことである。例えば、ＲＡＩＤ(Redundant Array of Independent Disks)に組み入れられた磁気ディスクの様な短期ストレージ媒体は、分離して管理しなければならないほどに、ネットワーク中の他のコンポーネントとは異なったパラメータを持っている。ＨＳＭはストレージに対して、自動的に性能チューニングを提供し、性能ボトルネックを解消する当座のソリューションである。現状では、ＨＳＭの背後にある技術は、各データボリュームに対するアクセス頻度を保存し、そのアクセスパターンを解析することである。ＨＳＭは更に、ストレージ内に論理ボリュームを持ち込み、ストレージサブシステムに対するアクセス率を正規化している。現状のＨＳＭシステムの一例は、Ｈｉｔａｃｈｉ Ｌｉｇｈｔｎｉｎｇ ９９００ＴＭＶ製品シリーズに含まれるＣｒｕｉｓｅＣｏｎｔｒｏｌ(Ｒ)であり、今日広範に使用可能である。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
0008  ＯＳＤとＲＡＩＮアーキテクチュアは完全に拡張可能なアーキテクチュアの例ではあるが、管理データのＴＣＯを最少にして維持する為には、階層型ストレージデータ管理に加えて追加の技術が必要である。もし会社がストレージ容量を拡張する為に、データ量の増大に伴って同一のストレージシステム(例えばオンラインストレージデバイス)を定期的に追加していくなら、ストレージ容量の定期的な追加により、高コストが余儀なくされる。ストレージ容量は容易に限界に達して、会社はＴＣＯを最小にできなくなる。
【０００９】
0009  もう一つ考慮しなければならない側面は、データには生涯に亘って変動するデータ固有の価値が有ることである。異なったタイプのストレージデバイスと媒体を使用して、データをその価値に従い生涯に亘って管理するアーキテクチュアが必要である。データはその価値に従って適切な場所に保存される。データ価値とストレージコストの双方を考慮して、適切な保存場所を自動的に定めるシステムを提供することが重要である。
【００１０】
0010  慣用的なＨＳＭ技術は、データ価値の生涯に亘る変動を考慮していない。現状では、ユーザによるデータの生涯管理はアーカイブの前に静的に定義され、データは事前設定されたパラメータに従い、異なったタイプのストレージ媒体に保存される。例えば、ＲＡＩＤシステム中のデータが事前設定した寿命に達すれば、システムは単純に当該データをテープにアーカイブするのみである。しかしながら、その生涯に亘って変動するデータの価値は、時時変動するユーザの利益にも依存している。もしユーザが、生涯中にデータ価値の変更を希望すれば、これを人手で行う必要があり、新たな管理コストが発生する。
【００１１】
0011  データの生涯に亘って、ユーザの利益に基づきデータの価値を考慮し、データをデータの価値とストレージコストに基づいて、適切なストレージ資源に配置する階層型ストレージ管理の為の方法とシステムが必要である。
【００１２】
0012  更に又、データをその生涯に亘ってＴＣＯを最少にするために、ＯＳＤやＲＡＩＮのような完全に拡張可能なアーキテクチュアを可能にする階層型ストレージ管理の為の方法とシステムが必要である。
【課題を解決するための手段】
【００１３】
0013  本発明の実施例は、データの生涯に亘ってユーザ利益に基づいてデータ価値を考慮した階層型データストレージ管理を提供することで、これらのニーズに取り組むものである。データは、算定された価値とストレージコストに基づいて、適切なストレージ資源に配置される。本発明により、データボリュームを最少コストで管理する拡張可能なネットワークアーキテクチュアが可能になる。
【００１４】
0014  階層型データ管理装置は、複数のアプリケーションサーバ、メタデータサーバ、ＳＡＮ(Storage Area Network)、及び複数のストレージデバイスで成り、これら複数のアプリケーションサーバとメタデータサーバは互いにＬＡＮ(Local Area Network)を通して結合され、ＳＡＮはこれら複数のストレージデバイスを複数のアプリケーションサーバとメタデータサーバに結合し、複数のストレージデバイスは複数のデータパスを通して互いに結合される。階層型データストレージ管理の実行方法は、データアクセスクライアント要素からメタデータサーバにデータアクセスコマンドを発行し、メタデータサーバが受領応答を発行し、メタデータ管理要素がメタデータを発行し、データアクセスレコードをメタデータ管理要素からデータ価値管理ユニットに転送し、各データの価値を計算し、計算された価値をデータ価値テーブルに保存し、要求に従って、一セットのデータ価値を階層型ストレージ管理モジュールに転送し、メタデータ調整を計画し、メタデータ調整を実行し、ストレージ特性テーブルを生成して、ストレージ特性テーブルを管理し、データ価値とストレージコストを正規化し、複数のストレージデバイスにアクセスし、更にコマンド実行を求めることから成る。
【００１５】
0015  本発明の多様な実施例の構成や動作に加えて、本発明の更なる機能と便益が添付した図面を参照しながら以下に詳細に説明される。本発明はここに記された具体的実施例に限られるものではないことに注意が必要である。このような実施例は単に説明の為のみに展開する。ここに展開する開示に基づき、追加の実施例が当業者には明白であろう。
【発明の効果】
【００１６】
本発明の実施例は、データの生涯に亘ってユーザ利益に基づいてデータ価値を考慮した階層型データストレージ管理を提供することで、これらのニーズに取り組むものである。データは、算定された価値とストレージコストに基づいて、適切なストレージ資源に配置される。本発明により、データボリュームを最少コストで管理する拡張可能なネットワークアーキテクチュアが可能になる。
【発明を実施するための最良の形態】
【００１７】
0016  本発明を、以下の添付図面を参照して説明する。
【００１８】
0031  好適な実施例についての以降の説明では、本発明の一部である添付図面が参照され、本図面により、本発明が適用される具体的実施例が説明の目的で示される。他の実施例も可能であり、本発明の範囲を離れることなく構造的変更も可能であることを理解する必要がある。
【００１９】
0032  図１はＤＬＣＭ(Data Life Cycle Management)情報より成るグラフである。オブジェクトは(データと方法を組み入れた)データ構造であり、他のオブジェクトとは“交信”可能であるものの、そのインスタンスはユニークであり、他のオブジェクトとは区別される。オブジェクト指向プログラミングでのオブジェクトの寿命(又は生涯)は、オブジェクトの生成(インスタント生成とか構築とも言われる)からもはや使用されなくて解放される迄の時間である。オブジェクト指向プログラミングでの各オブジェクトの寿命は、慣用形プログラミングの場合よりも広範に変動する傾向がある。
【００２０】
0033  グラフ１００は、管理対象データの保存時間を表示するＸ軸１１、管理対象データのタイプを表示するＹ軸１０、及び採用されるデータ管理技術を表示するＺ軸１２とから成るＤＬＣＭ情報で構成される。管理対象データの保存期間は日又は年で計測される。データの可能なタイプの例はトランザクションデータ、データベース／データウェアハウス(ＤＢ／ＤＷＨ)データ、Ｅ−メールドキュメント、ディジタルコンテンツデータ等である。採用される管理技術の例はブロック管理、ファイル管理、オブジェクト管理等である。グラフ１００には二つの大きな傾向が見られる。即ち、管理対象データのタイプは構造型から準構造型と非構造型に変化し、データ保存時間も増大する。
【００２１】
0034  構造型データの例にはトランザクションデータとＤＢ／ＤＷＨが存在する。準構造型データの例はＥ−メールで、これには構造型部分(ヘッダ部)と非構造型部分(メールの本体)が存在する。非構造型データの例はディジタルコンテンツで、このデータ構造はユニークでなく予想し難いものである。現存のストレージシステムは、準構造型と非構造型データに比べて構造型データを最もよく管理することができ、準構造型と非構造型データについても管理効率の向上を目指している。
【００２２】
0035  管理対象データの保存時間を増大させる幾つかの他の要因が存在する。即ち、政府規制が会社に対してそのビジネス活動を監査する為にデータの長期保存を要求し、データマイニング、ビジネスインテリジェンス等でのデータの再利用も要因である。従って、データ管理のより良いソリューションが望まれる。
【００２３】
0036  図１の実線の矢印１３はマーケットの傾向を示しており、会社では管理対象データ量の増大が問題となり、結果として、エンタプライズデータのＴＣＯ(Total Cost of Ownership)（ＴＣＯ−Ｄ）について心配している状態を示している。従って、データをその生涯を通して管理することは会社にとって大変緊急な課題になってきた。ストレージサービスベンダーの観点からは、ブロックベースのＳＡＮ(Storage Area Network)やファイルベースのＮＡＳ(Network Attached Storage)と共にＯＳＤ(Object based Storage Devices)の如き適切な技術を提供し操作できれば、マーケットを拡大し利益を得ることができる。このマーケット傾向は、図１の点線の矢印１４で示す。
【００２４】
0037  既に述べたように、データをその生涯に亘って管理することは、挑戦的な課題である。この為の主要な課題は、定常的に増大する大量のデータを如何に管理し、同時に非常に低いＴＣＯを維持する為に関連コストを如何に抑えるか、である。
【００２５】
0038  大量データを望まれるコストパラメータ範囲内で管理するマネージメントとストレージシステムに対する基本的要求は、完全に拡張可能なアーキテクチュアにより、データ管理サービスを最少コストで提供することである。この完全に拡張可能なアーキテクチュアの要求は、ストレージシステムの容量が無制限であることを意味する。同時に、ストレージシステムに関するデータ管理ソフトウェアが実行する管理範囲についても無制限であることも必要である。最少ＴＣＯは最少管理タスクで達成される。
【００２６】
0039  ＯＳＤ(Object based Storage Devices)とＲＡＩＮ(Reliable Array of Independent Nodes)は現在完全に拡張可能なデータ管理を狙えるストレージシステムアーキテクチュアである。
【００２７】
0040  図２はＯＳＤアーキテクチュアの一般的事例を示す。アーキテクチュア２００は、複数のアプリケーションサーバ２０２、メタデータサーバ２０４、複数のストレージデバイス２０６、ＳＡＮ(Storage Area Network)２０８、及びＬＡＮ(Local Area Network)２１０より成り立つ。各アプリケーションサーバ２０２は、アプリケーションプログラム要素２１２とデータアクセスクライアント要素２１４で成り立つ。メタデータサーバ２０４はメタデータ管理要素２１６を有する。アプリケーションサーバ２０２はＬＡＮ２１０を通して互いに結合される。アプリケーションサーバ２０２は、ＳＡＮ２０８を通してストレージデバイス２０６にアクセスする。ＳＡＮ２０８と各ストレージデバイス２０６との間には、論理的又は物理的リンク２１８が確立している。アーキテクチュア２００内で結合するアプリケーションサーバとストレージデバイスの数には制限がない。
【００２８】
0041  メタデータサーバ２０４に属するメタデータ管理要素２１６は、データロケーションとそのセキュリティー(メタデータ)を単一のポイント−ポイントフローの形で、制御する。メタデータ管理要素２１６は更にデバイス管理に責任を持つ。複数のアプリケーションサーバ２０２が所定のデータのロケーションに関する情報を受信した後、これらサーバはストレージデバイス２０６に直接アクセスする。アクセスシーケンスの一例を以下に示す。
【００２９】
0042  アプリケーションプログラム要素２１２は、データアクセスクライアント要素２１４にデータ入出力処理(１)ＲＥＱを要求する。
【００３０】
0043  データアクセスクライアント要素２１４は、コマンド(２)ＲＥＱとデータオブジェクトＩＤをメタデータ管理要素２１６に要求する。
【００３１】
0044  メタデータ管理要素２１６は、コマンド(２)ＲＥＱ要求を調べて、データアクセスクライアント要素２１４に応答(３)ＡＣＫを返す。応答(３)ＡＣＫは、要求されたデータオブジェクトＩＤのデータが存在するアドレスを含む。
【００３２】
0045  データアクセスクライアント要素２１４は、このアドレスに基づいてデータを読み出し、提供されたアドレスが指示するストレージデバイス２０６にコマンド(４)ＲＥＱを送る。
【００３３】
0046  ストレージデバイス２０６はコマンドを実行しデータを読み出し、完了応答(５)ＡＣＫをデータアクセスクライアント要素２１４に返す。
【００３４】
0047  データアクセスクライアント要素２１４は、アプリケーションプログラム要素２１２に応答(６)ＡＣＫを返す。
【００３５】
0048  ＯＳＤは完全に拡張可能である。追加のストレージデバイス又は能力をアーキテクチュア２００に付加することができる。
【００３６】
0049  ＲＡＩＮシステムは独立した分散ストレージデバイス(ノード)より成る。各ノードは自ノード内のみのメタデータを管理し他のノ−ドへのアクセス方法を知っている為、ＲＡＩＮシステムは通常は、共通デイレクトリ又はメタデータサーバを持っていない。ノード間の関係の一例は親子関係で、親ノードは子ノードへのアクセス方法を知っている。一つのノードがノード内のクライアントから要求された或るデータ項目を自ノード内で検出できない場合には、データが存在するかもしれない他のノードにアクセスする。データ項目は、独立に又有意味に処理されるデータの最小の論理的ユニットとして定義される関連した文字列である。このネットワークの容量は新ノードを追加することにより自動的に拡張することができる。
【００３７】
0050  ＯＳＤとＲＡＩＮに共通する基本技術の一つは、複数のアプリケーションから複数のストレージシステムへのアクセスを排他的に管理することである。本発明はこの技術に焦点を当てることなく、現行技術を使用して既に述べた挑戦的課題に向けて焦点を当てる。
【００３８】
環境例：
0051  本発明は階層型データストレージ管理方法及び装置に向けられ、ここではデータの生涯を通して、ユーザ利益に基づき、各データ項目に対して価値を割り当てる。データは、ストレージコストを考慮して適切なストレージ資源に配置される。
【００３９】
0052  図３は本発明の第一の実施例に従うＯＳＤ(Object based Storage Device)アーキテクチュアの一例を示す。
【００４０】
0053  アーキテクチュア３００は複数のアプリケーションサーバ３０２、メタデータサーバ３０４、オンラインストレージデバイス３２４、ニアラインストレージデバイス３２６、オフラインストレージデバイス３２８等の複数のストレージデバイス、ＳＡＮ(Storage Area Network)３０８、及びＬＡＮ(Local Area Network)３１０より成り立つ。各アプリケーションサーバ３０２は、アプリケーションプログラム要素３１２及びデータアクセスクライアント要素３１４を有する。メタデータサーバ３０４は、メタデータ管理要素３１６、データ価値管理要素３２０、及び階層形ストレージ管理要素３２２を有する。ＬＡＮ３１０を通して、アプリケーションサーバ３０２は互いに結合され又メタデータサーバ３０４と結合する。ＳＡＮ３０８と複数のリンク３１８を通して、アプリケーションサーバ３０２はストレージデバイス３２４，３２６、３２８にアクセスする。アーキテクチュア３００内のアプリケーションサーバとストレージデバイスの数には制限がない。
【００４１】
0054  メタデータサーバ３０４に属するメタデータ管理要素３１６は、データロケーションとセキュリティー(メタデータ)に対して単一のポイント−ポイントのフローコントロールを提供する。メタデータ管理要素３１６は更にデバイス管理に責任を持つ。アプリケーションサーバ３０２は、所定のデータ項目のロケーションに関する情報を入手後は、ストレージデバイスの一つに保存されているデータ項目に直接アクセスする。
【００４２】
0055  図２と図３に各々示すアーキテクチュア２００と３００の相違点を、以下に要約する。
【００４３】
0056  アーキテクチュア２００は、全てが同一タイプの複数のストレージデバイスを有する。
【００４４】
0057  アーキテクチュア３００は異なったタイプのストレージデバイスを有する。図３に示す環境例では三タイプのストレージデバイスを示す。アーキテクチュア３００で示す例では、ストレージデバイスの数とタイプについては制限がない。アーキテクチュア３００では、オンラインストレージデバイス３２４、ニアラインストレージデバイス３２６、オフラインストレージデバイス３２８を有する。オンラインストレージデバイス３２４はこの三種の中では最も高価であるが最高の性能を発揮する。オンラインストレージデバイス３２４の例は、ＳＣＳＩディスク又はファイバチャネルディスクを使用するＲＡＩＤシステムである。ニアラインストレージデバイス３２６はオンラインストレージデバイスよりは安価で中庸の性能を示す。ニアラインストレージデバイスの例は、ＳＡＴＡディスクを使用するＲＡＩＤである。オフラインストレージデバイス３２８は通常最も安価であるが、その性能は良くない。異なったタイプのストレージ媒体を使用することによって、アーキテクチュア３００は柔軟でコスト耐力のあるアーキテクチュアを提供する。
【００４５】
0058  トランザクションデータのデータ量が増大するに従い、ユーザはオンラインストレージデバイス３２４を準備し追加することができる。アーカイブ予定であり将来限定された時点でのみアクセスされるデータに対しては、当該データが最高の性能を要求しない限り、オンラインストレージデバイス３２４に代わって、ニアラインストレージデバイス３２６を準備し増設することができる。アクセス予定がなく、ともかくアーカイブするデータには、ユーザはオフラインストレージデバイス３２８を準備し増設することができる。
【００４６】
0059  メタデータサーバ３０４は、アーキテクチュア２００のメタデータサーバに加えて、データ価値管理要素３２０と階層型ストレージ管理要素３２２を備える。
【００４７】
0060  データ価値管理要素３２０はユーザの利益レベルに基づいて、データに価値を割り当てる。データ価値管理要素３２０は、メタデータ管理要素３１６から、ユーザの最新利益を示すデータアクセスレコード(７)ＡＣＳを受信し、このアクセスレコードを解析し、アクセス頻度、ストレージ内での寿命、インデックス、データオブジェクトの書誌的情報、又はデータオブジェクトから抽出した用語等のパラメータに基づいて、ある時点のユーザ利益を決定し、データ価値(８)ＶＡＬを割り当てる。
【００４８】
0061  階層型ストレージ管理要素３２２は、割り当てられた価値(８)ＶＡＬとストレージ特性に基づいてデータを再配置する。各ストレージ特性はコスト、性能実績等のストレージに関る特徴等より成る。例えば階層型ストレージ管理要素３２２は、データ価値とストレージコストを比較し、当該データを適切なストレージロケーションに再配置する。この詳細なデータフローについては図４に関連して説明する。総称的には、データフローは図３に於ける矢印(１)から(８)で示す。
【００４９】
0062  図４は、本発明に従う階層型データ管理フローの詳細ブロックダイアグラムを示す。
【００５０】
0063  アプリケーションサーバ３０２内のデータアクセスクライアント要素３１４は、メタデータ管理要素３１６にデータアクセスコマンド(９)ＣＯＭを送信する。これに応答して、メタデータ管理要素３１６から三つのコンポーネントに一組の結果が返送される。データアクセスコマンド(９)ＣＯＭは、アクセス対象のデータオブジェクトの識別情報を含んでいる。
【００５１】
0064  メタデータサーバ３０４内のメタデータ管理要素３１６は、データアクセスクライアント要素３１４からコマンド(９)ＣＯＭを受信して、これを解析し、コマンド実行要素４０２と共にコマンド(９)ＣＯＭを実行する。次いで、メタデータ管理要素３１６は、データアクセスクライアント要素３１４に応答(１０)ＡＣＫを返送する。アーキテクチュア３００にユニークな機能は、データ価値管理要素３２０にデータアクセスレコード(７)ＡＣＳを送信することである。データアクセスレコード(７)ＡＣＳはデータフロー４０８として送信される。
【００５２】
0065  メタデータサーバ３０４内のデータ価値管理要素３２０は、メタデータ管理要素３１６からデータアクセスレコード(７)ＡＣＳを受信して、このレコードとユーザ利益に基づいて、各データ項目に対して価値を計算し、その結果を保持する。アーキテクチュア３００のもう一つの特徴は、データ価値計算モジュール４１０がデータオブジェクトを個々の特性に分割して、各特性値を計算して、個々の値をデータ価値(８)ＶＡＬに合成することである。各個別の特性に対する価値(８)ＶＡＬのセットは、ある特定時点でのユーザ利益を反映している。要求が有れば、データ価値管理要素３２０は、階層型ストレージ管理要素３２２に対してデータ価値(８)ＶＡＬのセットを送信する。このことはデータフロー４１４を通して実現される。
【００５３】
0066  メタデータサーバ３０４内の階層型ストレージ管理要素３２２は、データ価値(８)ＶＡＬのセットを受信し、データ価値とユーザによって事前設定された個々のストレージ特性(例：ストレージコスト)とのバランスをとるべく、メタデータの調整を計画し実行する。ユーザは、計画されたメタデータ調整を直接確認し修正し、メタデータ調整の実行を指示することが出来る。メタデータ調整計画モジュール４１６とメタデータ調整実行モジュール４１８はアーキテクチュア３００の特徴的なコンポーネントである。
【００５４】
0067  階層型ストレージ管理要素３２２は、ユーザ利益に基づいてデータ価値を計算し、ストレージコストに基づいて適切なストレージ資源にデータを再配置する。
【００５５】
0068  階層型ストレージ管理要素３２２は、更に、他の追加的機能、即ちストレージ特性テーブル４２０の管理、を実行する。ストレージ特性テーブル４２０は、ストレージ特性、コスト等の情報を管理する。慣例的には、これら特性はユーザインターフェース(図示していない)を通してユーザにより定義される。このインターフェースにより、ユーザは対応するストレージ特性を入力することが出来る。
【００５６】
0069  メタデータ調整を実行する為に、階層型ストレージ管理要素３２２は、フロー４２４を通して、メタデータ管理要素３１６に対して、データアクセスコマンド(１１)ＣＯＭを送信する。メタデータ管理要素３１６は、階層型ストレージ管理要素３２２に対して、受領応答(１２)ＡＣＫを発行する。続いて、階層型ストレージ管理要素３２２は対応するストレージデバイスにアクセスして、コマンド(１２)ＣＯＭの実行を依頼する。データフロー４２２はこの動作ステップを示す。可能性のあるコマンド例は、データの再配置要求である。
【００５７】
0070  セキュリティーの観点から、メタデータサーバ３０４が管理する全てのテーブルは、認可されたユーザのみがアクセスできる特定のストレージ領域に保存される。
【００５８】
0071  図５は図４で参照したメタデータテーブル４０６の一例を示す。メタデータテーブル４０６は、以下のデータタイプを示す欄を有する。即ち、データオブジェクトＩＤ５５１、データオブジェクト名５５２、ストレージＩＤ５５３、ストレージ内アドレス５５４、フラグ５５５、及び他の機能５５６である。
【００５９】
0072  欄５５１は各データオブジェクトに対するデータオブジェクトＩＤ、例えば、“２”を示す。このデータオブジェクトＩＤ(ＤＯＩＤ)は、アーキテクチュア３００を配備したシステムでは固有である。データアクセスクライアント要素３１４はＤＯＩＤによってアクセス対象のデータを識別する。ヘテロな環境下で、本パラメータを固有に保つ技術には、指紋技術やハッシングがある。この技術については、Arturo Crespo, Hector Garcia-Molina.による、“Awareness Services for Digital Libraries”, Research and Advanced Technology for Digital Libraries: First European Conference; proceedings/ECDL '97, Pisa, Italy, September 1-3, 1997、に記されている。上記ドキュメントの内容は参照により本発明の開示に含まれる。
【００６０】
0073  欄５２２は各データオブジェクトのデータオブジェクト名を示す。ここでの例では、“Ｙｙｙ”。
【００６１】
0074  欄５５３はＤＯＩＤで定義したデータを保存する固有なストレージＩＤを示す。ここでの例では、“Ｔ３”。
【００６２】
0075  欄５５４はＤＯＩＤで定義したデータを保存するロケーションを識別するためのストレージ内での固有なアドレスを示す。ここでの例では、“１０００”。欄５５３と５５４を併せて全システム内での固有なストレージロケーションを指定する。
【００６３】
0076  欄５５５はデータオブジェクトの現在の状態を表すフラグ、即ち“ＲＥＡＤ”、“ＷＲＩＴＥ”、“ＯＰＥＮ”等を示す。“ＲＥＡＤ”はデータアクセスクライアントが当該データオブジェクトを読み取り中で、“ＷＲＩＴＥ”はデータアクセスクライアントが当該データオブジェクトを書き込み中で、更に“ＯＰＥＮ”は当該データオブジェクトに対してアクセス中ではないことを示す。“ＷＲＩＴＥ”の場合には、メタデータ管理要素３１６は、排他書き込みアクセスを保障する為に、他ユーザからの当該データオブジェクトに対する付随アクセスを拒絶する。
【００６４】
0077  欄５５６はデータオブジェクトのサイズ、アクセスコントロールリスト(ＡＣＬ)情報、データオブジェクト自身を記述するデータ特性等の、メタデータを記述する為に用いられるその他の特徴を表示する。
【００６５】
0078  メタデータテーブル４０６の行５６１から５６３はメタデータエントリの例であり、上記で記述したパラメータで識別される。
【００６６】
0079  ＲＥＡＤコマンドの場合は、メタデータ管理要素３１６は、ＲＥＡＤコマンドを受信し、このコマンドに付随するＤＯＩＤを用いてメタデータテーブル４０６のエントリを検索する。高速検索を達成するのに、幾つかのインデックス技術が存在する。メタデータ管理要素３１６は、欄５５５にＲＥＡＤフラグをセットして、欄５５３のストレージＩＤと欄５５４のストレージ内アドレスをデータアクセスクライアント要素３１４に返送する。
【００６７】
0080  ＷＲＩＴＥコマンドの場合は、メタデータ管理要素３１６は、存在するデータに関するＷＲＩＴＥコマンドを受信し、このコマンドに付随するＤＯＩＤを用いてメタデータテーブル４０６のエントリを検索する。ＷＲＩＴＥフラグが欄５５５にセットされる。欄５５３のストレージＩＤと欄５５４のストレージ内アドレスをデータアクセスクライアント要素３１４に返送する。メタデータ管理要素３１６が新規データに対するＷＲＩＴＥコマンドを受信すると、メタデータテーブル４０６に新規エントリを生成し、新規ＤＯＩＤと新規ロケーションを当該新規データに割り当てる。新規ＤＯＩＤを割り当てる為に、ディジタル認証又は指紋技術が使用される。
【００６８】
0081  メタデータ管理要素３１６は、システム全体に亘って、不使用ストレージスペースを管理し新規ストレージロケーションを割り当てる。主として階層型ストレージ管理要素３２２からの要求に従い、ＷＲＩＴＥコマンドがパラメータとして候補ストレージロケーションを指定できることはアーキテクチュア３００の特徴的な点である。
【００６９】
0082  図４に戻って、データ価値計算モジュール４１０は、データ価値をデータ価値テーブル４１２に格納する。図６はデータ価値テーブル４１２の一例である。
【００７０】
0083  データ価値テーブル４１２はデータオブジェクトＩＤ欄６５１、データオブジェクト特性欄６５２、アクセスレコード欄６５３、及びデータ価値欄６５４を持つ。
【００７１】
0084  欄６５１は、各データオブジェクトに対して、データオブジェクトを表す数値によりデータオブジェクトＩＤを指定する。例えば、“２”。
【００７２】
0085  欄６５２はデータオブジェクト自身の特徴を記述するデータオブジェクト特性を指定する。例えば、“Ｇ，Ｉ，Ｋ，Ｌ，Ｎ，Ｐ，Ｑ”。データオブジェクト特性の例は、インデックス(構造化データ)、著者、題目、キーワード、製作日等の書誌情報(準構造化データ)、又はデータから抽出した全ての用語(非構造化データ)である。非構造型データから用語を抽出するには、インターネットの検索エンジンに類似したインデックス化技術が採用される。
【００７３】
0086  欄６５３はメタデータ管理要素３１６から受信したデータアクセスレコード(７)ＡＣＳを特徴付ける。アーキテクチュア３００では、欄６５３内の数値はデータがアクセスされた回数を示す。本発明のもう一つの可能性ある実施例では、欄６５３内のアクセスレコードは、コマンドタイプの幾つかのサブクラスを表示する。この具体例では又、メタデータ管理要素３１６はアクセスレコードをコマンドタイプでクラス分けする。
【００７４】
0087  欄６５４はデータ価値計算モジュール４１０によって算出されたデータ価値を示す。データ価値を計算する最も簡単な方法は、欄６５３のアクセスレコードを欄６５４のデータ価値とすることである。然しながら、本発明のもう一つの実施例では、ユーザ利益を反映する為に、データのより小さな粒度(即ち、データ特性)例えば、データオブジェクトの寿命(後述する)を考慮して計算する。
【００７５】
0088  データ価値テーブル４１２の行６６１から６６４はデータ価値エントリの例である。
【００７６】
0089  本発明の一実施例では、システムはデータ価値テーブル４１２をユーザに提示し、ユーザがこのテーブルにエントリを作成したり、修正できるようにする。
【００７７】
0090  本発明のもう一つの実施例では、データ価値テーブル４１２は、データオブジェクトが新規にシステムに保存された時点を示すデータ生成時刻に関するエントリを設ける。このエントリを使用して、データ価値管理要素３２０はデータオブジェクトの寿命を考慮し、これをデータ価値に割り当てる。例えば、データの寿命が或る期間内、例えば３０年、ならば、データ価値管理要素３２０はこのデータオブジェクトの価値は極めて高く、欄６５３の対応アクセスレコードの値の如何に関らず、欄６５４の値を“２５”にセットする。データ価値管理要素３２０はデータオブジェクトの寿命を欄６５３でのアクセスレコードに基づいて計算し、欄６５４のデータ価値に持ち込む。
【００７８】
0091  図４で参照するユーザ利益テーブル２７０は、各特性パラメータに対する合計のアクセスを記録する。図７はユーザ利益テーブル２７０の一例を示す。
【００７９】
0092  ユーザ利益テーブル２７０は、特性パラメータ７７１、データオブジェクトへのインデックス７７２、及び評価点７７３の各欄を有する。
【００８０】
0093  欄７７１は各ユーザ特性パラメータ評価点エントリ用の特性パラメータを示す。図６のデータ価値テーブル４１２の欄６５２のデータオブジェクト特性の行６６１で“Ｂ”で示すように、各ユーザ特性パラメータは、図７の行７８２の“Ｂ”で示すように、ユーザ利益テーブル２７０のエントリに対応する。
【００８１】
0094  欄７７２は欄７７１の特性パラメータを持つデータオブジェクトへのインデックスを示す。このインデックスはデータオブジェクトＩＤ(ＤＯＩＤ)である。パラメータ“Ａ”及び“Ｂ”は図６の行６６１内のＤＯＩＤ“１”で定義されるデータオブジェクトに含まれ、パラメータ“Ｌ”は図６の行６６２，６６３、６６４内のＤＯＩＤ“２”、“３”、“ｎ”で定義されるデータオブジェクトに含まれ、更にパラメータ“Ｍ”は、図６の行６６３内のＤＯＩＤ“３”で定義されるデータオブジェクトに含まれる。
【００８２】
0095  欄７７３は、各特性パラメータに対する合計アクセスレコードに相当する評価点を示す。例えば、パラメータ“Ａ”と“Ｂ”はＤＯＩＤ“１”で定義されるデータオブジェクトにのみ含まれ、これらの評価点は同じで、図６の欄６５３内のアクセスレコードの４である。一方、パラメータ“Ｌ”はＤＯＩＤ“２”、“３”、“ｎ”で定義されるデータオブジェクトに含まれ、これの評価点は図６の欄６５３のＤＯＩＤ“２”、“３”、“ｎ”のデータオブジェクトのアクセスレコードの合計値、２６(＝０＋１６＋１０)になる。
【００８３】
0096  ユーザ利益テーブル２７０の行７８１から７８４は、特性パラメータ評価点エントリの例である。
【００８４】
0097  ユーザの最近の実アクセスレコードに基づいて、ユーザ利益テーブル２７０は、ユーザの現状の利益を反映している。本発明のもう一つの実施例では、システムはユーザ利益テーブル２７０をユーザに提示して、ユーザが修正できるようにする。
【００８５】
0098  図１０は、データ価値管理要素３２０が、データ価値テーブル４１２に新規エントリを追加する為の処理フローを示す。処理フローは下記のステップを実行する。
【００８６】
0099  ステップ１０１１にて、データ価値管理要素３２０は新規ＤＯＩＤとその特性を取得する。データ価値管理要素３２０がメタデータ管理要素３１６から受信したデータアクセスレコードに新規ＤＯＩＤを検出したら、データ価値管理要素３２０は、メタデータ管理要素３１６にその特性を送信するように依頼する。メタデータ管理要素３１６に新規データオブジェクトに関する情報をオンデマンドで送付依頼する代わりに、データ価値管理要素３２０はデータオブジェクトに直接アクセスして、自らデータ特性を生成しても良い。
【００８７】
0100  ステップ１０１２にて、データ価値テーブル４１２にエントリが作り込まれる。データ価値管理要素３２０は、データ価値テーブル４１２に受信したデータオブジェクトに関するエントリを作成して、図６の欄６５１にデータオブジェクトＩＤを、欄６５２にデータオブジェクト特性をセットする。欄６５３と６５４の対応フィールドはデータ価値計算モジュール４１０が稼動する迄は空白のままである。
【００８８】
0101  ステップ１０１３にて、図７のユーザ利益テーブル２７０に、各新規特性パラメータに対するエントリが作成される。データ価値管理要素３２０は、ステップ１０１１で受信した新規特性パラメータを、図７のユーザ利益テーブル２７０に挿入する。更にデータ価値管理要素３２０は、図７の欄７７２に当該新規データオブジェクトへのインデックスを挿入する。欄７７３の対応フィールドはデータ価値計算モジュール４１０が稼動する迄は空白のままである。
【００８９】
0102  もしメタデータテーブル４０６の幾つかのエントリが削除されたら、データ価値管理要素３２０は、メタデータテーブル４０６から全てのＤＯＩＤに対して、データ価値テーブル４１２と比較し、削除されたＤＯＩＤに対応するエントリを検出し削除して、メタデータテーブル４０６とデータ価値テーブル４１２間の整合性を保持する。ユーザ利益テーブル２７０に関しては、削除されたデータのみに含まれる特性パラメータをそこから削除するか否かは、各実装次第である。本発明のこの実施例は主として、アーカイビングに使用される為に、データオブジェクトの削除は稀にしか発生しない。
【００９０】
0103  一般的に、データ価値計算モジュール４１０は、性能への影響を考慮して事前設定計画に従って、図６で示すデータ価値テーブル４１２の欄６５４を埋める為に稼動する。図１１はデータ価値計算の処理シーケンスを示す。処理は、ステップ１１１１と、ステップ１１１３から１１１７で成るステップ１１１２で構成される。
【００９１】
0104  ステップ１１１１にて、データアクセスレコード(７)ＡＣＳのセットを取得する。データ価値管理要素３２０内のデータ価値計算モジュール４１０は、メタデータ管理要素３１６からデータアクセスレコード(７)ＡＣＳのセットを受信する。メタデータ管理要素３１６がデータ価値管理要素３２０からの要求に応答するインターフェース(プロトコル又はコマンド)を持っていることは、本実施例のユニークな点である。
【００９２】
0105  ステップ１１１２にて、データ価値テーブル内の全対象データオブジェクトのデータ価値は加算される。各データオブジェクトに対して、データ価値計算モジュール４１０はステップ１１１３から１１１７のシーケンスを実行する。ステップ１１１３にて、データ価値計算モジュール４１０は、データ価値テーブル４１２の欄６５３の対応するアクセスレコードを、アクセスレコードの値で加算する。引き続くステップ１１１４にて、図６のデータオブジェクト特性欄６５２記載のデータオブジェクトの各特性パラメータに対して、データ価値計算モジュール４１０はステップ１１１５から１１１７を実行する。ステップ１１１５にて、データ価値計算モジュール４１０は、図７のユーザ利益テーブル２７０の欄７７３の各評価点を、データアクセスレコード(７)ＡＣＳのセットのアクセスレコードの値で、加算する。ステップ１１１６にて、データ価値計算モジュール４１０は、特性パラメータが参照した各データに対して、データ価値テーブル４１２の欄６５４のデータ価値をデータアクセスレコード(７)ＡＣＳのセットのアクセスレコードの値で加算する。かくして、アクセスレコードはユーザ利益テーブル２７０とデータ価値テーブル４１２に組み入れられる。アクセスレコードの値は、最近の一か月に１０回アクセスされたデータオブジェクトと最近の一週間で１０回アクセスされた別のデータオブジェクトのユーザ利益を区別する為に、データオブジェクトのアクセス頻度で重み付けしてもよい。
【００９３】
0106  本発明のもう一つの実施例では、データ価値計算モジュール４１０は、データオブジェクトの寿命を計算し、この計算された寿命に従ってデータ価値に対して追加の値を加えても良い。例えば、データ価値計算モジュール４１０は、短い寿命のデータオブジェクトは、長い寿命のデータオブジェクトより大きな価値を持つとしても良い。
【００９４】
0107  図８は図４で参照したストレージ特性テーブル４２０の一例を示す。
【００９５】
0108  ストレージ特性テーブル４２０はストレージＩＤ８５１、アドレス領域８５２、ストレージ領域コスト８５３、及びその他８５４のデータタイプの欄を有する。
【００９６】
0109  欄８５１は全システム内でストレージをユニークに識別するストレージＩＤを示す。例えば、Ｔ１は図４で示すオンラインストレージデバイス３２４を、Ｔ２はニアラインストレージデバイス３２６を、Ｔ３はオフラインストレージデバイス３２８を示す。
【００９７】
0110  欄８５２は、アドレス領域の範囲を示し、この中では全てのストレージアドレスが等しいコストを持つ。行８６１に示す例では、ストレージＴ１のアドレス領域１〜１００は、全て１０のコスト値を持っている。欄８５３はストレージのコスト値を示す。ストレージのコスト値はストレージ特性の一つである。
【００９８】
0111  欄８５４はストレージ特性を表すその他の特徴を示す。このような特徴には平均性能情報、信頼性情報等が該当する。本発明の実施例では、この情報はストレージコストを定義する為に使用される。本発明の他の実施例では、この情報はストレージコストの代わりにストレージ特性の粒度を拡張する為に使用される。
【００９９】
0112  行８６１から８６６で表示する情報はストレージ特性の例である。オンラインストレージデバイスＴ１のコストは最大であり、ニアラインストレージデバイスＴ２は中庸であり、オフラインストレージデバイスＴ３は最も安価である。一つのストレージデバイスの中でも、ストレージ領域によって異なったストレージコストを持ち得る事に注意する必要がある。
【０１００】
0113  データ価値とストレージコストを正規化し比較する為に、データ価値テーブル４１２とストレージ特性テーブル４２０を結合テーブル１５０に統合する。図９は結合テーブル１５０の一例を示す。
【０１０１】
0114  結合テーブル１５０は、データオブジェクトＩＤ９８１、データ価値９８２、正規化済データ価値９８３、ストレージＩＤ９８４、ストレージ内アドレス９８５、ストレージ領域コスト値９８６、適正ストレージコスト９８７、及び再配置要求９８８のデータタイプ欄より成り立つ。
【０１０２】
0115  欄９８１は、各データオブジェクトに対するデータオブジェクトＩＤを示す。データオブジェクトＩＤはテーブル４０６と４１２を連結し、ストレージＩＤはテーブル４０６と４２０を連結する。欄９８２はデータ価値を示す。この情報はデータ価値テーブル４１２で説明済である。
【０１０３】
0116  欄９８３は正規化済データ価値を示す。欄９８３での情報は新たに計算されたもので、ストレージ領域コスト９８６と比較される。データ価値を正規化する最も簡単な方法は最大のデータ価値を用いることである。然しながら、データ価値にストレージコスト値の区分と同一になるように区分を設けることは、両者を比較する為に重要なことである。
【０１０４】
0117  欄９８４と９８５は各々ストレージＩＤとアドレスを示す。メタデータテーブル４０６の欄５５３のストレージＩＤ情報はストレージ特性テーブル４２０の欄８５１に対応する。この情報は、ストレージ特性テーブル４２０とメタデータテーブル４０６を結合することを可能にする。同様に、メタデータテーブル４０６の欄５５４のストレージアドレスはストレージ特性テーブル４２０の欄８５２のアドレス領域に含まれ、更に結合テーブル１５０の欄９８５のアドレスに対応する。この情報はストレージ領域コスト９８６を記入することを可能にする。テーブル４０６(図５)の各エントリに対して、同じストレージＩＤがテーブル４２０(図８)に見つかり、対応するストレージ領域が同様に見つかる。例えば、テーブル４０６(図５)の行５６１は、ストレージＩＤのＴ２とアドレス３００を持ち、これらはテーブル４２０(図８)の行８６４に該当する。
【０１０５】
0118  欄９８６はストレージコスト値を示す。この情報はストレージ特性テーブル４２０に特有のものである。もし他のストレージ特性をデータ価値との比較の為に使用するなら、それらの特性は、同様に、ストレージ特性テーブル４２０から選択する。
【０１０６】
0119  欄９８７は各データオブジェクトのデータ価値に見合う適正なストレージコストを示す。このコストは通常、正規化済データ価値９８３により定義され、本事例ではこれらは同一である。
【０１０７】
0120  欄９８８は、正規化の結果として、データオブジェクトを再配置すべきか否かを表示する。“ＹＥＳ”は、データの価値と現在のストレージロケーションのコストとのバランスの結果として、このデータは再配置すべきであることを示す。“ＮＯ”は、バランスが示す通り、現データは適正なロケーションに保存されており再配置が不要であることを示す。欄９８６でのストレージ領域コストと欄９８７の適正なストレージコストの値が不一致なら、プログラムはデータが適正な領域に配置されていないことを確認し、再配置要求９８８が“ＹＥＳ”にセットされ、他の場合(ストレージ領域コスト値９８６と適正ストレージコスト値９８７が一致)には、“ＮＯ”がセットされる。例えば、行９９１のデータは、コストが“２”のストレージ領域に保存されるべきところ、現在は“６”の領域に保存されており、再配置が必要である。
【０１０８】
0121  本発明の他の実施例として、欄９８６と欄９８７の正確な一致に代わって、両者の相違が適正範囲内ならバランスしていると判断しても良い。更に他の本発明の実施例として、ストレージ領域コスト９８６と適正なストレージコスト９８７は、ランクによって正規化し、この値で互いに比較しても良い。もしランクが異なれば、再配置要求９８８が“ＹＥＳ”になる。
【０１０９】
0122  メタデータ調整計画モジュール４１６の目的は、欄９８７と９８８に情報を埋め込むことである。メタデータ調整実行モジュール４１８も、これらの欄に基づいてデータの再配置を実行する。もし欄９８８が“ＹＥＳ”なら、データオブジェクトは欄９８７と同じ値を持つストレージ領域に再配置される。
【０１１０】
0123  行９９１から９９３までの情報は結合テーブル１５０のエントリの例である。
【０１１１】
0124  図１２は、メタデータ調整計画モジュール４１６が実行する、メタデータ調整を計画する処理フロー１２００を示す。既に述べた通り、メタデータ調整計画モジュール４１６が、性能へのボトルネックを避ける為、事前設定計画に従って走行することは、必須ではないが望ましいことである。
【０１１２】
0125  処理フロー１２００はステップ１２１１から１２１４で成り、ステップ１２１１でデータ価値テーブルを受信し、ステップ１２１２でメタデータテーブルを受信し、ステップ１２１３でデータ価値テーブルとストレージ特性テーブルを結合テーブルに統合し、ステップ１２１４でデータ価値とストレージコスト(ストレージ特性)を正規化する。
【０１１３】
0126  ステップ１２１１で、メタデータ調整計画モジュール４１６は、データ価値管理要素３２０からデータ価値テーブル４１２を受信する。
【０１１４】
0127  ステップ１２１２で、メタデータ調整計画モジュール４１６は、更にメタデータ管理要素３１６からメタデータテーブル４０６を受信する。
【０１１５】
0128  ステップ１２１３で、データ価値テーブル４１２とストレージ特性テーブル４２０は結合テーブル１５０に統合される。メタデータ調整計画モジュール４１６は、データ価値テーブル４１２とストレージ特性テーブル４２０を図９で示す結合テーブル１５０に統合する。
【０１１６】
0129  ステップ１２１４でデータ価値とストレージコスト(ストレージ特性)を正規化する。メタデータ調整計画モジュール４１６は、図９のテーブル１５０の欄９８７と欄９８８の為の値を編集する。データ価値９８３は、ストレージコスト値の区分に適合すべく正規化済の為に、メタデータ調整計画モジュール４１６はこれらを欄９８７の適正なストレージコストフィールドにコピーする。欄９８７の適正なストレージコストと欄９８６の現ストレージコストが不一致なら、メタデータ調整計画モジュール４１６は欄９８８の再配置要求フィールドに“ＹＥＳ”をセットする。そうでなければ、当該フィールドに“ＮＯ”をセットする。
【０１１７】
0130  欄９８７に値をセットするのに幾通りかの方法が可能である。一つの方法は、最初に図９に示す結合テーブル１５０の全エントリを欄９８３の正規化済データ価値でソートし、その後に、事前設定された順序通りに欄９８７に適正なストレージコストを割り当てることである。
【０１１８】
0131  階層型ストレージ管理要素３２２が、メタデータ調整実行モジュール４１８による実行を開始するに先立って、ユーザはこの再配置計画を確認し修正したいと思うかも知れない。ユーザからの要求に従って、メタデータ調整計画モジュール４１６は図９に示す結合テーブルをユーザに示して、再配置計画の確認と編集が出来るようにする。これら機能を実行する為のインターフェースについては詳細は議論しないが、これらは当業者には明らかなことであろう。
【０１１９】
0132  メタデータ調整の処理フロー１４００は、メタデータ調整実行モジュール４１８が実行する。一般的に、メタデータ調整実行モジュール４１８は、性能へのボトルネックを避けるため事前設定計画に従って実行する。
【０１２０】
0133  ステップ１４１１〜１４１８の間に、メタデータ調整実行モジュール４１８は、図９の欄９８８に“ＹＥＳ”がセットされている各エントリに対して以下のステップを実行する。
【０１２１】
0134  ステップ１４１１にて、メタデータ調整実行モジュール４１８はメタデータ管理要素３１６に対してデータオブジェクトＩＤを用いて“ＲＥＡＤ”コマンドを送信し、ストレージＩＤとストレージアドレスの応答を受信する。ストレージＩＤとストレージアドレスは図９のテーブルに既に示されているにも拘わらず、モジュール４１８が敢えてこれらを求めるのは、このモジュールが実行している間に、何かのクライアントがデータロケーションを更新する可能性がある為である。
【０１２２】
0135  ステップ１４１２にて、メタデータ調整実行モジュール４１８は、受信したストレージＩＤとストレージアドレスを図９のテーブルのものと比較する。もしこれらが異なっていても受信したストレージＩＤとストレージアドレスのストレージコストが結合テーブル１５０の欄９８７での適正ストレージコストと同じ場合には、メタデータ調整実行モジュール４１８はステップ１４１１に戻り、次のエントリに進む。異なっている場合は、このモジュール４１８は次のステップ１４１３に進む。他の実施例として、もし受信アドレスが異なっていたら、このモジュール４１８は、データオブジェクトはクライアントにより移動されており再配置は適当でない、と認識し、次のエントリに進んでも良い。
【０１２３】
0136  ステップ１４１３にて、メタデータ調整実行モジュール４１８は、受信したストレージＩＤとストレージアドレスに基づいて、データオブジェクトを読み込みこれをバッファーに一時的に保存する。
【０１２４】
0137  ステップ１４１４にて、メタデータ調整実行モジュール４１８は、図８に示すストレージ特性テーブル４２０を使用して、ストレージコストが欄９８７(図９)の適正なストレージコストと等しいストレージＩＤとアドレス領域を識別する。
【０１２５】
0138  ステップ１４１５にて、メタデータ調整実行モジュール４１８は、ステップ１４１４で識別されたストレージＩＤとアドレス領域内で不使用スペースを見つける為に、メタデータ管理要素３１６に対して“ＷＲＩＴＥ”コマンドを送信する。この場合、メタデータ管理要素３１６は、図５で示したメタデータテーブル４０６の新規エントリに現エントリからの全ての追加メタデータをコピーする。
【０１２６】
0139  ステップ１４１６にて、メタデータ調整実行モジュール４１８が失敗の応答を受信したら、このモジュールはステップ１４１４で識別した領域の隣接領域に対して、“ＷＲＩＴＥ”コマンドを送信する。隣接領域のストレージコストは欄９８７での適切なストレージコストと同じか、又は同じコストの不使用スペースが存在しなければ近い値のコストのスペースを求める。成功応答を受信する迄本操作を繰り返す。
【０１２７】
0140  ステップ１４１７にて、メタデータ調整実行モジュール４１８はバッファー内のデータを読み出し、成功応答で受信したストレージＩＤとアドレスに書き込む。
【０１２８】
0141  ステップ１４１８にて、メタデータ調整実行モジュール４１８は、メタデータ管理要素３１６に“ＲＥＬＥＡＳＥ”コマンドを送信して、図５のメタデータテーブル４０６で解放されたエントリを不使用スペースにセットして他のデータオブジェクトに使用できるようにする。
【０１２９】
0142  本発明の異なった実施例として、ステップ１４１５と１４１６を実行する代わりに、メタデータ調整実行モジュール４１８は特別な“ＷＲＩＴＥ”コマンドを発行して、メタデータ管理要素３１６が識別領域の隣接領域も含めてスペースを検出するように依頼することも出来る。このことは、メタデータ管理要素３１６が、必ずしも正確なストレージコストでなくとも、欄９８７での適正なストレージコストに対して適切な範囲にあるスペースを検出することを意味する。
【０１３０】
0143  更に他の実施例として、現ストレージＩＤとステップ１４１２で比較した新ストレージＩＤが等しい場合には、メタデータ調整実行モジュール４１８は、バッファーに読み込む代わりに、当該ストレージデバイスに対して、単にデータオブジェクトを当該ストレージデバイス内の適切なアドレスに移動するように要求しても良い。
【０１３１】
0144  本発明の方法は、ＲＡＩＮアーキテクチュアの如き、異なった階層型ストレージ管理装置の実施例を用いて実行することが出来る。
【０１３２】
0145  図１３は本発明の第二実施例に従う、階層型データ管理装置のブロックダイアグラムを示す。
【０１３３】
0146  図１３に示す階層型データ管理装置１３００は、複数のアプリケーションサーバ１３０２、ネットワーク１３０８、及びネットワークとデータフロー１３１０にて互いに結合した複数のストレージシステムより成る。
【０１３４】
0147  ネットワーク内の複数のアプリケーションサーバ１３０２は、アプリケーションプログラム要素１３０４とデータアクセスクライアント要素１３０６を有する。複数のストレージシステムは、オンラインストレージシステム１３１２、ニアラインストレージシステム１３２２、及びオフラインストレージシステム１３３２等の異なったタイプのストレージシステムから成る。オンラインストレージシステム１３１２は、メタデータ管理ユニット１３１４、データ価値管理ユニット１３１６、階層型ストレージ管理ユニット１３１８、及びオンラインストレージデバイス１３２０を有する。ニアラインストレージシステム１３２２は、メタデータ管理ユニット１３２４、データ価値管理ユニット１３２６、階層型ストレージ管理ユニット１３２８、及びニアラインストレージデバイス１３３０を有する。オフラインストレージシステム１３３２は、メタデータ管理ユニット１３３４、データ価値管理ユニット１３３６、階層型ストレージ管理ユニット１３３８、及びオフラインストレージデバイス１３４０を有する。複数のアプリケーションサーバ１３０２と複数のストレージデバイスは、ネットワーク１３０８にコマンドフロー線を使用して結合する。これらの線は、ストレージデバイス間の概念的データフロ−を表す図１３のデータフロー線１３１０にて示す。実際のデータフローはネットワーク１３０８を通して実行される。
【０１３５】
0148  図３で示した階層型ストレージ管理装置と図１３での装置の間の主要な相違は、図１３の場合、オンライン、ニアライン又はオフラインの各ストレージシステムは、メタデータ管理ユニット、データ価値管理ユニット、階層型ストレージ管理ユニットを内部的に持ち、図３のようなＳＡＮ(Storage Area Network)又はＮＡＳ(Network Attached Storage)を通して、分離したメタデータサーバ３０４と外部的にデータ交信を行う必要がないことである。
【０１３６】
0149  メタデータ管理ユニット(１３１４、１３２４、１３３４)は自らのストレージシステム内のデータのメタデータを管理する。ストレージシステム内のメタデータ管理ユニットがユーザ／クライアントから要求されたデータオブジェクトを自システム内で検出できない場合には、この要求をこのデータオブジェクトを持ち得る他のストレージシステムに転送する。
【０１３７】
0150  データ価値管理ユニット(１３１６、１３２６、１３３６)は、自システム内に含まれるデータオブジェクトのデータ価値を管理する。データ価値の計算方法は、本発明の第一実施例と同様でデータアクセスレコードをベースとする。
【０１３８】
0151  階層型ストレージ管理ユニット(１３１８、１３２８、１３３８)は、各データ価値を正規化し、本発明の第一実施例で使用したのと同じ方法を用いて、適正なストレージコストを割り当てる。階層型ストレージ管理ユニットは、各ストレージデバイス内で管理すべきストレージコストの範囲を知っている。もし適正なストレージコストが自システム内に入っておれば、階層型ストレージ管理ユニットは、第一実施例で述べたのと同様な方法を用いて、メタデータを調整する。そうでなければ、階層型ストレージ管理ユニットは、ストレージコストをカバーし得る他のストレージシステムにこのデータオブジェクトを移動し、保存するように依頼する。
【０１３９】
0152  本発明の第二実施例のユニークな特徴は、メタデータ管理ユニットがどのデータオブジェクト(ＤＯＩＤ)を各子ノードが持っているかを問い合わせるのみならず、各子ノードがどのストレージコストをカバーするかを問い合わせることである。
【０１４０】
0153  本発明はストレージネットワークの範囲に限定されるものでない。当業者なら、ここでの記述に基づき本発明は他の環境でも実施できることを悟るであろう。
【０１４１】
0154  更に、本発明の多様な実施例を記述したが、それらの記述は例示として提示したもので、これに限定するのではないことを理解願いたい。当業者には、様式や詳細に亘る多様な変更が、本発明の精神や範囲を逸脱することなく適用可能なことは明らかであろう。
【０１４２】
0155  加えて、本発明は機能的ブロックや互いの関係を用いて記述してきた。これら機能的構成ブロックの境界や方法ステップは記述の便宜により、任意に定義してきた。指定された機能や互いの関係が適切に維持される限り、境界を変えることは可能である。そのような如何なる境界の変更も本発明でクレームされる範囲と精神に含まれる。当業者は、これらの機能ブロックは、図１２と図１３に関連して説明したように、ディスクリートコンポーネント、アプリケーションに指向した集積回路(ＡＳＩＣ)、適切なソフトウェアを実行するプロセッサ等、又はこれらの組み合わせで実現できることを認識するであろう。かくして、本発明の生命と範囲は、これまで事例的に述べたことに制限されることなく、後続する請求項及びそれと均等のものに従ってのみ定義されなければならない。
【図面の簡単な説明】
【０１４３】
【図１】図１はＤＬＣＭ(Data Life Cycle Management)情報で構成されるグラフを示す。
【図２】図２はＯＳＤ(Object based Storage Device)アーキテクチュアの一般的事例を示す。
【図３】図３は本発明の第一実施例に従う、ＯＳＤアーキテクチュアの一例を示す。
【図４】図４は図３で示した本発明の実施例に従う階層型データ管理フローの為の詳細ブロックダイアグラムを示す。
【図５】図５はメタデータテーブルの一例を示す。
【図６】図６はデータ価値テーブルの一例を示す。
【図７】図７はユーザ利益テーブルの一例を示す。
【図８】図８はストレージ特性テーブルの一例を示す。
【図９】図９は結合テーブルの一例を示す。
【図１０】図１０は図３でのデータ価値管理要素がデータ価値テーブルに新エントリを追加する為のフローチャートを示す。
【図１１】図１１はデータ価値計算の為のフローチャートを示す。
【図１２】図１２は図４での階層型ストレージ管理要素が実行するメタデータ調整計画の処理を示す。
【図１３】図１３は本発明の第二実施例に従う、階層型データ管理装置のブロックダイアグラムを示す。
【図１４】図１４はメタデータ調整の為のフローチャートを示す。
【符号の説明】
【０１４４】
１０    タイプ
１１    時間
１２    技術
２０２    アプリケーションサーバ
２０４    メタデータサーバ
２０６    ストレージデバイス
２０８    ＳＡＮ
２１０    ＬＡＮ
２１２    アプリケーションプログラム
２１４    データアクセスクライアント
２１６    メタデータ管理
【図１】
2006031668.tif 000003
【図２】
2006031668.tif 000004
【図３】
2006031668.tif 000005
【図４】
2006031668.tif 000006
【図５】
2006031668.tif 000007
【図６】
2006031668.tif 000008
【図７】
2006031668.tif 000009
【図８】
2006031668.tif 000010
【図９】
2006031668.tif 000011
【図１０】
2006031668.tif 000012
【図１１】
2006031668.tif 000013
【図１２】
2006031668.tif 000014
【図１３】
2006031668.tif 000015
【図１４】
2006031668.tif 000016
【外国語明細書】
2006031668.tif 000017
2006031668.tif 000018
2006031668.tif 000019
2006031668.tif 000020
2006031668.tif 000021
2006031668.tif 000022
2006031668.tif 000023
2006031668.tif 000024
2006031668.tif 000025
2006031668.tif 000026
2006031668.tif 000027
2006031668.tif 000028
2006031668.tif 000029
2006031668.tif 000030
2006031668.tif 000031
2006031668.tif 000032
2006031668.tif 000033
2006031668.tif 000034
2006031668.tif 000035
2006031668.tif 000036
2006031668.tif 000037
2006031668.tif 000038
2006031668.tif 000039
2006031668.tif 000040
2006031668.tif 000041
2006031668.tif 000042
2006031668.tif 000043
2006031668.tif 000044
2006031668.tif 000045
2006031668.tif 000046
2006031668.tif 000047
2006031668.tif 000048
2006031668.tif 000049
2006031668.tif 000050
【図１】
2006031668.tif 000051
【図２】
2006031668.tif 000052
【図３】
2006031668.tif 000053
【図４】
2006031668.tif 000054
【図５】
2006031668.tif 000055
【図６】
2006031668.tif 000056
【図７】
2006031668.tif 000057
【図８】
2006031668.tif 000058
【図９】
2006031668.tif 000059
【図１０】
2006031668.tif 000060
【図１１】
2006031668.tif 000061
【図１２】
2006031668.tif 000062
【図１３】
2006031668.tif 000063
【図１４】
2006031668.tif 000064