JP2012027933A

JP2012027933A - 独立ノード冗長アレイに対するポリシーに基づく管理

Info

Publication number: JP2012027933A
Application number: JP2011203548A
Authority: JP
Inventors: Rodriguez Andres; ロドリゲス，アンドレス; A Orenstein Jack; オレンステイン，ジャック，エイ; M Shaw David; ショウ，デイビッド，エム; Benjamin K D Bernard; バーナード，ベンジャミン，ケイ，ディー
Original assignee: Archivas Inc
Current assignee: Hitachi Vantara LLC
Priority date: 2003-10-27
Filing date: 2011-09-16
Publication date: 2012-02-09
Anticipated expiration: 2024-10-27
Also published as: CA2543746A1; JP5685169B2; US20100138384A1; EP1678645B1; AU2004286660A1; US20050120025A1; US8165996B2; US8954406B2; US20120246126A1; US20140181055A1; EP1678645A2; EP1678645A4; WO2005043323A2; US7657586B2; US7155466B2; AU2004286660B2; CA2543746C; US20070094316A1; WO2005043323A3; JP2007511820A

Abstract

【課題】独立ノード冗長アレイに対するポリシーに基づく管理システムを提供する。
【解決手段】アーカイブクラスタアプリケーションが独立ノードの冗長アレイにおいて分散態様で実行される。所与のノードが大量のデータを記憶している一方、アーカイブファイルへのアクセスを可能にするデータリポジトリとして機能する。互いに対称関係にあるそれぞれのノードは一連のソフトウェアプロセスを有する。リクエストマネジャーはノードに対するデータリクエストを管理し、ストレージマネジャーはこのノードと連携するディスクからのデータ読み出し/書込み機能を管理し、メタデータマネジャーは分散データベースにまたがるメタデータのトランザクション及びリカバリを容易にする。ポリシーマネジャーはクラスタ内の「アーカイブオブジェクト」の動作を決定するポリシーを実行する。アーカイブクラスタアプリケーションはオブジェクトに基づくストレージを提供する。
【選択図】図１

Description

本願は、２００３年１０月２７日付出願第６０/５１４，７６６号に基づく優先権を主張する。

本発明は、分散型コンピュータネットワークにおける可用性、信頼性及び持続性の高いデータ保存技術に係わる。

関連技術の説明

従来のテープまたは光メモリに取って代わる、またはこれを補足する、高度の可用性、信頼性及び持続性を備えた「固定コンテンツ」のアーカイバルメモリに対する需要が高まっている。「固定コンテンツ」とは参照またはその他の目的で不変の状態で保管されることが期待されるあらゆるタイプのディジタル情報を意味する。このような固定内容の例としては、特に、電子メール、文献、診断用画像、検査画像、音声記録、フィルム、ビデオなどが挙げられる。従来の独立ノード冗長アレイ（The Redundant Array of Independent
Nodes-“ＲＡＩＮ”）記憶方式は、このような固定コンテンツ情報資産を記憶するための大容量オンライン・アーカイブを作成するための推薦アーキテクチュアとして登場した。必要に応じてクラスタにノードを加えたり除外したりすることによって、ＲＡＩＮ型アーキテクチュアは記憶クラスタを１つまたは２つ以上のノードの故障から隔離することができる。複数のノードにデータを複製することによって、ＲＡＩＮ型のアーカイブはノードの故障または欠損を自動的に補償することができる。通常、ＲＡＩＮ型システムは閉システム内の同一コンポーネントから設計されたハードウェア装置として広く供給される。

アーカイブ・インフラストラクチャの技術的陳腐化に対処することはディジタル内容を保存する上で最も重要な問題である。技術の変化が急速であるだけに、テープや光ディスクを読み取る装置として現在普及している装置が今後１０年間利用できるかどうかは疑問である。陳腐化は、例えば、ファイルのオリジナル・フォーマット、ファイルを書き込んだアプリケーション、内容が記録された媒体など、種々のレベルにおいて現れる。最新の技術に対応でき、しかも妥当なコストでオンラインアクセスが可能な大規模なアーカイブを構築することは一見したところ不可能であるかに思える。アーカイブは記憶するデータの全ライフサイクルを扱わねばならないから、問題は深刻である。保存期間が極めて長いアーカイブなら、時間の経過とともに大量のデータを蓄積することができる。従って、アーカイブシステムは円滑に、例えば、数テラバイトから数ぺタバイトへ成長可能でなければならず、高度の可用性を提供し、データ損失を回避し、容易に管理できるものでなければならない。

従来技術は上記の問題に適切に対処しきれていない。特に、大容量アーカイブシステムの構築にはエラーが付き物であることは周知である。データベース、ネットワークの形成、オペレーティングシステム、保管システム及びウェブサーバーはいずれもそれらを運用するのに豊富なスキルを有する専門家のチームを必要とする。また、記憶システム、データベース、ウェブサーバー及びオペレーティングシステムはいずれも、管理者が性能を最適化することを可能にする厖大な範囲の調整可能なパラメータを有する。さらにまた、大規模インフラストラクチャに深刻な問題が生じた場合、その診断及び解決に数週間を要することがある。アーカイブシステムは継続的に利用可能でなければならないから、管理者は進行中のサービスを中断することなく、故障機器を排除、取替えする能力を備える必要がある。最後に、種々のセキュリティーシステムが存在するにもかかわらず、多くの場合、管理者は如何にしてアーカイブを悪意の攻撃または偶発的な損傷から守るかを自身で判
断しなければならない。

本発明は上記及びその他の問題を解決しようとするものである。

本発明はＲＡＩＮモデルに基づく低コスト且つ拡大縮小可能な、ディスク使用のアーカイブデータ保存装置を提供する。本発明を利用することにより、企業や組織は固定コンテンツ情報を恒久的に保存することができる。このシステムは厖大なディジタルアーカイブの構築及び維持に伴う煩雑さを軽減するように構成されている。管理者はその日の作業においてポリシーを設定しさえすればよいという意味で、このシステムの自律的な管理を可能にする。豊富なメタデータ管理レイヤーとフレキシブルなポリシープロセッサとによりこのようなポリシーに従った管理が可能になる。ポリシールールを規定することによって、アーカイブ管理者はシステムの動作と、システムによるファイル管理方法を決定する。即ち、ユーザーは例えば、ドメイン毎のポリシーに従いながら、貴重なデータの長期保存に必要なメタデータ抽出、データ暗号化、データ圧縮、データ複製を行うプロセスを確定することができる。

１つの実施態様として、本発明は独立ノードの冗長アレイ、好ましくはリナックスＯＳ搭載サーバーとして実現される。但し、それぞれのマシーンが同じハードウェアを有することは必要条件ではない。ノードはアーカイブオブジェクトを管理するネットワークベースのアプリケーションをサポートする。システムは自律的に、即ち、実質的には自己制御し、手動による介入から機能的に独立に管理される。本発明の特徴として、システムは高レベルのポリシーに規定されて自動的に（または概ね自動的に）自己構成する。このことは、新技術が出現しても進化できるシステムにとって自己構成、自己回復及び自己最適化は不可欠であることから、ディジタル資産を長期に亘って管理する上で極めて有益である。

本発明では、独立ノードの冗長アレイにわたり分散的にアーカイブクラスタプリケーションが実行される。このアプリケーションにより、アーカイブデータベースを多数のノードにわたって分散させ、複製することができる。図示実施例の場合、それぞれのノードが完全なアーカイブクラスタプリケーションを実行することが好ましい。即ち、それぞれのノードは多量の（例えば、テラバイトの）データを記憶するデータリポジトリを提供するとともに、アーカイブファイルへのアクセスを可能にするポータルとして働く。実行時オペレーション及びデータ（及びメタデータ）の物理的記憶はクラスタのノード間で分散されるから、容量が増大する過程でも高度の信頼性と性能が保証される。１つのノードが故障しても、クラスタが処理を他のノードに振り向けることにより対応するから、アーカイブクラスタプリケーションは常にアーカイブデータを利用することができる。

