JP2007524877A - データ記憶システム - Google Patents

Abstract

データ記憶システムを効率的にマッピングするためのシステム及び方法を記載する。一実現例では、区分リソースサーバは複数の個別サーバを含み、これら個別サーバはクライアントには同等に見える。個別サーバそれぞれは、区分リソースサーバに維持されている各リソースへの参照を備えた経路指定テーブルを含むことができる。クライアントからの要求は、対象となるリソースを維持するか或いは管理しているサーバにそうした要求を経路指定する経路指定テーブルの関数として処理される。サーバは、論理ブロック・ネームにより編成された分化した記憶クラスを提供できる。更に、サーバが、クライアントからのリソースに対するアクセスへの要求を検出し、そのクライアントとの通信のための接続を確立する処理も記載されている。次に、この処理は、検出した要求に応じることができるサーバを識別し、状態情報がこの接続に関連付けられているかを特定する。するとこの処理は、識別したサーバに状態情報へのアクセスを許可し、このサーバにクライアントへの応答を作成且つ送信させ、更に、このサーバに状態情報を更新させる。

Description

本発明は、データ記憶に関し、特に、複数のサーバに亘ってデータを記憶するデータ記憶システム及びサービスに関する。

企業の電子商取引に対する依存、オンライン取引処理、及びデータベースが増大するにつれ、管理し記憶する必要がある情報の量には経験豊富なネットワーク管理者ですら怖じ気づくことがある。

サーバはデータを上手く記憶するが、その容量は限られており、多くのユーザが同一情報にアクセスしようとするとボトルネックとなることがある。その代わり、ほとんどの企業は、テープライブラリ、ＲＡＩＤディスクアレイ、更には光学記憶装置などの周辺記憶装置に依存している。これらの記憶装置は、データをオンラインでバックアップし、大量の情報を記憶するのに有効である。サーバにこうした装置を多数接続することで、ネットワーク管理者は、当該企業に関わるかなりの量のデータを記憶可能なサーバファームを構築できる。

ＲＡＩＤディスクアレイなどの高度な記憶技術は、分化した記憶クラスを提供する。これらの記憶クラスは、性能、信頼性、エラー検出、及び他の点において互いに異なることがある。これら様々な記憶クラスにより、システム管理者は異なる種類のデータを異なる記憶クラスで記憶できる。

既存のシステムは十分役には立つが、一般的にサービスクラス毎に別個の記憶装置を使用する。従って、１つの記憶装置を、例えばＲＡＩＤレベル０などの一定の性能レベルに設定し、この装置（或いは複数装置）が、フォトショップの一時ファイルなどの適切なデータを記憶できる。従って、これらシステムは、異なる記憶クラスに専用の装置を必要とする。

サーバファームのサイズが増大し、マルチメディアなどのデータ集中度が高いアプリケーションへの企業の依存度が増大すると、こうした従来の記憶モデルは有用性を維持できなくなる。この理由は、これらの周辺装置へのアクセスが遅くなることがあり、全てのユーザが、常に各記憶装置に容易且つ透過的にアクセスできるとは限らないからである。

最近になって、多くのベンダーがストレージ・エリア・ネットワーク（ＳＡＮ）を開発している。ＳＡＮは、より多くの選択肢（ネットワーク・ストレージ（ＮＡＳ）として動作する周辺装置よりも遙かに高速なアクセスを含む）をネットワーク記憶に提供する。更に、ＳＡＮは、大量データの取扱うために別個のネットワークを形成する柔軟性も提供する。

ＳＡＮは、複数ユーザの大きなネットワークに代わって、様々な種類のデータ記憶装置を関連付けられたデータサーバに相互接続する高速の特殊目的ネットワーク又はサブネットワークである。典型的には、ストレージ・エリア・ネットワークは、企業のためのリソースを計算するネットワーク全体の一部である。ＳＡＮは、通常は、ＩＭＢのＳ／３９０メインフレームのような他の計算リソースに近接してクラスタ化されているが、ＡＴＭ又は同期光通信ネットワークなどの広域通信ネットワーク・キャリア技術を用いて、バックアップ及び超大容量記憶用の遠隔地まで延びることもある。ＳＡＮは、光ファイバＥＳＣＯＮ又はファイバチャンネル技術などの既存の通信技術を用いることもできる。

ＳＡＮは、ディスク・ミラー化、バックアップ及び復元、データの記録及び記録データの取り出し、１つの記憶装置から他の記憶装置へのデータ移送、並びにネットワーク内の異なるサーバ間でのデータ共有をサポートする。ＳＡＮは、ネットワークに取り付けた記憶システムにサブネットワークを結合させることができる。

ＳＡＮには大きな将来性があるが、大きな課題に直面している。端的に言って、消費者は自分たちのデータ記憶システムに多くを期待している。具体的には、消費者は、ＳＡＮがネットワーク的なスケーラビリティ、サービス、及び柔軟性を提供する一方、サーバファームに太刀打ちできる速度でデータアクセスを実現することを要求している。これは、クライアントのデータ使用の動的パターンが大きく変動し、時間と共に変化する傾向にある環境においては特に難題である。例えば、ある記憶システムがクライアント要求に応答できる速度は、その要求を処理しているサーバで利用できるリソースに少なくとも部分的には依存する。しかし、データに対するクライアント要求は突発的に発生することがあり、又、記憶データの特定部分を、他のデータのある部分よりも非常に頻繁に要求する場合がある。更に、クライアント要求は、記憶データの特定部分が、通常は（常にでないにせよ）記憶データの他の部分と共に要求されるというパターンを踏むことがある。

企業の記憶システムでは、記憶データの特定部分は他の部分よりも頻繁に要求されるという事実に対処する様々な技術が開発されてきた。更に、企業の記憶システムが、ディスク記憶装置からより効率的に読み出されるデータブロックのパターンを作成できるように、ストライピング技術も開発されてきた。しかし、これらの技術をこうした典型的な企業の記憶システムに容易に実装するには、ゲートウェイ又はスイッチを修正してクライアント要求を監視し、データが元となる記憶媒体にどのように記憶されるかを制御することで実行する。こうした技法はストレージ・エリア・ネットワークにも利用できるが、これら技法を用いると、ＳＡＮはゲートウェイ又はスイッチ・アーキテクチャを使用せざるを得なくなり、クライアント要求が実行される速度が低下することにもなりかねない。

もう一つのアプローチは「記憶の仮想化」であり、中間デバイスをクライアントとサーバとの間に配置して、中間デバイスが要求の経路指定を実行するというものである。この方法では、何れのサーバも区分（原語：partition）されたサービス全体の一部のみを提供しているということを意識しない。中間デバイスを追加すると、システムの複雑性が増加してしまう。

従って、クライアントによるマルチサーバ環境における任意サーバとの連絡を許容し、且つ中間デバイス又はサーバにそれほど依存せずに、分散したリソースへのアクセスを許容できれば好ましい。又、ゲートウェイが全ての着信要求トラフィックを監視することなく、データがシステムにどのように記憶され且つ管理されるかをストレージ・エリア・ネットワークが制御できる方法及びシステムを提供するのが望ましい。更に、クラス専用記憶装置を必要とすることなく、分化した記憶クラスを記憶装置に提供することが望ましい。

発明の概要
一実現例では、本明細書に記載したシステム及び方法は、ブロックレベル・データ記憶サービスを提供するシステムを含む。より具体的には、本発明のシステム及び方法は、ブロック記憶サービスを複数の等価サーバにわたって区分するサーバシステムと共に用いられるブロックレベル・データ記憶サービスを提供する。等価サーバからなるシステムは、これに限定するわけではないが、それぞれが類似のインターフェースをクライアントに提示し、そのクライアントからの同一の要求に同一の応答を提示する複数の等価サーバからなるシステムを包含する。本明細書に記載したシステム及び方法は様々な用途に適用可能で、特定の用途に限定されるわけではない。ただし、説明を明確にするため、本明細書に記載したシステム及び方法は、ブロックレベル・データ記憶適用例を参照して説明する。又、この適用例では、複数のデータブロックが、複数の記憶装置にまたがって区分されたブロックデータ・ボリュームに記憶され、このデータ・ボリュームの異なる部分が、システム上の異なる等価サーバに関連付けられている。

本明細書に記載したように、このサーバシステムは、データブロックをデータ・ボリュームの異なる部分にわたって分散するための適応記憶ブロックデータ分散処理を用いる。このため、各等価サーバは、経路指定テーブル、データ移動プロセス、及び要求モニタ・プロセスを含む。要求モニタ・プロセスは、システムにアクセスしている１つ又は複数のクライアントからのサーバへの要求を監視できる。この要求は、ボリュームの区分又はある位置に記憶されたデータブロックに関連付けられているかもしれない。要求モニタは、関連付けられたサーバへのクライアントからの異なる要求を監視できる。更に、要求モニタは、システムの複数等価サーバ上で実行中の他の要求モニタ・プロセスと通信できる。こうすることで、要求モニタは、クライアントにより区分ブロックデータ記憶システムに転送される要求のグローバル・ビューを生成できる。この情報を共有することで、各等価サーバは、それに関連付けられた要求モニタ・プロセスを介して、ブロックデータ記憶システムによって処理される要求をグローバルに認識できる。

一旦、ブロックデータ記憶システムが処理している要求トラフィックのグローバル認識が得られると、各等価サーバは、そのデータ移動プロセスを用いてデータブロックを、或いは様々なデータブロックの管理責任を１つのサーバから別のサーバに移動できる。一実施形態では、各データ移動プロセスは、グローバル要求データを用いて要求クライアントにとってより効率的なサービス及びリソースのより効果的な割当てを実現するか、或いはブロックデータ記憶システムの性能、信頼性、又はそれ以外の特性を向上させるデータブロックの分散を特定する。

一実施形態では、各データ移動プロセスは他のデータ移動プロセスと通信して、異なるサーバのデータ移動プロセスに、データブロックが１つのサーバから他のサーバに移される時に通信させることができる。例えば、一実施形態では、データ移送の信頼性を向上させるため、異なる等価サーバ上のデータ移動プロセスは、１つのサーバから他のサーバへのデータブロックの移送を監視し、このブロックデータ移送が完了した時とこの移送が成功したかを確認するトランザクション機構を利用できる。

データブロック記憶システムにより維持される１つのボリュームの異なる区分にわたる異なるデータブロックの位置と、異なるボリュームにわたる異なるデータブロックの位置とを継続して認識するために、各等価サーバは経路指定テーブルを維持する。これを達成するため、各等価サーバは、ブロックデータ記憶システムに記憶されている異なるデータブロックと、各データブロックを担当する等価サーバとを追跡する経路指定テーブル・プロセスを含む。一実施形態では、これら等価サーバの経路指定テーブル・プロセスは互いと通信して、ブロックデータ記憶システムにより維持される異なるデータブロックと、これら異なるデータブロックに関連付けられた等価サーバとのシステム全体にわたる包括的データベースを提供する経路指定テーブルを各等価サーバに維持させることができる。

