JP2016512634A

JP2016512634A - オブジェクトストレージインデキシングシステムのためのコンテンツクラス

Info

Publication number: JP2016512634A
Application number: JP2015559219A
Authority: JP
Inventors: イシャウッド，ベンジャミン; カッツ，ユーリー; ロジャース，リッチ
Original assignee: Hitachi Data System Corp
Current assignee: Hitachi Data System Corp
Priority date: 2013-02-27
Filing date: 2013-02-27
Publication date: 2016-04-28
Anticipated expiration: 2033-02-27
Also published as: US20160154833A1; JP6448555B2; EP4224324A2; EP2962217A4; US10817489B2; EP4224324A3; CN104981802A; US9965502B2; US20170192986A1; US20150278311A1; US9639564B2; WO2014133495A1; CN104981802B; EP2962217A1

Abstract

ストレージシステムは、コントローラと、メモリと、各オブジェクトがコンテンツデータとメタデータとを有する１以上のオブジェクトと、を備える。メタデータを用いて、ユーザ定義のコンテンツプロパティを構築し、各コンテンツプロパティは、そのコンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドをオブジェクトから抽出する能力を与える。それらのコンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化している。コントローラは、それらのコンテンツクラスのコンテンツプロパティをインデキシングして、インデックスを作成するように機能する。インデキシングされるコンテンツプロパティは、コンテンツプロパティ名で識別される。一部の実施形態では、コントローラは、異なるメタデータ・フォーマットでの異なる表現による同じ値を持つコンテンツプロパティについて、それらの異なる表現による値を、同じコンテンツプロパティ名で同じインデックスフィールドに入れることによって、インデックスを重複排除するように機能する。
【選択図】図１０

Description

本発明は、概して、ストレージシステムに関し、より具体的には、複製オブジェクトストレージシステムなどのストレージシステムにおいてオブジェクトの非構造化コンテンツ及びそのメタデータに構造体を提供するコンテンツクラスの使用に関するものである。

オブジェクトストレージシステムは、様々な非構造化コンテンツを格納することができる。この非構造化コンテンツは、コンテンツを追加的に記述するのに役立つ関連メタデータをさらに含み得る。このように多様なコンテンツ及び関連メタデータによって、ストレージ資源の多くの部分をインデックス専用とすることなくコンテンツのインデキシングを可能とする一般的な機構を提供することは難しくなる。

本発明の例示的な実施形態により、オブジェクトの非構造化コンテンツ及びそのメタデータ用の構造体を構築する青写真を定義するための機構を提供する。この機構は、「コンテンツクラス」と呼ばれる。これらのクラスは、ユーザ定義による「コンテンツプロパティ」のセットで構成される。各プロパティによって、ある特定のメタデータフィールド（例えば、いずれかのカスタムメタデータのＸＭＬタグ）をオブジェクトから抽出し、それをユーザ定義の名前で強い型付けによって効率的にインデキシングし、そのフィールドをユーザインタフェース及びプログラマチック・クエリインタフェースを介して多次元的にクエリ可能にする、ための能力が与えられる。

本発明の一態様によれば、ストレージシステムは、コントローラと、メモリと、それぞれコンテンツデータとメタデータとを含む１以上のオブジェクトとを備える。メタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築し、各コンテンツプロパティは、そのコンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドを１以上のオブジェクトから抽出する能力を与える。それらのコンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化している。コントローラは、それらのコンテンツクラスのコンテンツプロパティをインデキシングして、インデックスを作成するように機能する。インデキシングされるコンテンツプロパティは、コンテンツプロパティ名で識別される。

一部の実施形態では、コントローラは、異なるメタデータ・フォーマットでの異なる表現による同じ値を持つコンテンツプロパティについて、それらの異なる表現による値を、同じコンテンツプロパティ名で同じインデックスフィールドに入れることによって、インデックスを重複排除するように機能する。各コンテンツプロパティは、コンテンツプロパティ名を指定する名前フィールドに加えて、メタデータのコンテンツからコンテンツプロパティの値をどのように抽出すべきかを特定する表現フィールド、コンテンツプロパティの値のデータ型を指定するデータ型フィールド、数値及び日付データ型のフォーマットを指定するフォーマットフィールド、または、コンテンツプロパティで指定される表現は同じメタデータ・コンテンツ内で複数の値に評価される可能性があるかどうかを指定する複数値フィールド、のうち少なくとも１つを含む。コントローラは、コンテンツプロパティのインデックスを用いて、１以上のオブジェクトのコンテンツを検索するように機能する。コンテンツデータ及びメタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築する。

本発明の他の態様は、複数のノードを有するストレージシステムにおいてオブジェクトのコンテンツをインデキシングするための装置に関する。それらのノードは、複数のノードをそれぞれ有する複数のクラスタシステムにグループ分けされる。各オブジェクトは、コンテンツデータとメタデータとを有する。メタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築し、各コンテンツプロパティは、そのコンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドをそれらのオブジェクトから抽出する能力を与える。それらのコンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化している。装置は、コントローラとメモリとを備える。コントローラは、それらのコンテンツクラスのコンテンツプロパティをインデキシングして、インデックスを作成するように機能する。インデキシングされるコンテンツプロパティは、コンテンツプロパティ名で識別される。

一部の実施形態では、コントローラは、異なるメタデータ・フォーマットでの異なる表現による同じ値を持つコンテンツプロパティについて、それらの異なる表現による値を、同じコンテンツプロパティ名で同じインデックスフィールドに入れることによって、インデックスを重複排除するように機能する。コントローラは、コンテンツプロパティのインデックスを用いて、それらのオブジェクトのコンテンツを検索するように機能する。各クラスタシステムは、複数の名前空間に論理的に分割され、それぞれの名前空間は、オブジェクトの集まりを含むとともに、それに関連付けられたプライベートファイルシステムであって、該クラスタシステムの他の名前空間に対してプライベートなファイルシステムを有する。テナントは、名前空間をグループ化したものである。個々の名前空間のそれぞれで各コンテンツプロパティの設定を閲覧表示するのではなく、１つの場所からのテナント内の名前空間にわたって、コンテンツクラスでグループ分けされたコンテンツプロパティのコンテンツプロパティ設定を閲覧表示する方法が、コンテンツクラスによって提供される。

本発明の他の態様は、複数のノードを有するストレージシステムに関する。それらのノードは、複数のノードをそれぞれ有する複数のクラスタシステムにグループ分けされる。各オブジェクトは、コンテンツデータとメタデータとを有する。メタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築し、各コンテンツプロパティは、そのコンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドをそれらのオブジェクトから抽出する能力を与える。それらのコンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化している。オブジェクトのコンテンツをインデキシングする方法は、インデックスを作成するためにコンテンツクラスのコンテンツプロパティをインデキシングすることを含む。インデキシングされるコンテンツプロパティは、コンテンツプロパティ名で識別される。

本発明のこれらおよび他の特徴ならびに効果は、以下の具体的な実施形態についての詳細な説明を参照することで、当業者に明らかになるであろう。

本発明の方法および装置を適用することができる固定コンテンツストレージアーカイブの簡略ブロック図である。

独立ノードの冗長アレイの簡略図であり、それぞれノードは、対称であって、アーカイブクラスタアプリケーションをサポートしている。

所与のノードで実行されるアーカイブクラスタアプリケーションの各種コンポーネントの上位図である。

クラスタの所与のノードにおけるメタデータ管理システムのコンポーネントの一例を示している。

オブジェクトのコア構成の一例を示している。

メタデータ、および本明細書ではアノテーションと呼ばれるユーザ定義のメタデータの複数の名前付き集合のシステムを有するオブジェクトの一例を示している。

複数のアノテーションおよびアクセス制御リスト（ＡＣＬ）を有するオブジェクトの一例を示している。

オブジェクトの複数のアノテーションの使用を実現するための装置の一例を示している。

コンテンツクラス定義の一例を示している。

インデキシングシステムにおいてコンテンツクラスを利用するシステムの一例を示している。

本発明の以下の詳細な説明では、本開示の一部をなす添付の図面を参照し、それらの図面に、限定するものではない実例として、本発明を実施することができる例示的な実施形態を示している。図面では、本質的に類似したコンポーネントは、いくつかの図面にわたって同様の符号で示している。また、詳細な説明では、以下に記載するような、さらには図面に示すような、種々の例示的な実施形態を提示しているが、本発明は、本明細書で記載および図示される実施形態に限定されるものではなく、当業者に周知であるような、または周知となるような、他の実施形態に拡張することができるということに留意すべきである。本明細書における「一実施形態」、「本実施形態」、または「これらの実施形態」という表現は、その実施形態に関連して記載される特定の機能、構造、または特徴が、本発明の少なくとも１つの実施形態に含まれることを意味し、これらの表現が本明細書の様々な箇所に記載されていても、必ずしもそれらがすべて同じ実施形態を指しているとは限らない。また、本発明についての完全な理解を与えるため、様々な具体的詳細が以下の詳細な説明において記載される。しかしながら、これら特定の詳細は、すべてが本発明を実施するために必要とは限らないことは、当業者には明らかであろう。他の状況では、本発明を不必要に不明瞭にすることがないよう、周知の構造、材料、回路、プロセス、およびインタフェースについては詳細に記載しておらず、さらに／または、それらをブロック図の形式で示している場合がある。

また、以下の詳細な説明の一部は、コンピュータにおける演算のアルゴリズムおよび記号表現によって提示される。これらのアルゴリズム記述および記号表現は、データ処理技術の当業者が、自身の技術革新の本質を他の当業者に最も効果的に伝えるために用いる手段である。アルゴリズムは、所望の最終状態または結果に至る一連の定義されたステップである。本発明において、実施されるステップは、具体的な結果を得るための具体的な数量の物理的操作を必要とする。通常、これらの数量は、必ずしもではないが、記憶、伝達、結合、比較、およびその他の操作が可能な電気信号もしくは磁気信号または命令の形をとるものである。これらの信号は、ビット、値、要素、記号、文字、項、番号、命令などとして参照することが、一般的に使用されているという主な理由で、時として好都合であることが実証されている。しかしながら、留意すべきことは、これらおよび類似の表現はすべて、適切な物理量に関連付けられるべきであり、それらの数量に適用される単なる便宜的なラベルにすぎないということである。別段の規定がある場合を除き、以下の説明から明らかなように、本明細書全体を通して「処理する」、「演算する」、「計算する」、「判断する」、「表示する」などのような用語を使用する解説は、コンピュータシステムのレジスタおよびメモリ内の物理的（電子的）な量として表されるデータを、コンピュータシステムのメモリもしくはレジスタ内または他の情報記憶、伝達、または表示装置内で同様に物理量として表される他のデータに操作および変換する、コンピュータシステムまたは他の情報処理装置のアクションおよびプロセスを含み得るものと理解される。

本発明は、さらに、本明細書に記載のオペレーションを実行するための装置に関する。この装置は、所要の目的のために専用に構築することができ、または１以上のコンピュータプログラムにより選択的にアクティブ化または再構成される１以上の汎用コンピュータを含むことができる。かかるコンピュータプログラムは、限定するものではないが、光ディスク、磁気ディスク、読み取り専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびドライブ、または電子情報を保存するのに適した他の任意のタイプの媒体など、非一時的媒体を含むコンピュータ可読記憶媒体に保存することができる。本明細書で提示するアルゴリズムならびに表示は、本来、特定のコンピュータまたは他の装置に関連したものではない。種々の汎用システムを、本明細書に記載の教示によるプログラムおよびモジュールと共に用いることができ、または所望の方法ステップを実行するために、より特化した装置を構築するほうが適当であることが実証される場合がある。また、本発明は、いずれかの特定のプログラミング言語に準拠して説明されるものではない。当然のことながら、本明細書に記載の発明の教示を実施するために、様々なプログラミング言語を用いることができる。プログラミング言語（複数の場合もある）による命令は、例えば中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラである１以上の処理装置で実行することができる。

