JP4648723B2 - データ価値に基づく階層型ストレージ管理の為の方法と装置 - Google Patents

Description

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 本発明の実施例は、データの生涯に亘ってユーザ利益に基づいてデータ価値を考慮した階層型データストレージ管理を提供することで、これらのニーズに取り組むものである。データは、算定された価値とストレージコストに基づいて、適切なストレージ資源に配置される。本発明により、データボリュームを最少コストで管理する拡張可能なネットワークアーキテクチュアが可能になる。

本発明による階層型ストレージデータ管理システムは、複数のアプリケーションサーバと、ＬＡＮ（ローカルエリアネットワーク）を通して前記複数のアプリケーションサーバに結合するメタデータサーバと、複数のデータフローパスにより結合され、それぞれ前記アプリケーションサーバからの要求に応じてデータオブジェクトを記憶する複数のストレージデバイスと、前記複数のストレージデバイスを前記複数のアプリケーションサーバと前記メタサーバに結合するストレージネットワークと、を備える階層型ストレージデータ管理システムであって、前記メタデータサーバは、前記ストレージデバイスに格納された各前記データオブジェクトの格納位置を管理するメタデータ管理要素と、前記ストレージデバイスに格納された各前記データオブジェクトに価値を割り当てるデータ価値管理要素と、階層型ストレージ管理要素と、を有し、前記データ価値管理要素は、前記メタデータ管理要素から前記データオブジェクトに対する複数のユーザ利益表示を受信する手段と、前記複数のユーザ利益表示を解析する手段と、各データオブジェクトのユーザ利益レベルを決定する手段と、前記ユーザ利益レベルに対応して前記各データオブジェクトにデータ価値を割り当てる手段と、を備え、前記ユーザ利益表示は、前記データオブジェクトから抽出したインデックス、書誌情報、及び用語の少なくとも一つと、前記データオブジェクトが保存されてから削除されるまでの寿命に関して該データオブジェクトに割り当てられた寿命値でなるデータ価値と、を含み、前記階層型ストレージ管理要素は、前記メタデータ管理要素から複数のストレージ領域に対する複数のストレージコスト表示を受信する手段と、前記複数のストレージコスト表示を解析する手段と、前記ストレージ領域に対してストレージコストレベルを決定する手段と、前記ストレージコストレベルに対応して前記ストレージ領域にストレージコスト値を割り当てる手段と、を備え、前記ストレージコスト表示は、前記ストレージ領域の平均性能と信頼性とを含み、前記メタデータサーバは、前記データ価値の区分を前記ストレージコスト値の区分と同一に設定することによって、前記データ価値管理要素で計算された複数のデータオブジェクトのデータ価値と、前記階層型ストレージ管理要素により割り当てられた前記ストレージデバイス内の複数のストレージ領域のストレージコスト値を正規化すると共に、正規化済データ価値を正規化済ストレージコスト値と比較して、前記データオブジェクトを別のストレージ領域に再配置するかどうかを決定し、データオブジェクトを、該データオブジェクトのデータ価値と等しいストレージコスト値を持つストレージ領域に再配置することを特徴とする。
また本発明による階層型ストレージデータ管理方法は、複数のアプリケーションサーバと、ＬＡＮ（ローカルエリアネットワーク）を通して前記複数のアプリケーションサーバに結合するメタデータサーバと、複数のデータフローパスにより結合され、それぞれ前記アプリケーションサーバからの要求に応じてデータオブジェクトを記憶する複数のストレージデバイスと、前記複数のストレージデバイスを前記複数のアプリケーションサーバと前記メタサーバに結合するストレージネットワークと、を備える階層型ストレージデータ管理システムによるストレージデータ管理方法であって、複数のデータオブジェクトとストレージネットワークで結合したストレージデバイス内の複数のストレージ領域をユーザに提示する第１のステップと、前記各データオブジェクトから抽出したインデックス、書誌情報、及び用語の少なくとも一つと前記データオブジェクトが保存されてから削除されるまでの寿命に関して該データオブジェクトに割り当てられた寿命値とを含み複数のユーザ利益表示を収集する収集ステップ、前記複数のユーザ利益表示を解析する解析ステップ、前記データオブジェクトに対してユーザ利益レベルを決定する決定ステップ、及び前記ユーザ利益レベルに対応して前記各データオブジェクトにデータ価値を割り当てる割当てステップを有し、各前記データオブジェクトに対してデータ価値を計算する第２のステップと、各ストレージ領域の平均性能と信頼性のデータを収集して複数のストレージコスト表示するステップ、前記複数のストレージコスト表示を解析するステップ、前記各ストレージ領域のストレージコストレベルを決定するステップ、及び前記ストレージコストレベルに対応させて事前指定の期間内でのアクセス回数又は前記各データオブジェクトが保存されてから削除されるまでの寿命を加算して前記各ストレージ領域にストレージコスト値を割り当てる第３のステップと、計算されたデータ価値と割り当てられたストレージコスト値を同一の値区分を持つように正規化する第４のステップと、正規化済データ価値を正規化済ストレージコスト値と比較して、前記データオブジェクトを別のストレージ領域に再配置すべきかどうかを決定する第５のステップと、データオブジェクトを、該データオブジェクトのデータ価値と等しいストレージコスト値を持つストレージ領域に再配置する第６のステップと、を備えることを特徴とする。

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)アーキテクチュアの一般的事例を示す。 図３は本発明の第一実施例に従う、ＯＳＤアーキテクチュアの一例を示す。 図４は図３で示した本発明の実施例に従う階層型データ管理フローの為の詳細ブロックダイアグラムを示す。 図５はメタデータテーブルの一例を示す。 図６はデータ価値テーブルの一例を示す。 図７はユーザ利益テーブルの一例を示す。 図８はストレージ特性テーブルの一例を示す。 図９は結合テーブルの一例を示す。 図１０は図３でのデータ価値管理要素がデータ価値テーブルに新エントリを追加する為のフローチャートを示す。 図１１はデータ価値計算の為のフローチャートを示す。 図１２は図４での階層型ストレージ管理要素が実行するメタデータ調整計画の処理を示す。 図１３は本発明の第二実施例に従う、階層型データ管理装置のブロックダイアグラムを示す。 図１４はメタデータ調整の為のフローチャートを示す。

