JP2010509686A - プライマリー・クラスタの高速リカバリ - Google Patents

Abstract

個々のアーカイブが好ましくは対称ノードのストレージ・クラスタである一連の分散型アーカイブに亘ってクラスタ・リカバリ・プロセスを実行する。クラスタのそれぞれのノードは典型的には固定コンテンツ・データおよび関連メタデータのオブジェクト-ベースのストレージを提供するアプリケーションのインスタンスを実行する。このストレージ方法では、先ず第１クラスタと第２クラスタの間に連携関係または「リンク」を確立することによってコピー・プロセスを容易にする。第１クラスタは「プライマリー」クラスタと呼称され、第２クラスタは「レプリカ」クラスタと呼称されることがある。リンクが形成されると、第１クラスタの固定コンテンツ・データおよびメタデータが第１クラスタから第２クラスタへ、好ましくは連続的に、コピーされる。但し、第１クラスタに故障が発生すると、フェイルオーバー・オペレーションが行なわれ、第１クラスタのクライアントが第２クラスタへリダイレクトされる。第１クラスタが修理されるかまたは取替えられると（「復旧」）、修理されるかまたは取替えられた第１クラスタは第１クラスタのクライアントにサービスする権限を取り戻す。この復旧オペレーションは好ましくは２段階で行なわれる：即ち、好ましくは第１クラスタのメタデータの「バルク」転送を伴う「高速リカバリ」段階と、これに続く、固定コンテンツ・データの転送を伴う「フェイルバック」段階である。第２クラスタからメタデータを受信すると、フェイルバック段階が完了したか、開始されたばかりかに関係なく、修理された、または取替えられた第１クラスタはクライアントにサービスする権限を取り戻す。

Description

発明の背景

本願は２００７年１１月８日付け米国出特許願第６０/８５７，７２８号をベースとし、該出願に基づく優先権を主張する。

本発明は分散コンピュータ・ネットワークにおける可用性、信頼性および永続性にすぐれたデータ保存に関する技術一般に係わる。

関連技術の説明

「固定コンテンツ」を、従来のテープや光学的記憶手段に代わる、またはこれらを補完する可用性、信頼性および永続性にすぐれた態様で記録保存するアーカイブ保存に対する需要が高まりつつある。「固定コンテンツ」とは典型的には、参考資料として不変の状態で保存したいディジタル情報を指す。このような固定コンテンツの例として、特に、ｅメール、公文書、診断画像、チェック画像、音声記録、フィルム、ビデオなどが挙げられる。従来の冗長独立ノード・アレイ方式（ＲＡＩＮ）の保存アプローチはこのような固定コンテンツ情報資産を保存する大規模なオンライン・アーカイブを形成するのに最適のアーキテクチャとして出現した。個々のノードが必要とするクラスタと結合・離脱できるから、ＲＡＩＮアーキテクチャは１つまたは２つ以上のノードが故障しても保存クラスタを防護する。複数のノードにデータをコピーすることによって、ＲＡＩＮ-タイプのアーカイブはノードの故障または撤去を自動的に埋め合わせすることができる。典型例として、ＲＡＩＮシステムはクローズドシステム内で同じコンポーネントから設計されたハードウェア・アプライアンスとして実施される。

クラスタ回復のプロセスは個々の独立アーカイブが好ましくは対称ノードを有する保存クラスタである一連の分散アーカイブに亘って実施される。クラスタのそれぞれのノードは多くの場合固定コンテンツ・データおよび関連のメタデータをオブジェクトに基づいて保存するアプリケーションのインスタンスを実行する。この保存方法では、第１クラスタと第２クラスタとの間の関連付けまたは「リンク」を先ず設定することによってコピーを容易にする。第１クラスタを「一次」、第２クラスタを「レプリカ」と呼称することがある。リンクが設定されたら、次いで第クラスタの固定コンテンツ・データおよびメタデータを第１クラスタから第２クラスタに、好ましくは連続的にコピーする。但し、第１クラスタに異常が発生すると、フェイルオーバー動作が起こり、第１クラスタのクライアントが第２クラスタにリダイレクトされる。第１クラスタの異常が修理または置換（「復元」）されると、修理または置換された第１クラスタがそのクライアントに対してサービスする権威を取り戻す。この復元動作は２段階で行なわれることが好ましい：即ち、好ましくは、第１クラスタ・メタデータの「バルク」転送を伴う「高速回復」段階と、これに続く固定コンテンツ・データの転送を伴う「フェイルバック」段階である。第２クラスタからメタデータを受信すると、フェイルバック段階が完了したか、開始されたかに関係なく修理または置換された第１クラスタがクライアントにサービスする権威を取り戻す。

本発明の比較的核心的な特徴の幾つかを以上に概説した。上述した特徴は飽くまでも説明のためのものである。ここに開示する発明を異なる態様で適用するか、または後述するように発明に変更を施すことによって上記以外の有益な成果を得ることができる。

図１は本発明を実施することによって得られる固定コンテンツ保存アーカイブの簡略化したブロックダイヤグラムである。 図２はそれぞれが対称であり、本発明のアーカイブ・クラスタ・アプリケーションを支援する冗長独立ノード・アレイを示す簡略図である。 図３は所与のノードにおいて実行されるアーカイブ・クラスタ・アプリケーションの種々のコンポーネントを示すハイレベル図解である。 図４はアーカイブをベースとするビジネスの継続性および/または障害回復を容易にするためコンテンツを１つまたは２つ以上の遠隔アーカイブ・サイトにコピーする本発明の方法を示す説明図である。 図５は管理者がクラスタ間にリンクを設定することによりオブジェクト・レベルのコピーを容易にすることを可能にする本発明の方法を示す説明図である。 図６は単向性トポロジーでの一次クラスタ障害を伴う第１使用事例を示す説明図である。 図７は双方向トポロジーを伴う第２使用事例におけるフェイルオーバーの説明図である。 図８は双方向トポロジーを伴う第２使用事例における回復段階の説明図である。 図９は本発明によるソース・クラスタから送り先クラスタへのバルク転送プロセスのための種々の処理状態およびデータ・フローを示す説明図である。

拡張可能なディスク-ベース保存管理システム、好ましくは冗長独立ノード・アレイに基づくシステム・アーキテクチャを提供することもまた公知である。それぞれのノードが異なるハードウェアから成り、「異機種環境にある」と考えることができる。ノードは典型例として、実物理的な記憶ディスク、またはストレージ・エリア・ネットワーク（ＳＡＮ）の場合のように仮想記憶ディスクから成る１つまたは２つ以上の記憶ディスクへのアクセスを有する。それぞれのノードに支持されているアーカイブ・クラスタ・アプリケーション（および、場合によっては、このアプリケーションを実行する内在オペレーティング・システム）は同じか、または実質的に同じである。図示例では、それぞれのノードに存在する（オペレーティング・システムを含む）ソフトウェア・スタックが対称であるのに対して、ハードウェアは異種であることができる。図１に示すようなシステムを使用して、企業は文献、ｅメール、衛星画像、診断画像、チェック画像、音声記録、ビデオなどのような多様な固定コンテンツ情報を永久保存することができる。上記情報の種類は説明の便宜上列記下に過ぎないことが言うまでもない。独立サーバー、またはいわゆるストレージ・ノードにデータをコピーすることによって高度の確実性が達成される。それぞれのノードがそのピアと対称であることが好ましい。従って、好ましくはどのノードもすべての機能を実行できるから、いずれか１つのノードが故障してもアーカイブの利用度には殆ど影響しない。

米国特許第７，１５５，４６６号明細書に記述されているように、それぞれのノードにおいて実行される分散ソフトウェア・アプリケーションはディジタル資産をファイル転送し、保存し、管理し、検索する。図２の実施例において、個々のアーカイブの物理的境界はクラスタと呼称される。典型的には、クラスタは単一のデバイスではなく、デバイスの集積である。デバイスは同質であってもよいし、異種であってもよい。典型的なデバイスは例えばLinuxのようなオペレーティング・システムを運用するコンピュータまたはマシーンである。コモディティ・ハードウェアにおいてホストとして機能するLinux-ベース・システムのクラスタは少数のストレージ・ノード・サーバーから数千テラバイトのデータを保存する多数のノードまで拡張可能なアーカイブを提供する。このアーキテクチャによって、常にストレージ容量を組織が必要とするアーカイブの増大に合わせることができる。アーカイブが常時デバイスの故障から保護されるように、クラスタ全体に亘ってデータがコピーされることが好ましい。ディスクまたはクラスタが故障すると、クラスタは同じ
データのコピーを保持する他のノードのクラスタへ自動的に切り替わる。

