特許 6017684 リソースプーリングを利用した、要求ベースによるストレージの分散型クオリティ・オブ・サービス管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6017684

(24)【登録日】2016年10月7日

(45)【発行日】2016年11月2日

(54)【発明の名称】リソースプーリングを利用した、要求ベースによるストレージの分散型クオリティ・オブ・サービス管理

(51)【国際特許分類】

   G06F 9/50 20060101AFI20161020BHJP

   G06F 9/46 20060101ALI20161020BHJP

   G06F 13/10 20060101ALI20161020BHJP

   G06F 3/06 20060101ALI20161020BHJP

【ＦＩ】

   G06F9/46 462Z

   G06F9/46 350

   G06F13/10 340A

   G06F3/06 301J

【請求項の数】18

【全頁数】23

(21)【出願番号】特願2015-515211(P2015-515211)

(86)(22)【出願日】2013年5月30日

(65)【公表番号】特表2015-525397(P2015-525397A)

(43)【公表日】2015年9月3日

(86)【国際出願番号】US2013043473

(87)【国際公開番号】WO2013181464

(87)【国際公開日】20131205

【審査請求日】2015年10月21日

(31)【優先権主張番号】13/485,615

(32)【優先日】2012年5月31日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】510149482

【氏名又は名称】ヴイエムウェア インコーポレイテッド

【氏名又は名称原語表記】ＶＭｗａｒｅ，Ｉｎｃ．

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】グラティ、アジャイ

(72)【発明者】

【氏名】シャンムガナサン、ガネーシャ

(72)【発明者】

【氏名】バルマン、ピーター ジョセフ

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 特開２００６−２３６３５１（ＪＰ，Ａ）

【文献】 特開２００７−２５７０９７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ３／０６

Ｇ０６Ｆ ９／４６

Ｇ０６Ｆ １３／１０

(57)【特許請求の範囲】

【請求項1】

共通リソースにアクセスするためにホストコンピュータ上で動作中のクライアントのためのクオリティ・オブ・サービス（ＱｏＳ）を提供する方法であって、
前記共通リソースの現在のキャパシティを、前記クライアントが前記共通リソースにアクセスする際のレイテンシの全体的な平均に基づいて計算すること、
前記共通リソースの全体的な予約値をクライアント間で分配して前記ホストコンピュータ上で動作中の各クライアントの動的な予約値を計算することにより、各クライアントの動的な予約値を取得することであって、前記分配することは、クライアントに分配される全体的な予約値を、共通リソースに対するクライアントの要求値に応じて一時的に制限することを含む、前記動的な予約値を取得すること、
計算された現在のキャパシティを、前記クライアントの動的な予約値を用いて前記ホストコンピュータ上で動作中のクライアント間で割り振ることを備え、
前記クライアント間の共通リソースに対する前記全体的な予約値を分配することは、
親ノードおよび子ノードの階層構造を通じて、前記階層構造のルートノードの全体的な予約値が、前記階層構造のレベルごとの分配処理で前記階層構造のより下位のノードに分配されるように、前記全体的な予約値を分配することを含む、方法。

【請求項2】

請求項１に記載の方法であって、
前記共通リソースの計算された現在のキャパシティを割り振ることは、
前記共通リソースの計算された現在のキャパシティを前記クライアント間で、前記クライアントに割り当てられたシェアに基づいて分配することを含む、方法。

【請求項3】

請求項１に記載の方法であって、
特定のホストコンピュータ上で動作中の各クライアントの前記要求値を、前記特定のホストコンピュータから前記共通リソースにアクセスする際の特定のホストコンピュータのレイテンシの平均と、前記クライアントから前記共通リソースにアクセスするリクエストに応答する入力または出力の平均回数を使って計算することをさらに備える方法。

【請求項4】

請求項３に記載の方法であって、
前記計算された要求値を、前記ホストコンピュータの各々によってアクセス可能な共有ファイルに保存すること、または前記計算された要求値を、前記特定のホストコンピュータと接続された他のホストコンピュータに転送することをさらに備える方法。

【請求項5】

請求項１に記載の方法であって、
前記共通リソースの計算された現在のキャパシティを特定のホストコンピュータに割り当てることをさらに備え、
該割り当てることは、
前記特定のホストコンピュータのホストキューのデプスを調整することを含み、
前記ホストキューが、前記特定のホストコンピュータ上で動作中の前記クライアントからの前記共通リソースに対する未処理のリクエストを保存するために使用される、方法。

【請求項6】

請求項１に記載の方法であって、
前記共通リソースの前記現在のキャパシティを計算することは、
前記共通リソースの前記現在のキャパシティを、前記レイテンシの全体的な平均、平滑化パラメータ、およびリソース輻輳閾値を使って計算することを含み、
前記平滑化パラメータは、計算される前記現在のキャパシティの以前の値と比較した計算される前記現在のキャパシティの変動を平滑化するためのパラメータであり、
前記リソース輻輳閾値は、共通リソースの最大レイテンシを示す、方法。

【請求項7】

システムであって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに動作的に接続された複数のクライアントと、
共通リソースにアクセスするための前記クライアントからのリクエストを保存するホストキューを備えるリソースインタフェースと、
前記少なくとも１つのプロセッサに動作的に接続されたリソースプールモジュールであって、
前記クライアントが前記共通リソースにアクセスする際のレイテンシの全体的な平均に基づいて前記共通リソースの現在のキャパシティを計算するように構成された第一の構成要素と、
前記共通リソースの全体的な予約値をクライアント間で分配して各クライアントの動的な予約値を計算することにより、各クライアントの動的な予約値を取得するように構成された第二の構成要素であって、前記分配することは、クライアントに分配される全体的な予約値を、共通リソースに対するクライアントの要求値に応じて一時的に制限することを含み、前記第二の構成要素は、親ノードおよび子ノードの階層構造を通じて、前記階層構造のルートノードの全体的な予約値が、前記階層構造のレベルごとの分配処理で前記階層構造のより下位のノードに分配されるように、前記全体的な予約値を分配するようにさらに構成されている、前記第二の構成要素と、
を含む前記リソースプールモジュールと、
前記リソースプールモジュールに動作的に接続されたスケジューラであって、計算された現在のキャパシティを、前記クライアントの動的な予約値を用いて割り振るように構成されているスケジューラと
を備える、システム。

【請求項8】

請求項７に記載のシステムであって、
前記スケジューラが、前記共通リソースの計算された現在のキャパシティを前記クライアント間で、前記クライアントに割り当てられたシェアに基づいて分配するように構成されている、システム。

【請求項9】

請求項７に記載のシステムであって、
前記リソースプールモジュールが、各クライアントの前記要求値を、ホストコンピュータから前記共通リソースにアクセスする際の特定のホストコンピュータのレイテンシの平均と、前記クライアントからの前記共通リソースにアクセスするリクエストに応答した入力または出力の平均回数を使って計算するように構成されている、システム。

【請求項10】

請求項９に記載のシステムであって、
前記リソースプールモジュールが、計算された要求値を、前記他のホストコンピュータによってアクセス可能な共有ファイルの中に保存するようにさらに構成されているか、または前記計算された要求値を前記ホストコンピュータに接続された他のホストコンピュータに転送するように構成されている、システム。

【請求項11】

請求項７に記載のシステムであって、
前記リソースプールモジュールが、ホストコンピュータのホストキューのデプスを、前記共通リソースの前記計算された現在のキャパシティの一部を前記ホストコンピュータに割り当てるために調節するように構成され、
前記ホストキューが、前記クライアントからの前記共通リソースに対する未処理のリクエストを保存するために使用される、システム。

【請求項12】

請求項７に記載のシステムであって、
前記リソースプールモジュールが、前記共通リソースの前記現在のキャパシティを、前記レイテンシの全体的な平均、平滑化パラメータ、およびリソース輻輳閾値を使って計算するように構成され、
前記平滑化パラメータは、計算される前記現在のキャパシティの以前の値と比較した計算される前記現在のキャパシティの変動を平滑化するためのパラメータであり、
前記リソース輻輳閾値は、共通リソースの最大レイテンシを示す、システム。

【請求項13】

共通リソースにアクセスするためにホストコンピュータにおけるクライアントのためのクオリティ・オブ・サービスを提供するプログラム命令を含むコンピュータ可読ストレージ媒体であって、
前記ホストコンピュータの１つまたは複数のプロセッサにより前記プログラム命令が実行されると、前記１つまたは複数のプロセッサに、
前記共通リソースの現在のキャパシティを、前記クライアントが前記共通リソースにアクセスする際のレイテンシの全体的な平均に基づいて計算すること、
前記共通リソースの全体的な予約値をクライアント間で分配して前記ホストコンピュータ上で動作中の各クライアントの動的な予約値を計算することにより、各クライアントの動的な予約値を取得することであって、前記分配することは、クライアントに分配される全体的な予約値を、共通リソースに対するクライアントの要求値に応じて一時的に制限することを含む、前記動的な予約値を取得すること、
前記計算された現在のキャパシティを、前記クライアントの動的な予約値を用いて前記ホストコンピュータ上で動作中のクライアント間で割り振ること
を含むステップを実行させ、
前記クライアント間の共通リソースに対する前記全体的な予約値を分配することは、
親ノードおよび子ノードの階層構造を通じて、前記階層構造のルートノードの前記全体的な予約値が、前記階層構造のレベルごとの分配処理で前記階層構造のより下位のノードに分配されるように、前記全体的な予約値を分配することを含む、コンピュータ可読ストレージ媒体。