本発明のこの実現例によれば、本発明は、複数のサーバが、着信するサービス又はリソース要求を統一的にサポートできるようにする方法、コンピュータ・プログラム製品、及びシステムを特に提供する。そのために、本明細書に記載のシステム及び方法は、複数サーバにわたってリソースを分散し、編成し、且つ維持する。好適な一実施形態では、これらサーバは、着信する要求に同一様態で応答できるという点において全く同等である。従って、各サーバは、システム上に維持されているリソースへのアクセスを要求しているクライアントには同等に見える。

一実施形態では、経路指定テーブルも、サーバをメンバとするグループを示す帰属関係情報を記憶する。この経路指定テーブルは必要に応じて更新可能で、それによってグループを構成する様々なサーバの追加、削除、又は一時的な利用不可能状態によるグループ帰属関係の変更を反映する。変更がサーバグループに伝わると、各サーバにおける全ての関連した経路指定テーブルは同一情報を保持することになる。

任意サーバがリソース要求を受け取ると、そのサーバは関連した経路指定テーブルを用いて、どのグループメンバが要求リソース・オブジェクト又は要求リソース・オブジェクトの一部を実際に保持しているかを識別する。すると、ネットワークを介した費用がかかる照会／応答トランザクションを行うことなく、正しいサーバから所望のデータ・オブジェクトに横方向にアクセスすることにより、この要求に応えることができる。

本発明の別の実現例では、クライアントからのリソースに対するアクセス要求を検出し、そのクライアントとの通信のための接続を確立することにより、あるプロセスがクライアント要求に応答する。次に、このプロセスは、検出した要求に応じることができるサーバを識別し、状態情報がこの接続に関連付けられているかを特定する。するとこのプロセスは、識別したサーバに状態情報へのアクセスを許可し、このサーバにクライアントへの応答を作成且つ送信させ、更に、このサーバに状態情報を更新させる。

本発明の別の実現例では、システムがデータ・ネットワークを介してサービスを提供する。このシステムは、クライアントからのリソースへのアクセス要求を検出すると共に当該クライアントとの通信接続を確立するプロセスと、要求されたリソースに関連付けられたサーバを識別するサーバ識別プロセスと、検出した要求を識別したサーバに転送する要求ルータと、前記通信接続に関連付けられた状態情報への分散アクセスを許容するソケットサーバとを含み、前記識別されたサーバが、クライアントに応答するため状態情報にアクセスできる。

本発明の更に別の実現例によれば、分散サービスにデータ・ネットワークを介してアクセスするためのサーバは、クライアントからのサービスへのアクセス要求を検出すると共に当該クライアントと通信接続を確立するリスニング・スレッドを含み、この通信接続が、それに関連付けられた状態情報を備えている。更に、このサーバは、検出した要求に応じる能力がある利用可能サーバのリストを維持するリソース管理プロセスと、識別したサーバに検出した要求を転送する要求ルータと、前記通信接続に関連付けられた状態情報への分散アクセスを許容する接続データ・サーバとを含み、前記識別したサーバが、クライアントに応答するため状態情報にアクセスできる。

本発明の更に別の実現例によれば、区分リソースをサポートする複数サーバにクライアントからの検出した要求に応答させるソケットサーバを提供する。このソケットサーバは、前記クライアントと通信するために開かれた通信チャンネルに関連付けられたデータファイルを作成するための、前記検出した要求に応答するファイル・プロセスであって、状態情報を維持するためのファイル・プロセスと、前記複数サーバからの前記データファイルへのアクセス要求を検出する制御プロセスであって、前記複数サーバの少なくとも一つに、前記状態情報へのアクセスを許可するため前記データファイルへのアクセスを制御する制御プロセスと、前記複数サーバの一つに、前記作成したファイルに記憶された前記状態情報を更新させるファイル書き込みプロセスとを含む。

本発明の更なる実施形態は、次の特徴の内１つ又は複数を含みうる。前記状態情報はメモリに記憶できる。インターロック・プロセスを用いて前記状態情報を含むファイルへのアクセスを制御してよく、前記識別されたサーバは、ファイルに書き込むことで前記状態情報を更新してよい。前記インターロック・プロセスは、前記状態情報を含むファイルへのアクセスを一度に１台のサーバに制限でき、更に、このプロセスは、クライアントからの例えば分散サービスへの要求を検出するためのリスニング・スレッドを含むことができる。この通信接続は、ＨＴＴＰ、ＦＴＰ、ｉＳＣＳＩ、ＮＦＳ、及び／又はＣＩＦＳ通信プロトコルとして実現できる。前記状態情報は、ＩＰアドレス、ＴＣＰシーケンス番号及び／又はｉＳＣＳＩシーケンス番号を含むことができ、更に、ネットワーク・スタックにおける層と関連付けてもよい。

本発明の更に別の実現例では、ブロックレベル・データ記憶サービスが、単一の記憶装置上で分化記憶プールを提供する。そのために、本明細書に記載のシステム及び方法は、前記記憶装置（或いは複数の記憶装置）の論理ブロック・ネーム（ＬＢＮ）空間にわたる異なる性能特性を活用する。これら異なる性能特性を利用して、単一装置上で２つ以上の記憶クラスをサポートできる。

より具体的には、一様態において、本明細書に記載したシステム及び方法は、分化記憶クラスを提供するシステム及び方法を提供する。こうしたシステムは、複数の記憶位置と、当該記憶位置を編成するための論理ブロック・ネーム空間とを備えた記憶装置を含むことができる。性能プロセスが、前記記憶位置を異なる性能レベルを提供する複数領域に区分でき、マッピング・プロセスが、前記記憶位置の区分した部分を前記論理ブロック・ネーム空間の選択したセクションにマッピングできる。

幾つかの実施形態では、前記性能プロセスは、前記複数の記憶位置を異なるサービスレベルに関連付けられた複数カテゴリに分離する。又、この異なるサービスレベルは、例えば異なるＲＡＩＤ性能レベルに関連付けてもよい。しかし、当業者であれば、ＲＡＩＤ以外のタイプの分化記憶を用いてもよいことは理解するはずである。その例としては、使用する媒体と、コストと、他の特徴又は変数とを区別する記憶システムが含まれる。更に、幾つかの実施形態では、基礎となる記憶装置は単一の記憶媒体であるが、随意選択で、前記マッピング・プロセスが、複数の記憶ボリュームを選択した性能レベルで形成してもよく、更に、これら複数記憶ボリュームを１つ又は複数の記憶装置に関連付けてもよい。

随意選択で、前記システムは、前記論理ブロック・ネーム空間の異なる部分間でデータを移動させる負荷バランシング移動プロセスを更に含むこともできる。前記負荷バランシング移動プロセスは、データを記憶プール間で移動してシステム性能を向上させる適応データ配置プロセスを含むことができる。更に、管理プロセスが、管理者にデータを異なる記憶プール間で移動させることもできる。これらシステムは、データブロックを移動、記憶、且つアクセスでき、このために、ファイルシステム・サービスを提供するためディレクトリ構造及び階層を備えたファイルを含むファイルとして編成されたデータブロックを移動できる。代替的実施形態では、これらシステムは、記憶ボリューム・サービスを提供するためのプロセスを含むことができる。

別の実施形態では、これらシステムは、分化記憶クラスをサポートするシステムを提供する。こうしたシステムは、複数の記憶位置と、当該記憶位置を編成するための論理ブロック・ネーム空間とを備えた記憶装置を含むことができる。この記憶装置は、その内部で変動する前記記憶位置の性能パラメータも備えている。このシステムは、上述の記憶位置を性能パラメータの変動の関数として複数領域に区分するための区分プロセスを更に含むこともできる。前記区分プロセスは、システム要素の選択された構成の関数として固定セットの区分を選択できる。更に、性能プロセスが、複数の区分を異なる性能レベルと関連付けることができ、又、マッピング・プロセスが、前記記憶位置の識別した区分を前記論理ブロック・ネーム空間の選択したセクションにマッピングできる。

本明細書で記載したシステム及び方法は、ＲＡＩＤコントローラ、デバイスドライバ、オペレーティング・システム、アプリケーション・プログラム、又はネットワーク・サービスを含む多種多様な形式で実現できる。一実施形態では、このシステムは、１つ又は複数のサーバを含んだストレージ・エリア・ネットワークとして実現される。このサーバは、それ自身を構成するコンピュータ・コードを実行して、少なくとも部分的には、分化記憶クラスをサポートする記憶システムを提供するプロセスを実行する。

別の様態では、本発明は、分化記憶クラスを提供するための処理を提供する。こうした方法は、複数の記憶位置と、当該記憶位置を編成するための論理ブロック・ネーム空間とを備えた１つ又は複数の記憶装置を提供する段階を含むことができる。前記処理が、前記記憶位置を異なる性能レベルを提供する複数領域に区分でき、更に、前記記憶位置の区分した部分を前記論理ブロック・ネーム空間の選択したセクションにマッピングできる。随意選択で、前記処理は、前記複数の記憶位置を異なるサービスレベルに関連付けられた複数カテゴリに分離し、随意選択で、前記複数の記憶位置を、異なるＲＡＩＤ性能レベルに関連付けられた複数カテゴリに分離する段階を含むことができる。一実現例では、前記マッピング処理は、前記論理ブロック・ネーム空間の異なる部分を、ＲＡＩＤの異なるレベルにそれぞれ関連付ける。

随意選択で、前記処理は、前記論理ブロック・ネーム空間の異なる部分間でデータを移動させることによって負荷バランシングを行う段階を含むこともできる。負荷バランシングを行う前記段階は、異なる性能レベルを備えた記憶プールを含む記憶プール間でデータを移動し、従ってシステム性能全体又は１つの記憶クラスの性能全体などのシステムの一定局面の性能を向上させるか、或いは１つのデータクラスのサービスを向上させる。

これを達成するため、この処理は、管理者にデータを異なる記憶プール間で移動させることもできる。これは、データを異なる記憶プール間で移動させるパラメータ（動作パラメータを含む）を設定する能力を、前記管理者に提供するユーザ・インターフェースを介して実行できる。

前記マッピング段階は、複数の記憶ボリュームを選択した性能レベルで形成できる。

本発明のその他の特徴及び利点は、次に記載する好適な実施形態の説明及び請求の範囲から明らかになるはずである。

本明細書に記載したシステム及び方法は、データ・ネットワーク上の複数サーバに分散したリソースを編成し、管理するためのシステムを含む。より具体的には、本明細書に記載したシステム及び方法は、区分サービスをより効率的に運用するシステム及び方法を提供する。具体的には、本明細書に記載したシステム及び方法は、記憶装置の区分ボリュームにわたるデータブロックの割当てを管理するシステム及び方法を提供する。本明細書に記載されたシステム及び方法は、概ね記憶装置及びアプリケーションに関わるが、当業者であれば、本発明は分散ファイルシステム、アプリケーション・サービス・プロバイダ及び他のアプリケーションをサポートするためのシステムを含む他の用途にも適用できることは理解するはずである。更に、通常の技能を備えた当業者であれば、本明細書に記載したシステム及び方法は、本発明により実現できる単に例示的な種類のもので、これらの代表的な実施形態は個別の用途に合わせて修正、補足、且つ変更できることは理解するはずである。

図１を参照すると、本発明による適応記憶ブロックデータ分散のためのシステム１０が図示されている。図１に示したように、１つ又は複数のクライアント１２が、例えばインターネット、イントラネット、ＷＡＮ、又はＬＡＮなどのネットワーク１４を介して、或いは直接接続によってサーバグループ１６の一部であるサーバ１６１、１６２、１６３に接続されている。更に、図１はグループ１６を複数サーバのローカル集合として示しているが、互いから物理的に離れたサーバを含む複数サーバの集合又はグループとしてもよい。