より具体的な特徴として、それぞれのノードは同じソフトウェアプロセスセット、例えば、リクエストマネジャー、ストレージマネジャー、メタデータマネジャー、ポリシーマネジャーなどを有する。従って、アーカイブクラスタプリケーション自体に関して、それぞれのノードは他のノードと対称関係にあると考えることができる。リクエストマネジャーはノードに対するデータ（即ち、ファイルデータ）リクエストを管理し、ストレージマネジャーはこのノードと連携するディスクからのデータ読取り/書込み機能を管理し、メタデータマネジャーは分散するデータベースに亘ってメタデータのトランザクション及び復元を容易にする。ポリシーマネジャーは、「アーカイブオブジェクト」のクラスタ内の動作を決定するオペレーションである１つまたは２つ以上のポリシーを実行する。本発明によると、アーカイブクラスタプリケーションはオブジェクトベースで保存を行う。このアプリケーションはメタデータ及びポリシーを生アーカイブデータと恒久的に連携させて、全体でアーカイブオブジェクトを構成させることが好ましい。オブジェクトポリシーが
アーカイブにおけるオブジェクトの動作を決定する。結果として、アーカイブはクライアントアプリケーションとは関係なく自己管理し、すべてのオブジェクトポリシーが有効となるように自動的に作用する。

代表的な実施態様では、アプリケーションが固定コンテンツファイルシステム（ＦＣＦＳ）にソースファイルを書き込むと、自動的に固定コンテンツファイルデータが確定される。一旦ファイルが記憶されたら、変更不能であることが好ましい。また、保持期間が切れるまでは、ファイルが消去不能であることが好ましい。メタデータは著者や作成日のようなアーカイブオブジェクトを同定する情報である。本発明では、メタデータがポリシー設定、例えば、保持期間やファイル保護をも含み、これらはアーカイブオブジェクトのポリシーに関するパラメータとして機能する。ポリシーは所与のポリシーマネジャーによって実行されるオペレーションであり、データがアーカイブに記憶される期間であるデータのライフサイクル中のアーカイブオブジェクトの動作を決定する。ポリシーはオブジェクトのメタデータからそれらのパラメータを得る。それぞれのアーカイブオブジェクトはそれ自体のポリシーをカプセル化しているから、アーカイブについてのそれ自体の動作、例えば、その内容が真正であるかどうか、またはその保持期間が未だ有効であるかどうかはアーカイブオブジェクトにかかっている。

本発明の主な特徴の幾つかの概略を以上に述べたが、これらの特徴はあくまでも説明の便宜上のものである。ここに開示する発明を上記とは異なる態様で実施するか、または後述するような変更を加えることによって他の多くの有益な成果を得ることができる。

図１は本発明の実施例である固定コンテンツストレージアーカイブの簡略化したブロックダイヤグラムである。図２はそれぞれが互いに対称関係にあり、本発明のアーカイブクラスタ（ＡｒＣ）アプリケーションをサポートする独立ノード冗長アレイの簡略図である。図３は所与のノードにおいて実行されるアーカイブクラスタアプリケーションの種々のコンポーネントの詳細図である。図４は外部アプリケーションからアーカイブへ所与のファイルが入力される態様を示す簡略図である。図５は所与のノードが故障した際にクラスタのバランスを取り戻す態様を示す簡略図である。図６は所与のノードにおける管理コンソールから得られるアーカイブクラスタページの表示内容を示す図である。

本発明はディスクを使用する拡大縮小可能なアーカイブデータ保存装置として実施することが好ましく、独立ノードの冗長アレイに基づくシステムアーキテクチュアとして実施することがより好ましい。ノードは異なるハードウェアから成り、従って、「異質」であると見做すことができる。これに反して、それぞれのノードにおいてサポートされるアーカイブクラスタアプリケーション（及び、場合によっては、アプリケーションを実行するＯＳ）は同じである。即ち、それぞれのノードにおける（ＯＳを含む）ソフトウェアスタックは対称的であるのに対して、ハードウェアは異質である。図１に示すように、本発明を利用すれば、企業は多様なタイプの固定コンテンツ情報、例えば、文献、電子メール、衛星画像、診断画像、検査画像、録音記録、ビデオなどを恒久的に保存することができる。上記した幾つかのタイプは説明のための例に過ぎないことはいうまでもない。独立サーバーまたはいわゆる記憶ノードにおいてデータを複製することによって高度の可用性が得られる。それぞれのノードは他のノードと対称関係にあることが好ましい。好ましいくは任意所与のノードがすべての機能を果すことができるため、いずれか１つのノードが故障
してもアーカイブの可用性には殆ど影響しない。

代表的な実施態様では、本発明がアーカイブクラスタ（ＡｒＣ）アプリケーションとも呼称される分散型ソフトウェアアプリケーションとして実現される。このアプリケーションはディジタル資産を捕捉、保存、管理、及び検索する。図２に示す実施例では、個々のアーカイブの物理的境界をここではクラスタと呼称する。通常、クラスタは単一の装置ではなく、装置の集合である。上述したように、これらの装置は同質であっても異質であってもよい。典型的な装置はリナックスのようなオペレーティングシステムを実行するコンピュータまたはマシーンである。市販のハードウェアをホストとするリナックスベースのシステムのクラスタは数個のストレージノードサーバーから数千テラバイトのデータを記憶する多数のノードにまで拡張可能なアーカイブを提供する。このアーキテクチュアによって、記憶容量を、組織の増大するアーカイブ需要に合せて増大させることができる。アーカイブが常に装置の故障から保護されるようにクラスタ全体に亘ってデータを複製することが好ましい。ディスクまたはノードが故障した場合、クラスタは同じデータの複製を保持しているこのクラスタ中の他のノードへ自動的に障害迂回する。

図示のクラスタは好ましくは大別して下記のコンポーネントから成る：ノード２０２、１対のネットワークスイッチ２０４、電力分配装置（ＰＤＵ）２０６、及び無停電電源（ＵＰＳ）２０８。ノード２０２は通常、市販の１つまたは２つ以上のサーバーより成り、ＣＰＵ（例えば、インテルｘ８６）、適当なランダムアクセスメモリ（ＲＡＭ）、１つまたは２つ以上のハードドライブ（例えば、標準的なＩＤＥ/ＳＡＴＡ、ＳＣＳＩなど）、及び２つまたは３つ以上のネットワークインターフェースカード（ＮＩＣ）を含む。典型的なノードは２．４ＧＨｚチップ、５１２ＭＢのＲＡＭ、及び６つの２００ＧＢハードドライブを含む２Ｕラックマウント方式ユニットである。但し、これは１例に過ぎない。ネットワークスイッチ２０４は通常、ノード間でピア・ツー・ピア交信を可能にする内部スイッチ２０５と、クラスタの外部からそれぞれのノードへのアクセスを可能にする外部スイッチ２０７を含む。それぞれのスイッチはクラスタ中のすべてのノードを扱うのに充分なポートを必要とする。この必要性を満たすには、イーサネットまたはＧｉｇＥを使用すればよい。ＰＤＵ２０６はすべてのノード及びスイッチへの給電に使用され、ＵＰＳ２０８はすべてのノード及びスイッチを保護するのに使用される。多くの場合、クラスタは公衆インターネット、企業イントラネット、またはその他のワイドエリアまたはローカルエリアネットワークなどのネットワークに接続可能である。図示例の場合、クラスタは企業環境内で実現される。クラスタには、例えば、サイトの企業のドメインネームシステム（ＤＮＳ）のネームサーバーをナビゲーションすることによって到達することができる。即ち、例えば、クラスタのドメインが既存のドメインの新しいサブドメインである場合が考えられる。代表例では、このサブドメインが企業ＤＮＳサーバーにおいてクラスタ自体のネームサーバーに委託される。エンドユーザーは公知のインターフェースまたはアクセスツールを利用してクラスタにアクセスする。クラスタへのアクセスは、例えば、ＡＰＩを介して、または公知または新規に開発されたアクセス方法、サービス、プログラムまたはツールを介して、ＩＰベースのプロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、ウェブサービスなどを利用することでよって行うことができる。

