(57)【要約】例えば、少なくとも１つの計算エンティティと少なくとも１つのストアとの間におけるデーター入力／出力要求の端末から端末までのフローに対してポリシーを適用するための、データー・ストレージ入力／出力要求制御について記載する。種々の例において、両端間フローの１つ以上のステージに複数のキューが構成され、ポリシーを固守するように制御される。例では、各ステージが制御インターフェースを有し、コントローラーからの制御命令を受けて実行することを可能にする。コントローラーは、集中型でも分散型でもよい。例えば、制御命令は、キュー指定規則および／またはキューの構成を含む。種々の例では、キューおよびキュー指定規則は、フローの実行、ポリシーの変化、インフラストラクチャの変化、またはその他の要因の内任意のものについてのフィードバックにしたがって、動的に作成または見直しされる。例では、ステージ毎に、フロー・エンドポイントの上位識別子が解決され、そのステージによる使用に適した低位識別子を得る。【選択図】図１
2016536714.tif 000002
【特許請求の範囲】
【請求項１】
データー・ストレージ・システムにおけるコンピューターに実装された方法であって、
プロセッサーにおいて、フローのエンドポイント間においてデーター・ストレージ入力／出力要求のフローに適用される１つ以上の判断基準を含むポリシーにアクセスするステップであって、前記エンドポイントが、少なくとも１つの計算エンティティおよび少なくとも１つのストアを含む、ステップと、
制御命令を前記データーのフローの少なくとも１つのステージに送るステップであって、前記ステージが、前記フローが通過する前記データー・ストレージ・システムのコンポーネントであり、前記ステージが、前記制御命令を解釈するように構成され、前記制御命令が、前記ポリシーが満たされるように前記データー・ストレージ入力／出力要求のフローを処理するために、前記少なくとも１つのステージにおいて複数のキューを制御するように構成される、ステップと、
を含む、方法。
【請求項２】
請求項１記載の方法において、前記フローが３つ以上のエンドポイント間にある、方法。
【請求項３】
請求項１記載の方法において、前記データー・ストレージ入力／出力要求のフローが、少なくとも部分的に１つ以上の他のフローと共有されるリソースを使用する、方法。
【請求項４】
請求項１記載の方法において、前記ポリシーにアクセスするステップが、前記少なくとも１つの計算エンティティおよび前記少なくとも１つのストアの上位識別子にアクセスするステップを含み、上位識別子が、前記少なくとも１つのステージによって理解されない識別子であり、前記方法が、前記上位識別子を解決し、前記少なくとも１つのステージによって理解される下位識別子を得るステップを含む、方法。
【請求項５】
請求項１記載の方法において、前記データー・ストレージ・システムにおける集中コントローラーにおいて前記方法を実行し、前記データー・ストレージ・システムが、複数の計算エンティティおよび複数のストアの間において、複数のデーター・ストレージ入力／出力要求のフローを有し、各フローが少なくとも１つのステージを有する、方法。
【請求項６】
請求項１記載の方法において、前記制御命令が、どのタイプのデーター・ストレージ入力／出力要求が、ステージにおいて指定されたキューに入れられるか指定するキュー指定規則を作成するように構成される、方法。
【請求項７】
請求項１記載の方法において、前記制御命令が、キューのサービス特性、キューのルーティング特性の内任意の１つ以上を設定する(configure)ように構成される、方法。
【請求項８】
請求項１記載の方法であって、前記データー・ストレージ入力／出力要求のフローについてのフィードバックを得て、前記フィードバックに基づいて前記制御命令を変更するステップを含む、方法。
【請求項９】
データー・ストレージ・システムのコンポーネントにおけるコンピューターに実装された方法であって、
プロセッサーにおいて、少なくとも１つの計算エンティティと少なくとも１つのストアとの間におけるデーター・ストレージ入力／出力要求のフローを受けるステップと、
制御命令を受けるステップと、
前記制御命令にしたがって１つ以上のキューを構成するステップと、
前記制御命令の一部であるキュー指定規則にしたがって、前記データー・ストレージ入力／出力要求を前記キューに割り当て、前記キューをサービスするステップと、
を含む、方法。
【請求項１０】
データー・ストレージ・システム・コンポーネントであって、
少なくとも１つの計算エンティティと少なくとも１つのストアとの間において、前記プロセッサーにおける複数のキューを介して、データー・ストレージ入力／出力要求のフローを伝送するように構成されたプロセッサーと、
前記データー・ストレージ・システムのコントローラーから制御命令を受けるように構成されたインターフェースと、
を含み、前記プロセッサーが、前記制御命令にしたがって前記キューを構成し、前記制御命令の一部であるキュー指定規則にしたがって、前記データー・ストレージ入力／出力要求を前記キューに割り当てるように構成される、データー・ストレージ・システム・コンポーネント。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  大型データー・センターおよび他のタイプのデーター・ストレージ・システムのようなデーター・ストレージ・システムは、増々複雑になりつつある。ストレージまでの入力／出力パス(path)は、長くて多くのレイヤを含むことが多く、これらの間のインターフェースは不透明である。このため、例えば、フローに利用可能な特定の帯域幅を保証するために、ストレージ入力／出力フローの実行(performance)を指令する両端間ポリシー(end-to-end policy)を施行するのが難しくなる。ストレージ入力／出力フローは、ストレージと計算エンドポイントとの間におけるストレージ入力／出力要求のストリームを含む。例えば、データーをファイルから読み出す、データーをファイルに書き込む、またはデーターを格納するためにファイルを作成する。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
[0002]  企業のデーター・センターにおける物理サーバーの仮想化およびストレージの仮想化により、ストレージ入力／出力フローに沿って複雑さが増大するに至った。
[0003]  以下で説明する実施形態は、既知のデーター・ストレージ・システムの欠点のいずれかを解決する実施態様にも、その全てを解決する実施態様にも限定されることはない。
【課題を解決するための手段】
【０００３】
[0004]  以下に紹介するのは、基本的な理解を読み手に与えるための本開示を簡略化した摘要である。この摘要は、本開示の広範な全体像ではなく、主要な／重要な要素を識別するのでもなく、本明細書の範囲を正確に叙述するのでもない。その唯一の目的は、本明細書において開示される概念から選択したものを、後に紹介する更に詳細な説明の前置きとして、簡略化した形態で紹介することである。
【０００４】
[0005]  例えば、少なくとも１つの計算エンティティと少なくとも１つのストアとの間におけるデーター入力／出力要求の両端間フローに対してポリシーを提供するためのデーター・ストレージ入力／出力要求の制御について説明する。種々の例において、両端間フローの１つ以上のステージにおいて複数のキューが構成され、ポリシーを固守するように制御される。例では、各ステージが制御インターフェースを有し、コントローラーからの制御命令を受けて実行することを可能にする。コントローラーは、集中型でも分散型でもよい。例えば、制御命令は、キュー指定規則(queuing rule)および／またはキューの構成を含む。種々の例では、キューおよびキュー指定規則は、フローの実行、ポリシーの変化、インフラストラクチャの変化、またはその他の要因の内任意のものについてのフィードバックにしたがって、動的に作成または見直しされる。例では、ステージ毎に、フロー・エンドポイントの上位識別子が解決され、そのステージによる使用に適した低位識別子を得る。
【０００５】
[0006]  付随する特徴の多くは、添付図面と関連付けて以下の詳細な説明を参照し考慮することにより、一層深く理解されるに連れて、一層容易に認められるであろう。
【図面の簡単な説明】
【０００６】
[0007]  この説明は、以下の詳細な説明を、添付図面を考慮して読むことにより、一層深く理解できよう。
【図１】図１は、データー・センターを含むデーター・ストレージ・システムの模式図である。
【図２】図２は、計算サーバーおよびストレージ・サーバーの模式図である。
【図３】図３は、コントローラーにおける方法およびステージにおける方法の流れ図である。
【図４】図４は、コントローラーにおける発見方法の流れ図である。
【図５】図５は、トポロジー・グラフの模式図である。
【図６】図６は、コントローラーにおける方法の流れ図である。
【図７】図７は、ステージにおける方法の流れ図である。
【図８】図８は、トポロジー・サブグラフの模式図である。
【図９】図９は、データー・ストレージ・システムのあるステージの実施形態を実現することができる、計算ベース・デバイスの一例を示す。
【０００７】
添付図面において同様の部分を指すために、同様の参照番号を使用することとする。
【発明を実施するための形態】
【０００８】
[0008]  添付図面に関連付けて以下に示す詳細な説明は、本例の説明であることを意図しているのであり、本例を構成するまたは利用することができる形態だけを表すことを意図するのではない。この説明は、本例の機能、および本例を構成しそして動作させるためのシーケンスを明記する。しかしながら、同一のまたは同等の機能およびシーケンスが異なる例によって遂行されてもよい。
【０００９】
[0009]  本明細書では、本例について、集中コントローラーを有するデーター・センターにおいて実現されるとして説明し図示するが、説明するシステムは一例として示すのであって、限定ではない。当業者には認められようが、本例は、パーソナル・コンピューターを含む種々の異なるタイプのデーター・ストレージ・システム、および散在する(decentralized)コントローラーが使用される場合の適用に適している。
【００１０】
[0010]  前述のように、ストレージまでの入力／出力パスは、多くの場合、長く複雑であり、このために、例えば、特定のサービス品質を保証するため、または要求がサニタイゼーション・ミドルボックスを介して送出されることを確実にするために、両端間ポリシーを施行するのが困難になる。多くの場合、多くの異なる顧客が、データー・センターまたは他のデーター・ストレージ・システムにおいて実行するプロセスを有し、リソースが共有される。例えば、データー・ストレージ・システムには、エンティティ間におけるストレージ・リソースおよび相互接続リソースがある。ストレージ入力／出力要求の実行および処理のために顧客の（または他の）ポリシーを固守することが非常に難しくなり、これがクラウド計算サービスの採用および進歩に対する障壁となるおそれがある。
【００１１】
[0011]  本明細書において説明する方法および装置は、データー・ストレージ入力／出力要求のフローに両端間ポリシーを適用することを可能する。フローとは、指定されたエンドポイント間におけるこのような要求のストリームである。エンドポイントの内少なくとも１つは、計算サーバーのような計算エンティティであり、エンドポイントの内少なくとも１つは、ストレージ・サーバー上におけるファイル・シェア、または計算サーバーにおけるローカル・ストレージ上におけるファイル・シェアのようなストアである。また、ある例では、計算サーバーがストアを含むこともできる。また、ある例では、ストレージ・サーバーが計算エンティティを含むこともできる。このように、コンピューター間のフローおよび／またはサーバー間のフローにポリシーを適用することができる。多対１構成、１対多構成、および多対多構成というように、マルチポイント・フローにポリシーを適用することができる。フローのエンドポイントは、上位識別子を使用して指定されることがあるが、フローの１つ以上のレイヤではこの上位識別子が理解されない場合がある。レイヤについては、以下で更に詳しく説明する。
【００１２】
[0012]  ポリシーは、フローの実行(performance)および／またはフローに適用される機能を指定する１つ以上の判断基準を含み、フローはそのエンドポイントに関して指定される。例えば、実行を指定する判断基準は、フローに適用される最小帯域幅を含むことができる。機能を指定する判断基準は、フローに適用されるウィルス・チェック機能を含むことができる。
【００１３】
[0013]  レイヤとは、フローが通過するデーター・ストレージ・システムのコンポーネントである。非網羅的なレイヤ例を以下に列挙すると、計算サーバーのハイパーバイザーにおけるネットワーク・ドライバー、ストレージ・サーバーにおけるネットワーク・ドライバー、データー・ストレージ・システムの相互接続におけるスイッチが挙げられる。コントローラーと通信することを可能にする制御インターフェースを有するレイヤのことを、本文書では「ステージ」(stage)と呼ぶ。本明細書において説明する例では、少なくとも１つのステージが、ポリシーを固守するようにフローを制御するために使用される。本明細書において説明する方法を処理するデーター・ストレージ・システムは、１つ以上のステージを有することができる。データー・センターにおいてステージであるレイヤの割合が増えるに連れて、ポリシー施行能力の柔軟性およびパワーも増える。これによって、各レイヤをアップグレードしてステージにする必要なく、既存のデーター・ストレージ・システムにおいて本技術が作用することを可能にする。
【００１４】
[0014]  各ステージは、複数のキューを含み、コントローラーから受ける制御命令の結果として、キューを受けてインストールすることができる。コントローラーは、集中型でも分散型でもよい。制御命令をステージに送ることによって、ポリシー施行を可能にするために、キューを動的に構成することができる。フィードバックは、フローの振る舞い(behavior)、ポリシー更新、インフラストラクチャの変化、およびその他の要因を含み、キューを動的に構成するために使用することができる。
【００１５】
[0015]  図１は、ストレージ・システム例１００を示す模式図である。ストレージ・システム１００は、データーを格納する複数のストレージ・サーバー１０４と、計算を実行する複数の計算サーバー１０２とを含む。計算では、ストレージ・サーバー１０４および／または計算サーバーの１つ以上におけるローカル・ストレージ１０３から読み出し、そしてこれらに書き込む。この例では、ストレージ入力／出力要求のフローは、計算サーバー１０２における２つの仮想機械１１６から、相互接続１１０におけるスイッチ１０８を経由する、１つのストレージ・サーバー１０４までの破線１２０によって表されている。これは一例に過ぎず、ストレージ入力／出力要求は、仮想機械とローカル・ストレージとの間、または他のエンティティ間で流れるのでもよい。
【００１６】
[0016]  相互接続１１０は、イーサネット（登録商標）のような任意の適したタイプの通信リンク、InfiniBand（商標）通信リンクのようなスイッチ・ファブリック・コンピューター・ネットワーク通信リンク、または計算サーバー１０２、ローカル・ストレージ１０３、およびストレージ・サーバー１０４を相互接続する他のリンクを含む。１つ以上のスイッチ１０８が相互接続１１０内にあってもよいが、これは必須ではない。以下で更に詳しく説明するように、通信リンクを介してストレージ入力／出力要求を送るためには、種々の通信プロトコルを使用することができる。
【００１７】
[0017]  この図は４つの計算サーバーおよび２つのストレージ・サーバーを示すが、本明細書において説明する方法は、図１に示すよりも小さいシステム（例えば、１つのＰＣ）、または遙かに大きいコンピューター・サーバーおよび／またはストレージ・サーバーを有するシステムにも等しく適用可能である。前述のように、計算サーバー機能およびストレージ・サーバー機能を分離するのではなく、これら双方を提供するエンティティを使用することが可能である。
【００１８】
[0018]  また、図１はコントローラー１０６も示す。コントローラー１０６は、相互接続１１０に接続され、したがってデーター・ストレージ・システムの１つ以上のステージと通信することができる。前述のように、ステージとは、コントローラーと通信することを可能にする制御インターフェースを有する、フローのレイヤである。この例では、コントローラーは集中型である。しかしながら、複数のステージにおいてというように、データー・ストレージ・システム１００における複数のエンティティにわたってコントローラーの機能を分散させることも可能である。
【００１９】
[0019]  １つ以上の制御アプリケーション１１２がコントローラー１０６に接続され、操作者、顧客、ポリシーのライブラリー、自動化されたエンティティ、または他のソースからポリシー１１４を受ける。制御アプリケーションは、制御命令を１つ以上のステージに送ることによって、コントローラー１０６と一緒に、ポリシー１１４を施行するために動作する。図１の例では、仮想機械１１６の内２つが各々ステージ１１８を有する。
【００２０】
[0020]  あるいは、または加えて、本明細書において説明するステージおよび／またはコントローラーの機能は、少なくとも部分的に、１つ以上のハードウェア・ロジック・コンポーネントによって実行することができる。例えば、限定ではなく、使用することができる実証的なタイプのハードウェア・ロジック・コンポーネントには、フィールド−プログラマブル・ゲート・アレイ（ＦＰＧＡ）、プログラム特定集積回路（ＡＳＩＣ）、プログラム特定標準的製品（ＡＳＳＰ）、システム−オンーアーチップ・システム（ＳＯＣ）、複合プログラマブル・ロジック・デバイス（ＣＰＬＤ）が含まれる。
【００２１】
[0021]  図２は、図１の構成または他の構成において使用することができる計算サーバー１０２の一例およびストレージ・サーバー１０４の一例の模式図である。この例では、計算サーバーは仮想化を利用する。しかしながら、これは必須ではない。仮想機械および／またはハイパーバイザーを有さない計算サーバーを使用することもできる。
【００２２】
[0022]  計算サーバー１０２は、ハイパーバイザー２１４（仮想機械モニターとしても知られる）を含む。ハイパーバイザー２１４は、計算サーバー１０２において１つ以上の仮想機械を作成し実行することができる。これによって、異なるプロセスのために異なる仮想機械を使用することによって、複数の異なるプロセスまたはアプリケーションを計算サーバー１０２において並列に実行することが可能になる。ハイパーバイザー２１４は、ソフトウェアおよび／またはハードウェアを使用してコンピューターに実装される。図２の例では、ＶＭ１、ＶＭ２、ＶＭ３、およびＶＭ４で示す４つの仮想機械が計算サーバー１０２に存在することが、模式的に示されている。しかしながら、他の数の仮想機械を使用することもできる（０、１、２、またはそれ以上）。
【００２３】
[0023]  図２の例では、仮想機械４が、図２において「ゲストＯＳ」と名付けられ中括弧で囲まれた(bracketed)領域によって示されるゲスト・オペレーティング・システムを使用して、アプリケーション２００を実行する。ゲスト・オペレーティング・システムは、通信プロトコル・スタックおよびストレージ・スタックを含む。通信プロトコル・スタックは、この例では、トランスポート・コントロール・プロトコル（ＴＣＰ）２０２、インターネット・プロトコル（ＩＰ）２０６、および仮想ネットワーク・インターフェース・カード（ＶＮＩＣ）２１０を含む。ストレージ・スタックは、ファイル・システム２０４、ブロック・デバイス２０８、および仮想ハード・ディスク２１２を含む。仮想ハード・ディスク２１２は、入力−出力プロトコル・コンポーネント２１８を介してネットワーク・ドライバー２２０に接続され、ネットワーク・ドライバー２２０は計算サーバー１０２において物理ネットワーク・インターフェース・カード２２２を制御する。また、仮想ネットワーク・インターフェース・カード２１０もネットワーク・ドライバー２２０に接続されている。この接続は、仮想スイッチ２１６を経由する。
【００２４】
[0024]  入力−出力（ＩＯ）プロトコル・コンポーネント２１８は、複数のキューを含み、サーバー・メッセージ・ブロック（ＳＭＢ）または任意の他の適した分散型ストレージ・プロトコルを使用して実装することができる。図２の例では、ＩＯプロトコル・コンポーネントは、更に詳細に、２つのキュー２２６、２２８を有することが示されており、これらのキュー２２６、２２８は、着信するＩＯパケット２２４（ストレージ入力／出力要求である）に割り当てられる。この例では、各キューが指定されたフローに関連付けられているので、キュー２２６はフロー１のパケットのためにあり、キュー２２８はフローｎのパケットのためにある。しかしながら、キューが特定のフローと関連付けられるのは必須ではない。例えば、キューが、ステージにおける他のいずれのキューにも割り当てられないままでいるパケットをいずれも引き受けるデフォルト・キューであってもよい。
【００２５】
[0025]  ＩＯプロトコル・コンポーネント２１８は、コントローラー１０６とインターフェースするための制御インターフェース２３０を含むので、１つのステージである。コントローラー１０６は、図１のコントローラーの一例である。また、コントローラー１０６は、キュー２２６、２２８やキュー指定規則を作成、削除、編集、および構成するため、そしてキューの振る舞いについてのフィードバックを得るために、ＩＯプロトコル・コンポーネント２１８およびネットワーク・ドライバー２２０と通信することもできる。キュー指定規則は、ＩＯプロトコル・コンポーネント２１８および／またはネットワーク・ドライバー２２０において格納することができ、この例では、これらは双方共ステージである。
【００２６】
[0026]  また、ストレージ・サーバー１０４は２つのステージも含み、これらはＩＯプロトコル・コンポーネント２３２およびネットワーク・ドライバー２３８である。ＩＯプロトコル・コンポーネントは、サーバー・メッセージ・ブロック（ＳＭＢ）または任意の他の適した分散型ストレージ・プロトコルを使用して実装することができる。この例では、ストレージ・サーバー１０４におけるＩＯコンポーネント２３２は、キューを作成していない（しかしながら、ある例では、キューを有する場合もある）。
【００２７】
[0027]  ストレージ・サーバー１０４は、ストレージ・ディスク２４２または他の記憶デバイスを制御するディスク・ドライバー２３６と通信可能なファイル・システム２３４を含む。また、ストレージ・サーバー１０４は、ネットワーク・ドライバー２３８に接続された物理ネットワーク・インターフェース・カード２４０も含む。
【００２８】
[0028]  破線２４４は、仮想機械４におけるアプリケーション２００とストレージ・サーバー１０４におけるストレージ・ディスク２４２との間におけるストレージ入力出力要求のフローを表す。この例における要求のフローは、アプリケーション２００のファイル・システム２０４から、ゲスト・オペレーティング・システムのブロック・デバイス２０８に、そしてハイパーバイザーの仮想ハード・ディスク２１２およびＩＯプロトコル・コンポーネント２１８に伝わる。続いて、計算サーバー１０２のネットワーク・ドライバー２２０、物理ネットワーク・インターフェース・カード２２２に、そして１つ以上の通信リンクを介してスイッチ１０８等に伝わり、ストレージ・サーバー１０４の物理ネットワーク・インターフェース・カード２４０に達する。これは、ネットワーク・ドライバー２３８を経由して、ストレージ・サーバー１０４のＩＯプロトコル・コンポーネント２３２に、ならびにストレージ・サーバーのファイル・システム２３４およびディスク・ドライバー２３６に進み、ディスク２４２において終了する。この例における要求のフローは双方向である。コントローラー１０６は、本明細書において説明する方法を使用して、ＩＯ要求のフローにポリシーを施行することができる。
【００２９】
[0029]  図３は、コントローラーにおける方法例、およびステージにおける方法例の流れ図である。コントローラーにおける方法は、制御プレーン(control plane)における方法と呼ぶこともでき、ステージにおける方法はデーター・プレーンにおける方法と呼ぶこともできる。コントローラーは、図１および図２に示すように集中型でもよく、または例えば複数のステージにおける機能を使用して、分散型にしてもよい。
【００３０】
[0030]  コントローラーは、フローに対するポリシーにアクセスする（３００）。例えば、ポリシーは、予め構成されているポリシーであってもよく、閾値、判断基準、または規則にしたがってポリシーのライブラリーから選択されてもよく、ユーザによって入力されてもよく、複数の利用可能なポリシーから顧客によって選択されてもよく、あるいは他の方法でアクセスされてもよい。
【００３１】
[0031]  これより、ポリシーの例をいくつか示すが、これらは例に過ぎず、他のポリシーを使用してもよい。
[0032]  詳述しやすくするために、｛［ＶＭの集合］、［ストレージ・シェアの集合］｝→ポリシーという形態のフロー・ポリシー例を示す。しかしながら、フロー・ポリシーを表現するために他のフォーマットが使用されてもよい。
【００３２】
[0033]  ポリシーＰ１。｛ＶＭｐ、シェアＸ｝→帯域幅Ｂ。この例では、ＶＭｐが、ストレージ・シェアＸ上でＳＱＬデーター・ファイルにアクセスするＳＱＬクライアントを実行する。正しいクエリー（query）の挙動(performance)を与えるために、シェアにアクセスするとき、ｐには帯域幅Ｂが保証される。Ｂは、１秒当たりのトークン単位で表すことができる。トークンについては、以下で更に詳しく説明する。
【００３３】
[0034]  ポリシーＰ２。｛ｐ、Ｘ｝→Ｍｉｎ帯域幅Ｂ。この設定は、シェアＸにアクセスするときにＶＭ  ｐに最小帯域幅Ｂが約束されたポリシーＰ１と同様である。つまり、他のＶＭがアイドルであるとき、ｐはその帯域幅保証を超えることができる。
【００３４】
[0035]  ポリシーＰ３。｛ｐ、Ｘ｝→サニタイズ。ＶＭｐは信頼できないコードを実行し、そのトラフィックは、ウィルス・チェッカーまたは他のチェック・プロセスのような、サニタイゼーション・レイヤを通して送出される。
【００３５】
[0036]  ポリシーＰ４。｛ｐ、Ｘ｝→高い優先順位。ＶＭｐは、ストレージ・シェアＸ上でＳＱＬログ・ファイルにアクセスするＳＱＬクライアントを実行する。ログ処理に対する低レイテンシを確保するために、ｐのストレージ・トラフィックは、両端間のパス(end-to-end path)にそって高い優先順位の処理を要求する。
【００３６】
[0037]  ポリシーＰ５。｛［ｐ、ｑ、ｒ］、［Ｘ，Ｙ］｝→帯域幅Ｂ。ＶＭｐ、ｑ、およびｒは、同じ顧客に属し、シェアＸおよびＹにアクセスするとき、帯域幅Ｂが保証される。このような顧客毎の保証は、関与するＶＭのいずれもが帯域幅保証を使用することができるので、有用である。
【００３７】
[0038]  ポリシーＰ１〜Ｐ４は、両端間フローの処理を指定し、一方Ｐ５はマルチポイント・フローに適用される。
[0039]  コントローラーは、ポリシーを実装する(implement)ために制御命令を作成する（３０２）。たとえば、ポリシーＰ１について検討する。ＶＭｐからのストレージ・トラフィックは、計算サーバーにおけるゲストＯＳおよびハイパーバイザーをトラバースし(traverse)、次いでネットワーク・スイッチ、そして最後にストレージ・サーバーにおけるＯＳをトラバースし、その後にディスク・アレイに到達する。このポリシーを施行するために、これらのレイヤの内少なくとも１つは、ＶＭｐからシェアＸへの要求が転送されるレート(rate)を制御するように構成される。ポリシーＰ１を施行するために、これらのレイヤの１つ以上においてレートを制御するための制御命令を作成する。
【００３８】
[0040]  制御命令を作成する一部として、コントローラーはフロー名称解決を実行することもできる。例えば、ポリシーは、フローの１つ以上の個々のレイヤでは理解されない上位名称を使用して表現されたエンドポイントを有するフローに適用されるように指定される。コントローラーは、この上位エンドポイント名称を解決して、個々のレイヤによって理解される下位識別子を求める。上位エンドポイント名称を解決するプロセスは、フロー名称と下位ステージ特定のＩＯ要求識別子との間に一貫性のある１対１のマッピングを与える。例えば、ポリシーＰ１では、ＶＭｐからシェアＸまでのレイヤはいずれも、施行点として動作することができるものの、各々、それらをトラバースする要求におけるある下位識別子を観察することしかできない。フローの宛先であるシェアＸは、ＶＭおよびゲストＯＳ内部にあるファイル・システムのように見えるかもしれないが、ハイパーバイザー内部にあるブロック・デバイス（例えば、"/dev/scsidisk5"）として現れる。ハイパーバイザーは、これをストレージ・サーバー上のＶＨＤファイルにマッピングする（例えば、"＼＼serve＼share＼ file.VHD"）。一方、ストレージ・サーバーはこのファイル（例えば、"H: ＼file.VHD"）を特定のデバイス（例えば、"/device/ssd5"）にマッピングする。
【００３９】
[0041]  制御命令は、１つ以上のキューおよび／またはキュー・ドレイン・レート(queue drain rate)のような、キューのパラメーターを設定する(configure)ための命令を作成、編集、または削除する命令を含むことができる。また、制御命令は、入力／出力要求をキューに割り当てるための判断基準を指定するキュー指定規則も含むことができる。
【００４０】
[0042]  制御命令は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して書くことができる。アプリケーション・プログラミング・インターフェースは、ＳＭＢのような分散型ストレージ・プロトコルの最上位に位置する。しかしながら、これは必須ではない。コントローラーがどのようにして制御命令を作成するか（３０２）についての更なる詳細については、図４および図６を参照して以下で説明する。
【００４１】
[0043]  コントローラーは、制御命令を１つ以上の選択したステージに送る（３０４）。例えば、制御命令は、図１を参照して先に説明した通信リンクを介して送られる。以下で更に詳しく説明するように、コントローラーは、１つ以上のステージから、どれに制御命令を送るか選択することができる。例えば、ポリシー施行の効率というような判断基準を使用する。
【００４２】
[0044]  前述のように、フローのパスに沿った１つよりも多いステージにおいて、フロー・ポリシーを施行することができる。例えば、ポリシーＰ１は、ＶＭｐの帯域幅が決してＢを超えないことを要求する。この帯域幅制限は、ＶＭ内部の任意のステージにおいて、ハイパーバイザーにおいて、ネットワーク・スイッチにおいて、またはストレージ・サーバー自体においてでさえも施行することができる。対比として、ポリシーＰ４は、ＶＭｐのパケットが高い優先順位を得ることを必要とするので、両端間の経路に沿った全てのステージにおいて施行されなければならない。
【００４３】
[0045]  マルチポイント・ポリシーは、分散型施行の必要性に他の次元を追加する。即ち、制御命令を１つよりも多いステージに送る。例えば、ポリシーＰ５は、ＶＭｐ、ｑ、およびｒからシェアＸおよびＹへの総トラフィックが、レート制限される(rate limited)ことを要求する。これは、これらのＶＭをホストする計算サーバーの各々において、および／またはシェアが実装されるストレージ・サーバーにおいて施行することができる。
【００４４】
[0046]  ある例では、コントローラーは、フローの振る舞い、キューの振る舞い、ポリシーの施行、または他の要因についてのフィードバックを受ける（３０６）。これは、ポリシーを実施する制御命令を動的に作成するためにフィードバックを使用する。このように、コントローラーにおけるプロセスは、変化しつつある条件に直面して、公正で正確なポリシー施行を遂行しようとして、連続的に制御命令を適応化することができる。これを「動的施行」と呼ぶことができる。
【００４５】
[0047]  動的施行を必要とせずに施行できるポリシーの例に、ＶＭｐのトラフィックに対して固定帯域幅制限を設定するポリシーＰ１がある。また、固定施行規則は、ポリシーＰ３およびＰ４に対しても動作可能である。対比として、ポリシーＰ２は動的施行を使用する。ポリシーＰ２は、ＶＭｐに対する帯域幅制限が、スペア・システムの容量に基づいて（最小保証を下回ることなく）調節されることを要求する。同様に、総合保証(aggregate guarantees)を提供するＰ５のようなマルチポイント・ポリシーも動的施行規則を使用する。
【００４６】
[0048]  ステージにおけるプロセスは、コントローラーから制御命令の一部として１つ以上のキュー指定規則を受けるステップ（３０８）を含む。ステージは、制御命令にしたがってその１つ以上のキュー３１０を構成し、キュー指定規則にしたがって、そのステージにおけるしかるべきキューにストレージＩＯパケットを転送する（３１２）。ステージは、例えば、サービス判断基準、および同様にコントローラーによって指定することができる規則にしたがって、そのキューをサービスする(service)（３１４）。
【００４７】
[0049]  図４は、コントローラー（集中型または分散型でもよい）における発見方法の流れ図である。この方法は、コントローラーが、データー・センターまたは他のストレージ・システムのような、ストレージ・システムのステージ・レベルのトポロジー・グラフを作成し維持することを可能にする。コントローラーが分散型であり、各ステージにおいて機能を含む場合、ある例では、各ステージがステージ・レベルのトポロジー・グラフを作成し維持してもよい。ステージ・レベルのトポロジー・グラフは、ストレージ・システムにおけるステージ間における通信リンクを表すように、ストレージ・システムのステージ毎のノードと、ノードを接続するエッジとを含む。
【００４８】
[0050]  コントローラーは、個々のステージが起動(boot up)または初期化するときに、これらからメッセージを受ける（図４のステップ４００参照）。例えば、各ステージは、起動または初期化するときに、メッセージを１つ以上の指定されたアドレスに送る、またはメッセージをブロードキャストするように構成することができる。また、コントローラーは、例えば、データー・ストレージ・システムにおけるトラフィックを観察することによって、ストレージ・システムの１つ以上のレイヤ（これらは、コントローラーに対する専用インターフェースを有さないストレージ・システムのコンポーネントである）を検出することもできる。
【００４９】
[0051]  コントローラーは、どのタイプのＩＯヘッダをステージが理解するかについての詳細、およびそのステージにおけるキューのサービスおよびルーティング・プロパティの詳細というような、ステージ情報を発見する（４０４）。キューのサービス・プロパティは、どの位速くサービスされるのか管理し、ルーティング・プロパティは、ＩＯ要求が送出される次のステージを指示する。コントローラーは、クエリーをステージに送ることによって、ステージの振る舞いを観察することによって、または他の方法で、ステージ情報を発見する（４０４）のでもよい。
【００５０】
[0052]  コントローラーは、データー・センターまたは他のストレージ・システムのような、ストレージ・システムのステージ・レベル・トポロジー・グラフを作成し維持する（４０６）。前述のように、ステージ・レベル・トポロジー・グラフは、ストレージ・システムにおけるステージ間における通信リンクを表すように、ストレージ・システムのステージ毎のノードと、ノードを接続するエッジとを含む。ステージ・レベル・トポロジー・グラフの一例を図５に示す。任意に、コントローラーは、物理リソースに対応するグラフのエッジの容量を判定する。これは、予め構成されたトポロジー・マップを使用することによって行うことができる。また、 Iometer（商標）またはその他の測定および特徴化ツールというような、ベンチマーク・プロセスを実行することによって容量を発見することもできる。
【００５１】
[0053]  図５は、図２の構成のステージ・レベル・トポロジー・グラフである。これは、４つのステージ５００、５０２、５０４、５０６を含む。仮想機械（ＶＭ）からのストレージＩＯ要求は、ＩＯプロトコル・コンポーネント２１８に対応する第１ステージ５００に到達し、続いて第２ステージ５０２であるネットワーク・ドライバー２２０に進む。要求は、スイッチ１０８を介して、図５のステージ５０４である、ストレージ・サーバーにおけるネットワーク・ドライバー２３８に伝わる。ＩＯ要求は、図５のステージ５０６に対応するＩＯプロトコル・コンポーネント２３２に進み、フローはストレージ・サーバーにおける記憶ディスクにおいて終了する。図５の例では、ＳＭＢにおいて使用される分散型ストレージ・プロトコルであるが、これは必須ではない。他の分散型ストレージ・プロトコルを使用することもできる。また、図５のステージ・レベル・トポロジー・グラフは、ネットワーク・リンク、ネットワーク・スイッチ１０８、およびストレージ・バックエンドを含む基礎的な物理リソースも含む。仮想ハード・ディスクにアクセスする仮想機械によって、簡単なＩＯフローが示されている。この例では、コントローラーは、ステージについての情報を発見し、この情報をグラフに格納した。例えば、下位ＩＯヘッダは、ステージがパケットをキューに割り当てるために使用することができる。
【００５２】
[0054]  図６は、コントローラーにおける方法の流れ図である。この方法は、図３の方法（ステップ３００から３０６）と同様であり、更に詳細になっている。図３に関して、この方法は集中型コントローラーにおいて実装することができ、または複数のエンティティ間で分散することもできる。
【００５３】
[0055]  コントローラーは、図３を参照して先に説明したように、ポリシーを受ける（６００）か、またはポリシーにアクセスする。基礎をなす物理的リソースの容量のために、そして既存のポリシーを考慮に入れて、このポリシーが実現可能であることをチェックすることができる（６０２）。例えば、コントローラーは、それが作成し維持してあるステージ・レベル・トポロジー・グラフ、およびそれが有する既存のポリシーについての情報を使用することもできる。
【００５４】
[0056]  コントローラーは、ポリシーをどこで実施するか決定する（６０４）ことができる。例えば、複数のステージが利用可能な場合もあり、コントローラーは、これらのステージの内どの１つ以上を、ポリシーを施行するために使用するか決定することができる。利用可能なＣＰＵリソースおよびその他というような、種々の要因を考慮に入れることができる。
【００５５】
[0057]  コントローラーは、フロー・エンドポイント識別子を解決して下位識別子を得る（６０６）。コントローラーは、どのヘッダ・タイプであればステージが理解できるのか発見する。例えば、この情報を求めるために、メッセージをそのステージに送る。この情報を使用して、上位エンドポイント名称を解決して適したヘッダ・タイプを得て、この適したヘッダ・タイプに基づいてキュー指定規則を策定する(generate)。
【００５６】
[0058]  コントローラーは、キュー指定規則を作成し、これらがインストールされる該当のステージに送る。図２の計算サーバーＩＯプロトコル・コンポーネントステージに対するキュー指定規則の例は次の通りである。
【００５７】
[0059] 1: I0 Header <VM1, ＼＼server X＼share＼file F>→Queue Q1
[0060] 2: IO Header <VM2, ＼＼server Z＼share＼*>→Queue Q2
[0061] 3: IO Header <VM3, *>→Queue Q4
[0062] 4: <*, *>→Queue Q3
[0063]  ここで、「サーバー」はリモート機械またはローカル・ホストでもよい。シンボル「＊」はワイルドカードである。上のキュー指定規則１は、パケットのヘッダが、当該パケットがＶＭ１から発しておりサーバーＸにおけるファイルＦに宛てられることを示す場合、これらのパケットはキュー１に割り当てられることを表す。上のキュー指定規則２は、パケットのヘッダが、これらがＶＭ２から発しておりサーバーＺ上の任意のファイルに宛てられることを示す場合、これらのパケットはキュー２に割り当てられることを表す。上のキュー指定規則３は、パケットのヘッダが、これらがＶＭ３から発していることを示す場合、これらのパケットはキュー４に割り当てられることを表す。キュー指定規則４は、パケットが他のキューのいずれにも割り当てられない場合、これらのパケットはキュー３に割り当てられることを表す。
【００５８】
[0064]  図２のストレージ・サーバー・ステージにおけるＩＯプロトコル・コンポーネントに対するキュー指定規則の例は、次の通りである。
[0065] 1: IO Header <SID S1, H: ＼File F>→Queue Ql
[0066] 2: IO Header <SID S2, H: ＼File G>→Queue Ql
[0067] 3: IO Header <SID S2, H: ＼Directory A/*>→Queue Q2
[0068] 4: <*, *>→Queue Q3
[0069]  ここで、ＳＩＤは、ユーザ、プロセス、およびサーバーを識別するセキュリティ記述子を表す。上のキュー指定規則１は、パケットのヘッダがサーバー１のＳＩＤを含み、パケットの宛先がファイルＦである場合、これらのパケットはキュー１に割り当てられることを記述する。上のキュー指定規則２は、パケットのヘッダがサーバー２のＳＩＤを含み、パケットの宛先がファイルＧである場合、これらのパケットはキュー１に割り当てられることを記述する。尚、これは、異なるフローに属するパケットが同じキューに導かれる場合もあることを示すことを注記しておく。上のキュー指定規則３は、パケットのヘッダがサーバー２のＳＩＤを含み、パケットの宛先がディレクトリＡである場合、これらのパケットはキュー２に割り当てられることを記述する。上のキュー指定規則４は、規則１および２を満たさないパケットはキュー３に割り当てられることを記述する。
【００５９】
[0070]  また、コントローラーは、キュー・ドレイン・レートおよびキュー・ルーティングのような、キュー毎の構成を決定する。例えば、コントローラーは、トークン・レート、優先順位、およびキュー・サイズのような、キュー・プロパティを設定することができる。キューのトークン・レートは、パケットがキューから放出されるレートに関係する。キューの優先順位は、他のキューに対して、キューがサービスされる順序を指定する。キューのサイズは、キューに格納することができるパケットの数を指定する。
【００６０】
[0071]  構成変更可能なサービス・プロパティによってキューを実施するステージは、優先的にＩＯ要求を抑えるまたは処理する(treat)ことができる。これらのサービス・プロパティは、実行分離(performance isolation)ポリシー（例えば、上のポリシーＰ１、Ｐ２、Ｐ４、Ｐ５）の実施を可能にする。ＩＯトラフィックを抑えるために、キューはトークン・バケット抽象化(token-bucket abstraction)を使用することができる。キューは、一定のトークン・レートでサービスされてもよい。優先順位フィールドによって示されるように、あるキューが他よりも優先的に扱われてもよい。キューがキュー・サイズ閾値に達した場合、ステージはコントローラーに通知することができる。コントローラーは、以下で更に詳しく説明するＡＰＩのconfigureQueueServiceコールを使用して、または他の方法で、キューに対するサービス・プロパティ（＜トークン・レート、優先順位、キュー・サイズ＞）を設定することもできる。周期的に、コントローラーは、以下で更に詳しく説明するＡＰＩのコールを使用して、キューの平均サービス・レートおよびキュー・サイズまたは他の統計というような、キューを記述する統計を監視することができる。
【００６１】
[0072]  あるステージが、キューに入れられたＩＯ要求をどのように送出するかの制御を可能にしてもよい。キューは、デフォルトのネクストホップと関連付けられてもよい。例えば、計算サーバーのＩＯプロトコル・コンポーネントステージにおける要求をネットワーク・ドライバーに送出するのでもよい。このステージにおけるキューは、ハイパーバイザーにもないステージというような、異なるステージに要求を送出させるように構成することができる。このようなステージの構成変更可能な配管工事(plumbing)は、豊富な１組のフロー・ポリシーを可能にする。例えば、コントローラーは、信頼できないＶＭからウィルス・スキャナ・ステージを経てＩＯ要求を送出する制御命令を送ることもできる。
【００６２】
[0073]  コントローラーは、図３を参照して先に説明したように、制御命令を選択されたステージに送り（６０８）、任意にフィードバックを受ける。これは、ポリシーに対する変化および／またはフロー・パスに対する変更についての情報を受けることもできる（６１０）。例えば、顧客はＶＭを追加するまたは削除することができる。ファイルは、異なるストレージ・サーバーに移動することもできる。この結果、新たなフロー・パスができ、これに沿ってポリシーが施行されることになる。コントローラーは、古いフロー・パスに沿ったステージにおいてキュー指定規則を削除し、新たなフロー・パスに沿ってキュー指定規則を追加することができる。
【００６３】
[0074]  コントローラーは、新たなポリシーが定められるときに、様々なステージを更新することができる。多くの場合、ステージに跨がる特定の更新順序付けは要求されず、各ステージにおける一時的な一貫性のない規則が、これらが最終的に収束する限り、許容され得る。例えば、コントローラーは、関連するステージに対する、あるバージョン番号の任意の状態更新を一括処理し、同じバージョン番号の承認を待ち、次いで任意の別の状態転移を進めることができる。厳密な更新順序付けが必要とされる場合、コントローラーは、分散同意プロトコルに関係することをステージに要求することなく、各ステージをその順序で更新する。ステージ構成は、ソフト・ステートであるので、パスに沿ったあるステージの障害（例えば、ストレージ・サーバーの障害）が、そのステージにおけるキューおよびキュー指定規則を破壊するおそれがある。サーバーがオンラインに復帰したとき、制御サービスに連絡を取り、それに責任があるキュー指定規則のリストを得る。
【００６４】
[0075]  ある例では、コントローラーは、フローに関連付けられたバージョン番号を追跡し、それがステージに連絡を取る毎に、その数を単調に増加させる。あるエポック番号のメッセージを受信すると、ステージはそれよりも低いバージョン番号を有する後続のメッセージ（一時的なネットワーク分割(partition)の後システム内にあった可能性があるメッセージ）を全て破棄する。
【００６５】
[0076]  図７は、ステージにおける方法の模式図である。ステージが起動または初期化すると、その存在を通知するためにコントローラーに連絡を取る（７００）。例えば、指定されたアドレスでメッセージをコントローラーに送ることができ、または通知メッセージをブロードキャストすることもできる。ステージは、２つ以上のキュー、およびキュー毎に少なくとも１つのキュー指定規則を受け、インストールする（７０２）。これは、キューおよびキュー指定規則を、コントローラーからの制御命令の一部として受ける。ステージは、制御命令にしたがってそれらのドレイン・レートおよびルーティング特性を設定することによって、キューを構成する。
【００６６】
[0077]  ステージは、ストレージＩＯ要求パケットを受ける（図７のステップ７０４参照）。例えば、そのヘッダを調べることによって、パケットがキュー指定規則と一致するか否かチェックする。一致がある場合、一致したキューにパケットを転送する（７０８）。一致がない場合、ある例では要求パケットをブロックし（７１０）、キュー指定規則を求めるメッセージをコントローラーに送る（７１２）。尚、ブロックするステップ７１０は任意であることを注記しておく。回答を受けた場合（７１４）、コントローラーから受けたキュー指定規則をインストールし（７１６）、要求メッセージのブロックを解除する（７１８）。コントローラーから回答を受けなかった場合、ブロックした要求に対してデフォルトのキューを使用する（７２０）。次いで、最小ヒープ順序、または任意の他の適した順序にしたがって、キューをサービスする。キューの振る舞いについてのフィードバックをコントローラーに送ることができる（７２４）。
【００６７】
[0078]  図８は、先のポリシーＰ５の施行に関連するステージを含むトポロジー・サブグラフの一例を示す。ＶＭからステージまでのパスに沿った他のステージは、明確化のために省略されている。
【００６８】
[0079]  ポリシーＰ５は、｛｛ｐ、ｑ、ｒ｝、｛Ｘ，Ｙ｝｝→帯域幅Ｂと表現することができ、これが意味するのは、仮想機械ｐ８００、ｑ８０２、およびｒ８０４からのパケットが、ストレージ・シェアＸ８０６およびＹ８０８に行こうとしており、これらに総帯域幅Ｂが保証されることになっているということである。このポリシーは、マルチポイント・フローを伴うので特に興味深い。即ち、これは多数のソース（ＶＭｐ、ｑ、ｒ）から多数の宛先（シェアＸ、Ｙ）へのＩＯに対して総合的な保証を提供する。以下で説明するように、これはステージの動的構成を使用する。例えば、ｐがＩＯを生成する唯一のＶＭである場合、これが帯域幅Ｂを得ればよい。
【００６９】
[0080]  このポリシーは、以下のように施行することができる。コントローラー１０６によって維持されるデーター・センター・トポロジー・グラフを想定すると、コントローラーにおける制御アプリケーションが、このポリシーに関連するサブグラフを決定する。図８に示すように、このサブグラフは、ＶＭｐ、ｑ、ｒから、シェアＸおよびＹが実装されているストレージ・サーバーまでのパスに沿ってステージを含む。このグラフのエッジはステージ間のリンク、物理的ネットワーク・リンク、およびストレージ・サーバーから実際のディスクへのインターフェースである。制御アプリケーションの動作は、２つのステップを含む。
【００７０】
[0081]  最初に、受付（admission）制御である。コントローラーは、以上のグラフに沿ったエッジが、保証を満たすのに十分な予備容量を有することを確認する。ネットワーク・リンクおよびディスクへのリンクの合計帯域幅容量は、コントローラーの発見コンポーネントによって判定される。各リンク上における容量の一部は、前から存在するポリシーのために確保されている場合もあるので、このポリシーは、各リンク上において確保されていない容量が保証Ｂ以上である場合にのみ、受け付けることができる。
【００７１】
[0082]  第２に、施行である。コントローラーは、ＶＭｐ、ｑ、ｒからシェアＸ、Ｙまでの全てのＩＯの合計レートが、総帯域幅Ｂを保証することを確認する。この総帯域幅制限は、グラフにおける任意のカット(cut)において施行することができる。この例は、顧客の１人だけの視点からのものである。図８に示すように、ＶＭがホストされているハイパーバイザーまたはストレージ・サーバーにおいてこれを施行することができる。この例では、コントローラーがハイパーバイザー内部のあるステージにおいて帯域幅制限を施行することを選択したと仮定する。これを行うためには、制限の総和がＢに等しくなるように、ＶＭ毎に帯域幅制限を決定する必要がある。つまり、コントローラー・アプリケーションは、分散型レート制限を行う必要がある。即ち、１組のＮ個のＶＭ（この例では、Ｎ＝３）を想定し、これらの間で帯域幅Ｂを分散することがタスクになる。これは、各ソースにリンクのその最大−最小公正シェアを与えることによって行うことができる。最大−最小分配（sharing)では、ＶＭのトラフィック要求量、即ち、これらがトラフィックを送ることができるレートに基づいて、ＶＭにレートを割り当てる(assign)。具体的には、ＶＭがその要求量よりも大きなレートを得ることがなく、要求量が満たされないＶＭが等しいレートを得るように、要求量が少ない順にレートが割り当てられる。つまり、ＶＭに対して要求量の集合Ｄを想定すると、コントローラーは、最大−最小公正シェアｆを決定し、次いで個々のＶＭに割り当てられるレートを指定し、これらのレートの合計が前述の帯域幅となることを確保する。
【００７２】
[0083]  これらのレートが与えられると、制御アプリケーションはハイパーバイザーのステージを構成する。ＶＭｐに対して、ｐがホストされたハイパーバイザーのステージにおいてキューを作成し、ＶＭｐからシェアＸおよびｙへのトラフィック全てをこのキューに導くキュー指定規則を作成し、このキューのドレイン帯域幅を、ｐに割り当てられたレートに設定する(configure)。ＶＭｑおよびｒに対するステージ構成は同様である。
【００７３】
[0084]  コントローラーは、ＶＭ要求量を近似するために、周期的にハイパーバイザー・ステージから統計を収集することができる。制御アプリケーションは、これらの統計を使用して、キュー・ドレイン設定値から周期的に更新帯域幅制限を策定する(generate)。
【００７４】
[0085]  以上で説明した例は、マルチポイント・フローに対して総合保証を確保する。他の例では、総合最小帯域幅保証(aggregate minimum bandwidth guarantee)を提供する場合もある。これが意味するのは、１つのフローに対するＶＭがインアクティブになっているとき、他のフローのＶＭは予備の帯域幅を利用できるということである。例えば、コントローラーは、トラフィック統計をステージのキューから収集し、全てのデーター・センターＩＯフローにわたる階層的最大−最小分配アルゴリズムを使用して、それらの帯域幅制限を決定する。
【００７５】
[0086]  前述のように、各ステージおよびコントローラーは、これらが通信することを可能にするＡＰＩを実装することもできる。１つの可能なＡＰＩの例についてこれより示すが、これは一例であり、多くの他のＡＰＩが使用されてもよい。
【００７６】
[0087]   Ａ０  getQueuelnfo ()    
[0088]  このＡＰＩコールは、ステージが整列のために使用するＩＯヘッダの種類、および構成変更可能であるステージのキュー・プロパティを戻す。また、これは、デフォルトのネクストホップ・ステージを含む、可能なネクストホップ・ステージも指定する。
【００７７】
[0089]  Ａ１  getQueueStats (Queue-id q)
[0090]  このＡＰＩコールはキュー統計を戻す。
[0091]  Ａ２  createQueueRule (IO Header i, Queue-id q)
[0092]  このＡＰＩコールは、キュー指定規則ｉ→ｑを作成する。
【００７８】
[0093]  Ａ３  removeQueueRule (IO Header i, Queue-id q)  
[0094]  このＡＰＩコールは、キュー指定規則を解除する。
[0095]  Ａ４  configureQueueService (Queue-id q,<token rate, priority, queue size>)
[0096]  このＡＰＩコールは、トークン・レート、キューの優先順位、およびサイズの内１つ以上を設定する(configure)。
【００７９】
[0097]  Ａ５  configureQueueRouting (Queue-id q, Next-hop stage s)
[0098]  このＡＰＩコールは、キューを送出しようとする次のホップ・ステージを構成する(configure)。
【００８０】
[0099]  Ａ６  configureTokenBucket (Queue-id q, <benchmark-results>)
[00100]  このＡＰＩコールは、所与の要求に対してどれくらいのトークンを引き受けるべきかを示すベンチマーク結果を得る。
【００８１】
[00101]  図９は、計算ベース・デバイス例９００の種々のコンポーネントを示し、デバイス９００は、任意の形態の計算および／または電子デバイスとして実現することができ、このデバイスにおいて、コントローラーおよび／またはステージの実施形態を実現することができる。
【００８２】
[00102]  計算ベース・デバイス９００は、１つ以上のプロセッサー９０２を含む。プロセッサー９０２は、マイクロプロセッサー、コントローラー、またはストレージ・システムにおいてストレージ入力出力要求を制御するために、デバイスの動作を制御するコンピューター実行可能命令を処理する任意の他の適したタイプのプロセッサーであってもよい。ある例では、例えば、システムオンチップ・アーキテクチャーが使用される場合、プロセッサー９０２は、コントローラーおよび／またはステージの方法の一部をハードウェアで実現する（ソフトウェアまたはファームウェアではなく）１つ以上の固定機能ブロック（アクセレレーターとも呼ぶ）を含むのでもよい。本デバイス上でアプリケーション・ソフトウェアを実行することを可能にするために、計算ベース・デバイスにおいて、オペレーティング・システム９０４を含むプラットフォーム・ソフトウェアまたは任意の他の適したプラットフォーム・ソフトウェアを設けてもよい。
【００８３】
[00103]  コンピューター実行可能命令は、計算ベース・デバイス９００によってアクセス可能な任意のコンピューター読み取り可能媒体を使用して供給することができる。コンピューター読み取り可能媒体は、例えば、メモリー９０８のようなコンピューター記憶媒体、および通信媒体を含むことができる。メモリー９０８のようなコンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のための任意の方法または技術で実現される。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、あるいは計算デバイスによるアクセスのために情報を格納するために使用することができる任意の他の非通信媒体を含むが、これらに限定されない。対照的に、通信媒体は、搬送波のような変調データー信号、または他の伝送メカニズムに、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターを具体化することができる。本明細書において定義する場合、コンピューター記憶媒体は通信媒体を含まない。したがって、コンピューター記憶媒体は、伝搬信号自体であると解釈すべきでない。伝搬信号は、コンピューター記憶媒体内に存在することもあるが、伝搬信号自体はコンピューター記憶媒体の例ではない。コンピューター記憶媒体（メモリー９０８）は計算ベース・デバイス９００内部に示されているが、ストレージは分散されまたは離れて配置され、ネットワークまたは他の通信リンクによって（例えば、通信インターフェース９１０を使用して）アクセスされてもよいことは認められよう。
【００８４】
[00104]  計算ベース・デバイスがステージを実装する場合、複数の構成変更可能なキュー９０６を含む。計算ベース・デバイスがコントローラーまたはステージを実装する場合、デバイスがコントローラーまたはステージと適宜通信することを可能にする制御インターフェース９０７を含む。トポロジー・グラフ、パラメーター値、キュー指定規則、閾値、判断基準、およびその他のデーターを格納するために、データー・ストア９１２が設けられる。
【００８５】
[00105]  「コンピューター」または「計算ベース・デバイス」という用語は、本明細書では、命令を実行することができるように処理能力を有する任意のデバイスを指すために使用される。このような処理能力は多くの異なるデバイスに組み込まれ、したがって「コンピューター」および「計算ベース・デバイス」という用語は、各々、ＰＣ、サーバー、移動体電話機（スマート・フォンを含む）、タブレット・コンピューター、セット・トップ・ボックス、メディア・プレーヤー、ゲーム・コンソール、パーソナル・ディジタル・アシスタント、および多くの他のデバイスを含むことは、当業者には認められよう。
【００８６】
[00106]  本明細書において説明した方法は、有形記憶媒体上にある機械読み取り可能な形態、例えば、プログラムがコンピューター上で実行されたとき、そしてコンピューター・プログラムがコンピューター読み取り可能媒体上に具体化することができる場合、本明細書において説明した方法の内任意のものの全てのステップを実行するように構成されたコンピューター・プログラム・コード手段を含むコンピューター・プログラムの形態のソフトウェアによって実行することができる。有形記憶媒体の例には、ディスク、サム・ドライブ(thumb drive)、メモリー等のような、コンピューター読み取り可能媒体を構成するコンピューター記憶デバイスを含み、伝搬信号を含まない。伝搬信号は、有形記憶媒体内に存在することもあるが、伝搬信号自体は有形記憶媒体の例ではない。ソフトウェアは、本方法のステップを任意の適した順序でまたは同時に実行することができるように、パラレル・プロセッサーまたはシリアル・プロセッサー上における実行に相応しくすることができる。
【００８７】
[00107]  これは、ソフトウェアが価値のある、別個に取引可能な製品となり得ることを認める。これは、所望の機能を実行するために「ダム」(dumb)または標準的なハードウェア上で実行するソフトウェアまたはこれを制御するソフトウェアを包含することを意図している。また、ＨＤＬ（ハードウェア記述言語）ソフトウェアのような、所望の機能を実行するために、シリコン・チップを設計するまたは万能プログラマブル・チップを構成する際に使用されるような、ハードウェアの構成を「記述する」ソフトウェアまたは ハードウェアの構成を定めるソフトウェアを包含することも意図している。
【００８８】
[00108]  尚、プログラム命令を格納するために利用される記憶デバイスは、ネットワークにわたって分散させることができることは、当業者には理解できよう。例えば、リモート・コンピューターが、ソフトウェアとして記述されたプロセスの一例を格納することもできる。ローカルまたは端末コンピューターが、リモート・コンピューターにアクセスし、プログラムを実行するために、ソフトウェアの一部または全部をダウンロードすることもできる。あるいは、ローカル・コンピューターが必要に応じてソフトウェアの断片をダウンロードすること、またはローカル端末において一部のソフトウェア命令を実行し、リモート・コンピューター（またはコンピューター・ネットワーク）において一部を実行することもできる。また、当業者には周知である従来の技法を利用することによって、ソフトウェア命令の全部または一部を、ＤＳＰ、プログラマブル・ロジック・アレイ等のような専用回路によって実行できることも、当業者には理解できよう。
【００８９】
[00109]  当業者には明白であろうが、本明細書において示した範囲またはデバイス値はいずれも、求められる効果を失うことなく、広げることまたは変更することもできる。
[00110]  以上、構造的特徴および／または方法論的アクトに特定的な文言で主題について説明したが、添付した特許請求の範囲において定められる主題は、以上で説明した特定の特徴やアクトに必ずしも限定されないことは理解されてしかるべきである。逆に、以上で説明した特定の特徴やアクトは、特許請求の範囲を実現する形態例として開示したまでである。
【００９０】
[00111]  尚、以上で説明した便益および利点は、１つの実施形態に関係してもよく、または様々な実施形態に関係してもよいことは理解されよう。実施形態は、先に述べた問題の内いずれかを解決するものにも、全てを解決するものにも、また先に述べた便益や利点の内いずれかを有するものにも、全てを有するものにも限定されない。更に、「１つの」項目に言及するときは、１つ以上のその項目に言及するということも理解されよう。
【００９１】
[00112]  本明細書において説明した方法のステップは、任意の適した順序で実行されても、または該当する場合には同時に実行されてもよい。加えて、個々のブロックは、本明細書において説明した主題の主旨や範囲から逸脱することなく、これらの方法のいずれからも削除されてもよい。以上で説明した例はいずれも、求められる効果を失うことなく更に他の例を形成するために、その態様を、説明した他の例のいずれの態様とでも組み合わせることができる。
【００９２】
[00113]  「含む」(comprising)という用語は、本明細書では、識別された方法のブロックまたはエレメントを含むが、このようなブロックまたはエレメントが排他的リストを構成するのではなく、方法または装置が追加のブロックまたはエレメントを含んでもよいことを意味するために使用される。
【００９３】
[00114]  尚、以上の説明は一例として挙げたに過ぎず、当業者によって種々の変更が成されてもよいことは理解されよう。以上の明細書、例、およびデーターは、実施形態例の構造および使用についての完全な説明を示す。以上ある程度の特定性をもって、または１つ以上の個々の実施形態を参照して種々の実施形態について説明したが、当業者であれば、本明細書の主旨や範囲から逸脱することなく、開示された実施形態に対して多数の改変を行うことができよう。
【図１】
2016536714.tif 000003
【図２】
2016536714.tif 000004
【図３】
2016536714.tif 000005
【図４】
2016536714.tif 000006
【図５】
2016536714.tif 000007
【図６】
2016536714.tif 000008
【図７】
2016536714.tif 000009
【図８】
2016536714.tif 000010
【図９】
2016536714.tif 000011
【国際調査報告】
2016536714.tif 000012
2016536714.tif 000013