図示のクラスタは好ましくは大別して下記のコンポーネントから成る：ノード２０２、１対のネットワーク・スイッチ２０４、配電ユニット（ＰＤＵ）２０６、および無停電電源（ＵＰＳ）２０８。ノード２０２は典型例として、１つまたは２つ以上のコモディティ・サーバーから成り、ＣＰＵ（例えば、Intel ｘ８６）、適当なランダム・アクセス・メモリ（ＲＡＭ）、１つまたは２つ以上のハード・ドライブ（例えば、標準的なＩＤＥ/ＳＡＴＡ、ＳＣＳＩなど）、および２つ以上のネットワーク・インターフェース（ＮＩＣ）カードを含む。典型的なノードは２．４ＧＨｚチップ、５１２ＭＢＲＡＭ、および６つの２００ＧＢハード・ドライブを含む２Ｕラック・マウント方式ユニットである。但し、本発明はこれに制限されるものではない。ネットワーク・スイッチ２０４はノード間のピア対ピア通信を可能にする内部スイッチ２０５、および追加クラスタがそれぞれのノードにアクセスすることを可能にする外部スイッチ２０７から成る。いずれのスイッチもクラスタ中のすべてのノードを取扱うのに充分な数のポートを必要とする。この条件を満たすためにはEthernetまたはGigEスイッチを使用すればよい。すべてのノードおよびスイッチに対する給電にはＰＤＵ２０６を使用し、すべてのノードおよびスイッチを保護するためにはＵＰＳ２０８を使用する。クラスタは多くの場合、公衆インターネット、企業イントラネット、またはその他の広域または構内ネットワークのようなネットワークと接続可能である。図示例の場合、クラスタは企業環境内に実装される。このクラスタには、例えば、サイトの企業ドメイン・ネーム・システム（ＤＮＳ）ネーム・サーバーを介してナビゲートすることによって到達することができる。例えば、クラスタのドメインが既存ドメインの新しいサブドメインである場合が考えられる。代表的な実施例として、このサブドメインは企業ＤＮＳサーバーにおいてクラスタ自体におけるネーム・サーバーに任せられる。エンドユーザーは公知のインターフェースまたはアクセス・ツールを利用してクラスタにアクセスする。即ち、クラスタへのアクセスは、例えば、API、またはその他の公知またはその後開発されたアクセス方法、サービス、プログラムまたはツールを介して、ＩＰ-ベースのプロトコル(HTTP、FTP、NFS、AFS、SMB、ウェブ・サービスなど）に従って実行することができる。

クライアント・アプリケーションは標準的なUNIXファイル・プロトコル、またはHTTP APIのような１種類または２種類以上の外部ゲートウェイを介してクラスタにアクセスする。アーカイブは標準的なUNIXファイル・プロトコル設計の仮想ファイル・システム、例えば、NFS、FTP、SMB/CIFSなどを介して表示することが好ましい。

１つの実施例では、アーカイブ・クラスタ・アプリケーションが（例えば、Ethernetを介して）クラスタとしてネットワーク化された冗長独立ノード・アレイ（Ｈ-ＲＡＩＮ）で実行される。所与のノードのハードウェアは異質であってもよい。但し、確実性のため、それぞれのノードは図３に示すように幾つかのランタイム・コンポーネントから成る（同じインスタンスか、または実質的に同じインスタンスである）分散アプリケーションのインスタンス３００を実行することが好ましい。即ち、ハードウェアは異質であってもよいが、（少なくとも本発明に関する限り）ノードにおけるソフトウェア・スタックは同じである。これらのソフトウェア・コンポーネントはゲートウェイ・プロトコル層３０２、アクセス層３０４、ファイル・トランザクション/管理層３０６、およびコア・コンポーネント層３０８から成る。尚、ここに使用する「層」という表現は説明の便宜上の表現であって、その機能を別の表現でも特徴付けできることは当業者のよく知るところである。１つまたは２つ以上の層（またはこれに含まれるコンポーネント）は一体化されていてもいなくてもよい。複数の層に亘って幾つかのコンポーネントを共用してもよい。メタデータをファイルとして表示しながら、アーカイブ・コンテンツを元のフォーマットにすることが好ましい。

ゲートウェイ・プロトコル層３０２におけるゲートウェイ・プロトコルは既存のアプリケーションに対して透過的である。具体的には、ゲートウェイはカスタム・アプリケーションを構成するためＮＦＳ３１０やＳＭＢ/ＣＩＦＳ３１２のようなネイティブ・サービスおよびウェブ・サービスＡＰＩを提供する。アクセス層３０４はアーカイブへのアクセスを可能にする。具体的には、本発明の場合、固定コンテンツファイル・システム（ＦＣＦＳ）３１６がネイティブ・ファイル・システムをエミュレートすることによってアーカイブ・オブジェクトへのフルアクセスを可能にする。ＦＣＦＳは普通のファイルであるかのようにアプリケーションがアーカイブ・コンテンツに直接アクセスすることを可能にする。メタデータをファイルとして表示しながら、アーカイブ・コンテンツをオリジナル・フォーマットにすることが好ましい。ＦＣＦＳ３１６はディレクトリの標準的なビュー、許可およびルーチン・ファイル-レベル・コールを提供するから、管理者は慣れた態様で固定コンテンツ・データをセットアップすることができる。ファイル・アクセス・コールを好ましくはユーザー-スペース・デーモンが傍受して（層３０８の）該当するコア・コンポーネントへ伝送し、この該当コア・コンポーネントが呼出しアプリケーションに対する適切なビューを動的に作成する。自主的なアーカイブ管理を容易にするため、FCFSコールをアーカイブ・ポリシーによって制約することが好ましい。１例として、管理者またはアプリケーションは保存期間（所定のポリシー）が未だ有効なアーカイブを消去できない。

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

コア・コンポーネントはポリシー・マネジャー３２６のほかに、メタデータ・マネジャー３２８、およびストレージ・マネジャー３０８の１つまたは２つ以上のインスタンスをも含む。好ましくはメタデータ・マネジャー３２８をそれぞれのノードにインストールする。全体として、クラスタ中のメタデータ・マネジャーはすべてのアーカイブ・オブジェクトを管理する分散データベースとして作用する。所与のノードにおいて、メタデータ・マネジャー３２８は、好ましくはそれぞれのオブジェクトが外部ファイル（「ＥＦ」、即ち、保管されるためアーカイブに加わったデータ）とアーカイブ・データが物理的に位置づけられている一連の内部ファイル（それぞれの「ＩＦ」）との間に位置するアーカイブ・オブジェクトのサブセットを管理する。同じメタデータ・マネジャー３２８が他のノードからコピーされた一連のアーカイブ・オブジェクトをも管理する。従って、すべての外部ファイルの現況を幾つかのノードにおける複数のメタデータ・マネジャーが利用することができる。ノードに故障が発生した場合、このオペレーションについては詳しく後述する。ストレージ・マネジャー３３０は分散アプリケーションにおける他のすべてのコンポーネントが利用できるファイル・システム層を提供する。好ましくは、これがノードのローカル・ファイル・システム中にデータ。オブジェクトを保管する。所与のノードにおけるそれぞれのドライブはこのドライブ独自のストレージ・マネジャーを有することが好ましい。これにより、ノードは個別のドライブを排除してスループットを最適化することが
できる。ストレージ・マネジャー３３０はまた、システム情報、データに対する完全性チェックおよびローカル・ディレクトリ構造検討能力を提供する。

図３に示すように、クラスタは通信ミッドウェア３３２およびＤＮＳマネジャー３３４を介して内部および外部通信を管理する。インフラストラクチャー３３２はアーカイブ・コンポーネント間の通信を可能にする効率的且つ信頼度の高いメッセージ-ベースのミッドウェア層である。図示例の場合、この層がマルチキャストおよび２地点間通信を可能にする。ＤＮＳマネジャー３３４はすべてのノードを企業サーバーに接続する分散ネーム・サービスを運用する。好ましくは、ＤＮＳマネジャーが（独自に、またはＤＮＳサービスと協働して）すべてのノードに亘ってリクエストを負荷平衡させることによってクラスタのスループットおよび利用度を最大限に高める。

図示の実施例では、ＡｒＣアプリケーション・インスタンスがRed Hart Linux 9.0のようなベース・オペレーティング・システム３３６において実行される。通信ミッドウェアは使い勝手の良い分散型通信メカニズムである。その他のコンポーネントとして固定コンテンツファイル・システム（ＦＣＦＳ）３１６に利用できるＦＵＳＥ（ファイルシステム・イン・USErspace）を含むことができる。ＮＦＳゲートウェイ３１０は標準nfsd Linux Kernel NFSドライバーのユーザー・スペース・インプレメンテーションであるUnfsdによって実施することができる。それぞれのノードにおけるデータベースは、例えば、オブジェクト関連データベース管理システム（ＯＲＤＢＭＳ）である（本明細書においてＰｏｓｔｇｒｅｓとも呼称する）ＰｏｓｔｇｒｅＳＱとして実装することができる。ノードはＪａｖａＨＴＴＰサーバー/サーブレット・コンテナーであるＪｅｔｔｙのようなウェブ・サーバーを含むことができる。言うまでもなく、上記メカニズムは説明のための例に過ぎない。

所与のノードにおけるストレージ・マネジャー３３０は物理的保管デバイスを管理する。好ましくは、それぞれのストレージ・マネジャー・インスタンスが、すべてのファイルが配置アルゴリズムに従って配置されるシングル・ルート・ディレクトリの管理に責任を負う。１つのノードにおいて複数のストレージ・マネジャー・インスタンスを同時に実行され、それぞれのインスタンスがシステムにおける異なる物理的ディスクを表わすのが普通である。ストレージ・マネジャーはドライブを取り除き、システムの残余部分からインターフェース技術が利用される。ファイルの書込みを要求されると、ストレージ・マネジャー・インスタンスは任せられた表現のためのフルパスおよびファイル・ネームを生成する。図示の実施例では、ストレージ・マネジャーに保存すべきそれぞれのオブジェクトが未加工データとして受信され、ストレージ・マネジャーはこれを保存する際にファイルにこのストレージ・マネジャー自体のメタデータを付加することによって種々の情報を記録する。例えば、このメタデータは下記要素を含む：ＥＦの長さ（バイトで表わされる外部ファイルの長さ）、ＩＦセグメントのサイズ（このファイル部分のサイズ）、ＥＰ保護表現（ＥＦ保護モード）、ＩＦ保護役割（この内部ファイルの表現）、ＥＦ作成タイムスタンプ（外部ファイルのタイムスタンプ）、シグネチャ（シグネチャのタイプを含む書込み（ＰＵＴ）時における内部ファイルのシグネチャ）およびＥＦファイル・ネーム（外部ファイルのファイル・ネーム）。内部ファイルのデータと共にこの付加メタデータを保存することによって保護レベルを高めることができる。具体的には、スキャベンジングによって、内部ファイルに保存されているメタデータからデータベース中の外部ファイル記録を作成できる。

上述したように、内部ファイルは好ましくはアーカイブ・オブジェクトにおけるオリジナル・ファイルの一部を表わすデータの「チャンク」であり、好ましくは種々のノードに配置されて分散化および保護ブロックを実現する。典型例としては、それぞれのアーカイブ・オブジェクトごとのメタデータ・マネジャーに１つの外部ファイル項目が存在し、そ
れぞれの外部ファイル項目ごとに多数の外部ファイル項目が存在する。多くの場合、内部ファイルのレイアウトはシステムに応じて異なる。実施態様によっては、ディスクにおけるこのデータの実際の物理フォーマットが一連の可変長レコードとして保存される。

リクエスト・マネジャー３２４はシステム内の他のコンポーネントとの対話によってアーカイブ・アクションを実行するのに必要な一連のオペレーションを実行する任務を有する。リクエスト・マネジャーは種類の異なる多くの同時アクションを支援し、失敗したトランザクションをロールバックすることができ、実行に長時間を要するトランザクションを支援する。リクエスト・マネジャーはまた、アーカイブにおける読取/書込みオペレーションが正しく行なわれ、すべてのリクエストが常に既知の状態にあることを保証する。複数のノードに亘る複数の読取/書込みオペレーションを協調させることによって所与のクライアントのリクエストを満足させるようにトランザクション制御機能をも有する。さらにまた、リクエスト・マネジャーは最近使用されたファイルをキャッシュに格納して、セッションおよびデータブロックのためのバッファリング機能をも果す。

クラスタの主要任務は無限数のファイルを確実にディスクに保存することである。所与のノードが、何らかの理由で到達できない、または利用できないという意味で「信頼できない」と考えられる場合がある。このような信頼できない複数のノードが協働して信頼できる利用度の高いストレージを作成する。一般に、保存しなければならない２種類の情報がある：即ち、ファイルそのものと、ファイルに関するメタデータとの２種類である。

以上に既知のアーカイブ・クラスタを説明した。企業（またはその他の事業体）が分散クラスタを実現し、クラスタのコピーおよび回復を可能にする方法を以下に説明する。

クラスタ・リカバリ
以下に説明する本発明には下記の述語が適用される。

レプリケーション：プライマリー・クラスタからレプリカ・クラスタへ効率的にデータをコピーするプロセス。正常な操作条件下ではプライマリー・クラスタにおけるオーソリテーティブ・ネームスペースがレプリカ・クラスタにおけるバックアップ・ネームスペースへコピーされるデータのソースである。

プライマリー・クラスタ（ＰＣ）：正常な操作条件下においてオーソリテーティブ・ネームスペースを含むクラスタ。プライマリー・クラスタは「ソース」と呼称されることがある。フェイルオーバーまたはフェイルバック手順の過程ではプライマリー・クラスタ指定は変化しないことが好ましい。必ずしも制限的な意味ではないが、多くの場合、プライマリー・クラスタは地理的な位置で特定される。プライマリー・クラスタが故障している間、プライマリー・クラスタは一時的にアーソリテーティブ・ネームスペースを提供することを止め、リカバリの間バックアップ・ネームスペースとなることができる。リカバリが完了すると、プライマリー・クラスタは多くの場合オーソリテーティブ・ネームスペースとしての役割を取り戻す。リカバリ・シナリオによっては、故障したプライマリー・クラスタを新しいプライマリー・クラスタに置き換え、前者は新しい場所で動作することになる。

レプリカ・クラスタ（ＲＣ）：正常な操作条件下でバックアップ・ネームスペースを提供するクラスタ。レプリカ・クラスタは「ターゲット」または「レプリカ」と呼称されることがある。必ずしも制限的な意味ではないが、多くの場合、レプリカ・クラスタは地理的な位置で特定される。フェイルオーバーまたはフェイルバック手順の過程ではレプリカ・クラスタ指定は変化しないことが好ましい。プライマリー・クラスタが故障している間、レプリカ・クラスタがクライアントに対してオーソリテーティブ・ネームスペースを提
供することができる。

ネームスペース（ＮＳ）：一連のファイルおよびディレクトリのための論理的容器。ネームスペースは収容しているオブジェクトに関連する文脈を提供して（異なるネームプレース中に存在する）同名のアイテムとの弁別を可能にする。好ましくは完全なファイルシステム・ツリーを提供する。従って、異なるネームスペース中に存在する限り、同名のファイルが同じクラスタに共存することを可能にする。クラスタは（外部クライアントにより書込み可能な）オーソリテーティブ・ネームスペースまたは（外部クライアントのよる読出し専用の）バックアップ・ネームスペースを提供することができる。クラスタは役割の異なる複数のネームスペースを同時に主宰することができる。

オーソリテーティブ・ネームスペース（ＡＳ）：オブジェクトの最新バージョンを収納している書込み可能なネームスペース。所与のオブジェクト群に関して常時唯一のオーソリテーティブ・ネームスペースが存在できることが好ましい。クラスタはプライマリー・クラスタにおけるオーソリテーティブ・ネームスペースから、レプリカ・クラスタによって主宰される１つまたは２つ以上のバックアップ・ネームスペースにコピーするように構成されている。オーソリテーティブ・ネームスペースを提供するクラスタがバックアップ・ネームスペースを提供するように格下げされることになる。フェイルオーバーおよびリカバリの過程ではネームスペースは一時的にオーソリテーティブ・コピーを失うことになる。

バックアップ・ネームスペース（ＢＮ）：外部クライアントによる書込みが不能であり、コピーするプロセスを介してオーソリテーティブ・ネームスペースからデータを受信するネームスペース。コピー・プロセスはゲートウェイ・アクセスと非同期であるから、コピーされたデータは常に最新データではないと考えねばならない。バックアップ・ネームスペースを提供するクラスタはフェイルオーバーのプロセスにおいて格上げされてオーソリテーティブ・ネームスペースを提供することができる。

レプリケーション：プライマリー・クラスタからレプリカ・クラスタへ効率的にデータをコピーするプロセス。正常な操作条件下ではプライマリー・クラスタにおけるオーソリテーティブ・ネームスペースがレプリカ・クラスタにおけるバックアップ・ネームスペースへコピーされるデータのソースである。

フェイルオーバー：プライマリー・クラスタに故障が発生した際に、レプリカ・クラスタをバックアップ・ネームスペース提供からオーソリテーティブ・ネームスペース提供に切替えるプロセス。このプロセスの一部として、クラスタ・クライアントをプライマリー・クラスタからレプリカ・クラスタへリダイレクトすることができる。

リカバリ：レプリカ・クラスタからプライマリー・クラスタへ迅速且つ効率的にデータをコピーするプロセス。高速リカバリは最初にコピーされた固定コンテンツ・データとは別にＰＣからＲＣへメタデータを転送することによって可能となる。ＰＣがメタデータを取り戻すと、ＰＣは直ちに第１アーカイブに対する支配権を取り戻すことができる。リカバリ・プロセスはプライマリー・クラスタがレプリカ・クラスタへ障害迂回し、修理および/または取替えされた後に行なわれる。レプリカ・クラスタにおけるオーソリテーティブ・ネームスペースはそのデータをプライマリー・クラスタにおけるバックアップ・ネームスペースにコピーする。

フェイルバック：リカバリ・プロセスが完了すると同時にレプリカ・クラスタがオーソリテーティブ・ネームスペース提供からバックアップ・ネームスペース提供に切り替わり、プライマリー・クラスタがバックアップ・ネームスペース提供からオーソリテーティブ
・ネームスペース提供に切り替わるプロセス。このプロセスの一部として、クラスタ・クライアントをレプリカ・クラスタからプライマリー・クラスタへリダイレクトすることができる。

リンク：コピー・プロセスのため２つのクラスタ間に設定される連携。このリンクは一連のデータをソースからターゲットにコピーする方法を表わす。１つの実施例として、最小の「データ・セット]はネームスペースである。リンクは多くの場合、ソース・クラスタＤＮＳネーム、ターゲット・クラスタＤＮＳネーム、コピー・プロセスのスケジュール、移送の形態、コピーされるネームスペース、および認証情報を含む。