【請求項14】

請求項１３に記載のコンピュータ可読ストレージ媒体であって、
前記共通リソースの前記計算された現在のキャパシティを割り振ることは、
前記共通リソースを前記クライアント間で、前記クライアントに割り当てられたシェアに基づいて分配することを含む、コンピュータ可読ストレージ媒体。

【請求項15】

請求項１３に記載のコンピュータ可読ストレージ媒体であって、
前記ステップが、
特定のホストコンピュータ上で動作中の各クライアントの前記要求値を、前記特定のホストコンピュータから前記共通リソースにアクセスする際の特定のホストコンピュータのレイテンシの平均と、前記クライアントから前記共通リソースにアクセスするリクエストに応答する入力または出力の平均回数を使って計算することをさらに含む、コンピュータ可読ストレージ媒体。

【請求項16】

請求項１３に記載のコンピュータ可読ストレージ媒体であって、
前記ステップが、
前記ホストコンピュータの各々によってアクセス可能な共有ファイル内の前記計算された要求値を記憶することをさらに含む、コンピュータ可読ストレージ媒体。

【請求項17】

請求項１３に記載のコンピュータ可読ストレージ媒体であって、
前記ステップは、
前記共通リソースの前記計算された現在のキャパシティの一部を特定のホストコンピュータに割り当てることをさらに備え、
前記割り当てることは、
前記特定のホストコンピュータのホストキューのデプスを調整することを含み、
前記ホストキューが、前記特定のホストコンピュータ上で動作中の前記クライアントからの前記共通リソースに対する未処理のリクエストを保存するために使用される、コンピュータ可読ストレージ媒体。

【請求項18】

請求項１３に記載のコンピュータ可読ストレージ媒体であって、
前記共通リソースの前記現在のキャパシティを計算することは、
前記共通リソースの前記現在のキャパシティを、前記レイテンシの全体的な平均、平滑化パラメータ、およびリソース輻輳閾値を使って計算することを含み、
前記平滑化パラメータは、計算される前記現在のキャパシティの以前の値と比較した計算される前記現在のキャパシティの変動を平滑化するためのパラメータであり、
前記リソース輻輳閾値は、共通リソースの最大レイテンシを示す、コンピュータ可読ストレージ媒体。

【発明の詳細な説明】

【背景技術】

【0001】

ネットワークコンピュータのためのリソース、例えばデータストレージファシリティの共有は、保守および運転費用を低減化し、個々のリソースの使用に関する柔軟性を実現し、リソース管理を単純化することによって、効率を改善できる。共有ストレージに関して、利点には、データ統合、データへのユニバーサルアクセス、容易なストレージ管理、仮想化環境のための仮想マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）のライブマイグレーション（live migration）のサポートが含まれる。

【0002】

リソース共有の重要な一面がクオリティ・オブ・サービス（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）であり、これは共有リソースが複数のユーザまたはクライアント間である方針に従って割り振られるというリソース管理方式を指す。この方針は、サービスの最小および／または最大レベルを（例えば、共有リソースのパーセンテージとして）保証するものであってもよい。また、文献の中で「使用比率配分（ｗｅｉｇｈｔ）」とも呼ばれる、割り当てられたリソースの「シェア」に従ってサービスを分配し、各クライアントに、割り当てられたシェアと同じ比率でそのピア（peer）と同等のレベルのサービスが提供されるようにすることも一般的である。これらのアプローチを、特定の方針のために組み合わせることが可能である。それゆえ、ＱｏＳにより、サービスを均等に分配し、または選択されたアプリケーション、ユーザ、またはデータフローに任意で割当の優先順位を付けて、共有ストレージ環境におけるワークロードパフォーマンスを管理できることが提案される。

【発明の概要】

【課題を解決するための手段】

【0003】

共通リソースにアクセスするためにホストコンピュータ上で動作中のクライアントにクオリティ・オブ・サービス（ＱｏＳ）を提供するシステムおよび方法は、ホストコンピュータのうちの少なくとも１つのリソースプールモジュールとローカルスケジューラを使用する。リソースプールモジュールは、共通リソースに関する各クライアントのエンタイトルメントを、共通リソースの現在のキャパシティと共通リソースに対するクライアントの要求に基づいて計算するように動作する。これに加えて、リソースプールモジュールは、共通リソースの計算された現在のキャパシティの一部を特定のホストコンピュータに、その特定のホストコンピュータ上で動作中の各クライアントの計算されたエンタイトルメントに基づいて割り当てるように動作する。ローカルスケジューラは、計算された現在のキャパシティの一部を、その特定のホストコンピュータ上で動作中のクライアント間で割り振るように動作する。

【0004】

本発明のある実施形態による、共通リソースにアクセスするためにホストコンピュータ上で動作中のクライアントのためにＱｏＳを提供する方法は、クライアントが共通リソースにアクセスする際のレイテンシの全体的な平均に基づいて共通リソースの現在のキャパシティを計算するステップと、共通リソースに関する各クライアントのエンタイトルメントを、計算された現在のキャパシティと共通リソースに対するクライアントの要求に基づいて計算するステップと、共通リソースの計算された現在のキャパシティの一部を特定のホストコンピュータに、その特定のホストコンピュータ上で動作中の各クライアントの計算されたエンタイトルメントに基づいて割り当てるステップと、計算された現在の能力の一部を特定のホストコンピュータ上で動作中のクライアント間で割り振るステップと、を含む。いくつかの実施形態において、この方法のステップは、コンピュータ可読ストレージ媒体に含まれるプログラム命令がホストコンピュータの１つまたは複数のプロセッサによって実行されるときに行われる。

【0005】

本発明のある実施形態によるシステムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに動作的に接続された複数のクライアントと、共通リソースにアクセスするためのクライアントのリクエストを保存するホストキューを備えるリソースインタフェースと、少なくとも１つのプロセッサに動作的に接続されたリソースプールモジュールと、リソースプールモジュールに動作的に接続されたスケジューラと、を含む。リソースプールモジュールは、クライアントが共通リソースにアクセスする際のレイテンシの全体的な平均に基づいて共通リソースの現在のキャパシティを計算するように構成された第一の構成要素と、共通リソースに関する各クライアントのエンタイトルメントを、計算された現在のキャパシティと共通リソースに対するクライアントの要求に基づいて計算するように構成された第二の構成要素と、共通リソースの計算された現在のキャパシティの一部を特定のホストコンピュータに、各クライアントの計算されたエンタイトルメントを使って割り当てるように構成された第三の構成要素と、を含む。スケジューラは、計算された現在のキャパシティの一部を、ホストコンピュータ上で動作中の少なくとも１つのクライアント間で割り振るように構成されている。

【0006】

本発明の実施形態の他の態様と利点は、本発明の原理の例として示される以下の詳細な説明を、添付の図面と併せて読むことによって明らかとなるであろう。

【図面の簡単な説明】

【0007】

【図1】本発明のある実施形態によるネットワークコンピュータシステムのブロック図である。

【図2】本発明のある実施形態による図１のネットワークコンピュータシステムのホストコンピュータのブロック図である。

【図3】本発明のある実施形態による、異なるＶＭ集合を示すためのネットワークコンピュータの仮装マシン（ＶＭ）、ホストコンピュータ、ストレージの概略図である。

【図4】本発明のある実施形態による、ＶＭを用いたリソースプール階層構造の概略図である。

【図5】本発明のある実施形態による、ホストコンピュータに含められたストレージリソースプール（ＳＲＰ：ｓｔｏｒａｇｅ ｒｅｓｏｕｒｃｅ ｐｏｏｌ）モジュールのブロック図である。

【図6】図４に示されるリソースプール階層構造の別の概略図である。

【図7】本発明のある実施形態による、異なるデータストアに基づいて分割されるリソースプール階層構造を示すブロック図である。

【図8】本発明のある実施形態による、共通リソースにアクセスするためにホストコンピュータ上で動作中のクライアントのためにクオリティ・オブ・サービス（ＱｏＳ）を提供する方法のフロー図である。

【発明を実施するための形態】

【0008】

説明文全体を通じて、同様の要素を特定するために同様の参照番号が使用されている場合がある。
容易に理解されるように、本明細書で一般的に説明され、添付の図面に示される実施形態の構成要素は、様々な異なる構成に配置、構成することができる。それゆえ、図面に示されているような各種の実施形態に関する以下のより詳しい説明は、本願の範囲を限定しようとするものではなく、各種の実施形態を代表しているにすぎない。実施形態の様々な態様が図面に示されているが、図面は、特にことわりがないかぎり、必ずしも正確な縮尺で描かれているわけではない。

【0009】

本発明は、その主旨または本質的な特性から逸脱することなく、他の具体的な形態で実施してもよい。説明されている実施形態は、あらゆる点において、あくまでも例示であり、限定的とはみなされない。したがって、本発明の範囲はこの詳細な説明ではなく、付属の特許請求の範囲によって示される。特許請求の範囲の意味と均等性の範囲内に含まれるすべての変更形態は、その範囲に包含される。