詳しくは後述するように、クライエントアプリケーションは１つまたは２つ以上のタイプの外部ゲートウェイ、例えば、標準型ＵＮＩＸファイルプロトコル、またはＨＴＴＰ
ＡＰＩなどを介してクラスタにアクセスする。ゲートウェイは管理コンソールを介して独立に機能可能化または機能抑止されることが好ましい。アーカイブは、オプションとして標準的なＵＮＩＸファイルプロトコル利用設備下に作用する仮想ファイルシステムを介して露出されることが好ましい。例えば、ＮＦＳ、ＦＴＰ、ＳＭＢ/ＣＩＦＳなどがある。
標準的なＴＣＰ/ＩＰアドレスを介してアーカイブに正しくアクセスすると、ファイルプ
ロトコルは標準的なＵＮＩＸオペレーティングシステム上におけるように動作する。尚、
「/」はクラスタのルートディレクトリである。

好ましい実施態様では、アーカイブクラスタアプリケーションは（例えば、イーサネットを介して）１つのクラスタとしてネットワークを形成する独立ノード冗長アレイ（Ｈ−ＲＡＩＮ）上を走る。所与のノードのハードウェアは異質であってもよい。但し、可用性を最大にするためには、それぞれのノードが、図３に示すように、幾つかの実行時コンポーネントから成る分散アプリケーションの全インスタンス３００を実行することが好ましい。即ち、ハードウェアは異質であっても、（少なくとも本発明に関する限り）ノード上のソフトウェアスタックは同じである。これらのソフトウェアコンポーネントはゲートウェイプロトコルレイヤー３０２、アクセスレイヤー３０４、ファイルトランザクション及び管理レイヤー３０６、及びコアコンポーネントレイヤー３０８から成る。「レイヤー」と呼称するのは飽くまでも説明の便宜上であって、当業者には周知のように、もっと有意義な方法でその機能を特徴付けることができる。レイヤー（またはこれに含まれるコンポーネン）の１つまたは２つ以上が一体化されていてもよい。幾つかのコンポーネントを複数のレイヤーで共用させることもできる。

ゲートウェイプロトコルレイヤー３０２におけるゲートウェイプロトコルは既存のアプリケーションに透過性を与える。特に、ゲートウェイはネイティブファイルサービス、例えば、ＮＦＳ３１０、ＳＭＢ/ＣＩＦＳ３１２、及びウェブサービスを提供することによってカスタムアプリケーションを形成する。ＨＴＴＰサポート３１４も提供される。アクセスレイヤー３０４はアーカイブへのアクセスを可能にする。特に、本発明では、固定コンテンツファイルシステム（ＦＣＦＳ）３１６がネイティブファイルシステムをエミュレートすることによってアーカイブオブジェクトへの完全なアクセスを可能にする。ＦＣＦＳはあたかも普通のファイルであるかのようにアプリケーションを直接アーカイブ内容にアクセスさせる。好ましくは、アーカイブのコンテンツを元のフォーマットにレンダリングする一方、メタデータをＸＭＬファイルとして表現する。ＦＣＦＳ３１６はディレクトリ、パーミッション及びルーチンのファイルレベルのコールを型通りに表示するから、管理者は慣れた態様で固定コンテンツデータを提供することができる。ファイルアクセスコールはユーザースペースデーモンによってインターセプトされ、（レイヤー３０８における）該当のコアコンポーネントに転送され、このコアコンポーネントが呼出しアプリケーションに対する適切な表示を動的に形成する。詳しくは後述するように、ＦＣＦＳコールをアーカイブポリシーによって制約することによって自律的なアーカイブ管理を容易にすることが好ましい。従って、１例として、管理者またはアプリケーションは（所与のポリシーである）保持期間が未だ有効なアーカイブオブジェクトを消去することはできない。

アクセスレイヤー３０４はウェブユーザーインターフェース（ＵＩ）３１８及びＳＮＭＰゲートウェイ３２０をも含むことが好ましい。ウェブユーザーインターフェース３１８はファイルのトランザクション/管理レイヤー３０６における管理エンジン３２２への対
話型アクセスを可能にする管理コンソールとして実現することが好ましい。管理コンソール３１８はアーカイブオブジェクト及び個別ノードを含むアーカイブを動的に表示する、パスワードで保護されたウェブベースのＧＵＩであることが好ましい。ＳＮＭＰゲートウェイ３２０は管理エンジン３２２へのストレージ管理アプリケーションのアクセスを容易にし、クラスタの動作を確実にモニターし且つ制御することを可能にする。管理エンジンはシステム及びポリシーイベントを含むクラスタの動作をモニターする。ファイルのトランザクション/管理レイヤー３０６はリクエストマネジャープロセス３２４をも含む。リクエストマネジャー３２４は（アクセスレイヤー３０４を介しての）外界からのすべてのリクエストと、コアコンポーネントレイヤー３０８におけるポリシーマネジャー３２６からの内部リクエストを統合する。ポリシーマネジャー３２６の動作については詳しく後述する。

ポリシーマネジャー３２６のほかに，コアコンポーネントはメタデータマネジャー３２８、及びストレージマネジャー３３０の１つまたは２つ以上のインスタンスをも含む。メタデータマネジャー３２８はそれぞれのノードにインストールすることが好ましい。全体として、クラスタにおけるメタデータマネジャーはすべてのアーカイブオブジェクトを管理する分散データベースとして作用する。所与のノードにおいて、メタデータマネジャー３２８はアーカイブオブジェクトのサブセットを管理し、好ましくはそれぞれのオブジェクトが外部ファイル（「ＥＦ」、記憶させるためアーカイブに入力されるデータ）とアーカイブデータが物理的に配置されている内部ファイルセット（それぞれが「ＩＦ」)との間に位置する。同じメタデータマネジャーが他のノードから複製されたアーカイブオブジェクトのセットをも管理する。従って、それぞれの外部ファイルの現状を幾つかのノードにおける複数のメタデータマネジャーが常に利用することができる。ノードに故障が発生した場合、他のノードにおけるメタデータマネジャーがそれまで故障ノードによって管理されていたデータに直ちにアクセスする。ストレージマネジャー３３０は分散アプリケーションにおける他のすべてのコンポーネントが利用できるファイルシステムレイヤーを提供する。好ましくはこのファイルシステムレイヤーがノードのローカルファイルシステムにデータオブジェクトを記憶させる。所与のノードにおけるそれぞれのドライブは好ましくはそれ自体のストレージマネジャーを有する。これにより、ノードは個々のドライブを除去してスループットを最適化することができる。ストレージマネジャー３３０はシステム情報、データに関する完全性チェックをも提供するとともに、ローカル構造に直接アクセスすることもできる。

