JP6130518B2 - インスタンスホストの構成 - Google Patents

Description

多くの会社及び他の組織は、該会社及び組織の運営をサポートするために、多数のコンピューティングシステムを、（例えば、ローカルネットワークの一部として）同じ場所に位置する、または代わりに（例えば、１つ以上のプライベートまたはパブリック中間ネットワークを介して接続される）複数の異なる地理的な場所に位置するコンピューティングシステム等と相互接続する、コンピュータネットワークを運営している。例えば、単一の組織によって運営され、かつ該組織を代表するプライベートデータセンター、及びコンピューティングリソースを顧客に提供するビジネスとして事業団体によって運営されるパブリックデータセンター等の、膨大な数の相互接続されるコンピューティングシステムを収容するデータセンターが一般的になってきている。いくつかのパブリックデータセンターの運営者は、種々の顧客によって保有されるハードウェアのためのネットワークアクセス、電力、及び安全な設置設備を提供する一方で、他のパブリックデータセンターの運営者は、それらの顧客が使用するために利用できるようにされるハードウェアリソースも含む「フルサービス」の設備を提供する。しかしながら、代表的なデータセンターの規模及び範囲が増大するにつれて、物理的なコンピューティングリソースを提供、監督、及び管理するタスクがますます複雑になってきている。

商品ハードウェアのための仮想化技術の出現により、多様なニーズを有する多数の顧客のための大規模なコンピューティングリソースの管理に関して利益をもたらし、それにより、種々のコンピューティングリソースを、複数の顧客によって効率的かつ安全に共有することが可能になる。例えば、仮想化技術は、単一の物理的コンピューティングマシンによってホストされる１つ以上の仮想マシンを各ユーザに提供することによって、単一の物理的コンピューティングマシンを複数のユーザの間で共有することを可能にし得、そのような仮想マシンのそれぞれは、ユーザが所与のハードウェアコンピューティングリソースの唯一のオペレータかつ管理者であるという錯覚をユーザに提供する異なる論理コンピューティングシステムとして機能する一方で、種々の仮想マシン間でのアプリケーションの隔離及び安全性も提供する、ソフトウェアシミュレーションである。さらに、いくつかの仮想化技術は、複数の異なる物理的コンピューティングシステムにわたる複数の仮想プロセッサを有する単一の仮想マシン等の、２つ以上の物理的リソースにわたる仮想リソースを提供することができる。

仮想化された計算、記憶、及びネットワーキングリソースといった、プロバイダによってサポートされる機能及び特徴が成長するにつれて、また、大規模プロバイダによって使用される一団のハードウェアプラットフォームが成長するにつれて、プラットフォームに対する構成の変更等の管理上の制御動作を実装するタスク自体がリソースに集中するようになる可能性がある。制御及び構成動作のオーバーヘッドは、いくつかの事例において、ユーザによって知覚される程度に、仮想化リソースの応答性に影響を与え始めることさえあり得る。

少なくともいくつかの実施形態による、例示的なシステム環境を例示する図である。 少なくともいくつかの実施形態による、インスタンスホストプラットフォームのリモート構成用に構成される制御サーバの例示的な構成要素を例示する図である。 少なくともいくつかの実施形態による、インスタンスホストプラットフォームの例示的な構成要素を例示する図である。 少なくともいくつかの実施形態による、クライアントと、制御サーバと、インスタンスホストプラットフォームとの間の例示的な相互作用を例示する図である。 少なくともいくつかの実施形態による、制御サーバでワークフローマネージャノードから開始するコマンドフローの実施例を例示する図である。 少なくともいくつかの実施形態による、インスタンスホストプラットフォームの登録と関連付けられる例示的な動作を例示する図である。 少なくともいくつかの実施形態による、リソースインスタンスを起動することと関連付けられる例示的な動作を例示する図である。 少なくともいくつかの実施形態による、制御サーバからインスタンスホストに発行される例示的なコマンド要求の要素を例示する図である。 少なくともいくつかの実施形態による、インスタンスホストのリモート構成を行うように動作可能な制御サーバの動作の態様を例示するフロー図である。 少なくともいくつかの実施形態による、制御サーバでのリモートイベント通知に関連する動作の態様を例示するフロー図である。 少なくともいくつかの実施形態による、制御サーバのプールサイズを決定することに関連する動作の態様を例示するフロー図である。 少なくともいくつかの実施形態による、サードパーティプラットフォームのリモート構成を管理するように構成される制御サーバの動作の態様を例示するフロー図である。 少なくともいくつかの実施形態による、プロバイダネットワークによって、及びサードパーティによってサポートされる計算リソースインスタンス定義の実施例を例示する図である。 少なくともいくつかの実施形態による、サードパーティプラットフォームのプラットフォーム承認要求に応答して、プロバイダネットワークの制御サーバによって行われる動作の態様を例示するフロー図である。 クライアントが、プロバイダネットワークの制御サーバ構成要素によって制御されるサードパーティプラットフォーム上でインスタンス化されるインスタンスを含むリソースインスタンスを、複数のプロバイダから選択することを可能にするように実装され得る、プログラマチックユーザインターフェースの実施例を例示する図である。 少なくともいくつかの実施形態において使用され得る例示的なコンピューティングデバイスを例示するブロック図である。

実施形態は、複数の実施形態及び実例となる図面について一例として本明細書で説明されるが、当業者は、実施形態が、説明される実施形態または図面に限定されないことを認識するであろう。図面及びその詳細な説明は、実施形態を、開示される特定の形態に限定することを意図するものではなく、逆に、添付の特許請求の範囲によって定義される趣旨及び範囲の範囲内に含まれる全ての修正物、均等物、及び代替物を対象とすることを意図することを理解されたい。本明細書で使用される見出しは、編成目的のために過ぎず、説明または特許請求の範囲を限定するために使用されることを意味していない。本出願の全体を通して使用される「してもよい／し得る（ｍａｙ）」という用語は、義務的な意味（すなわち、「〜しなければならない」という意味）ではなく、許容的な意味（すなわち、「〜する可能性がある」という意味）で使用される。同様に、「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、及び「含む（ｉｎｃｌｕｄｅｓ）」という用語は、「含むが、それらに限定されない」ことを意味する。

低オーバーヘッドリソースインスタンスのホスト構成のための方法及び装置の種々の実施形態が説明される。インターネット及び／または他のネットワークを介して、分散した１組のクライアントにアクセス可能な（種々のタイプのクラウドに基づくコンピューティングまたは記憶等の）１つ以上のマルチテナントサービスを提供するために、企業または公的部門の組織等のエンティティによってセットアップされるネットワークは、この文書で、プロバイダネットワークと称され得る。「マルチテナント」という用語は、それぞれのカスタマイズ可能な隔離されたサービスのビューが異なるクライアントエンティティに提供されるような様式で、アプリケーション及び／またはデータ仮想化を実装するように設計され、よって、所与の１組の下層のリソースを使用してサービス機能の一部分が提供されている１つのクライアントが、その１組のリソースが他のクライアントにも使用されていることを認識しない場合がある、サービスを指すために本明細書で使用され得る。プロバイダネットワークは、いくつかの実施形態において、マルチテナントサービスに加えて、またはその代わりに、（プライベートクラウドの実装等のための）単一のテナントサービスをサポートし得る。そのようなプロバイダネットワークは、プロバイダによって提供されるインフラストラクチャ及びサービスを実装し、構成し、そして配信するために必要とされる、一群の物理的及び／または仮想化コンピュータサーバ、記憶デバイス、ネットワーキング装置、ならびに同類のもの等の、種々のリソースプールをホストする多数のデータセンターを含み得る。プロバイダネットワークのリソースのサブセットは、いくつかの実施形態において、仮想もしくは物理的計算インスタンス、記憶インスタンス、またはネットワークリソースインスタンス等の「インスタンス」と呼ばれるユニットにおけるクライアントによる予約（及び該クライアントへの割り当て）のために提供され得る。仮想計算インスタンスは、例えば、指定された計算容量（ＣＰＵのタイプ及び数、メインメモリのサイズ、記憶デバイスの数及びサイズ等を示すことによって指定され得る）と、指定されたソフトウェアスタック（例えば、次にハイパーバイザー上で動作し得る、特定のバージョンのオペレーティングシステム）とを有する１つ以上のサーバを備え得る。仮想計算インスタンス、記憶リソースインスタンス、またはネットワークリソースインスタンスを含む、種々の種類のリソースインスタンスは、本明細書で「インスタンスホストプラットフォーム」または「インスタンスホスト」と称されるシステム上でインスタンス化され得る。いくつかの実施形態において、特定のタイプのＮ個の異なる仮想計算インスタンスをインスタンス化することができるインスタンスホストプラットフォームは、例えば、一般的にごく僅かなハードウェアサーバの計算能力を利用する仮想化ソフトウェア及び／またはオペレーティングシステムソフトウェア等の、最初にインストールされる選択された１組の比較的低レベルのソフトウェア構成要素を有するハードウェアサーバを備え得る。より多くの仮想計算インスタンスが起動されるにつれて、例えば異なる仮想計算インスタンス上で実行するクライアントアプリケーションに対して、より多くのサーバの計算能力部分が使用され得る。異なる実施形態においてプロバイダネットワークのリソースを実装するために、汎用または専用コンピュータサーバ、記憶デバイス、ネットワークデバイス、及び同類のものを含む、いくつかの異なるタイプのコンピューティングデバイスが単独でまたは組み合わせて使用され得る。下で説明されるように、いくつかの実施形態において、プロバイダネットワークリソースのサブセットは、制御及び構成の目的（例えば、クライアントの要求に応答したインスタンスホスト上でのリソースインスタンスの起動、監視、及び終了）専用であり得る。そのような専用の制御リソースは、本明細書で「制御プレーンリソース」、「制御プレーンサーバ」または「制御サーバ」と称され得る。少なくともいくつかの実施形態では、下でさらに詳細に説明されるように、プロバイダネットワーク内のインスタンスホスト上でリソースインスタンスを構成するために使用することに加えて、所与のプロバイダネットワークの少なくともいくつかの制御サーバはまた、プロバイダネットワークの外部のリモートプラットフォームで、例えばサードパーティのデータセンターもしくは設備で、または存在点の場所もしくは類似する設備でホストされるインスタンスをリモートに構成することも可能であり得る。

一実施形態によれば、インスタンスを管理するための制御ソフトウェアは、インスタンスホストに課される管理オーバーヘッドを最小にするような方法で実装され得る。構成関連の処理の多くは、そのような実施形態において、インスタンスホストから外され得、よって、高レベルの決定及びメタデータの操作が制御サーバで実装され得る一方で、単純な低レベルの（及び一般的に冪等及びステートレスの）構成関連のコマンドだけをインスタンスホスト自体で実行しなければならない場合がある。そのような実施形態では、インスタンスホストで理解するために、インスタンス状態及びインスタンスタイプ定義に関する詳細が必要とされ得ない。例えば、そのような一実施形態では、制御サーバで層状制御ソフトウェアアーキテクチャが用いられ得、該制御サーバでは、ワークフローマネージャ構成要素を呼び出すことによって、インスタンス状態マネージャがクライアントのインスタンス構成要求に応答する。ワークフローマネージャは、（クライアントのインスタンス構成要求に応答して、インスタンス状態マネージャが到達する）より高レベルの構成決定を、制御ソフトウェアの構成デファイナ構成要素によって提供されるインスタンス構成定義との関連において、その構成定義に固有の１つ以上のより低レベルのワークフロー動作に翻訳し得る。ワークフローマネージャは、次に、ワークフロー動作を、制御サーバの制御ソフトウェアのコマンドコミュニケータ構成要素に伝送し得る。コマンドコミュニケータは、所与のワークフロー動作に対応する１つ以上の低レベルコマンド（オペレーティングシステムコマンドまたは仮想化ソフトウェアコマンド）を、コマンドプロトコルに従って、ネットワークを通じて、特定のインスタンスホストに安全に提出し得る。

インスタンスホストで、コマンド受信機（単純なウェブサーバ等）は、リモートコマンドエグゼキュータ（ＲＣＥ）をインスタンス化することによって、コミュニケータからの所与のコマンドに応答し得る。ＲＣＥは、要求に応じてコマンド受信機によってスポーンされる単一の実行スレッド（またはソフトウェアプロセス）を含み得、少なくともいくつかの実施形態において、一般的にインスタンスホスト上の仮想化ソフトウェア構成要素に、またはインスタンスホストのオペレーティングシステム構成要素に向けられる、１つ以上の動作を発行するのに十分な長さだけアクティブな状態を維持し得る。ＲＣＥは、そのような実施形態において、動作が開始された後に、抜けるか、または終了し得る。コマンド受信機は、ＲＣＥの動作によって生成される戻りコード、標準出力、または誤り出力をコマンドコミュニケータに提供し得る。これらの結果は、要求されたコマンドの成功または失敗を判定するために制御サーバで翻訳され得、いくつかの実施形態では、判定に応じて、クライアントのインスタンス構成要求に対する応答が作成され得る。したがって、インスタンスホストのインスタンス構成オーバーヘッドは、そのような実施形態において、主に、ＲＣＥのインスタンス化及びＲＣＥによって要求される動作に限定され得、それによって、クライアントが要求するリソースインスタンス自体に使用するためのインスタンスホストリソースの大部分を確保する。いくつかの実装形態において、制御サーバソフトウェアの異なる層の構成責任のカプセル化は、数百または数千のインスタンスホストを、単一の制御サーバまたはいくつかの制御サーバからリモートに構成することを可能にするのに十分効率的であり得る。

少なくともいくつかの実施形態において、ＲＣＥをインスタンス化することは、例えばウェブサーバによって、共通ゲートウェイインターフェース（ＣＧＩ）に従って、少なくとも１つの実行のスレッドをインスタンス化することを含む。ＨＴＴＰＳ（安全なバージョンのＨＴＴＰ（ハイパーテキストトランスファープロトコル））等の効率的で良く知られているプロトコルは、いくつかの実施形態において、コマンドをインスタンスホストに伝送するために、及び／またはインスタンスホストから結果を受け取るために使用され得る。コマンド自体は、いくつかの実施形態において、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔオブジェクト表記法）またはＸＭＬ（拡張マークアップ言語）のいくつかの変形等の、業界標準のフォーマットまたは表記法でフォーマットされ得る。他の実施形態では、プライベートもしくは独自のプロトコル及び／またはフォーマットが使用され得る。使用するコマンドプロトコルは、少なくとも１つのサブセットが冪等であるように設計される複数のコマンドタイプをサポートし得、例えば、所与の１組のパラメータを有する特定の冪等コマンド「ｃｍｄ１」が２度以上発行された場合、コマンドの２番目の発行及び任意のその後の発行は、いかなる悪影響も及ぼし得ない。

いくつかの実施形態において、プロバイダネットワークは、複数の地理的領域に組織され得、各領域は、１つ以上の可用性コンテナを含み得、それは、本明細書で「可用性ゾーン」と称され得る。次に、可用性コンテナは、所与の可用性コンテナのリソースが他の可用性コンテナの不具合から保護されるような方法で設計される、１つ以上の異なる場所またはデータセンターを備え得る。すなわち、１つの可用性コンテナの不具合は、任意の他の可用性コンテナの不具合をもたらすと予測され得ず、したがって、リソースインスタンスまたは制御サーバの可用性プロファイルは、異なる可用性コンテナのリソースインスタンスまたは制御サーバの可用性プロファイルとは関係ないことが意図される。クライアントは、それぞれの可用性コンテナの複数のアプリケーションインスタンスを起動することによって、クライアントのアプリケーションを単一の場所の不具合から保護することが可能であり得る。同時に、いくつかの実装形態では、同じ地理的領域内に存在するリソースインスタンス間で、安価で低待ち時間のネットワーク接続性が提供され得る（また、同じ可用性コンテナのリソース間のネットワーク伝送は、さらに速くなり得る）。いくつかのクライアントは、クライアントのアプリケーションの種々の構成要素を正確にどこで動作させるかという所望の制御度を維持するために、例えば領域レベル、可用性コンテナレベル、またはデータセンターレベルのいずれかに、クライアントのリソースが予約及び／またはインスタンス化される場所を特定することを望み得る。他のクライアントは、リソースがクライアントの要件、例えば、性能、高い可用性、サポートされるソフトウェアのレベル等を満たすのであれば、クライアントのリソースが予約またはインスタンス化された正確な場所にあまり関心がない場合がある。ある可用性コンテナ（またはデータセンター）に位置する制御サーバは、いくつかの実施形態において、他の可用性コンテナ（または他のデータセンター）のインスタンスホストでリソースインスタンスをリモートに構成することが可能であり得、すなわち、特定の可用性コンテナまたはデータセンターは、ローカルリソースインスタンスを管理するために、ローカル制御サーバを有する必要がない場合がある。

少なくともいくつかの実施形態において、制御サーバは、制御サーバから管理されているリソースインスタンスで、ある特定のタイプのイベント（種々の副構成要素での予期しないシャットダウンまたは誤り等）が起こったときに、通知を受け取るように構成され得る。そのような一実施形態において、制御サーバは、インスタンスホストプラットフォームで、使用中の仮想化ソフトウェア（例えば、ハイパーバイザー）が（または使用中のオペレーティングシステムによって）提供される既存のイベントモニタを利用し得る。軽量イベントディスパッチャは、制御サーバに代わってインスタンスホストでインスタンス化され、一実装形態において、イベントモニタに加入し得る。イベントモニタが、イベントが起こったことをイベントディスパッチャに知らせたときに、そして、イベントディスパッチャが、制御サーバに対する通知がイベントに対して適切であると判定したときに、イベントディスパッチャは、対応する通知を制御サーバに（例えば、コマンドコミュニケータまたはワークフローマネージャに）伝送し得る。イベントの指示は、制御ソフトウェアスタック、例えばコマンドコミュニケータからワークフローマネージャに、及びインスタンス状態マネージャに渡され得、イベントのタイプに基づいて、必要に応じてインスタンス状態メタデータを更新し得る。いくつかの実施形態において、インスタンス状態マネージャは、イベントが予期しないシャットダウンまたは他の不具合であった場合に、回復動作を開始し得る。回復動作は、いくつかの実施形態において、他の構成動作と同じ流れに従い得、例えば、回復動作は、インスタンス状態マネージャによって開始され、ワークフローマネージャ及びコマンドコミュニケータを介して低レベルコマンドに逐次的に変換され、そして、ＲＣＥを介して実行するために、インスタンスホストでコマンド受信機に伝送され得る。