チェンジ・ログ：所与のソース-クラスタ領域および時間範囲に関する変更の順序付リスト。

コンプリート・チェンジ・ログ：完全変更の記述を含む変更ログ。

チェンジ：例えば、形成、削除、保存などのような動機付けゲートウェイ・オペレーションに関して提示されることが多い所与のアーカイブ・オブジェクトの状態変更。変更は通常ソース・クラスタにおいてのみ行なわれ、特定した上でターゲット・クラスタへ移動させねばならない。

チェンジ・デスクリプション：アーカイブ・オブジェクトに対する１つまたは２つ以上の変更の圧縮された部分ビュー。変更記述は変更の事実と変更後のオブジェクトの望ましい最終状態を示す。変更記述は内部ファイルとは対照的に、アーカイブ・データベースから得られる情報で構成することが好ましい。（ユーザー・メタデータを閉じる、またはファイルを作成する、などのような）幾つかのオペレーションには、変更記述が変更を表わすのに必要なすべてのデータを含むのではなく、必要なデータのソースに関する参照を含まねばならない。

ローカル・チェンジ・デスクリプション：ローカル・クラスタにすべての参照データが含まれている完全変更記述または変更記述。

リモート・チェンジ・デスクリプション：完全変更記述ではなく、リモート・クラスタにおけるデータに関する参照を含む変更記述。リモート・クラスタは変更ログで特定される。

