JP5254611B2 - 固定内容分散データ記憶のためのメタデータ管理 - Google Patents

Description

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

公知技術の説明

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

従来のアーカイバル記憶システムは典型的にはファイル毎にメタデータ及びその内容を記憶する。多くの場合、メタデータはシステムに記憶されている実データの内容、品質、状態、及びその他の特徴を記述する。分散記憶の場合、ファイルに関するメタデータは、例えば、ファイルの構成要素が記憶されているファイル名、ファイルの作成日時、保持データなどを含む。記憶システムの信頼性とファイルの利用可能度を達成するには信頼できるファイル記憶が必要であるが、メタデータのインテグリティもまたシステムの重要な部分である。ところが、公知の技術では、潜在的に信頼性に欠けるノードの分散システムにメタデータを分散させることは不可能であった。本発明はこの問題に取り組むものである。

発明の概要

好ましくは対称的なノードから成るアーカイバル記憶クラスタは好ましくはメタデータ・オブジェクトの形態を取る所与のメタデータに対するアクセスを組織し、提供するメタデータ管理システムを含む。それぞれのメタデータ・オブジェクトは固有の名前を有することができ、メタデータ・オブジェクトは領域として組織される。領域は1つまたは2つ以上のオブジェクト属性（例えば、オブジェクト名）をハッシュし、得られたハッシュ値のビット数を抽出することによって選択することが好ましい。ビット数は設定パラメータによってコントロールすることができる。それぞれの領域は冗長に記憶される。領域は領域コピー群から成る。具体的には、1つの認証の領域コピーがあり、バックアップ・コピーが幾つか存在するか、または全く存在しない。バックアップ・コピーの数は「許容可能な不具合点」(TPOF)数と呼称されることがある設定パラメータによってコントロールすることができる。即ち、代表的な実施態様として、領域は認証領域コピーとそのTPOFバックアップ・コピーから成る。領域コピーは、ノード毎の認証領域コピーの数とノード毎の領域コピーの総数がバランスするようにクラスタ・ノードに分散させる。

本発明の特徴として、それぞれの領域のそれぞれのコピーに関与するノードを領域「マップ」が識別する。領域マップはメタデータ管理システムを構成するプロセスによってアクセスすることができる。領域マップにおける領域はハッシュ値群を表し、この領域群全体が対応のすべてのハッシュ値をカバーする。上述したように、領域はハッシュ値のビット数を抽出することによって導き出される数によって識別される。領域マップ中の領域を画定し、所与の領域のオーナーシップを管理するためにネームスペース区分スキーマが使用される。この区分スキーマはデータベースにおいて実行することが好ましい。

領域コピーは3つの状態：「認証」、[バックアップ」及び「不完全」のいずれか1つの状態にある。もし領域コピーが認証のものであれば、領域に対するリクエストはすべてこのコピーに向けられ、それぞれの領域に1つの認証コピーが存在することになる。もし領域コピーがバックアップ・コピーなら（または不完全コピーなら）このコピーは（認証領
域管理プロセスから）更新リクエストを受信する。メタデータがロードされつつあっても、（典型的には、認証領域コピーに対して）未だ同期化されていない間は不完全コピーである。同期化が完了するまでは不完全コピーは他の状態に昇格する資格は与えられず、同期化が完了した時点で初めてバックアップ・コピーとなる。

本発明では、バックアップ領域コピーを認証領域コピーと同期化する。同期化は更新リクエストの処理中に認証領域コピーとそのＴＰＯＦバックアップ・コピーとの間のプロトコルまたは「契約」を実行することによって保証される。例えば、ローカル更新を行った後、認証領域管理プロセスは（多くの場合、他のノードに存在する）そのＴＰＯＦバックアップ・コピーのそれぞれに対して更新リクエストを発信する。更新リクエストが受信されると、所与のバックアップ・コピーに関連する領域管理プロセスが確認を発信するか、または発信しようとするのが通常の手順である。確認はプロセスがそのローカル・データベースに更新を書き込んだかどうかとは無関係である。更新が適切になされたことを指示する前に認証領域管理プロセスはＴＰＯＦバックアップ・コピーのすべてからの確認を待つ。但し、この更新プロセスが上手く行かない場合が幾つか考えられる。例えば、（確認を待っている間に)認証領域管理プロセスがバックアップ管理プロセスの不作動を示す異議に遭遇する、確認を発信下にもかかわらず、バックアップ管理プロセスが更新リクエストの処理を局所的に失敗する、確認を発信したものの、バックアップ領域管理プロセスが認証領域管理プロセスの不作動を示す異議に遭遇する、などがそれである。バックアップ領域管理プロセスが更新を処理できなければ、このバックアップ管理プロセスはシステムから排除される。バックアップ領域管理プロセスも認証領域管理プロセスも機能しなくなれば、新しい領域マップが提供される。このように同期化を確保することによって、それぞれのバックアップ・コピーを認証コピーに対して「ホット・スタンバイ」の状態に維持することができる。このようなバックアップ・コピーは、もし認証領域コピーが消えた場合、または負荷分散の必要上、現在の認証領域コピーを降格（いずれかのバックアップ領域コピーを昇格)させねばならない場合、昇格して認証コピーとなることができる。

このようにデザインしたから、たとえ多数のノードが同時に故障しても、メタデータの高い利用可能度を確保することができる。

本発明の比較的重要な構成要件を以上に述べたが、これらの構成要件は飽くまでも説明の便宜上選択下に過ぎず、本発明の開示内容を多様な態様で適用するか、または以下に説明するように本発明を部分的に変更することによって上記以外の多くの好ましい成果を達成することができる。

本発明の詳細及びその利点を添付の図面を参照して以下に説明する。

本発明は規模拡張可能なディスク−ベースのアーカイバル記憶装置管理システムとして実施することが好ましく、このシステムは独立ノード冗長アレイの基づくシステム構造であることが好ましい。ノードは種々のハードウェアを含むことがあるから、「混成」と考えることができる。ノードは多くの場合、1つまたは2つ以上の記憶ディスクへのアクセスを有し、記憶ディスクは物理記憶ディスクの場合もあれば、記憶領域ネットワーク(ＳＡＮ)において見られるような仮想記憶ディスクの場合もある。それぞれのノードにおけるアーカイブ・クラスタ・アプリケーション（及び、場合によっては、アプリケーションを実行する内在オペレーション・システム）は同じか、または殆ど同じである。1つの実施態様として、それぞれのノードにおける（オペレーション・システムを含む)ソフトウェア・スタックが対称性であるのに対して、ハードウェアは混成的であってもよい。図1に示すようなシステムを利用することによって、企業は多様な種類に亘る、例えば、文書、e-メール、衛星画像、診断画像、検査画像、音声記録、ビデオなどのための恒久的な記憶装置を作成することができる。以上に列挙した種類はほんの一部の例に過ぎないことは云うまでもない。独立サーバー、またはいわゆる記憶装置ノードにおけるデータを複製することによってハイレベルの信頼度が達成される。それぞれのノードはそのピアと対称であることが好ましい。即ち、いずれのノードもすべての機能を行うことができるから、いずれかのノードが呼称しても、アーカイブの利用可能度には殆ど影響しない。