層状制御ソフトウェアアーキテクチャの設計目標の１つは、ある特定のタイプの大規模な不具合イベントからの回復を、許容可能な時間枠内で達成できることを確実にすることである。例えば、データセンター全体にわたるまたは可用性ゾーン全体にわたる不具合を低減させるために、重要な構成要素において種々のレベルの冗長性でデータセンター及び可用性ゾーンが実装され得る場合であっても、そのような大規模な不具合を１００％保証で防止することは非常に困難であり得る。プロバイダネットワークのクライアントの多くは、ミッションクリティカルな機能のためのそのリソースインスタンスに依存し得るので、そのような稀な不具合イベントからの相当に素早い回復が所望され得る。故に、少なくともいくつかの実施形態では、大規模な不具合に対する目標回復時間に基づいて、制御サーバに専用されるリソースが決定され得る。大規模な不具合が生じた場合にインスタンス回復構成動作が必要とされ得る率が推定され得る。パラメータ化されたモデルが生成され得、該モデルとしては、例えば、管理すべき不具合の規模の表示（例えば、障害対策計画を作成するべき同時のまたはほぼ同時の不具合の数）ならびに異なるデータセンターに対するそうしたインスタンスの潜在性マッピング、インスタンスを完全に再インスタンス化するために行うことが必要になる回復関連の構成動作のシーケンス、ならびにある特定のレベルの計算及びネットワーク能力を有する回復サーバが単位時間当たりに編成することが可能であり得るそのような動作の数が挙げられる。回復時間の目標を満たすために必要とされる回復動作率を含むモデルの種々のパラメータを使用して、特定の能力レベルの制御サーバの数が決定され、そして、適切なタイプの制御サーバのプールが確立され得る。いくつかの事例において、大規模な不具合イベントに応答するために必要な制御サーバの数は、正常な動作状態に必要とされる制御サーバの数を超える場合があり、その場合、プロバイダネットワークの運営者は、展開する制御サーバの数を決定する前に、大規模な不具合を取り扱うための十分な制御サーバを有していないという結論と、追加の制御サーバを維持するコストとを検討し得る。

少なくともいくつかの実施形態において、ワークフローマネージャ及びコマンドコミュニケータ等の、制御サーバの構成要素のいくつかまたは全ては、必要に応じてそのサイズを動的に増加させることができるクラスタのノードとして実装され得る。例えば、所与の時点でインスタンス化されるＷ個のワークフローマネージャ及びＣ個のコマンドコミュニケータノードが存在し得、各構成要素のためのノードの数は、所望に応じて増加または減少され得る。所与のハードウェアデバイスは、いくつかの実装形態において、所与のタイプの制御サーバ構成要素の１つ以上のノードに使用され得、例えば、Ｓ個の制御サーバを、Ｗ個のワークフローマネージャノード及びＣ個のコマンドコミュニケータノードをホストするために割り当てることが可能であり得、ここで、Ｓ≦（Ｗ＋Ｃ）である。

上で述べられるように、所与のインスタンスホストプラットフォームは、いくつかの実施形態において、複数のリソースインスタンスをサポートすることが可能であり得る。いくつかのそのような実施形態では、所与のインスタンスホスト上のリソースインスタンスとそれらを管理する制御サーバとの間の柔軟性のあるマッピングが実装され得、例えば、ホストＨ１上の１つのリソースインスタンスＲＩ−Ｘは、制御サーバＣＳ１によって管理され得る一方で、Ｈ１上の別のリソースインスタンスＲＩ−Ｙは、異なる制御サーバＣＳ２によって管理され得る。少なくともいくつかの実施形態では、競合する動作が（例えば、同じ名前を有するまたは競合する名前を有するファイルシステム等のソフトウェア記憶デバイスを作成するために２つの異なるコマンドが）試みられることを防止するために、並行処理制御機構が実装され得る。例えば、所与のインスタンスホストプラットフォーム上の並行構成動作の数は、一実装形態において、ロックを使用して制限され得る。いくつかの実施形態ではロックマネージャが実装され得、所与のインスタンスホストに対して構成動作を行う前に、該ロックマネージャから専用のロック（または共有ロックが維持されている間に許可される共有者の数及び／またはインスタンスホスト動作のタイプに対する制限を有する、共有ロック）を取得しなければならない。

少なくともいくつかの実施形態において、上で説明されるリソースインスタンス構成に使用されるモジュール的手法はまた、メトリクスの収集またはログ記録の収集等の他のタイプの動作にも使用され得る。例えば、インスタンスホストから制御サーバに（ＣＰＵ利用率、メモリ使用量、またはネットワーク使用量の測定値等の）性能情報をプッシュする代わりに、プルモデルが実装され得、該プルモデルでは、上で説明されるコマンドコミュニケータを使用して、制御サーバのメトリックコレクタ構成要素が「ｇｅｔ−ｍｅｔｒｉｃｓ」コマンドをインスタンスホストに発行し得る。ＲＣＥまたは類似する一時的なスレッドもしくはプロセスは、インスタンスホストでハイパーバイザーまたはオペレーティングシステムツールを使用して、情報を収集するためにインスタンス化され得、結果は、メトリックコレクタに送り返され得る。

クライアントが制御サーバに対してインスタンス起動要求を発行するときに、異なる実施形態では、複数の基準のうちのいずれかに基づいて、要求されたインスタンスに使用される特定のインスタンスホストが選択され得る。いくつかの事例において、インスタンスホストは、クライアントの識別情報に少なくとも部分的に基づいて選択され得、例えば、クライアントの施設に地理的に近いデータセンターを選択するために、クライアントのインターネットプロトコルアドレスまたは物理アドレスが使用され得る。クライアントが、いくつかの場所でだけ利用可能であるか、またはデータセンター間での供給もしくは需要の変動により、いくつかのデータセンターで他よりも容易に利用可能である、特定のタイプのリソースインスタンスを要求する場合、インスタンスホストは、要求されたリソースの可用性に基づいて選択され得る。いくつかの実施形態では、特定のインスタンスホストを選択するために、プライシングポリシー（例えば、ある特定の１組のインスタンスホストを使用して最も良くサポートすることができるある特定のプライスレベルに対して、クライアントが選好を表したかどうか）、ならびにプロバイダネットワーク内の現在の性能条件及び傾向が使用され得る。

いくつかの実施形態において、プロバイダネットワークの制御ソフトウェアアーキテクチャは、リモートな場所で、例えば、プロバイダネットワークの外部のデータセンターもしくは他の設備、または、プロバイダネットワークと他のネットワークとの間のアクセスポイントで、装置を使用してリソースインスタンスのインスタンス化をサポートし得る。例えば、サードパーティプロバイダは、プロバイダネットワークの制御サーバを使用して管理されるリソースインスタンスのためのハードウェアを展開することによって、データセンターで十分に活用されていないハードウェアを利用することを望み得る。別の実施例において、いくつかの実施形態では、制御サーバを使用したリモートインスタンスのために、プロバイダネットワークと関連付けられる１つ以上のインターネットの存在点（ＰＯＰ）の場所にあるホストが利用され得る。いくつかのそのようなＰＯＰの場所において、ホストの少なくともいくつかは、プロバイダネットワークのサービス（コンテンツ配信等）をサポートするように構成され得、そのようなホストは、いくつかの事例において、プロバイダネットワーク内のリソースインスタンスをインスタンス化するために使用されるインスタンスホストの大部分に一般的にインストールされる、ストリップダウンしたバージョンのソフトウェアスタックを使用し得る。そのようなストリップダウンしたホストは、制御サーバによってリソースインスタンスをインスタンス化するために使用され得る。「リモートプラットフォーム」という用語は、サードパーティによって全体が保有／管理され、プロバイダネットワークの外側に位置するプラットフォーム、またはプロバイダネットワークと電気通信プロバイダ等の他のサービスプロバイダとの間の境界であるＰＯＰもしくは類似するエンティティに位置するプラットフォームを指すために本明細書で使用され得る。同様に、「リモートな場所」という用語は、そのようなリモートプラットフォームが組み込まれる設備を指すために使用され得る。所与の制御サーバは、サードパーティプラットフォーム、ならびにまたは代わりに、いくつかの実施形態では、プロバイダネットワーク保有のインスタンスホストを管理することが可能であり得る。プロバイダネットワークの運営者は、クライアントによってアクセス可能であるリソースのプール全体を増加させ得るので、また、より良い地理的分布、システム全体にわたるリスク管理の強化、及び収益の増加にもつながり得るので、そのようなシナリオをサポートすることに前向きであり得る。そのような一実施形態において、サードパーティベンダー（またはＰＯＰの場所の運営者）は、プロバイダネットワーク保有のインスタンスホストが使用される方法に類似する様式で、仮想化リソースをホストするために使用することができる、リモートな設備に位置する候補プラットフォームを示すプラットフォーム承認リクエストを（例えば、制御サーバ構成要素によってサポートされるプログラマチックインターフェースを介して）提出し得る。それに応答して、プラットフォーム能力を検証する責任を果たす制御サーバ構成要素は、候補プラットフォームに対して１つ以上の試験を行い得る。本明細書で「能力判定動作」と称され得るそのような試験は、インストールしたソフトウェアスタックの検査、性能試験、リモートコマンドエグゼキュータ（ＲＣＥ）機構をサードパーティプラットフォーム上で成功裏に使用することができることを検証するための検査、等を含む、様々な異なる構成要素を含み得る。特定の候補プラットフォームが試験にパスした場合は、リソースインスタンスをプロバイダネットワークの制御サーバによって構成することができる、「承認された」プラットフォームに指定され得る（ハードウェアプラットフォームをインスタンスに使用する前に、いくつかの実施形態では、プロバイダネットワーク保有のハードウェアプラットフォームに対して、類似する能力試験が行われ得る）。

候補リモート（例えば、サードパーティまたはＰＯＰ）プラットフォームは、承認された後に、利用可能なインスタンスホストのプールに含まれ得、該プールからクライアントのインスタンス構成要求に応答するように選択され得る。プロバイダネットワーク保有のインスタンスホストに使用されるように、承認されたインスタンスホストプラットフォームを構成するために、類似する層状制御ソフトウェア手法が使用され得、例えば、インスタンス状態マネージャ、ワークフローマネージャ、及び制御サーバ端部のコマンドコミュニケータは、協働して、リモートコマンドエグゼキュータ（ＲＣＥ）を呼び出して、サードパーティプラットフォームに対してローカル構成動作を行い得る。制御サーバとプロバイダネットワークの内部インスタンスホストとの間の通信の場合のように、少なくともいくつかの実装形態では、安全なネットワーキングプロトコルが使用され得る。いくつかの実装形態では、コマンドコミュニケータによってトンネリングプロトコルが使用され得、または制御サーバとインスタンスホストプラットフォームとの間の通信を中継するためにプロキシが使用され得る。少なくともいくつかの実施形態では、制御サーバが、一般的にファイアウォール等のネットワークセキュリティバリアによって外部トラフィックから保護されるサードパーティプラットフォームと通信することを可能にするために、トンネリングまたは他の類似する技法が使用され得る。

少なくともいくつかの実施形態において、プロバイダネットワークは、そのインスタンスホストを使用して１組のリソースインスタンスタイプをサポートし得、例えば、「小」、「中」、及び「大」インスタンスが、各タイプによってサポートされる能力及び特徴のそれぞれの定義によって、仮想化計算リソースに対してサポートされ得る。サードパーティプラットフォームはまた、いくつかの事例において、これらの同じタイプのインスタンスもサポートし得、それによって、サードパーティプラットフォームをプロバイダネットワークのインフラストラクチャの中へ殆ど継ぎ目なく統合することを可能にする。例えば、下層のハードウェアまたはソフトウェアは、プロバイダネットワークが定義したインスタンスタイプと完全に適合していないので、またはサードパーティは、該サードパーティの提供物とプロバイダネットワークによって提供されるインスタンスタイプとを区別することを望むので、または他の何らかの理由で、いくつかの実施形態において、サードパーティは、保有するインスタンスタイプを定義することを許可され得る。プロバイダネットワークは、そのような実施形態においてクライアントが取得し得る全ての異なるインスタンスタイプを示す、クライアントに面するインターフェース（例えば、ウェブサイトまたはアプリケーションプログラミングインターフェース（ＡＰＩ））を実装し得、例えば、インターフェースは、プロバイダネットワークのインスタンスタイプ、ならびにプロバイダネットワークの制御サーバを使用して種々のサードパーティパートナーによってサポートされる追加的なインスタンスタイプを示し得る。いくつかの実施形態において、サードパーティからプロバイダネットワークへのプラットフォーム承認要求またはいくつかの追加的な通信は、サードパーティがサポートすることを望むインスタンスタイプの指示を含み得る。一実施形態において、サードパーティプロバイダは、サポートされるインスタンスタイプ定義に従って候補プラットフォームの能力を検査するために、試験の提案（または実際の試験）を提供し得る。

上で説明される柔軟性のある制御プレーンアーキテクチャはまた、いくつかの実施形態において、プロバイダネットワークの外側の種々のデータセンターに位置するプラットフォームを収容することが可能であり得、クライアント保有の十分に利用されていないハードウェアプラットフォームをクライアントが展開するための、または十分に利用されているクライアント側プラットフォームに対してさえも制御プレーンアーキテクチャを利用するための機会も提供し得る。例えば、一実施形態において、サードパーティがインスタンスをホストするために承認されたプラットフォームを獲得し得るのと同じように、プロバイダネットワークのクライアントは、クライアントのネットワークまたは承認されたデータセンター内に存在するプラットフォームを獲得し得る。クライアントのプラットフォームがインスタンスの展開を承認されると、プラットフォーム上でインスタンスを構成するために、プロバイダネットワーク内の制御サーバが使用され得る。
例示的なシステム環境

図１は、少なくともいくつかの実施形態による、例示的なシステム環境を例示する。示されるように、システムは、いくつかの制御サーバプール１２０（プール１２０Ａ、１２０Ｂ、及び１２０Ｃ等）と、インスタンスホストプール１１０（プール１１０Ａ、１１０Ｂ、及び１１０Ｃ等）とを備える、プロバイダネットワーク１０２を含み得る。制御サーバプール１２０は、例えば、クライアント１５０（クライアント１５０Ａまたは１５０Ｂ等）から制御サーバによって受け取られるインスタンス構成要求１７０に応答して、インスタンスプール１１０のインスタンスホストに提出されるコマンドを介して、インスタンスホスト上でリモートに構成動作を行うように構成される、複数のハードウェア及び／またはソフトウェア制御サーバを備え得る。どのタイプのリソースインスタンスを所与のインスタンスホストに実装するかの決定、インスタンス状態情報、及びインスタンスをインスタンス化するために使用される構成定義／レイアウトに関連する処理等の、構成関連の処理の大部分は、例えば図２に関して下でさらに詳細に説明される種々の構成要素を使用して、制御サーバ上で行われ得る。プール１２０の制御サーバは、プール１１０のインスタンスホストで実行するために、比較的低レベルのシーケンス（例えば、ハイパーバイザーレベルまたはオペレーティングシステムレベルのコマンド）を伝送し得、そこでは、一般的に、一時的なリモートコマンドエグゼキュータ（ＲＣＥ）は、要求されたコマンドまたはコマンドシーケンスを実行し、戻り値を提供し、次いで、抜けるかまたは終了するようにインスタンス化され得る。いくつかの実施形態において、コマンドは、少なくともいくつかの冪等動作をサポートするコマンドプロトコルに従ってフォーマットされ得、よって、コマンド要求が何らかの形で喪失または無視されるか、または戻り値が喪失または無視される場合であっても、コマンドは、一般的に、否定的な結果を伴わずに、再発行され得る。

各インスタンスホストプール１１０Ａは、示される実施形態において、仮想化計算サーバ、仮想化記憶リソース、及び／または仮想化ネットワークリソース等の、種々のタイプの１つ以上のリソースインスタンスにそれぞれ適応させることができる、いくつかのインスタンスホストプラットフォームを備え得る。所与のプール内に含まれるインスタンスホストの数は、インフラストラクチャの制約（例えば、プロバイダネットワークのデータセンターにおける空き、帯域幅、または電力制限）または種々のタイプのリソースインスタンスに対する要求等の、種々の因子に基づいて決定され得る。異なるインスタンスタイプ（例えば、「大」と「小」との仮想計算インスタンス）がサポートされる、及び／または異なるプライシングポリシー（長期予約とオンデマンドと「スポット」とのプライシング等）がサポートされるいくつかの実施形態において、いくつかのインスタンスホストプールは、特定のインスタンスタイプのインスタンス、または特定のプライシングポリシーに従ってプライシングされるインスタンスを提供するために専用され得る。特定のクライアント１５０のインスタンスが起動される特定のインスタンスホストは、局所性（例えば、クライアントの施設もしくはネットワークに対する、またはクライアントによって使用されている他のインスタンスホストに対する物理的な近接性）、クライアントによって要求されるインスタンスタイプ、クライアントによって要求されるプライシングポリシー、またはプロバイダネットワーク内の現在のもしくは予想されるリソース使用傾向（例えば、最近の期間を通じて低レベルのＣＰＵまたはネットワーク利用率であったインスタンスホストは、非常に混雑したインスタンスホストを好み得る）等の、種々の因子に基づいて選択され得る。