インビジブル・ファイル：いかなるゲートウェイを介してもアクセスできないアーカイブ・ファイル。これらのファイルは究極的にはデータベースに加えられる可能性がある記録の安全な中間的保存手段として利用される。インビジブル・ファイル・コンテンツは通常、メッセージ層-符号化構造であるが、これに限定されるものではない。

アドミニストレータ：クラスタ管理者。典型的には、管理すべきクラスタに関する管理パスワードを有し、クラスタの構成と管理を任務とする。「管理者」という名称の頭に所管のコピー・クラスタの名称が付記されることが多い。

図４は３つのレプリカ・クラスタ４０２（１つは米国ウォバシャに、１つは英国ルートンに、１つは日本国京都に設置されている）と共にプライマリー・クラスタ４００を示す。多くの場合、クラスタは異なる地理的位置に設置されるが、これは必須条件ではない。ＰＣ４００からそれぞれのＲＣ４０２に（コピー・プロセスによって）コンテンツをコピーすることによって事業の継続性や災害の復旧を可能にする。即ち、機能停止の事態が発生した場合、クライアント・アプリケーションはレプリカ・クラスタに切替えることによ
ってシステムの停止時間を最短にとどめることができる。復旧機能（リカバリー・プロセス）は新しいプライマリー・クラスタの迅速な再生を可能にし、この新しいプライマリー・クラスタは元のままに再生/復元されたＰＣであるか、または全く新しいＰＣである。

図５はクラスタ間のコピーイング・リンク形成を可能にする管理コンソールのグラフィカル・ユーザー・インターフェース（ＧＵＩ）５００を示す。上述したように、リンクはソース・ネームスペースを特定のターゲット・クラスタにコピーすることを可能にする。リンクを構成するには１つまたは２つ以上の選択肢がある。即ち、ディジタル・シグネチャー・オプションを選択すれば、リンクの信頼性を確保することができる。圧縮オプションを選択すれば、リンク全体に亘ってデータを圧縮することによりＷＡＮ帯域幅条件を極力軽減することができる。暗号化オプションを選択すれば、もしリンクが（インターネットのような）パブリック・ネットワークを包含する場合に安全確保を必要とする場合に、（例えば、ＳＳＬのような）暗号化を採用することができる。さらにまた、スケジューリング・オプションはコピーが行われる適時とコピーの重要度の選択を可能にする。これらのオプションが管理者によって組み合わされることが好ましい。ＰＣから１つまたは２つ以上のＲＣへのアーカイブ・オブジェクトのコピー・プロセスは同期的に且つ確実に行なわれることが好ましい。

好ましくは、固定コンテンツ・データ、メタデータ、およびポリシー情報（例えば、属性の分断など）を含めてオブジェクト・レベルでコピーを追跡チェックする。ＧＵＩは、例えば、オブジェクトの数および容量などのようなメトリクスを表示することもできる。如何なるアーカイブも、管理者が本発明のコピー・プロセス、リカバリ、およびフェイルバックのためにアーカイブを設定することを可能にするマシーンを含むことができる。

多重コピーイング・トポロジー方式を実行することができる。簡単な方式としては、単一のプライマリー・クラスタがそのデータ・オブジェクトを単一のレプリカ・クラスタにコピーする方式がある。これは１対１（ＰＣ対ＲＣ）のコピー・プロセスである。単一のＰＣが図４に示すように複数のＲＣにそのデータをコピーする場合もある。このような１対多数方式のアプローチは保存に要するコストという点でコストが高くなる。「多数対１」方式は複数のプライマリー・クラスタが大容量の中央レプリカ・クラスタにコピーする場合に採用される。「双方向」アプローチでは、第１および第２クラスタが互いに相手にコピーする。「、マルチ-ホップ」アプローチでは、ＡがＢにコピーし、次いでＢがＣにコピーする。（上記方式を組み合わせる）ハイブリッド方式を実行することもできる。実行されるトポロジーに関係なく、単一または複数のコピーイング・リンクを使用してクラスタ管理者が所与のトポロジーを作成することが好ましい。リンクの構成によって究極的なネットワーク・トポロジーが決定されることが好ましい。また、リンクの形成は２地点間であることが好ましい。例えば、１対多数トポロジーを設定するには、プライマリー・クラスタ管理者はそれぞれのＲＣとのリンクを形成することになる。次いで、それぞれのＲＣ管理者がこれらのリンクの形成を完成することになる。マルチ-ホップ方式の場合には、中間クラスタを介してまたはエンド・レプリカから直接的にデータを復旧できるためには、リンク構成が「チェーン」コンセプトを理解しなければならないという条件が加わる。

図６は単向性トポロジーにおけるプライマリー・クラスタを伴う第１使用例を示す。この実施例においてはクラスタ６００がＰＣであり、ＲＣとしてのクラスタ６０２にコピーする。これがステップ６０１である。即ち、ＲＣはクラスタ６００のための専用レプリカである。ここで、ＰＣが完全に故障状態に陥ると仮定する。ＲＣ管理者は管理者ＧＵＩを利用することによってクラスタ６０２がクラスタ６００のネームスペースに代わってオーソリテーティブになるように操作する。その結果、クラスタ６００のクライアント６０４はクラスタ６０２にリダイレクトされて読出し/書込みを行なうことになる。その後、ク
ラスタ６００に代わって新しいクラスタ６０６がインストールされると仮定する。クラスタ６０６の管理者は管理者ＵＩを介してクラスタ６０２とのリンクを復旧する。ステップ６０５において、クラスタ６０２の管理者はそのＵＩを介してリカバリを開始する。リカバリが完了すると（または完了に近づくと）、クラスタ６０２の管理者はネームスペースを「読出し専用」としてマーキングする。新しいクラスタ６０６へのメタデータ転送を完了すると、クラスタ６０２はクラスタ６０６に対してクラスタ６０６が読出し/書込みモードになることを指示するメッセージを送信する。こうしてリカバリが完了する。この時点でクラスタ６０６は支配権を取り戻し、クライアントはクラスタ６０２からクラスタ６０６へリダイレクトされる。好ましくは、ステップ６０７に示すように、コピー・プロセスが両方向に継続する。即ち、クラスタ６０６はクライアント（クラスタ６００の元のクライアント）に読出し/書込みアクセスを提供しながらクラスタ６０２からデータを引き出し続ける。このオペレーションはクラスタ６０６がすべてのデータを回復するまで続く。同時に、クラスタ６０６はクラスタ６０２に向かってすべての新しい変更をコピーし、クラスタ６０２は本来のＲＣ状態に戻る。

図６に示すオペレーションはＰＣに部分的な故障が生じた場合も同様であり、この場合、ＰＣは全体が置き換えられるのではなく、修理されるだけである。

第１クラスタにメタデータが復帰すると、クライアントは第１クラスタからすべてのデータを読み出すことができる。この時点で、アーカイブはクライアントのため、未だ第２クラスタから返還されていないコンテンツを検索する。多くの場合、クライアントはリダイレクトされず、コンテンツが返還されていないことに気付いていない。第２クラスタから引き出されるのと並行して読出しが行われる時、クライアントは性能の低下を経験することがある。