図３に示すように、クラスタは通信ミドルウェアレイヤー３３２及びＤＮＳマネジャー３３４を介して内部及び外部通信を管理する。インフラストラクチャ３３２はアーカイブコンポーネント間の通信を可能にする効率的で、しかも信頼度の高いメッセージに基づくミドルウェアレイヤーである。図示例では、このレイヤーがマルチキャスト/ポイント・
ツー・ポイント通信を支援する。ＤＮＳはすべてのノードを企業サーバーに接続する分散ネームサービスを実行する。ＤＮＳマネジャーはリクエスト負荷がすべてのノードにおいて均等になるように作用して、クラスタのスループット及び可用性を最大限に維持することが好ましい。

図示例において、ＡｒＣアプリケーションは、例えば、ＲｅｄＨａｔＬｉｎｕｘ９．０のようなベースオペレーティングシステム３３６で実行される。通信ミドルウェアとしては、Ｓｐｒｅａｄグループ通信またはその他の分散型通信機構に基づくものを使用できる。周知のように、Ｓｐｒｅａｄは高性能のメッセージサービスを可能にするツールキットであり、外部または内部ネットワークに発生する障害に対して柔軟に対応することができる。Ｓｐｒｅａｄは分散アプリケーションのための一体化されたメッセージバスとして機能し、高度に調整されたアプリケーションレベルのマルチキャスト通信及びグループ通信を可能にする。その他のコンポーネントとして、固定内容ファイルシステム（ＦＣＦＳ）３１６のために使用できるＦＵＳＥ（ＵＳＥｒｓｐａｃｅにおけるファイルシステム）が挙げられる。ＮＦＳゲートウェイ３１０は標準的なｎｆｓｄＬｉｎｕｘＫｅｒｎｅｌ
ＮＦＳドライバーのユーザースペース版であるＵｎｆｓｄによって実現することができる。それぞれのノードにおけるデータベースは、例えば、オブジェクト関連データベース管理システム（ＯＲＤＢＭＳ）であるＰｏｓｔｇｒｅＳＱＬによって実現することができる。ノードはＪａｖａＨＴＴＰサーバー及びサーブレットコンテナであるＪｅｔｔｙのようなウェブサーバーを含む。但し、以上に挙げた機構はあくまでも説明の便宜上列記したものであり、本発明がこれらの機構に制限されるものではない。

