(57)【要約】好ましくは対称ノードから成るアーカイブ・ストレージ・クラスタであって、これに含まれるデータ保護管理システムは定期的にその時利用可能なノードを、それぞれのセットがｎ個のノードから成り、「ｎ」が設定可能な「データ保護レベル」（ＤＰＬ）を表わす１組または２組以上の保護セットに組織する。形成時点では、その時利用可能なノードが１つの、唯１つの保護セットのメンバーであるという意味で、所与の保護セットは閉の状態にある。オブジェクトをアーカイブ内に保管する時、データ保護管理システムは（直接またはストレージ・マネジャーを介して）オブジェクトを所与の保護セットの所与のノード内に保管し、次いで、このオブジェクトのコピーが所与の保護セット内の他のノードへの分散を強制する。その結果、１つのオブジェクトのすべてのＤＰＬコピーが同じ保護セット内に、即ち、その保護セットだけに保管する。このスキームによって、クラスタ全体としてのＭＴＤＬが有意に改善される。所与の保護セットのノード内で多重故障が発生してもデータが失われるだけだからである。クラスタ内でランダム分布の状態で故障が発生する恐れは殆どない。
2009527824.tif 000002
【特許請求の範囲】
【請求項１】
一括してネットワーク化され、個々のノードがオブジェクトに基づくストレージを提供するアプリケーション・インスタンスを実行するように冗長配列されている個別ノードにおける保護管理方法であって、
１つまたは２つ以上の保護レベルから成るセットのそれぞれに照らして、保護セット内のノード数が所与の保護レベルと関数関係にあり、分類の時点において、所与のノードが１つの、且つ唯一の保護セットのメンバーであるようにノードを１つまたは２つ以上の保護セット内に分類し；
所与の保護セット内のノードに所与のオブジェクトを保管する一方、所与のオブジェクトの１つまたは２つ以上のコピーを所与の保護セットだけのノード内に保管するステップを含む保護管理方法。
【請求項２】
保護レベルをデータ保護レベル（ＤＰＬ）として定義する請求項１に記載の保護管理方法。
【請求項３】
ノードを分類するするステップにおいて、保護セット・マップを作成し、これを冗長配列内の他のノードに対して同報通信する請求項１に記載の保護管理方法。
【請求項４】
保護セット・マップ作成のステップにおいて、
冗長配列を構成しているそれぞれのノードの現時状態に関する情報を求め;
少なくとも第１保護セットに関して、第１保護セット中の所与のノードが所与の状態にあるかどうかを判断し；
もし第１保護セット中の所与のノードが所与の状態にあれば、第１保護セットを解体し；
所与の保護レベルに関連して、現時点で未分類の少なくとも１つの他のノードを、解体された第１保護セットの１つまたは２つ以上のノードと共に分類する請求項３に記載の保護管理方法。
【請求項５】
冗長配列のうちの所与のノードにおいて分類ステップを行なう請求項１に記載の保護管理方法。
【請求項６】
リーダー選択を利用して冗長配列中の所与のノードを選択するステップをも含む請求項５に記載の保護管理方法。
【請求項７】
所与の事象毎に定期的に分類を更新するステップをも含む請求項１に記載の保護管理方法。
【請求項８】
所与の事象が保護セット内の所与のノードの故障または冗長配列への新しいノードの追加である請求項７に記載の保護管理方法。
【請求項９】
所与のオブジェクトが冗長配列中に保管されるため提出された外部ファイルの内部ファイル・コンポーネントである請求項１に記載の保護管理方法。
【請求項１０】
それぞれのノードがオブジェクトに基づくストレージを提供するアプリケーション・インスタンスを実行するように一括してネットワーク化された個別のノードから成る冗長配列において行なわれる、平均データ・ロス時間（ＭＴＤＬ）を改善する方法であって、
保護セット内のノード数が所与の保護レベルと関数関係にある１つまたは２つ以上の保護レベルのそれぞれについて、ノードを１つまたは２つ以上の保護セットに分類し、マップ作成の時点において、所与のノードが１つの、且つ唯一の保護セットのメンバーとなるデータ構造を形成し；
所与の保護セット内のノードに所与のオブジェクトを保管する一方、所与のオブジェクトの１つまたは２つ以上のコピーを所与の保護セットだけのノード内に保管するステップを含む前記方法。
【請求項１１】
データ構造を更新するステップをも含む請求項１０に記載の方法。
【請求項１２】
定期的に、または所与の事象毎にデータ構造を更新する請求項１１に記載の方法。
【請求項１３】
個々のノードがオブジェクトに基づくストレージを提供するように一括してネットワーク化された個別ノードから成る冗長配列におけるノードであって、
保護セット内のノード数が所与の保護レベルと関数関係にある１つまたは２つ以上の保護レベルのそれぞれについて、ノードを１つまたは２つ以上の保護セットに分類し、所与のノードが１つの、且つ唯一の保護セットのメンバーとなるようにするマップと；
所与のオブジェクトがノードに保管されると、これに呼応して、マップを利用して所与のオブジェクトの１つまたは２つ以上のコピーを保管すべき場所を識別することによって所与のデータ保護レベルを満たす保護マネジャーとから成り、
１つまたは２つ以上のコピーが所与の保護セットの１つまたは２つ以上の他のノードに保管され、異なる保護セットのノードには保管されないノード。
【請求項１４】
保護マネジャーが定期的に、または所与の事象毎に新しいマップを作成する請求項１３に記載のノード。
【請求項１５】
冗長配列中の他のノードで機能する他の保護マネジャーに対して新しいマップを同報通信する請求項１４に記載の方法。
【請求項１６】
ノード内で所与のディスク故障が発生すると、保護マネジャーが所与の修復を行なって保護セットの維持を試みる請求項１３に記載の方法。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は２００６年２月１６日付け出願第６０/７７３，８５３号および２００７年２月１５日付け出願第１１/６７５，２２４号に基づきこれらの出願に基づく優先権を主張する。
【技術分野】
【０００２】
本発明は分散型コンピュータ・ネットワークにおける利用度、信頼性、および永続性に優れたデータ管理技術に係わる。
【背景技術】
【０００３】
従来のテープ方式および光学方式のストレージ技術に代わる、またはこれを補強する、利用度、信頼性、および永続性に優れた「固定コンテンツ」のアーカイブ・ストレージに対する需要が増している。ここにいう「固定コンテンツ」とは参照などの目的で不変の状態で保持されることを期待されるディジタル情報を指す。例えば、電子メール、文書、診断画像、検査画像、録音、フィルム、ビデオなどである。従来のリダンダント・アレイ・オブ・インディペンデント・ノード（ＲＡＩＮ）（個別ノードの冗長配列）ストレージ方式はこのような固定コンテンツ情報資産を保管する大型オンライン・アーカイブを作成するための画期的な構造として出現した。必要に応じてクラスタにノードを出し入れすることを可能にすることで、ＲＡＩＮ構造はストレージ・クラスタを１つまたは２つ以上のノードの故障から保護する。複数のノードにおいてデータを複製することによってＲＡＩＮ型のアーカイブはノードの故障または除去を自動的に補償することができる。典型的には、ＲＡＩＮシステムは閉鎖系内に同じコンポーネントから設計されたハードウェア装置として広く普及している。
【０００４】
図１はこのような拡張可能なディスク式アーカイブ・ストレージ管理システムを示す。ノードは異なるハードウェアから成り、従って、「不均一」と考えられる。ノードは多くの場合１つまたは２つ以上のストレージ・ディスクへのアクセスを有し、ストレージ・ディスクはストレージ・エリア・ネットワーク（ＳＡＮ）の場合のように、実際の物理的ストレージ・ディスクまたはバーチャル・ストレージ・ディスクから成る。それぞれのノードによって支持されるアーカイブ・クラスタ・アプリケーション（および、任意ではあるが、アプリケーションが実行される基礎的なオペレーション・システム）は同じか、またはほぼ同じである。それぞれのノードにおける（オペレーティング・システムを含む）ソフトウェア・スタックは対称的であるが、ハードウェアは不均一である。図１に示すように、このシステムを利用して、企業は文書、電子メール、衛星写真、診断画像、検査画像、録音、ビデオ、などのような多種にわたる固定コンテンツ情報の恒久的なストレージを作成することができる。上記の固定コンテンツの種類は説明のための例であり、他にも考えられる。高レベルの信頼性は独立サーバ、またはいわゆるストレージ・ノードにおいてデータを複製することによって達成される。それぞれのノードどうしは対称であることが好ましい。即ち、所与のノードがすべての機能を行なうことができるから、どれか１つのノードが故障しても、アーカイブの利用度に対する影響は殆どない。
【０００５】
本願の出願人の所有にかかる米国特許第７，１５５，４６６号明細書に記載されているように、ＲＡＩＮに基づくアーカイブ・システムにおいてディジタル資産を捕捉し、保存し、管理し、検索する、それぞれのノードにおいて実行される分散型ソフトウェア・アプリケーションを組み込むことは公知である。図２はこのようなシステムを示す。個々のアーカイブの物理的な境界をクラスタと呼称する。典型的には、クラスタは単一のデバイスではなく、デバイスの集合である。デバイスは均一でも不均一でもよい。典型的なデバイスはＬｉｎｕｘのようなオペレーション・システムを運用するコンピュータまたはマシーンである。コモディティ化したハードウェアがホストであるＬｉｎｕｓ系システムのクラスタは少数のストレージから数千テラバイトのデータを保管する多数のノードに拡大させることができるアーカイブを提供する。この構造によって、ストレージ容量は組織の増大するアーカイブ需要と常に対応することができる。
【０００６】
上記のようなストレージ・システムにおいて、データは通常、アーカイブが常にデバイスの故障から保護されるようにクラスタ全体に亘って分散される。ディスクまたはノードが故障すると、クラスタは自動的に、同じデータのコピーを保持しているクラスタ中の他のノードへ故障迂回する。データ保護の観点からすればこのアプローチは有効であるが、クラスタの平均データロス時間（ＭＴＤＬ）の計算値は期待されるほど高くはない。具体的には、ＭＴＤＬは多くの場合、アーカイブがデータを失うまでの計算された時間量である。ディジタル・アーカイブにおいては、いかなるデータロスも望ましくないが、ハードウェアおよびソフトウェア・コンポーネントの性質上、このような事象の発生は不可避である。アーカイブ・クラスタ内のオブジェクトおよびそのコピーがランダムに分散している以上、例えば、もし（ミラー・コピーが保管されている)所与のノード内の所与のディスクに予期しない故障が発生すると、オブジェクトの所要のコピーが利用不能になるから、ＭＴＤＬは所期の値よりも短くなる可能性がある。
【発明の概要】
【０００７】
本発明の目的は、拡大可能なディスク式アーカイブ・ストレージ管理システムにおけるデータ・ロス平均時間（ＭＴＤＬ）を改善することにある。１つの実施形態として、所与のアーカイブ・オブジェクトのコピーをこのオブジェクト自体をも保管する所与の「保護セット」内のノードに配布するように強制することによってこの目的を達成する。この方法は（クラスタ全体にオブジェクトをランダムに分散させる方式と比較して）データ・ロスを有意に軽減することができる。即ち、データが失われるより前に、保護セットのノード内で多重故障が発生しなければならないからである。
【０００８】
１つの実施形態において、好ましくは対称ノードから成るアーカイブ・ストレージ・クラスタは、既存の利用可能なノードを定期的に、それぞれのセットがｎ個のノードから成り、「ｎ」が設定可能な「データ保護レベル」（ＤＰＬ）を表わす１つまたは２つ以上の保護セットに組織するデータ保護管理システムを含む。作成の時点において、所与の保護セットは、既存の利用可能なノードが唯一の保護セットのメンバーであるという意味で閉状態にある。１つのオブジェクトをアーカイブ内に保管する場合、データ保護管理システムはこのオブジェクトを所与の保護セットの所与のノードに保管し、このオブジェクトのコピーが所与の保護セット内の他のノードに配布されるように強制する。結果として、１つのオブジェクトのすべてのＤＰＬコピーが同じ保護セット内に、且つこの保護セットだけに保管されることになる。所与の保護セットのノード内に多重的な故障が発生してもこのデータが失われるだけであるから、クラスタ全体としてのＭＴＤＬは有意に改善される。このような事象はクラスタ内のランダム分散ノード全般に発生する故障よりもはるかに確率が低い。
【０００９】
データ保護管理システムを配分することが好ましい。具体的には、データ保護管理システムを分散させた保護管理インスタンスのセットとして実施し、それぞれの保護管理インスタンスがクラスタの所与のノードに作用するように構成することが好ましい。セットのうちのどのインスタンスが所与に時点において保護セットを管理するかを決めるため、保護マネジャーがリーダー選択プロトコルを実行する。所与の時点において利用されるプロトコル・セットを保護セット・マップによって定義することが好ましい。リーダーとして作用する保護マネジャー・インスタンスは保護セット・マップを作成・管理し、このマップをクラスタ中の他の保護マネジャー・インスタンスに同報通信することができる。保護マネジャーは定期的にマップの正確さを検証し、新しいデータ（例えば、故障したノード、作動中のノード、クラスタに新たに加わるノード、などに関する情報）に基づいてセットか解体したり、新しいセットを作成したりする。新しい保護セット・マップを作成するため、リーダーはすべてのノードおよび、もし存在するなら既存の保護セット・マップのリストを入手する。次いで、好ましくは類似の既存未分類ノードをＤＰＬ毎に分類することによって、考えられるすべての保護レベルについて、新しい保護セット・マップを作成する。新しい保護セット・マップが作成されたら、これを特定場所に（リーダー・ノードに）保管し、他の保護マネジャー・インスタンスに同報通信する。
【００１０】
即ち、図示の実施形態では、データ保護管理スキームがアーカイブ内に１つまたは２つ以上のデータ保護セットを自動的に形成し、データ・オブジェクトおよびそのコピーを独自の態様で（即ち、唯一のデータ保護セット内に）保管することによってＭＴＤＬを改善する。このような設計によって、クラスタ内のランダム・ノードに亘って同時的にノード故障が発生してもデータの高い利用度を確保することができる。
【００１１】
本発明の重要な構成要件の幾つかを以上に概説した。但し、これらの構成要件はあくまでも説明のためのものであり、ほかにも、多様な態様で本発明を応用することにより、または後述のように変更を加えることによって種々の好ましい成果を挙げることができる。
【実施例】
【００１２】
図２に示すように、本発明のクラスタ実施例は大別して下記のコンポーネントを含む：ノード２０２、１対のネットワーク・スイッチ２０４、電力分配装置（ＰＤＵ）２０６、および無停電電源（ＵＰＳ）２０８。ノード２０２は多くの場合１つまたは２つ以上のコモディティ化したサーバを含むとともに、ＣＰＵ（例えば、Ｉｎｔｅｌ ｘ８６）、適当なランダムアクセスメモリ（ＲＡＭ）、１つまたは２つ以上のハードドライブ（例えば、標準的なＩＤＥ/ＳＡＴＡ、ＳＣＳＩなど）、および２つ以上のネットワークインターフェース（ＮＩＣ）カードを含む。典型的なノードは２．４ＧＨｚチップ、５１２ＭＢ ＲＡＭ、および６つの２００ＧＢハードドライブを含む２Ｕラックマウント方式のユニットである。但し、本発明はこの構成に限定されるものではない。ネットワークスイッチ２０４は典型的にはノード間のピアツーピア通信を可能にする内部スイッチ２０５と、エキストラ・クラスタがそれぞれのノードにアクセスすることを可能にする外部スイッチ２０７から成る。それぞれのスイッチはクラスタ中のすべてのノードを操作するのに充分なポートを必要とする。この目的にはＥｔｈｅｒｎｅｔまたはＧｉｇＥスイッチを利用することができる。ＰＤＵ２０６はすべてのノードおよびスイッチへの給電に利用され、ＵＰＳ２０８はすべてのノードおよびスイッチの保護に利用される。限定的ではないが、クラスタは公共インターネット、企業内インターネット、またはその他のワイドエリアネットワークまたはローカルエリアネットワークのようなネットワークに接続できるのが典型的である。図示例はクラスタが企業環境内に実施された場合である。クラスタには、例えば、サイトの企業ドメインネーム・システム（ＤＮＳ）のネームサーバを介してナビゲートすることによって到達することができる。例えば、クラスタのドメインが既存のドメインの新しいサブドメインである場合がある。典型的な実施例では、サブドメインは企業ＤＮＳサーバにおいてクラスタ自体のネームサーバに任せられる。エンドユーザーは公知のインターフェースまたはアクセス・ツールを利用してクラスタにアクセスする。例えば、クラスタへのアクセスはＩＰに基づくプロトコル（ＨＴＴＰ、ＥＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、Ｗｅｂサービスなどを利用し、ＡＰＩを介して、またはその他公知の、または最近開発されたアクセス方法、サービス、プログラムまたはツールを介して行なうことができる。
【００１３】
クライアント・アプリケーションは１種または２種以上の外部ゲートウエイ、例えば、標準ＵＮＩＸファイル・プロトコル、またはＨＴＴＰ ＡＰＩを介してクラスタにアクセスする。アーカイブは好ましくは随意に標準ＵＮＩＸファイル・プロトコル向きのデバイスを作用させることができるバーチャル・ファイル・システムを介して可視化する。このようなバーチャル・ファイル・システムとしては、ＮＦＳ、ＥＴＰ、ＳＭＢ/ＣＩＦＳなどがある。
【００１４】
１つの実施例として、アーカイブ・クラスタ・アプリケーションはクラスタとして（例えば、Ｅｔｈｅｒｎｅｔを介して）ネットワーク化された個別ノードの冗長配列（Ｈ-ＲＡＩＮ）で実行される。所与のノードのハードウェアは不均一であってもよい。但し、信頼度を最大限に高めるには、それぞれのノードが図３に示すような幾つかのランタイム・コンポーネントから成る分散アプリケーションの（全く同じか、または殆ど同じ）インスタンス３００を実行することが好ましい。即ち、ハードウェアは不均一であってもよいが、ノードにおけるソフトウェア・スタックは（少なくとも本発明に関する限り）同じである。これらのソフトウェア・コンポーネントはゲートウエイ・プロトコル層３０２、アクセス層３０４、ファイル・トランザクション/管理層３０６、およびコア・コンポーネント層３０８から成る。「層」という表現は説明の便宜上付したものであり、当業者なら周知のように、別の表現を使用して機能を特徴付けることができる。層（またはこれの含まれるコンポーネント）の１つまたは２つ以上を一体化することも可能である。コンポーネントによっては幾つかの層によって共有することもできる。
【００１５】
ゲートウエイ・プロトコル層３０２におけるゲートウエイ・プロトコルは既存アプリケーションに対して透過性である。具体的には、ゲートウエイはネイティブファイル・サービス、例えば、ＮＦＳ ３１０およびＳＭＢ/ＣＩＦＳ ３１２、およびＷｅｂサービスＡＰＩのようなサービスを提供してカスタム・アプリケーションを構成する。ＨＴＴＰサポート ３１４も提供される。アクセス層３０４はアーカイブへのアクセスを可能にする。特に、本発明では、Ｆｉｘｅｄ Ｃｏｎｔｅｎｔ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＦＣＦＳ）３１６がネイティブファイル・システムをエミュレートすることによってアーカイブ・オブジェクトへの全面的なアクセスを可能にする。ＦＣＦはアプリケーションに対して、もし普通のファイルならアーカイブ・コンテンツへの直接アクセスを可能にする。メタデータをファイルのままとしながら、アーカイブ・コンテンツを元のフォーマットにすることが好ましい。ＦＣＦＳ ３１６は慣用的なディレクトリ・テーブル、パーミッションおよび通常のファイル・レベル・コールを可能にするから、管理者は固定コンテンツを周知の方法で提供することができる。ファイルへのアクセスは自主的なアーカイブ管理を容易にするためにはＦＣＦＳコールをアーカイブ・ポリシーによって制約することが好ましい。１つの例として、管理者またはアプリケーションは保存期間（所与のポリシー)が未だ有効なアーカイブ・オブジェクトを消去することはできない。
【００１６】
アクセス層３０４はＷｅｂユーザー・インターフェース（ＵＩ）３１８およびＳＮＭＰゲートウエイ３２０をも含むことが好ましい。Ｗｅｂユーザー・インターフェース３１８はファイル・トランザクション/管理層３０６における管理エンジン３２２への双方向アクセスを可能にする管理コンソールとして実施することが好ましい。管理コンソール３１８はパスワードによって保護され、アーカイブ・オブジェクトおよび個別ノードを含むアーカイブのダイナミック・ビューを提供するＷｅｂに基づくＧＵＩであることが好ましい。ＳＮＭＰゲートウエイ３２０は管理エンジン３２２へのストレージ管理アプリケーションのアクセスを容易にし、これによってクラスタの活動をしっかりモニターし、制御することを可能にする。管理エンジンはシステムおよびポリシー事象を含むクラスタの活動をモニターする。ファイル・トランザクション/管理層３０６はリクエスト管理プロセス３２４をも含む。リクエスト管理３２４は（アクセス層３０４を介して)外部世界からのすべてのリクエストおよびコア・コンポーネントそう３０８におけるポリシー・マネジャー３２６からの内部リクエストを調整する。
【００１７】
ポリシー・マネジャー３２６のほかに、コア・コンポーネントはメタデータ・マネジャー３２８、およびストレージ・マネジャー３３０の１つまたは２つ以上のインスタンスをも含む。メタデータ・マネジャー３２８をそれぞれのノードに設けることが好ましい。全体として、クラスタにおけるメタデータ・マネジャーはすべてのアーカイブ・オブジェクトを管理する分散型データベースとして作用する。所与のノードにおいて、メタデータ・マネジャー３２８は好ましくはそれぞれのオブジェクトが外部ファイル（「ＥＦ」、ストレージのためアーカイブに加わったデータ）とアーカイブ・データが物理的に配置されている一連の内部ファイル（それぞれが「ＩＦ］)の間に位置するアーカイブ・オブジェクトのサブセットを管理する。同じメタデータ・マネジャーは他のノードから複写された一連のアーカイブ・オブジェクトをも管理する。従って、すべての外部ファイルの現状は常に幾つかのノードにおける複数のメタデータ・マネジャーによって利用することができる。ノードに障害がある場合、他のノードにおけるメタデータ・マネジャー故障ノードによってすでに管理されたデータに対するアクセスを継続する。この動作についてはより詳しく後述する。ストレージ・マネジャー３３０は分散アプリケーションにおける他のすべてのコンポーネントが利用できるファイル・システム層を提供する。好ましくは、このファイル・システム層はノードのローカル・ファイル・システムにおけるデータ・オブジェクトを保管している。所与のノードにおけるそれぞれのドライブは好ましくはそれ自体のストレージ・マネジャーを有する。これによりノードは個々のドライブを除いてその処理能力を最適化することができる。ストレージ・マネジャー３３０はまた、システム情報を提供し、データの完全性をチェックし、ディレクトリ構造に局所的にアクセスすることができる。
【００１８】
本発明の実施例では、リクエスト・マネジャー３３０は保護マネジャー・インスタンス３３１を含むかまたはこれと連携する。ノードにおいて動作する保護マネジャー・インスタンス３３１は協働して分散データ保護管理システムを構成する。詳しくは後述するように、データ保護管理システムは定期的にその時の利用可能なノードを、それぞれのセットがｎ個のノードから成り、「ｎ」が設定可能な「データ保護レベル」（ＤＰＬ）を表わす１組または２組以上の保護セットに組織する。形成時点では、その時利用可能なノードが１つの、唯１つの保護セットのメンバーであるという意味で、所与の保護セットは閉の状態にある。オブジェクトをアーカイブ内に保管する時、データ保護管理システムは（直接またはストレージ・マネジャーを介して）オブジェクトを所与の保護セットの所与のノード内に保管し、次いで、このオブジェクトのコピーが所与の保護セット内の他のノードへの分散を強制する。その結果、１つのオブジェクトのすべてのＤＰＬコピーが同じ保護セット内に、即ち、その保護セットだけに保管する。このスキームによって、クラスタ全体としてのＭＴＤＬが著しく改善される。所与の保護セットのノード内で多重故障が発生してもデータが失われるだけだからである。このような事象が発生する確率はクラスタ内でランダム・ノード全体に亘って発生する故障の確率よりもはるかに低い。この作用について詳しくは後述する。
【００１９】
図３に示すように、クラスタは通信ミドルウエア３３２およびＤＮＳマネジャー３３４を介して内部および外部通信を管理する。インフラ構造３３２はメッセージに基づく効率的且つ確実なミドルウエア層であり、アーカイブ・コンポーネント間の通信を可能にする。図示の実施例では、この層はマルチキャストおよび２点間通信を可能にする。ＤＮＳマネジャー３３４はすべてのノードを企業サーバに接続する分散ネーム・サービスを行なう。ＤＮＳマネジャーは（単独で、またはＤＮＳサービスと共に）リクエストをすべてのノードに負荷分散することによって、クラスタの処理能力と利用度を確保する。
【００２０】
図示実施例の場合、ＡｒＣアプリケーション・インスタンスがＲｅｄ Ｈａｔ Ｌｉｎｕｘ ９．０、Ｆｅｄｏｒａ Ｃｏｒｅ ６などのようなベース・オペレーション・システム３３６上で実行する。通信ミドルウエアは使い勝手のよい分散型通信機構である。その他のコンポーネントとしては、Ｆｉｘｅｄ Ｃｏｎｔｅｎｔ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＦＣＦＳ）３１６に使用できるＦＵＳＥ（ＵＳＥｒｓｐａｃｅにおけるＦｉｌｅｓｙｓｔｅｍ）が挙げられる。ＮＦＳゲートウエイ３１０は標準的なｎｆｓｄ Ｌｉｎｕｘ Ｋｅｒｎｅｌ ＮＦＳドライバーによって実施できる。それぞれのノードにおけるデータベースは、例えば、オブジェクト関連データベース管理システム（ＯＲＤＢＭＳ）であるＰｏｓｔｇｒｅＳＱＬ（ここではＰｏｓｔｇｒｅｓとも呼称する）によって実施することができる。ノードはＪａｖａ ＨＴＴＰサーバおよびサーブレット・コンテナであるＪｅｔｔｙのようなＷｅｂサーバを含むことができる。いうまでもなく、以上に上げた機構はいずれも説明のための例である。
【００２１】
所与のノードにおけるストレージ・マネジャー３３０は物理的ストレージ・デバイスの管理を担当するものである。それぞれのストレージ・マネジャー・インスタンスは配置アルゴリズムに従ってすべてのファイルが配置されるシングル・ルート・ディレクトリを担当することが好ましい。多重ストレージ・マネジャー・インスタンスは同時に１つのノードに作用することができ、それぞれのインスタンスはシステム内の異なる物理的ディスクを表わすのが普通である。ストレージ・マネジャーはシステムの残り部分から、使用中のドライブおよびインターフェース技術を抽出する。ストレージ・マネジャー・インスタンスがファイルの書込みを要求されると、表現の責任を明らかにするためのフルパスおよびフルネームを発生させる。典型的な実施形態としては、ストレージ・マネジャーに保管されるそれぞれのオブジェクトは未加工データの形で受信され、ストレージ・マネジャーがファイルに自らのメタデータを付加して、種類ごとに情報を追跡できるようにする。メタデータの例としては：ＥＦ長さ（バイト単位で表わされる外部ファイルの長さ）、ＩＦ Segmentサイズ（この部分の内部ファイルのサイズ）、ＥＦ保護表現（ＥＦ保護モード）、ＩＦ保護ロール（この内部ファイルの表現）、ＥＦ作成タイムスタンプ（外部ファイル・タイムスタンプ）、シグネチャー（シグネチャー・タイプを含む書込み時における内部ファイルのシグネチャー）およびＥＦファイルネーム（外部ファイル・ファイルネーム）が挙げられる。この付加メタデータを内部ファイル・データと共に保管することで追加の保護レベルが規定される。具体的には、スキャベンジングによって、内部ファイルに保管されているメタデータからデータベースに外部ファイル記録を形成することができる。他のポリシーとして、内部ファイルに対する内部ファイル・ハッシュを有効化することによって内部ファイルが無傷のままであることを有効化することができる。
【００２２】
内部ファイルがアーカイブ・オブジェクトにおける元の「ファイル」の一部を表わすデータの「チャンク」という形を取り、異なるノードに位置させて分散化と保護ブロックを達成する場合がある。但し、外部ファイルをこのように小さいチャンク単位に分割する必要はない：即ち、これに代わる態様として、内部ファイルが外部ファイルの完全なコピーであればよい。典型的な態様として、メタデータ・マネジャーにはそれぞれのアーカイブ毎に１つの外部ファイル・エントリが存在し、それぞれの外部ファイル・エントリ毎に多数の内部ファイル・エントリが存在する。多くの場合、内部ファイルのレイアウトはシステムに応じて異なる。所与の実施態様においては、ディスク状のこのデータの実際の物理的フォーマットが一連の可変長さ記録として保管される。
【００２３】
リクエスト・マネジャー３２４はシステム内の他のコンポーネントとの相互作用によってアーカイブ・アクションを行なうのに必要な一連のオペレーションを実行するものである。リクエスト・マネジャーは異なる種類の多くの同時的な作用を支援し、トランザクション処理中の故障に際してデータベースへの更新処理を無効化することができ、実行に長時間を要することがあるトランザクションを支援する。リクエスト・マネジャーはまた、アーカイブに対する読出し/書込み動作が正しく行なわれ、すべてのリクエストが常に既知状態にあるように作用する。さらにまた、複数ノードに跨る読出し/書込み動作を調整することによって所与のクライエントのリクエストを満足させる。また、リクエスト・マネジャーは最近使用されたファイルに関してメタデータ・エントリをキャッシング制御し、セッションおよびデータブロックに対する緩衝作用をも果す。
【００２４】
クラスタの主要機能は無制限のフアィル数をディスクに確実に記憶させることにある。何らかの理由でアクセス不能または利用不能であるという意味で所与のノードが「信頼できない」と考えられる場合がある。このような信頼性を欠く可能性があるノードが協働して信頼でき、且つ利用度の高いストレージを生成する。大別して、保管する必要がある情報には２つのタイプがある：即ち、ファイルそのものと、そのファイルに関するメタデータとである。
【００２５】
保護管理
本発明では、保護管理システムが所与の保護セット内のノードへのオブジェクト・コピーの分散を制約することによって平均データロス時間を改善する。ここで使用される「保護セット」とは所与の保護レベルを与えられた１組のノードを指す。データ保護レベル（ＤＰＬ）の文脈にフォールト・トレランスが記述されている場合には、保護セットはノードのＤＰＬ番号を含むのが普通である。本発明の保護セット・マップは考えられるすべての所与ＤＰＬレベルを与えられたすべての保護セットを含む。例えば、ノード数Ｎ＝{１、２、３、４、５、６、７、８}を有する８クラスタノードの場合、保護セット・マップは好ましくは下記のように規定される（クラスタの最大ＤＰＬはノード数に等しい）：
ＤＰＬ １：すべてのノード；この情報は存続させる必要はない
ＤＰＬ ２：{１、２}{３、４}{５、６}{７、８}
ＤＰＬ ３：{１、２、３}{４、５、６}［ノード７および８は使用されない］
ＤＰＬ ４：{１、２、３、４}{５、６、７、８}
ＤＰＬ ５：{１、２、３、４、５}［ノード６、７および８は使用されない］
ＤＰＬ ６：{１、２、３、４、５、６}［ノード７および８は使用されない］
ＤＰＬ ７：{１、２、３、４、５、６、７}［ノード８は使用されない］
ＤＰＬ ８：{１、２、３、４、５、６、７、８}
（上記のような）保護セット・マップにはそれぞれデータ保護レベルを有する。大ざっぱにいえば、保護セット・マップはデータ構造であると考えることができる。後述するように、保護セット・マップは周期的且つ自動的に作成されることが好ましく、クラスタ全体を通して作用する保護マネジャーがこれを利用する。あるいは、必要に応じて、例えば、クラスタに新しいノードが追加されたり、旧来のクラスタがグレードアップされたり、ノードに故障が発生したりするような所与の事象に呼応して保護セット・マップが作成される。好ましい技術の例としては（公知のリーダー選択アルゴリズムを実行することによって）一連の保護マネジャー・インスタンスの中から、所与のノードにおいて動作する所与の保護マネジャー・インスタンスをリーダーとして作用させる技術がある。リーダーは保護セット・マップを作成し、これを確保した上で、クラスタに含まれる他の保護マネジャー・インスタンスに新しい保護セット・マップを同報通信する。即ち、所与の時点において（または所与の時間に亘って）所与の保護セット内のクラスタ・ノードの分類を示す保護セット・マップが、クラスタにおいて動作するリクエスト・マネジャー・プロセスによって利用される。図示のように、保護セット・マップは（アーカイブ・オブジェクトおよびそのミラー・コピーを保管するよう指名された）リクエスト・マネジャー・プロセスに対して、クラスタのそれぞれのノードがメンバーである現時点での保護セットを指示する。即ち、リクエスト・マネジャー・プロセスがアーカイブ・オブジェクトの保管場所として所与の保護セット内の所与のノードを選択すると、このリクエスト・マネジャー・プロセス（およびこれと同一であってもよい連携の保護マネジャー・プロセス・インスタンス）はこのオブジェクトのＤＰＬコピーが所与の保護セットだけに属する他のノードに保管されることをも保証する。従って、好ましい実施形態では、所与のオブジェクトが該当ＤＰＬレベルの所与の保護セットにのみ保管される。１例として、保護セット・マップに指定されている通りに所与のオブジェクトが保護セット{１、２}に保管される場合、このオブジェクトのコピーはこのセット内のノードに保管され、（少なくとも保管の時点において）その他のノードには保管されない。即ち、オブジェクトまたはそのコピーがノード{２、３}、ノード{４、５}、などに存在してはならない。従って、この（ＤＰＬ２のオブジェクトの）システムに２つの故障があれば、故障は同一の保護セット内にあり（即ち、保護セット{１、２}内にあり、データ・ロスが生ずる。オブジェクトのコピーのランダム分散を採用するオブジェクト分散スキームと比較して、データ・ロスの可能性ははるかに少ない。即ち、ＭＴＤＬが改善される。
【００２６】
保護マネジャーの主要な機能は保護セット・マップを管理することにある。具体的には、保護マネジャーはリーダー選択を実行することができ、好ましくは、（例えば、ノード状態データベースなどを介して)クラスタ中のそれぞれのノードの状態を知っている。従って、例えば、保護マネジャーは利用不能な状態にあるノードを追跡し、所与のノードが最後にクラスタ内に「存在した」時点を追跡する。保護マネジャーはまた連携の保管マネジャーの状態変化に関する情報をも把握していることが好ましい（上記したように、一体化された単一のプロセスである場合もある）。１つの実施態様として、この情報（またはその一部）を保護マネジャーが利用して、その時点での保護セットが正確かどうかを判断する。例えば、所与のノードに故障が発生し、オーバーロードの状態にあるから、所与の保護セットはもはや正確ではない；追加ノードがクラスタに設けられたから、１つまたは２つ以上の保護セットはもはや正確ではない、などである。定期的に、または必要に応じて、保護マネジャー（および、特にリーダーとして作用するインスタンス）がその時点での保護セット・マップの正確さを検証し、結果に照らして、（検証の結果および/または新しいデータに基づいて）セットを解体するかまたは新しい保護セットを作成する。保護セット・マップの作成は図４に示すようなプロセス・フローに従って行なうことが好ましい。
【００２７】
プロセスはリーダーがすべてのノードおよび現時点での保護セット・マップを得るステップ４００で始まる。ステップ４０２において、保護セットにおけるすべてのノードが設定可能な時間を超えて存続するなら、リーダーがこの保護セットを解体する。ルーチンはステップ４０４に進み、可能なＤＰＬレベルが揃っているかどうかを判定する。揃っていなければ、ルーチンはステップ４０６に進み、次のＤＰＬレベルを得る。ステップ４０８において、（例えば、容量のような１つまたは２つ以上の属性、プロセッサの数、などの点で）類似する未分類ノードをサイズが一致するＤＰＬと共に分類する。再びステップ４０４に戻る。すべてのＤＰＬレベルが設定されれば（即ち、ステップ４０４の試験結果がポジティブなら）ルーチンはステップ４１０へ分岐し、ここで新しい保護セット・マップが確保され、他のすべてのノードに同報通信される。こうして保護セット・マップの作成プロセスが完了する。
【００２８】
保護セットはこのセット内の１つまたは２つ以上のノードが設定可能な時間に亘って利用不能でない限り、解体しないことが好ましい。これにより、ノードがクラスタ内を転々と移動して保管されているデータが混乱するのを回避することができる。上記したように、保護マネジャー・リーダー・インスタンスは作成した保護セット・マップを、好ましくは平易なテキスト・フォーマットの構成オブジェクトとして、デバッギングおよびテストを容易にするサービス・アクセスが可能な分散データベース中に確保する。一般に、保護セットは頻繁に書込みまたは読出しをする必要はない。上述したように、保護マネジャーはクラスタ中で動作する他のすべての保護マネジャーにも保護セット・マップを同報通信する。（リーダーではなく）所与の保護マネジャーが初期化する場合、この保護マネジャーは現在の保護セット・マップに関する知識を持っていない可能性がある。新しい保護セット・マップが作成される時、すべての保護マネジャーにメッセージを送信して新しいマップをロードすることが好ましい。どの保護マネジャーが新しいマップを作成し、同報通信するかを選択するためにリーダー選択を利用することによって競合状態を回避することができる。ポリシー実行とストレージ・マネジャー選択のために、保護マネジャーもヘルパー方法を提供することが好ましい。具体的には、所与の外部ファイル（ＥＦ）およびこれと連携する内部ファイル（ＩＦ）に関して、保護マネジャーは必要に応じて（即ち、ＥＦ/ＩＦを完全に保護された状態へ移動させるため）適切な修復ステップを求める。修復を行なうため、保護マネジャーは外部ファイルおよびこれと連携する内部ファイルを有効化する。保護マネジャーは保護ポリシー検出をも行うことができる。所与の保護ポリシーが設定可能である場合がある。当業者には周知のように、本発明のＭＴＤＬ改善を実行しないクラスタをグレードアップした後、すべてのノードにおいて保護ポリシーを開始する必要がある。保護ポリシー検出は、例えば、クラスタ・バランス機能のような他のアーカイブ・クラスタ機能と協働することもできる。例えば、ノードがクラスタ・アーカイブとくっついたり離れたりするのに伴って、システムは自動的にクラスタのロード・バランスを調整し、メンバー・ノード間にファイルを再分散させることによって性能を最適化する。即ち、ＤＰＬが不変のクラスタでは、ノードが保護セット内で平衡を保っていることが好ましい。（クラスタのバランスをよくするために）適切な状況では、システム内でデータを再分散させながら所与のＩＦのＤＰＬコピーを他のセットへ移動させる必要がある。具体的には、システム内にデータを均等に（またはほぼ均等に)分散させるようにクラスタ・バランス・ポリシーを設計する。（例えば、新しいノードが加わったり、所与のノードが脱落することで）システムのバランスが崩れたら、クラスタ・バランス・ポリシーによってオブジェクトを移動させて分布を均等化する必要がある。結果としてオブジェクトの１つのコピーが移動したら、他のコピーをも移動させて保護セットを維持しなければならない。
【００２９】
ストレージ・マネジャー選択（即ち、リクエスト・マネジャーによる、アーカイブに書き込まれる所与のオブジェクトがどのストレージ・マネジャーのノードに保管されるかの選択）を増やすことによって、既存保護セット・マップ中に画定されている保護セット・マップを強化することが好ましい。このようにすれば、オブジェクトのすべてのコピーがこのオブジェクトそのものが保管されるント同じ保護セット内に保管される。これを図５に示す。この例（ＤＰＬ３）では、保護セット５００がこれと連携するノード５０２、５０４および５０６を有する。他の保護セット５０８はノード５１０、５１２および５１４を含む。上記したように、（保護セット・マップの既存バージョンとは異なり）所与の時点において、１つの保護セット以上の保護セットのメンバーであるノードは１つもない。オブジェクト自体５０５ａは（例えば、所与のリクエスト・マネジャー・プロセスによって）ノード５０４に書き込まれている。即ち、ＤＰＬコピー５０５ｂおよび５０５ｃがランダム分散されるのではなく、保護セット５００中の利用可能なままの状態にあるノード５０２および５０６に書き込まれる。従って、コピー５０５ｂはノード５０２に、コピー５０５ｃはノード５０６に書き込まれる。
【００３０】
「ＤＰＬ」設定パラメータは上記の例に制限されるものではなく、適当な故障許容範囲を採用することができる。名称に関係なく、本発明は（データ保護セット内の１つのノードに書き込まれた）オブジェクトのコピーが同じセット内の他のノードにだけ書き込まれるようにすることによって著しいＭＴＤＬの改善を達成する。さらにまた、詳しくは説明しないが、（例えば、多重パリティ保護のような）他の技術を本発明の方法と併用できることは当業者が容易に予想できることである。
【００３１】
データ保護マップはオープンソースとして利用できるＰｓｔｇｒｅＳＱＬを使用して実施されたデータベースに保管するというような便利な態様で管理することができる。マップの同報通信は使い勝手のよいノード間通信機構ＴＣＰ/ＩＰマルチキャストを利用することができる。上述したように、新しい保護セット・マップを作成する際には、保護マネジャー・リーダーが他ノードへのこのマップの配布を開始し（且つすべてのノードが受取るまで処理の一時停止をリクエストすることができる）。ノードのすべてが新しいマップを配布されたことをシステムが確認すると通常の処理が再開される。
【００３２】
特にノード数の増大（例えば、＞２０）に伴って、ＭＴＤＬをさらに改善するには、内部ファイル（ＩＦ）にＲＡＩＤを使用することが好ましい。上記スキームの結果として、ノードが論理的鏡像関係になる（例えば、それぞれのノード対が同じデータを含む）。
【００３３】
必要なら、ノードに故障が発生したら、保護マネジャーが修復ポリシーを実行して、こしょうの結果解体した所与の保護セット対の修復を試みる。この修復ポリシーはアーカイブが利用できる他の修復機能を利用することができる。例えば、ポリシー・マネジャーがリクエスト・マネジャーアイの機能をコールして修復作業を開始することができる。このような修復作業はストレージ・マネジャー選択プロセス、保護マネジャーおよびその他の内部コンポーネントを利用することによってポリシー修復作業を完了することになる。
【００３４】
本発明はディジタル化された資産を捕捉し、保存し、管理し、検索するように設計されたアーカイブ管理の解決を容易にする。この設計は多くの必要条件と取組んでいる：無制限のストレージ、高い信頼度、自己管理、法規制の順守、ハードウェアの独立性、および既存アプリケーションとの容易な一体化などである。（例えば)Ｌｉｎｕｘを実行するコモディティ化したハードウェアのクラスタは堅牢なプラットフォームとバーチャルに無制限のアーカイブを提供する。このシステムは、例えば、少数のストレージ・ノード・サーバから数千テラバイトのデータを保管する多数のノードまでの規模に順応できる。独自の構造により、ストレージ容量は常に組織の増大するアーカイブ需要に順応することが可能になる。上記のように、システムはフアィルを失わないように設計されているが、クラスタ内で動的に作成される複数の保護セットに亘ってデータを複製することによってＭＴＤＬの改善を達成する。もし所与のディスクまたはノードが故障しても、クラスタは自動的に、同じデータのコピーを維持している保護セット内の他のノードに切り替わる。
【００３５】
以上、本発明の幾つかの実施例において行なわれる特定の動作順序を説明したが、このような順序は飽くまでも例として説明したものであって、異なる順序で、または幾つかの動作を組み合わせる、またはオバーラップさせる、などの方法で所要の動作を行なう実施態様も可能である。上記実施例ではそれぞれの実施形態に応じて特定の構成要件、構造または特性を有するが、必ずしもすべての実施形態がこれら特定の構成要件、構造または特性を含むとは限らない。
【００３６】
以上、本発明を方法に関して説明したが、本発明はここに述べる方法を実施するための装置にも係わる。この装置は必要な目的に応じて構成するか、またはコンピュータに記憶されているコンピュータ・プログラムによって選択てきに作用、または再構成される汎用コンピュータを含むものであればよい。このようなコンピュータ・プログラムは、例えば、光学ディスク、ＣＤ−ＲＯＭ，磁気-光学ディスクのようなディスク、読出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気または光学カード、または電子マニュアルを記憶するのに好適な媒体のような読出し可能な記憶媒体に記憶させることができ、それぞれをコンピュータ・システム・バスに接続すればよい。
【００３７】
システムの所与のコンポーネントを別々に説明したが、当業者には周知のように、所与の命令、プログラム・シーケンス、コード部分などで機能の幾つかを組み合わせるか、または共用させることができる。
【００３８】
上述のように、リクエスト・マネジャー・コンポーネントはアーカイブへの書込みだけでなく、ポリシー違反が検出された場合のポリシー修復に際しても保護マネジャーを利用する。保護マネジャーの機能を支援するか、または可能にするには、リクエスト・マネジャーを利用することが好ましいが、アプリケーションのその他のコンポーネントを利用することもできる。
【００３９】
以上に説明した本発明の範囲を後記する請求項によって定義する。
【図面の簡単な説明】
【００４０】
【図１】本発明の固定コンテンツ・ストレージ・アーカイブを簡略化して示すブロックダイヤグラムである。
【図２】それぞれが対称的であり且つ本発明のアーカイブ・クラスタ・アプリケーションをサポートする個別ノードの冗長配列を示す簡略図である。
【図３】所与のノードにおけるアーカイブ・クラスタ・アプリケーションの種々のコンポーネントのハイレベル図解である。
【図４】本発明の保護セット・マップ作成プロセスのフローチャートである。
【図５】本発明のＭＴＤＬを改善するため、所与の保護管理インスタンスがデータ・オブジェクトのコピーの分散を制約する方法を示すダイヤグラムである。
【図１】
2009527824.tif 000003
【図２】
2009527824.tif 000004
【図３】
2009527824.tif 000005
【図４】
2009527824.tif 000006
【図５】
2009527824.tif 000007
【国際調査報告】
2009527824.tif 000008