(57)【要約】  コンピュータベースシステムは、ネットワーク中で相互接続されるノードと呼ばれる幾つかのコンピュータベース設備を備えており、記憶ノードは、ダイレクトアクセスローカルメモリユニット（３８）と、キューに基づいて前記ユニットへのアクセスを管理するストレージサーバ（４６）とを有し、アプリケーションノードはそれぞれ、ローカルメモリユニット（３３）上の物理アドレスを指定するブロックのアドレスの形式でアクセス可能であるファイルの表現をもつアプリケーション環境と、ブロックアドレスを指定するアクセス要求に基づいてストレージサーバ（４６）と相互作用可能なストレージクライアント（４４）とを有している。ストレージサーバ（４６）は、決定された順序でストレージサーバのキュー（６４）に格納されているアクセス要求を実行できるスケジューラを備えている。この順序は、性能基準を形成しキューおよび／またはキューが常駐する記憶ノードの１つ以上の状態パラメータを伴う一組の規則に応じて決定される。【選択図】図３
2010507851.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク中で相互接続されるノードと呼ばれる複数のコンピュータベース設備を有し、
記憶ノードとして知られる前記ノードの少なくとも一部が、少なくとも１つのローカルダイレクトアクセスメモリユニット（３８）と、アクセス要求のキュー（６４）に基づいて前記ローカルメモリユニット（３８）へのアクセスを管理するように配置されたストレージサーバ（４６）とを有し、
アプリケーションノードとして知られる前記ノードの少なくとも一部のそれぞれが、
記憶ノードのローカルメモリユニット（３８）上に少なくとも１つの物理アドレスを指定するブロックアドレスの形式で前記ノードからアクセス可能であるファイルの表現を有するアプリケーション環境と、
ブロックアドレスを指定するアクセス要求に基づいて前記ストレージサーバ（４６）の何れか１つと相互作用可能なストレージクライアント（４４）とを備えるコンピュータベースシステムであって、
前記ストレージサーバ（４６）の少なくとも１つは、特定された順序で前記キュー（６４）に格納された前記アクセス要求を実行可能であるスケジューラを備え、前記スケジューラは、性能基準を形成し前記キューおよび／または前記キューが常駐する前記記憶ノードの１つ以上の状態パラメータを伴う一組の規則に応じてこの順序を決定するように並べられていることを特徴とするコンピュータベースシステム。
【請求項２】
前記一組の規則は前記ローカルメモリユニットの１つ以上の状態パラメータをも伴っていることを特徴とする請求項１に記載のコンピュータベースシステム。
【請求項３】
前記一組の規則は、前記キュー（６４）に存在する要求の選択に適するとともにそれぞれの要求のヘッダ（６２）の内容に基づく規則からなり、前記規則はこれらの要求と関連付けられた他のデータを欠く時に使用できることを特徴とする請求項１または２に記載のコンピュータベースシステム。
【請求項４】
前記一組の規則は、前記キュー（６４）に存在する要求を選択するのに適するとともに、問題になっている前記ストレージサーバ（４６）とこのストレージクライアント（４４）との前の相互作用に基づいて確立された量的基準に基づく規則からなることを特徴とする請求項１〜４のいずれか一項に記載のコンピュータベースシステム。
【請求項５】
前記量的基準は、前記ストレージクライアントにより問題になっている前記ストレージサーバ（４６）の前のローディングの持続時間に基づいて確立されていることを特徴とする請求項４に記載のコンピュータベースシステム。
【請求項６】
前記一組の規則は、前記キュー（６４）に存在する要求の選択に適するとともに、前記要求が前記キュー（６４）に存在していた時間の長さに基づく規則からなることを特徴とする請求項１〜５のいずれか一項に記載のコンピュータベースシステム。
【請求項７】
前記一組の規則は、前記キュー（６４）に存在する要求の選択に適するとともに、各要求によって指定された前記物理アドレスと前記ストレージサーバ（４６）によって前にアクセスされた物理アドレスとの間の距離に基づく規則からなることを特徴とする請求項１〜６のいずれか一項に記載のコンピュータベースシステム。
【請求項８】
前記ストレージサーバ（４６）の少なくとも１つは、前記性能基準に関して戦略を立てる複数の異なる組の規則のうちから選択された一組の規則に応じて決定された順序で、前記ストレージサーバのキュー（６５）に格納された前記アクセス要求を実行するように並べられていることを特徴とする請求項１〜７のいずれか一項に記載のコンピュータベースシステム。
【請求項９】
前記ストレージクライアント（４４）の少なくとも一部は、問題になっている前記ストレージクライアントによって前に送信された前記ストレージサーバ（４６）へのアクセス要求の完了前に、所定のストレージサーバにアクセス要求を選択的に送信するように許可されていることを特徴とする請求項１〜８のいずれか一項に記載のコンピュータベースシステム。
【請求項１０】
前記ストレージサーバ（４６）の少なくとも一部は幾つかのローカルメモリユニット（３８）を管理していることを特徴とする請求項１〜９のいずれか一項に記載のコンピュータベースシステム。
【請求項１１】
前記ノードの少なくとも一部はアプリケーションノードおよび記憶ノードであることを特徴とする請求項１〜１０のいずれか一項に記載のコンピュータベースシステム。
【請求項１２】
前記一組の規則は、選択された時間の間に前記キューに格納された前記要求の実行をシフトするのに適した規則からなることを特徴とする請求項１〜１１のいずれか一項に記載のコンピュータベースシステム。
【請求項１３】
前記規則は前記記憶ノードのリソースの占有レベルに基づいていることを特徴とする請求項１２に記載のコンピュータベースシステム。
【請求項１４】
前記規則は、前記キューに格納された要求の回数と、前記キューに格納された要求のタイプとからなるグループのうちから選択された基準に基づいていることを特徴とする請求項１２または１３に記載のコンピュータベースシステム。
【請求項１５】
前記規則は前のシフトから経過した時間を評価することに基づいていることを特徴とする請求項１２〜１４のいずれか一項に記載のコンピュータベースシステム。
【請求項１６】
各ブロックアドレスと、記憶ノードのローカルメモリユニット（３８）上の少なくとも１つの物理アドレスとの間の対応付けを維持可能な対応付けモジュール（３６）を備えていることを特徴とする請求項１〜１５のいずれか一項に記載のコンピュータベースシステム。
【請求項１７】
前記対応付けモジュール（３６）は、各ブロックアドレスと記憶ノードのローカルメモリユニット（３８）上の少なくとも１つの物理アドレスとの間の対応付けを有する対応テーブル（４２）と、所定の要求に対して少なくとも１つの物理アドレスを定義するように指定されたモータ（４０）とを備え、前記定義は、ブロックアドレスを使って前記対応テーブル（４２）に応答させるとともに、前記所定の要求を実行するために問題になっている前記ストレージクライアント（４４）に対して決定された前記１つまたは複数の物理アドレスを有する前記所定の要求を送信することにより行なわれることを特徴とする請求項１６に記載のコンピュータベースシステム。
【請求項１８】
ノードとして知られる複数の相互接続されたコンピュータベース設備を有するネットワーク中で使用可能であり、
ａ．仮想アドレスの形式での表現に基づいて前記ネットワークのアプリケーションノードからファイル要求を送信するステップと、
ｂ．各仮想アドレスと、前記ネットワークの記憶ノードのローカルメモリユニット（３８）上の少なくとも１つの物理アドレスとの間の対応付けに基づいて、前記仮想アドレスに対応する少なくとも１つの物理アドレスを決定するステップと、
ｃ．前記物理アドレスを指定するアクセス要求を、前記物理アドレスと関連付けられた前記ローカルメモリユニット（３８）へのアクセスを管理するストレージサーバ（４６）に対してストレージクライアント（４４）から送信するステップとを有するデータ管理方法であって、
ｄ．前記アクセス要求を前記ストレージサーバ（４６）内のキュー（６４）に入れ、性能基準を形成し前記キューおよび／または前記キューが常駐する前記記憶ノードの１つ以上の状態パラメータを伴う一組の規則に応じて決定された順序で、前記キュー（６４）に格納された前記アクセス要求を実行するステップをさらに備えていることを特徴とする方法。
【請求項１９】
前記一組の規則は前記ローカルメモリユニットの１つ以上の状態パラメータをも伴っていることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記一組の規則は、前記キュー（６４）に存在する要求の選択に適するとともに各要求のヘッダ（６２）の内容に基づく規則からなり、その規則は、前記要求と関連付けられた他のデータを欠く時に有効になることを特徴とする請求項１８または１９に記載の方法。
【請求項２１】
前記一組の規則は、前記キュー（６４）に存在する要求の選択に適するとともに、問題になる前記ストレージサーバ（４６）と各要求を発行する前記ストレージクライアント（４４）との前の相互作用に基づいて確立された量的基準に基づく規則からなることを特徴とする請求項１８〜２０のいずれか一項に記載の方法。
【請求項２２】
前記量的基準は、前記ストレージクライアントによって、問題になっている前記ストレージサーバ（４６）の前のローディングの持続時間に基づいて確立されていることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記一組の規則は、選択された時間の間に前記キュー（６４）内に存在する要求を選択するのに適した規則からなることを特徴とする請求項１８〜２２のいずれか一項に記載の方法。
【請求項２４】
前記一組の規則は、前記キュー（６４）に存在する要求の選択に適するとともに、各要求によって指定された前記物理アドレスと前記ストレージサーバ（４６）によって前にアクセスされた物理アドレスとの間の距離に基づく規則からなることを特徴とする請求項１８〜２３のいずれか一項に記載の方法。
【請求項２５】
前記一組の規則は、前記性能基準に関して戦略を立てる複数の異なる組の規則のうちから選択された複数の規則からなることを特徴とする請求項１８〜２４のいずれか一項に記載の方法。
【請求項２６】
問題になっているアクセス要求送信者（４４）によって予め送信された、ストレージサーバ（４６）へのアクセス要求のためのステップｄの完了前に、ステップｃは別の物理アドレスを使って同じアクセス要求送信者（４４）によって再現可能であることを特徴とする請求項１６〜２３のいずれか一項に記載の方法。
【請求項２７】
前記ストレージサーバ（４６）の少なくとも一部はそれぞれのアクセス要求送信者（４４）毎にキュー（６４）を備えていることを特徴とする請求項１８〜２６のいずれか一項に記載の方法。
【請求項２８】
前記ストレージサーバ（４６）の少なくとも一部は複数のローカルメモリユニット（３８）へのアクセスを管理することを特徴とする請求項１８〜２７のいずれか一項に記載の方法。
【請求項２９】
前記一組の規則は、選択された時間の間に前記キューに格納された前記要求の実行をシフトするのに適した規則からなることを特徴とする請求項１８〜２８のいずれか一項に記載の方法。
【請求項３０】
前記規則は前記記憶ノードのリソースの占有レベルに基づいていることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記規則は、前記キューに格納された要求の回数と前記キューに格納された要求のタイプとからなるグループのうちから選択された基準に基づいていることを特徴とする請求項２９または３０に記載の方法。
【請求項３２】
前記規則は前のシフトから経過した時間を評価することに基づいていることを特徴とする請求項２９〜３１のいずれか一項に記載の方法。
【請求項３３】
コンピュータベース装置であって、
請求項１８〜３２のいずれか一項に記載の方法のステップｄを実行するように並べられた記憶ノードを形成することを特徴とするコンピュータベース装置。
【請求項３４】
コンピュータプログラム生成物であって、
コンピュータ上で作動される時に、請求項１８〜３３のいずれか一項に記載の方法を行なうように適合された手段をコード化するプログラムを備えていることを特徴とするコンピュータプログラム生成物。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク中で相互接続されるノードとして知られている幾つかのコンピュータ設備またはステーションを備えるコンピュータベースシステムに関する。
【背景技術】
【０００２】
現代のネットワークは、１つ以上のサーバに接続されローカルまたはリモートにアプリケーションおよび／またはストレージスペースを共有可能であるユーザステーションを備える。
【０００３】
大量のデータを利用する共有アプリケーションの範囲内では、または、大量のデータの共有の範囲内では、ストレージエリアネットワーク（すなわちＳＡＮ）のような特殊化されたストレージシステムを使用することが普通である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
これらの改良型のシステムの使用には、関連するコスト、性能、拡張性制限のような、および、それらの改良型のシステムに対応する設備の一般的な取り扱い難さのようなある種の欠点がある。
【０００５】
さらに、現代の研究によれば、これらの改良型のシステムの使用には、ネットワーク中に既に存在している機器の不十分な利用が現れている。
【０００６】
発明はこの状況を改善することを目指している。
【課題を解決するための手段】
【０００７】
この目的を達成するために、本発明は、ネットワーク中で相互接続されているノードと呼ばれる複数のコンピュータベース設備を備えるコンピュータベースシステムを提案する。記憶ノードとして知られるノードの少なくとも一部は、少なくとも１つのローカルダイレクトアクセスメモリユニットと、アクセス要求のキューに基づいて前記ローカルメモリユニットへのアクセスを管理するように並べられたストレージサーバとを備えている。
【０００８】
アプリケーションノードとして知られるノードの少なくとも一部はアプリケーション環境とストレージクライアントとをそれぞれ備えており、
前記アプリケーション環境は、仮想アドレスの形式でこのノードからアクセス可能であるファイルの表現を維持するように並べられたファイルシステムマネージャと、各仮想アドレスと記憶モードのローカルメモリユニット上の少なくとも１つの物理アドレスとの間の対応付けを維持可能である対応付けモジュールとを設けられており、
前記ストレージクライアントは、物理アドレスを指定するアクセス要求に基づいて何れか１つのストレージサーバと相互作用可能である。
【０００９】
このコンピュータベースシステムでは、ストレージサーバの少なくとも１つは、特定された順序でストレージサーバのキューに格納されたアクセス要求を実行可能であるスケジューラを備え、そのスケジューラは、性能基準を形成しキューおよび／またはキューが常駐する記憶ノードの１つ以上の状態パラメータを伴う一組の規則に応じてこの順序を決定するように並べられている。
【００１０】
この種のコンピュータベースシステムは、データを効率的に記憶するためにネットワークの（ノードとも称される）ステーションの固有のストレージリソースを使用する利点を有する。これらのステーションでは、ストレージサーバを使ってネットワークおよびストレージリソースの使用を最適化してもよい。したがって、このシステムによって、特殊化されたシステムを必要とせずネットワークの固有の能力を最大限に利用することが可能になる。
【００１１】
また、発明は、ノードとして知られる複数の相互接続されたコンピュータベース設備を有するネットワーク中で使用され得るデータ管理方法に関し、その方法は、
ａ．仮想アドレスの形式での表現に基づいてネットワークのアプリケーションノードからファイル要求を送信するステップと、
ｂ．各仮想アドレスとネットワークの記憶ノードのローカルメモリユニット上の少なくとも１つの物理アドレスとの間の対応付けに基づいて前記仮想アドレスに対応する少なくとも１つの物理アドレスを決定するステップと、
ｃ．前記物理アドレスを指定するアクセス要求を記憶ノードのローカルメモリユニットへのアクセスを管理するストレージサーバに送信するステップと、
ｄ．アクセス要求を前記ストレージサーバ内のキューに入れ、性能基準を形成し１つまたは複数のローカルメモリユニット、および／または、問題になっている記憶ノードの１つ以上の状態パラメータ（プロセッサ負荷、中央メモリの占有レベルなど）を伴う一組の規則に応じて決定された順序で、前記キューに格納されたアクセス要求を実行するステップとを備えている。
【００１２】
発明のさらなる利点および特徴は、以下の図面に基づいて限定せずに例示として提供される幾つかの実施の形態に続く記述の検討から明らかになる。
【図面の簡単な説明】
【００１３】
【図１】発明によるコンピュータベースシステムの概略的な機能図を示す。
【図２】図１におけるシステムの論理実装の例を示す。
【図３】図２からの要素の構成例を示す。
【図４】図１におけるシステム内のファイルへのアクセス方法を示す。
【図５】図４におけるプロセスの一部の機能実装の例を示す。
【図６】図５の実装の範囲内でストレージサーバのスケジューリング実行ループの例を示す。
【図７】図６における機能の例を示す。
【図８】図６における機能の例を示す。
【図９】図６における機能の例を示す。
【図１０】図６における機能の例を示す。
【図１１】代替的な実施の形態におけるストレージサーバのスケジューリング実行ループの例を示す。
【図１２】図１１からの機能の例を示す。
【図１３】図１２からの機能の例を示す。
【図１４】図１２からの機能の例を示す。
【図１５】図１２からの機能の例を示す。
【発明を実施するための形態】
【００１４】
以下の図面および説明はある特定の性質をもつ要素を本質的に含んでいる。これらの要素は、本発明の理解を助けるために役立つだけでなく、場合によっては本発明を定義するためにも役立っている。
【００１５】
本発明は著作権保護に適格な要素を行使するものである。権利の所有者は、公文書に現れるような、本特許文献または本特許明細書の何れによる同一の複製に対しても異議を唱えない。その他については、著作者は自分の権利を完全に留保している。
【００１６】
図１は発明によるコンピュータベースシステムの概略的な構想を示している。本システムでは、アプリケーション環境２はファイルシステムマネージャ４にアクセスする。仮想化層６はファイルシステムマネージャ４とストレージサーバ８との間で対応付け（通信）を確立する。
【００１７】
図２は図１におけるシステムの論理的な実装を示している。この実装では、本明細書中でノードとも呼ばれる一組のステーション１０は、それらのステーションが物理リソースおよびアプリケーションリソースを形成するネットワーク中で相互接続されている。
【００１８】
ここで説明されている例では、ネットワークは、Ｎｉでラベル付けされた５つのステーションで構成され、ｉは１〜５の間で変化する。アプリケーション環境２は、Ｎ１、Ｎ２およびＮ３に渡って分布されたアプリケーション層１２と、Ｎ４に渡って分布されたアプリケーション層１４と、Ｎ５に渡って分布されたアプリケーション層１６とから構成されている。
【００１９】
ここで使用される設備またはステーションという用語は、アプリケーション、サーバプログラム、または、両方が動作するネットワークでのコンピュータベース要素に一般的に言及されるように解釈されるべきであることに留意されたい。ファイルシステムマネージャ４は、分散型ファイルシステム１８と、２つの非分散型ファイルシステム２０、２２とから構成されている。システム１８は、Ｎ１、Ｎ２、Ｎ３に渡って分布され、分散型アプリケーション層１２からアクセスされ得るすべてのファイルを定義している。ファイルシステム２０、２２はそれぞれアプリケーション層１４、１６からアクセスされ得るすべてのファイルを定義している。
【００２０】
ファイルシステム１８、２０、２２によって指定されたファイルは、すべてのＮｉに渡って分布された仮想記憶空間２４に物理的に格納（記憶）され、ｉは１〜５の間で変化する。ここでは、仮想記憶空間２４は、共有論理空間２６と、２つの非公開（プライベート）論理空間２８、３０とに分割されている。
【００２１】
共有論理空間２６は、分散型ファイルシステム１８を用いて分散型アプリケーション層１２からアクセス可能である空間に対応し、非公開論理空間２８、３０は、ファイルシステム２０、２２を用いてアプリケーション層１４、１６からアクセス可能である空間に対応している。
【００２２】
論理空間２６はＮ１、Ｎ２、Ｎ３に渡って分布し、非公開論理空間２８はＮ３、Ｎ４に渡って分布し、非公開論理空間３０はＮ５に渡って分布している。
【００２３】
したがって、層１２（または層１４または層１６のそれぞれ）のアプリケーションは、データがこのアプリケーションを使用するステーション１０の記憶ディスクのうちの１つに必ずしも物理的に存在していなくても、ファイルシステム１８（またはファイルシステム２０またはファイルシステム２２のそれぞれ）を用いて論理空間２６（または論理空間１８または論理空間３０のそれぞれ）に記憶されているデータを「確認」している（「見」ている）。
【００２４】
その上、空間２６、２８、３０は純粋に論理的であり、すなわち、その空間は物理記憶空間を直接的に表さない。論理空間は、ファイルシステム１８、２０、２２内で言及または格納された仮想アドレスを用いて写像（マップ）される。
【００２５】
これらのファイル中のデータにアクセスするため、対応付けジュールを使用することが必要である。対応付けモジュールは、論理空間内のデータの仮想アドレスと、これらのデータが実際に記憶されている物理記憶空間を指定する物理アドレスとの間に対応テーブルを格納している。
【００２６】
様々な実施の形態が対応付けモジュール用に可能である。ここで記述された物理記憶空間の分散は、発明のまさに一般的な範囲を示すように意図された例である。
【００２７】
示された例から分かるように、各ステーションは、アプリケーション層とストレージ層の両方のため使用されている。この多機能性によって、この空間を未占有のままにしておくことよりもむしろネットワークのすべてのステーションに渡って自由空間を使用することが可能になる。
【００２８】
しかしながら、発明の範囲内では、ステーションの一部を特殊化すること、および、ストレージ専用ノードまたはアプリケーション専用ノードを作成することが可能である。
【００２９】
これが意味していることは、発明の範囲内では、何らかのステーションがアプリケーションノード、記憶ノードとして機能するかもしれないし、または、両方の役割を同時に実行するかもしれないことである。
【００３０】
アプリケーションリソース、ストレージリソース、およびファイルシステムリソースのすべてが、各ステーションにローカルに一体化されているかもしれないし、または、ネットワークのステーションに渡って分布されているかもしれない。
【００３１】
これは、たとえば、ステーションＮ１、Ｎ２、Ｎ３のリソースがアプリケーションレベルと、ファイルシステムおよびストレージレベルとの両方で一体的に分布されている場合に当てはまる。
【００３２】
図３は、図２におけるステーション１０のアーキテクチャの例を示している。この例で示されたステーションは、ステーションＮ１、Ｎ２、Ｎ３のうちの１つを表している。
【００３３】
ステーションＮｘは、個々に、図１に示されたグローバル構造のものと類似した構造を有する。したがって、そのステーションは、ダイレクトアクセスローカルメモリの形式で、アプリケーション層３２と、ファイルシステム３４と、仮想化層３６と、記憶空間３８とを備えている。
【００３４】
仮想化層３６は、モータ４０および対応テーブル４２を備えている。記憶空間３８へのダイレクトアクセスは、ストレージクライアント４４およびストレージサーバ４６によって管理されている。これらの要素の役割および動作方法は以下に記載される。
【００３５】
ここに記載された例は、すべてのリソース、すなわち、アプリケーションおよびストレージの両方がネットワーク上で分布されている発明の改良された実施の形態を示している。
【００３６】
これが意味することは、たとえば、ファイルシステム３４が全体としてステーションに存在するのではなく幾つかのステーションに渡って分布されていること、および、ファイルシステムへのアクセスが所望のデータを格納したネットワークの他のノードとの対応付けを伴っていることである。
【００３７】
同じことが、仮想化層３６、ストレージクライアント４４、ストレージサーバ４６についても言える。これらの要素の分散はアドミニストレーション（管理）モジュール４８を用いて管理されている。
【００３８】
アドミニストレーションモジュール４８は、主に、論理空間を作成更新するときに使用される。論理空間の作成または変更中に、アドミニストレーションモジュール４８は、論理空間の各仮想アドレスと所定の記憶ノード上の物理アドレスとの間に対応テーブルを作成するために仮想化層３６を呼び出す。
【００３９】
次に、このファイルのシステムを介してアクセスされ得るファイルと、当該ファイルを構成するデータの仮想アドレスとの間での対応付けが、この論理空間を利用するファイルシステムのレベルで確立され、「物理」データは、論理空間が作成された時に描かれるマッピングに従って、仮想アドレスとともに対応テーブルに関連付けられる物理アドレスに記憶される。
【００４０】
これが意味することは、論理空間がアドミニストレーションモジュールによって作成されると直ぐに、仮想アドレスと物理アドレスとの間の対応付けが生成されることである。このように、仮想アドレスは論理空間にアクセスするファイルシステム内で「空（エンプティ）」であるように見えるのに対し、仮想アドレスに対応する物理アドレスは対応テーブルによって既に「確保（リザーブ）」されている。
【００４１】
この空間におけるファイル内のデータとこれらのデータの仮想アドレスとの間のリンクが確立された時に始めて、物理アドレスが充填される。
【００４２】
仮想化層によって行われる作業は様々な方法で実行されることがある。一つの実施の形態では、仮想化層は、異質ストレージリソースに渡ってデータを分布させて、ネットワーク中のストレージリソースのフローを利用（開発）することと、これらのリソースの記憶容量を利用することとの間で最良の折衷案を見出している。この仮想化層の例は、欧州特許第１４５４２６９Ｂ１号明細書の段落［００４６］から［００６２］に記載されている。
【００４３】
仮想化層３６もまた被書込みデータを保護するためのメカニズムを組み込むかもしれない。このメカニズムは、たとえば、ＲＡＩＤの方式で、別個のステーションに位置している物理記憶空間にある物理アドレスを持つ各書込み要求（リクエスト）の選択的な重複に基づいているかもしれない。
【００４４】
対応テーブル４２は必ずしも単純なテーブルではない。対応テーブルは、特に、対応テーブルが対応付けを保持する１つまたは複数の論理空間に関連するコンフィギュレーションデータを格納していることがある。この場合、対応テーブルは、ネットワーク中のストレージリソースのフローの利用とこれらのリソースの記憶容量の利用との間の最良の折衷案を確保するために、特に、仮想アドレスと物理アドレスとの間の対応付けの分布を更新する仮想化層３６のメカニズムと相互作用することがある。これらのメカニズムの１つの実施の形態は、欧州特許第１４５４２６９Ｂ１号明細書の段落［００６３］から［００７５］に記載されている。明細書の残りの部分の全体に亘って、検討中のリソースが分布されているかどうかは問題でない。
【００４５】
発明の理解を助けるため、アプリケーション層とストレージ層を区別することが望ましい。実際に、ストレージ層に記憶されたデータへのアクセスの管理は、既存の方法より多数の利点を有するアプローチである。
【００４６】
図４はファイルにアクセスするシステムによって実行されるプロセスを示している。
【００４７】
所定のノードのアプリケーション層のアプリケーションによるファイルへのアクセスはファイルアクセス要求５０によって開始される。ファイルアクセス要求５０は、
ファイルシステムに対して問題となっているファイルの識別子と、このファイル中のアドレスと、
要求のサイズ、すなわち、対象とするファイルのアドレスに続けてアクセスすべきビット数と、
要求のタイプ、すなわち、リード（読出し）またはライト（書込み）と、
を備える。
【００４８】
ステップ５２において、ファイルシステムは、このファイル中のデータに対して１つ以上の仮想アドレスを決定し、要求５０とこれらの仮想アドレスとに基づいて１つ以上の仮想アクセス要求を発生させる。
【００４９】
仮想アクセス要求はそれぞれ、
所望の仮想アドレスと、
要求のサイズ、すなわち、対象とされる仮想アドレスの後にアクセスすべきビット数と、
要求５０のタイプと同一である要求のタイプと、
を備える。
【００５０】
今度は、図２に記載されているシステムを参照すると、ステップ５２は、論理空間と、要求５０によって指定されたこの空間での１つまたは複数の仮想アドレスとを決定すること、および、１つ以上の「仮想」要求を生成することにある。
【００５１】
ファイルアクセス要求と仮想アクセス要求との間にレベルの差が存在する。実際には、ファイルアクセス要求は、１つのファイルの内容を再構成することを可能にするため、仮想アドレスの実質的な量の内容を対象とするのに対し、仮想要求はこのアドレスと関連付けられたデータのブロックの内容を目標とする。
【００５２】
取得された１つまたは複数の仮想アクセス要求はその後に仮想化層へ送信され、ステップ５４において１つまたは複数の物理アドレスと、対応する記憶空間とを決定する。
【００５３】
物理アドレスを決定するために、仮想化層は、モータ４０および対応テーブル４２を使用することによって動作する。
【００５４】
リードアクセス要求の範囲内で、所望のファイルは記憶空間３８に既に存在し、モータ４０は、ファイル中の１つまたは複数のデータの物理アドレスを対応付けにより決定するために、１つまたは複数の仮想アドレスを用いて対応テーブル４２を呼び出す。
【００５５】
ライトアクセス要求の範囲内で、ファイルは必ずしも記憶空間３８に予め存在しない。それにもかかわらず、ここまでに理解されているように、仮想アドレスと物理アドレスとの間の対応付けは一定であり、それから、モータ４０は、リード要求の範囲内と同様に動作して、データの１つまたは複数の物理アドレスを決定する。
【００５６】
いずれの場合も、ひとたびモータ４０が物理アドレスを決定すると、モータは、ステップ５６において、物理アクセス要求を発生させ、その物理アクセス要求をモータがストレージクライアント４４へ送信する。
【００５７】
ステップ５６において、物理アクセス要求は、要求５０と、ステップ５４において決定される１つまたは複数の物理アドレスとに基づいて発生される。
【００５８】
これらの要求は、
目標とされる物理アドレスと、
要求のサイズ、すなわち、要求によって目標とされる物理アドレスに続いてアクセスすべきビット数と、
対象とされるアクション（作用）のタイプ、すなわち、リードまたはライトと、
を備える。
【００５９】
物理アドレスと要求のサイズとはステップ５４から直接的に取得され、要求のタイプは問題となっている仮想アクセス要求のタイプから引き継がれる。
【００６０】
それから、ステップ５２で取得されたすべての物理アドレスのために物理アクセス要求をストレージクライアント４４に送信したときに停止条件５８に達するループが始められる。
【００６１】
実際には、各物理アクセス要求はステップ６０において実行用のストレージクライアント４４の要求キューに入れられる。ストレージクライアント４４は任意に多数のキューを、たとえば、ストレージクライアントが相互作用するそれぞれのストレージサーバ４６毎にキューを備えることがある。
【００６２】
このループでは、ステップ５６のすべての物理アクセス要求は、簡単にするために、順次に実行されるものとして示されている。しかしながら、実行は並列に行われてもよく、直列だけで行なわれなくてもよい。
【００６３】
記載されている例では、要求が物理アクセス層に到達するまで、要求が層から層へ送信される。しかしながら、アドレス（仮想アドレスおよびその後に物理アドレス）だけを決定し送信し、物理層のレベルで初期ファイル要求の選択特性を回復（リカバー）して物理アクセス要求を形成することが可能である。
【００６４】
所定の物理アクセス要求を実行するために、ストレージクライアント４４は記憶空間３８を収容するストレージステーションのストレージサーバ４６と相互作用し、その記憶空間３８には問題となっている物理アクセス要求によって指定された物理アドレスが位置付けられている。この相互作用は図５を用いて説明される。
【００６５】
図５から分かるように、ストレージクライアント４４による物理アクセス要求の実行は、最初に、問題となっているストレージサーバ４６によって物理アクセス要求の受信を備えている。この受信は、ここでは、目標とされる要求のタイプ、この要求のサイズ、および、物理アドレスをストレージサーバ４６に知らせるヘッダ６２の送信の形式を取っている。
【００６６】
それから、ヘッダを介して要求は、ストレージサーバ４６内のキュー６４に記憶される。キュー６４は、未だに実行されていないが、問題となっているストレージサーバ４６に対して全てのストレージクライアント４４により送信されている全てのアクセス要求と、それらの実行状態とを格納している。
【００６７】
ストレージサーバ４６は、多数のキュー６４を、たとえば、ネットワーク中のそれぞれのストレージクライアント４４毎に１つのキューを備え、または、ストレージサーバ４６がアクセスを管理するそれぞれの記憶空間毎に１つのキューを備え、または、後述されるスケジューリング戦略を実施するために適した他の構成を備えることがある。
【００６８】
このようにして、ストレージサーバ４６は、カスケードにおいて、１つ以上のストレージクライアントから大量の要求を受信することがあり、ストレージサーバが実行されるステーションと、ストレージサーバが管理するディスクの充満レベルと、一般にネットワークの充満レベルとを占有するために最も好ましい順序で、それらの要求を実行できる。
【００６９】
既知の構成では、ストレージクライアントとストレージサーバとの関係は「クライアント指向」と呼ばれる。このタイプの関係では、ストレージクライアント４４からの要求のキューが広がり、サーバが前の要求に応答した時にクライアントは新しいアクセス要求をサーバに送信するように許可されるだけである。
【００７０】
ここに記載されているアーキテクチャは、記憶空間へのアクセスの管理について「サーバ指向」を構成している。このように、既知の構成と対照的に、所定のストレージクライアント４４は、ストレージサーバがストレージクライアント４４に前に送信された要求の結果を最初に返信することを必要とせずに、多数のアクセス要求を同じストレージサーバ４６に送信可能である。これにより、入力／出力アクセスに負荷されるディスクおよびネットワークのより良好なバランスを実現することが可能になり、特に有利である。
【００７１】
要求をストレージサーバのキュー６４に受信するのと並行して、ストレージサーバがキューに受信された要求をスケジュールして実行するループにおいて、ストレージサーバ４６はステップ６６を実行する。したがって、ヘッダ６２に対応する要求は、ストレージサーバによって決定された順序で、このループにおいて処理される。
【００７２】
ステップ６６では、プロセッサ負荷、ステーションの中央メモリの充満レベルなどのようなパラメータを考慮して、サーバがアクセスを管理する記憶空間の利用と、サーバが実行されるステーションの利用とをローカルに最適化するために、サーバはキュー６４での要求のスケジューリングを実行する。
【００７３】
ステップ６６で行われるスケジューリングおよび実行は図６を用いて説明される。
【００７４】
所定の時点で、ストレージサーバ４６は、ストレージサーバのキューの中に、様々な状態であり得る一組の要求を有している。これらの状態は、たとえば、（要求がキューにちょうど受信されたときの）「未処理」、（ストレージサーバ４６が、要求を実行するために必要とされるすべてのデータを有し、その後になって要求の実行をプログラムしたときの）「実行待ち」、または、「実行中」である。
【００７５】
これらの要求は少なくとも２つの別の種類であるようにも見える。第１の種類は「ネットワーク」と呼ばれ、ストレージサーバ４６と所定のストレージクライアント４４との間で起こらなければならない交換を意味する。他方の種類は「ディスク」と呼ばれ、データを読み取るまたは書き込むためにストレージサーバが管理する記憶空間のうちの１つでストレージサーバ４６が行なわれなければならないアクセスを意味する。
【００７６】
ステップ６６のスケジューリングは、処理負荷、ステーションの中央メモリの充満レベルなどのようなパラメータを考慮して、これらの要求の性質および要求の状態と、システムのネットワークの状態パラメータおよびストレージサーバ４６によって管理される記憶空間の状態パラメータと、要求が実行されるステーションの用途とに基づいて実行される。
【００７７】
ステップ６６は、ストレージサーバが複数のデータストレージディスクを管理する場合に関連して説明されている。その結果、ループに関して全体的な性質をもつ様々な要素はテーブルであり、出来るだけ多次元のテーブルである。
【００７８】
したがって、テーブルはＬａｓｔ＿Ｓｅｃｔとして使用かつ知られ、そのＬａｓｔ＿Ｓｅｃｔは単一の行からなり、その各列はこの列に対応するディスクのためにアクセスされた最後のセクタを意味している。
【００７９】
同様に、行列Ｔｍ＿Ｕｓｅｄが使用され、行列Ｔｍ＿Ｕｓｅｄではその行はそれぞれストレージクライアントを意味し、その列はそれぞれディスクを意味し、行ｘと列ｙとの交点の要素の値はクライアントｘによって出された要求に対してディスクｙの占有時間を表現する。
【００８０】
ステップ６６のループはデータ７０を処理する。データ７０は要求リストＦｉｌｅおよび要求リストＬｉｓｔ＿Ｒｅｑを格納している。要求リストＦｉｌｅは、状態「未処理」を有する一組の要求、すなわち、その時点でストレージサーバの１つまたは複数のキューに受信される要求を格納している。
【００８１】
Ｌｉｓｔ＿Ｒｅｑとして知られているリストは、「実行待ち」または「実行中」という状態をもつ一組の要求を格納している。これらの要求はそれぞれエイジインジケータによって伴われている。要求のエイジインジケータは、この要求がリストＬｉｓｔ＿Ｒｅｑに追加された後から完了されたループの回数を示している。
【００８２】
ステップ７２において、ストレージサーバは、引数として、リストＦｉｌｅおよびＬｉｓｔ＿Ｒｅｑとともに関数Ｉｎｉｔ（）を呼び出す。関数Ｉｎｉｔ（）は図７を参照してより詳細に記載される。
【００８３】
関数Ｉｎｉｔ（）は、ステップ７００から開始し、ステップ７０２において引数としてリストＦｉｌｅおよびＬｉｓｔ＿Ｒｅｑを有する関数Ａｄｄ＿Ｎｅｗ＿Ｒｅｑ（）を呼び出すのを開始する。関数Ａｄｄ＿Ｎｅｗ＿Ｒｅｑ（）は、リストＦｉｌｅからすべての新しい要求を取り出し、それらをリストＬｉｓｔ＿Ｒｅｑに追加する役割を持っている。リストＬｉｓｔ＿Ｒｅｑにおいて、新しい要求のエイジインジケータは、関数Ａｄｄ＿Ｎｅｗ＿Ｒｅｑ（）によって０（ゼロ）にリセットされる。
【００８４】
ステップ７０２は、システムの機能を最適化するために、ストレージサーバの占有に関連する二重条件により従わされている。第１の条件はステップ７０４でテストされ、そのステップ７０４では待機インジケータＳｔａｔ＿Ｗｔがテストされる。
【００８５】
インジケータＳｔａｔ＿Ｗｔが０（ゼロ）に等しいとき、これが意味することは前のループ以降に待ちが何ら存在しなかったことである。逆に、前のループ中の待ちは１に等しいインジケータＳｔａｔ＿Ｗｔによって示される。
【００８６】
第２の条件はステップ７０６でテストされ、そのステップ７０６ではリストＦｉｌｅ中に３つ以上の要求が存在することをストレージサーバが検証している。
【００８７】
これらの条件のうちの一方が満たされない場合には、すなわち、前のループの間に待ちが存在していた場合、または、リストＦｉｌｅ中に３つ以上の要求が存在する場合には、関数Ｉｎｉｔ（）はステップ７０８において行なわれ、そのステップ７０８ではインジケータＳｔａｔ＿Ｗｔが次のループに対して０（ゼロ）にセットされる。
【００８８】
次に、ステップ７１０では、リストＬｉｓｔ＿Ｒｅｑが空であるかどうかをストレージサーバはチェックする。空でない場合、関数Ｉｎｉｔ（）はステップ７１２で終了し、スケジューリングループは、リストＬｉｓｔ＿Ｒｅｑ中の要求を処理するために継続できる。
【００８９】
リストＬｉｓｔ＿Ｒｅｑが空である場合、スケジューリングループを継続する必要がなく、ストレージサーバはステップ７１４において関数Ｗａｉｔ（１）によって１ミリ秒間待機し、その後、次のループに対してインジケータＳｔａｔ＿Ｗｔを１にセットし、ステップ７０２に戻ってストレージサーバの１つまたは複数のキューによって受信された新しい要求を回復する。
【００９０】
関数Ｉｎｉｔ（）の後に、ストレージサーバはステップ７６において関数Ｒｕｎ＿Ｏｌｄ（）を呼び出す。この関数の目的は、非常に大きいエイジインジケータを有するＬｉｓｔ＿Ｒｅｑの要求を実行することである。
【００９１】
関数Ｒｕｎ＿Ｏｌｄ（）は、図８を用いて記載され、旧い要求が実行される場合には１に等しいインジケータＲｓｔを返し、そうでない場合には０（ゼロ）に等しいインジケータを返す。
【００９２】
開始ステップ８００の後に、ストレージサーバはステップ８０２において関数Ｍａｘ＿Ａｇｅ（）を呼び出す。関数Ｍａｘ＿Ａｇｅ（）は、引数として、リストＬｉｓｔ＿Ｒｅｑを取り、Ｌｉｓｔ＿Ｒｅｑ中の要求から最大のエイジインジケータを返す。
【００９３】
このエイジインジケータが１５０より大きい場合、ステップ８０４においてストレージサーバは引数としてリストＬｉｓｔ＿Ｒｅｑおよび数１２０を取る関数Ａｇｅ（）を呼び出す。関数Ａｇｅ（）は、１２０より大きいエイジインジケータを有するＬｉｓｔ＿Ｒｅｑ中の一組の要求を決定する。これらの要求は要求リストＬｉｓｔ＿Ｏｌｄ中に記憶される。
【００９４】
次に、ステップ８０６において、ストレージサーバは、引数としてのリストＬｉｓｔ＿ＯｌｄおよびテーブルＬａｓｔ＿Ｓｅｃｔを持つ関数Ｒｅｑ＿Ｍｉｎ＿Ｓｅｃｔ（）を呼び出す。関数Ｒｅｇ＿Ｍｉｎ＿Ｓｅｃｔ（）によって、最近アクセスされた最後のセクタに最も近い要求アクセスセクタを有する要求がリストＬｉｓｔ＿Ｏｌｄの中でどれかを決定することが可能になる。
【００９５】
これは、Ｌｉｓｔ＿Ｏｌｄ中に格納されている要求毎に、目標とされるディスクセクタと、Ｌａｓｔ＿Ｓｅｃｔに格納されているようにこのディスク上でアクセスされた最後のセクタとの間の距離の絶対値を計算することにより行われる。ひとたび最小値が決定されると、対応する要求が要求Ｒｅｑに格納される。
【００９６】
次に、ストレージサーバは、ステップ８０８において、関数Ｅｘｅｃ（）の引数として要求Ｒｅｑを呼び出すことにより要求Ｒｅｑを実行する。関数Ｅｘｅｃ（）は、要求Ｒｅｑを実行し、要求の実行時間を測定し、この実行時間を数Ｔ＿ｅｘに格納する。
【００９７】
要求の実行は図９を用いて記載される。この実行は、キュー６４中のヘッダに格納された物理アドレス・サイズ・タイプの要求９００からなるトリプレットに基づいている。
【００９８】
ステップ９０２において、要求のタイプに関するテストは、実行されるべきディスクおよびネットワーク入力／出力の連鎖（チェイン）を決定する。
【００９９】
要求のタイプがライト要求である場合、ストレージサーバはストレージクライアントに依頼してステップ９０４でライトデータをストレージサーバへ送信するようにする。ストレージサーバはそのデータを待ち、そのデータを受信すると直ぐにステップ９０６においてそのデータを物理アドレスによって指定された空間に入力する。
【０１００】
それから、ストレージサーバ４６は、ライトレシート９０８をストレージクライアント４４へ送信してその書込みを確認する。この後、実行はステップ９１４で完了される。
【０１０１】
要求がリード要求である場合、ストレージサーバ４６は、ステップ９１０において、要求のサイズに達するまで物理アドレスにより指定された空間に格納されたデータにアクセスし、ステップ９１２においてこれらのデータをストレージクライアント４４へ送信する。この後、実行はステップ９１４で完了される。
【０１０２】
ひとたび要求Ｒｅｑが実行されると、ストレージサーバはステップ８１０においてＬｉｓｔ＿Ｒｅｑを更新する。この更新は、引数としてのリストＬｉｓｔ＿Ｒｅｑおよび数Ｔ＿ｅｘを持つ関数Ｕｐｄ（）を呼び出すことによって行われる。
【０１０３】
この関数は、リストＬｉｓｔ＿ＲｅｑおよびＬｉｓｔ＿Ｏｌｄから要求Ｒｅｑを引き出し、行列Ｔｍ＿Ｕｓｅｄを更新し、要求Ｒｅｑを送信したストレージクライアント４４に対応する行と、要求Ｒｅｑによって目標とされたディスクに対応する列との交点にある要素に数Ｔ＿ｅｘを加算する。これにより、各ストレージクライアントによる各ディスクの占有を最新の状態に保つことを可能にする。最後に、テーブルＬａｓｔ＿Ｓｅｃｔは、実際にアクセスされた最後のセクタを考慮するために、要求Ｒｅｑによってアクセスされたディスクの列の中で更新される。
【０１０４】
それから、ストレージサーバ４６は、ステップ８１２において、リストＬｉｓｔ＿Ｏｌｄが空であるかどうかをチェックする。空である場合、インジケータＲｓｔはステップ８１４において１にセットされて「旧い」要求が実行されていることを示すようにし、関数Ｒｕｎ＿Ｏｌｄ（）はステップ８１６において完了される。空でない場合、関数Ｒｕｎ＿Ｏｌｄ（）はステップ８０６に戻って残りの他の旧い要求を実行するようにする。
【０１０５】
関数Ｍａｘ＿Ａｇｅ（）が１５０より小さいエイジインジケータを返す場合、インジケータＲｓｔはステップ８１８において０（ゼロ）にセットされて「旧い」要求が実行されていないことを示すようにし、関数Ｒｕｎ＿Ｏｌｄ（）はステップ８２０において完了される。
【０１０６】
次に、スケジューリングおよび実行ループは、ステップ７８においてインジケータＲｓｔに関するテストを続けて「旧い」要求が実行されているかどうかを判定する。実行されていた場合には、ストレージサーバは関数Ｉｎｉｔ（）を再度呼び出すことによりステップ７２を使ってループを繰り返す。
【０１０７】
そうでない場合、ストレージサーバは、引数としてのリストＬｉｓｔ＿Ｒｅｑを用いて関数Ｒｕｎ＿Ｍｉｎ＿Ｕｓｅ（）を呼び出すことによりスケジューリング実行ループを終了する。
【０１０８】
関数Ｒｕｎ＿Ｍｉｎ＿Ｕｓｅ（）は図１０を参照して記載される。ステップ１０００における初期の後、ストレージサーバ４６は、ステップ１００２において引数としての数１を用いて関数Ａｄｄ＿Ａｇｅ（）を呼び出す。関数Ａｄｄ＿Ａｇｅ（）は、リストＬｉｓｔ＿Ｒｅｑ中のすべての要求のエイジインジケータを１ずつ増加させ、カウンタＭｉｎ＿ｔを０（ゼロ）にリセットする。
【０１０９】
それから、ステップ１００４において、ストレージサーバ４６は、引数としてのリストＬｉｓｔ＿ＲｅｑおよびカウンタＭｉｎ＿ｔを用いて関数Ｕｓｅ＿Ｉｎｆ＿Ｍｉｎ＿ｔ（）を呼び出す。関数Ｕｓｅ＿Ｉｎｆ＿Ｍｉｎ＿ｔ（）は、リストＬｉｓｔ＿Ｒｅｑを通して動作し、要求を送信したストレージクライアント４４に対応する行と、要求が指定するディスクに対応する列との交点での行列Ｔｍ＿Ｕｓｅｄの要素がＭｉｎ＿ｔより小さいかどうかを要求毎に検証する。
【０１１０】
具体的には、これが意味することは、所定の要求が選択されるのが次の場合、すなわち、その要求を送信したクライアントが、この要求がＭｉｎ＿ｔより短い時間で目標とするディスクを既に占有している場合である。したがって、選択された要求全てがリストＬｉｓｔ＿Ｍｉｎ＿Ｒｅｑに記憶される。
【０１１１】
ステップ１００６において、ストレージサーバは、Ｌｉｓｔ＿Ｍｉｎ＿Ｒｅｑが空であるかどうかを調べるためにテストを行う。そうである場合、カウンタＭｉｎ＿ｔはステップ１００８において１ずつ増加され、ステップ１００４が繰り返される。
【０１１２】
ひとたびリストＬｉｓｔ＿Ｍｉｎ＿Ｒｅｑが少なくとも１つの要求を格納すると、ストレージサーバ４６はステップ９０６、９０８、９１０と異なるステップ１０１０、１０１２、１０１４を実行し、そのステップ９０６、９０８、９１０は、リストＬｉｓｔ＿Ｍｉｎ＿ＲｅｑがリストＬｉｓｔ＿Ｏｌｄの代わりにここで使用されているリストＬｉｓｔ＿Ｍｉｎ＿Ｒｅｑであるという点だけで前に記述されている。
【０１１３】
ステップ１０１０、１０１２、１０１４に従って最も好ましい要求の実行後に、ストレージサーバ４６はステップ１０１６において関数Ｒｓｔ−Ｔｍ−Ｕｓｅｄ（）を呼び出す。
【０１１４】
関数Ｒｓｔ−Ｔｍ−Ｕｓｅｄ（）の目的は、１つのストレージクライアント４４が他のストレージクライアントと比べてかなり多くのディスクを使用している場合に、行列Ｔｍ＿Ｕｓｅｄをリセットすることである。
【０１１５】
このため、関数Ｒｓｔ−Ｔｍ−Ｕｓｅｄ（）は行列Ｔｍ＿Ｕｓｅｄのすべての要素を合算している。これは、すべてのストレージクライアント４４によってストレージサーバ４６により管理されているディスクの占有時間の総計を表している。
【０１１６】
この総計が既定の値を超える場合、行列Ｔｍ＿Ｕｓｅｄのすべての要素は０（ゼロ）にセットされる。そうでない場合、行列Ｔｍ＿Ｕｓｅｄは不変である。
【０１１７】
ステップ１０１６の後、関数Ｒｕｎ＿Ｍｉｎ＿Ｕｓｅ（）はステップ１０１８において終了し、スケジューリング実行ループがステップ７２で再開する。
【０１１８】
こうして、関数Ｒｕｎ＿Ｍｉｎ＿Ｕｓｅ（）によって、要求のヘッダ中に格納されている情報に基づいて、これらの要求により指定されたデータの有無と無関係に、要求の実行をスケジュールすることを可能にする。
【０１１９】
したがって、このようにして、大量の要求、特に、ライト要求の実行を、これらの要求に書き込まれるべきデータを使って記憶空間に過剰な負荷を加えることなく、スケジュールすることが可能である。
【０１２０】
しかしながら、その他のアプリケーションでは、要求を実行するために必要とされるすべてのデータが利用可能であるリストＦｉｌｅ中の要求だけをスケジュールすることが可能である。これは、データ供給ループを並列に設けることによって行うことが可能であり、それによって要求データのストレージに割り当てられた空間が、スケジュールされるべき要求の量を最適化するような方法で充満されることを保証している。
【０１２１】
ステップ６６は、ストレージサーバが複数のデータストレージディスクを管理する場合に関連して記載されている。
【０１２２】
その結果として、ループと比較して本質的にグローバルである多数の要素はテーブルであり、多次元であることもある。ストレージサーバが単一のディスクだけを制御する場合には、その状況は簡略化されるかもしれない。それから、要素Ｌａｓｔ＿Ｓｅｃｔは簡単な値になり、要素Ｔｍ＿Ｕｓｅｄは１次元テーブル（ストレージクライアント）になる。
【０１２３】
さらに、スケジューリングは、すべての要求をストレージサーバのキューに一緒に入れることによってここでは実行されている。しかしながら、リストＬｉｓｔ＿Ｒｅｑを索引付けすること、または、直列または並列にキュー毎にスケジューリングを実行することのいずれかによって要求が取り出されたキューに応じて（の関数として）、要求同士をそれぞれ区別することが可能である。
【０１２４】
図１１はスケジューリング実行ループの代替的な実施の形態を示している。
【０１２５】
この特定の実施の形態では、スケジューリング実行ループは、図６に示されたステップより前に実行されるスリープループ１１０をさらに有する点を除いて、図６に示されたスケジューリング実行ループと本質的に同一である。
【０１２６】
スリープループ１１０はスリープマネージメント関数Ｓｌｅｅｐ＿Ｍｎｇ（）１１２を備え、スリープマネージメント関数Ｓｌｅｅｐ＿Ｍｎｇ（）１１２の結果は変数Ｓｌｐに記憶される。
【０１２７】
変数Ｓｌｐは、ストレージサーバを一時的にスリープ状態にするかどうかの決定を示している。さらに、この関数は、図１３〜図１５に関して記載される。
【０１２８】
関数Ｓｌｅｅｐ＿Ｍｎｇ（）１１２の後、スリープループ１１０は変数Ｓｌｐの値に関連したテスト１１４を備えている。
【０１２９】
この変数がゼロでない場合、ストレージサーバは関数Ｆｏｒｃｅ＿Ｓｌｐ（）１１６によって一時的にスリープ状態にされる。その後、スリープループ１１０は１１２でリセットされる。
【０１３０】
関数Ｆｏｒｃｅ＿Ｓｌｐ（）１１６は、「スリープ状態移行」として知られる要求をキューの中に送信することにより、「ストレージサーバをスリープ状態にする」。スリープ状態移行要求はすべての他の要求に優先する。スリープ状態移行要求が実行されるとき、スリープ状態移行要求は、ストレージサーバをパラメータ化可能な時間に対して空動作させる。この関数は、図７における関数Ｗａｉｔ（）の等価として考慮され得る。
【０１３１】
変数Ｓｌｐがゼロである場合、スケジューリング実行ループは図６に示されているように正確に実行される。
【０１３２】
ここで、関数Ｓｌｐ＿Ｍｎｇ（）が図１２を参照して記載される。同図から分かるように、関数Ｓｌｐ＿Ｍｎｇ（）は、１１２８で終了する前に、関数Ｕｐｄ＿Ｓｌｐ＿Ｐａｒ（）１１２２と、関数Ｐｅｒｆ＿Ｓｌｐ（）１１２４と、関数Ｍｎｔ＿Ｓｌｐ（）１１２６との順次実行を備える。
【０１３３】
関数Ｕｐｄ＿Ｓｌｐ＿Ｐａｒ（）１１２２の役割は、サーバをスリープ状態にするかどうかを決定するために使用されるパラメータを更新することである。ここでは、その関数が図１３の助けをかりて記載される。
【０１３４】
図１３から分かるように、関数Ｕｐｄ＿Ｓｌｐ＿Ｐａｒ（）１１２２は、２つのパラメータＴｍ＿ｐｓｄおよびＮｂ＿Ｒｑ＿Ｓｌｐと変数Ｓｌｐとを更新する。
【０１３５】
ステップ１３０２において、パラメータＴｍ＿ｐｓｄは関数Ｅｌｐｓ＿Ｔｉｍｅ（）を用いて更新される。関数Ｅｌｐｓ＿Ｔｉｍｅ（）は、関数Ｕｐｄ＿Ｓｌｐ＿Ｐａｒ（）１１２２の最後の実行からどのくらいの時間が経過したのかを計算する。
【０１３６】
この計算は、たとえば、あるループから次のループまで、それぞれの実行で更新される時間／日付変数を保持（保存）することにより、および、後続するループの間にその変数を実行の現在時間と比較することにより行われ得る。
【０１３７】
ステップ１３０４では、パラメータＮｂ＿Ｒｑ＿Ｓｌｐは値Ｔｍ＿ｐｓｄ＊Ｆｑ＿Ｒｑ＿Ｓｌｐずつ増加される。パラメータＮｂ＿Ｒｑ＿Ｓｌｐはスリープ状態にする多数の要求を表している。
【０１３８】
ここに記載された実施の形態では、２つの主要なスリープ条件のタイプが存在する。第１のものは性能に関係される条件のタイプである。第２のものは名目上の占有レベルに関係するタイプである。このレベルは、特に、アドミニストレーションモジュールを用いて定義されることがあり、または、一般に条件はシステムアドミニストレータによって固定されたパラメータとして考えられることがある。
【０１３９】
パラメータＮｂ＿Ｒｑ＿Ｓｌｐはこの第２のタイプに属している。このパラメータは、ストレージサーバのアドミニストレータによって規定されたパラメータである頻度Ｆｑ＿Ｒｑ＿Ｓｌｐを持つスリープ要求をサーバが作成することを保証するカウンタである。
【０１４０】
しかしながら、これより先で明らかになるように、スリープ要求はある種の条件下でのみ実際に実行される。このカウンタによって、スリープ要求が何回実行され得たのかを決定することが可能になる。
【０１４１】
次に、ステップ１３０６において、変数Ｓｌｐは現在のスリープループに対して０（ゼロ）にリセットされ、関数Ｕｐｄ＿Ｐａｒ＿Ｓｌｐ（）が１３０８で終了する。
【０１４２】
ここで、関数Ｐｅｒｆ＿Ｓｌｐ（）が図１４を参照して記載される。この関数によって、記憶ノードの状態パラメータとキューとに基づいてスリープ状態にすることを決定することが可能になる。
【０１４３】
このため、この関数は、２回のテスト１４０２、１４０４に基づいている。第１のテスト１４０２は、ローカルリソース、すなわち、ストレージサーバが実行される記憶ノードのリソースの占有レベルに関する。
【０１４４】
ここで記載される実施の形態では、テストされるのはプロセッサリソースである。これを行なうために、プロセッサの占有レベルを評価する関数が呼び出される。これらの関数は、標準タイプであるとともに、たとえば、オペレーティングシステムによって保持されるグローバル変数を調べることに基づいていてもよく、または、これらの関数はより特定の関数でもよい。
【０１４５】
プロセッサが（たとえば９０％を越える）極端な負荷を既に受けている場合、ストレージサーバをスリープ状態にしてストレージサーバが記憶ノードの性能を低下させないようにすることが決定される。
【０１４６】
したがって、この場合には、変数Ｓｌｐは１４０６で１にセットされ、関数Ｐｅｒｆ＿Ｓｌｐ（）は１４０８で終了する。
【０１４７】
なお、多数の他の条件が、プロセッサ負荷、または、その代わりにたとえばローカルメモリユニットのアクセス負荷のようなもの、または、当業者が予想し得る他のものと協働してここでは使用されるかもしれない。
【０１４８】
第２のテスト１４０４は、第１のテスト１４０２が否定である場合、すなわち、プロセッサ負荷があまり大きくない場合に行われるだけである。第２のテストはキュー内に格納された要求の回数の評価に関する。
【０１４９】
実際には、この回数があまりに少ない場合、ストレージサーバはスケジューリングループをうまく利用せず、それによって潜在的に性能を低下させている。
【０１５０】
その結果、キュー内に存在する要求の回数があまりに少ない場合、変数Ｓｌｐが１４０６で１にセットされ、関数Ｐｅｒｆ＿Ｓｌｐ（）が１４０８で終了する。そうでなければ、その関数は１４０８で直ちに終了する。
【０１５１】
なお、ここでもまた、多数の他の条件が使用されてもよく、好ましい性能条件が満たされない限りその原理はストレージサーバをスリープ状態にすることになる。
【０１５２】
これらの代替的な条件のうち１つは、たとえば、キュー内に存在する要求のタイプに着目してもよい。このように、要求が「遠い」場合、すなわち、各要求によって指定された物理アドレスと、ストレージサーバによって前にアクセスされた物理アドレスとの間の距離が一定のしきい値より高い場合、「より近い」要求がキューに到着するのを待つことは好ましいと考えられることがある。使用される可能性のある別のタイプの基準は、要求の性質、すなわち、読出しまたは書込み、または、要求の特性に関する他の基準である。
ここで、関数Ｍｎｔ＿Ｓｌｐ（）は図１５の助けをかりて記載される。この関数によって、予定されたスリープ期間を取り消すこと、または逆に、「メンテナンス」スリープを課すことが可能になる。関数Ｍｎｔ＿Ｓｌｐ（）は２回のテスト１５０２、１５０８に基づいている。
【０１５３】
第１のテスト１５０２は、スリープ要求のうちの１つを実行可能にするために必要とされるスリープ要求の最小回数とパラメータＮｂ＿Ｒｑ＿Ｓｌｐを比較する。このことは、結局、多くのスリープ要求が最近実行されたかどうかを決定することになる。
【０１５４】
パラメータＮｂ＿Ｒｑ＿Ｓｌｐが最小回数より小さい場合、変数Ｓｌｐが１５０４で０（ゼロ）にセットされ、その関数は１５０６で終了する。
【０１５５】
第２のテスト１５０８は、第１のテスト１５０２が肯定である場合に行われるだけである。この第２のテストは、パラメータＮｂ＿Ｒｑ＿Ｓｌｐをスリープ要求の最大回数と比較する。このことは、結局、いずれかのスリープ要求が実行されてから非常に長い時間が経過したかどうかを決定することになる。
【０１５６】
パラメータＮｂ＿Ｒｑ＿Ｓｌｐが最大回数より少ない場合、その関数は１５０６で終了する。反対の場合、変数Ｓｌｐは１５１０で１にセットされ、その後、関数が１５０６で終了する。
【０１５７】
これが意味することは、たとえスリープ要求を実行することが推測的に予定されている場合であっても、多数の他の要求が少し前に既に実行されているので、このスリープ要求が行われることはなく、または逆に、
ある特定の長さの時間が経過しスリープ要求が実行されない時には、たとえ他の基準に照らしてスリーブ要求が必要でない場合であっても、１つのスリープ要求を実行する任意の決定がなされる。
【０１５８】
関数Ｍｎｔ＿Ｓｌｐ（）は関数Ｐｅｒｆ＿Ｓｌｐ（）の後に実行されるという事実により、関数Ｍｎｔ＿Ｓｌｐ（）は関数Ｐｅｒｆ＿Ｓｌｐ（）の決定を覆すことができることが理解される。換言すると、ストレージサーバのメンテナンスのために、この関数によって、予定されたスリープ期間を取り消すこと、または、変数Ｓｐｌに影響することにより予定されなかったスリープ期間を強制することが可能になる。
【０１５９】
なおまた、関数Ｆｏｒｃｅ＿Ｓｌｐ（）はそれぞれの実行で１単位までカウンタＮｂ＿Ｒｑ＿Ｓｌｐを減少させている。
【０１６０】
前述を読むことから明らかになるように、スケジューリング実行ループは、直列に処理される３つの主要部分と選択的なプレループ、すなわち、
ストレージサーバが位置している記憶モードの性能を保証するための選択的なスリープループと、
新しい要求を管理するための第１の部分と、
最も旧い要求を処理する第２の部分と、
ストレージサーバを最も使用していないストレージクライアントから来る要求を処理するための第３の部分と、
を備えている。
【０１６１】
これらの部分は互いに独立していること、および、簡略化されたループは後者のうちの１つまたは幾つかだけを格納していることは明確に明らかである。これらの部分の処理は並列でもよいこと、および、「旧い」要求を実行した後にループをリセットする代わりに、第３の部分を実行することが可能であることも同様に明らかである。
【０１６２】
第２の部分および第３の部分は、より一般的な概念における特定の例であるとみなされることがある。
【０１６３】
したがって、第２の部分では、「旧い」要求の処理は、何らかの理由のためにアルゴリズムにより優先事項として実行されなかった「例外」要求を管理する必要性から生じる。このことは、そのような場合を回避するための他の実施が予想され得る点で、注記されるべき指針概念である。
【０１６４】
第３の部分に関して、一般的な概念は、ストレージクライアントとストレージサーバとの関係に基づく量的基準に応じて（の関数として）要求をスケジューリングすることである。このように、記載された例では、ローカルメモリユニットの使用時間の量的基準が要求同士を区別するために使用される。
【０１６５】
しかしながら、ストレージクライアント／ストレージサーバの相互作用を特徴付ける統計量に基づく、たとえば、平均データ交換レベル、これらの相互作用中に見出される平均ネットワークレイテンシー、パケットの損失レベルなどに基づく他の量的基準を使用することが可能になる。
【０１６６】
さらに、ここに記載された実施は、簡略化された例として与えられ、バッファの使用のような従来のプログラミング技術を使用することによって、または、スケジューリングのための他のパラメータを考慮することによってさらに改良され得る。
【０１６７】
提示された記載では、スケジューリングは２つの主要な軸に便宜を与える、すなわち、旧い要求の実行、および、ディスクとクライアントとの間の負荷の分担に便宜を与える戦略に基づいている。
【０１６８】
その他の戦略は、以下のような他のアプローチに便宜を与えるために（対応して前述を変更させることによって）実施されることもある：
たとえば、隣接またはほぼ隣接している要求を単一の要求にまとめることによって、ディスク帯域幅の利用を最大化し、それによってディスクアクセスを軽減するアプローチと；
たとえば、レイテンシー（待ち時間）を短縮するために１つまたは複数のディスクの中心を目標とする最適化要求をストレージサーバで発生させることにより、または、ストレージサーバで予測要求を発生させる（すなわち、将来の要求を予想することによってデータを目標とする）ことにより、ディスクレイテンシーの利用を最大化するアプローチ。
【０１６９】
その他の戦略、および、それらの実施、ならびに、様々な変形が当業者にとって明白である。
【０１７０】
したがって、記憶されたデータにアクセスするアプリケーションは、様々な要素同士の関係を管理するドライバを備えていることもあり、その関係は、たとえば、アプリケーションとファイルシステムとの間の相互作用、ファイルシステムと対応付けモジュールとの間の相互作用、対応付けモジュールとストレージクライアントとの間の相互作用、各要素から結果を取得して当該結果（またはその結果の変形形態）を用いて次の要素を呼び出すことによるストレージサーバの戦略の実施である。
【０１７１】
代替的に、システムは自律的でもよく、データを呼び出すアプリケーションに依存しなくてもよく、要素は互いに通信可能であってもよいので、情報は層を下方へ移動して要素と要素の間で再び上方へ移動するようにしている。
【０１７２】
同様に、これらの要素同士の通信は、たとえば、ＰＯＳＩＸインターフェイスと、ＩＰ、ＴＣＰおよびＵＤＰプロトコルと、共有メモリと、ＲＤＭＡ（リモート・ダイレクト・アクセス・メモリ）とを用いて様々な方法で確保されることがある。発明の目的は既存のネットワークリソースに基づいて特殊化されたストレージシステムの利点を提供することであることに注意すべきである。
【０１７３】
上述されたシステムの実施の形態は、コンピュータを使ってステーションが作られたネットワークに基づき、そのシステムは以下の構成からなる：
（たとえば、ＣＩＳＣまたはＲＩＳＣタイプの、またはその他の）特殊化されたプロセッサまたは汎用プロセッサと、
１つ以上のストレージディスク（たとえば、シリアルＡＴＡまたはＳＣＳＩインターフェイスの、またはその他を有するハードディスク）またはその他のタイプのストレージと、
ネットワークインターフェイス（たとえば、Ｇｉｇａｂｉｔ、Ｅｔｈｅｒｎｅｔ、Ｉｎｆｉｎｉｂａｎｄ、ＳＣＩなど）と、
アプリケーションをサポートしてファイルシステムマネージャを提供するための（Ｌｉｎｕｘのような）オペレーティングシステムに基づくアプリケーション環境と、
対応付けモジュールを生成するためのアプリケーションアセンブリ、たとえば、Ｓｅａｎｏｄｅｓ（登録商標）社のアプリケーションＥｘａｎｏｄｅｓ（登録商標）のクラスタード・ロジカル・ボリューム・マネジャ（Ｃｌｕｓｔｅｒｅｄ  Ｌｏｇｉｃａｌ  Ｖｏｌｕｍｅ  Ｍａｎａｇｅｒ）と、
各ＮＢＤのストレージクライアントおよびサーバクライアントを生成するためのアプリケーションアセンブリ、たとえば、Ｓｅａｎｏｄｅｓ（登録商標）社のアプリケーションＥｘａｎｏｄｅｓ（登録商標）のＥｘａｎｏｄｅｓ  Ｎｅｔｗｏｒｋ  Ｂｌｏｃｋデバイスモジュールと、
共有要素を管理するためのアプリケーションアセンブリ、たとえば、Ｓｅａｎｏｄｅｓ（登録商標）社のアプリケーションＥｘａｎｏｄｅｓ（登録商標）のＥｘａｎｏｄｅｓ  Ｃｌｕｓｔｅｒｅｄ  Ｓｅｒｖｉｃｅ  Ｍａｎａｇｅｒモジュール。
【０１７４】
このタイプのシステムはネットワーク内で作られてもよく、そのシステムは以下の構成からなる：
ネットワーク上のアプリケーション用途に適合しアプリケーションノードとして機能する従来のユーザステーションと、
上記の記載に従って生成されネットワークのサーバおよびストレージノードとして機能する一組のコンピュータベースの機器。
【０１７５】
その他の機器およびアプリケーションは、発明の範囲内で装置の代替的な実施の形態を作るために当業者にとって明らかになる。
【０１７６】
発明は、アプリケーションノードおよび記憶ノードを備えるコンピュータベースシステムを全体として包含している。また、発明は、このコンピュータベースシステムの個別の要素と、特に、別々に取り上げられたアプリケーションノードおよび記憶ノードと、それらを作るための様々な手段とを包含している。
【０１７７】
同様に、データマネージメントプロセスは、全体として考慮されるべきであり、すなわち、アプリケーションノードと記憶ノードとの相互作用において、さらに、このプロセスのアプリケーションノードおよび記憶ノードを作るのに適した個別のコンピュータベースの設備に関しても考慮されるべきである。
【０１７８】
上記の記載は発明の特定の実施の形態を記述することを目指している。上記の記載は、限定的なものとして、または、発明を限定的な方法で記述するものとして見なされるべきでなく、特に、互いに記載された変形例の特徴のすべての組合せを網羅している。
【０１７９】
また、プロダクト（生成物）として、発明はあらゆるコンピュータ読出し可能な「媒体」（担体）で利用可能にされ記載されたソフトウェア要素にも及んでいる。「コンピュータ読出し可能な媒体」という表現は、磁気的、光学的、および／または、電子的なデータストレージ担体と、アナログ信号またはデジタル信号のような伝送担体または伝達手段（ビィークル）とを包含している。
【０１８０】
また、このような媒体は、ソフトウェア要素自体、すなわち、インストレーションおよび／または開発に使用されるソフトウェア要素のように、インストレーションディスクまたはリモートロード可能なインストレーションプログラムのように直接的に動作されるのに適した要素も含んでいる。このようなインストレーションは、その都度適切なプロダクトを用いて、クライアントステーションおよびサーバステーションに渡ってグローバル的にまたは別々に行われてもよい。
【図１】
2010507851.tif 000003
【図２】
2010507851.tif 000004
【図３】
2010507851.tif 000005
【図４】
2010507851.tif 000006
【図５】
2010507851.tif 000007
【図６】
2010507851.tif 000008
【図７】
2010507851.tif 000009
【図８】
2010507851.tif 000010
【図９】
2010507851.tif 000011
【図１０】
2010507851.tif 000012
【図１１】
2010507851.tif 000013
【図１２】
2010507851.tif 000014
【図１３】
2010507851.tif 000015
【図１４】
2010507851.tif 000016
【図１５】
2010507851.tif 000017
【国際調査報告】
2010507851.tif 000018
2010507851.tif 000019
2010507851.tif 000020
2010507851.tif 000021
2010507851.tif 000022
2010507851.tif 000023
2010507851.tif 000024
2010507851.tif 000025