図７および図８は双方向トポロジーを伴う第２使用例のフェイルオーバーおよびリカバリ段階を示す。この実施例では、それぞれのクラスタが他のクラスタにコピーしている。即ち、クラスタ７００はクラスタ７０２にコピーされるネームスペースＡを有するプライマリー・クラスタであり、クラスタ７０２はクラスタ７００にコピーされるネームスペースＢを有するプライマリー・クラスタである。ステップ７０１は正規の双方向コピー・プロセスを示す。ステップ７０３において、クラスタ７００に故障が生じた。上述したように、ネームスペースＡのクライアントはクラスタ７０２へリダイレクトされる。図８に示すように、本発明の高速クラスタ・リカバリがクラスタ７０２において開始された（この実施例では、図６に示す実施例の場合のように全体を新しいクラスタと交換するのではなく、クラスタ７００がバックアップした場合を想定している）。リカバリ段階がステップ８０１である。クラスタ７００がスタンドアップした後、クラスタ７０２からクラスタ７００へ矢印で示すようにネームスペースＡのメタデータが提供される。このようなリカバリの進行中にもネームスペースＡのクライアントはクラスタ７０２のサービスを受けている。これと同時に、ネームスペースＢは再びクラスタ７００へのコピー・プロセスを開始する。リカバリが完了すると、ステップ８０３に示すようにフェイル-段階が始まる。この時点で、ネームスペースＡは再びクラスタ７００へのコピー・プロセスを開始する。（初めにクラスタ７００からクラスタ７０２にコピーされた）データがクラスタ７００のネームスペースＡへ返還される。しかし、メタデータが高速でリカバリされるから、リカバリ段階（ステップ８０１）が完了すると同時に、ネームスペースＡのクライアントはデータがクラスタ７００に返還されるのを待つことなくクラスタ７００からサービスを受けることができる。

以下に、コピー・プロセス、フェイルオーバー、およびリカバリに関してさらに詳細に説明する。

レプリケーション（コピー・プロセス）
コピー・プロセス・マネジャーは他のコピー・プロセス・コンポーネントを統括する最上位のコンポーネントである。その役割はコピー・プロセス全体と構成およびコピー状態情報とを調整することにある。コピー・プロセス・マネジャーの常態における制御流れは下記の通りである。即ち、起動すると、先ず構成をロードする。それぞれのコピー・プロセス・リンクごとに、コピー・プロセス・マネジャーは下記のアルゴリズムを繰返す：コピー・プロセス・リンク・オブジェクトを作成し；スケジューラに事象を記録し；コピー・オブジェクトを作成し；リンクがネームスペース・マスターであるかどうかを確認して、もしマスターであればコピー・スタート送信機能（ ）をコールし；さもなければ（即ち、リンクがネームスペース・マスターでなければ）、コピー・スタート受信機能（ ）をコールする。コピー・プロセス・マネジャーはスケジューラ/優先順位に変化があればこれに応答して該当のリンクでコピー・セット優先度機能（ ）をコールする。停止の必要があれば、これに応答してコピー・プロセス・マネジャーはすべてのリンクでコピー停止機能（ ）をコールする。

コピー・プロセス・マネジャーはコピー・プロセスの全面的なトップ・レベル制御を行なう。コピー・プロセス・リンクの両端は同じアルゴリズムを繰返すことが好ましい。両端はスケジュールに従って起動・停止するだけであるから、このプロセスにクラスタ間の制御通信は不要である。一方の端部でリンクが中断された場合にのみ、他方の端部におけるコピー・プロセス・マネジャーに対してプロセス中止のメッセージが送信される。

「常態」制御流れと「復旧」制御流れはコピー・プロセスに伝達される制御フラッグに幾つかの相違点があることを除けば殆ど同じである。

好ましくは、管理エンジン（図３を参照）によってコピー・プロセス・マネジャーを起動させる。上述したように、コピー・プロセス・マネジャーはコピー・プロセス構成をロードし、この構成で１つまたは２つ以上のコピー・プロセス・リンクを形成する。好ましくは、コピー・プロセス・マネジャーが起動、停止および優先度変更に関する通告をすべて受信してレジスタに記録し、これらの情報を調整機構としての役割に利用することによって挙動の変更を必要とすることをリンクに通告する。スケジューラの起動・停止に対応して、コピー・プロセス・マネジャーは該当リンクと連携するコピー・プロセス・ワーカー・スレッド、例えば、リンクごとの変更ログ・コレクション・コンポーネントなどを協調させる。リンクがスケジュールされれば、コピー・プロセス・マネジャーはスケジューラからの事象「起動」指令に従って該当のリンクを作動させるだけである。上述したように、リンクが起動メッセージを受信すると、コピー・オブジェクトを作成し、ネームスペースの状態（オーソリテーティブかバックアップか）に応じてコピー・オブジェクトの送信開始または受信開始をコールする。スケジューラから優先度変更を受信すると、コピー・プロセス・マネジャーは優先度設定機能を介して該当のリンクに状態変更を通告する。コピー・プロセスは適当な時点において優先度が変更されるように調整される。プロセスを停止しなければならない時には、コピー・プロセス・マネジャーが停止をコールし、このコールでコピー・プロセスは直ちに終了する。

リンクの管理
ここに使用するレプリケーション・リンクという表現はコピー・プロセスのため２つのクラスタを連携させる構成を指す。リンクの管理にはこのような連携構成の形成、変更および削除が含まれる。リンク・マネジャーはこの機能性を実現する。

リンクの形成
コピー・プロセスのため２つのクラスタを連携させる必要が生じた場合、レプリケーション・リンクを形成しなければならない。後述するセキュリティ上の観点から、リンクの
形成はプライマリー・クラスタとレプリカ・クラスタの双方からの管理を伴う２-ステップ・プロセスであることが好ましい。

このプロセスを起動させるため、ＰＣ管理者は管理ＵＩを利用してレプリケーション・リンクの形成を起動させる。この場合、管理者がＲＣのＤＮＳネーム、優先度およびスケジュール情報、および何らかの認証情報(ユーザーネーム/パスワード）の提供を要求されることが好ましい。このオペレーションの結果、これらの情報を含む構成オブジェクトがＰＣに形成され、ＲＣ側のレプリケーション・マネジャーに対して、リンクの形成を要請するメッセージが送信される。このメッセージは典型的には以下に挙げる情報を含む：プライマリー・クラスタのＤＮＳネーム；認証情報、および（もしＳＳＬが使用されるなら）プライマリー・クラスタのＳＳＬ証明書の公開部分；コピー・プロセスのための転送構成（例えば、ＨＴＴＰ、ＳＳＬに採用されているＨＴＴＰなど）；コピーされるネームスペース；データ・トラフィックを圧縮すべきかどうかを記述するフラッグ。レプリカ・クラスタにこれらの情報が保存され、レプリカ管理者の管理ＵＩにリクエストが提示される。レプリカ管理者はリクエストを受容れるか拒絶するかを選択することができる。リンクが形成され、双方の管理者によって認可されるまでにｎ回のレプリケーション・オペレーションが許されることが好ましい。既にネームスペースが存在するなら、リンク形成が実現しないことが好ましい。必要とあれば、リンクの形成にセーフ・メッセージング・プロトコルを利用することができ、この場合、リンク形成のための情報交換の状態がプライマリー・クラスタ側に記録される。「リンクが形成された」という返事が来ない場合、プライマリー・クラスタ管理者はリンク形成オペレーションを再度試みることができる。リプレイの問題を防止するため、リンク形成メッセージに独自のＩＤが含まれることが好ましい。レプリカ側からのリンク認定メッセージが受信されると、システムはたとえ最初のリンク形成メッセージに対する返事が受信されなくても、リンクが正しく形成されたと想定する。

レプリカ・クラスタからの成功の返事が受信されるまで、プライマリー・クラスタ側の構成状態が持続しないことが好ましい。好ましくは、リンク形成メッセージが独自の識別子を含み、リモート・クラスタが再試行なのか、違法な真似リクエストなのかを検知できるようにする。リンク形成失敗の場合、レプリカ・クラスタ管理者が部分的に形成されているリンクを消去しなければならないことがある。持続的なリンク構成は極めて固定的であり、（作動中、停止状態、などのような）リンク状態はレプリケーション・マネジャーにおいて持続する。リンクが形成されたら、プライマリー・クラスタは構成された情報を利用することによって（ＤＮＳを介して）レプリカ・クラスタの場所を特定し、レプリケーション・オペレーションを開始することができる。それぞれのクラスタは相手クラスタに認定させるためのクライアント証明書としてＳＳＬサーバー証明書を利用することができる。プライマリー・クラスタからレプリカ・クラスタへのメッセージが失敗すれば、リンク形成も失敗に終わり、ＰＣ管理者はプロセスを再開しなければならない。

リンクの修正
スケジュール、優先度、転送および圧縮設定はすべて既存のリンクで修正することができる。その他の変更に際しては、リンクを削除し、再形成することが好ましい。

リンクの削除
レプリケーション・リンクはいずれの管理者によっても削除することができる。２つのクラスタ間の接続性に問題がなければ、リモート・クラスタに対してそちら側でもリンクを削除するようリグエストするメッセージが送信される。リモート・クラスタとの接触が不可能なら、ローカル・リンク構成だけが削除される。

リンクが削除されると、削除された側の構成状態が削除され、リモート側に対してメッ
セージが送信される。リモート側はリンク・ダウンをマーキングするが、状態の削除は一切行なわない。リモート側の管理者がリンクを削除すれば、状態は削除される。この時点で、トラッキング状態の設定変更もすべて削除される。レプリカ・クラスタの管理者がリンクを削除する時、管理者はこのリンクと連携するネームスペースを削除するか否かを選択することができる。リンク削除に関する互いの通信には、リンク成形プロセスの時と同じ「安全」メッセージ・プロトコルを使用することが好ましい。レプリカ側に対応のリンクが構成されていない状態でＰＣがレプリカ側に情報をコピーしようとすると、コピー・プロセスは拒絶される。

リンクの状態
レプリケーション・リンクは一時停止させることができる。その結果、すべての形成設定変更が即時停止し、レプリカ・クラスタに対してデータ・リクエストを停止するようメッセージが送信される。このリンクが管理者によって復旧されるまでこのリンクでのコピー・プロセスは継続されない。一時停止または復旧の状態はリンク構成の残りの部分とともに持続するから、クラスタの再起動によってコピー・プロセスが問題なく再開される。

セキュリティ
上述したように、クライアント側の証明書を含むＳＳＬセキュリティを利用することがレプリケーション・リンクのセキュリティの観点から好ましい。

フェイルオーバー
フェイルオーバーはプライマリー・クラスタに故障が生じた場合に、クラスタ・クライアントがレプリカ・クラスタから、およびレプリカ・クラスタに、引き続き読出し、書込みをできるようにするプロセスである。典型的には、フェイルオーバーは幾つかのステップから成る：即ち、故障の特定、（もし可能なら）プライマリー・クラスタを書込み不能に変更し；レプリカ・クラスタへのバックログ書込みを処理し；クライアントをリダイレクトしてレプリカ・クラスタを使用させる。

所与の時点において、所与のデータ・セットに関して、書込み可能なクラスタが２つ以上存在しないことが好ましい。フェイルオーバー・プロセスによって、２つの書込み可能なコピーが存在するのを防止しながら随時にデータのコピーを読出し/書込みすることができる。

故障の特定
クラスタの故障は管理者によって特定されるのが普通である。必要とあれば、自動的フェイルオーバーも可能であるが、プライマリー・クラスタの故障なのか、プライマリー・クラスタとレプリカ・クラスタとの間のネットワークの故障なのかを自動的に判断するのは多くの場合困難であり、好ましい技術ではない。後者の場合、２つの書込み可能なコピーが生ずることになり、混乱を招く。しかも、プライマリー・クラスタの故障が正確に検出されたとしても、レプリカ側には、クライアントに対してレプリカ・クラスタを利用するように切替える必要があることを知らせる術がない。

書込みを認めないようにプライマリー・クラスタを変更
或る容量まではプライマリー・クラスタを利用できるにも拘らず、管理者がレプリカ・クラスタへのフェイルオーバーを決定した場合、先ず、プライマリー・クラスタを読出し専用であるとマーキングしなければならない。これはプライマリー・クラスタ管理者によって管理ＵＩを介して手動で行なわれることが好ましい。クライアントがプライマリー・クラスタとレプリカ・クラスト双方における同じネームスペースに書き込むとネーミングの不一致を解決することが極めて困難になるから、手動で構成することが望ましい。

バックログを処理
データ・コピー（レプリケーション)プロセスの異なる段階でメタデータおよびデータが移動することが好ましい。即ち、故障が発生した場合、処理すべきメタデータがレプリカ・クラスタに存在することになる。もしプライマリー・クラスタを利用できなければ、このメタデータと連携するデータにアクセスできない。この場合、管理者が一旦フェイルオーバー（書込み可能にする）の意図を通報したら、すべてのメタデータをできるだけ迅速にしょりしなければならない。