所与のノードにおけるストレージマネジャー３３０は物理的記憶装置を管理する。それぞれのストレージマネジャーインスタンスは並列アルゴリズムに従ってすべてのファイルが配置されている単一のルートディレクトリを担当することが好ましい。同時に複数のス
トレージマネジャーインスタンスが１つのノードにおいて機能し、それぞれのインスタンスがシステム内の異なる物理的ディスクを表す。ストレージマネジャーがドライブを取除き、システムの残り部分からのインターフェース技術が利用される。ファイルへの書込みを要求されると、ストレージマネジャーは対応の表示を行うため、フルパス及びフルネームを形成する。代表的な実施態様では、ストレージマネジャーに記憶させるべきそれぞれのオブジェクトが記憶させるべき生データの形で受信され、記憶させるファイルにストレージマネジャーが自らのメタデータを加えることにより、異なるタイプの情報をトラックできるようにする。例えば、このメタデータは以下に列記する内容を含む：ＥＦ長さ（外部ファイルの長さ（バイト））、ＩＦセグメントサイズ（内部ファイルのこの部分のサイズ）、ＥＦ保護表示（ＥＦ保護モード）、ＩＦ保護任務（この内部ファイルの表示）、ＥＦ作成時刻印(外部ファイル時刻印）、ハッシュ（ハッシュタイプを含む、書込み時（ＰＵＴ）における内部ファイルのハッシュ）及びＥＦファイルネーム（外部ファイルのファイルネーム）。内部ファイルのデータとともにこの追加メタデータを記憶させることによって、保護効果のレベルがさらに向上する。特に、スキャベンジングは、内部ファイルに記憶されているメタデータから、データベース中に外部ファイルを作成することを可能にする。その他のポリシーは内部ファイルに対して内部ファイルハッシュを有効化することにより、内部ファイルがそのままであることを有効化することができる。基本親情報に対するデータ探索を回避することによって最適化が可能になる。

上述したように、内部ファイルはアーカイブオブジェクト中のオリジナル「ファイル」の一部を表す「大量の」データであることが好ましく、ストライピング及び保護ブロック達成するため異なるディスクに配置することが好ましい。通常、それぞれのアーカイブオブジェクト毎に１つのファイル記述項がメタデータマネジャーに存在し、それぞれの外部ファイル記述項ごとに多数の内部ファイル記述項が存在する。多くの場合、内部ファイルのレイアウトはシステムに応じて異なる。実施態様によっては、ディスク上におけるこのデータの物理的フォーマットが一連の可変長記録の形で記憶される。

ファイルを記憶させると、ストレージマネジャーはファイルが媒体に書き込まれたことを保証する。ストレージマネジャーはまた、システムの残りの部分からの、種々のサービスに対するリクエストに応答する。これらのサービス及びその動作は以下の動作を含む：Ｅｘｉｓｔｓ−内部ファイルが存在するかどうかをチェック；Ｄｅｌｅｔｅ−内部ファイルを消去する；Ｗｉｐｅ−内部ファイルを消去し、書き直す（確実な消去）；Ｍｅｔａｄａｔａ−内部ファイルからストレージマネジャーを得る；Ｈａｓｈ−内部ファイルに対応する内部ファイルハッシュ（内部ファイル・メタデータを含む）を回復する；Ｌｉｓｔａｌｌ−このストレージマネジャーに対応するすべての内部ファイルのリストを回復する；及びＤｅｌｅｔｅａｌｌ−このストレージマネジャーにおけるすべての内部ファイルを消去する。

リクエストマネジャー３２４は、システム内の他のコンポーネントと相互作用することによってアーカイブ作用を行うのに必要な一連のオペレーションを実行する。リクエストマネジャーは多様な同時作用を可能にし、途中に故障が発生したトランザクション処理を無効化することができ、実行に長時間を要する可能性があるトランザクションをサポートする。リクエストマネジャーはまた、アーカイブにおける読取り/書込みオペレーション
が適正に行われ、リクエストがすべて常に既知の状態にあることを保証する。さらにまた、所与のクライエントリクエストを満たすように、複数ノードにおいて同時に行われる複数の読取り/書込みオペレーションを整合させるべくトランザクション制御を可能にする。また、リクエストマネジャーは最近使用されたファイルに対応するメタデータマネジャー記述項をキャッシュし、セッション及びデータブロックのためのバッファリングを提供する。

クラスタの最も重要な機能はディスクに無制限の数のファイルを確実に記憶させることにある。何らかの理由でアクセス不能であるか、または利用不能であれば、所与のクラスタを「信頼できない」と考えられる。本発明の目的はこのような信頼できないノードを回収して信頼できる、可用性の高いストレージを作成することにある。記憶させる必要がある情報は２つのタイプに大別される。即ち、ファイル自体とファイルに関するメタデータである。

図４はファイルをシステムに入力する方法を示す。ステップ１において、独自のキーとともにファイルが幾つかのサポートされているゲートウェイの１つを介してアーカイブに入力される。ファイルを保護するためには、ステップ２に図示するように、幾つかのスキーム：ファイル二重化、回復ストライプを利用してファイル内容を複数ノードに分散させることにより消失ストライプを再生させるＲＡＩＤ-５のようなスキーム、及び複数の回復ストライプを利用して同時的に発生するノードの故障がシステム全体の故障に至らないようにする（例えば、Ｒａｂｉｎ情報分散アルゴリズムまたはＩＤＡのような）ＲＡＩＤ-５スキームのバリエーションのうちの１つを利用すればよい。ステップ３に示すように、キー値情報及びその他のシステムメタデータをメタデータマネジャーに書き込む。次いで、ステップ４に示すように、メタデータマネジャーが分散データベースを更新する。こうしてプロセスが完了する。

信頼性の高いアーキテクチャは他の目的にも貢献する。ストレージノードをグレードアップする場合、他のノードに冗長ファイルを配置しているのと同じメタデータを利用することによって新しいノードを配置することができる。これを４つのノード５０２、５０４、５０６及び５０８を示す図５に基づいて説明する。図５から明らかなように、ノード２が故障すると、メタデータがクラスタを再び平衡させるのに必要なあらゆる情報を提供する。新しいノード５１０が加わると、クラスタはこの容量を平衡回復プロセスの一部として利用する。平衡回復の方法及びタイミングを判断するプロセスはルールベースポリシーによって与えられる。このシナリオにおいては、図５に示すように、システムは下記のステップを実行する。既存ノード５０４をオフライン処理する。これに代わるノードとして新しいノード５１０が同定される。次いで、該当のメタデータが複製すべきファイル５１０及びこれらのファイルの位置を同定する。次いでリクエストマネジャーは複製されるファイルを新しいノード５１０へ誘導する。次いで、リクエストマネジャーが位置情報とともに更新される。

一般に、メタデータの量と必要な同時性に応じて異なるが、所与のノードと連携する所与数のメタデータマネジャーが存在する。それぞれのメタデータマネジャーはそれぞれのメタデータサブセットを担当する。（メタデータオブジェクトの形態の）メタデータを、ハッシュ処理を利用することで複数のメタデータマネジャーに分散させることが好ましい。それぞれのメタデータマネジャーは１つまたは２つ以上の範囲のハッシュ値を担当する。好ましくは、それぞれのメタデータオブジェクトが名前を有し、このオブジェクトを担当するメタデータマネジャーを、名前のハッシング処理でハッシュ値を求めることによって決定する。所与のアプリケーションがメタデータオブジェクトを作成、検索または更新しなければならない場合、このアプリケーションは名前をハッシュ処理することによってハッシュ値を求め、次いで、メタデータオブジェクトのハッシュ値を含む範囲４１２を担当するメタデータマネジャーに対してリクエストを送信する。１つのメタデータマネジャーが直ちに他の領域の担当を引受けることができるようにメタデータ更新を管理することによって高い可用性が得られる。メタデータオブジェクトを更新する場合、担当のメタデータマネジャーに更新指令が送信され、メタデータマネジャーがこの更新指令をそのローカルデータベースに入力する。更新スル前に、アットランダムに選択された１組の他のメタデータマネジャーに更新指令が送信される。何らかの理由で１つのメタデータマネジャーが利用不能である場合、別のメタデータマネジャーが問題の領域を制御することができ
、クラスタ全体に分散させたメタデータのバックアップコピーを利用することによってこの領域に対するリクエストを取扱うことができる。

本発明のＲＡＩＮアーキテクチャの利点は、（システムを構成する）それぞれのノードが同じでなくてもよいことである。性能、容量、及び期待される信頼性において、それぞれのノードが互いに著しく異なっていてもよい。Ｈ−ＲＡＩＮシステムの設計は商用ハードウェアを使用する多数のノードを前提とする。図１は互いに異質のハードウェア・コンポーネント１００ａ‐１００ｎで構成されたＨ−ＲＡＩＮクラスタを示す。所与のシステムの実施には幾つかの戦略がある。同じ構成のノードを追加することによって記憶容量を増大させることができる。このように新しいノードを追加しても、長い目で見れば大したコスト増にはならない。アーカイブ全体のギガバイト当りの平均コストは経時的に軽減される。アーカイブの容量とコストの関連は予測可能である。高品質のハードウェアを使用する新しいノードでクラスタを拡張することによって記憶容量、性能及び信頼性を高めることができる。システムがこれらの新しいノードを活用することによってアーカイブの性能を高めることができる。例えば、ＣＰＵに負担がかかるフィルタリングオペレーションには高性能ＣＰＵとともに新しいノードを使用すればよい。このようにすれば、比較的少量の新しいハードウェアで「プット」性能をかなり向上させることができる。いずれの戦略を採用しても、ユーザーは技術的インフラストラクチャをグレードアップするとともに、アーカイブ内容を新しいノードへ透過的に移動させることができる。初期のインストレーションをそのまま生かしながら、改良を重ねることができる。ハードウェアの価格が低下すれば、その時点でユーザーはコスト当たり性能が高いストレージノードでアーカイブの性能を高めることができる。互いに異質のノードで構成されたアーキテクチャの場合、これらの選択がすべて容易になる。図５はノードをアップグレードするためのシナリオの１つを示すが、このほかにも本発明が採用できるシナリオが幾つか考えられる。

新しいノードの追加は自動的に行われることが好ましい。システムは容量の増大などのような管理上のタスクを自動化するように構成されている。例えば、ユーザーが新しいノードサーバーをクラスタに追加した後、手動干渉無しに、アプリケーションは直ちにそのノードを全体的なワークフローに投入する。代表的な実施態様では、１つのクラスタが、例えば、数百のノードを含むことができる。システムにノードを追加することによって、１つのクラスタを数千テラバイトにまで拡張することができる。

アプリケーションはデータ損失に対する保護を可能にする。或るノードが動作不能に陥ると、リクエストマネジャーが自動的にストレージオペレーションを別のノードに肩代わりさせる。分散型アプリケーションは常に所与のノードのデータをクラスタ中のいずれかのノードにおいて複製する。アーカイブの障害迂回機能により、故障ノードから別のノードへデータが透過的に移行するから、故障ノードのデータを常時利用することができる。上述したように、システム中に記憶されているすべてのファイルが、消失ファイルを自動的に再生するデータ保護スキームによって保護されることが好ましい。

ディジタルアーカイブは極めて大規模且つ長命であるから、特殊なデータ管理方式を可能にする。このシステムを管理運営するためのコストは長期のスパンで考えねばならない。アーカイブシステムが自己管理し、殆ど手動干渉を必要としなければ、著しいコスト軽減につながる。本発明は、アーカイブ中でのライフサイクルに亘ってアーカイブオブジェクトの動作を決定する自らのポリシーをそれぞれのオブジェクトがカプセル化するように構成することで上記目的を達成する。即ち、それぞれのアーカイブオブジェクトはアーカイブとともにオブジェクト自体の動作を自律する。所与のアーカイブオブジェクトに関して、アーカイブクラスタアプリケーションは下記ポリシーのいずれか１つまたは２つ以上を適用する：即ち、保護、データ確認、保持、クラスタバランス、不要情報収集、スキャベンジング、及び重複削除である。保護ポリシーはデータオブジェクトの完全性を保護す
る；即ち、例えば、ハードウェアに故障が発生すると、修理を開始する。データ確認ポリシーはファイルコンテンツがそのディジタル署名と一致することを確認する。このポリシーを、ディジタル署名の形成に使用される特定のハッシュアルゴリズムにセットすることが好ましい。保持ポリシーは保持期間が切れる前にファイルが消去されるのを防止する。保持期間が切れたら、アプリケーションによって自動的に、またはアーカイブ管理者によって積極的にデータオブジェクトを消去することができる。クラスタバランスポリシーはクラスタ中のすべてのノードにデータオブジェクトが均等に分散させるように作用する。不要情報収集ポリシーは不完全なトランザクションによって取り残されたままのファイルを排除することによってディスクスペースを再利用する。このポリシーはシステムメタデータの完全性をチェックする機能をも果たす。このポリシーは排除する前に、消去すべきデータをマーキングしなければならない期間を規定するピックアップタイムにセットすることが好ましい。スキャベンジングポリシーはメタデータの消失を防止するポリシーである。アーカイブのストレージマネジャーは内部ストレージファイル中のデータファイルのメタデータをも含む。内部ストレージファイルは必要に応じてアーカイブのスキャベンジングポリシーにアクセス可能な冗長レイヤーを提供する。重複削除ポリシーは重複しているデータオブジェクトを発見し、余分なコピーを排除することによって有効クラスタ容量を増大させる。

本発明では、クラスタが１つまたは２つ以上のタイプの自動化されたポリシーの管理下にある：即ち、保護、データ確認、保持、クラスタバランス、不要情報収集、スキャベンジング、重複削除、などである。これらのポリシーのそれぞれについて、以下に詳細を説明する。ポリシーマネジャーはシステム中のそれぞれのノードに対してポリシー管理を実施する。

システム内部において、アーカイブクラスタアプリケーションは１つまたは２つ以上のデータ保護スキームを支援する。代表的なスキームがＲＡＩＤ-１（シンプルミラーリン
グ)保護スキームである。このほか、代表的なスキームとして、情報分散アルゴリズムが
ある。管理者の観点からすれば、この支援はクラスタ全体のための単一の調整可能な保護パラメータとして露出されることが好ましい。但し、これは１例に過ぎない。即ち、代表的な実施態様では、特定の保護スキーム及び関連のパラメータに煩わされることなく、管理者はファイルをサポートするための許容可能障害点数（ＴＰＯＦ）を設定するだけでよい。アーカイブクラスタアプリケーションはそれぞれのノード内の各ディスクをモニターし、ノード及びディスクの故障を自動的に対応することができる。特定のＴＰＯＦに対応して、アプリケーションはクラスタ中のノード数に応じて（利用可能なスキームのうち）最善の保護スキームを活用する。ＲＡＩＤ-１データ保護スキームだけが利用可能である
場合、最も単純な２方向ミラーリングの場合でも、ディスク利用率は５０％に過ぎない。ミラー数が増えると、ＴＰＯＦも増大するが、ディスク利用率は低下する。例えば、３方向ミラーリングでは、ディスク利用率は３３％、４方向ミラーリングではディスク率が２５％となる。保護ポリシーはクラスタレベルにセットすることが好ましく、ファイルレベルでは利用できない。