【0010】

本明細書を通じた特徴、利点または同様の文言への言及は、本発明により実現可能な特徴と利点のすべてが、本発明のいずれか１つの実施形態にあるべきであるか、またはあることを暗示していない。むしろ、特徴と利点に言及する文言は、ある実施形態に関連して説明されている具体的な特徴、利点、または特性が本発明の少なくとも１つの実施形態に含められることを意味すると理解する。それゆえ、本明細書を通じた機能と利点に関する議論および同様の文言は、同じ実施形態を指していることもあるが、必ずしもそうとはかぎらない。

【0011】

さらに、説明されている本発明の特徴、利点、特性は、１つまたは複数の実施形態の中で任意の適当な方法で組み合わせてもよい。当業者であれば、本明細書の説明から、本発明が、特定の実施形態の具体的な特徴または利点のうちの１つまたは複数がなくても実施可能であることがわかるであろう。また別の場合には、ある実施形態において、本発明のすべての実施形態の中にあるとはかぎらない追加の機能と利点が認められ得る。

【0012】

本明細書全体における「１つの実施形態」、「ある実施形態」への言及または同様の文言は、明記された実施形態に関連して説明された特定の特徴、構造または特性が、本発明の少なくとも１つの実施形態に含められることを意味する。それゆえ、本明細書中の「１つの実施形態において」、「ある実施形態において」、および類似の文言はすべてが同じ実施形態を指していることもあるが、必ずしもそうとはかぎらない。

【0013】

リソース管理に関する従来のクオリティ・オブ・サービス（ＱｏＳ）技術では、異なるインフラストラクチャおよび／または目的を有する異なる企業に対応するのに十分な管理が提供されない。これに加えて、ＱｏＳ技術の中には中央集中的スケジューラを必要とするものがあり、これによってＱｏＳメカニズムが一層複雑化する可能性があり、またシステム全体の不具合もさらに起きやすくなり得る。

【0014】

従来のＱｏＳ技術の限界と問題を鑑み、中央集中的スケジューラ（centralized performance）を使用せずに、共有リソース環境中のワークロードパフォーマンス（workload performance）に対する管理を維持するためのＱｏＳ管理が求められている。

【0015】

ここで、図１を参照すると、本発明のある実施形態によるネットワークコンピュータシステム１００が示されている。図１に示されるように、ネットワークコンピュータシステムは、ネットワーク１０２と、ネットワークに接続された多数のホストコンピュータ１０４Ａ、１０４Ｂ．．．１０４Ｎと、同じくネットワークに接続された共有ストレージ１０６と、を含む。それゆえ、ホストコンピュータ１０４の各々は、ネットワークを介して共有ストレージにアクセスし、ストレージによって提供されるリソースを他のホストコンピュータと共有できる。その結果、任意のホストコンピュータ上で実行中の任意のプロセスが、ネットワークを介してストレージにアクセスできる。より詳しく説明するように、図の実施形態では、分散されたホストコンピュータは、要求ベースのＱｏＳメカニズムを実行することによって、ホストコンピュータにより共有されているストレージリソースに関するワークロードパフォーマンスに対する管理を維持する。

【0016】

ネットワーク１０２は、ネットワークに接続されたデバイス間の通信を可能にする任意の種類のコンピュータネットワークまたはネットワークの組み合わせであってよい。ネットワーク１０２は、インターネット、広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ストレージエリアネットワーク（ＳＡＮ：ｓｔｏｒａｇｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ファイバチャネルネットワークおよび／またはその他のネットワークを含んでいてもよい。ネットワーク１０２は、ストレージアレイとの通信に適したプロトコル、例えばＦｉｂｒｅ Ｃｈａｎｎｅｌ、ｉＳＣＳＩ、ＦＣｏＥ、ＨｙｐｅｒＳＣＳＩ等をサポートするように構成されていてもよい。

【0017】

ホストコンピュータ１０４Ａ、１０４Ｂ．．．１０４Ｎは、１つまたは複数のクライアントをホストまたはサポートする物理的コンピュータシステムであり、これによってクライアントは物理的コンピュータシステム上で動作する。ホストコンピュータは、データセンタで一般的に見られるサーバであってもよい。本明細書において、「クライアント」という用語は、コンピュータシステム上で実行可能な任意のソフトウェアエンティティ、例えばソフトウェアアプリケーション、ソフトウェアプロセスまたは仮想マシン（ＶＭ）である。ホストコンピュータについては、以下により詳しく説明する。

【0018】

ストレージ１０６は、ホストコンピュータ１０４Ａ、１４０Ｂ．．．１０４Ｎのためのデータを保存するために使用され、これにはコンピュータシステムに接続された他の任意のストレージデバイスと同様にアクセスできる。ある実施形態において、ストレージは、ホストコンピュータ上で動作中のクライアント等のエンティティにより、任意のファイルシステム、例えば仮想マシンファイルシステム（ＶＭＦＳ；ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｆｉｌｅ ｓｙｓｔｅｍ）またはネットワークファイルシステム（ＮＦＳ：ｎｅｔｗｏｒｋ ｆｉｌｅ ｓｙｓｔｅｍ）等を使用してアクセス可能である。ストレージは、１つまたは複数のコンピュータデータストレージデバイス１０８を含み、これは、例えばソリッドステートデバイス（ＳＳＤ：ｓｏｌｉｄ−ｓｔａｔｅ ｄｅｖｉｃｅ）、ハードディスクまたはこの２つの組み合わせ等、任意の種類のストレージデバイスとすることができる。ストレージデバイスは、ネットワークアタッチトストレージ（ＮＡＳ：ｎｅｔｗｏｒｋ−ａｔｔａｃｈｅｄ ｓｔｏｒａｇｅ）および／またはストレージエリアネットワーク（ＳＡＮ）の構成要素として動作してもよい。ストレージはストレージ管理モジュール１１０を含み、これはストレージの動作を管理する。ストレージ管理モジュールはリクエストキュー１１２、すなわちストレージに対するペンディングの入力／出力（ＩＯ）リクエストのリストを保持する。ある実施形態において、ストレージ管理モジュール１１０は、ストレージの１つまたは複数のコンピュータシステム（図示せず）上で実行されるコンピュータプログラムである。ストレージは、複数のデータストアまたはロジカルユニットナンバー（ＬＵＮ：ｌｏｇｉｃａｌ ｕｎｉｔ ｎｕｍｂｅｒ）をサポートしていてもよい。ストレージ１０６はどのような種類のコンピュータデータストレージであってもよいが、ストレージ１０６は本明細書においては、ストレージアレイとして説明する。

【0019】

次に図２を参照すると、本発明のある実施形態によるホストコンピュータ１０４Ａの構成要素が示されている。他のホストコンピュータ１０４Ｂ．．．１０４Ｎはホストコンピュータ１０４Ａと同様である。それゆえ、ホストコンピュータ１０４Ａを他のホストコンピュータの例として使用する。図２において、ホストコンピュータ１０４Ａの各種の構成要素間の物理的接続は示されていない。図の実施形態では、ホストコンピュータ１０４Ａは、多数のクライアント２２０Ａ、２２０Ｂ．．．２２０Ｎをサポートするように構成され、これらはＶＭである。ホストコンピュータによってサポートされるＶＭの数は、１〜１００超のいずれであってもよい。ホストコンピュータによってサポートされるＶＭの正確な数は、ホストコンピュータの物理的リソースによってのみ限定される。ＶＭは、ホストコンピュータのハードウェアリソースの少なくともいくつかを共有し、これにはシステムメモリ２２２、１つまたは複数のプロセッサ２２４、ストレージインタフェース２２６、ネットワークインタフェース２２８が含まれる。システムメモリ２２２は、ランダムアクセスメモリ（ＲＡＭ：ｒａｍｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）であってもよく、ホストコンピュータの一次メモリである。プロセッサ２２４は、例えばサーバで一般的に見られる中央処理ユニット（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）等の、任意の種類のプロセッサとすることができる。ストレージインタフェース２２６は、ホストコンピュータがストレージアレイ１０６と通信できるようにするインタフェースである。例えば、ストレージインタフェースは、ホストバスアダプタまたはネットワークファイルシステムインタフェースであってもよい。ネットワークインタフェース２２８は、ホストコンピュータがネットワーク１０２に接続された他のデバイスと通信できるようにするインタフェースである。例えば、ネットワークインタフェースはネットワークアダプタであってもよい。

【0020】

図の実施形態において、ＶＭ ２２０Ａ、２２０Ｂ．．．２２０Ｎは仮想マシンコントローラ２３０の上で動作し、これはＶＭによるホストコンピュータ１０４Ａのハードウェアリソースの共有を可能にするソフトウェアインタフェースレイヤである。しかしながら、他の実施形態において、ＶＭの１つまたは複数は入れ子構造とすることができ、すなわち、あるＶＭが他のＶＭ内で動作する。例えば、ＶＭのうちの１つは、あるＶＭの中で動作してもよく、これはまた他のＶＭ内で動作する。仮想マシンモニタは、ホストコンピュータのオペレーティングシステムの上で、またはホストコンピュータのハードウェア上で直接動作してもよい。いくつかの実施形態において、仮想マシンモニタ（virtual machine monitor）は、ホストコンピュータのハードウェア構成要素の上にインストールされたハイパーバイザの上で動作する。仮想マシンモニタのサポートにより、ＶＭは仮想化されたコンピュータシステムを提供し、これはホストコンピュータとは、および相互に別である外観を呈する。各ＶＭは、ゲストオペレーティングシステム２３２と１つまたは複数のゲストアプリケーション２３４を含む。ゲストオペレーティングシステムはそれぞれのＶＭのマスタコントロールプログラムであり、とりわけ、ゲストオペレーティングシステムはソフトウェアプラットフォームを形成し、その上でゲストアプリケーションが動作する。