示されるように、プロバイダネットワークのインスタンスホストプール１１０及び制御サーバプール１２０は、示される実施形態において、種々の可用性コンテナ１０５の間で分散され得、例えば、可用性コンテナ１０５Ａは、インスタンスホストプール１１０Ａと制御サーバプール１２０Ａとを備え、可用性コンテナ１０５Ｂは、インスタンスホストプール１１０Ｂと制御サーバプール１２０Ｂとを備え、可用性コンテナ１０５Ｃは、インスタンスホストプール１１０Ｃを備え、一方で、可用性コンテナ１０５Ｄは、制御サーバプール１２０Ｃを備える。各可用性コンテナ１０５は、他のコンテナのプロファイルとは関係なく可用性プロファイルまたは不具合プロファイルを有するように設計され得、よって、ある可用性コンテナ１０５において経験する不具合（停電等）が、他の可用性コンテナ内の不具合と相関するものと予想され得ない。１６０Ａ、１６０Ｂ、１６０Ｃ等の両端矢印１６０は、示される実施形態において、（プール１２０の制御サーバから送られる）構成コマンド及び（プール１１０のインスタンスホストから送られる）構成コマンドの結果に関連する相互作用を示す。矢印１６０Ｃで示されるように、（１０５Ｂ等の）所与の可用性コンテナの中の制御サーバは、（１０５Ｃ等の）異なる可用性コンテナの中、ならびにそれらが保有する可用性コンテナ内のインスタンスホストの構成を管理し得る。種々の実施形態において、いくつかの可用性コンテナ（例えば、１０５Ａ及び１０５Ｂ）は、インスタンスホストプールならびに制御サーバプールを備え得、他のもの（例えば、１０５Ｄ）は、インスタンスホストプールを含まない場合があり、また、いくつか（例えば、１０５Ｃ）は、制御サーバプールを含まない場合がある。所与のクライアントは、いくつかの実施形態において、インスタンス構成要求を種々の制御サーバに提出し得、例えば、クライアント１５０Ｂは、要求１７０Ｂをプール１２０Ｂならびにプール１２０Ｃの制御サーバに提出し得る。所与のインスタンスホストプール１１０は、示される実施形態において、プール１２０Ｂ及び１２０Ｃの制御サーバによって管理されるインスタンスホストプール１１０Ｃの場合のように、１つ以上の制御サーバプールから管理され得る。

図１はまた、プロバイダネットワーク１０２の外部のサードパーティプラットフォームの構成に対するサポートも例示する。示される実施形態において、プロバイダネットワークのプール１２０Ａの制御サーバは、サードパーティネットワーク１２５Ａの承認されたインスタンスホスト候補プラットフォーム１３５Ａで、リソースインスタンスの構成をリモートに制御し得る一方で、プール１２０Ｂまたは１２０Ｃの制御サーバは、サードパーティネットワーク１２５Ｂの承認されたインスタンスホスト候補プラットフォーム１３５Ｂで、インスタンスを構成することが可能であり得る。所与の制御サーバは、示される実施形態において、サードパーティプラットフォームならびにプロバイダネットワーク保有のインスタンスホストを管理することが可能であり得る。ネットワーク１２５Ａまたは１２５Ｂの運営者等のサードパーティプロバイダは、いくつかの実施形態において、プロバイダネットワーク１０２内のサーバ構成要素を制御するために、該運営者がインスタンスをホストすることを承認させたい候補プラットフォームを示す、プラットフォーム承認要求を提出し得る。能力判定試験は、制御サーバからの候補プラットフォームで開始され得、例えば、候補プラットフォームがインスタンスを構成するために必要とされるＲＣＥ機能をサポートすることができるかどうか、プラットフォームが所望の性能、可用性、信頼性レベルをサポートすることができるかどうか、及び／またはプラットフォームが所望のソフトウェアスタックをサポートすることができるかどうかを判定する。プラットフォームは、承認されると、インスタンスホストプールに（例えば、特別なサードパーティインスタンスホストプールに、または既にプロバイダネットワーク内にセットアップされたインスタンスホストのうちの１つに）含まれ、そして、プロバイダネットワークの任意の他のインスタンスホストに類似する様式で処理され得る。いくつかの実施形態において、サードパーティネットワークの運営者は、プロバイダネットワークによってネイティブにサポートされるインスタンスタイプと異なる、該運営者保有のインスタンスタイプを定義することが可能であり得、他の実施形態において、サードパーティプロバイダは、プロバイダネットワークがサポートする同じタイプのインスタンスをサポートすることが必要とされ得る。上で述べられるように、例えばストリップダウンしたバージョンのプロバイダネットワークの代表的な内部インスタンスホストソフトウェアスタックを有する、存在点の場所（図１では示さず）のプラットフォームは、いくつかの実施形態において、候補プラットフォーム１３５が使用される方法に類似する様式で、リソースインスタンスをホストするために使用され得る。

構成関連の作業の大部分がインスタンスホストではなく専用の制御サーバで実行される構成要素によって行われる、モジュール式の制御アーキテクチャを実装した結果として、示される実施形態において、構成関連のオーバーヘッドは、インスタンスホスト自体で最小にされ得る。例えば、軽量でステートレスな構成要素だけが、制御サーバからＨＴＴＰＳを介して低レベルコマンドを受け取り、そして、一般的に、コマンドを実行するために一時的なＣＧＩプロセスをインスタンス化するように構成される最小のウェブサーバ、またはある特定のタイプの稀なイベントがインスタンスホストで起こったときに、制御サーバに通知することができるイベントリスナ等の、インスタンスホストのインスタンス構成をサポートすることが必要とされ得る。各制御サーバは、いくつかの実施形態において、多数のインスタンスホストのための動作を行うことが可能であり得る。所与のプール１２０に確立される専用の制御サーバの数は、異なる実施形態において、大規模な停電に応答するために回復構成動作を行う必要があり得る率等の、種々の因子に基づいて選択され得る。クライアントインスタンス構成要求（及び要求に対する応答）は、図１の矢印１７０（例えば、クライアント１５０Ａとプール１２０Ａとの間の矢印１７０Ａ、クライアント１５０Ｂとプール１２０Ｂとの間の矢印１７０Ｂ、またはクライアント１５０Ｂとプール１２０Ｃと間の矢印１７０Ｃ）によって示される。所与のクライアント要求に応答するプール１２０の特定の１つまたは複数の制御サーバを選択するために、様々な技法のいずれかが使用され得、例えば、制御サーバは、ロードバランシング機構を使用して、またはクライアントアフィニティ（例えば、同じ制御サーバによって取り扱われ得る、同じクライアントＩＰアドレスからの要求）に基づいて、またはランダムに選択され得る。種々の制御サーバ構成要素の機能、ならびにクライアントと、制御サーバと、インスタンスホストプラットフォームとの間の相互作用に関する追加的な詳細は、下で提供される。
制御サーバ及びインスタンスホスト構成要素

図２は、少なくともいくつかの実施形態による、インスタンスホストプラットフォームのリモート構成用に構成される制御サーバの例示的な構成要素を例示する。例示される構成要素と、構成要素が実装されるハードウェア／ソフトウェアサーバとの間のマッピングは、経時的に、及び異なる実施形態で変動し得る。例えば、いくつかの実装形態では、単一のコンピューティングデバイス上の例示される構成要素のそれぞれをインスタンス化することが可能である一方で、他の実施形態では、特定の構成要素のインスタンスまたはノードに対して１つ以上のコンピューティングデバイスが使用され得る（例えば、複数のワークフローマネージャノードが、所与のコンピューティングデバイスに組み込まれる１つ以上のワークフローマネージャノードによってインスタンス化され得る）。

クライアント及びサードパーティ相互作用マネージャ構成要素２３５は、示される実施形態において、インスタンス起動もしくは構成要求、またはサードパーティもしくはクライアント保有のプラットフォームに対する承認要求等の、入来クライアント要求２０１及び／またはサードパーティ要求２０２を受け取る責任を果たし得る。いくつかの実施形態では、クライアント相互作用及び／またはサードパーティ相互作用をサポートするために、１つ以上のプログラマチックインターフェース（ウェブページ、ウェブサイト、ＡＰＩ、グラフィカルユーザインターフェース、またはコマンドラインツール等）が実装され得る。インスタンス状態マネージャ２１０は、示される実施形態において、クライアントもしくはサードパーティ要求に応答して構成動作を編成する、停電もしくは予期しないインスタンスのシャットダウンに応答する、及び／または新しいインスタンスホストを登録する責任を果たし得る。例えば、クライアントからのインスタンス起動要求に応答して、インスタンス状態及び回復マネージャ２１０は、（容量マネージャ２０５の補助を用いて）起動のためにどのインスタンスホストを使用するのかを正確に識別し得、次いで、選択されたインスタンスホストでの最終的な実行のためのより低レベルのコマンドに翻訳される起動コマンドを、ワークフローマネージャ２２５に発行し得る。

容量マネージャ２０５は、示される実施形態において、インスタンスホストプール１１０が、予想される需要に対して十分にサイズ決定されることを確実にするように、及び／または必要に応じてプール間でリソースを移動させるように構成され得る。能力テスタ２１５は、サードパーティ候補プラットフォームを承認する決定を補助するために、及び／またはプロバイダネットワーク内のインスタンスホストが十分に供給されることを検証するために、試験（性能試験、ソフトウェアスタックの確認、及び同類のもの等）を行うように構成され得る。計測／請求マネージャ２３０は、例えば、ネットワーク要求カウント、測定したトラフィック、Ｉ／Ｏカウント、ＣＰＵ利用率、及び同類のもの等のメトリクス等に基づいて、クライアントに効力のある特定のプライシング計画に従って、請求期間を通じて特定のリソースインスタンスを使用するために所与のクライアントにいくら課金するのかを決定するように構成され得る。

構成デファイナ２２０は、示される実施形態において、起動される特定のインスタンスタイプについて、特定のインスタンスホストに実装される特定の構成レイアウトの詳細（例えば、種々のファイルシステムの名前、及びセットアップするソフトウェアデバイス、種々の調整可能な設定のパラメータ値、及び同類のもの）を生成する責任を果たし得る。ワークフローマネージャ２２５は、インスタンス状態マネージャ２１０によって発行される高レベルコマンド及び構成デファイナ２２０からの構成レイアウトの詳細を受け取る、ならびに１つ以上の低レベルコマンドを含むワークフローにコマンドを翻訳する責任を果たし得る。ワークフローマネージャ２２５は、次いで、ワークフローコマンドをコマンドコミュニケータ２４０に渡し、該コマンドコミュニケータは、ＲＣＥを介して実行するために、（例えば、ＪＳＯＮまたはＸＭＬでフォーマットされる）対応するコマンドシーケンス２８１を（例えば、ＨＴＴＰＳを介して）選択されたインスタンスホストに伝送し得る。いくつかの実施形態において、競合または重複する修正要求によりインスタンスホスト構成が破損されないことを確実にするために、ワークフローマネージャ２２５によって（または図２で例示される他の構成要素によって）ロックサービス２７５が使用され得、例えば、特定のタイプの構成の変更が許可される前にインスタンスホストに対する専用のロックが必要とされ得る。ロックサービス２７５は、いくつかの実施形態において、制御サーバの構成要素ではない場合があり、例えば、プロバイダネットワークにおいて他の目的に使用される既存のロックサービスが使用され得る。制御サーバはまた、いくつかの実施形態において、ある特定のタイプのイベント（リソースインスタンスに影響を及ぼし得る、予期しないシャットダウン、ハードウェアもしくはソフトウェアの誤りまたは不具合等）がインスタンスホストで起こったときに、通知を受け取るように構成される、イベントリスナ２４５も含み得る。イベントリスナ２４５は、いくつかの実施形態において、イベントに関する情報をインスタンス状態マネージャに伝送し得、該インスタンス状態マネージャは、例えばインスタンス状態情報を更新する必要があるかどうかを判定するために、該情報を適切に翻訳し得る。少なくともいくつかの実施形態において、コマンドコミュニケータ２４０はまた、低レベルコマンドをインスタンスホストに提出して、例えば計測マネージャ２３０の代わりに、インスタンスホストから性能または他のメトリクスも収集し得、そのような実施形態において、コマンドコミュニケータによって発行される１組のコマンドは、メトリクス収集のための非修正コマンド、ならびに構成の変更を実装するための修正コマンドを含み得る。

インスタンス状態マネージャ２１０は、その名前で示されるように、種々のリソースインスタンスの状態を認識し得るが、ワークフローマネージャ２２５、コマンドコミュニケータ２４０、及び／またはイベントリスナ２４５等の低レベル構成要素は、少なくとも、示される実施形態において、それらの機能を行うためにそのような低レベル構成要素によってインスタンス状態に関する知識またはそれに関する詳細が必要とされない場合があるという意味で、ステートレスであり得ることに留意されたい。インスタンス状態に関する情報を限定された１組の構成要素に制限することによって、ワークフローマネージャ及びコマンドコミュニケータ等のステートレス構成要素の実装は、そのような実施形態において、実質的に簡略化され得る。また、図２の両方向矢印は、例示される種々の制御サーバ構成要素間で起こり得る相互作用のタイプのいくつかの実施例を示すが、少なくともいくつかの実施形態では、追加的なタイプの相互作用も構成要素間でサポートされ得ること、例えば、いくつかの実施形態では、構成要素のうちの任意の１つが、任意の他の構成要素と通信することが可能であり得ることにも留意されたい。

図３は、少なくともいくつかの実施形態による、（プロバイダネットワークオペレータによって保有されるプラットフォーム、ならびにサードパーティプラットフォームを含み得る）インスタンスホストプラットフォームの例示的な構成要素を例示する。示されるように、インスタンスホストプラットフォームは、制御サーバのコマンドコミュニケータ２４０によって生成されるコマンドのシーケンスを受け取るように構成される、ウェブサーバ等のコマンド受信機構成要素３０５を含み得る。インスタンスホストはまた、ホストのベアハードウェアの上に仮想化機能を提供する、ハイパーバイザー３１７も含み得る。ハイパーバイザー３１７は、示される実施形態において、インスタンスホストプラットフォームのリソースを複数のドメインに組織し得、あるドメイン（ドメインゼロと呼ばれ得る）が管理に使用され、他のドメインがリソースインスタンスに使用される。オペレーティングシステム３１５のインスタンスは、ドメインゼロにセットアップされ得る。各受信したコマンドに、またはコマンドのシーケンスに応答して、コマンド受信機３０５は、３３０Ａまたは３３０Ｂ等のリモートコマンドエグゼキュータ（ＲＣＥ）３３０をインスタンス化し得る。次いで、ＲＣＥ３３０は、動作、例えばハイパーバイザー３１７に、またはドメインゼロオペレーティングシステム３１５に向けられる動作に対する要求を発行し得る。いくつかの実施形態において、ＲＣＥ３３０は、ドメインゼロオペレーティングシステム３１５またはハイパーバイザー３１７の構成要素とみなされ得るか、またはそのように実装され得る。その動作要求（複数可）を発行し、（例えば、戻りコード、誤り出力、または標準出力を含む）結果を受け取った後に、例示される実施形態において、所与のＲＣＥは、終了するか、または抜け得る。ＲＣＥは、いくつかの実装形態において、自発的に抜けるか、または終了し得る一方で、他の実装形態において、ＲＣＥは、（例えば、「キル」信号またはいくつかの他の機構を使用して）コマンド受信機３０５によって終了され得る。他の実施形態において、ＲＣＥは、ただ所与の動作を開始するために必要とされる期間よりも長い期間にわたって存在したままの状態であり得、例えば、ＲＣＥのプールが維持され得る。少なくとも１つの実装形態において、各ＲＣＥは、ＣＧＩ過程または実行のスレッドを表し得る。いくつかの実施形態において、ＲＣＥは、長時間にわたる動作を開始し、そして抜け得、長時間にわたる動作（ＲＣＥが抜けた後も継続し得る）は、コマンド受信機によって非同期的に取得され得る。

ＲＣＥによって開始される動作は、（動作が成功した場合）最終的に、ワークフローマネージャ２２５からの構成コマンドの実装をもたらし得、例えば、計算リソース３５０Ａもしくは３５０Ｂ、記憶リソース３６０Ａもしくは３６０Ｂ、またはネットワークリソース３７０Ａもしくは３７０Ｂ等の種々の仮想化リソースインスタンス３４５のインスタンス化（または、構成の修正）をもたらす。ＲＣＥ及びコマンド受信機はまた、示される実施形態において、所与の時間に特定のインスタンスがどのような状態にあるかを認識していない場合があるという意味で、インスタンス状態に関してステートレスであり得る。インスタンスホストがハイパーバイザーによってドメインに組織されるいくつかの実施形態において、各仮想リソースインスタンスは、それぞれのドメインに対応し得る。インスタンスホストはまた、示される実施形態において、イベントディスパッチャ３１０も備え得る。イベントディスパッチャは、１つ以上のイベントモニタ（例えば、ハイパーバイザー３１７またはドメインゼロオペレーティングシステム３１５内に実装されるモニタ）に加入し得る。イベントモニタ（複数可）は、インスタンスホストである特定のタイプのイベントが起こった場合、そのときには、種々の実施形態において、イベントディスパッチャに通知し得、イベントディスパッチャは、直接またはコマンド受信機を介して、制御サーバのイベントリスナ２４５にイベントに関して通知し得る。
例示的な要求／応答フロー

図４は、少なくともいくつかの実施形態による、クライアントと、制御サーバと、インスタンスホストプラットフォームとの間の例示的な相互作用を例示する。示されるように、クライアント１５０は、示される実施形態において、インスタンスを起動する、または終了する要求等の、インスタンス構成要求４４０を制御サーバ４１０に提出し得る。クライアント要求は、いくつかの実施形態において、制御サーバ４１０の相互作用マネージャ構成要素２３５によって実装されるウェブページまたはＡＰＩ等の、プログラマチックインターフェースを介して伝送され得る。制御サーバ層のいくつかの構成要素（インスタンス状態マネージャ２１０、ワークフローマネージャ２２５、及び／またはコマンドコミュニケータ２４０等）は、協働して、インスタンス構成要求を、インスタンスホストプラットフォーム３０１に伝送される低レベルコマンドのシーケンス４５０に翻訳し得る。