符号の説明

１０ タイプ
１１ 時間
１２ 技術
２０２ アプリケーションサーバ
２０４ メタデータサーバ
２０６ ストレージデバイス
２０８ ＳＡＮ
２１０ ＬＡＮ
２１２ アプリケーションプログラム
２１４ データアクセスクライアント
２１６ メタデータ管理

Claims (20)

1. 複数のアプリケーションサーバと、
   ＬＡＮ（ローカルエリアネットワーク）を通して前記複数のアプリケーションサーバに結合するメタデータサーバと、
   複数のデータフローパスにより結合され、それぞれ前記アプリケーションサーバからの要求に応じてデータオブジェクトを記憶する複数のストレージデバイスと、
   前記複数のストレージデバイスを前記複数のアプリケーションサーバと前記メタサーバに結合するストレージネットワークと、
   を備える階層型ストレージデータ管理システムであって、
   前記メタデータサーバは、
   前記ストレージデバイスに格納された各前記データオブジェクトの格納位置を管理するメタデータ管理要素と、前記ストレージデバイスに格納された各前記データオブジェクトに価値を割り当てるデータ価値管理要素と、階層型ストレージ管理要素と、を有し、
   前記データ価値管理要素は、
   前記メタデータ管理要素から前記データオブジェクトに対する複数のユーザ利益表示を受信する手段と、前記複数のユーザ利益表示を解析する手段と、各データオブジェクトのユーザ利益レベルを決定する手段と、前記ユーザ利益レベルに対応して前記各データオブジェクトにデータ価値を割り当てる手段と、を備え、
   前記ユーザ利益表示は、
   前記データオブジェクトから抽出したインデックス、書誌情報、及び用語の少なくとも一つと、前記データオブジェクトが保存されてから削除されるまでの寿命に関して該データオブジェクトに割り当てられた寿命値でなるデータ価値と、を含み、
   前記階層型ストレージ管理要素は、
   前記メタデータ管理要素から複数のストレージ領域に対する複数のストレージコスト表示を受信する手段と、前記複数のストレージコスト表示を解析する手段と、前記ストレージ領域に対してストレージコストレベルを決定する手段と、前記ストレージコストレベルに対応して前記ストレージ領域にストレージコスト値を割り当てる手段と、を備え、
   前記ストレージコスト表示は、前記ストレージ領域の平均性能と信頼性とを含み、
   前記メタデータサーバは、
   前記データ価値の区分を前記ストレージコスト値の区分と同一に設定することによって、前記データ価値管理要素で計算された複数のデータオブジェクトのデータ価値と、前記階層型ストレージ管理要素により割り当てられた前記ストレージデバイス内の複数のストレージ領域のストレージコスト値を正規化すると共に、正規化済データ価値を正規化済ストレージコスト値と比較して、前記データオブジェクトを別のストレージ領域に再配置するかどうかを決定し、データオブジェクトを、該データオブジェクトのデータ価値と等しいストレージコスト値を持つストレージ領域に再配置する
   ことを特徴とする階層型ストレージデータ管理システム。