【0021】

ネットワーク１０２に接続された他の任意のコンピュータシステムと同様に、ＶＭ ２２０Ａ、２２０Ｂ．．．２２０Ｎはそのネットワーク１０２に接続された他のコンピュータシステムと、ホストコンピュータ１０４Ａのネットワークインタフェース２２８を使って通信できる。これに加えて、ＶＭはホストコンピュータのストレージインタフェース２２６を使ってストレージアレイ１０６にアクセスできる。それゆえ、ホストコンピュータのＶＭは、ホストコンピュータのためのストレージアレイによって提供される共有ストレージリソースを求めて競合する。同様に、ホストコンピュータは共有ストレージリソースを求めて他のホスト１０４Ｂ．．．１４０Ｎと競合する。

【0022】

ネットワークコンピュータシステム１００のホストコンピュータ１４０Ａ、１０４Ｂ．．．１０４Ｎの各々は、図２に示されているように、ホストコンピュータのストレージインタフェース２２６の命令発行キュー２３６の中にストレージアレイ１０６における未処理のＩＯリクエストを特定の最大数まで保持できる。特定のホストコンピュータの命令発行キューの大きさ（本明細書では、「ホストキューデプス（host queue depth）」ともいう。）は、ストレージアレイが、現在その特定のホストコンピュータに割り振られているＩＯリクエストを処理するキャパシティを反映する。以下により詳しく説明するように、ホストコンピュータの命令発行キューは、ストレージアレイによって提供されるストレージリソースに関するＱｏＳ制御を実行するために使用される。

【0023】

共有される共通リソース、すなわちストレージアレイ１０６によって提供される共有ストレージリソースを求める競合によって、異なるエンティティ間、例えばホストコンピュータ１０４Ａ、１０４Ｂ．．．１０４ＮによってホストされるＶＭ等間の共有ストレージリソースの分配を制御するために、ネットワークコンピュータシステム１００内のＱｏＳ管理メカニズムが必要である。共有リソースが異なるＶＭ間で均等に分けられる場合は、共有ストレージリソースの分配工程は簡単であることもある。しかしながら、特定の状況では、ＶＭのいくつかが他のＶＭより多くの量の共有ストレージリソースを必要とすることもある。本明細書において、共有ストレージリソースの量は、１秒当たりのＩＯ動作の回数（ＩＯＰＳ：ＩＰ ｏｐｅｒａｔｉｏｎｓ ｐｅｒ ｓｅｃｏｎｄ）で測定でき、ＩＯＰＳの数値が大きいほど、共有ストレージリソースへのアクセスが多いことを意味する。これに加えて、異なるＶＭのニーズは、共有ストレージリソースに対するＶＭの要求の変化に基づいて変わり得る。さらに、特定の状況では、異なるホストコンピュータ上で動作中のＶＭが異なるグループに属することもあり、その共有ストレージリソースへのアクセスに関するニーズと要求事項は異なる。このようなＶＭの集合の一例を、以下に図３を参照しながら説明する。

【0024】

図３は、ストレージアレイ１０６に接続されて、ストレージアレイにより提供されるストレージリソースを共有するホストコンピュータ１０４Ａと１０４Ｂを示す。ホストコンピュータ１０４Ａは、ＶＭ２２０Ａと２２０Ｂを含む。ホストコンピュータ１０４Ｂは、ＶＭ２２０Ｃと２２０Ｄを含む。この例では、ホストコンピュータ上で動作中のＶＭ２２０Ａとホストコンピュータ１０４Ｂ上で動作中のＶＭ２２０Ｃは、ある企業の営業部門に属する。ホストコンピュータ１０４Ａ上で動作中のＶＭ２２０Ｂとホストコンピュータ１０４Ｂ上で動作中のＶＭ２２０Ｄは、その企業の財務部門に属する。営業部門のＶＭ２２０Ａと２２０Ｃは異なる大陸での営業を取り扱っていてもよく、それゆえ、異なる時間帯での要求のピークと谷に基づいて、全体で１，０００ＩＯＰＳの予約が必要である。財務部門のＶＭ２２０Ｂと２２０Ｄはバックグラウンドでデータ分析を行っていてもよく、それゆえ、重要な営業のＶＭに対するその影響を削減するために、５００ＩＯＰＳの総スループットに制限される。これに加えて、この５００ＩＯＰＳをＶＭ間でその重要性に基づいて１：２の比率で割り当てたいと思う人がいる場合もある。これは、シェア制御として知られる。本発明の実施形態によるネットワークコンピュータシステム１００のＱｏＳ管理メカニズムは、異なる集合のＶＭの要求事項に対応するための共有ストレージリソースのロバストなＱｏＳ制御を提供するように設計され、ＱｏＳメカニズムを一層複雑化する可能性があり、またシステム全体の不具合をさらに起こしやすくし得る中央集中的なリソーススケジューラを設ける必要がない。後述のように、ネットワークコンピュータシステムのＱｏＳ管理メカニズムは、ストレージリソースプール（ＳＲＰ）の概念を使って、ネットワークコンピュータシステム全体を通じて分散されたクライアントのためのＱｏＳを管理する。それゆえ、ネットワークコンピュータシステムのＱｏＳ管理メカニズムは、本明細書において、ＳＲＰベースのＱｏＳ管理メカニズムと呼ぶ。

【0025】

ＳＲＰベースのＱｏＳ管理メカニズムによって、ユーザ、例えばシステム管理者は、スループット予約値（下限）、制限値（上限）、シェア（案分比例的共有）を使って所望のＱｏＳを指定することができる。これらの数値は、リソースプール階層構造のいずれのノード、例えばリソーリソースプール階層構造内の個々のＶＭおよび／または関係するＶＭの集合についても設定でき、これらはリソースプール階層構造の中の、ＶＭより高い位置にあるノードによって概念的に指定される。予約値は、リソースプール階層構造の中のノード、例えばＶＭやＶＭの集合が受け取らなければならない共有リソースの最低量を明示する絶対的な保証である。制限値は、リソースプール階層構造の中のノードに対して行われるべき最大割り振りを明示する。これらの数値は、そのサービスレベル目標（ＳＬＯ：ｓｅｒｖｉｃｅ ｌｅｖｅｌ ｏｂｊｅｃｔｉｖｅ）に基づいて契約により設定されたＩＯＰＳに関する厳密な分離の実行とテナント（tenant）の制限に有益である。シェアは、リソースプール階層構造の中のノード間の相対的重要性を表す尺度であり、キャパシティに限りがある場合に、割り振りに優先順位を付けるために使用される。

【0026】

ＳＲＰベースのＱｏＳ管理メカニズムによればまた、ユーザはネットワークコンピュータシステム１００の中のホストコンピュータ１０４Ａ、１０４Ｂ．．．１０４Ｎ上で動作中のクライアントをストレージリソースプール（すなわち、ＳＲＰ）にグループ分けして、特定のグループまたはＳＲＰの中のクライアントがリソース割り振りの単独のユニットとして扱えるようにすることができる。その後、これらのユニットを合体させて、より大きなリソースプールまたはグループにし、リソースプール階層構造を作ることができる。クライアントのクループ分けは、クライアントが動作中の基本のホストコンピュータに関係なく行うことができる。それゆえ、ある特定のホストコンピュータ上で動作中のクライアントは、異なるリソースプールまたはグループに属していてもよい。このような分散型アーキテクチャは、仮想化データセンタにおいて非常に一般的である。リソースプール階層構造を定義する情報はストレージアレイ１０６の中に保存された共有ファイルの中に保存されてもよく、それによってネットワークコンピュータシステム内の各ホストコンピュータはこの情報にアクセスできる。あるいは、リソースプール階層構造の情報はネットワークコンピュータシステム内の他のホストコンピュータにブロードキャストされてもよく、それによって各ホストコンピュータが他のすべてのホストコンピュータからのこれらの数値を把握できる。

【0027】