低レベルコマンドは、示される実施形態において、インスタンスホストプラットフォーム３０１でＲＣＥ動作に翻訳され得る。示されるように、ＲＣＥは、例えば新しい過程またはスレッドをスポーンすることによって、インスタンス化され得（図４の要素４６１）、ＲＣＥは、１つ以上の動作を発行または行い得（要素４６２）、次いで、抜けるかまたは終了し得る（要素４６３）。コマンドの結果４７０は、制御サーバ４１０に送り返され得る。結果４７０に基づいて、インスタンス構成応答４８０が要求元クライアント１５０に送り返され得る。コマンドシーケンス４５０及び／または結果４７０は、種々の実施形態において、ＨＴＴＰＳ等の任意の適切で安全なネットワーキングプロトコルを使用して伝送され得る。コマンド及び結果は、いくつかの実施形態において、ＪＳＯＮまたはＸＭＬの変形に従ってフォーマットされ得る。使用するコマンドプロトコルは、種々の実施形態において、少なくともいくつか冪等動作をサポートし得る。いくつかの実施形態において、コマンドプロトコルは、性能メトリクスの収集、ログ記録の収集、及び同類のものを含む、様々な他のコマンドタイプ及び機能をサポートし得、例えば、インスタンスホストプラットフォーム３０１で１つ以上のリソースインスタンスを保有するクライアントの課金額を決定するために、制御サーバ４１０によって低レベルコマンドを発行して、どれくらいの様々な種類の動作をクライアントがインスタンスに発行したか、またはどれくらいのネットワークトラフィックをクライアントがインスタンスホストプラットフォームで負担したかを決定し得る。いくつかの実装形態において、ＲＣＥ以外の機構は、メトリクスまたはログ記録の収集等の、制御サーバが要求したある特定のタイプの動作に使用され得る一方で、他の実装形態において、ＲＣＥは、構成修正及びメトリクス／ログの収集の双方に使用され得る。

図５は、少なくともいくつかの実施形態による、制御サーバでワークフローマネージャノードから開始するコマンドフローの実施例を例示する。図示される実施例は、インスタンスホストでのソフトウェアＲＡＩＤ（独立したディスクの冗長アレイ）デバイスの作成を取り扱い、新しい仮想計算インスタンスをセットアップするために必要とされる構成の一部を表し得る。ここでは、一実施形態において、制御サーバ及びインスタンスホストの異なる構成要素が動作し得る、コマンドレベルの詳細を、具体的な実施例を使用して例示するために実施例が提供され、ＲＡＩＤデバイスとは関連のない数多くの他のタイプの構成動作が、種々の実施形態において、類似する粒度のコマンドを使用して実装され得る。経過時間は、図５の最上部から最下部へと増加する。

ワークフローマネージャ２２５は、示される実施形態において、例えば新しい計算インスタンスに対するクライアントの要求に応答してインスタンス状態マネージャ２１０から、計算インスタンスのためのルートファイルシステムをセットアップする高レベル要求を受け取り得る（図５の要素５０２）。ワークフローマネージャ２２５は、コマンドコントローラ２４０に、ブロックデバイスサブシステムに向けられるコマンド「ｂｌｏｃｋ．ｒａｉｄ１．ｃｒｅａｔｅ」を提出し得（要素５０７）、（例えば、ソフトウェアデバイス名の場合、「ｍｄ２」、「ｓｄａ３」、及び同類のもの等の）指定されたパラメータ値を有するＲＡＩＤ１デバイスの作成を要求する。ワークフローマネージャ２２５は、作成される新しいインスタンスに対して構成デファイナ２２０から取得される構成定義またはレイアウトに少なくとも部分的に基づいて、パラメータ値を決定した場合がある。

「ｂｌｏｃｋ．ｒａｉｄ１．ｃｒｅａｔｅ」コマンドに応答して、コマンドコミュニケータ２４０は、「ＲＣＥ．ｅｘｅｃ」コマンドをインスタンスホストのコマンド受信機３０５に提出し得る（要素５１２）。次に、コマンド受信機３０５は、この場合ではドメインゼロオペレーティングシステム層での「ｍｄａｄｍ」（複数デバイスの管理）コマンドの呼び出しである、要求された動作を実行する、ＲＣＥ過程またはスレッドをインスタンス化し得る（要素５１５）。ＲＣＥ過程またはスレッドは、呼び出しによる戻り値または終了コード（要素５１８の「＄？」値）、呼び出された動作による標準出力（要素５１８の「＄１」値）、及び呼び出された動作による標準誤り（要素５１８の「＄２」値）を取得し得る。これらの結果は、コマンド受信機によってコマンドコミュニケータ２４０に伝送され得る（要素５２１）。次に、コマンドコントローラ２４０は、それが受け取った「ｂｌｏｃｋ．ｒａｉｄ１．ｃｒｅａｔｅ」コマンドの戻り値（例えば、この実施例では、成功を示す「真」）に結果を翻訳し、戻り値をワークフローマネージャ２２５に伝送し得る（要素５２４）。ワークフローマネージャ２２５は、同様に、それが受け取った「ｓｅｔｕｐ−ｉｎｓｔａｎｃｅ−ｒｏｏｔ−ｆｓ」コマンドの戻り値を決定し、この戻り値（同じく、この実施例では、「真」）をインスタンス状態マネージャに提供し得る（要素５２７）。その相互作用が図５で例示される種々の構成要素は、インスタンス状態マネージャによって維持され得るインスタンス状態情報を認識しない場合があり得、代わりに、表された層のそれぞれは、必要に応じて下位レベル動作だけを行い得、その蓄えられた結果は、（例えば、インスタンスの起動、再構成、または終了への）インスタンス状態の変更に関与し得ることに留意されたい。

いくつかの実施形態において、新しいインスタンスホストプラットフォームがプロバイダネットワークのデータセンターに加えられたときに、最終的にホスト上に展開されるリソースインスタンスの特定のタイプ及び数に関する決定を行わなければならない場合がある。新しいインスタンスホストは、そのような実施形態において、インスタンスをホストするための「レジスタ」と言われ得、登録の結果は、１つ以上のインスタンスタイプの「インスタンススロット」の数（ホスト上で起動することができる潜在的なインスタンスの論理表現）の決定を含み得る。図６は、少なくともいくつかの実施形態による、インスタンスホストプラットフォームの登録と関連付けられる例示的な動作を例示する。図５の場合のように、経過時間は、図６の最上部から最下部へと増加する。要素６０２で示されるように、インスタンスホストは、登録要求をインスタンス状態マネージャ２１０に伝送し得る（または、インスタンスホストに代わって登録要求が伝送され得る）。いくつかの実施形態では、登録プロセスを編成するために、インスタンス状態マネージャとは別の登録マネージャが使用され得る。インスタンス状態マネージャ２１０は、要素６０７によって示されるように、登録要求に応答して、容量マネージャ２０５にインスタンススロットセットアップ要求を伝送し得る。インスタンススロットセットアップ要求は、「いくつのインスタンススロット、及びどのインスタンスタイプ（複数可）をインスタンスホストＸがサポートするべきか？」という質問に回答する要求の均等物を表し得る。容量マネージャ２０５は、要素６１２で示されるように、ハードウェア能力要求を構成デファイナ２２０に提出することによって、少なくとも部分的に、インスタンススロットセットアップ要求に応答し得る。少なくともいくつかの実施形態において、インスタンスホストとしてプロバイダネットワークによって獲得されたコンピューティングデバイスのハードウェア能力に関する情報は、インベントリデータベースで利用可能であり得る。いくつかの実装形態において、１つ以上の好ましいベンダーからのラックに基づくサーバ等の、いくつかの「標準」タイプのハードウェアデバイスは、プロバイダネットワークの中のインスタンスホストに使用され得、よって、登録時に性能試験を行う必要がない場合があり、すなわち、インベントリは、インスタンスホストの能力を決定するための十分な情報を含み得る。構成デファイナは、インベントリルックアップを行って（要素６１５）、インスタンスホストのハードウェア詳細を取り出し得る（要素６１８）。

ハードウェアの詳細に基づいて、構成デファイナは、インスタンスホストのための１組の実行可能なインスタンス構成を作成し得（要素６２１）、例えば、構成デファイナは、プロバイダネットワークで使用中の「大」、「中」、及び「小」のインスタンスタイプの定義に基づいて、インスタンスホストが、Ｍ個の「大」計算インスタンス、Ｎ個の「中」計算インスタンス、またはＰ個の「小」計算インスタンスをホストすることが可能であり得ると判定し得る。実行可能な構成のリストは、容量マネージャ２０５に提供され得る。次いで、容量マネージャは、種々のタイプのインスタンスに対する現在の及び予想される需要及び供給等の種々の因子に基づいて、インスタンスホストに対する実行可能な構成の１つを選択し得る。いくつかの実施形態において、容量マネージャ２０５はまた、新しいインスタンスホストが位置するデータセンターまたは可用性コンテナのプライシングポリシー及び／または現在のリソース利用レベルも考慮し得る。容量マネージャ２０５は、次いで、選択されたインスタンススロット定義（例えば、「Ｎ個の大インスタンススロット」）をインスタンス状態マネージャに伝送し得（要素６２４）、スロット定義をメタデータデータベースに記憶し得る。インスタンス状態マネージャ２１０は、いくつかの実施形態において、登録承認をインスタンスホストに提供し得（要素６２７）、インスタンス構成の準備ができていることをインスタンスホストに示し得る（要素６３１）。他の実施形態において、特定のインスタンスホストが利用されるインスタンスの数及びタイプを決定する過程は、図６で示される過程と異なり得る。

図７は、少なくともいくつかの実施形態による、リソースインスタンスを起動することと関連付けられる例示的な動作を例示する。経過時間は、図７の最上部から最下部へと増加する。インスタンス状態マネージャ２１０は、示される実施形態において、クライアント１５０から、指定されたインスタンスタイプ（例えば「小」、「中」、または「大」の計算インスタンス）のリソースインスタンスを起動する要求を受け取り得る。インスタンス状態マネージャ２１０は、必要とされるインスタンスタイプを示す要求を（図７の要素７０２で示されるように）容量マネージャ２０５に送り得る。容量マネージャ２０５は、インスタンスホストプール１１０のデータベースに少なくとも部分的に基づいて、インスタンスを起動するために使用される特定のインスタンスホスト３０１及び特定のＩＰアドレスを決定し、そして、少なくともＩＰアドレスをインスタンス状態マネージャに提供し得る（要素７０７）。次いで、インスタンス状態マネージャ２１０は、インスタンスタイプ及びＩＰアドレスを示す、特定の設定パラメータ及びレイアウト情報に対する要求を構成デファイナに提出し得る（要素７１１）。例示される実施形態において、構成デファイナは、インスタンスホストの特定のスロット番号を含む、要求された設定パラメータをインスタンス状態マネージャに提供し得る（要素７１４）。次いで、インスタンス状態マネージャは、インスタンスタイプ、ＩＰアドレス、及びスロット番号を示す、起動コマンドをワークフローマネージャ２２５に発行し得る（要素７２１）。ワークフローマネージャ２２５は、コマンドコミュニケータ２４０に対するコマンドのシーケンスを開始し（要素７２１）、次に、１つ以上のＲＣＥを使用して実行するために、コマンドのシーケンスをインスタンスホストに提出し得る（要素７２４）。
ＨＴＴＰＳのコマンド要求及び応答

少なくともいくつかの実施形態において、上で述べられるように、制御サーバとインスタンスホストとの間の通信は、ＨＴＴＰＳ等の安全なプロトコルを使用して実装され得る。図８は、少なくともいくつかの実施形態による、制御サーバからインスタンスホストに発行される例示的なコマンド要求の要素を例示する。使用するＨＴＴＰＳの要求及び応答フォーマットは、複数のヘッダ及び本体要素を含み得るが、そのうちのいくつかの実施例だけが図８で提供される。要素８０２で示されるように、制御サーバのコマンドコミュニケータからインスタンスホストのコマンド受信機に送られるコマンドに使用される要求ヘッダは、要求の本体から決定されるダイジェストまたはハッシュ値８２０を含み得、よって、要求本体の完全性をインスタンスホストで検証することができる。要求ヘッダは、要素８２１で示されるように、ＨＴＴＰの「ＰＵＴ」指令または要求メソッドを指定して、「ＣＨＡＮＧＥ−ＩＤ」、「ＵＵＩＤ」、及び「ｓｕｂｓｙｓｔｅｍＩＤ」を含むリソース名を伴う。ＣＨＡＮＧＥ−ＩＤは、発行されているコマンドに通じた特定のクライアント要求を表し得、所与のクライアント要求に対応するＣＨＡＮＧＥ−ＩＤは、いくつかの実施形態において、例えばクライアント相互作用マネージャ２３５によって割り当てられ得、そして、コマンド及び応答のパラメータが、図４、図５、または図７等で示される制御サーバの異なる構成要素間で流れるときに渡され得る。普遍的に一意の識別子またはＵＵＩＤは、示される実施形態において、特定のコマンド要求のために生成され得、例えば、コマンドコミュニケータ２４０は、それがインスタンスホストに送る各コマンド要求に対して異なるＵＵＩＤを生成し得る。サブシステム識別子は、示される実施形態において、要求された動作を行うために使用されるドメインゼロオペレーティングシステムまたはハイパーバイザー層で、特定のサブシステムを示し得る。少なくともいくつかの実施形態では、コマンド要求が送られたとき、それを受け取ったとき、または対応する動作がインスタンスホストで実行されたときに、ログ記録が生成され得、ログ記録は、ＣＨＡＮＧＥ−ＩＤ、ＵＵＩＤ、及びサブシステムＩＤのうちのいくつかまたは全部を含み得、より簡単なデバッギングまたは相関分析を可能にする。

ＨＴＴＰＳの要求の本体８０６は、図８の示された実施例でＪＳＯＮ類似の構文を使用して指定された、定義されたコマンドプロトコルに従うコマンドのシーケンスを含み得る。いくつかの実施形態において、コマンドプロトコルは、要求本体８０６内のファイル内容の仕様を許可し得、ファイル内容は、コマンドのいくつかまたは全部のパラメータとしての役割を果たし得る。例えば、図８で、ラベル＠ＦＩＬＥ１及び＠ＦＩＬＥ２を有する２つのファイルの内容（例えば、ＵＲＬ符合化された１６進形態）が要求本体に含まれ得る。示されるように、「コマンド」というキーワードは、要求に含まれるコマンドのシーケンスを示し得る。３つのコマンド−「ｃｍｄ１」、「ｃｍｄ２」、及び「ｃｍｄ３」が、シーケンスに示される。「ｃｍｄ１」は、２つのファイルパラメータＦＩＬＥ１及びＦＩＬＥ２を有し、それらのそれぞれの内容は、＠ＦＩＬＥ１及び＠ＦＩＬＥ２によって示される。「ｃｍｄ２」は、任意のファイルパラメータを有しない一方で、「ｃｍｄ３」は、単一のファイルパラメータＦＩＬＥ２を有する。使用中のコマンドプロトコルに従って、「ｃｍｄ１」に対応する動作がＲＣＥを介してインスタンスホストで実行されたときに、示される実施形態において、＠ＦＩＬＥ１及び＠ＦＩＬＥ２の内容が、動作のパラメータとして提供される。同様に、ＲＣＥが「ｃｍｄ３」に対応する動作を行ったきには、＠ＦＩＬＥ２の内容がパラメータとして提供される。図８で示される様式の要求本体のファイルの仕様は、示される実施形態において、便利な機能を表し得、他の実施形態では、ファイル内容を含む別個のメッセージ等の他の手法が使用され得る。いくつかの実施形態において、コマンドプロトコルは、コマンドが要求本体に現れる順序でコマンドがインスタンスホストで実行されるように要求し得、他の実施形態では、そのような順序付けが必要とされない場合がある。一実装形態では、単一の要求で伝送することができるコマンドの数に対して最大数制限が課され得る。他の実装形態では、コマンドの数に対していかなる制限も課されない場合がある。要求ヘッダのＵＵＩＤは、いくつかの実施形態において、図８で示されるように、本体に含まれ得る。他の実施形態では、コマンドシーケンスを示すために、ＸＭＬ等の、図８で示されるＪＳＯＮ類似のフォーマットとは異なるフォーマットが使用され得る。

いくつかの実施形態において、コマンド要求に対する回答は、シーケンスのコマンドのそれぞれに対する別個の句または要素を含み得る。要求本体８０６のコマンドシーケンスの第１のコマンドのための応答句（「ｃｍｄ１−Ｆ ＦＩＬＥ１ ＦＩＬＥ２」）は、一実施形態について、応答本体８１０で示される。「コマンド番号」値（示される実施例において「１」）は、句がシーケンスの第１のコマンドに対するものであることを示す。第１のコマンドの実行によって生成される標準出力は、「ｓｔｄｏｕｔ」フィールドで示される。標準誤り出力は、「ｓｔｄｅｒｒ」フィールドで示される。コマンドの終了コード（例えば、使用するオペレーティングシステムまたはハイパーバイザー構成要素によって返される値）は、「終了コード」フィールドで示される。加えて、応答句は、壁時計時間（インスタンスホスト上でコマンドを完了するために費やした経過時間）、ならびにマイクロ秒またはミリ秒等の単位で表される、インスタンスホストでコマンドに対して費やしたリソース使用量を示すシステム及びユーザＣＰＵ時間を含む。種々の実施形態では、図８で示されるもの以外のフォーマットがコマンド及び／またはコマンド応答に使用され得る。
インスタンスホストのリモート構成のための方法

図９は、少なくともいくつかの実施形態による、インスタンスホストのリモート構成を行うように動作可能な制御サーバの動作の態様を例示するフロー図である。要素９０１及び９０２で示されるように、プロバイダネットワークのインスタンスホストとしての役割を果たすために、１組のコンピューティングデバイスが指定され得、インスタンスホストのリモート構成を管理するために、１組の制御サーバが指定され得る。種々のタイプのマルチテナントのネットワークアクセス可能なサービスは、異なる実施形態において、インスタンスホストに実装されるリソースインスタンスを使用して提供され得（及び制御サーバの補助を用いて構成され得）、仮想化計算サービス、記憶サービス、またはネットワーキング関連のサービス、ならびに、リレーショナルもしくは非リレーショナルデータベース、内容マネジメントサービス、及び同類のもの等の高レベルマルチテナントアプリケーション等のインフラストラクチャ関連のサービスを含む。