書込み可能状態にレプリカを変更
書込み可能となるようにレプリカ・クラスタを切替えるプロセスはレプリカ・クラスタ管理者によって手動で行なわれることが好ましい。管理ＵＩにおいて、レプリカ・クラスタ管理者は該当のリンクまたはリンク群を選択し、これらのリンクを介してコピーされるデータへの読出し/書込みアクセスの提供を開始する。これらのリンクによってサービスされるネームスペースに読出し/書込み可能としてマーキングされ、クラスタはそれぞれのネームスペースに対する書込みを受容れる。

クライアントをレプリカへリダイレクト
クライアント自身の、ＤＮＳ中の、またはクライアントとクラスタの間のネットワークにおけるレプリカ・クラスタにクライアントをダイレクトすることができる。

リカバリ
リカバリはレプリカ・クラスタにおけるＵＩ「リカバー」ボタンを介して管理者によって起動される。このボタンを作動させるには２つの主要条件を満たさねば成らない：プライマリー・クラスタ（マスター）ネームスペースが空であること（後述する部分リカバリを支援する必要がない）；およびＰＣネームスペースが読出し専用モードであること。最悪の故障の場合、新しくインストールされるクラスタが必要であるから、プライマリー・クラスタ・ネームスペースは空である。ソース・クラスタの故障が重大でなければ、プライマリー・クラスタ・ネームスペースを空にしなければならない（部分的リカバリを支援する必要はない）。

部分的リカバリ
所与のクラスタ内に、１つのオーソリテーティブ・コピーが存在し、ゼロまたは多数のバックアップ・コピーが存在することがある。バックアップ・コピーの数は構成パラメータによって制御することができ、このパラメータは「許容故障点数（ＴＰＯＦ）とも呼称される。もしプライマリー・クラスタがＴＰＯＦ＋１を超えるノードを失えば、クラスタ上のすべてのデータを消去して完全に復元するには最適とは言えない。同様に、レプリカ・クラスタにＴＰＯＦ＋１の故障が発生すると、レプリカ全体を消去し、マスターを再コピースルには理想的ではない。いずれの場合も部分復旧から恩恵を受けることになる。

即ち、プライマリー・クラスタにＴＰＯＦ＋１の故障がある場合、完全な故障の際と同様にコピー・プロセス・フェイルオーバーが行なわれる。しかし、レプリカ・クラスタにＴＰＯＦ＋１の故障が発生した場合には、フェイルオーバーは行われない。両クラスタにＴＰＯＦ＋１の故障が発生すると、いずれのシステムもゲートウェイ・ロードを支援できないからフェイルオーバーは不可能である。この場合、それぞれの方向から１回ずつ部分的修理が２回相次いで行われる。この部分リカバリ・プロセスでリカバー可能な紛失データが特定され、適当な変更ログが形成され、必要なら、リカバー不能な紛失データに関して報告する。

コピー
コピー、リカバリ、およびフェイルバックの段階において、データ流れに対してバルク
・コピー・プロセスを実行することが好ましい。

バルク・コピーにはアーカイブへのデータ・ローディングにバッチング・アプローチを採用することが好ましい。ソース・クラスタではクラスタ領域ごとにプロセスが変更記述を集め、ターゲット・クラスタに向かって移動させる。それぞれの変更ログがターゲットに保存される時点で、システムはどのような変更をコピーすべきかを知る。このステップの後にソースが故障すると、システムはどのような変更が失われたかをも知る。プロセスはまたそれぞれの変更記述によって指摘されるデータをターゲット・クラスタに取込み、それぞれのログを「受容れた」としてマーキングする。この時点において、ログのコピーは完全に成功裡に行なわれる。換言すると、固定コンテンツ・データおよびメタデータがコピーされたことになる。このステップの後にソースが故障しても、データが失われることはない。プロセスはまた受容れた変更をターゲット・クラスタ中のデータベースにアップロードし、変更を「統合された」としてマーキングする。この時点において、コピーされた変更はターゲット・クラスタ中のすべてのゲートウェイを介して読出しアクセスに利用することができる。この時点でソースが故障しても、すべての変更を利用することができる。

バルク・コピー・プロセス中、コピー・プロセスのパイプラインの段階によっては特有の変更があり得る。つまり、これらの段階はアトミックではない。所与のコピー・プロセスにおいて、部分的にのみ完全な段階がある。即ち、或る変更はこの段階をクリアし、或る変更はクリアしない。段階ごとに要する時間に差があることが多い。先行の段階が完了する前に後続の段階がはじめることがあるが、先行の段階が完了するまでに後続の段階が完了することはできない。

バルク・コピー・プロセスには幾つかの挙動差がある。最初のコピー・プロセスは既に設定されているプライマリー・クラスタと新しいレプリカ・クラスタとの間で開始される。最高の優先度は先ずＰＣからＲＣにすべてのデータをコピーすることにある。追加のネームスペースを主宰し、コピーされたネームスペースに対する読出しアクセスを支援するレプリカの能力は、最初のコピー・プロセスをできる限り迅速に完了するように選択的に先送りすることができる。

正規のコピー・プロセスは連続的なプロセスである。メタデータおよびコンテンツ・データをプライマリー・クラスタからレプリカ・クラスタに安全にコピーすることが要点である。特に、コピーされたファイルはゲートウェイ読み出しアクセスに利用可能でなければならない。但し、この読出しアクセスの重要度は二次的であり、コピー・プロセスよりも後回しになってもよい。コピーされたファイルは故障の際にプライマリー・クラスタの修理に利用できることが重要である。修理のための利用もまたその重要度はプライマリー・クラスタからの最初のコピー・プロセスと比較すれば二次的である。プリマリー・クラスタの故障から修理開始まで遅れは許容される。

