(57)【要約】効率的な区分リソースサーバを提供するためのシステム及び方法を提供する。一実施形態では、区分リソースサーバは、複数の個別サーバを含み、これら個別サーバはクライアントには同等に見える。個別サーバそれぞれは、区分リソースサーバに維持されている各リソースへの参照を備えた経路指定テーブルを含むことができる。クライアントからの要求を処理するには、経路指定テーブルが、対象リソースを維持するか或いは管理する個別サーバにこの要求を経路指定して実行する。
2005539289.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおける複数サーバにわたって分散したリソースにアクセスするための方法であって、
前記ネットワークを介して１つのサーバに接続を確立する段階と、
前記リソースを前記サーバから要求する段階と、
前記複数サーバにわたる前記リソースの分散を特定する段階と、
前記サーバへのネットワーク接続を維持したまま、前記複数サーバわたり分散した前記リソースを、前記サーバを介して返す段階とを含む、方法。
【請求項２】
前記分散は、前記複数サーバそれぞれに存在する経路指定テーブルから特定され、且つ前記複数サーバ間で同期が取られている、請求項１に記載の方法。
【請求項３】
前記経路指定テーブルが、前記複数サーバそれぞれに存在する前記リソース又は前記リソースの一部への参照を含む、請求項２に記載の方法。
【請求項４】
各サーバが、前記複数サーバにより維持される各リソースへの直接参照を維持する経路指定テーブルを含む、請求項２に記載の方法。
【請求項５】
クライアント要求の経路指定が要求毎に別々に行われる、請求項１に記載の方法。
【請求項６】
クライアントを前記複数サーバに接続させたまま、リソース又はその部分を移動できる、請求項１に記載の方法。
【請求項７】
前記経路指定テーブルを動的に更新する段階を含む、請求項１に記載の方法。
【請求項８】
後続クライアント要求が、この後続要求を処理する役目を負ったサーバに転送される、請求項１に記載の方法。
【請求項９】
分散リソースにアクセスするためのクライアント／サーバ・アーキテクチャであって、
ネットワークに接続された複数のサーバと、
前記複数サーバにわたり分散したリソースとを含み、各サーバが、前記リソース又は前記リソースの一部を、前記複数サーバ内の対応したサーバに関連付ける経路指定テーブルを含み、
前記リソースへのクライアント要求が、前記複数サーバの１つに経路指定され、当該１つのサーバが、前記リソースへの前記クライアント要求に応答する、クライアント／サーバ・アーキテクチャ。
【請求項１０】
前記リソースが、複数のデータブロックを備えたファイルを含む、請求項９に記載のアーキテクチャ。
【請求項１１】
前記経路指定テーブルが、前記複数データブロックからなるグループへの参照を含む、請求項１０に記載のアーキテクチャ。
【請求項１２】
ネットワークにおける複数サーバにわたって分散したリソースにアクセスを提供するための方法であって、
前記複数サーバにわたる前記リソースの分散を特定する段階と、
前記複数サーバそれぞれに、前記複数サーバにわたり分散した各リソースへの参照を含んだテーブルを提供する段階であって、前記参照が、それぞれリソースを管理するそれぞれのサーバを表す、提供する段階と、
特定のリソースへのアクセスを求める着信要求をリッスンする段階と、
前記要求リソースを管理するサーバを特定するために前記テーブルに照会することによって、前記の検出した着信要求を処理する段階とを含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介したファイル・アクセスに関し、詳細には、複数のサーバ上に存在するファイル及び／又は他のリソースに対するクライアント要求の透過的な経路指定に関する。
【背景技術】
【０００２】
大企業や他の大きな組織は、記録、ファイル、及びそれ以外のリソースを、組織の必要性に応える幾つかのサーバにわたって格納したいと考えることがある。こうした状況では、幾つかのサーバを１つのグループに集約して、クライアントにはこれらサーバが単一の論理単位のように見せることが望ましくなる。理想的には、こうした単一の論理単位であれば、内部に含まれたデータ・オブジェクトの重複は無いはずである。更に、この単一論理単位は、この分散形論理単位に属するサーバに到着する任意のリソース要求に応える上で、可能な限り小さいオーバーヘッドを備えるべきである。多くの場合は、要求されたリソース・オブジェクトが、そのリソース要求を元々受け取ったサーバには存在しないことがあり、元々のリソース要求に応えるには所望リソースの何らかの転送、経路指定、又は入手が必要となる。
【０００３】
特定の情報又は特定のファイルへのアクセスを望むクライアントを、要求した情報又はファイルを持つサーバにリダイレクトする仕組みのマルチサーバ環境が知られている。リダイレクト後に、クライアントは、リダイレクト先のサーバへの新たな接続を確立し、元々接続されていたサーバへの接続を切断する。しかし、このアプローチでは、クライアントと最初のサーバとの間に長期間の接続を維持するという利点が生かされない。
【０００４】
もう一つのアプローチは「記憶装置仮想化」であり、中間デバイスをクライアントとサーバとの間に配置して、中間デバイスが要求の経路指定を実行するというものである。この方法では、何れのサーバも区分されたサービス全体の一部のみを提供しているということを意識していない。中間デバイスを追加すると、システムの複雑性が増加してしまう。
【０００５】
従って、クライアントによるマルチサーバ環境の任意サーバとの連絡を許容し、且つ連絡を取ったサーバのみと接続を維持しつつ、このマルチサーバ環境に分散したファイルなどのリソースへのアクセスを許容する方法及びシステムを提供することが望まれる。
発明の概要
【０００６】
本発明は、サーバグループ内の全てのサーバと費用がかかる照会／応答トランザクションを行わずに、サーバグループに対するリソース要求を、所望のリソース・オブジェクトを持つサーバへ横方向に（原語：laterally）経路指定できるシステム及び方法に関する。所望のリソース・オブジェクトを持つサーバとの接続は長期間にわたるものとして、このサーバが、上述のリソース・オブジェクトを要求クライアントに返すべきである。
【０００７】
本発明の別の目的は、グループメンバ間でグループ帰属関係の情報を共有して、所望のリソース・オブジェクトを保持するよう指定されたサーバを示し、且つこれを任意サーバから実行するために、こうしたグループ帰属関係情報が、要求されたリソース・オブジェクトと共に決定論的に処理されるようにすることである。
【０００８】
本明細書で実施形態として広く記載された本発明によれば、本発明は、複数のサーバが、着信するサービス要求を統一的にサポートできるようにする方法、コンピュータ・プログラム、及びシステムを特に提供する。そのために、本明細書に記載のシステム及び方法は、リソースを複数サーバにわたって分散し、編成し、且つ維持する。これらサーバは、着信する要求に同一様態で応答できるという点において全く同等である。従って、サーバは、システム上に維持されているリソースへのアクセスを要求しているクライアントには同等に見える。一実施形態では、この分散サーバシステム内の各サーバに、システム内で維持されている各リソースへの参照を列記したテーブルを与えることで、少なくとも部分的にはサーバが同等に見える。この参照は、実際にその参照に関連付けられたリソースに責任を負うか、或いはそのリソースを管理するサーバを直接的に指し示すか、或いは他の方法で参照するという意味で、直接参照であることが好ましい。従って、本発明によるサーバグループは、リソースへのアクセス要求毎に固定上限である１レベルのリダイレクトを設定することによって、他形式の分散リソース割り振りに関連付けられたネットワーク・トラフィックを減らす分散リソース割り振りシステムを提供する。
【０００９】
各サーバは、経路指定テーブルに格納されたグループ帰属関係に関する情報全体にアクセスできる。この経路指定テーブルはアクセス毎に更新可能で、グループを構成する様々なサーバの追加、削除、又は一時的な利用不可能状態による、グループ帰属関係の変更を反映する。変更がサーバグループに伝わると、各サーバにおける全ての関連した経路指定テーブルは同一情報を保持することになる。
【００１０】
任意サーバがリソース要求を受け取ると、そのサーバは関連した経路指定テーブルを用いて、どのグループメンバが要求リソース・オブジェクト又は要求リソース・オブジェクトの一部を実際に保持しているかを識別する。すると、ネットワークを介した費用がかかる照会／応答トランザクションを行うことなく、正しいサーバから所望のデータ・オブジェクトに横方向にアクセスすることにより、この要求に応えることができる。
【００１１】
より具体的には、本発明は、一様態において、ネットワークにおける複数サーバに分散したリソースにアクセスするための方法を含む。これら方法は、ネットワークを介して１つのサーバとの接続を確立し、このサーバからリソースを要求し、複数サーバにわたるリソースの分散を特定し、このサーバへのネットワーク接続を維持した状態で、このサーバを介して複数サーバにわたり分散したリソースを返す。随意選択だが、この分散は、複数サーバそれぞれに存在する経路指定テーブルから特定され、又、複数サーバ間で同期が取られる。経路指定テーブルは、複数サーバそれぞれに存在するリソース又はリソースの一部への参照を含むことができる。この参照は、関連付けられたリソースへの直接参照でよい。
【００１２】
一様態では、本発明は、分散リソースにアクセスするためのクライアント／サーバシステムを提供する。このシステムは、ネットワークに接続した複数サーバと、これら複数サーバにわたって分散したリソースとを含み、リソース又はリソースの一部を、これらサーバ内の対応するサーバに関連付ける経路指定テーブルが各サーバに設けられている。
【００１３】
本発明のその他の特徴及び利点は、次に記載する好適な実施形態の説明及び特許請求の範囲から明らかになるはずである。
【発明を実施するための最良の形態】
【００１４】
本明細書に記載したシステム及び方法は、データネットワーク上の複数サーバに分散したリソースを編成し、管理するためのシステムを含む。本発明は、部分的には、区分されたリソース環境における分散リソースを取り出すための透過的な要求の経路指定に関わる。本明細書に記載されたシステム及び方法は、概ね記憶装置及びアプリケーションに関わるが、当業者であれば、本発明は分散ファイルシステム、アプリケーション・サービス・プロバイダ及び他のアプリケーションをサポートするためのシステムを含む他の用途にも適用できることは理解するはずである。更に、通常の技能を備えた当業者であれば、本明細書に記載したシステム及び方法は、本発明により実現できる単に例示的な種類のもので、これらの代表的な実施形態は個別の用途に合わせて修正、補足、且つ変更できることは理解するはずである。
【００１５】
図１を参照すると、本発明によるシステムの一実施形態が図示されている。図１に示したように、１つ又は複数のクライアント１２が、例えばインターネット、イントラネット、ＷＡＮ、又はＬＡＮを介して、或いは直接接続によってサーバグループ１６の一部であるサーバ１６１、１６２、１６３に接続されている。
【００１６】
クライアント１２は、ＰＣワークステーション、手持ち型計算装置、ワイヤレス通信装置、又はこのサーバ１６と情報交換するためサーバ１６にアクセスして、このサーバと対話可能なネットワーククライアントを装備した他の装置を含む任意適切なコンピュータシステムでよい。このネットワーククライアントは、ネットスケープ・ウェブブラウザ、マイクロソフト・インターネット・エクスプローラー・ウェブブラウザ、リナックス・ウェブブラウザ、又はプロプラエタリ・ウェブブラウザを含むウェブクライアントなどのウェブクライアントか、ユーザによる、ウェブサーバ、ｆｔｐサーバ、ゴーファサーバ、又は他の種類のネットワークサーバとのデータ交換を可能とするウェブクライアントでよい。随意選択だが、クライアント１２及びサーバ１６は、遠隔サーバ１６のサービスにアクセスするのにインターネット１４などの安全が保証されていない通信路に依存してもよい。通信路を安全にするためには、これらクライアント及びサーバは、インターネットを介してデータを送信するための保護チャンネルを遠隔ユーザに提供するため開発された従来の安全保護システムの何れかなどの安全保護システムを利用すればよい。こうしたシステムの１つには、遠隔ユーザに、従来のウェブブラウザ・プログラムとウェブサーバとの間に信用できるパスを提供するネットスケープ・セキュアソケットレイヤー（ＳＳＬ）安全保護機構がある。
【００１７】
サーバ１６のサポートには、任意バージョンのユニックス・オペレーティングシステムを実行し、且つクライアント・システムの何れかと接続してデータを交換できるサーバを実行する、サンスパーク（商標）システムなどの市販のサーバ・プラットフォームを使用してもよい。図１の実施形態では、サーバ１６は、アパッチ・ウェブサーバ又は任意適切なウェブサーバのようなウェブサーバを含むことができる。サーバのウェブサーバ構成要素の動作は、「Laurie et al., Apache The Definitive Guide,
O'Reilly Press (1997)」を参照すればより完全に理解できる。
【００１８】
サーバ１６は、その動作を拡張して本明細書に記載したトランザクションを達成する他の構成要素を含むこともでき、又、サーバ１６のアーキテクチャは、用途に従って変更してもよい。例えば、このウェブサーバは、サーバに後述する動作を実行させるための、典型的にはモジュールと呼ばれる組み込み拡張機能を備えてもよいし、或いは、このウェブサーバは、実行可能ファイル（それぞれが上記動作の全て又は一部を実行するために利用される）のディレクトリにアクセス可能としてもよい。
【００１９】
こうした構成では、クライアント１２は、例えばサーバ１６１など、グループ１６の何れかのサーバに連絡を取り、ファイル、データベース、アプリケーション、又は他のリソースなどのネットワーク１４を介して利用可能なリソースにアクセスする。連絡を受けたサーバ１６１自体がそうしたリソースを保持しておらず、管理もしていないこともある。典型的には、クライアント１２は、グループ１６内の何れかのサーバに接続する。サーバグループ１６は、クライアント１２による区分リソースの利用が可能となるように構成されている。例示目的で、サーバ１６１、１６２、１６３の３つのサーバ全てにわたって区分されている１つのリソース１８と、これら３つのサーバの内の２つにわたって区分されている他のリソース１７との２つのリソースが図示されている。サーバグループ１６におけるサーバの数には特に制限はない。同様に、リソースの数にも特に制限はない。すなわち、各リソースは単一サーバ上に全てが収容されていてもよいし、各リソースは、サーバグループの全てのサーバ又はサーバグループの部分集合など、幾つかのサーバにわたって区分されていてもよい。実際には、もちろん、こうしたサーバに利用できる金額やサーバの計算処理上の制限など、実現に関わる事情による制限がありうる。更に、一実施例では、グループ分け自体（すなわち、どのサーバがグループを構成するかという決定）が運営上の決定となることもある。典型的なシナリオでは、１つのグループが、２、３のサーバのみか或いはたった１つのサーバしか含まないこともありうる。システム管理者は、必要なサービスのレベルを確保する必要性に合わせ、サーバをグループに追加していくことになる。サーバを増やせば、格納されるリソースのためのスペース（メモリ、ディスク記憶装置）が増加し、クライアント要求を処理するＣＰＵ処理能力が増加し、クライアントからの要求及びクライアントへの応答を伝送するネットワーク能力（ネットワーク・インターフェース）が増大する。当業者であれば、本明細書に記載したシステムは、追加サーバをグループ１６に加えることにより容易にスケール変更して、増大したクライアント需要に対処できることは理解するはずである。
【００２０】
本発明の文脈における代表的なリソースは、ブロック形式で格納される１つ又は複数のデータ・ボリュームでもよく、異なるブロックを異なるサーバ上に格納できる。このいわゆる「ブロック格納サービス（原語：block
storage service）は、本質的にネットワークアクセス可能ディスク・ドライブを表すものと考えることができる。従来の格納サーバでは、こうしたボリュームは単一サーバ内に収容されている。従来からの１つのサーバは、複数のボリュームを備えることができるが、常に複数ボリューム全体を格納する。
【００２１】
図２を参照すると、サーバ１６１（図１）に接続しているクライアント１２は、サーバグループ１６をそれが単一サーバであるかのように見ることになる。クライアント１２は、サーバグループ１６が場合によっては多数のサーバ１６１、１６２、１６３から構築されていることを認識しないし、リソース１７、１８が幾つかのサーバ１６１、１６２、１６３にわたって区分されていることも認識しない。結果として、サーバの数と、リソースがサーバ内で区分けされる様態とは、クライアント１２が認識するネットワーク環境に影響を与えることなく変更できる。
【００２２】
図３を参照すると、区分サーバグループ１６において、任意のボリュームを、グループ１６内の任意数のサーバにわたって分散してよい。図１及び２に示したように、１つのボリューム１７（リソース１）は、サーバ１６２、１６３にわたり分散されており、別のボリューム１８（リソース２）は、サーバ１６１、１６２、１６３にわたって分散されている。有利なことに、それぞれのボリュームは、「ページ」とも呼ばれる複数ブロックからなる固定サイズのグループで構成されており、代表的な１ページは８１９２個のブロックを含む。他の適切なページ・サイズを用いてもよい。代表的な実施形態では、グループ１６内の各サーバは、各ボリューム用の経路指定テーブル１６５を含んでおり、経路指定テーブル１６５は、特定ボリュームの特定ページが存在するサーバを識別する。例えば、サーバ１６１が、ボリューム３、ブロック９３８４７への要求をクライアント１２から受け取ると、サーバ１６１は、そのページ番号（例えば、ページ・サイズが８１９２個であればページ１１）を計算し、経路指定テーブル１６５においてページ１１を含むサーバの位置すなわちサーバ番号をルックアップする。仮にサーバ１６３がページ１１を含んでいる場合は、この要求はサーバ１６３に転送され、このサーバがデータを読み出して、そのデータをサーバ１６１に返す。次に、サーバ１６１は、この要求されたデータをクライアント１２に送る。言い換えると、この応答は、常にクライアント１２から要求を受け取ったものと同一サーバ１６１を介してクライアント１２に返される。
【００２３】
クライアント１２にとっては、どのサーバ１６１、１６２、１６３に接続しているかは透過的である。実際は、クライアントは、これらサーバをサーバグループ１６としか見えず、クライアントはサーバグループ１６にリソースを要求する。クライアント要求の経路指定は、それぞれの要求毎に別々に実行されることは理解すべきである。これにより、リソースの複数部分が、異なるサーバに存在できるようになる。又、これによって、クライアントがサーバグループ１６に接続している間に、リソース又はその部分を移動することが可能である。もしこれが行われた場合は、経路指定テーブル１６５は必要に応じて更新され、その後のクライアント要求は、現時点でその要求を処理する役目を果たすことになったサーバに転送される。少なくともリソース１７又は１８内部では、経路指定テーブル１６５は同一である。ここで説明する本発明は「リダイレクト」機構とは異なる。リダイレクト機構では、クライアントからの要求を処理できないことはサーバが決定し、クライアントをこの処理が可能なサーバにリダイレクトする。すると、クライアントは別のサーバと新たな接続を確立する。接続確立は比較的効率が悪いので、リダイレクト機構は頻繁な要求の処理には適していない。
【００２４】
図４は、区分サーバ環境でクライアント要求を処理するための代表的なプロセスの流れ４０を示す。処理４０は、ファイル又はファイルのブロックなどのリソースへの要求を受け取ること（ステップ４２）により、ステップ４１を開始する。ステップ４３において、プロセスは、要求されたリソースがクライアントからこの要求を最初に受け取ったサーバに存在するかを調べる。もし要求されたリソースが最初のサーバに存在すれば、ステップ４８で最初のサーバが、要求されたリソースをクライアントに返し、プロセス４０はステップ４９で終了する。反対に、要求されたリソースがこの最初のサーバに存在しなければ、ステップ４４でこのサーバは経路指定テーブルを調べて、ステップ４５でどのサーバがクライアントに要求されたデータを実際に保持しているかを特定する。すると、ステップ４６で、この要求は要求されたリソースを保持しているサーバに転送され、ステップ４８で、このサーバが最初のサーバに要求されたリソースを返す。上述と同様に、プロセスはここでステップ４８へ進み、ステップ４８では最初のサーバが、要求されたリソースをクライアントへ転送し、ステップ４９でプロセス４０は終了する。
【００２５】
幾つかのサーバに分散されているリソースは、ディレクトリ、ディレクトリ内の個別のファイル、又はファイル内のブロックであってもよい。他の区分サービスを考慮することも可能である。例えば、データベースを類似の様態で区分したり、分散ファイルシステム、或いはインターネットを介して配信されるアプリケーションをサポートする分散サーバ又は区分サーバを提供したりできる。一般に、このアプローチは、クライアント要求がリソース全体の部分への要求であると解釈でき、且つリソースの部分に対する処理が、全ての部分の間におけるグローバル協調（原語：coordination）を必要としないような任意のサービスに適用できる。
【００２６】
更に、図１では、システムが、複数サーバシステムからなるグループを含む機能ブロック要素の集合として図示されているが、通常の技能を備えた当業者には、本発明のシステムは、これらサーバ上で実行可能で、従ってこれらサーバを本発明に従ってシステムとして構成できるコンピュータ・プログラムとして、或いはコンピュータ・プログラムの一部として実現できることは明らかなはずである。更に、図１はグループ１６を複数サーバのローカル集合として示しているが、通常の技能を備えた当業者であれば、これは一実施形態にすぎず、本発明は、互いから物理的に離れたサーバを含む複数サーバの集合又はグループを含みうることは理解するはずである。
【００２７】
上述のように、幾つかの実施形態では、本発明のシステムは、ユニックス・ワークステーションなどの従来のデータ処理システム上で動作するソフトウェア構成要素として実現してもよい。そうした実施形態では、このシステムは、Ｃ言語コンピュータ・プログラム又はＣ＋＋、フォートラン、Ｊａｖａ（登録商標）、又はベーシックを含んだ任意の高レベル言語で書かれたコンピュータ・プログラムとして実装できる。そうした高レベルプログラム作成の一般的な技法は公知であり、例えば「Stephen G. Kochan, Programming in C, Hayden
Publishing (1983)」に記載されている。
【００２８】
本発明を、図示し且つ詳細に説明した好適な実施形態に関連して開示してきたが、当業者には、様々な修正及び改良が可能なことは明らかなはずである。従って、本発明の精神及び範囲は、次の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【００２９】
次の図は、本発明の幾つかの例示的な実施形態を示すもので、類似の参照番号は類似の要素を示す。上述の実施形態は本発明を例示したもと理解すべきであり、いかなる意味でも限定的なものと解釈すべきではない。
【図１】サーバグループとして編成されたサーバを備えたクライアント／サーバ・アーキテクチャの概略図である。
【図２】クライアントから見たサーバグループの概略図である。
【図３】クライアントと、あるグループのサーバとの間での情報の流れを詳細に示す。
【図４】区分リソース環境におけるリソースの取り出しに関するプロセスのフローチャートである。
【図１】
2005539289.tif 000003
【図２】
2005539289.tif 000004
【図３】
2005539289.tif 000005
【図４】
2005539289.tif 000006
【国際調査報告】
2005539289.tif 000007
2005539289.tif 000008