新しい仮想化計算サーバを起動する、または既存の仮想化サーバを終了する要求等の、マルチテナントサービスの１つ以上に向けられるインスタンス構成要求は、示される実施形態において、例えばフロントエンドロードバランサで、またはクライアント相互作用マネージャ２３５等のフロントエンド制御サーバ構成要素で受け取られ得る（要素９０７）。構成要求の性質及び制御サーバ構成要素の実装形態（例えば、制御サーバ機能の構成要素が、複数の制御サーバにわたって分散されているか、マルチノードクラスタとして実装されているか、または全てが単一のモノリシックな制御サーバ内に組み込まれているか）に基づいて、クライアントの要求に応答してどの特定の制御サーバを関与させるか、及びどの特定のインスタンスホスト（複数可）を関与させるかに関して、選択を行わなければならない場合がある。示される実施形態において、クライアントが、新しい計算インスタンスをアクティブにまたは起動させることを望む場合は、例えば、クライアントの要求を受け取ったソースに近いデータセンターまたは可用性コンテナの種々のインスタンスホストの利用レベル、クライアントがサインアップしたプライシングモデル、クライアントに使用されている他のインスタンスホストに関連する利用可能なインスタンスホストの局所性等の因子に基づいて、またはクライアントによって示される明示的な場所の選好に基づいて、特定のインスタンスホストが選択され得る（要素９１０）。同様に、要素９０２で決定される１組の種々の制御サーバの利用レベルまたは局所性（例えば、クライアントに対する、または選択されたインスタンスホストに対する近接性）等の、異なる実施形態における種々の因子に基づいて、制御サーバ（複数可）がクライアントの要求に対して選択され得る（要素９１０）。

インスタンス状態マネージャ２１０、ワークフローマネージャ２２５、構成デファイナ２２０、及びコマンドコミュニケータ２４０等の、いくつかの異なる制御サーバ構成要素は、示される実施形態において、協働してクライアントの要求に応答し得る。いくつかの実施形態において、例えば選択されたインスタンスホストの構成状態またはメタデータの矛盾する変化を防止するために、随意に、制御サーバ構成要素の１つによって、選択されたインスタンスホストに対してロックが獲得され得（要素９１３）、またはいくつかの他の並行処理制御機構が使用され得る。異なる実施形態において、及び異なるタイプの構成の変更に対して異なるロック粒度が用いられ得、例えば、いくつかの実施形態では、所与のインスタンスホストと関連付けられるメタデータのサブセットだけがロックされ得る一方で、他の実施形態では、一群のインスタンスホストのメタデータが１つの単位としてロックされ得る。構成要求に由来するコマンドシーケンスは、最終的に、選択された制御サーバ構成要素から、選択されたインスタンスホストに伝送され得る（要素９１４）。いくつかの実施形態では、ＨＴＴＰＳ及びＪＳＯＮまたはＸＭＬ等の標準プロトコルまたはフォーマットがコマンドシーケンスに使用され得る。

選択されたインスタンスホストで、１つ以上の低レベルでステートレスな軽量リモートコマンドエグゼキュータ（ＲＣＥ）は、示される実施形態において、コマンドシーケンスで示される動作を実装するために、例えばＣＧＩ過程またはスレッドの形態で、インスタンス化され得る（要素９１６）。実装形態に応じて、別個のＲＣＥスレッド／過程がシーケンスの中の各コマンドに対して実装され得るか、または単一のＲＣＥが複数のコマンドを実装する責任を果たし得る。ＲＣＥは、少なくともいくつかの実施形態において、動作を発行または開始した後に、抜けるかまたは終了し得る。ＲＣＥ動作の結果（例えば、オペレーティングシステムまたはハイパーバイザーレベルのコマンドの戻り値もしくは終了コード、標準出力、及び／または標準誤り）は、示される実施形態において、コマンド要求に対して発行した制御サーバ構成要素に提供され得る（要素９１９）。いくつかの実装形態において、ＲＣＥは、自発的に抜け得る一方で、他の実装形態において、ＲＣＥは、それらの結果を受け取った後に、（例えば、「キル」信号を送ることによって）明示的に終了され得る。少なくともいくつかの実施形態では、収集されたＲＣＥ結果に基づいて、クライアントの構成要求の高レベルの結果（例えば、成功結果または不具合結果）が決定され得る（要素９２１）。要素９１３に対応する動作において、競合する構成の変更を防止するためにロックが獲得されていた場合、該ロックは、解除される。いくつかの実施形態において、結果の指示または通知は、要求元クライアントに提供され得る。

上で述べられるように、いくつかの実施形態において、制御サーバ構成要素は、ある特定のタイプのイベント（例えば、予期しない過程または構成要素の不具合／シャットダウン等の、制御サーバコマンドに対して非同期的に起こるイベント）がインスタンスホストで起こったときに、インスタンスホストから通知を受け取るように構成され得る。図１０は、少なくともいくつかの実施形態による、制御サーバでのリモートイベント通知に関連する動作の態様を例示するフロー図である。要素１００１で示されるように、所与のインスタンスホストで種々の非同期イベントを記録するために、特定の１つまたは複数の制御サーバが選択され得る。いくつかの実施形態では、コマンドシーケンスを所与のインスタンスホストに提出する責任を果たす同じ制御サーバが使用され得る一方で、他の実施形態では、イベント通知のために異なる制御サーバが選択され得る。イベントリスナ２４５は、選択された制御サーバ上でインスタンス化され得る（要素１００４）。イベントリスナ２４５は、インスタンスホストからイベント通知を受け取るために、所与のインスタンスホストのイベントディスパッチャ３１０に加入または登録し得る。いくつかの実施形態において、イベントディスパッチャは、重要なイベントがインスタンスホストで起こったときに、例えばインスタンスホストにインストールされる仮想化ソフトウェア層イベントモニタ（またはオペレーティングシステム層イベントモニタ）から、指示を取得するように構成され得る。制御サーバでのイベントリスナに対する通知は、いくつかの実施形態において、ＨＴＴＰＳ等の安全なネットワーキングプロトコルを使用して提供され得、そのような実施形態では、イベント通知に指定される特定のポートが選択され得る。

予期しないシャットダウンまたは不具合等のイベントが起こったときに、イベントディスパッチャ３１０は、示される実施形態において、適切なフォーマット及びプロトコルを使用して、通知をイベントリスナ２４５に伝送し得る。イベントリスナが通知を受け取った後に（要素１００７）、例えばイベントの性質に依存して、インスタンス状態マネージャ２１０または回復マネージャ等の１つ以上の他の制御サーバ構成要素が通知を受け得る（要素１０１０）。イベントによって影響を及ぼされたリソースインスタンス（複数可）に関する状態情報は、例えば影響を及ぼされたインスタンス上で状態マネージャ２１０によって維持される状態メタデータ内で、変更され得る（要素１０１３）。イベントリスナ２４５自体は、示される実施形態において、インスタンス状態を認識しない場合があり、また、１つ以上のインスタンスホストからイベント通知を受け取り、そして、イベント通知を適切な高レベル制御サーバ構成要素に渡すだけの責任を果たし得る。したがって、制御サーバ設計のモジュール的な成熟は、図１０で示される実施形態において、より高いレベルの状態管理の決定からイベント通知の受信（イベントリスナの責任）を隔離し得る。少なくともいくつかの実施形態において、影響を及ぼされたインスタンスホストに対する回復動作は、インスタンス状態マネージャ２１０またはある特定のタイプのイベントのための制御サーバの別個の回復マネージャ構成要素によって開始され得る。一実施形態において、イベントが起こった影響を及ぼされたインスタンスホストにリソースインスタンスを所有するクライアントが通知を受け得る。

いくつかの実施形態では、インスタンスホストで、制御サーバの１つ以上のプール１２０、及び／または（不具合イベントの後にインスタンス状態を復元するために必要とされ得る回復動作を含む）リソースインスタンスのリモート管理専用の他のリソースがセットアップされ得る。そのようなプールに含まれる制御サーバの数は、異なる実装形態において、例えば現在の動作条件に基づいて変動し得、また、いくつかの因子に基づいて決定され得る。図１１は、少なくともいくつかの実施形態による、制御サーバのプールサイズを決定することに関連する動作の態様を例示するフロー図である。制御サーバプールのサイズは、図１１で示される実施形態において、（多数のリソースインスタンスに影響を及ぼす、データセンターレベルまたは可用性コンテナレベルでの電力不具合等の）大規模な不具合イベントと関連付けられる回復要件に少なくとも部分的に基づいて決定され得る。要素１１０１で示されるように、停電の頻度、影響を及ぼされた実行中のリソースインスタンスの数の範囲、種々の回復動作が費やす時間の長さ、回復時間の関数としての顧客フィードバック等の、大規模停電に関するメトリクスが収集され得る。そのようなメトリクスに基づいて、計画されるべき停電イベントの規模に対するある特定のターゲット目標、及びインスタンスに対する目標回復時間が策定され得る。

要素１１０４で示されるように、ターゲットサイズの大規模停電が発生した場合に必要とされ得る種々のタイプの回復動作率を決定するために、モデル（式に基づくシミュレーションモデルまたは分析モデル等）が収集され得る。そのような回復動作は、例えば、ファイルシステムを検査し、再構築すること、リポジトリからインスタンスホストに仮想マシン画像またはインスタンススナップショットをコピーすること、及び制御ソフトウェアスタックの種々のレベルでの類似する動作を含み得る。一実装形態において、例えば、モデルは、Ｘ分以内の１００，０００の仮想計算インスタンスの不具合に対するインスタンス回復を計算するために、タイプＲ１の必要とされる回復動作率は、毎分５０，０００であり、タイプＲ２の必要とされる回復動作率は、毎分１０，０００であることを示し得る。いくつかの実施形態では、種々のサイズの制御サーバによって種々のタイプの回復動作を完了することができる率を決定するために、試験が実行され得る（要素１１０７）。したがって、モデル及び試験結果を使用してそのような動作を行うための種々のタイプの必要とされる回復動作率及び異なるタイプの制御サーバの容量を推定することで、制御サーバプール（複数可）に対して権限を与えるべき１つ以上の容量レベルの制御サーバの数が決定され得る（要素１１１１）。いくつかの実施形態では、回復動作時間を最適化するための種々のデータセンターでの、または異なる可用性コンテナ内の制御サーバの配置等の、より詳細な推奨事項に対してモデルが使用され得る。いくつかの実施形態では、（例えば、停電がない場合の）標準動作条件に必要とされ得る制御サーバの数を決定するために、類似するモデルも使用され得る。そのような実施形態において、通常動作状態下での必要とされる特定の容量レベルの制御サーバの数がＮ１個であると推定され、かつターゲットサイズの大規模な不具合下での必要とされるその容量レベルの制御サーバの数がＮ２個であると推定された場合、プロバイダネットワークの運営者は、より多い数のＮ１及びＮ２に設定されたプールサイズを選択し得、よって、どちらのタイプの動作条件も成功裏に管理することができる。
サードパーティリソースインスタンス

少なくともいくつかの実施形態において、プロバイダネットワークの制御サーバ（または集合的に、分散された一群の制御サーバ）は、いくつかの実施形態について図１で例示されるように、プロバイダネットワークの外部にあるサードパーティプラットフォームのリモート構成を管理することが可能であり得る。図１２は、いくつかの実施形態による、そのような制御サーバの動作の態様を例示するフロー図である。図１２の要素１２０１で示されるように、マルチテナントのネットワークアクセス可能サービスに向けられるインスタンス構成要求は、サードパーティインスタンスホストプラットフォームならびにプロバイダネットワークの内部にあるインスタンスホストの双方を管理することができる制御サーバで受け取られ得る。要求の性質に応じて、制御サーバは、要求に対応する構成動作を行わなければならない特定のインスタンスホストプラットフォームを決定し得る（要素１２０４）。選択されたプラットフォームが（要素１２０７で検出されたときに）サードパーティプラットフォームである場合、制御サーバ構成要素は、例えばワークフローマネージャ及びコマンドコミュニケータの機能に関して上で説明される技法に類似する技法を使用して、低レベルコマンドシーケンスをサードパーティプラットフォームに発行し得（要素１２１０）、そして、結果を収集し得る。選択されたプラットフォームが（同じく、要素１２０７で検出されたときに）プロバイダネットワークプラットフォームである場合は、低レベルコマンドがプロバイダネットワークプラットフォームに発行され得（要素１２１３）、そして、結果が収集され得る。いずれの場合も、１つ以上の制御サーバ構成要素は、低レベルコマンドシーケンスの収集した結果を解析して、インスタンス構成要求のより高いレベルの結果を決定し、そして、少なくともいくつかの実施形態では、ある特定のタイプの要求について、要求を提出したクライアントに応答が提供され得る（要素１２１６）。上で述べられるように、図１２のサードパーティプラットフォームに関して例示される機能のタイプは、少なくともいくつかの実施形態において、さらに、または代わりに、存在点の場所のプラットフォーム及び類似するリモートプラットフォームに関してサポートされる。

いくつかの実施形態において、プロバイダネットワーク１０２は、一群のリソース容量単位を表す、１つ以上のデフォルト「インスタンスファミリ」をサポートし得る。いくつかのインスタンスファミリは、一般的な使用、すなわち、一般的に使用されるアプリケーションを実行するクライアントを対象とし得、他のインスタンスファミリは、高メモリアプリケーション、高ＣＰＵアプリケーション、クラスタ化されたアプリケーション、並列アプリケーション、または同類のもの等の、特殊な仕様に対してサポートされ得る。サードパーティ（例えば、プロバイダネットワーク運営者以外のエンティティ）が、プロバイダネットワークの制御サーバから、リモートインスタンス構成について該エンティティのインスタンスホストを登録することを許可されるいくつかの実施形態において、サードパーティの少なくともいくつかは、該サードパーティが保有するデフォルトのインスタンスファミリを定義し得る。少なくとも１つの実施形態において、クライアントは、下でさらに詳細に説明されるように、プロバイダネットワーク及び／またはサードパーティによって定義されるデフォルトインスタンスタイプからの変動を特定し得る。図１３は、少なくともいくつかの実施形態による、プロバイダネットワークによって、及びサードパーティによってサポートされ得るそれぞれの計算リソースインスタンス定義の実施例を例示する。プロバイダネットワーク１０２に属するインスタンスホストを使用してサポートされ得る「標準」インスタンスファミリ１３０２の１つの実施例が、サードパーティインスタンスホストに対してサードパーティによって定義される別の例示的なインスタンスファミリ１３４０とともに示される。計算リソースインスタンスタイプは、計算容量、メモリ容量、記憶容量、ネットワーキング容量、オペレーティングシステムのバージョンまたはアドレスサイズ（例えば、３２ビット対６４ビットのアドレス）、及び同類のもの等の、種々の特性において互いに異なり得る。図１３において、インスタンスタイプは、異なる計算容量（「Ｃ」と呼ばれる単位で表される）、メモリ容量（「Ｍ」と呼ばれる単位で表される）、及び記憶容量（「Ｓ」と呼ばれる単位で表される）を有するように示され、明確にするために、インスタンスタイプ間の他の違いは示されない。いくつかの実施形態では、プロバイダネットワーク内または所与のサードパーティネットワーク内のいずれかで、１つを超えるインスタンスファミリが定義され得、例えば、特別な「高メモリ」インスタンスファミリが、メモリ集約的なアプリケーションに対してサポートされ得る。一実施形態において、所与のプロバイダネットワークまたは所与のサードパーティは、１種類のインスタンスだけを定義またはサポートし得る。

いくつかの実施形態において、異なるインスタンスタイプの所与のインスタンスファミリは、小さい１組の異なるハードウェアサーバタイプを使用して実装され得る（例えば、いくつかの事例では、単一のサーバタイプでさえも、所与のファミリの全てのインスタンスタイプに対して十分であり得る）。例えば、例示される実施形態において、標準インスタンスファミリ１３０２の種々のインスタンスタイプ（小、中、大、及び特大）は、３２の処理コア、６４ギガバイトの利用可能なメインメモリ、及び１６００ギガバイトの利用可能なディスク記憶を有する単一のサーバタイプ「Ｓ１」を使用して、プロバイダネットワーク１０２内で実装可能であり得る。標準インスタンスファミリ１３０２の４つのインスタンスタイプの相対的な計算容量は、１：２：４：８の比率である。特大インスタンス１３１６が、Ｓ１サーバの３２のコアを全て使用することを許可された場合、大インスタンス１３１４は、最大で１６のコアを使用することを許可され得、中インスタンス１３１２は、最大で８つのコアを使用し得、小インスタンス１２１０は、最大で４つのコアを使用し得る。同様に、特大インスタンス１３１６が、メインメモリの６４ギガバイトを全て使用することを許可された場合、大、中、及び小のインスタンスタイプによって使用可能な最大メモリは、それぞれ、３２ギガバイト、１６ギガバイト、及び８ギガバイトに設定され得る。異なるインスタンスタイプに対する記憶容量の制限は、同じ比率、すなわち、特大インスタンスに対して１６００ギガバイトの全て、大インスタンスに対して８００ギガバイト、中インスタンスに対して４００ギガバイト、及び小インスタンスに対して２００ギガバイトに設定され得る。

プロセッサコア使用量、メモリ使用量、記憶使用量に対する制限、ならびにネットワーキング制限及び同類のものの制限は、いくつかの実施形態において、異なるインスタンスタイプを実装するために使用されるハイパーバイザーまたは他の低レベルソフトウェアの設定またはパラメータを使用して制御され得る。したがって、少なくともいくつかの実施形態では、上で説明される制御サーバ構成要素の補助を用いて、所与のＳ１サーバの仮想化設定を変更することによって、８つの小インスタンス、４つの中インスタンス、２つの大インスタンス、１つの特大インスタンス、または小、中、及び大インスタンスの種々の組み合わせ（例えば、１つの大インスタンス、１つの中インスタンス、及び２つの小インスタンス）をセットアップすることが可能であり得る。潜在的に、標準ファミリにおける各より大きいインスタンスタイプの容量を分割して、整数個のより小さいインスタンスを形成することができるという事実は、制御サーバ構成要素からのインスタンスホストの柔軟な構成に有用であり得る。単一のサーバタイプＳ１が上で述べられているが、いくつかの実施形態では、複数の異なるサーバタイプを使用して、種々の容量レベルの所与のインスタンスファミリが実装され得、異なる容量レベルのインスタンスファミリに使用されるコアまたは他のリソースの数が互いの整数倍であるといったいかなる要件もない。