さらに詳細に以下で説明する本発明の例示的な実施形態により、オブジェクトの非構造化コンテンツ及びそのメタデータ用の構造体を構築する青写真を定義するため、ならびに効率的なインデキシング及び検索を容易にするための、コンテンツクラスと呼ばれる機構を提供する装置、方法、ならびにコンピュータプログラムを提供する。

Ｉ．固定コンテンツ分散データストレージ

従来のテープおよび光学ストレージ・ソリューションに取って代わるかまたはそれを補う、高可用性かつ高信頼性の永続的な「固定コンテンツ」のアーカイブストレージに対する必要性が高まっている。「固定コンテンツ」という用語は、一般に、参照または他の目的のために変更なく保持されると予想される任意のタイプのデジタル情報を指す。このような固定コンテンツの例として、数ある中でも、電子メール、文書、診断画像、チェック画像、音声録音、フィルムおよびビデオなどが挙げられる。従来の独立ノード冗長アレイ（ＲＡＩＮ：Redundant Array of Independent Nodes）ストレージ方式は、このような固定コンテンツ情報資産の保存用の大規模なオンラインアーカイブを作成するために選択されるアーキテクチャとして出現した。ＲＡＩＮアーキテクチャは、ノードを必要に応じてクラスタに加えたり外したりすることを可能とすることによって、１以上のノードの障害からストレージクラスタを遮断する。複数ノード上にデータを複製することによって、ＲＡＩＮ型アーカイブはノード障害または削除を自動的に補償することができる。一般に、ＲＡＩＮシステムは、多くは、閉システム内の同一のコンポーネントから設計されたハードウェア装置として供給される。

図１は、そのようなスケーラブルなディスクベースのアーカイブストレージ管理システムの一例を示している。それらのノードは、異なるハードウェアを備えることができ、その場合、「異種」とみなすことができる。ストレージエリアネットワーク（ＳＡＮ）におけるように、各ノードは、一般に、実際の物理ストレージディスクまたは仮想ストレージディスクとすることができる１以上のストレージディスクへのアクセスを有する。各ノードでサポートされるアーカイブクラスタアプリケーション（さらに、オプションとして、そのアプリケーションが実行される基礎となるオペレーティングシステム）は、同じであるか、または略同じとすることができる。各ノード上のソフトウェアスタック（オペレーティングシステムを含み得る）は対称であるが、一方、ハードウェアは異種とすることができる。図１に示すようなシステムを使用して、企業は、とりわけ文書、電子メール、衛星画像、診断画像、チェック画像、音声録音、ビデオなど、多くの異なるタイプの固定コンテンツ情報用のパーマネントストレージを作成することができる。当然のことながら、これらのタイプは単なる例示にすぎない。独立サーバまたはいわゆるストレージノード上でデータを複製することにより、高レベルの信頼性が達成される。好ましくは、各ノードは、そのピアと対称である。従って、好ましくは所与のノードはいずれも全ての機能を実行することができるので、いずれか１つのノードの障害がアーカイブの可用性に及ぼす影響はほとんどない。

本出願と同一の所有者による米国特許第７１５５４６６号に記載されているように、ＲＡＩＮベースのアーカイブシステムにおいて、デジタル資産を収集、保存、管理、及び検索する各ノード上で実行される分散ソフトウェアアプリケーションを導入することが知られている。図２は、そのようなシステムを示している。個々のアーカイブの物理的境界は、クラスタ（またはシステム）と呼ばれる。典型的には、クラスタは単一の装置ではなく、装置の集まりである。装置は、同種または異種のものとすることができる。典型的な装置は、Ｌｉｎｕｘなどのオペレーティングシステムが作動するコンピュータまたはマシンである。汎用ハードウェアでホストされるＬｉｎｕｘベースのシステムのクラスタにより、数台のストレージノードサーバから、数千テラバイトのデータを保存する多数のノードまでの、スケーラブルなアーカイブが提供される。このアーキテクチャにより、組織の増大するアーカイブ要求に常にストレージ容量を合わせ得ることが確保される。

上述のようなストレージシステムでは、一般に、アーカイブが装置障害から常に保護されるように、データはクラスタ全体にランダムに分散される。ディスクまたはノードが故障すると、クラスタは、そのクラスタ内の同データの複製を保持している他のノードに自動的にフェイルオーバする。このアプローチは、データ保護の観点からは十分に機能するが、クラスタについて計算された平均データ損失時間（ＭＴＤＬ：ＭｅａｎＴｉｍｅｔｏＤａｔａＬｏｓｓ）は、要求に応えるほどには高くない場合がある。具体的には、ＭＴＤＬは、一般に、アーカイブがデータを損失するまでの算出された時間を表す。デジタルアーカイブでは、いかなるデータ損失も望ましくはないが、ハードウェアコンポーネント及びソフトウェアコンポーネントの性質上、その発生の可能性は（わずかではあるが）常にある。オブジェクト及びそれらのコピーがアーカイブクラスタ内にランダムに分散されていることから、例えば、あるノード内の（ミラーコピーが保存されている）あるディスクが予想外に故障すると、オブジェクトの必要なコピーが利用できない場合があることにより、ＭＴＤＬは、結局は要求よりも低くなり得る。

本発明が実施される例示的なクラスタは、図２に示すように、好ましくは、以下の大別カテゴリのコンポーネントを含む：ノード２０２、一対のネットワークスイッチ２０４、電力配分装置（ＰＤＵ）２０６、及び無停電電源装置（ＵＰＳ）２０８。ノード２０２は、典型的には１以上の汎用サーバを備え、ＣＰＵ、適切なランダムアクセスメモリ（ＲＡＭ）、１以上のハードドライブ（例えば、標準ＩＤＥ／ＳＡＴＡ、ＳＣＳＩなど）、及び２つ以上のネットワークインタフェースカード（ＮＩＣ）を収容している。典型的なノードは、２．４ＧＨｚチップ、５１２ＭＢＲＡＭ、及び６つの２００ＧＢハードドライブを備えた２Ｕラックマウントユニットである。ただし、これに限定されない。ネットワークスイッチ２０４は、典型的には、ノード間のピアツーピア通信を可能にする内部スイッチ２０５と、各ノードへの追加クラスタアクセスを可能にする外部スイッチ２０７と、を備える。各スイッチは、クラスタ内の全てのあり得るノードを扱うのに十分なポートが必要である。この目的で、イーサネットまたはＧｉｇＥスイッチを使用することができる。ＰＤＵ２０６は、全てのノード及びスイッチへの通電のために使用され、また、全てのノードおよびスイッチを保護するＵＰＳ２０８が使用される。限定するものではないが、クラスタは、一般に、公衆インターネット、企業イントラネット、または他の広域もしくはローカルエリアネットワークのようなネットワークに接続可能である。例示的な一実施形態では、クラスタは企業環境において実現される。それには、例えばサイトの企業ドメインネームシステム（ＤＮＳ）ネームサーバを通してナビゲートすることより、到達できる。この場合、例えば、クラスタのドメインは、既存のドメインの新規のサブドメインとすることができる。典型的な実現形態では、サブドメインは、企業ＤＮＳサーバにおいて、そのクラスタ自体のネームサーバにデリゲートされる。エンドユーザは、一般的なインタフェースまたはアクセスツールを用いてクラスタにアクセスする。この場合、例えば、クラスタへのアクセスは、任意のＩＰベースのプロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、Ｗｅｂサービスなど）で、ＡＰＩ（アプリケーションプログラムインタフェース）を介して、または他の周知もしくは後に開発されるアクセス方式、サービス、プログラム、もしくはツールで、実施することができる。

クライアントアプリケーションは、標準的ＵＮＩＸファイルプロトコルまたはＨＴＴＰＡＰＩなどの１以上のタイプの外部ゲートウェイを介してクラスタにアクセスする。アーカイブは、好ましくは、任意の標準ＵＮＩＸファイルプロトコル向きファシリティの下に任意選択的に配置することができる仮想ファイルシステムを通して、公開される。これらには、ＮＦＳ、ＦＴＰ、ＳＭＢ／ＣＩＦＳなどが含まれる。

一実施形態において、アーカイブクラスタアプリケーションは、クラスタとして（例えばイーサネットで）相互にネットワーク接続された独立ノードからなる冗長アレイ（Ｈ−ＲＡＩＮ）上で動作する。それらのノードのハードウェアは、異種のものとすることができる。しかしながら、最大限の信頼性を得るためには、各ノードは、以下で図３に示すように、いくつかのランタイムコンポーネントを含む分散アプリケーションのインスタンス３００（同じインスタンスまたは略同じインスタンスとすることができる）を実行することが好ましい。このように、ハードウェアは異種のものであってもよいが、ノード上のソフトウェアスタックは、（少なくとも本発明に関連する限りにおいて）同じものである。これらのソフトウェアコンポーネントは、ゲートウェイプロトコル層３０２、アクセス層３０４、ファイルトランザクション／管理層３０６、及びコアコンポーネント層３０８を構成している。「層」という呼称は説明のためのものであって、当業者であれば理解できるように、それらの機能を他の有意義な方法で特徴付けてもよい。これらの層（またはその中のコンポーネント）の１以上を、統合することができ、またはその逆も可能である。一部のコンポーネントを、層間で共有することができる。

ゲートウェイプロトコル層３０２内のゲートウェイプロトコルは、既存のアプリケーションへの透過性を提供する。具体的には、ゲートウェイは、ＮＦＳ３１０及びＳＭＢ／ＣＩＦＳ３１２のようなネイティブファイルサービスを提供するとともに、カスタムアプリケーションを構築するためのＷｅｂサービスＡＰＩを提供する。さらに、ＨＴＴＰサポート３１４を提供する。アクセス層３０４は、アーカイブへのアクセスを提供する。具体的には、本発明によれば、固定コンテンツファイルシステム（ＦＣＦＳ）３１６がネイティブファイルシステムをエミュレートすることで、アーカイブオブジェクトへのフルアクセスを提供する。ＦＣＦＳは、アーカイブコンテンツがまるで通常のファイルであるかのように、それらへの直接アクセスをアプリケーションに与える。好ましくは、アーカイブされたコンテンツは、そのオリジナルフォーマットでレンダリングされ、メタデータはファイルとして公開される。ＦＣＦＳ３１６は、ディレクトリおよびパーミッションの通常のビューと、ルーチンファイルレベルコールとを提供し、これにより、管理者は、自身が熟知している方法で固定コンテンツデータをプロビジョニングすることができる。ファイルアクセスコールは、好ましくは、ユーザ空間デーモンによりインタセプトされて、（層３０８の）適切なコアコンポーネントにルーティングされ、このコアコンポーネントは、呼出し側アプリケーションに対して適切なビューを動的に生成する。ＦＣＦＳコールは、好ましくは、自律的なアーカイブ管理を容易にするためにアーカイブポリシーによって制約される。従って、一例では、管理者またはアプリケーションは、保存期間（所与のポリシー）がまだ有効であるアーカイブオブジェクトを削除することはできない。