より具体的な実施態様としては、保護ポリシーはクラスタレベルで設定され、ファイルレベルでは利用できない。クラスタレベルの初期値は変化可能であるが、クラスタに入力される新しいファイルにのみ適用される。１例として、クラスタレベルにおける初期値ＴＰＯＦは１である。保護ポリシーの実行頻度は設定可能である。初期値設定頻度は周期的であり、例えば、２４時間毎である。この場合、クラスタ中のどこかでディスクまたはノードに故障が発生すると、すべてのノードに対する保護ポリシーが自動的に起動する。

所与のノードにおけるポリシーマネジャーは以下に述べるように保護を行う。ポリマーマネジャーは実行するノードが所有するすべての外部ファイル（ＥＦ）に亘って保護ポリ
シーを反復実行する。それぞれの外部ファイル毎に、ポリシーマネジャーはすべての内部ファイル（ＩＦ）に亘って反復実行する。こうして、ＩＦが指示するファイルに到達でき、必要に応じて修理を開始することができる。

データ確認はデータの変造及び/またはサボタージュを防止する。即ち、アーカイブクラスタアプリケーションは、クラスタに挿入されるファイルがディジタル署名と一致することを確認するデータ確認ポリシーを支援する。署名はファイルの実際のコンテンツから形成するか、または実際のコンテンツの一部によって形成することが好ましい。アーカイブは、例えば、記憶されているコンテンツからこの署名を再生させ、元の署名と比較することによって記憶されているファイルコンテンツの信憑性を周期的にチェックする。データの信憑性を実証するためには署名が一致しなければならず、さもない時はアーカイブが除外すべきものとしてアーカイブ管理者に返送する。図示例においては、データ確認用のディジタル書名を、ＭＤ５アルゴリズムを使用して計算するが、（例えば、ＳＨＡ-１、ＭＤ４などのような）適当な暗号機能を利用してもよい。図示例では、アーカイブに挿入する際にファイルのＭＤ５内容ハッシュを計算する。クライエントのアプリケーションに記憶されている内容がオリジナルと同一であることを実証するには、クラスタの外部でＭＤ５ハッシュキーを計算し、これをクラスタが維持しているハッシュキーと比較すればよい。データ確認ポリシーの実行頻度を設定し、設定した実行頻度（例えば、１週間毎）を適用する。

ポリシーマネジャーは所与のノードに対して以下のようにしてデータ確認を支援する。確認の対象ノードが所有するすべての外部ファイル（ＥＦ）に亘って反復実行する。それぞれのＥＦ毎に、ディスク上のコンテンツのＭＤ５ハッシュキーを計算し、最初の書込み時に記憶された外部ファイルに対応のＭＤ５ハッシュキーと比較する。それぞれの内部ファイル（ＩＦ）毎に、ポリシーマネジャーは最初の書込み時及び必要に応じて最初の修復時に記憶された内部ファイルのＭＤ５ハッシュを比較することによってコンテンツを認証する。上述したように、ＥＦハッシュはオリジナルコンテンツから引出すことが好ましい。また、ＩＦハッシュはスキャベンジング情報とともにオリジナルコンテンツから引出すことが好ましい。

多くのデータファイルに関して、組織及び規制上の基準が課せられ、種々の期間に亘ってデータファイルを保存するよう要求している。アーカイブクラスタアプリケーションは保持期間が切れる前に、事故または悪意によるファイルの消失を防止するため、データファイルの性質に応じて保持期間を定める。例えば、ファイルが１/１/２００４に記憶され、その保持期間が２ヶ月であれば、３/１/２００４以前にファイルを消去しようとすると、エラーが返送される。３/１/２００４またはそれ以後ならば、ファイルに消去許可のフラグが付せられる。アーカイブ管理者が積極的に消去しない限り、ファイルはクラスタ内に温存される。

保持期間はミリセコンド単位で記憶させることが好ましい。例えば、保持期間を−１と設定することによって消去不能であることをファイルにマークすることもできる。保持ポリシーについては、個々のディレクトリレベルで初期値を設定することが好ましいが、ＨＴＴＰゲートウェイを使用する場合には挿入されるそれぞれのファイルにも設定することができる。一旦或るファイルに保持期間を規定したら、（利用可能なゲートウェイを介して)変更することができるが、延長する場合のみであって、短縮は許されない。或るファ
イルに関するファイルに設定される保持期間初期値が「０」ということは、そのファイルをいつでも消去できることを示唆するものである。代表的な実施態様では、所与のノードにおけるリクエストマネジャー（ＲＭ）が保持ポリシーをモニターする。但し、これは必須条件ではない。

経時的にクラスタ内の個々のノードがそのストレージ利用度の点で互いにバランスを失う可能性がある。アーカイブクラスタアプリケーションはこの容量利用度をモニターし、例えば、クラスタに新しいノードが追加されると、クラスタを平衡状態に戻すべくファイルを再配置する。クラスタバランスは調整可能なパラメータを持たないクラスタレベルのポリシーであることが好ましいが、このことは必須条件ではない。クラスタバランスはクラスタの容量利用度を平衡状態に戻す積極的なアルゴリズムではあるが、リクエストマネジャーが所与のノードとともに、データを配置すべきノードを適正に選択することによって書込み毎にこのバランスを維持するように試みることが好ましい。

