(57)【特許請求の範囲】
【請求項１】
クラスタインスタンスを操作する方法であって、前記クラスタインスタンスが独立ノード冗長アレイを備え、各ノードが、プロセッサと、前記プロセッサに結合されたデータストアと、ローカルファイルシステムと、前記データストアに記憶され前記プロセッサによって実行されるアプリケーションインスタンスとを備える方法において、
クラスタに、管理アカウントが割り当てられた複数のテナントを作成し、
前記クラスタを論理的に区分し、複数のデータオブジェクトを含む、１つまたは複数の名前空間のセットを、前記複数のテナントに含まれるテナントに関連付け、
前記名前空間のセットに含まれる名前空間が他の名前空間に対するプライベートファイルシステムを有し、
前記名前空間のセットに含まれる名前空間を、少なくとも１つの他の名前空間の構成に影響を及ぼさずに、前記関連付けられたテナントの管理アカウントにより選択的に構成する、ことを含む方法。
【請求項２】
前記名前空間が前記クラスタインスタンスの論理的区分であり、前記複数のデータオブジェクトが特定のアプリケーションに関連する、請求項１に記載の方法。
【請求項３】
前記名前空間に１つまたは複数の能力が関連する、請求項１に記載の方法。
【請求項４】
前記能力が、読取り、書込み、削除、パージ、特権的削除、および検索のうちの少なくとも１つを含む、請求項３に記載の方法。
【請求項５】
前記名前空間を選択的に構成する前記ステップが、前記能力をイネーブルまたはディセーブルにすることを含む、請求項３に記載の方法。
【請求項６】
前記能力が、前記関連付けられたテナントのデータアカウントによりイネーブルまたはディセーブルにされる、請求項５に記載の方法。
【請求項７】
前記複数のテナントに含まれるテナントを１つまたは複数のサブ・テナントに論理的に区分化するステップをさらに含む、請求項１に記載の方法。
【請求項８】
前記名前空間に関連する管理操作を、前記関連付けられたテナントの１つまたは複数の事前定義済み役割に制限することをさらに含む、請求項１に記載の方法。
【請求項９】
前記関連付けられたテナントの許可のセットであって、前記名前空間についての許可をマスクする許可のセットを定義することをさらに含む、請求項１に記載の方法。
【請求項１０】
前記名前空間に関連する１つまたは複数のデータアクセスアカウントを定義することをさらに含み、前記名前空間中のデータオブジェクトへのアクセスがデータアクセスアカウントに制限される、請求項１に記載の方法。
【請求項１１】
前記関連付けられたテナントがトップレベルテナントである、請求項１に記載の方法。
【請求項１２】
前記クラスタにストレージクォータを割り当てることをさらに含む、請求項１に記載の方法。
【請求項１３】
前記ストレージクォータを１つまたは複数の名前空間にわたって区分化することをさらに含む、請求項１２に記載の方法。
【請求項１４】
クラスタインスタンスを操作する方法であって、前記クラスタインスタンスが独立ノード冗長アレイを備え、各ノードが、プロセッサと、前記プロセッサに結合されたデータストアと、ローカルファイルシステムと、前記データストアに記憶され前記プロセッサによって実行されるアプリケーションインスタンスとを備える方法において、
クラスタに、管理アカウントが割り当てられた複数のテナントを作成し、
前記クラスタを論理的に区分し、複数のデータオブジェクトを含む、１つまたは複数の名前空間のセットを、前記複数のテナントに含まれるテナントに関連付け、
各名前空間が前記名前空間のセット中の他のどんな名前空間に対しても独立して管理され、
或る名前空間に関連する１つまたは複数の許可のセットを定義する許可マスクを構成することであって、構成されると前記許可のセットが前記或る名前空間のみに適用され、
前記名前空間のセットに含まれる名前空間を、少なくとも１つの他の名前空間の構成に影響を及ぼさずに、前記関連付けられたテナントの管理アカウントにより選択的に構成する、ことを含む方法。
【請求項１５】
前記許可のセットが、能力のセットから選択された能力を含む、請求項１４に記載の方法。
【請求項１６】
前記能力のセットからの前記能力をイネーブルにすることにより、或る操作が、前記或る名前空間のみに対してイネーブルにされ、前記名前空間のセット中の他のどんな名前空間に対してもイネーブルにされない、請求項１５に記載の方法。
【請求項１７】
前記或る名前空間が認証名前空間であり、前記認証名前空間へのアクセスを、資格授与されたユーザに制限するステップをさらに含む、請求項１４乃至１６のいずれか１項に記載の方法。
【請求項１８】
前記或る名前空間が、その中でデータオブジェクト同士が関連するデフォルト名前空間である、請求項１４乃至１７のいずれか１項に記載の方法。
【請求項１９】
ネットワークで接続される複数のノードにより形成されるクラスタを含む装置であって、各ノードが、
プロセッサと、
コンピュータプログラム命令を保持するコンピュータメモリとを備え、
前記コンピュータプログラム命令が、前記プロセッサによって実行されたとき、
前記クラスタに、管理アカウントが割り当てられた複数のテナントを作成し、
前記クラスタを論理的に区分し、複数のデータオブジェクトを含む、１つまたは複数の名前空間のセットを、前記複数のテナントに含まれるテナントに関連付け、
前記名前空間のセットに含まれる名前空間を、少なくとも１つの他の名前空間の構成に影響を及ぼさずに、前記関連付けられたテナントの管理アカウントにより選択的に構成する、装置。
【請求項２０】
前記クラスタを論理的に区分化するのに用いられる１つまたは複数の表示インタフェースをエクスポートするウェブ・ベースのインタフェースをさらに備える、請求項１９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００９年１０月３０日に出願された米国特許出願第１２／６０９，８６９号に基づくものであり、この出願に対する優先権を主張する。
【０００２】
本発明は一般に、分散コンピュータネットワークにおける、可用性、信頼性、および持続性の高いデータストレージのための技法に関する。
【背景技術】
【０００３】
従来のテープおよび光学ストレージ解決法に取って代わるかまたはそれを補う、可用性、信頼性、および持続性の高い方式による「固定コンテンツ」のアーカイブストレージ（ａｒｃｈｉｖａｌ  ｓｔｏｒａｇｅ）に対する必要性が高まってきた。用語「固定コンテンツ」とは、通常、参照または他の目的のためにそのままで保存されることが予想される任意のタイプのディジタル情報を指す。このような固定コンテンツの例としては、多くの例の中でもとりわけ、電子メール、文書、診断画像、チェック画像、音声録音、フィルムおよびビデオなどが挙げられる。従来の独立ノード冗長アレイ（ＲＡＩＮ、Ｒｅｄｕｎｄａｎｔ
Ａｒｒａｙ  ｏｆ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｎｏｄｅｓ）ストレージ手法は、このような固定コンテンツの情報資産を記憶するための大規模なオンラインアーカイブを生み出すために選択されるアーキテクチャとして登場した。ＲＡＩＮアーキテクチャは、ノードが必要に応じてクラスタに結合することおよびクラスタから退出することを可能にすることにより、ストレージクラスタを１つまたは複数のノードの障害から隔離する。ＲＡＩＮタイプのアーカイブは、データを複数のノード上で複製することにより、ノードの障害または除去を自動的に補償することができる。通常、ＲＡＩＮシステムは、閉システム内の同一コンポーネントから設計されたハードウェア機器として広く供給される。
【発明の概要】
【０００４】
独立ノード冗長アレイを備えるコンテンツプラットフォーム（または「クラスタ」）が、論理的に区分化される。管理者が、ウェブ・ベースのインタフェースを使用してコンテンツプラットフォーム内の１つまたは複数の「テナント」を定義するが、テナントは、１組の属性、すなわち、名前空間、管理アカウント、データアクセスアカウント、および許可マスクを有する。名前空間は、少なくとも１つの定義されたアプリケーションに通常関連するオブジェクトの集まりとしての働きをする、コンテンツプラットフォームの論理的区分である。各名前空間は、他の名前空間に対するプライベートファイルシステムを有する。名前空間は通常、名前空間管理者が所与のデータアカウントについてイネーブルまたはディセーブルにするように選択できる１つまたは複数の能力（例えば読取り、書込み、削除、パージなど）を有する。名前空間許可マスクは、テナントに対して大域的であり名前空間の許可をマスクする許可のセットである。しかし、ある名前空間へのアクセスは、別の名前空間へのアクセスをユーザに与えない。このインタフェースを使用して、テナントの管理者は名前空間を作成および管理し、したがって、その場合クラスタは名前空間のセットに論理的に区分化され、１つまたは複数の名前空間は所与のテナントに関連する。テナントは、企業、企業内の組織の部門、その課などとすることができるが、この技法は、サービスプロバイダによって実施することもできる。この手法により、ユーザは、クラスタデータを論理的区分に分けることができる。この管理インタフェースを使用して、所与のテナントに関連する名前空間は、名前空間のセット中の少なくとも１つの他の名前空間の構成に影響を及ぼさずに選択的に構成される。このアーキテクチャにより、１つのテナント当たり複数の名前空間があり構成が名前空間レベルで行われる、多くのトップレベルテナントのサポートが可能になる。
【０００５】
以上、本発明のより関連性の高い特徴のいくつかを概説した。これらの特徴は例示に過ぎないと解釈すべきである。開示する本発明を異なる方式で適用することにより、または本発明を後述のように修正することにより、多くの他の有益な結果を達成することができる。
【図面の簡単な説明】
【０００６】
【図１】本発明をその中で実施できる固定コンテンツストレージアーカイブの簡略化されたブロック図である。
【図２】本発明による、各独立ノードが対称でありアーカイブクラスタアプリケーションをサポートする、独立ノード冗長アレイの簡略化された表現の図である。
【図３】所与のノード上で実行されるアーカイブクラスタアプリケーションの様々なコンポーネントの高レベル表現の図である。
【図４】本明細書に述べる技法によりどのようにクラスタが区分化されるかを示す図である。
【図５】テナント管理者コンソールの「概観」ページを示す図である。
【図６】テナント管理者コンソールの「名前空間」ページを示す図である。
【図７】テナント管理者コンソールの「名前空間を作成する」コンテナページを示す図である。
【図８】所与の名前空間についての「名前空間の概観」コンテナページを示す図である。
【図９】管理者が所与のポリシを構成できる、所与の名前空間についての「ポリシ」コンテナページを示す図である。
【図１０】どのように管理者が名前空間についてバージョニングをイネーブルにするかを示す図である。
【図１１】どのように管理者が名前空間について廃棄サービスをイネーブルにするかを示す図である。
【図１２】どのように管理者が名前空間について特権的削除オプションをイネーブルにするかを示す図である。
【図１３】どのように管理者が名前空間について保存クラスをイネーブルにするかを示す図である。
【発明を実施するための形態】
【０００７】
スケーラブルなディスク・ベースのアーカイブストレージ管理システムを提供すること、好ましくは、独立ノード冗長アレイに基づくシステムアーキテクチャを提供することもまた知られている。各ノードは、異なるハードウェアを備える場合があり、したがって「異種」と考えることができる。ノードは通常、１つまたは複数のストレージディスクへのアクセスを有するが、これらのストレージディスクは、実際の物理ストレージディスクとすることもでき、またはストレージエリアネットワーク（ＳＡＮ）におけるように仮想ストレージディスクとすることもできる。各ノード上でサポートされるアーカイブクラスタアプリケーション（および任意選択で、このアプリケーションが実行される、基礎を成すオペレーティングシステム）は、同じかまたはほぼ同じとすることができる。例示的な一実施形態では、各ノード上のソフトウェアスタック（オペレーティングシステムを含むことができる）は対称だが、ハードウェアは異種である場合がある。このシステムを使用して、図１に示すように、企業が、とりわけ文書、電子メール、衛星画像、診断画像、チェック画像、音声録音、ビデオなど、多くの異なるタイプの固定コンテンツ情報のための永続的ストレージを生み出すことができる。当然、これらのタイプは例示に過ぎない。独立サーバまたはいわゆるストレージノード上でデータを複製することによって、高レベルの信頼性が達成される。各ノードは、そのピアと対称であることが好ましい。したがって、好ましくはどんな所与のノードも全ての機能を実施することができるので、いずれか１つのノードの障害はアーカイブの可用性にほとんど影響を及ぼさない。
【０００８】
米国特許第７，１５５，４６６号に記載のように、各ノード上で実行される分散ソフトウェアアプリケーションが、ディジタル資産を取り込み、保存し、管理し、取り出す。図２の例示する一実施形態では、個別アーカイブの物理的境界が、クラスタと呼ばれる。通常、クラスタは、単一のデバイスではなく、デバイスの集まりである。デバイスは、同種または異種である場合がある。典型的なデバイスは、Ｌｉｎｕｘなどのオペレーティングシステムを実行するコンピュータまたはマシンである。コモディティハードウェア上でホストされるＬｉｎｕｘベースのシステムのクラスタは、少数のストレージノードサーバから、何千テラバイトものデータを記憶する多くのノードまでスケーリングできるアーカイブを提供する。このアーキテクチャにより、記憶容量が、組織のますます増加するアーカイブ要件に常に遅れを取らずにいられることが確実になる。アーカイブが常にデバイス障害から保護されるように、データがクラスタ全体で複製されることが好ましい。ディスクまたはノードに障害が発生した場合、クラスタは自動的に、クラスタ中の、同じデータのレプリカを維持する他のノードにフェイルオーバする。
【０００９】
例示的なクラスタは、以下の一般的なコンポーネントカテゴリ、すなわちノード２０２、１対のネットワークスイッチ２０４、電力分配ユニット（ＰＤＵ）２０６、および無停電電源（ＵＰＳ）２０８を備えることが好ましい。ノード２０２は通常、１つまたは複数のコモディティサーバを備え、ＣＰＵ（例えばＩｎｔｅｌ  ｘ８６）、適切なランダムアクセスメモリ（ＲＡＭ）、１つまたは複数のハードドライブ（例えば標準的なＩＤＥ／ＳＡＴＡ、ＳＣＳＩなど）、および２つ以上のネットワークインタフェース（ＮＩＣ）カードを含む。典型的なノードは、２．４ＧＨｚチップ、５１２ＭＢ  ＲＡＭ、および６つの２００ＧＢハードドライブを備えた、２Ｕラックマウント式ユニットである。ただしこれは限定ではない。ネットワークスイッチ２０４は通常、ノード間のピア・ツー・ピア通信を可能にする内部スイッチ２０５と、各ノードへのクラスタ外アクセスを可能にする外部スイッチ２０７とを含む。各スイッチは、クラスタ中の全ての潜在的なノードに対処するのに十分なポートを必要とする。この目的で、ＥｔｈｅｒｎｅｔまたはＧｉｇＥスイッチを使用することができる。ＰＤＵ２０６は、全てのノードおよびスイッチに電力供給するのに使用され、ＵＰＳ２０８は、全てのノードおよびスイッチを保護するのに使用される。限定というわけではないが、クラスタは通常、公衆インターネット、企業イントラネット、または他のワイドエリアもしくはローカルエリアネットワークなど、ネットワークに接続可能である。例示的な一実施形態では、クラスタは、企業環境内で実現される。クラスタへは、例えば、サイトの法人ドメインネームシステム（ＤＮＳ）ネームサーバを介してナビゲートすることによって到達することができる。したがって例えば、クラスタのドメインは、既存のドメインの新しいサブ・ドメインとすることができる。代表的な一実装形態では、サブ・ドメインは、法人ＤＮＳサーバ中で、クラスタ自体の中のネームサーバに委任される。エンドユーザは、任意の従来のインタフェースまたはアクセスツールを使用して、クラスタにアクセスする。したがって例えば、コンテンツプラットフォームへのアクセスは、任意のプロトコル（ＲＥＳＴ、ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、ウェブサービスなど）によって、またはＡＰＩを介して、またはいずれか他の既知のもしくは後に開発されるアクセス方法、サービス、プログラム、もしくはツールを通して行うことができる。
【００１０】
クライアントアプリケーションは、標準的なＵＮＩＸファイルプロトコルやＨＴＴＰ  ＡＰＩなど、１つまたは複数のタイプの外部ゲートウェイを通してクラスタにアクセスする。アーカイブは、任意の標準的なＵＮＩＸファイルプロトコル指向の機能の下に任意選択で位置することのできる仮想ファイルシステムを通して見えるようにされることが好ましい。これらの仮想ファイルシステムとしては、ＮＦＳ、ＦＴＰ、ＳＭＢ／ＣＩＦＳなどが挙げられる。
【００１１】
一実施形態では、アーカイブクラスタアプリケーションは、クラスタとして共にネットワーク化（例えばＥｔｈｅｒｎｅｔを介して）された独立ノード冗長アレイ（Ｈ−ＲＡＩＮ）上で実行される。所与の各ノードのハードウェアは、異種である場合がある。しかし、信頼性のために、好ましくは、各ノードは分散アプリケーションのインスタンス３００（同じインスタンス、またはほぼ同じインスタンスとすることができる）を実行し、インスタンス３００は、次に図３に示すようにいくつかの実行時コンポーネントからなる。したがって、ハードウェアは異種である場合があるが、ノード上のソフトウェアスタックは（少なくとも本発明に関しては）同じである。これらのソフトウェアコンポーネントは、ゲートウェイプロトコルレイヤ３０２、アクセスレイヤ３０４、ファイルトランザクションおよび管理レイヤ３０６、ならびにコアコンポーネントレイヤ３０８を含む。「レイヤ」という呼称は説明の目的で提供するものであり、これらの機能を他の有意義な方法で特徴付けることもできることを当業者なら理解するであろう。これらのレイヤ（またはその中のコンポーネント）の１つまたは複数が統合されてもよく、そうでなくてもよい。いくつかのコンポーネントは、複数のレイヤにまたがって共有されてもよい。
【００１２】
ゲートウェイプロトコルレイヤ３０２中のゲートウェイプロトコルは、既存のアプリケーションに対する透過性を提供する。特に、ゲートウェイは、ＮＦＳ３１０やＳＭＢ／ＣＩＦＳ３１２などのネイティブファイルサービス、ならびに、カスタムアプリケーションを構築するためのウェブサービスＡＰＩを提供する。ＨＴＴＰサポート３１４もまた提供される。アクセスレイヤ３０４は、アーカイブへのアクセスを提供する。特に、本発明によれば、固定コンテンツファイルシステム（ＦＣＦＳ）３１６が、ネイティブファイルシステムをエミュレートして、アーカイブオブジェクトへの完全なアクセスを提供する。ＦＣＦＳは、アーカイブコンテンツが普通のファイルであるかのように、アーカイブコンテンツへの直接アクセスをアプリケーションに与える。好ましくは、アーカイブされたコンテンツはその元のフォーマットでレンダリングされ、メタデータはファイルとして見えるようにされる。ＦＣＦＳ３１６は、ディレクトリおよび許可の従来型のビューと、ルーチンファイル・レベルコールとを提供し、したがって管理者は、管理者に馴染みのある方式で固定コンテンツデータをプロビジョニングする（ｐｒｏｖｉｓｉｏｎ）ことができる。ファイルアクセスコールは、ユーザ空間デーモンによってインターセプトされて適切な（レイヤ３０８中の）コアコンポーネントにルーティングされることが好ましく、このコアコンポーネントは、呼出し側アプリケーションに対する適切なビューを動的に生み出す。ＦＣＦＳコールは、自律的なアーカイブ管理を容易にするためにアーカイブポリシによって制約されることが好ましい。したがって一例では、管理者またはアプリケーションは、保存期間（所与のポリシ）がまだ有効であるアーカイブオブジェクトを削除することはできない。
【００１３】
アクセスレイヤ３０４はまた、ウェブユーザインタフェース（ＵＩ）３１８およびＳＮＭＰゲートウェイ３２０を備えることが好ましい。ウェブユーザインタフェース３１８は、ファイルトランザクションおよび管理レイヤ３０６中の管理エンジン３２２への対話式アクセスを提供する管理者コンソールとして実現されることが好ましい。管理コンソール３１８は、アーカイブオブジェクトと個々のノードとを含めたアーカイブの動的ビューを提供する、パスワード保護されたウェブ・ベースのＧＵＩであることが好ましい。ＳＮＭＰゲートウェイ３２０は、管理エンジン３２２への容易なアクセスをストレージ管理アプリケーションに提供して、ストレージ管理アプリケーションがクラスタアクティビティを安全に監視および制御できるようにする。管理エンジンは、システムとポリシイベントとを含めたクラスタアクティビティを監視する。ファイルトランザクションおよび管理レイヤ３０６はまた、要求マネージャプロセス３２４を備える。要求マネージャ３２４は、外部世界（アクセスレイヤ３０４を通した）からの全ての要求、ならびにコアコンポーネントレイヤ３０８中のポリシマネージャ３２６からの内部要求を取りまとめる。
【００１４】
コアコンポーネントはまた、ポリシマネージャ３２６に加えて、メタデータマネージャ３２８と、ストレージマネージャ３３０の１つまたは複数のインスタンスとを備える。メタデータマネージャ３２８は、各ノード上にインストールされることが好ましい。クラスタ中のメタデータマネージャは、集合的に、分散データベースとして働いて、全てのアーカイブオブジェクトを管理する。所与のノード上で、メタデータマネージャ３２８はアーカイブオブジェクトのサブセットを管理し、好ましくは、各オブジェクトは、外部ファイル（「ＥＦ」、記憶されるようにアーカイブに入ったデータ）と、アーカイブデータが物理的に位置する１組の内部ファイル（それぞれ「ＩＦ」）との間でマッピングする。同じメタデータマネージャ３２８が、他のノードから複製された１組のアーカイブオブジェクトも管理する。したがって、あらゆる外部ファイルの現在の状態が、いくつかのノード上の複数のメタデータマネージャに常に利用可能である。ノード障害が発生した場合、他のノード上のメタデータマネージャは、障害が発生したノードによって前に管理されていたデータへのアクセスを提供し続ける。この動作については、後でより詳細に述べる。ストレージマネージャ３３０は、分散アプリケーション中の他の全てのコンポーネントに利用可能なファイルシステムレイヤを提供する。ストレージマネージャ３３０は、データオブジェクトをノードのローカルファイルシステムに記憶することが好ましい。所与のノード中の各ドライブは、それ自体のストレージマネージャを有することが好ましい。これにより、このノードは、個々のドライブを除去することができ、スループットを最適化することができる。ストレージマネージャ３３０はまた、システム情報と、データに対する完全性チェックと、ローカルディレクトリ構造を横断する能力とを提供する。
【００１５】
図３に示すように、クラスタは、通信ミドルウェアレイヤ３３２およびＤＮＳマネージャ３３４を通して、内部および外部通信を管理する。インフラストラクチャ３３２は、アーカイブコンポーネント間の通信を可能にする効率的で信頼性のあるメッセージ・ベースのミドルウェアレイヤである。例示する一実施形態では、このレイヤは、マルチキャスト通信およびポイント・ツー・ポイント通信をサポートする。ＤＮＳマネージャ３３４は、全てのノードを企業サーバに接続する分散ネームサービスを実行する。ＤＮＳマネージャは（単独で、またはＤＮＳサービスと共に）、全てのノードにわたり要求の負荷平衡を保って、最大のクラスタスループットおよび可用性を確実にすることが好ましい。
【００１６】
例示する一実施形態では、アプリケーションインスタンスは、Ｒｅｄ  Ｈａｔ  Ｌｉｎｕｘ１０．０などの基礎オペレーティングシステム３３６上で実行される。通信ミドルウェアは、任意の好都合な分散通信機構である。他のコンポーネントは、ＦＵＳＥ（Ｆｉｌｅｓｙｓｔｅｍ  ｉｎ  ＵＳＥｒｓｐａｃｅ）を含むことができ、ＦＵＳＥは、固定コンテンツファイルシステム（ＦＣＦＳ）３１６のために使用することができる。ＮＦＳゲートウェイ３１０は、Ｕｎｆｓｄによって実現することができ、Ｕｎｆｓｄは、標準的なｎｆｓｄ  Ｌｉｎｕｘ  Ｋｅｒｎｅｌ  ＮＦＳドライバのユーザ空間実装である。各ノード中のデータベースは、例えばＰｏｓｔｇｒｅＳＱＬ（本明細書ではＰｏｓｔｇｒｅｓとも呼ばれる）によって実現することができ、ＰｏｓｔｇｒｅＳＱＬは、オブジェクト関係データベース管理システム（ＯＲＤＢＭＳ）である。ノードは、Ｊｅｔｔｙなどのウェブサーバを含むことができ、Ｊｅｔｔｙは、Ｊａｖａ  ＨＴＴＰサーバ／サーブレットコンテナである。当然、上記の機構は例示に過ぎない。
【００１７】
所与のノード上のストレージマネージャ３３０は、物理ストレージデバイスを管理することを担う。各ストレージマネージャインスタンスは、その配置アルゴリズムに従って全てのファイルが配置される単一のルートディレクトリを担当することが好ましい。複数のストレージマネージャインスタンスが１つのノード上で同時に実行されていてよく、各ストレージマネージャインスタンスは普通、システム中の異なる物理ディスクを表す。ストレージマネージャは、使用されているドライブおよびインタフェース技術を、システムの残りの部分から抽象化する。ストレージマネージャインスタンスは、ファイルを書き込むよう依頼されたとき、担当することになる表現の完全なパスおよびファイル名を生成する。代表的な一実施形態では、ストレージマネージャ上で記憶されることになる各オブジェクトは、記憶されるべき生データとして受け取られ、次いでストレージマネージャは、種々のタイプの情報を常に把握するために、このオブジェクトを記憶する際にストレージマネージャ自体のメタデータをファイルに追加する。例として、このメタデータは、ＥＦ長（バイトで表された外部ファイルの長さ）、ＩＦセグメントサイズ（内部ファイルのこの部分のサイズ）、ＥＦ保護表現（ＥＦ保護モード）、ＩＦ保護役割（この内部ファイルの表現）、ＥＦ作成タイムスタンプ（外部ファイルのタイムスタンプ）、署名（署名タイプを含めた、書込み時（ＰＵＴ）の内部ファイルの署名）、およびＥＦファイル名（外部ファイルのファイル名）を含む。内部ファイルデータと共にこの追加メタデータを記憶することにより、追加のレベルの保護がもたらされる。特に、スカベンジングによって、内部ファイルに記憶されたメタデータから、データベース中の外部ファイル記録を作成することができる。他のサービス（本明細書では「ポリシ」と呼ばれることもある）が、内部ファイルハッシュを内部ファイルに対して妥当性検査して、内部ファイルが損なわれないままであることを妥当性検査することができる。
【００１８】
前述のように、内部ファイルは、アーカイブオブジェクト中の元の「ファイル」の一部を表すデータの「チャンク」であることが好ましく、これらのチャンクは、種々のノード上に配置されて、ストライピングおよび保護ブロックを達成することが好ましい。通常は各アーカイブオブジェクトに対して１つの外部ファイルエントリがメタデータマネージャ中に存在するが、各外部ファイルエントリに対して多くの内部ファイルエントリがある場合もある。通常、内部ファイルレイアウトはシステムに依存する。所与の一実装形態では、このデータのディスク上の実際の物理的フォーマットは、一連の可変長の記録に記憶される。
【００１９】
要求マネージャ３２４は、システム内の他のコンポーネントと対話することによって、アーカイブアクションを実施するのに必要な１組の操作を実行することを担う。要求マネージャは、種々のタイプの多くの同時アクションをサポートし、失敗したトランザクションがあればそれをロールバックすることができ、実行に長時間かかる可能性のあるトランザクションをサポートする。要求マネージャはまた、アーカイブ中での読取り／書込み操作が正しく処理されることを確実にし、全ての要求が常に既知の状態にあることを保証する。要求マネージャはまた、複数のノードにまたがる複数の読取り／書込み操作を調整するためのトランザクション制御を提供して、所与のクライアント要求を満たす。加えて、要求マネージャは、最近使用されたファイルのメタデータマネージャエントリをキャッシュし、セッションならびにデータブロックのためのバッファリングを提供する。
【００２０】
クラスタの主要な任務は、無限数のファイルを確実にディスク上に記憶することである。所与のノードが、何らかの理由で到達不可能であるかさもなければ利用不可能であるかもしれないという意味で、「信頼性がない」と考えられる場合がある。このような潜在的に信頼性のないノードの集まりが協働して、信頼性があり可用性の高いストレージを生み出す。一般に、記憶する必要のある情報には２つのタイプがある。すなわち、ファイル自体と、ファイルに関するメタデータとである。
【００２１】
上述したようなコンテンツプラットフォームが、参照によりその開示が組み込まれる２００７年２月１５日に出願された米国特許出願第１１／６７５，２２４号に記載の方式などのデータ保護レベル（ＤＰＬ）方式を実施することができる。
【００２２】
コンテンツプラットフォームはまた、参照によりその開示が組み込まれる２００７年１１月７日に出願された米国特許出願第１１／９３６，３１７号に記載の方式などの複製方式を実施することもできる。
【００２３】
以上は、知られている「アーカイブクラスタ」に関する記述である。以下に、記憶すべきユーザデータの量が増加するのに伴ってどのように企業（またはサービスプロバイダなど他のエンティティ）がクラスタを区分化してクラスタリソースをより効果的に利用することができるかについて述べる。
【００２４】
クラスタ区分化−テナントおよび名前空間
【００２５】
次に述べる主題に対して、以下の術語が適用される。
【００２６】
データアカウント（ＤＡ）：１つまたは複数の名前空間へのアクセスを提供する認証されたアカウント。このアカウントは、このアカウントがアクセスできる各名前空間につき、ＣＲＵＤ（作成、読取り、更新、および削除）特権の別個のセットを有する。
【００２７】
名前空間（ＮＳ）：クラスタの論理的区分。名前空間は本質的に、少なくとも１つの定義されたアプリケーションに特有のオブジェクトの集まりとしての働きをする。後述するように、各名前空間は、他の名前空間に対するプライベートファイルシステムを有する。さらに、ある名前空間へのアクセスは、別の名前空間へのアクセスをユーザに与えない。アーカイブは、単一のクラスタ上で許容される名前空間の数の上限を有することができる（例えば１００個まで）。
【００２８】
認証名前空間（ＡＮＳ）：認証されたデータアクセスを必要とする名前空間（好ましくはＨＴＴＰのみ）。
【００２９】
デフォルト名前空間（ｄＮＳ）：ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）以外においてクラスタ中に取り込まれるデータと共に使用される名前空間。ＲＥＳＴは、ウェブ上で構造化データおよびタイプ情報を交換するのに一般に使用される軽量プロトコルである。さらに、アプリケーションがＲＥＳＴインタフェースを使用する場合でも、名前空間がクラスタに対して認証中に指定されない場合は、全てのデータをデフォルト名前空間に記憶することができる。
【００３０】
テナント：名前空間（複数可）および場合によっては他のサブテナントの、グループ化。
【００３１】
トップ・レベルテナント（ＴＬＴ）：親テナントを持たないテナント。例えば企業。
【００３２】
サブテナント：別のテナントを親に持つテナント。例えば企業の資金調達部門。
【００３３】
デフォルトテナント：デフォルト名前空間のみを含むトップ・レベルテナント。
【００３４】
クラスタ：上述したような物理的アーカイブインスタンス。
【００３５】
クラスタが新たにインストールされたとき、このクラスタはテナントを含まない。クラスタ管理者は、トップ・レベルテナントと、これらのトップ・レベルテナントに関連する管理アカウントとを作成し、また、デフォルトテナントおよびデフォルト名前空間をイネーブルにする。図４に、この基本概念を示す。この図に示すように、図２〜３に示し上述したシステムなどの、クラスタインスタンス４００がある。後でより詳細に示すが、クラスタ管理者は、アカウント４０２を有する。適切な管理者に、トップレベルテナント４０４と、このＴＬＴについての１つまたは複数の名前空間（第１の認証名前空間４０６（エンジニアリング部門の）および第２の認証名前空間４０８（財務部門の）など）とを作成する権限が与えられる。適切な管理者はまた、このＴＬＴについての管理者アカウント４１２およびデータアカウント４１４をセットアップする。加えて、管理者は、関連するデフォルト名前空間４１８を有するデフォルトテナント４１６をイネーブルにすることもできる。図示されていないが、認可された管理者はまた、サブテナントをセットアップすることもできる。管理者はまた、管理ログ４２０を確立する。当然、上記の構成は例に過ぎず、本明細書の主題は、どんな特定のタイプの使用ケースまたはテナント／名前空間構成にも限定されない。
【００３６】
マクロレベルでは、全ての名前空間は、同じ品質および能力を有する同じまたはほぼ同じエンティティと考えることができる。一般に、かつ理解されるであろうが、名前空間は、適切に資格授与された管理者によって決定されるようにイネーブルまたはディセーブルにすることのできる１組の関連する能力を有する。単一の名前空間が１つまたは複数のアプリケーションをホストすることができるが、好ましくは、名前空間は１つの定義されたアプリケーションのみに関連する（ただしこれは限定ではない）。名前空間は通常、名前空間管理者が所与のデータアカウントについてイネーブルまたはディセーブルにするように選択できる以下の１組の関連する能力のうちの１つまたは複数を有する。すなわち、読取り（ｒ）（ファイル読取り、ディレクトリリスティング、およびｅｘｉｓｔｓ／ＨＥＡＤ操作を含む）、書込み（ｗ）、削除（ｄ）、パージ（ｐ）（ファイルの全てのバージョンのパージを可能にする）、特権（Ｐ）（特権的削除および特権的パージを可能にする）、ならびに検索（ｓ）である。
【００３７】
名前空間を使用して、かつ図４に全体的に示すように、管理者は、クラスタに対して複数のドメインを作成することができ、これらのドメインは、ユーザ／動作主の観点に基づいて異なる。これらのドメインは、例えばアクセスアプリケーション、クラスタ管理者、ＴＬＴ管理者、サブテナント管理者、および複製を含む。アクセスアプリケーションのドメインは、所与の名前空間である。認可された管理者（管理者４０２など）が、クラスタ全体のビューを有する。図示のように、管理者４０２は、トップ・レベルテナントを作成することができ、クラスタスコープを有するアクションに関する全ての管理を実施することができる。企業展開などいくつかの状況では、テナントは、テナントを管理する能力を適切な管理者に与えることができ、この場合、任意のクラスタ管理者がＴＬＴ管理者としても機能できることになる。ＴＬＴ管理者は、名前空間、データアカウント、およびサブテナントを作成する。ＴＬＴは、名前空間クォータなどいくつかの構成設定を修正することができ、またはバージョニングを可能にすることができる。サブテナント管理者は、サブテナントの下に名前空間を作成することができる。複製のドメインは、クラスタ間の複製を構成する間にクラスタ管理者によって定義される１組のＴＬＴである。
【００３８】
テナントが、管理者から見た論理的アーカイブであることは、当業者なら理解するであろう。図４に示すように、テナントは、クラスタの一部を使用して組織または部門を表すことができる。テナントは、他のテナントを含めることのできる階層として実現することができる。
【００３９】
テナントは、以下の１組の属性を有することが好ましい。すなわち、名前空間、管理アカウント、データアクセスアカウント、許可マスク、状態のロール・アップ、名前、およびクォータである。テナントは、０以上の名前空間を含むことができる。テナントは、テナントの属性をユーザが監視および更新できるようにする１組の管理アカウント（アカウント４１２など）を有することになる。データアクセスアカウントは、名前空間オブジェクトにアクセスするアカウントのセットである。許可マスク（ｒ／ｗ／ｄ／ｐ／Ｐ／ｓ）は、テナントに対して大域的であり名前空間の許可をマスクする許可のセットである。状態のロール・アップは、テナント内の全ての名前空間に対するメトリックである。テナントの名前は、適切な管理者によって設定可能かつ変更可能である。同じクラスタ内のテナント名は、競合し（ｃｏｌｌｉｄｅ）てはならない。トップレベルテナントには、管理者によってハードストレージクォータが割り当てられることが好ましい。適切な管理者は、このクォータを下げるかまたは上げることができ、この管理者は、望むだけのクォータを割り当てることができる。ＴＬＴはソフトクォータを指定することもでき、ソフトクォータは、ハードクォータの所与のパーセンテージである。テナントは、そのクォータを１つまたは複数の名前空間の間で分割することができるが、割り当てられる総クォータは、テナントのクォータを超えてはならない。課金の目的で、クォータは、取り込まれたファイルの、最も近いブロックサイズに切り上げられたサイズを測定することになることが好ましい。ソフトクォータは通常、ハードクォータの所定のパーセンテージ（例えば８５％）だが、この値は構成設定可能とすることができる。ハードクォータを超過した後はそれ以上の書込みは許可されないが、好ましくは、進行中の書込みはブロックされない。クォータを超過することと、それ以上の書込みがブロックされることとの間に遅延があるのは許容可能とすることができる。クォータは、複製されるが変更できないことが好ましい。レプリカが書込み可能になったとき、クォータもまたそこで施行される。
【００４０】
テナント管理者はまた、モニタ役割、管理者役割、セキュリティ役割、およびコンプライアンス役割うちの１つまたは複数を含む１組の役割を有する。モニタ役割は、管理者役割の読取専用バージョンである。管理者役割は、テナントに関連する主要役割である。先に記述および例示したように、この役割は、管理ユーザが現在のテナントの下に名前空間を作成するのを可能にし、このテナント内の全ての名前空間（および、ファイル数、利用可能な空間、使用されている空間など、関連する統計）のビューを提供する。管理者はまた、テナントおよび名前空間ログを閲覧することができ、管理者は、テナントおよび名前空間構成を閲覧する／更新することができる。セキュリティ役割は、新しい管理ユーザを作成／修正／削除する能力をユーザに与える。セキュリティ役割を有するユーザは、他のテナント・レベルの管理アカウントから役割を追加および削除することができる。テナントが最初に作成されたとき、好ましくは、このテナントに関連する１人の管理ユーザが存在し、このユーザアカウントはセキュリティ役割のみを有する。コンプライアンス役割は、特権的削除および保存クラス機能（以下に定義する）を使用可能にする。
【００４１】
名前空間は、アプリケーションから見た論理的アーカイブである。本明細書の主題によれば、特定の名前空間は、異なる名前空間とは別個であり、ある名前空間へのアクセスは、別の名前空間へのアクセスをユーザに与えない。名前空間の管理は、所有テナントレベルで実施されることが好ましい。さらに、名前空間は、その名前空間に関連するオブジェクトの数が０である場合にのみ削除できることが好ましい。名前空間はまた、以下の属性、すなわち許可マスク、初期設定、他の設定、表示名、クォータ、ログ、および統計を有することが好ましい。前述のように、許可マスク（ｒ／ｗ／ｄ／ｐ／Ｐ／ｓ）は、名前空間に対して大域的でありアカウントの許可をマスクする設定のセットである。初期設定は、持続的なままであることが好ましいデータ保護レベル（ＤＰＬ）やハッシング方式などを識別する。他の設定は、名前空間に対して設定してから後で変更することのできる設定（保存、シュレッド、バージョニング、索引付けなど）を指す。この機能については、後でより詳細に述べる。表示名は、名前空間の名前または他の識別子である。クォータは、ハード（ＧＢで表される）とソフト（パーセントで表される）のいずれかである。ログ属性は、ログされることになる、名前空間に関係するシステムイベントを識別する。統計属性は、容量やオブジェクト数など、名前空間に関係するデータから生成される統計を識別する。
【００４２】
テナント名および名前空間名は、様々な管理ユーザインタフェース（ＵＩ）における、人間が読める識別子であることが好ましい。これらの名前はまた、ホスト名の中で使用されて、データアクセス要求の名前空間と、管理者が管理しているテナントと、検索を制限すべき範囲とを指定することが好ましい。テナントには複数の名前空間が関連する場合があるので、名前空間名は有用である。ＨＴＴＰを介したオブジェクトアクセスは、以下の形のホスト名を使用することが好ましい。
【００４３】
＜名前空間名＞．＜テナント名＞．＜クラスタ・ドメイン・サフィックス＞（＜ｎａｍｅｓｐａｃｅ−ｎａｍｅ＞．＜ｔｅｎａｎｔ−ｎａｍｅ＞．＜ｃｌｕｓｔｅｒ−ｄｏｍａｉｎ−ｓｕｆｆｉｘ＞）
これらの名前は、従来のドメインネームシステム（ＤＮＳ）規格に準拠する。前述のように、クラスタ上のテナント名は競合してはならない。
【００４４】
以下に、テナント管理ユーザインタフェース（ＵＩ）と、このインタフェースによって提供される関連機能とに関する追加の詳細を提供する。テナントＵＩは、ウェブ・ベースのユーザインタフェース（図３のインタフェース３１８など）として、すなわち、管理エンジンへの対話式アクセスを提供するテナント管理者コンソールとして実現されることが好ましい。管理コンソールは、アーカイブの動的ビューを提供する、パスワード保護されたウェブ・ベースのＧＵＩであることが好ましい。テナント管理者がテナント管理者コンソールにログインすると、メインナビゲーションメニューを提示する概観ページが提供される。このメニューは、概観、名前空間、データアクセスアカウント、サービス、セキュリティ、および監視など、１つまたは複数の高レベル機能（ウェブページとして実現される）へのアクセスを提供する。次に、これらのインタフェースのいくつかについてより詳細に述べる。
【００４５】
図５に見られるように、「概観」ページ５００は、統計および主要イベントログを含めた、現在のテナント（すなわち管理者がログインしたテナント）に関する情報を示す。通常、このページは以下の情報を含み、好ましくはこの情報は編集可能でない。すなわち、テナント名５０２と、テナントアカウント設定を更新するためのリンク５０４と、任意のクラスタ管理者がまたこのテナントを管理してこのテナントに関連する全ての名前空間中の全てのオブジェクトを検索する（検索役割を有すると仮定した場合）ことを可能にするチェックボックス５０６と、クォータ（総計、未割振り、および割振り済み）、名前空間（総数、取込み済みオブジェクト、索引付け済みオブジェクト、およびバージョニング済みオブジェクト）、ならびにアカウント（データアカウントの数および管理アカウントの数）などのロール・アップ情報５０８と、このテナントによって所有される名前空間に適用される許可メニュー５１０と、テナント説明５１２と、ログおよびアラート５１４とである。図５に示すように、許可メニューは、有効な許可（チェックが入っている）、および許可マスクの値を識別する。これはトップレベルなので、全ての設定は、継承されるものとして、かつテナントマスク中に存在するものとして示されている。ユーザが編集タブを選択すると、サブ・メニュー５１６が表示されて、許可された管理者が個々の許可を修正できるようになる。好ましくは、管理者役割は、このページ上のパネルを修正することができ、モニタ役割および管理者役割は、このページ、およびこのページ上のパネルを閲覧することができる。
【００４６】
図６に「名前空間」ページ６００を示すが、このページは、このテナントの直下に定義された全ての名前空間、ならびに、各名前空間に関する一般的な統計（オブジェクト数、任意のアラート、およびクォータ）をリストする。このページにより、管理者は、特定の名前空間をさらに構成するために掘り下げることができる。このページは、管理者役割およびモニタ役割を有するアカウントによって閲覧可能である。このページは、現在のテナントによって所有される名前空間をリストするテーブル６０２を含み、管理者が名前空間を作成すること、リストされた名前空間についての設定を閲覧もしくは編集すること、またはリストされた名前空間についての統計を閲覧することを可能にするためのコントロール（例えばリンク／ボタン６０４）が設けられる。このテーブルは、オブジェクト数６０６、アラート６０８、およびクォータ６１０など、所与の名前空間についての統計および他の情報がサマリ形式で表示される列を含む。
【００４７】
「名前空間を作成する」コンテナタイトルバーを選択することにより、図７に示されるように「名前空間を作成する」コンテナ７００が展開して、テナントが現在のテナントについての新しい名前空間を追加できるようになる。新しい名前空間を作成するために、ユーザは以下の情報を提供する。すなわち、名前７０２、説明７０４、最大サイズ（ＴＢ、ＧＢ、ＭＢなどで表された、新しい名前空間のハードクォータ）７０６、ソフトクォータ（デフォルトで８５％とすることができる）７０８、ＤＰＬ値７１０（デフォルトで、外部記憶については１、内部記憶については２とすることができる）、ハッシュ値７１２（デフォルトでＳＨＡ−２５６とすることができる）、保存モード７１４（企業またはコンプライアンス。デフォルトでは企業）、オブジェクトバージョニング７１６（オン／オフ。デフォルトではオフ）、および検索の索引付け７１８（オン／オフ。デフォルト値はテナントから継承される）である。管理者役割は、このページを閲覧および修正できることが好ましい。名前空間についての個々のパラメータが構成された後は、ユーザは、「名前空間を作成する」ボタン７２０を選択して、このプロセスを完了する。このようにして、テナント構成内の個別の名前空間それぞれが、テナント内の他のいずれかの名前空間と比較して高度に構成設定可能である。この、名前空間ごとの構成設定可能性オプションは、大きな操作管理フレキシビリティをもたらす。
【００４８】
再び図６を参照するが、識別された名前空間のいずれか１つをユーザが選択すると、図８に示されるように「名前空間の概観」コンテナ８００が展開して、選択された名前空間に関する統計が見えるようにされる。この統計は、名前空間名のフィールド８０２、オブジェクトおよび使用のグラフ８０４（例えば名前空間中のオブジェクト、索引付けされたオブジェクト、名前空間に転送されたバイトなどの使用、ファイルサイズ合計、および割り振られた総クォータ）、アラート８０６、許可メニュー８０８（この名前空間についての許可マスクを示す）、ならびに説明８１０を含む。モニタ役割および管理者役割が、このページを閲覧することができる。図８にやはり示されるように、所与の名前空間が構成のために選択されると、「ポリシ」タブ８１２、「サービス」タブ８１４、「コンプライアンス」タブ８１６、「プロトコル」タブ８１８、および「監視」タブ８２０を含めて、いくつかのコンテナページが見えるようにされる。次に、これらのインタフェースのいくつかについてより詳細に述べる。
【００４９】
ユーザが「名前空間の概観」コンテナ８００から「ポリシ」タブ８１２を選択した場合、「ポリシ」ページが表示され、次いでユーザはこの「ポリシ」ページから、この特定の名前空間について１つまたは複数のポリシを構成することができる。図９では、ユーザは、「ポリシ」ページ９００を開いて「保存ポリシ」タイトルバーを選択しており、これによりコンテナ９０２が開き、管理者はコンテナ９０２を通して保存ポリシを設定する。オフセット保存方法９０４を選択した場合、管理者は、最大値（年、月、日）を設定する。固定日付保存方法９０６を選択した場合、ユーザは、カレンダを使用して日付を設定する。特別値保存方法９０８を選択した場合、ユーザは、１組のオプション（削除を可能にする、最初は未指定、不定、および禁止）から選択することができる。保存クラス方法９１０を選択した場合、１組の追加オプションが見えるようにされるが、これについては後でより詳細に述べる。構成が行われた後は、構成は、「ポリシを更新する」ボタン９１２を選択することによって保存される。
【００５０】
別の構成設定可能なポリシは、バージョニングである。図１０に、この目的で使用できる１組のコントロールを備えたコンテナ１０００を示す。このコンテナが開かれると、ユーザは、チェックボックス１００２を選択して、この特定の名前空間についてバージョニングをイネーブルにすることができる。このチェックボックスを選択した場合、次いでユーザは、プライマリクラスタ上で、およびもし複製がイネーブルにされている場合にはいずれかのレプリカクラスタ上で、バージョンがどれくらい長く維持されるべきかを構成することができる（フィールド１００４を使用して）。このポリシは、「ポリシを更新する」ボタン１００６を選択することによって保存される。
【００５１】
以下、バージョニングに関する追加の詳細を提供する。前述のように、バージョニングがイネーブルにされている場合、アーカイブは、オブジェクトの複数のバージョンを記憶することができる。オブジェクトのバージョンは、ファイルと、それに関連するデータと、メタデータと、カスタムメタデータとからなる。バージョンは、データオブジェクトのみに適用されディレクトリまたはシンボリックリンクには適用されないことが好ましいが、これは限定ではない。バージョンは、データ、メタデータ、およびカスタムメタデータである。好ましくは、メタデータ変更は、現在のバージョン上の適所で行われ、新しいバージョンを生み出さない。バージョンは、以下に述べるようにして相互にリンクされた固有のオブジェクトである。バージョンは、特定のオブジェクトの、所与の時点よりも前の全てのバージョンを削除する操作である刈込み操作によって削除される。特定のオブジェクトの古いバージョンを削除する操作は、パージである。図１０に示されるように、チェックボックス１００２により、特定の名前空間についてバージョニングがイネーブルまたはディセーブルにされる。デフォルトでは、このオプションはディセーブル（チェックなし）であることが好ましい。前のバージョンを保持する日数が構成設定可能であり、デフォルトでは０日に設定される。複製機能がイネーブルにされている場合、前のバージョンを保持する日数をレプリカについて設定することができ、この値もまたデフォルトでは０日である。このパラメータの値が、プライマリについて指定された日数未満である場合は、警告が出されるが、この警告は、プライマリ上よりも少ないバージョン数しか保持されないと、レプリカからリストアする場合にバージョンが失われるかもしれないことをユーザに示すことになる。好ましくは、バージョニングが前にイネーブルにされた（かつオブジェクトがバージョニングされた）後でこの機能をディセーブルにすると、これまでの既存のバージョンが削除され、これらの既存のバージョンは刈込みの候補になる。
【００５２】
管理者コンソールの記述に戻るが、ユーザが名前空間についての「サービス」タブ８１４を選択した場合、１つまたは複数のサービスオプションを構成することができる。このようなサービスオプションの１つは、廃棄であり、これは、保存の期限が切れたオブジェクトの自動削除を可能にする。廃棄サービスオプションは、チェックボックス１１０２を含むパネル１１００を通してイネーブルにされるが、チェックボックス１１０２は、この特定の名前空間についてこのオプションをイネーブルにするために選択される。ユーザは、「サービスを更新する」ボタン１１０４を選択して、この構成を完了する。したがって、この構成オプションによれば、構成済みの保存（例えば保存クラス中で識別される）の期限が切れた後は、この保存クラスに関連するオブジェクト（この名前空間のみについての）は、自動的にクラスタから削除される。この操作は、クラスタが記憶空間を再生利用できるようになるので有利である。しかし、廃棄サービスは名前空間ごとであり、このことは非常に望ましく、管理フレキシビリティの増大をもたらす。
【００５３】
ユーザが名前空間についての「コンプライアンス」タブ８１６を選択した場合、１つまたは複数のコンプライアンスオプションを構成することができる。図１２では、ユーザは、「特権的削除」コンプライアンスオプションを選択しており、このオプションによりユーザは、特定のオブジェクトを削除のために識別することができ、この削除の理由を提供することができる。図示のように、「特権的削除」パネル１２００は、削除すべきオブジェクトが（好ましくはその完全なパスによって）識別されるフィールド１２０２、ならびに、削除の理由を示す説明フィールド１２０４を含む。次いで、「このオブジェクトを削除する」ボタン１２０６を選択することにより、このオブジェクトはクラスタから永久に削除される。この機能は、企業動作モードでのみイネーブルにされることが好ましい。特権的削除機能により、ユーザは、オブジェクトが保存されていても、オブジェクトの全てのバージョンを除去することができる。
【００５４】
名前空間についての「コンプライアンス」タブ８１６中の別の構成設定可能なオプションは、１つまたは複数の保存クラスを構成するオプションである。保存クラスは、同じ保存構成に従うことになるオブジェクトの定義済みグループ化である。ユーザが「保存クラス」タブにナビゲートすると、前に定義された１組の保存クラスおよびそれらの値が表示され、これらを検討のために選択することができる。新しい保存クラスを追加するには、ユーザはタイトルバーを選択し、これにより、図１３に示されるコンテナ１３００が開く。このパネルを使用して、ユーザは、フィールド１３０２を使用して新しい保存クラス名を識別することができ、メニュー１３０４によって保存方法を選択することができ、フィールド１３０６に説明を追加することができる。保存方法メニュー１３０４は、前に記述された保存オプション（年、月、日）が見えるようにする。「新しい保存クラスを追加する」ボタン１３０８を使用して、新しいクラスが構成される。
【００５５】
詳細に例示はしないが、他の表示パネルは、操作および機能を名前空間特有ベースで構成するのに使用できる他の構成オプションが見えるようにする。したがって、「プロトコル」タブ８１８により、管理者は、ＨＴＴＰ、ＨＴＴＰＳをイネーブルにするなどプロトコル設定を管理することができ、ＩＰアドレスのホワイト／ブロックリストを作成することができる。「管理」タブ８２０により、管理者は、名前空間特有のシステムログメッセージを識別または検討することができ、オブジェクトステータスを検討することができ、特権的削除および保存クラスアクティビティを例証することができる。
【００５６】
管理者はまた、コンソール中のページからデータアクセスアカウントを作成および管理することができ、テナントが現在ログインしている全ての名前空間にこれらの構成設定が適用されるようにすることができる。このような各データアクセスアカウントにつき、管理者は、個人に与えられることになる所望のアクセス権（例えば読取り、書込み、削除、パージ、検索など）を関連付けることができる。
【００５７】
名前空間が認証される場合、以下の追加の制御を課すことができる。好ましくは、認証名前空間中のアーカイブオブジェクトへのアクセスは、ＨＴＴＰを通して実施され、有効な証明書を条件とする。クライアントは、典型的には各ＨＴＴＰ操作時にクッキーおよびホストヘッダを使用して、これらの証明書をクラスタに供給しなければならない。クライアント要求を名前空間中の特定のデータアクセスアカウントにマッピングするのに必要とされる必要情報は、ユーザ名、パスワード、および完全修飾名前空間名（ＦＱＮＮ、ｆｕｌｌｙ  ｑｕａｌｉｆｉｅｄ  ｎａｍｅｓｐａｃｅ  ｎａｍｅ）を含む。ＦＱＮＮは、テナント階層内の名前空間を識別し、名前空間名、テナント名、およびテナントの親の名前（もしあれば）に基づく。ＲＥＳＴアクセス方法が、オブジェクトアクション（オブジェクト取込み、オブジェクト取出し、オブジェクト存在チェック、オブジェクト削除、オブジェクトパージ、ディレクトリリスティング、およびディレクトリ作成）、ならびにメタデータアクション（保存を設定する、リーガルホールドを設定する、削除時シュレッドを設定する、カスタムメタデータを設定する／得る／削除する、全てのメタデータを得る）に使用されることが好ましい。知られているように、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）は、ウェブ上で構造化データおよびタイプ情報を交換するのに一般に使用される軽量プロトコルである。ＨＴＴＰオーバーＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）などのトランスポートレイヤセキュリティ機構を使用して、２つの隣接ノード間のメッセージを確保することができる。これらの技術および規格に精通していることが仮定される。
【００５８】
したがって、例えばＨＴＴＰ  ＤＥＬＥＴＥ要求を使用して、名前空間からデータオブジェクトまたは空のデータディレクトリが削除される。バージョニングが名前空間についてイネーブルにされている場合、この方法は、データオブジェクトの最新のバージョンを削除し、またはこの方法は、オブジェクトの全てのバージョンをパージすることができる。データアカウントにコンプライアンス許可がイネーブルにされている場合、この方法は、前述のように、保存されているオブジェクトを特権的削除または特権的パージすることができる。ＨＴＴＰ  ＤＥＬＥＴＥ要求は、全てのバージョンを削除するかどうか（オブジェクトがバージョニングされている場合に）を制御する「パージ」（真／偽）、保存されているオブジェクトの特権的削除か特権的パージかを制御する「特権的」（真／偽）、真に設定される（特権的ならば）と共にＨＴＴＰ４００エラーを提供する（特権的でないならば）「理由」など、１組のメタデータパラメータをサポートすることが好ましい。
【００５９】
ＵＩを、クラスタおよびテナントに焦点を合わせた各部分に区分化することにより、異なる人々がクラスタおよびテナント管理を実施することができる。これにより、クラスタ管理ビューとテナント管理ビューとの間のプライバシーによって、クラスタを「破壊」するかもしれないハードウェア詳細または他の詳細へのアクセスをテナントが有さないことが保証され、テナントデータのプライバシーが保護されることが保証される。
【００６０】
本明細書に述べた主題は、多くの利点をもたらす。述べた名前空間手法を使用して、エンティティ（アーカイブを運営する企業など）が、そのデータをより容易に分離および管理することができる。この手法により、管理者は、総クラスタデータセットの選択されたサブセットに対してクラスタ操作を実施することができ、また、計測操作（例えば容量報告）をより細かい粒度で実施する能力も可能になる。増加し続ける（例えばペタバイト規模の）データを他の方法で管理することは困難であろうが、述べたようにしてクラスタを区分化できることにより、操作、管理、および監督上の著しい効率がもたらされる。
【００６１】
述べた主題により、異なる管理者が、クラスタおよびテナント管理を実施することができ、この２つのエリア間を通過する情報を最小限に抑えることができる。
【００６２】
この主題は、どんな特定のタイプの使用ケースにも限定されない。典型的な使用環境は企業だが、この技法は、ストレージサービスプロバイダ、または、ストレージクラウドを運営するエンティティによって実施することができる。
【００６３】
本明細書に述べた技法は、テナント（ＴＬＴなど）に関連するユーザが、前述のように作成および管理されるアクセス特権を有するものだが、この技法は、固定コンテンツのためのアーカイブクラスタ以外において拡張および使用することもできる。したがって例えば、これらの技法はまた、ストレージ管理システムのための標準的な可視化手法のコンテキストで実施することもできる。
【００６４】
以上、本発明のいくつかの実施形態によって実施される特定の順序の動作を述べたが、このような順序は例であり、代替実施形態では、これらの動作を異なる順序で実施すること、いくつかの動作を結合すること、いくつかの動作を重ねることなどもできることを理解されたい。本明細書において所与の実施形態を参照する場合、これは、述べる実施形態が特定の特徴、構造、または特性を含むことがあるが、あらゆる実施形態が必ずしもこれらの特定の特徴、構造、または特性を含むとは限らないことを示す。
【００６５】
本発明を方法またはプロセスのコンテキストで述べたが、本発明は、本明細書の動作を実施するための装置にも関する。この装置は、必要とされる目的のために特に構築されてもよく、または、コンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ化もしくは再構成される汎用コンピュータを備えてもよい。このようなコンピュータプログラムは、コンピュータ可読記憶媒体に記憶することができ、コンピュータ可読記憶媒体は、以下のものに限定されないが、光学ディスクやＣＤ−ＲＯＭや光磁気ディスクを含めた任意のタイプのディスク、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気もしくは光学カード、または、電子的命令を記憶するのに適した任意のタイプの媒体などであり、これらはそれぞれコンピュータシステムバスに結合される。
【００６６】
システムの所与のコンポーネントについて別々に述べたが、これらの機能のいくつかを所与の命令、プログラムシーケンス、コード部分などにおいて結合または共有できることは、当業者なら理解するであろう。
【００６７】
本明細書において、単語「位置」は、必ずしも「地理的」位置に限定されない。クラスタは通常は地理的に離れているが、これは要件ではない。プライマリクラスタが、都市のあるデータセンタ中に位置し、レプリカクラスタが、同じセンタの別のデータセンタ中に位置する場合がある。この２つのクラスタはまた、単一のデータセンタ内の異なる位置にある場合もある。
【００６８】
「固定コンテンツ」のためのアーカイブのコンテキストで本発明を述べたが、これもまた限定ではない。本明細書に述べた技法は、コンテンツに対する付加タイプおよび置換タイプの修正を可能にするストレージシステムにも等しく適用することができる。
【００６９】
本発明について述べてきたが、次に以下のとおり特許請求する。
【図１】
0005433085.tif 000002
【図２】
0005433085.tif 000003
【図３】
0005433085.tif 000004
【図４】
0005433085.tif 000005
【図５】
0005433085.tif 000006
【図６】
0005433085.tif 000007
【図７】
0005433085.tif 000008
【図８】
0005433085.tif 000009
【図９】
0005433085.tif 000010
【図１０】
0005433085.tif 000011
【図１１】
0005433085.tif 000012
【図１２】
0005433085.tif 000013
【図１３】
0005433085.tif 000014