同時係属出願第10/974,443号に記述されているように、それぞれのノードにおいて実行される分散ソフトウェア・アプリケーションはディジタル・アセットを補足、保存、管理および検索する。図2の実施態様において、個々のアーカイブの物理境界をクラスタと呼称する。多くの場合、クラスタは単一のデバイスではなく、デバイスの集合である。これらのデバイスは均一であっても混成であってもよい。典型的なデバイスは、例えば、Ｌｉｎｕｘのようなオペレーティング・システムを運営するコンピュータまたはマシンである。コモディティ・ハードウェアにおける主役であるＬｉｎｕｘ−系システムのクラスタは、小は数個の記憶装置ノード・サーバから大は数千テラバイトのデータを記憶する多数のノードまで規模を拡張できるアーカイブを提供する。このような構造であれば、組織の増大するアーカイブ需要に合せていつでも記憶容量を増強することができる。アーカイブが常にデバイスの故障から保護されるように、クラスタ全体に亘ってデータを複製することが好ましい。ディスクまたはノードが故障すると、クラスタは同じデータの複製を維持しているクラスタ内の他のノードが自動的に肩代わりする。

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

クライアント・アプリケーションは１つまたは２つ以上のタイプの外部ゲートウェイ、例えば、ＵＮＩＸファイル・プロトコル、またはＨＴＴＰ ＡＰＩなどを介してクラスタにアクセスする。アーカイブは必要に応じて標準的なＵＮＩＸファイル・プロトコル‐ベースの設備下に作用する仮想ファイル・システムを介して可視化できることが好ましい。例えば、ＮＦＳ、ＦＴＰ、ＳＭＢ/ＣＩＦＳなどである。

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

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

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

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

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

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

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

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

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

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

本発明では、所与のメタデータ、例えば、システム・データへのアクセスを編成し、提供するのがメタデータ管理システムである。システム・メタデータはアーカイブ中に存在するファイルに関する情報、構成情報、管理ＵＩに表示される情報、メトリックス、取り消し不能なポリシー違反などを含む。詳しくは図示しないが、（例えば、アーカイブ・ファイルと関連するユーザ・メタデータのような）その他のタイプのメタデータも、以下に説明するメタデータ管理システムを利用することによって管理することができる。

クラスタの代表的な実施態様において、下記オブジェクト・タイプの１つまたは２つ以上を含むことがある一連のメタデータ・オブジェクトの持続性を可能にする：
・ＥｘｔｅｒｎａｌＦｉｌｅ：アーカイブのユーザによって読取られるファイル；
・ＩｎｔｅｒｎａｌＦｉｌｅ：ストレージ・マネジャーによって記憶されているファイル；尚、Ｅｘｔｅｒｎａｌ ＦｉｌｅｓとＩｎｔｅｒｎａｌ Ｆｉｌｅｓの間には１つまたは２つ以上の関係が存在するのが普通である。
・ＣｏｎｆｉｇＯｂｊｅｃｔ：クラスタの構成に使用される名前／値ペア；
・ＡｄｍｉｎＬｏｇＥｎｔｒｙ：管理ＵＩに表示されるメッセージ；
・ＭｅｔｒｉｃｓＯｂｊｅｃｔ：ある時点における（例えば、ファイル数のような）アーカイブの大きさを表す時刻印されたキー／値ペア；
・ＰｏｌｉｃｙＳｔａｔｅ：あるポリシーの違反。
云うまでもなく、上記オブジェクトは説明の便宜上挙げた例であり、本発明の範囲を制限するものではない。

それぞれのメタデータ・オブジェクトは固有のネームを有し、このネームは変わらないことが好ましい。領域は認証領域コピーとＴＰＯＦ数（０以上）バックアップ領域コピーを有する。０コピーでも、メタデータ管理システムはその規模を拡張できるが、利用可能度が高いとは云えない。領域は１つまたは２つ以上のオブジェクト属性（例えば、完全なパスネームまたはその一部）をハッシュ処理し、所与のハッシュ値ビット数を抽出することによって選択される。これらのビットが領域数を構成する。選択されたビットは低位ビット、高位ビット、中位ビットまたは個々のビットの組み合わせである。代表的な実施態様では、所与のビットがハッシュ値の低位ビットである。オブジェクトの属性は公知のハッシュ関数を使用してハッシュすればよい。ハッシュ関数としては、例えば、ｊａｖａ．ｌａｎｇ．ｓｔｒｉｎｇ．ｈａｓｈＣｏｄｅのようなＪａｖａ−系のハッシュ関数がある。領域数を構成するビット数はｒｅｇｉｏｎＭａｐＬｅｖｅｌと呼称される設定パラメータによってコントロールされる。例えば、この設定パラメータを６にセットすると、結果は２^６＝６４領域となる。領域の数がもっと多くても良いことは云うまでもなく、詳しくは後述するように、ネームペース区分スキーマを利用することによって自動的に領域の数を調節することができる。

それぞれの領域は冗長に記憶させればよい。上述のように、領域には１つの認証コピーとゼロまたは１つ以上のバックアップ・コピーがある。バックアップ・コピーの数は上記メタデータＴＰＯＦ（または「ＴＰＯＦ」）設定パラメータによってコントロールされる。好ましくは、領域コピーをクラスタのすべてのノードに分散させることによってノード毎の認証領域コピーの数をバランスさせるとともに、ノード毎の領域総数をバランスさせる。

メタデータ管理システムはそれぞれのノードにおけるデータベースにメタデータ・オブジェクトを記憶させる。このデータベースを利用して領域マップをサポートする。１つの実施態様として、ＰｏｓｔｇｒｅＳＱＬを使用してデータベースを実施するが、このデータベースはオープンソースとして利用することができる。領域コピー毎にスキーマが存在し、それぞれのスキーマにメタデータ・オブジェクトのタイプ毎のテーブルが存在することが好ましい。スキーマは簡単に云えば、テーブル、索引、手続、及びその他のデータベース・オブジェクトを有することができるネームスペースである。それぞれの領域が独自のスキーマを持つことが好ましい。それぞれのスキーマはメタデータ・オブジェクト毎に1つずつのテーブルから成るテーブル一式を有する。これらのテーブルのそれぞれにおける１行は単一のメタデータ・オブジェクトに対応する。データベースとしてはＰｏｓｔｇｒｅｓが好ましいが、（例えば、Ｏｒａｃｌｅ、 ＩＢＭ ＤＢ/２などのような）適当な関係型データベースを使用してもよい。