不要情報収集はメタデータマネジャーにおいて論理的に消去されるとしてマーキングされたすべてのファイルを物理的に消去するのに必要である。このような記入事項が現れるのは、ファイル書込み中の失敗が原因であり、誤った書込みプロセスによってコンポーネントの一部が自動的にクリーンアップされなかったのである。不要情報収集は調整可能なパラメータを持たないクラスタレベルのポリシーであることが好ましいが、このことは必須条件ではない。不要情報収集ポリシーの実行頻度は設定可能である。1例として、初期値実行頻度は２４時
間に一度と設定することができる。

所与のノードにおけるポリシーマネジャーは下記のように不要情報収集を支援する。実行の対象であるノードが所有するすべてのメタデータに亘って反復する。それぞれの外部ファイル毎に、ポリシーマネジャーは関連する内部ファイルすべてを有することを確認する。次いで、ポリシーマネジャーは誤ってこれらの内部ファイルに挿入された残留データをクリーンアップする。

スキャベンジングは最悪のメタデータ喪失に対する安全ネットである。上述したように、（ストレージマネジャーによって）記憶させられたそれぞれの物理的ファイルは（メタデータマネジャーによって管理される)メタデータをも含む。スキャベンジングポリシーはすべてのファイルに亘って作用してそれぞれのファイルのメタデータを無傷に維持する。メタデータが欠落していることが判明すると、必要に応じて再生させる。スキャベンジングは調整可能なパラメータを持たないクラスタレベルのポリシーであることが好ましいが、このことは必須条件ではない。スキャベンジングポリシーの実行頻度は設定することができる。初期値実行頻度は２４時間に一度である。

所与のノードにおけるポリシーマネジャーは下記のようにスキャベンジングを支援する。ポリシーマネジャーの実行対象であるノードが所有するすべてのファイルに亘って反復実行する。それぞれのファイル毎に、ポリシーマネジャーはクラスタがこのファイルのための有効なメタデータを有することを認証する。必要に応じて、メタデータの修復を開始する。

上述したように、アーカイブにおけるそれぞれのノードが、図６に示すようなディスプレイインターフェースを出力する管理コンソールを支援する。図６には、アーカイブクラスタの概括ページ６００を示す。このページは、クラスタが所与の日時の状態として、完全に作動していることを示すインジケータ６０２を含む。このインジケータはその時々の動作状態に応じて色が変わる（例えば、緑色から黄色へ、黄色から赤色へ）。ポリシーステータス及びリセントイベント表６０４はポリシータブ６０６及びイベントタブ６０８を含むことが好ましい。（図示例において）支援されるポリシーのそれぞれについてカレントポリシーステータスが示されている。ノードリスト表６１０はそれぞれのノードをそのＩＤ、ステータス及びノードＩＰアドレスによって識別している。管理オペレーションを容易にするため、一連のコントロールが設けられている。具体的には、管理コンソールが下記のコントロールを含む一連のクラスタ/ノードコンポーネントコントロールを可視化
することが好ましい：ノード起動、ノード停止、ノード再起動、クラスタ起動、クラス停止、及びクラスタ再起動のコントロール。（図示例において）クラスタ中のクラスタボリューム及びトータルファイルを示すための、１つまたは２つ以上のメトリックグラフ６１２、６１４をも設ける。種々のディスプレイタブを選択することによって、管理者はその他の詳細を観察し、セットすることができる。ディスプレイタブはクラスタノードページ６１６、ゲートウェイページ６１８、システムセッティングページ６２０及びクラスタログページ６２２を含む。クラスタノードページ６１６はクラスタ中のそれぞれのノードに関して設定可能な性質を有する。ゲートウェイタブ６１８は支援されるそれぞれのゲートウェイに関する情報を表示する。それぞれのゲートウェイはゲートウェイの作用を可能にしたり不能にしたりできるとともに、１つまたは２つ以上の設定可能な性質を有する。

いうまでもなく、図６に示すディスプレイのレイアウトは１例に過ぎない。上述したように、管理コンソールはそれぞれのノードに存在するウェブ-ベースのアプリケーション
であることが好ましい。ゲートウェイからクラスタに入力される他のすべての外部リクエストと同様に、管理コンソールリクエストもＤＮＳ負荷バランサーによって選択されたノードにおいて処理される。

本発明はディジタル資産を捕捉、保存、管理及び検索するように構成されたアーカイブ管理対策を容易にする。この構成は種々の必要条件を満たす：即ち、無制限の記憶、高い信頼性、自己管理、規制との整合性、ハードウェアからの独立性、及び既存アプリケーションとの一体化の容易さである。

本発明が提案する、市販のハードウェアで実行される（例えば）Ｌｉｎｕｘのクラスタは堅牢なプラットホームと殆ど無制限のアーカイブを可能にする。このシステムは、例えば、数個のストレージノードサーバーから数千テラバイトのデータを記憶する多数のノードまで拡張することができる。この独自のアーキテクチャにより、記憶容量は組織の増大するアーカイブ需要にペースを合せて増大することができる。このシステムはファイルを絶対に喪失しないように構成されている。アーカイブが常に装置故障から保護されるようにクラスタ全体に亘ってデータを複製する。ディスクまたはノードが故障すると、クラスタは自動的に、同じデータの複製を保持しているクラスタ中の他のノードに肩代わりする。本発明は自律的な処理によってアーカイブの保存コストを軽減する。例えば、ノードがアーカイブと接合したり、アーカイブから切り離されると、システムは自動的にクラスタの負荷バランスを調整し、構成ノード全体に亘ってファイルを再分散させることによって性能を最適化する。

本発明は政府規制及び業界規制や、金融書類及び医療データのような記録の長期保存に関連して企業を助けることを目的とする。本発明はワーム（ＷＯＲＭ）保証やユーザー定義の保存ポリシーとの整合を容易にするタイムスタンピングを実施することによって上記目的を達成する。

本発明はオープンプラットホーム上に展開することでハードウェア依存性を解消する。商品プラットホームと工業所有権を有する記憶装置とのコストギャップが増大するに従って、情報技術（ＩＴ）の買い手は最早高コスト装置の売り手との関係に縛られたくないと考えている。所与のノードは、多くの場合、商品ハードウェアと、好ましくはオープンソース（例えば、Ｌｉｎｕｘ）オペレーティングシステムで作用するから、買い手は最善の対策として多様なハードウェアオプションで購入できることが好ましい。

本発明はファイルの記憶及び検索に業界標準のインターフェース、例えば、ＮＦＳ、ＨＴＴＰ、ＦＴＰ、ＣＩＦＳなどを提供する。これにより、システムは標準的なコンテンツ管理システム、検索システム、記憶管理ツール（例えば、ＨＳＭ及びバックアップシステ
ム）、及びカスタマイズされたアーカイブアプリケーションと容易に相互作用することができる。

ＲＡＩＮに基づくアーキテクチャを使用することにより、システムは複製ポリシーによって規定される程度に信頼性を保証することができる。故障ディスクまたは所与のノードにおけるファイルは自動的に他の場所へ再配置されるから、システムは自己回復性である。小規模で始まったアーカイブはノードを追加するだけで容易に拡張することができる。極めて対称的であるから、性能に影響を及ぼすことなく多数のノードから成るクラスタに亘って処理能力及び記憶容量を分散させることができる。

大規模アーカイブの構築には通常２つの初期コストが伴う：即ち、アーカイブが運営される装置と、これと協働するソフトウェアに要するコストである。いずれも多くの場合財産的価値のあるものである。本発明は幾つの方法でこのコストを軽減する。このシステムは商品オペレーティングシステム及びハードウェア、特に、好ましい実施態様としては、Ｌｉｎｕｘシステムのクラスタにおいて作用するように構成されている。Ｌｉｎｕｘの新しいモデルで動作するコンピュータならシステムノードとして作用することができる。ハードウェアに左右されないプラットホームを利用することによって、ユーザーは個々の需要に適した最善のストレージクラスタコンポーネントを求めることができる。このシステムは広範囲のアプリケーションと協働し、例えば、ＮＦＳ、ＨＴＴＰ及びＦＴＰを含む最もポピュラーなファイルレベルのインターフェースを支援するように構成されている。このことはシステムが広範囲のアプリケーションと容易に協働できることを意味する。