ＶＭ２２０Ａ、２２０Ｂ、２２０Ｃ、および２２０Ｄを有するリソースプール階層構造の例が図４に示されている。図４に示されるリソースプール階層構造は、４つのＶＭ２２０Ａ、２２０Ｂ、２２０Ｃ、および２２０Ｄを含み、これらはリソースプール階層構造の最も下位のノードとして見ることができる。この例では、ＶＭ２２０Ａと２２０Ｃがノード４０２Ａにより示されるように１つにまとめられ、これは２つのＶＭ２２０Ａと２２０Ｃの親ノードとして見ることができる。それゆえ、２つのＶＭ２２０Ａと２２０Ｃはノード４０２Ａの子供、すなわち子ノードとして見ることができる。同様に、ＶＭ２２０Ｂと２２０Ｄは、他のノード４０２Ｂにより示されているように１つにまとめられ、これは２つのＶＭ２２０Ｂと２２０Ｄの親ノードとして見ることができる。それゆえ、２つのＶＭ ２２０Ｂと２２０Ｄはノード４０２Ｂの子供、すなわち子ノードとして見ることができる。２つのノード４０２Ａと４０２Ｂはさらに、ノード４０４で示されているように１つにまとめられ、これはリソースプール階層構造のルートノードである。ノード４０４はまた、２つのノード４０２Ａと４０２Ｂの親ノードとして見ることができ、反対に、２つのノード４０２Ａと４０２Ｂはノード４０４の子供、すなわち子ノードとして見ることができる。このリソースプール階層構造は、組織構造、例えば業務用に１つまたは複数のＶＭを使用する部門または部署を有する企業等を概念的に表していてもよい。企業を表す場合、リソースプール階層構造のルートノード４０４はその企業全体を表してもよく、２つのノード４０２Ａと４０２Ｂはその企業の部門または部署、例えばそれぞれ営業および財務部門を表してもよく、ＶＭ２２０Ａと２２０Ｃは営業部門のために動作し、ＶＭ２２０Ｂと２２０Ｄは財務部門のために動作する。

【0028】

ＳＲＰベースのＱｏＳ管理メカニズムは、ストレージリソースプール（ＳＲＰ）モジュール２３８とローカルスケジューリングモジュール２４０を使用し、これらは図２に示されるように、ネットワークコンピュータシステム１００の中の各ホストコンピュータに含まれる。各ホストコンピュータの中のＳＲＰモジュールはネットワークコンピュータシステムの他のホストコンピュータのＳＲＰモジュールと協働して、ストレージアレイ１０６のキャパシティのうちのどれだけをそのホストコンピュータに提供するべきかを判断し、これは少なくとも、そのホストコンピュータのクライアントによるストレージアレイへの要求全体と、ストレージアレイの平均レイテンシに基づく。ＳＲＰモジュールは次に、ホストコンピュータに割り振られるストレージキャパシティのうちのどれだけをそのホストコンピュータの各クライアント、例えば各ＶＭに提供するべきかを判断する。ＳＲＰモジュールはまた、リソースプール階層構造のルートノードにおける全体的な予約値、全体的な制限値、シェアを、共有ストレージリソース、その静的な予約、制限、シェアの値に基づいてクライアントへと分配する。本明細書において、シェア値は、割り当てられたシェアの数と同等である。これに加えて、本明細書において、静的な値は、ユーザ、例えばシステム管理者、またはネットワークコンピュータシステム１００の中のいずれかのコンピュータ上で実行中の管理プログラムによって設定される値である。これらの静的な値は、ストレージアレイ１０６の中に保存された共有ファイルの中に保存されてもよく、これによってネットワークコンピュータシステムの中の各ホストコンピュータはこの情報にアクセスできる。あるいは、これらの静的な値はネットワークコンピュータシステム内の他のホストコンピュータにブロードキャストされてもよく、それによって各ホストコンピュータが他のホストコンピュータからのこれらの数値を把握できる。分配の結果として、各クライアントには、現在のモニタリング時間間隔についての動的な予約値、動的な制限値、動的なシェア値が割り当てられる。次いで、これらの動的な値のほか、クライアントへのストレージキャパシティの割り振りは、毎回次のモニタリング時間間隔について再計算される。

【0029】

各ホストコンピュータのローカルスケジューラ２４０は、そのホストコンピュータのクライアント、例えばＶＭによるＩＯリクエストのスケジュールを、ホストコンピュータ内のＳＲＰモジュール２３８によって計算された動的な予約値、動的な制限値、動的なシェア値に従って決定するように動作する。図２ではローカルスケジューラとＳＲＰモジュールが仮想マシンモニタ２３０と別に示されているが、これらの構成要素の一方または両方を仮想マシンモニタの一部として実装してもよい。いくつかの実施形態において、ＳＲＰモジュールとローカルスケジューラはホスコンピュータ上で実行されるソフトウェアプログラムとして実装される。しかしながら、他の実施形態では、ＳＲＰモジュールとローカルスケジューラはソフトウェアとハードウェアのいずれかの組み合わせを使って実装してもよい。

【0030】

次に、図５を参照すると、本発明のある実施形態によるＳＲＰモジュール２３８の構成要素が示されている。図５に示されるように、ＳＲＰモジュールは、要求更新構成要素５０２と、ストレージキューデプス更新構成要素５０４と、ストレージＩＯＰＳキャパシティ計算構成要素５０６と、配分構成要素５０８と、ホストキューデプス調整構成要素５１０と、を含む。図の実施形態では、ＳＲＰモジュールのこれらの構成要素が別々の要素として示されている。しかしながら、他の実施形態では、これらの構成要素の１つまたは複数を他の構成要素と組み合わせてもよく、および／またはこれらの構成要素の１つまたは複数をさらに細かい下位の構成要素に分割してもよい。ＳＲＰモジュールがソフトウェアモジュールとして実装されるある実施形態において、ＳＲＰモジュールの構成要素は、そのソフトウェアモジュールの処理ブロックとして見ることができる。ＳＲＰモジュールの構成要素に関する以下の説明文では、ホストコンピュータ１０４ＡのクライアントがＶＭとして説明される。しかしながら、前述のように、これらのクライアントは、共有ストレージリソースのためのストレージアレイ１０６にアクセスできる任意のエンティティとすることができる。

【0031】

ＳＲＰモジュール２３８のリソース要求更新構成要素５０２は、ホストコンピュータ１０４Ａの各ＶＭの共有ストレージリソースに対する要求と、ホストコンピュータに関する合算ＶＭ要求、すなわちホストコンピュータ内のすべてのＶＭの要求の合計を更新するように動作する。リソース要求更新構成要素は、ホストコンピュータの平均レイテンシ（「ａｖｇＬａｔｅｎｃｙ」）と平均測定ＩＯＰＳ（「ａｖｇＩｏｐｓ」）を、ホストコンピュータ、例えばホストコンピュータ上で動作中の仮想マシンモニタ２３０またはハイパーバイザによって保持される統計を使って判断する。ホストコンピュータが保持するこれらの統計には、モニタリング間隔中の合算レイテンシとホストコンピュータの各ＶＭにより実行されるＩＯ総数が含まれる。次に、リソース要求更新構成要素は、ホストコンピュータの各ＶＭの要求を、リトルの法則から得られる次の方程式を使って、平均未処理ＩＯ数（「ｄｅｍａｎｄＯＩＯ」）として計算する。
ｄｅｍａｎｄＯＩＯ＝ａｖｇＬａｔｅｎｃｙ×ａｖｇＩｏｐｓ （方程式１）
これらの数値は次に、ネットワークコンピュータシステム１００内の各ホストコンピュータがこれらのＶＭ要求値を未処理のＩＯ（ＯＩＯ：ｏｕｔｓｔａｎｄｉｎｇ ＩＯ）として得ることができるように、利用可能な状態とされる。ある実施形態において、これらの値はストレージアレイ１０６に保存された共有ファイルの中で更新される。それゆえ、ネットワークコンピュータシステム内の各ホストコンピュータは共有ファイルにアクセスして、ネットワークコンピュータシステム内の他のホストコンピュータのｄｅｍａｎｄＯＩＯを呼び出すことができる。他の実施形態において、これらの値はネットワークコンピュータシステム内の他のホストコンピュータにブロードキャストされてもよく、それによって各ホストコンピュータが他のすべてのホストコンピュータからのこれらの値を把握できる。

【0032】

リソース要求更新構成要素５０２は次に、ｄｅｍａｎｄＯＩＯの値を、以下の方程式を使い、ストレージデバイス輻輳閾値レイテンシ（storage device congestion threshold latency : 「Ｌ_ｃ」）に基づく正規化要求ＩＯＰＳ値（「ｄｅｍａｎｄＩｏｐｓ」）に変換する。
ｄｅｍａｎｄＩｏｐｓ＝ｄｅｍａｎｄＯＩＯ／Ｌ_ｃ （方程式２）
輻輳閾値は、ストレージデバイスが動作する最大レイテンシである。リソース要求更新構成要素は、ストレージキューデプス（storage queue depth）、すなわちリクエストキュー１１２のデプス（図１に示される）を制御して、レイテンシをＬ_ｃに近い状態に保ち、それによってストレージアレイ１０６は効率的に利用される。これは、局所的なレイテンシの変化に基づくＶＭの要求の過大評価を回避するのに役立つ。例えば、輻輳閾値は一般に、３０ミリ秒に設定できる。ＳＳＤ追加ＬＵＮ（SSD-backed LUN）の場合、Ｌ_ｃはこれより低い値、例えば５〜１０ミリ秒に設定できる。

【0033】

リソース要求更新構成要素５０２は次に、この値が各ＶＭの予約と制限の設定値により表される下限と上限の間に確実に含まれるように、次の方程式を使ってｄｅｍａｎｄＩｏｐｓの値を調整する。

【0034】