アクセス層３０４は、さらに、Ｗｅｂユーザインタフェース（ＵＩ）３１８及びＳＮＭＰゲートウェイ３２０を含むことが好ましい。Ｗｅｂユーザインタフェース３１８は、好ましくは、ファイルトランザクション／管理層３０６の管理エンジン３２２への対話型アクセスを提供する管理コンソールとして実現される。管理コンソール３１８は、好ましくは、パスワード保護されたＷｅｂベースのＧＵＩであって、アーカイブオブジェクト及び個々のノードを含むアーカイブの動的ビューを提供するものである。ＳＮＭＰゲートウェイ３２０は、管理エンジン３２２への容易なアクセスをストレージ管理アプリケーションに提供して、それらがクラスタアクティビティを安全に監視および制御することを可能とする。管理エンジンは、システムイベント及びポリシーイベントを含むクラスタアクティビティを監視する。さらに、ファイルトランザクション／管理層３０６は、要求マネージャプロセス３２４を含む。要求マネージャ３２４は、（アクセス層３０４を通した）外界からの全ての要求、ならびにコアコンポーネント層３０８のポリシーマネージャ３２６からの内部要求をオーケストレートする。

コアコンポーネントには、ポリシーマネージャ３２６に加えて、さらに、メタデータマネージャ３２８、及びストレージマネージャ３３０の１以上のインスタンスが含まれる。メタデータマネージャ３２８は、好ましくは、各ノード上にインストールされる。クラスタ内のメタデータマネージャは、共同で分散データベースとして機能して、全てのアーカイブオブジェクトを管理する。所与のノードにおいて、メタデータマネージャ３２８は、アーカイブオブジェクトのサブセットを管理し、その場合、好ましくは、各オブジェクトは、外部ファイル（「ＥＦ」、保存用のアーカイブに加えられたデータ）と、アーカイブデータが物理的に配置された内部ファイル（それぞれ「ＩＦ」）のセットとの間でマッピングする。同じメタデータマネージャ３２８が、さらに、他のノードから複製されたアーカイブオブジェクトのセットも管理する。従って、すべての外部ファイルの現在の状態を、いくつかのノード上の複数のメタデータマネージャで常に利用することができる。ノード障害の場合には、他のノード上のメタデータマネージャが、障害ノードでそれまで管理されていたデータへのアクセスを引き続き提供する。ストレージマネージャ３３０は、分散アプリケーションの他の全てのコンポーネントで利用できるファイルシステム層を提供する。これにより、好ましくは、データオブジェクトは、ノードのローカルファイルシステムに保存される。所与のノードにおける各ドライブは、好ましくは、それに専用のストレージマネージャを有する。これにより、そのノードは、ドライブを個別に削除することが可能となり、スループットを最適化することができる。ストレージマネージャ３３０は、さらに、システム情報、データの完全性チェックを提供するとともに、ローカル構造をトラバースすることを可能とする。

同じく図３に示すように、クラスタは、通信ミドルウェア層３３２及びＤＮＳマネージャ３３４を介して、内部通信および外部通信を管理する。インフラストラクチャ３３２は、アーカイブコンポーネント間の通信を可能にする効率的かつ高信頼性のメッセージベースのミドルウェア層である。例示的な一実施形態では、この層は、マルチキャスト通信及びポイントツーポイント通信をサポートする。ＤＮＳマネージャ３３４は、全てのノードを企業サーバに接続する分散ネームサービスを実行する。好ましくは、ＤＮＳマネージャは（単独で、またはＤＮＳサービスと共に）、全てのノード間に要求の負荷を分散することで、最大限のクラスタスループット及び可用性を確保する。

例示的な一実施形態では、アプリケーションインスタンスは、Ｌｉｎｕｘなどの基本オペレーティングシステム３３６上で実行される。通信ミドルウェアは、任意の適当な分散通信機構である。他のコンポーネントには、固定コンテンツファイルシステム（ＦＣＦＳ）３１６のために使用できるＦＵＳＥ（Filesystem in USErspace）を含むことができる。ＮＦＳゲートウェイ３１０は、標準ｎｆｓｄＬｉｎｕｘカーネルＮＦＳドライバによって実現することができる。各ノードのデータベースは、オブジェクトリレーショナルデータベース管理システム（ＯＲＤＢＭＳ）によって実現することができる。ノードは、ＪａｖａＨＴＴＰサーバ／サーブレットコンテナであるＪｅｔｔｙなどのＷｅｂサーバを含むことができる。当然のことながら、上記の機構は単なる例示にすぎない。

所与のノードのストレージマネージャ３３０は、物理ストレージデバイスを管理することを担う。好ましくは、各ストレージマネージャインスタンスは１つのルートディレクトリを担当し、そこに、その配置アルゴリズムに従って全てのファイルが配置される。１つのノードで複数のストレージマネージャインスタンスを同時に実行することができ、それぞれは、通常、システムにおける異なる物理ディスクを表す。ストレージマネージャは、システムの他の部分から使用されるドライブ及びインタフェース技術を要約する。ストレージマネージャインスタンスは、ファイルの書き込みを依頼されると、担当することになる表現のフルパス及びファイル名を生成する。典型的な一実施形態では、ストレージマネージャに保存される各オブジェクトは、保存されるべき生データとして受け取られ、そしてそれを保存する際に、ストレージマネージャにより、それ自身のメタデータが、種々のタイプの情報を追跡するためにファイルに追加される。例として、このメタデータには、ＥＦ長（バイトで表された外部ファイルの長さ）、ＩＦセグメントサイズ（内部ファイルの当該部分のサイズ）、ＥＦ保護表示（ＥＦ保護モード）、ＩＦ保護ロール（当該内部ファイルの表現）、ＥＦ作成タイムスタンプ（外部ファイルのタイムスタンプ）、シグネチャ（シグネチャタイプを含む、書き込み（ＰＵＴ）時の内部ファイルのシグネチャ）、及びＥＦファイル名（外部ファイルのファイル名）が含まれる。内部ファイルデータと共にこの追加メタデータを保存することにより、追加的な保護レベルが提供される。具体的には、スキャベンジングによって、内部ファイルに保存されたメタデータから、データベース内に外部ファイルレコードを作成することができる。他のポリシーにより、内部ファイルに対して内部ファイルハッシュを検証することで、内部ファイルに損傷がないことを確認することができる。

内部ファイルは、アーカイブオブジェクトにおけるオリジナル「ファイル」の一部を表すデータの「チャンク」とすることができ、それらを、ストライピング及び保護ブロックを実現するように、いくつかの異なるノードに配置することができる。ただし、このように外部ファイルをより小さいチャンク単位に分割することは必要条件ではなく、代替案では、内部ファイルは、外部ファイルの完全コピーとすることができる。一般に、メタデータマネージャには、各アーカイブオブジェクトに対して１つの外部ファイルエントリが存在し、それぞれの外部ファイルエントリに対して多くの内部ファイルエントリが存在し得る。一般に、内部ファイルレイアウトは、そのシステムに依存する。特定の実現形態において、ディスク上のそのデータの実際の物理フォーマットは、一連の可変長レコードに格納される。

要求マネージャ３２４は、システム内の他のコンポーネントと対話することによって、アーカイブアクションを実施するのに必要な一連のオペレーションを実行することを担う。要求マネージャは、種々のタイプの多くの同時アクションをサポートし、失敗したトランザクションがあればそれをロールバックすることができ、また、実行に長時間を要し得るトランザクションをサポートする。要求マネージャは、さらに、アーカイブにおいて読み出し／書き込みオペレーションが適切に処理されることを確保するとともに、全ての要求が常に既知の状態にあることを保証する。さらに、それは、所与のクライアント要求に応えるために、複数の読み出し／書き込みオペレーションをノード間で調整するためのトランザクション制御を提供する。加えて、要求マネージャは、最近使用されたファイルのメタデータマネージャエントリをキャッシュするとともに、セッションならびにデータブロックのバッファリングを提供する。

クラスタの主要な役割は、無制限の数のファイルを高信頼度でディスクに保存することである。所与のノードが、何らかの理由で到達不可能であるか、それ以外にも利用できない場合があると、その意味で「信頼性に欠ける」ものと評価されることがある。このように低信頼性の可能性があるノードの集まりの協働によって、高信頼性かつ高可用性のストレージを形成する。一般に、保存する必要のある情報には、ファイル自体と、ファイルに関するメタデータという２つのタイプがある。固定コンテンツ分散データストレージについての更なる詳細は、参照により本明細書に組み込まれる米国特許出願公開第２００７／０１８９１５３号及び米国特許第７６５７５８１号に記載されている。

名前空間（ＮＳ）とは、クラスタの論理パーティションである。名前空間は、基本的に、少なくとも１つの規定されたアプリケーションに固有のオブジェクトの集まりとしての役割を果たす。後述されるように、それぞれの名前空間は、他の名前空間に対してプライベートなファイルシステムを有する。また、１つの名前空間にアクセスすると、別の名前空間へのユーザアクセスは認められない。アーカイブは、１つのクラスタで許容される名前空間数の上限（例えば、１０，０００まで）を有し得る。認証名前空間（ＡＮＳ）は、認証データアクセスを必要とする名前空間（好ましくは、ＨＴＴＰ専用）である。デフォルト名前空間（ｄＮＳ）は、ＲＥＳＴ（Representational State Transfer）以外でクラスタにインジェストされたデータで使用するための名前空間であり、ＲＥＳＴは、ウェブ上で構造化データおよび型情報を交換するために一般に使用される軽量プロトコルである。また、アプリケーションがＲＥＳＴインタフェースを使用する場合であっても、クラスタへの認証時に名前空間が指定されなければ、全てのデータをデフォルト名前空間に保存することができる。テナントは、名前空間（複数の場合もある）及び場合によっては他のサブテナントをグループ化したものである。最上位テナント（ＴＬＴ：Top-Level Tenant）は、親テナントを持たないテナント、例えば企業である。サブテナントは、その親が別のテナントであるテナントであり、例えば企業の財務部である。デフォルトテナントは、デフォルト名前空間のみを含む最上位テナントである。クラスタ（またはシステム）は、上述のような物理的アーカイブインスタンスである。その全体が参照により本明細書に組み込まれる米国特許出願公開第２０１１／０１０６８０２号を参照する。

マクロレベルでは、全ての名前空間は、同じ品質及び機能を有する同じまたは略同じエンティティと考えることができる。一般的に、そして後に分かるように、名前空間は、関連付けられた機能のセットを有し、それらを、適切に認証された管理者によって決定されるように有効または無効にすることができる。１つの名前空間で１以上のアプリケーションをホストすることができるものの、１つの名前空間は、１つの規定されたアプリケーションのみに関連付けられることが好ましい（ただし、これに限定されない）。名前空間は、典型的には、所与のデータアカウントに対して有効または無効にするように名前空間管理者が選択することができる関連機能の以下のセットのうち、１以上を有する：ファイルの読取り、ディレクトリリストの作成、およびexists／ＨＥＡＤオペレーションを含む読取り（ｒ）；書込み（ｗ）；削除（ｄ）；ファイルのすべてのバージョンのパージを許可するパージ（ｐ）；特権的削除および特権的パージを許可する特権（Ｐ）；および検索（ｓ）。

名前空間を用いて、管理者は、クラスタの複数のドメインを作成することができ、それらのドメインは、ユーザ／アクタの立場によって異なるものである。これらのドメインには、例えば以下のようなものが含まれる：アクセスアプリケーション、クラスタ管理者、ＴＬＴ管理者、サブテナント管理者、および複製。アクセスアプリケーションのドメインは、所与の名前空間である。テナントは、好ましくは、属性のセットを有し、それらは、名前空間、管理アカウント、データアクセスアカウント、許可マスク、ロールアップ状態、名前、およびクォータである。テナントは、ゼロ個以上の名前空間を含み得る。