図４に示すように、それぞれのノード４００は一連のプロセスまたはコンポーネントを有する：即ち、１つまたは２つ以上の領域マネジャー（ＲＧＭ）４０２ａ‐ｎ、メタデータ・マネジャー（ＭＭ）４０４、少なくとも１つのメタデータ・マネジャー・クライアン
ト（ＭＭＣ）４０６、及び１つまたは２つ以上のスキーマ４１０ａ‐ｎを有するデータベース４０８。ＲＧＭ、ＭＭ及びＭＭＣコンポーネントはＪａｖａバーチャル・マシンのようなバーチャル・マシン４１２で実行する。領域コピー毎に１つのＲＧＭが存在する。従って、認証領域コピー毎にＲＧＭ、バックアップ領域コピー毎にＲＧＭ、不完全領域コピー毎にＲＧＭが存在する。また、ＲＧＭ４０２毎にデータベース・スキーマ４１０が存在し、ＲＧＭ４０２がこのスキーマを実行する。データベースはまた領域マップ４０５を記憶する。本発明では、後述するように、それぞれのノードが領域マップの同じグローバル・ビューを持つことが好ましく、この条件は同期化スキーマによって強制される。領域マネジャーＲＧＭ４０２は（認証、バックアップ、不完全の別なく）領域コピーに作用し、メタデータ・マネジャー・クライアント４０６及びその他の領域マネジャー４０２からのリクエストを実行する。リクエストは適当な手段、例えば、図３に示すような通信ミドルウェアまたはその他のメッセージ層を介して所与のＲＧＭへ送信される。領域マネジャーが提供する実行環境において、これらのリクエストは、例えば、このＲＧＭの管理下にあるスキーマに作用するようにデータベースと接続することによって実行される。それぞれの領域マネジャーはそのデータをデータベース４０８に記憶させる。メタデータ・マネジャー４０４はノードにおいてメタデータ管理を行うトップレベルのコンポーネントであり、領域マネジャー（ＲＧＭ）の創成及び破壊、さらには、ＲＧＭが必要とする資源、例えば、クラスタ構成情報やデータベース・コネクションのプールの編成を行う。好ましくは、（所与のノードにおける）所与のメタデータ・マネジャーがリーダーをして作用し、（ノードのセットまたはサブセット）のうち、どのメタデータ・マネジャーがどの領域コピーに作用するかを判定する。メタデータ・リーダーを選択するにはブリ・アルゴリズム(ｂｕｌｌｙ ａｌｇｏｒｉｔｈｍ）またはその変形アルゴリズムを使用すればよい。それぞれのノードは単一のメタデータ・マネジャーを有することが好ましいが、それぞれのノードが複数のＭＭｓを実行することも可能である。（詳しくは後述するような)ネームスペース区分スキーマによって領域オーナーシップが確立したら、それぞれのメタデータ・マネジャーは１つまたは２つ以上の領域マネジャーのセットを調整する。（例えば、管理エンジン、ポリシー・マネジャーなどのような）システム・コンポーネントはメタデータ・マネジャー・クライアントを介してメタデータ・マネジャーＭＭと相互作用する。ＭＭＣは（領域マップを利用して）所与のリクエストを実行するＲＧＭを位置検出し、選択されたＲＧＭに対してリクエストを発信し、選択されたＲＧＭが（例えば、ノード故障のため）利用不能であれば、リクエストに再試行する。この場合、ノードが新しい領域マップを受信すれば、再試行は成功する。

上述のように、領域マップはそれぞれの領域のコピーに寄与するノードを同定する。バーチャル・マシン４１２（及びこれに含まれるそれぞれのＲＧＭ、ＭＭ及びＭＭＣコンポーメント）は領域マップ４０５へのアクセスを有する；ＪＶＭへのコピー後、領域マップのコピー４２０も図４に示した。従って、所与のノードにおけるＪＶＭ及びデータベースが領域マップを利用することができる。本発明を制限するものではない図示の実施例においては、それぞれのメタデータベースが（例えば、ネームのような）属性を有し、この属性をハッシュ処理することによって０×０乃至０×３ｆｆｆｆｆｆの整数、即ち、３０−ビット値が得られる。これらの値は符号付きの３２−ビット整数で表わすことができ、（例えば、値域のハイエンドに１を加える場合のように）オーバーフローの問題に遭遇することはない。３０ビットなら大規模クラスタにも充分な約１０億領域にも対応できる。１つの領域はハッシュ値群を表し、全領域から成るセットは考えられるすべてのハッシュ値をカバーする。領域毎にビット位置が異なり、異なるビット位置が一定の法則に従うことが好ましい。従って、それぞれの領域は好ましくはハッシュ値のＲｅｇｉｏｎＬｅｖｅｌＭａｐビットを抽出することによって導き出される数によって同定される。設定パラメータが６にセットされ、６４領域が可能な場合、得られるハッシュ値は数０×０乃至０×３ｆとなる。

既に述べたように、領域コピーは３つの状態のうちのいずれか１つの状態にある：即ち、「認証」、「バックアップ」及び「不完全」の状態である。もし領域コピーが認証コピーなら、領域に対するリクエストはすべてこのコピーに向けられ、領域毎に１つの認証コピーが存在する。領域コピーがバックアップなら、このコピーは（認証領域マネジャー・プロセスから）バックアップ・リクエストを受信する。メタデータをロード中であるが未だコピーが（多くの場合、他のバックアップ・コピーと）同期化されていなければ、領域コピーは不完全である。同期化が完了し、この時点でコピーがバックアップ・コピーになるまで、不完全領域コピーは他の状態へ昇格することができない。それぞれの領域は１つの認証コピーと（メタデータＴＰＯＦ設定パラメータによってセットされる）所与の数のバックアップまたは不完全コピーを有する。

認証領域コピーとそのＴＰＯＦバックアップ・コピーとの間の所与のプロトコル（または「契約」）を行使することによってバックアップ領域コピーを認証領域コピーと同期させる。このプロトコルを以下に説明する。

これまでの経緯として、ＭＭＣにおいて更新リクエストが受信されると、ＭＭＣはローカル領域マップを検索することによって認証領域コピーの場所を発見する。ＭＭＣは認証領域コピーと連携するＲＧＭに対して更新リクエストを送信し、このＲＧＭがこれをコミットする。更新は（認証領域コピーと連携するＲＧＭによって）ＴＰＯＦバックアップ・コピーのそれぞれのＲＧＭにも送信される。但し、認証ＲＧＭは成功を指示するために、バックアップ領域コピーと連携するそれぞれのＲＧＭが更新をコミットするのを待つ必要はなく；バックアップ領域コピーと連携するＲＧＭが更新を受信すると、このＲＧＭは直ちに（認証ＲＧＭに対して)確認を返信するか、または返信しようとする。この確認はバックアップ・リクエストが受信され、実行される前に発信される。不具合が生じない限り、認証ＲＧＭがすべての確認を受信すれば、このことがＭＭＣに通告され、ＭＭＣは手続呼び出し側に成功したことを返信する。但し、所与の不具合事象が起こると、プロトコルに従って、（バックアップＲＧＭか、認証ＲＧＭかに関係なく)問題のＲＧＭ（及びその影響下にあるノード）が運用から除外され、ＭＭリーダーによって新しい領域マップが発行される。適当な技術を利用してもよいが、好ましくはＪＶＭを停止させることによってＲＧＭを運用から除外する。新しいマップは失われた領域コピーの代替コピーとなる。このように、それぞれのバックアップ領域コピーは認証領域コピーに対する「ホット・スタンバイ」であり、（認証ＲＧＭの故障、負荷バランスのためなどの理由で）必要に応じて認証領域コピーに昇格することができる。

更新プロセスが失敗する幾つかの態様がある。例えば、（確認を待っている時に）認証領域マネジャーが（確認を待っている時に）、バックアップ・マネジャー・プロセスが作用しなかったという異議に遭遇することがあり、あるいはまた、確認を送信したにも拘わらず、バックアップ・マネジャー・プロセスが更新リクエストの処理を局所的に失敗する場合があり、さらにまた、バックアップ・マネジャー・プロセスが確認を送信している最中に、認証領域マネジャー・プロセスが作用しなかったという異議に遭遇するなどの場合もある。上述したように、もし所与のバックアップＲＧＭが更新を処理できなければ、運用から除外される。また、バックアップＲＧＭまたは認証ＲＧＭが作用不能になれば、新しい領域マップが発行される。