ｄｅｍａｎｄＩｏｐｓ＝ｍｉｎ（ｍａｘ（ｄｅｍａｎｄＩｏｐｓ，Ｒ）．Ｌ） （方程式３）
次にホストコンピュータについての要求を合算するように、ＶＭのｄｅｍａｎｄＩｏｐｓの値を加算してから、ホストコンピュータ１０４Ａで境界チェックを適用し、合算値がそのホストコンピュータに関する予約と制限の設定により表される下限と上限の中に確実に含まれるようにする。

【0035】

ＳＲＰモジュール２３８のストレージキューデプス更新構成要素５０４は、ストレージアレイのキャパシティを、ストレージアレイ１０６のストレージキューデプスとして更新するように動作し、これが次に、そのＳＲＰモジュールが動作中のホストコンピュータ１０４Ａを含む、ネットワークコンピュータシステム１００の中の各ホストコンピュータに割り振られる。ストレージキューデプス更新構成要素は、以下の方程式を使ってストレージキューデプスを調整し、測定されたレイテンシが輻輳閾値内に保持されるようにする。

【0036】

【数1】

上の方程式において、Ｑ（ｔ）は時間ｔでのストレージキューデプスを示し、Ｌ（ｔ）はすべてのホストコンピュータの現在の平均レイテンシであり、γ∈［０，１］は平滑化パラメータであり、Ｌｃはデバイス輻輳閾値である。

【0037】

ＳＲＰモジュール２３８のストレージＩＯＰＳキャパシティ計算構成要素５０６は、ストレージアレイ１０６のＩＯＰＳキャパシティを計算するように動作する。ストレージＩＯＰＳキャパシティ計算構成要素は、ストレージキューデプス計算構成要素５０４により計算された更新アレイキューデプスの値を、リトルの法則を使って得られる次の方程式を使って同等のストレージＩＯＰＳキャパシティに変換する。
ａｒｒａｙＩＯＰＳ＝Ｑ（１＋ｌ）／Ｌ_ｃ （方程式５）
キューデプスのＩＯＰＳへの変換は、配分構成要素５０８によって行われる配分動作の中で使用されるリソースプール設定が、後述のように、より透明性の低いＯＩＯの値ではなく、ユーザにとってなじみのあるＩＯＰＳで示されるために行われる。

【0038】

ＳＲＰモジュール２３８の配分構成要素５０８は、現在の要求の分布を反映するＶＭの動的な予約、制限、シェアの値のほか、計算されたａｒｒａｙＩＯＰＳの値に関するＶＭのエンタイトルメントを計算するように動作する。配分構成要素は、入力として、リソースプール階層構造の構造、リソースプール階層構造のノード（例えば、図４に示されるノード４０２Ａ、４０２Ｂ、および４０４Ｃ）の静的な予約、制限、シェアの設定のほか、ＶＭとノードの要求を取る。配分構成要素は次に、リソースプール階層構造のルートノードでの予約、制限、アレイＩＯＰＳとシェアの値をＶＭへと分配するように動作する。

【0039】

リソースプール階層構造のルートノードは、リソースプール（ＲＰ：ｒｅｓｏｕｒｃｅ ｐｏｏｌ）階層構造のノード間で分割または分配する必要のある４つのリソースタイプを保持する。
（１）予約されたＲＰキャパシティ（Ｒ）、
（２）ＲＰ制限（Ｌ）、
（３）アレイＩＯＰＳ（Ｉ）、
（４）合計ＲＰシェア（Ｓ）。

【0040】

配分構成要素５０８は、リソースプール階層構造のレベルごとのパスを行い、ルートノードから始めてリソースプール階層構造の各レベルでリソースを分ける。リソースプール階層構造の各ノードについて、分配構成要素はそのノードのリソースを、その子供、すなわち子ノード間で分ける。本明細書において、Ｒ−配分動作、Ｌ−配分動作、Ｉ−配分動作、およびＳ−配分動作は、配分構成要素がそれぞれＲ、Ｌ、Ｉ、Ｓの数値を分配するために実行する動作である。

【0041】

リソースプール階層構造のルートノードのＲ、Ｌ、Ｉ、およびＳの値は本明細書において、全体的なＲ、Ｌ、Ｉ、およびＳ値と呼ばれることもある。
Ｒ−配分動作、Ｌ−配分動作、およびＳ−配分動作後に得られるＶＭのＲ、Ｌ、Ｓの値は、次のモニタリング時間間隔中のＶＭの動的なＲ、Ｌ、Ｓ設定として使用される。Ｉ−配分の中でＶＭごとに得られるＩの値は、そのＶＭのエンタイトルメント（entitlement）として知られる。Ｒ−配分動作、Ｌ−配分動作、およびＩ−配分動作中、ノードがＲ、Ｌ、およびＩの値のシェアを受ける限度は、一時的にそれらの合算要求が上限とされ、これによってリソースを現時点でより要求の高いＶＭに向けることができる。

【0042】

Ｒ−配分動作に関して、配分構成要素５０８はまず、ルートノードで予約されたＲＰキャパシティＲをその子供、すなわち子ノードに配分する。各子ノードにおいて、そこに割り当てられた予約がその子供間で配分されるキャパシティとして使用される。この工程は、ネットワークコンピュータシステム１００のすべてのＶＭがその更新されたＲのシェアを受け取るまで繰り返される。Ｌ−配分動作およびＩ−配分動作に関して、配分構成要素は同様の手順に従って「ＲＰ制限Ｌ」と「アレイＩＯＰＳ Ｉ」を配分し、各ＶＭが新しい動的な制限設定とエンタイトルメントＥ_ｉを受け取るようにする。Ｓ−配分動作に関して、配分構成要素はルートノードでの合計ＲＰシェアＳを、子ノードの静的なシェア値に基づいてその子供、すなわち子ノード間で配分する。各子ノードでは、その割り振られたシェアを次に、その子供間で、子供のシェア設定の比率により分けられる。

【0043】

配分構成要素５０８は、Ｒ−配分動作、Ｌ−配分動作、Ｉ−配分動作、およびＳ−配分動作を実行して、各子ノードに親のキャパシティの一部を、それらの予約と制限による制約を前提として、そのシェアに応じて与えようと試みる。この目的を達成するための１つのアルゴリズムは、親キャパシティの小さい固定量を選択された子ノードに逐次的に与え、親のキャパシティ全体が子供に分配されるようにすることである。このアルゴリズムを説明するために、ａ_ｉが配分工程のある段階で子供ｉに対して行われる割り振りを示し、ｓ_ｉがそのシェア値であるものとする。このアルゴリズムでは、配分工程はまず、各子ノードにその予約を与え、すなわちａ_ｉの初期値は子ｉの静的な予約値である。リソースの次の数量について、配分工程は子供の中から、その静的な制限値以下の最も小さい正規化割り振り（smallest normalized allocation）（ａ_ｉ／ｓ_ｉ）の子ノードを選択し、その割り振りを少量δだけ増やす。この工程は、親のキャパシティ全体がすべて配分されるまで続く。このアルゴリズムの問題は、それがｎ個のＶＭ分のランタイムＯ（ｌｏｇ ｎ^＊ｃａｐａｃｉｔｙ／δ）を有し、これはキャパシティの値が大きいと非常に長くなる可能性があることである。他の問題は、適正な値δを見つけることである。それゆえ、配分構成要素は、他の分散アルゴリズムを使って、親ノードのリソースをその子ノードに、より効率的な方法で分けることができる。

【0044】

例えば、Ｒ−配分動作、Ｌ−配分動作、およびＩ−配分動作のために配分構成要素５０８が使用できる１つの分散アルゴリズムは、分散工程中にその一時的な制限（ｌ）の値としてノードの要求を用いることを含み、ｒとｓの値はそれぞれ、静的な予約とシェアの値である。子ノードの要求の合計が親で配分されるキャパシティより小さい場合、子ノードの静的な制限がその要求の代わりに使用される。Ｒ−配分動作に関して、ルートノードの予約の設定（Ｒ）が配分すべきキャパシティとして使用され、その一方で、Ｌ−配分動作およびＩ−配分動作に関しては、キャパシティはそれぞれ、ルートの制限の設定（Ｌ）とアレイＩＯＰＳ（Ｉ）である。Ｓ−配分動作に関して、親のシェア値は単純に子供のシェアの比率で分けられる。この分配アルゴリズムの擬似コードを以下に示す。
データ：Ｃ：配分すべきキャパシティ
子ｃ_ｉ、１≦ｉ≦ｎ、パラメータｒ_ｉ、ｌ_ｉ、ｓ_ｉ
結果：ａ_ｉ：子ｃ_ｉについて計算された割り振り
可変数：

【0045】

【数2】

Ｖ：集合

【0046】

【数3】

からの要素の順序付集合｛ｖ_１，ｖ_２，．．．ｖ_２ｎ，ｖ_ｉ≦ｖ_ｉ＋１｝
ｉｎｄｅｘ［ｉ］：ｖ_ｉがｒ_ｋまたはｌ_ｋのいずれかの場合、ｋと等しい
ｔｙｐｅ［ｉ］；ｖ_ｉが制限（予約）である場合、Ｌ（Ｒ）と等しい
集合：ＲＢ＝｛１，．．．ｎ｝，ＬＢ＝｛｝，ＰＳ＝｛｝

【0047】

【数4】