クライアント１２は、ＰＣワークステーション、手持ち型計算装置、ワイヤレス通信装置、又はこのサーバグループ１６と情報交換するためサーバグループ１６にアクセスして、このサーバと対話可能なネットワーク・クライアントを装備した他の装置を含む任意適切なコンピュータ・システムでよい。ネットワーク・クライアントは、ユーザがサーバとデータ交換できるものあれば任意のクライアントでよい。随意選択だが、クライアント１２及びサーバグループ１６は、遠隔サーバグループ１６のサービスにアクセスするのに安全が保証されていない通信路に依存してもよい。通信路を安全にするためには、これらクライアント及びサーバは、ネットワークを介してデータを送信するための保護チャンネルを、遠隔ユーザに提供するため開発された従来の安全保護システムの何れかなどの安全保護グループシステムを利用すればよい。こうしたシステムの１つには、遠隔ユーザに、従来のウェブブラウザ・プログラムとウェブサーバとの間に信用できるパスを提供するネットスケープ・セキュアソケットレイヤー（ＳＳＬ）安全保護機構がある。

各サーバ１６１、１６２、及び１６３は、任意バージョンのＵｎｉｘ（登録商標）オペレーティング・システム上で動作するサンパーク（原語：SunParc）（商標）システムなどの市販のサーバプラットフォームを含むことができる。

各サーバ１６１、１６２、及び１６３は、それらの動作を拡張して本明細書に記載したトランザクションを達成する他のソフトウェア構成要素を含むこともでき、又、サーバ１６１、１６２、及び１６３のアーキテクチャは、用途に従って変更してもよい。例えば、各サーバは、サーバに後述する動作を実行させるための、典型的にはモジュールと呼ばれる組み込み拡張機能を備えてもよいし、或いは、これらサーバは、実行可能ファイル（それぞれが後述する動作の全て又は一部を実行するために利用される）のディレクトリにアクセス可能としてもよい。他の実施形態では、サーバ１６１、１６２、及び１６３は、当該サーバのオペレーティング・システムか、デバイスドライバか、テープライブラリ、ＲＡＩＤ記憶システム又は他のデバイスなどの周辺装置上で動作するソフトウェア・プロセスかに後述するプロセスの一部を組み込むソフトウェア・アーキテクチャを利用してもよい。何れの場合も、通常の技能を備えた当業者であれば、本明細書に記載したシステム及び方法は、多くの異なる実施形態及び実行例を介して実現でき、更に、採用した実施例及び実行例は対象とする用途の関数として異なり、これら全ての実施形態及び実行例はその範囲に入ることは理解するはずである。

こうした構成では、クライアント１２は、例えばサーバ１６１など、グループ１６の何れかのサーバに連絡を取り、データブロック、ページ、ファイル、データベース、アプリケーション、又は他のリソースなどのリソースにアクセスする。連絡を受けたサーバ１６１自体が要求されたリソースを保持しておらず、管理もしていないこともある。これに対処するため、サーバグループ１６は、クライアント１２による区分リソースの利用を可能とするように構成されている。例示目的で、サーバ１６１、１６２、１６３の３つのサーバ全てにわたって区分されている１つのリソース１８と、これら３つのサーバの内の２つにわたって区分されている他のリソース１７との２つのリソースが図示されている。サーバグループ１６がブロックデータ記憶システムであるこの代表的な応用例では、各リソース１８及び１７は区分ブロックデータ・ボリュームでよい。図１の実施形態では、従ってサーバグループ１６は、複数の等価サーバであるサーバ１６１、１６２、及び１６３からなるストレージ・エリア・ネットワーク（ＳＡＮ）として動作できるブロックデータ記憶サービスを提供する。各サーバ１６１、１６２、及び１６３は、区分ブロックデータ・ボリューム１８及１７の１つ又は複数部分をサポートできる。図示したシステム１０では、２つのデータ・ボリュームと３つのサーバが存在するが、サーバの数は特に限定されるものではない。同様に、リソース又はデータ・ボリュームの数にも特に制限はない。更に、各データ・ボリュームは単一サーバ上に全てが収容されていてもよいし、各データ・ボリュームは、サーバグループの全てのサーバ又はサーバグループの部分集合など、幾つかのサーバにわたって区分されていてもよい。実際には、もちろん、サーバ１６１、１６２、及び１６３に利用できるメモリの量やサーバ１６１、１６２、及び１６３の計算処理上の制限など、実現に関わる事情による制限がありうる。更に、一実施例では、グループ分け自体（すなわち、どのサーバがグループ１６を構成するかという決定）が運営上の決定となることもある。典型的なシナリオでは、１つのグループが、始めは２、３のサーバのみか或いはたった１つのサーバしか含まないこともありうる。システム管理者は、必要なサービスのレベルを確保する必要性に合わせ、サーバをグループに追加していくことになる。サーバを増やせば、記憶されるリソースのためのスペース（メモリ、ディスク記憶装置）が増加し、クライアント要求を処理するＣＰＵ処理能力が増加し、クライアントからの要求及びクライアントへの応答を伝送するネットワーク能力（ネットワーク・インターフェース）が増大する。当業者であれば、本明細書に記載したシステムは、追加サーバをグループ１６に加えることにより容易にスケール変更して、増大したクライアント需要に対処できることは理解するはずである。

図２を参照すると、サーバ１６１（図１）に接続しているクライアント１２は、サーバグループ１６をそれが単一サーバであるかのように見ることになる。クライアント１２は、サーバグループ１６が場合によっては多数のサーバ１６１、１６２、１６３から構築されていることを認識しないし、ブロックデータ・ボリューム１７、１８が幾つかのサーバ１６１、１６２、１６３にわたって区分されていることも認識しない。結果として、サーバの数及びリソースがサーバ間で区分される様態は、クライアント１２が認識するネットワーク環境に影響を与えることなく変更できる。

図３を参照すると、区分サーバグループ１６において、任意のボリュームを、グループ１６内の任意数のサーバにわたって分散してよい。図１及び２に示したように、１つのボリューム１７（リソース１）は、サーバ１６２、１６３にわたり分散されており、別のボリューム１８（リソース２）は、サーバ１６１、１６２、１６３にわたって分散されている。有利なことに、それぞれのボリュームは、「ページ」とも呼ばれる複数ブロックからなる固定サイズのグループで構成されており、代表的な１ページは８１９２個のブロックを含む。他の適切なページ・サイズを用いてもよい。代表的な実施形態では、グループ１６内の各サーバは、各ボリューム用の経路指定テーブル１６５を含んでおり、経路指定テーブル１６５は、特定ボリュームの特定ページが存在するサーバを識別する。例えば、サーバ１６１が、区分ボリューム１８、ブロック９３８４７への要求をクライアント１２から受け取ると、サーバ１６１は、要求されたブロック番号をページ・サイズで割ってそのページ番号（この例のようにページ・サイズが８１９２個であればページ１１）を計算し、経路指定テーブル１６５においてページ１１を含むサーバの番号をルックアップする。仮にサーバ１６３がページ１１を含んでいる場合は、この要求はサーバ１６３に転送され、このサーバがデータを読み出して、そのデータをサーバ１６１に返す。次に、サーバ１６１は、この要求されたデータをクライアント１２に送る。言い換えると、この応答は、常にクライアント１２から要求を受け取ったものと同一サーバ１６１を介してクライアント１２に返される。

クライアント１２にとっては、どのサーバ１６１、１６２、１６３に接続しているかは透過的である。実際は、クライアントは、これらサーバをサーバグループ１６としか見えず、クライアントはサーバグループ１６にリソースを要求する。クライアント要求の経路指定は、それぞれの要求毎に別々に実行されることは理解すべきである。これにより、リソースの複数部分が、異なるサーバに存在できるようになる。又、これによって、クライアントがサーバグループ１６に接続している間に、リソース又はその部分を移動することが可能である。もしこれが行われた場合は、経路指定テーブル１６５は必要に応じて更新され、その後のクライアント要求は、現時点でその要求の処理を担当するサーバに転送される。少なくともリソース１７又は１８内部では、経路指定テーブル１６５は同一である。ここで説明する本発明は「リダイレクト」機構とは異なる。リダイレクト機構では、サーバがクライアントからの要求を処理できないことはそのサーバが決定し、クライアントをこの処理が可能なサーバにリダイレクトする。すると、クライアントは別のサーバと新たな接続を確立する。接続確立は比較的効率が悪いので、リダイレクト機構は頻繁な要求の処理には適していない。

図４は、区分サーバ環境でクライアント要求を処理するための代表的な処理の流れ４０を示す。処理４０は、ファイル又はファイルのブロックなどのリソースへの要求を受け取ること（ステップ４２）により、ステップ４１を開始する。ステップ４３でこのサーバは経路指定テーブルを調べて、ステップ４４でどのサーバがクライアントに要求されたデータ部分を実際に保持しているかを特定する。ステップ４５において、この処理は、要求されたリソースがクライアントからこの要求を最初に受け取ったサーバに存在するかを調べる。もし要求されたリソースが最初のサーバに存在すれば、ステップ４８で最初のサーバが、要求されたリソースをクライアントに返し、処理４０はステップ４９で終了する。それに対して、もし要求されたリソースが最初のサーバに存在しなければ、ステップ４６でこの要求は、要求されたリソースを保持するサーバに転送され、ステップ４７でこのサーバが、要求されたリソースを最初のサーバに返す。上述と同様に、処理はここでステップ４８へ進み、最初のサーバが、要求されたリソースをクライアントへ転送し、ステップ４９で処理４０は終了する。

幾つかのサーバに分散されているリソースは、ディレクトリ、ディレクトリ内の個別のファイル、又はファイル内のブロックであってもよい。他の区分サービスを考慮することも可能である。例えば、データベースを類似の様態で区分したり、分散ファイルシステム、或いはインターネットを介して配信されるアプリケーションをサポートする分散サーバ又は区分サーバを提供したりできる。一般に、このアプローチは、クライアント要求がリソース全体の部分への要求であると解釈でき、且つリソースの部分に対する処理が、全ての部分の間におけるグローバル調整（原語：coordination）を必要としないような任意のサービスに適用できる。

図５を参照すると、ブロックデータ・サービスシステム１０の一実施形態を示す。特に、図５は、クライアント１２がサーバグループ１６と通信するシステム１０を示す。このサーバブロックは、３つのサーバ１６１、１６２、及び１６３を含む。各サーバは、経路指定テーブル２０Ａ、２０Ｂ、及び２０Ｃとして示した経路指定テーブルを含む。更に、各サーバは、それぞれデータ移動プロセス２２Ａ、２２Ｂ、及び２２Ｃを含む。各等価サーバ１６１、１６２、及び１６３は、これら経路指定テーブル及びデータ移動プロセスに加え、図５に示したようにそれぞれ要求モニタ・プロセス２４Ａ、２４Ｂ、及び２４Ｃを含む。更に、例示目的のみだが、図５は、１つのサーバ（サーバ１６２）から別のサーバ（サーバ１６３）へ移送可能な１ページのデータ２８としてのデータブロックの配置を示す。図５は、データブロックがデータページに編成されていることを図示しているが、これは単なる特定の実現例にすぎず、他の実現例では個々のデータブロックを異なるサーバ間で移動してもよい。更に、ファイル、ディレクトリ、及び他のデータ編成などの異なる種類のデータブロック編成を用いることができ、本明細書に記載したシステム及び方法は、ページ単位のデータブロックを１つのサーバから別のサーバへ移動するもののような特定の実施形態には限定されない。