同期化が維持されていることを検証する手段として、起こり得る幾つかの故障シナリオを以下に説明する。第1のシナリオでは、更新リクエストを確認した後、それぞれのバックアップＲＧＭが関連のデータベースにおいて局所的にこのリクエストを成功裏に実施すると仮定する。この場合、認証スキーマとバックアップ・スキーマは同期している。第２のシナリオでは、認証ＲＧＭがバックアップＲＧＭからの（例えば、Ｊａｖａ ＩＯＥｘｃｅｐｔｉｏｎのような）異議に遭遇すると仮定する。このことはバックアップＲＧＭが故障状態にある可能性を意味する。この場合、ＭＭリーダーが新しいマップを送信するか、またはバックアップ・ノードが故障したことに気付いて自ら新しいマップの創成を開始することを認証ＲＧＭがリクエストする。（「新しいマップ」が単に現在のマップの更新バージョンであってもよいことは云うまでもない）。このプロセスの一部として、この時点においても認証ＲＧＭから入手可能な中断された更新が残余のバックアップ領域コピー及び新しい不完全領域コピーに適用される。第３のシナリオでは、認証ＲＧＭに対するバックアップ・リクエストを確認している最中に、バックアップＲＧＭが異議に遭遇すると仮定する。このことは認証ＲＧＭが故障状態にある可能性を意味する。この場合、認証領域コピーを含むノードの故障は知らされているから、ＭＭリーダーは新しいマップを送信する。もしこの更新がいずれかのバックアップＲＧＭによって行われたとしたら、新しいマップが分散させられる時点ですべての領域コピーがこの更新を利用できることになる。呼び出し側に対しては更新が失敗であったと報告されるが、実際には更新が成功したのであるから、偽ネガティブという結果になる（但し、これは許容し得る挙動である）。いずれのバックアップＲＧＭによっても更新が行われなかった場合、更新は消失し、呼び出し側に対して失敗であったと報告される。第４のシナリオでは、バックアップＲＧＭが確認受信後、バックアップ・リクエストの処理に失敗すると仮定する。この場合には、上述したように、失敗と同時にバックアップＲＧＭがシャットダウンする。このシャットダウンを確実にするため、予期せぬ事態が発生すると同時にシャットダウンを実施する（例えば、Ｊａｖａ ＳＱＬＥｘｃｅｐｔｉｏｎなど）。これにより、同期化関係を確保できなくなると、バックアップ領域は確実に運用から除外される。このような場合、ノーマル・マップ再編成プロセスが別のノードに新しいバックアップ領域コピーを創成する。少なくとも認証領域コピーにおいて更新がなされ、従って、新しいバックアップ領域コピーは認証領域コピーと同期化される。第５のシナリオでは、局所的にコミットする前に認証ＲＧＭが故障すると仮定する。このような場合、メタデータ更新は存在せず、リクエストは失敗する。

上記以外にも種々のシナリオが想定されるが、上記シナリオから、本発明が認証領域コピーとそのＴＰＯＦバックアップ領域コピーとの間の同期化を保証する態様が理解されるであろう。

既に述べたように、領域マップはそれぞれの領域のそれぞれのコピーのオーナーシップを記述する。例えば、図５はメタデータＴＰＯＦ＝２の４−ノード・クラスタに関する領域マップを示す。この例において、領域０に関してはノード１が認証であり、ノード２及び３がバックアップ、領域１に関してはノード２が認証、ノード３及び４がバックアップというように順次指定されている。本発明では、クラスタの拡張に合せて、特定領域の管理（オーナーシップ）を変化させるためネームスペース区分スキーマを利用する。ダイナミックな拡張を可能にする方法の１つはハッシュ値数を構成するビット数を決定するｒｅｇｉｏｎＭａｐＬｅｖｅｌ設定パラメータを増分することである。クラスタの拡張に伴い、領域マップの１つまたは２つ以上の区分が「スプリット」される。スプリット操作にはハッシュ値のもう１つのビットが利用され、これに合せてメタデータの再分散が行われる。例えば、レベル６におけるマップと、ハッシュ値が０×１０００００２ａ及び０×１０００００６ａである２つのメタデータ・オブジェクトを考察されたい。これらのハッシュ値（１６進法 ０×２ａ、「２」は２進「００１０」、「６」は２進「０１１０」）の最後の６ビットは同じである；従って、双方のオブジェクトは領域０×２ａに該当する。もしマップ・レベルが７にまで上昇すると、領域は０乃至０×７ｆとなり、双方のオブジェクトは別々の領域、即ち、０×２ａと０×６ａに分けられる。

このアプローチを使用してもよいが、すべての領域を同時にスプリットされねばならない。この方法よりも好ましい方法は領域を増分的にスプリットすることである。このため、ネームスペース区分スキーマが領域を順次、即ち、領域０に始まり、現時点レベルの最終領域で終わるようにスプリットする。領域はハッシュ値のもう１つのビットを使用してスプリットする。図６はこのプロセスを示す。この実施例においては、マップ・レベル１に２つの領域６０２（ノード０）及び６０４（ノード１）が存在する。ノード番号が２進法で示されている。マップの拡張が必要な場合、区分スキーマがハッシュ値のもう１つのビットを使用して領域０をスプリットする。その結果、３つの領域６０６、６０８及び６１０が創成される。新しいビットが０であるオブジェクトは領域６０６（ノード００）にとどまり、残余のオブジェクトが新しい最終領域６１０（ノード１０）に移る。スプリットの結果として付加されるビットをイタリック文字で示す。即ち、００及び１０である。尚、最初と最後の領域６０６及び６１０は２つのビットを使用するのに対して、中央（スプリットされていない）領域は１つだけのビットを使用する；それでも、ナンバリング・スキーマは正しく作用する。即ち、左から右へ見て、｛０、１、２｝となる。さらに拡張させるには、領域１をスプリットして４つの領域６１２（ノード００）、６１４（ノード１）、６１６（ノード１０）及び６１８（ノード１１）を創成する。これによってレベル２が完成する。領域マップが再び拡張しなければならない場合、スキーマが００乃至０００をスプリットし（即ち、ハッシュ値のもう１つのビットを加えることによる）、末尾に新しい領域を加える（同様にハッシュ値のもう１つのビットを加えることによる）。結果として領域マップは図示のように５つの領域６２０、６２２、６２４、６２６及び６２８を有する。

領域数がノード数と一致しなくてもよい。換言すれば、独立ノード・アレイにおいて、領域数はノード数と相関関係にはない。

従って、１つの実施態様として、メタデータ・オブジェクトを領域に配置し、領域を増分的にスプリットすることによって領域を管理する。領域コピーは（認証、バックアップ、不完全の別なく)それぞれのノードにおけるデータベースに記憶される。既に述べたように、メタデータ操作は認証ＲＧＭによって行われる。しかし、ノードが故障すると、幾つかの領域コピーが失われる。既に述べたように、領域のバックアップ・コピーの１つを認証領域コピーに昇格させることによって利用可能度を回復することができ、これには数秒もあれば充分である。バックアップを昇格させるこの短いインターバルの間、ＭＭＣから領域へ送信されるリクエストは失敗に終わる。この失敗は意義としてＭＭＣによって認識され、ＭＭＣは遅れてリクエストを再試行する。但し、リクエストが再試行されるまで、更新されたマップは定位置にあるから、ＭＭＣユーザに対するサービスが中断されることはない。上述したように、このアプローチは領域のコピー（好ましくはコピーのすべて）が同期関係にあることを前提とする。