各ｋ＝１，．．．，２ｎについて、以下を行う。
／^＊ＰＳの要素の割り振りをｖ_ｋまで増やせるか？^＊／
（ＰＳｗｔ^＊ｖ_ｋ＋ＬＢｃａｐ＋ＲＢｃａｐ＞Ｃ）であれば、
｜＿ｂｒｅａｋ
／^＊ｔｙｐｅ［ｋ］がＰＳ内のある子の制限であれば、その子をＰＳ集合からＬＢ集合に移行させる^＊／
（ｔｙｐｅ｛ｋ｝＝Ｌ）であれば、
ＬＢ＝ＬＢ∪｛ｉｎｄｅｘ［ｋ］｝
ＬＢｃａｐ＝ＬＢｃａｐ＋ｌ_{ｉｎｄｅｘ［ｋ］}
ＰＳ＝ＰＳ−｛ｉｎｄｅｘ［ｋ］｝
ＰＳｗｔ＝ＰＳｗｔ＋ｗ_{ｉｎｄｅｘ［ｋ］}
上記以外であれば、
／^＊ｔｙｐｅ［ｋ］＝Ｒ：子をＲＢからＰＳに移行＊／
ＰＳ＝ＰＳ∪｛ｉｎｄｅｘ［ｋ］｝
ＰＳｗｔ＝ＰＳｗｔ＋ｗ_{ｉｎｄｅｘ［ｋ］}
ＲＢ＝ＲＢ−｛ｉｎｄｅｘ［ｋ］｝
ＲＢｃａｐ＝ＲＢｃａｐ＋ｒ_{ｉｎｄｅｘ［ｋ］}
ｉ∈ＲＢであれば、ａ_ｉ＝ｒ_ｉ；／^＊割り振りは予約と等しい^＊／
ｉ∈ＬＢであれば、ａ_ｉ＝ｌ_ｉ；／^＊割り振りは制限と等しい^＊／
／^＊ＰＳ要素はキャパシティの残りをシェアの比率で得る^＊／
ｉ∈ＰＳであれば、ａ_ｉ＝（ｗ_ｉ／Σ_ｊ∈ＰＳｗ_ｊ）×（Ｃ−ＬＢｃａｐ−ＲＢｃａｐ）：
上記のアルゴリズムはｎ個のＶＭ分のランタイムＯ（ｎ^＊ｌｏｇ ｎ）を持ち、時間により分けられて、分別されたシーケンスＶが作られる。工程の終わりに、いくつかの子供はその制限で上限が定められ（ＬＢ集合）、またいくつかはその予約以上には割り振りを受けておらず（ＲＢ集合）、残りはそのシェアに比例する割り振りを受けている（ＰＳ集合）。

【0048】

配分構成要素５０８によって実行される配分工程の一例をここで、図６を参照しながら説明するが、これは図４に示すものと同じリソースプール階層構造を示している。しかしながら、図６では、リソースプール階層構造の各ノードの静的な予約、制限、シェアの値が示されている。これに加えて、ＶＭ２２０Ａ、２２０Ｂ、２２０Ｃ、および２２０Ｄの計算された要求も示されている。さらに、配分工程の結果、すなわち動的な予約、制限、シェアの値がノード４０２Ａおよび４０２Ｂ、ならびにＶＭについて示されている。図６において、タプルＵは静的な設定または値を示し、タプルＤは予約、制限、シェアの値の動的な配分結果を示す。この例では、上述の効率的な分配アルゴリズムが配分工程に使用されている。

【0049】

Ｒ−配分動作に関して、配分構成要素５０８は、リソース要求更新構成要素５０２によって更新されたＶＭの要求を、リソースプール階層構造のノードにおける制限設定の一時的な上限として使用する。ＶＭの要求がそれぞれ６００、４００、４００、および１００であるため、ＶＭの制限の一時的上限はそれぞれ６００、４００、４００、および１００に設定される。配分構成要素はまた、ＶＭの要求を合算して、ノード４０２Ａと４０２Ｂに関する要求の値を得る。この例において、ノード４０２Ａと４０２Ｂの合算要求は、それぞれ１，０００および５００であり、これはＶＭ ２２０Ａと２２０Ｃの要求の合計が１，０００であり、ＶＭ２２０Ｂと２００Ｄの要求の合計が５００であるからである。それゆえ、ノード４０２Ａと４０２Ｂの制限の一時的な上限は、それぞれ１，０００および５００に設定される。

【0050】

配分構成要素５０８は次に、ルートノード４０４からＶＭ２２０Ａ、２２０Ｂ、２２０Ｃ、および２２０Ｄとレベルごとに進み、親の予約を子供間で配分する。リソースプール階層構造のルートノード４０４では、ユーザによって１，２００に設定されている予約値Ｒがノード４０２Ａと４０２Ｂの間でそれぞれのシェアの比率（３：１）で配分され、その結果、それぞれの割り振りは９００と３００になる。これらの値はノード４０２Ａと４０２Ｂの予約と制限の値の間にあるため、これらはルートノードでのＲ−配分動作の最終的な結果となる。

【0051】

リソースプール階層構造の次のレベルでは、ノード４０２Ａの予約Ｒ＝９００がＶＭ２２０Ａと２２０Ｃの間で配分される。そのシェアの比率（１：２）に基づいて、ＶＭ２２０Ａはその予約値に３００が割り振られ、これはその予約４００より小さい。したがって、配分構成要素５０８は実際に、ＶＭ２２０Ａにユーザが設定した予約の数量４００を与え、ＶＭ２２０Ｃは残り、すなわち５００の値を得る。ＶＭ２２０Ｂと２２０Ｄに関して、ノード４０２Ｂの予約Ｒ＝３００は、ＶＭ２２０Ｂと２２０Ｄの間でそのシェアの比率（１：１）に基づいて均等に配分される。しかしながら、ＶＭ２２０Ｄの制限が一時的にその要求を上限とされているため、ＶＭ２２０Ｄには１００が与えられ、その一方で、ＶＭ２２０Ｂは残りの数量２００を得る。

【0052】

Ｌ−配分動作に関して、配分構成要素５０８は同様に、親の制限の値をレベルごとにその子供間で分ける。ルートノード４０４でユーザが設定した制限Ｌ＝２３００はノード４２０Ａと４０２Ｂの間でそのシェアの比率（３：１）で分けられる。しかしながら、ノード４０２Ｂへの割り振りは、その制限の設定値５００が上限となり、その結果、１，８００と５００がそれぞれノード４０２Ａと４０２Ｂに割り振られる。

【0053】

次のレベルで、ノード４０２Ａの制限Ｌ＝１８００がＶＭ２２０Ａと２２０Ｃの間で配分される。そのシェアの比率（１：２）に基づいて、ＶＭ２２０Ａにはその制限の値に６００が割り振られ、ＶＭ２２０Ｃにはその制限の値に１，２００が割り振られる。ＶＭ２２０Ｂと２２０Ｄに関して、制限Ｌ＝５００が、ＶＭ２２０Ｂと２２０Ｄの間でそのシェアの比率（１：１）に基づいて均等に配分される。しかしながら、ＶＭ２２０Ｄに関する制限が一時的にその要求を上限とされているため、ＶＭ２２０Ｄには１００が与えられ、その一方で、ＶＭ２２０Ｂは残りの数量４００を得る。

【0054】

Ｓ−配分動作に関して、リソースプール階層構造の各レベルで、配分構成要素５０８は単純に親ノードのシェアをその子ノード間でそのシェアの比率により分ける。それゆえ、ルートノード４０４でユーザが設定したシェアＳ＝１，０００がノード４０２Ａと４０２Ｂの間でそのシェアの比率（３：１）により分けられ、その結果、７５０と２５０がそれぞれノード４０２Ａと４０２Ｂに割り振られる。次のレベルでは、ノード４０２Ａのシェアの値Ｓ＝７５０がＶＭ ２２０Ａと２２０Ｃの間でそのシェアの割合（１：２）に基づいて配分され、その結果、２５０と５００がそれぞれＶＭ ２２０Ａと２２０Ｃに割り振られる。これに加えて、ノード４０２Ｂのシェアの値Ｓ＝２５０がＶＭ２２０Ｂと２２０Ｄの間でそのシェアの比率（１：１）に基づいて配分され、その結果、１２５と１２５がそれぞれＶＭ２２０Ｂと２２０Ｄに割り振られる。

【0055】

上記の例では、ＶＭ２２０Ｂと２２０Ｄの静的な設定値は同じである。しかしながら、その要求の差によって、結果として得られる動的な設定値はＶＭ２２０Ｂと２２０Ｄの間で異なる。ＶＭ２２０Ａと２２０Ｃに関して、ＶＭ２２０ＣにはＶＭ２２０Ａより多くの予約が与えられており、これはＶＭ２２０Ａのシェアの値のほうが大きいからである。しかしながら、ＶＭ２２０Ａについてユーザが設定した予約に適合するために、ＶＭ２２０ＣはＶＭ２２０Ａの予約の２倍未満を受け取っている。

【0056】

図５に戻ると、ＳＲＰモジュール２３８のホストキューデプス調整構成要素５１０は、新しいホストキューデプスの値、すなわち命令発行キュー２３６のデプスを、配分構成要素５０８により計算されたアレイＩＯＰＳに関するホストコンピュータ１０４ＡのＶＭ２２０Ａ、２２０Ｂ．．．２２０Ｎのエンタイトルメントに基づいて計算するように動作する。ホストキューデプス調整構成要素は、ホストキューデプスを調整するために、以下の方程式を用いて新しいホストキューデプスを計算する。