図５に示したように、各等価サーバ１６１、１６２、及び１６３は、経路指定テーブル２０Ａ、２０Ｂ、及び２０Ｃを含むことができる。図５に示したように、各経路指定テーブル２０Ａ、２０Ｂ、及び２０Ｃは、情報を共有する目的で互いと通信できる。上述のように、経路指定テーブルは、個別の等価サーバの内の何れがサーバグループ１６により維持されている特定リソースを担当するかを探知できる。図５に示した実施形態では、サーバグループ１６はストレージ・エリア・ネットワーク（ＳＡＮ）とすることができ、このネットワークでは、各等価サーバ１６１、１６２、及び１６３は、クライアント１２がこのＳＡＮ上のその等価サーバにアクセスするのに利用できる個別のＩＰアドレスを備えている。上述したように、各等価サーバ１６１、１６２、及び１６３は、クライアント１２からの同一要求に同一の応答を提供できる。それを達成するため、個別の等価サーバ１６１、１６２、及び１６３の経路指定テーブルは互いに動作を調整して、異なるリソース（この代表的な実施形態では、データブロック、ページ、或いはデータブロックの他の編成）とそれぞれのデータブロック、ページ、ファイル、又は他の記憶要素を担当する個別の等価サーバとのグローバル・データベースを提供する。

図６は、経路指定テーブル２０Ａの一例とそこに記憶されている情報とを示す。図６に示したように、各経路指定テーブルは、区分データブロック記憶サービスをサポートする各等価サーバ１６１、１６２、及び１６３のサーバ番号６１０を含む。更に、各経路指定テーブルは、各等価サーバに関連付けられたページ６２０も識別する。

図５に更に示したように、データ移動プロセス２２Ｂは、より効率的な或いはより信頼性の高いデータブロック配列が可能かどうか特定するため、経路指定テーブル２０Ｂ内に記憶されている情報を利用する。このため、データ移動プロセス２０Ｂは、要求モニタ２４Ａ、２４Ｂ、及び２４Ｃにより収集されたデータにアルゴリズムを適用するコンピュータ・プログラムを含む。このデータ移動プロセスは、データブロックのより効率的な割当てが可能かを判断する際に、データブロックの現在の分散状況を検討し、これらデータブロックへの現在のクライアント要求を考慮するアルゴリズムを適用する。このため、データ移動プロセス２２Ｂは、要求モニタ・プロセス２４Ｂと通信することもできる。

各要求モニタ・プロセス２４Ａ、２４Ｂ、及び２４Ｃは、それぞれの等価サーバに到着する要求パターンを監視して、クライアント１２からのパターン又は要求がＳＡＮに転送されているか、又、これらパターンが、データブロックをより効率的に又はより信頼性高く区分できるかを判断する。一実施形態では、要求モニタ・プロセス２４Ａ、２４Ｂ、及び２４Ｃは、それぞれの等価サーバに到着するクライアント要求を単に監視するだけである。一実施形態では、各要求モニタ・プロセスは、個別の要求モニタ・プロセスが認識した異なる要求を表すテーブルを構築する。各要求モニタ・プロセス２４Ａ、２４Ｂ、及び２４Ｃは、各等価サーバが認識した要求のグローバル・データベースを構築するために互いに通信可能である。従って、この実施形態では、各要求モニタ・プロセスは、各等価サーバ１６１、１６２、及び１６３からの要求データを統合して、ブロックデータ記憶システム１６全体が認識する要求トラフィックを表すグローバル・データベースを生成できる。

一実施形態では、このグローバル要求データベースをデータ移動プロセス２２Ａ、２２Ｂ、及び２２Ｃが利用可能として、より効率的又は信頼性が高いデータブロックの区分が可能かどうかを判断するのに使用できるようにする。しかし、代替的実施形態では、各要求モニタ・プロセス２４Ａ、２４Ｂ、及び２４Ｃは、要求データベースを検討して要求のパターンがそのデータベース内に存在するかを特定できるパターン識別プロセスを含む。例えば、一実施形態では、要求モニタ・プロセス２４Ｂは、要求のグローバル・データベースを検討して、複数の異なるデータブロックが典型的には一緒に或いは連続的に要求されるパターンが存在するかを特定できる。こうしたパターンが識別されると、このパターンにはフラグをセットし、且つ何れかのデータ移動プロセス２２Ａ、２２Ｂ、又は２２Ｃが利用可能として、より効率的にクライアント要求に応えられるようにデータブロックを複数サーバにわたってストライピング可能かを特定できる。更に、他の実施形態では、要求モニタ・プロセスが、典型的には一緒に要求され且つ予め確認された或いは所定の閾値を上回る頻度で要求されるデータブロックを識別可能としてもよい。こすることで、要求モニタ２４Ａ、２４Ｂ、及び２４Ｃは、区分ボリューム内に存在するかもしれない「高需要ブロック」を識別できる。他の実施形態では、要求モニタ・プロセス２４Ａ、２４Ｂ、及び２４Ｃは、クライアントからブロックデータ記憶システム１６に転送される要求内に存在する他のパターンを識別可能としてもよい。

図５を再び参照すると、区分データブロックを再分散した例が示されている。具体的には、図５には次の任意の例を示した。すなわち、１ページ分のデータ２８を等価サーバ１６２から等価サーバ１６３へ移動させるため、データ移動プロセス２２Ｂ及びデータ移動プロセス２２Ｃが互いの動作を調整する。この実施形態では、１ページ分のデータが１つのサーバから次のサーバへ移動されている。通常の技能を備えた当業者であれば理解するように、１ページ分のデータは、２，０００から典型的には１６，０００個のデータブロックまでの複数データブロックをグループ化したデータブロック編成であって、このページが区分データブロック・ボリューム１８において別個の記憶単位であると識別されるようにヘッダを付けたものである。従って、この実施形態では、要求モニタ２４Ｂは、ページ２８が高需要ブロックと判断できるほど高頻度で要求されていると判断したのかもしれない。更に、要求モニタ２４Ｂは、等価サーバ１６２が等価サーバ１６３に比べてリソースが逼迫していると判断したのかもしれない。従って、等価サーバ１６３は、等価サーバ１６２に比べて、クライアント１２からのページ２８への要求により迅速に応えるために利用可能なリソースを備えているのかもしれない。よって、データ移動プロセス２２Ｂ及びデータ移動プロセス２２Ｃは、ページ２８を等価サーバ１６２から等価サーバ１６３へ移送するよう協働できる。

一実施形態では、データ移動プロセスは、ページ２８を等価サーバ１６２の記憶装置から等価サーバ１６３の記憶装置に単に移送し、関連付けられた経路指定テーブルを更新する。すると、この更新は、ブロックデータ記憶システム１６内の複数の経路指定テーブル２０Ａ、２０Ｂ、及び２０Ｃに通信される。しかし、他の実施形態では、データ移動プロセス２２Ｂ及び２２Ｃはトランザクション機構プロセスを用いてもよく、このプロセスは、ページ２８の等価サーバ１６２から等価サーバ１６３への移送を監視し、このトランザクションがいつ完了したか、又オプションだが、ページ２８がエラー無しで移送されたかを判断し、その時点で関連付けられた経路指定テーブル２０Ａ、２０Ｂ、及び２０Ｃを更新する。データ移動プロセス２２Ｂ及び２２Ｃが用いるトランザクションは、分散形ファイルシステムで一般的に用いられるような任意の従来の移送機構プロセスでよい。

図７乃至１２は、データ又はサービスへのアクセスに関するクライアントからの要求により効率的に対処するシステム及び方法を示す。

ここで図７を参照すると、ローカル・エリア・ネットワーク２４を介して通信する複数のクライアント１２からのリソース要求をサポートする従来のネットワーク・システムを示した。特に、図７は、複数のクライアント１２と、ローカル・エリア・ネットワーク（ＬＡＮ）２４と、スイッチ１６、マスタ・データテーブル１８、及び複数のサーバ２２ａ乃至２２ｎを含む記憶システム１４とを示す。記憶システム１４は、記憶リソースをＬＡＮ２４上で動作するクライアント１２に提供するストレージ・エリア・ネットワーク（ＳＡＮ）を提供できる。図７に示したように、各クライアント１２は、記憶システム／ＳＡＮ１４上に維持されているリソースを要求できる。それぞれの要求はスイッチ１６に送信され、このスイッチがそれを処理する。処理時に、クライアント１２は、ＬＡＮ２４を介してリソースを要求できる。また処理時に、スイッチ１６は、マスタ・データテーブル１８を用いて、複数サーバ２２Ａ乃至２２Ｎのどのサーバがクライアント１２に要求されているリソースを備えているかを識別する。

図７では、マスタ・データテーブル１８はデータベース・システムとして示されているが、代替的な実施形態では、スイッチ１６は、このスイッチが維持するフラットファイル・マスタ・データテーブルを用いてもよい。何れの場合も、スイッチ１６は、マスタ・データテーブル１８を利用して複数サーバ２２Ａ乃至２２Ｎの内どのサーバがどのリソースを維持しているかを特定する。従って、マスタ・データテーブル１８は、記憶システム１４により維持される様々なリソースと、基礎となるサーバ２２Ａ乃至２２Ｎの何れがどのリソースを担当しているかと、を列記した索引として機能する。

ここではＬＡＮを記載したが、当業者であれば、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイドエリア・ネットワーク（ＷＡＮ）、キャンパス・ネットワーク、又はインターネットなどネットワークのネットワークなどの、ＬＡＮ以外のネットワークも使用できることは理解するはずである。従って、本発明は、いかなる特定種類のネットワークにも限定されない。

図７に更に示したように、スイッチ１６が、要求されたリソースを得るための適切なサーバ２２Ａ乃至２２Ｎをいったん特定すると、取り出したリソースを識別されたサーバからスイッチ１６を介してＬＡＮ２４に送り、適切なクライアント１２に引き渡しできる。従って図７は、記憶システム１４が、スイッチ１６を、ＬＡＮ２４からの全要求の処理に関わる中央ゲートウェイとして使用することを示している。この中央ゲートウェイ・アーキテクチャを採用すると、クライアント１２により要求されたリソースを記憶システム１４から引き渡す時間が比較的長くなることがあり、記憶システム１４が維持するリソースへの需要増大による待ち時間の増加に従って、この引き渡し時間は増加することがある。

図８を参照すると、本発明によるシステム１０を示した。特に、図８は、複数のクライアント１２と、ローカル・エリア・ネットワーク（ＬＡＮ）２４と、複数のサーバ３２Ａ乃至３２Ｎを含むサーバグループ３０とを示す。図８に示したように、クライアント１２はＬＡＮ２４を介して通信する。図８に示したように、各クライアント１２は、サーバグループ３０に維持されているリソースを要求できる。ある応用例では、サーバグループ３０は、ネットワーク２４を介して通信するクライアント１２にネットワーク記憶リソースを提供するストレージ・エリア・ネットワーク（ＳＡＮ）である。従って、クライアント１２は、図８に要求３４として示したように、ＬＡＮ２４を介してサーバ（例えばサーバ３２Ｂとして示した）に送信される要求を出すことができる。