いくつかの実施形態において、サードパーティプラットフォームのリモート構成のために、プロバイダネットワークの制御サーバ機能を利用することを望むサードパーティは、プロバイダネットワークのインスタンスホストに使用される該サードパーティのインスタンスホストプラットフォームに対して同じハードウェアプラットフォームまたはベンダーを使用することが必要とされ得る。しかしながら、少なくともいくつかのサードパーティ運営者は、少なくともいくつかの実施形態において、該サードパーティ運営者の候補インスタンスホストプラットフォームに対して異なるタイプのハードウェアを使用し得、その結果、該サードパーティ運営者のインスタンスタイプは、そのような実施形態において、種々のタイプの容量（例えば、計算、メモリ、または記憶容量）において、プロバイダネットワークに対してネイティブなインスタンスタイプとは異なり得る。図１３の実施例において、サードパーティインスタンスファミリ１３４０は、「ベースライン」インスタンスタイプと、「大」インスタンスタイプとを含む。所与のサードパーティによって定義される異なるタイプのインスタンスのための容量比率は、少なくともいくつかの実施形態において、例えばプロバイダネットワーク運営者とサードパーティとの間の事業合意の一部として、プロバイダネットワーク運営者に提供され得る。例えば、図１３において、「ベースライン」の計算容量と「大」サードパーティインスタンスタイプとの間の比率は、ｘ：ｙとして示され、サードパーティインスタンスタイプのメモリ容量間の比率は、ｐ：ｑとして示され、記憶容量間の比率は、ｆ：ｇとして示される。

プロバイダネットワークが、例えば共有されたインスタンス予約インターフェース及び／または共有された構成ＡＰＩを提供することによって、サードパーティインスタンスファミリ１３４０をサポートするクライアントに面するインターフェースを実装する実施形態では、クライアントに、サードパーティインスタンスの相対的な容量及びプロバイダネットワーク自体のインスタンスに関する情報を知らせる必要があり得る。示される実施形態において、例えば、プロバイダネットワークの制御サーバの能力テスタ構成要素２１５は、「標準」インスタンスファミリ１３０２のインスタンスタイプに関連する種々のサードパーティインスタンスタイプの容量を決定する責任を果たし得る。能力テスタは、例えば、１組の試験１３９０を、「ベースライン」または「大」インスタンスが起動された特定のサードパーティインスタンスホストプラットフォームに伝送し得、そして、試験の結果１３９２を使用して、サードパーティインスタンスタイプの容量とプロバイダネットワークの標準インスタンスタイプとの比率を決定し得、ならびに、サードパーティインスタンスタイプの容量の比率（例えば、ｘ：ｙ、ｐ：ｑ、ｆ：ｇ）が正しいことを検証し得る。加えて、能力テスタ２１５はまた、いくつかの実施形態において、サードパーティがプロバイダネットワークの制御サーバ構成要素からリモートに制御されるようにその一団のインスタンスホストに加えることを望む、新しいインスタンスホスト候補プラットフォームの妥当性を検査する責任も果たし得る。性能及び容量の試験に加えて、いくつかの実施形態では、サードパーティプラットフォーム上の能力テスタによって、例えば、所望のソフトウェアがインストールされたこと、構成動作を実装するために必要に応じて制御サーバによって適切な種類のＲＣＥを成功裏に呼び出すことができること等を確認する試験を含む、他のタイプの試験も行われ得る。

プロバイダネットワーク及び／またはサードパーティネットワークが１組のデフォルトでサポートされるインスタンスタイプを定義する少なくともいくつかの実施形態において、クライアントが、サポートされるインスタンスタイプのプロパティからの変動を示すことを可能にすることによって、クライアントによって取得することができるリソースインスタンスのプロパティに関するさらなる柔軟性がサポートされ得る。例えば、一実施形態では、１組のデフォルト仮想化インスタンスタイプがサポートされ得、各インスタンスタイプは、関連付けられた１組のプロパティまたは能力を有する。ある特定のデフォルトインスタンスタイプＤＩＴ１は、ＣＰＵ性能プロパティＣＰ、ディスク記憶プロパティＤＰ、ネットワークスループットプロパティＮＰ、ネットワーク待ち時間プロパティＮＬＰ、及びインストールされたソフトウェアのプロパティＳＰによって特徴づけられ得る。クライアントは、例えばインスタンス構成要求において、そのプロパティが全般的にＤＩＴ１に対して定義されるプロパティに類似するが、異なるネットワーク待ち時間プロパティＮＬＰ２、または異なる１組のインストールされたソフトウェアＳＰ２、またはいくつかの他のプロパティ変動を有するリソースインスタンスを起動することを望むことを示し得る。制御サーバ構成要素が、要求されたプロパティ変動をサポートすることができると判定した場合、（例えば、プロパティ変動を実装するためのコマンドを含む）クライアントの要求に従ってリソースインスタンスを構成するための１組のコマンドが、上で説明される種類の技法を使用して発行され得る。本明細書で説明される制御サーバ構成要素を切り離すことで、そのような変動を、構成をインスタンス化するためにより多くのハードワイヤードの手法が使用される環境よりもはるかに容易に取り扱うことを可能にし得る。

いくつかの実施形態において、図４で示される種類の制御サーバアーキテクチャによって可能にされる柔軟性は、クライアントが、クライアント保有のインスタンスタイプを定義することを可能にし得、そのプロパティは、プロバイダネットワークによって及び／またはサードパーティプロバイダによってサポートされるデフォルトのインスタンスタイプと実質的に異なり得る。そのような実施形態において、クライアントＣ１は、例えばプログラマチックインターフェースを介して及び／またはプロバイダネットワークによって定義されるインスタンス定義言語もしくはプロトコルを使用して、種々の性能及び他の能力を詳述する該クライアントの好ましいインスタンスタイプの定義を提出し得る。種々の制御サーバ構成要素（能力テスタ２１５等）は、該当する場合に、どのインスタンスホストプラットフォーム（プロバイダネットワークの内部にあるプラットフォーム、サードパーティプラットフォームのいずれか、または双方）が、クライアント定義のインスタンスタイプをサポートすることが可能であるかを決定し得、そうしたインスタンスホストプラットフォームは、そのクライアントのインスタンス構成要求に使用され得る。いくつかの実施形態では、完全に動的なインスタンス定義がサポートされ得、クライアントは、所望に応じて、クライアントのインスタンスのいずれかに対するカスタマイズされたプロパティまたは特性を定義し得る。

図１４は、少なくともいくつかの実施形態による、サードパーティネットワークのリソースインスタンスを構成して、ネットワークアクセス可能サービスを提供するために、プロバイダネットワークの制御サーバによって行われる動作の態様を例示するフロー図である。図１４の要素１４０１で示されるように、サードパーティプラットフォーム承認要求は、プログラマチックインターフェース（ＡＰＩまたはウェブページ等）を介して、相互作用マネージャ２３５等の制御サーバフロントエンド構成要素によって受け取られ得る。承認要求は、プラットフォームのネットワークアドレスまたは座標、ネットワークアドレスを使用して管理者としてプラットフォームにログインするために使用可能な信用証明書、１つ以上のマルチテナントサービスを提供するためにプラットフォーム上でサポートされるインスタンスの種類に関するインスタンスタイプ情報、及び／またはプラットフォームがサポートを主張するリソースインスタンスをサポートすることが可能であるという妥当性を検査するために動作され得る試験のタイプを示す試験情報等の、承認が所望される候補プラットフォームに関する種々のタイプの情報を含み得る（少なくともいくつかの実施形態において、単一の承認要求は、複数の候補プラットフォームを示し得、その場合、単一のプラットフォームに対する本明細書で説明される試験のタイプ及び他の動作は、示される候補プラットフォームのそれぞれに対して繰り返され得ることに留意されたい）。承認要求に応答して、能力テスタ２１５等の制御サーバ構成要素は、インストールされたソフトウェアスタック検証、性能試験、信頼性試験、（例えば、候補プラットフォーム上のウェブサーバまたは他のコマンド受信機を、ＣＧＩに基づく過程またはスレッドを起動するように構成できるかどうかを含む）リモートコマンドを介してＲＣＥを起動できることを検証するための検査、及び同類のもの等の、１つ以上の能力判定動作を候補プラットフォーム上で開始し得る（要素１４０４）。候補プラットフォームでサポートされるインスタンスタイプが示される実施形態において、能力テスタ２１５は、示されたインスタンスタイプ、またはインスタンスタイプの示されたインスタンスの数が候補プラットフォーム上でインスタンス化できるかどうかを検証し得る。サポートされるインスタンスタイプの試験定義、またはそのような試験定義に対するポインタは、いくつかの実施形態において、承認要求に含まれ得る。サポートされるインスタンスのタイプは、種々の実施形態において、プロバイダネットワークによって定義されるか、サードパーティによって定義されるか、またはサードパーティ及びプロバイダネットワークの双方によって定義される、インスタンスタイプまたはファミリを含み得る。

結果が、（要素１４０７で判定したときに）候補プラットフォーム能力が許容可能であることを示す場合、プラットフォームは、例えばプロバイダネットワークの制御サーバを使用してリソースインスタンス構成がリモートに行われるプラットフォームのプールに含めることに対して、承認されたものとして指定され得る（要素１４１３）。リモートコマンドをサポートするためにプラットフォームに対する任意の追加的な構成の変更（適切なバイナリまたはライブラリを使用してＣＧＩ過程を起動するために必要とされる、ウェブサーバ構成の変更等）が必要とされる場合、そのような変更は、示される実施形態において、例えば承認要求で提供される管理者信用証明書を使用して行われ得る。候補プラットフォームの能力が許容できないと分かった場合、承認要求は、拒否され得る（要素１４１０）。

その後に、クライアントのインスタンス構成要求を（例えば、相互作用マネージャ２３５を介して）制御サーバで受け取ったときに、制御サーバ構成要素（例えば、インスタンス状態マネージャ２１０）は、同じく図１２に関して上で説明されるように、プロバイダネットワークのインスタンスホストが要求に応答するように使用されるかどうか、または承認されたサードパーティプラットフォームが使用されるかどうかに関する判定を行い得る。少なくともいくつかの実施形態において、クライアントは、図１５を参照して下で説明されるように、そのプラットフォーム上で該クライアントのインスタンスが起動されるソース（例えば、プロバイダネットワーク、または特定のサードパーティネットワーク）に関する該クライアントの選好を示すことを可能にされ得る。他の実施形態において、インスタンス状態マネージャは、クライアントのネットワークに対するサードパーティプラットフォームの近接性、または他のインスタンスホストの現在のまたは予想される利用レベルに対するサードパーティプラットフォームの現在のまたは予想される利用レベル等の種々の因子のいずれかに基づいて、クライアントがサードパーティプロバイダに対する選好を明確に示さない場合であっても、承認されたサードパーティインスタンスホストを選択するように決定し得る。それに応じて、クライアントによって要求される構成を行うために、特定の承認されたサードパーティプラットフォームを使用するように決定が行われ得る（要素１４１６）。

制御サーバ構成要素が複数のサーバ全体にわたって分散される少なくともいくつかの実施形態では、選択されたサードパーティインスタンスホストプラットフォームのリモート構成に対してより低いレベルの制御サーバ構成要素（例えば、ワークフローマネージャ、コマンドコミュニケータ、及びイベントリスナ）が使用される、特定の制御サーバが選択され得る（要素１４１９）。コマンドシーケンスは、図４、図５、図７、図８、及び図９との関連において上で説明されるように、コマンドシーケンスがプロバイダネットワーク自体のインスタンスホストに送られる方法に類似する様式で、１つ以上のＲＣＥを介して、実装のために、適切な制御サーバから、選択された承認されたサードパーティインスタンスホストに送られ得る（要素１４２２）。例えば、ＨＴＴＰＳプロトコルは、コマンドシーケンスに使用され得、コマンド自体は、異なる実施形態において、ＪＳＯＮ、ＸＭＬ、またはＪＳＯＮもしくはＸＭＬの変形に従ってフォーマットされ得る。一実施形態において、サードパーティインスタンスホストプラットフォームに対する構成の変更の並行処理制御は、例えば、プロバイダネットワークのロックマネージャ、サードパーティ運営者によって実装されるロックマネージャ、またはプロバイダネットワーク及びサードパーティのロックマネージャの組み合わせを使用して実装され得る。そのような実施形態では、サードパーティプラットフォームにコマンドシーケンスを発行する前に、プロバイダネットワークのインスタンスホストをロックするための上で説明される様式に類似する様式で、適切なロックマネージャ（複数可）から１つ以上のロックが取得され得、ロック（複数可）は、動作が開始または完了した後に解除され得る。サードパーティプラットフォームで、ウェブサーバ等のコマンド受信機は、いくつかの実施形態において、要求された１つまたは複数の動作を行うために、必要に応じて（例えば、ＣＧＩを使用して）ＲＣＥをインスタンス化し得、ＲＣＥは、動作を開始した後に、終了または抜け得る。終了コードまたは戻りコード、標準出力及び／または標準誤り等のＲＣＥ動作の結果は、制御サーバに提供され得、クライアントの要求に対する応答は、収集されたＲＣＥの結果に基づいて提供され得る（要素１４２５）。したがって、サードパーティプロバイダは、プロバイダネットワーク運営者によって構築される既存のインスタンス構成制御インフラストラクチャを利用することを可能にし得る一方で、該サードパーティプロバイダのサードパーティデータセンターのインフラストラクチャを保有し、管理し続ける。多くの場合において、サードパーティが、過度のまたは十分に使用されていないハードウェアプラットフォームの利用率を飛躍的に増加させ、かつ収益化することが可能になり得る。上で述べられるように、クライアントネットワークはまた、十分に使用されていないハードウェアプラットフォームも備え得、プロバイダネットワークのクライアントはまた、いくつかの実施形態において、そのようなプラットフォームをより良く利用するために、プロバイダネットワークの制御サーバを使用することも可能にされ得る。例えば、クライアントは、そのような実施形態において、プロバイダネットワーク装置上で動作する図２の制御サーバ構成要素の補助を用いて、クライアント保有のハードウェアプラットフォーム上のリソースインスタンスを起動することが可能であり得る。同様に、少なくとも１つの実施形態において、存在点（ＰＯＰ）の場所を運営または管理するエンティティは、プロバイダネットワークの制御サーバを使用して、リソースインスタンスをホストするためのホストを構成し得る。

少なくとも１つの実施形態において、上で説明される種類の能力試験は、例えば定期的にそのようなプラットフォームの承認を延長するために、サードパーティプラットフォームに対して経時的に繰り返され得る。そのような一実施形態では、承認を新しくするために、１つ以上のサードパーティプラットフォーム上で再実行される能力試験反復スケジュールが決定され得る。次いで、能力試験の反復は、スケジュールに従って開始され得、承認を新しくするかどうかに関する判定は、反復の結果に少なくとも部分的に基づき得る。

上で述べられるように、いくつかの実施形態において、クライアントには、そのインスタンスホストがクライアントのリソースインスタンスに使用されるプロバイダに対する該クライアントの選好をプログラム的に示す機会が提供され得る。図１５は、クライアントが、プロバイダネットワークの制御サーバ構成要素によって制御されるサードパーティプラットフォーム上でインスタンス化されるインスタンスを含むリソースインスタンスを、複数のプロバイダから選択することを可能にするように実装され得る、プログラマチックユーザインターフェースの実施例を例示する。例示されるユーザインターフェースは、示される実施形態において、メッセージ領域１５０３及び複数のフォームフィールドを有する、ウェブページ１５００を備える。メッセージ領域１５０３に示されるように、クライアントは、ウェブページ１５００を使用して、該クライアントのインスタンスのニーズに関するいくつかの予備的な選好を提供するように要求され、フォームフィールドの提出は、クライアントが所望のインスタンスに対して１つ以上選択し得る特定のインスタンスホストのオプションのリストをもたらす。

フィールド１５０７を使用して、クライアントは、例えば計算リソースがデフォルトのリソースタイプである選択肢のドロップダウンリストを介して、該クライアントが獲得することを望むリソース（複数可）のタイプ（例えば、計算と、記憶と、ネットワーク）を示し得る。フィールド１５０９は、好ましいリソースベンダーを指定するために使用され得、クライアントが特定のベンダーを指定しないことを望む場合、「利用可能で最も安価な」ベンダーというデフォルトの選択肢が使用され得る。フィールド１５１１を使用して、クライアントは、好ましい可用性コンテナを示し得るか、または地理的に最も近い可用性コンテナの設定というデフォルトオプションのままにし得る。フィールド１５１２は、クライアントが、利用可能な種々のインスタンスタイプの中から選択することを可能にし、該インスタンスのいくつかは、クライアント保有のインスタンスホストを使用するプロバイダネットワークによって実装され得る一方で、他のインスタンスは、サードパーティによって保有されるインスタンスホストを使用して実装され得る。クライアントは、要素１５１２内に含まれる種々のリンクをクリックして、各ファミリのインスタンスタイプ、利用可能なプライシングポリシー、及び／または追加的な情報に関するさらなる詳細を見出し得る。クライアントは、示される実施形態において、フォームフィールド１５１３を使用して、必要とされるリソースインスタンスの数を指定し得、また要素１５１５を使用して、インスタンスが必要とされる期間を指定し得る。クライアントの選好は、「送信！」ボタン１５１９を使用して提出され得る。

異なる選好情報は、図１５で示される以外の他の実施形態において、クライアントから要請され得ること、及びウェブページ以外のプログラマチックインターフェース（例えば、ＡＰＩ、コマンドラインツール、またはグラフィカルユーザインターフェース）は、いくつかの実施形態において、クライアントの選好を取得するために使用され得ることに留意されたい。また、いくつかの実施形態において、図９、図１０、図１１、図１２、及び図１４のフロー図等の、上で説明されるフロー図で例示される動作のいくつかは、図で示される順序とは異なる順序で行われ得、他の実施形態において、動作のいくつかは、順次的ではなく並列に行われ得ることにも留意されたい。種々の実施形態において、フロー図に示される動作のいくつかは、省略され得る。
使用事例

効率的でモジュール式のリソースインスタンスのリモート構成制御といった、上で説明される技法は、仮想化リソースをホストするために多数のプラットフォームが使用される種々のタイプの環境において有益であり得る。これらの技法は、クライアントに提供される種々のマルチテナントサービスをサポートするために必要とされるプラットフォーム上の構成ソフトウェアを使用する代替的な手法が、相当なオーバーヘッドを課し得る環境において特に有用であり得る。そのようなプラットフォーム上の構成ソフトウェアは、理想的には、代わりに顧客が要求した収益生成リソースインスタンス専用にされるべき、計算サイクル、メモリ、及び／または記憶の割合を低減させ得る。
例示的な実施形態

