(57)【要約】  リソースコマンドメッセージは、コマンドとコマンドの緊急性または重要性に関する情報とを備えている。情報は、リソースデバイスによって解釈され、リソースデバイスに関する情報と組み合わせてリソースコマンドメッセージ内のコマンドを処理するタイミングを決定する。複数のリソースノードを備えるリソースデバイスは、より高いパフォーマンス、応答性、および複数のリソースノードで同じリソースコマンドメッセージをパラレルに処理することによる負荷分散を提供する。
2009512011.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一部はメモリ内に存在し、１つのリソースノードを備えるリソースデバイスにアドレス指定され、
（ａ）１つのコマンドと、
（ｂ）コマンドの緊急性とコマンドの重要性の少なくとも１つを含むコマンドパラメータとを備えており、コマンドを処理するタイミングの決定はコマンドパラメータおよびリソースノードに関連する情報との関数である、リソースコマンドメッセージ。
【請求項２】
リソースデバイスは第２のリソースノードを備えており、リソースノードのそれぞれがコマンドメッセージを処理できる、請求項１に記載のリソースコマンドメッセージ。
【請求項３】
コマンドの緊急性が、優先されるプロバイダを含む、請求項１に記載のリソースコマンドメッセージ。
【請求項４】
コマンドの緊急性が、コマンドを処理するための相対的な時間を指定する、請求項１に記載のリソースコマンドメッセージ。
【請求項５】
コマンドの緊急性が、コマンドを処理するための絶対的な時間を指定する、請求項１に記載のリソースコマンドメッセージ。
【請求項６】
コマンドの重要性が、サービスの品質に関する情報を指定する、請求項１に記載のリソースコマンドメッセージ。
【請求項７】
コマンドの重要性が、コマンドを処理するための相対的な優先度を指定する、請求項１に記載のリソースコマンドメッセージ。
【請求項８】
コマンドの重要性が、コマンドを処理するための絶対的な優先度を指定する、請求項１に記載のリソースコマンドメッセージ。
【請求項９】
コマンドパラメータが、コマンドを先行するコマンドと後続のコマンドの少なくとも１つに関連付けるコマンド識別子をさらに備える、請求項１に記載のリソースコマンドメッセージ。
【請求項１０】
リソースコマンドメッセージを処理する方法であって、少なくとも一部はメモリ内に存在し、１つのリソースノードを備えるリソースデバイスにアドレス指定され、
リソースコマンドメッセージは１つのコマンドと、コマンドの緊急性とコマンドの重要性の少なくとも１つを含むコマンドパラメータとを備えており、
（ａ）コマンドを処理するタイミングをコマンドパラメータとリソースノードに関連する情報との関数として決定するステップと、
（ｂ）コマンドが処理されるタイミングに基づいてコマンドキューを順序変更するステップとを備える、方法。
【請求項１１】
コマンドキューの位置が、絶対的なコマンドキューの位置である、請求項１０に記載の方法。
【請求項１２】
コマンドキューの位置が、別のコマンドキューの位置にある別のコマンドと相対的である、請求項１０に記載の方法。
【請求項１３】
コマンドが処理されるタイミングを決定するステップが、コマンドの処理を遅延させるステップを含む、請求項１０に記載の方法。
【請求項１４】
遅延させるステップが、コマンドをまったく処理しないことを含む、請求項１３に記載の方法。
【請求項１５】
リソースコマンドメッセージにリソースコマンド応答メッセージで応答するステップをさらに備える、請求項１０に記載の方法。
【請求項１６】
リソースコマンド応答メッセージは、リソースノードがコマンドを処理する能力の指定を含む、請求項１５に記載の方法。
【請求項１７】
要求された割り当ての少なくとも一部を予約するステップをさらに備える、請求項１６に記載の方法。
【請求項１８】
リソースコマンドメッセージ応答が、コマンドが処理されたことの確認を含む、請求項１５に記載の方法。
【請求項１９】
リソースコマンドメッセージを、先行するコマンドの処理を中断する命令と解釈するステップをさらに備える、請求項１０に記載の方法。
【請求項２０】
リソースデバイスが複数のリソースノードを備える、請求項１０に記載の方法。
【請求項２１】
リソースコマンドメッセージを複数回実質的にパラレルに処理するステップをさらに備える、請求項２０に記載の方法。
【請求項２２】
リソースコマンドメッセージが、複数のリソースノードの中から優先されるプロバイダを選択するステップをさらに備える、請求項２１に記載の方法。
【請求項２３】
請求項１０に記載のステップをプロセッシングユニットで実行する命令を格納する、コンピュータ可読メモリ。
【請求項２４】
リソースを管理する１つのリソースノードを備えるリソースデバイスにアクセスする方法であって、
（ａ）１つのコマンドと、１つのコマンドパラメータとを含むリソースコマンドメッセージを作成するステップであって、コマンドパラメータはコマンドの緊急性とコマンドの重要性の少なくとも１つを備えており、
コマンドを処理するタイミングの決定はコマンドパラメータとリソースノードに関連する情報との関数であるステップと、
（ｂ）コマンドメッセージをリソースデバイスに送信するステップとを備える、方法。
【請求項２５】
リソースデバイスが複数のリソースノードを備える、請求項２４に記載の方法。
【請求項２６】
送信する動作が、リソースコマンドメッセージを複数のリソースノードにマルチキャストで送信するステップを含む、請求項２５に記載の方法。
【請求項２７】
複数のリソースノードの中から優先されるプロバイダを選択するステップをさらに備える、請求項２５に記載の方法。
【請求項２８】
優先されるプロバイダを選択するステップが、複数のリソースノードの中から最初に応答したプロバイダを選択するステップを備える、請求項２７に記載の方法。
【請求項２９】
リソースコンシューマとリソースノードの少なくともいずれかがスロースタートを使用するステップをさらに備える、請求項２４に記載の方法。
【請求項３０】
コマンドパラメータがコマンドグループ識別子を含む、請求項２４に記載の方法。
【請求項３１】
請求項２４に記載のステップをプロセッシングユニットで実行する命令を格納する、コンピュータ可読メモリ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティングリソースコマンドメッセージング（ｃｏｍｐｕｔｉｎｇ  ｒｅｓｏｕｒｃｅ  ｃｏｍｍａｎｄ  ｍｅｓｓａｇｉｎｇ）およびリソースデバイスの分野に関するものである。
【背景技術】
【０００２】
リソースデバイスは、コンピューティングリソースを管理する。こうしたコンピューティングリソースには、ストレージアレイを構成するディスクドライブ上のデータストレージからサーバファームに含まれる大容量コンテンツサーバ内の接続プロセスに至るまで、無数の例がある。通常、リソースデバイスは複数のリソースノードを備えているので、リソースコンシューマ（ｒｅｓｏｕｒｃｅ  ｃｏｎｓｕｍｅｒ）の視点からは唯一の論理リソースデバイスとして表示される分散型のリソースを構成している。
【０００３】
物理リソースの管理を担当するリソースノードは、リソースノードがデータストレージリソースを管理しているか、接続およびコンテンツリソースを管理する個々のＷｅｂサーバであるかにかかわらず、効率的に機能する必要がある。多くのリソースコンシューマおよびリソースデバイスを備える複雑な環境では、特にこのことが言える。効率は、スケーラビリティ（ｓｃａｌａｂｉｌｉｔｙ）、高パフォーマンス、負荷分散、短い応答時間（応答性）、または最適化を要求できるその他の属性を含む望ましい特性によって決まる。リソースノードは、通常、外部の管理システムによって管理されるか、またはそれに課される管理レイヤ（ｍａｎａｇｅｍｅｎｔ  ｌａｙｅｒ）を備えている。これによって、残念ながらリソース管理の基本的な責務を超える余分なオーバヘッドが発生する。複数のリソースノードを備えるリソースデバイスでは、外部の管理の問題は深刻化する。例えば、リソースノードに負荷が割り当てられると、通常はリソースコンシューマにその状態を通知するか、リソース要求を他のリソースノードに移行するか、またはその他の帯域外管理通信を実行することによってパフォーマンスを最大化するので、結果として過剰な帯域外通信が発生する。こうしたシステムでは、新しいリソースノードが環境に追加されると、管理に関する「チャタリング（ｃｈａｔｔｅｒ）」の増大が通信と帯域幅処理の大きな部分を占め、パフォーマンスに悪影響を及ぼすため、スケーラビリティの問題が発生する。こうしたきめの粗いスケーラビリティにより、システムの能力を徐々に高めるためのコストは増大し、システム全体を複製するためのコストは法外な金額になる。
【０００４】
コストを削減し、それ以外の望ましい結果を達成するためには、個々のリソースノードがそれぞれ他のリソースノードにも外部の管理システムにも関係なく機能するシステムを設計するのが有利である。換言すると、リソースノードはリソース管理の基本的な責務を実行するために他のリソースノードに関する情報を必要とすべきではない。リソースへのアクセスを希望するリソースコンシューマにサービスするためには、自律型のリソースノードがリソースコンシューマから送信されたコマンドを処理するタイミングを、（ａ）リソースノードに関連する情報と、（ｂ）リソースコンシューマによってそのコマンドを含むメッセージ内に提供された任意の情報とに基づいて決定するか、少なくともこうした情報の要因として決定される必要がある。
【０００５】
リソースコンシューマは、コマンド情報を提供するほか、コマンドが処理されるための望ましい緊急性または重要性に関する情報を提供する。リソースコンシューマが自律型のリソースノードの動作を理解していれば、リソースコンシューマはすべてのリソースノードとの対話に基づいてそのリソースコマンドメッセージを調整し、より高いパフォーマンスを実現できるので、追加の機能を導入しなくても必然的にスケーラビリティ、パフォーマンス、または応答性の効果が得られる。
【０００６】
現在の関連技術では、リソースコンシューマとリソースノードとの対話によって発生する必然的な動作でなく、こうした対話以外のアクティビティに照準を合わせることによって、コンピューティングリソースへの効率的なアクセスを提供しようとする。関連技術では、追加の機能を導入することによって望ましい特性を最適化する。例えば、関連技術ではリソースコンシューマと他のリソースコンシューマとの通信、リソースノードと他のリソースノードとの通信、または通信パスを使用した通信によるリソースコンシューマとリソースノードとの通信の管理が必要であろう。
【０００７】
Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓの米国特許第５，５０６，９６９号、「Ｍｅｔｈｏｄ  ａｎｄ  ａｐｐａｒａｔｕｓ  ｆｏｒ  ｂｕｓ  ｂａｎｄｗｉｄｔｈ  ｍａｎａｇｅｍｅｎｔ」は、複数のアプリケーションから周辺モジュールへの高速バス上のバスアクセスを効率的にスケジュールする方法について教示している。この特許では、アプリケーションとモジュールとの間のバスが管理される方法について説明しているが、バス管理システムが必要であり、個々のモジュールおよびアプリケーションの動作で望ましいパフォーマンスは得られない。この出願では、モジュールが要求を処理するタイミングを決定できるようにするための緊急性または重要性に関する情報を備えるリソースコマンドメッセージを使用しない。
【０００８】
Ｈｅｗｌｅｔｔ−Ｐａｃｋｅｔ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｃｏｍｐａｎｙの米国特許第６，８８６，０３５号「Ｄｙｎａｍｉｃ  ｌｏａｄ  ｂａｌａｎｃｉｎｇ  ｏｆ  ａ  ｎｅｔｗｏｒｋ  ｏｆ  ａ  ｃｌｉｅｎｔ  ａｎｄ  ｓｅｒｖｅｒ  ｃｏｍｐｕｔｅｒ」は、クライアントコンピュータがリダイレクト（ｒｅｄｉｒｅｃｔｉｏｎ）を使用することによって自らとリソースの間のスループットを最適化する方法について教示している。リダイレクトには、ネットワーク上のホストがネットワーク上の他のホストについてそれ自身以上に精通している必要がある。システムに導入される追加のエレメントのそれぞれについて、管理し、システムに統合してリダイレクトのための十分な情報を保証する必要があるため、システムのスケーラビリティは低下する。負荷分散は、コマンドメッセージ内の緊急性または重要性に関する情報を使用することによるので、自動的には実現されない。
【０００９】
ＥＭＣ  Ｃｏｒｐｏｒａｔｉｏｎの米国特許第６，９０４，４７０号、「Ｄｅｖｉｃｅ  ｓｅｌｅｃｔｉｏｎ  ｂｙ  ａ  ｄｉｓｋ  ａｄａｐｔｅｒ  ｓｃｈｅｄｕｌｅｒ」は、要求の緊急性と優先度に基づいてリソースのＩ／Ｏ要求を効率的にスケジュールする方法について教示している。この特許は、ディスクアダプタによって管理される論理ボリュームを対象とする様々なＩ／Ｏタスクを管理するために、どのタイプのスケジューラが使用されるべきかをメインスケジューラが決定する方法について説明している。論理ボリュームは、物理データストレージリソースに関連付けられているが、コヒーレントな（ｃｏｈｅｒｅｎｔ）仮想デバイスである。したがって、各ディスクアダプタはリソースでなくデバイスを管理しており、追加の管理機能を導入することによって、論理ボリューム全体の負荷分散、パフォーマンス、およびその他の品質を保証する。特許第６，９０４，４７０号は、リソースノードの自律型の動作には対応せず、その動作は緊急性と重要性に関する情報とリソースノードの情報とを使用してタスクが実行されるタイミングを決定することから必然的に決まる。
【００１０】
自律型のリソースノードの動作によって、スケーラビリティ、高パフォーマンス、負荷分散、または応答性を含む望ましい属性が必然的に得られるというニーズに対応する関連技術は存在しない。自律型のリソースノードの利点を完全に実現するためには、ソリューションが以下の特性を備えるのが好ましい：
・  リソースノードは、リソースコンシューマから送信されたコマンドを処理するタイミングを、コマンドに関連する情報およびリソースノード自体の情報に関連する情報に基づいて決定する。
・  リソースコンシューマからリソースノードに送信されたメッセージは、メッセージまたはメッセージ内のコマンドの処理に関連付けられた緊急性または重要性に関するリソースコンシューマの認識を表している。
【００１１】
リソースノードに送信されたコマンドを処理するタイミングをリソースノードが決定できることにより、いくつかの利点が得られる。第１に、個々のリソースノードはその主要な責務に照準を合わせる（他のリソース中心でない作業でなく）ので、こうしたリソースノードの機能は付加的な管理作業を実行している同様のリソースノードより効率的である。第２に、複数のリソースコンシューマは外部のアービトレータ（ａｒｂｉｔｒａｔｏｒ）を備えていない１つのリソースデバイスの複数のリソースノードと対話することができる。これで、各リソースノードはどのリソースコンシューマが注目に値するのか（該当する場合）を独自に決定できるので、応答時間が短縮される。第３に、複数のリソースノードが冗長なリソースへのアクセスを提供し、さらにこうしたリソースノードが同時にアドレス指定される場合に、各リソースデバイスはその最大限の能力を活用するので、リソースノードのグループは自動的に負荷分散される。１つの冗長なリソースノードの負荷が最大である場合は、外部の介入なしに別の冗長なリソースノードが要求に対応することができる。さらに、冗長なリソースノードのいずれかがリソースコンシューマへの有効な応答を提供できるので、システムの応答性は冗長なリソースノードを備えていないリソースデバイスより高くなる。第４に、各リソースノードは独立しており、リソースコンシューマまたは他のリソースノードから追加の情報を要求することなく、環境に容易に統合できるため、こうした環境のスケーラビリティは高い。いくつかの利点のみが示されているが、当然のことながら本主題にはこれ以外の利点も想定されている。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
このように、リソースコマンドメッセージを提供する方法および装置、およびコマンドメッセージの内容とリソースノードに関連付けられた情報に基づいてリソースコマンドメッセージを処理するタイミングを自律的に決定する１つまたは複数のリソースノードを備えるリソースデバイスへの高いニーズは依然として残されている。
【課題を解決するための手段】
【００１３】
本発明の１つの態様は、コマンドおよびコマンドの緊急性またはコマンドの重要性の指定を含むコマンドパラメータを備えるリソースコマンドメッセージを目的とする。リソースコンシューマは、リソースコマンドメッセージを構成して１つのリソースデバイスを構成するリソースノードと対話する。リソースノードは、リソースコマンドメッセージの緊急性または重要性とリソースノード中心の情報に基づいて、リソースコマンドメッセージを処理する。さらに、リソースデバイスは複数のリソースノードを備えることができ、各リソースノードは他のすべてのノードから独立して動作する機能を備えており、各リソースノードがリソースコマンドメッセージを受信できる。リソースコマンドメッセージの緊急性または重要性には、相対的な値または絶対的な値が含まれる。
【００１４】
別の態様では、本発明はリソースコマンドメッセージを処理する方法を目的とする。本方法には、リソースコマンドメッセージに含まれるコマンドの緊急性またはコマンドの重要性の情報を解釈するステップと、こうした情報をリソースノードの情報と組み合わせてリソースコマンドメッセージ内のコマンドが処理されるタイミングを決定するステップとが含まれる。本方法には、コマンドが処理されるタイミングに基づいてコマンドキュー内のコマンドが処理される順序を決定するステップがさらに含まれる。こうした決定により、コマンドは即時に処理されること、処理を遅延されること、処理されないこと、あるいは、前または後に送信された他のコマンドに関連して処理の順序を変更することができる。さらに、本方法にはリソースデバイスを構成する複数のリソースノードによってリソースコマンドメッセージを処理するステップが含まれる。
【００１５】
さらに別の態様では、本発明は、コマンドとコマンドの緊急性またはコマンドの重要性の少なくともいずれかを備えるコマンドパラメータとを含むリソースコマンドメッセージを作成することによってリソースデバイスにアクセスする方法を目的とする。本方法には、またリソースデバイスにリソースコマンドメッセージを送信するステップと、リソースコマンドメッセージ内のコマンドを処理するタイミングを決定するステップとが含まれる。リソースデバイスが複数のリソースノードを備える場合に、リソースコマンドメッセージを送信するステップには、少なくともいくつかのリソースノードにマルチキャストで送信するステップが含まれる。
【００１６】
好ましい実施形態では、リソースデバイスに含まれるリソースノードは、自律型のエンティティとして動作でき、各リソースノードがその独自のリソースを管理する。リソースコンシューマは、リソースノードからリソースを取得してそれぞれの独自の機能を実行する。リソースコンシューマも自律型のエンティティである。リソースコンシューマがリソースを必要としているで、リソースコンシューマはコマンドの緊急性またはコマンドの重要性の指定を伴うリソースコマンドメッセージをリソースデバイスに送信することによって、リソースの取得、リソースの予約、リソースの使用、または他の方法によるリソースとの対話を行う。リソースノードは自律型で複数のリソースコンシューマからの要求に対してサービスを行うので、リソースノードはその状態、履歴、能力、またはその他の関連情報に関する情報とその緊急性または重要性に関する情報の解釈を組み合わせて、コマンドを処理する方法またはタイミングを決定する。本明細書で使用する限り、「処理するタイミング」という表現は、コマンドの処理を自律的に行うことを意味しており、時間ベースの処理、処理の順序、または他のプロセス処理の概念を含めて広義に解釈する必要がある。
【００１７】
リソースコンシューマとリソースノードは、コンシューマまたはノードの制御の範囲外にあるパスを経由して通信できることが想定されている。好ましい実施形態では、高パフォーマンスまたは高信頼性を保証するために、リソースデバイスは複数のリソースノードを備えており、各リソースノードはリソースのすべてまたは一部を管理し、さらに他のすべてのノード、デバイス、コンシューマのいずれからも独立して機能する。リソースノードが冗長なリソースを提供する場合は、リソースコンシューマがリソースコマンドメッセージを一部またはすべてのリソースノードに送信し、ネットワークまたは負荷の現在の状態が指定されると、対応できる可能性が最も高いリソースノードが応答する。さらに、他のリソースノードは、追加のリソースコマンドメッセージまたはリソースコマンド応答を、前に処理されていないコマンドの処理を中断または停止して複数の応答を減少する命令と解釈する。リソースノードの自律型の動作とリソースコマンドの緊急性または重要性を組み合わせることにより、全体的に負荷分散されたシステムが実現され、帯域外通信の必要はない。
【００１８】
以下は、本明細書内で使用する用語の説明である。以下の用語は、本発明の主題の様々な態様について暗黙的な制限なしに説明する場合に、明確さを保証するために示されている。
【００１９】
「リソースデバイス」は、通信パス上でその全体または一部をアドレス指定でき、リソースコンシューマによってコンピューティングリソースとして使用されるプロダクトへのアクセスを提供する論理デバイスを意味する。論理リソースデバイスは、物理デバイスまたは仮想デバイスを含むことが想定されている。物理リソースデバイスには、コンピュータ、モニタ、ハードディスクドライブ、パワーサプライ、またはその他の物理エレメントが含まれる。仮想リソースデバイスには、アドレス指定可能なビデオディスプレイ、論理ストレージボリューム、ＵＲＬを伴うＷｅｂサーバファーム、または物理エレメントのその他の抽象概念が含まれる。リソースコンシューマは、各リソースデバイスをそれが実際の物理アーキテクチャか仮想アーキテクチャかにかかわらず、コヒーレントな一体型のデバイスと解釈する。
【００２０】
「リソースコンシューマ」は、希望する機能を実行するプロダクトへのアクセスまたは制御を要求するエンティティを意味する。リソースコンシューマには、コンピュータ、アプリケーション、ユーザ、Ｗｅｂサーバゲートウェイ、または通信パスを経由してリソースノードと通信できるその他のエンティティが含まれる。したがって、リソースコンシューマもアドレス指定可能でもある。リソースデバイスは、場合によってはリソースコンシューマとして機能できると考えられる。
【００２１】
「リソースノード」は、リソースデバイスの部分を意味しており、より大きなリソースデバイスの断片を表す。最大でリソースデバイス全体であり、リソースデバイス全体を含む。リソースノードは、通信パス上で独立したアドレス指定可能なエンティティとして動作することもできる。想定されるリソースノードには、論理パーティション（他の論理パーティションと組み合わせてリソースコンシューマの観点から見た論理ボリュームを構成する）、アドレス指定可能なビデオフレーム、サーバファーム内の個々のＷｅｂサーバ、またはその他の構成要素が含まれる。
【００２２】
本明細書で教示する内容は、ストレージデバイス、またはメディアコンテンツサーバを含むコンピューティングリソースの開発者または製造者によって、高いパフォーマンスおよび迅速な応答を提供する効率的でスケーラブルなシステムを構築するために使用されるのが有利であろう。
【００２３】
本発明の様々な目的、機能、態様、および利点は、以下に示す本発明の好ましい実施形態に関する詳細な説明と添付の図面からより明らかになるであろう。ただし、こうした図面では、類似の番号は類似のコンポーネントを表している。
【発明を実施するための最良の形態】
【００２４】
以下の実施形態に関する詳細な説明は、ストレージアレイ内のディスクとサーバファーム内のＷｅｂサーバに基づく例について言及しており、本発明の主題の適用可能性を例証している。以下の２つの例が使用されているが、他にも無数の例を示すことができるので、こうした例から暗黙的な制限は導かれないものとする。
【００２５】
図１は、リソースコンシューマが１つまたは複数のリソースノードを備えるリソースデバイスと対話する環境を示している。リソースデバイス１１０は、１つまたは複数のリソースノード１００Ａから１００Ｎを備えている。個々のリソースノードは、それぞれ通信パス１１５を介して１つまたは複数のリソースコンシューマ１２０Ａから１２０Ｐと通信接続されている。好ましい実施形態では、多くのリソースコンシューマは多くのリソースデバイスと対話する。
【００２６】
リソースコンシューマ
リソースコンシューマ１２０Ａから１２０Ｐは、互いに独立して動作し、リソースノード１００Ａから１００Ｎによって管理される任意のリソースと対話するために、リソースノード１００Ａから１００Ｎ以外のエンティティからの情報を必要としない。
【００２７】
リソースコンシューマ１２０Ａから１２０Ｐは、リソースデバイス１１０と対話し、リソースノード１００Ａから１００Ｎによって管理されるリソースにアクセスするようにプログラムされた命令をコンピュータ可読メモリ内に含むハードウェア、ソフトウェア、またはファームウェアの組合せを備えている。好ましい実施形態では、リソースコンシューマはリソースにアクセスしようとするアプリケーションまたはオペレーティングシステムを実行するコンピュータを備えている。さらに好ましい実施形態では、リソースコンシューマはワークステーションを備えており、ワークステーションはワークステーションのオペレーティングシステムとリソースノード１００Ａから１００Ｎとの通信を備えるドライバを備えている。ドライバは、さらにオペレーティングシステムにリソースデバイス１００に関する十分な情報を提供し、リソースデバイス１００はローカルに接続されたデバイスとして表示される。例えば、Ｗｉｎｄｏｗｓ（登録商標）コンピュータがストレージ用の論理ボリュームをマウントしようとする。Ｗｉｎｄｏｗｓ（登録商標）コンピュータは、ファイルシステムからＩ／Ｏコマンドを受け取り、これをメッセージに変換するドライバを備えている。変換されたメッセージは、ネットワークを経由してファイルシステムにも論理ボリュームにアクセスするアプリケーションにも透過な方法で、論理ボリュームを構成する論理パーティションに送信される。論理ボリュームは、ローカルに接続されたディスクドライブとして表示される。
【００２８】
一方、リソースコンシューマ１２０Ａから１２０Ｐは、リソースノード１００Ａから１００Ｎと直接対話するアプリケーションを備えていると考えられる。例えば、Ｗｅｂサイトへのゲートウェイは分散型Ｗｅｂサーバファームにアクセスするリソースコンシューマを表すことができ、個々のＷｅｂサーバはリソースノードを表している。
【００２９】
リソースコンシューマ１２０Ａから１２０Ｐは互いに独立して機能するが、リソースノード１００Ａから１００Ｎと集合的にまたは個別に対話する。さらに、リソースコンシューマ１２０Ａから１２０Ｐは、リソースコンシューマ１２０Ａから１２０Ｐまたはリソースノード１００Ａから１００Ｎの外部のシステム（ネームサーバ、メタデータサーバ、またはその他の外部システムを含む）から情報を要求する必要がない。好ましい実施形態では、リソースコンシューマ１２０Ａから１２０Ｐはリソースノード１００Ａから１００Ｎを検出する機能を備えていることが想定されている。検出の機能には、通信パス１１５を経由したブロードキャストメッセージの送信が含まれており、リソースノード１００Ａから１００Ｎはそれぞれの名前を使用してこれに応答する。さらに、好ましい実施形態では、リソースコンシューマ１２０Ａから１２０Ｐは、名前識別（ｎａｍｅ  ｒｅｓｏｌｕｔｉｏｎ）を使用してリソースノード１００Ａから１００Ｎからの応答を通信パス１１５上のアドレスに変換する。検出および名前識別を実行するには、ＳＳＤＰ、ＤＮＳ、ＷＩＮＳなどを含む様々な方法があることを、ネットワークプログラミングの当業者は理解するであろう。
【００３０】
リソースコンシューマ１２０Ａから１２０Ｐがリソースノード１００Ａから１００Ｎとの通信を確立すると、リソースコンシューマ１２０Ａから１２０Ｐはリソースコマンドメッセージをリソースデバイス１１０に送信する。リソースコマンドメッセージは、その全体または一部がリソースデバイス１１０にアドレス指定できる。好ましい実施形態では、リソースコマンドメッセージはマルチキャストを使用してリソースノード１００Ａから１００Ｎに集合的に送信され、全体としてアドレスを指定されるが、リソースデバイス１１０は部分的にアドレス指定されるユニキャストメッセージングも可能であることが想定されている。これに関連して、「マルチキャスト」は通信パス１１５を経由して唯一のメッセージを送信するので、リソースコンシューマは各リソースノードにメッセージの２つ以上のコピーを送信することによって通信パス１１５上の帯域幅を消費する必要なしに、２つ以上のリソースノード１００Ａから１００Ｎがメッセージを受信することを意味する。リソースデバイス１１０は、マルチキャストおよびユニキャストのメッセージングを使用して同時にアドレス指定することもできると考えられる。
【００３１】
各リソースコンシューマ１２０Ａから１２０Ｐは、それぞれに固有のニーズに関するコマンドパラメータを備えるリソースコマンドメッセージを構築する。リソースコマンドメッセージの少なくとも一部は、メッセージが構築されたときにメモリ内に存在することが想定されている。本明細書で使用する限り、「メモリ」という用語は情報を格納する任意のハードウェアを意味しており、メモリが存在する場所も情報が格納される方法も問題ではない。コマンドパラメータには、リソースコンシューマのニーズを満足するために必要な緊急性または重要性に関するリソースコンシューマの認識が含まれる。緊急性は、タイミングに関する制約の認識を示しており、重要性は個々のリソースコンシューマによって要求される優先度の認識を示している。リソースノード１００Ａから１００Ｎは、緊急性または重要性のコマンドパラメータおよびその他のコマンドパラメータを使用して、リソースコマンドメッセージを処理するタイミングの決定を支援する。好ましい実施形態では、リソースコンシューマはその独自の内部情報に基づいて、またはリソースノードからの応答から収集された情報に基づいて、その緊急性または重要性を決定する。さらに、より好ましい実施形態では、コマンドパラメータには関連のリソースコマンドメッセージのグループを相互に関連付けるために使用されるコマンド識別子が含まれる。
【００３２】
リソースコンシューマ１２０Ａから１２０Ｐは、それぞれが１つのリソースコマンドメッセージから２つ以上の応答を受信する機能を備えている。リソースデバイス１１０がリソースノード１００Ａから１００Ｎによって管理される冗長なリソースを備える場合は、リソースノード１００Ａから１００Ｎの２つ以上がメッセージに応答する。各リソースノードは互いに独立して機能しており、すでに応答が生成されているかどうかを認識していないので、複数の応答が予想される。ただし、複数の応答は緊急性または重要性の情報を適切に処理することによって減少される。
【００３３】
好ましい実施形態では、リソースコンシューマ１２０Ａから１２０Ｐはスロースタート（ｓｌｏｗ  ｓｔａｒｔ）アルゴリズムを使用して輻輳（ｃｏｎｇｅｓｔｉｏｎ）を回避し、帯域幅の効率的な利用を保証すると同時に、リソースノードからの複数の応答を減少する。初めにサイズの小さいリソースコマンドメッセージを低速で送信することにより、リソースコンシューマ１２０Ａから１２０Ｐはリソースノード１００Ａから１００Ｎのいずれが最初に応答する可能性が高いかを判定し、次に個々のリソースコンシューマ１２０Ａから１２０Ｐがそれぞれの緊急性と重要性の情報を独自に調整することによって複数の応答の減少を支援することができる。例えば、スロースタートアルゴリズムは大きなコマンドメッセージを小さなコマンドメッセージに分割し、この小さなコマンドメッセージを低速で送信することができる。応答が受信されると、このアルゴリズムはより大きなメッセージのより高速での送信を開始する。スロースタートは、ネットワーク機器が小さなバッファを備える場合に、大きなパケットによるフラッド（ｆｌｏｏｄｅｄ）が実行されないことを保証する。このような機器でフラッドが実行されると、ネットワークパフォーマンスが低下する。さらに、スロースタートは初めにどのリソースノードの応答性が高いかを検知する機会をリソースコンシューマに提供する。初めにパケットが低速で送信されるときに、リソースノードからの複数の応答が許可される枠（ｗｉｎｄｏｗ）が提供される。リソースコンシューマは、複数の応答を使用してリソースの優先されるプロバイダ（ｐｒｅｆｅｒｒｅｄ  ｐｒｏｖｉｄｅｒ）を決定することができる。さらに、通信速度が向上すると、優先されるプロバイダの情報が使用され、複数の応答が消去される。
【００３４】
リソースデバイス
リソースデバイス１１０は、１つまたは複数のリソースノードを備えている（リソースノード１００Ａから１００Ｎとして図示されている）。図１は唯一のリソースデバイスを示しているが、通信パス１１５上に複数のリソースデバイスが共存することが考えられる。
【００３５】
リソースデバイス１１０は、１つまたは複数のリソースコンシューマ１２０Ａから１２０Ｐからアクセスできるので、リソースデバイス１１０は共有リソースでもよいことが想定されている。好ましい実施形態では、リソースデバイス１１０にはリソースノード１００Ａから１００Ｎ上に存在する情報が含まれており、リソースデバイス１１０が私的に所有されているか、またはリソースコンシューマ１２０Ａから１２０Ｐ間で共有されている場合を示している。
【００３６】
リソースデバイス１１０は、リソースデバイス１１０を通信パス１１５上のその他のリソースデバイスと区別するためにリソースコンシューマ１２０Ａから１２０Ｐによって使用される識別子を備えている。好ましい実施形態では、こうした識別子にはリソースノード１００Ａから１００Ｎのメモリ内に格納される名前が含まれており、名前によって通信パス１１５上のアドレスを割り出すことができる。リソースコンシューマ１２０Ａから１２０Ｐが検出要求を発行すると、リソースノード１００Ａから１００Ｎは名前を使用して応答する。こうした名前にはリソースデバイス１１０の名前が含まれており、リソースノードがリソースデバイス１１０に属することを示している。特に好ましい実施形態では、名前識別によってＩＰアドレス（ユニキャストまたはマルチキャストのアドレスを含むことができる）が特定される。リソースコンシューマ１２０Ａから１２０Ｐは１つのアドレスからリソースデバイス１１０のアドレス（ＩＰマルチキャストアドレスが好ましい）を特定できることが想定されている。
【００３７】
好ましい環境では、リソースデバイス１１０は冗長なリソースノードを備えており、２つ以上のリソースノード１００Ａから１００Ｎが重複するリソースを管理している。例えば、リソースデバイス１１０がリソースコンシューマ１２０Ａから１２０Ｐによってデータを格納するために使用される論理ボリュームを表す場合に、リソースノード１００Ａとリソースノード１００Ｂは同じ格納データをミラーリングする論理パーティションを表すことができる。さらに別の例では、リソースデバイス１１０が論理Ｗｅｂサーバであり、リソースノード１００Ａから１００Ｎは個々のサーバであって到着する接続要求コンテンツを処理する同等の能力を備えている。
【００３８】
冗長なリソースノードを備えるリソースデバイスの例として、Ｚｅｔｅｒａ（登録商標）テクノロジーに基づいて実装され、論理ボリューム（リソースデバイス）がＩＰアドレスを指定できる複数の論理パーティション（リソースノード）として仮想化されたストレージアレイについて考察する。論理ボリュームは、１から最大値ＭＡＸまでの論理ブロックアドレス（ＬＢＡ：ｌｏｇｉｃａｌ  ｂｌｏｃｋ  ａｄｄｒｅｓｓｅｓ）が割り当てられた１つの仮想ディスクを表している。各論理パーティションはＬＢＡのセットを管理しており、必ずしも連続でなくてもよいが、論理パーティションの集合はＬＢＡ  １からＭＡＸまでの範囲全体をカバーする。さらに、２つ以上の論理パーティションが同じＬＢＡのセットを管理する場合は冗長であり、したがってデータのミラーリングが提供される。ワークステーションは、論理ボリュームをローカルに接続されたディスクドライブと同様にマウントする。ドライバは、唯一のアドレスを使用してネットワーク経由ですべての論理パーティションにマルチキャストを使用してコマンドメッセージを送信する論理パーティションとのすべての通信を処理する。
【００３９】
冗長なノードを備えるリソースデバイスの別の例は、各サーバが同一のコンテンツをブラウザに表示できるＷｅｂサーバファームである。ゲートウェイは、インターネット経由で到着したコマンドメッセージによる要求をサーバ（複数）に集合的に送信する。最初に応答するサーバは接続を処理する。
【００４０】
リソースデバイス１１０は、プロセッサ帯域幅、ディスプレイ、メモリ、表示可能なコンテンツ（ｓｅｒｖａｂｌｅ  ｃｏｎｔｅｎｔ）、接続処理（ｃｏｎｎｅｃｔｉｏｎ  ｈａｎｄｌｉｎｇ）、ネットワーク帯域幅、またはこれ以外の関連コンピューティングリソースを含む他のコンピューティングリソースを表すことができると考えられる。
【００４１】
通信パス
通信パス１１５は、リソースコンシューマ１２０Ａから１２０Ｐおよびリソースノード１００Ａから１００Ｎ間のアドレス指定およびデータ転送をサポートする。通信パス１１５は、リソースノードからもリソースコンシューマからも直接管理されないことが想定されているが、リソースコンシューマ１２０Ａから１２０Ｐまたはリソースノード１００Ａから１００Ｎは通信パス１１５の動作を変更できることが想定されている。さらに、通信パス１１５は通信パスの信頼性を低下する特性を備えていると考えられる。
【００４２】
好ましい実施形態では、通信パス１１５はインターネットプロトコルを搬送するＥｔｈｅｒｎｅｔ（登録商標）通信を備えるパケット交換ネットワークを備えている。好ましい実施形態では、リソースコンシューマ１２０Ａから１２０Ｐおよびリソースノード１００Ａから１００ＮはＤＨＣＰを使用してＩＰアドレスを取得する。
【００４３】
リソースノード
図２は、予想されるリソースノードの物理的実施形態を示している。リソースノード２００は、リソースコンシューマから通信パス１１５を経由してリソースコマンドメッセージを受信する。プロセッシングユニット２１０は、リソースコマンドメッセージを受信し、メモリ２２０内に格納されたコマンドキュー２３０を使用してメッセージ内のコマンドを処理する。メッセージ内のコマンドは、コマンド２３３Ａから２３３Ｎで表されるコマンドキュー２３０に配置されている。プロセッシングユニット２１０は、コマンドキュー２３０またはリソースノードデータ２４０を含むメモリ２２０内に格納されたリソースノード情報に従ってコマンド２３３Ａから２３３Ｎを処理する。プロセッシングユニット２１０がコマンド２３３Ａから２３３Ｎを処理するときに、プロセッシングユニット２１０はリソース通信パス１１５を経由してリソース２６０Ａから２６０Ｍにアクセスする。
【００４４】
メモリ２２０内に格納されたリソースノード情報は、リソースノード２００が他のリソースノードに関係なく機能でき、一連の主要な責務に照準を合わせることができるために十分な情報を備えることが想定されている。好ましい実施形態では、プロセッシングユニット２１０とメモリ２２０を備えるハードウェアの１つのエレメントは、１つまたは複数のリソースノードにサービスを提供する。例えば、データストレージリソースを備えるディスクドライブは、メモリとプロセッシングユニットを使用して多くの論理パーティションを提供し、各パーティションに独自のＩＰアドレスを割り当ててそれぞれがＬＢＡセットを管理するように構成できる。一方、複数のディスクドライブをサポートするラックマウント型エンクロージャには、プロセッシングユニット２１０を構成する１つまたは複数のＣＰＵと、メモリ２２０を構成する１つまたは複数のＲＡＭモジュールを含めることができる。これで、ラックマウント型エンクロージャは複数のディスクドライブを管理する多くの論理パーティションを提供することができる。また、リソースノード２００は唯一のリソースを表すこともできることも想定されている。例えば、アドレスを割り当てられた１つの論理パーティションはディスクドライブ全体を管理することができる。
【００４５】
リソース通信パス２１５は、プロセッシングユニット２１０とリソース２６０Ａから２６０Ｍとの間のアドレス指定およびデータ転送を提供する。好ましい実施形態では、リソース通信パス２１５はディスクドライブ通信バスを備えている。ディスクバスの例には、ＡＴＡ、ＳＣＳＩ、ファイバチャネル、ＵＳＢ、またはその他現存するものやまだ発明されていないものが含まれる。さらに、リソース通信パス２１５にはパケット交換ネットワークを含めることができるとも考えられる。例えば、リソースノード２００がコンテンツサーバである場合に、リソース通信パス２００はコンテンツを格納するストレージアレイへのＩＰネットワークでもよい。
【００４６】
リソースノード２００は、個々のリソースコマンドメッセージに含まれる緊急性または重要性の情報の解釈と、メモリ２２０内に格納されたリソースノードの情報の解釈に基づいて、コマンド２３３Ａから２３３Ｎを処理するタイミングを決定する。リソースノード２００は、それ自体に関する情報を使用してコマンドを自律的に処理する適切な方法を決定する。リソースノード２００に関する情報には、コマンドを処理する能力、容量、負荷、コマンドキューの順序、コマンドキューに配置された先行するコマンド、またはリソースコンシューマから送信されたリソースコマンドメッセージのサービスに影響を及ぼすその他の関連情報が含まれる。例えば、リソースノード２００が１００％の容量で機能して多くのリソースコンシューマにサービスを提供している場合は、現在の負荷を処理しながら現在のリソースコマンドメッセージを報告なしに（ｓｉｌｅｎｔｌｙ）廃棄することによってこのサービスを行わないことを決定できる。リソースコンシューマは、送信したリソースコマンドメッセージが廃棄された場合に、場合によってはメッセージの緊急性または重要性を調整した別のコマンドを送信するか、または別のリソースノードの応答を待つことができる。
【００４７】
メモリ２２０内に格納されたリソースノード２００に関連する情報には、リソースノード２００の動作を決定する命令およびデータを含めることができるのが有利である。特に好ましい実施形態では、リソースノードのデータ２４０にはリソースコンシューマがリソースデバイス全体についての理解を確立するために使用する情報（リソースノードが属するリソースデバイスの名前、リソースノードの名前、リソースノードがリソースデバイス内で果たす役割、属性、またはリソースノードに関するその他の情報を含む）が含まれる。これは、リソースノードデータ２４０がリソースデバイス情報も表すことを意味している。
【００４８】
好ましい実施形態では、リソースノード２００はその責務の処理に照準を合わせ、それ以外の作業を実行しないことによって、リソースデバイスの望ましい特性を高めることができる。これで、リソースノード２００はサービス要求に対してその機能を十分に活用でき、パフォーマンスにも応答性にも悪影響を及ぼさない。さらに、リソースノード２００の複製はリソースコンシューマの観点から高度な機能を提供する。
【００４９】
冗長なリソースノード
冗長なリソースノードは、ほとんど同等のリソースへのアクセスを提供するリソースノードである。冗長なリソースノードは、例えばリソースノードデータ２４０、名前、またはアドレスによって区別できる。ただし、冗長なリソースノードはそれぞれ同じタイプのリソースを管理し、リソースコマンドメッセージのサービスを行う上で、負荷、機能、またはその他の能力に関して同等の能力を備えている。冗長なリソースノードの例には、同等のコンテンツのサービスを実行できる別々のディスク上または２台のＷｅｂサーバ上の論理ボリューム内にある同じＬＢＡのセットを管理する論理パーティションが含まれる。好ましい実施形態では、冗長なリソースノードは同じマルチキャストグループに加わることができ、リソースコンシューマはこれらに同時にアドレス指定できる。
【００５０】
好ましい実施形態では、リソースコンシューマはリソースコマンドメッセージを実際にどのリソースノードが処理するかに関係なく、リソースデバイスのリソースノードにリソースコマンドメッセージを送信する。冗長なリソースノードの場合は、リソースコマンドメッセージは冗長なリソースノードによって実質的にパラレルに処理される可能性が高い。本明細書で使用する限り、「実質的にパラレルに」という表現は、少なくとも２つのリソースノードが通信パスとリソースノードのタイミング特性により、リソースコマンドメッセージを１０秒以内に次々に処理することを意味する。タイミング特性には、待ち時間、ノードの負荷、またはリソースコンシューマまたはリソースノードによって直接指定されるものを含めて処理時間に影響を及ぼすその他のパラメータが含まれる。
【００５１】
冗長なリソースノードでは、リソースコマンドメッセージに対して複数の応答が生成される可能性があり、このことによって場合によっては帯域幅が消費されることが想定されている。好ましい実施形態では、リソースノードおよびリソースコンシューマは、複数の応答の消去を試みる形で対話する。リソースコンシューマは、さらに複数の応答が予想される複数のリソースコマンドメッセージの交換を開始できることが想定される。好ましい実施形態では、リソースコンシューマは応答するリソースノードの中から優先されるプロバイダを選択し、さらに優先されるプロバイダの情報を後続のリソースコマンドメッセージの緊急性に挿入する。リソースノードが優先されるプロバイダである場合は、リソースコマンドメッセージを正常に処理する。リソースノードが優先されるプロバイダでない場合は、処理を遅延させる。優先されるプロバイダが応答する場合は、リソースコンシューマは次のメッセージを送信する。優先されるプロバイダ以外のリソースノードは、次のメッセージを受信し、以前に送信された保留中のコマンドをキャンセルする。さらに、現在のコマンドはコマンドキュー内で先行するコマンドの位置を引き継ぐことも想定される。
【００５２】
リソースコマンドメッセージは、関連のコマンドのグループを識別するために使用されるコマンド識別子を備えることができることが想定されている。こうした状況において、リソースノードがそのコマンドキュー内にコマンドを保持しており、関連する追加のコマンドを受信した場合に、リソースノードはこの連続するイベントを先行するコマンドの処理（コマンドの削除を含めて）を中断する命令と解釈できるので、予想される複数応答の数が減少する。
【００５３】
リソースノード２００は、リソースコマンドメッセージに含まれるコマンドおよびコマンドパラメータに基づいて、コマンドを実行すること、または今後の利用に備えてリソースを予約することができる。コマンドを実行すると、実際にリソースコマンドメッセージに対するサービスが提供される。リソースを予約すると、リソースコンシューマは複数のリソースノードの能力を集約することができる。
【００５４】
リソースコマンドメッセージ
図３は、予想されるリソースコマンドメッセージの概略を示している。リソースコマンドメッセージ３００は、コマンドパラメータ３３０を伴うコマンド３２０を備えており、これがリソースノードによって処理される。好ましい実施形態では、リソースコンシューマはリソースデスティネーションアドレス（ｒｅｓｏｕｒｃｅ  ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓ）３１０を使用してリソースコマンドメッセージ３００をリソースデバイスまたはリソースノードに送信する。リソースコマンドメッセージ３００には、オプションでデータ３４０も含まれる。例えば、コマンド３２０がディスクドライブへの書き込みコマンドを指定する場合はデータ３４０が存在する。ただし、データ３４０は書き込みの対象となるデータを表す。好ましい実施形態では、リソースコマンド３２０はコマンドの緊急性の情報３３５またはコマンドの重要性の情報３３７を備えている。さらに好ましい実施形態では、リソースコマンド３２０はコマンド識別子３３３を備えている。用語「指定する（ｉｎｄｉｃａｔｅｓ）」は、本明細書で使用する限り、何かが解決（ｒｅｓｏｌｖｅｄ）されて他の何かが得られることを意味する。したがって、「コマンド３２０は書き込みコマンドを指定する」は、「コマンド３２０が解決されて書き込みコマンドが得られる」ことを意味する。
【００５５】
リソースコンシューマは、リソースコマンドメッセージ３００をコンピュータ可読メモリ内に構築し、リソースコマンドメッセージ３００の少なくとも一部はメモリ内に存在する。リソースコマンドメッセージ３００は、いったん構築されると、リソースコンシューマとリソースノードを接続する通信パスを経由して送信される。リソースコマンドメッセージ３００は、構築されている間に送信できることも想定される。好ましい実施形態では、リソースコマンドメッセージ３００はデータグラム（ｄａｔａｇｒａｍ）にカプセル化され、パケット交換ネットワークを経由して送信される。特に好ましい実施形態では、リソースコマンドメッセージ３００はユーザデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）を使用してトランスポート（ｔｒａｎｓｐｏｒｔ）として送信される。ＵＤＰは伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）に比べて処理のオーバヘッドが削減されており、１つのコマンドの情報が別のコマンドの処理には必要ないアトミックな（ａｔｏｍｉｃ）コマンド構造に適する。想定されるコマンドには、Ｉ／Ｏ処理の実行、データの読み出し、データの書き込み、リソースの割り当て、リソースの予約、リソースの管理、リソースの状態の確認、リソースのインベントリの管理、リソースのイベントの記録、リソースのロック、またはリソースに関連するその他の操作が含まれる。リソースノードは、コマンドパラメータ３３０をノード自体の情報と組み合わせて使用し、コマンド３２０を処理するタイミングを決定する。
【００５６】
コマンド識別子
コマンド識別子３３３は、関連する２つ以上のコマンドをグループ分けするための情報を備えている。コマンド識別子３３３は、コマンドのグループごとに固有の値を含んでいることが想定されている。コマンドは、様々な理由によってグループ分けされる。例えば、ファイルシステムがミラーリングされた複数の論理パーティションを備える論理ボリュームから読み出す多くのＬＢＡを備えるファイルデータを要求する場合に、ドライバは要求をＬＢＡごとの個別のリソースコマンドメッセージまたは関連するＬＢＡのグループのリソースコマンドメッセージに分割する。ミラーリングされた個々の論理パーティションは、個々のリソースコマンドメッセージに応答して複数の応答を生成する可能性がある。ただし、リソースノードがコマンド識別子３３３によって識別されるコマンドグループ内で新しい読み出しコマンドを検出すると、リソースノードは先行するコマンドの処理を中断し、先行するリソースコマンドメッセージへの複数の応答の可能性を低下させる。また、リソースノードは現在実行中のコマンドの処理を停止すること、または処理されたコマンドの応答を中断することができるとも考えられる。好ましい実施形態では、コマンド識別子３３３はＩＤ番号またはシーケンス番号を備えている。
【００５７】
コマンド識別子３３３は、一連の入札応答（ｂｉｄ−ｒｅｓｐｏｎｓｅ）トランザクションを表すとも考えられる。例えば、Ｗｅｂサーバゲートウェイに１台のＷｅｂサーバの能力を超える要注意の接続が多数存在する。ゲートウェイは、接続の数を示すデータ３４０とコマンド識別子３３３を伴うリソースコマンドメッセージ３００をリソースノードとして動作するすべてのＷｅｂサーバに送信する。応答可能なＷｅｂサーバは、それぞれ容量を予約して応答を送信する。ゲートウェイはこうした応答を統合し、同じコマンド識別子３３３を伴う後続のコマンドを送信することによって、関与するＷｅｂサーバに対して接続を処理するように命令する。さらに、関与しないＷｅｂサーバは後続のコマンドを同じコマンド識別子３３３を伴うコマンドの処理を停止する命令と解釈する。
【００５８】
緊急性
緊急性３３５（本明細書で名詞として使用される場合）は、コマンド３２０を処理するタイミングに関連する情報を備えている。リソースノードは、コマンドが実際に処理されるタイミングとコマンドキュー内のコマンドの順序を、緊急性３３５から推測することが想定されている。予想される緊急性には、相対的なタイミング情報または絶対的なタイミング情報が含まれる。相対的なタイミング情報には、時間枠内に処理する必要があるという指定が含まれる。絶対的なタイミング情報には、リソースコンシューマの観点またはリソースノードの観点から特定の時間に処理するという指定が含まれる。
【００５９】
リソースノードは、同様に緊急性３３５をノード自体の情報と組み合わせる。好ましい実施形態では、緊急性３３５にはリソースコンシューマの優先されるプロバイダが含まれている。優先されるプロバイダに一致するリソースノードは、優先されるプロバイダに一致しないリソースノードより緊急性が高いと推論される。例えば、優先されるプロバイダリソースノードはコマンドを正常に処理するが、優先されないプロバイダリソースノードはコマンドの処理を遅延させる。このアプローチには、複数の応答が減少することによって帯域幅が節約される、また、元の優先されるプロバイダがすぐに応答できない場合に別のリソースノードが優先されるプロバイダとして引き継ぐことができるので高い応答性が保証されるといったいくつかの利点がある。
【００６０】
重要性
重要性３３７（本明細書で名詞として使用される場合）は、コマンド３２０を処理する優先度に関連する情報を備えている。重要性には、相対的な優先度または絶対的な優先度が含まれることが想定されている。相対的な優先度にはサービスの品質（ＱｏＳ：ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）の情報が含まれる。絶対的な優先度には、多くの場合にコマンドキューに関連付けられた個別のレベルが含まれる。リソースノードは、複数のリソースコンシューマから送信されたリソースコマンドメッセージを処理し、重要性の情報を使用してコマンドの処理順序を解決することが想定されている。
【００６１】
リソースノードは、緊急性３３５または重要性３３７を含むコマンドパラメータを使用してコマンドの最終的な処理順序を決定する。
【００６２】
コマンドキュー
図４は、予想されるリソースノードコマンドキューの概略を表している。コマンドキュー４００は、１つまたは複数のコマンド位置４１５Ａから４１５Ｚを備えており、位置の数はリソースノードの実装によって決まる。
【００６３】
図４は、コマンドキューの一般的な表現を示しているが、こうしたデータ構造でなくても一連のコマンドの処理順序を決定する多くの方法が考えられることを当業者は理解するであろう。「コマンドキュー」は、本明細書で使用する限り、コマンドの任意の処理順序を含むように広義に解釈されるものとする。コマンドキューの例には、時間の順、優先度の順、先着順（ｆｉｒｓｔ  ｃｏｍｅ  ｆｉｒｓｔ  ｓｅｒｖｅ）、保留中のコマンドと実行中のコマンドのみ、またはリソースノードによって決定されたこれ以外の順序が含まれる。
【００６４】
リソースノードは、コマンドを処理するタイミングに基づいて、コマンドの順序または順序変更を決定する。リソースノードの情報、コマンドの緊急性または重要性に基づいて順序が決定されると、リソースノードはコマンドキュー４００内の適切な位置にコマンドを配置することによってキューの順序変更を行う。「位置」は、本明細書で使用する限り、保留中または実行中の他のコマンドに対するコマンドの相対的な順序の概念を含むように広義に解釈されるものとする。リソースノードは、コマンドキュー４００を操作する機能を備えている。さらに、順序付けではリソースノードがコマンドを処理しない、したがって、コマンドはキューに入らないという指定が可能である。この概念には、リソースノードに多くの負荷があるために、入ってくるメッセージをリソースノードが処理できない状況も含まれる。したがって、リソースノードがコマンドを処理する「タイミング」を決定するという概念には、リソースコマンドメッセージを無視することも含まれる。
【００６５】
好ましい実施形態では、コマンドキュー４００は一般的に先着順のキューであり、リソースノードはＱｏＳ、優先されるプロバイダの情報、またはコマンド識別子に基づいてコマンドの位置を変更する。
【００６６】
リソースコマンドメッセージの処理
図５は、リソースノードがコマンドキューのメッセージを処理するために使用する予想される一連のステップを示している。リソースコンシューマはリソースコマンドメッセージを１つまたは複数のリソースノードに送信する。したがって、複数のリソースノード（冗長なノードであるのが好ましい）がリソースコマンドメッセージを受信する場合に、図５に示すステップは実質的にパラレルに実行される。
【００６７】
ステップ５００で、リソースノードはリソースコマンドメッセージを受信する。リソースコマンドメッセージは、個々のノードへのアドレス指定またはリソースノードセットへの集合的なアドレス指定が可能である。好ましい実施形態では、リソースノードはリソースコマンドメッセージをユニキャストまたはマルチキャストのＩＰアドレスで受信する。リソースノードは、その負荷が大きい場合はリソースコマンドメッセージを受信できないことが想定されている。この場合は、別のリソースノードがこれを処理するか、またはリソースコンシューマがリソースメッセージの再送を試みる。
【００６８】
ステップ５０５で、リソースノードはリソースコマンドメッセージの評価を開始する。リソースノードは、該当する場合にリソースコマンドメッセージ内の緊急性の情報を解釈する。緊急性の情報には、直接的な情報または間接的な情報が含まれる。直接的な情報には、コマンドが処理されるべき時間への参照が含まれる。例えば、直接的な情報にはリソースコンシューマの望ましい緊急性の指定が絶対的な時間または相対的な時間として含まれている。間接的な情報には、リソースノードが緊急性の情報に基づいて時間を推定するための参照が含まれている。例えば、リソースコマンドメッセージに優先されるプロバイダの情報が含まれている場合に、リソースノードはコマンドが処理されるタイミングを変更できる。
【００６９】
ステップ５１０で、リソースノードはリソースコマンドメッセージの評価を継続し、該当する場合に重要性の情報を解釈する。緊急性の情報を解釈するステップと同様に、重要性の情報にも直接的な情報または間接的な情報が含まれる。直接的な情報には、絶対的な優先度または相対的な優先度の情報が含まれる。間接的な情報には、ＱｏＳの情報が含まれる。ＱｏＳの情報は、リソースノードに対してコマンドを他のコマンドより優先的に処理してパフォーマンスを向上するように指示する。
【００７０】
ステップ５１５で、リソースノードはノード自体に関連する情報を収集し、リソースコマンドメッセージ内のコマンドが処理されるべきタイミングについて最終的な決定を行う。想定されるリソースノード情報には、負荷の情報、機能、先行するコマンド、コマンドキュー内のコマンド、またはリソースノードに関するその他の情報が含まれる。
【００７１】
先行するステップの順序は変更が可能であり、必ずしも提示された順序に従う必要はないことを当業者は理解するであろう。
【００７２】
ステップ５２０で、リソースノードは自らのリソースノード情報を緊急性または重要性の情報から解釈される情報と組み合わせてリソースコマンドメッセージ内のコマンドが処理されるべきタイミングを決定する。ステップ５３３で、リソースノードはコマンドを本当に処理すべきかどうかを決定する。処理しない場合は、ステップ５３５でリソースノードはコマンドメッセージを報告なしに廃棄する。好ましい実施形態では、リソースノードはリソースコマンドメッセージが廃棄されるかどうかを自律的に決定し、リソースコンシューマはそのリソースに関するニーズが満たされることを保証する責任を負う。リソースノードの負荷が高い場合、リソースノードのコマンドキューに空きがない場合、リソースノードのリソースが予約されている場合、またはその他の原因によってリソースノードがコマンドを処理するのが望ましくない場合は、リソースノードがコマンドを廃棄することが想定されている。廃棄された場合は、ステップ５００で、リソースノードは再び他のリソースコマンドメッセージを受信するまで待機する。
【００７３】
コマンドが処理されるべきであるとリソースノードが決定した場合は、ステップ５４３でコマンドが遅延されるべきかどうかを決定する。コマンドは、リソースノードが優先されるプロバイダではない、コマンドが処理される時間をリソースコンシューマが明確に要求しているなど、いくつかの理由で遅延される可能性がある。コマンドが遅延される場合は、ステップ５４５でリソースノードはコマンドが遅延される時間を決定する。また、リソースノードは、現在のコマンドを優先して実行中のコマンドをキャンセルすることによってコマンドの処理を高速化することができるとも考えられる。
【００７４】
コマンド処理の条件を操作した後に、ステップ５５３でリソースノードは保留中のコマンドを中断するかどうかを決定する。コマンドが有効ではなくなっている場合は（コマンドのコマンドパラメータによる情報で決定される）、保留中のコマンドが中断される。現在のコマンドがコマンド識別子によってそれ自体を保留中のコマンドが属するグループの一部と識別した場合に、ステップ５５５でリソースノードは現在のコマンドを保留中のコマンドの中断命令と解釈することができる。中断には、保留中のコマンドの処理をさらに遅延させる、停止させる、保留中のコマンドをコマンドキューから削除する、保留中のコマンドを削除する、または保留中のコマンドの処理時間を変更する結果となるその他のアクションが含まれる。
【００７５】
ステップ５６５で、リソースノードはコマンドが処理されるべきタイミングの決定を完了し、リソースノードはこのコマンドをコマンドキュー内に配置する。好ましい実施形態では、コマンドキューの順序は優先度、緊急性、またはコマンド識別子に基づき、リソースノードによって変更される。コマンドキューを具体化するには、本明細書で説明した以外に多くの方法があることを当業者は理解するであろう。リソースノードは、コマンドをコマンドキュー内の絶対位置または相対位置に挿入することが想定されている。例えば、コマンドキューの位置の数が設定されている場合に、絶対位置は標準的なキューへの固有のインデックスを表す。絶対位置の例には、現在実行中のコマンド位置、最初の位置、または最後の位置が含まれる。相対位置は、多くの場合に、時間または優先度によって順序付けられた位置、キュー内の他のコマンドに対する相対的な位置を表す。
【００７６】
ステップ５７０で、リソースノードは該当する場合にコマンドを実行する。さらに、該当する場合は、ステップ５７５でリソースノードがリソースコマンド応答メッセージをリソースコンシューマに送信する。好ましい実施形態では、この応答にコマンドが処理されることの確認、要求されるデータ、またはコマンドを処理するための能力の指定が含まれる。さらに好ましい実施形態では、リソースノードはリソースコンシューマから要求されたリソース割り当ての少なくとも一部を予約し、その能力の指定をリソースコンシューマに通知する。例えば、リソースコンシューマが１００ギガバイトのデータの格納を要求する場合に、リソースノードは５０ギガバイトを格納できるという指定で応答できる。リソースノードは、５０ギガバイトを予約することによって、リソースコンシューマが他のリソースノードの能力を統合して１００ギガバイトを確保できるようにすることができる。
【００７７】
リソースコマンド応答メッセージは、他のリソースノードで受信した場合は、リソースコマンドメッセージ内のコマンドの処理を中断する命令と解釈できることも想定されている。ソフトウェアまたはファームウェア開発の当業者は、ステップ５７０がメッセージ処理のステップとパラレルなスレッドまたはタスクとして実行できることを理解するであろう。
【００７８】
好ましい実施形態では、図５に示されるリソースノードのステップはプロセッシングユニットで実行される一連の命令としてコンピュータ可読媒体に格納される。ファームウェアまたはソフトウェア開発の当業者は、こうしたステップを実装するには多くの予想される方法が存在するが、こうした方法はすべて本発明の主題の範囲を逸脱しないことを理解するであろう。さらに別の好ましい実施形態では、複数のリソースノードがリソースコマンドメッセージを実質的にパラレルに処理することが想定されている。さらに好ましい実施形態では、複数のリソースノードがリソースコマンドメッセージを３秒以内に次々に処理する。
【００７９】
リソースデバイスへのアクセス
図６は、リソースコンシューマとリソースノードがリソースにアクセスできるようにするために使用する予想される一連のステップを示している。リソースコンシューマは、１つまたは複数のリソースノードを備えるリソースデバイスにリソースコマンドメッセージを送信する。好ましい実施形態では、１つまたは複数のリソースコンシューマは互いに無関係にステップを実行し、場合によっては同じリソースノードと対話することが想定されている。
【００８０】
ステップ６００で、リソースコンシューマはコンピュータ可読メモリ内でリソースコマンドメッセージを構築するプロセスを開始する。リソースコンシューマは、リソースコマンドメッセージ内のコマンドに関連付けられた緊急性に対してリソースコンシューマが希望する意味（ｓｅｎｓｅ）を設定する。ステップ６０５で、リソースコンシューマはコマンドの重要性を設定する。該当する場合は、現在のリソースコマンドメッセージに対してステップ６００および６０５の両方が実行される。ステップ６１０で、リソースコンシューマはオプションで現在のコマンドが先行するコマンドまたは後続のコマンドにどう関連するのかを示すコマンド識別子を割り当てる。ステップ６００、６０５、または６１０は、任意の順序で実行できる。
【００８１】
ステップ６１５で、リソースコンシューマはコマンド、コマンド識別子を含むコマンドパラメータ、緊急性、または重要性に基づいて、リソースコマンドメッセージを構築する。
【００８２】
ステップ６２０で、リソースコンシューマはリソースデバイスにリソースコマンドメッセージを送信する。好ましい実施形態では、リソースコマンドメッセージは１つまたは複数のパケットとして構成され、パケット交換ネットワークを経由して送信される。特に好ましい実施形態では、ＵＤＰを使用してパケットが送信される。さらに、リソースコンシューマがリソースコマンドメッセージを送信する場合に、リソースコンシューマはリソースノードのグループまたはすべてのリソースノードに集合的にメッセージを送信するのが好ましい。好ましい実施形態では、リソースコマンドメッセージはマルチキャストを使用して送信され、各リソースノードはアドレスがリソースデバイスを示すマルチキャストグループのメンバーである。リソースコマンドメッセージは、リソースコンシューマとリソースノードを接続する通信パスの輻輳を回避するために、初めは低速で送信されることが想定されている。ＴＣＰを含むネットワークプロトコルの当業者は、スロースタートによって輻輳が回避されることを理解するであろう。
【００８３】
ステップ６２５で、リソースノードはリソースコマンドメッセージを受信し、メッセージの処理を開始する。好ましい実施形態では、複数のリソースノードが同じリソースメッセージを受信できる。さらに、より好ましい実施形態では、複数のリソースノードが同等にコマンドを処理し、リソースコマンドメッセージを送信したリソースコンシューマに応答を返すことができる。
【００８４】
ステップ６３０で、リソースノードは、緊急性、重要性、またはコマンド識別子の情報とリソースノード自体に関する情報を使用して、コマンドが処理されるべきタイミングを決定する。ステップ６３３で、リソースノードは先行するコマンドの処理が中断されるべきかどうかを決定する。中断される場合は、ステップ６３５で、先行するコマンドが中断され、中断されない場合はステップ６４０で現在のコマンドがコマンドキューに挿入される。コマンドが処理される順番になると、ステップ６４５でリソースノードがコマンドを実行し、ステップ６５０で適切な応答を送信する。
【００８５】
好ましい実施形態では、ステップ６５５で、リソースコンシューマは複数のリソースノードから複数の応答を受信できる。この場合、複数のリソースノードは冗長な機能を提供する。この場合に、リソースコンシューマは複数のノードの中から優先されるリソースノードを選択できる。特に好ましい実施形態では、優先されるリソースノードは冗長なノードの中で最初に応答したノードを基準として選択される。複数のリソースノードを備えるリソースデバイスと対話する各リソースコンシューマは、まったく異なる優先されるプロバイダを指定することができる。さらに、環境の条件が変化するにつれて、優先されるプロバイダも変わることができる。したがって、指定された任意の時間に、外部管理を課することなしにリソースコンシューマは必然的に一定のパフォーマンス、負荷分散、または応答性を実現する。
【００８６】
好ましい実施形態では、図６に示されるステップはプロセッシングユニットで実行される命令の形でコンピュータ可読媒体に格納される。
【００８７】
利点
リソースコンシューマと１つまたは複数のリソースノードを備えるリソースデバイスは、リソースコマンドメッセージを使用することによる必然的な結果として、多くの利点を実現できる。
【００８８】
さらなるリソースデバイスまたはリソースノードがシステムに追加されると、リソースの規模は必然的に拡大される。個々のリソースノードはその主要な責務とリソースコマンドメッセージの処理に照準を合わせているので、リソースノードは自律的であり、リソースコマンドメッセージを処理する通信パスの能力まで、アトミックレベルでシステムの規模を拡大することができる。通信パスの帯域幅はより効率的に使用される。これは、すべてのトラフィックがシステムの管理または保守でなく、リソースへのアクセスに関連するためである。さらに、リソースシステムがさらなる機能を必要とする場合に、リソースシステム全体の複製とは対照的に、個々のリソースノードを追加すればよいため、コストの増大が抑制される。
【００８９】
さらなる冗長なノードがシステムに追加されると、リソースのパフォーマンスと応答性の両方が向上する。リソースコンシューマは、リソースコマンドメッセージを複数のリソースノードに集合的に送信するので、複数のリソースノードが応答できる。個々のリソースノードに異なる負荷が割り当てられているので、最も応答性の高いリソースノードが最初に応答し、結果として応答時間が最短になる。さらに、複数のリソースノードは（必ずしも冗長なノードではない）、リソースコマンドメッセージを実質的にパラレルに処理し、リソースコンシューマに高いパフォーマンスを提供する。リソースコンシューマは、重要性の情報を使用してコマンドの処理に関して考慮すべき優先度をリソースノードに対して指定する。重要性の情報は、ＱｏＳデータの処理を支援する。複数の応答は、スロースタートによって減少されるので、輻輳が回避され、帯域幅消費が制限される。さらに、リソースコンシューマはそれぞれのリソースノードに固有のビューを備えており、冗長なリソースノードで動作する場合に優先されるプロバイダを独自に選択することによって、最短の応答時間と複数メッセージの減少の保証を支援する。
【００９０】
各ノードは独自に機能しており、各ノードのそれぞれが処理するように設計されただけのトラフィックを処理できるので、冗長なリソースノードの必然的な結果として負荷分散が実現される。リソースコンシューマは、その要求に対してどのリソースノードがサービスするかに関する事前の優先度はないが、リソースコンシューマは複数の応答を減少するためにどのノードを優先するかをバイアスできる。リソースコンシューマに優先されるプロバイダがある場合でも、継続的に対話することにより、他のリソースノードがどう応答するかに基づいて優先されるプロバイダを変更することができる。したがって、ノード間で負荷が分散される。システムにさらなるノードが追加されると負荷が軽減されるので、リソースコンシューマは必要に応じて優先されるノードを循環させることによって、複数のリソースコンシューマがリソースノードを効果的に共有することができる。
【００９１】
以上のように、リソースコマンドメッセージの特定の構成および方法が開示されている。ただし、前述の開示の他に、本明細書に示す本発明の概念を逸脱することなく、さらに多くの変更が可能であることは当業者には言うまでもない。したがって、本発明の主題は本開示の精神を除いて制限してはならない。さらに、本開示を解釈する上で、すべての用語はコンテクストに合わせて最大限広義に解釈されるものとする。特に、「備える」、「備えている」という用語は、エレメント、コンポーネント、またはステップに非独占的に言及し、言及されたエレメント、コンポーネント、またはステップは、明示的に言及されない他のエレメント、コンポーネント、またはステップとの共存、併用、または組合せが可能であると解釈されるものとする。
【図面の簡単な説明】
【００９２】
【図１】リソースコンシューマが複数のリソースノードを備える１つのリソースデバイスと対話する環境を示す図である。
【図２】リソースノードの予想される物理的実施形態を示す概略図である。
【図３】コンピュータ可読メモリに格納される予想されるリソースコマンドメッセージを示す概略図である。
【図４】予想されるリソースノードコマンドキューを示す概略図である。
【図５】リソースコマンドメッセージを処理するための予想されるステップを示す概略図である。
【図６】リソースデバイスにアクセスするための予想されるステップを示す概略図である。
【図１】
2009512011.tif 000003
【図２】
2009512011.tif 000004
【図３】
2009512011.tif 000005
【図４】
2009512011.tif 000006
【図５】
2009512011.tif 000007
【図６】
2009512011.tif 000008
【国際調査報告】
2009512011.tif 000009
2009512011.tif 000010
2009512011.tif 000011