サーバグループ３０はストレージ・エリア・ネットワークとして構成されており、複数の等価サーバ３２Ａ乃至３２Ｎを含むことができる。これらサーバは、それぞれ別個のＩＰアドレスを備えており、従って、サーバグループ３０は、複数の異なるＩＰアドレスを含む１つのＳＡＮとして見え、それぞれのＩＰアドレスは、このＳＡＮにより維持される記憶リソースにアクセスするためクライアント１２が使用できる。更に、図示したサーバグループ／ＳＡＮ３０は、複数サーバ３２Ａ乃至３２Ｎを利用してこのストレージ・エリア・ネットワークにわたってリソースを区分できる。従って、個別サーバそれぞれは、サーバグループ／ＳＡＮ３０が維持するリソースの一部を担当できる。

動作時には、サーバ３２Ｂにより受信されたクライアント要求３４はサーバ３２Ｂによって処理され、クライアント１２が求めるリソースを特定し、複数サーバ３２Ａ乃至３２Ｎのどれがこのリソースを担当しているかを特定する。図８に示した例では、ストレージ・エリア・ネットワーク３０は、サーバ３２Ａがクライアント要求３４で識別されたリソースを担当することを特定する。図８に更に示したように、ストレージ・エリア・ネットワーク３０が採用するシステムでは、元々のサーバ３２Ｂがクライアント要求３４に応答するのでなく、担当サーバ（サーバ３２Ａ）に、ＬＡＮ２４上で経路指定可能な応答３８を、要求クライアント１２へ引き渡しさせることによって、担当サーバを要求クライアント１２に直接的に応答させるというショートカット手法を採用する。

上述したように、図８に示したストレージ・エリア・ネットワーク３０は、複数の等価サーバを含む。等価サーバは、限定するわけではないがクライアント１２に一様のインターフェースを提示するサーバシステムであると理解される。すなわち、各等価サーバは、クライアント１２の要求に同一の様態で応答するものである。従って、各サーバ３２Ａ乃至３２Ｎはクライアント１２に同一の応答を与える。従って、クライアント１２にとっては、サーバ３２Ａ乃至３２Ｎの内どれが要求に応答しているかは重要ではない。図示したサーバ３２Ａ乃至３２Ｎは、それぞれカリフォルニア州サンタクララ所在のサン・マイクロシステムズ社（原語：Sun
Microsystems, Inc.）が市販するサーバシステムの何れかなどの、従来のコンピュータ・ハードウェア・プラットフォームを含むことができる。各サーバは、１つ又は複数のソフトウェア・プロセスを実行して、このストレージ・エリア・ネットワークを実現する。サーバグループ３０は、ファイバチャネル・ネットワークシステム、アービットレーテッド・ループ、又はストレージ・エリア・ネットワークを提供するのに適したそれ以外の任意種類のネットワーク・システムを含むことができる。

各サーバ３２は自分自身の記憶リソースを維持してもよいし、図９に更に示したように、専用サーバ・ユニット４２に接続された記憶装置４４を含むこともできる。記憶装置４４は、ＲＡＩＤディスクアレイ・システム、テープライブラリ・システム、ディスクアレイ、又はＬＡＮ２４を介してクライアント１２に記憶リソースを提供するのに適したその他の任意装置でよい。

本発明のシステム及び処理はストレージ・エリア・ネットワークの応用例に限定されるものではなく、第１サーバが要求を受信し、第２サーバがその要求に対する応答を生成且つ送信するのがより効率的な他の応用例にも適用できる。他の応用例には、分散形ファイルシステム、データベース応用例、アプリケーション・サービスプロバイダ応用例、又はこのショートカット応答技術から利益を得られるその他の任意応用例が含まれる。

図９及び１０は、図８に示したシステムと共に使用するのに適したショートカット応答の一実施形態をより詳細に示す。特に、図１０は、ショートカット応答動作時に、接続及び状態情報がどのように形成されるを一例として示す機能ブロック図である。後に詳述するように、クライアント１２とサーバ３２とが情報交換する時に、これらクライアントとサーバとの間で接続が確立される。確立したそれぞれの接続について、サーバ３２は、クライアント１２に応答する際に使用する接続情報を維持する。従来のクライアント／サーバ情報交換では、クライアント要求を受信するサーバがそのクライアント要求にも応答する。こうした場合では、要求に応答したサーバが、クライアント１２への接続を設定するサーバでもある。従って、応答するのに必要な接続情報をサーバが必要とする時には、こうした接続情報は全てそのサーバが利用可能である。

本明細書に記載したショートカット応答処理では、応答を生成し送信するサーバは、要求３４を受信して接続を確立したサーバとは異なる場合もある。従って、応答３８を生成するサーバがクライアント１２に直接的に応答するためには、受信サーバ上に存在する接続情報にアクセスする必要があるかもしれない。この状態は、図９で高レベルにおいて図示されており、後に詳述する。

ショートカット応答の一例を図１０に示した。特に、図１０は、クライアント１２の１つから送信された要求３４に対するショートカット応答に参加する２つのサーバ３２Ａ及び３２Ｂを示す。この実施形態では、受信サーバはサーバ３２Ａであり、応答サーバはサーバ３２Ｂである。本明細書に記載したショートカット応答技術では、要求３４は受信サーバ３２Ａにより受信可能である。受信サーバ３２Ａは、サーバ３２Ｂが、要求３４で識別されたリソースを実際に担当していることを特定できる。従って、受信サーバ３２Ａは、この要求３４を応答サーバ３２Ｂに転送できる。応答サーバ３２Ｂは、要求３４への適切な応答を特定できる。すると、応答サーバ３２Ｂは、クライアント１２に直接送信できる応答３８を作成できる。しかし、上述のように、応答３８を生成するには、応答サーバ３２Ｂは、クライアントが送信した要求３４に応答して受信サーバ３２Ａが生成した接続情報にアクセスする。

図１０に示したように、クライアント要求３４が受信サーバ３２Ａに受信されると、このクライアント要求は、データリンク層４６を含む複数のネットワーク層により処理されうる。（典型的には、物理層はイーサネット（登録商標）・アダプタカード及びイーサネット（登録商標）・プロトコルを使用する。しかし、物理層の実装は実際の応用例に従って異なることがある。）従って、図１０に更に示したように、要求３４は、（図示した実施形態では）それぞれイーサネット（登録商標）・プロトコル処理層、インターネット・プロトコル（ＩＰ）処理層、及び伝送制御プロトコル（ＴＰＣ）トランスポート層を含む、データリンク層４６、ネットワーク層４８、及びトランスポート層５０により処理可能である。

図１０に更に示したように、ＩＰ層及びＴＣＰ層の接続情報５４及び５８が生成される。この情報には、要求３４を生成し且つ応答３８の転送先であるクライアント１２のＩＰアドレスを表す情報を含むことができる。更に、この情報には、幾つかの実施形態ではクライアントを識別するのに使用可能なＴＣＰ及び／又はｉＳＣＳＩシーケンス番号を含むこともできる。

ＴＣＰ層では、受信されるデータグラム又はパケットの数、或いはそれに類似した情報などの情報を含んだ接続情報５８を生成できる。

要求３４は、ＴＣＰ層５０の次に、アプリケーション層（すなわち、ＯＳＩモデルにおける「上位層」）５２に到着する。図示した実施形態では、アプリケーション層は、このストレージ・エリア・ネットワークの一部として使用できるインターネット・スモールコンピュータシステム・インターフェース（ｉＳＣＳＩ）プロトコルである。アプリケーション層では、接続情報６０が記憶される。その際、この情報は、ｉＳＣＳＩアプリケーション・プログラムの適切な機能に関連したアプリケーション・レベルの接続情報を表す。接続情報に加え、ＨＴＴＰクッキー、ＴＰＣ及び／又はｉＳＣＳＩシーケンス番号などの状態情報、及び他の類似情報も維持、記憶されることも理解できるであろう。

何れの場合でも、クライアント１２への応答の生成に関わる情報が、異なるレベルのネットワーク・プロトコルにおいて生成されることが分かるはずである。本明細書で記載するショートカット応答処理では、プロトコル・スタックの異なる層５４、５８、及び６０で維持されるプロトコル接続及び状態情報が応答サーバ３２Ｂと共有される。図１０に示したように、サーバ３２Ｂには、これと類似のプロトコル・スタックが確立されている。このプロトコル・スタックは、データリンク層６２、ネットワーク層６４、トランスポート層６８、及びアプリケーション層７０を含む。受信サーバ３２Ａと同様に、応答サーバ３２Ｂにおける各層６４、６８、及び７０は、それぞれ機能ブロック７２、７４、及び７８で示した接続及び状態情報のような接続及び状態情報を記憶できる。

要求３４に応答するにあたって、受信サーバ３２Ａは、破線８１で示したように要求３４をプロトコル・スタック内の上方へ送り出し、各層を通過させる。通常の技能を備えた当業者には公知であるが、要求３４がプロトコル・スタックを上方へ通過する際に、各層は情報をアンパックし、要求内のヘッダ情報を検討し、要求３４に応答する時に利用される接続情報を設定、更新することを含む他の機能を実行してその要求を処理する。

図１０に更に示したように、最高位の層５２では、ｉＳＣＳＩプロトコルが、クライアント１２により要求されたリソースをサーバ３２Ｂが本当に担当しているかを特定できる。従って、この応用例では、ｉＳＣＳＩアプリケーション・プログラムは、実線８２で示したようにクライアント要求をサーバ３２Ｂに転送できる。アプリケーション層５２は、クライアント要求を、クライアント１２が要求したリソースを管理しているサーバ３２Ｂのアプリケーション層７０に転送する。これを達成するため、サーバ３２Ａは、このサーバ３２Ａで維持されている接続データ５４、５８、及び６０へのアクセスを提供可能な分散形ソケットサーバ（原語：distributed
socket server）を含むことができる。図１０で示したように、この分散形ソケットサーバを設けると、要求３４がサーバ３２Ｂのネットワーク・スタックを介して受信され経路指定されたかのように、サーバ３２Ｂにこの接続及び状態情報へのアクセスを提供できる。図１０の経路８２で示したように、この分散形ソケットサーバは、要求３４がサーバ３２Ａからサーバ３２Ｂへ経路指定されたかような効果を奏する。結果的に、サーバ３２Ｂは、クライアント１２へ応答３８を生成するのに必要な接続及び状態情報を得る。

図１１を参照すると、分散形ソケットサーバの一実施形態が図示されている。特に、図１１は、等価サーバ３２Ａ及び３２Ｂを示す。サーバ３２Ａは、プロトコル・スタックにおける層４６、４８、５０、及び５２を含む複数の層を備えている。これらの層に並んで分散形ソケットサーバ８４が図示されている。同様に、サーバ３２Ｂは、プロトコル・スタックにおける層６２、６４、６８、及び７０を含む複数層を備えることが図示されている。サーバ３２Ｂは、プロトコル・スタックの各層と通信していることを示した分散形ソケットサーバ・プロセス８５を備えている。図１１には、サーバ３２Ａのアプリケーション層５２とサーバ３２Ｂのアプリケーション層７０との間のデータ交換に加え、サーバ３２Ａのソケットサーバ８４とサーバ３２Ｂのソケットサーバ８５との間のデータ交換の例も図示した。