名前空間は、アプリケーションから見た論理的アーカイブである。本明細書に記載の主題によれば、特定の名前空間は、別の名前空間と区別されるものであり、１つの名前空間にアクセスすると、別の名前空間へのユーザアクセスは認められない。好ましくは、名前空間の管理は、所有するテナントレベルで実行される。また、好ましくは、名前空間は、その名前空間に関連付けられているオブジェクトの数がゼロである場合にのみ削除することができる。さらに、名前空間は、好ましくは、以下の属性を有する：許可マスク、初期設定、その他の設定、表示名、クォータ、ログ、および統計。上述のように、許可マスク（ｒ／ｗ／ｄ／ｐ／Ｐ／ｓ）は、その名前空間にグローバルな設定のセットであり、これにより、アカウントのパーミッションをマスクする。初期設定は、データ保護レベル（ＤＰＬ）、ハッシング方式などを特定し、これらは、永続的に維持されることが好ましい。その他の設定は、その名前空間において設定して後に変更することができる設定（リテンション、シュレッド、バージョニング、インデキシングなど）を指す。表示名は、名前空間の名前または他の識別子である。クォータは、（ＧＢで表す）ハードか、または（パーセントで表す）ソフトのいずれかである。ログ属性は、その名前空間に関連してログ記録されるシステムイベントを特定する。統計属性は、容量、オブジェクト数など、名前空間に関連したデータから生成される統計を特定する。

ＩＩ．メタデータ管理

メタデータ管理システムは、システムメタデータなどの所定のメタデータを編成し、それへのアクセスを提供することを担う。このシステムメタデータは、アーカイブに配置されるファイルに関する情報を含むとともに、構成情報、管理ＵＩに表示される情報、メトリクス、回復不能なポリシー違反に関する情報などを含む。詳細には例示していないが、さらに他のタイプのメタデータ（例えば、アーカイブされたファイルに関連付けられたユーザメタデータ）も、以下で説明するメタデータ管理システムを用いて管理することができる。

クラスタの典型的な一実施形態では、メタデータ管理システムは、（単なる例示にすぎない）以下のオブジェクトタイプのうちの１以上を含み得るメタデータオブジェクトのセットに対して永続性を提供する。

ExternalFile：アーカイブのユーザによって知覚されるファイル。

InternalFile：ストレージマネージャによって保存されたファイル。典型的には、外部ファイルと内部ファイルとの間に１対多の関係があり得る。

ConfigObject：クラスタを構成するために使用される名前／値ペア。

AdminLogEntry：管理ＵＩに表示されるメッセージ。

MetricsObject：ある時点におけるアーカイブの何らかの測度（例えば、ファイル数）を表すタイムスタンプ付きのキー／値ペア。

PolicyState：何らかのポリシー違反。

各メタデータオブジェクトは、好ましくは変更されない固有の名前を有し得る。メタデータオブジェクトは、リージョンに編成されている。各リージョンは、正式なリージョンコピーと、「許容障害」（ＴＰＯＦ：Tolerable Points Of Failure）数のバックアップリージョンコピー（ゼロ個以上からなるセット）と、を含む。ゼロ個のコピーの場合、メタデータ管理システムは、スケーラブルであるが、高可用性ではない可能性がある。リージョンは、１以上のオブジェクト属性（例えば、完全修飾パス名などのオブジェクト名、またはその一部）をハッシュ化して、そのハッシュ値から所定数のビットを抽出することにより、選択される。これらのビットは、リージョン番号を構成する。選択されるビットは、下位ビット、上位ビット、中位ビット、または個々のビットの任意の組み合わせとすることができる。典型的な一実施形態では、所定のビットは、ハッシュ値の下位ビットである。オブジェクトの属性またはいくつかの属性は、任意の適当なハッシュ関数を用いてハッシュ化することができる。これらには、限定するものではないが、java.lang.string.hashCodeのようなＪａｖａベースのハッシュ関数などが含まれる。好ましくは、リージョン番号を構成するビット数は、本明細書においてｒｅｇｉｏｎＭａｐＬｅｖｅｌと呼ばれる構成パラメータにより制御される。この構成パラメータが、例えば６に設定されると、その結果、２^６＝６４のリージョンが得られる。当然のことながら、さらに多くのリージョン数も許容され、リージョン数は、名前空間パーティション構成を用いて自動的に調整することができる。

各リージョンは、重複して保存することができる。上述のように、リージョンには、１つの正式コピーと、ゼロ個以上のバックアップコピーがある。前述のように、バックアップコピーの数は、メタデータＴＰＯＦ構成パラメータによって制御される。好ましくは、ノードあたりの正式リージョンコピー数のバランスをとるとともに、ノードあたりのリージョンコピー総数のバランスをとるように、リージョンコピーは、クラスタの全てのノード間に分散される。

メタデータ管理システムは、各ノードで作動するデータベースにメタデータオブジェクトを保存する。このデータベースは、リージョンマップをサポートするために用いられる。好ましくは、リージョンコピーごとにスキーマがあり、各スキーマには、メタデータオブジェクトのタイプごとにテーブルがある。スキーマは、簡単には、テーブル、インデックス、プロシージャ、及びその他のデータベースオブジェクトを所有し得る名前空間である。各リージョンは、好ましくは、それに専用のスキーマを有する。各スキーマは、各メタデータオブジェクトに対して１つのテーブルからなる、テーブルの完全なセットを有する。これらのテーブルのうちの１つにおける１つの行が、１つのメタデータオブジェクトに対応する。

図４に示すように、各ノード４００は、プロセスまたはコンポーネントのセットを有し、すなわち、１以上のリージョンマネージャ（ＲＧＭ）４０２ａ〜ｎと、メタデータマネージャ（ＭＭ）４０４と、少なくとも１つのメタデータマネージャクライアント（ＭＭＣ）４０６と、１以上のスキーマ４１０ａ〜ｎを含むデータベース４０８と、を有する。ＲＧＭ（複数の場合もある）、ＭＭ、及びＭＭＣコンポーネントは、Ｊａｖａ仮想マシンのような仮想マシン４１２で実行される。リージョンコピーごとに１つのＲＧＭがある。従って、正式リージョンコピー用のＲＧＭ、各バックアップリージョンコピー用のＲＧＭ、及びそれぞれの不完全リージョンコピー用のＲＧＭがある。さらに、ＲＧＭ４０２ごとに、そのＲＧＭを管理するデータベーススキーマ４１０がある。データベースは、さらにリージョンマップ４０５を格納している。各ノードは、好ましくは、同期方式により強制される要件を備えた、リージョンマップの同じグローバルビューを有する。リージョンマネージャＲＧＭ４０２は、（場合によって、正式、バックアップ、または不完全のものである）リージョンコピーに対するオペレーション、ならびにメタデータマネージャクライアント４０６及び他のリージョンマネージャ４０２により出された要求の実行を担う。要求は、図３に示す通信ミドルウェアまたは他のメッセージング層などの任意の適当な手段を通して所定のＲＧＭに供給される。リージョンマネージャは、例えばデータベースへの接続を提供することによって、そのＲＧＭが管理しているスキーマで動作するように構成された、それらの要求を実行する実行環境を提供する。各リージョンマネージャは、そのデータをデータベース４０８に保存する。メタデータマネージャ４０４は、そのノードにおけるメタデータ管理を担う最上位コンポーネントである。それは、リージョンマネージャ（ＲＧＭ）の作成及び破棄と、ＲＧＭが必要とするリソースである例えばクラスタ構成情報及びデータベース接続プールの編成を担う。好ましくは、（所定のノードにおける）所定のメタデータマネージャが、リーダーとしての役目を果たして、（ノードのセットまたはサブセットのうちの）どのメタデータマネージャがどのリージョンコピーを担当するのかを決定することを担う。ブリーアルゴリズムまたはその変形などのリーダー選出アルゴリズムを用いて、メタデータマネージャリーダーを選出することができる。ノードごとに複数のＭＭを作動させることは可能であるが、好ましくは、各ノードは、単一のメタデータマネージャを有する。（後述するように）名前空間パーティション構成によって、リージョン所有権が確立されると、これにより、各メタデータマネージャは、その１以上のリージョンマネージャからなるセットの調整を担う。システムコンポーネント（例えば、管理エンジン、ポリシーマネージャなど）は、メタデータマネージャクライアントを通して、メタデータマネージャＭＭと対話する。ＭＭＣは、（リージョンマップを用いて）所与の要求を実行するためのＲＧＭを見つけること、選択されたＲＧＭに要求を発行すること、及び選択されたＲＧＭが（例えば、そのノードが故障したことにより）利用できない場合に要求を再試行すること、を担う。後者の場合は、そのノードで新たなリージョンマップを受け取ると、再試行要求は成功することになる。

上述のように、リージョンマップは、各リージョンの各コピーを担当するノードを特定している。仮想マシン４１２（及び、その中の各ＲＧＭ、ＭＭ、ＭＭＣコンポーネント）は、リージョンマップ４０５へのアクセスを有し、さらに図４には、ＪＶＭにコピーされた後のリージョンマップのコピー４２０を示している。リージョンマップは、このように、所与のノードにおいてＪＶＭとデータベースの両方で利用できる。この例示的な実施形態では、各メタデータオブジェクトは、ハッシュ化されることで０ｘ０〜０ｘ３ｆｆｆｆｆｆｆの間に含まれる整数すなわち３０ビットの値が生成される属性（例えば名前）を有する。これらの値は、（例えば、範囲の上限に１を加えたときに）オーバーフロー問題を引き起こす心配なく符号付き３２ビット整数で表すことができる。３０ビットによって、大規模なクラスタの場合であっても十分な約１０億個までのリージョンが可能である。各リージョンは、ハッシュ値のセットを表し、全てのリージョンからなるセットによって、すべての可能なハッシュ値を網羅する。各リージョン用として異なるビット位置があり、それらの異なるビット位置は、固定順序であることが好ましい。これにより、各リージョンは、好ましくはハッシュ値のＲｅｇｉｏｎＬｅｖｅｌＭａｐビットを抽出することにより導出される番号によって、識別される。６４個のリージョンを可能とするように、構成パラメータが６に設定されている場合、その結果得られるハッシュ値は、０ｘ０〜０ｘ３ｆの番号となる。

前述のように、リージョンコピーは、「正式」、「バックアップ」、「不完全」という３つの状態のいずれかにある。リージョンコピーが正式のものである場合は、そのリージョンへの全ての要求はこのコピーに送られ、また、リージョンごとに１つの正式コピーがある。リージョンコピーがバックアップである場合、このコピーは、（正式リージョンマネージャプロセスから）バックアップ要求を受け取る。リージョンコピーは、メタデータはロードされているが、そのコピーが（典型的には、他のバックアップコピーに関して）まだ同期されない場合には、不完全である。不完全なリージョンコピーは、同期が完了するまでは、他の状態に進む資格がなく、同期が完了した時点で、そのコピーはバックアップコピーとなる。各リージョンは、１つの正式コピーと、（メタデータＴＰＯＦ構成パラメータによって設定される）所定の数のバックアップコピーまたは不完全コピーと、を有する。

バックアップリージョンコピーは、正式リージョンコピーとそのＴＰＯＦバックアップコピーとの間で所定のプロトコル（または「コントラクト」）を実施することにより、正式リージョンコピーとの同期が維持される。このプロトコルについて以下で説明する。