従って、メタデータ管理システムは領域のコピーを同期化された状態に維持する。認証領域コピー中のオブジェクトに対して行われる更新はそのままバックアップ領域コピーにおいて複製される。認証ＲＧＭによって更新が行われると、これと同じ更新がすべてのバックアップ領域コピーに適用される。これとは対照的に、汎用分散データベースでは異なるサイトにおいて異なる更新が行われることがあり、特定の更新サイトがロールバックを必要とするような問題に遭遇することがある。本発明では、１つの領域の１つのコピー内で、他のすべてのコピーにおいて実行されるのと同じ順序で１つずつリクエストを実行することが好ましい。例えば、デッドロックまたはうっかりのロック忘れがあってもトランザクションを中断する必要はない。典型的には、リクエストの実行が失敗する原因は例えばディスクのクラッシュ、データベースの容量不足などのようなノード故障に限られる。しかし、メタデータ管理システムは（ノード・レベル、領域管理レベルなど、レベルに関係なく）このような故障があれば、故障ノードにおける領域コピーを配置換えするように作用する；従って残余の領域コピーのインテグリティが保証される。詳しく後述するように、本発明では、もし認証ＲＧＭを含むノードが故障しても、アックアップＲＧＭは（更新実行中であるか否かに関係なく）同期関係を保つか、または中断された更新によってのみ同期状態から逸脱する。後者の場合、同期関係の回復は容易である。バックアップ領域は認証領域と同期化された状態に維持されるから、（バックアップから認証への）昇格は一瞬で行われる。

ノードの故障はバックアップ領域の消失につながり易い。バックアップ領域は他のノードに新しい不完全領域を創成することによって回復される。不完全領域が創成されるや否や、記録更新が開始され、認証領域からのデータ複写が開始される。複写が完了すると、累積更新が当てはめられ、更新されたバックアップが形成される。新しいバックアップ領域はＭＭリーダーに対して、最新バージョンであることを通告し、これに応答してＭＭリーダーは領域の（不完全からバックアップへの）昇格を含むマップを送信する。

本発明によるバックアップ領域維持に関するさらなる詳細を以下に説明する。

既に述べたように、バックアップ・スキーマは同期関係にある領域のバックアップ・コピーの１つまたは２つ以上（好ましくはすべて）に依存するから、それぞれのバックアップ・コピーは「ホット・スタンバイ」である。バックアップ領域は下記のように維持される。メタデータ・オブジェクトは認証ＲＧＭに対してリクエストを送信することによって創成または変更される。リクエストの実行は多くの場合下記のように進められる：
それぞれのバックアップ領域マネジャーのためにローカル・データベースを更新し、
データベース更新をコミットし、
バックアップ領域マネジャーに対してバックアップ・リクエストを送信し、
バックアップ・リクエストの確認を待ち、
管理を呼び出し側に戻す
バックアップ・リクエストに時間切れの規定はない。バックアップＲＧＭからの異議が遠隔ノードが故障したことを示唆する。管理エンジンがこの異議に気付き、ＭＭリーダーにこの故障を知らせる。その結果、他の場所に新しい不完全領域コピーが創成される。次いで、この不完全領域コピーを記述する新しい領域マップが分散させられる。従って、認証ＲＧＭはこの異議を無視することができる。

バックアップ・リクエストの受信側はこのリクエストを確認し、リクエストされた更新をローカル・データベースに適用する。最も新しく受信されたバックアップ・リクエストはバックアップ領域の回復に利用される。最新のリクエストだけが必要とされるから、新しいバックアップ・リクエストが受信され、実行される時、先行のリクエストは廃棄してもよい。