2. 前記複数のストレージデバイスは、
   複数のオンラインストレージデバテイスと、
   前記オンラインストレージデバイスよりも性能が低い複数のニアラインストレージデバイスと、
   前記ニアラインストレージデバイスよりも性能が低い複数のオフラインストレージデバイスと、
   の少なくとも一つからなる
   ことを特徴とする請求項１の階層型ストレージデータ管理システム。
3. 前記アプリケーションサーバは、
   前記ＬＡＮを通して相互結合し、前記ストレージネットワークを通して前記ストレージデバイスにアクセスし、
   前記ストレージネットワークと前記ストレージデバイスの各々との間にリンクが形成された
   ことを特徴とする請求項１の階層型ストレージデータ管理システム。
4. 前記各ストレージデバイスは、
   他のストレージデバイスに直接アクセスするリンクを有し、自らのメタデータを管理し、更に要求されたデータオブジェクトが自らのシステムに不在の場合には他のストレージデバイスに要求を転送する
   ことを特徴とする請求項１の階層型ストレージデータ管理システム。
5. 前記ユーザ利益表示は、
   前記データオブジェクトへのユーザのアクセスレコードでなる
   ことを特徴とする請求項１の階層型ストレージデータ管理システム。
6. 前記ユーザのアクセスレコードは、
   事前指定の期間内でのアクセス回数、又は前記データオブジェクトが保存されてから削除されるまでの寿命である
   ことを特徴とする請求項５の階層型ストレージデータ管理システム。
7. 前記ユーザのアクセスレコードは、複数のコマンドタイプで分類され、
   前記データ価値は、前記コマンドタイプの幾つか又は全ての前記ユーザのアクセスレコードの合計である
   ことを特徴とする請求項５の階層型ストレージデータ管理システム。
8. 前記アクセス回数は、アクセス頻度で重み付けする
   ことを特徴とする請求項６の階層型ストレージデータ管理システム。
9. 前記書誌情報は、
   著者、題目、キーワード、及び製作日を含む
   ことを特徴とする請求項１の階層型ストレージデータ管理システム。
10. 前記メタデータ管理要素は、
    前記データ価値管理要素からの前記データアクセスレコードに対する要求に答える為のインターフェースを持つ
    ことを特徴とする請求項５の階層型ストレージデータ管理システム。
11. 前記ストレージコスト値は、
    前記ストレージ領域がオンラインストレージデバイス、ニアラインストレージデバイス、オフラインストレージデバイスの何れに存在するかに従って、高から低まで変化する
    ことを特徴とする請求項１の階層型ストレージデータ管理システム。
12. 前記メタデータサーバは、
    前記データ価値の最大値を前記ストレージコスト値の最大値として使用し、これに従って他のストレージコスト値を調整する
    ことを特徴とする請求項１の階層型ストレージデータ管理システム。