本発明は多くの利点を提供する。上述したように、大規模アーカイブシステムの構成にはエラーが付き物である。データベース、ネットワーク構成、オペレーティングシステム、ストレージ管理システム及びウェブサーバーはいずれも豊富なスキルを有する専門家チームでなければ一括して運営することはできない。本発明は、例えば、高レベルのポリシーを介してシステム構成を設定することによってインストール及び一体化を簡単にする自律的システムでこの問題と取り組む。記憶システム、データベース、ウェブサーバー及びオペレーティングシステムがいずれも、管理者が性能を最適化することを可能にする広範囲の調整可能なパラメータを有することも公知である。本発明の自律システムは自体のオペレーションをモニターしながら、負荷平衡化のような機能を自動的に行う。公知技術では、大規模インフラストラクチャに生じた問題を診断または決定するのに数週間を要する。アーカイブシステムは連続的に利用可能でなければならないから、管理者は進行中のサービスを中断することなく故障装置を取外し、交換できねばならない。本発明が提供するような自律システムは誤動作中のプロセス、ノードなどを自動的に検知し、アーカイブからこれらを安全に取外す。種々のセキュリティ機構が存在するにもかかわらず、管理者は悪意の攻撃または不慮の損傷からアーカイブを如何にして保護するかを自身の判断で決定する場合が多い。これに反して、本発明では、文献の保存、データ確認、及びファイル複製を実行する保護ポリシーを組合せて貴重なディジタル資産の損失から保護する。

本発明を方法及びプロセスに関して説明したが、本発明はオペレーションを実行するための装置にも係わる。この装置は所期の目的のために特に構成された装置か、コンピュータに記憶されているコンピュータプログラムによって作動させるか、または再構成できる商品コンピュータか、である。このようなコンピュータプログラムはコンピュータ可読記憶媒体、例えば、光ディスク、ＣＤ−ＲＯＭ、磁気-光ディスクのようなディスク、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気または光カード、またはコンピュータプログラム命令を記憶するのに好適な媒体などであり、いずれもコンピュータシステムバスに接続される。

システムの所与のコンポーネントを別々に説明したが、当業者なら容易に理解できるよ
うに、機能の幾つかは所与の命令、プログラムシーケンス、コード部分などにおいて組合わせるか、または共用させることができる。

Claims

それぞれがオブジェクトに基づくストレージを提供するアプリケーションインスタンスを実行し、全体としてネットワークを構成する独立ノードの冗長アレイにおいて、
所与のノードに所与の固定内容データが書き込まれると、ポリシーデータを含むメタデータと一緒に所与内容データをカプセル化するデータオブジェクトを作成し；
所与のノードにデータオブジェクトを記憶させ；
アーカイブオブジェクトのライフサイクル中、データオブジェクトのメタデータに含まれるポリシーデータに抗して１つまたは２つ以上のポリシーを含むポリシーセットを強制するステップから成ることを特徴とするストレージ管理方法。
１つまたは２つ以上のポリシーから成るポリシーセットがデータ保護ポリシーを含むことを特徴とする請求項１に記載の方法。
１つまたは２つ以上のポリシーから成るポリシーセットがデータ確認ポリシーを含むことを特徴とする請求項１に記載の方法。
１つまたは２つ以上のポリシーから成るポリシーセットが保持ポリシーを含むことを特徴とする請求項１に記載の方法。
１つまたは２つ以上のポリシーから成るポリシーセットがクラスタバランスポリシーを含むことを特徴とする請求項１に記載の方法。
１つまたは２つ以上のポリシーから成るポリシーセットが不要情報収集ポリシーを含むことを特徴とする請求項１に記載の方法。
１つまたは２つ以上のポリシーから成るポリシーセットがスキャベンジングポリシーを含むことを特徴とする請求項１に記載の方法。
１つまたは２つ以上のポリシーから成るポリシーセットが重複削除ポリシーを含むことを特徴とする請求項１に記載の方法。
それぞれが所与のオペレーティングシステムによって操作され且つローカルファイルシステムを含む所与のハードウェアを有する独立ノードの冗長アレイにおいて、
ノードのローカルファイルシステムに書き込まれた所与の固定内容データと連携し、ポリシーデータと一緒に所与の固定内容データをカプセル化するデータオブジェクトセットと；
所与のノードにおける所与のハードウェアにおいて実行されるアプリケーションインスタンスとを含み；
アプリケーションインスタンスが
所与のノードのローカルファイルシステムに記憶されているデータオブジェクトへのアクセスを可能にするファイルシステムコードと；
所与のデータオブジェクトと連携するリクエストを処理するリクエストマネジャーコードと；
ノードのローカルファイルシステムにデータオブジェクトを記憶させるストレージマネジャーコードと；
所与のノードを含む互いに協働するノードセットに亘ってデータオブジェクトを管理するメタデータマネジャーコードと；
アーカイブオブジェクトのライフサイクル中、データオブジェクトのメタデータに含まれるポリシーデータに抗して１つまたは２つ以上のポリシーから成るポリシーセットを
強制するポリシーマネジャーコード
を含むことを特徴とする改良。
それぞれが所与のオペレーティングシステムによって操作され且つローカルファイルシステムを含む所与のハードウェアを有する独立ノードの冗長アレイより成るシステムにおいて、
ノードのローカルファイルシステムに書き込まれた所与の固定内容データと連携し、ポリシーデータと一緒に所与の固定内容データをカプセル化するデータオブジェクトセットと；
所与のノードにおける所与のハードウェアにおいて実行されるアプリケーションインスタンスを含み；
アプリケーションインスタンスが
所与のノードのローカルファイルシステムに記憶されているデータオブジェクトへのアクセスを可能にするファイルシステムコードと；
所与のデータオブジェクトと連携するリクエストを処理するリクエストマネジャーコードと；
ノードのローカルファイルシステムにデータオブジェクトを記憶させるストレージマネジャーコードと；
所与のノードを含む互いに協働するノードセットに亘ってデータオブジェクトを管理するメタデータマネジャーコードと；
データオブジェクトのライフサイクル中、データオブジェクトのメタデータに含まれるポリシーデータに抗して１つまたは２つ以上のポリシーから成るポリシーセットを強制するポリシーマネジャーコードを含む
ことを特徴とするシステム。
第１及び第２ノードにおける所与のハードウェアが混成であることを特徴とする請求項１０に記載のシステム。
アプリケーションインスタンスが構成要素を介して所与のノードを管理する管理インタフェースをも含むことを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットがデータ保護ポリシーを含むことを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットがデータ確認ポリシーを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットが保持ポリシーを含むことを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットがクラスタバランスポリシーを含むことを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットが不要情報収集ポリシーを含むことを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットがスキャベンジングポリシーを含むことを特徴とする請求項１０に記載のシステム。
１つまたは２つ以上のポリシーから成るポリシーセットが重複削除ポリシーを含むこと
を特徴とする請求項１０に記載のシステム。
所与のノードにおいて実行されるアプリケーションインスタンスが他のすべてのノードにおいて実行されるアプリケーションインスタンスと同じであり、所与のノードのうちの第１及び第２ノードにおける所与のハードウェアが混成であることを特徴とする請求項１０に記載のシステム。