(57)【特許請求の範囲】
【請求項１】
プロビジョニングされた作業負荷のそれぞれの速度を実現するために、マルチテナント・ストレージ・サービスに実装された複数のブロックレベル・ストレージ・デバイスの各々についてアドミッション制御パラメータのそれぞれのセットを確立し、
複数のブロックレベル・ストレージ・デバイスの各々に対応するそれぞれのプロビジョニングされた速度を、前記マルチテナント・ストレージ・サービスの１つのクライアントの代わりに確立し、
前記マルチテナント・ストレージ・サービスのクライアント側コンポーネントにより、第一ストレージ・サーバに実装された第一ブロックレベル・ストレージ・デバイスの少なくとも１部を特定の期間中に対象とすることを期待された作業要求の特定の速度の推定値を生成し、前記特定の速度が前記プロビジョニングされた速度のうちの第一のプロビジョニングされた速度を超え、
前記クライアント側コンポーネントにより、作業要求のそれぞれの速度がそれぞれ前記プロビジョニングされた速度未満であることを予測される、第二ストレージ・サーバを含む、１つ以上の他のストレージ・サーバを識別し、
前記第一ストレージ・サーバが前記第一のプロビジョニングされた速度を超える速度で作業要求を完了するために前記特定の期間中に十分な作業負荷容量を有することを検証し、
前記第一ブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記第一ストレージ・サーバが前記特定の期間中に前記第一のプロビジョニングされた速度を超える速度まで作業要求を受け入れることを可能にし、
前記第二ストレージ・サーバで少なくとも１つの特定のブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記第二ストレージ・サーバが前記特定の期間中に前記第二ストレージ・サーバの前記プロビジョニングされた速度より低下した速度で作業要求を受け入れることを可能にする、
ように構成された１つ以上のコンピューティング・デバイス、
を備える、システム。
【請求項２】
前記クライアント側コンポーネントの少なくとも１部は、マルチテナント・コンピューティング・サービスのインスタンス・ホストで仮想化管理ソフトウェア・スタック内に実装される、請求項１に記載のシステム。
【請求項３】
前記第一ブロックレベル・ストレージ・デバイスの前記少なくとも１つのアドミッション制御パラメータを変更するために、前記１つ以上のコンピューティング・デバイスは、前記第一ブロックレベル・ストレージ・デバイスと関連した作業トークン・バケットのトークン補充速度を増加させるようにさらに構成される、請求項１または２に記載のシステム。
【請求項４】
前記第一ブロックレベル・ストレージ・デバイスの前記１部は、特定のクライアントのために確立されたマルチパーティション・ブロックレベル・ボリュームの第一パーティションを備え、前記第二ストレージ・サーバで前記特定のブロックレベル・ストレージ・デバイスの少なくとも１部は、前記マルチパーティション・ブロックレベル・ボリュームの第二パーティションを備える、請求項１−３のいずれか一項に記載のシステム。
【請求項５】
前記１つ以上のコンピューティング・デバイスは、
前記特定の期間後に、前記第一ブロックレベル・ストレージ・デバイスの特定のアドミッション制御パラメータをリセットし、前記第一ストレージ・サーバが前記第一のプロビジョニングされた速度を超えない作業要求を受け入れることを可能にする、
ようにさらに構成される、請求項１−４のいずれか一項に記載のシステム。
【請求項６】
前記特定のアドミッション制御パラメータをリセットするために、前記特定のアドミッション制御パラメータの値は、リセット期間にわたる減衰関数に従い第一設定から第二設定へ変更される、請求項５に記載のシステム。
【請求項７】
前記特定のアドミッション制御パラメータをリセットするために、前記特定のアドミッション制御パラメータの値は、ステップ関数に従い第一設定から第二設定へ変更される、請求項５に記載のシステム。
【請求項８】
１つ以上のコンピューティング・デバイスにより、
それぞれの作業負荷制限を実装するために、ストレージ・サービスで実装された複数のブロックレベル・ストレージ・デバイスについて１つ以上のアドミッション制御パラメータのそれぞれのセットを確立し、
複数のブロックレベル・ストレージ・デバイスの各々に対応するそれぞれのプロビジョニングされた速度を、前記マルチテナント・ストレージ・サービスの１つのクライアントの代わりに確立し、 
前記ストレージ・サービスのクライアント側コンポーネントにより、第一ストレージ・サーバで実装された第一ブロックレベル・ストレージ・デバイスの少なくとも１部を特定の期間中に対象とすることを期待された作業要求の特定の速度の推定値を生成し、前記作業要求の特定の速度が前記プロビジョニングされた速度のうちの第一速度を超え、
前記クライアント側コンポーネントにより、前記特定の期間中に対象とする作業要求の第二速度が特定のブロックレベル・ストレージ・デバイスと関連した第二速度未満であることを予測される前記特定のブロックレベル・ストレージ・デバイスの少なくとも１部を識別し、
前記第一ブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記第一ストレージ・サーバが前記第一速度を超える速度で前記第一ブロックレベル・ストレージ・デバイスを対象とする作業要求を受け入れることを可能にする、
前記特定のブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記特定のブロックレベル・ストレージ・デバイスに対応するストレージ・サーバが前記第二速度より低下した速度で作業要求を受け入れることを可能にする、
ことを実行する、ことを備える、方法。
【請求項９】
前記第一ストレージ・サーバは、前記ストレージ・サービスの複数のクライアントのブロックレベル・ストレージ・デバイスを実装するように構成される、請求項８に記載の方法。
【請求項１０】
前記１つ以上のコンピューティング・デバイスにより、
前記変更前に、前記第一ストレージ・サーバが前記第一速度を超える前記速度で作業要求を完了するために前記特定の期間中に十分な作業負荷容量を有することを検証する、
ことを実行することをさらに備える、請求項８または９に記載の方法。
【請求項１１】
前記クライアント側コンポーネントの少なくとも１部は、マルチテナント・コンピューティング・サービスのインスタンス・ホストで仮想化管理ソフトウェア・スタック内に実装される、請求項８−１０のいずれか一項に記載の方法。
【請求項１２】
前記第一ブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを前記変更することは、前記第一ブロックレベル・ストレージ・デバイスと関連した作業トークン・バケット内のトークン補充速度を増加させることを備える、請求項８−１１のいずれか一項に記載の方法。
【請求項１３】
前記第一ブロックレベル・ストレージ・デバイスの前記１部は、特定のクライアントのために確立されたマルチパーティション・ブロックレベル・ボリュームの第一パーティションを備え、前記特定のブロックレベル・ストレージ・デバイスの前記部分は、前記マルチパーティション・ブロックレベル・ボリュームの第二パーティションを備える、請求項８−１２のいずれか一項に記載の方法。
【請求項１４】
前記１つ以上のコンピューティング・デバイスにより、
前記特定の期間後に、前記第一ブロックレベル・ストレージ・デバイスの特定のアドミッション制御パラメータをリセットし、前記第一ストレージ・サーバが前記第一速度を超えない作業要求を受け入れることを可能にする、
ことを実行することをさらに備える、請求項８−１３のいずれか一項に記載の方法。
【請求項１５】
前記１つ以上のコンピューティング・デバイスにより、
第一インスタンス・ホストで第一コンピュート・インスタンス及び第二インスタンス・ホストで第二コンピュート・インスタンスを含む複数のコンピュート・インスタンスへ前記第一ブロックレベル・ストレージ・デバイスを接続し、前記クライアント側コンポーネントは、前記第一インスタンス・ホストでインスタンス化され、
前記第一インスタンス・ホストで前記クライアント側コンポーネントにより、前記第二インスタンス・ホストにおける第二クライアント側コンポーネントの作業負荷レベルの指標を取得し、前記少なくとも１つのアドミッション制御パラメータに行われる変更を決定し、
前記第二クライアント側コンポーネントの前記作業負荷レベルの前記指標は、前記第一インスタンス・ホストで前記第一ストレージ・サーバから前記クライアント側コンポーネントへ提供される、
ことを実行することをさらに備える、請求項８−１４のいずれか一項に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
いくつかの先導技術企業は、「サービスとしてのソフトウェア」を販売する技術を構築することに投資している。このようなサービスは、クライアントまたは加入者へコンピューティング及び／またはストレージ・リソース（たとえば、ブロックレベル・デバイス・インタフェースまたはウェブ・サービス・インタフェースのいずれか一方を提供するストレージ・デバイス）へのアクセスを提供する。マルチティア電子商取引システム内で、異なる種類のリソースの組み合わせを、加入者、及び／または彼らのアプリケーション、例えば、物理若しくは仮想マシン全体、ＣＰＵ、メモリ、ネットワーク帯域、またはＩ／Ｏ容量、に割り当て得る。ストレージ・サービスに実装されたブロックレベル・ストレージ・デバイスは、たとえば、別のサービスにより実装された１つ以上の物理または仮想マシンから、アクセス可能にされ得る。
【０００２】
クライアントへサービスを提供するすべてのシステムは、システムを潜在的に過負荷にする可能性があるサービス要求の過剰な負荷から、それ自体を保護する必要がある。一般に、システムは、それが受信するクライアント要求のある部分について期待されたサービス品質を提供不可能である場合に「過負荷」状態にあるとみなされる。過負荷のシステムが適用する一般的な解決策は、システムが過負荷状態から抜け出すまで、クライアントへのサービスを拒否すること、または特定の数の着信要求をスロットリングすることを備える。このような技術は、たとえば、ストレージ・デバイスごとのレベルで、いくつかの実施形態において、ストレージ・サーバで用いられ得る。
【０００３】
いくつかの現在のシステムは、要求速度を固定されたグローバル閾値と比較すること、及びこの閾値を超えるとクライアントへのサービスを選択的に拒否することで過負荷状況を回避する。しかしながら、さまざまな予測不可能な速度で異なる種類の要求を受信するシステムにおいて、意味のある（許容可能な性能を提供することはほとんどない）単一のグローバル閾値を定義することは、不可能ではないにしても、困難であるため、この要求を満たすために必要な仕事量は、少なくともいくつかの場合において、さまざまでもあり、予測不可能である。多くのサービスは、クライアント要求を経時的に均一に分散させるときに最適に動作するように設定されていてもよいが、実際には、作業分散においてこのような時間的な均一性に遭遇することは、めったにない。高水準の顧客満足度を達成して維持したいサービス・プロバイダは、より洗練された方式で時間的かつ空間的作業負荷の変動に対処する技術を実装する必要がある可能性がある。
【図面の簡単な説明】
【０００４】
【図１】少なくともいくつかの実施形態により、ブロックレベル・ストレージ・サービスを実装するシステムを例示する。
【図２】少なくともいくつかの実施形態により、操作をスケジューリングするために作業トークン・バケットを利用するアドミッション制御機構の態様を例示する。
【図３】少なくともいくつかの実施形態により、さまざまな種類のアドミッション制御ポリシーを実装するために使用され得る、トークン・バケットの例示的な構成プロパティを説明する。
【図４】少なくともいくつかの実施形態により、サービスのバックエンド・ストレージ・サーバ及びこのサービスのクライアント側コンポーネント間の例示的なアドミッション制御インタラクションを説明する。
【図５】少なくともいくつかの実施形態により、複数のパーティションを含む仮想ボリュームのために使用され得るアドミッション制御メタデータの実施例を例示する。
【図６】少なくともいくつかの実施形態により、複数のコンピュート・インスタンスへ接続可能であるブロックレベル・デバイスのためのアドミッション制御関連の操作の実施例を例示する。
【図７】少なくともいくつかの実施形態により、ブロックレベル・ストレージ・デバイスのためのアドミッション制御を実装するために実行され得る操作の態様を例示する流れ図である。
【図８】少なくともいくつかの実施形態により、ストレージ・サービスのクライアント側コンポーネント間の作業負荷関連のメッセージがサーバ側コンポーネントによりリダイレクトされ得るシステムを例示する。
【図９】少なくともいくつかの実施形態により、作業負荷関連のメッセージをリダイレクトするために使用され得る分散ポリシーの例示的なパラメータを例示する。
【図１０】少なくともいくつかの実施形態により、ストレージ・サービスのクライアント側及びサーバ・コンポーネントの両方による作業負荷関連のメッセージのリダイレクトの実施例を例示する。
【図１１】少なくともいくつかの実施形態により、ストレージ・サービスのクライアント側コンポーネントで維持され得る所属グループのデータベースの例示的な要素を例示する。
【図１２】少なくともいくつかの実施形態により、リダイレクトされたメッセージを使用してストレージ作業負荷管理を実装するために実行され得る操作の態様を例示する流れ図である。
【図１３】少なくともいくつかの実施形態で使用され得る例示的なコンピューティング・デバイスを説明するブロック図である。
【０００５】
いくつかの実施形態及び例示的な図面のための実施例として実施形態を本明細書で記載するが、当業者は、実施形態が記載されたこれらの実施形態または図面に限定されないことを認識するであろう。図面及びこれらへの詳細な説明が開示された特定の形態に実施形態を限定することを意図されないが、対照的に、この意図が添付の特許請求の範囲により定められるような趣旨及び範囲内に入るすべての修正形態、均等物及び代替物を網羅することであることを理解するべきである。本明細書で使用された表題は、構成上の目的のみのためであり、本明細書の範囲または特許請求の範囲を制限するために使用されることを意図されない。本出願を通して使用されるような、単語「ｍａｙ」は、強制的な意味（すなわち、しなければならないことを意味する）よりもむしろ、許容的な意味（すなわち、可能性があることを意味する）で使用される。同様に、単語「ｉｎｃｌｕｄｅ」、「ｉｎｃｌｕｄｉｎｇ」、及び「ｉｎｃｌｕｄｅｓ」は、含むことを意味するが、これに限定されない。
【発明を実施するための形態】
【０００６】
ネットワーク・アクセス可能なブロック・ストレージ・デバイスの協調アドミッション制御を伴う技術、及びリダイレクトされた作業負荷メッセージを伴う技術を含む、ストレージ・システムでの作業負荷管理のための方法及び装置のさまざまな実施形態を記載する。用語「アドミッション制御」及び「スロットリング」は、受信した作業要求（ストレージ・サービスを対象とする読み出しまたは書き込み要求のような）を、たとえば、延期または拒否することとは対照的に、実装のために受け入れる速度を制限するために実行された操作を表すために本明細書で同義的に使用され得る。アドミッション制御を実行する際に伴われる１セットのソフトウェア及び／またはハードウェア・エンティティは、「アドミッション制御装置」と集合的に称され得る。少なくともいくつかの実施形態において、アドミッション制御技術は、プロバイダ・ネットワーク環境内に実装されたストレージ・サービスの１つ以上のコンポーネントで使用され得る。分散された１セットのクライアントへインターネット及び／または他のネットワークを介してアクセス可能な１つ以上のネットワーク・アクセス可能なサービス（さまざまな種類のクラウド・ベースのデータベース、コンピューティングまたはストレージ・サービスのような）を提供するために、企業または公共部門の組織のようなエンティティによりセットアップされたネットワークは、本明細書でプロバイダ・ネットワークと称され得る。サービスのうちのいくつかは、より高水準のサービスを構築するために使用され得る。たとえば、コンピューティング、ストレージまたはデータベース・サービスは、コンテンツ配信サービスまたはストリーミング・データ処理サービスのためのブロックを構築する場合に使用され得る。
【０００７】
プロバイダ・ネットワークのサービスのうちの少なくともいくつかは、「インスタンス」と称されるサービス・ユニットでのクライアントの使用のためにパッケージ化されることができる。たとえば、仮想化されたコンピューティング・サービスによりインスタンス化された仮想マシンは、「コンピュート・インスタンス」を表すことができる。プロバイダ・ネットワークのこのようなコンピュート・インスタンスを実装するコンピューティング・デバイスは、本明細書において、「インスタンス・ホスト」、またはより単純に「ホスト」と本明細書で称され得る。所与のインスタンス・ホストは、いくつかのコンピュート・インスタンスを備えることができ、特定のインスタンス・ホストでコンピュート・インスタンスのコレクションは、１人以上のクライアントのアプリケーションを実装するために使用され得る。たとえば、ディスク・ベースのストレージ・ハードウェア及び関連したソフトウェアのあるコレクションを使用して、ネットワーク・アクセス可能なストレージ・サービスのボリューム（または１つ以上のボリュームの部分）のような論理ストレージ・デバイスを実装するコンピューティング・デバイスは、「ストレージ・サーバ」と本明細書で称され得る。所与のストレージ・サーバは、１人以上のクライアントのストレージ・デバイス（またはストレージ・デバイスの部分）をホストし得る。
【０００８】
いくつかの実施形態によれば、プロバイダ・ネットワークのブロック・ストレージ・サービスは、クライアントがＩ／Ｏのためのブロック・デバイス・プログラマティック・インタフェースを実装するマウント可能なブロックレベル・ボリュームのような、ブロック・ストレージ・デバイスを作成またはインスタンス化すること、及びコンピュート・インスタンスへ１つ以上のブロック・ストレージ・デバイスをプログラムで接続してこのインスタンスからネットワーク上のブロックレベルＩ／Ｏ操作（たとえば、ファイル・レベルＩ／Ｏ操作に対照的に）を支援すること、を可能にし得る。１つの実施形態において、たとえば、ブロック・ストレージ・サービスは、ブロック・ストレージ・サービス（１秒あたりのブロックＩ／Ｏ操作などの単位で表現された）により支援されるプロビジョニングされたスループット・レベルのようなさまざまな他のパラメータと同様に、ボリューム・サイズをクライアントが指定することを可能にする、「ＣｒｅａｔｅＶｏｌｕｍｅ」アプリケーション・プログラム・インタフェース（ＡＰＩ）を公開し得る。「ＡｔｔａｃｈＶｏｌｕｍｅ」ＡＰＩは、指定されたデバイス名で指定されたボリューム（またはボリュームのパーティション）を少なくとも１つの指定されたコンピュート・インスタンスへプログラムで接続するこのような実施形態において支援され得る。ブロック・ストレージ・サービスにより実装された所与のボリュームがコンピュート・インスタンスに接続された後に、いくつかの実施形態において、コンピュート・インスタンスは、それがたとえば、ファイル・システムでボリュームをフォーマットする及び／またはボリューム上にアプリケーションをインストールする、ローカル・ドライブとインタラクトすることと同じように、ボリュームとインタラクトし得る。このようにして、ブロック・ストレージ・サービスにより提供されたボリュームは、コンピュート・インスタンスの観点から生のフォーマットされていない外付けハード・ドライブと同様に動作し得る。
【０００９】
いくつかの実施形態において、１つ以上のプロバイダ・ネットワーク・サービスは、サービス・クライアントとインタラクトするフロントエンド・レイヤ、及びサービス・クライアントの代わりにフロントエンド・レイヤがアクセスするリソースを含むバックエンド・レイヤを備える階層化アーキテクチャを使用して実装され得る。このような、階層化アプローチは、たとえば、クライアント・データのための所望のレベルのセキュリティまたは隔離を実装するため、バックエンドでの実装の柔軟性を支援するため、及びその他のためのさまざまな理由のために使用され得る。たとえば、ブロック・ストレージ・サービスは、ディスクのような物理ストレージ・デバイスを含む複数のストレージ・サーバを備えるバックエンド・レイヤ、及びブロック・ストレージを利用するクライアント・アプリケーション上にコンピュート・インスタンスを実装する同じインスタンス・ホスト上で実行するフロントエンド・レイヤを備え得る。たとえば、仮想化管理ソフトウェア・スタック（管理用オペレーティング・システム・インスタンスまたはハイパーバイザの１つ以上のモジュールのような）のコンポーネントを含み得る、フロントエンド・レイヤは、アプリケーションの読み出し及び書き込み要求をインターセプトし、読み出されるまたは書き込まれるデータを永続的に格納するストレージ・サーバへ対応する物理的な入力／出力（Ｉ／Ｏ）要求を発行し得る。またバックエンドでのストレージ・サーバは、ストレージ・サービスの「サーバ側」コンポーネント（またはサーバ・コンポーネント）と本明細書で称され得る、フロントエンド・コンポーネントは、「クライアント側」コンポーネント（またはクライアント・コンポーネント）と本明細書で称され得る。いくつかの実施形態において、少なくとも２種類の通信チャネルは、フロントエンド・レイヤ及びバックエンド・レイヤ、「データ・プレーン」通信チャネル及び「制御プレーン」通信チャネル間に確立され得る。データ・プレーン・チャネルは、フロントエンド・レイヤからバックエンド・レイヤへストレージ要求を提出し、このような要求への応答を受信することを主に対象とし得る。制御プレーン通信チャネルは、たとえば、リカバリ関連の操作、作業負荷を変更することに応答する動的な再構成、及びその他のものを有する、管理用または構成関連の操作を主に対象とし得る。セキュリティ及び他の理由のため、データ・プレーン及び制御プレーン・チャネルは、それぞれのセットのネットワーク・リンク及びデバイスを使用する、及び／または独立して構成された仮想ネットワークを使用する少なくともいくつかの実施形態に実装され得る。データ・プレーン通信チャネルは、たとえば、第一ストレージ要求をフロントエンドのクライアント側コンポーネントからバックエンドでのストレージ・サーバへ送信する前に、確立されなければならない可能性がある。少なくともいくつかの実施形態において、以下で説明されるように、既存のデータ・プレーン通信チャネルは、フロントエンド・コンポーネント・セット中の、またはバックエンド・コンポーネント・セット中のリダイレクトされた作業負荷関連の情報のために使用され得（たとえば、ピギーバック技術を使用して）、つぎにリダイレクトされた作業負荷関連の情報を使用して、サービス要求をスケジューリングする、またはこれをリスケジューリングし得る。
【００１０】
先に述べたように、いくつかの実施形態において、クライアントは、たとえば、ブロック・ストレージ・デバイスを作成するときに、クライアントのブロック・ストレージ・デバイスまたはボリュームのためのさまざまな性能関連の選好または要件を示し得る。クライアントは、たとえば、所望のサイズのボリューム、またはボリュームが支援するように構成される秒あたりのＩ／Ｏ操作数（ＩＯＰＳ）を示し得る。いくつかの実装において、ブロック・ストレージ・サービスは、クライアントが示したボリューム・サイズに基づき、支援される最大ＩＯＰＳレベルを決定し得る。少なくともいくつかの実施形態により、ブロック・ストレージ・サービスは、プロビジョニングされた作業負荷モデルを支援できる。プロビジョニングされた作業負荷モデルにおいて、作業要求が対象とし得る（ボリュームまたはボリュームのパーティションのような）所与のオブジェクトは、それが作業要求のための許容可能な応答時間に関する作業要求の特定速度（「プロビジョニングされたスループット容量」）まで通常支援可能であるような方式でセットアップまたは設定され得る。用語「スループット容量」は、所与の速度で作業要求（ストレージ・リソースの場合の読み出しまたは書き込みのような）を完了するリソース能力を表すために本明細書で使用される。スループット容量は、ストレージ・リソースの場合に論理的または物理的なＩＯＰＳのような、秒あたりの作業操作で表現され得る。プロビジョニングされた作業負荷モデルを支援するために、利用可能なスループット容量を以下で説明されるようなトークン・バケット内の作業トークンの可用性によりモデル化する技術のような、さまざまな種類のアドミッション制御技術のうちのいずれかを使用し得る。少なくともいくつかの実施形態において、作業トークンを利用しない他のアドミッション制御技術を使用し得る。
【００１１】
少なくともいくつかの実施形態において、プロビジョニングされない作業負荷モデルは、また、または代わりにストレージ・サービスで支援され得る。たとえば、１つのボリュームＶ１は、プロビジョニングされたＩＯＰＳ設定Ｐ１を有することができ、同じストレージ・サービスの別のボリュームＶ２は、プロビジョニングされたＩＯＰＳ設定を有し得ない。このような実施形態において、サービスは、プロビジョニングされたＩＯＰＳ速度Ｐ１を満たすのに十分であると推定されるＶ１のためのリソースを予約または延期しようとし得、必ずしも所定のＩＯＰＳ目標を達成しようとすることなくＶ２のためのベストエフォート型スケジューリングを単に実装し得る。１つの実施形態において、クライアントは、たとえば、実質的な１セットのリソースをプロビジョニングされたボリュームのために事前に割り当て得るので、プロビジョニングされないボリュームのための速度とは異なるプロビジョニングされたボリュームのための速度で予定され得る。予定速度は、プロビジョニングされないボリュームよりもプロビジョニングされたボリュームの方が高くあり得る。本明細書に記載された作業負荷管理技術は、少なくともいくつかの実施形態において作業負荷モデル（プロビジョニングされた、またはプロビジョニングされない）のいずれかの種類に適用され得る。
【００１２】
ストレージ・サービスでの使用の際にプロビジョニングされた作業負荷モデルに従い、上記で示されるように、十分なリソースは、各ブロック・ストレージ・デバイスのために割り当てられ、対応するスループット・レベルを支援し得る。たとえば、ブロック・ストレージ・ボリュームＶ１及びＶ２が接続されるコンピュート・インスタンスＣＩ１を含むクライアントＣ１を検討する。クライアントがボリュームＶ１のためにＰ１のプロビジョニングされたＩＯＰＳレベル（ＰＩＯＰＳ）、及びボリュームＶ２のためにＰ２のＰＩＯＰＳを要求する（たとえば、ボリューム作成時に）場合に、ストレージ・サービスは、所望のＩ／Ｏ速度を支援可能な物理的なストレージ・デバイス（及びネットワーク・デバイス）を含むバックエンド・ストレージ・サーバ、及び所望のＩ／Ｏ速度のために処理する要求を取り扱い可能なＣＰＵを識別し得る。典型的にバックエンド・サーバでのアドミッション制御機構は、いくつかの実装においてボリュームためのＰＩＯＰＳ制限を実施し得る。たとえば、Ｖ１について、秒あたりのＰ１トークンの補充速度を有するトークン・バケットを確立し得ることから、１つのＩ／Ｏ要求を受け入れるごとに１トークンを消費する。同様に、秒あたりＰ２トークンの補充速度を有するトークン・バケットは、Ｖ２のために確立され得ることから、１つのＩ／Ｏ要求を受け入れるごとに１トークンを消費する。Ｉ／Ｏ要求をバックエンド・ストレージ・サーバで受信するが、トークンが残っていない場合に、この要求をキューに入れる、または拒否し得る。いくつかの実装において、異なるカテゴリの作業要求のためのアドミッション制御を独立して取り扱うことができ、たとえば、書き込むためよりも読み出すために異なるトークン・バケットをセットアップし得る。
【００１３】
Ｖ１及びＶ２を設定するアプリケーションの種類に応じて、Ｖ１及びＶ２に向けられたＩ／Ｏ作業負荷での変形形態は、依然として経時的に発生する可能性があり、所望のものより高速なＩ／Ｏ応答時間（またはより高速なＩ／Ｏ拒否速度）へつながる可能性がある。Ｉ／Ｏ操作が１秒のような所与の時間間隔中にＰ１より高速度でＶ１を対象とする場合に、たとえば、アドミッション制御装置は、操作のうちのいくつかを延期または拒否しなければならない可能性がある。いくつかの状況において、少なくともいくつかの時間間隔について、２つのボリュームの組み合わされたＩＯＰＳは、それらが組み合わされプロビジョニングされた速度を下回っている可能性があるが、ボリュームのうちの１つのための要求速度は、そのボリュームについてプロビジョニングされた制限を超える可能性がある。たとえば、Ｐ１及びＰ２が両方とも１０００ＩＯＰＳである場合に、このためそれらの組み合わされたＰＩＯＰＳは２０００であり、所与の１秒間に、Ｖ１についてのＩ／Ｏ要求の速度は、１２００（そのプロビジョニングされたレベルを超える）であることができ、Ｖ２を対象とするＩ／Ｏ要求の速度は、５００（そのプロビジョニングされたレベルを下回る）であり得る。少なくともいくつかの実施形態において、ストレージ・サービス（たとえば、アプリケーションを実行するインスタンス・ホストで）のクライアント側コンポーネントでの読み出し及び書き込み要求パターンを解析すること、ならびに高精度でＩ／Ｏ要求速度での変形形態を予測することは可能であり得る。このような実施形態において、クライアント側コンポーネントは、バックエンド・ストレージ・サーバと協調して、以下で説明されるように少なくとも一時的にボリュームのための作業要求を受け入れるために使用されるアドミッション制御パラメータを変更し得るため、プロビジョニングされたＩＯＰＳレベルを超える要求速度は、十分なリソースが利用可能である場合に、１つ以上のボリュームのためのいくつかの期間に支援され得る。上記の実施例において、アドミッション制御のためにトークン・バケットを使用している実施形態において、クライアント側コンポーネントは、Ｖ１のためのストレージ・サーバが１２５０ＩＯＰＳを取り扱うことが可能である場合に、Ｖ１のバケットの補充速度（たとえば、１２００ＩＯＰＳを比較的容易に取り扱うことが可能であるように、秒あたり１２５０トークンへ、）を一時的に増加させ、Ｖ２のバケットの補充速度（たとえば、秒あたり７５０トークンへ）を低下させ得る。あるいは、補充速度を調整する代わりに、ある数のトークンは、Ｖ２のバケットから「借用」または転送され、Ｖ１のバケットにデポジットされ得る。この方式で、十分なリソースが利用可能である限り、さまざまな種類の一時的な補正のアドミッション制御パラメータ調整を行い、ストレージ・サービスの全体的な応答性を強化し得る。容量を借用するボリュームまたはデバイスは、「貸し手」または「ドナー」・ボリュームまたはデバイスと称され得、一方、プロビジョニングされた作業負荷より高い作業負荷を予想されるものは、「借り手」または「レシピエント」・ボリュームまたはデバイスと称され得る。いくつかの実施形態において、いくつかの異なる貸し手ボリュームＶ２、Ｖ３、．．．（各々がプロビジョニングされた作業負荷レベル未満の作業負荷レベルを有することを予想される）から容量を借用してＶ１の増大した需要に対処することは可能であり得る。１つの実施形態において、Ｖ１の増大した需要が部分的にのみ満たされることが可能である（たとえば、Ｖ１の予想された作業負荷及びプロビジョニングされた速度間の差が２００ＩＯＰＳである場合に、１００ＩＯＰＳのみがＶ２、Ｖ３、．．．などから集合的に借用されることが可能である）場合でさえ、依然として容量は、１つ以上の貸し手ボリュームから借用され、Ｖ１の作業負荷の管理を支援し得る。プレゼンテーションを簡素化するために、以下の説明の多くは、単一の貸し手ボリューム、単一の借り手ボリューム、及び借り手ボリュームでの余分な需要の完全な履行を伴う状況に焦点を当てるが、さまざまな実施形態において、複数の貸し手、複数の借り手、及び／または部分的な履行を同様に支援し得る。
【００１４】
少なくともいくつかの実施形態において、それぞれのセットのアドミッション制御パラメータ（たとえば、トークン・バケット補充速度）は、マルチテナント・ストレージ・サービスに実装された複数のブロックレベル・ストレージ・デバイスの各々のためにプロビジョニングされた作業負荷のそれぞれの速度を実現するために確立され得る。サービスのクライアント側コンポーネントは、第一ストレージ・サーバに実装された第一ブロックレベル・ストレージ・デバイスの少なくとも１部をある期間中に対象とすることを期待された作業要求の速度の推定値を生成し得る。第一デバイスへの作業要求の期待された速度が第一デバイスのプロビジョニングされた作業負荷を超える場合に、クライアント側コンポーネントは、この期間中に期待された作業負荷がプロビジョニングされた作業負荷を下回る、第二ブロックレベル・ストレージ・デバイス（たとえば、別のストレージ・サーバでまたは同じストレージ・サーバで）を識別しようとし得る。このような第二デバイスを探し出すことが可能である場合に、少なくともいくつかの実施形態において、クライアント側コンポーネントは、第一ストレージ・サーバが第一デバイスの余分な作業負荷を受け入れるのに十分な容量を有するかどうかを確認し得る（たとえば、第一ストレージ・サーバと通信することで）。ストレージ・サーバが多くの場合においてマルチテナント（すなわち、ブロック・ストレージ・デバイスがいくつかの異なるクライアントまたはインスタンスの代わりに所与のサーバ上に実装されることができ、各ブロック・デバイスがそれぞれのＰＩＯＰＳ速度を支援する必要がある可能性がある）であってもよいため、ストレージ・サーバは、ＰＩＯＰＳレベルを超える過剰な負荷を常に取り扱うことができない可能性がある。ストレージ・サーバが増大した負荷のうちの少なくともいくつかを取り扱うことが可能である場合に、クライアント側コンポーネントは、少なくとも関心の期間中に第一及び第二デバイスに適用されるアドミッション制御パラメータの変更を開始し得る。したがって、プロビジョニングされたレベルより高い作業負荷は、第一デバイスのために受け入れられることが可能であり、第二デバイスは、そのプロビジョニングされたレベルより低い作業要求の速度に制限される。（１つの実施形態において、いくつかの状況下で、たとえば、第二デバイスで期待された作業負荷レベルが第二デバイスのためにプロビジョニングされたレベルを実質的に下回る場合に、第一デバイスに関連するパラメータのみを変更し得る。）この期間の終了後に、アドミッション制御設定は、いくつかの実施形態において、リセットされそれらの元の値に戻り得る。いくつかの実施形態において、アドミッション制御設定は、たとえば、減衰関数に従い、あるリセット時間間隔にわたり徐々にリセットされることができ、他の実施形態において、ステップ関数は、瞬時にまたはほぼ瞬時にアドミッション制御設定の値を変更するために使用され得る。
【００１５】
多くの場合において、借り手及び貸し手デバイスは、同じクライアント・アカウント若しくはリンクするクライアント・アカウントにより所有される、若しくはこれらに割り当てられ得る、またはその他の方法で論理的に関連付けられ得る（たとえば、それらが関連したアプリケーションのために使用されている場合に）。このようにして、少なくともいくつかの実施形態において、一方のデバイスの「借り手」容量へ、プロビジョニングされたものより高速な他方での作業負荷を支援するかどうかを判定するときに、ストレージ・サービスのクライアント側コンポーネントは、クライアント・アカウント情報、またはこれらのデバイスを使用しているアプリケーションの種類についての情報のような、メタデータを使用し得る。
【００１６】
また同様の技術は伴われたデバイスのうちの少なくとも１つがプロビジョニングされたＩＯＰＳ設定を有さない実施形態で使用されることができ、代わりにたとえば、内部作業負荷速度目標は各々のデバイスと関連することができ（たとえば、計測された作業負荷動向に基づき）、容量は他方よりあまりビジーではないことが予想されるデバイスから借りられ、この２つのうちのよりビジーな方へ貸し出され得る。先に述べたように、ブロック・デバイスを使用しているアプリケーションがコンピューティング・サービスのインスタンス・ホストにコンピュート・インスタンス上で実行されるいくつかの実施形態において、クライアント側コンポーネントは、インスタンス・ホストで仮想化管理ソフトウェア・スタックの部分であってもよい。少なくとも１つの実施形態において、クライアント側コンポーネントは、インスタンス・ホスト以外のデバイス、たとえば、フロントエンド・インスタンス・ホスト及びバックエンド・ストレージ・サーバ間のストレージ・サービスの仲介ノードで実行され得る。
【００１７】
いくつかの実施形態において、ボリュームのようなブロック・ストレージ・デバイスは、１つより多いバックエンド・ストレージ・デバイスまたは１つより多いバックエンド・ストレージ・サーバにわたりパーティション化される、または分散され得る。このようなパーティション化は、たとえば、単一のストレージ・サーバまたは単一のストレージ・デバイスで簡単に収容されることが不可能な非常に大きなボリューム及び／または非常に高いスループット・レベルを支援するために、実装され得る。２０テラバイト・ボリュームは、  １つの例示的な状況において５つの４テラバイト・パーティションに分割され得、これらの各々は、それぞれのストレージ・サーバで１セットのディスクを使用して格納され得る。パーティション化されたボリュームを支援するいくつかの実施形態において、パーティション化の詳細、またはいくつかのパーティション間でボリュームを分散させる事実でさえ、必ずしもボリュームを要求したクライアントへ明らかにされない可能性がある。クライアントの観点から、単一のプロビジョニングされた作業負荷レベルを有する単一のボリュームを構成することは明らかであり得る。ストレージ・サービスのフロントエンド及びバックエンド・コンポーネントは、たとえば、どのぐらいの数のパーティションを設定する必要があるか、及びストレージ・サーバ／デバイスのどちらにパーティションを格納する必要があるかを判定することにより、パーティション化を実装し得る。大きな「仮想」ボリュームのプロビジョニングされたスループット容量をパーティション間に分散させ得る。たとえば、２０テラバイト・ボリュームが内部で１００００ＩＯＰＳのためにプロビジョニングされている（クライアントの観点から）場合に、５つの４テラバイト・ボリュームの各々は、２０００ＰＩＯＰＳのために構成され得る。アドミッション制御は、いくつかのこのような実施形態においてパーティション・レベルで、たとえば、ボリューム・レベルで、加えてまたはこれの代わりに、実行され得る。個別のトークン・バケットは、いくつかの実装において各々のパーティションのために用いられ得る。このような例示的な状況において、パーティションのうちの１つ以上についての作業負荷は、ある期間中に２０００ＩＯＰＳレベルを超えて上昇することを予想され、１つ以上の他のパーティションについての作業負荷は、２０００レベルを下回ることを予想される場合に、ストレージ・サービスのクライアント側コンポーネントは、異なるパーティションのＰＩＯＰＳレベルを調整し得る。予想された作業負荷レベルを支援するために、たとえば、よりビジーであることを予想されるパーティションのトークン補充速度は、増加し得、あまり頻繁に使用されないことを予想されるパーティションのトークン補充速度は、低下し得る。このようにして、スループット容量のパーティション・レベルの「借用」及び「貸与」は、このような実施形態において実行され得るが、また同様のアドミッション制御パラメータ調整は、ボリューム・レベルで実装され得る。
【００１８】
ボリュームのようなブロックレベル・ストレージ・デバイスは、たとえば、先に述べた「ＡｔｔａｃｈＶｏｌｕｍｅ」ＡＰＩの均等物を使用して、１つの実施形態で単一のコンピュート・インスタンスによりのみ接続可能であり得る。他の実施形態において、単一のブロックレベル・デバイスまたはパーティションは、複数のコンピュート・インスタンスから接続され得、異なるインスタンス・ホストで潜在的にインスタンス化され得る。一般に、さまざまな実施形態において、所与のストレージ・サーバまたはストレージ・デバイスがＭ個の異なるクライアント側コンポーネントからアクセスされ得、逆に、ストレージ・サービスの所与のクライアント側コンポーネントは、Ｎ個の異なるストレージ・サーバにアクセス可能であり得る。
【００１９】
さまざまな実施形態においてクライアント側コンポーネントからのストレージ要求を受信しこれらに応答するために、上述したように、データ・プレーン通信チャネルは、ストレージ・サービスのクライアント側コンポーネント及びバックエンド・ストレージ・サーバ間に確立され得る。少なくともいくつかの実施形態において、ストレージ要求をスケジューリングする際に役立ち得る作業負荷関連の情報は、たとえば、既存のデータ・プレーン通信チャネル経由で、バックエンド・サーバを介してメッセージ・リダイレクトを使用して協動するクライアント側コンポーネント間で交換され得る。他の協動するクライアント側コンポーネントから受信した作業負荷情報（たとえば、いかなる場合にも送信されているデータ・プレーン・メッセージ上にピギーバックされた）は、所与のクライアント側コンポーネントで非常に低いオーバーヘッドで収集され、つぎにローカルに決定をスケジューリング（またはリスケジューリング）するストレージ要求を改善するために使用され得る。たとえば、ストレージ・サービスの単一のエンド・ユーザの顧客（または１セットの論理的に関連した顧客）の代わりにインスタンス化された１グループのクライアント側コンポーネントは、他のものにわたるこのグループのストレージ操作のいくつかの種類に優先順位を設定しようとする、またはグループのメンバー間のストレージ・リソース使用状況に関してあるレベルの公平性を課そうとするような、作業負荷管理タスクで協動するためにリダイレクト・メッセージを使用することを一括して決定し得る。このような１グループの協調または協動するクライアント側コンポーネントは、本明細書でクライアント側「所属グループ」と称され得る。いくつかの実施形態において、また、または代わりに１グループの協調するバックエンド・サーバ・コンポーネントは、作業負荷情報を交換するためにリダイレクト・メッセージを使用し、それら自体のバックエンド・アドミッション制御決定の質を高めるためにこのような情報を使用し得る。
【００２０】
このようなリダイレクト技術を使用する１つの実施形態によれば、マルチテナント・ネットワーク・アクセス可能なストレージ・サービスの第一クライアント側コンポーネントＣ１は、その（すなわち、Ｃ１の）ストレージ作業負荷のメトリックＭ１を決定し得る。このようなメトリックは、たとえば、ストレージ要求をＣ１から１つ以上のストレージ・サーバの方向へ向けた速度を、特定の時間間隔中に、計測することで取得され得る。つぎにＣ１は、既存のデータ・プレーン通信チャネルを介してサービス・バックエンドの特定のストレージ・サーバＳ１へメトリックＭ１を送信し得る。サーバＳ１は、作業負荷メトリック分散ポリシーのさまざまなパラメータに基づき、メトリックＭ１を向ける必要がある、１つ以上の異なるクライアント側コンポーネントＣ２、Ｃ３、．．．、を識別し得る。少なくともいくつかの実施形態において、サーバＳ１は、たとえば、クライアント側コンポーネントからの制御プレーン・メッセージの形式で、または他のデータ・プレーン・メッセージの形式で、またはＭ１をＣ１により送信する同じデータ・プレーン・メッセージで、作業負荷関連の情報を分散させる必要がある所属グループの協動するクライアント側コンポーネントのセットについてガイダンスを受信し得る。
【００２１】
ストレージ・サーバＳ１は、たとえば、Ｓ１及びＣ２間で事前に作成された異なる既存のデータ・プレーン通信チャネルを使用して、選択された第二クライアント側コンポーネントＣ２へメトリックＭ１を送信し得る。Ｃ２で、Ｍ１（同様のリダイレクト・メッセージを介して他のクライアント側コンポーネントから収集された他のメトリック、及びＣ２自体のメトリックと同様に）は、Ｃ２のその後の作業負荷に調整を行うために使用され得る。たとえば、Ｃ２が協動したい他のクライアント側コンポーネントにおける作業負荷条件のその状況に基づき、Ｃ２は、１つ以上のストレージ要求（Ｓ１または他のサーバへ）の提出をリスケジュールするまたは遅延させ得る。またＳ１は、分散ポリシーに基づき他のクライアント側コンポーネントにＭ１を送信し得る。同様に、Ｃ２は、既存のデータ・プレーン通信チャネルを使用していくつかのサーバへそれ自体のメトリックＭ２を送信することができ、Ｍ２は、Ｃ１の他のクライアント側コンポーネント及びＣ２の所属グループにリダイレクト経由で配信され得る。ある期間（たとえば分散ポリシーにより決定された）にわたり、Ｃ１の異なるメンバー及びＣ２の所属グループは、互いから比較的最近の作業負荷情報をすべて取得し得るため、より多くの情報の作業負荷スケジューリング決定を行う位置にあってもよい。
【００２２】
グループの作業負荷スケジューリング決定を、少なくともグループ全体の視点から、改良するためにリダイレクトを介して所属グループのメンバー間の作業負荷データを共有するこのような技術が、使用されるアドミッション制御技術にかかわらず用いられ得ることに留意する。たとえば、いくつかの実施形態において、ストレージ・サービスが先に述べられた方式でプロビジョニングされたＩＯＰＳを実装するかどうかにかかわらず、作業負荷情報はリダイレクトを介して共有され、スケジューリング目的の要求のために使用され得る。いくつかの実施形態において、ストレージ・サーバ間でＩ／Ｏ容量ユニットを論理的に転送する、またはアドミッション制御パラメータを一時的に変更するクライアント側コンポーネントについて先に述べられた技術は、  リダイレクト技術と組み合わされ得る。たとえば、クライアント側コンポーネントは、サーバ作業負荷レベルの予想に基づきストレージ・サーバのためのアドミッション制御設定を依然として調整することができ得、同時に他の協動するクライアント側コンポーネントから取得された作業負荷情報を使用して、それ自体の提出されたサービス要求のスケジューリングを変更する。いくつかの実施形態において、リダイレクト技術を使用する代わりに、またはこのことに加えて、異なるインスタンス・ホストに設置されたストレージ・サービスのクライアント側コンポーネントは、たとえば、予想された作業負荷レベルまたは他のメタデータを共有して、互いに直接に通信し得る。１つの実施形態において、また、または代わりにバックエンド・ストレージ・サーバは、アドミッション制御パラメータ変更のためにそれら自体の間で直接に作業負荷情報を共有し得る。少なくとも１つの実施形態において、ストレージ・サーバは、作業負荷メトリックをクライアント側コンポーネントで使用して、協動してクライアント作業負荷を変更する場合でさえ、アドミッション制御パラメータを利用して作業負荷をスロットリングし続け得る。このようにして、いくつかの実施形態において、ストレージ・サーバで行われたアドミッション制御決定は、実際には、クライアント側コンポーネントにより作業負荷リスケジューリング試行をオーバーライドするために使用され得る。
【００２３】
ストレージ・サーバが受信した作業負荷情報をリダイレクトするように設定される実施形態において、複数の異なるパラメータを備えるメトリック分散ポリシーは、リダイレクト・プロセスを導くために使用され得る。このようなパラメータは、たとえば、（ａ）他のクライアント側コンポーネントへのメトリック伝播のタイミング、（ｂ）メトリックを送信するクライアント側コンポーネントを選択するために使用される基準、及び／または（ｃ）メトリックをリダイレクトするクライアント側コンポーネント数、を管理し得る。いくつかの実施形態において、たとえば、多くの「ゴシップ」ベースのプロトコルで情報伝播のために使用されたものと同様の方式で、所属グループのメンバーの中から無作為選択を使用して、メトリックの宛先を選択し得る。少なくともいくつかの実施形態において、このポリシーは、たとえば、メトリックが要求されたデータ・ブロックまたは要求を書き込む応答を含むネットワーク・メッセージ上にピギーバックされるかどうか若しくはこのような条件下で、またはメトリックがデータ・ストレージ・ペイロード若しくは応答を含まないメッセージに送信されるかどうかの、選択された宛先にメトリックを送信するために使用される機構を示すことができる。１つの実施形態において、たとえば、クライアント側コンポーネントからのメトリックの最初の送信、及びメトリックの再送信の両方は、通常のデータ・プレーン・トラフィックのために生成されるネットワーク・メッセージ上にメトリックをピギーバックすることを伴い得る。
【００２４】
少なくともいくつかの実施形態において、クライアント側コンポーネントの所属グループの異なるメンバーは、あるアプリケーションまたはアプリケーション・セットのコンテキストで異なる役割を有し得る。結果として、あるコンポーネントＣ１からのストレージ要求は、別のコンポーネントＣ２のストレージ要求より高い重要性を有すると判断され得る。たとえば、Ｃ１は、アプリケーション・ノード・クラスタのプライマリまたはマスタ・コンポーネントの代わりにストレージ要求を提出していて良いのと同時に、Ｃ１は、このクラスタのワーカ・ノードの代わりにストレージ要求を提出していて良い。このような状況において、相対的な重みまたは優先順位は、異なるグループのメンバーの要求と関連することができ、重み情報は、グループ・メンバー間で伝播され得るため、要求スケジューリング決定は、ビュー内の異なるコンポーネントの相対的な重要性で行われることが可能である。
【００２５】
例示的なシステム環境
図１は、少なくともいくつかの実施形態により、ブロックレベル・ストレージ・サービスを実装するシステムを説明する。示されるように、複数の異なるブロック・ストレージ・デバイス１２０（ボリューム全体またはボリュームのパーティションのような）は、描写された実施形態において、さまざまなコンピュート・インスタンス１４０で実行するアプリケーションにより発行された読み出し及び書き込み要求を支援するように、さまざまなバックエンド・ストレージ・サーバ１１０で構成され得る。たとえば、ブロック・ストレージ・デバイス１２０Ａ及び１２０Ｂをストレージ・サーバ１１０Ａに設置しながら、ブロック・ストレージ・デバイス１２０Ｃ及び１２０Ｄをストレージ・サーバ１１０Ｂに設置する。コンピュート・インスタンス１４０Ａ及び１４０Ｂをインスタンス・ホスト１４５Ａに実装しながら、コンピュート・インスタンス１４０Ｃ及び１４０Ｄをインスタンス・ホスト１４５Ｂで実行する。
【００２６】
コンピュート・インスタンス１４０で実行中のアプリケーションは、ブロック・ストレージ・デバイス１２０を使用して実装されるストレージ・オブジェクト（ファイルまたはファイル・システムのような）のための読み出し及び／または書き込み要求１２２（またクライアント読み出し／書き込み要求と本明細書で称される）を発行する。所与のインスタンス・ホスト１４５でのアプリケーション読み出し／書き込み要求１２２は、インスタンス・ホストでストレージ・サービスのローカルなクライアント側コンポーネント１５０で捕捉またはインターセプトされることができる。クライアント側コンポーネント１５０は、ストレージ・サーバへ対応するバックエンドＩ／Ｏ要求１２３を発行し得る。このようにして、クライアント側コンポーネントは、コンピュート・インスタンス、及びこのような実施形態においてコンピュート・インスタンスに論理的に接続されるストレージ・デバイス間の仲介とみなされ得る。バックエンドＩ／Ｏ要求は、クライアント読み出し／書き込み要求の変換に類似するとみなされ得る。たとえば、コンピュート・インスタンス１４０Ａ及び１４０Ｂからのクライアント読み出し／書き込み要求１２２Ａは、インスタンス・ホスト１４５Ａでクライアント側ストレージ・サービス・コンポーネント１５０ＡによりバックエンドＩ／Ｏ要求１２３Ａ及び１２３Ｂへ変換される。同様に、インスタンス・ホスト１４５Ｂでコンピュート・インスタンス１４０Ｃからのクライアント読み出し／書き込み要求１２２Ｃ及び１２２Ｄは、それぞれローカルのクライアント側コンポーネント１５０Ｂ及び１５０Ｃにより取り扱われる。
【００２７】
いくつかの実装において少なくとも、所与のクライアント読み出しまたは書き込み要求１２２が必ずしも対応するバックエンドＩ／Ｏ要求１２３をもたらさない可能性があり、代わりに、このような実装において、いくつかのクライアント読み出し／書き込み要求が他のものと統合される、またはクライアント側コンポーネント１５０によりさらに小さい要求に分割され得るため、バックエンドＩ／Ｏ要求数がクライアント読み出し／書き込み要求に正確にマッチングしない可能性があることに留意する。クライアント側コンポーネントは、いくつかの実施形態において読み出し／書き込み要求を結合及び／または分割することに関与し得、またキャッシングまたは他の操作を実行し得る。クライアント側コンポーネント１５０は、いくつかの実装において、実行の１つ以上のプロセスまたはスレッドを各々備え得る。いくつかの実施形態において、単一のクライアント側コンポーネント１５０は、所与のインスタンス・ホスト１４５でインスタンス化され得る。このようなモノリシックのクライアント側コンポーネント１５０は、いくつかの異なるコンピュート・インスタンスのための、及び／またはインスタンスに接続された、いくつかの異なるブロック・ストレージ・デバイスのための読み出し及び書き込み要求を取り扱うことに関与し得る。他の実施形態において、別個のクライアント側コンポーネント１５０は、所与のコンピュート・インスタンスのための、または所与の接続されたブロック・ストレージ・デバイスのためのブロック・ストレージ要求を取り扱うことに関与し得る。描写された実施形態において、クライアント側コンポーネント１５０は、それらのインスタンス・ホスト１４５で仮想化管理ソフトウェア・スタック１７０（たとえば、クライアント・アプリケーションよりも管理用操作に専用の特別なオペレーティング・システム・インスタンスで、またはハイパーバイザで）内に組み込まれる。たとえば、クライアント側コンポーネント１５０Ａは、インスタンス・ホスト１４５Ａで仮想化管理ソフトウェア・スタック（ＶＭＳＳ）１７０Ａのサブコンポーネントでありながら、クライアント側コンポーネント１５０Ｂ及び１５０Ｃは、インスタンス・ホスト１４５Ｂで仮想化管理ソフトウェア・スタック１７０Ｂの部分である。他の実施形態において、ブロック・ストレージ・サービスのクライアント側コンポーネントは、仮想化管理ソフトウェア・スタックに実装されない可能性があり、代わりにたとえば、それらは、コンピュート・インスタンス１４０に、またはいくつかの場合において、仮想化管理ソフトウェア・スタックからの書き込み要求を受け入れストレージ・サーバに、この要求をリダイレクトするルーチング仲介に、実装され得る。
【００２８】
図１で示された実施形態において、各ブロック・ストレージ・デバイス１２０は、たとえば、上記で説明された種類のプロビジョニングされた作業負荷モデルに従い、ストレージ・サーバにより使用され、着信するバックエンドＩ／Ｏ要求１２３を、許容、遅延または拒否するかどうかを判定する、対応する１セットのサーバ側アドミッション制御パラメータ（ＡＣＰ）１３０を有する。このようにして、サーバ側アドミッション制御パラメータ１３０Ａ、１３０Ｂ、１３０Ｃ及び１３０Ｄは、それぞれブロック・ストレージ・デバイス１２０Ａ、１２０Ｂ、１２０Ｃ及び１２０Ｄに適用する。加えて、またクライアント側コンポーネント１５０は、それぞれブロック・ストレージ・デバイス１２０Ａ、１２０Ｂ、１２０Ｃ及び１２０Ｄのためにクライアント側のアドミッション制御パラメータ１５２Ａ、１５２Ｂ、１５２Ｃ及び１５２Ｄのような、さまざまなブロック・ストレージ・デバイス１２０のために１セットのクライアント側のアドミッション制御パラメータ１５２を維持し得る。通常の操作条件下で、たとえば、実際の読み出し／書き込み要求速度がプロビジョニングされたＩＯＰＳで、またはこれを下回るバックエンドＩ／Ｏ要求により取り扱われることが可能であるときに、クライアント側のアドミッション制御パラメータは、少なくともいくつかの実施形態においてサーバ側のアドミッション制御パラメータと異ならない可能性がある。作業要求のより高い速度が１つ以上のブロック・デバイス１２０を対象とすることを期待されるいくつかの種類の操作条件下で、インスタンス・ホスト、ストレージ・サーバ、またはインスタンス・ホスト及びストレージ・サーバの両方のいずれかでアドミッション制御パラメータは、以下で説明されるように変更され得る。いくつかの実装において、たとえば、クライアント側コンポーネントは、あるセットのストレージ・デバイス１２０のために一時的にそれらのローカルのアドミッション制御パラメータ１５２を変更し、つぎにこれらのストレージ・デバイスのために使用されるアドミッション制御パラメータ１３０をオーバーライドし、変更されたクライアント側パラメータにマッチングさせ、プロビジョニングされたものより高い作業負荷レベルを有効にし得る。
【００２９】
クライアント側コンポーネント１５０は、クライアント読み出し／書き込み要求の時間的及び／または空間的分散を監視することができ、監視結果の解析に基づき、少なくとも短期間の今後の要求速度を推定可能にし得る。いくつかの実施形態において少なくとも、クライアント側コンポーネント１５０は、ストレージ・サーバより簡単に複数のブロック・デバイスまたはパーティション間で作業負荷パターンでの対照的な傾向（たとえば、他方のボリュームの作業負荷の減少と時間的に少なくともほぼ同時に起こる一方のボリュームでの作業負荷の増加）を予想可能であり得る。これは、たとえば、典型的に所与のストレージ・サーバが他のサーバに設置されたデバイスに関する作業要求のための要求／応答経路にない可能性があるため、所与のクライアント側コンポーネントは、複数のバックエンド・ストレージ・デバイスのための作業要求への可視性を有し得ることと同じであり得る。いくつかの実施形態において、同じインスタンス・ホスト１４５に、または異なるインスタンス・ホストに設置されたクライアント側コンポーネント１５０は、矢印１２４Ａで示されるような、アドミッション制御決定を行うために使用され得る作業負荷情報または他のメタデータを交換し得る。同様に、少なくとも１つの実施形態において、またあるセットのストレージ・サーバ１１０は、作業負荷情報または他のメタデータを交換し得る。いくつかの実施形態において、１つのストレージ・サーバで１つのクライアント側コンポーネントから受信した作業負荷情報は、図８との関連において以下で議論されるように、他のクライアント側コンポーネントへリダイレクトされ得る、または１つのクライアント側コンポーネントで１つのストレージ・サーバから受信した作業負荷情報は、別のストレージ・サーバへ中継され得る。
【００３０】
図１で示された実施形態において、あるブロック・デバイス１２０について、予想された要求速度が時間間隔中にプロビジョニングされたレベルより高いＩ／Ｏ速度を必要とする可能性があることを所与のクライアント側コンポーネント１５０が推定する場合に、クライアント側コンポーネントは、スループット容量が「借用」され予想されたより高い要求速度に応えることが可能である、いくつかの他のブロック・デバイスを探そうとし得る。いくつかの実施形態において、アドミッション制御パラメータ変更を行い要求速度でこのようなサージまたはバーストを取り扱うために、クライアント側コンポーネント１５０は、（ａ）あるブロック・デバイスが許容される最高要求速度での一時的な低下を受け入れることが可能である、及び（ｂ）増加した要求速度を制限するストレージ・サーバが増加量を受け入れるのに十分な容量を有する、ことを検証する必要がある可能性がある。これらの条件を満たすことが可能である場合に、影響を受けたデバイスのためにクライアント側のアドミッション制御パラメータは、典型的に、影響を受けたブロック・デバイスのセットのために結合され許可された要求速度がそれらのプロビジョニングされた作業負荷レベルの合計のままで、またはこれを下回ったままであるような方式で、描写された実施形態において変更され得るが、一時的なサージまたはバーストは、よりビジーなデバイスで取り扱われることが可能である。作業トークンを使用して利用可能なスループット容量を表す実施形態において、たとえば、余分な要求を予想するデバイスのトークン・バケットの補充速度は、上昇し得るとともに、需要が低いと予想されるトークン・バケットの補充速度は、低下し得る。
【００３１】
いくつかの実施形態において、いくつかの異なるブロック・デバイスからの予備のまたは余分な容量は、ビジーなブロック・デバイスで許容された作業要求の速度を増加させることを補うために借用され得る。たとえば、図１で説明された実施形態において、デバイス１２０ＡでＩ／Ｏ要求の受け入れ速度での大幅な増加は、デバイス１２０Ｂ、１２０Ｃ及び１２０Ｄで最大受け入れ速度を低下させることで補われ得る。このような補正技術のアプリケーションのより詳細な実施例は、図４で説明され、以下に記載される。クライアント側のアドミッション制御パラメータへ行われたこの変更は、いくつかの実装において対応するサーバ側のアドミッション制御パラメータを一時的にオーバーライドし得る。いくつかの実施形態において、クライアント側コンポーネントにより変更可能な単一のセットのアドミッション制御パラメータは、別個のセットのサーバ側及びクライアント側パラメータの代わりに、インスタンス・ホスト１４５またはストレージ・サーバ１１０のいずれか一方で、維持され得る。
【００３２】
トークン・バケットを使用するアドミッション制御
任意のさまざまなアドミッション制御技術が、ストレージ操作のためにクライアントのプロビジョニングされた作業負荷を合理的な応答性で取り扱うことを確保する異なる実施形態において実装され得る。図２は、少なくともいくつかの実施形態により、操作をスケジューリングするために作業トークン・バケットを利用するアドミッション制御機構の態様を説明する。一般的に言えば、このような機構は、ストレージ・オブジェクト、データベース・テーブル、データベース・パーティション、及び同様のもののような、さまざまな種類のエンティティの作業負荷管理のために使用され得る。ブロック・ストレージ・サービスとの関連で、このようなバケットは、さまざまな実施形態において、インスタンス・ホスト１４５、ストレージ・サーバ１１０、またはインスタンス・ホスト及びストレージ・サーバの両方のいずれかで、１つ以上のアドミッション制御装置２８０によりさまざまなボリュームまたはボリューム・パーティションのために維持され得る。トークンの単一のバケット２０２を使用する機構は、プレゼンテーションを簡単にするために図２で説明されるが、読み出し操作のための一方のバケット及び書き込み操作のための他方のバケットのような、複数のバケットの組み合わせは、いくつかの実施形態において使用され得る。この機構により、ブロックレベル・ストレージ・デバイス（たとえば、ボリューム、またはボリュームの１部）のような特定の作業目標１０２と関連したアドミッション制御目的のためにセットアップされたバケット２０２（たとえば、少なくともいくつかの実施形態においてソフトウェア・プログラム内のデータ構造として実装され得る論理コンテナ）に、矢印２０４Ａを介して示されるような、バケットの初期化中に最初の１セットのトークン２０８を追加し得る。最初の追加は、たとえば、さまざまな実施形態において、作業負荷の予想、サービス・レベルの契約、対応するデータ・オブジェクトを所有若しくは管理するクライアントにより指定されたプロビジョニング予算、またはこのような要因のいくつかの組み合わせに基づき、決定され得る。いくつかの種類のバケットについて、最初の追加は、いくつかの実施形態においてゼロに設定され得る。いくつかの実装において、バケットの最初の追加は、バケットを構成する最大の追加に設定され得る。
【００３３】
新規の作業要求２７０の指標（ストレージ・オブジェクトまたはデータベース・オブジェクトの場合に読み出し要求または書き込み要求のような）をアドミッション制御装置２８０で受信するときに、アドミッション制御装置は、ある数Ｎのトークン（実装または構成パラメータに応じて、Ｎが１以上であってもよい）が描写された実施形態のバケット２０２内に存在するかどうかを判定しようとし得る。その数のトークンがバケット内で利用可能である場合に、作業要求２７０を直ちに実行のために受け入れる、または承認することができ、トークンを消費する、またはバケットから除去し得る（矢印２１０）。別途、Ｎトークンが存在しない場合に、作業要求２７０の受け入れは、十分なトークンが描写された実施形態において利用可能になるまで延期され得る。説明された状況において、作業要求２７０Ａを受け入れていて、作業要求２７０Ｂを延期していて、作業要求２７０Ｃ、２７０Ｄ及び２７０Ｅをまだアドミッション制御装置２８０が検討している。延期された要求は、たとえば、十分なトークンが後にバケット２０２で利用可能になるときに、矢印２３２で示されるように、最終的に受け入れられ得る。いくつかの実施形態において、特定の作業要求があるタイムアウト・ウィンドウ内で受け入れられない場合に、それは、矢印２３０で示されるような、アドミッション制御装置により拒否される可能性がある。拒否された作業要求は、いくつかの実装において再提出または再試行され得る。少なくともいくつかの実施形態において、アドミッション制御装置２８０が作業要求を処理するときに十分なトークンがバケット２０２で利用不可能である場合に、この作業要求は、延期される代わりに直ちに拒否される可能性がある。
【００３４】
２０４Ｂとラベル付けされた矢印により示されるように、バケット２０２は、図３を参照して以下で説明されるように、たとえば、バケットと関連した補充速度のような構成パラメータに基づき、経時的に補充または再追加され得る。いくつかの実装において、トークン補充操作は、たとえば、単一のソフトウェア・ルーチン内に、消費操作を伴う、または消費操作に近接した時間に実行されることができ、Ｎトークンは、要求を承認するために消費されることができ、Ｍトークンは、補充速度、及びバケットが最後に補充されてから経過した時間に基づき加えられ得る。所与のバケットの補充速度またはトークン・カウントは、典型的に短い時間間隔で、たとえば、より高い作業要求速度を取り扱うことを可能にするために、ストレージ・サービスのクライアント側コンポーネント１５０により変更され得る。制限は、たとえば、構成パラメータを使用して、バケットがいくつかの実施形態において保持し得る最大数のトークンに、及び／または最小数のトークンに設けられ得る。構成パラメータ設定のさまざまな組み合わせを使用して、かなり洗練されたアドミッション制御方式を異なる実施形態において実装し得る。
【００３５】
１つの単純で例示的な状況において、秒あたり１００作業要求の定常負荷を支援するために、最初の追加の１００トークン、許与可能な最大追加の１００トークン及び最小のゼロ・トークンで図２のバケット２０２を構成し得る。Ｎを１に設定し得、補充速度を秒あたり１００トークンに設定し得、１０ミリ秒毎に１回、補充目的のために１トークンを追加し（最大追加限度を超えないと仮定する）得る。作業要求２７０が到着すると、各作業要求のために１トークンが消費され得る。各秒中に均一に分散される、秒あたり１００作業要求で定常状態の作業負荷が適用される場合に、補充速度及び作業負荷到着速度は、互いに均衡し得る。このような定常状態の作業負荷は、上記に記載されたバケット・パラメータを与えられた、いくつかの実施形態において無期限に維持され得る。
【００３６】
上記の実施例を拡張して、到着速度及び／または補充速度が均一ではない場合に、状況は、いくつかの（典型的に短い）時間間隔（たとえば、補充機構より多いトークンの間断ない消費においてあるセットの作業要求が置き換え可能である場合に）にバケット２０２が空のままであることが発生する可能性がある。このような場合において、到着する作業要求は、拒否（または遅延後にリタイア）されなければならない可能性がある。実質的な遅延または高い拒否率を導入することなく作業負荷の一時的な不均一性に対処するために、先に述べられたクライアント側コンポーネント１５０によるアドミッション制御パラメータの一時的な変更のような、異なる実施形態においてさまざまな技術を用い得る。
【００３７】
図３は、少なくともいくつかの実施形態により、さまざまな種類のアドミッション制御ポリシーを実装するために使用され得る、バケット２０２のような、トークン・バケットの例示的な構成プロパティ３０２を説明する。いくつかの実装において、トークン・バケットは、アドミッション制御装置２８０のインメモリ・データ構造として実装されることができ、必要に応じて永続ストレージへ書き込まれ得る。このようなデータ構造は、追加を最後に変更したときに現在のトークン追加を表すフィールド、及び／または図３で示されたさまざまなパラメータ及びポリシーのための値を含むことができる。
【００３８】
トークン消費ポリシー３１０は、トークンをアドミッション制御のために消費する方式、及び消費のタイミング（たとえば、作業要求を受け入れる前にすべてのトークンを消費するかどうか、または受け入れられた要求のために実行された実際の作業量に基づきいくつのトークンを後で消費できるかどうか）を示すことができる。いくつかの実施形態において、異なる数のトークンは、その消費ポリシーに基づき所与のバケットから異なる種類の操作のために消費され得る。たとえば、Ｉ／Ｏ操作は、「大規模」または「小規模」として分類され得、異なるトークン量は、Ｉ／Ｏ操作のサイズに基づき消費され得る。いくつかの実施形態において、またトークン消費ポリシーは、対応する作業目標がしばらくの間に作業要求の対象となっていない場合にトークンをバケットから削除するかどうか（及びどのような速度で）を示すアイドル中の減衰パラメータ、またはそれらがある時間間隔中に使用されていない場合にトークンが一方のバケットから他方へ（たとえば、使用頻度の低いボリュームのバケットから使用頻度の高いボリュームのバケットへ）転送されるかどうかを示すアイドル時の転送パラメータ、を指定し得る。１つの実施形態において、失効ポリシーは、指定された時間間隔で消費されていないトークンを消費するために使用され得る。たとえば、各トークンは、トークンがアドミッション制御目的のためにもはや有用ではなくなり得る有効期限と関連し得る。
【００３９】
プロパティ３０２は、いくつのトークンを起動時または初期化時にバケット内に配置するかを示す、描写された実施形態において初期トークン追加パラメータ３０６を含み得る。トークン補充ポリシー・パラメータ３１４は、どのような速度で、及び／またはどのような状況下で、たとえば、バケットと関連した作業目標を構成している作業速度を維持することを支援するために、トークンがバケットに加えられるかを示し得る。前述したように、バケットのパラメータのうちの１つ以上を経時的に変更し得る。たとえば、デフォルト補充速度をバケットに適用し得るが、プロビジョニングされたものより高い速度に対応するために、より高い非デフォルトの速度を少なくとも一時的に使用し得る。最大追加パラメータ３１８は、バケットの最大容量及び対応する作業目標を示し得る。いくつかの実施形態において、異なる種類の操作は、異なるアドミッション制御ルールを有することができ（たとえば、読み出しが書き込みと異なるルールを有することができ、またはＩ／Ｏがデータ読み出し若しくは書き込み量に基づき異なるルールを有することができ）、バケットを使用する操作の種類は、適用可能な操作種類のパラメータ３２０で指定され得る。少なくともいくつかの実施形態において、バケットのトークンの使用のためにクライアントが請求される金額を決定するために使用され得る、１つ以上の価格ポリシー３２２は、バケット・プロパティで示され得る。異なる実施形態において、図３で示された１サブセットの例示的なパラメータのみを用い得るが、他の実施形態においては、図３で示されたものを超える追加のバケット構成パラメータを使用し得る。図３で示されたさまざまなプロパティのための値及び／または設定は、他のアドミッション制御設定と同様に、少なくともいくつかの実施形態において、プログラムにより（たとえば、ウェブ・サービス呼び出しを使用するクライアント側コンポーネント１５０により）設定または変更され得る。作業トークンを利用しないアドミッション制御技術を少なくともいくつかの実施形態で用い得ることに留意する。
【００４０】
ストレージ・サーバ及びクライアント側コンポーネント間のアドミッション制御インタラクション
図４は、少なくともいくつかの実施形態により、サービスのバックエンド・ストレージ・サーバ及びこのサービスのクライアント側コンポーネント間の例示的なアドミッション制御関連のインタラクションを説明する。１０００のＰＩＯＰＳ速度を各々が有する、合計４つの例示的なブロック・ストレージ・デバイスを示す。ストレージ・サーバ１１０Ａは、ブロック・ストレージ・デバイス１２０Ａ及び１２０Ｂを含み、ストレージ・サーバ１１０Ｂは、ブロック・ストレージ・デバイス１２０Ｃ及び１２０Ｄを含む。ブロック・デバイス１２０Ａ及び１２０Ｃは、たとえば、それらが同じクライアントにより所有されるため、またはそれらが単一の仮想ボリュームの異なるパーティションを表すため、所属の組４１０とみなされ得る。それぞれのトークン・バケットは、描写された実施形態において各デバイスのためのアドミッション制御のために使用され得る。アドミッション制御パラメータの変更を行い、所与のデバイス１２０でより高いＩ／Ｏ速度を有効にするかどうかを検討するときに、少なくともいくつかの実施形態において、クライアント側コンポーネント１５０は、借用可能な容量のソースを識別するその試行の際に所属のデバイス１２０で予想された作業負荷を優先的に調べ得る。
【００４１】
クライアント側ストレージ・サービス・コンポーネント１５０は、ＩＯＰＳ推定器４３３を含む。この推定器は、たとえば、デバイス１２０に接続する１つ以上のコンピュート・インスタンスの代わりにクライアント側コンポーネントで取り扱われる読み出し／書き込み要求のログ、他のインスタンス・ホストまたは同じインスタンス・ホストで他のクライアント側コンポーネントから収集された情報、及び／またはストレージ・サーバ１１０から収集された情報を含む、さまざまなソースからストレージ作業負荷関連のメトリックを収集し得る。収集されたデータを使用して、推定器４３３は、さまざまなコンピュート・インスタンスから発行された読み出し及び書き込み要求で時間的及び／または空間的パターンを検出可能であり得、このパターンを使用して今後の読み出し／書き込み速度及び／またはバックエンドＩ／Ｏ速度についての少なくとも短期予測を行うことが可能であり得る。図４で示された実施例において、推定器４３３はつぎのＮ秒間に、１２００ＩＯＰＳをデバイス１２０Ａで期待し、６００ＩＯＰＳをデバイス１２０Ｃで期待することを予測している。それに応じて、デバイス１２０Ａ（ＰＩＯＰＳ１０００で）のために予測された１２００ＩＯＰＳを有効にするために、クライアント側コンポーネント１５０は、デバイス１２０Ａへそれらの容量の（少なくとも）２００ＩＯＰＳを寄与または「貸与」可能な他のデバイス１２０を探そうとし得る。加えて、またクライアント側コンポーネント１５０は、デバイス１２０Ａを設置するストレージ・サーバ１１０Ａがデバイス１２０Ａに向けられた余分な負荷を取り扱い可能であるために十分な空き容量を有することを検証する必要がある可能性がある。
【００４２】
「１ａ」とラベル付けされた矢印により示されるように、クライアント側コンポーネントは、ストレージ・サーバ１１０Ｂへ（たとえば、ストレージ・サーバ１１０Ｂのアドミッション制御装置コンポーネントへ）クエリを送信し、つぎのＮ秒間にデバイス１２０Ｃ（余分な容量を必要なデバイス１２０Ａと提携する）から２００ＩＯＰＳを借用可能であるかどうかを判定し得る。（いくつかの実装において、限界に達することなく余分な２００ＩＯＰＳを取り扱い可能であるために、２００よりわずかに多いＩＯＰＳが必要とされる可能性がある。）「１ｂ」とラベル付けされた矢印により示されるように、描写された実施形態においてほぼ同じ時間に、クライアント側コンポーネントは、別のクエリをストレージ・サーバ１１０Ａへ送信し、ストレージ・サーバがデバイス１２０Ａのためにプロビジョニングされるものより２００多いＩＯＰＳを取り扱うために十分な容量を有するかどうかを判定し得る。いくつかの実装において、矢印１ａ及び１ｂで示された２つのクエリは、並行して送信され得る。他の実施形態において、クライアント側コンポーネントは、他方を提出する前に一方のクエリへの応答を受信するのを待ち得る。後者の状況で、クエリは、いずれの順序でも提出され得る。いくつかの実施形態において、制御プレーン・チャネルを介してクエリを送信（及びそれらの応答を受信）し得、他の実施形態において、データ・プレーン・チャネルを使用し得る。
【００４３】
ストレージ・サーバ１１０Ａ及び１１０Ｂは、それらのローカルな作業負荷メトリック及び／またはアドミッション制御メタデータを調べ、クエリに応答し得る。いくつかの実施形態において、たとえば、ストレージ・サーバ１１０Ａは、最後のＭ秒間に各々のそのブロック・デバイスのために平均要求速度を決定し得る。平均要求速度の合計が十分な量でブロック・デバイスのためにプロビジョニングされた速度の合計未満である場合に、ストレージ・サーバは、クエリ１ｂ（「２」とラベル付けされた矢印により示されるように）へ肯定的に応答し得る。各々のブロック・デバイス１２０用のアドミッション制御のためにトークン・バケット機構を使用する実施形態において、予備のスループット容量を示し得る、さまざまなバケットのために蓄積された、または未使用のトークンの現在の追加は、クエリへ応答するために調査され得る。たとえば、ストレージ・サーバ１１０Ｂで、ブロック・デバイス１２０Ｃのためのトークン・バケットは、３００ＩＯＰＳの利用可能な空き容量を示し得るため、２００ＩＯＰＳの要求への肯定的な返答を提供し得る（「３」とラベル付けされた矢印により示されるように）。クエリ１ａ及び１ｂへの応答は、任意の順序で受信され得、ラベル「２」及び「３」は、応答がその順序で受信される必要があることを意味するように意図されない。いくつかの実施形態において、ストレージ・サーバ１１０Ｂは、容量を借用する要求へ肯定的に応答する前に他のデバイスの作業負荷状態を調査しても良い。たとえば、デバイス１２０のバケット内のトークン数が非常に少ない場合に、ストレージ・サーバですべてのブロック・デバイスがそれらのプロビジョニングされたＩＯＰＳに関して合理的にアンダーロードであるときにのみトークンを貸与するという保守的な前提に基づき、ストレージ・サーバ１１０Ｂは、要求１ａへ否定的に応答し得る。
【００４４】
クライアント側コンポーネントがドナー・ブロック・デバイスを探し出すことが可能である場合、及び余分な容量を必要なストレージ・サーバが対応する負荷を取り扱い可能である場合に、１つ以上のアドミッション制御パラメータを変更して、要求の予想されたサージを実行のために受け入れることを可能にし得る。「４ａ」とラベル付けされた矢印により示されるように、描写された実施例において、デバイス１２０Ａのために使用されたトークン・バケットの補充速度を２００トークン／秒で一時的に増加させ得、「４ｂ」とラベル付けされた矢印により示されるように、デバイス１２０Ｃのために同じ量で補充速度を低下させ得る。矢印「４ａ」及び「４ｂ」に対応する操作を任意の順序で、または並行して実行し得る。いくつかの実施形態において、トークン補充速度以外のパラメータまたは設定を変更し得る。たとえば、いくつかの実施形態においてデバイス１２０Ａのために使用されたトークン・バケットへ２００*Ｎトークンを単純に加えることができ、デバイス１２０Ｃのためにトークン・バケットから２００*Ｎトークンを差し引き得る。Ｎ秒期間が経過した後に、少なくともいくつかの実施形態においてパラメータをそれらの元の値にリセットし得る。アドミッション制御パラメータのこのようなリセットは、たとえば、いくつかのブロック・デバイスがその他の方法で長期間にそれらのプロビジョニングされた速度より高い要求速度を維持可能であり得、他のデバイスがそれらのプロビジョニングされた速度を超えるようになることを防ぐ、窮乏または不公平な状況を防ぐことを支援し得る。
【００４５】
いくつかの実施形態において少なくとも、予想された作業負荷全体を取り扱うために所与のブロック・デバイスのための容量を必要なだけ取得することが常に可能ではあり得ないことに留意する。たとえば、所与のブロック・デバイスのプロビジョニングされた作業負荷レベルは、５０％を超え得るが、５０％の不足のほぼ半分は、他のデバイスから借用された容量を使用して克服され得る。いくつかの実施形態において、このような状況下で、ストレージ・サービス（たとえば、クライアント側コンポーネントで）のアドミッション制御装置は、「ベストエフォート型」アプローチを実装するように構成され得ることにより、キューイングまたは延期なしで作業負荷全体を取り扱い不可能である場合でさえ、利用可能な空き容量と同じくらいは、過負荷なブロック・デバイスのために展開され得る。他の実施形態において、アドミッション制御パラメータは、所与のデバイスのために予想された容量不足全体のみが他のデバイスから借用された容量を使用して満たされることが可能であるように調整され得る。
【００４６】
パーティション化されたボリュームのためのアドミッション制御
少なくともいくつかの実施形態において、先に示されたように、複数のストレージ・サーバまたは複数の物理デバイス間でパーティション化される仮想ボリュームは、ストレージ・サービスにより実装され得る。図５は、少なくともいくつかの実施形態により、複数のパーティションを備える仮想ボリュームのために使用され得るアドミッション制御メタデータの実施例を説明する。示されるように、４つのバックエンド・ストレージ・サーバ５２０を使用して、４つのブロックレベル・ボリュームを実装する。ボリュームのうちの２つ、５２０Ｂ及び５２０Ｃは、複数のストレージ・サーバ間でパーティション化され、残りの２つのボリューム５２０Ａ及び５２０Ｄは、１つのストレージ・サーバへ各々とどめられる。
【００４７】
複数のストレージ・サーバ５１０間にボリューム５２０Ｂ及び５２０Ｃを物理的に分散させる事実は、描写された実施形態においてクライアントの代わりにボリュームを確立するため、クライアントに明らかではない可能性がある。したがって、このようなボリュームは、仮想または仮想化されたボリュームと称され得る。ボリューム５２０Ｂがセットアップされるクライアントは、４０００ＰＩＯＰＳ（アドミッション制御メタデータ５２３の「ボリュームＰＩＯＰＳ」カラムで示されるように）を支援可能なボリュームを単に要求し得る。このような要求に応答して、ストレージ・サービスは、それぞれのストレージ・サーバ５１０Ａ、５１０Ｂ、５１０Ｃ及び５１０Ｄで４つのパーティション５３０Ａ、５３０Ｂ、５３０Ｃ及び５３０Ｄにボリュームを分割する決定を行っていて良い。同様に、クライアントの代わりにボリューム５２０Ｃをセットアップするためクライアントは、１８００ＰＩＯＰＳボリュームを要求していて良く、ストレージ・サービスは、それぞれストレージ・サーバ５１０Ｂ及び５１０Ｃでパーティション５３０Ｋ及び５３０Ｌに対応するボリュームを分割する決定を行っていて良い。より低いＰＩＯＰＳレベルに対して、ボリューム５２０Ａのために要求された１０００ＰＩＯＰＳ、またはボリューム５２０Ｄのために要求された７５０ＰＩＯＰＳのような、複数のパーティションは、必要とされない可能性がある。いくつかの実施形態において、ボリュームは、プロビジョニングされた作業負荷レベル以外の要因に基づきパーティション化され得る。たとえば、要求されたボリューム・サイズは、複数のパーティションを必要とする、またはしないかどうかを判定するために使用され得る。外部的には、クライアントの観点から、ボリュームは、そのＰＩＯＰＳレベルまたはサイズに関係なく同じ方式で処理され得る。内部的には、ストレージ・サービスは、異なるデバイス及びサーバ間でいくつかのボリューム（必ずしもすべてのボリュームではないが）のコンテンツを分散させ、要求された高い合計のプロビジョニングされた作業要求速度を達成する、及び／または要求された大きなボリューム・サイズを達成し得る。
【００４８】
描写された実施形態において、ＰＩＯＰＳ設定は、全体のボリューム・レベル（「ボリュームＰＩＯＰＳ」カラムで示されるような）及びパーティション・レベル（「パーティションＰＩＯＰＳ」カラムで示されるような）の両方でアドミッション制御メタデータ５２３の部分として維持される。所与のボリュームのパーティションＰＩＯＰＳの合計は、全体的なそのボリュームについてのＰＩＯＰＳ設定まで加え得る（少なくとも通常の操作条件下で）。ＰＩＯＰＳ設定に加えて、またストレージ・サービスのアドミッション制御装置（たとえば、クライアント側コンポーネント１５０で）は、「評価されたＩＯＰＳ」カラムにより示されるように、今後の時間間隔中に予想されたＩＯＰＳを評価し得る。所与のパーティションのために予測されたＩＯＰＳがプロビジョニングされたＩＯＰＳを超えるときに、少なくともいくつかの実施形態において、同じボリュームの他のパーティションでＰＩＯＰＳ及び評価されたＩＯＰＳ間の差は、プロビジョニングされた容量のいくつかが増加した需要を満たすために転送されることが可能であるかどうかを判定するために調査され得る。たとえば、図５で示された実施例においてパーティション５３０Ｂに関して、評価されたＩＯＰＳは、プロビジョニングされたＩＯＰＳを２００超える。それに応じて、パーティション５３０Ｂに関与しているクライアント側コンポーネントは、ボリューム５２０Ｂの残りのパーティションの予想されたＩＯＰＳを調査し得る。残りのパーティション５３０Ａ、５３０Ｃ及び５３０Ｄの各々は、プロビジョニングされたレベルよりはるかに低いＩ／Ｏ操作の速度を維持することを期待される。その結果、残りのパーティションのうちのいずれか１つ（またはいずれかの組み合わせ）は、パーティション５３０Ｂで予想された余分な２００ＩＯＰＳを維持するため容量を借用する候補として描写された実施形態で選択され得る。同様に、パーティション５３０Ｌ用に余分な容量を取得するために、最初にそのピア・パーティション５３０Ｋを候補として選択し得る。同じボリュームのパーティションのいずれも十分な空き容量がない場合に、他のパーティションまたは他のボリュームは、少なくともいくつかの実施形態において候補として選択され得る。
【００４９】
多重接続されたボリュームのためのアドミッション制御
いくつかの実施形態において、ボリュームのような所与のブロック・ストレージ・デバイスは、一度に最大１つのコンピュート・インスタンスに接続され得るため、一度に最大でも１つのコンピュート・インスタンスからアクセスされ得る。他の実施形態において、所与のボリュームまたはパーティションは、同時に複数のコンピュート・インスタンスに（したがって、これらからアクセス可能な）接続され得る。図６は、少なくともいくつかの実施形態により、複数のコンピュート・インスタンスに接続可能であるブロックレベル・デバイスのためのアドミッション制御関連の操作の実施例を説明する。４つのストレージ・サーバ６１０Ａ、６１０Ｂ、６１０Ｃ及び６１０Ｄを示す。３つ及び２つのパーティションをそれぞれ含む、２つのパーティション化されたボリューム６２０Ｂ及び６２０Ｃを説明し、３つのパーティション化されないボリューム６２０Ａ、６２０Ｄ及び６２０Ｅを示す。パーティション化されたボリュームを支援するいくつかの実施形態において、パーティション化されないボリュームは、単一のパーティションを各々含むボリュームとして簡単に管理され得る。パーティション化されたボリューム及びパーティション化されないボリュームの両方は、たとえば、さまざまな「ＡｔｔａｃｈＶｏｌｕｍｅ」ＡＰＩ呼び出しの結果として、描写された実施形態において複数のコンピュート・インスタンスへ接続され得る。パーティション化されたボリューム６２０Ｂは、コンピュート・インスタンス１４０Ａ及び１４０Ｂへ接続され、パーティション化されないボリューム６２０Ｅは、コンピュート・インスタンス１４０Ｂ及び１４０Ｃへ接続される。１４０Ｂのような所与のコンピュート・インスタンスは、少なくともいくつかの実施形態において１つより多い多重接続ボリューム（６２０Ｂ及び６２０Ｅのような）へ接続され得る。
【００５０】
異なるインスタンス・ホスト１４５で潜在的に各々に実行していることが可能である、いくつかの異なるコンピュート・インスタンスへ所与のボリューム・パーティションまたはボリュームを接続する能力は、ストレージ・サービスのクライアント側コンポーネントで用いられアドミッション制御パラメータ調整を行う予測ロジックを複雑にする可能性がある。１つの所与のボリュームへ最大でも１つのインスタンスを接続する１つの実施形態において、現在接続されるインスタンスのインスタンス・ホストでクライアント側コンポーネントは、比較的簡単にボリュームでＩ／Ｏ要求速度に関する作業負荷メトリックを収集可能であり得る。しかしながら、同じボリュームまたはパーティションに異なるインスタンスからアクセスすることが可能であるときに、潜在的に異なるアプリケーションについて、要求パターンを収集及び解析することは、容易ではない可能性がある。複数の接続を支援するいくつかの実施形態において、伴われた異なるインスタンス・ホスト（すなわち、同時に接続されたインスタンスを実行している異なるインスタンス・ホスト）のクライアント側コンポーネントは、接続されたインスタンスの各々についての作業負荷情報を交換し得る。矢印６５０Ａ、６５０Ｂ、６５０Ｃ及び６５０Ｄにより示されるような、他の実施形態において、多重接続されたボリュームを実装することに関与したストレージ・サーバ６１０は、クライアント側コンポーネントでアドミッション制御決定のために使用される作業負荷情報のコンジットとしての役割を果たすことができる。たとえば、６１０Ｄのようなストレージ・サーバは、クライアント側コンポーネント１５０Ａへ多重接続されたボリューム６２０ＥのＩ／Ｏメトリックを提供し得る。またはストレージ・サーバ６１０Ｂは、クライアント側コンポーネント１５０Ａへ多重接続されたボリューム・パーティション６３０ＡのＩ／Ｏメトリックを提供し得る。いくつかの実施形態において、ストレージ・サーバは、同じボリュームまたはパーティションへ接続される異なるコンピュート・インスタンスのための作業負荷メトリックを隔離し、クライアント側コンポーネントへインスタンスが編成したメトリックを提供することが可能であり得る。このようなアプローチは、クライアント側コンポーネント１５０により行われた予測の精度を向上させることを支援することができ、それに応じてそのアドミッション制御パラメータ変更の有効性を高め得る。
【００５１】
クライアント側の協調アドミッション制御のための方法
図７は、少なくともいくつかの実施形態により、ブロックレベル・ストレージ・デバイス用のアドミッション制御を実装するために実行され得る操作の態様を説明する流れ図である。要素７０１で示されるように、アドミッション制御パラメータは、プロビジョニングされた作業負荷モデルを実装するストレージ・サービスのいくつかのブロックレベル・ストレージ・デバイスの各々のために確立され得る。トークン・バケット（図２のバケット２０２に類似した）を使用して利用可能な容量を表す実施形態において、たとえば、このようなパラメータは、所与のボリュームまたはパーティション、最初のトークンの追加、最大及び／または最小のトークンの追加、及びその他のもののために使用された、トークン・バケットの補充速度を含み得る。各セットのアドミッション制御パラメータ設定は、たとえば、対応するボリューム作成要求に示されたボリューム・サイズ及び／または作業負荷パラメータのようなクライアントが指定した選好または要件に基づき、選択され得る。パーティション化されたボリュームを支援するいくつかの実施形態において、クライアント要件は、いくつの異なるパーティションをセットアップするかを判定し、パーティションが存在するストレージ・サーバを識別するために使用され得る。パラメータは、たとえば、コンピュート・インスタンスで実行するアプリケーションから発行された読み出しまたは書き込み操作のような、作業要求を許容、延期または拒否するために、ストレージ・サーバ、ストレージ・サービスのクライアント側コンポーネント、またはストレージ・サーバ及びクライアント側コンポーネントの両方のいずれかでアドミッション制御装置モジュールにより、使用され得る。
【００５２】
要素７０４で示されるように、ストレージ・サービスのクライアント側コンポーネントは、さまざまなブロック・ストレージ・デバイスで期待された作業負荷レベル（ＩＯＰＳのような）を推定するように構成され得る。このような推定値は、いくつかの実装において数秒または数百ミリ秒のような比較的短期間に生成され得（またはこの期間に有効であると仮定される）、読み出し及び書き込み要求の分散でパターンを示す収集されたメトリックにたとえば基づき得る。メトリックは、たとえば、ブロックレベル・デバイスへ接続されたコンピュート・インスタンスを実行するインスタンス・ホストの仮想化管理ソフトウェア・スタックで、収集され得る。この仮想化管理ソフトウェア・スタックは、少なくともいくつかの実施形態においてコンピュート・インスタンスで実行するアプリケーションから発行されたＩ／Ｏ要求のための仲介として作用し得、ストレージ・サーバを対象とするバックエンドＩ／Ｏ要求にアプリケーション読み出し／書き込み要求を変換し得る。
【００５３】
時間間隔Ｔ１の間に有効な推定値を、対応するプロビジョニングされた速度と比較し得る。すべての期待されたＩ／Ｏ速度が対応するプロビジョニングされた速度（要素７０７で検出されるような）である、またはこれらを下回る場合に、時間間隔Ｔ１の間にアドミッション制御パラメータへの調整を必要としない可能性があり（要素７２５）、クライアント側コンポーネントは、後続の時間間隔の間の推定値に使用されるメトリックを収集し得る。少なくとも１つのブロック・ストレージ・デバイスＢＤ１（ストレージ・サーバＳＳ１で）がそれのプロビジョニングされたＩ／Ｏ速度ＰＲ１（また要素７０７で検出されるような）より高いＸ  ＩＯＰＳである速度でＩ／Ｏ要求を受信することが期待される場合に、クライアント側コンポーネントは、いくつかの他のブロック・デバイスＢＤ２がＢＤ２のプロビジョニングされたＩＯＰＳ速度ＰＲ２より低い速度でＩ／Ｏ要求を受信することが期待されるかどうか（またはそれぞれプロビジョニングされたものより低い速度ＰＲ２、ＰＲ３、．．．で要求を受信することを各々期待された、１グループのこのような潜在的な貸し手ブロック・デバイスＢＤ２、ＢＤ３、．．．を探し出すことが可能であるかどうか）を判定するために進行し得る（要素７１０）。クライアント側コンポーネントがＢＤ１の期待された余分な作業負荷にマッチングするまたはこれさえ超える十分な空き容量を探し出そうとし得るが、いくつかの場合において、ＢＤ１の余分な作業負荷の１部だけを補充するのに十分な貸し手デバイスを探し出すことのみ可能であり得ることに留意する。このような貸し手デバイスを探し出すために、少なくともいくつかの実施形態において、クライアント側コンポーネントは、ＢＤ１と提携したブロック・デバイス、たとえば、同じクライアントが所有するデバイス、またはＢＤ１として同じより大規模な仮想ボリュームのパーティションであるデバイスのために作業負荷推定値を最初に調査し得る。いくつかの実装において、所与のインスタンス・ホストでクライアント側コンポーネントは、他のインスタンス・ホスト（たとえば、以下で説明されるようなクライアント側所属グループのメンバー）で他のクライアント側コンポーネントと、またはストレージ・サーバと通信して、このようなデバイスＢＤ２を探し出すことが可能であるかどうかを判定し得る。
【００５４】
このような第二デバイスＢＤ２を探し出すことが不可能であった場合に、  アドミッション制御パラメータを変更してＴ１中にＢＤ１で（ＰＲ１＋Ｘ）の所望のＩＯＰＳ速度を達成することは実現不可能である可能性がある（要素７２２）。しかしながら、このようなデバイスＢＤ２（またはデバイスＢＤ２、ＢＤ３、．．．のグループ）を探し出す（また要素７１０で検出されるような）場合に、クライアント側コンポーネントは、追加のチェックを実行し得る。クエリは、ＢＤ１を設置するストレージ・サーバＳＳ１を対象とし、ＳＳ１がＴ１中にＢＤ１で予想された追加の負荷の少なくともいくつかを管理するのに十分な容量を有するかどうかを判定し得る（要素７１３）。ＳＳ１が他のクライアント（または同じクライアント）のためにいくつかのビジーなブロック・ストレージ・デバイスを支援していて、増加した作業負荷を受け入れるのに十分に利用可能なスループット容量を有さない可能性がある場合もあり得る。このような状況において、ＳＳ１は、それが余分な作業負荷を取り扱い不可能であることをクライアント側コンポーネントに示すことができ、それに応じてクライアント側コンポーネントは、アドミッション制御パラメータ変更がＴ１中にＢＤ１で予想された余分な作業負荷に対応することが実現不可能であるという結論を下す可能性がある（要素７２２）。
【００５５】
ＳＳ１が余分なＩＯＰＳ（また要素７１３で検出されるような）を取り扱い可能である場合に、アドミッション制御パラメータ設定は、ＢＤ１に変更され（要素７１６）、より高い作業負荷の少なくともいくつかを受け入れることを可能にし得る。たとえば、アドミッション制御のためにトークン・バケットを使用する実施形態において、補充速度を増加させ得る、またはＢＤ１用のバケットへＸトークンまでを加え得る。少なくともいくつかの実施形態において、ＢＤ２、ＢＤ３、．．．でアドミッション制御パラメータへ対応する補正変更を行い得る。たとえば、それらのトークン・バケットで補充速度を低下させ得る、またはそれらのトークン・バケットからいくつかのトークンを削除し得る。変更されたパラメータに基づき、ＢＤ１は、Ｔ１中に余分な要求を受け入れ得る。一方では、Ｔ１中に、ＢＤ２、ＢＤ３、．．．で受け入れられた要求の最大速度は、それらのプロビジョニングされたレベルより下に低下する可能性がある。少なくともいくつかの実施形態において、アドミッション制御パラメータへの変更は、たとえば、減衰関数に従い徐々に、またはステップ関数に従いほぼ瞬時に、のいずれかに、期間Ｔ１後に元に戻され得る（要素７１９）。アドミッション制御パラメータへの変更は、たとえば、必要ならそれら自体のスループット容量を正常に増加させるためにＢＤ１以外のデバイスを提供するために、いくつかの実施形態において、比較的に短い期間Ｔ１の間に支援のみされ得る。期間Ｔ１が経過した後に、要素７０４以降に対応する操作は、つぎの時間間隔で繰り返され得る。
【００５６】
先に述べられたように、また予想された作業負荷の推定値に基づきクライアント側コンポーネントによりアドミッション制御パラメータを調整する技術は、プロビジョニングされた作業負荷モデルを使用しない実施形態において使用され得る。たとえば、今後の時間間隔に内部の作業負荷速度目標は、いくつかの実施形態においてプロビジョニングされないボリュームと関連することができ、上記で説明された種類の一時的な容量転送は、プロビジョニングされたＩＯＰＳ速度を使用する代わりに内部の作業負荷速度目標に基づいて実装され得る。
【００５７】
リダイレクトを介する作業負荷情報発信
図８は、少なくともいくつかの実施形態により、ストレージ・サービスのクライアント側コンポーネント間の作業負荷関連のメッセージがサーバ側コンポーネントによりリダイレクトされ得るシステムを説明する。示されるように、システム８００は、８５０Ａ及び８５０Ｂのような、サービスの複数のクライアント側コンポーネント８５０からのＩ／Ｏ要求８１７（たとえば、８１７Ａ及び８１７Ｂ）に応答することに関与している、サーバ８１０Ａ及び８１０Ｂのような、マルチテナント・ストレージ・サービスの複数のバックエンド・サーバ８１０を含み得る。描写された実施形態において、クライアント側コンポーネント８５０は、仮想化されたコンピューティング・サービスのインスタンス・ホストでそれぞれ仮想化管理ソフトウェア・スタック（ＶＭＳＳ）８７０内に各々実装され得る。たとえば、クライアント側コンポーネント８５０Ａは、インスタンス・ホスト８４５ＡでＶＭＳＳ８７０Ａの１つ以上のモジュールを含み得、クライアント側コンポーネント８５０Ｂは、インスタンス・ホスト８４５ＢのＶＭＳＳ８７０Ｂ内に実装され得る。クライアント側コンポーネントは、インスタンス・ホスト８４５Ａのコンピュート・インスタンス８４０Ａ及び８４０Ｂならびにインスタンス・ホスト８４５Ｂのコンピュート・インスタンス８４０Ｃ及び８４０Ｄのような、コンピュート・インスタンス８４０上で実行するアプリケーションで最初に生成された読み出しまたは書き込み要求８２２（たとえば、８２２Ａ、８２２Ｂ、８２２Ｃ及び８２２Ｄ）の代わりにストレージ・サーバ８１０へＩ／Ｏ要求を提出し得る。単一のクライアント側コンポーネント８５０を図８の各インスタンス・ホストで示すが、さまざまな実施形態において、複数のクライアント側コンポーネントを同じインスタンス・ホストに実装し得る。ストレージ・サービスは、いくつかの実施形態において、ブロック・デバイスまたはボリューム・レベルでプログラマティック・インタフェースを実装し得るが、また、または代わりにファイル・システムＡＰＩのような他のインタフェースを異なる実施形態において実装し得る。少なくとも１つの実施形態において、図２で説明されたトークン・ベースのアプローチと同様にアドミッション制御技術もシステム８００で使用し得る。１つの実施形態において、ストレージ・サービスは、図４との関連で先に述べられたようにプロビジョニングされたＩＯＰＳを支援し得るが、またメッセージ・リダイレクト・ベースの作業負荷管理アプローチは、プロビジョニングされた作業負荷モデルを使用しない実施形態で用いられ得る。
【００５８】
図８に描写された実施形態において、データ・プレーン通信チャネル８４４は、各々のさまざまなストレージ・サーバ及びあるサブセットのクライアント側コンポーネント間に確立されていて良い。先に示されたように、データ・プレーン通信経路は、コンピュート・インスタンス８４０（このような読み出し及び書き込みのための要求と同様に）でアプリケーションの代わりにデータ読み出しまたは書き込みを含むトラフィックのために最初に確立され得、制御プレーン通信経路（図８で図示せず）は、管理または構成目的のために最初に使用され得る。たとえば、データ・プレーン通信チャネル８４４Ａを介してクライアント側コンポーネント８５０Ａからサーバ８１０ＡへＩ／Ｏ要求を送信（及び対応する応答を受信）し得、データ・プレーン通信チャネル８４４Ｃを介してクライアント側コンポーネント８５０Ａからサーバ８１０ＢへＩ／Ｏ要求を送信（及び対応する応答を受信）し得る。同様に、データ・プレーン通信チャネル８４４Ｂ及び８４４Ｄは、それぞれサーバ８１０Ａ及び８１０Ｂとのクライアント側コンポーネント８５０Ｂのデータ関連のインタラクションのために使用され得る。少なくともいくつかの実施形態において、すべてのバックエンド・ストレージ・サーバ８１０がすべてのクライアント側コンポーネント８５０に確立されたデータ・プレーン（または制御プレーン）通信チャネルを有し得るとは限らないことに留意する。このようにして、いくつかの実施形態において少なくとも、さまざまなサブセットのクライアント側コンポーネントは、さまざまなサブセットのストレージ・サーバへセットアップされた通信チャネルを有し得る。
【００５９】
１つのストレージ・サービスのいくつかの数のクライアント側コンポーネント８５０は、単一のアプリケーション、または関連した１セットのアプリケーションの代わりにストレージまたはＩ／Ｏ要求のための仲介として構成され得る。たとえば、コンピュート・インスタンス８４５の何十または何百を含む大規模な分散処理アプリケーションは、ストレージ・サービスの同じエンド・ユーザのクライアント・アカウントの代わりに実行され得る、または１セットのインタラクト・アプリケーションは、複数のコンピュート・インスタンスを使用して１つ以上のユーザ・アカウントの代わりに実行され得る。いくつかのこのようなアプリケーションについて、所与のストレージ・ボリュームまたはバックエンド・デバイスは、複数のクライアント側コンポーネント（図６で示されるものと同様の方式で）からアクセス可能であるように構成され得る。図５で説明されるこれらと同様にパーティション化されたボリュームを使用するいくつかの実施形態において、いくつかのクライアント側コンポーネントは、１つのアプリケーションのためにセットアップされた単一のパーティション化されたボリュームのための要求応答経路に関与し得る。このようにして複数のクライアント側コンポーネントは、種々の構成でいくつかのアプリケーションまたはアプリケーション・グループの代わりに実行されたＩ／Ｏに関わり得る。エンド・ユーザのクライアントの観点及び／またはアプリケーションの観点から、アプリケーション（複数を含む）のさまざまな要素について共有された作業負荷情報に理想的に基づき、関連する複数のクライアント側コンポーネントによるバックエンド要求の協動スケジューリング及び／またはアドミッション制御は、有益であり得る。それに応じて、少なくともいくつかの実施形態において、さまざまなグループのクライアント側コンポーネントは、それぞれのグループ内の作業負荷情報を共有するために、及び共有された作業負荷情報を使用してより多くの情報の作業負荷スケジューリング決定を行うために、識別され得る。このようなグループは、クライアント側の所属グループと本明細書で称され得る。描写された実施形態において、クライアント側コンポーネント８５０Ａ及び８５０Ｂは、同じ所属グループのメンバーであると仮定される。所属グループのメンバーシップは、グループのメンバー間の共有されたリソース、コンピュート・インスタンスまたは関連するインスタンス・ホストのセットの共通のクライアント・アカウント所有権、パーティション化されたボリュームまたは多重接続され共有されたボリュームへのアクセス、グループのために使用されたリソースのローカル性または近接性、及びその他のものの使用のような、さまざまな実施形態においていくつかの異なる要因のいずれかに基づき決定され得る。
【００６０】
図８で示された実施形態において、作業負荷情報は、既存のデータ・  プレーン通信チャネルを使用してクライアント側コンポーネント８５０からストレージ・サーバ８１０へ送信され、つぎに分散ポリシーの１セットのパラメータに基づきストレージ・サーバから発信コンポーネントの所属グループの他のクライアント側コンポーネントへリダイレクトされ得る。このようにして、たとえば、クライアント作業負荷メトリック８１８は、コンポーネント８５０Ａからサーバ８１０Ａへ送信されたバックエンドＩ／Ｏ要求８１７Ａ内に含まれ得る。複数の異なる種類の作業負荷メトリックを異なる実施形態において送信し得る。メトリック８１８は、たとえば、前のＸ秒間にクライアント・コンポーネント８５０Ａにより発行された読み出し要求及び／または書き込み要求の数または速度、最後のＸ秒間にクライアント・コンポーネント８５０Ａによりさまざまなコンピュート・インスタンス８４５から受信した要求の数または速度、クライアント・コンポーネント８５０Ａにより発行されたバックエンド要求のためのレイテンシまたは応答時間計測、インスタンス・ホスト８４５ＡのＣＰＵ使用率かローカル・ディスク使用率かネット使用率のメトリック、及びその他のものを示すことができる。いくつかの実施形態において、今後の時間間隔の間に期待／推定されたメトリックは、既に計測されているメトリックの代わりに、またはこれらに加えて送信され得る。
【００６１】
サーバ８１０Ａにおいて、メトリック８１８をバッファ８７６Ａまたはデータベースへ少なくとも一時的に保存し得る。いくつかの実装において、以下で説明されるように保持ポリシーに基づきバッファ８７６で同じクライアント側コンポーネント８５０からの古いメトリックを上書きできる。分散ポリシー８７８Ａに従い、サーバ８１０Ａは、８５０Ａから（及び／または所属グループの他のメンバーから）のメトリックを伝播する、８５０Ｂのような、１つ以上の他のクライアント側コンポーネントを識別し得る。描写された実施形態において、メトリックは、Ｉ／Ｏ要求８１７Ｂへの応答８１９で、サーバ８１０Ａからクライアント側コンポーネント８５０Ｂへ送信され得る。いくつかの実施形態において、所属グループの１人より多いメンバーのためのメトリック８２１を単一のメッセージで送信することができ、他の実施形態において、単一のクライアント側コンポーネントのメトリックをメッセージごとに送信し得る。
【００６２】
選択された宛先のクライアント側コンポーネント８５０Ｂにおいて、受信したメトリック８２１を所属グループのデータベース８７０Ｂに保存し得る。データベース８７０Ｂは、たとえば、所属グループのさまざまな他のメンバーの作業負荷メトリック、さまざまなメンバーに添付された相対的な優先順位または重み、任意の所与のメンバーのためにどの程度最近に作業負荷メトリックを取得したか、及びその他のものを含むことができる。受信したメトリック８２１に基づいて及び／またはリポジトリ８７０Ｂの追加のメタデータに基づいて、クライアント側コンポーネント８５０Ｂは、たとえば、それが他の所属グループのメンバーからの高い要求速度を考慮して１つ以上のバックエンド・サーバを対象とする作業負荷を軽減する必要があると判定する場合に、要求キュー８７２Ｂ内でいくつかの選択された要求をキューアップすることで、後続のバックエンド・サービス要求のためにスケジューリング決定を行うことができる。コンポーネント８５０Ｂの作業負荷メトリックは、８１０Ｂまたは８１０Ａのような１つ以上のサーバ８１０へ順に送信されることができ、所属グループの他のコンポーネントへリダイレクトされ得る。このようにして、コンポーネント８５０Ａは、サーバ８１０のいくつかの組み合わせから８５０Ｂ及び他の所属グループのメンバーと関連したメトリックを受信し得、それ自体のデータベース８７０Ａ内にその情報を保存し得る。クライアント側コンポーネント８５０Ａは、収集された作業負荷情報を使用して、たとえば、一時的に要求キュー８７２Ａにいくつかの要求を配置することで、１つ以上のバックエンド・サーバ８１０を対象とするそれ自体の作業負荷を変更し得る。各ストレージ・サーバは、サーバ８１０Ｂでのバッファ８７６Ｂのような、クライアント・メトリックのそれ自体のバッファ８７６を維持することができ、適用可能な分散ポリシー（サーバ８１０Ｂでのポリシー８７８Ｂのような）に従いいくつかのセットのクライアント側コンポーネントへメトリックを再分散させ得る。時間内の任意の所与のポイントで異なるストレージ・サーバ８１０でのバッファ８７６のコンテンツは、互いに異なり得る。少なくともいくつかの実施形態において、またさまざまなサーバ８１０により使用された分散ポリシーのパラメータは、互いに異なり得る。たとえば、サーバ８１０Ｂでの作業負荷メトリックのメッセージのためのスケジューリング・ポリシーは、時間内の所与のポイントにおいて、サーバ８１０Ａでその時間に使用されるスケジューリング・ポリシーと異なり得る。
【００６３】
クライアント側作業負荷情報は、描写された実施形態において、経時的にさまざまな協動するクライアント側コンポーネントに伝播され得る。図８で示されるように、作業負荷メトリックをいかなる場合でも送信されている要求及び応答上にピギーバックする場合に、共有する作業負荷情報と関連したオーバーヘッドを少なくともいくつかの実施形態において最小化し得る。さらに、少なくともいくつかの実装において、１つの所属グループの複数のサービス要求の全体的な速度が増加する場合に、さらにバックエンドＩ／Ｏ要求及び応答は、ピギーバック目的のために単位時間あたりに利用可能であり得るため、より頻繁に作業負荷情報を伝播し得る。結果として、所与のクライアント側コンポーネントでの作業負荷メトリックの計測、及び他のクライアント側コンポーネントが作業負荷メトリックを受信する時間の間の平均遅延を低減させ得る。このようにして、ストレージ・サービスの全体的な作業負荷レベルを低減させた場合よりもこのような実装でより最近のメトリックを使用して、さまざまなクライアント側コンポーネントでの作業負荷スケジューリング決定を行い得る。それに応じて、共有された作業負荷メトリックに基づき行われたスケジューリング決定の品質は、全体的な作業負荷レベルを上昇させながら向上し得る。
【００６４】
先に述べられたように、ストレージ・サーバ８１０は、いくつかの実施形態においてクライアント側コンポーネントで使用される技術とは関係なく、作業負荷をスロットリングするためにアドミッション制御パラメータを利用し続け得る。このような状況において、ストレージ・サーバでアドミッション制御設定に基づき行われた要求を拒否するまたは遅延させる決定は、クライアント側コンポーネントによる作業負荷リスケジューリング決定をオーバーライドする効果を有し得る。たとえば、上記で説明された種類の共有する作業負荷メトリックに基づいて、特定のクライアント側コンポーネントＣ１は、所与のストレージ・サーバＳ１へある間隔中に秒あたりＮバックエンド要求をスケジューリングしようとし得る。Ｓ１のアドミッション制御パラメータ（たとえば、他のクライアント側コンポーネントからのＳ１を対象とする作業負荷との組み合わせで）がその作業負荷レベルを許可しない場合に、Ｃ１の要求のうちのいくつかは、Ｃ１の所属グループとの関連で作業負荷レベルを管理するＣ１の努力にもかかわらずＳ１により拒否される可能性がある。
【００６５】
メトリック分散ポリシー
ストレージ・サーバにより受信した作業負荷メトリックを伝播する方式のいくつかの態様は、さまざまな実施形態において設定可能なパラメータを介して制御可能であり得る。図９は、少なくともいくつかの実施形態により、作業負荷関連のメッセージをリダイレクトするために使用され得る分散ポリシーの例示的なパラメータを説明する。示されるように、ストレージ・サーバ８１０のデータベース９５６内で識別された所属グループのメンバーのために適用される分散ポリシーのパラメータ９０２は、特に、宛先選択ポリシー９１０、メッセージ・スケジューリング・ポリシー９１４、転送機構９１８、クライアント・メトリック保持ポリシー９２０、メトリック・グルーピング・ポリシー９２４、及び／またはサーバ作業負荷伝播設定９２８を含むことができる。
【００６６】
クライアント側コンポーネントの作業負荷メトリックをリダイレクトすることに関与しているストレージ・サーバは、さまざまな実施形態においていくつかの異なるアプローチのいずれかを使用して、データベース９５６（たとえば、単一の所属グループまたは複数の所属グループ、もしあれば、さまざまなクライアント側コンポーネント８５０が属している）に含めるため所属グループのメンバーシップ情報を提供され得る。１つの実施形態において、所与のクライアント側コンポーネントＣ１は、制御プレーン・メッセージまたはデータ・プレーン・メッセージのいずれか一方を介してＣ１が協動したい、他のクライアント側コンポーネントＣ２、Ｃ３、．．．、のリストをサーバＳ１へ送信し得る。サーバＳ１は、たとえば、コンポーネントがＣ１と共有する作業負荷メトリックに参加したいかどうかに関して、他のメンバーから受信したそれぞれのメッセージに基づき、または各提案されたメンバーＣ２、Ｃ３、．．．にクエリを行うことでのいずれか一方で、メンバーシップを確認するように設定され得る。このような確認関連のメッセージは、いくつかの実施形態において制御プレーン経路、または他の実施形態においてデータ・プレーン経路を使用して送信または交換され得る。いくつかの実施形態において、クライアント側コンポーネントは、ストレージ・サーバへメッセージを介して所属グループ内のそれらのメンバーシップを定期的に再確認し得る。１つの実施形態において、ストレージ・サーバは、たとえば、直接サーバ間通信を使用して、または図３で図示された方式で以下に説明されるクライアント側コンポーネントによりリダイレクトされたメッセージを介してのいずれか一方で、他のストレージ・サーバと所属グループのメンバーシップ情報を交換し得る。
【００６７】
特定の所属グループ内で、サーバ８１０は、１セットのメトリックを宛先選択ポリシー９１０に基づき対象とする特定のクライアント側コンポーネント（及び／またはクライアント側コンポーネント数）を識別し得る。たとえば、いくつかの実施形態において、宛先は、ゴシップ・ベースのプロトコルで使用されたものと同様の方式で、所属グループのメンバーの中から無作為に抽出され得る。他の実施形態において、さらに決定論的宛先選択技術を使用し得る。たとえば、いくつかのクライアント側コンポーネントが、他のものよりさらに頻繁に作業負荷情報を提供される際に、ラウンドロビン・アプローチを利用し得る、または優先度ベースの宛先リストを使用し得る。リダイレクトされたメトリックを含むメッセージのタイミングは、たとえば、クライアント側コンポーネントを対象とする各通信において、クライアント側コンポーネントを対象とするＮ番目の通信ごとに、各クライアント側コンポーネントへＮ秒ごとに少なくとも１回、サーバ及びクライアント側コンポーネント間のネットワーク利用レベルに基づき選択された時間で、ならびにその他のものでメトリックをサーバ８１０が含むかどうかを、メッセージ・スケジューリング・ポリシー９１４に基づき決定され得る。たとえば、サービス応答上にピギーバックすることが使用される、別個のメトリック固有メッセージが使用される、またはピギーバック及びメトリック固有メッセージのいくつかの組み合わせが使用されるかどうか、使用される特定のメッセージング技術は、描写された実施形態において転送機構９１８を介して示され得る。いくつかの実施形態において、転送機構は、サーバ及びクライアント側コンポーネント間のメッセージのために使用された送信ユニットのサイズのパケット・サイズに関して、データ・ペイロードのサイズに依存し得る。たとえば、１つの転送機構設定により、サーバは、メッセージ送信サイズが４０９６バイトでありデータ・ペイロードが３０７２バイトを占める場合に、メトリックの１０２４バイトのみを含むことができるような、この通信がどのくらいデータ・ペイロードのバイトを含まなければならないかに基づき、どれほどの（またはどの特定の）クライアント側メトリック情報が所与のデータ・プレーン・メッセージに送信されるかを決定し得る。
【００６８】
いくつかの状況において少なくとも、以前に収集されたメトリックがスケジューリングを改良する際に十分に役に立つほど正確ではない可能性がある場合に、選択された時間窓内に収集されたこれらの作業負荷メトリックのみを使用してスケジューリング決定を行ったほうがよい可能性がある。それに応じて、クライアント・メトリックの保持ポリシー９２０は、ストレージ・サーバでそれらを最初に受信した後に、どのくらいの期間メトリックを保持またはリダイレクトする必要があるかを示す、いくつかの実施形態に適用され得る。いくつかの実装において、たとえば、３００秒より古いメトリックを破棄し得る、グローバル保持ポリシーは、すべてのメトリックに適用され得る。他の実装において、それぞれの保持ポリシーは、たとえば、所属グループごとで、クライアント側コンポーネントごとで、クライアント・アカウントごとで、顧客アプリケーションごとで、またはリダイレクトされるメトリックの種類に基づいて（たとえば、異なる保持期間をディスク関連のメトリックよりＣＰＵ関連のメトリックのために使用し得る）、異なるセットのメトリックに適用され得る。
【００６９】
いくつかの実施形態において、単一のクライアント側コンポーネントのメトリックをストレージ・サーバによりメッセージごとにリダイレクトすることができ、他の実施形態において、所属グループのいくつかのまたはすべてのメンバーに利用可能な直近のメトリックを送信し得る。メトリックのグルーピング・ポリシー９２８は、いくつかのこのような実施形態において所与のメッセージにパッケージ化される必要があるメトリック・セットを決定するために使用され得る。サーバが大規模なメトリック・データ量を各クライアント側コンポーネントから収集する場合に、いくつかの実施形態においてグルーピング・ポリシーに基づき、たとえば、最大送信ユニット・サイズまたはパケット・サイズに基づき、１つのメッセージに１サブセットのメトリックのみを送信し得る。ピギーバックを使用している実装において、上記で示されるように、クライアント側コンポーネントへの所与のメッセージ内に含まれる、またはこれ内でグルーピングされるメトリック・セットは、このメッセージのデータ・ペイロードを考慮した後に残るスペースに依存し得る。
【００７０】
少なくとも１つの実施形態において、またストレージ・サーバは、図１０で図示され以下で記載されるように、それら自体のメトリックを収集し、他のストレージ・サーバへのリダイレクトのためにクライアント側コンポーネントへそれらを送信し得る。図９で示された他のポリシーのいくつかに概念が似るがクライアント側メトリックよりもサーバ側メトリックへ適用可能な、作業負荷メトリックのサーバ間リダイレクトを管理するポリシー（たとえば、どのくらいの間隔でメトリックを再分散させる必要があるか、及びどのセットのサーバ間であるか）は、描写された実施形態においてサーバ側伝播設定９２８により示され得る。さまざまな実施形態において、図９で示されたすべての異なるパラメータ及びポリシーを使用できるとは限らないが、他の実施形態において、他のパラメータ（図９で図示せず）を使用できることに留意する。
【００７１】
作業負荷情報の双方向分散
図１０は、少なくともいくつかの実施形態により、ストレージ・サービスのクライアント側及びサーバ・コンポーネントの両方による作業負荷関連のメッセージのリダイレクトの実施例を説明する。クライアント側コンポーネント８５０Ａ、８５０Ｂ及び８５０Ｃを含む所属グループ１０１２を示す。所属グループのメンバーシップは、たとえば、単に異なるクライアント側コンポーネントはそれらが共有した作業負荷データを使用してリソース・スケジューリングで協動したいことを示す要求を提出するため、異なるクライアント側コンポーネント、共有リソースの使用、同様の顧客アプリケーション、ローカル性、またはいくつかの場合によりＩ／Ｏ要求が取り扱かわれている共通の顧客アカウントに基づいて、異なる実施形態においてさまざまな要因に基づき決定され得る。
【００７２】
描写された実施形態において、クライアント側コンポーネント８５０Ａは、その作業負荷メトリックを８１０Ａのような１つ以上のストレージ・サーバへ送信する。サーバ８１０Ａは、８５０Ａのメトリックを所属グループ１０１２の他のメンバーへリダイレクトする。同様に、また８５０Ａのメトリック（または８５０Ｂ若しくは８５０Ｃからのメトリック）を受信する８１０Ｂまたは８１０Ｃのような他のサーバは、上記で記述されたようなさまざまなポリシー及びパラメータの種類に基づき、所属グループ１０１２の他のメンバーにメトリックをリダイレクトし得る。描写された実施形態において、クライアント側コンポーネントのメトリックを再分散させることに加えて、ストレージ・サーバは、リダイレクトする仲介としてクライアント側コンポーネントを使用して、サーバ側メトリックを伝播し得る。このようにして、ストレージ・サーバ８１０Ａは、あるセットのサーバ側メトリック（たとえば、前のＮ秒間に取り扱っている合計の読み出しまたは書き込み要求速度）をクライアント側コンポーネント８５０Ａへ送信する。クライアント側コンポーネントは、たとえば、クライアント側メトリックを分散させる方法と同様な方式でデータ・プレーン通信チャネルを使用して、８１０Ｂまたは８１０Ｃのような他のサーバへサーバ側メトリックをリダイレクトし得る。所与のストレージ・サーバ８１０Ａは、それがたとえば、制御プレーン・メッセージの部分として、またはデータ・プレーン・メッセージ内で伝播されたそれのメトリックを有したい、他のサーバ・セットを示し得る。リダイレクトされたサーバ側メトリックは、サーバで使用され、他のサーバで観測された作業負荷傾向に基づくサーバ側アドミッション制御パラメータの一時的な変更のような、より多くの情報のアドミッション制御決定を行うことができる。
【００７３】
データ要求（たとえば、読み出し要求）、データ・ペイロード（たとえば、書き込み要求または読み出し要求への応答）またはＩ／Ｏ応答（たとえば、書き込み要求への応答）を含むネットワーク・メッセージ内に作業負荷メトリックを組み込むいくつかの実施形態において、所与のデータ・プレーン・メッセージは、ピギーバックされたクライアント側メトリック、サーバ側メトリック、または両方の種類のメトリックを含み得る。このようにして、たとえば、読み出し要求でクライアント側コンポーネント８５０Ａのメトリックをサーバ８１０Ａへ送信し得、読み出し要求への応答は、読み出しデータ・ペイロードに加えて８５０Ｂのような他のコンポーネントからのクライアント側メトリックと同様に８１０Ａのサーバ側メトリックを含み得る。少なくともいくつかの実施形態において、それぞれの所属グループは、クライアント側コンポーネント間で共有する作業負荷情報のために及び（または代わりに）サーバ８１０間で共有する作業負荷情報のために定められ得る。
【００７４】
所属グループのメンバーの役割及び相対的な優先順位
いくつかの実施形態において、クライアント側の所属グループの異なるメンバーのストレージ要求は、たとえばあるセットのアプリケーションに関するメンバーの役割に基づき、異なる優先順位を有するように処理され得る。グループ・メンバーの役割についての情報は、さまざまなグループ・メンバーの各々で所属グループのデータベース内に維持され得る。メンバー間の作業負荷メトリックの段階的な分散の結果として、時間内の所与のポイントで異なるグループ・メンバーでのデータベースのコンテンツは、少なくともいくつかの実施形態において必ずしも同一ではない可能性がある。図１１は、少なくともいくつかの実施形態により、ストレージ・サービスのクライアント側コンポーネント８５０で維持され得る所属グループのデータベース１１０２の例示的なコンテンツを説明する。所属グループの情報は、図１１において表形式で表示されるが、異なる実施形態において任意の適切なデータ構造を使用し得る。示されるように、データベースは、コンポーネント（カラム１１２４）と関連した論理的または機能的な役割（たとえば、「コーディネータ」、「データ収集部」など）の指標と同様にコンポーネント識別子（カラム１１２０において）を含み得る。
【００７５】
所属グループの各コンポーネントのために格納されたメトリック（カラム１１３２で示された読み出し及び書き込み要求速度のような）をどの程度最近受信したかを示すデータは、カラム１１２８に含まれ得る。さまざまな種類のストレージ操作の役割及び／または要求速度に基づき、相対的な重みは、たとえば別の要求（たとえば、そのバックエンド要求間の遅延を導くより優先順位の低いコンポーネントによる）に優先して１つのコンポーネントからの要求に優先順位をつけるために使用され得る、各コンポーネントへ割り当てられ得る。描写された実施例において、各コンポーネントにより発行された読み出し及び書き込みに異なる重みを添付し、他の実装において、読み出し対書き込み用の個別の重みの代わりに各コンポーネントに単一の重みを割り当て得る。いくつかの実施形態において、それぞれの重みは、ストレージ要求の異なるサイズ範囲に割り当てられ得る。たとえば、クライアントＣ１により発行された５１２ＫＢより大きい大量の書き込みは、１つの重みを割り当てられ得、１６ＫＢより少ない少量の書き込みは、同じクライアントＣ１から、異なる重みを割り当てられ得る。さまざまな実施形態において、相対的な重みは、たとえば、関連するクライアント側コンポーネントの各々の合意で、互いにメッセージを交換した後に所属グループのメンバーにより割り当てられ得る。提案または承認された相対的な重みは、メトリック伝播のために使用されたものと同様の方式で、いくつかの実施形態において所属グループのメンバー間のデータ・プレーン経路沿いにリダイレクトを介して送信され得る。他の実施形態において、制御プレーン・メッセージは、相対的な重み情報または優先順位情報を伝えるために使用され得る。
【００７６】
リダイレクトされたメッセージを使用する作業負荷管理の方法
図１２は、少なくともいくつかの実施形態により、リダイレクトされたメッセージを使用してストレージ作業負荷管理を実装するために実行され得る操作の態様を説明する流れ図である。要素１２０１で示されるように、データ・プレーン通信チャネルは、いくつかの実施形態においてまた確立され得る管理用または構成関連のチャネルとは対照的にデータ要求及び応答のために主に意図された、クライアント側コンポーネント及びストレージ・サービスのサーバ・コンポーネント間に確立され得る。ストレージ・サービスは、少なくともいくつかの実施形態においてマルチテナントであってもよい。たとえば、各ストレージ・サーバ及び／またはクライアント側コンポーネントは、いくつかの異なるクライアントのストレージ要求の取り扱いを担当し得る。少なくとも１つの実施形態において、ブロックレベル・デバイス・インタフェース（たとえば、ブロックレベルＡＰＩを使用してボリュームに接続及びアクセスすることを可能にするインタフェース）は、ストレージ・サービスにより支援され得る。また、ファイル・システム・インタフェースのような他の種類のプログラマティック・インタフェース、または非構造化ストレージ・オブジェクトへのアクセスを提供するウェブ・サービスＡＰＩは、異なる実施形態において支援され得る。
【００７７】
要素１２０４で示されるように、クライアントの所属グループのメンバーシップ（作業負荷メトリックを共有して、ストレージ関連の操作のための集合的なスケジューリングを改良し得るクライアント側コンポーネントのセット）を決定し得る。さまざまな要因は、提供されるインスタンスまたはアプリケーションの共通の所有権、パーティション化されたボリュームまたは多重接続されたボリュームのような共有リソースの使用、使用されるハードウェア・セットに関するローカル性、実行するアプリケーションの種類、及びその他のもののような、異なる実施形態においてどのクライアント側コンポーネントが協動するかを判定するときに考慮され得る。
【００７８】
ストレージ・サーバにより適切な所属グループのメンバーへクライアント側コンポーネントの作業負荷情報を発信するために使用されるパラメータ及び／またはポリシーのセットを決定し得る（要素１２０７）。このようなパラメータは、メトリックの宛先、メッセージの頻度、メトリック分散のために使用されるメッセージング機構、及びその他のもののために使用される、選択基準を有し得る。分散ポリシーは、少なくともいくつかの実施形態においてストレージ・サーバにより異なり得る。いくつかの分散パラメータ設定は、１つの実施形態においてストレージ・サービスの顧客により示された選好に基づき設定され得る。分散ポリシーは、たとえば、行われるスケジューリング決定の有効性の測定に基づき、経時的に調整され得る。１つの実装において、連続してリダイレクトされたメトリック・メッセージ間の間隔のようなパラメータを収集されたストレージ性能メトリックの解析に基づき調整し得る、機械学習アプローチを使用できる。
【００７９】
所与のクライアント側コンポーネントＣ１は、ある時間間隔にその作業負荷メトリックＭ１（たとえば、読み出し要求、書き込み要求などの速度）を収集し（要素１２１０）、それらを選択されたストレージ・サーバＳ１に送信する（要素１２１３）ことができる。いくつかの実施形態において、既存のデータ・プレーン通信チャネルは、たとえば、読み出し要求若しくは書き込み要求上にメトリックをピギーバックすることで、またはデータ・プレーン・チャネルを介して個別のメトリック固有メッセージを送信することで、使用され得る。順に、サーバＳ１は、たとえば、これらのクライアント側コンポーネントから受信した後続のＩ／Ｏ要求への応答内にメトリックを含むことで、他の既存のデータ・プレーン通信チャネルを使用して、１つ以上の他のクライアント側コンポーネントＣ２、Ｃ３、．．．、へメトリックＭ１を送信し得る（要素１２１６）。受信するクライアント側コンポーネントは、所属グループのデータ及びメタデータのそれらのローカル・コレクションに受信したメトリックを加え得、受信したメトリックを使用して、ストレージ・サービスのバックエンドへ提出される他のサービス要求についてスケジューリング決定を行い得る（要素１２１９）。プロセスは、異なる期間にさまざまなクライアント・サーバ組み合わせで繰り返され得る（たとえば、要素１２１０〜１２１９で示すそれらと同様の操作は繰り返され得る）ため、所属グループの他のメンバーでの作業負荷条件の集合的見解は、クライアント側コンポーネントと各々協動することで徐々に利用可能になり、スケジューリング決定は、全体として所属グループの利益のために改良されることが可能である。
【００８０】
リダイレクトされた作業負荷メトリックは、いくつかの実施形態において非データ・プレーン・メッセージを使用して送信され得、たとえば、制御プレーン経路を使用し得る。作業負荷情報がいかなる場合でも配信されているメッセージにピギーバックすることを介して送信されるこれらの実施形態において、作業負荷情報を発信するオーバーヘッドをかなり低く維持し得る。いくつかの実施形態において、また、または代わりにサーバ側作業負荷メトリックは、サーバがそれら自体の作業負荷メトリックをクライアント側コンポーネントへ収集して送信し、つぎにクライアント側コンポーネントがこのメトリックを他のサーバへ転送する、同様のリダイレクト技術を使用して送信され得る。
【００８１】
さまざまな実施形態において、図７及び１２の流れ図で図示されたこれら以外の操作が上記で記載された作業負荷管理技術を実装するために使用され得ることに留意する。示された操作のうちのいくつかは、いくつかの実施形態において実装されない可能性がある、または異なる順序で若しくは順次よりも並行して実装され得る。たとえば、図１２に関して、データ・プレーン通信チャネルの確立は、所属グループを識別した後に、または所属グループのメンバーシップの決定と並行して発生し得る。少なくともいくつかの実施形態において、上記で説明されたこの技術は、ブロック・デバイスより他の種類のストレージ・デバイスで作業負荷を管理するために使用され得る。たとえば、同様の技術は、ブロック・デバイスのＩ／Ｏインタフェースよりもウェブ・サービス・インタフェースを使用して任意のストレージ・オブジェクトにアクセスすることを可能にする非構造化ストレージ・デバイスのために、またはリレーショナル若しくは非リレーショナル・データベースのテーブル若しくはパーティションにアクセスするために使用され得る。
【００８２】
ユースケース
ネットワーク・アクセス可能なストレージ・デバイスのための協調アドミッション制御の、及びリダイレクトされた作業負荷メトリックに基づきスケジューリングするストレージ作業負荷の、上記で説明された技術は、複数の状況で有用であり得る。アプリケーションのストレージ・ニーズが増大する場合に、ますます大きなボリュームは、ボリュームのためにプロビジョニングされた比例してより高いスループット容量速度で、クライアント・アプリケーションのために構成され得る。いくつかの理由（ディスクまたはディスク・アレイのような個々のストレージ・デバイスのスループット能力がより高いプロビジョニングされた容量のために、または高い可用性／耐久性の理由のために需要ほど速く増加しない事実のような）のため、ストレージ・サービスは、必ずしもクライアントへパーティショニングの詳細を明らかにすることなく、バックエンドで複数のストレージ・サーバ及び／またはデバイス間で大きなボリュームをパーティション化し得る。つぎにストレージ・サービスは、異なるパーティションを対象とする作業負荷の均衡を取らなければならない可能性がある。不均衡な作業負荷のクライアント側予測は、記載されたこれらと同様に、作業負荷で時間的及び空間的な変形形態を取り扱う際に非常に有用であり得る。非常に頻繁に利用される可能性が高いパーティションは、あまりビジーではないと期待される別のものからプロビジョニングされた容量を「借用」可能であり得る。クライアントに大きなボリュームは、変形形態に関係なく簡単に高い作業負荷を取り扱い可能であるように見える。同様に、異なるボリューム間でプロビジョニングされた容量を一時的に転送する能力は、同じボリュームの異なるパーティションよりも、不均一な作業負荷でいくつかの異なるボリュームを使用する複数のクライアント・アプリケーションのグループ（または単一のクライアント・アプリケーション）に利益をもたらすことができる。本明細書で記載された種類の動的なアドミッション制御パラメータ変更は、作業負荷が一重接続されたボリュームの場合でよりもさらに大きな程度に異なり得る、多重接続されたボリューム（作業要求がいくつかの異なるコンピュート・インスタンスからの所与のボリュームを対象とし得る）のためにさらにより有用であり得る。
【００８３】
上記で説明されたリダイレクト・ベースの技術は、特に作業負荷スケジューリング決定を共有された作業負荷情報上で行ったかどうかにかかわらず送信されるメッセージ上にメトリックをピギーバックするときに、作業負荷メトリックを伝播する非常に効果的な方式を提供し得る。クライアントが所属グループを集合的に画定することを可能にすること、及びつぎにこのようなグループのメンバー間で作業負荷情報を共有することで、全体としてグループの利益となるより高レベルのスケジューリング最適化を費用対効果で実現することは可能であり得る。作業負荷レベルが増加する場合に、メトリックは、いくつかの実装においてさらにより頻繁に交換され得るため、より高い負荷レベル下でより良いスケジューリングへ潜在的につながる。
【００８４】
例示的なコンピュータ・システム
少なくともいくつかの実施形態において、クライアント側コンポーネント及びストレージ・サービスのバックエンド・コンポーネントを実装する技術を含む、本明細書で記載された技術の１つ以上の１部またはすべてを実装するサーバは、１つ以上のコンピュータ・アクセス可能な媒体を含む、またはこれにアクセスするように構成される汎用コンピュータ・システムを含み得る。図１３は、このような汎用コンピューティング・デバイス３０００を説明する。図示された実施形態において、コンピューティング・デバイス３０００は、入力／出力（Ｉ／Ｏ）インタフェース３０３０を介してシステム・メモリ３０２０（不揮発性及び揮発性メモリ・モジュールの両方を含むことができる）へ連結された１つ以上のプロセッサ３０１０を含む。さらにコンピューティング・デバイス３０００は、Ｉ／Ｏインタフェース３０３０へ連結されたネットワーク・インタフェース３０４０を含む。
【００８５】
さまざまな実施形態において、コンピューティング・デバイス３０００は、１つのプロセッサ３０１０を含むユニプロセッサ・システム、またはいくつかのプロセッサ３０１０（たとえば、２、４、８、または別の適切な数）を含むマルチプロセッサ・システムであってもよい。プロセッサ３０１０は、インストラクションを実行することが可能な任意の適切なプロセッサであってもよい。たとえば、さまざまな実施形態において、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、またはＭＩＰＳインストラクション・セット・アーキテクチャ（ＩＳＡ）、若しくは任意の他の適切なＩＳＡのような、さまざまなＩＳＡのいずれかを実装する、汎用または組み込みプロセッサであってもよい。マルチプロセッサ・システムにおいて、各プロセッサ３０１０は、通常、必ずしもそうではないが、同じＩＳＡを実装し得る。いくつかの実装において、グラフィックス処理部（ＧＰＵ）は、従来のプロセッサの代わりに、またはこれに加えて使用され得る。
【００８６】
システム・メモリ３０２０は、プロセッサ（複数を含む）３０１０によりアクセス可能なインストラクション及びデータを格納するように構成され得る。少なくともいくつかの実施形態において、システム・メモリ３０２０は、揮発性及び不揮発性部分の両方を含む得、他の実施形態において、揮発性メモリのみ使用され得る。さまざまな実施形態において、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、シンクロナス・ダイナミックＲＡＭまたは任意の他の種類のメモリのような、任意の適切なメモリ技術を使用して、システム・メモリ３０２０の揮発性部分を実装し得る。システム・メモリの不揮発性部分（たとえば、１つ以上のＮＶＤＩＭＭを含むことができる）に対して、いくつかの実施形態においてＮＡＮＤフラッシュ・デバイスを含むフラッシュ・ベースのメモリ・デバイスを使用し得る。少なくともいくつかの実施形態において、システム・メモリの不揮発性部分は、スーパーキャパシタまたは他の蓄電装置（たとえば、バッテリ）のような、電源を含み得る。さまざまな実施形態において、メモリスタ・ベースの抵抗変化型メモリ（ＲｅＲＡＭ）、３次元ＮＡＮＤ技術、強誘電体ＲＡＭ、磁気抵抗ＲＡＭ（ＭＲＡＭ）、またはさまざまな種類の相変化メモリ（ＰＣＭ）のいずれかは、システム・メモリの不揮発性部分のために少なくとも使用され得る。図示された実施形態において、上記で説明されたこれらの方法、技術、及びデータのような、１つ以上の所望の機能を実装するプログラム・インストラクション及びデータは、コード３０２５及びデータ３０２６としてシステム・メモリ３０２０内に格納されて示される。
【００８７】
１つの実施形態において、Ｉ／Ｏインタフェース３０３０は、ネットワーク・インタフェース３０４０、またはデータ・オブジェクト・パーティションの物理的な複製を格納するために使用された、さまざまな種類の永続及び／または揮発性ストレージ・デバイスのような他のペリフェラル・インタフェースを含むデバイスに、プロセッサ３０１０、システム・メモリ３０２０、及び任意の周辺機器間のＩ／Ｏトラフィックを協調させるように構成され得る。いくつかの実施形態において、Ｉ／Ｏインタフェース３０３０は、任意の必要なプロトコル、タイミングまたは他のデータ変換を実行して、一方のコンポーネント（たとえば、システム・メモリ３０２０）から他方のコンポーネント（たとえば、プロセッサ３０１０）による使用に適切なフォーマットにデータ信号を変換し得る。いくつかの実施形態において、Ｉ／Ｏインタフェース３０３０は、たとえば、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）・バス規格またはユニバーサル・シリアル・バス（ＵＳＢ）規格の変種のような、さまざまな種類のペリフェラル・バスを介して接続されたデバイスのための支援を有し得る。いくつかの実施形態において、Ｉ／Ｏインタフェース３０３０の機能は、たとえば、ノースブリッジ及びサウスブリッジのような、２つ以上の別個のコンポーネントに分割され得る。また、いくつかの実施形態において、システム・メモリ３０２０へのインタフェースのような、Ｉ  ／Ｏインタフェース３０３０の１部またはすべての機能性は、直接プロセッサ３０１０に組み込まれ得る。
【００８８】
ネットワーク・インタフェース３０４０は、たとえば、図１から図１２で説明されるような他のコンピュータ・システムまたはデバイスのような、単一のネットワークまたは複数のネットワーク３０５０へ接続されたコンピューティング・デバイス３０００及び他のデバイス３０６０間でデータを交換することを可能にするように構成され得る。さまざまな実施形態において、ネットワーク・インタフェース３０４０は、たとえば、イーサネット（登録商標）・ネットワークの種類のような、任意の適切な有線または無線の一般的なデータ・ネットワークを介して通信を支援し得る。加えて、ネットワーク・インタフェース３０４０は、ファイバ・チャネルＳＡＮのようなストレージ・エリア・ネットワーク経由で、または任意の他の適切な種類のネットワーク及び／またはプロトコル経由で、アナログ音声ネットワークまたはデジタル・ファイバ通信ネットワークのような電気通信／電話網を介する通信を支援し得る。
【００８９】
いくつかの実施形態において、システム・メモリ３０２０は、対応する方法及び装置の実施形態を実装するために図１から図１２について上記で説明されたようなプログラム・インストラクション及びデータを格納するように構成されたコンピュータ・アクセス可能な媒体の１つの実施形態であってもよい。しかしながら、他の実施形態において、プログラム・インストラクション及び／またはデータは、異なる種類のコンピュータ・アクセス可能な媒体上で受信、送信または格納され得る。一般的に言えば、コンピュータ・アクセス可能な媒体は、磁気または光媒体、たとえば、Ｉ／Ｏインタフェース３０３０を介してコンピューティング・デバイス３０００へ連結されたディスクまたはＤＶＤ／ＣＤのような、非一時的なストレージ・メディアまたはメモリ・メディアを含み得る。また非一時的なコンピュータ・アクセス可能なストレージ・メディアは、システム・メモリ３０２０または別の種類のメモリとしてコンピューティング・デバイス３０００のいくつかの実施形態に含まれ得る、ＲＡＭ（たとえば、ＳＤＲＡＭ、ＤＤＲ  ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどのような任意の揮発性または不揮発性媒体を含むことができる。さらに、コンピュータ・アクセス可能な媒体は、ネットワーク・インタフェース３０４０を介して実装され得るような、ネットワーク及び／または無線リンクのような通信媒体を介して搬送された、電気、電磁気、またはデジタル信号のような伝送媒体または信号を含み得る。図１３で図示されたような複数のコンピューティング・デバイスの部分またはすべては、さまざまな実施形態において記載された機能性を実装するために使用され得る。たとえば、さまざまな異なるデバイス及びサーバ上で実行するソフトウェア・コンポーネントは、機能性を提供するために協力し得る。いくつかの実施形態において、記載された機能性の部分は、汎用コンピュータ・システムを使用して実装されることに加えて、またはこのことの代わりに、ストレージ・デバイス、ネットワーク・デバイス、または専用コンピュータ・システムを使用して実装され得る。用語「コンピューティング・デバイス」は、本明細書で使用される場合、少なくともすべてのこれらの種類のデバイスを指すが、これらの種類のデバイスに限定されない。
【００９０】
結論
さまざまな実施形態は、コンピュータ・アクセス可能な媒体上に前述の説明に従い実装されたインストラクション及び／またはデータを受信、送信または格納することをさらに備え得る。一般的に言えば、コンピュータ・アクセス可能な媒体は、ネットワーク及び／または無線リンクのような通信媒体を介して搬送された、電気、電磁気、またはデジタル信号のような伝送媒体または信号と同様に、磁気または光媒体、たとえば、ＲＡＭ（たとえば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどのような、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、揮発性または不揮発性媒体のようなストレージ・メディアまたはメモリ・メディアを含み得る。
【００９１】
図面で図示され本明細書で記載されたようなさまざまな方法は、方法の例示的な実施形態を表す。この方法は、ソフトウェア、ハードウェア、またはそれらの組み合わせに実装され得る。方法の順序は、変更され得、さまざまな要素は、追加、記録、結合、省略、変更などをされ得る。
【００９２】
さまざまな修正及び変更は、本開示の利益を有する当業者に明らかであるように行われ得る。すべてのこのような修正及び変更ならびに、それに応じて、限定的というよりも例示的な意味にとらえられる上記の説明を包含することを意図する。
【００９３】
本開示の実施形態は、以下の条項の観点で記載されることが可能である。
【００９４】
[条項１]
プロビジョニングされた作業負荷のそれぞれの速度を実現するために、マルチテナント・ストレージ・サービスで実現された複数のブロックレベル・ストレージ・デバイスの各々のためにアドミッション制御パラメータのそれぞれのセットを確立し、
前記マルチテナント・ストレージ・サービスのクライアント側コンポーネントにより、第一ストレージ・サーバで実現された第一ブロックレベル・ストレージ・デバイスの少なくとも１部を特定の期間中に対象とすることを期待された作業要求の特定の速度の推定値を生成し、前記特定の速度が最初にプロビジョニングされた速度を超え、
前記クライアント側コンポーネントにより、それぞれのプロビジョニングされた速度より低い作業要求のそれぞれの速度を予測する、第二ストレージ・サーバを含む、１つ以上の他のストレージ・サーバを識別し、
前記第一ストレージ・サーバが前記最初にプロビジョニングされた速度より高い速度で作業要求を完了するために前記特定の期間中に十分な作業負荷容量を有することを検証し、
前記第一ブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記第一ストレージ・サーバが前記特定の期間中に前記最初にプロビジョニングされた速度を超える速度までで作業要求を受け入れることを可能にし、
前記第二ストレージ・サーバで少なくとも１つの特定のブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記第二ストレージ・サーバが前記特定の期間中に前記第二ストレージ・サーバのプロビジョニングされた速度を超えない速度で作業要求を受け入れることを可能にする、
ように構成された１つ以上のコンピューティング・デバイス、
を備える、システム。
[条項２]
前記クライアント側コンポーネントの少なくとも１部は、マルチテナント・コンピューティング・サービスのインスタンス・ホストで仮想化管理ソフトウェア・スタック内に実現される、条項１に記載の前記システム。
[条項３]
前記第一ブロックレベル・ストレージ・デバイスの前記少なくとも１つのアドミッション制御パラメータを変更するために、前記１つ以上のコンピューティング・デバイスは、前記第一ブロックレベル・ストレージ・デバイスと関連した作業トークン・バケットのトークン補充速度を増加させるようにさらに構成される、条項１に記載の前記システム。
[条項４]
前記第一ブロックレベル・ストレージ・デバイスの前記部分は、特定のクライアントのために確立されたマルチパーティション・ブロックレベル・ボリュームの第一パーティションを備え、前記第二ストレージ・サーバで前記特定のブロックレベル・ストレージ・デバイスの少なくとも１部は、前記マルチパーティション・ブロックレベル・ボリュームの第二パーティションを備える、条項１に記載の前記システム。
[条項５]
前記１つ以上のコンピューティング・デバイスは、
前記特定の期間後に、前記第一ブロックレベル・ストレージ・デバイスの特定のアドミッション制御パラメータをリセットし、前記第一ストレージ・サーバが前記最初にプロビジョニングされた速度を超えない作業要求を受け入れることを可能にする、
ようにさらに構成される、条項１に記載の前記システム。
[条項６]
前記特定のアドミッション・パラメータをリセットするために、リセット期間にわたり減衰関数に従い、前記特定のアドミッション制御パラメータの値を第一設定から第二設定へ変更する、条項５に記載の前記システム。
[条項７]
前記特定のアドミッション・パラメータをリセットするために、ステップ関数に従い、前記特定のアドミッション制御パラメータの値を第一設定から第二設定へ変更する、条項５に記載の前記システム。
[条項８]
１つ以上のコンピューティング・デバイスにより、
それぞれの作業負荷制限を実装するために、ストレージ・サービスに実装された複数のブロックレベル・ストレージ・デバイスのために１つ以上のアドミッション制御パラメータのそれぞれのセットを確立し、
前記ストレージ・サービスのクライアント側コンポーネントにより、第一ストレージ・サーバで実装された第一ブロックレベル・ストレージ・デバイスの少なくとも１部を特定の期間中に対象とするように期待された作業要求の特定の速度の推定値を生成し、前記作業要求の特定の速度が前記第一ブロックレベル・ストレージ・デバイスと関連した第一速度を超え、
前記クライアント側コンポーネントにより、前記特定の期間中に対象とする作業要求の第二速度が前記特定のブロックレベル・ストレージ・デバイスと関連した第二速度より低いことを予測される特定のブロックレベル・ストレージ・デバイスの少なくとも１部を識別し、
前記第一ブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記第一マルチテナント・ストレージ・サーバが前記第一速度を超える速度で前記第一ブロックレベル・ストレージ・デバイスを対象とする作業要求を受け入れることを可能にする、
ことを実行する、ことを備える、方法。
[条項９]
前記第一ストレージ・サーバは、前記サービスの複数のクライアントのブロックレベル・ストレージ・デバイスを実装するように構成される、条項８に記載の前記方法。
[条項１０]
前記１つ以上のコンピューティング・デバイスにより、
前記変更前に、前記第一ストレージ・サーバが前記第一速度を超える前記速度で作業要求を完了するために前記特定の期間中に十分な作業負荷容量を有することを検証する、
ことを実行することをさらに備える、条項８に記載の前記方法。
[条項１１]
前記１つ以上のコンピューティング・デバイスにより、
前記特定のブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記対応するストレージ・サーバが前記第二速度を超えない速度で作業要求を受け入れることを可能にする、
ことを実行することをさらに備える、条項８に記載の前記方法。
[条項１２]
前記クライアント側コンポーネントの少なくとも１部は、マルチテナント・コンピューティング・サービスのインスタンス・ホストで仮想化管理ソフトウェア・スタック内に実装される、条項８に記載の前記方法。
[条項１３]
前記第一ブロックレベル・ストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを前記変更することは、前記第一ブロックレベル・ストレージ・デバイスと関連した作業トークン・バケットのトークン補充速度を増加させることを備える、条項８に記載の前記方法。
[条項１４]
前記第一ブロックレベル・ストレージ・デバイスの前記部分は、特定のクライアントのために確立されたマルチパーティション・ブロックレベル・ボリュームの第一パーティションを備え、前記特定のブロックレベル・ストレージ・デバイスの前記部分は、前記マルチパーティション・ブロックレベル・ボリュームの第二パーティションを備える、条項８に記載の前記方法。
[条項１５]
前記１つ以上のコンピューティング・デバイスにより、
前記特定の期間後に、前記第一ブロックレベル・ストレージ・デバイスの特定のアドミッション制御パラメータをリセットし、前記第一ストレージ・サーバが前記第一速度を超えない作業要求を受け入れることを可能にする、
ことを実行することをさらに備える、条項８に記載の前記方法。
[条項１６]
前記１つ以上のコンピューティング・デバイスにより、
第一インスタンス・ホストで第一コンピュート・インスタンス及び第二インスタンス・ホストで第二コンピュート・インスタンスを含む複数のコンピュート・インスタンスに前記第一ブロックレベル・ストレージ・デバイスを接続し、前記クライアント側コンポーネントは、前記第一インスタンス・ホストでインスタンス化され、
前記第一インスタンス・ホストで前記クライアント側コンポーネントにより、前記第二インスタンス・ホストで第二クライアント側コンポーネントの作業負荷レベルの指標を取得し、前記少なくとも１つのアドミッション制御パラメータへ行われる変更を決定する、
ことを実行することをさらに備える、条項８に記載の前記方法。
[条項１７]
前記第二クライアント側コンポーネントの前記作業負荷レベルの前記指標は、前記第一インスタンス・ホストで前記第一ストレージ・サーバから前記クライアント側コンポーネントへ提供される、条項１６に記載の前記方法。
[条項１８]
１つ以上のプロセッサで実行されるときに、
ストレージ・サービスの第一ストレージ・サーバに実装された第一ブロック・ストレージ・デバイスの少なくとも１部を特定の期間中に対象とすることを期待された作業要求の特定の速度の推定値を生成し、前記作業要求の特定の速度が前記第一ブロック・ストレージ・デバイスと関連した第一速度を超え、
前記ストレージ・サービスのクライアント側コンポーネントで、前記特定の期間中に特定のブロック・ストレージ・デバイスの少なくとも１部を対象とする作業要求の第二速度が前記特定のブロック・ストレージ・デバイスと関連した第二速度未満であることを予測される少なくとも１つの他のストレージ・サーバを識別し、
前記第一ブロック・ストレージ・デバイスと関連した少なくとも１つのアドミッション制御パラメータを変更し、前記第一ストレージ・サーバが前記第一速度を超える速度で作業要求を受け入れることを可能にする、
プログラム・インストラクションを格納する非一時的なコンピュータ・アクセス可能なストレージ・メディア。
[条項１９]
前記第一ストレージ・サーバは、前記ストレージ・サービスの複数のクライアントのストレージ・デバイスを実装するように構成される、条項１８に記載の前記非一時的なコンピュータ・アクセス可能なストレージ・メディア。
[条項２０]
前記インストラクションは、前記１つ以上のコンピューティング・デバイス上で実行されるときに、
前記少なくとも１つのアドミッション制御パラメータを変更する前に、前記第一ストレージ・サーバが前記第一速度を超える前記速度で作業要求を完了するために前記特定の期間中に十分な作業負荷容量を有することを期待されることを検証する、
条項１８に記載の前記非一時的なコンピュータ・アクセス可能なストレージ・メディア。
[条項２１]
前記インストラクションは、前記１つ以上のコンピューティング・デバイス上で実行されるときに、
前記特定のストレージ・デバイスの少なくとも１つのアドミッション制御パラメータを変更し、前記他のストレージ・サーバが前記第二速度を超えない速度で作業要求を受け入れることを可能にする、
条項１８に記載の前記非一時的なコンピュータ・アクセス可能なストレージ・メディア。
[条項２２]
前記クライアント側コンポーネントの少なくとも１部は、マルチテナント・コンピューティング・サービスのインスタンス・ホストで仮想化管理ソフトウェア・スタック内に実装される、条項１８に記載の前記非一時的なコンピュータ・アクセス可能なストレージ・メディア。
【図１】
0006290462.tif 000002
【図２】
0006290462.tif 000003
【図３】
0006290462.tif 000004
【図４】
0006290462.tif 000005
【図５】
0006290462.tif 000006
【図６】
0006290462.tif 000007
【図７】
0006290462.tif 000008
【図８】
0006290462.tif 000009
【図９】
0006290462.tif 000010
【図１０】
0006290462.tif 000011
【図１１】
0006290462.tif 000012
【図１２】
0006290462.tif 000013
【図１３】
0006290462.tif 000014