図１１に示したように、分散形ソケットサーバ８４は、アプリケーション５２が確立したソケットと協働できる。一実施形態では、アプリケーション５２は、クライアントからの要求３４（図示しない）を受信し、サーバ３２Ａがクライアントにより要求されたリソースを担当するサーバでないことを特定する。サーバ３２Ａは、次に要求されたリソースを担当するネットワーク上のサーバを特定或いは識別する。アプリケーション５２は、サーバ３２Ｂが要求されたリソースを担当していることを特定する。次に、アプリケーション５２は、アプリケーション７０にアプリケーション・レベルでこの要求をサーバ３２Ｂで動作している転送する。この要求の転送は、図１１に示した通信８６で図示してある。アプリケーション７０は、転送された要求を受信し、その要求を処理する。

この要求を処理すると、サーバ３２Ｂは、応答（図示しない）を生成するための接続及び状態情報がサーバ３２Ａに記憶されていることを確認する。従って、アプリケーション７０は、ソケットサーバ８５に接続及び状態情報をソケットサーバ８４から要求するように指示する。ソケットサーバ８４は、プロトコル・スタックの各層４６、４８、５０、及び５２と通信している。従って、ソケットサーバ８４は、プロトコル・スタックのこれら層から適切な接続及び状態情報を収集し、収集した接続及び状態情報をソケットサーバ８５に通信８８を介して伝送できる。ソケットサーバ８５は、適切なプロトコル層６４、６８、及び７０でこの適切な情報を記憶又は設定できる。サーバ３２Ｂが応答を生成すると、ソケットサーバ８５は、接続状態に必要な変更があればそれをサーバ３２Ａのソケットサーバ８４に返送する。従って、分散形ソケットサーバ８５は、応答３８を生成するためサーバ３２Ｂを構成する（図１０を参照）。

図１２を参照すると、ショートカット応答に関する１つの処理がフローチャートとして示されている。具体的には、図１２は、ステップ９２で開始する１つの処理９０を示す。ステップ９２では、図示したクライアント１２の何れかが、カプセル化した要求をストレージ・エリア・ネットワーク（ＳＡＮ）に送信する。ステップ９２の後、処理９０はステップ９４に進む。このステップでは、クライアントが要求を差し向けたサーバのプロトコル・スタックをこの要求が通過する。このプロトコル・スタックを通過する際に、この要求は、それに関連した接続情報及び状態情報を変更且つ作成する。ブロック９８では、処理９０が、クライアント１２が生成した要求に応答する適切なサーバを特定する。応答サーバが要求を受信したサーバとは異なる場合は、処理９０は識別した応答サーバにその要求を転送する（或いは経路指定又はリダイレクトする）。

ブロック１００で、応答サーバは、転送された要求を処理してショートカット応答を生成するのに必要な接続及び状態情報を保持したサーバ（すなわち受信サーバ）を特定できる。別の実行例では、転送された要求に、識別した応答サーバ（例えばサーバ３２Ｂ）にクライアントへの適切な応答を生成させるための必要な接続状態情報を保持させてもよい。何れにしても、クライアントに要求されたリソースを担当すると識別されたサーバは、要求に応答するのに必要な接続状態情報とクライアントからの要求を現時点で保持している。ブロック１０２では、応答サーバは、そのサーバ上のプロトコル・スタックの層を介してクライアントへの応答を生成できる。次に、この分散形ソケットサーバは、適切なサーバ上の接続及び状態情報を更新し、処理が終了する。

図１３乃至１７は、分化した記憶プールを備えた記憶システムに関わる。これら記憶プールによって、システム管理者は、異なる種類のデータを異なる記憶クラスで記憶できる。

先ず図１３を参照すると、論理ブロック・ネーム（ＬＢＮ）の異なるセクションが、異なる種類の性能特性を備えることを示した記憶装置１０を図示する。具体的には、図１３で示した例では、装置１０のＬＢＮは、セクション１２、１４、及び１６としてそれぞれ示した３つの異なる性能クラスに分割されている。従って、図１３は、ディスク１０の全ネーム空間の抽象表現である。これらの用語の使用は異なる場合があるが、論理ブロック・ネーム空間は、ディスク上のアドレス可能位置の総体（原語：full
compliment）であることは一般に理解されており、更に、論理ブロックは、ディスク１０などのディスク上の最小アドレス可能空間であると理解されるはずである。典型的には、各論理ブロックは、ディスク先頭で始まって０から順番に割当てられる固有の論理ブロック・ネーム（又は番号）により識別できる。ＩＳＯ９６６０の標準では、ＣＤ上の全データは、論理ブロック番号でアドレス指定される。従って、図１３に示した装置は、例えばハードディスク装置のように記憶ディスクであると一般に理解される。しかし、本発明はそれに限定されるものではない。本明細書に記載されているシステム及び方法は、コンパクト・ディスク、フロッピー（登録商標）・ディスク、テープ駆動システム、及び他の類似種類のデータ記憶装置にも適用できる。

いずれにせよ、論理ブロック・ネーム空間は、それぞれが異なる種類の性能特性を備えた異なるセクションに再分割できることは一般に理解できるだろう。対象となる性能特性には、データがディスクのその部分からアクセスされる割合、ディスクのその部分の信頼性、及び記憶装置のその部分にアクセスするのに掛かる時間（デジタル・リニアテープ記憶に特に関連性が高い）が含まれうる。

一実現例では、本明細書に記載したシステム及び方法は、図示した記憶装置１０などの個別装置をスキャンし且つある種の特性を測定して、どのようにその装置を異なる性能クラスへ再分割すべきかを特定できる性能測定システムを含む。一実施形態では、この性能測定システムは、ＬＢＮの一部で実験的な読み出し書き込み動作を実行し、収集した実験データを用いてＬＢＮ空間内の異なる論理ブロック領域の性能特性を特定する。次に、この測定処理は、これら測定した特性から、一群の論理ブロックが、図示したセクション１２、１４、又は１６の何れかのような１つのセクションに集合化できるかどうかを判断できる。こうしたセクションにおいては、集合化した論理ブロックは共通の性能特性を備え、従って、特定の性能レベルと関連付けられうるＬＢＮ空間内における下位空間を提供する。言うまでもなく、当業者であれば、ＬＢＮ空間を異なるセクションに再分割するための細分性を選択可能である。又、選択した細分性は、概ね用途と、この用途にとって望ましい又は必要な記憶クラスの数とに左右される。他の実行例及び実施形態では、性能領域への区分は、システム設計時に決定且つ実行され、特定のシステム設計で固定される。この設計過程には実験及び測定が含まれることがあるが、その設計過程から得られる製品自体は、典型的には性能測定要素を含まない。選択した実施形態及び実行例は、対象となっているアプリケーション及び製品設計の詳細に焦点を当てられる。仮に製品の構成が大きく変動する可能性があり、製品設計段階でそうした構成全てを予め検討且つ分析していない場合は、「ランタイム」に測定を実行すると有用である。反対に、製品構成が承認に先だって厳密に管理され、分析されていれば、性の分析はその時点で行い、動作可能すなわち納入製品には測定要素は必要ない。

図１４を参照すると、ＲＡＩＤシステム２０が図示されている。ＲＡＩＤシステム２０は、装置２５Ａ乃至２５Ｄとして図示した同一の記憶装置を共有する、複数の分化した記憶プールを提供する。詳細には、図１４は、プールＡ２２及びプールＢ２４を含むＲＡＩＤ記憶システム２０を図示する。この実施形態に示すように、プールＡ２２はＲＡＩＤ１０記憶プールとして設定してあり、プールＢ２４はＲＡＩＤ５０記憶プールとして設定してある。当業者には周知のように、ＲＡＩＤは、「安価（又は独立）ディスクの重複アレイ」を表すため一般的に用いられる頭字語である。ＲＡＩＤディスクアレイは、単一の記憶システムとして集合的に機能するディスクの集合体であって、１つのディスクが故障してもデータを失うことなく、又、互いに独立して動作できる。様々なタイプのＲＡＩＤシステムが存在するが、一般に、カリフォルニア大学バークリー校の用語である「ＲＡＩＤ」が、６つのＲＡＩＤレベルを定義している。各レベルは、複数システム２５Ａ乃至２５Ｄなどのシステムにおける複数ドライブにわたってデータを分散するための異なる方法を示す。この技法は、コストと速度とを妥協させるものである。上述の異なるレベルには異なる意味があり、各レベルは、典型的には異なる利用法又は用途に対して最適化されている。例えば、ＲＡＩＤレベル０には重複はなく、異なるドライブ２５Ａ乃至２５Ｄにわたってデータを分割するので、データ処理量が高くなる。重複情報は全く記憶されていないので、性能は非常に高いが、アレイにおけるディスクの故障はデータ消失を意味する。このレベルは一般にストライピングと呼ばれる。ＲＡＩＤレベル１は、一般に２台のハード・ドライブによるミラリングと呼ばれる。このレベルでは、全てのデータを１台のドライブから別のドライブへ複写することにより重複を実現する。レベル１アレイの性能は単一ドライブより僅かに優れている。しかし、一方のドライブが故障しても、データは消失しない。図示したプールＡ２２が用いているようなＲＡＩＤレベル１０は、複数のＲＡＩＤ１（ミラリングした）セットを単一アレイで用いた二重レベルアレイである。データは、全てのミラリングされたセットにわたりストライピングされる。ＲＡＩＤ１は複数のドライブを用い、性能を向上させ、又、各ドライブは典型的には複写又はミラリングされている。プールＢ２４が用いているようなＲＡＩＤレベル５０は、複数のＲＡＩＤ５レベルを単一アレイで用いた二重レベルアレイである。図１４に示したＲＡＩＤシステム２０は、４つの記憶装置２５Ａ乃至２５Ｄを用いて、それぞれが異なる性能特性及び異なる性能レベルを持つ、２つの異なる記憶クラスをサポートすることは理解できるだろう。

図１５に示したもののような本発明による例示的システムでは、図１４に示したＲＡＩＤレベルを図１３に示した装置性能変化と組み合わせることによって、分化したプールを形成している。特に、図１５は、４つの記憶装置３５Ａ乃至３５Ｄを含むシステム３０を示す。他の記憶装置を必要に応じて追加してもよい。図１３と同様に、装置３５Ａ乃至３５ＤのＬＢＮ空間は、装置の表面に延伸しているように抽象的に図示されており、又、図１３に示したように、装置３５Ａ乃至３５Ｄは、それぞれのＬＢＮ下位空間が異なる性能レベルに関連付けられた３つの下位空間に再分割されている。同時に、図１５に示したシステムは、異なるＲＡＩＤレベルを異なる性能下位空間に関連付けている。例えば、性能ＡのＬＢＮ下位空間は、ＲＡＩＤ１０記憶レベルをサポートするために用いられており、性能ＢのＬＢＮ下位空間は、ＲＡＩＤ５サービスレベルをサポートするために用いられており、又、性能ＣのＬＢＮ下位空間は、ＲＡＩＤ５０性能レベルを提供するために用いられている。