13. 前記メタデータサーバは、
    前記ストレージコスト値の最大値をデータ価値の最大値として使用し、これに従って他のデータ価値を調整する
    ことを特徴とする請求項１の階層型ストレージデータ管理システム。
14. 複数のアプリケーションサーバと、
    ＬＡＮ（ローカルエリアネットワーク）を通して前記複数のアプリケーションサーバに結合するメタデータサーバと、
    複数のデータフローパスにより結合され、それぞれ前記アプリケーションサーバからの要求に応じてデータオブジェクトを記憶する複数のストレージデバイスと、
    前記複数のストレージデバイスを前記複数のアプリケーションサーバと前記メタサーバに結合するストレージネットワークと、
    を備える階層型ストレージデータ管理システムによるストレージデータ管理方法であって、
    複数のデータオブジェクトとストレージネットワークで結合したストレージデバイス内の複数のストレージ領域をユーザに提示する第１のステップと、
    前記各データオブジェクトから抽出したインデックス、書誌情報、及び用語の少なくとも一つと前記データオブジェクトが保存されてから削除されるまでの寿命に関して該データオブジェクトに割り当てられた寿命値とを含み複数のユーザ利益表示を収集する収集ステップ、前記複数のユーザ利益表示を解析する解析ステップ、前記データオブジェクトに対してユーザ利益レベルを決定する決定ステップ、及び前記ユーザ利益レベルに対応して前記各データオブジェクトにデータ価値を割り当てる割当てステップを有し、各前記データオブジェクトに対してデータ価値を計算する第２のステップと、
    各ストレージ領域の平均性能と信頼性のデータを収集して複数のストレージコスト表示するステップ、前記複数のストレージコスト表示を解析するステップ、前記各ストレージ領域のストレージコストレベルを決定するステップ、及び前記ストレージコストレベルに対応させて事前指定の期間内でのアクセス回数又は前記各データオブジェクトが保存されてから削除されるまでの寿命を加算して前記各ストレージ領域にストレージコスト値を割り当てる第３のステップと、
    計算されたデータ価値と割り当てられたストレージコスト値を同一の値区分を持つように正規化する第４のステップと、
    正規化済データ価値を正規化済ストレージコスト値と比較して、前記データオブジェクトを別のストレージ領域に再配置すべきかどうかを決定する第５のステップと、
    データオブジェクトを、該データオブジェクトのデータ価値と等しいストレージコスト値を持つストレージ領域に再配置する第６のステップと、
    を備えることを特徴とする階層型ストレージデータ管理方法。
15. 前記各データオブジェクトに対するアクセスは、複数のアクセス用コマンドタイプよりなり、
    前記各データ価値は、前記コマンドタイプの幾つか又は全ての前記アクセス回数の合計である
    ことを特徴とする請求項１４の階層型ストレージデータ管理方法。
16. 前記アクセス回数をアクセス頻度で重み付けする
    ことを特徴とする請求項１５の階層型ストレージデータ管理方法。
17. 前記書誌情報は、
    著者、題目、キーワード、及び製作日でなる
    ことを特徴とする請求項１４の階層型ストレージデータ管理方法。
18. 前記割当てステップは、
    前記各ストレージ領域がオンラインストレージデバイス、ニアラインストレージデバイス、オフラインストレージデバイスの何れに存在するかに従って、ストレージコスト値を高から低に変化させる
    ことを特徴とする請求項１４の階層型ストレージデータ管理方法。
19. 前記第４のステップは、
    前記データ価値の最大値を前記ストレージコスト値の最大値として使用し、これに従って他のストレージコスト値を調整するステップでなる
    ことを特徴とする請求項１４の階層型ストレージデータ管理方法。
20. 前記第４のステップは、
    前記ストレージコストの最大値を前記データ価値の最大値として使用し、これに従って他のデータ価値を調整するステップでなる
    ことを特徴とする請求項１４の階層型ストレージデータ管理方法。

Images