簡単な背景として、更新要求をＭＭＣで受け取ると、ＭＭＣは、正式リージョンコピーの場所を見つけるためにローカルリージョンマップをルックアップする。ＭＭＣは、更新要求を、正式リージョンコピーに関連付けられたＲＧＭに送り、そしてこれが、それを完遂する。さらに、更新は、（正式リージョンコピーに関連付けられたＲＧＭによって）ＴＰＯＦバックアップコピーの各々のＲＧＭにも送られる。ただし、正式ＲＧＭは、成功を表明するために、バックアップリージョンコピーに関連付けられた各ＲＧＭが更新を完遂するのを待つ必要はなく、むしろ、バックアップリージョンコピーに関連付けられたＲＧＭは、更新を受け取ると、直ちに確認応答を（正式ＲＧＭに）返すか、または返すことを試みる。バックアップ要求が受け取られたときに、それが実行される前に、この確認応答が発行される。何の障害も発生しない場合には、正式ＲＧＭは、確認応答をすべて受け取るとＭＭＣに通知し、そしてこれが、呼び出し元に成功を返す。一方、特定の障害イベントが発生した場合、影響を受けたＲＧＭが（バックアップであるか、正式のものであるかに関わらず）、それ自身を（さらに、場合によっては、影響を受けるノードを）サービスから削除することがプロトコルによって確保され、ＭＭリーダーによって新たなリージョンマップが発行される。好ましくは、ＲＧＭは、ＪＶＭを停止させることにより、自身をサービスから削除するが、任意の適当な方法を用いることができる。新たなマップは、失われたリージョンコピーに代わるものを規定する。このように、各バックアップリージョンコピーは、正式リージョンコピーのための「ホットスタンバイ」であり、従って、（正式ＲＧＭの障害か、またはロードバランシングのためなど、いずれかの理由で）もし必要なときには正式なものに昇格する資格を有する。

更新プロセスが失敗し得るいくつかの状況がある。それは、例えば、正式リージョンマネージャが（確認応答を待っているときに）バックアップマネージャプロセスが停止したことを示す例外が発生する場合があり、またはバックアップマネージャプロセスが確認応答を発行したにもかかわらずローカルに更新要求の処理に失敗する場合があり、またはバックアップリージョンマネージャプロセスが確認応答を発行している間に正式リージョンマネージャプロセスが停止したことを示す例外が発生する場合などがある。上述のように、あるバックアップＲＧＭが、更新を処理できない場合には、自身をサービスから削除する。また、バックアップＲＧＭまたは正式ＲＧＭのいずれかが停止したときには、新たなリージョンマップが発行される。

メタデータ管理システムは、リージョンのコピーの同期を維持する。正式リージョンコピーにおいてオブジェクトに対して実施される更新は、バックアップリージョンコピーにおいて再現される。更新が正式ＲＧＭによって完遂されると、同じ更新が全てのバックアップリージョンコピーに適用される。それらで障害が（ノードレベルであるか、リージョンマネージャレベルなどであるかに関わらず）発生すれば、メタデータ管理システムによって、障害が発生したノードにおけるリージョンコピーの再割当てが行われることが確保され、これにより、残りのリージョンコピーの完全性が保証される。正式ＲＧＭを含むノードが故障する場合、バックアップＲＧＭは、（現在実行中の更新の有無に関わらず）同期しているか、または更新が中断されたことのみによって同期していないか、いずれかである。後者の場合、再同期させることは容易である。バックアップリージョンは、正式リージョンとの同期が維持されているので、（バックアップから正式なものに）昇格させることは即時的である。

また、ノード障害によって、バックアップリージョンを失う可能性もある。バックアップリージョンは、他のいずれかのノードに、新たに不完全なリージョンを作成することによって復元される。不完全なリージョンが作成されたら、直ちに更新の記録を開始するとともに、正式リージョンからのデータのコピーを開始する。コピーが完了したら、蓄積された更新を適用することで、最新状態のバックアップを得る。そして新たなバックアップリージョンは、自身が最新状態であることをＭＭリーダーに通知し、これにより、ＭＭリーダーは、そのリージョンの（不完全からバックアップへの）昇格を含むマップを送信する。

なお、リージョンの数はノードの数に対応している必要はないということに留意すべきである。より一般的には、リージョンの数は、独立ノードのアレイにおけるノード数に相関してない。メタデータ管理についての更なる詳細は、米国特許第７６５７５８１号に記載されている。

ＩＩＩ．自己記述オブジェクトの複数のユーザ定義メタデータ

多くのオブジェクトストレージシステムは、システムでインジェストされたオブジェクトにメタデータ（データに関するデータ）を関連付ける機能を有する。このメタデータを用いて、オブジェクトについてのさらなる記述情報を提供することにより、オブジェクトにアノテーションを付ける。追加のメタデータによって、解析及びディスカバリなどのアクティビティのために、コンシューマが同様の基準でオブジェクトを識別するのに役立てるための必要な情報を提供し、これによって自己記述オブジェクトを作成する。オブジェクトが、より自己記述的になるほど、これによって、追加のメタデータの提供が要求され得る多くの異なる目的及びコンシューマのために、オブジェクトを利用することが可能となる。

オブジェクトにメタデータを関連付けるための現状の方法は、ＸＭＬまたはＪＳＯＮなどの明確に定義されたフォーマットに情報を形成することと、それを１つのエンティティとしてそのオブジェクトに関連付けることからなる。多様なコンシューマがメタデータを利用及び拡張するためには、メタデータのフォーマットに関して、あらゆるプロデューサ及びコンシューマとの調整が必要となり、これによって、非互換性が生じたり、または他のメタデータが破壊されたりしないことが保証される。多様なコンシューマ／プロデューサ間の違いの調整は、コンシューマ／プロデューサの数が多くなるほど、それらのコンシューマ／プロデューサは別々の競合企業／製品からのものであり得るので、達成することが難しくなる可能性がある。

区別するための基準または能力を持たないのであれば、様々に異なるアプリケーションは、それでも、同じ名前を持つが他のソフトウェア・エンティティによって生成されたタグ／ヘッダが存在し得ることを認識していなければならない。

本発明の例示的な実施形態では、メタデータの複数の集合をオブジェクトに関連付ける機能を利用する。メタデータの各集合は、アノテーションと呼ばれる意図的な意味付けを提供することができる。これらのアノテーションに、名前が関連付けられて、オブジェクトごとに複数のアノテーションを可能とする。これらのアノテーションは、自己記述オブジェクトのユーザ定義メタデータまたはカスタムメタデータの名前付き集合である。

オブジェクトは、そのアノテーションと共に、オブジェクトストレージシステムにおいて自己記述オブジェクトを作成することを可能とする。それぞれの自己記述オブジェクトは、自身についての十分な情報を格納しており、これにより、そのオブジェクトに関する情報をリレーショナルデータベースなどの他のソースから収集する必要なく、オブジェクトの利用を可能とする。これによって、オブジェクトストレージシステムとやりとりすることのみにより、増え続けるオブジェクトで機能し得るシステムおよび方法を構築する機能が実現される。

所与のコンシューマ／プロデューサは、他のコンシューマ／プロデューサの存在の有無を懸念する必要なく、その独自の名前付きアノテーション（複数の場合もある）を作成し、そのアノテーションの内容を、その要求に適した形式（例えば、ＸＭＬ、ＪＳＯＮ、カンマ区切りなど）にフォーマットすることができる。また、メタデータ全体に対して規定される標準レイアウト／スキーマを備える必要もない。これによって、同じデータの多重使用が可能となる。例えば、デジタル画像は、その画像を他のソフトウェアが使用していることを知る必要なく、様々に異なるソフトウェアによる様々な情報によってアノテーションを付けることができる。様々なアノテーションは、顔認識、雲量、天候パターン、物体識別、他の画像との関係、および他の多くのトピックのような情報を含み得る。名前付きアノテーションによって、結果的に、全てのアノテーションを書き換える必要なく、個々のアノテーションを容易に修正することが可能となり、各アノテーションのセキュリティを実現する機能が提供され、また、検索基準として名前を用いて、ある特定の種類の情報を含む全てのオブジェクトが識別される。さらに、アクセスセキュリティは、オブジェクト全体ならびに個々のアノテーションのそれぞれに適用することができる。このレベルのセキュリティによって、要求するコンシューマの資格情報に基づいて、同じオブジェクトの異なるビューを構築するための異なるアクセス制御を提供することが可能となる。

一般に、オブジェクトストレージシステムには、オブジェクトにメタデータを添付するという概念がある。暗黙の組織を提供するために個々の要素を命名または構成する方法はそれぞれに異なり得る。本発明の実施形態により、メタデータの様々に異なるレイアウト／フォーマットを許容するメタデータまたはアノテーションの個別の集合を提供し、これらの集合へのアクセスは、アクセス制御リスト（ＡＣＬ）構造体によって制限される。

オブジェクトストレージシステムにおけるコンテンツの利用は、オブジェクトの作成、読取り、更新、および削除のためにネットワークプロトコルを利用することが中心である。多くのプロトコルを用いることができるが、本説明では、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を中心とし、それは、より具体的には、多くのウェブベースのクライアント／サーバ実装でよく見られるとともにクラウドベースのストレージで典型的なRepresentational State Transfer（ＲＥＳＴ：レスト）と呼ばれる分散システム用アーキテクチャ・スタイルである。各オブジェクトシステムは、プロセッサと、メモリと、ユーザ定義メタデータの複数の名前付き集合にそれぞれ関連付けられた少なくとも１つのオブジェクトと、を備える。

インターネット上で検索すると、ＨＴＴＰ／ＲＥＳＴとは何かについて、多くの高度かつ詳細な説明が現れるが、以下では、本発明に関連した具体的な実装について重点的に説明する。基本的に、要求は、ユニフォームリソースロケータ（ＵＲＬ）、オペレーションタイプ、及びオプションのペイロードで構成されている。オブジェクトストレージシステムの文脈では、ＵＲＬは、要求されたオペレーションを実行すべき対象のオブジェクトを特定する。オブジェクトに対して実行されるオペレーションには、ＧＥＴ、ＰＵＴ、ＨＥＡＤ（システムメタデータの取得）、ＰＯＳＴ（更新）、及びＤＥＬＥＴＥが含まれる。

図５は、オブジェクトのコア構成の一例を示している。オブジェクトシステム内のオブジェクトは、３つの主要部分、すなわち、固定コンテンツデータと、システムメタデータと、アノテーション（すなわち、ユーザ定義メタデータまたはカスタムメタデータ）と、を有し得る。固定コンテンツデータは、それが保存された以前に存在していたデータの正確なデジタル複製であり得る。それは、オブジェクトシステムに保存されると、そのデータは、一般に変更することはできないが、追加可能である場合がある。システムメタデータは、そのサイズ及び作成日などのデータを記述するシステム管理プロパティを含む。システムメタデータは、一般に、リテンションまたはＤＰＬ（データ保護レベル）などのポリシー設定を含み、これは、内部プロセスがオブジェクトとやりとりする方法に影響を及ぼす。本説明では、ユーザまたはアプリケーションがオブジェクトを追加的に記述するために提供するメタデータを含むアノテーションに着目する。上述のように、それは、ＸＭＬとして記述されることができ、一般的に、オブジェクトを自己記述的にするために用いられる。