システム３０を設定する過程で、記憶システム管理者は、これら性能ＬＢＮ下位空間のうちどれを使ってどのＲＡＩＤレベルをサポートすべきかを決定できる。異なる下位空間からの選択には任意適切な技法を使用すればよい。例えば、例えば領域Ａが特に優れたランダム・アクセスＩ／Ｏ性能を備えたドライブ領域なら、これをＲＡＩＤ−１０セットに割り当てるのが適切な場合が多い。それは、ＲＡＩＤ−１０は良好なランダム・アクセス性能（特にランダム書き込み性能）を特徴とするからである。これら二層の特性がこうして互いを強化し、良好なランダム書き込み性能を備えた「プールＡ」がもたらされる。

図１６は、図１５に示したタイプの分化記憶プールにわたる、範囲又はページに基づいた記憶サービスの割当て処理の一例を示す。図示したように、システム３０は、頻繁にアクセスされるデータを記憶できるプールＡを提供する。このため、ＬＢＮのプールＡ下位空間を用いてＲＡＩＤレベル１０をサポートする。ＲＡＩＤレベル１０は、一定の耐故障性と相当のデータ処理量をもたらす。記憶サービスを異なる記憶クラスにわたって仮想化することで、上述したように同一セットの装置を利用する一方で、最適或いはほぼ最適な性能と、最小の物理装置消費が同時に得られる。ブロック記憶サービスの複数インスタンス（「論理ボリューム」）を形成することができ、これら全てが、同一セットの基礎となる分化記憶プールを共有する。それぞれは、その性能要件に従って割り当てられたプールの部分である。

図１７は任意選択の実施形態を示し、このシステムは、データブロックをデータ・ボリュームの異なる部分にわたって分散するための、上述の適応記憶ブロックデータ分散処理を用いる（図１乃至６を参照）。システム５０の各サーバ２２Ａ、２２Ｂは、経路指定テーブル５２、データ移動プロセス５４、及び要求モニタ・プロセス５８を含む。要求モニタ・プロセス５８は、システム５０にアクセスしている１つ又は複数クライアント１２からサーバ２２Ａ又は２２Ｂへの要求を監視できる。

この要求は、記憶装置３０のボリュームの区分又はある位置に記憶されたデータブロックに関連付けられているかもしれない。要求モニタ５８は、関連付けられた１つ又は複数のサーバ２２Ａ、２２Ｂへのクライアント１２からの異なる要求を監視できる。更に、要求モニタ５８は、システム５０の複数等価サーバ２２上で実行中の他の要求モニタ・プロセス５８と通信できる。こうすることで、要求モニタ５８は、クライアント１２により区分ブロックデータ記憶システム５０に転送される要求のグローバル・ビューを生成できる。この情報を共有することで、各サーバ２２Ａ及び２２Ｂは、それに関連付けられた要求モニタ・プロセス５８を介して、ブロックデータ記憶システム５０により処理される要求をグローバルに認識できる。

図１７に更に示したように、データ移動プロセス５４は、より効率的な或いはより信頼性の高いデータブロック配置が可能かどうか特定するために経路指定テーブル５２内に記憶された情報を利用する。これを達成するため、データ移動プロセス５４は、要求モニタ５８により収集されたデータにアルゴリズムを適用するコンピュータ・プログラムを含む。このデータ移動プロセス５４は、データブロックのより効率的な割当てが可能かを判断する際に、データブロックの現在の分散状況を検討し、これらデータブロックへの現在のクライアント１２の要求を考慮するアルゴリズムを適用する。図示したこの実施形態では、このアルゴリズムは、特定のデータブロックが現在使用されている記憶クラスと異なるクラスにより適しているかを判断する。従って、この適応プロセスは、例えばシステム３０と同様に、このシステムで利用可能な幾つかの記憶クラス間でデータを移動可能である。こうすることで、システム５０は、最適或いはほぼ最適なデータ記憶性能を達成できる。こうして達成される記憶性能は、データ移動プロセスがシステム中の異なる領域間でデータを移動させるような単一サーバを用いるシステムでも達成できる。

更に、図１３乃至１７は、代表的システムを機能ブロック要素の集合として図示しているが、通常の技能を備えた当業者には、本発明のシステム及び方法は、サーバ上で実行可能で、従ってこれらサーバを本発明に従ったシステムとして構成できるコンピュータ・プログラムとして、或いはコンピュータ・プログラムの一部として実現できることは明らかなはずである。更に、上述のように、幾つかの実施形態では、本発明のシステムは、ユニックス・ワークステーションなどの従来のデータ処理システム上で動作するソフトウェア構成要素として実現してもよい。そうした実施形態では、このシステムは、Ｃ言語コンピュータ・プログラム又はＣ＋＋、フォートラン、Ｊａｖａ（登録商標）、又はベーシックを含んだ任意の高レベル言語で書かれたコンピュータ・プログラムとして実装できる。そうした高レベルプログラム作成の一般的な技法は公知であり、例えば「Stephen G.
Kochan, Programming in C, Hayden Publishing (1983)」に記載されている。

更に、図示したシステム及びプロセスは、従来のハードウェア・システムから構築してよく、特別に開発されたハードウェアは必要ない。例えば、図示したサーバグループ及び／又はクライアント・システムは、ネットワークサーバと情報交換するためこのサーバにアクセスして、このサーバと対話可能なネットワーククライアントを装備したＰＣワークステーション、手持ち型計算装置、ワイヤレス通信装置、又は他の装置を含む任意適切なコンピュータシステムでよい。随意選択だが、これらクライアント及びサーバは、遠隔サーバのサービスにアクセスするにあたって安全が保証されていない通信路に依存してもよい。通信路を安全にするためには、これらクライアント及びサーバは、インターネットを介してデータを送信するための保護チャンネルを遠隔ユーザに提供するため開発された従来の安全保護システムの何れかなどの安全保護システムを利用すればよい。これらサーバのサポートには、任意バージョンのユニックス・オペレーティングシステムを実行し、何れかのクライアントと接続してデータを交換できるサーバを実行する、サンスパーク（原語：Sun
Sparc）（商標）システムなどの市販のサーバプラットフォームを使用してもよい。

本発明を、図示し且つ詳細に説明した好適な実施形態に関連して開示してきたが、当業者には、様々な修正及び改良が可能なことは明らかなはずである。

次の図は、本発明の幾つかの例示的な実施形態を示すもので、類似の参照番号は類似の要素を示す。上述の実施形態は本発明を例示したもと理解すべきであり、いかなる意味でも限定的なものと解釈すべきではない。
サーバグループとして編成されたサーバを備えたクライアント／サーバ・アーキテクチャの概略図である。 クライアントから見たサーバグループの概略図である。 クライアントと、あるグループのサーバとの間での情報の流れを詳細に示す。 区分リソース環境におけるリソースの取り出しに関する処理のフローチャートである。 本発明によるシステムの一実施形態をより詳細に機能ブロック図として示す。 経路指定テーブルの一例を示す。 ストレージ・エリア・ネットワーク上に維持されたリソースにアクセスを提供する従来技術システムの構成を概略的に示す。 本発明による一システムの機能ブロック図を示す。 図８のシステムをより詳細に示す。 ネットワークの複数層を通過するデータの流れを示す。 図８のシステムの一実施形態をより詳細に示す。 図８に示したシステムの代表的処理のフローチャートを示す。 ＬＢＮのリストに基づいて異なる性能特性を備えた１つの記憶装置を示す。 同一の記憶装置を共有するＲＡＩＤ分化記憶プールを示す。 個別の記憶装置性能とＲＡＩＤ性能特性とを組み合わせた分化記憶プールを示す。 記憶サービスの、分化記憶プールにわたる範囲及びページに基づいた割当てを示す。 図５の実施形態に類似した実施形態をより詳細に機能ブロック図として示す。

Claims (64)

1. ブロックレベル・データ記憶のためのシステムであって、
   複数の等価サーバであって、それぞれが記憶ブロックの一部を担当し、それぞれが前記サーバ間でブロックの移動を調整するために他のサーバ上のデータ移動プロセスと直接的に通信可能なデータ移動プロセスを備えた、複数の等価サーバと、
   他のサーバ上の要求モニタ・プロセスと直接的に通信可能であって、ブロックへの要求の調整分析を生成可能な要求モニタ・プロセスと、
   等価サーバとそれらに関連付けられたデータブロックとの調整リストを維持するため、経路指定テーブル・プロセッサと通信可能な経路指定テーブル・プロセスとを含む、システム。
2. 前記データ移動プロセスが、前記複数サーバの動作特性に応答すると共に前記複数サーバにわたるブロックの再配分を識別するための適応移動アルゴリズムを含む、請求項１に記載のシステム。
3. 前記要求モニタ・プロセスが、任意サーバが受信した要求数を特定して、当該サーバが負担する要求負荷を測定する、請求項１又は２に記載のシステム。
4. 前記要求モニタ・プロセスが、データ・ボリュームにアクセスするクライアントの数、Ｉ／Ｏ要求の数、及び利用可能な記憶の容量からなるグループから選択されるパラメータを測定する、上記請求項の何れかに記載のシステム。
5. 前記要求モニタ・プロセスが、任意のブロック・グループが高需要ブロック基準を上回る頻度で一緒にアクセスされているかを識別する、上記請求項の何れかに記載のシステム。
6. 前記データ移動プロセスが、前記要求モニタ・プロセスにより生成されたデータを処理して、性能を向上させるため選択したサーバに移動すべきデータブロックを特定する、上記請求項の何れかに記載のシステム。
7. 前記データ移動プロセスが、適応ブロック分散アルゴリズムを前記要求モニタ・プロセスにより生成されたデータに適用する、上記請求項の何れかに記載のシステム。
8. 前記データ移動プロセスが、選択したデータブロックを複数サーバにわたってストライピングするデータ・ストライピング・アルゴリズムを含む、上記請求項の何れかに記載のシステム。
9. 前記データ移動プロセスが、データブロックのサーバ間の移送を監視するトランザクション・プロセスを含む、上記請求項の何れかに記載のシステム。
10. 前記トランザクション・プロセスが、データブロックの前記移送時に検出されたエラーをログ記録するエラーログ・プロセスを含む、請求項９に記載のシステム。
11. 前記要求モニタが、２つ以上のデータ・ボリュームに対する要求を監視する、上記請求項の何れかに記載のシステム。
12. 前記データ移動プロセスが、２つ以上のデータ・ボリュームに関連付けられたデータブロックを移動する、上記請求項の何れかに記載のシステム。
13. ブロックレベル・データ記憶のための処理であって、
    複数の等価サーバを提供する段階であって、各等価サーバが、記憶データブロックの一部を担当し、それぞれの等価サーバに受信されたクライアント要求を監視すると共に、別のサーバ上の要求モニタ・プロセスと直接的に通信してブロック要求の調整分析を生成する、提供する段階と、
    前記サーバ間でデータブロックを移動する段階と、
    等価サーバとそれらに関連付けられたデータブロックとの調整リストとなる経路指定テーブルを維持すると共に、当該システム上の異なるサーバにわたって記憶されているデータブロックを追跡するグローバル経路指定テーブル・プロセッサを生成するために他の経路指定テーブルと通信する段階とを含む、処理。