リカバリには、プライマリー・クラスタをネームスペース・オーソリティとしてできるだけ早く復旧することが重要である。ネームスペース・オーソリティとして、プライマリー・クラスタは読出しおよび書込みゲートウェイ・サポートの立場を取り戻すことができる。ネームスペース・オーソリティへの移行が尚早に行われた場合、ゲートウェイ読出し性能に問題が生じても許容できる。リカバリング・レプリカが全く新しいクラスタである場合、他のクラスタを使用する場合よりもリカバリに失敗するおそれがあり、これが最大の問題である。例えば、クラスタに追加のネームスペース・サポートを確立することは二次的な問題であり、リカバリング・ネームスペースがオーソリテーティブになるまで遅延してもよい。ゲートウェイ読出しアクセスのためのサポートを早期に確立することも書込みサポートと比較すれば二次的な問題である。読出しサポートの遅延が書き込みサポート
を加速すれば、読出しおよび書き込みゲートウェイ・アクセス・サポートが同時に確立される。

１回のバルク・コピー・プロセスがレプリケーションのすべての条件をサポートする。コピー・プロセス・シナリオに合わせて挙動細部を制御するには、バルク・コピーの２つの属性を規定することが好ましい。第１の属性は「インデックスなし」属性であり、最初のコピー・プロセスに採用することができ、大量のデータをコピーする場合のリカバリにも採用することができる。ターゲットが衝突の恐れがない（例えば、空の状態からスタート）状態であり、他のシステム・プロセスがメタデータ・アクセスを必要としない場合にこの属性を規定する。この場合、コピー・プロセスは随意にデータベース・インデックスを省き、すべてのメタデータ記録をロードしてから、インデックスを付加することができる。第２の属性は「メタデータ優先」属性であり、プライマリー・クラスタの状態復帰を急ぐ場合にこの属性を採用する。即ち、本発明の好ましい実施例において実行される「高速リカバリ」オプションがこれである。この属性を規定すれば、すべてのメタデータが（例えば、クラスタ・データベースへ）ロードされるや否や、プライマリー・クラスタへの固定コンテンツ返送（受信させるだけ）が始まったかどうかに関係なく、ネームスペースは直ちにオーソリテーティブになる。即ち、このオプションでは、関連のデータがローカル・クラスタにコピーされる前にメタデータをデータベースにロードすることができる。読み合わせを支援するため、（プライマリー・クラスタにおける）新しいリモート・データ表現がリカバリ中のリモート（レプリカ）クラスタのどの場所に利用できるデータが存在するかを示唆する。

図９は種々のプロセス状態およびバルク・ムーブ・プロセスにおけるソース・クラスタ９００から送り先クラスタ９０２へのデータ・フローを示す。ソース・アーカイブのデータは「未コピー」の状態からスタートし、「メタデータをコピー」、「データをコピー」の段階を経て、最終的にはターゲット・クラスタにおいて「利用可能状態」となる。それぞれの移行段階はそれぞれのスタート状態にある１つまたは２つ以上のオブジェクトに対する単一のトランザクションとして行なわれる。尚、これらの状態におけるデータはオブジェクトではなく、オブジェクトへの変更である。好ましくは、バルク-ムーブ・プロセスはオブジェクトをコピースルのではなく、ソース・アーカイブからターゲット・アーカイブへの変更をコピーする。例えば、「削除」変更はソース・アーカイブにおいて行なわれた削除動作をターゲット・アーカイブにまで伝播するのに必要な情報だけを含む。「オブジェクト形成」変更は必然的に新しいオブジェクトを表現するのに必要なすべてのデータを含む。

図９に示す状態を以下に説明する。

「未コピー」：この状態でのデータ量はターゲット・クラスタにとって既知の時間によって制約される。ターゲット・クラスタはこのデータに関するその他の情報は全く持っていない。もしソース・クラスタが完全に故障すると、この段階でのデータは失われる。失われたデータは限られた時間に亘って記述されるはずであった部分だけである。

「メタデータ・コピー」：メタデータ属性の変化はターゲット・クラスタにコピーされている。これらの属性は変更のタイプ、変更されるオブジェクトの名称、所有者、団体、サイズ、ハッシュ値、その他のメタデータ特性を含む。「削除」のような変更はメタデータだけで表現される。これらのメタデータ・オンリーの変更はこの初期状態に達すれば成功裡にコピーされる。「オブジェクト形成」変更は、オブジェクト-コンテンツが未だ転送されていないからこと段階では不完全である。この時点でソース・クラスタが故障すると、「オブジェクト形成」変更は部分的に失われ；変更記述のためのメタデータは存続し、連携のファイル・コンテンツは失われる。

「データ・コピー」：この段階において、すべての変更を表現するのに必要なデータはすべてターゲット・クラスタにコピーされる。もしソース・クラスタが完全に故障しても、この段階までになされた変更はすべて完全にコピーされる。

「利用可能」：この段階でデータのコピー・プロセスは完了した。ターゲット・クラスタにアクセスするクライアントはこれらの変更を利用することができる。

ここで再び図９の状態図を参照してコピー・プロセスのさらなる詳細を説明する。これらの状態移行を実行する種々のプロセスは図示の通りであり、ソフトウェアで容易に実行することができる。ボックスはプロセスを示す。これらのボックスは一括してグループ化されており、プロセスはクラスタ中の単一ノードにおいて実行される。尚、クラスタは好ましくはメタデータ・オブジェクトの形でメタデータを組織化し、所与のメタデータへのアクセスを可能にするメタデータ管理システムを含む。それぞれのメタデータは独自のネームを有し、メタデータ・オブジェクトは、多くの場合、領域として組織されている。このようなメタデータ管理システムに関する詳細は参考のため本願明細書にも組み込んだ米国特許出願第１１/１９０，４０２号に開示されている。

先ず、ソース・クラスタにおいて実行される変更ログ回収プロセスを介して変更が特定される。ソース・クラスタでは変更ログの保存は行なわれない。次いで、変更ログが変更ログ・メッセージ・レシーバによって受信され、不可視ファイルとして保存される。変更ログ通信が適度にランダムなら、ローカル・ストレージ・マネジャー（ＳＭ）が変更ログを保存する。不可視ファイルには変更ログのタイプ（完全またはリモート、ソース・クラスタ、ドメイン、および時間）をラベリングする。不可視ファイルを保存した後、変更ログ・メッセージ・レシーバは送信側に対して受信を確認する。変更ログが「完全」でなければ、ローカル・バッチ・ビルダーでバッチ・ビルド・プロセスが起動される。

リモート変更ログは下記のサブ-ステップに従ってローカル変更ログに変換される。第１のステップとして、バッチ・ビルダーがリモート変更ログを開き、構文解析する。それぞれの変更がチェックされる。変更記述が完全なら、そのままバッチ・ゲートウェイへ送られる。ソース・クラスタからデータを取込む必要があるような変更記述なら、リモート・ソース転送可能なデータを形成してバッチ・ゲートウェイへ転送する。第２に、形成されたリモート・ソース転送可能なデータが検索コンテンツを変換してインライン化し、有効化する場合がある。このファイルが利用できる外部ファイル・ハッシュが存在しなければ、算出されたハッシュ値をターゲット・クラスタにおいて使用することができる。少なくとも、変換プロセスはソースからの内部ファイル・ハッシュ値をターゲット・ストレージ・マネジャーによる新しい内部ファイル・ハッシュ値と相互照合する。第３に、この場合、バッチ・ゲートウェイが直接ローカル・ノードにおいてコールされる。変更ログ毎に新しいバッチが形成される。次いで、ストリーム・バッチ・メカニズムがローカル変更ログを構成する。ローカル変更ログはリモート変更ログから時間とドメインの情報を受け継ぐ。リモート変更ログが正しくローカル変更ログに変換されたら、リモート変更ログが削除される。何らかの故障が発生しても、リモート変更ログは変化しない。そこで、再試行が行なわれる。

上記のようにリモート変更ログが変換されると、ターゲット・クラスタのリーダー・ノードにおいて作用するシングル・バッチ・マスターが不可視ファイルに記憶されているローカル変更ログを見つける。これらの不可視ファイルに記憶されているローカル変更ログは下記のように仕分けされる：すべてのドメインが安全に保存されるまで（即ち、プライマリー・クラスタが死を宣告されるまで）所与の時間に亘って如何なる変更も処理されない；いずれかのドメインについて次の時間帯に変更ログが処理されるまでに所与の時間に
亘ってすべてのドメインに関してローカル変更ログが処理される。１つの時間帯において変更ログ処理が行われるドメインの順序は任意である。

次いで、バッチ・マスターは個々の不可視ファイルに合わせたサイズのバッチを集合させる。１つの不可視ファイルがバッチにまたがって分割されることはない。バッチ・マスターは個々のファイルに含まれる変更ログを構文解析し、カレント・レジョン・マップに従ってターゲット・クラスタ領域に亘って記述項を分割する。それぞれの領域内にバッチ・ランナーが形成され、変更記述を受信し、コミットを処理する。バッチ・ランナー内で、バッチ・セグメントが不可視ファイル境界に対応する変更を保持する。コミットを実行する時、それぞれのバッチ・ランナーはバッチ・セグメントを走査し、必要な行を挿入するようにデータベースに指令する。これらの指令は局所的に実行され、メッセージとしてすべてのバックアップ領域2送信され、実行される。これらの指令は一度に発信される。それぞれのバッチ・セグメントは指令を2通りの形式のいずれか１つの形式で発信する。そちらの形を使用するかは領域において変更ログの作用が成功したか失敗したかを示唆するマーカー・ファイルに問い合わせることによって決定される。指令の２通りの形式を以下に説明する：