図６は、メタデータ、および本明細書ではアノテーションと呼ばれるユーザ定義のメタデータの複数の名前付き集合のシステムを有するオブジェクトの一例を示している。図７は、複数のアノテーションおよびアクセス制御リスト（ＡＣＬ）を有するオブジェクトの一例を示している。従来、オブジェクトは、１つの無名カスタムメタデータセクションで構成されていた。本発明では、アノテーションと呼ばれるユーザ定義メタデータまたはカスタムメタデータの複数の名前付き集合または要素を提供する。オブジェクトに関連付けられた複数の名前付き集合からの各々の名前付き集合は、単一の要求で個別にアドレス可能であり、その単一の要求は、オブジェクトのアドレス可能ユニット、及びその特定の名前付き集合を指定する限定言語、を含むものである。各々の名前付き集合が個別にアドレス可能であると、１回の要求で一度に複数の名前付き集合へのアクセスを可能とする実装を備えることもできる。例示目的で、本説明におけるサンプルでは、自由に利用できるオープンソースのコマンドラインツールを使用し、これにより、ｃｕｒｌ（Command-line Universal Resource Locator）と呼ばれるＨＴＴＰ／ＲＥＳＴ要求を実行する。このツールは、フルウェブブラウザを使用することなくＨＴＴＰ要求を実行するための極めて単純な機構を提供する。図７のアノテーションの例は、土地利用解析、地下水位変動、人口密度分布、政府機関一覧、および標高偏差データを含んでいる。各アノテーションは、図示のような物体画像を分析する独立のプログラムによって生成することができる。オブジェクトのアノテーションの他の例は、そのオブジェクトを別のオブジェクトにリンクまたは関連付けするものである。

オブジェクトは、オブジェクトレベルのアクセス制御リスト（ＡＣＬ）を含むことができる。さらに、各アノテーションは、それ自体で所有するアノテーションレベルのＡＣＬを含むことができ、これにより、異なるアノテーションは、異なるＡＣＬを有することができ、それはオブジェクトレベルのＡＣＬとは異なるものであってもよい。アノテーションのアノテーションレベルＡＣＬは、そのアノテーションにアクセスすることができるリクエスタを指定する。

オブジェクトが既存であれば、ＨＴＴＰＲＥＳＴ要求を用いて、アノテーションを追加、更新、または削除することができる。これは、オブジェクトシステムなどのコントローラまたはプロセッサによって、既存のオブジェクトへのＵＲＬを指定して、ＰＵＴオペレーションを要求し、アノテーションのコンテンツを供給することにより、実行される。要求ＵＲＬは、オブジェクトを提示するだけではなく、その名前のアノテーションで、指定したオペレーションを実行することをオブジェクトストレージのウェブサーバに指示する。このとき、ｃｕｒｌコマンドと共に供給されるのが、そのオブジェクトに対するオペレーションに使用されるアノテーション・コンテンツである。アノテーションのフォーマット（ＸＭＬ、ＪＳＯＮ、バイナリなど）は、オブジェクトストレージシステムによって決められてはいない。しかしながら、例示目的で、アノテーション・コンテンツは、ＸＭＬ形式で表現する。そのオペレーションが許可されるかどうかは、そのオブジェクトストレージシステムに適用される構成またはポリシーに依存し得る。例えば、オブジェクトストレージが読取り専用モードである場合、ユーザの資格情報に基づくアクセス制限がある場合、ポリシーによって既存のコンテンツの更新が許可されない場合などがある。しかしながら、本発明の説明のため、オブジェクト及びそのアノテーションへの自由なアクセスを許可する構成及びポリシーを想定する。

［アノテーションのＨＴＴＰＲＥＳＴオペレーション］

前述のように、オブジェクト及びアノテーションに対して実行することができるいくつかのオペレーションがあり、それらは、ＧＥＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＰＯＳＴ、及びＨＥＡＤである。これらのオペレーションを使用する方法について、以下で説明する。

最初のオペレーションは、オブジェクトのアノテーションを作成／置換するものである。これは、既存のオブジェクトを対象とするＨＴＴＰＰＵＴオペレーションを発行して、新規のアノテーション・コンテンツを供給することにより、実行される。以下は、annotation.xmlファイルの内容を用いてfoobarという名前付きアノテーションを既存のオブジェクトobject.xxxに対して追加／置換するためのコマンドラインの一例である。
curl-T annotation.xml “http://ns1.ten1.hcp.example.com/rest/object.xxx?type=custom-metadata&annotation=foobar”

次のオペレーションは、アノテーションを取得するものである。これは、その既存のオブジェクトを対象とするＨＴＴＰＧＥＴオペレーションを発行することにより、実行される。そのアノテーション・コンテンツが、ＨＴＴＰＧＥＴ要求応答の本体の中に返される。以下は、オブジェクトobject.xxxに関連付けられたfoobarという名前付きアノテーションを取得して、それをユーザのコンソールに表示させるためのコマンドラインの一例である。
curl “https://ns1.ten1.hcp.example.com/rest/object.xxx?type=custom-metadata&annotation=foobar”

アノテーションを取得することなく、特定のアノテーションについての詳細（すなわち、プロパティ）を取得するために、ＵＲＬ指定で追加的指示を与える以下のＨＴＴＰＨＥＡＤ要求を、そのオブジェクトに対して実行することができる。以下は、オブジェクトobject.xxxのfoobarアノテーションについての詳細を表示させるためのｃｕｒｌコマンドの一例である。
curl-I “http://ns1.ten1.hcp.example.com/rest/object.xxx?type=custom-metadata&annotation=<foobar>”

以下は、このコマンドからの出力例である。
HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-HCP-ServicedBySystem: hcp.example.com
X-HCP-Time: 1348516584
X-HCP-SoftwareVersion: 5.1
X-RequestId: BE4012AB68AF46B
Content-Type: text/xml
Content-Length: 136
X-HCP-Type: annotation
X-HCP-Size: 136
X-HCP-ChangeTimeMilliseconds: 1348511536000.00
X-HCP-ChangeTimeString: 2012-09-24T14:32:16-0400
X-HCP-Hash: MD5 7701F57B64ADD508FB986868790CA4FE
X-HCP-Acls: Public:READ

ある所与のオブジェクトの全てのアノテーションの一覧を取得するためには、他の形式のＨＴＴＰ要求を実行する。利用可能な２つの機構がある。第１のものは、そのオブジェクトに対してＨＴＴＰＨＥＡＤ要求またはＧＥＴ要求を実行することであり、その応答は、単純な名前／サイズ一覧からなる。それらのアノテーションに関する完全な情報を求める場合は、ＵＲＬ要求と一覧表示方法の指定で選択的指示を与えるＨＴＴＰＧＥＴ要求を、そのオブジェクトに対して実行することができる。以下は、オブジェクトobject.xxxに関連付けられた全てのアノテーションの一覧を取得して、それをユーザのコンソールにＸＭＬ形式で表示させるためのコマンドラインの一例である。
curl “https://ns1.ten1.hcp.example.com/rest/object.xxx?type=custom-metadata-info” -H “Accept: application/xml”

以下は、アノテーション一覧の出力例であり、アノテーションについての名前及び関連オブジェクトストレージメタデータからなる。
<annotations>
<annotation>
<name>HDI</name>
<hash>MD5 3970858C9F1BE83ED9DC6E837BE1D292</hash>
<changeTimeMilliseconds>1348593706000.00</changeTimeMilliseconds>
<changeTimeString>2012-09-25T13:21:46-0400</changeTimeString>
<size>74</size>
<contentType>text/xml</contentType>
<acl>Public:READ</acl>
</annotation>
<annotation>
<name>myCustomMetadata</name>
<hash>MD5 BE83ED9DC6E837BE1D29272721A9F14F</hash>
<changeTimeMilliseconds>1348603222000.00</changeTimeMilliseconds>
<changeTimeString>2012-09-25T16:00:22-0400</changeTimeString>
<size>174</size>
<contentType>text/xml</contentType>
<acl>JohnD:READ,WRITE</acl>
</annotation>
</annotations>

最後に、オブジェクトに関連付けられたアノテーションを削除するためには、ＨＴＴＰＤＥＬＥＴＥ要求を実行する。以下は、オブジェクトobject.xxxからfoobarアノテーションを削除するためのコマンドラインの一例である。
curl -X DELETE “http://ns1.ten1.hcp.example.com/rest/object.xxx?type=custom-metadata&annotation=foobar”

オブジェクトストレージシステムとの間でコンテンツを送受信するための追加的／先進的機構があり、それらも、同じく上記で提示したコアＡＰＩ機構に適用するものである。追加的機構の一部を以下に列挙する。

１）システムに含まれるものとして、無名アノテーションがあり、これは、従来の製品の単一のカスタムメタデータ・コンテナに相当する。これは、後方互換性のために含まれており、前述の同じ機構を用いて、要求の「アノテーション」ＵＲＬ指定を省くことにより、アクセスすることができる。

２）ネットワーク接続を介して送信する場合に、アノテーションの圧縮を用いることができる。

３）１回のＨＴＴＰＰＵＴ（書込み）オペレーション及びＨＴＴＰＧＥＴオペレーションの使用方法は、１回のＨＴＴＰオペレーションを用いて、オブジェクトの固定コンテンツならびにアノテーションを共に読取り／書込み可能に提供される。これは、既存の製品において全Ｉ／Ｏ（ＷｈｏｌｅＩ／Ｏ）と呼ばれて、アノテーションを許容するように拡張されたものである。これらの要求は、全Ｉ／ＯＰＵＴ要求及び全Ｉ／ＯＧＥＴ要求と呼ぶことができる。

４）既存のクエリインタフェースへの拡張を利用して、アノテーション情報を含む検索／インデキシング・レポーティングを提供する。

５）上述の機能は、上記のＨＴＴＰ／ＲＥＳＴＡＰＩに限定されるものではなく、その製品用のウェブベースＧＵＩインタフェースでも用いられる。

図８は、オブジェクトの複数のアノテーションの使用を実現するための装置の一例を示している。装置８００は、オブジェクト（破線で示す８１２）が保存されるオブジェクトシステム（破線で示す８１０）の一部、またはオブジェクト８２２を保存するためのシステム８２０から分離した管理コンピュータの一部、または上述のような独立ノード冗長アレイ（図１〜４を参照）のシステムの一部、などであり得る。装置８００は、プロセッサまたはコントローラ８０２と、メモリ８０４とを備え、アノテーションに対して、アノテーションのアクセス制御リスト（ＡＣＬ）の作成または更新を含むオペレーション（例えば、ＰＵＴ、ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ、ＤＥＬＥＴＥ、全Ｉ／ＯＰＵＴ、全Ｉ／ＯＧＥＴ）を実行するように機能する。

ＩＶ．コンテンツクラス

図９は、コンテンツクラス定義の一例を示している。本発明の実施形態では、オブジェクトの非構造化コンテンツ及びそのメタデータ用の構造体を構築する青写真を定義するための機構として「コンテンツクラス」を利用する。これらのクラスは、ユーザ定義による「コンテンツプロパティ」のセットで構成される。各コンテンツプロパティによって、ある特定のメタデータフィールド（例えば、いずれかのカスタムメタデータのＸＭＬタグ）をオブジェクトから抽出し、それをユーザ定義の名前で強い型付けによって効率的にインデキシングして、そのフィールドをユーザインタフェース及びプログラマチック・クエリインタフェースを介して多次元的にクエリ可能にする、ための能力が与えられる。コンテンツクラスによって、コンテンツプロパティのセットは、名前付きカテゴリにグループ化ならびに編成される。各コンテンツクラスが名前付きであることで、それらのコンテンツクラスをユーザインタフェース及びプログラマチックインタフェースによって参照することができ、これにより、非構造化コンテンツについてクエリを構築することが、より簡単となる。

