"それぞれがオブジェクトに基づくストレージを提供するアプリケーションインスタンスを実行し、全体としてネットワークを構成する独立ノードの冗長アレイにおいて、所与のノードに所与の固定内容データが書き込まれると、ポリシーデータを含むメタデータと一緒に所与内容データをカプセル化するデータオブジェクトを作成し;所与のノードにデータオブジェクトを記憶させ;アーカイブオブジェクトのライフサイクル中、データオブジェクトのメタデータに含まれるポリシーデータに抗して1つまたは2つ以上のポリシーを含むポリシーセットを強制するステップから成ることを特徴とするストレージ管理方法。1つまたは2つ以上のポリシーから成るポリシーセットがデータ保護ポリシーを含むことを特徴とする請求項1に記載の方法。1つまたは2つ以上のポリシーから成るポリシーセットがデータ確認ポリシーを含むことを特徴とする請求項1に記載の方法。1つまたは2つ以上のポリシーから成るポリシーセットが保持ポリシーを含むことを特徴とする請求項1に記載の方法。1つまたは2つ以上のポリシーから成るポリシーセットがクラスタバランスポリシーを含むことを特徴とする請求項1に記載の方法。1つまたは2つ以上のポリシーから成るポリシーセットが不要情報収集ポリシーを含むことを特徴とする請求項1に記載の方法。1つまたは2つ以上のポリシーから成るポリシーセットがスキャベンジングポリシーを含むことを特徴とする請求項1に記載の方法。1つまたは2つ以上のポリシーから成るポリシーセットが重複削除ポリシーを含むことを特徴とする請求項1に記載の方法。それぞれが所与のオペレーティングシステムによって操作され且つローカルファイルシステムを含む所与のハードウェアを有する独立ノードの冗長アレイにおいて、ノードのローカルファイルシステムに書き込まれた所与の固定内容データと連携し、ポリシーデータと一緒に所与の固定内容データをカプセル化するデータオブジェクトセットと;所与のノードにおける所与のハードウェアにおいて実行されるアプリケーションインスタンスとを含み;アプリケーションインスタンスが所与のノードのローカルファイルシステムに記憶されているデータオブジェクトへのアクセスを可能にするファイルシステムコードと;所与のデータオブジェクトと連携するリクエストを処理するリクエストマネジャーコードと;ノードのローカルファイルシステムにデータオブジェクトを記憶させるストレージマネジャーコードと;所与のノードを含む互いに協働するノードセットに亘ってデータオブジェクトを管理するメタデータマネジャーコードと;アーカイブオブジェクトのライフサイクル中、データオブジェクトのメタデータに含まれるポリシーデータに抗して1つまたは2つ以上のポリシーから成るポリシーセットを強制するポリシーマネジャーコードを含むことを特徴とする改良。それぞれが所与のオペレーティングシステムによって操作され且つローカルファイルシステムを含む所与のハードウェアを有する独立ノードの冗長アレイより成るシステムにおいて、ノードのローカルファイルシステムに書き込まれた所与の固定内容データと連携し、ポリシーデータと一緒に所与の固定内容データをカプセル化するデータオブジェクトセットと;所与のノードにおける所与のハードウェアにおいて実行されるアプリケーションインスタンスを含み;アプリケーションインスタンスが所与のノードのローカルファイルシステムに記憶されているデータオブジェクトへのアクセスを可能にするファイルシステムコードと;所与のデータオブジェクトと連携するリクエストを処理するリクエストマネジャーコードと;ノードのローカルファイルシステムにデータオブジェクトを記憶させるストレージマネジャーコードと;所与のノードを含む互いに協働するノードセットに亘ってデータオブジェクトを管理するメタデータマネジャーコードと;データオブジェクトのライフサイクル中、データオブジェクトのメタデータに含まれるポリシーデータに抗して1つまたは2つ以上のポリシーから成るポリシーセットを強制するポリシーマネジャーコードを含むことを特徴とするシステム。第1及び第2ノードにおける所与のハードウェアが混成であることを特徴とする請求項10に記載のシステム。アプリケーションインスタンスが構成要素を介して所与のノードを管理する管理インタフェースをも含むことを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットがデータ保護ポリシーを含むことを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットがデータ確認ポリシーを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットが保持ポリシーを含むことを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットがクラスタバランスポリシーを含むことを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットが不要情報収集ポリシーを含むことを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットがスキャベンジングポリシーを含むことを特徴とする請求項10に記載のシステム。1つまたは2つ以上のポリシーから成るポリシーセットが重複削除ポリシーを含むことを特徴とする請求項10に記載のシステム。所与のノードにおいて実行されるアプリケーションインスタンスが他のすべてのノードにおいて実行されるアプリケーションインスタンスと同じであり、所与のノードのうちの第1及び第2ノードにおける所与のハードウェアが混成であることを特徴とする請求項10に記載のシステム。本発明はディスクを使用する拡大縮小可能なアーカイブデータ保存装置として実施することが好ましく、独立ノードの冗長アレイに基づくシステムアーキテクチュアとして実施することがより好ましい。ノードは異なるハードウェアから成り、従って、異質であると見做すことができる。これに反して、それぞれのノードにおいてサポートされるアーカイブクラスタアプリケーション及び、場合によっては、アプリケーションを実行するOSは同じである。即ち、それぞれのノードにおけるOSを含むソフトウェアスタックは対称的であるのに対して、ハードウェアは異質である。図1に示すように、本発明を利用すれば、企業は多様なタイプの固定コンテンツ情報、例えば、文献、電子メール、衛星画像、診断画像、検査画像、録音記録、ビデオなどを恒久的に保存することができる。上記した幾つかのタイプは説明のための例に過ぎないことはいうまでもない。独立サーバーまたはいわゆる記憶ノードにおいてデータを複製することによって高度の可用性が得られる。それぞれのノードは他のノードと対称関係にあることが好ましい。好ましいくは任意所与のノードがすべての機能を果すことができるため、いずれか1つのノードが故障してもアーカイブの可用性には殆ど影響しない。代表的な実施態様では、本発明がアーカイブクラスタArCアプリケーションとも呼称される分散型ソフトウェアアプリケーションとして実現される。このアプリケーションはディジタル資産を捕捉、保存、管理、及び検索する。図2に示す実施例では、個々のアーカイブの物理的境界をここではクラスタと呼称する。通常、クラスタは単一の装置ではなく、装置の集合である。上述したように、これらの装置は同質であっても異質であってもよい。典型的な装置はリナックスのようなオペレーティングシステムを実行するコンピュータまたはマシーンである。市販のハードウェアをホストとするリナックスベースのシステムのクラスタは数個のストレージノードサーバーから数千テラバイトのデータを記憶する多数のノードにまで拡張可能なアーカイブを提供する。このアーキテクチュアによって、記憶容量を、組織の増大するアーカイブ需要に合せて増大させることができる。アーカイブが常に装置の故障から保護されるようにクラスタ全体に亘ってデータを複製することが好ましい。ディスクまたはノードが故障した場合、クラスタは同じデータの複製を保持しているこのクラスタ中の他のノードへ自動的に障害迂回する。図示のクラスタは好ましくは大別して下記のコンポーネントから成る:ノード202、1対のネットワークスイッチ204、電力分配装置PDU206、及び無停電電源UPS208。ノード202は通常、市販の1つまたは2つ以上のサーバーより成り、CPU例えば、インテルx86、適当なランダムアクセスメモリRAM、1つまたは2つ以上のハードドライブ例えば、標準的なIDESATA、SCSIなど、及び2つまたは3つ以上のネットワークインターフェースカードNICを含む。典型的なノードは2.4GHzチップ、512MBのRAM、及び6つの200GBハードドライブを含む2Uラックマウント方式ユニットである。但し、これは1例に過ぎない。ネットワークスイッチ204は通常、ノード間でピアツーピア交信を可能にする内部スイッチ205と、クラスタの外部からそれぞれのノードへのアクセスを可能にする外部スイッチ207を含む。それぞれのスイッチはクラスタ中のすべてのノードを扱うのに充分なポートを必要とする。この必要性を満たすには、イーサネットまたはGigEを使用すればよい。PDU206はすべてのノード及びスイッチへの給電に使用され、UPS208はすべてのノード及びスイッチを保護するのに使用される。多くの場合、クラスタは公衆インターネット、企業イントラネット、またはその他のワイドエリアまたはローカルエリアネットワークなどのネットワークに接続可能である。図示例の場合、クラスタは企業環境内で実現される。クラスタには、例えば、サイトの企業のドメインネームシステムDNSのネームサーバーをナビゲーションすることによって到達することができる。即ち、例えば、クラスタのドメインが既存のドメインの新しいサブドメインである場合が考えられる。代表例では、このサブドメインが企業DNSサーバーにおいてクラスタ自体のネームサーバーに委託される。エンドユーザーは公知のインターフェースまたはアクセスツールを利用してクラスタにアクセスする。クラスタへのアクセスは、例えば、APIを介して、または公知または新規に開発されたアクセス方法、サービス、プログラムまたはツールを介して、IPベースのプロトコルHTTP、FTP、NFS、AFS、SMB、ウェブサービスなどを利用することでよって行うことができる。詳しくは後述するように、クライエントアプリケーションは1つまたは2つ以上のタイプの外部ゲートウェイ、例えば、標準型UNIXファイルプロトコル、またはHTTPAPIなどを介してクラスタにアクセスする。ゲートウェイは管理コンソールを介して独立に機能可能化または機能抑止されることが好ましい。アーカイブは、オプションとして標準的なUNIXファイルプロトコル利用設備下に作用する仮想ファイルシステムを介して露出されることが好ましい。例えば、NFS、FTP、SMBCIFSなどがある。標準的なTCPIPアドレスを介してアーカイブに正しくアクセスすると、ファイルプロトコルは標準的なUNIXオペレーティングシステム上におけるように動作する。尚、はクラスタのルートディレクトリである。好ましい実施態様では、アーカイブクラスタアプリケーションは例えば、イーサネットを介して1つのクラスタとしてネットワークを形成する独立ノード冗長アレイH-RAIN上を走る。所与のノードのハードウェアは異質であってもよい。但し、可用性を最大にするためには、それぞれのノードが、図3に示すように、幾つかの実行時コンポーネントから成る分散アプリケーションの全インスタンス300を実行することが好ましい。即ち、ハードウェアは異質であっても、少なくとも本発明に関する限りノード上のソフトウェアスタックは同じである。これらのソフトウェアコンポーネントはゲートウェイプロトコルレイヤー302、アクセスレイヤー304、ファイルトランザクション及び管理レイヤー306、及びコアコンポーネントレイヤー308から成る。レイヤーと呼称するのは飽くまでも説明の便宜上であって、当業者には周知のように、もっと有意義な方法でその機能を特徴付けることができる。レイヤーまたはこれに含まれるコンポーネンの1つまたは2つ以上が一体化されていてもよい。幾つかのコンポーネントを複数のレイヤーで共用させることもできる。ゲートウェイプロトコルレイヤー302におけるゲートウェイプロトコルは既存のアプリケーションに透過性を与える。特に、ゲートウェイはネイティブファイルサービス、例えば、NFS310、SMBCIFS312、及びウェブサービスを提供することによってカスタムアプリケーションを形成する。HTTPサポート314も提供される。アクセスレイヤー304はアーカイブへのアクセスを可能にする。特に、本発明では、固定コンテンツファイルシステムFCFS316がネイティブファイルシステムをエミュレートすることによってアーカイブオブジェクトへの完全なアクセスを可能にする。FCFSはあたかも普通のファイルであるかのようにアプリケーションを直接アーカイブ内容にアクセスさせる。好ましくは、アーカイブのコンテンツを元のフォーマットにレンダリングする一方、メタデータをXMLファイルとして表現する。FCFS316はディレクトリ、パーミッション及びルーチンのファイルレベルのコールを型通りに表示するから、管理者は慣れた態様で固定コンテンツデータを提供することができる。ファイルアクセスコールはユーザースペースデーモンによってインターセプトされ、レイヤー308における該当のコアコンポーネントに転送され、このコアコンポーネントが呼出しアプリケーションに対する適切な表示を動的に形成する。詳しくは後述するように、FCFSコールをアーカイブポリシーによって制約することによって自律的なアーカイブ管理を容易にすることが好ましい。従って、1例として、管理者またはアプリケーションは所与のポリシーである保持期間が未だ有効なアーカイブオブジェクトを消去することはできない。アクセスレイヤー304はウェブユーザーインターフェースUI318及びSNMPゲートウェイ320をも含むことが好ましい。ウェブユーザーインターフェース318はファイルのトランザクション管理レイヤー306における管理エンジン322への対話型アクセスを可能にする管理コンソールとして実現することが好ましい。管理コンソール318はアーカイブオブジェクト及び個別ノードを含むアーカイブを動的に表示する、パスワードで保護されたウェブベースのGUIであることが好ましい。SNMPゲートウェイ320は管理エンジン322へのストレージ管理アプリケーションのアクセスを容易にし、クラスタの動作を確実にモニターし且つ制御することを可能にする。管理エンジンはシステム及びポリシーイベントを含むクラスタの動作をモニターする。ファイルのトランザクション管理レイヤー306はリクエストマネジャープロセス324をも含む。リクエストマネジャー324はアクセスレイヤー304を介しての外界からのすべてのリクエストと、コアコンポーネントレイヤー308におけるポリシーマネジャー326からの内部リクエストを統合する。ポリシーマネジャー326の動作については詳しく後述する。ポリシーマネジャー326のほかに,コアコンポーネントはメタデータマネジャー328、及びストレージマネジャー330の1つまたは2つ以上のインスタンスをも含む。メタデータマネジャー328はそれぞれのノードにインストールすることが好ましい。全体として、クラスタにおけるメタデータマネジャーはすべてのアーカイブオブジェクトを管理する分散データベースとして作用する。所与のノードにおいて、メタデータマネジャー328はアーカイブオブジェクトのサブセットを管理し、好ましくはそれぞれのオブジェクトが外部ファイルEF、記憶させるためアーカイブに入力されるデータとアーカイブデータが物理的に配置されている内部ファイルセットそれぞれがIFとの間に位置する。同じメタデータマネジャーが他のノードから複製されたアーカイブオブジェクトのセットをも管理する。従って、それぞれの外部ファイルの現状を幾つかのノードにおける複数のメタデータマネジャーが常に利用することができる。ノードに故障が発生した場合、他のノードにおけるメタデータマネジャーがそれまで故障ノードによって管理されていたデータに直ちにアクセスする。ストレージマネジャー330は分散アプリケーションにおける他のすべてのコンポーネントが利用できるファイルシステムレイヤーを提供する。好ましくはこのファイルシステムレイヤーがノードのローカルファイルシステムにデータオブジェクトを記憶させる。所与のノードにおけるそれぞれのドライブは好ましくはそれ自体のストレージマネジャーを有する。これにより、ノードは個々のドライブを除去してスループットを最適化することができる。ストレージマネジャー330はシステム情報、データに関する完全性チェックをも提供するとともに、ローカル構造に直接アクセスすることもできる。図3に示すように、クラスタは通信ミドルウェアレイヤー332及びDNSマネジャー334を介して内部及び外部通信を管理する。インフラストラクチャ332はアーカイブコンポーネント間の通信を可能にする効率的で、しかも信頼度の高いメッセージに基づくミドルウェアレイヤーである。図示例では、このレイヤーがマルチキャストポイントツーポイント通信を支援する。DNSはすべてのノードを企業サーバーに接続する分散ネームサービスを実行する。DNSマネジャーはリクエスト負荷がすべてのノードにおいて均等になるように作用して、クラスタのスループット及び可用性を最大限に維持することが好ましい。図示例において、ArCアプリケーションは、例えば、RedHatLinux9.0のようなベースオペレーティングシステム336で実行される。通信ミドルウェアとしては、Spreadグループ通信またはその他の分散型通信機構に基づくものを使用できる。周知のように、Spreadは高性能のメッセージサービスを可能にするツールキットであり、外部または内部ネットワークに発生する障害に対して柔軟に対応することができる。Spreadは分散アプリケーションのための一体化されたメッセージバスとして機能し、高度に調整されたアプリケーションレベルのマルチキャスト通信及びグループ通信を可能にする。その他のコンポーネントとして、固定内容ファイルシステムFCFS316のために使用できるFUSEUSErspaceにおけるファイルシステムが挙げられる。NFSゲートウェイ310は標準的なnfsdLinuxKernelNFSドライバーのユーザースペース版であるUnfsdによって実現することができる。それぞれのノードにおけるデータベースは、例えば、オブジェクト関連データベース管理システムORDBMSであるPostgreSQLによって実現することができる。ノードはJavaHTTPサーバー及びサーブレットコンテナであるJettyのようなウェブサーバーを含む。但し、以上に挙げた機構はあくまでも説明の便宜上列記したものであり、本発明がこれらの機構に制限されるものではない。所与のノードにおけるストレージマネジャー330は物理的記憶装置を管理する。それぞれのストレージマネジャーインスタンスは並列アルゴリズムに従ってすべてのファイルが配置されている単一のルートディレクトリを担当することが好ましい。同時に複数のストレージマネジャーインスタンスが1つのノードにおいて機能し、それぞれのインスタンスがシステム内の異なる物理的ディスクを表す。ストレージマネジャーがドライブを取除き、システムの残り部分からのインターフェース技術が利用される。ファイルへの書込みを要求されると、ストレージマネジャーは対応の表示を行うため、フルパス及びフルネームを形成する。代表的な実施態様では、ストレージマネジャーに記憶させるべきそれぞれのオブジェクトが記憶させるべき生データの形で受信され、記憶させるファイルにストレージマネジャーが自らのメタデータを加えることにより、異なるタイプの情報をトラックできるようにする。例えば、このメタデータは以下に列記する内容を含む:EF長さ外部ファイルの長さバイト、IFセグメントサイズ内部ファイルのこの部分のサイズ、EF保護表示EF保護モード、IF保護任務この内部ファイルの表示、EF作成時刻印保護スキームである。このほか、代表的なスキームとして、情報分散アルゴリズムがある。管理者の観点からすれば、この支援はクラスタ全体のための単一の調整可能な保護パラメータとして露出されることが好ましい。但し、これは1例に過ぎない。即ち、代表的な実施態様では、特定の保護スキーム及び関連のパラメータに煩わされることなく、管理者はファイルをサポートするための許容可能障害点数TPOFを設定するだけでよい。アーカイブクラスタアプリケーションはそれぞれのノード内の各ディスクをモニターし、ノード及びディスクの故障を自動的に対応することができる。特定のTPOFに対応して、アプリケーションはクラスタ中のノード数に応じて利用可能なスキームのうち最善の保護スキームを活用する。RAID1データ保護スキームだけが利用可能である場合、最も単純な2方向ミラーリングの場合でも、ディスク利用率は50に過ぎない。ミラー数が増えると、TPOFも増大するが、ディスク利用率は低下する。例えば、3方向ミラーリングでは、ディスク利用率は33、4方向ミラーリングではディスク率が25となる。保護ポリシーはクラスタレベルにセットすることが好ましく、ファイルレベルでは利用できない。より具体的な実施態様としては、保護ポリシーはクラスタレベルで設定され、ファイルレベルでは利用できない。クラスタレベルの初期値は変化可能であるが、クラスタに入力される新しいファイルにのみ適用される。1例として、クラスタレベルにおける初期値TPOFは1である。保護ポリシーの実行頻度は設定可能である。初期値設定頻度は周期的であり、例えば、24時間毎である。この場合、クラスタ中のどこかでディスクまたはノードに故障が発生すると、すべてのノードに対する保護ポリシーが自動的に起動する。所与のノードにおけるポリシーマネジャーは以下に述べるように保護を行う。ポリマーマネジャーは実行するノードが所有するすべての外部ファイルEFに亘って保護ポリシーを反復実行する。それぞれの外部ファイル毎に、ポリシーマネジャーはすべての内部ファイルIFに亘って反復実行する。こうして、IFが指示するファイルに到達でき、必要に応じて修理を開始することができる。データ確認はデータの変造及びまたはサボタージュを防止する。即ち、アーカイブクラスタアプリケーションは、クラスタに挿入されるファイルがディジタル署名と一致することを確認するデータ確認ポリシーを支援する。署名はファイルの実際のコンテンツから形成するか、または実際のコンテンツの一部によって形成することが好ましい。アーカイブは、例えば、記憶されているコンテンツからこの署名を再生させ、元の署名と比較することによって記憶されているファイルコンテンツの信憑性を周期的にチェックする。データの信憑性を実証するためには署名が一致しなければならず、さもない時はアーカイブが除外すべきものとしてアーカイブ管理者に返送する。図示例においては、データ確認用のディジタル書名を、MD5アルゴリズムを使用して計算するが、例えば、SHA1、MD4などのような適当な暗号機能を利用してもよい。図示例では、アーカイブに挿入する際にファイルのMD5内容ハッシュを計算する。クライエントのアプリケーションに記憶されている内容がオリジナルと同一であることを実証するには、クラスタの外部でMD5ハッシュキーを計算し、これをクラスタが維持しているハッシュキーと比較すればよい。データ確認ポリシーの実行頻度を設定し、設定した実行頻度例えば、1週間毎を適用する。ポリシーマネジャーは所与のノードに対して以下のようにしてデータ確認を支援する。確認の対象ノードが所有するすべての外部ファイルEFに亘って反復実行する。それぞれのEF毎に、ディスク上のコンテンツのMD5ハッシュキーを計算し、最初の書込み時に記憶された外部ファイルに対応のMD5ハッシュキーと比較する。それぞれの内部ファイルIF毎に、ポリシーマネジャーは最初の書込み時及び必要に応じて最初の修復時に記憶された内部ファイルのMD5ハッシュを比較することによってコンテンツを認証する。上述したように、EFハッシュはオリジナルコンテンツから引出すことが好ましい。また、IFハッシュはスキャベンジング情報とともにオリジナルコンテンツから引出すことが好ましい。多くのデータファイルに関して、組織及び規制上の基準が課せられ、種々の期間に亘ってデータファイルを保存するよう要求している。アーカイブクラスタアプリケーションは保持期間が切れる前に、事故または悪意によるファイルの消失を防止するため、データファイルの性質に応じて保持期間を定める。例えば、ファイルが112004に記憶され、その保持期間が2ヶ月であれば、312004以前にファイルを消去しようとすると、エラーが返送される。312004またはそれ以後ならば、ファイルに消去許可のフラグが付せられる。アーカイブ管理者が積極的に消去しない限り、ファイルはクラスタ内に温存される。保持期間はミリセコンド単位で記憶させることが好ましい。例えば、保持期間を-1と設定することによって消去不能であることをファイルにマークすることもできる。保持ポリシーについては、個々のディレクトリレベルで初期値を設定することが好ましいが、HTTPゲートウェイを使用する場合には挿入されるそれぞれのファイルにも設定することができる。一旦或るファイルに保持期間を規定したら、利用可能なゲートウェイを介して変更することができるが、延長する場合のみであって、短縮は許されない。或るファイルに関するファイルに設定される保持期間初期値が0ということは、そのファイルをいつでも消去できることを示唆するものである。代表的な実施態様では、所与のノードにおけるリクエストマネジャーRMが保持ポリシーをモニターする。但し、これは必須条件ではない。経時的にクラスタ内の個々のノードがそのストレージ利用度の点で互いにバランスを失う可能性がある。アーカイブクラスタアプリケーションはこの容量利用度をモニターし、例えば、クラスタに新しいノードが追加されると、クラスタを平衡状態に戻すべくファイルを再配置する。クラスタバランスは調整可能なパラメータを持たないクラスタレベルのポリシーであることが好ましいが、このことは必須条件ではない。クラスタバランスはクラスタの容量利用度を平衡状態に戻す積極的なアルゴリズムではあるが、リクエストマネジャーが所与のノードとともに、データを配置すべきノードを適正に選択することによって書込み毎にこのバランスを維持するように試みることが好ましい。不要情報収集はメタデータマネジャーにおいて論理的に消去されるとしてマーキングされたすべてのファイルを物理的に消去するのに必要である。このような記入事項が現れるのは、ファイル書込み中の失敗が原因であり、誤った書込みプロセスによってコンポーネントの一部が自動的にクリーンアップされなかったのである。不要情報収集は調整可能なパラメータを持たないクラスタレベルのポリシーであることが好ましいが、このことは必須条件ではない。不要情報収集ポリシーの実行頻度は設定可能である。1例として、初期値実行頻度は24時間に一度と設定することができる。所与のノードにおけるポリシーマネジャーは下記のように不要情報収集を支援する。実行の対象であるノードが所有するすべてのメタデータに亘って反復する。それぞれの外部ファイル毎に、ポリシーマネジャーは関連する内部ファイルすべてを有することを確認する。次いで、ポリシーマネジャーは誤ってこれらの内部ファイルに挿入された残留データをクリーンアップする。スキャベンジングは最悪のメタデータ喪失に対する安全ネットである。上述したように、ストレージマネジャーによって記憶させられたそれぞれの物理的ファイルはメタデータマネジャーによって管理されるメタデータをも含む。スキャベンジングポリシーはすべてのファイルに亘って作用してそれぞれのファイルのメタデータを無傷に維持する。メタデータが欠落していることが判明すると、必要に応じて再生させる。スキャベンジングは調整可能なパラメータを持たないクラスタレベルのポリシーであることが好ましいが、このことは必須条件ではない。スキャベンジングポリシーの実行頻度は設定することができる。初期値実行頻度は24時間に一度である。所与のノードにおけるポリシーマネジャーは下記のようにスキャベンジングを支援する。ポリシーマネジャーの実行対象であるノードが所有するすべてのファイルに亘って反復実行する。それぞれのファイル毎に、ポリシーマネジャーはクラスタがこのファイルのための有効なメタデータを有することを認証する。必要に応じて、メタデータの修復を開始する。上述したように、アーカイブにおけるそれぞれのノードが、図6に示すようなディスプレイインターフェースを出力する管理コンソールを支援する。図6には、アーカイブクラスタの概括ページ600を示す。このページは、クラスタが所与の日時の状態として、完全に作動していることを示すインジケータ602を含む。このインジケータはその時々の動作状態に応じて色が変わる例えば、緑色から黄色へ、黄色から赤色へ。ポリシーステータス及びリセントイベント表604はポリシータブ606及びイベントタブ608を含むことが好ましい。図示例において支援されるポリシーのそれぞれについてカレントポリシーステータスが示されている。ノードリスト表610はそれぞれのノードをそのID、ステータス及びノードIPアドレスによって識別している。管理オペレーションを容易にするため、一連のコントロールが設けられている。具体的には、管理コンソールが下記のコントロールを含む一連のクラスタノードコンポーネントコントロールを可視化することが好ましい:ノード起動、ノード停止、ノード再起動、クラスタ起動、クラス停止、及びクラスタ再起動のコントロール。図示例においてクラスタ中のクラスタボリューム及びトータルファイルを示すための、1つまたは2つ以上のメトリックグラフ612、614をも設ける。種々のディスプレイタブを選択することによって、管理者はその他の詳細を観察し、セットすることができる。ディスプレイタブはクラスタノードページ616、ゲートウェイページ618、システムセッティングページ620及びクラスタログページ622を含む。クラスタノードページ616はクラスタ中のそれぞれのノードに関して設定可能な性質を有する。ゲートウェイタブ618は支援されるそれぞれのゲートウェイに関する情報を表示する。それぞれのゲートウェイはゲートウェイの作用を可能にしたり不能にしたりできるとともに、1つまたは2つ以上の設定可能な性質を有する。いうまでもなく、図6に示すディスプレイのレイアウトは1例に過ぎない。上述したように、管理コンソールはそれぞれのノードに存在するウェブベースのアプリケーションであることが好ましい。ゲートウェイからクラスタに入力される他のすべての外部リクエストと同様に、管理コンソールリクエストもDNS負荷バランサーによって選択されたノードにおいて処理される。本発明はディジタル資産を捕捉、保存、管理及び検索するように構成されたアーカイブ管理対策を容易にする。この構成は種々の必要条件を満たす:即ち、無制限の記憶、高い信頼性、自己管理、規制との整合性、ハードウェアからの独立性、及び既存アプリケーションとの一体化の容易さである。本発明が提案する、市販のハードウェアで実行される例えばLinuxのクラスタは堅牢なプラットホームと殆ど無制限のアーカイブを可能にする。このシステムは、例えば、数個のストレージノードサーバーから数千テラバイトのデータを記憶する多数のノードまで拡張することができる。この独自のアーキテクチャにより、記憶容量は組織の増大するアーカイブ需要にペースを合せて増大することができる。このシステムはファイルを絶対に喪失しないように構成されている。アーカイブが常に装置故障から保護されるようにクラスタ全体に亘ってデータを複製する。ディスクまたはノードが故障すると、クラスタは自動的に、同じデータの複製を保持しているクラスタ中の他のノードに肩代わりする。本発明は自律的な処理によってアーカイブの保存コストを軽減する。例えば、ノードがアーカイブと接合したり、アーカイブから切り離されると、システムは自動的にクラスタの負荷バランスを調整し、構成ノード全体に亘ってファイルを再分散させることによって性能を最適化する。本発明は政府規制及び業界規制や、金融書類及び医療データのような記録の長期保存に関連して企業を助けることを目的とする。本発明はワームWORM保証やユーザー定義の保存ポリシーとの整合を容易にするタイムスタンピングを実施することによって上記目的を達成する。本発明はオープンプラットホーム上に展開することでハードウェア依存性を解消する。商品プラットホームと工業所有権を有する記憶装置とのコストギャップが増大するに従って、情報技術ITの買い手は最早高コスト装置の売り手との関係に縛られたくないと考えている。所与のノードは、多くの場合、商品ハードウェアと、好ましくはオープンソース例えば、Linuxオペレーティングシステムで作用するから、買い手は最善の対策として多様なハードウェアオプションで購入できることが好ましい。本発明はファイルの記憶及び検索に業界標準のインターフェース、例えば、NFS、HTTP、FTP、CIFSなどを提供する。これにより、システムは標準的なコンテンツ管理システム、検索システム、記憶管理ツール例えば、HSM及びバックアップシステム、及びカスタマイズされたアーカイブアプリケーションと容易に相互作用することができる。RAINに基づくアーキテクチャを使用することにより、システムは複製ポリシーによって規定される程度に信頼性を保証することができる。故障ディスクまたは所与のノードにおけるファイルは自動的に他の場所へ再配置されるから、システムは自己回復性である。小規模で始まったアーカイブはノードを追加するだけで容易に拡張することができる。極めて対称的であるから、性能に影響を及ぼすことなく多数のノードから成るクラスタに亘って処理能力及び記憶容量を分散させることができる。大規模アーカイブの構築には通常2つの初期コストが伴う:即ち、アーカイブが運営される装置と、これと協働するソフトウェアに要するコストである。いずれも多くの場合財産的価値のあるものである。本発明は幾つの方法でこのコストを軽減する。このシステムは商品オペレーティングシステム及びハードウェア、特に、好ましい実施態様としては、Linuxシステムのクラスタにおいて作用するように構成されている。Linuxの新しいモデルで動作するコンピュータならシステムノードとして作用することができる。ハードウェアに左右されないプラットホームを利用することによって、ユーザーは個々の需要に適した最善のストレージクラスタコンポーネントを求めることができる。このシステムは広範囲のアプリケーションと協働し、例えば、NFS、HTTP及びFTPを含む最もポピュラーなファイルレベルのインターフェースを支援するように構成されている。このことはシステムが広範囲のアプリケーションと容易に協働できることを意味する。本発明は多くの利点を提供する。上述したように、大規模アーカイブシステムの構成にはエラーが付き物である。データベース、ネットワーク構成、オペレーティングシステム、ストレージ管理システム及びウェブサーバーはいずれも豊富なスキルを有する専門家チームでなければ一括して運営することはできない。本発明は、例えば、高レベルのポリシーを介してシステム構成を設定することによってインストール及び一体化を簡単にする自律的システムでこの問題と取り組む。記憶システム、データベース、ウェブサーバー及びオペレーティングシステムがいずれも、管理者が性能を最適化することを可能にする広範囲の調整可能なパラメータを有することも公知である。本発明の自律システムは自体のオペレーションをモニターしながら、負荷平衡化のような機能を自動的に行う。公知技術では、大規模インフラストラクチャに生じた問題を診断または決定するのに数週間を要する。アーカイブシステムは連続的に利用可能でなければならないから、管理者は進行中のサービスを中断することなく故障装置を取外し、交換できねばならない。本発明が提供するような自律システムは誤動作中のプロセス、ノードなどを自動的に検知し、アーカイブからこれらを安全に取外す。種々のセキュリティ機構が存在するにもかかわらず、管理者は悪意の攻撃または不慮の損傷からアーカイブを如何にして保護するかを自身の判断で決定する場合が多い。これに反して、本発明では、文献の保存、データ確認、及びファイル複製を実行する保護ポリシーを組合せて貴重なディジタル資産の損失から保護する。本発明を方法及びプロセスに関して説明したが、本発明はオペレーションを実行するための装置にも係わる。この装置は所期の目的のために特に構成された装置か、コンピュータに記憶されているコンピュータプログラムによって作動させるか、または再構成できる商品コンピュータか、である。このようなコンピュータプログラムはコンピュータ可読記憶媒体、例えば、光ディスク、CD-ROM、磁気光ディスクのようなディスク、読出し専用メモリROM、ランダムアクセスメモリRAM、磁気または光カード、またはコンピュータプログラム命令を記憶するのに好適な媒体などであり、いずれもコンピュータシステムバスに接続される。システムの所与のコンポーネントを別々に説明したが、当業者なら容易に理解できるように、機能の幾つかは所与の命令、プログラムシーケンス、コード部分などにおいて組合わせるか、または共用させることができる。"