「確実に新しい」：最初に新しいと確証された変更が本当に新しければ（データベース中に存在しないなら）、指令は最適の形を取ることができる。
「必要なら変更」：最初に新しいと確証された変更がオーソリテーティブ領域でもバックアップ領域でも新しくない可能性があれば、「インサート-イフ-アブセントｓｑｌ」の指令が必要である。

バッチが成功裡にコミットすると、使用されている不可視ファイルがすべて削除される。バッチ実行の一部に失敗があれば、使用されている不可視ファイルすべてがそのまま残される。以後、再試行して無期限にこれらのファイルを再訪することになる。コミットはシステム全体に亘ってアトミックではないから、バッチ・マスターによる変更ログのリプレイは許容しなければならない。上記マーカー・ファイルによって、それぞれの領域エレメント（バックアップまたはオーソリテーティブ）に対するトランザクションは１回だけで済む。

上記バルク・コピー・アプローチはコピー・オペレーションを２段階に分離する：即ち、先ずはバルク・メタデータ、次いでデータである。コピー・プロセスおよびリカバリ・プロセスにはこのバルク-ムーブを利用することが好ましい。メタデータ優先アプローチには重大な利点がある。即ち、非同期的コピー・プロセスは、ソース・クラスタが故障した場合、ある程度のデータ損失を伴う。ソース側で発生したが未だターゲット側には伝えられていない変更は失われる。メタデータ優先アプローチでは、データ損失が軽減され、容易に管理される。メタデータを先ず送信するから、メタデータ変更の損失は比較的小さい。メタデータの伝送は（はるかに大量の、ネットワークにかける負担も遥かに大きい）データ伝送によって妨げられない。従って、ソース・クラスタが完全にダウンした場合、ターゲット・クラスタは詳細な損失を報告することができる。例えば、ターゲット・クラスタは下記のようなデータを示す報告を作成することができる：ソース・クラスタからの変更がすべて失われた故障（Ａ）までの時間；およびデータ変更は失われたがメタデータ変更は失われなかった故障（Ｂ）までの時間。例えば、この時間中に削除変更は失われない。「書込みオブジェクト」変更は一部が失われる。オブジェクトのネームおよび属性は失われないが、オブジェクトのコンテンツは失われる。報告はソース・クラスタにおいてかきこまれたがそのデータはコピーされなかったオブジェクト（ネーム、所有者、サイズ、などと共に）の完全リストをも含む。これらの変更はすべて時間（Ｂ）内に失われる。尚、ＡはＢよりも遥かに小さく、Ｂはオブジェクト別コピー・ストラテジーの場合の損失ほど大きくはない（恐らくは、より小さい）。失われたファイルはネームおよびサイズが
判っており、ファイルは故障直前に形成されたものであるから、この詳細な報告を利用することによって企業内の異なるシステムに生き残っているかもしれないこれらのファイルの別のコピーを識別し、見つけ、手動でリカバーできる可能性がある。

メタデータ優先ストラテジーにはほかにも利点がある。帯域幅を制約される構成では妥協を必要とすることが多い。最初にコピーされるから、最新のメタエータは最新のファイル・コンテンツよりも優先される。このストラテジーをうまく実行すれば、上記時間（Ａ）を数秒に短縮することができる。足止めされるデータが蒙る犠牲はメタデータのサイズに正比例する。(データ変更とは異なり）メタデータの変更はその伝送のために必要な帯域幅は遥かに小さいから、せいぜい１メガビット程度の犠牲に止まる。

本発明の幾つかの実施例における特定のオペレーション順序を説明したが、この順序は飽くまでも例であり、実施例によっては、オペレーションをことなる順序で実行するか、オペレーションを組み合わせるか、オーバーラップさせるなど、種々の実施形態が可能である。特定の構成要件、構造、または特性を含む実施例について説明したが、必ずしもこれら特定の構成要件、構造および特性を含まなくてもよい。

方法またはプロセスに関して本発明を説明したが、本発明はオペレーションを実行するための装置にも係わる。この装置は必要な目的のために特別に構成されてもよいが、コンピュータに内蔵されるプログラムによって選択的に作用させるか、または再構成できる汎用コンピュータとして実施することもできる。このようなコンピュータ・プログラムを、それぞれがコンピュータ・システム・バスに接続されるコンピュータ可読記憶媒体、例えば、オプチカル・ディスク、ＣＤ−ＲＯＭ，磁気光学ディスク、読出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、のようなディスク、磁気または光学カードのほか、電子指令の記憶に適した媒体に記憶させればよい。

システムの所与のコンポーネントを別々に説明したが、当業者には明白なように、機能の幾つかを所与の構成、プログラム・シーケンス、コード部分、などにおいて組み合わせたり、共用したりすることも可能である。

ここに使用する語「ロケーション」は必ずしも「地理的な」ロケーションに限定されない。クラスタは、多くの場合、地理的に互いに離れているが、これは必須条件ではない。プライマリー・クラスタを都市のデータ・センターに配置し、レプリカ・クラスタを同じ都市の別のデータ・センターに配置することができる。また、２つのクラスタを１つのデータ・センター内の異なる場所に配置することもできる。

「固定コンテンツ」のアーカイブに関して本発明を説明したが、本発明はこれに限定されるものではない。ここに記述した技術はコンテンツに変更を加えることを可能にするストレージ・システムにも適用することができる。

以上に説明した本発明の範囲は後記する請求項によって定義される。

Claims (11)

1. それぞれのロケーションにおいて複数の独立ノードがネットワーク接続されてクラスタを構成し、クラスタを構成するそれぞれのノードが固定コンテンツ・データおよびこれと連携するメタデータのオブジェクト-ベースのストレージを提供するアプリケーションのインスタンスを実行するように一連の分散ロケーションにまたがって有効なストレージ方法であって、
   第１クラスタと第２クラスタとの間に連携関係を構成し；
   第１クラスタから第２クラスタに第１クラスタの固定コンテンツおよびメタデータをコピーし；
   第１クラスタに関連する故障が発生すると、第１クラスタのクライアントを第２クラスタへリダイレクトし；
   第１クラスタが修理または取替えられ、第２クラスタからメタデータを受信すると、第２クラスタから固定コンテンツが転送されたかどうかに関係なく、修理または取替えられた第１クラスタが第１クラスタのクライアントにサービスする権限を取り戻すステップから成ることを特徴とする前記ストレージ方法。
2. コピー・プロセスのステップにおいて、固定コンテンツ・データに先立って第１クラスタのメタデータが第１クラスタから第２クラスタへ転送させる請求項１に記載の保管方法。
3. 第１クラスタが修理または取替えられると、固定コンテンツ・データよりも先に第１クラスタのメタデータが第２クラスタから修理または取替えられた第１クラスタへ転送される請求項１に記載の保管方法。
4. メタデータがあい２クラスタから修理または取替えられた第１クラスタへバルク転送プロセスによって転送される請求項３に記載の保管方法。
5. 修理または取替えられた第１クラスタに固定コンテンツ・データが復旧したら、修理または取替えられた第１クラスタにおけるノードから固定コンテンツ・データを得るため、クライアントを第１クラスタへダイレクトするステップをも含む請求項１に記載の保管方法。
6. 第１クラスタがメタデータおよびコンテンツ・データを第２クラスタにコピーする分散型ストレージ・システムにおいて、
   第１クラスタに関連する故障が発生すると、第１クラスタのクライアントを第２クラスタへリダイレクトし；
   修理または取替えられた第１クラスタに対してコンテンツ・データの転送に先立ってメタデータをバルク転送し、メタデータのバルク転送が完了すると同時に、修理または取替えられた第１クラスタが第１クラスタのクライアントにサービスする権限を取り戻すステップから成る方法。
7. メタデータのバルク転送に続いて、修理または取替えられた第１クラスタにコンテンツ・データを返還するステップをも含む請求項６に記載の保管方法。
8. 修理または取替えられた第１クラスタにコンテンツ・データが返還されるまで、クライアントのリクエストに応答して、第１クラスタにおいて読出しが行なわれ、第２クラスタにおいて関連のコンテンツ検索が行われる請求項７に記載の保管方法。
9. メタデータおよびコンテンツ・データを第１クラスタがオーソリテーティブであるネー
   ムスペースと連携させる請求項６に記載の保管方法。
10. 第１および第２クラスタが複数の独立ノードがネットワーク接続されており、それぞれのノードがそれぞれのノードが固定コンテンツ・データおよびこれと連携するメタデータのオブジェクト-ベースのストレージを提供するアプリケーションのインスタンスを実行する請求項６に記載の保管方法。
11. コンテンツ・データが固定コンテンツ・データである請求項１０に記載の保管方法。

Images