(57)【要約】      （修正有）【課題】効率的な分割リソースサーバを提供するシステム及び方法を開示する。【解決手段】分割リソースサーバに複数のサーバが含まれ、前記複数のサーバがそれぞれ記憶サービスをサポートしている。本システム及び方法は、分割された複数のリソースのアーカイビングを行う。この目的で、本システム及び方法に、１つのサーバ上で動作するスナップショットプロセスであって、他のサーバ上で動作する他のスナップショットプロセスと協働して、前記分割された複数のリソースの状態を表す状態情報を生成することの可能なスナップショットプロセスが含まれる。【選択図】図１
2008108258.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２つのサーバと；
前記複数のサーバにわたって分割された複数のリソースと；
前記複数のサーバ上で動作するスナップショットプロセスであって、前記複数のサーバのうちで前記複数の分割リソースの少なくとも１部分集合のデータを保持している１つのサーバ上で動作するスナップショットプロセスが、前記複数の分割リソースの前記部分集合のデータを保持している少なくとも１つの別のサーバ上で動作する少なくとも１つの別のスナップショットプロセスと協働して、前記複数のサーバ上の前記複数の分割リソースの状態を表す状態情報を生成することが可能である、スナップショットプロセスと；
を備えた、分割記憶サービスを提供するためのシステム。
【請求項２】
前記複数のサーバのうちの１つのサーバ上で動作するスナップショットプロセスが、前記サーバ上に存在する前記複数の分割リソースの前記部分集合のデータを保持している全ての他のサーバ上で動作する複数のスナップショットプロセスと協働する、請求項１に記載のシステム。
【請求項３】
複数のサーバ間で複数のスナップショットプロセスを協働させることに、前記少なくとも１つの別のスナップショットプロセスを協働させることを求める命令にタイムスタンプを施すタイムスタンププロセスが含まれる、請求項２に記載のシステム。
【請求項４】
前記スナップショットプロセスに、各サーバによって受け取られた要求を処理する要求制御プロセスが含まれる、請求項１に記載のシステム。
【請求項５】
前記要求制御プロセスに、各サーバによる要求の処理を中断させる中断プロセスが含まれる、請求項４に記載のプロセス。
【請求項６】
前記要求制御プロセスに、各サーバによって受け取られた要求にタイムスタンプを施すタイムスタンププロセスが含まれる、請求項４に記載のプロセス。
【請求項７】
前記スナップショットプロセスに、中断された要求を分析して、選択された一時点よりも後に受け取られた要求を特定することが含まれる、請求項１に記載のプロセス。
【請求項８】
前記状態情報を用いて、分割リソースのコピーを作成するアーカイブプロセスが更に含まれる、請求項１に記載のシステム。
【請求項９】
前記状態情報を用いて、前記少なくとも２つのサーバにわたって分割された複数のリソースのコピーを同時に作成するアーカイブプロセスが更に含まれる、請求項１に記載のシステム。
【請求項１０】
少なくとも２つのサーバと、前記複数のサーバにわたって分割された複数のリソースとを設けるステップと；
前記複数のサーバ上でスナップショットプロセスを動作させるステップであって、前記複数のサーバのうちで前記複数の分割リソースの少なくとも１部分集合のデータを保持している１つのサーバ上で動作するスナップショットプロセスが、前記複数の分割リソースの前記部分集合のデータを保持している少なくとも１つの別のサーバの上で動作する少なくとも１つの別のスナップショットプロセスと協働して、前記複数のサーバ上の前記複数の分割リソースの状態を表す状態情報を生成することが可能である、ステップと；
を含む、分割記憶サービス提供方法。
【請求項１１】
複数のスナップショットプロセスを協働させることに、前記複数のサーバのうちの１サーバ上で動作するスナップショットプロセスを、前記１サーバ上に存在する複数の分割リソースの前記部分集合のデータを保持している全ての他のサーバ上で動作する複数のスナップショットプロセスと協働させることが含まれる、請求項１０に記載の方法。
【請求項１２】
複数のサーバ間でスナップショットプロセスを協働させることに、前記少なくとも１つの別のスナップショットプロセスを協働させることを求める命令にタイムスタンプを施すことが含まれる、請求項１１に記載の方法。
【請求項１３】
スナップショットプロセスを動作させることに、各サーバによって受け取られた要求を処理する要求制御プロセスを動作させることが含まれる、請求項１０に記載の方法。
【請求項１４】
前記要求制御プロセスに、各サーバによる要求の処理を中断させる中断プロセスが含まれる、請求項１３に記載の方法。
【請求項１５】
前記要求制御プロセスに、各サーバによって受け取られた要求にタイムスタンプを施すことが含まれる、請求項１３に記載の方法。
【請求項１６】
中断された要求を分析して、選択された一時点よりも後に受け取られた要求を特定することが含まれる、請求項１３に記載の方法。
【請求項１７】
少なくとも２つのサーバにわたって分割された複数のリソースのスナップショットを作成するための方法であって：
前記複数のサーバのうちの１つのサーバ上で動作する第１のスナップショットプロセスに管理命令を出すステップであって、前記第１のスナップショットプロセスが、前記複数のサーバのうちで前記分割された複数のリソースの少なくとも１部分集合を保持している別の１サーバ上で動作する別のスナップショットプロセスに、前記分割された複数のリソースの少なくとも前記部分集合の状態を表す状態情報を生成させるステップと；
前記第１のスナップショットプロセスに待機中の要求を保留させ、前記別のスナップショットプロセスに待機中のクライアント要求を保留させるステップと；
前記別のスナップショットプロセスに、要求が保留されていることを知らせ、前記第１のスナップショットプロセスに、そのサーバ上に保持されている分割リソースの状態を表す状態情報を生成させ、また前記別のサーバに対して、そのサーバ上に保持されている分割リソースの状態を表す情報を生成することを求めるスナップショット命令を生成させるステップと；
を含む方法。
【請求項１８】
前記管理命令に、前記スナップショットの作成対象である前記リソースをサポートしている第２のサーバに対する準備命令が含まれる、請求項１７に記載の方法。
【請求項１９】
前記状態情報を処理して、前記リソースのアーカイブコピーを作成することが更に含まれる、請求項１７に記載の方法。
【請求項２０】
前記第１及び第２のスナップショットプロセスに、前記状態情報の生成後に保留中の要求を解放させることが更に含まれる、請求項１７に記載の方法。
【請求項２１】
少なくとも２つのサーバを有するデータネットワークと；
前記複数のサーバにわたって分割された複数のリソースと；
前記少なくとも２つの各サーバ上で動作するスナップショットプロセスであって、前記複数のサーバのうちで前記複数の分割リソースの少なくとも１部分集合のデータを保持している１つのサーバ上で動作するスナップショットプロセスが、前記複数の分割リソースの前記部分集合のデータを保持している少なくとも１つの別のサーバ上で動作する少なくとも１つの別のスナップショットプロセスと協働して、前記複数のサーバ上の前記複数の分割リソースの状態を表す状態情報を生成することが可能である、スナップショットプロセスと；
を備えた、記憶領域ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の参照
本出願は、その内容全体が本願中に援用された２００３年１月２１日出願の仮出願第６０／４４１，８１０号の利益を主張する、現在は米国特許第７，１２７，５７７号である２００４年１月２０日出願の米国特許出願第１０／７６１，８９３号の部分継続出願である。
【０００２】
発明の分野
本発明は、データ記憶、詳細には複数のサーバにわたる複数のデータブロックのバックアップシステム及び方法に関する。
【背景技術】
【０００３】
大容量記憶システムの動作中には、前記システム上でデータがどのように記憶されているかに関する情報を周期的に収集し、記憶されたデータのバックアップコピーを逐次作成することが望ましい。そのようにデータを収集することは、修復不可能な障害が発生した場合の復旧を含めた多くの理由で有益であろう。
【０００４】
大容量記憶システムのバックアップは、通常、前記大容量記憶システム上に記憶されたデータを読み取り、これを例えばディスク記憶システム又は磁気テープなどのバックアップ記憶システムに書き込んで、前記記憶されたデータのアーカイブコピーを作成することによって行われる。
【０００５】
しかし、そのようなアーカイブコピーの作成が負担となることがある。多くの先行技術のバックアップ方法では、前記バックアップコピーの完全性と整合性とを保つために、前記システムの現在進行中の（オンライン）作業を終了させる必要がある。これは、通常のバックアップ技術では、前記大容量記憶システムから複数のブロックを順次バックアップシステムにコピーするか、又は前記大容量記憶システム上のファイルシステムを、最初のディレクトリの最初のファイルの最初のブロックから、最後のディレクトリの最後のファイルの最後のブロックまで順番にウォークスルーするためである。いずれの場合にも、バックアッププロセスは、データがバックアップシステムに書き込まれている間に行われた更新を認識しないことになる。
【０００６】
このため、バックアップ作業を実行しながらオンライン作業を継続できるようにすると、バックアップ作業中にデータが変更された場合に、矛盾が生じてしまう。前記記憶システムが記憶作業を継続しないようにすれば、システム動作中に矛盾が生じるリスクが解消されるであろう。しかし、バックアップ作業には時間がかかるので、その間システム動作を中断させることは望ましくない。
【０００７】
この問題を解決するための方法の一つに、１枚のディスクのデータのミラーコピー又は同一のコピーを作成することがある。バックアップ作業が必要な場合には、前記ミラーディスクを記憶装置用の静的イメージとして使用してもよい。（例えばテープによるバックアップが終了した時など）前記静的イメージが不要となった時には、ミラリングが休止していた間の変更をすべてミラーディスクにコピーすることによって２枚のディスクを再同期させた後に、ミラリングを再開する。
【０００８】
ミラリングは、効果的ではあるが、システム上に記憶されたデータを正確に読み取る必要がある。しかし、今日では、集中型記憶制御システムを用いなくてもよい新たな分散型記憶システムが開発されている。これらの分散型システムは、より柔軟でスケーラブルな分散型サーバ構造が実現できるという利点を有し、画期的であるが、従来の記憶システムにはない課題も有する。そのような課題の一つに、データボリューム又は記憶ボリュームとも称される、複数の個別に機能するサーバに分散されたリソースの信頼できるアーカイブコピーを作成する能力がある。
【０００９】
従って、当該技術分野において、システム内の複数の異なるサーバにわたって保持されているリソースの信頼できるスナップショットを作成可能な分散型記憶システムが必要とされている。
【００１０】
発明の概要
ここに記載のシステム及び方法には、グループ内の個々のサーバに分割されたサービス又はリソースをサポートする、複数のサーバからなるグループを有するサーバシステムが含まれる。一用途においては、本システム及び方法は、複数のクライアントに記憶サービスを提供するための分割記憶サービスを提供する。この実施例においては、１つ又は複数のリソースが複数のサーバにわたって分割され、各サーバが前記複数のリソースの一部に対応していてもよい。このように分割されたサービスにおいては、前記複数のリソースが複数のサーバ上に広がっており、各サーバが前記ボリューム内のデータの一部を保有する。
【００１１】
フォールトトレランス、データのバックアップ及びその他の利益を得るために、ここに記載の分割された記憶サービスは、記憶アドミニストレータに、前記複数のリソースの状態のコピーを作成するスナップショットプロセス及びシステムを提供する。典型的には、前記スナップショットプロセスにより、前記記憶システムの所定の時点での状態のアーカイブとして機能する第２の記憶ボリュームが作成される。記憶アドミニストレータが、このアーカイブを、元のリソースが後に失われた場合の復旧ツールとして、オフラインバックアップ用のバックアップツールとして、又はその他の適切な理由で用いてもよい。
【００１２】
本発明の更なる特徴及び利点は、以下の好適な実施例の説明及び請求項から明らかとなろう。
【００１３】
発明の詳細な説明
ここに記載のシステム及び方法には、データネットワーク上の複数のサーバにわたって分散された複数のリソースを編成及び管理するためのシステムが含まれる。より詳細には、ここに記載のシステム及び方法には、分割された記憶サービスをアーカイビング処理するためのシステム及び方法が含まれる。しかし、本発明を、分散型ファイルシステム及びデータベースシステムを含むがこれに限定されない、記憶以外の用途及びサービスに用いてもよいことは、当業者に理解されるであろう。更に、ここに記載のシステム及び方法は、本発明によって実現可能なシステム及び方法の種類を例示したものに過ぎず、これらの例示的な実施例を、必要に応じて適切に変更、補足及び修正してもよいことも、当業者に理解されるであろう。
【００１４】
最初に図１を参照すると、本発明のシステムの一実施例が図示されている。図１に示すように、１つ又は複数のクライアント１２が、例えばインターネット、イントラネット、ＷＡＮ又はＬＡＮなどのネットワーク１４を介して、或いは直接接続によって、サーバグループ１６の一部であるサーバ１６１、１６２及び１６３に接続されている。
【００１５】
図示された複数のクライアント１２は、例えばＰＣワークステーション、ハンドヘルド型計算装置、ワイヤレス通信装置又はその他の、サーバグループ１６へのアクセス及び相互作用によってサーバグループ１６との情報交換が可能なネットワーククライアントプログラムが搭載された類似の装置などの、いかなる好適なコンピュータシステムであってもよい。又は、クライアント１２及びサーバグループ１６が、遠隔のサーバグループ１６にあるサービスにアクセスするために、保護されていない通信システム経路を利用してもよい。そのような通信経路にセキュリティを施すために、クライアント１２及びサーバグループ１６が、例えばネットワーク上でデータを安全に伝送する伝送路を構築するために開発された従来のセキュリティシステムのいずれかなどのセキュリティシステムを用いてもよい。そのようなシステムの１つに、クライアントとサーバとの間に信頼できる経路を構築する、Ｎｅｔｓｃａｐｅ（登録商標）セキュアソケットレイヤー（ＳＳＬ）セキュリティ機構がある。
【００１６】
図１は、クライアント１２が複数のサーバ１６１、１６２及び１６３と通信可能であることを図示している。システム１０によって使用されるサーバ１６１、１６２及び１６３は、例えばＵｎｉｘ（登録商標）オペレーティングシステムの一バージョン上でランするＳｕｎ  Ｓｐａｒｃ（登録商標）システムなどの、市販されている従来のサーバハードウェアプラットフォームであってもよい。任意の好適なデータ処理プラットフォームを用いることが可能である。更に、サーバ１６１、１６２又は１６３のうちの１つ又は複数が、テープライブラリなどの記憶装置又はその他の、ネットワーク１４を介して他のサーバ及びクライアントと共にネットワーク化された装置を有してもよいことが理解されるであろう。
【００１７】
各サーバ１６１、１６２及び１６３に、ここに記載の動作及びトランザクションを実行するための複数のソフトウェアコンポーネントが含まれてもよく、また、サーバ１６１、１６２及び１６３のソフトウェアアーキテクチャが、用途に応じて多様であってもよい。幾つかの実施例においては、サーバ１６１、１６２及び１６３が、前記サーバのオペレーティングシステム内、デバイスドライバ内、アプリケーションレベルのプログラム内或いは、テープライブラリ、ＲＡＩＤ記憶システム又はその他の何らかの装置などの周辺装置上で動作するソフトウェアプロセス内に以下に記載のプロセスの幾つかを構築するソフトウェアアーキテクチャを用いてもよい。いずれの場合にも、ここに記載のシステム及び方法が、数多くの異なる実施態様及び実施例を通じて実現可能であり、どのような実施態様及び実施例を用いるかは、目的の用途によって異なり、またこれらの実施態様及び実施例が全て本発明の範囲に含まれることが当業者に理解されるであろう。
【００１８】
本発明の実施に際しては、複数のクライアント１２が、サーバグループ１６内に分割された複数のリソースを有することが必要となる。従って、複数のクライアント１２のそれぞれが、サーバグループ１６に要求を送る。典型的には、あるクライアント１２が、グループ１６の複数のサーバのうちの１つである、例えばサーバ１６１などと連絡をとり、例えばデータブロック、ページ、ファイル、データベーステーブル、アプリケーション又はその他のリソースなどのリソースにアクセスする。連絡を受けるサーバ１６１自体は、要求されたリソースを保持又は制御する必要はない。しかし、好適な一実施例においては、サーバグループ１６は、どのサーバが最初に要求を受け取ったかにかかわらず、分割された複数のリソースの全てをクライアント１２が利用可能であるように構成されている。説明のために、２つのサーバ１６１及び１６２にわたって分割された１つのリソース１８（「リソース２」）及び２つのサーバ１６２及び１６３にわたって分割された別のリソース１７（「リソース１」）の２つのリソースを図に示す。システム１０をブロックデータ記憶システムとして例示したこの用途においては、各リソース１８及び１７が、分割されたブロックリソースを表していてもよい。
【００１９】
従って、図示されたサーバグループ１６は、複数のサーバ１６１、１６２及び１６３からなる記憶領域ネットワーク（ＳＡＮ）として機能することの可能なブロックデータ記憶サービスを提供する。サーバ１６１、１６２及び１６３のそれぞれが、分割されたブロックリソース１８及び１７の１つ又は複数の部分をサポートしてもよい。図示されたシステム１０では、２つのリソース及び３つのサーバが存在するが、サーバの数には特に制限はない。同様に、リソースの数にも特に制限はない。更に、各リソース又は複数のリソースが一つのサーバに完全に包含されていてもよいし、或いは、前記サーバグループ内の全てのサーバであっても前記サーバグループ内の部分集合であってもよい複数のサーバにわたって分割されていてもよい。実際には、当然のことながら、例えばサーバ１６１、１６２及び１６３において使用可能なメモリの量又はサーバ１６１、１６２及び１６３の計算処理上の制約などの、実施要件による制約が存在しうる。一実施例においては、グループ化すること自体、即ちどのサーバによってグループを構成するかの決定が、アドミニストレータによってなされてもよい。多くの場合、１つのグループに最初に含まれるサーバは、数個又は１つのみである。システムアドミニストレータが、必要とされる性能レベルに応じて、グループにサーバを追加する。サーバの数が増えると、（メモリ、ディスク記憶装置などの）リソース記憶領域が広がり、クライアントの要求に応えるＣＰＵ処理能力が高まり、クライアントとの間で要求及び応答をやり取りするネットワーク容量（ネットワークインターフェース）が増加する。ここに記載のシステムを、クライアントのより高い要求に対処するために、更なるサーバをグループ１６に追加することによって容易に拡張可能であることが、当業者に理解されよう。
【００２０】
ここで図２を参照すると、サーバ１６１（図１）に接続しているクライアント１２からは、サーバグループ１６は、複数のＩＰアドレスを有する単一のサーバであるかのように見える。クライアント１２は、サーバ１６が多数のサーバ１６１、１６２、１６３などの多数のサーバによって構成されている可能性があることや、複数のブロックリソース１７、１８が前記サーバ１６１、１６２、１６３にまたがって分割されていることには気付かない。この結果、サーバの数及び、これらのサーバにまたがってリソースが分割されている仕方を、クライアント１２から見たネットワーク環境に影響を及ぼすことなく変更することが可能である。
【００２１】
図３は、図２のリソース１８がサーバ１６１と１６２とにまたがって分割されていることを示している。分割されたサーバグループ１６内では、いかなるリソースがグループ１６内のいかなる数のサーバにわたって広がっていてもよい。図１及び図２を参照しながら既に説明したように、１つのリソース又はボリューム１７（「リソース１」）がサーバ１６２及び１６３にわたって広がっている一方で、別のリソース又はボリューム１８（「リソース２」）がサーバ１６１及び１６２にわたって広がっていてもよい。各ボリュームが、「ページ」とも呼ばれる、複数のブロックからなる一定のサイズのグループ単位で構成され、例えばあるページに８１９２個のブロックが含まれていると有利であろう。別の好適なページサイズを用いてもよい。一実施例においては、グループ１６内の各サーバ１６１、１６２、１６３に、各ボリュームに関するルーティングテーブル１６５、１６６、１６７がそれぞれ含まれ、ルーティングテーブル１６５が、特定のボリュームの特定のページが記憶されたサーバを特定する。例えば、サーバ１６１がクライアント１２からボリューム１８のブロック９３８４７を求める要求を受け取ると、サーバ１６１はページ番号（ページサイズが８１９２のこの例では１１ページ）を計算し、対応するルーティングテーブル１６５を検索して、ボリューム１８の１１ページが記憶されているサーバの場所又は番号を探す。要求された１１ページがサーバ１６１ではなくサーバ１６２に記憶されている場合には、要求がサーバ１６２へと転送され、サーバ１６２はデータを読み取って、このデータをサーバ１６１へと送る。次に、サーバ１６１はこの要求されたデータをクライアント１２へと送る。クライアント１２から要求を受け取ったのと同じサーバ１６１を介して、応答がクライアント１２へと送られてもよい。
【００２２】
従って、クライアント１２にとっては、どのサーバ１６１、１６２、１６３がクライアント１２の目的のリソースを持っているかは重要ではない。上述のように、サーバ１６１、１６２及び１６３は、各ルーティングテーブル１６５、１６６、１６７を用いてクライアントの要求に対応し、クライアント１２は、どのサーバが要求したリソースと関連しているのかを予め知っておく必要がない。このため、リソースの複数の部分が複数の異なるサーバに存在することが可能である。また、複数のリソース又はこれらの複数の部分を、クライアント１２がサーバグループ１６に接続している間に移動させることも可能である。リソースを移動させると、ルーティングテーブル１６５、１６６、１６７が必要に応じて更新され、次のクライアント要求が、現在その要求の処理に当たっているサーバへと送られる。少なくともリソース１７又は１８内では、そのリソースに関するルーティングテーブル１６５、１６６、１６７が同一であってもよい。
【００２３】
図４は、分割されたサーバ環境内でクライアント要求を処理するための要求処理プロセス４０の一例を図示したものである。要求処理プロセス４０は、ステップ４１で開始し、ステップ４２で、例えばあるファイル又はあるファイルの複数のブロックなどのリソースを求める要求を受け取る。要求処理プロセス４０は、ステップ４３でルーティングテーブルを調べ、要求されたリソースがどのサーバに位置しているかを判定する。ステップ４４で前記要求されたリソースが最初のサーバに存在している場合には、ステップ４８で前記最初のサーバが前記要求されたリソースをクライアント１２に送り、ステップ４９でプロセス４０が終了する。逆に、ステップ４４で前記要求されたリソースが最初のサーバに存在していない場合には、ステップ４５で、前記サーバが、前記最初のサーバのルーティングテーブルからのデータを用いて、どのサーバがクライアントから要求されたリソースを実際に保持しているのかを調べる。次に、ステップ４６で前記要求が前記要求されたリソースを保持しているサーバへと送られ、このサーバがステップ４８で前記要求されたリソースを前記最初のサーバへと送る。次に、プロセス４０が前述のようにステップ４８へと進み、前記最初のサーバに前記要求されたリソースをクライアント１２へと送らせ、ステップ４９で終了する。
【００２４】
従って、ここに記載のシステム及び方法が、１つ又は複数のリソースをあるサーバグループ内の複数のサーバにわたって分割可能であり、また複数のクライアントからの要求に対応可能であることが、当業者に理解されよう。更に、上述の説明は、ここに記載のシステム及び方法が、前記リソースを再分散又は再分割させて、前記リソースの複数の部分が前記サーバグループにわたって分散する又は広がる仕方を変更することが可能であることも示している。複数のサーバにまたがって広がる前記リソースは、複数のディレクトリ、あるディレクトリ内の個々のファイル、あるファイル内の複数のブロック又はこれらの組み合わせであってもよい。その他の分割サービスが実現されてもよい。例えば、データベースを類似の方法で分割したり、分散型ファイルシステムを提供したり、インターネットを介して配信されるアプリケーションをサポートする分散又は分割されたサーバを提供することも可能であろう。一般には、そのような方法を、クライアント要求がリソース全体の一部に対する要求として解釈されるいかなるサービスにおいても採用することが可能である。
【００２５】
ここで図５を参照すると、複数のサーバ１６１、１６２及び１６３にわたって分割された１つ又は複数のリソース１７、１８の分散スナップショットを作成可能な、システム１０の一実施例が図示されている。詳細には、図５に図示されるシステム１０では、クライアント１２がサーバグループ１６と通信を行う。サーバグループ１６には、図１及び図３に例示された３つのサーバ１６１、１６２及び１６３が含まれる。図５の実施例では、サーバ１６１、１６２及び１６３は、それぞれがクライアントからの同じ要求に対して実質的に同一のリソースを提供することが可能であるという点で、互いに同等なサーバとして示されている。このように、クライアント１２の視点からは、サーバグループ１６は、クライアント１２と通信を行うための複数のネットワーク又はＩＰアドレスを供給する単一のサーバシステムのように見える。各サーバには、ルーティングテーブル２０Ａ、２０Ｂ及び２０Ｃとして図示された対応するルーティングテーブル及び、対応するスナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃがそれぞれ含まれる。更に、また単に例示的な目的で、図５はリソース１７及び１８を、元のリソース１７及び１８のイメージを表す第２の記憶ボリュームを作成するためにコピーされてもよい複数のデータページ２８として表している。
【００２６】
一実施例においては、あるサーバに組み込まれた単一のルーティングテーブルが、このサーバ上に記憶された全ての分割されたリソースに対応していてもよい。図３及び図５にこの構成が図示されている。或いは、各サーバが、そのサーバ上の分割されたリソースごとに個別のルーティングテーブルを有してもよい。同様のことがサーバ上で実行されるスナップショットプロセスにも当てはまる。即ち、あるサーバ上の全ての分割されたリソースについて共通のスナップショットプロセスを実施してもよいし、又はあるサーバ上の分割された複数のリソースのそれぞれについて個別のスナップショットプロセスを実施してもよい。
【００２７】
図５に矢印で示すように、ルーティングテーブル２０Ａ、２０Ｂ及び２０Ｃはそれぞれ、情報を共有する目的で相互に通信を行うことが可能である。上述のように、これらのルーティングテーブルは、複数の互いに同等なサーバのうちのいずれがサーバグループ１６によって保持されている特定のリソースに対応しているのかを、そのサーバ上に前記リソースのどの部分も記憶されていない場合においても突き止めることが可能である。図５に示す実施例においては、サーバグループ１６がＳＡＮを形成し、互いに同等なサーバ１６１、１６２及び１６３のそれぞれが、前記ＳＡＮ上でクライアントがそのサーバにアクセスするために使用できる個々のＩＰアドレスを有してもよい。また上述のように、互いに同等なサーバ１６１、１６２及び１６３が、クライアント１２からの同じ要求に対して同じ応答を送ることが可能であってもよい。この目的で、互いに同等なサーバ１６１、１６２及び１６３のそれぞれのルーティングテーブル２０Ａ、２０Ｂ及び２０Ｃが互いに協働して、サーバグループ１６内に記憶された複数の異なるリソース及びこれらのリソースにそれぞれ対応する互いに同等な複数のサーバからなるグローバルなデータベースを構成してもよい。
【００２８】
図６は、サーバグループ１６内の複数のサーバ上に記憶された複数のリソース又はボリューム１７、１８のためのルーティングテーブルを例示したものである。これらのルーティングテーブルには、サーバグループ１６内の分割されたデータブロック記憶サービスをサポートする互いに同等なサーバ１６１、１６２及び１６３ごとの識別情報（サーバＩＤ）が含まれる。これらのルーティングテーブルのそれぞれに、各ボリューム１７、１８について、サーバグループ１６内の互いに同等なサーバ１６１、１６２及び１６３のそれぞれに関連したデータページを特定するテーブルが含まれる。図６に示す実施例においては、前記互いに同等な複数のサーバが、２つの分割されたボリューム１７、１８をサポートする。第１のボリューム１８が、２つの互いの同等なサーバ１６１及び１６２にわたって分散又は分割されている。第２のボリューム１７が、２つの互いに同等なサーバ１６２及び１６３にわたって分割されている。
【００２９】
ここで再び図５を参照すると、互いに同等なサーバ１６１、１６２及び１６３のそれぞれに、スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃのそれぞれが含まれることが示されている。各スナップショットプロセスが、前記サーバシステム上で動作するコンピュータプロセスであり、各サーバによって保持されているリソース部分のスナップショットを作成するようにデザインされていてもよい。従って、図５に図示されたスナップショットプロセス２２Ａが、分割されたリソース１８のうちでサーバ１６１が保持している部分のコピーを作成してもよい。このことは、あるページ２８及びページ２８のコピー２９を示した図５に少なくとも部分的に図示されている。同様に、スナップショットプロセス２２Ｂが、分割されたリソース１７及び１８のうちでサーバ１６２が保持している部分のコピーを作成してもよい。
【００３０】
本発明の実施に際しては、互いに同等なサーバ１６１、１６２及び１６３のそれぞれが、通常は互いに独立して動作可能である。従って、スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃが、特定の時点におけるリソース１７及び１８の正確なスナップショットを作成するように、互いに協働しなければならない。このような協働の必要は、少なくとも部分的には、クライアント１２Ａ乃至１２Ｅからの書き込み要求が、いかなる時点においても、またサーバ１６１、１６２及び１６３のいずれに向けても出されうることから生じる。従って、１つのスナップショットプロセスが開始した後は、全ての書き込み要求がサーバ１６１、１６２及び１６３のそれぞれに受け取られる。スナップショットプロセスから容認不可能な又は予期しない結果が生じることを避けるために、スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃは、互いに協働して、特定の時点における分割されたリソース１７及び１８の状態を表す状態情報を作成する。詳細には、一実施例において、スナップショットを作成する命令が発せられた直後に時間「Ｔ」が存在し、前記時間「Ｔ」よりも前にクライアント１２にその完了が知らされた全ての書き込み動作が前記スナップショットに含まれ、前記時間「Ｔ」よりも後にその完了が知らされた全ての書き込み動作が前記スナップショットから除外されるように、時間パラメータが選択される。
【００３１】
この目的で、各スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃは、アドミニストレータからの要求を受け取って、リソース１７、１８のスナップショットを作成することが可能である。前記スナップショットプロセスには、目的のリソースをサポートしている他のサーバ上で動作しているスナップショットプロセスの作業及び動作との協働を求める命令を前記アドミニストレータに向けて発する協働プロセスが含まれる。図５に示す例においては、アドミニストレータがサーバ１６２上で動作しているスナップショットプロセス２２Ｂに向けてスナップショット命令を発してもよい。前記スナップショット命令が、スナップショットプロセス２２Ｂに、サーバグループ１６２内のリソース１７又はリソース１８或いは任意のリソースの組み合わせのスナップショットを作成するように求めてもよい。スナップショットプロセス２２Ｂがルーティングテーブル２０Ｂにアクセスして、サーバグループ１６内のどのサーバがリソース１７、１８内のデータブロックの少なくとも一部分をサポートしているのかを調べてもよい。次に、スナップショットプロセス２２Ｂが、記憶ボリューム１７、１８の一部分をサポートしている前記複数のサーバのそれぞれに向けて命令を発してもよい。図５の例では、サーバ１６１及び１６２が、リソース１８の一部分をサポートしている。従って、スナップショットプロセス２２Ｂが、スナップショットプロセス２２Ａに対して、スナップショットの作成のための準備を行うことを求める命令を発してもよい。同時に、スナップショットプロセス２２Ｂ自身も、サーバ１６２上に保持されているリソース１８の前記部分のスナップショットを作成する準備を開始してもよい。
【００３２】
図７に示す一実施例においては、１つ又は複数のリソースのスナップショットを作成するための準備を行うことを求める命令をスナップショットプロセス２２Ｂから受け取ると、スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃのそれぞれが、前記スナップショット命令が適用される前記複数のリソースに言及する全ての要求を一時的に中断してもよい。前記スナップショット命令で言及されていない他のリソースがあってもよく、そのようなリソースに関する動作を求める要求は影響を受けない。そのような要求に、書き込み要求、読み出し要求及びその他の、前記用途に適した任意の要求が含まれてもよい。この目的で、各スナップショットプロセスにそのサーバによって実行される要求を処理させること及び、これらの要求の実行を一時的に停止させて、要求された単一の又は複数のリソースの状態を変更させる可能性のある書き込み動作を一時的に停止させることを可能にする要求制御プロセスが、各スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃに含まれてもよい。
【００３３】
各スナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃが要求の処理を一時的に停止させると、サーバがリソース１８などの前記要求されたリソースのスナップショットの作成を開始する準備ができていることを示す応答が、調整スナップショットプロセス２２Ｂへ発せられてもよい。調整スナップショットプロセス２２Ｂが各サーバ２２Ａから準備完了信号を受け取り、自身のスナップショット動作の準備も完了していると判定すると、スナップショットプロセス２２Ｂが適切な１つ又は複数のサーバにスナップショット命令を発してもよい。必要な場合には、前記サーバが、前記スナップショット命令の受信に応答して、前記サーバによって保持されているボリューム１８のデータブロックのコピーを表す状態情報を生成するアーカイブプロセスを作動させてもよい。一実施例においては、スナップショットが作成されてから変更されていないボリューム部分（ページ）が一度だけ記録されるように、「コピーオンライト」プロセスによってミラーイメージが作成される。所望の場合には、このミラーイメージが、テープ又は別のアーカイブ記憶媒体に後の時点で転送されてもよい。このような技術は当業で周知であり、使用する技術が用途により、また前記ミラーイメージの大きさ及びその他の類似の条件に適合するように、様々に異なっていてもよい。
【００３４】
状態情報の作成後に、前記スナップショットプロセスは終了され、前記複数のサーバが、中断中又は待機中の要求を解放して処理できるようにしてもよい。
【００３５】
図７は、サーバ１６１、１６２及び１６３にわたって分割された２つのリソースのスナップショットイメージを作成するための、本発明に基づく一方法を図示したものである。ここにより詳細に説明するように、図７に図示された分散スナップショット７０は、記憶アドミニストレータがリソース１７及び１８の特定の時点における状態を表す情報を作成することを可能にする。前記作成された状態情報に、ファイル構造、記憶されたデータに関するメタデータ、前記分割されたリソースによって保持されているデータのコピー又は前記リソースの複数の部分のコピー或いはその他のこれらのような情報が含まれてもよい。従って、ここに記載のスナップショットプロセスが、前記分割されたリソースの構造に関する情報が作成されて後に使用するために記憶される用途及び、前記分割されたリソースの完全なアーカイブコピーが作成される用途を含めた多くの用途を有することが理解されよう。ここに記載の分散スナップショットプロセスが、本発明の範囲に含まれると理解される他の用途に用いられてもよい。
【００３６】
図７は、分割された１つ又は複数のリソースの状態情報を生成するためのスナップショット要求の実行手順を示す、時間／空間図である。詳細には、図７はリソース１７及び１８の一貫した分散スナップショットを作成する多段階プロセス７０を図示している。この目的で、図５に示す３つのサーバ、１６１、１６２及び１６３を表す３本の垂直な線を図７に示す。矢印７２乃至７８は、１つ又は複数のクライアント１２からの書き込み要求を表し、矢印８２乃至８８は、サーバ１６１、１６２及び１６３のそれぞれからの応答を表す。
【００３７】
図７に示すように、プロセス７０は、アドミニストレータからスナップショット命令が発せられた時に開始する。この場合、前記スナップショット命令は、前記アドミニストレータから発せられ、サーバ１６２に到達する。スナップショット命令９０は、サーバ１６２に向かう矢印９０として図示されている。図７に示すように、サーバ１６２上で実行されているスナップショットプロセスは、スナップショット命令９０に応答して、他のサーバ１６１及び１６３の動作を協働させる命令を発する。これらの命令は、サーバ１６１及び１６３上で実行されているスナップショットプロセスを協働させ、各サーバによってリソース１７及び１８の一部として保持されているデータの状態を表す状態情報を生成させる。
【００３８】
図７に更に示すように、サーバ１６２上で実行されているスナップショットプロセス２２Ｂは、サーバ１６１及び１６３のそれぞれに対して、準備命令９２及び９４を発する。各サーバ１６１及び１６３上で実行されているスナップショットプロセスは、前記準備命令に応答して、前記「準備」命令の到達前にクライアントから受け取った（例えば要求７８などの）待機中の要求及び、前記「準備」命令に続いて受け取った（例えば要求７６などの）要求を保留する。
【００３９】
要求が保留されると、サーバ１６１及び１６３は、前記準備命令を発したサーバ１６２に応答して、各サーバ１６１及び１６３が全ての待機中の要求を中断したことを伝える。次に、協働サーバとして動作しているサーバ１６２が、スナップショット命令を各サーバに対して発する。このことは、図７に矢印９８及び１００により図示されている。
【００４０】
スナップショット命令に応答して、サーバ１６１及び１６３は、サーバ１６２と同様に、要求された複数のリソースのうちの各サーバによって保持されている部分のスナップショットを作成する。前記スナップショット情報が、次に各サーバのデータファイル内に格納されてもよい。或いは、各サーバ１６１、１６２及び１６３上で実行されているスナップショットプロセス２２Ａ、２２Ｂ及び２２Ｃが、前記複数のリソースのアーカイブコピーを作成してもよい。これらのアーカイブコピーが、テープ記憶装置又はその他の種類の大容量記憶装置へと転送されてもよい。
【００４１】
作成されたスナップショットには、領域１０４内で完了された要求は全て含まれるが、領域１１０内で完了された要求は含まれない。
【００４２】
図８は、分割された複数のリソースのスナップショットを作成するためのプロセスの別の一実施例を図示したものである。詳細には、図８は、３つの時間間隔にわたって発生するプロセス１２０を示す時間−空間図である。これらの時間間隔は、図８の時間−空間図内に互いに異なる陰影を付けた複数の領域として示され、時間間隔１２２、１２４及び１２６と名付けられている。時間間隔１２２は、アドミニストレータがスナップショット要求１４０を発する時点よりも前に位置し、時間間隔１２４は、スナップショット要求１４０が発せられた前記時点と、前記スナップショット動作が開始する時点との間に位置し、時間間隔１２６は、前記スナップショットが作成された後に位置している。スナップショット動作要求１４０は矢印１４０で図示され、これとは異なる書き込み要求は、矢印１３０乃至１３８で図示されている。これらの書き込み要求への応答は、矢印１３１、１３３、１３５、１３７及び１３９で図示されている。図７と同様に、図５に示すシステム１０の３つのサーバは、それぞれサーバ１６１、１６２及び１６３と名付けられ、垂直な線で表されている。
【００４３】
図８に図示するプロセス１２０は、タイムスタンプ及び同期システムクロックを用いた一貫した分散スナップショットの作成を説明している。より詳細には、プロセス１２０は、サーバ１６１、１６２及び１６３が複数の書き込み要求を受け取ってもよく、これらの書き込み要求のそれぞれが、いずれのサーバにいずれの時点で到達してもよいことを示している。このことは、図８に、時間間隔１２２の間に発生する書き込み要求１３０、１３２及び１３６によって示されている。図８に更に示すように、書き込み要求１３４が時間間隔１２４の間に到達してもよいし、また書き込み要求１３８が時間間隔１２６の間に到達してもよい。従って、図８に示すプロセス１２０は、スナップショットプロセスの前、間及び後に起こりうる書き込み要求を処理するようにデザインされている。
【００４４】
スナップショットプロセスは、スナップショット要求１４０がサーバ１６１、１６２及び１６３の少なくとも１つによって受け取られた時に開始する。図８は、スナップショット要求１４０がアドミニストレータからサーバ１６２へと送られることを図示している。スナップショット１４０が受け取られると、サーバ１６２上で動作しているスナップショットプロセスが、前記スナップショットが作成される元となったリソースをサポートしている他のサーバ１６１、１６３へと「準備」命令１４２、１４４を発してもよい。この準備命令は、サーバ１６２からサーバ１６１へと向かう矢印１４２及び、サーバ１６２からサーバ１６３へと向かう矢印１４４によって示されている。準備命令を受け取ると、サーバ１６１及び１６３の一方又は双方が、サーバ１６２と同様にスナップショットの準備を行う。例えばリソース１８のみのスナップショットが要求された場合に、準備命令が、分割されたリソース１８のデータを保持しているサーバ１６１のみに送られることが理解されよう。
【００４５】
複数のサーバで依然として待機中となっている要求は、これらをこれ以上待機させ続ける必要がないので、次の段階に移り、完了後直ちに通知されてもよい。代わりに、各サーバ１６１、１６２及び１６３はこれらの要求のそれぞれが処理された時点を調べ、これらの要求のそれぞれにタイムスタンプを施す。図８に示す実施例においては、このタイムスタンプは、待機中であるか、又はサーバ１６２がスナップショット要求１４０を受け取った後に受け取られた書き込み要求１３６、１３４及び１３８の全てに対して施される。協働サーバ１６２が各サーバ１６１及び／又は１６３から「準備完了」応答１５０、１５１を受け取ると、協働サーバ１６２が、スナップショットを作成することを求める命令を発し、この命令を待機中のサーバ１６１及び／又は１６３へと送る。この命令には、現在の時点であるタイムスタンプが含まれる。このことは、図８にサーバ１６１及び１６３に対する命令を表す矢印１６０及び１６２により図示されている。サーバ１６１及び１６３がこの命令を受け取ると、これらのサーバは、命令１６１及び１６２が伝送された時点よりも早いタイムスタンプが施された書き込み要求を前記スナップショットに加える。「スナップショット作成」命令１６０及び１６２のタイムスタンプよりも後のタイムスタンプを施された書き込み要求は、作成されたスナップショットには含まれない。図８に図示された例では、書き込み要求１３６及び１３４は作成されたスナップショットに含まれるが、書き込み要求１３８は作成されたスナップショットに含まれない。スナップショット情報が作成された後に、プロセス１２０が、図７を参照して前述したプロセス７０と同様に進行してもよい。時点Ｔ１及びＴ３は、それぞれ、サーバ１６１（サーバ１）及びサーバ１６３（サーバ３）から見た「時点Ｔ」を表す。
【００４６】
図７及び図８が、スナップショットプロセスに３つのサーバ１６１、１６２及び１６３が参加している場合を図示したものであることは、当業者に理解されよう。リソース１８のみのスナップショットが要求されている場合には、サーバ１６３はスナップショットプロセスには加わらない。同様に、リソース１７がのみの場合のスナップショットプロセスには、サーバ１６１は加わらない。分割リソースが３つよりも多い数のサーバにわたって分散されている場合には、更なるサーバ及びスナップショット命令が含まれなければならないであろう。
【００４７】
図１は、複数のサーバシステムからなるグループを含む複数の機能ブロック要素からなる構成体としてのシステムを図示したものであるが、本発明のシステムが、複数のサーバ上で動作することによって前記複数のサーバを本発明に基づくシステムとして構成することの可能な、複数のコンピュータプログラム又は複数のコンピュータプログラムの複数の部分として実現されてもよいことが、当業者に理解されよう。更に、図１はグループ１６を複数のサーバのローカルな集合として図示しているが、これが一実施例に過ぎず、本発明が互いに物理的に離間した複数のサーバが含まれるサーバ集合又はサーバグループから構成されてもよいことが、当業において通常の技術を有する者に明らかとなろう。
【００４８】
上述のように、幾つかの実施例においては、本発明のシステムが、Ｕｎｉｘ（登録商標）ワークステーションなどの従来のデータ処理システム上で動作するソフトウェア構成要素として実現されてもよい。そのような実施例においては、前記システムが、Ｃ言語コンピュータプログラムとして、或いはＣ＋＋、Ｆｏｒｔｒａｎ、Ｊａｖａ（登録商標）又はＢＡＳＩＣなどの高レベルの言語で書かれたコンピュータプログラムとして実現されてもよい。そのような高レベルのプログラミングのための一般的な方法は公知であり、例えば１９８３年にＨａｙｄｅｎ  Ｐｕｂｌｉｓｈｉｎｇ社から発行された、Ｓｔｅｐｈｅｎ  Ｇ．Ｋｏｃｈａｎ著のＰｒｏｇｒａｍｍｉｎｇ  ｉｎ  Ｃに記載されている。
【非特許文献１】１９８３年にＨａｙｄｅｎ  Ｐｕｂｌｉｓｈｉｎｇ社から発行された、Ｓｔｅｐｈｅｎ  Ｇ．Ｋｏｃｈａｎ著のＰｒｏｇｒａｍｍｉｎｇ  ｉｎ  Ｃ
【００４９】
本発明を、複数の好適な実施例を詳細に図示及び説明しながら開示したが、様々な変更及び改良をこれらに加えてもよいことが当業者に容易に理解されよう。従って、本発明の精神と範囲とは、添付の請求項によってのみ限定されるべきである。
【図面の簡単な説明】
【００５０】
以下の図面は、本発明の例示的な実施例の幾つかを図示したものであり、同様の参照記号は同様な要素を言及するものである。これらの図示された実施例は、本発明の例を挙げたものであり、いかなる点においても限定するものではないと理解されるべきである。
【図１】複数のサーバが１サーバグループに編成されたクライアント−サーバ構造の略図である。
【図２】図１のサーバグループをクライアントから見た略図である。
【図３】図１のクライアントとサーバグループの複数のサーバとの間の情報の流れを詳細に示したものである。
【図４】分割リソース環境にある複数のリソースを取り出すためのプロセスフロー図である。
【図５】本発明のシステムの一実施例を、機能ブロック図としてより詳細に図示したものである。
【図６】図５のシステムへの使用に適したルーティングテーブルの一例を図示したものである。
【図７】本発明のシステムによってサポートされるリソースのスナップショットを作成する１プロセスを図示したものである。
【図８】本発明のシステムによってサポートされるリソースのスナップショットを作成する別の１プロセスを図示したものである。
【図１】
2008108258.tif 000003
【図２】
2008108258.tif 000004
【図３】
2008108258.tif 000005
【図４】
2008108258.tif 000006
【図５】
2008108258.tif 000007
【図６】
2008108258.tif 000008
【図７】
2008108258.tif 000009
【図８】
2008108258.tif 000010
【外国語明細書】
2008108258000001.pdf
2008108258000002.pdf
2008108258000003.pdf
2008108258000004.pdf