バックアップ領域コピーがホット・スタンバイとして使用されるためには、認証領域コピーと同期関係に維持されていなければならない。既に述べたように、領域コピーが(バックアップから認証へ）昇格する前に最新の更新と同期化させる方法がスキーマによって可能になる。従って、バックアップ・リクエストの受信を確認した後（可能なら）、バックアップＲＧＭはこの更新をローカル・データベースにコミットするか、または運用から撤退する。図示実施例の場合、バックアップＲＧＭは所与のプロセス、例えば、ＪＶＭを停止させるか、または適当な領域を消去することによって運用から撤退することができる。従って、このスキーマによれば、もしバックアップＲＧＭが存在するなら、認証ＲＧＭと同期化される。

本発明のメタデータ管理システムの実施態様のさらなる詳細を以下に説明する。

ノード内及びノード間通信は片方向リクエスト・パターン、確認リクエスト・パターンまたはリクエスト/レスポンス・パターンに基づいて行うことができる。片方向リクエスト・パターンの場合、リクエストは１つまたは２つ以上の受信側に向かって送信される。それぞれの受信側がこのリクエストを実行する。送信側は確認または回答を期待しない。確認リクエスト・パターンの場合、リクエストは１つまたは２つ以上の受信側に向かって送信される。それぞれの受信側は受信を確認してからリクエストを実行する。リクエスト/レスポンス・パターンの場合、１つまたは２つ以上の受信側に向かって送信される。それぞれの受信側がリクエストを実行し、送信側に対して回答を送信する。回答が組み合わされ、リクエストの実行を集約するオブジェクトを生む。バックアップ領域コピーの正当性を保証したい場合に確認リクエスト・パターンが使用される。これらの通信パターンはＭＭＣ及びＲＧＭ間の、ＲＧＭ間の、ＭＭ間の、及びシステム・コンポーネントとＭＭＣ間の種々の相互作用に利用される。

上述したように、ＭＭリーダーは、ノードがクラスタから離脱するか、ノードがクラスタと結合するか、または不完全領域コピーがローディングを完了すると、領域マップを創成する。第１のケース、即ち、ノードがクラスタから一時的にせよ恒久的にせよ離脱すると、このノードにおいてＭＭによって管理される領域は配置換えされねばならない。第２のケースは、ノードが再び運用されるか、またはノードが初めてクラスタと結合する場合であり、この場合、他のＭＭｓの負担を軽くするように領域が配置される。新しいノードにおいて創成される領域はすべて不完全である。これらの領域はデータ・ローディングが完了するとバックアップに昇格する。第３のケースは不完全領域がデータ・ローディングを完了すると同時に発生する状況である。この時点で領域はバックアップに昇格する。マップ創成アルゴリズムは、所与のノードが領域のコピーを２つ以上含まず、クラスタ全体に亘って認証領域がバランス良く配分され、すべての領域がクラスタ全体に亘ってバランス良く配分されるようにするアルゴリズムであることが好ましい。すべてのＲＧＭがすべてのメタデータ更新を処理し、従って、クラスタ全体に配分されねばならないから、上記第2及び第３の条件が必要になる。

マップ創成アルゴリズムに関するさらなる詳細を以下に説明する。

ＭＭリーダーが新しいマップの創成を必要とする場合、先ずは領域の調査を行う。そのためには、リクエスト／レスポンス・メッセージ・パターンを利用して、現時点においてクラスタ中に存在するそれぞれのノードにおけるＭＭに対してリクエストを送信する。リクエスト／レスポンス・パターンは好ましくは、すべてのレスポンスを組み合わせて、如何なる領域がアーカイブ中に存在するかを示す完全な画像を形成する集合ステップを含む。領域調査によって得られる情報は領域コピー毎に下記の要項を含むことが好ましい：領域コピーを所有するノード、（もし存在するとして）領域マネジャーによって処理された最新の更新、及び領域のデータベース・スキーマに記憶されている時刻印。領域時刻印は調査から削除された、もはや使用されることのない領域を同定するのに利用される。これによって、廃用の領域が創成中のマップから除外され、廃用領域スキーマが削除されることになる。多くの場合、廃用領域コピーは創成中の領域コピーのマップ・バージョン・ナンバーよりも低位のマップ・バージョン・ナンバーを持つことになる。但し、常にこのようになるとは限らない。ノード・クラッシュのため、新しいマップの創成が必要になった場合、領域調査が残余の領域を発見し、新しいマップを形成する。もし、不成功に終わったノードが時間内に再起動して領域調査に応答すると、ノードは何事もなかったかのようにその領域を報告することになる。しかし、これらの領域はいずれも、ノードがダウンしている間は更新されなかったから、廃用領域である。この問題を解決する方法は領域調査に伴う領域時刻印を調査することである。それぞれの領域コピーは最近行われた更新の時刻印を表す領域時刻印を報告する。或る領域の最大時刻印が（ｖ，ｕ）であると仮定する。領域コピーは同期化されているから、有効な時刻印は（ｖ，ｕ）と（ｖ，ｕ-１）である。このことから、不成功に終わった領域が最新のマップ・バージョン・ナンバーを有していようと廃用マップ・バージョン・アンバーを有していようと、廃用領域が同定される。ノードが失敗し、速やかにサービスに復帰し、廃用領域に基づいてリクエスト処理を開始する恐れはない。その理由は、このノードは再起動時には領域マップを持たず、マップが受信されるまでＲＧＭは存在しないからである。ＭＭＣからのリクエストはＲＧＭが創成されるまでは処理不能である。即ち、失敗したノードが迅速に再起動しても、新しいマップを得るまではリクエストを処理することはできず、新しいマップが得られると、モードはその古い領域を廃棄する。

領域調査後、下記のように初期領域が形成される。もし、領域調査の結果、領域が全く発見されない場合にクラスタは初めて起動する。この場合、先ず認証領域オーナーが配置される。それぞれの配置には、アルゴリズムは最もビジーでないノードを選択する。最もビジーでないノードは領域コピーが最も少ないノードである。所有される認証コピーの数に基づいて問題が解決される。認証コピーのオーナーを割当てたら、バックアップ領域のオーナーを割当て、認証領域のオーナーと総量域のオーナーをバランスさせる。新しいマップがすべてのＭＭに送信され、ＭＭはマップによって記述される領域を創成する。

クラスタが起動すると、下記の順序でマップ変形を行うことよってマップを変化させることが好ましい：（１）(ノードの故障が原因で）領域が認証コピーを持たない場合にはバックアップを昇格させ；（２）領域がＴＰＯＦ以上のバックアップを有する場合には余計なバックアップを削除し；（３）（ノードの故障または認証への昇格のせいで、領域がＴＰＯＦよりも少ないバックアップを有する場合、新しい不完全領域コピーを創成し；（４）オーナーシップを再バランスさせ；（５）認証オーナーシップを再バランスさせる；（５）認証オーナーシップを再バランスさせる。ステップ（４）では最もビジーなノードを発見し、その領域の１つを、オーナーシップ・カウントが少なくとも２だけ低いノードに配置換えする。（もしターゲット・ノードのオーナーシップ・カウントが１だけ低ければ、配置換えはワークロードのバランスを助けることにはならない。）好ましくは、新しい不完全領域を創成することによってこれを行うことが好ましい。ステップ（５）では、最大数の認証領域を発見し、認証オーナーシップ・カウントが少なくとも２だけ低いバッ
クアップを発見する。このステップは、例えば、バックアップを昇格させ、認証を降格させることによって応答性を交換する。ノードが所有する認証領域の最大数を減らしている間は、このオペレーションが継続される。

ノードがクラスタから離脱すると、ステップ（１）及び（３）がノードの離脱によって生じた領域マップのギャップを埋める。次いで、ステップ（４）及び（５）を利用することによって、必要なら、ワークロードを均衡させる。

ノードがクラスタをつなぎ合わせると、ステップ（１）−（３）は何も変化させない。これとは対照的に、ステップ（４）は新しいノードに配置される不完全領域群を生む。不完全領域がデータ・ローディングを完了すると、このことがＭＭリーダーに通告される。マップは不完全領域をバックアップに昇格させる。ステップ（５）新しいノードに認証領域を配置する効果を有する。

不完全領域がその同期化を終えると、バックアップに変換し、ＭＭリーダーに通告する。ＭＭリーダーは少なくとも１つの領域にＴＰＯＦ以上のバックアップを含む新しいマップを発行する。

ＭＭが新しいマップを受信すると、新しいマップを現在マップと比較し、ＭＭによって管理されるそれぞれの領域について、何らかの変化を加える必要がある。考えられる変化として、下記のような変化が考えられる：領域を消去し、領域を創成し、バックアップ領域を認証領域に昇格させ、不完全領域をバックアップ領域に昇格させ、認証領域をバック領域に降格させる。第1のタイプの変化については、ロード・バランスによって領域コピーの管理を１つのノードから他のノードに移動させ、コピーを消去することができる。この場合、ネットワーク及びデータベース資源が、領域のデータを記憶するスキーマの消去を含めて戻される。領域を創成する第２のタイプの変化は、認証及びバックアップ領域の創成に伴い、新しいクラスタにおいて起こるのが普通である。この後、不完全領域だけが創成される。領域創成に伴い、メタデータ・オブジェクトのタイプ毎のテーブルを含むデータベース・スキーマが創成される。それぞれの領域のスキーマは領域の役割（認証、バックアップまたは不完全）を同定する情報を含む。バックアップから認証への昇格である第３タイプの変化は領域の役割の変更を必要とする。その他の変化タイプでは、その名称が暗示するように、領域の役割が不完全からバックアップへ、または認証からバックアップへ変化する。

不完全領域はデータなしの状態から始まる。上述したように、他の領域コピーと同期化するとバックアップ領域に昇格される。この同期化プロセス中に領域は更新される過程にあるから、これは慎重に行われねばならない。大量のデータを素早くＰｏｓｔｇｒｅｓデータベースにロードするには、すべての索引及びトリガーをドロップしてから、ＣＯＰＹコマンドを使用してデータをロードすればよい。代表的な実施態様としての完全な手順は下記の通りである：(1)空スキーマを創成し；（２）テーブル毎に、パイプを介して接続される２つのＣＯＰＹを利用する；即ち、第1ＣＯＰＹは遠隔の認証領域からデータをちゅうしゅつし、第２ＣＯＰＹはローカル不完全領域にデータをロードする；（３）(外部ファイル・メトリックスを維持するため）トリガーを加え；（４）索引を加える。バックアップ領域と同様に、不完全領域はバックアップ・リクエストを処理する。バックアップ領域はデータベースを更新することによってこれらのリクエストを実施する。トリガー及び索引がないから不完全領域はこれを行うことができない。これに反して、バックアップのリクエストはデータベースに記録されている。データがロードされ、トリガー及び索引が回復されると、累積された更新リクエストが処理される。更新リクエストが処理されている最中に更なる更新リクエストが入ってくることがある；これらのリクエストは待ち行列させられるが、処理される。所与の時点で、入来するリクエストが阻止され、待ち行列が空になると、領域は入来するバックアップ・リクエストの処理に切り替わる。この切り替えが行われると、領域はＭＭリーダーに対して、バックアップ領域に昇格させてもよいことを通告する。

後述するように、ＭＭコンポーネント間の幾つかの相互作用を慎重に同期化しなければならない。

メタデータのテーブルが一時的に不正確になる恐れがあるから、マップ更新をリクエスト実行と同時にいってはならない。例えば、ＲＧＭが認証からバックアップへ降格されている最中に更新リクエストがＲＧＭに入来したと仮定する。この場合、降格の過程でリクエストの実行が開始される可能性がある。ローカルな更新となり、バックアップ・リクエストが発信されることになる。ところが、ＲＧＭは（誤った挙動である）自らのバックアップ・リクエストを受信し、新しい認証領域がバックアップ・リクエストを受信することになる。一方、バックアップ・リクエストが処理を終える前にオブジェクトに対するリクエストが新しい認証領域に送信され、結果として、探索が不正確なものとなる。別の例として、不完全領域がデータ・ローディングの最中である場合、バックアップ・リクエストはデータベースの末尾に保管される。ローディング完了と同時に待ち行列のリクエストが処理される。これらがすべて処理されて初めて、更新リクエストが受信される毎に処理される。累積リクエストの実行から入来リクエストの実行への切り替えはアトミックアクションの形で行われねばならない。さもないと、更新が失われる恐れがある。このような問題はＲＧＭ毎のロックを創成することによって回避され、このようなロックを創成することによって個々のＲＧＭによるリクエスト実行を保護することが好ましい。

本発明は多くの利点を提供する。ノードの各メタデータ・マネジャーはクラスタ全体のためのメタデータの所与の部分を管理する。即ち、所与のノードに記憶されているメタデータは（メタデータの）分散データベースの一部を構成し、理論的には、データベースはクラスタに含まれるすべてのノード（または所与のノード・サブセット）に均等に分散されていることになる。メタデータ・マネジャーは互いに協働して上記の機能を達成する。クラスタに新しいノードが追加されると、個々のノードの役割が新しい容量に合せて調整され、このステップには、新しいメンバーが等分の役割を担うようにすべてのノードにメタデータを再分散させるステップが含まれる。これとは逆に、ノードが故障し、クラスタから除外されると、残りのノード・メタデータ・マネジャーが分担を増やすことによって、減少した容量を補償する。データ喪失を防止するため、好ましくは複数のノードに亘ってメタデータ情報を複製し、これらのノードがクラスタ全体のメタデータの何%かをそれぞれ直接管理し、このデータを残りのノード群に亘って複製する。

新しいマップが創成されると、ＭＭリーダーはこのマップを他のノードに分散させ、すべてのノードがこのマップを持つまで処理を中断するようリクエストする。すべてのノードがこのマップを持ったことをシステムが確認すると、処理が再開される。

本発明はディジタル・アセットを捕捉、保存、管理、及び検索するようにデザインされたアーカイブ管理を容易にする。このデザインは多様な必要条件を念頭に置いたデザインである：即ち、無制限のストレージ、高い信頼性、自律的管理、規制順守、ハードウェアからの独立、及び既存のアプリケーションとの一体化の容易さである。
これらの必要条件のそれぞれを以下に説明する。

商品ハードウェアで実行される（例えば）Ｌｉｎｕｘのクラスタは堅牢なプラットホームと、殆ど無制限のアーカイブを可能にする。このシステムは、例えば、数個のストレージ・ノード・サーバーから数千テラバイトのデータを記憶する多数のノードまで拡張することができる。この独自の構造により、記憶容量は組織の増大するアーカイブ需要にペースを合せて増大することができる。

このシステムはファイルを絶対に喪失しないように構成されている。アーカイブ装置故障から保護されるようにクラスタ全体に亘ってデータを複製する。ディスクまたはノードが故障すると、クラスタは自動的に、同じデータの複製を保持しているクラスタ中の他のノードが肩代わりする。

本発明は自律的な処理によってアーカイブ・ストレージのコストを軽減する。例えば、ノードがアーカイブと接合したり、アーカイブから切り離されると、システムは自動的にクラスタの負荷バランスを調整し、構成ノード全体に亘ってファイルを再分散させることによって性能を最適化する。

本発明は政府規制及び業界規制や、金融書類及び医療データのような記録の長期保存に関連して企業を支援することができる。この利点はワーム（ＷＯＲＭ）保証やユーザ定義の保存ポリシーとの整合を容易にする時刻印を実施することによって達成される。

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

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

本発明の実施例によって行われるオペレーションの特定の順序を以上に述べたが、この順序は飽くまでも例であり、上記とは異なる順序でオペレーションを行うか、幾つかのオペレーションを組み合わせたり、オーバーラップすることなども可能である。所与の実施態様は特定の構成要件、構造、または特徴を含むことができるが、すべての実施態様が必ずこのような構成要件、構造、または特徴を含まねばならないわけではない。

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

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

本発明の実施例としての固定内容記憶アーカイブの簡略化ブロックダイヤグラムである。 それぞれが対称性を有し、本発明のアーカイブ・クラスタ・アプリケーションを支援する独立ノード冗長アレイの簡略図である。 所与のノードにおいて実行するアーカイブ・クラスタ・アプリケーションの構成コンポーネントのハイレベル・ブロック図である。 クラスタの所与のノードにおけるメタデータ管理システムの構成コンポーネントを示す説明図である。 領域マップの説明図である。 クラスタの規模の拡大に呼応した領域マップの変化を容易にするネームスペース区分スキーマの使用法を示す説明図である。

Claims (19)

1. ネットワークを構成するノードの冗長アレイにおけるメタデータ管理方法であって、各ノードがオブジェクト形式の記憶を行ない、アプリケーションのインスタンスを実行することで前記オブジェクトに対する処理が実行され、各ノードは、プロセッサ及びメモリ、記憶手段を有し、前記メモリに格納されたプログラムを前記プロセッサで実行することにより、メタデータ管理手段、メタデータ管理クライアント手段を実現するものであり、
   メタデータ・オブジェクトは、所与の領域の同定が前記メタデータ・オブジェクトの属性をハッシュし、得られたハッシュ値の所与のビット組み合わせを抽出することによって行なわれる、アレイ全体に亘って分散させた領域群に記憶されており、
   前記メタデータ管理手段は、前記メタデータ・オブジェクトに対応する領域毎に、該領域の認証領域コピーをノードの中に記憶し、この領域に向けられる更新リクエストを受信し、これに回答するノードと、各々が該領域のバックアップ領域コピーを記憶し、該認証領域コピーに対するバックアップとして作用できるゼロまたは１つ以上のノードと、を同定するマップを作成するものであり、
   前記マップは、各ノードが前記メタデータ・オブジェクトの記憶位置を示す同一のグローバル・ビューを有するように、ノードのアレイ全体に分散されており、
   前記メタデータ管理クライアント手段は、所与のメタデータ・オブジェクトの更新リクエストを受信すると、前記マップから前記メタデータ・オブジェクトの記憶位置を取得することにより該メタデータ・オブジェクトに対応する領域の認証領域コピーを記憶するノードを同定し、
   前記メタデータ管理手段は、同定された前記ノードが前記更新リクエストを処理する場合、認証領域コピーまたはこれと関連するバックアップ領域コピーと関連する故障の発生により、認証領域コピーとこれと関連するバックアップ領域コピーとの間の同期関係を維持できなければ、前記バックアップ領域コピーの１つを認証領域コピーに変換して、その旨を記憶した新しいマップを発行し、
   前記メタデータ管理手段は、アレイ中に現存する何れのノードが何れのコピーを有するかの調査を行い、現在使用されていない領域を示す廃用の領域があった場合、前記マップから前記廃用の領域を除外する
   ことを特徴とするメタデータ管理方法。
2. 前記メタデータ管理クライアント手段は、前記認証領域コピーを記録するノードに対する更新を行う場合、ゼロまたは１つ以上の前記バックアップ領域コピーを記憶するそれぞれのノードに向けて前記更新リクエストを発信することを特徴とする請求項1に記載の方法。
3. 前記更新リクエストを受信すると、前記更新リクエストが実行されるか否かに拘らず、前記バックアップ領域コピーを記憶するノードから確認が発信されることを特徴とする請求項２に記載の方法。
4. ノード数の増大に伴って、各ノードが割り当てられた前記マップの領域を分割し、分割して増えた領域に増大したノードを割り当てることを特徴とする請求項1に記載の方法。
5. 各ノードが割り当てられたマップの領域を分割し、前記ハッシュ値の所与の第２の桁の値を不変に維持しながら、所与の第１の桁の値を調整することによって、ハッシュ値を分類し、分割して増えた領域に増大したノードを割り当てることを特徴とする請求項４に記載の方法。
6. ハッシュ値にビットを加えることによって所与の第１ハッシュ値を調整することを特徴とする請求項５に記載の方法。
7. 認証領域コピー及びバックアップ領域コピーをノード全体に分散させることによってノード毎の認証領域コピー数をバランスさせることを特徴とする請求項１に記載の方法。
8. 認証領域コピー及びバックアップ領域コピーをノード全体に分散させることによってノード毎の認証領域コピー数をバランスさせるとともに、ノード毎の認証領域コピー及びバックアップ領域コピーの総数をバランスさせることを特徴とする請求項１に記載の方法。
9. 所与の領域のバックアップ領域コピー数が設定可能であることを特徴とする請求項１に記載の方法。
10. 新しいマップを発行する場合、バックアップ領域コピーを認証領域コピーに昇格させることを特徴とする請求項１に記載の方法。
11. 領域が不完全領域コピーをも含み、不完全領域コピーはバックアップ領域コピーに昇格するには不適格であることを特徴とする請求項１０に記載の方法。
12. 新しいマップを発行する場合、前記メタデータ管理手段が領域コピーを削除するステップ、領域コピーを創成するステップ、バックアップ領域コピーを認証領域コピーに昇格させるステップ、不完全領域コピーをバックアップ領域コピーに昇格させるステップ、認証領域コピーをバックアップ領域コピーに降格させるステップのいずれか１つを行うことを特徴とする請求項１に記載の方法。
13. ネットワークを構成するノードの冗長アレイにおけるメタデータ管理方法であって、前記ノードは、プロセッサ及びメモリ、記憶手段を有し、前記メモリに格納されたプログラムを前記プロセッサで実行することにより、メタデータ管理手段、メタデータ管理クライアント手段を実現するものであり、
    メタデータ・オブジェクトは、所与の領域の同定が前記メタデータ・オブジェクトの属性をハッシュし、得られたハッシュ値の所与のビット群を抽出することにより行なわれる、アレイ全体に分散させた領域群に記憶されており、
    前記メタデータ管理手段は、前記メタデータ・オブジェクトに対応する領域毎に、該領
    域の認証領域コピーをノードの中に記憶し、この領域に向けられる更新リクエストを受信し、これに回答するノードと、各々が該領域のバックアップ領域コピーを記憶し、該認証領域コピーに対するバックアップとして作用できるゼロまたは１つ以上のノードと、を同定するマップを作成するものであり、
    前記マップは、各ノードが前記メタデータ・オブジェクトの記憶位置を示す同一のグローバル・ビューを有するように、ノードのアレイ全体に分散されており、
    前記メタデータ管理手段は、
    所与の認証領域コピーとこれと関連するゼロまたは１つ以上のバックアップ領域コピーとの同期関係が保証されるようにマップを維持し、
    認証領域コピーまたはこれと関連するバックアップ領域コピーと関連する故障の発生により、認証領域コピーとこれと関連するバックアップ領域コピーとの間の同期関係を維持できなければ、前記バックアップ領域コピーの１つを認証領域コピーに変換し、その旨を記憶した新しいマップを発行して、アレイ全体に亘って新しいマップを分散させ、
    前記メタデータ管理手段は、
    アレイ中に現存する何れのノードが何れのコピーを有するかの調査を行い、
    現在使用されていない領域を示す廃用の領域があった場合、前記マップから前記廃用の領域を除外する
    ことを特徴とするメタデータ管理方法。
14. 故障の結果として領域に認証領域コピーがなくなった場合、前記マップの所与の領域においてバックアップ領域コピーを認証領域コピーに昇格させることを特徴とする請求項１３に記載の方法。
15. 領域が設定可能なバックアップ領域コピー数よりも多くなった場合、前記メタデータ管理手段は、余剰のバックアップ領域コピーが削除された新しいマップを作成することを特徴とする請求項１３に記載の方法。
16. 故障または昇格の結果として領域が設定可能なバックアップ領域コピー数よりも少なくなると、前記メタデータ管理手段は、新しい不完全領域コピーが創成された新しいマップを作成することを特徴とする請求項１３に記載の方法。
17. 前記メタデータ管理手段は、領域コピーを１つのノードから他のノードへ配置換えした新しいマップを作成することを特徴とする請求項１３に記載の方法。
18. 配置換えされる領域コピーが認証領域コピーであることを特徴とする請求項１７に記載の方法。
19. メタデータ・オブジェクトがアレイ全体に分散させた領域群に記憶され、所与の領域の同定がメタデータ・オブジェクトの属性をハッシュし、得られたハッシュ値の所与のビット群を抽出することにより行なわれる、ネットワークを構成するノードの冗長アレイであって、
    バーチャル・マシンと；
    データベースと；
    前記メタデータ・オブジェクトに対応する領域毎に、該領域の認証領域コピーを記憶し、この領域に向けられる更新リクエストを受信し、これに回答するノードと、各々が該領域のバックアップ領域コピーを記憶し、該領域の該認証領域コピーに対するバックアップとして作用できるゼロまたは１つ以上のノードと、を同定する、データベースに記憶されたマップと、
    所与の認証領域コピーまたはバックアップ領域コピーに対して更新リクエストを実行する、バーチャル・マシンにおいて実行される１つまたは２つ以上の領域マネジャー・プロ
    セスと、
    １つまたは２つ以上の領域マネジャー・プロセスを発生させ、且つ管理するためのメタデータ・マネジャー・プロセスと、
    更新リクエストを受信し、これに応答するクライアント・プロセスとを有し、
    前記マップは、所与の認証領域コピーとこれと関連するゼロまたは１つ以上のバックアップ領域コピーとの同期関係が保証されるように構成されており、前記メタデータ管理手段は、認証領域コピーまたはこれと関連するバックアップ領域コピーと関連する故障の発生により、認証領域コピーとこれと関連するバックアップ領域コピーとの間の同期関係が継続できなければ、前記バックアップ領域コピーの１つを認証領域コピーに変換し、その旨を記憶した新しいマップを発行して、アレイ全体に亘って新しいマップを分散させ、
    メタデータ・マネジャー・プロセスは、アレイ中に現存する何れのノードが何れのコピーを有するかの調査を行って、現在使用されていない領域を示す廃用の領域があった場合、前記マップから前記廃用の領域を除外することを特徴とするノードの冗長アレイ。

Images