14. データブロックを移動する前記段階が、前記複数サーバの動作特性に応答する応移動アルゴリズであって、前記複数サーバにわたるブロックの再配分を識別す適応移動アルゴリズムを適用する段階を含む、請求項１３に記載の処理。
15. 前記要求の監視が、任意サーバが受信した要求の数を特定して、当該サーバが負担する要求負荷を測定する、請求項１３又は１４に記載の処理。
16. 前記要求の監視が、データ・ボリュームにアクセスするクライアントの数、Ｉ／Ｏ要求の数、及び利用可能な記憶の容量からなるグループから選択されるパラメータを測定する段階を含む、上記請求項の何れかに記載の処理。
17. 前記要求の監視が、任意のブロック・グループが高需要ブロック基準を上回る頻度で一緒にアクセスされているかを識別する段階を含む、上記請求項の何れかに記載の処理。
18. 前記データを移動する段階が、選択したデータブロックを複数サーバにわたってストライピングする段階を含む、上記請求項の何れかに記載の処理。
19. 前記データを移動する段階が、複数サーバにわたるデータブロックの移送を監視する段階を含む、上記請求項の何れかに記載の処理。
20. データブロックの前記移送時に検出されたエラーをログ記録するエラーログを生成する段階を更にを含む、請求項１９に記載の処理。
21. 前記要求の監視が、２つ以上のデータ・ボリュームに対する要求を監視する段階を含む、上記請求項の何れかに記載の処理。
22. サービスをデータ・ネットワークを介して提供するための処理であって、
    クライアントからのリソースに対するアクセスへの要求を検出し、当該クライアントとの通信のための接続を確立する段階と、
    前記検出された要求に応じるサーバを識別する段階と、
    状態情報が前記接続に関連付けられているかを特定する段階と、
    前記識別したサーバに前記状態情報へのアクセスを許可し、前記識別したサーバに前記クライアントへの応答を作成且つ送信させる段階と、
    前記識別したサーバに前記状態情報を更新させる段階とを含む、処理。
23. 前記状態情報をメモリに記憶する段階を更に含む、請求項２２に記載の処理。
24. 前記識別したサーバに前記状態情報を更新させるためのファイル書き込みプロセスを提供する段階を更に含む、請求項２２又は２３に記載の処理。
25. 前記状態情報を含むファイルへのアクセスを制御するためのインターロック・プロセスを提供する段階を更に含む、請求項２２乃至２４の何れかに記載の処理。
26. 前記インターロック・プロセスが、クライアントからの要求を検出するためのリスニング・スレッドを含む、請求項２５に記載の処理。
27. 前記リスニング・スレッドが、クライアントからの分散サービスへのアクセス要求を検出する、請求項２６に記載の処理。
28. 前記通信接続が、ＨＴＴＰ、ＦＴＰ、ｉＳＣＳＩ、ＮＦＳ、及びＣＩＦＳからなるグループから選択される通信プロトコルに従う、請求項２２乃至２７の何れかに記載の処理。
29. 前記状態情報が、ＩＰアドレス、ＴＣＰシーケンス番号、及びｉＳＣＳＩシーケンス番号からなるグループから選択される情報を含む、請求項２２乃至２８の何れかに記載の処理。
30. サービスをデータ・ネットワークを介して提供するためのシステムであって、
    クライアントからのリソースへのアクセス要求を検出すると共に当該クライアントとの通信接続を確立するプロセスと、
    前記要求されたリソースに関連付けられたサーバを識別するサーバ識別プロセスと、
    前記検出した要求を識別したサーバに転送する要求ルータと、
    前記通信接続に関連付けられた状態情報への分散アクセスを許容するソケットサーバとを含み、前記識別サーバが、前記クライアントに応答するため前記状態情報にアクセスできる、システム。
31. 前記ソケットサーバが、前記識別したサーバに前記状態情報を更新させるためのファイル書き込みプロセスを含む、請求項３０に記載のシステム。
32. 前記ソケットサーバが、前記状態情報を含むファイルへのアクセスを制御するためのインターロック・プロセスを含む、請求項３０又は３１に記載のシステム。
33. 前記インターロック・プロセスが、前記状態情報を含む前記ファイルへのアクセスを一度に１台のサーバに制限する、請求項３２に記載のシステム。
34. 前記インターロック・プロセスが、クライアントからの要求を検出するためのリスニング・スレッドを含む、請求項３４に記載のシステム。
35. 前記リスニング・スレッドが、クライアントからの分散サービスへのアクセス要求を検出する、請求項３４に記載のシステム。
36. 前記通信接続が、ＨＴＴＰ、ＦＴＰ、ｉＳＣＳＩ、ＮＦＳ、及びＣＩＦＳからなるグループから選択される通信プロトコルに従う、請求項３０乃至３５の何れかに記載のシステム。
37. 前記状態情報が、ＩＰアドレス、ＴＣＰシーケンス番号、及びｉＳＣＳＩシーケンス番号からなるグループから選択される情報を含む、請求項３０乃至３６の何れかに記載のシステム。
38. データ・ネットワークを介して分散サービスにアクセスするためのサーバであって、
    クライアントからのサービスへのアクセス要求を検出すると共に当該クライアントと通信接続を確立するリスニング・スレッドであって、当該通信接続が、それに関連付けられた状態情報を備える、リスニング・スレッドと、
    前記検出した要求に応じる能力がある利用可能サーバのリストを維持するリソース管理プロセスと、
    識別したサーバに前記検出した要求を転送する要求ルータと、
    前記通信接続に関連付けられた状態情報への分散アクセスを許容する接続データ・サーバとを含み、前記識別したサーバが、前記クライアントに応答するため状態情報にアクセスできる、サーバ。
39. 区分リソースをサポートする複数サーバに、クライアントからの検出した要求に応答させるソケットサーバであって、
    前記クライアントと通信するために開かれた通信チャンネルに関連付けられたデータファイルを作成するための、前記検出した要求に応答するファイル・プロセスであって、状態情報を維持するためのファイル・プロセスと、
    前記複数サーバからの前記データファイルへのアクセス要求を検出する制御プロセスであって、前記複数サーバの少なくとも一つに前記状態情報へのアクセスを許可するため、前記データファイルへのアクセスを制御する制御プロセスと、
    前記複数サーバの一つに、前記作成したファイルに記憶された前記状態情報を更新させるファイル書き込みプロセスとを含む、ソケットサーバ。
40. 前記制御プロセスが、前記作成されたファイルへのアクセスを制御するインターロック・プロセスを含む、請求項３９に記載のソケットサーバ。
41. 前記制御プロセスが、前記複数サーバからの前記作成されたファイルへのアクセス要求に応答するリスニング・プロセスを含む、請求項３９又は４０に記載のソケットサーバ。
42. 前記ファイル・プロセスが、ネットワーク・スタック内の層に関連付けられた状態情報を識別するプロセスを含む、請求項３９乃至４１の何れかに記載のソケットサーバ。
43. 請求項２２乃至２９の何れかの処理を実行するための命令を記憶したコンピュータ可読媒体。
44. 分化記憶クラスを提供するシステムであって、
    複数の記憶位置と、当該記憶位置を編成するための論理ブロック・ネーム空間とを備えた記憶装置と、
    記憶位置を異なる性能レベルを提供する複数領域に区分する性能プロセスと、
    前記記憶位置の前記区分した部分を、前記論理ブロック・ネーム空間の選択したセクションにマッピングするマッピング・プロセスとを含む、システム。
45. 前記性能プロセスが、前記複数の記憶位置を、異なるサービスレベルに関連付けられた複数カテゴリに分離する、請求項４４に記載のシステム。
46. 前記性能プロセスが、前記複数の記憶位置を、異なるＲＡＩＤ性能レベルに関連付けられた複数カテゴリに分離する、請求項４５に記載のシステム。
47. 前記マッピング処理が、前記論理ブロック・ネーム空間の異なる部分を、ＲＡＩＤの異なるレベルにそれぞれ関連付ける、請求項４４に記載のシステム。
48. 前記論理ブロック・ネーム空間の異なる部分間でデータを移動させる負荷バランシング移動プロセスを更に含む、請求項４４に記載のシステム。
49. 前記負荷バランシング移動プロセスが、データを記憶プール間で移動してシステム性能を向上させる適応データ配置プロセスを含む、請求項４８に記載のシステム。
50. 前記負荷バランシング移動プロセスが、管理者にデータを異なる記憶プール間で移動させる管理プロセスを含む、請求項４８に記載のシステム。
51. 前記記憶を用いてファイルシステム・サービスを提供するプロセスを更に含む、請求項４４に記載のシステム。
52. 記憶ボリューム・サービスを提供するプロセスを更に含む、請求項４４に記載のシステム。
53. 前記マッピングプロセスが、複数の記憶ボリュームを選択した性能レベルで形成する、請求項４４に記載のシステム。
54. 分化記憶クラスを提供する処理であって、
    複数の記憶位置と、当該記憶位置を編成するための論理ブロック・ネーム空間とを備えた記憶装置を提供する段階と、
    記憶位置を異なる性能レベルを提供する複数領域に区分する段階と、
    前記記憶位置の前記区分した部分を、前記論理ブロック・ネーム空間の選択したセクションにマッピングする段階とを含む、処理。
55. 前記複数の記憶位置を、異なるサービスレベルに関連付けられた複数カテゴリに分離する段階を更に含んだ、請求項５４に記載の処理。
56. 前記複数の記憶位置を、異なるＲＡＩＤ性能レベルに関連付けられた複数カテゴリに分離する段階を更に含んだ、請求項５４に記載の処理。
57. 前記マッピング処理が、前記論理ブロック・ネーム空間の異なる部分を、ＲＡＩＤの異なるレベルにそれぞれ関連付ける、請求項５４に記載の処理。
58. 前記論理ブロック・ネーム空間の異なる部分間でデータを移動させることによって負荷バランシングを行う段階を更に含む、請求項５４に記載の処理。
59. 前記負荷バランシング・プロセスが、データを記憶プール間で移動してシステム性能を向上させることを含む、請求項５８に記載の処理。
60. 前記負荷バランシングを行う段階が、管理者にデータを異なる記憶プール間で移動させる段階を含む、請求項５８に記載の処理。
61. 前記マッピング段階が、複数の記憶ボリュームを選択した性能レベルで形成する、請求項５４に記載の処理。
62. 分化記憶クラスを提供するシステムであって、
    複数の記憶位置と、当該記憶位置を編成するための論理ブロック・ネーム空間とを備えた記憶装置であって、当該装置内部で変動する前記記憶位置の性能パラメータを備えた記憶装置と、
    前記記憶位置を、性能パラメータの変動の関数として複数領域に区分するための区分プロセスとを含む、システム。
63. 前記区分プロセスが、システム要素の選択された構成の関数として固定セットの区分を選択する、請求項６２に記載のシステム。
64. 複数の区分を異なる性能レベルと関連付ける性能プロセスと、
    前記記憶位置の前記識別した部分を、前記論理ブロック・ネーム空間の選択したセクションにマッピングするマッピング・プロセスとを含む、請求項６２に記載のシステム。
    

Images