図９の例は、名前、複数値、表現、データ型、フォーマットのためのコンテンツプロパティ・フィールドを有する。名前フィールドは、そのコンテンツプロパティの、ユーザ指定による固有の名前のためのものであり、好ましくは、クエリに用いることが可能な、人間にとって意味を持つ名前である。複数値フィールドは、指定された表現がアノテーションにおいて複数のインスタンスを有し得るかどうかを指定するために（すなわち、その同じカスタムメタデータ・コンテンツ内でそのプロパティが複数の値に評価される可能性があるかどうかを示すために）使用される。表現フィールドは、そのコンテンツプロパティの値をカスタムメタデータ・コンテンツからどのように抽出すべきかを特定している。カスタムメタデータがＸＭＬ形式である場合には、この表現は、ＸＰａｔｈ構文によるものとなる。この表現は、アノテーションの値／プロパティを指定する修正ＸＰａｔｈ形式である。データ型フィールドは、インデキシングのために、表現で指定される項目の明確に定義された許容データ型、すなわち、そのカスタムプロパティの期待されるデータ型（例えば、文字列、トークン化テキスト、ブール、整数、浮動小数点、日付）のためのものである。フォーマットフィールドは、数値及び日付データ型の場合の特殊なフォーマットのためのものである。このオプションによって、ユーザは、日付型、整数型、浮動小数点型のプロパティについて、期待されるフォーマットを選択することができる。これらのフィールドは、コンテンツクラス定義の一部として定義される場合のコンテンツプロパティの属性である。

図１０は、インデキシングシステムにおいてコンテンツクラスを利用するシステムの一例を示している。特定のアプリケーションは、一般に、同じスキーマでメタデータを生成するので、コンテンツクラスは、パッケージを定義して、それらの定義をオブジェクトストレージエコシステム全体にわたって管理するのに役立ち、これによって、各テナント（すなわち、仮想オブジェクト・ストア）、及びアプリケーションが使用するその名前空間（すなわち、オブジェクト・コンテナ）において、コンテンツプロパティの重複セットを定義する必要がなくなる。各テナントは、これらのコンテンツクラスを利用して、その名前空間の各々に対して所望のインデキシング挙動を得ることができる。また、検索インデキシングシステムは、コンテンツクラスで指定されたコンテンツプロパティと、システムメタデータのみインデキシングして、インデキシングされたコンテンツを、コンテンツプロパティ名によって識別することができる。

アプリケーション開発者は、特定のアプリケーションをホストしているどのテナントにも利用できるコンテンツクラス定義を作成することができ、この定義は、アプリケーションの変更がない限り、変更される可能性は低い。好ましくは、コンテンツクラスのコンシューマは、インデキシング性能及び資源消費を最大限とするために、コンテンツクラスの使用をオプトインまたはオプトアウトすることができる。

オブジェクトストレージシステムにおけるクエリエンジンのインデックスは、システム全体にグローバルであり、資源を消費する。これらのインデキシング資源のコストを最小限に抑えることにおいて管理者を支援するために、コンテンツクラスによって、（個々の名前空間のそれぞれで各設定を閲覧表示するのではなく）１つの場所からのテナント内の全ての名前空間にわたって、コンテンツプロパティ設定を閲覧表示するための手段が提供される。これにより、様々なスキーマにわたって、インデックスフィールドの簡単なデデュープ（重複排除）が可能となる。例えば、２つの異なるコンテンツクラスが、どちらも「医師名」フィールドを定義している場合は、両方のプロパティで同じインデックスフィールド名を共有することで、それらの値をインデックスにおいて効果的にデデュープ（重複排除）することが有用であり得る。

以下で、多数の医用画像を保存するオブジェクトストレージシステムの例を用いて、本発明の機能について説明する。これらの画像のそれぞれは、その画像を診断した医師及びその画像が関連付けられている患者の基本的な連絡先情報を提供する（例えば、ＸＭＬベースの）カスタムメタデータを有する。次のカスタムメタデータの断片について考える。
<record>
<doctor>
<id>12345</id>
<name>John Smith</name>
<address>1234 Main Street Boston, MA 02215</address>
</doctor>
<patient>
<id>56789</id>
<name>John Smith</name>
<address>567 Lincoln St Waltham, MA 03786</address>
<dateOfBirth>1/2/1970</dateOfBirth>
<patient>
</record>

一般的なインデキシング／検索アプローチによって、ユーザは、カスタムメタデータ内の個々のキーワード及びフレーズについて、クエリを実行することが可能である。インデキシングの際に、カスタムメタデータの構造は考慮されない。本例では、ユーザが医師名でクエリを正確に実行することは不可能である。「John Smith」についてのクエリでは、医師John Smithによって診断された全ての画像、ならびに患者John Smithに関連付けられている全ての画像が、他の医師によって診断された画像を含めて、返されることになる。また、値範囲を用いてオブジェクトを見つけること（例えば、生年月日に基づいて特定の年齢の全ての患者を見つけること）は不可能である。さらに、一般的なインデキシング／検索システムは、カスタムメタデータ・コンテンツのインデキシングに対してオール・オア・ナッシング・アプローチを取っており、そのインデックスのサイズに対する制御をユーザにほとんど与えない。有効にすると、検索においてユーザが関心のない可能性がある情報を含めて、全てのカスタムメタデータ・コンテンツがインデキシングされる。これは、インデックスサイズの肥大化につながる場合があり、システム全体にわたるディスク及びＲＡＭの利用にマイナスの影響を与える。

コンテンツクラスによって、カスタムメタデータ・コンテンツをインデキシング及び検索する際に使用するコンテンツプロパティをユーザに指定させることにより、これら全ての問題は解決される。コンテンツプロパティは、オブジェクトにおいてカスタムメタデータに含まれ得る具体的な属性と共に、このメタデータの構造に関する情報を（ＸＰａｔｈ構文を用いた）表現の形式で記述する。先の例では、カスタムメタデータの構造に精通する管理者は、以下のコンテンツプロパティを定義することができる。
表現名前型
−−−−−−−−−−−−−−− −−−−− −−−−−
［/record/doctor/name ］［医師］［String］
［/record/patient/name ］［患者］［String］
［/record/patient/dateOfBirth］［ＤＯＢ］［Date］

これらのコンテンツプロパティは、その後、インデキシングならびに検索のために、カスタムメタデータ・コンテンツから指定の値を抽出するために用いられる。例えば、コンテンツプロパティの名前が「医師」であるコンテンツプロパティによって、オブジェクトから、/record/doctor/nameの下の指定のメタデータフィールドを抽出する能力が与えられる。これによって、それらの定義されたオブジェクトのプロパティに対するクエリが可能となる。例えば、医師：「John Smith」では、医師John Smithによって診断された画像のみが返される。John Smithという名前の患者に関連した画像は、このクエリによって返されることはない。これによって、ユーザは、それらのカスタムメタデータに対して焦点を絞った構造化クエリを実行することが可能となる。他の例では、ＤＯＢ：［1/1/1940 TO 1/1/1980］によって、１９４０年から１９８０年の間に生まれた患者についての画像のみが返される。

また、これは、ユーザが検索のために有用と考える値のみがインデキシングされることも意味する。ユーザが、インデキシングにおいて、オブジェクトのそれらのカスタムメタデータからのもの以外の値にはいずれも関心がない場合には、インデックスサイズは、カスタムメタデータ全体がどのような大きさであるかに関係なく、オブジェクトごとに、これらの３つのフィールドのみに制限され、これによって、ディスク及びＲＡＭスペースの大幅な節約が得られるとともに、性能が向上する。

さらに、同じ値の表現がカスタムメタデータのフォーマットにおいて異なる場合に、インデックスは、その名前空間内で、またはさらに名前空間の間にわたって、効率的に「重複排除」することができる。例えば、同じカスタムメタデータが異なる名前空間で異なるフォーマットにされた状況について考える。ある名前空間では、それらのカスタムメタデータを、次のようなフォーマットとすることができる。
<doctor>
<name>John Smith</name>
</doctor>

別の名前空間では、それらのカスタムメタデータを次のようなフォーマットとすることができる。
<physician>
<fullname>John Smith</fullname>
</physician>

管理者は、両方の値を同じインデックスフィールドに入れることができる。
表現名前型
−−−−−−−−−−− −−−− −−−−−
［/doctor/name ］［医師］［String］
［/physician/fullname］［医師］［String］

これによって、統一的検索が可能となる。医師：「John Smith」についてのクエリによって、両方のカスタムメタデータ・フォーマットのオブジェクトが見つかり、そして同じく、ディスク及びＲＡＭの大幅な節約が可能となり、こうして性能が向上する。

［インデキシング及び検索］

オブジェクトストレージシステムでは、カスタムメタデータ・コンテンツをインデキシングする際に、インデキシングされるオブジェクトに適用できるコンテンツクラスをルックアップして、それらのコンテンツクラスで定義されているコンテンツプロパティを発見し、それらのコンテンツプロパティをコンテンツに適用する。このとき、全てのコンテンツプロパティの表現を、インデキシングされるコンテンツに対して評価し、そして、表現が一致した値のみ、それらの適切なフォーマット及びデータ型を用いてインデキシングする。

オブジェクトストレージシステムにおいてオブジェクトを検索する場合、ユーザは、定義されたコンテンツプロパティのいずれかを用いて、プロパティのユーザフレンドリな名前（例えば、上記の例では医師）を使用してコンテンツを検索することができる。システムは、そのプロパティ名を内部のインデックスフィールドと照合することで、該当する結果（例えば、医師：「John Smith」）を見つける。ユーザによる検索を支援するために、システムは、好ましくは、（例えば、ドロップダウンリスト／メニューを用いた）直感的なグラフィカルユーザインタフェースで選択するための適切なコンテンツクラス及びコンテンツプロパティの一覧を、ユーザに提示する。

図８に示すものと同様の装置を用いて、コンテンツクラスにグループ分けされたコンテンツプロパティを利用するインデキシング／検索機能を実現することができる。例えば、上記の検索インデキシングシステムは、メモリ８０４に格納されたモジュールとして実装することができ、それは、プロセッサまたはコントローラ８０２により実行されることで、上記のインデキシング及び検索を実施するものである。

アノテーション（すなわち、オブジェクトに関連付けられたユーザ定義メタデータの集合）がある場合は、コンテンツクラスによって、インデキシング／検索機能のために、関心のあるアノテーション要素を指定することが可能となる。コンテンツクラスには、同様に、特定の名前付きアノテーションの指定が含まれる。これにより、アプリケーション／顧客が提供したアノテーションに基づいてコンテンツをインデキシングするための極めて強力なツールが得られる。

この高度な検索／インデキシング機能によって、関心事象を同定する潜在的な可能性があるパターンを見つけるために、複数のアプリケーションによって生成された全てのコンテンツ及びそのアノテーションをウォークスルーすることが可能な解析エンジンを構築することが可能である。その場合、一見無関係に見えるデータの集合間に関係を構築するために役立つ追加のアノテーションを追加することが可能である。例えば、そのオブジェクトストレージシステムは、多くの地理空間画像が取り込まれたものである。これらの画像を、有用とするためには、様々に異なるソフトウェアによって抽出することができる情報が必要である。そのような有用な情報は、雲量であり得る。あるソフトウェアは、画像を雲量率について解析することが可能であり得る一方で、他のソフトウェアは、それらの結果を分析して、雲のない画像セットを得るために画像を補正することが可能であるか、または再取り込みの必要があるか判断することができる。これは、雲量が閾値未満である画像が、地勢またはヒューマン・ベースの活動／物体における変化についてさらに分析される候補であり得る場合に、利用することもできる。アノテーションは、テロ活動などの項目を識別するために追加することができる。