【0057】

【数5】

式中、Ｑ（ｔ＋１）はアレイキューデプスの値、ａｒｒａｙＩＯＰＳはアレイのＩＯＰＳキャパシティ、Ｅ_ｉはホストコンピュータのＶＭのエンタイトルメントである。

【0058】

図２に戻ると、ローカルスケジューラ２４０は、ホストコンピュータ１０４Ａのアレイキャパシティのシェア、すなわちＳＲＰモジュール２３８のホストキューデプス調整構成要素５１０によって計算された新しいホストキューデプスの値を、ＶＭ ２２０Ａ、２２０Ｂ．．．２２０Ｎの間で割り振るように動作する。ローカルスケジューラは、ＳＲＰモジュールによって計算されたＶＭの動的な予約、制限、シェアの設定を使用して、ＶＭからのＩＯリクエストのスケジュールを立てる。ローカルスケジューラは、新しいホストキューデプスの値によって定義される制限をホストコンピュータでの未処理のＩＯの総数に適用する。ある実施形態において、ローカルスケジューラは、アジャイ・グラティ（Ａｊａｙ Ｇｕｌａｔｉ）、アリフ・マーチャント（Ａｒｉｆ Ｍｅｒｃｈａｎｔ）、ピーター・バーマン（Ｐｅｔｅｒ Ｖａｒｍａｎ）の「ｍＣｌｏｃｋ：ハイパーバイザＩＯスケジューリングのスループット可変性の扱い（ｍＣｌｏｃｋ：Ｈａｎｄｌｉｎｇ Ｔｈｒｏｕｇｈｐｕｔ Ｖａｒｉａｂｉｌｉｔｙ ｆｏｒ Ｈｙｐｅｒｖｉｓｏｒ ＩＯ Ｓｃｈｅｄｕｌｉｎｇ）」に記載されているｍＣｌｏｃｋスケジューラである。しかしながら、他の実施形態では、ＳＲＰモジュールにより計算されたＶＭの動的な予約、制限、シェアの設定を使い、その一方でホストキューデプスの値により定義される制限に従い、ホストコンピュータのＩＯリクエストのスケジュールを立てることができる任意のＩＯスケジューラを、ローカルスケジューラとして使用できる。

【0059】

このようにして、ネットワークコンピュータシステム１００の中の各ホストコンピュータは、ストレージの平均レイテンシに基づいて、ストレージ１０６のキャパシティ全体の一部をそれ自体に独立して割り振り、共有ストレージリソースに対するクライアントの要求に基づいて計算された動的な予約、制限、シェアの値の計算結果を使って、そのホストコンピュータ上で動作中のクライアント間で割り振られたストレージリソースを管理できる。それゆえ、ネットワークコンピュータシステムが共有ストレージリソースを効率的に割り当てるために中央集中的なＱｏＳマネージャ／スケジューラは必要とならない。

【0060】

いくつかの実施形態において、ホストコンピュータ１０４Ａ、１０４Ｂ．．．１０４Ｎ上で動作中のクライアントは、同様に共有ストレージリソースを必要とする下位の構成要素を含んでいてもよい。それゆえ、これらの実施形態では、このような下位の構成要素を、共有ストレージリソースを消費する「クライアント」と考えてもよい。例えば、ホストコンピュータの１つで動作中のＶＭは、ストレージ１０６に保存される１つまたは複数の仮装マシンファイル、例えば仮想マシンディスク（ＶＭＤＫ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｄｉｓｋ）に関連付けられていてもよい。これらのＶＭのＶＭＤＫは共有ストレージリソースを消費し、それゆえ、それにはリソースを効率的に共有するために、予約、制限、シェアの値が割り当てられる。ある実施形態において、ＶＭのＶＭＤＫはまた、リソースプール階層構造の中に含められ、ＱＯＳ制御のために、各ホストコンピュータのＳＲＰモジュール２３８とローカルスケジューラ２４０によって考慮される。

【0061】

ＶＭＤＫを含むリソースプール階層構造７００の例が図７に示されている。図７に示されるように、階層構造７００はルートノード７０２と、ノード７０４Ａおよび７０４Ｂと、ＶＭ７０６Ａ、７０６Ｂ、７０６Ｃ、７０６Ｄ、および７０６Ｅと、ＶＭＤＫ７０８Ａ、７０８Ｂ、７０８Ｃ、７０８Ｄ、７０８Ｅ、７０８Ｆ、７０８Ｇ、および７０８Ｈと、を含む。このリソースプール階層構造では、各ホストコンピュータのＳＲＰモジュール２３８とローカルスケジューラ２４０は、単純にストレージ１０６のキャパシティとルートノード７０２に割り当てられた全体的な予約、制限、シェアの値を上述の方法でＶＭＤＫへと分配する。状況によっては、ＶＭＤＫは異なるデータストアで保存されてもよい。例えば、ＶＭＤＫ７０８Ａ、７０８Ｂ、７０８Ｄ、７０８Ｅ、および７０８Ｈはデータストア１に保存されてもよく、ＶＭＤＫ７０８Ｃ、７０８Ｆ、および７０８Ｇはデータストア２に保存されてもよい。このような状況では、ホストコンピュータ１０４Ａ、１４０Ｂ．．．１０４Ｎの各々におけるＳＲＰモジュールは、リソースプール階層構造を、ユーザが提供できるデータストアの情報を使ってデータストアごとのリソースプール階層構造に分割するように構成されていてもよい。例えば、リソースプール階層構造７００は、それぞれデータストア１と２に対応するリソースプール階層構造７５０Ａと７０５Ｂに分割されてもよい。次いで、各ホストコンピュータのＳＲＰモジュールは、データストアごとのリソースプール階層構造７５０Ａと７５０Ｂの各々を上述の方法で動作させて、ＱｏＳ制御を提供する。

【0062】

本発明のある実施形態による、共通リソースにアクセスするためにホストコンピュータ上で動作中のクライアントのためにクオリティ・オブ・サービス（ＱｏＳ）を提供する方法を、図８のフロー図を参照しながら説明する。ブロック８０２では、共通リソースの現在のキャパシティが、クライアントが共通リソースにアクセスする際のレイテンシの全体的な平均に基づいて計算される。ブロック８０４では、共通リースに関する各クライアントのエンタイトルメントが、計算された現在のキャパシティと共通リソーに対するクライアントの要求に基づいて計算される。ブロック８０６では、共有リソースの計算された現在のキャパシティの一部が特定のホストコンピュータに、その特定のホストコンピュータ上で動作中の各クライアントの計算されたエンタイトルメントを使って割り当てられる。ブロック８０８では、計算された現在のキャパシティの一部が、その特定のホストコンピュータ上で動作中のクライアント間で割り振られる。

【0063】

本明細書の方法の動作は特定の順序で示され、説明されているが、各方法の動作の順序を変更して、特定の動作を逆の順序で行ってもよく、または特定の動作を少なくとも部分的に他の動作と同時に実行してもよい。他の実施形態では、別々の動作の命令または下位の動作を間欠的および／または交互に実施してもよい。

【0064】

この方法のための動作の少なくとも一部は、コンピュータにより実行されるためのコンピュータ使用可能なストレージ媒体に保存されたソフトウェア命令を使って実装してもよいことにも留意すべきである。例えば、コンピュータプログラム製品のある実施形態は、コンピュータにより実行されると、コンピュータに本明細書に記載された動作を実行させるようなコンピュータ可読ブログラムを保存する、コンピュータ使用可能なストレージ媒体を含む。

【0065】

さらに、本発明の少なくとも一部の実施形態は、コンピュータまたはいずれかの命令実行システムによって、またはこれに関連して使用するためのプログラムコードを提供するコンピュータ使用可能またはコンピュータ可読媒体からアクセス可能なコンピュータプログラムの形態をとることができる。この説明の解釈において、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって、またはこれに関連して使用するためのプログラムを含み、保存し、通信し、伝播し、または転送する任意の装置とすることができる。

【0066】

コンピュータ使用可能またはコンピュータ可読媒体は、電子、磁気、光、電磁気、赤外線、または半導体システム（もしくは装置もしくはデバイス）または伝播媒体とすることができる。コンピュータ可読媒体の一例は、半導体またはソリッドステートメモリ、磁気テープ、リムーバブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、リジッド磁気ディスク、光ディスクを含む。光ディスクの現時点での例には、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスクリード／ライト（ＣＤ−Ｒ／Ｗ）、デジタルビデオディスク（ＤＶＤ）、およびブルーレイディスクが含まれる。

【0067】

上記の説明において、各種の実施形態の具体的な詳細が提供されている。しかしながら、いくつかの実施形態はこれらの具体的な詳細のすべてがなくても実施できる。他の例では、特定の方法、手順、構成要素、構造および／または機能は、簡潔性と明瞭性のために、本発明の各種の実施形態を可能にする程度以上に詳細には説明されていない。

【0068】

本発明の具体的な実施形態を説明し、示したが、本発明は説明され、示された部品の具体的な形態または配置に限定されない。本発明の範囲は、添付の特許請求の範囲とその均等物によって定義されるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】