(57)【要約】本開示の実施形態は、輻輳を測定し、共有リソースへのサービス品質を制御する技法を提供する。共有リソースとインターフェースするモジュールは、クライアントにアクセスすることによって共有リソースの使用をモニタする。共有リソースの使用率が共有リソースによってサポートされる最大率を超えたことが検出されると、モジュールは、輻輳メトリックを特定し、共有リソースへのアクセスを現在試みているクライアントに輻輳メトリックを送信する。そして、クライアントは、共有リソースの別のアクセスを試みる前に、輻輳メトリックに基づいて遅延期間を決定する。
2016525761.tif 000002
【特許請求の範囲】
【請求項１】
共有リソースへのアクセスを有する複数のクライアントにリソース使用フィードバックを提供するコンピュータ実行方法であって、
前記複数のクライアントのうちの少なくとも一部分による前記共有リソースの使用率をモニタすることであって、各クライアントには、前記共有リソースに対して最小使用率が確保されている、前記モニタすること、
前記共有リソースの使用率が、前記共有リソースによってサポートされる最大使用率を超えたと判断されると、前記共有リソースへのアクセスを現在試みている前記複数のクライアントのうちの少なくとも一部分の輻輳メトリックを特定することであって、各クライアントの輻輳メトリックは、前記共有リソースの前記クライアントの使用に基づき、前記共有リソースの別のアクセスを試みる前の遅延期間を計算するのに前記クライアントによって使用される、前記特定すること、
特定された輻輳メトリックのそれぞれを、対応するクライアントに送信することを備える、方法。
【請求項２】
前記共有リソースは、前記複数のクライアントの実行をサポートするホストコンピュータのクラスタに属するホストコンピュータに収容されたローカル記憶ドライブであり、
前記クラスタ内の各ホストコンピュータは、対応するローカル記憶ドライブに、単一の仮想記憶デバイスとしてアクセス可能な共有リソースのプールを形成する、請求項１に記載の方法。
【請求項３】
前記複数のクライアントのうちの少なくとも１つが、仮想ディスクでＩ／Ｏ動作を実行しており、
前記仮想ディスクの少なくとも１つのセクションは、前記共有リソースの部分によってバッキングされ、前記仮想ディスクの少なくとも１つの他のセクションは、前記クラスタに属する異なるホストコンピュータに収容された異なるローカル記憶ディスクによってバッキングされる、請求項２に記載の方法。
【請求項４】
前記仮想ディスクは、ＲＡＩＤ０ストライプセットとして編成され、
前記共有リソースの一部分によってバッキングされる前記仮想ディスクのセクション、異なるローカル記憶ディスクによってバッキングされる前記仮想ディスクの少なくとも１つの他のセクションは両方とも、前記ＲＡＩＤ０ストライプセット内の異なるストライプを表す、請求項３に記載の方法。
【請求項５】
第２のクライアントが、Ｉ／Ｏ動作を第２の仮想ディスクで実行しており、前記第２の仮想ディスクの少なくとも１つの部分は、前記共有リソースの第２の部分によってバッキングされ、前記第２の仮想ディスクの少なくとも１つの他の部分は、前記クラスタに属する異なるホストコンピュータに収容される異なるローカルディスクによってバッキングされる、請求項３に記載の方法。
【請求項６】
前記複数のクライアントはそれぞれ、前記クラスタ内の前記ホストコンピュータの１つで実行中の仮想マシンを含む、請求項２に記載の方法。
【請求項７】
前記共有リソースに確保された最小使用率を超えた全てのクライアントには、非ゼロ値を有する輻輳メトリックが送信され、前記共有リソースに確保された最小使用率を超えない全てのクライアントには、前記クライアントによって計算される遅延期間を生じさせない輻輳メトリックゼロ値が送信される、請求項１に記載の方法。
【請求項８】
プロセッサで実行されると、共有リソースへのアクセスを有する複数のクライアントにリソース使用フィードバックを提供する動作を実行する命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記動作は、
前記複数のクライアントのうちの少なくとも一部分による前記共有リソースの使用率をモニタすることであって、各クライアントには前記共有リソースに最小使用率が確保されている、前記モニタすること、
前記共有リソースの使用率が、前記共有リソースによってサポートされる最大使用率を超えたと判断されると、前記共有リソースへのアクセスを現在試みている前記複数のクライアントのうちの少なくとも一部分の輻輳メトリックを特定することであって、各クライアントの輻輳メトリックは、前記共有リソースの前記クライアントの使用に基づき、前記クライアントによって使用されて、前記共有リソースの別のアクセスを試みる前の遅延期間を計算する、前記特定すること、
特定された輻輳メトリックのそれぞれを、対応するクライアントに送信すること、を備える、コンピュータ可読記憶媒体。
【請求項９】
前記共有リソースは、前記複数のクライアントの実行をサポートするホストコンピュータのクラスタに属するホストコンピュータに収容されたローカル記憶ドライブであり、前記クラスタ内の各ホストコンピュータは、対応するローカル記憶ドライブに、単一の仮想記憶デバイスとしてアクセス可能な共有リソースのプールを形成する、請求項８に記載のコンピュータ可読記憶媒体。
【請求項１０】
前記複数のクライアントのうちの少なくとも１つは、仮想ディスクでＩ／Ｏ動作を実行しており、前記仮想ディスクの少なくとも１つのセクションは、前記共有リソースの部分によってバッキングされ、前記仮想ディスクの少なくとも１つの他のセクションは、前記クラスタに属する異なるホストコンピュータに収容された異なるローカル記憶ディスクによってバッキングされる、請求項９に記載のコンピュータ可読記憶媒体。
【請求項１１】
前記仮想ディスクは、ＲＡＩＤ０ストライプセットとして編成され、
前記共有リソースの部分によってバッキングされる前記仮想ディスクのセクション、異なるローカル記憶ディスクによってバッキングされる前記仮想ディスクの少なくとも１つの他のセクションは両方とも、前記ＲＡＩＤ０ストライプセット内の異なるストライプを表す、請求項１０に記載のコンピュータ可読記憶媒体。
【請求項１２】
第２のクライアントが、Ｉ／Ｏ動作を第２の仮想ディスクで実行しており、前記第２の仮想ディスクの少なくとも１つの部分は、前記共有リソースの第２の部分によってバッキングされ、前記第２の仮想ディスクの少なくとも１つの他の部分は、前記クラスタに属する異なるホストコンピュータに収容される異なるローカルディスクによってバッキングされる、請求項１０に記載のコンピュータ可読記憶媒体。
【請求項１３】
前記複数のクライアントはそれぞれ、前記クラスタ内の前記ホストコンピュータの１つで実行中の仮想マシンを含む、請求項９に記載のコンピュータ可読記憶媒体。
【請求項１４】
前記共有リソースに確保された最小使用率を超えた全てのクライアントには、非ゼロ値を有する輻輳メトリックが送信され、前記共有リソースに確保された最小使用率を超えない全てのクライアントには、前記クライアントによって計算される遅延期間を生じさせない輻輳メトリックゼロ値が送信される、請求項８に記載のコンピュータ可読記憶媒体。
【請求項１５】
コンピュータシステムであって、
プロセッサと、
モジュールをホストするメモリであって、前記モジュールは、前記プロセッサで実行されると、共有リソースへのアクセスを有する複数のクライアントにリソース使用フィードバックを提供する動作を実行する、前記メモリとを備え、前記動作は、
前記複数のクライアントのうちの少なくとも一部分による前記共有リソースの使用率をモニタすることであって、各クライアントには、前記共有リソースに最小使用率が確保されている、前記モニタすること、
前記共有リソースの使用率が、前記共有リソースによってサポートされる最大使用率を超えたと判断されると、前記共有リソースへのアクセスを現在試みている前記複数のクライアントのうちの少なくとも一部分の輻輳メトリックを特定することであって、各クライアントの輻輳メトリックは、前記共有リソースの前記クライアントの使用に基づき、前記クライアントによって使用されて、前記共有リソースの別のアクセスを試みる前の遅延期間を計算する、前記特定すること、
特定された輻輳メトリックのそれぞれを、対応するクライアントに送信することを備える、コンピュータシステム。
【請求項１６】
前記共有リソースは、前記複数のクライアントの実行をサポートするホストコンピュータのクラスタに属するホストコンピュータに収容されたローカル記憶ドライブであり、
前記クラスタ内の各ホストコンピュータは、対応するローカル記憶ドライブに、単一の仮想記憶デバイスとしてアクセス可能な共有リソースのプールを形成する、請求項１５に記載のコンピュータシステム。
【請求項１７】
前記複数のクライアントのうちの少なくとも１つは、仮想ディスクでＩ／Ｏ動作を実行しており、前記仮想ディスクの少なくとも１つのセクションは、前記共有リソースの部分によってバッキングされ、前記仮想ディスクの少なくとも１つの他のセクションは、前記クラスタに属する異なるホストコンピュータに収容された異なるローカル記憶ディスクによってバッキングされる、請求項１６に記載のコンピュータシステム。
【請求項１８】
前記仮想ディスクは、ＲＡＩＤ０ストライプセットとして編成され、
前記共有リソースの部分によってバッキングされる前記仮想ディスクのセクション、異なるローカル記憶ディスクによってバッキングされる前記仮想ディスクの少なくとも１つの他のセクションは両方とも、前記ＲＡＩＤ０ストライプセット内の異なるストライプを表す、請求項１７に記載のコンピュータシステム。
【請求項１９】
第２のクライアントが、Ｉ／Ｏ動作を第２の仮想ディスクで実行しており、前記第２の仮想ディスクの少なくとも１つの部分は、前記共有リソースの第２の部分によってバッキングされ、前記第２の仮想ディスクの少なくとも１つの他の部分は、前記クラスタに属する異なるホストコンピュータに収容される異なるローカルディスクによってバッキングされる、請求項１７に記載のコンピュータシステム。
【請求項２０】
前記共有リソースに確保された最小使用率を超えた全てのクライアントには、非ゼロ値を有する輻輳メトリックが送信され、前記共有リソースに確保された最小使用率を超えない全てのクライアントには、前記クライアントによって計算される遅延期間を生じさせない輻輳メトリックゼロ値が送信される、請求項１５に記載のコンピュータシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
分散システムでは、ネットワーク内の複数のクライアントが共有リソースのプールにアクセスすることができる。例えば、分散ストレージシステムでは、ホストコンピュータのクラスタは、各ホストコンピュータ内にあるか、又は各ホストコンピュータに取り付けられたローカルディスク（例えば、ＳＳＤ、ＰＣＩベースのフラッシュストレージ、ＳＡＴＡ、又はＳＡＳ磁気ディスク）を集約して、ストレージの単一の共有プールを作成することができる。ストレージのこのプール（本明細書では「データストア」又は「ストア」と呼ばれることがある）は、クラスタ内の全てのホストコンピュータによってアクセス可能であり、ストレージエンティティの単一の名前空間（namespace）（ファイルの場合では階層ファイルシステム名前空間、オブジェクトの場合では一意の識別子のフラットな名前空間等）として提示し得る。そして、ホストコンピュータ上で生成された仮想マシン等のストレージクライアントは、データストアを使用して、例えば、動作中に仮想マシンによってアクセスされる仮想ディスクを記憶し得る。データストアを構成する共有ローカルディスクは、異なる性能特徴（例えば、容量、毎秒の入力数／出力数、又はＩＯＰＳ性能等）を有し得るため、仮想ディスク又はその部分を記憶するそのような共有ローカルディスクの使用は、所与の各仮想マシンのニーズに基づいて仮想マシンに分散される。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
この手法は、費用効率的な手法を企業に提供する。例えば、プールされたローカルディスクを使用する分散ストレージは、安価であり、高度にスケーラブルであり、管理が比較的単純である。そのような分散ストレージは、クラスタ内の商品ディスクを使用することができるため、企業は、追加のストレージ・インフラストラクチャに投資する必要がない。しかし、この手法に伴って生じる一問題は、共有ストレージリソースにアクセスしている複数のクライアント間の競合に関する。特に、複数のクライアントが、ローカルディスクのＩＯＰＳ容量を超える結合ＩＯＰＳ（毎秒入力数／出力数）で特定のホストコンピュータ内の同じローカルディスクによってバッキングされた（backed）異なるデータに同時にアクセスする必要がある場合、全体性能の低下及び待ち時間の増大が生じる。
【課題を解決するための手段】
【０００３】
本開示の一実施形態は、共有リソースへのアクセスを有する複数のクライアントにリソース使用フィードバックを提供する方法を提供する。本方法は一般に、クライアントの少なくとも部分による共有リソースの使用率をモニタするステップであって、各クライアントには、共有リソースに最小使用率が確保されている、モニタするステップを含む。共有リソースの使用率が、共有リソースによってサポートされる最大使用率を超えたと判断されると、共有リソースへのアクセスを現在試みているクライアント群の少なくとも一部の輻輳メトリックが特定される。各クライアントの輻輳メトリックは、共有リソースのクライアントの使用に基づき、共有リソースの別のアクセスを試みる前の遅延期間を計算するのにクライアントによって使用される。本方法は一般に、特定された輻輳メトリックのそれぞれを対応するクライアントに送信するステップを含む。
【０００４】
他の実施形態は、限定ではなく、処理ユニットが開示される方法の１つ又は複数の態様を実施できるように構成された命令を含むコンピュータ可読媒体と、開示される方法の１つ又は複数の態様を実施するように構成された、プロセッサ、メモリ、及びモジュールを有するコンピュータシステムとを含む。
【図面の簡単な説明】
【０００５】
【図１】一実施形態によるコンピューティング環境例を示す。
【図２】一実施形態による、仮想ディスクを表すオブジェクトストア内で編成されたオブジェクトの階層構造例を示す。
【図３】一実施形態によるＶＳＡＮモジュールの構成要素を示す。
【図４】一実施形態による、定義ストレージポリシーに基づいて仮想ディスクオブジェクトを作成する方法流れ図を示す。
【図５】一実施形態による、ＶＭに端を発するＩ／Ｏ動作の処理を示す。
【図６】実施形態による、ＶＳＡＮモジュールによりクライアントに輻輳メトリックを送信する方法の流れ図を示す。
【図７】輻輳中、ＶＳＡＮモジュールへＩ／Ｏ動作要求を遅延させる方法を示す。
【発明を実施するための形態】
【０００６】
本明細書に開示される実施形態は、共有リソース（例えば、ストレージ等）での輻輳を測定し、共有リソースの消費者に提供されるサービス品質を制御する技法を提供する。一実施形態では、共有リソース（例えば、ローカルストレージ等）をホストコンピュータのクラスタに提供するホストコンピュータは、リソースにアクセスしているクライアント（例えば、クラスタ内の任意のホストコンピュータで実行中の仮想マシン等）の共有リソース（例えば、ＩＯＰＳ等）の使用をモニタする。クライアントのうちの特定のクライアントがそれ自体に保持されたレート（rate）を超えているため、共有リソースについてクライアント間に競合がある場合（例えば、特定のクライアントが、本明細書において更に説明するように、クライアントに保持されている最小レートで共有リソースにアクセスすることができない場合）、ホストコンピュータは、共有リソースにアクセスを試みているクライアントのうちの少なくとも一部に輻輳メトリック（congestion metric）を出力する。輻輳メトリックは、リソース競合の程度を特定し得る。クライアントは、輻輳メトリックを使用して、続く要求（例えば、Ｉ／Ｏ要求等）が共有リソースにアクセスするのをどれくらい遅延させるかを決定する。例えば、特定の実施形態では、クライアントは、輻輳メトリックに基づいてある時間期間にわたり要求を遅延させる非ゼロ輻輳メトリック（non-zero congestion metric）を受信し（例えば、保持された率を超えたクライアント）、一方、他のクライアントは、「ゼロ」輻輳メトリック（zero congestion metric）を受信し（例えば、保持されたレート以内でリソースを使用したクライアント）、要求を即座に送信し得る。ストレージリソースをホストしているコンピュータは、所与のクライアントが、仮に全ての要求が即座に送達された場合に有し得る合計サービス時間と同様の合計サービス時間を有するように、輻輳メトリックへの応答を較正し得る。
【０００７】
例えば、本明細書に記載の技法は分散ストレージシステムの実施に使用し、この分散ストレージシステムでは、ホストコンピュータは、ホストコンピュータのローカルストレージにアクセスしている他のホストコンピュータに配置され得るクライアントによるＩ／Ｏ動作要求についての輻輳メトリックを出力する。当てはまる分散ストレージシステムの一例は、ソフトウェアベースの「仮想ストレージエリアネットワーク」（virtual storage area network : ＶＳＡＮ）であり、このネットワークでは、クラスタ内のホストサーバはそれぞれ、その商品であるローカルストレージリソース（例えば、ハードディスク及び／又は固体状態ドライブ等）を総合「オブジェクト」ストアの提供に寄与するノードとして機能する。各ホストサーバは、ストレージ管理ワークフローを自動化し（例えば、オブジェクトストア内でのオブジェクトの作成等）、オブジェクトストア内のオブジェクトに指定された予め定義されるストレージポリシーに基づいてオブジェクトストア内のオブジェクトへのアクセスを提供する（例えば、オブジェクトストア内のオブジェクトへのＩ／Ｏ動作の処理等）ために、ストレージ管理モジュール（本明細書ではＶＳＡＮモジュールと呼ばれることもある）を含み得る。特定の実施形態では、ホストサーバは、ＶＳＡＮオブジェクトストアへのクライアントとして機能する仮想マシン（virtual machine : ＶＭ）のインスタンス化を更にサポートする。そのような実施形態では、オブジェクトストアに記憶された「オブジェクト」は、例えば、ＶＭ構成ファイル及び仮想ディスク記述子ファイルを含み得るファイルシステムオブジェクト、実行時中にＶＭによってアクセスされる仮想ディスクオブジェクト等を含み得る。
【０００８】
管理者はまず、意図される使用（例えば、容量、可用性、ＩＯＰＳ等）に応じて「仮想ディスク」の特定の記憶要件を用いてＶＭを構成し得、管理者は、そのような可用性、容量、ＩＯＰＳ等を指定する各ＶＭのストレージプロファイル又はポリシーを定義し得る。更に後述するように、次に、ＶＳＡＮモジュールは、定義されたポリシーに基づいて、オブジェクトストアの物理的ストレージリソースでバッキングした（backing）ＶＭの仮想ディスクを作成し得る。例えば、管理者は、「４００」の読み出しＩＯＰＳの最小確保を要求する（しかし、消費可能な読み出しＩＯＰＳの最大量への制限はない）ストレージポリシーをＶＭ  Ａの仮想ディスクに対して指定し、したがって、ＶＳＡＮモジュールは、最大で「５５０」の読み出しＩＯＰＳを提供することができるローカルストレージリソースによってバッキングされた仮想ディスク「オブジェクト」を作成し得る。さらに、管理者は、「１００」の読み出しＩＯＰＳの最小確保を要求する（しかし、ここでも、消費可能な読み出しＩＯＰＳの最大量への制限はない）別のストレージポリシーをＶＭ  Ｂの仮想ディスクに対して指定し得る。ＶＳＡＮモジュールは、同じローカルストレージリソースを用いてＶＭ  Ｂの仮想ディスクをバッキングすることもできる（したがって、「５０」の読み出しＩＯＰＳが残る）。ＶＭ  Ａがその最大確保である「４００」の読み出しＩＯＰＳを超え、例えば、５００読み出しＩＯＰＳを利用する場合、ＶＭ  Ｂはローカルストレージリソースへの競合を経験せずに、「５０」の読み出しＩＯＰＳのレートで仮想ディスクへのＩ／Ｏ動作を実行し続けることができる。しかし、ＶＭ  Ａが「５００」の読み出しＩＯＰＳで仮想ディスクに対してＩ／Ｏを実行し続け、ＶＭ  Ｂが最小確保量である「１００」の読み出しＩＯＰＳを使用して、それ自体の仮想ディスクにアクセスする必要がある場合、競合が生じる。
【０００９】
一実施形態では、各ノード（例えば、ホストサーバ）でのＶＳＡＮモジュールは、ノードのローカルストレージリソースがクライアント（例えば、そのようなノードで実行中のＶＭの代理として機能している他のノード上の他のＶＳＡＮモジュール等）によってアクセスされているレートをモニタする。一実施形態では、各ノードに存在しているＶＳＡＮモジュールは、現在のリソース使用ステータスをクラスタ内の他のノードの他のＶＳＡＮモジュールにブロードキャストし得る。例えば、複数のクライアントによる同時アクセスに起因して、競合がローカルストレージリソースで生じる場合、ノードは輻輳メトリックを計算し、次に、輻輳メトリックは、ローカルストレージリソースにアクセスしようとしているクライアントに発行される。輻輳メトリックは、どの程度の輻輳が発生しているかの測定値を示し、クライアント（例えば、ローカルストレージリソースに達するＩ／Ｏ動作を実行中のＶＭの代理として機能しているＶＳＡＮモジュール）にＩ／Ｏ動作要求を遅延又は他の様式で抑制させる。特定の実施形態では、ノード内のＶＳＡＮモジュールは、それ自体も輻輳メトリックを使用して、ローカルストレージリソースへの入力要求をキューに入れ、遅延させる。
【００１０】
代替的には、ストレージリソースをホストするホストコンピュータのＶＳＡＮモジュールは、リソースの輻輳量を計算する。特定されると、ＶＳＡＮモジュールは、特定のクライアントのリソース使用を計算せずに、輻輳メトリックをクライアントに送信する。輻輳メトリックをホストコンピュータから受信すると、クライアントは、それ自体のリソース使用と、割り振られたリソースを超えているか否かとに基づいて、遅延期間を計算する。
【００１１】
この手法により、複数のクライアントにわたる分散プロビジョニング及び非集中化ポリシー施行が可能である。サーバ（例えば、ローカルストレージリソースを収容しているノード）での単一の大きなキューをサーバでのより小さなキュー及び各クライアントでの別個のキュー（要求毎の全体平均キュー遅延が、単一の大きなキューを使用して見られるものである）に分けることにより、この手法は、各クライアントの要求の差別化優先度スケジューリングを可能にしながら、サーバでのバッファリングに必要な空間を低減する。さらに、保持されたリソース割り振りを超えるクライアントのみがＶＳＡＮモジュールへの要求を遅延させる（保持されたリソースを使用しているクライアントはＶＳＡＮモジュールへの要求を遅延させない）ため、そのような手法が必要とする複雑な論理はより少数であり、その結果、分散システムの性能が改善する。
【００１２】
これより、例が添付図に示される幾つかの実施形態を詳細に参照する。なお、実施可能な場合は常に、類似又は同様の参照番号が図に使用され得、類似又は同様の機能を示し得る。図は、例示のみを目的として実施形態を示す。以下の説明から、本明細書に記載される原理から逸脱せずに、本明細書に示される構造及び方法の代替の実施形態が利用可能なことを当業者は容易に認識することになる。
【００１３】
以下、ＶＳＡＮモジュールは、リソースをモニタし、複数のポイントでのリソースの輻輳を制御するシステムの参照例を提供する。この参照例は、本明細書に記載される実施形態の理解を提供するために包含される。しかし、これらの実施形態が、コンピューティング環境のタイプに関わりなく、分散ストレージリソースのクライアントへの割り振りに関連する他の状況でも適用可能なことが当業者には明らかであろう。例えば、実施形態は、ソフトウェア定義のコンピュータ、ネットワーク、及びストレージアレイに適用可能であり得る。さらに、実施形態は、他の共有計算リソース（例えば、処理リソース、メモリリソース、及びネットワークリソース等）の割り振りに関連する他の状況で適用可能でもあり得る。
【００１４】
同様に、多くの特定の詳細が提供されて、実施形態の完全な理解を提供する。これらの特定の詳細の幾つかなしで実施形態が実施可能なことを当業者は認識しよう。他の場合、周知のプロセス動作及び実施詳細は、本開示の新規の態様を不必要に曖昧にしないように、詳述されていない。
【００１５】
図１は、一実施形態によるコンピューティング環境１００を示す。示されるように、コンピューティング環境１００は、クラスタ１１０のホストサーバ又はノード１１１に収容される（housed）か、又は直接取り付けられた（以下、「収容」若しくは「内に収容（housed in）」という用語の使用は、収容若しくは他の様式での直接取り付けの両方を包含するために使用され得る）商品ローカルストレージを利用して、ノードで実行中の仮想マシン（ＶＭ）１１２に集合オブジェクトストア１１６を提供するＶＳＡＮ環境である。ノード１１１内に収容されるか、又は他の様式で直接取り付けられるローカル商品ストレージは、固体状態ドライブ（solid state drive : ＳＳＤ）１１７及び／又は磁気又は回転ディスク１１８の組合せを含み得る。特定の実施形態では、ＳＳＤ１１７は、磁気ディスク１１８の前段の読み出しキャッシュ及び／又は書き込みバッファとして機能して、Ｉ／Ｏ性能を向上させる。
【００１６】
仮想化管理プラットフォーム１０５が、ノード１１１のクラスタ１１０に関連付けられる。仮想化管理プラットフォーム１０５は、管理者が様々なノード１１１上のＶＭの構成及び生成を管理できるようにする。図１の実施形態に示されるように、各ノード１１１は、仮想化レイヤ又はハイパーバイザ１１３、ＶＳＡＮモジュール１１４、及び（ノード１１１のＳＳＤ１１７及び磁気ディスク１１８を含む）ハードウェア１１９を含む。ハイパーバイザ１１３を通して、ノード１１１は、複数のＶＭ１１２を起動し実行することができる。ハイパーバイザ１１３は、部分的に、ハードウェア１１９を管理して、計算リソース（例えば、処理電力、ランダムアクセスメモリ等）を各ＶＭ１１２に適宜割り振る。さらに、更に後述するように、各ハイパーバイザ１１３は、対応するＶＳＡＮモジュール１１４を通して、クラスタ１１０内の任意のノード１１１に存在する任意のＶＭ１１２がアクセスし得る仮想ディスク（又はその部分）及び他の関連ファイルのストレージとして使用するために、ハードウェア１１９に配置されたストレージリソース（例えば、ＳＳＤ１１７及び磁気ディスク１１８）へのアクセスを提供する。特定の実施形態では、ＶＭウェア社（ＶＭｗａｒｅ，Ｉｎｃ．）（ＶＭウェア（ＶＭｗａｒｅ））からのｖスフィア（ｖＳｐｈｅｒｅ）ハイパーバイザが、ハイパーバイザ１１３としてノード１１１にインストールされ、ＶＭウェア（ＶＭｗａｒｅ）からのｖセンターサービス（ｖＣｅｎｔｅｒ  Ｓｅｒｖｅｒ）は、仮想化管理プラットフォーム１０５として使用され得る。
【００１７】
一実施形態では、ＶＳＡＮモジュール１１４は、ハイパーバイザ１１３内の「ＶＳＡＮ」デバイスドライバとして実行される。そのような実施形態では、ＶＳＡＮモジュール１１４は概念化（conceptual）「ＶＳＡＮ」１１５へのアクセスを提供し、概念化「ＶＳＡＮ」１１５を通して、管理者は、オブジェクトストア１１６によって裏付けられる幾つかの最上位レベル「デバイス」又は名前空間オブジェクトを生成することができる。一般的な特定のシナリオでは、デバイスオブジェクトの作成中、管理者は、デバイスオブジェクトに特定のファイルシステムを指定し得る（したがって、以下、そのようなデバイスオブジェクトは「ファイルシステムオブジェクト」とも呼ばれる）。例えば、一実施形態では、各ノード１１１内の各ハイパーバイザ１１３は、ブートプロセス中、ＶＳＡＮモジュール１１４によって公開される（exposed）概念的グローバル名前空間の／ｖｓａｎ／ルートノードを発見し得る。例えば、ＶＳＡＮモジュール１１４によって公開されるＡＰＩにアクセスすることにより、ハイパーバイザ１１３は、ＶＳＡＮ１１５に現在存在している全ての最上位レベルファイルシステムオブジェクト（又は他のタイプの最上位レベルデバイスオブジェクト）を特定することができる。ＶＭ（又は他のクライアント）がファイルシステムオブジェクトの１つにアクセスを試みる場合、ハイパーバイザ１１３は、そのときにファイルシステムオブジェクトを動的に「オートマウント（auto-mount）」し得る。例えば、ＶＳＡＮ１１５を通してアクセス可能なファイルシステムオブジェクト（例えば、／ｖｓａｎ／ｆｓ＿ｎａｍｅ１等）が実行されて、同時にアクセスするＶＭに同時に制御を提供するように構成される、ＶＭｗａｒｅの分散又はクラスタ化ファイルシステムＶＭＦＳ等の特定のファイルシステムのセマンティクス（semantics）をエミュレートし得る。ＶＳＡＮ１１５は複数のファイルシステムオブジェクトをサポートするため、任意の特定のクラスタ化ファイルシステムの制限によって限られずに、オブジェクトストア１１６を通してストレージリソースを提供することもできる。例えば、多くのクラスタ化ファイルシステム（例えば、ＶＭＦＳ等）は、ノード群１１１の特定量をサポートするようにしかスケーリングすることができない。複数の最上位レベルファイルシステムオブジェクトサポートを提供することにより、ＶＳＡＮ１１５は、そのようなクラスタ化ファイルシステムのスケーラビリティ制限を解消する。
【００１８】
以下の図２の説明で更に詳述するように、ファイルシステムオブジェクトはそれ自体、クラスタ１１０で実行中のＶＭ１１２によってアクセス可能な幾つかの仮想ディスク記述子ファイル（例えば、ｖスフィア（ｖＳｐｈｅｒｅ）環境内の．ｖｍｄｋファイル等）にアクセスを提供し得る。これらの仮想ディスク記述子ファイルは、仮想ディスクの実際のデータを含み、オブジェクトストア１１６によって別個にバッキングされる仮想ディスク「オブジェクト」への参照を含む。仮想ディスクオブジェクトそれ自体は、階層又は「複合」オブジェクトであり、これは、更に後述するように、仮想ディスクを最初に作成するとき、管理者によって生成された対応するストレージプロファイル又はポリシーのストレージ要件（例えば、容量、可用性、ＩＯＰＳ等）を反映した「構成要素」オブジェクト（ここでもオブジェクトストア１１６によって別個にバッキングされる）で更に構成される。更に後述するように、各ＶＳＡＮモジュール１１４は（更に後述する実施形態では、クラスタレベルオブジェクト管理又は「ＣＬＯＭ」サブモジュールを通して）、他のノード１１１の他のＶＳＡＮモジュール１１４と通信して、オブジェクトストア１１６に記憶された様々なオブジェクトのロケーション、構成、ポリシー、及び関係を記述するメタデータを含むインメモリメタデータデータベース（in-memory metadata database）を作成し保持する（例えば、各ノード１１１のメモリ内に別個ではあるが、同期して保持される）。このインメモリメタデータデータベースは、例えば、管理者が最初にＶＭに仮想ディスクを作成するとき、及びＶＭが仮想ディスク上でＩ／Ｏ動作（例えば、読み取り又は書き込み）を実行し、実行しているとき、ノード１１１上のＶＳＡＮモジュール１１４によって利用される。図３の状況で更に後述するように、ＶＳＡＮモジュール１１４は（更に後述される一実施形態では、ドキュメントオブジェクトマネージャ又は「ＤＯＭ」サブモジュールを通して）、インメモリデータベース内のメタデータを使用してオブジェクトの階層をトラバースし（traverse）、Ｉ／Ｏ動作を受ける仮想ディスクの部分をバッキングする実際の物理的ローカルストレージを収容する１つ又は複数のノードにＩ／Ｏ動作要求を適宜ルーティングする。
【００１９】
図２は、一実施形態による、仮想ディスクを表すオブジェクトストア１１６内の編成されたオブジェクトの階層構造例を示す。先に上述したように、複数のノード１１１のうちの１つで実行中のＶＭ１１２は、オブジェクトストア１１６内の階層又は複合オブジェクト２００として記憶された仮想ディスクに対してＩ／Ｏ動作を実行し得る。ハイパーバイザ１１３は、ＶＳＡＮモジュール１１４を通してＶＳＡＮ１１５の抽象化とインターフェースすることにより（例えば、一実施形態では、上述したように、仮想ディスクオブジェクトに対応する最上位レベルファイルシステムオブジェクトをオートマウントすることにより）、仮想ディスクにＶＭ１１２アクセスを提供する。例えば、ＶＳＡＮモジュール１１４は、インメモリメタデータデータベースのローカルコピーをキューに入れることにより、仮想ディスクの記述子ファイル２１０（例えば、．ｖｍｄｋファイル等）を記憶したＶＳＡＮ１１５に記憶された特定のファイルシステムオブジェクト２０５（例えば、一実施形態では、ＶＭＦＳファイルシステムオブジェクト等）を識別することができる。ファイルシステムオブジェクト２０５が、仮想化環境をサポートする場合、仮想マシン構成ファイル（例えば、ｖスフィア（ｖＳｐｈｅｒｅ）環境内の．ｖｍｘファイル等）等の目的に合った様々な他のファイルを記憶し得ることを認識されたい。特定の実施形態では、各ファイルシステムオブジェクトは、特定のＶＭに対応する仮想ディスク（例えば、「ＶＭ毎」のファイルシステムオブジェクト）のみをサポートするように構成し得る。
【００２０】
記述子ファイル２１０は、オブジェクトストア１１６に別個に記憶され、仮想ディスクを概念的に表す複合オブジェクト２００（したがって、本明細書では仮想ディスクオブジェクトと呼ばれることもある）への参照を含む。複合オブジェクト２００は、仮想ディスク作成時に管理者によって生成される対応するストレージプロファイル又はポリシー内のストレージ要件又はサービスレベル契約（ＳＬＡ：ｓｅｒｖｉｃｅ  ｌｅｖｅｌ  ａｇｒｅｅｍｅｎｔ）（例えば、容量、可用性、ＩＯＰＳ等）に合う仮想ディスクのストレージ編成又は構成を記述したメタデータ（本明細書では、仮想ディスク「ブループリント（blueprint）」と呼ばれることもある）を記憶する。例えば、図２の実施形態では、複合オブジェクト２００は、仮想ディスクの２つのミラーリングコピー（例えば、ミラー）がそれぞれ、ＲＡＩＤ０構成に更にストライピングされる（striped）ＲＡＩＤ１構成を記述した仮想ディスクブループリント２１５を含む。したがって、複合オブジェクト２２５は、各仮想ディスクミラー内の各ストライプ（例えば、仮想ディスクのデータパーテーション）に対応する幾つかの「リーフ」又は「構成要素」オブジェクト２２０ｘへの参照を含み得る。（例えば、各ストライプの）各構成要素オブジェクト２２０のインメモリメタデータデータベース内の、ＶＳＡＮモジュール１１４によってアクセス可能なメタデータは、ストライプを実際に記憶する物理的ストレージリソース（例えば、磁気ディスク１１８等）を収容するクラスタ１１０内の特定のノード１１１ｘ（及びそのような物理的リソース内のストライプのロケーション）へのマッピングを提供するか、又は他の様式で識別する。
【００２１】
図３は、一実施形態によるＶＳＡＮモジュール１１４の構成要素を示す。上述したように、特定の実施形態では、ＶＳＡＮモジュール１１４は、ＶＳＡＮ１１５の抽象化をハイパーバイザ１１３に公開するデバイスドライバとして実行し得る。ＶＳＡＮモジュール１１４の様々なサブモジュールは、異なる役割を果たし、そのような役割に応じて、ユーザ空間３１５又はカーネル空間３２０内で動作し得る。図３の実施形態に示されるように、ＶＳＡＮモジュール１１４は、ユーザ空間３１５内で動作するクラスタレベルオブジェクト管理（ＣＬＯＭ：ｃｌｕｓｔｅｒ  ｌｅｖｅｌ  ｏｂｊｅｃｔ  ｍａｎａｇｅｍｅｎｔ）サブモジュール３２５を含む。ＣＬＯＭサブモジュール３２５は、管理者によって仮想ディスクの作成中に仮想ディスクブループリントを生成し、そのような仮想ディスクブループリントに作成されたオブジェクトが、管理者によって設定されたストレージプロファイル又はポリシー要件を満たすように構成されることを保証する。（例えば、仮想ディスクの）オブジェクト作成中にアクセスされることに加えて、オブジェクトに関連するストレージプロファイル若しくはポリシーに管理者が変更を行ったとき又はクラスタ若しくは作業負荷への変更が現在のストレージプロファイル若しくはポリシーに準拠しないオブジェクトを生成する場合にも、（例えば、仮想ディスクブループリント又はオブジェクトストア１１６内の実際の物理的ストレージへの仮想ディスクブループリントのマッピングを動的に改訂又は他の様式で更新するために）ＣＬＯＭサブモジュール３２５にアクセスし得る。
【００２２】
一実施形態では、管理者が、仮想ディスクオブジェクト２００等の複合オブジェクトのストレージプロファイル又はポリシーを作成する場合、ＣＬＯＭサブモジュール３２５は、様々なヒューリスティック（heuristics）及び／又は分散アルゴリズムを適用して、ストレージポリシーを満たすか、又は他の様式で適合するクラスタ１１０内の構成（例えば、ミラーリングを通しての所望の冗長性を達成するとともに、ストライピングを通してアクセス性能を達成するＲＡＩＤ構成、どのノードのローカルストレージが、負荷バランシングを達成するために仮想ディスクの特定の部分／パーテーション／ストライプを記憶すべきか等）を記述する仮想ディスクブループリント２１５を生成する。例えば、ＣＬＯＭサブモジュール３２５は、一実施形態では、仮想ディスクが管理者によって最初に作成されたとき、図２の仮想ディスクオブジェクト２００のＲＡＩＤ１／ＲＡＩＤ０構成を記述するブループリント２１５の生成を担う。上述したように、ストレージポリシーは、容量、ＩＯＰＳ、可用性、及び信頼性についての要件を指定し得る。ストレージポリシーは、作業負荷の特徴付け（workload characterization）（例えば、ランダム又はシーケンシャルアクセス、Ｉ／Ｏ要求サイズ、キャッシュサイズ、予期されるキャッシュヒット率等）を指定することもできる。さらに、管理者は、特定のノード１１１（又は特定のノード１１１内部に収容されたローカルディスク）を優先的に使用するＶＳＡＮモジュール１１４への親和性を指定することもできる。例えば、ＶＭに新しい仮想ディスクをプロビジョニングする場合、管理者は、仮想ディスクが確保容量４００ＧＢ、「１５０」の読み出しＩＯＰＳの確保、「３００」の書き込みＩＯＰＳの確保、及び所望可用性９９．９９％を有することを指定するストレージポリシー又はプロファイルを仮想ディスクに生成し得る。生成されたストレージポリシーを受信すると、ＣＬＯＭサブモジュール３２５は、ＶＳＡＮモジュール１１４によって保持されるインメモリメタデータデータベースを照会して、生成されたストレージポリシーに合う複合オブジェクト（例えば、仮想ディスクオブジェクト）の仮想ディスクブループリントを生成するために、クラスタ１１０の現在状態を特定する。更に後述するように、次に、ＣＬＯＭサブモジュール３２５は、ブループリントを対応する分散オブジェクトマネージャ（ＤＯＭ）サブモジュール３４０に通信し、ＤＯＭサブモジュール３４０はオブジェクト空間１１６と対話して、例えば、複合オブジェクトの構成要素オブジェクト（例えば、ストライプ）をクラスタ１１０の様々なノード１１１内の物理的ストレージロケーションに割り振るか、又は他の様式でマッピングすることにより、ブループリントを実施する。
【００２３】
ＣＬＯＭサブモジュール３２５及びＤＯＭサブモジュール３４０に加えて、図３に更に示されるように、ＶＳＡＮモジュール１１４は、クラスタモニタリング、メンバシップ、及びディレクトリサービス（ＣＭＭＤＳ：ｃｌｕｓｔｅｒ  ｍｏｎｉｔｏｒｉｎｇ，  ｍｅｍｂｅｒｓｈｉｐ，  ａｎｄ  ｄｉｒｅｃｔｏｒｙ  ｓｅｒｖｉｃｅｓ）サブモジュール３３５を含むこともでき、このモジュールは、上述したインメモリメタデータデータベースを保持して、クラスタ１１０の状態についての情報をＶＳＡＮモジュール１１４の他のサブモジュールに提供するとともに、クラスタ１１０内の各ノード１１１のステータス、アクセス可能性、及び可視性をモニタすることによりクラスタ１１０の全般的な「正常性（health）」を追跡もする。インメモリメタデータデータベースは、様々なノード１１１、収容されるノード１１１内のストレージリソース（ＳＳＤ、磁気ディスク等）及びその特徴／性能、ノード１１１の現在の状態及び対応するストレージリソース、ノード１１１間のネットワークパス等のＶＳＡＮ環境の物理的インベントリ（physical inventory）を保持するディレクトリサービスとして機能する。上述したように、物理的インベントリの保持に加えて、インメモリメタデータデータベースは、オブジェクトストア１１６に記憶されたオブジェクトのメタデータのカタログ（例えば、どの複合オブジェクト及び構成要素オブジェクトが存在するか、どの構成要素オブジェクトがどの複合オブジェクトに属するか、どのノードが、どのオブジェクトへのアクセスを制御する「コーティネータ」又は「所有者」として機能するか、各オブジェクトのサービス品質要件、オブジェクト構成、物理的ストレージロケーションへのオブジェクトのマッピング等）を更に提供する。上述したように、ＶＳＡＮモジュール１１４内の他のサブモジュールは、ＣＭＭＤＳサブモジュール３３５にアクセスして、クラスタトポロジ及びオブジェクト構成の変更を知るために更新し得る（図３では接続線によって表される）。例えば、上述したように、仮想ディスク作成中、ＣＬＯＭサブモジュール３２５は、インメモリメタデータデータベースにアクセスして、仮想ディスクブループリントを生成し、実行中のＶＭ１１２からのＩ／Ｏ動作を処理するために、ＤＯＭサブモジュール３４０は、インメモリメタデータデータベースにアクセスして、対応する複合オブジェクト（例えば、仮想ディスクオブジェクト）の構成要素オブジェクト（例えば、スクリプト）を記憶したノード１１１と、Ｉ／Ｏ動作を満たすためにそれらのノードに到達可能なパスと特定する。
【００２４】
上述したように、ＤＯＭサブモジュール３４０は、Ｉ／Ｏ動作の処理中及びオブジェクト作成中、ＤＯＭサブモジュール３４０が実行される特定のノード１１１のローカルストレージに記憶されたオブジェクトストア１１６内の構成要素オブジェクト及びノード１１１が現在、「コーディネータ（coordinator）」又は「所有者（owner）」として指定されている特定の他の複合オブジェクトへのアクセスを制御するとともに、それらに対する動作を処理する。例えば、ＶＭからのＩ／Ｏ動作を処理する場合、特定の実施形態での複合オブジェクトの階層性に起因して、ターゲット複合オブジェクト（例えば、Ｉ／Ｏ動作の対象である仮想ディスクオブジェクト）のコーディネータとして機能するＤＯＭサブモジュール３４０は、第２のノード１１１のローカルストレージに記憶され、Ｉ／Ｏ動作の対象である仮想ディスクの部分である仮想ディスクオブジェクトの特定の構成要素オブジェクト（例えば、ストライプ等）のコーディネータとして機能する第２のノード１１１（又は複数の第２のノード１１１）内の異なるＤＯＭサブモジュール３４０と、ネットワークを介して更に通信する必要があり得る。Ｉ／Ｏ動作を発行しているＶＭが、仮想ディスクオブジェクトのコーディネータとも異なるノード１１１に存在する場合、ＶＭを実行しているノードのＤＯＭサブモジュール３４０は、コーディネータのＤＯＭサブモジュール３４０とも、ネットワークを介して通信する必要がある。特定の実施形態では、Ｉ／Ｏ動作を実行しているＶＭが、Ｉ／Ｏ動作の対象である仮想ディスクオブジェクトのコーディネータと異なるノードに存在する場合、２つのノードの２つのＤＯＭサブモジュール３４０は通信して、仮想ディスクオブジェクトのコーディネータの役割を、ＶＭを実行中のノードに変更し得る（例えば、それにより、ＶＭを実行中のノードと、仮想ディスクオブジェクトのコーディネータとして機能しているノードとの間でＩ／Ｏ動作を調整するために必要なネットワーク通信量が低減する）。
【００２５】
ＤＯＭサブモジュール３４０はまた、同様に、オブジェクト作成中、互いに通信する。例えば、仮想ディスク作成中にＣＬＯＭモジュール３２５によって生成された仮想ディスクブループリントは、どのノード１１１が仮想ディスクオブジェクトのコーディネータとして機能すべきかを指定する情報及び対応する複合オブジェクト（スクリプト等）を指定する情報を含み得る。そのような指定されたノードの各ＤＯＭサブモジュール３４０は、各オブジェクトを作成し、（必要な場合）ローカルストレージをそのようなオブジェクトに割り振り、オブジェクトを対応するＣＭＭＤＳサブモジュール３３５に通知して、オブジェクトに関するメタデータを用いてインメモリメタデータデータベースを更新する要求が発行される（例えば、実施形態に応じて、仮想ディスクオブジェクトのコーディネータとして指定されるＤＯＭサブモジュール３４０又は仮想ディスクブループリントを生成するノードのＤＯＭサブモジュール３４０等により）。そのような要求を実行するために、ＤＯＭサブモジュール３４０はログ構造化オブジェクトマネージャ（log structured object manager : ＬＳＯＭ）サブモジュール３５０と対話し、ＬＳＯＭサブモジュール３５０は、ノード１１１のローカルＳＳＤ及び磁気ディスクとの通信を実際に推進するＶＳＡＮモジュール１１４内の構成要素として機能する。ローカルストレージを構成要素オブジェクトに割り振ること（及びノードがコーディネータとして機能する複合オブジェクトのポリシー及び構成等の他のメタデータを記憶すること）に加えて、ＬＳＯＭサブモジュール３５０は、ノード１１１のローカルストレージへのＩ／Ｏ動作フローを更にモニタして、例えば、ストレージリソースが輻輳しているか否かを報告する。
【００２６】
図３は、論理エンドポイント（例えば、ノード、オブジェクト等）間の任意のサイズのデータグラム（datagram）を送る高信頼データグラムトランスポート（reliable datagram transport : ＲＤＴ）サブモジュール３４５も示し、ここで、エンドポイントは潜在的に、複数のパスを介し得る。一実施形態では、基本となるトランスポートはＴＣＰである。代替的には、ＲＤＭＡ等の他のトランスポートが使用され得る。ＲＤＴサブモジュール３４５は、例えば、上述したようにオブジェクトを作成するため又はＩ／Ｏ動作を処理するためにＤＯＭサブモジュール３４０が互いに通信する場合、使用される。特定の実施形態では、ＲＤＴモジュール３４５はＣＭＭＤＳモジュール３３５と対話して、論理的エンドポイントのアドレスを動的に分解して、インメモリメタデータデータベース内の最新のロケーション情報を維持するとともに、リンクの正常性に基づいて接続の作成、除去、又は再確立を行う。例えば、ＣＭＭＤＳモジュール３３５によりリンクが正常ではないと報告する場合、ＲＤＴサブモジュール３４５は、よりよい状態のリンクを優先してその接続を遮断し得る。
【００２７】
図４は、一実施形態による、定義されたストレージポリシーに基づいて仮想ディスクオブジェクトを作成する方法の流れ図を示す。例えば、ステップ４００において、管理者は、仮想管理プラットフォーム１０５のユーザインターフェースと対話して、容量要件、可用性要件、及びＩＯＰＳ要件（例えば、定義されたストレージポリシー）を有する仮想ディスクを作成し得る。一実施形態では、次に、ステップ４０５において、仮想管理プラットフォーム１０５は、「マスタ」ノード１１１に仮想ディスクのオブジェクトを作成するように要求し得る。ステップ４１０において、そのようなマスタノード１１１は、ＶＳＡＮモジュール内のＣＬＯＭサブモジュール３２５を通して仮想ディスクブループリントを生成し得る。上述したように、ＣＬＯＭサブモジュール３２５は、ＣＭＭＤＳサブモジュール３３５のインメモリメタデータデータベースを照会することによって特定されるクラスタ１１０のステータスに基づいて、仮想ディスクオブジェクト（例えば、複合オブジェクト）の作成の仮想ディスクブループリントを生成する。仮想ディスクブループリントは、仮想ディスクオブジェクトのコーディネータ又は所有者として機能すべき特定のノードを識別し得る。ステップ４１５において、マスタノード１１１のＤＯＭサブモジュール３４０は、識別されたノードのＤＯＭサブモジュール３４０に、仮想ディスクオブジェクトを作成するように要求し得る。ステップ４２０において、識別されたノードのＤＯＭサブモジュール３４０は、要求を受信し、例えば、対応するＬＳＯＭサブモジュール３５０と通信して、仮想ディスクオブジェクトを記述するメタデータをローカルストレージに永続的に記憶することにより、仮想ディスクオブジェクトを作成する。ステップ４２５において、ＤＯＭサブモジュール３４０は、仮想ディスクオブジェクトブループリントに基づいて、仮想ディスクブループリント内の任意の構成要素オブジェクトのコーディネータ又は所有者として機能するように指定されているクラスタ１１０内の他のノードを識別する。ＤＯＭサブモジュール３４０は、構成要素オブジェクトのコーディネータとして機能し、（例えば、ＲＤＴサブモジュール３４５を使用して）そのような構成要素オブジェクトをバッキングするデータをローカルストレージに記憶する他のノードのＤＯＭサブモジュール３４０と通信する。そのようなＤＯＭサブモジュール３４０は、仮想ディスクオブジェクトのコーディネータのＤＯＭサブモジュール３４０から、各構成要素オブジェクトを作成する要求を受信する場合、ステップ４３０において、各ＬＳＯＭモジュール３５０と通信して、ローカルストレージを構成要素オブジェクト（及び関連するメタデータ）に割り振る。そのような構成要素オブジェクトが作成されると、ＤＯＭサブモジュール３４０は、ステップ４３５において、ＣＭＭＤＳサブモジュール３３５のインメモリメタデータデータベースに構成要素の作成を通知する。そして、ステップ４４０において、仮想ディスクオブジェクトのコーディネータのＤＯＭサブモジュール３４０も、その作成をＣＭＭＤＳサブモジュール３３５に通知して、インメモリメタデータデータベースを更新し、最終的に、（例えば、仮想管理プラットフォーム１０５へのマスタノード通信を介して）肯定応答を管理者に送信する。
【００２８】
図５は、一実施形態による、ＶＭから発せられたＩ／Ｏ動作の中止を示す。特定のノードで実行中のＶＭが、仮想ディスクに対してＩ／Ｏ動作を実行する場合、ＶＭのゲストオペレーティングシステムは、ステップ５００において、（ゲストオペレーティングシステムのデバイスドライバを通して）仮想ディスクを対象としたＩ／Ｏ動作要求を送信し、この要求は、ステップ５０５において、ハイパーバイザ１１３によって受信され、最終的に、ハイパーバイザ１１３内のＩ／Ｏスタックの様々なレイヤを通してＶＳＡＮモジュール１１４のＤＯＭサブモジュール３４０に送信され変換される。ステップ５１０において、ＤＯＭサブモジュール３４０によって受信されたＩ／Ｏ要求は、ＤＯＭサブモジュール３４０がＣＭＭＤＳサブモジュール３３５のインメモリメタデータデータベースにアクセスすることにより、仮想ディスクオブジェクトのコーディネータノードを識別するために使用する仮想ディスクを表すオブジェクトの一意の識別子を含む（特定の実施形態では、インメモリメタデータデータベースにアクセスして、一意の識別子へのコーディネータノードの識別情報のマッピングを調べることは、仮想ディスクオブジェクトが最初にアクセスされるときのみ行われ、そのようなマッピングは、続く参照が必要ないように、将来のＩ／Ｏ動作で持続する）。仮想ディスクオブジェクトのコーディネータノードを識別すると、ＶＭを実行中のノードのＤＯＭサブモジュール３４０は、コーディネータノードのＤＯＭサブモジュール３４０と通信して（例えば、ＲＤＴサブモジュール３４５を使用して）、ステップ５１５において、Ｉ／Ｏ動作を実行することを要求する。上述したように、特定の実施形態では、ＶＭを実行中のノード及び仮想ディスクオブジェクトのコーディネータとして機能するノードが異なる場合、２つのＤＯＭサブモジュールは通信して、実行中のＶＭのノードであるように、仮想ディスクオブジェクトのコーディネータの役割を更新する。Ｉ／Ｏ要求をコーディネータが受信すると、ステップ５２０において、ＤＯＭサブモジュールは、（例えば、特定の実施形態では、再びインメモリメタデータデータベースを参照することにより）Ｉ／Ｏ動作の対象である仮想ディスクオブジェクトの特定の構成要素オブジェクト（例えば、スクリプト）のコーディネータノードを識別する。例えば、Ｉ／Ｏ動作がＲＡＩＤ０構成の複数のストライプ（例えば、複数の構成要素オブジェクト）に広がる場合、ＤＯＭサブモジュール３４０は、Ｉ／Ｏ動作を分割し、２つのストライプに対応する関連する構成要素オブジェクトの各コーディネートノードに、対応するＩ／Ｏ要求を適宜送信し得る。ステップ５２５において、仮想ディスクオブジェクトのコーディネータノードのＤＯＭサブモジュールは、識別された構成要素オブジェクトのコーディネータノードのＤＯＭサブモジュールが、Ｉ／Ｏ動作要求を実行することを要求し、ステップ５３０において、識別された構成要素オブジェクトのそのようなコーディネータノードのＤＯＭサブモジュールは、対応するＬＳＯＭサブモジュールと対話して、構成要素オブジェクトが記憶されたローカルストレージリソース内でＩ／Ｏ動作を実行する。
【００２９】
特定の状況では、複数のクライアント（例えば、実行中のＶＭの代理として機能する他のＶＳＡＮモジュール１１４）が、任意の所与の時間に特定のノードに配置された特定のローカルストレージリソースでＩ／Ｏ動作を実行する要求を同時に送信し得ることを認識されたい。例えば、異なるＶＭに対応する異なる仮想ディスクオブジェクトの構成要素オブジェクト（例えば、ストライプ等）は、同じノード上の同じローカルストレージによってバッキングし得る。Ｉ／Ｏ動作を受信すると、そのようなノードのＶＳＡＮモジュール１１４は、実行のために、Ｉ／Ｏ動作をストレージリソースキューに配置し得る。例えば、複数のクライアントが構成要素オブジェクトにアクセスすることによって生じるローカルストレージリソースのＩ／Ｏキュー内の輻輳又はオーバーフローの可能性を低減するために、ＶＳＡＮモジュール１１４は（上述したように、ＬＳＯＭサブモジュールを介して）、ローカルストレージリソースの使用をモニタし、ローカルストレージにアクセスを試みているクライアントに輻輳メトリックを出力し得る。輻輳メトリックは、更に詳細に後述するように、クライアントが、追加のＩ／Ｏ要求をローカルストレージリソースに送信する前に遅延を計算するために使用し得る測定を提供する。
【００３０】
図６は、一実施形態による、ＶＳＡＮモジュールによりクライアントに輻輳メトリックを送信する方法の流れ図を示す。例えば、異なる複合オブジェクトの構成要素は、同じノードに存在し、ＳＳＤ及び磁気ディスクＩＯＰＳ等の共有ローカルリソースに関して競合し得る。上述したように、各ノードのＬＳＯＭサブモジュール３５０は、各構成要素に適用されるローカル構成要素オブジェクト及びポリシーの構成を含む。さらに、ＬＳＯＭサブモジュール３５０は、構成要素オブジェクトのリソース使用をモニタして、構成要素オブジェクトがポリシーに従うことを保証する。構成要素オブジェクトにアクセスしているクライアント（例えば、実行中のＶＭの代理として機能している他のＶＳＡＮモジュール）が、そのオブジェクトのＩＯＰＳの割り振りを超えている場合、ＶＳＡＮモジュール１１４は（ＬＳＯＭサブモジュール３５０を通して）、輻輳メトリックをクライアントに送信し、それに応じて、クライアントは続くＩ／Ｏ要求を遅延させる。ステップ６０５において、クラスタ１１０内のノード１１１のＶＳＡＮモジュール１１４は、ノード１１１に存在する構成要素オブジェクトにアクセスしているクライアントから発せられたＩ／Ｏ動作要求を受信する。例えば、ＶＳＡＮモジュール１１４は（ＤＯＭサブモジュール３４０を通して）、実行中のＶＭに対応する仮想ディスクオブジェクトの構成要素オブジェクト（例えば、ストライプ等）のコーディネータとして機能し得る。ステップ６１０において、Ｉ／Ｏ動作要求を受信すると、ＶＳＡＮモジュール１１４は（ＬＳＯＭサブモジュール３５０を通して）、例えば、対応する仮想ディスクオブジェクトを構成する他の異なる構成要素オブジェクトにアクセスするために、同じローカルストレージにアクセス中であり得る他のクライアントに起因して、構成要素オブジェクトをバッキングしているローカルストレージリソースのＩＯＰＳ容量を超えている（例えば、競合及び潜在的な輻輳を生じさせる）か否かを判断する。競合がない場合、ステップ６１５において、ＶＳＡＮモジュール１１４は、ＬＳＯＭサブモジュール３５０と通信して、ローカルストレージリソースにアクセスすることにより、Ｉ／Ｏ動作要求を処理することに進む。
【００３１】
しかし、ローカルストレージリソースのＩＯＰＳ容量を超えている場合、ステップ６２０において、ローカルＬＳＯＭサブモジュール３５０は、ローカルストレージリソースとのＩ／Ｏを現在行っており、ストレージポリシーにおいて指定されるＩＯＰＳ確保を超えている任意のクライアントの輻輳メトリックを計算する。一実施形態では、ＬＳＯＭサブモジュール３５０は、（例えば、前の値を減衰させ、最近の輻輳測定を追加することにより）時間加重和（time-weighted sum）を使用して輻輳メトリックを計算する。さらに、特定の実施形態では、ＬＳＯＭサブモジュール３５０は、ローカルストレージリソースの他のクライアントによる使用に相対するローカルストレージリソースのクライアントの使用に基づいて、各クライアントの異なる輻輳メトリックを計算し得る。一実施形態では、クライアントが、クラスタ１１０の異なるノードに配置された複数のローカルストレージリソースにアクセスしている（例えば、クライアントから発せられたＩ／Ｏ動作が、異なる構成要素オブジェクトに向けられた複数のＩ／Ｏ動作に分割される）場合、ＶＳＡＮモジュール１１４は、（ＬＳＯＭサブモジュール３５０を通して）その他のノードのＶＳＡＮモジュール１１４と通信して、その他のノードに存在するその他のＶＳＡＮモジュールから生成される生じ得る輻輳のメトリックとその輻輳メトリックとを組み合わせて、クライアントの全体輻輳メトリックを生成し得る。
【００３２】
ステップ６２５において、ＶＳＡＮモジュール１１４は、輻輳メトリックをクライアントに送信する。受信すると、クライアントは、ＤＯＭサブモジュール３４０を通して、輻輳メトリックを使用し、クライアントが使用中のリソース量と、輻輳メトリックによって記述される輻輳量とに基づいて、続くＩ／Ｏ動作要求をどれくらい遅延させるかを決定する。すなわち、リソースを使い過ぎているクライアントへの固定期間の遅延を強制する（そのような手法は、使用の不要な変動を生じさせるおそれがある）のではなく、特定の実施形態では、輻輳メトリックは、メトリックに比例する分散（distribution）からランダム遅延期間を計算するための情報をクライアントに提供する。読み出し動作及び書き込み動作に必要とされるサービスコストは異なるため、輻輳メトリックによって必要とされる待機期間は、Ｉ／Ｏ動作のタイプ及びサイズに依存し得る。例えば、輻輳メトリックは、読み出し動作よりも書き込み動作の場合により長い遅延期間を必要とし得、その理由は、一般に、書き込み動作が読み出し動作よりも計算的に高負荷（expensive）であるためである。
【００３３】
代替の一実施形態では、ＶＳＡＮモジュールは、ローカルストレージリソースにアクセスしているあらゆるクライアントに、そのようなクライアントが確保された割り振りを超えているか否かに関係なく、異なる輻輳メトリックを出力し得る。確保された割り振りを超えているクライアントに送信される輻輳メトリックは、そのようなクライアントによる続くＩ／Ｏ動作要求の送信を遅延させることになり得るが、確保された割り振り内でローカルストレージリソースにアクセスしているクライアントは、遅延なしでＩ／Ｏ動作要求を送信することを許可する輻輳メトリック（例えば、ゼロメトリック）を受信し得る。輻輳が収まった後、ＶＳＡＮモジュール１１４は、各クライアント要求後の輻輳メトリックの送信を止め得る。
【００３４】
代替の実施形態では、ホストＬＳＯＭサブモジュール３５０は、輻輳のローカル測定を計算し、特定のクライアントのリソース使用に向けて輻輳メトリックを調整せずに、輻輳メトリックを各クライアントに送信する。送信されると、クライアントは、オーバーサブスクライブ（oversubscribing）の場合、要求を遅延させる。オーバーサブスクライブの場合、輻輳に応答するかどうかは消費クライアント次第であり得る。
【００３５】
図７は、一実施形態による、輻輳中にＶＳＡＮモジュールへのＩ／Ｏ要求を遅延させる方法を示す。ステップ７０５において、クラスタ１１０のノードで実行中のクライアント（例えば、ＶＭをサポートしているノード１１１のＶＳＡＮモジュール１１４）は、図６に説明されるように、Ｉ／Ｏ動作要求を仮想ディスクに送信した結果として、輻輳メトリックを受信し得る。例えば、クライアントＶＳＡＮモジュール１１４のＬＳＯＭサブモジュール３５０は、オブジェクトを記憶しているノードのＶＳＡＮモジュール１１４のＬＳＯＭサブモジュール３５０と通信し、そのような輻輳メトリックを受信し得る。クライアントＶＳＡＮモジュール１１４のＤＯＭサブモジュール３４０は、輻輳メトリックに基づいて時間遅延を計算し得る。輻輳メトリックを受信すると、クライアントＶＳＡＮモジュール１１４が、追加のＩ／Ｏ動作要求を送信する必要がある場合、ステップ７１０において、例えば、ある範囲にわたるランダム分布に基づいて、（ＤＯＭサブモジュール３４０を通して）要求を送信する前に遅延する時間を計算し、最大値は輻輳メトリックの関数である。ステップ７１５において、クライアントＶＳＡＮモジュール１１４は、Ｉ／Ｏ動作要求を送信する前に、計算された遅延だけ待機する。輻輳メトリックから計算された待機期間は、クライアントが確保された割り振りを超えているＩＯＰＳ量に基づき得る。すなわち、確保された割り振りを、小量だけ超えているクライアントよりもはるかに超えているクライアントほど、長期間にわたり要求を遅延させるように求められ得る。
【００３６】
１つ又は複数の実施形態について、理解を明確にするために幾らか詳細に説明したが、特許請求の範囲内で特定の変更及び変形が行われ得ることが明らかであろう。したがって、記載される実施形態は、限定ではなく例示として見なされるべきであり、特許請求の範囲は、本明細書に付与される詳細に限定されるべきではなく、特許請求の範囲及び均等物内で変更が可能である。例えば、幾つかの上述した実施形態は、ＶＳＡＮモジュールによって提供される仮想ディスクにアクセスするクライアントとして仮想マシンを記載するが、代替の実施形態では、非仮想化ホストサーバ及び／又はそこで実行中の非仮想化アプリケーションのクラスタ等の任意のクライアントが同様にＶＳＡＮモジュールを利用し得ることを認識されたい。同様に、ＶＳＡＮモジュールの代替の実施形態は、限定ではなく、ＲＥＳＴオブジェクト、ファイル、ファイルシステム、ブロブ（バイナリラージオブジェクト）、及び他のオブジェクト等の仮想ディスク以外の高レベルストレージオブジェクトの作成が可能であり得る。同様に、上記実施形態で記載された輻輳回避技法は主に、ローカルストレージリソースへの対処に関連したが、代替の実施形態は、例えば、単一のノードが、２つの異なるＶＭによって現在アクセスされている２つの異なる仮想ディスクのコーディネータとして動作する場合に生じ得るメモリ、処理、及び／又はネットワーキングリソースに対する競合を低減するためにも、同様の技法を利用し得る。そのような実施形態では、ＤＯＭサブモジュール３４０は、ＣＰＵ、メモリ、及びネットワーキングでのリソース使用もモニタして、ローカルストレージリソースのＩＯＰＳ及び容量等のリソース使用をモニタする際のＬＳＯＭサブモジュール３５０と同様に、それらのリソースに対する競合に対処し得る（又は代替的には、ＬＳＯＭサブモジュール３５０は、ＣＰＵ、メモリ、及び／又はネットワーキング使用をモニタするように構成することもできる）。同様に、ＶＳＡＮモジュール１１４は、ハイパーバイザ１１３に埋め込まれるものとして一般に説明されたが、代替の実施形態は、例えば、特別な仮想マシン又は仮想アプライアンス、別個のアプリケーション、又は分散オブジェクト記憶を提供し管理するために計算プラットフォームに挿入することができる任意の他の「プラグ可能」モジュール若しくはドライバとして、ハイパーバイザ１１３とは別個のＶＳＡＮモジュールを実施し得る。
【００３７】
説明したように、本明細書に記載された実施形態は、分散リソースへの輻輳を測定し、サービス品質を制御する。有利なことには、リソースが競合し、リソースを使用しすぎている全てのクライアントによる要求の遅延を求めながら、輻輳メトリックをクライアントに発行することにより、これらの実施形態は、分散リソースにアクセスするに際して予測可能性を提供し、プロビジョニングされたようにリソースを使用するクライアントへの待ち時間を短くする。さらに、リソースキューではなくリソースアプリケーションへの入口において要求を遅延させることに求められるのは、従来の解決策で要求されるよりも複雑性の低いキューイング論理である。
【００３８】
本明細書に記載される様々な実施形態は、コンピュータシステムに記憶されたデータを含む様々なコンピュータ実施動作を利用し得る。例えば、これらの動作は、物理的数量の物理的操作を必要とし得、必ずしもではないが通常、これらの数量は電気信号又は磁気信号の形態を取り得、電気信号又は磁気信号又はそれらの表現は、記憶、転送、結合、比較、又は他の様式での操作が可能である。さらに、そのような操作は、多くの場合、用語に関して、製造、識別、特定、又は比較等と呼ばれる。１つ又は複数の実施形態の一部をなす本明細書に記載される任意の動作は、有用なマシン動作であり得る。さらに、本開示の１つ又は複数の実施形態は、これらの動作を実行するデバイス又は装置にも関する。装置は特に、特定の所要目的に向けて構築されてもよく、又はコンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ化若しくは構成される汎用コンピュータであってもよい。特に、様々な汎用マシンが、本明細書での教示に従って書かれたコンピュータプログラムと併用され得、又は必要とされる動作を実行するより専用化された装置を構築することがより好都合であり得る。
【００３９】
本明細書に記載される様々な実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベース又はプログラマブル消費者電子装置、ミニコンピュータ、メインフレームコンピュータ等を含め、他のコンピュータシステム構成を用いて実施し得る。
【００４０】
１つ又は複数の実施形態は、１つ若しくは複数のコンピュータプログラムとして、又は１つ若しくは複数のコンピュータ可読媒体で実施される１つ若しくは複数のコンピュータプログラムモジュールとして実施され得る。コンピュータ可読媒体という用語は、データを記憶することができる任意のデータ記憶デバイスを指し、データは後にコンピュータシステムに入力することができ、コンピュータ可読媒体は、コンピュータにより読み出し可能にするようにコンピュータプログラムを実施する任意の既存又は後に開発される技術に基づき得る。コンピュータ可読媒体の例としては、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ（例えば、フラッシュメモリデバイス）、ＣＤ（コンパクトディスク）、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、又はＣＤ−ＲＷ、ＤＶＤ（デジタル多用途ディスク）、磁気テープ、並びに他の光学及び非光学データ記憶デバイスが挙げられる。コンピュータ可読媒体は、ネットワーク結合されたコンピュータシステムに分散することもでき、それにより、コンピュータ可読コードは分散して記憶され実行される。
【００４１】
加えて、記載の仮想化方法は一般に、仮想マシンが特定のハードウェアシステムに一致するインターフェースを提示すると仮定したが、記載の方法は、任意の特定のハードウェアシステムに直接対応しない仮想化と併せて使用することが可能である。ホスト実施形態、非ホスト実施形態、又は２つの区別が曖昧でありがちな実施形態として実施される、様々な実施形態による仮想化システムが全て考えられる。さらに、様々な仮想化動作は、全体的又は部分的にハードウェアで実施し得る。例えば、ハードウェア実施は、非ディスクデータを保護するために、ストレージアクセス要求を変更するためにルックアップテーブルを利用し得る。
【００４２】
仮想化の程度の関係なく、多くの変形、変更、追加、及び改善が可能である。したがって、仮想化ソフトウェアは、仮想化機能を実行するホスト、コンソール、又はゲストオペレーティングシステムの構成要素を含む。複数のインスタンスが、１つのインスタンスとして本明細書に記載される構成要素、動作、又は構造に提供され得る。最後に、様々な構成要素、動作、及びデータストア間の境界は幾らか任意のものであり、特定の動作は、特定の例示的な構成の文脈で示されている。機能の他の割り振りが考えられ、１つ又は複数の実施形態の範囲内にあり得る。一般に、例示的な構成において別個の構成要素として提示される構造及び機能は、結合された構造又は構成要素として実施され得る。同様に、１つの構成要素として提示される構造及び機能は、別個の構成要素として実施され得る。これら及び他の変形、変更、追加、及び改善は、添付の特許請求の範囲内にあり得る。特許請求の範囲では、要素及び／又はステップは、特許請求の範囲において明示的に記載される場合を除き、いかなる特定の順序の動作も暗示しない。
【図１】
2016525761.tif 000003
【図２】
2016525761.tif 000004
【図３】
2016525761.tif 000005
【図４】
2016525761.tif 000006
【図５】
2016525761.tif 000007
【図６】
2016525761.tif 000008
【図７】
2016525761.tif 000009
【国際調査報告】
2016525761.tif 000010
2016525761.tif 000011