本開示の実施形態は、以下の付記を考慮して説明することができる。
付記１．クライアントからのインスタンス構成要求に応答して、
リソースインスタンスのリモート構成を管理するように設計される１つ以上の制御サーバのうちの選択された制御サーバから、インスタンス構成に対する特定のコマンドプロトコルに従ってフォーマットされる１つ以上のコマンドのシーケンスを受け取ることであって、ネットワークアクセス可能サービスのリソースインスタンスを実装するように指定される複数のインスタンスホストのうちの選択されたインスタンスホストで行われる、受け取ることと、
１つ以上のコマンドのシーケンスを受け取ることに応答して、選択されたインスタンスホストで、リモートコマンドエグゼキュータをインスタンス化することと、
選択されたインスタンスホストでリモートコマンドエグゼキュータによって、１つ以上のコマンドのシーケンスに対応する１つ以上の構成動作を開始することと、
１つ以上の構成動作の結果を選択された制御サーバに提供することと、
リモートコマンドエグゼキュータを終了することと、
結果に少なくとも部分的に基づいて、インスタンス構成要求に対する応答をクライアントに提供することと、を含む、方法。
付記２．安全なネットワーキングプロトコルを介して、選択されたインスタンスホスト上で、ウェブサーバによって１つ以上のコマンドのシーケンスを受け取ることをさらに含み、
リモートコマンドエグゼキュータを該インスタンス化することは、共通ゲートウェイインターフェース（ＣＧＩ）規格に従って、ウェブサーバによる実行の少なくとも１つのスレッドをインスタンス化することを含む、付記１に記載の方法。
付記３．選択されたインスタンスホストのイベントディスパッチャによって、選択されたインスタンスホストに実装されるイベントモニタに加入することと、
１組の制御サーバのうちの特定の制御サーバに、安全なネットワーキングプロトコルを介して、イベントディスパッチャから、選択されたインスタンスホストに実装されるリソースインスタンスのイベントの通知を伝送することであって、該通知は、リソースインスタンスの状態情報を更新するために使用可能である、伝送することと、をさらに含む、付記１に記載の方法。
付記４．特定のタイプの不具合が生じた場合に、複数のインスタンスホストに実装されるリソースインスタンスを回復するためにインスタンス回復構成動作が行われる率を推定することと、
推定された率に少なくとも部分的に基づいて、１つ以上の制御サーバに含まれる制御サーバの数を決定することと、をさらに含む、付記１に記載の方法。
付記５．選択されたインスタンスホストは、プロバイダネットワークの第１の可用性コンテナの第１のデータセンター内に位置し、選択された制御サーバは、プロバイダネットワークの第２の可用性コンテナ内の異なるデータセンター内に位置し、第１の可用性コンテナは、第２の可用性コンテナとは異なる可用性プロファイルを有する、付記１に記載の方法。
付記６．システムであって、
ネットワークアクセス可能サービスのリソースインスタンスを実装するように構成可能な複数のインスタンスホストと、
複数のインスタンスホストでリソースインスタンスの構成を管理するように構成される１つ以上の制御サーバと、を備え、
１つ以上の制御サーバの選択された制御サーバは、クライアントからのインスタンス構成要求に応答して、１つ以上のコマンドのシーケンスを、複数のインスタンスホストのうちの選択されたインスタンスホストに伝送するように構成され、
選択されたインスタンスホストは、１つ以上のコマンドのシーケンスを受け取ることに応答して、リモートコマンドエグゼキュータをインスタンス化するように構成され、
リモートコマンドエグゼキュータは、１つ以上のコマンドのシーケンスに対応する１つ以上の構成動作を開始するように構成され、
選択された制御サーバは、１つ以上の構成動作の結果に少なくとも部分的に基づいて、インスタンス構成要求に対する応答をクライアントに提供するように構成される、システム。
付記７．選択されたインスタンスホストは、
ウェブサーバで１つ以上のコマンドのシーケンスを受け取るようにさらに構成され、
ウェブサーバは、共通ゲートウェイインターフェース（ＣＧＩ）規格に従って、リモートコマンドエグゼキュータをインスタンス化するように構成される、付記６に記載のシステム。
付記８．選択されたインスタンスホストは、
選択されたインスタンスホストに実装されるイベントモニタに加入し、そして、
安全なネットワーキングプロトコルを介して、１つ以上の制御サーバのうちの特定の制御サーバに、選択されたインスタンスホストでイベントモニタによって示されるイベントの発生の通知を伝送するように構成される、イベントディスパッチャを備える、付記６に記載のシステム。
付記９．特定の制御サーバは、
通知に少なくとも部分的に基づいて、リソースインスタンスの状態情報を更新するようにさらに構成される、付記８に記載のシステム。
付記１０．１つ以上の制御サーバは、制御サーバプールの複数の制御サーバを備え、制御サーバプールのサイズは、特定のタイプの不具合が生じた場合に、複数のインスタンスホストに実装されるリソースインスタンスを回復するためにインスタンス回復構成動作が行われる推定の率に少なくとも部分的に基づいて決定される、付記６に記載のシステム。
付記１１．選択されたインスタンスホストは、プロバイダネットワークの第１の可用性コンテナの第１のデータセンター内に位置し、選択された制御サーバは、プロバイダネットワークの第２の可用性コンテナ内の異なるデータセンター内に位置し、第１の可用性コンテナは、第２の可用性コンテナとは異なる可用性プロファイルを有する、付記６に記載のシステム。
付記１２．１つ以上のコマンドのシーケンスを伝送する前に、選択された制御サーバは、選択されたインスタンスホストに対するロックを取得するように構成される、付記６に記載のシステム。
付記１３．１つ以上のコマンドのシーケンスは、複数のコマンドタイプをサポートするコマンドプロトコルに従って伝送され、複数のコマンドタイプのうちの少なくとも１つのコマンドタイプのサブセットは、冪等コマンドを含む、付記６に記載のシステム。
付記１４．１つ以上の制御サーバのうちの特定の制御サーバは、
複数のコマンドタイプのうちの特定のコマンドタイプを使用して、選択されたインスタンスホストから１つ以上の性能メトリクスを収集するようにさらに構成される、付記１３に記載のシステム。
付記１５．選択されたインスタンスホストは、（ａ）クライアントの識別情報、（ｂ）インスタンス構成要求で示されるリソースインスタンスタイプ、（ｃ）複数のインスタンスホストと関連付けられる１つ以上の性能メトリクス、または（ｄ）１つ以上のプライシングポリシー、のうちの１つ以上に少なくとも部分的に基づいて、複数のインスタンスホストから選択される、付記６に記載のシステム。
付記１６．１つ以上のコマンドのシーケンスは、ハイパーテキストトランスファープロトコルの変形を介して伝送される、付記６に記載のシステム。
付記１７．１つ以上のコマンドのシーケンスは、ＪａｖａＳｃｒｉｐｔオブジェクト表記法（ＪＳＯＮ）フォーマットの変形に従って伝送される、付記６に記載のシステム。
付記１８．インスタンス構成要求は、構成されるリソースインスタンスタイプを示し、リソースインスタンスタイプは、（ａ）計算リソースインスタンス、（ｂ）記憶リソースインスタンス、または（ｃ）ネットワークリソースインスタンス、のうちの少なくとも１つを含む、付記６に記載のシステム。
付記１９．１つ以上のプロセッサで実行されたときに、１つ以上のネットワークアクセス可能サービスのリソースインスタンスをホストするように構成可能な複数のインスタンスホストを備えるプロバイダネットワークの制御サーバを実装するプログラム命令を記憶する、非一時的なコンピュータアクセス可能な記憶媒体であって、該制御サーバは、
クライアントからのインスタンス構成要求であって、１つ以上のネットワークアクセス可能サービスのうちの特定のサービスに向けられる、インスタンス構成要求に応答して、
複数のインスタンスホストのうちの選択されたインスタンスホストに１つ以上のコマンドを伝送し、
選択されたインスタンスホストから、１つ以上のコマンドに応答して、選択されたインスタンスホストでインスタンス化されるリモートコマンドエグゼキュータによって、選択されたインスタンスホストで開始される１つ以上の構成動作の結果を受け取り、
１つ以上の構成動作の結果に少なくとも部分的に基づいて、インスタンス構成要求に対する応答をクライアントに提供するように構成される、非一時的なコンピュータアクセス可能な記憶媒体。
付記２０．制御サーバは、（ａ）伝送される１つ以上のコマンドを決定するように構成されるワークフローマネージャ、（ｂ）１つ以上のコマンドを選択されたインスタンスホストに伝送するように構成される通信モジュール、及び（ｃ）選択されたインスタンスホストから非同期イベント通知を受け取るように構成されるイベントリスナ、のうちの１つ以上を備える、付記１９に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２１．１つ以上のコマンドを伝送する前に、制御サーバは、選択されたインスタンスホストに対するロックを取得するように構成される、付記１９に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２２．１つ以上のコマンドは、複数のコマンドタイプをサポートするコマンドプロトコルに従って伝送され、複数のコマンドタイプのうちの少なくとも１つのコマンドタイプのサブセットは、冪等コマンドを含む、付記１９に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２３．制御サーバは、
複数のコマンドタイプのうちの特定のコマンドタイプを使用して、選択されたインスタンスホストから１つ以上の性能メトリクスを収集するようにさらに構成される、付記２２に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２４．１つ以上のコマンドは、ハイパーテキストトランスファープロトコルの変形を介して伝送される、付記１９に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２５．特定のネットワークアクセス可能サービスは、１組のリソースインスタンスタイプを定義し、インスタンス構成要求は、（ａ）１組のうちの特定のリソースインスタンスタイプ、及び（ｂ）特定のリソースインスタンスタイプのデフォルトプロパティに対する要求された変動の指示を含み、１つ以上のコマンドのうちの少なくとも１つのコマンドは、要求された変動を実装することを目標にされる、付記１９に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２６．要求された変動は、（ａ）性能能力、または、（ｂ）インストールされたソフトウェア構成要素、のうちの少なくとも１つの指示を含む、付記１９に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２７．１つ以上のプロセッサで実行されたときに、
プロバイダネットワークの制御サーバから、インスタンス構成コマンドを受け取り、該制御サーバは、１つ以上のネットワークアクセス可能サービスを提供するためにリソースインスタンスのリモート構成を管理するように構成され、
インスタンス構成コマンドに応答して、リモートコマンドエグゼキュータをインスタンス化し、該リモートコマンドエグゼキュータは、コマンドに従って１つ以上の構成動作を開始するように構成され、そして、
１つ以上の構成動作の結果を制御サーバに提供する、プログラム命令を記憶する、非一時的なコンピュータアクセス可能な記憶媒体。
付記２８．命令は、１つ以上のプロセッサで実行されたときに、
ウェブサーバでインスタンス構成コマンドを受け取り、リモートコマンドエグゼキュータは、共通ゲートウェイインターフェース（ＣＧＩ）規格に従ってインスタンス化される少なくとも１つの実行可能な過程を含み、少なくとも１つの実行可能な過程は、１つ以上の構成動作の開始後に終了するように構成される、付記２７に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記２９．命令は、１つ以上のプロセッサで実行されたときに、
（ａ）ローカルハイパーバイザー構成要素、または（ｂ）ローカルオペレーティングシステム構成要素、のうちの少なくとも１つによって少なくとも部分的に実装されるイベントモニタに加入し、
制御サーバに、イベントモニタによって監視されるイベントの通知を伝送するように動作可能である、イベントディスパッチャを実装する、付記２７に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記３０．ネットワークアクセス可能サービスのリソースのリモート構成をサポートするプロバイダネットワークで、仮想化リソースをホストするための１つ以上の候補プラットフォームの指示を含む、プラットフォーム承認要求を受け取ることと、
プラットフォーム承認要求に応答して、１つ以上の候補プラットフォームのうちの特定の候補プラットフォームに対して能力判定動作を行うことと、
能力判定動作の結果に少なくとも部分的に基づいて、プロバイダネットワークの１つ以上の制御サーバを介して少なくとも部分的に構成される仮想化リソースをホストするために使用される承認されたプラットフォームとして、候補プラットフォームを指定することと、
承認されたプラットフォームで特定の仮想化リソースをインスタンス化するために、クライアントからのリソース要求に応答して、１つ以上の制御サーバのうちの特定の制御サーバから１つ以上の構成コマンドを発行することと、
１つ以上の構成コマンドに応答して、承認されたプラットフォームでインスタンス化されるリモートコマンドエグゼキュータによって開始される動作の結果に少なくとも部分的に基づいて、リソース要求に対する回答をクライアントに提供することであって、リモートコマンドエグゼキュータは、動作を開始した後に終了する、提供することと、を含む、方法。
付記３１．能力判定動作は、候補プラットフォームがリモートコマンドエグゼキュータをインスタンス化するように構成可能であるかどうかを検査することを含む、付記３０に記載の方法。
付記３２．能力判定動作は、候補プラットフォームが、共通ゲートウェイインターフェース（ＣＧＩ）に従ってリモートコマンドエグゼキュータをインスタンス化するように構成可能なウェブサーバを備えているかどうかを検査することを含む、付記３０に記載の方法。
付記３３．プロバイダネットワークによって実装されるネットワークアクセス可能サービスは、１組のサポートされる仮想化リソースインスタンスタイプを定義し、
プラットフォーム承認要求で、１組のサポートされる仮想化リソースインスタンスタイプのうちの特定の仮想化リソースインスタンスタイプの指示を受け取ることをさらに含み、特定の候補プラットフォームは、特定の仮想化リソースインスタンスタイプをサポートすることを目標にされ、能力判定動作は、特定の仮想化リソースインスタンスタイプを特定の候補プラットフォームに実装することができるかどうかを検査するための試験を含む、付記３０に記載の方法。
付記３４．プロバイダネットワークによって実装されるネットワークアクセス可能サービスは、１組のサポートされる仮想化リソースインスタンスタイプを定義し、
プラットフォーム承認要求で、１組のサポートされる仮想化リソースインスタンスタイプのメンバーではない異なる仮想化リソースインスタンスタイプの指示を受け取ることをさらに含み、特定の候補プラットフォームは、異なる仮想化リソースインスタンスタイプをサポートすることを目標にされる、付記３０に記載の方法。
付記３５．プラットフォーム承認要求は、サードパーティ相互作用のために少なくとも部分的に実装されるプログラマチックインターフェースを介して受け取られ、１つ以上の候補プラットフォームは、プロバイダネットワークの外部にある施設に存在する、付記３０に記載の方法。
付記３６．１つ以上の候補プラットフォームは、存在点（ＰＯＰ）の施設に存在する、付記３０に記載の方法。
付記３７．１つ以上のコンピューティングデバイスを備えるシステムであって、該１つ以上のコンピューティングデバイスは、
複数のネットワークアクセス可能サービスを実装するプロバイダネットワークで、仮想化リソースをホストするための１つ以上の候補プラットフォームの指示を含む、プラットフォーム承認要求を受け取り、
プラットフォーム承認要求に応答して、１つ以上の候補プラットフォームのうちの特定の候補プラットフォームに対する能力判定動作を開始し、
能力判定動作の結果に少なくとも部分的に基づいて、プロバイダネットワークの１つ以上の制御サーバを介して少なくとも部分的に構成される仮想化リソースをホストするために使用される承認されたプラットフォームとして、特定の候補プラットフォームを指定し、そして、
承認されたプラットフォームでインスタンス化されるリモートコマンドエグゼキュータを使用して、承認されたプラットフォームで特定の仮想化リソースを構成するために、クライアントからのリソース要求に応答して、１つ以上の制御サーバのうちの特定の制御サーバから１つ以上の構成コマンドを発行するように構成される、システム。
付記３８．特定の制御サーバは、
リモートコマンドエグゼキュータによって開始される動作の結果に少なくとも部分的に基づいて、リソース要求に対する回答をクライアントに提供するようにさらに動作可能であり、リモートコマンドエグゼキュータは、動作を開始した後に終了するように構成される、付記３７に記載のシステム。
付記３９．能力判定動作は、候補プラットフォームがリモートコマンドエグゼキュータをインスタンス化するように構成可能であるかどうかを検査することを含む、付記３７に記載のシステム。
付記４０．能力判定動作は、候補プラットフォームが、共通ゲートウェイインターフェース（ＣＧＩ）に従ってリモートコマンドエグゼキュータをインスタンス化するように構成可能なウェブサーバを備えているかどうかを検査することを含む、付記３７に記載のシステム。
付記４１．プラットフォーム承認要求は、特定の仮想化リソースインスタンスタイプの指示を含み、特定の候補プラットフォームは、特定の仮想化リソースインスタンスタイプをサポートすることを目標にされる、付記３７に記載のシステム。
付記４２．能力判定動作は、特定の仮想化リソースインスタンスタイプを特定の候補プラットフォームに実装することができるかどうかを検査するための試験を含む、付記４１に記載のシステム。
付記４３．プロバイダネットワークは、１組のサポートされる仮想化リソースインスタンスタイプを定義し、特定の仮想化リソースインスタンスタイプは、１組のサポートされる仮想化リソースインスタンスタイプに属する、付記３７に記載のシステム。
付記４４．プロバイダネットワークは、１組のサポートされる仮想化リソースインスタンスタイプを定義し、特定の仮想化リソースインスタンスタイプは、１組のサポートされる仮想化リソースインスタンスタイプに属さず、プラットフォーム承認要求は、特定の候補プラットフォームが特定の仮想化リソースインスタンスタイプを実装することができることを検証するために使用される１つ以上の試験の指示を含む、付記３７に記載のシステム。
付記４５．１つ以上の制御サーバは、特定の候補プラットフォームを、少なくとも１組のデフォルトの仮想化リソースインスタンスタイプの承認されたプラットフォームとして指定するように構成され、クライアントからのリソース要求は、１組に含まれないインスタンスタイプの特定の仮想化リソースインスタンスの指示を含み、特定の仮想化リソースインスタンスを構成するために、１つ以上の構成コマンドが発行される、付記３７に記載のシステム。
付記４６．特定の仮想化リソースインスタンスの特定のプロパティが、デフォルトの仮想化リソースインスタンスタイプのそれぞれの対応するプロパティとは異なり、特定のプロパティは、（ａ）性能プロパティ、（ｂ）記憶容量プロパティ、または、（ｃ）サポートされるソフトウェアの特徴プロパティ、のうちの少なくとも１つを含む、付記４５に記載のシステム。
付記４７．１つ以上の構成コマンドは、ハイパーテキストトランスファープロトコルの変形を介して伝送される、付記３７に記載のシステム。
付記４８．１つ以上の構成コマンドは、ＪａｖａＳｃｒｉｐｔオブジェクト表記法（ＪＳＯＮ）フォーマットの変形に従って伝送される、付記３７に記載のシステム。
付記４９．１つ以上のコンピューティングデバイスは、
クライアントが、（ａ）プロバイダネットワーク及び（ｂ）承認されたプラットフォームの保有者を含む、１組の利用可能なソースの中から、特定のリソースのプラットフォームソースを選択することを可能にする、プログラマチックインターフェースを実装するようにさらに動作可能である、付記３７に記載のシステム。
付記５０．プラットフォーム承認要求をクライアントから受け取り、１つ以上の候補プラットフォームがクライアントのクライアントネットワークに存在する、付記３７に記載のシステム。
付記５１．１つ以上のプロセッサで実行されたときに、プロバイダネットワークの制御サーバを実装するプログラム命令を記憶する、非一時的なコンピュータアクセス可能な記憶媒体であって、該制御サーバは、
クライアントからインスタンス構成要求を受け取った後に、その構成がプロバイダネットワーク内から管理されるリソースインスタンスを使用して少なくとも部分的に実装されるネットワークアクセス可能サービスに向けられ、
インスタンス構成要求に対応する１つ以上の構成動作が、プロバイダネットワークの外部にあるリモートプラットフォームで行われるかどうかを判定し、
１つ以上の構成動作が、プロバイダネットワークの外部にあるリモートプラットフォームで行われると判定することに応答して、
１つ以上のコマンドを、プロバイダネットワークの外部にある選択されたリモートプラットフォームに発行し、
選択されたリモートプラットフォームから、１つ以上のコマンドの結果を受け取り、
１つ以上の構成動作が、プロバイダネットワークの外部にあるリモートプラットフォームで行われないと判定することに応答して、
１つ以上のコマンドを、プロバイダネットワーク内の選択されたインスタンスホストに発行し、
選択されたインスタンスホストから、１つ以上のコマンドの結果を受け取り、
１つ以上のコマンドの結果に少なくとも部分的に基づいて、インスタンス構成要求に対する応答をクライアントに提供するように構成される、非一時的なコンピュータアクセス可能な記憶媒体。
付記５２．１つ以上の構成動作がプロバイダネットワークの外部にあるリモートプラットフォームで行われると決定することに応答して、制御サーバは、
１つ以上のコマンドを、プロバイダネットワークの外部にある選択されたリモートプラットフォームのコマンド受信機に発行するように構成され、コマンド受信機は、１つ以上のコマンドのうちの特定のコマンドに応答して、選択されたサードパーティプラットフォームのリモートコマンドエグゼキュータをインスタンス化するように構成され、リモートコマンドエグゼキュータは、特定のコマンドに対応する特定の動作を開始して、特定の動作の結果をコマンド受信機に提供し、そして、抜けるように構成される、付記５１に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記５３．１つ以上のコマンドを選択されたリモートプラットフォームに発行する前に、制御サーバは、プロバイダネットワーク内に実装されるロックマネージャを使用して、選択されたリモートプラットフォームに対するロックを取得するように構成される、付記５１に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記５４．１つ以上のプロセッサで実行されたときに、
サードパーティプラットフォームが、１つ以上の仮想化リソースをホストする候補とみなされることを示す、プラットフォーム承認要求を受け取り、
特定のコマンドプロトコルをサポートするように構成されるリモートコマンドエグゼキュータをサードパーティプラットフォームに実装できるかどうかを検査する少なくとも１つの試験を含む、サードパーティプラットフォームで実行される１つ以上の能力試験を識別し、
サードパーティプラットフォームに対する１つ以上の能力試験の実行を開始し、そして、
１つ以上の能力試験の結果に少なくとも部分的に基づいて、サードパーティプラットフォームを承認するかどうかを判定する、プログラム命令を記憶する、非一時的なコンピュータアクセス可能な記憶媒体。
付記５５．１つ以上の能力試験は、プロバイダネットワークのネットワークアクセス可能サービスでサポートされる特定のインスタンスタイプに対して定義される性能レベルに従って、サードパーティプラットフォームの性能能力を検査するための、特定の性能試験を含む、付記５４に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記５６．１つ以上の能力試験は、承認要求の開始側によって定義される特定のインスタンスタイプについて、承認要求で示される性能レベルに従って、サードパーティプラットフォームの性能能力を検査するための、特定の性能試験を含む、付記５４に記載の非一時的なコンピュータアクセス可能な記憶媒体。
付記５７．命令は、１つ以上のプロセッサで実行されたときに
サードパーティプラットフォームの承認を新しくするために、サードパーティプラットフォームに対して再実行される能力試験反復スケジュールを決定し、
スケジュールに従って能力試験反復を開始し、そして、
反復の結果に少なくとも部分的に基づいて、承認を新しくするかどうかを判定する、付記５４に記載の非一時的なコンピュータアクセス可能な記憶媒体。
実例となるコンピュータシステム