２つの目的を兼ねたこの同じデータを、医療分野で用いることができる。個人の健康についての検査及び結果に基づいて、多くのデータが収集される。様々に異なる種類の情報で拡張されたこのデータは、様々な診断、地理的位置、および解消法を結び付けることで、様々に異なるソフトウェア／手順によって収集されたものであり得る全ての異なる属性に基づいて調査を策定する助けとすることができる。そのような調査によって、今度は、追加のアノテーションをオブジェクトに追加することができ、これにより、例えば、ある特定の処置が一般に最も好ましい結果を出しているかどうかなど、さらなる利用が促される。

別の例は、他のアプリケーションによって提供されるアノテーションデータをウォークスルーして、コンテンツのライフサイクル事象を決定するプロセスを有するものである。例えば、それは、もはや保持し続ける必要が法的にないのはどの情報であるか、また、そのデータセットの使用目的での役目を果たさないのはどの情報であるかを判断するために用いることができる。これによって、特殊用途に焦点を合わせて、または顧客に再販売するために、より絞り込んだデータセットが生成される。

言うまでもなく、図１、４、８に示すシステム構成は、本発明を実施することができるコンテンツプラットフォームまたは複製オブジェクトストレージシステムを含むシステムの単なる例示であり、本発明は特定のハードウェア構成に限定されない。本発明を実施するコンピュータ及びストレージシステムは、さらに、周知のＩ／Ｏデバイス（例えば、ＣＤ及びＤＶＤドライブ、フロッピーディスクドライブ、ハードドライブなど）を備えることもでき、これらにより、上記発明の実施に使用されるモジュール、プログラム、及びデータ構造を保存し、読み出すことができる。これらのモジュール、プログラム、及びデータ構造は、かかるコンピュータ可読媒体上にコード化することができる。例えば、本発明のデータ構造は、発明で使用するプログラムが常駐する１以上のコンピュータ可読媒体とは独立のコンピュータ可読媒体に保存することができる。システムのコンポーネントは、例えば通信ネットワークであるデジタルデータ通信の任意の形式または媒体によって、相互接続することができる。通信ネットワークの例として、ローカルエリアネットワーク、例えばインターネットである広域ネットワーク、無線ネットワーク、ストレージエリアネットワークなどが含まれる。

本明細書では、発明についての完全な理解を与えるため、説明の目的で様々な詳細について記載している。しかしながら、本発明を実施するために、これら特定の詳細のすべてが必要とされるわけではないことは、当業者には明らかであろう。また、本発明は、プロセスとして記述できるということにも留意すべきであり、それは、通常、フローチャート、フロー図、構造図、またはブロック図として表現される。フローチャートでは、オペレーションが逐次プロセスとして記述され得るが、それらのオペレーションの多くは、並列または同時に実行することができる。さらに、オペレーションの順序は並べ替えることができる。

当該技術分野で知られているように、上記オペレーションは、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの何らかの組み合わせによって実行することができる。本発明の実施形態のいくつかの態様は、回路および論理デバイス（ハードウェア）を用いて実装することができる一方、他の態様は、機械可読媒体に格納された命令（ソフトウェア）を用いて実装することができ、それらの命令は、プロセッサで実行されることで、本発明の実施形態を実施する方法をプロセッサに実行させるものである。また、本発明のいくつかの実施形態は、ハードウェアのみで実行することができる一方、他の実施形態は、ソフトウェアのみで実行することができる。さらに、記載された種々の機能は、単一のユニットで実行することができ、または、あらゆる方法で多くのコンポーネントに分散させることができる。ソフトウェアで実行する場合、本方法は、コンピュータ可読媒体に格納された命令に基づいて、汎用コンピュータなどのプロセッサで実行することができる。それらの命令は、所望であれば圧縮および／または暗号化形式で媒体に保存することができる。

上記のことから、本発明は、オブジェクトの非構造化コンテンツ及びそのメタデータ用の構造体を構築する青写真を定義するため、ならびに効率的なインデキシング及び検索を容易にするための、コンテンツクラスと呼ばれる機構を提供する方法、装置、ならびにコンピュータ可読媒体に格納されたプログラムを提供するものであることは明らかであろう。また、本明細書では具体的な実施形態を例示および記載しているが、当業者であれば理解できるように、同じ目的を達成すると予測される任意の構成を、開示された特定の実施形態の代用とすることができる。本開示は、本発明のあらゆる改良または変形を包括するものであり、また、当然のことながら、以下の請求項において使用される用語は、本明細書に開示の特定の実施形態に発明を限定するものと解釈されるべきではない。むしろ、本発明の範囲は、かかる請求項によって権利が認められる均等物の全範囲と共に、確立されたクレーム解釈論に従って解釈されるべき以下の請求項によって、完全に決定されるべきである。

Claims

ストレージシステムであって、
コントローラと、
メモリと、
１以上のオブジェクトであって、各オブジェクトは、コンテンツデータとメタデータとを有する、オブジェクトと、を備え、
前記メタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築し、各コンテンツプロパティは、該コンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドを前記１以上のオブジェクトから抽出する能力を与えるものであり、
前記コンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化しており、
前記コントローラは、前記コンテンツクラスのコンテンツプロパティをインデキシングして、インデックスを作成するように機能し、
インデキシングされる前記コンテンツプロパティは、前記コンテンツプロパティ名で識別される、ストレージシステム。
前記コントローラは、異なるメタデータ・フォーマットでの異なる表現による同じ値を持つコンテンツプロパティについて、前記異なる表現による値を、同じコンテンツプロパティ名で同じインデックスフィールドに入れることによって、前記インデックスを重複排除するように機能する、請求項１に記載ストレージシステム。
各コンテンツプロパティは、前記コンテンツプロパティ名を指定する名前フィールドに加えて、
前記メタデータのコンテンツから該コンテンツプロパティの値をどのように抽出すべきかを特定する表現フィールド、
該コンテンツプロパティの値のデータ型を指定するデータ型フィールド、
数値及び日付データ型のフォーマットを指定するフォーマットフィールド、または、
該コンテンツプロパティで指定される表現は同じメタデータ・コンテンツ内で複数の値に評価される可能性があるかどうかを指定する複数値フィールド、のうち少なくとも１つを含む、請求項１に記載のストレージシステム。
前記コントローラは、コンテンツプロパティの前記インデックスを用いて、前記１以上のオブジェクトのコンテンツを検索するように機能する。請求項１に記載のストレージシステム。
前記コンテンツデータ及び前記メタデータを用いて、前記ユーザ定義の複数のコンテンツプロパティを構築する、請求項１に記載のストレージシステム。
複数のノードを有するストレージシステムにおいてオブジェクトのコンテンツをインデキシングするための装置であって、前記ノードは、複数のノードをそれぞれ有する複数のクラスタシステムにグループ分けされ、各オブジェクトは、コンテンツデータとメタデータとを有し、前記メタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築し、各コンテンツプロパティは、該コンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドを前記オブジェクトから抽出する能力を与えるものであり、前記コンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化しており、当該装置は、コントローラとメモリとを備え、前記コントローラは、
前記コンテンツクラスのコンテンツプロパティをインデキシングして、インデックスを作成するように機能し、
インデキシングされる前記コンテンツプロパティは、前記コンテンツプロパティ名で識別される、装置。
前記コントローラは、異なるメタデータ・フォーマットでの異なる表現による同じ値を持つコンテンツプロパティについて、前記異なる表現による値を、同じコンテンツプロパティ名で同じインデックスフィールドに入れることによって、前記インデックスを重複排除するように機能する、請求項６に記載の装置。
各コンテンツプロパティは、前記コンテンツプロパティ名を指定する名前フィールドに加えて、
前記メタデータのコンテンツから該コンテンツプロパティの値をどのように抽出すべきかを特定する表現フィールド、
該コンテンツプロパティの値のデータ型を指定するデータ型フィールド、
数値及び日付データ型のフォーマットを指定するフォーマットフィールド、または、
該コンテンツプロパティで指定される表現は同じメタデータ・コンテンツ内で複数の値に評価される可能性があるかどうかを指定する複数値フィールド、のうち少なくとも１つを含む、請求項６に記載の装置。
前記コントローラは、コンテンツプロパティの前記インデックスを用いて、前記オブジェクトのコンテンツを検索するように機能する、請求項６に記載の装置。
各クラスタシステムは、複数の名前空間に論理的に分割され、それぞれの名前空間は、オブジェクトの集まりを含むとともに、それに関連付けられたプライベートファイルシステムであって、該クラスタシステムの他の名前空間に対してプライベートなファイルシステムを有し、
テナントは、名前空間をグループ化したものであり、
個々の名前空間のそれぞれで各コンテンツプロパティの設定を閲覧表示するのではなく、１つの場所からのテナント内の名前空間にわたって、前記コンテンツクラスでグループ分けされたコンテンツプロパティのコンテンツプロパティ設定を閲覧表示する方法が、前記コンテンツクラスによって提供される、請求項６に記載の装置。
複数のノードを有するストレージシステムにおいて、オブジェクトのコンテンツをインデキシングする方法であって、前記ノードは、複数のノードをそれぞれ有する複数のクラスタシステムにグループ分けされており、各オブジェクトは、コンテンツデータとメタデータとを有し、前記メタデータを用いて、ユーザ定義の複数のコンテンツプロパティを構築し、各コンテンツプロパティは、該コンテンツプロパティのユーザ定義のコンテンツプロパティ名を参照することにより、ある特定のメタデータフィールドを前記オブジェクトから抽出する能力を与えるものであり、前記コンテンツプロパティを、ユーザ定義のコンテンツクラスに編成し、各コンテンツクラスは、コンテンツプロパティのセットを、ユーザ定義のコンテンツクラス名で名前付きカテゴリにグループ化しており、当該方法は、
インデックスを作成するために前記コンテンツクラスのコンテンツプロパティをインデキシングすることを含み、
インデキシングされる前記コンテンツプロパティは、前記コンテンツプロパティ名で識別される、方法。
異なるメタデータ・フォーマットでの異なる表現による同じ値を持つコンテンツプロパティについて、前記異なる表現による値を、同じコンテンツプロパティ名で同じインデックスフィールドに入れることによって、前記インデックスを重複排除することをさらに含む、請求項１１に記載の方法。
各コンテンツプロパティは、前記コンテンツプロパティ名を指定する名前フィールドに加えて、
前記メタデータのコンテンツから該コンテンツプロパティの値をどのように抽出すべきかを特定する表現フィールド、
該コンテンツプロパティの値のデータ型を指定するデータ型フィールド、
数値及び日付データ型のフォーマットを指定するフォーマットフィールド、または、
該コンテンツプロパティで指定される表現は同じメタデータ・コンテンツ内で複数の値に評価される可能性があるかどうかを指定する複数値フィールド、のうち少なくとも１つを含む、請求項１１に記載の方法。
コンテンツプロパティの前記インデックスを用いて、前記オブジェクトのコンテンツを検索することをさらに含む、請求項１１に記載の方法。
各クラスタシステムは、複数の名前空間に論理的に分割され、それぞれの名前空間は、オブジェクトの集まりを含むとともに、それに関連付けられたプライベートファイルシステムであって、該クラスタシステムの他の名前空間に対してプライベートなファイルシステムを有し、
テナントは、名前空間をグループ化したものであり、
当該方法は、個々の名前空間のそれぞれで各コンテンツプロパティの設定を閲覧表示するのではなく、１つの場所からのテナント内の名前空間にわたって、前記コンテンツクラスでグループ分けされたコンテンツプロパティのコンテンツプロパティ設定を閲覧表示するために、前記コンテンツクラスを用いることをさらに含む、請求項１１に記載の方法。