少なくともいくつかの実施形態において、種々の制御サーバ構成要素及び／またはインスタンスホストの機能を実装するための技法を含む、本明細書で説明される技術の１つ以上の一部分または全部を実装するサーバは、１つ以上のコンピュータアクセス可能な媒体を含む、またはそれにアクセスするように構成される、汎用コンピュータシステムを含み得る。図１６は、そのような汎用コンピューティングデバイス３０００を例示する。例示される実施形態において、コンピューティングデバイス３０００は、入力／出力（Ｉ／Ｏ）インターフェース３０３０を介してシステムメモリ３０２０に連結される、１つ以上のプロセッサ３０１０を含む。コンピューティングデバイス３０００はさらに、Ｉ／Ｏインターフェース３０３０に連結される、ネットワークインターフェース３０４０を含む。

種々の実施形態において、コンピューティングデバイス３０００は、１つのプロセッサ３０１０を含むユニプロセッサシステム、または複数（例えば、２つ、４つ、８つ、または別の適切な数）のプロセッサ３０１０を含むマルチプロセッサシステムであり得る。プロセッサ３０１０は、命令を実行することができる、任意の適切なプロセッサであり得る。例えば、種々の実施形態において、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ ＩＳＡ等の様々な命令セットアーキテクチャ（ＩＳＡ）のいずれか、または任意の他の適切なＩＳＡを実装する、汎用または組み込みプロセッサであり得る。マルチプロセッサシステムにおいて、プロセッサ３０１０のそれぞれは、必ずではないが、一般的に、同じＩＳＡを実装し得る。

システムメモリ３０２０は、プロセッサ（複数可）３０１０によってアクセス可能な命令及びデータを記憶するように構成され得る。種々の実施形態において、システムメモリ３０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプメモリ、または任意の他のタイプのメモリ等の、任意の適切なメモリ技術を使用して実装され得る。図示説明される実施形態において、上で説明される方法、技法、及びデータ等の、１つ以上の所望の機能を実装するプログラム命令及びデータは、システムメモリ３０２０内にコード３０２５及びデータ３０２６として記憶されるように示される。

一実施形態において、Ｉ／Ｏインターフェース３０３０は、プロセッサ３０１０と、システムメモリ３０２０と、ネットワークインターフェース３０４０または他の周辺インターフェースを含む、デバイスの中の任意の周辺デバイスとの間のＩ／Ｏトラフィックを協調させるように構成され得る。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０は、一方の構成要素（例えば、システムメモリ３０２０）からのデータ信号を、もう一方の構成要素（例えば、プロセッサ３０１０）による使用に好適なフォーマットに変換するために、任意の必要なプロトコル、タイミング、または他のデータ変換を行い得る。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０は、例えば、周辺構成要素相互接続（ＰＣＩ）バス規格またはユニバーサルシリアルバス（ＵＳＢ）規格の変形等の、種々のタイプの周辺バスを通して取り付けられるデバイスのためのサポートを含み得る。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０の機能は、例えば、ノースブリッジ及びサウスブリッジ等の、２つ以上の別個の構成要素に分割され得る。また、いくつかの実施形態において、システムメモリ３０２０へのインターフェース等の、Ｉ／Ｏインターフェース３０３０の機能の一部または全部が、プロセッサ３０１０の中へ直接組み込まれ得る。

ネットワークインターフェース３０４０は、例えば、コンピューティングデバイス３０００と、図１〜図１５で例示されるような他のコンピュータシステムまたはデバイス等の、１つまたは複数のネットワーク３０５０に取り付けられる別のデバイス３０６０との間で、データを交換することを可能にするように構成され得る。種々の実施形態において、ネットワークインターフェース３０４０は、例えば、複数のタイプのイーサネット（登録商標）ネットワーク等の、任意の適切な有線または無線の一般的なデータネットワークを介した通信をサポートし得る。加えて、ネットワークインターフェース３０４０は、アナログ音声ネットワークまたはデジタルファイバー通信ネットワーク等の電気通信／電話通信ネットワークを介した通信、ファイバーチャネルＳＡＮ等のストレージエリアネットワークを介した通信、または任意の他の適切なタイプのネットワーク及び／またはプロトコルを介した通信をサポートし得る。

いくつかの実施形態において、システムメモリ３０２０は、対応する方法及び装置の実施形態を実装するための、図１〜図１５について上で説明されるような、プログラム命令及びデータを記憶するように構成される、コンピュータアクセス可能な媒体の一実施形態であり得る。しかしながら、他の実施形態において、プログラム命令及び／またはデータは、異なるタイプのコンピュータアクセス可能な媒体で受け取られ、それに送られ、または記憶され得る。全般的に、コンピュータアクセス可能な媒体としては、Ｉ／Ｏインターフェース３０３０を介してコンピューティングデバイス３０００に連結されるディスクまたはＤＶＤ／ＣＤ等の、磁気もしくは光媒体等の非一時的な記憶媒体またはメモリ媒体が挙げられ得る。非一時的なコンピュータアクセス可能な記憶媒体としてはまた、コンピューティングデバイス３０００のいくつかの実施形態においてシステムメモリ３０２０または別のタイプのメモリとして含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の、任意の揮発性または不揮発性媒体も挙げられ得る。さらに、コンピュータアクセス可能な媒体としては、ネットワークインターフェース３０４０を介して実装され得るようなネットワーク及び／または無線リンク等の通信媒体を介して運搬される、電気信号、電磁信号、もしくはデジタル信号等の、伝送媒体または伝送信号が挙げられ得る。図１５で例示されるような複数のコンピューティングデバイスの一部分または全部は、種々の実施形態において、説明される機能を実装するために使用され得、例えば、様々な異なるデバイス及びサーバの上で動作しているソフトウェア構成要素は、機能を提供するために協働し得る。いくつかの実施形態において、説明される機能の一部分は、汎用コンピュータシステムを使用して実装されることに加えて、またはその代わりに、記憶デバイス、ネットワークデバイス、または特殊用途コンピュータシステムを使用して実装され得る。「コンピューティングデバイス」という用語は、本明細書で使用されるときに、少なくとも全てのこれらのタイプのデバイスを指し、また、これらのタイプのデバイスに限定されない。
結論

種々の実施形態はさらに、コンピュータアクセス可能な媒体に関する、上の説明に従って実装される命令及び／またはデータを受け取ること、送ること、または記憶することを含み得る。概して、コンピュータアクセス可能な媒体としては、磁気または光媒体等の記憶媒体またはメモリ媒体、例えばディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性または不揮発性媒体、ならびにネットワーク及び／または無線リンク等の通信媒体を介して運搬される、電気信号、電磁信号、またはデジタル信号等の伝送媒体または信号が挙げられ得る。

図面で図示され、本明細書で説明される様々な方法は、例示的な方法の実施形態を表す。それらの方法は、ソフトウェアで、ハードウェアで、またはそれらの組み合わせで実装され得る。方法の順序は、変更され得、また、種々の要素の追加、並べ替え、組み合わせ、省略、修正等が行われ得る。

本開示を利用する当業者には明らかなように、種々の修正及び変更が行われ得る。全てのそのような修正及び変更を含むことが意図され、故に、上の説明は、限定的な意味ではなく、例示的な意味を有するとみなされるべきである。

Claims (15)

1. システムであって、
   ネットワークアクセス可能サービスのリソースインスタンスを実装するように構成可能な複数のインスタンスホストと、
   前記複数のインスタンスホストでリソースインスタンスの構成を管理するように構成される１つ以上の制御サーバと、を備え、
   前記１つ以上の制御サーバのうちの選択された制御サーバは、クライアントからのインスタンス構成要求に応答して、１つ以上のコマンドのシーケンスを、前記複数のインスタンスホストのうちの選択されたインスタンスホストに伝送するように構成され、
   前記選択されたインスタンスホストは、前記１つ以上のコマンドのシーケンスを受け取ることに応答して、リモートコマンドエグゼキュータをインスタンス化するように構成され、
   前記リモートコマンドエグゼキュータは、前記１つ以上のコマンドのシーケンスに対応する１つ以上の構成動作を開始するように構成され、
   前記選択された制御サーバは、前記１つ以上の構成動作の結果に少なくとも部分的に基づいて、前記インスタンス構成要求に対する応答を前記クライアントに提供するように構成される、システム。
2. 前記選択されたインスタンスホストは、
   ウェブサーバで前記１つ以上のコマンドのシーケンスを受け取るようにさらに構成され、
   前記ウェブサーバは、共通ゲートウェイインターフェース（ＣＧＩ）規格に従って、前記リモートコマンドエグゼキュータをインスタンス化するように構成される、請求項１に記載のシステム。
3. 前記選択されたインスタンスホストは、
   前記選択されたインスタンスホストに実装されるイベントモニタに加入し、そして、
   安全なネットワーキングプロトコルを介して、前記１つ以上の制御サーバのうちの特定の制御サーバに、前記選択されたインスタンスホストで前記イベントモニタによって示されるイベントの発生の通知を伝送するように構成される、イベントディスパッチャを備える、請求項１に記載のシステム。
4. 前記特定の制御サーバは、
   前記通知に少なくとも部分的に基づいて、リソースインスタンスの状態情報を更新するようにさらに構成される、請求項３に記載のシステム。
5. 前記１つ以上の制御サーバは、制御サーバプールの複数の制御サーバを含み、前記制御サーバプールのサイズは、特定のタイプの不具合のイベントが生じた場合に、前記複数のインスタンスホストに実装されるリソースインスタンスを回復するためにインスタンス回復構成動作が行われる推定の率に少なくとも部分的に基づいて決定される、請求項１に記載のシステム。
6. 前記選択されたインスタンスホストは、プロバイダネットワークの第１の可用性コンテナの第１のデータセンター内に位置し、前記選択された制御サーバは、前記プロバイダネットワークの第２の可用性コンテナ内の異なるデータセンター内に位置し、前記第１の可用性コンテナは、前記第２の可用性コンテナとは異なる可用性プロファイルを有する、請求項１に記載のシステム。
7. 前記１つ以上のコマンドのシーケンスを伝送する前に、前記選択された制御サーバは、前記選択されたインスタンスホストに対するロックを取得するように構成される、請求項１に記載のシステム。
8. 前記１つ以上のコマンドのシーケンスは、複数のコマンドタイプをサポートするコマンドプロトコルに従って伝送され、前記複数のコマンドタイプのうちの少なくとも１つのコマンドタイプのサブセットは、冪等コマンドを含む、請求項１に記載のシステム。
9. 前記１つ以上の制御サーバのうちの特定の制御サーバは、
   前記複数のコマンドタイプのうちの特定のコマンドタイプを使用して、前記選択されたインスタンスホストから１つ以上の性能メトリクスを収集するようにさらに構成される、請求項８に記載のシステム。
10. 前記選択されたインスタンスホストは、（ａ）前記クライアントの識別情報、（ｂ）前記インスタンス構成要求で示されるリソースインスタンスタイプ、（ｃ）前記複数のインスタンスホストと関連付けられる１つ以上の性能メトリクス、または（ｄ）１つ以上のプライシングポリシー、のうちの１つ以上に少なくとも部分的に基づいて、前記複数のインスタンスホストから選択される、請求項６に記載のシステム。
11. クライアントからのインスタンス構成要求であって、１つ以上のネットワークアクセス可能サービスのうちの特定のサービスに向けられる、前記インスタンス構成要求に応答して、
    制御サーバによって、複数のインスタンスホストのうちの選択されたインスタンスホストに１つ以上のコマンドを伝送することと、
    制御サーバによって、前記選択されたインスタンスホストから、前記１つ以上のコマンドに応答して前記選択されたインスタンスホストでインスタンス化されるリモートコマンドエグゼキュータによって前記選択されたインスタンスホストで開始される、１つ以上の構成動作の結果を受け取ることと、
    制御サーバによって、前記１つ以上の構成動作の結果に少なくとも部分的に基づいて、前記インスタンス構成要求に対する応答を前記クライアントに提供することと、を含む、方法。
12. 前記制御サーバは、（ａ）伝送される前記１つ以上のコマンドを決定するように構成されるワークフローマネージャ、（ｂ）前記１つ以上のコマンドを前記選択されたインスタンスホストに伝送するように構成される通信モジュール、及び（ｃ）前記選択されたインスタンスホストから非同期イベント通知を受け取るように構成されるイベントリスナ、のうちの１つ以上を備える、請求項１１に記載の方法。
13. 前記１つ以上のコマンドを伝送する前に、前記制御サーバは、前記選択されたインスタンスホストに対するロックを取得するように構成される、請求項１１に記載の方法。
14. 複数のコマンドタイプのうちの特定のコマンドタイプを使用して、前記選択されたインスタンスホストから１つ以上の性能メトリクスを収集することをさらに含む、請求項１１に記載の方法。
15. 前記１つ以上のコマンドは、安全なバージョンのハイパーテキストトランスファープロトコルを介して伝送される、請求項１１に記載の方法。

Images