(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-04-12
(45)【発行日】2022-04-20
(54)【発明の名称】分散システムにおける顧客志向ネットワークの限界
(51)【国際特許分類】
H04L 41/40 20220101AFI20220413BHJP
H04L 45/42 20220101ALI20220413BHJP
【FI】
H04L41/40
H04L45/42
(21)【出願番号】P 2020047290
(22)【出願日】2020-03-18
(62)【分割の表示】P 2018146686の分割
【原出願日】2014-11-25
【審査請求日】2020-03-31
(32)【優先日】2013-11-25
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2013-11-25
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】507303550
【氏名又は名称】アマゾン・テクノロジーズ・インコーポレーテッド
(74)【代理人】
【識別番号】100098394
【氏名又は名称】山川 茂樹
(74)【代理人】
【識別番号】100064621
【氏名又は名称】山川 政樹
(72)【発明者】
【氏名】リザック,アヴィチャイ・メンドル
【審査官】大石 博見
(56)【参考文献】
【文献】特開2007-074055(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 41/40
H04L 45/42
(57)【特許請求の範囲】
【請求項1】
ネットワーク・アクセス可能サービスの一部分において、ネットワーク・トラフィックの1つ以上のカテゴリーに対して
データ送信のための資源限界を適用することと、
データ送信のための前記資源限界の適用後に、データ送信のための前記資源限界を低減させるためのプログラマチック・リクエストを取得することと、
少なくとも部分的に前記プログラマチック・リクエストに基づいて、1つ以上の作用を開始することと、
を1つ以上のコンピューティング装置において実施すること
を備える
方法。
【請求項2】
前記ネットワーク・アクセス可能サービスの前記一部分は、1つ以上のサービス・インスタンスを備え、前記方法は、前記1つ以上のコンピューティング装置において、
前記1つ以上のサービス・インスタンスにおいて、ネットワーク・トラフィックの前記1つ以上のカテゴリーに対応する1つ以上のメトリックスを取得することと、
前記1つ以上の作用を開始する前に、前記取得された1つ以上のメトリックスを使用して、資源使用が前記プログラマチック・リクエストにおいて示された閾値基準を満たしていることを検出することと、
を前記1つ以上のコンピューティング装置において実施することを更に備える、請求項1に記載の方法。
【請求項3】
前記プログラマチック・リクエストは、(a)超えられるべきでない平均的トラフィック送信速度、(b)超えられるべきでないピーク・トラフィック送信速度、(c)転送されるデータのバイト数に対する上限、又は(d)転送されるネットワーク・メッセージの数に対する上限、のうちの1つ以上を備える低減された資源限界を示す、請求項1又は請求項2に記載の方法。
【請求項4】
前記プログラマチック・リクエストは、資源限界が低減されるべきネットワーク・トラフィックの少なくとも特定のカテゴリーを示し、前記特定のカテゴリーは、(a)1つ以上の公衆インターネット・リンクにわたって流れるトラフィック、(b)プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、(c)2つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、(d)1つ以上のプロバイダ・ネットワークの一対のネットワーク・アクセス可能サービス間を流れるトラフィック、又は(e)一対の地理的場所間を流れるトラフィック、のうちの1つ以上を備える、請求項1から請求項3のいずれか一項に記載の方法。
【請求項5】
前記プログラマチック・リクエストは、(a
)特定のサービス・インスタンスから1つ以上の宛先へ流れるトラフィック、(b)1つ以上のソースから前記特定のサービス・インスタンスへ流れるトラフィック、のうちの1つ以上を含む、資源限界が低減されるべきネットワーク・トラフィック・フローの1つ以上の方向を示す、請求項1から請求項4のいずれか一項に記載の方法。
【請求項6】
1つ以上のコンピューティング装置を備えるシステムであって、
前記1つ以上のコンピューティング装置は、1つ以上のプロセッサ上で又は1つ以上のプロセッサにわたって実行されると、前記1つ以上のコンピューティング装置に、
ネットワーク・アクセス可能サービスの一部分において、ネットワーク・トラフィックの1つ以上のカテゴリーに対して
データ送信のための資源限界を適用させ、
データ送信のための前記資源限界の適用後に、データ送信のための前記資源限界を低減させるためのプログラマチック・リクエストを取得させ、且つ、
少なくとも部分的に前記プログラマチック・リクエストに基づいて、1つ以上の作用を開始させる
命令を含む、
システム。
【請求項7】
前記プログラマチック・リクエストは、(a)第1のサービス・インスタンスと第2のサービス・インスタンスとを備える、ネットワーク・アクセス可能サービスのサービス・インスタンスのサブセット、及び(b)閾値を超えるべきでない、前記サブセットの組み合わされた資源使用を示す、請求項6に記載のシステム。
【請求項8】
前記プログラマチック・リクエストは、前記資源限界が低減されるべき時間期間を示す、請求項6又は請求項7に記載のシステム。
【請求項9】
前記プログラマチック・リクエストは、前記ネットワーク・アクセス可能サービスに関連付けられた複数のアカウントのうちの1つ以上のアカウントを示し、且つ、前記資源限界は、前記1つ以上のアカウントに関連付けられたネットワーク・トラフィックに対して低減されるべきである、請求項6から請求項8のいずれか一項に記載のシステム。
【請求項10】
前記プログラマチック・リクエストは、前記資源限界が低減されたかどうかを決定するのに、メトリックスが計算されるべき時間期間を示す、請求項6から請求項9のいずれか一項に記載のシステム。
【請求項11】
1つ以上のプロセッサ上で又は1つ以上のプロセッサにわたって実行されると、1つ以上のコンピュータ・システムに、
ネットワーク・アクセス可能サービスの一部分において、ネットワーク・トラフィックの1つ以上のカテゴリーに対して
データ送信のための資源限界を課させ、
データ送信のための前記資源限界の適用後に、データ送信のための前記資源限界を低減させるためのプログラマチック・リクエストを取得させ、且つ、
少なくとも部分的に前記プログラマチック・リクエストに基づいて、1つ以上の作用を開始させる
プログラム命令を記憶する
1つ以上の非一過性コンピュータ・アクセス可能記憶媒体。
【請求項12】
前記ネットワーク・アクセス可能サービスの前記一部分は、1つ以上のサービス・インスタンスを備え、前記1つ以上の非一過性コンピュータ・アクセス可能記憶媒体は、1つ以上のプロセッサ上で又は1つ以上のプロセッサにわたって実行されると、前記1つ以上のコンピュータ・システムに、更に、
前記1つ以上のサービス・インスタンスにおいて、ネットワーク・トラフィックの前記1つ以上のカテゴリーに対応する1つ以上のメトリックスを取得させ、且つ、
前記1つ以上の作用を開始する前に、前記取得された1つ以上のメトリックスを使用して、資源使用が、前記プログラマチック・リクエストに示された閾値基準を満たしていることを検出させる
更なるプログラム命令を記憶する、請求項11に記載の1つ以上の非一過性コンピュータ・アクセス可能記憶媒体。
【請求項13】
前記プログラマチック・リクエストは、(a)超えられるべきでない平均的トラフィック送信速度、(b)超えられるべきでないピーク・トラフィック送信速度、(c)転送されるデータのバイト数に対する上限、又は(d)転送されるネットワーク・メッセージの数に対する上限、のうちの1つ以上を備える低減された資源限界を示す、請求項11又は請求項12に記載の1つ以上の非一過性コンピュータ・アクセス可能記憶媒体。
【請求項14】
前記プログラマチック・リクエストは、資源限界が低減されるべきネットワーク・トラフィックの少なくとも特定のカテゴリーを示し、前記特定のカテゴリーは、(a)1つ以上の公衆インターネット・リンクにわたって流れるトラフィック、(b)プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、(c)2つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、(d)1つ以上のプロバイダ・ネットワークの一対のネットワーク・アクセス可能サービス間を流れるトラフィック、又は(e)一対の地理的場所間を流れるトラフィック、のうちの1つ以上を備える、請求項11から請求項13のいずれか一項に記載の1つ以上の非一過性コンピュータ・アクセス可能記憶媒体。
【請求項15】
前記1つ以上の作用は、(a)1つ以上のパケットを破棄すること、(b)1つ以上のパケットを待ち行列に入れること、(c)特定の時間期間に対して、前記ネットワーク・アクセス可能サービスのサービス・インスタンスにおいて、ネットワーク・トラフィックに対して課せられるべき前記資源限界を増加させること、又は(d)通知を生成すること、のうちの1つ以上を備える、請求項11から請求項14のいずれか一項に記載の1つ以上の非一過性コンピュータ・アクセス可能記憶媒体。
【発明の詳細な説明】
【背景技術】
【0001】
多くの企業や他の組織は、コンピューティング・システムが同一の場所に配置される(例えば、ローカル・ネットワークの一部として)、或いは、多数の別個の地理的場所に配置される(例えば、一つ以上の私的或いは公的中間ネットワークを介して接続された)として、多数のコンピューティング・システムを相互接続するコンピュータ・ネットワークを動作させて、それぞれの動作をサポートする。例えば、単一の組織により且つその代わりに動作される私的データ・センター、および、顧客にコンピューティング資源を提供するようビジネスとしてエンティティによって動作される公的データ・センター等、著しい数の相互接続されたコンピューティング・システムを収容するデータ・センターは一般的になってきている。幾つかの公的データ・センターのオペレーターは、様々な顧客によって所有されるハードウェアについてネットワーク・アクセス、電力、および、安全な設置施設を提供し、他の公的データ・センターのオペレーターは、その顧客によって使用されるよう利用可能にされたハードウェア資源を含む「フルサービス」施設を提供する。しかしながら、典型的なデータ・センターの規模や範囲が増大されると、物理的なコンピューティング資源を提供し、運営し、管理する作業も益々複雑になってくる。
【0002】
商品ハードウェアに対する仮想化技術の出現は、様々なニーズを持つ多数の顧客に対して大規模なコンピューティング資源を管理することに関して利益をもたらすため、様々なコンピューティング資源が多数の顧客によって効率的に且つ安全に共有されることが可能となる。例えば、仮想化技術によると、単一の物理的なコンピューティング・マシンによってホストされる一つ以上のバーチャル・マシンを各ユーザに提供することで、該単一の物理的なコンピューティング・マシンは多数のユーザ間で共有されることができる。各バーチャル・マシンは、ユーザに所与のハードウェア・コンピューティング資源の唯一のオペレーターであり管理者であるといった錯覚を与える一方で、様々なバーチャル・マシン間でアプリケーション隔離やセキュリティを提供する、別個の論理的コンピューティング・システムとして作用するソフトウェア・シミュレーションとして考えられる。更に、幾つかの仮想化技術は、多数の別個の物理的なコンピューティング・システムにわたる多数の仮想プロセッサを含む単一のバーチャル・マシン等、二つ以上の物理的資源にわたる仮想資源を提供することができる。
【0003】
仮想化計算、ストレージ、および、ネットワーク資源のプロバイダによってサポートされる機能性や特徴が増大され、大規模なプロバイダによって使用されるハードウェア・プラットホームの隊が増大されると、ネットワーク・トラフィックの流れを管理する等、プラットホームに対する運営管理制御動作の実施自体が比較的複雑になる。多くの場合、このようなプラットホームで実行されるアプリケーションの機能性や有用性は、プロバイダ・ネットワークの他の部分および/またはクライアント、第三者等の外部エンティティとのネットワーク通信に広く依存し得る。分散システムのオペレーターは、所望のアプリケーション性能レベルを実現しようと典型的にセットアップされた高帯域幅ネットワーク・インフラストラクチャを有してもよい。しかしながら、高帯域幅ネットワーク装置およびリンクが提供されたとしても、特に、多くのタイプの展開されたアプリケーションに対して時間的に変化し、場所に依存する帯域幅要件を考慮するとネットワーク帯域幅は、多くの場合、障害資源となり得る。単一のハードウェア・プラットホーム上で実施される様々なバーチャル・マシンがプラットホームの共有ネットワークの構成要素を用いて満たされなくてはならない幅広く変化するネットワーク要件を有し、所与のハードウェア・プラットホームでインスタンス化されるアプリケーションやバーチャル・マシンのセットが時間と共に変化し得るため、仮想化はネットワーク帯域幅(並びに、待ち時間や他のネットワーク特徴)の管理を益々難しい問題にしている。
【図面の簡単な説明】
【0004】
【
図1】
図1は、少なくとも幾つかの実施形態による、中央化ネットワーク構成サービスが分散コンピューティング環境の複数のノードにおいてネットワーク・トラフィックを管理するよう実施されるシステムの実施例を例示する。
【
図2】
図2は、少なくとも幾つかの実施形態による、それぞれのネットワーク構成サーバーが幾つかの利用可能コンテナそれぞれに確立されるプロバイダ・ネットワーク環境の実施例を例示する。
【
図3】
図3は、少なくとも幾つかの実施形態による、仮想化されたコンピューティング・サービスのインスタンス・ホストにおいてトラフィック分類メタデータを解釈することができるネットワーク・マネージャ・モジュールの実施例を例示する。
【
図4a-4c】
図4a~
図4cは、少なくとも幾つかの実施形態による、インスタンス・ホストにトラフィック分類メタデータを送信するために使用され得るプロトコルの実施例をそれぞれ示す。
【
図5】
図5は、少なくとも幾つかの実施形態による、分散システムの装置においてネットワーク構成に対するネットワーク・トラフィック・カテゴリーを表すために使用され得る分類ツリー・データ構造の実施例を例示する。
【
図6】
図6は、少なくとも幾つかの実施形態による、データ・センターにおいて複数のインスタンス・ホストのネットワーク・トラフィック・カテゴリー情報を組み合わすために使用され得る階層型データ構造の実施例を例示する。
【
図7】
図7は、少なくとも幾つかの実施形態による、ネットワーク・トラフィックの単位のカテゴリーを確定するために分類ツリーと一緒に使用され得るトラフィック分類手順グラフの実施例を例示する。
【
図8】
図8は、少なくとも幾つかの実施形態による、トラフィック分類手順グラフのルックアップ・テーブル・ノードの使用の実施例を例示する。
【
図9】
図9は、少なくとも幾つかの実施形態による、ネットワーク構成サービスの一つ以上のパラメータに対する値を確定するために利用され得る応答メトリックの実施例を例示する。
【
図10】
図10は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実施される動作の態様を例示するフロー図である。
【
図11】
図11は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのトラフィック分類メタデータを生成し分散するために実施され得る動作の態様を例示するフロー図である。
【
図12】
図12は、少なくとも幾つかの実施形態による、トリガとなるイベントに応答してネットワーク管理パラメータを変更するよう実施され得る動作の態様を例示するフロー図である。
【
図13】
図13は、少なくとも幾つかの実施形態による、分散システムのクライアントにネットワーク関連のステータス情報の統一ビューを提供するよう実施される動作の態様を例示するフロー図である。
【
図14】
図14は、少なくとも幾つかの実施形態による、分散システムの少なくともノードのサブセットについてトポロジー可視化サーバーによって生成され得るカスタマイズ可能なヒートマップの実施例を例示する。
【
図15】
図15は、少なくとも幾つかの実施形態による、サービス管理者およびサービスの非管理クライアントに対してヒートマップを生成するために使用され得る収集されたメトリックスの異なるサブセットの実施例を例示する。
【
図16】
図16は、少なくとも幾つかの実施形態による、ネットワーク・トポロジーに対するヒートマップを表示するために使用され得るウェブベースのプログラマチック・インターフェイスの実施例を例示する。
【
図17】
図17は、少なくとも幾つかの実施形態による、プログラマチック・インターフェイスを介してトポロジー可視化サーバーによって受信され得る可視化リクエストの模範的な要素を例示する。
【
図18】
図18は、少なくとも幾つかの実施形態による、分散システムの様々なノードの性能インジケータを有するトポロジーの可視化を生成するよう実施される動作の態様を例示する。
【
図19】
図19は、少なくとも幾つかの実施形態による、それぞれの帯域幅限界およびそれぞれの帯域幅使用価格決定ポリシーが異なるインスタンス・タイプに設定された、ネットワーク・アクセス可能サービスに対して実施され得る計算インスタンス・タイプのセットの実施例を例示する。
【
図20】
図20は、少なくとも幾つかの実施形態による、ネットワーク構成サーバーによって受信され得る資源使用限界低減リクエストの模範的な要素を例示する。
【
図21】
図21は、少なくとも幾つかの実施形態による、ネットワーク・アクセス可能サービスのクライアント・アカウントに対する全体的な資源使用限界設定の確立、および、ユーザ・グループ、個人ユーザ、および、リンク付けされたアカウントに対する関連する資源使用限界設定の確立の実施例を例示する。
【
図22】
図22は、少なくとも幾つかの実施形態による、クライアントがネットワーク・アクセス可能サービスの一つ以上のノードに対する資源使用限界を低減することを可能にするよう実施される動作の態様を例示する。
【
図23】
図23は、少なくとも幾つかの実施形態による、クライアントが分散システムのノードにおいて資源使用限界と関連付けられるクエリーを出すことを可能にするよう実施される動作の態様を例示する。
【
図24】
図24は、少なくとも幾つかの実施形態において使用され得る模範的なコンピューティング装置を例示するブロック図である。
【0005】
本願では、幾つかの実施形態に対する実施例および例示的図面を用いて実施形態が説明されるが、当業者には、実施形態が記載する実施形態または図面に制限されないことが分かるであろう。図面およびそれに伴う詳細な説明は、実施形態を開示する特定の形態に制限することを意図せず、反対に、添付の特許請求の範囲によって定められる精神および範囲内の全ての変更態様、等価物、および、代替物を網羅することが意図されることは理解されるであろう。本願で使用される見出しは、整理目的のためのみに提供され、明細書または特許請求の範囲の範囲を制限するために使用されることは意図されていない。本願を通じて使用されるように、「得る」といった言い方は、強制的な意味合い(即ち、必須の意味)よりもむしろ、許容的な意味合い(即ち、可能性があるといった意味)で用いられる。同様にして、「含む」、「含んでいる」、および、「含み」といった用語は、含むことを意味しているが、これに制限されない。
【発明を実施するための形態】
【0006】
プロバイダ・ネットワーク等の大規模な分散システムにおいてネットワーク動作を構成する方法および装置の様々な実施形態を説明する。幾つかの実施形態では、中央化ネットワーク構成管理スキームが実施され、それによると、分散システムの帯域幅限界、待ち時間の管理、および、多数のノード(ホストおよびネットワーク装置等)に対する他のトラフィック・シェーピング・パラメータに関する様々なタイプの決定が、一つ以上のネットワーク構成サーバー(NCS)でなされる。(幾つかの実施形態では、サーバーの主な責任が様々なトラフィック・カテゴリーに対してそれぞれの帯域幅限界を課すことで分散システムの構成要素で帯域幅の使用を管理することであるため、ネットワーク構成サーバーは「帯域幅仲裁サーバー」と称されてもよい)。例えば、トラフィック分類手順またはルール、および、トラフィックの様々なカテゴリーに対するネットワーク構成オプションを含む決定を実施するために使用されるべきメタデータは、NCSから分散システムのノードへポータブルで解析しやすいフォーマットで送信され得る。分散システムのノードでは、受信されたメタデータが、例えば、仮想化管理ソフトウェア内のネットワーク管理モジ
ュールによって解釈されることで、ネットワーク・トラフィック・スケジュールのパケットまたは他の単位が生成された或いは受信されたままの状態で分類され、BASでなされた決定が適用されることでトラフィックの送信がスケジューリングされるおよび/または制限される。そのため、トラフィック・シェーピングのために使用されるべき論理を生成する責任(少なくとも幾つかの場合では、様々なソースから取得された重要な入力データ・セットの分析を必要とする)は、中央化ネットワーク構成サーバーによって扱われてもよく、論理は比較的簡単な制御モジュールによって様々なノードで適用されてもよい。少なくとも幾つかの実施形態では、所与のノードに送信されるメタデータは、ノードから収集されるメトリックス、当該ノードで行われるアプリケーションの性質等に基づき、当該ノード専用にカスタマイズされてもよい。ネットワーク構成管理技術は、幾つかの実施形態において、分散システムのクライアントが関心のある資源のネットワーク関連のステータスの統一或いは統合見解を得ることを可能にする、プログラマチック・インターフェイスに対するサポートを含んでもよい。少なくとも幾つかの実施形態では、資源使用インジケータ(例えば、適用可能な帯域幅限界に対する測定された帯域幅の比等)は、ヒートマップまたは他の可視化ツールを用いて表示されてもよい。プログラマチック・インターフェイスは、少なくとも幾つかの実施形態において、クライアントおよび/または管理者が中央化ネットワーク構成システムに様々なタイプの構成リクエストを要請できるよう実施されてもよく、その結果、例えば、NCSで確定され様々なノードに広められた分類関連のルールおよび/またはネットワーク設定が変化される。少なくとも幾つかの実施形態では、クライアントは、サービス・インスタンス等、様々な資源について帯域幅限界(または他のタイプの資源使用限界)の軽減をリクエストすることができる。少なくとも幾つかの実施では、ネットワーク構成スキームの一部或いは全部がウェブサービスとして実施されてもよく、例えば、一つ以上のウェブサービス・プログラマチック・インターフェイスがネットワーク構成サーバーとの様々なタイプの相互作用についてサポートされ得る。
【0007】
以下の説明の大半では、中央化ネットワーク構成技術が実施され得る分散システムの実施例として、プロバイダ・ネットワークが使用される。クライアントの分散されたセットにインターネットおよび/または他のネットワークを介してアクセス可能な一つ以上のネットワーク・アクセス可能サービス(例えば、様々なタイプのクラウドベースのデータベース、コンピューティングまたはストレージ・サービス)を提供するよう企業または公共部門組織等のエンティティによってセットアップされたネットワークは、本願ではプロバイダ・ネットワークと称されてもよい。少なくとも幾つかのサービスは、「インスタンス」と呼ばれるサービス単位でクライアント使用のためにパッケージ化されてもよい。例えば、仮想化されたコンピューティング・サービスによってインスタンス化されるバーチャル・マシンは「計算インスタンス」を表し、ストレージ・サービスによってインスタンス化されるブロックレベルの容積等のストレージ装置は「ストレージ・インスタンス」と呼ばれる。幾つかの実施形態では、より高いレベルのサービスのインスタンスが計算インスタンスおよび/またはストレージ・インスタンスを用いてパッケージ化されてもよく、例えば、幾つかの実施形態では、計算およびストレージ・インスタンスの組み合わせを用いてデータベース・インスタンスが構築されてもよい。プロバイダ・ネットワークの様々なネットワーク・アクセス可能サービスのこのような単位が実施されるサーバーおよび/またはストレージ装置等のコンピューティング装置は、本願では「インスタンス・ホスト」と呼ばれ、より簡単に「ホスト」と呼ばれる。本文書の残りでは、所与の通信のソース或いは宛先として使用される場合、「クライアント」といった用語は、プロバイダ・ネットワークの少なくとも一つのネットワーク・アクセス可能サービスにアクセスし利用することができるエンティティ(例えば、組織、多数のユーザを含むグループ、または、単一のユーザ)に所有され、管理され、或いは、割り付けられる全てのコンピューティング装置、プロセス、ハードウェア・モジュール、または、ソフトウェア・モジュールのいずれかを示す。
【0008】
所与のプロバイダ・ネットワークは、プロバイダによって提供されるインフラストラクチャおよびサービスを実施し、構成し、分散するのに必要な物理的および/または仮想化されたコンピュータ・サーバー、それぞれが一つ以上のストレージ装置を含むストレージ・サーバー、ネットワーク機器等の集まりを含む様々な資源プールをホストする多数のデータ・センター(異なる地理的領域にわたって分散され得る)を含み得る。幾つかの異なるハードウェアおよび/またはソフトウェア・コンポーネントは、その幾つかが異なるデータ・センターにおいて、または、異なる地理的領域においてインスタンス化される或いは実行され、様々な実施形態において各サービスを実施するために集合的に使用されてもよい。クライアントは、クライアント所有の或いはクライアント管理の土地に位置する装置、または、プロバイダ・ネットワーク外にあるデータ・センターから、および/または、プロバイダ・ネットワーク内の装置から、プロバイダ・ネットワークで資源およびサービスと相互に作用してもよい。少なくとも幾つかの実施形態では、様々なタイプの計算インスタンスを提供する仮想化されたコンピューティング・サービスは、プロバイダ・ネットワーク内で実施されてもよく、このような計算インスタンスはクライアントに割り付けられてもよい。プロバイダ・ネットワークの他のサービスは、このような計算インスタンスから、並びに、外部の場所からアクセスされ得る。プロバイダ・ネットワークは、本願記載の帯域幅管理技術の多くが実施され得る一つの模範的な状況として機能するが、これらの技術は、例えば、アプリケーションの異なるコンポーネントが時間的に変化する帯域幅のニーズを持つ大規模な分散アプリケーション環境等、プロバイダ・ネットワークよりも他のタイプの分散システムに適用されてもよいことに注意する。
【0009】
少なくとも一つの実施形態によると、幾つかのNCSは、プロバイダ・ネットワーク内の様々な場所でインスタンス化されてもよく、このとき、NCSの数および分散は、例えば、以下に説明する性能および/または利用可能性基準に基づいて確定される。NCSは、帯域幅管理の決定を補助するよう、プロバイダ・ネットワークの様々なノードから、例えば、プロバイダ・ネットワークにおいて実施される様々なタイプのサービスのインスタンス・ホストから、および/または、様々なタイプのネットワーク装置(スイッチ、ルーター、ゲートウェイ等)からネットワーク関連のメトリックスを取得するよう構成され得る。例えば、時間間隔中の所与のホストにおける実際の入来する/出発するネットワーク・トラフィックに関する情報、時間間隔中にドロップされたパケットの数、現在の帯域幅限界の実施により送信が遅延されたパケットの数、パケットのサイズ、トラフィックを所与のノードに或いは所与のノードから生じさせたアプリケーション、トラフィックを開始させたクライアント、および/または、様々な送信に伴われるエンドポイントのIPアドレスが、様々な実施形態において収集されてもよい。幾つかの実施形態では、他のソースからの入力が帯域幅管理の決定を行う際に使用されてもよい。例えば、分散型サービス妨害攻撃(DDOS)等のネットワーク侵入または攻撃を特定するようセキュリティ・サービスが幾つかのプロバイダ・ネットワークで実施されてもよく、潜在的な攻撃に関する警報は帯域幅限界の変化またはトラフィック・カテゴリーの定義に影響を及ぼし得る。少なくとも一つの実施形態では、プロバイダ・ネットワークは、例えば、管理および/または請求目的のために、IPアドレス毎にまたはクライアント毎にネットワーク・トラフィック・メトリックスを集めるサービスを含んでもよく、このような集める側はNCSに入力を供給してもよい。幾つかの実施形態では、プロバイダ・ネットワークの一つ以上のネットワーク・アクセス可能サービスのクライアントおよび/または管理者は、例えば、特定されたインスタンス・ホストまたはネットワーク装置に対する一つ以上の帯域幅管理パラメータを無効にするよう、NCSに帯域幅関連リクエストまたは他の構成リクエストを要請してもよく、このようなリクエストはNCSで行われる決定にも寄与し得る。
【0010】
このような入力に少なくとも部分的に基づき、所与のNCSは、プロバイダ・ネットワークの所与のノードで使用されるべき様々なネットワーク構成オプションおよび/または手順を確定してもよい。幾つかの場合では、パラメータを確定する際、一つ以上のグロー
バルおよび/またはローカル・ネットワーク管理ポリシーも考慮され得る。一実施形態では、カテゴリーそれぞれについて、帯域幅限界、待ち時間の目標または制約等の様々なネットワーク構成オプションと共に、トラフィック・カテゴリーのセットまたは階層が確定されてもよい。幾つかの実施では、フラットな分類(一つのレベルのみを有する階層に等しい)が使用されてもよく、他の実施では、異なるレベルのノード間で親子関係を有する多レベルの階層が使用されてもよい。後続する説明では、本願で使用する「階層」といった用語は、単一レベルのまたはフラットな分類と、親子関係を示す多レベルの分類との両方を網羅することを意図している。階層に加えて、任意の所与のネットワーク・パケット(または、データ転送の全ての適当な単位)をカテゴリーの一つに分類するために使用される手順(例えば、適用されるべき決定ステップまたはルールのシーケンス)が確定されてもよい。トラフィック・カテゴリーに関する情報、および、トラフィック単位をカテゴリーにマッピングするために使用される論理またはルールは、本願では合わせて「トラフィック分類メタデータ」または「分類メタデータ」と呼ばれる。少なくとも幾つかの実施形態において、所与のホストが別のホストとは異なる組み合わせのサービス・インスタンスを有し得、所与のホストのサービス・インスタンスで実施されるアプリケーションのネットワーク要件が他のアプリケーション(同じホストにある、または、他のホストにある)のネットワーク要件と異なり得るため、異なるセットのネットワーク構成パラメータが異なるホストに適当となり得る。したがって、少なくとも幾つかの実施形態では、分類メタデータは少なくとも幾つかのノードについてカスタマイズされてもよく、例えば、インスタンス・ホストIH1等、プロバイダ・ネットワークの一つのノードについて生成された分類メタデータは、インスタンス・ホストIH2等の異なるノードについて生成された分類メタデータと異なってもよい。異なるセットのトラフィック・カテゴリーが異なるノードに対して定められてもよく、例えば、異なる帯域幅限界または待ち時間要件が同じトラフィック・カテゴリーについて設定されてもよく、或いは、トラフィック単位分類手順の少なくとも幾つかのステップが異なってもよい。少なくとも幾つかの実施では、スイッチ、ルーター、ゲートウェイ、または、ロード・バランサ等の様々なネットワーク装置について、または、ネットワーク接続ストレージ装置について確定されるネットワーク構成パラメータは、装置と関連付けられるまたは影響を及ぼされる一組のホストの帯域幅管理パラメータから少なくとも部分的に導出され、例えば、特定のスイッチが八個のホストへの入来/出発トラフィックに使用される場合、トラフィックのあるカテゴリーに対するスイッチの帯域幅限界は八個のホストの帯域幅限界から導出され得る。
【0011】
所与のノードに対してNCSによって定められるトラフィック・カテゴリーは、異なる実施形態において様々な特性について互いと異なってもよい。一実施形態では、異なるセットのネットワーク・エンドポイントについて異なるカテゴリーが作成されてもよく、例えば、トラフィックの宛先(またはソース)のIP(インターネット・プロトコル)アドレスがトラフィックをカテゴリー化するために使用されてもよい。別の実施形態では、トラフィックが流れる原因となるアプリケーションの種類がトラフィックのカテゴリー化のために使用されてもよく、例えば、データベース関連のトラフィックが一つのカテゴリーに配置され、高性能計算に関連するトラフィックが別のカテゴリーに配置されてもよい。幾つかの実施形態では、トラフィックが生成される原因となるクライアント、および/または、クライアントの予算或いはクライアントが到達した契約上の合意の面がトラフィック・カテゴリーを定めるために使用されてもよい。複数のネットワーク・アクセス可能サービスが分散システムで実施される幾つかの実施形態では、トラフィック・カテゴリーはサービスに基づいて定められてもよく、該サービスによりトラフィックの特定の単位が生成される。サービスベースの分類が使用され、所与のパケットが二つ以上のサービスと関連付けられる場合、例えば、データのパケットがデータベース・サービスのデータベース・インスタンスの代わりにストレージ・サービスから転送される場合、パケットは様々な実施形態においてソース・サービス(即ち、送信側)または宛先サービス(受信側)に属するとして分類されてもよい。少なくとも一つの実施形態では、クライアントは、トラフ
ィック単位を分類するようネットワーク構成サービスによって使用され得る一つ以上の特性の表示を提供してもよく、例えば、クライアントは、幾つかのセットの計算インスタンスが少なくとも一時的に最優先インスタンスと識別されるようリクエストを出してもよく、これらのインスタンスへの或いはこれらのインスタンスからのトラフィックは高帯域幅限界を有する最優先トラフィックとして相応じて分類されてもよい。
【0012】
幾つかの実施形態では、NCSは所与のプロバイダ・ネットワークのノードについてトラフィック・カテゴリーをモデル化する或いは表すようツリーまたは同様の階層型データ構造を使用してもよく、このとき、それぞれの帯域幅限界および/または他のネットワーク構成オプションはツリーの各ノードに割り当てられる。少なくとも幾つかの実施では、帯域幅総和ポリシーが分類ツリーに適用されてもよい。このようなポリシーによると、ツリーにおける子ノードC1、C2、...Ckを有する所与の親ノードPがXビット/秒の帯域幅限界を有する場合、所与の時間期間中に子ノードC1、C2、...Ckと関連付けられる実際のトラフィックの総和は親の帯域幅限界を超えてはならない。Pの帯域幅限界が出発トラフィックについて1Gビット/秒に設定され、Pが二つの子ノードC1およびC2を有する実施例を考慮すると、その帯域幅限界それぞれも出発トラフィックについて1Gビット/秒に設定される。所与の1秒にわたって、C1トラフィックとして分類される0.6Gビットのトラフィックがあるインスタンスから流れると、C2に対して定められる個々の限界はより高いが、C2トラフィックとして分類されるわずか0.4Gビットのトラフィックだけが許可される。親子関係に基づく総和ポリシーは、当然のことながら、待ち時間の制約または目標、サービス品質の目標、パケット・フラグメンテーション設定、または、パケット・サイズについて少なくとも部分的に確定される設定等、NCSによって確定される幾つかのタイプのネットワーク構成オプションに対しては、様々な実施形態において、関連がない或いは有用でない。
【0013】
トラフィック・カテゴリーのセットを表すためにツリーまたはツリーのような構造を用いることに加えて、幾つかの実施形態では、NCSは第二のデータ構造を生成してトラフィック単位をカテゴリーに分類するために使用されるべき手順をモデル化してもよい。分類手順グラフとも呼ばれる第二のデータ構造は、幾つかの実施では決定ノードのシーケンスを一つ以上含んでもよく、所与のシーケンスの連続するノードそれぞれはトラフィック単位をより狭いカテゴリーに分類するために使用されるべき一つ以上の基準を示す。少なくとも一つの実施では、分類手順グラフのうちの幾つかの決定ノードは、多数のカテゴリーの選択肢の中から一つのカテゴリーを選択するために使用され得るルックアップ・テーブル(例えば、ハッシュ・テーブル)を含んでもよい。ルックアップ・テーブルのエントリーは、分類されるべきネットワーク・トラフィック単位の一つ以上の特性に基づいてインデックスを付けられてもよく、例えば、宛先またはソースIPアドレスの一部または全部がインデックス付けに使用されてもよく、或いは、別のパケットのヘッダ・フィールドの一部分またはパケットのボディのコンテンツさえもがテーブル中の特定のエントリーを調べるために使用されてもよい。少なくとも幾つかの実施形態では、ルックアップ・テーブルのエントリーは、別の分類手順グラフまたはサブグラフをもたらす。そのため、このような実施では、パケットの所与の特性が、最初に、幾つかの可能なルックアップ・テーブルのエントリーの中からのルックアップ・テーブルのエントリーの選択を生じ、続いて、選択されたルックアップ・テーブルのエントリーの処理が別のセットの決定ノード(これらノード自体が他のルックアップ・テーブルを含む)のトラバースをもたらし、最終的に、パケットのカテゴリーが識別される。様々な実施形態においてこのような手順のステップを用いて、比較的詳細な細かいカテゴリー・マッピングがネットワーク・パケットおよび/または他のトラフィック単位に対して定められ得、それにより、高度なトラフィック・シェーピングが可能となる。少なくとも幾つかの実施において、異なる分類階層および/または手順が入来するおよび出発するトラフィックに対して生成されてもよい。
【0014】
関連するネットワーク構成オプションを含むトラフィック・カテゴリーのセットと、ネットワーク・トラフィック単位をカテゴリーにマッピングするための論理を有するメタデータを生成した後、幾つかの実施形態では、NCSはメタデータが適用されるべきノードへの送信のためにメタデータのポータブル表現を生成してもよい。例えば、様々な実施では、メタデータの一つの或いは両方のコンポーネントがJSON(JavaScript(登録商標) Object Notation),XML(Extensible Markup Language),YAML(頭字語が“Yet Another Markup Language”または“YAML Ain’t Markup Language”等の幾つかの可能な拡張子を有するシリアル化フォーマット)等の業界標準プロトコルまたは言語に従って符号化されてもよい。他の実施では、独占的符号化技術またはプロトコルを使用してデータ構造のポータブル・バージョンを生成してもよい。
【0015】
ポータブル表現は、プロバイダ・ネットワークまたは分散システムのターゲット・ノード、例えば、表現を解析して手順グラフによって示される手順を実施する、ネットワーク管理モジュールのような制御/管理モジュールに送信されてもよい。受信したメタデータを用いて、その後様々なトラフィック単位がターゲット・ノードで適当なカテゴリーに分類され、様々なネットワーク送信はそれぞれのトラフィック・カテゴリーについて示される帯域幅限界または待ち時間要件等のネットワーク構成オプションに応じてスケジューリングされるおよび/または制限されるまたは遅延されてもよい。このような送信中に収集されるメトリックスはNCSにフィードバックされ、その後の時間期間にわたるメタデータの改善を可能にする。そのため、NCSと、NCSで成される決定が最終的に実施されるノードとの間でフィードバック・ループが確立されてもよく、それにより、時間をかけてネットワーク管理パラメータを動態的調整することが可能となる。このようなカスタマイズ可能なトラフィック分類および構成技術を用いることで、様々な実施形態において、中央化ネットワーク構成システムはプロバイダ・ネットワークの様々な部分におけるトラフィックを任意の所望のレベルの粒度に制御しシェーピングすることが可能となる。
【0016】
異なる実施形態において、様々なアプローチ法がターゲット・ノードへの分類メタデータの分散に使用されてもよい。例えば、一実施形態では、NCSは、NCSが割り当てられたホストおよび/またはネットワーク装置それぞれに分類メタデータを周期的に(例えば、少なくともX分に一回)「プッシュ」するよう構成されてもよい。幾つかの実施形態において、様々なタイプのトリガとなるイベント(潜在的なネットワーク侵入または攻撃の検出等)は、新しい分類メタデータの普及につながる。例えば、以下により詳細に説明するように、攻撃の影響を緩和または制限する試みとして、幾つかのセットのノードにおける帯域幅限界が低下されるか、低帯域幅限界を有する新しいカテゴリーが定められてもよい。別の実施形態では、例えば、NCSにメタデータ・リクエストを送信し、それに応答してメタデータを受信することで、プロバイダ・ネットワークの少なくとも幾つかのノードは、割り当てられたNCSからトラフィック分類メタデータを「プル」してもよい。幾つかの実施形態では、スケジュール化されたプッシュ技術、メタデータのトリガとなるイベントに基づく分散、および/または、ノードで開始されるプル技術の組み合わせが使用されてもよい。
【0017】
幾つかの実施形態では、プロバイダ・ネットワークまたは他の分散システムは、複数の地理的領域に整理されてもよく、各領域は、本願では「利用可能ゾーン」とも称される一つ以上の利用可能コンテナを含んでもよい。利用可能コンテナは、所与の利用可能コンテナにおける資源が他の利用可能コンテナにおける故障と隔離されるように操作される一つ以上の別個の場所またはデータ・センターを有してもよい。つまり、一つの利用可能コンテナにおける故障は、任意の他の利用可能コンテナにおける故障と時間的に或いは因果的に相互に関係することが予想されないため、資源インスタンスまたは制御サーバーの利用可能プロフィールは異なる利用可能コンテナにおける資源インスタンスまたは制御サーバ
ーの利用可能プロフィールと独立していることが意図される。クライアントは、それぞれの利用可能コンテナにおいて多数のアプリケーション・インスタンスを立ち上げることで単一の場所で故障からそれぞれのアプリケーションを保護することができる。同時に、幾つかの実施では、同じ地理的領域内にある資源インスタンス間に安価で低待ち時間のネットワーク接続が提供される(同じ利用可能コンテナの資源間のネットワーク送信はより速くなる)。ネットワーク構成システムについて所望のレベルの利用可能性および/または性能を実現するために、幾つかの実施形態では、少なくとも一つのネットワーク構成サーバーが各利用可能ゾーンでセットアップされてもよい。幾つかの実施形態では、少なくとも一つのNCSが各データ・センター内に確立されてもよい。幾つかの実施形態では、所与の領域、利用可能コンテナ、または、データ・センター内にセットアップされるべきNCSの数は、性能要件に少なくとも部分的に基づいて確定されてもよく、例えば、変更された帯域幅限界を生成し、変更された限界を適当なセットのノードで適用することで、ネットワーク構成システムがどれだけ早くネットワーク攻撃または他のトリガとなるイベントに反応することができるかに基づいて確定されてもよい。
【0018】
一実施形態によると、一つ以上のプログラマチック・インターフェイス(例えば、API(アプリケーション・プログラミング・インターフェイス)、ウェブページ、コマンド・ライン・ツール、グラフィカル・ユーザ・インターフェイス等)は、プロバイダ・ネットワークのクライアントおよび/または他のサービスによる使用のためにネットワーク構成システムによって実施されてもよい。このような実施形態の一つでは、前述の通り、様々なサービスのクライアントまたは管理者は、特定のサービス・インスタンスまたはホストについてネットワーク構成オプションを設定または変更するよう帯域幅無効リクエスト等の構成リクエストを要請してもよい。幾つかのクライアントは、例えば、少なくとも幾らかの時間間隔にわたって少なくとも幾つかのアプリケーションについて帯域幅限界を増加(または低減)させることを望む場合がある。幾つかの実施形態では、多数のサービス・インスタンス(数百または数千の計算インスタンス、ストレージ・インスタンス、データベース・インスタンス等)が所与のクライアントに割り付けられ、クライアントがそのサービス・インスタンスのサブセットのネットワーク・ステータス(適用可能な帯域幅限界、待ち時間設定等を含む)の最新の統合ビューを得ることを望む場合がある。幾つかの実施形態では、例えば、プロバイダ・ネットワークのコンソール・サービスによって、或いは、幾つかの他の統合ネットワーク・ビュー生成部によって統一されたビューを提供するために、ネットワーク構成サービスのプログラマチック・インターフェイスが使用されてもよい。プログラマチック・インターフェイスは、幾つかの実施形態では、新しいサービス・インスタンスが立ち上げられるインスタンス・ホストを識別する責任を担うインスタンス配置サービス等の他のサービスによって使用されてもよい。特定のインスタンス・ホストを新しいサービス・インスタンスに対する候補として考えた場合、配置サービスは、候補における最近の帯域幅使用傾向、ネットワーク送信が最近制限された数、および/または、当該インスタンス・ホストに対する現在確立されているネットワーク帯域幅限界または待ち時間設定等、プログラマチック・インターフェイス上で用いるネットワーク構成サービスから情報を取得し、この情報を用いて新しいサービス・インスタンスの配置を確定してもよい。
模範的なシステム環境
【0019】
図1は、少なくとも幾つかの実施形態による、中央化ネットワーク構成サービスが分散コンピューティング環境の複数のノードにおいてネットワーク・トラフィックを管理するよう実施されるシステム100の実施例を例示する。図示するように、NCS180AやNCS180Bのようなネットワーク構成サーバー180のプール182が確立されてもよい。幾つかの実施形態において、
図2に例示し、以下に説明するように、NCS180は、コンピューティング環境の様々なデータ・センターの間で分散されてもよい。所与のNCS180は、例えば、異なる実施形態において一つ以上のソフトウェアおよび/また
はハードウェア・モジュールを有し、幾つかのケースでは自身が複数のコンピューティング装置を用いて実施されてもよい。NCS180は、幾つかの異なるタイプのソースから入力を受信するよう構成され得る。分散コンピューティング環境の様々な要素において適用されるべき帯域幅限界等のカスタマイズ可能なトラフィック分類論理やネットワーク構成オプションは、図示する実施形態において、入力に基づいておよび/またはグローバル・ネットワーク管理ポリシー122を考慮してNCSによって確定されてもよい。ネットワーク構成サービスの視点からすると、分散コンピューティング環境の要素は、測定関連コンポーネント107、決定コンポーネント108、および、実施コンポーネント109といった三つの高レベルなカテゴリーに分類されてもよい。測定関連コンポーネント107はNCSに対する様々な入力ソースを有し、決定コンポーネント108はNCS自体を有し、実施コンポーネント109はネットワーク・トラフィックをシェーピングするために決定が実行される、または、決定コンポーネントによって生成された出力が他の目的のために利用されるエンティティを表す。古典的な制御システム・フィードバック・ループのようなフィードバック・ループは、実施コンポーネント(例えば、サービス・インスタンス・ホスト144および/またはネットワーク装置145)の幾つかから測定結果を得て、これらのメトリックスを用いてNCS180による後続の決定を確定することで確立されてもよく、NCSは実施されると将来的な決定に影響を与える追加的な測定につながる。
【0020】
幾つかのタイプのネットワーク関連のメトリックスは、例えば、メトリックス・コレクタ125によってインスタンス・ホスト144および/またはネットワーク装置145から集められ、図示する実施形態において、NCS180によってアクセス可能なメトリックス・データベース190に配置されてもよい。例えば、このようなメトリックスは、時間間隔(例えば、バイトまたはパケットで表現される)中の所与のホストにおける入来する/出発するネットワーク・トラフィック率、TCP(通信制御プロトコル)またはUDP(ユーザ・データグラム・プロトコル)のような様々なプロトコルに対応するネットワーク接続の数、時間間隔中にドロップされたパケットの数やパケットがドロップされた原因、現在の帯域幅限界の実施により送信が遅延されたパケットの数、パケットのサイズの分散、所与のノードに或いは所与のノードからトラフィックを生じさせたアプリケーション、トラフィックを開始させたクライアント、パケット・デリバリーと関連付けられる待ち時間、および/または、様々な送信に伴われるエンドポントのIPアドレスを含んでもよい。データベース190に記憶されるメトリックスに加えて、NCSは、セキュリティ・サービス111またはトラフィック・メトリック集合部112のようなシステム100の追加的な入力データ・ソース110から入力を受信してもよい。セキュリティ・サービス111は、ネットワーク侵入または攻撃(その幾つかはシステム100の外部で生ずる、例えば、公衆インターネットの様々な場所から生じ、他は幾つかのインスタンス・ホスト144自体で生ずる)を検出するよう、システム100の様々な部分でトラフィック・パターンを監視するよう構成されてもよい。不審なトラフィック・パターンが検出された場合、例えば、所与のネットワーク・アドレスに方向付けられた高トラフィックの急激且つ持続したバーストがあると、セキュリティ・サービス111はNCS180に通知する。これは緩和作用を伴い得る。例えば、NCS180は、新しいネットワーク・カテゴリーおよび適用されるべき対応する帯域幅限界を生成する、または、既存のカテゴリーの帯域幅限界を変更し、新しく変更されたまたは生成された分類メタデータを適当なホストに送信して潜在的なセキュリティ・イベントの影響を制限してもよい。トラフィック・メトリック集合部112は、コレクタ125から送信されるメトリックスをバケット、例えば、IPアドレス毎のバケットまたはクライアント毎のバケットに組み合わせてもよく、バケットの表現はネットワーク構成の決定を行う際に考慮されるようNCSに利用され得る。
【0021】
図1に示す実施形態では、クライアント無効リクエスト130および/または管理者無
効リクエスト131もNCS180による決定において役割を担う。例えば、NCS180は、グローバル・ポリシー122および他のメトリックスに基づき、インスタンス・ホスト144におけるトラフィックの所与のカテゴリーC1に対する帯域幅限界が考慮される次の時間間隔について2Gビット/秒に設定されるべきと確定し得る。しかしながら、計算インスタンスがたまたま当該インスタンス・ホストにおいてインスタンス化されるクライアントは、当該計算インスタンスに対して5Gビット/秒の帯域幅をリクエストする、または、当該インスタンス・ホストにおいて実施されるサービスの管理者は1Gビット/秒に帯域幅を制限するようリクエストする。このようなリクエストは、図示する実施形態において他の要因を無効にするためにNCSによって使用されてもよい。クライアントが、発生したトラフィックの量に比例してネットワーク・トラフィックに対する金額が請求される実施形態では、幾つかのクライアントはコストを制御するために帯域幅使用に上限を課すことを望む場合がある。このような上限も無効リクエスト130の実施例を表し得る。
【0022】
幾つかの実施形態によると、所与のNCS180は、NCSが割り当てられた一つ以上のインスタンス・ホスト144および/またはネットワーク装置145に対してトラフィック分類メタデータを生成してもよい。少なくとも幾つかの実施形態では、分類メタデータはネットワーク接続ストレージ(NAS)装置等のストレージ装置に対しても生成され得る。メタデータは、例えば、ツリー・データ構造として表されてもよい一つ以上のレベルのトラフィック・カテゴリーの階層を有してもよく、このとき、ツリーの各ノードはそれぞれのトラフィック・カテゴリーを表し、ネットワーク構成オプションまたは設定(例えば、帯域幅限界または待ち時間要件)の関連するセットを有する。幾つかの実施形態では、トラフィック総和ポリシーは、
図5を参照して以下に説明するように、分類ツリーに適用されてもよい。
図5によると、親ノードの子ノードとして表されるトラフィック・カテゴリーに対する実際のトラフィック率は親ノードの帯域幅限界を超えてはならない。それぞれの分類ツリーが各インスタンス・ホスト144に対して生成される幾つかの実施形態によると、
図6を参照して以下に説明するように、ホスト・レベルの分類ツリーは、NCS180によってラックレベルのツリーまたはデータ・センター・レベルの分類ツリーにさえも合わされ得る。このような高レベルのツリーは、例えば、ネットワーク・トラフィックの流れに対するより広い視点を得る、および/または、インスタンス・ホスト毎またはネットワーク装置毎に行われるよりも高レベルの決定を行うために使用されてもよい。
【0023】
分類ツリーに加え、トラフィック分類メタデータは、図示する実施形態においてパケット等のネットワーク・トラフィック単位を分類ツリーに定められる様々なカテゴリーにマッピングするために使用されるべき手順も含み得る。手順のステップは、例えば、手順グラフの決定ノードとして表されてもよい。所与の手順グラフは、幾つかの実施において一つ以上の決定ノードのシーケンスを有してもよく、このとき、連続するノードは、ネットワーク・トラフィック単位を連続して狭くなるトラフィック・カテゴリーに一致させるために使用されるべき基準の表示を含む。少なくとも一つの実施において、幾つかの決定ノードはハッシュ・テーブルのようなルックアップ・テーブルを含んでもよい。このようなルックアップ・テーブル・ノードを用いると、所与のパケットまたはトラフィック単位が単一のグラフ・ノードを用いて多数の異なるカテゴリーのうちの一つにマッピングされ、それにより、手順グラフのサイズや複雑性が減少される。幾つかのケースでは、ルックアップ・テーブル・ノードのエントリーは他の手順グラフまたはサブグラフへのポインタとして機能してもよく、それにより、非常に細かい分類論理または基準の使用が可能になる。手順グラフやルックアップ・テーブルを組み込む決定ノードの実施例は
図6および
図7に示され、以下により詳細に説明される。少なくとも幾つかの実施形態では、分類メタデータは、適当なインスタンス・ホスト144および/またはネットワーク装置145に分散されることに加えて、分類データベース192に記憶されてもよい。
【0024】
幾つかの実施形態によると、NCS180において生成されるメタデータは、分散システム127を介してその意図する宛先に送信されてもよい。分散システム127は、それ自体、ルーティング情報および/またはアクセス制御リスト等、他のタイプのメタデータをシステム100の様々なノードに分散するために使用され得る複数の中間ノードを幾つかの実施において有してもよい。データベース192が生成されたメタデータの保存場所として使用される実施形態では、分散システム127のノードは、例えば、データベース192が更新された場合に(例えば、通知メカニズムに申し込むことで)通知されてもよく、また、相応じて新しいメタデータを適当な宛先に転送してもよい。幾つかの実施形態では、メタデータのポータブル表現(例えば、分類ツリーおよび手順)は、JSON、XML、YAML、または、独自の技術または言語等のプロトコルを用いて、NCS自体によって、或いは、分散システム127によって生成されてもよい。一つの実施では、ポータブル表現がデータベース192に記憶されてもよい。
図3に例示され以下に更に詳細に説明されるように、宛先では、受信したメタデータの表現が、例えば、インスタンス・ホスト144の場合には仮想化管理ソフトウェア・スタックのネットワーク管理モジュールによって解析されてもよい。
【0025】
一実施形態では、実施サブシステム109の他の出力宛先150からNCS180に向けられたリクエストを扱うために一つ以上のAPIサーバー170がセットアップされ得る。例えば、一つ以上のサーバーは、分散環境の選択された部分のネットワーク・ステータスの統一ビューをクライアントに提供するために、統合ネットワーク・ビュー生成部152として構成されてもよい。ある一つの実施では、例えば、クライアントは、様々なインスタンス・ホストにおいて数百または数千のサービス・インスタンスが割り当てられ、ビュー生成部152によって実施されるコンソールを介してそれぞれのインスタンスに対する様々なタイプのメトリックス(例えば、最近の入来/出発トラフィック率、ドロップされたパケット率、適用可能な帯域幅限界等)を見ることができる。少なくとも一つの実施形態では、配置サービス151もAPIサーバー170を介してNCSからのネットワーク帯域幅限界および他のメトリックスにアクセスすることができ、これは、立ち上げられるべき新しいサービス・インスタンスに使用されるインスタンス・ホストに関して決定を行う際、或いは、既存のサービス・インスタンスを帯域幅の競合がより少ないインスタンス・ホストに移動する際に有用となる。
【0026】
図2は、少なくとも幾つかの実施形態による、それぞれのネットワーク構成サーバーが幾つかの利用可能コンテナそれぞれに確立されるプロバイダ・ネットワーク環境の実施例を例示する。図示するように、プロバイダ・ネットワーク202は、図示する実施形態において幾つかの利用可能コンテナ203、例えば、203A、203B、および、203Cを有してもよい。各利用可能コンテナは一つ以上のデータ・センター205を有してもよく、例えば、利用可能コンテナ203Aにはデータ・センター205Aおよび205Bが設けられ、利用可能コンテナ203Bにはデータ・センター205Cが設けられ、利用可能コンテナ203Cにはデータ・センター205Dが設けられる。前述の通り、各利用可能コンテナ203は、任意の所与の利用可能コンテナにおける様々なタイプの故障イベントの影響が当該利用可能コンテナに典型的には制限されるよう(例えば、電力源等のそれぞれ独立したインフラストラクチャ素子を有して、且つ、異なる利用可能コンテナ間の幾らかの地理的距離を有して)設計され操作され得る。そのため、故障および/またはエラーは、利用可能コンテナの境界を越えて典型的には広がらず、異なる利用可能コンテナは独立した故障プロフィールまたは独立した利用可能プロフィールを有すると考えられる。例えば、所与の利用可能コンテナが自然災害を受けた場合でも、他の利用可能コンテナは動作可能なままであると予期される。
【0027】
利用可能コンテナ間依存性を回避或いは低減するといった設計の目標を実現すべく、図
示する実施形態において少なくとも一つのNCS180が各利用可能コンテナ203に確立されてもよい。例えば、NCS180Aおよび180Bは利用可能コンテナ203Aのデータ・センター205Aおよび205Bにそれぞれセットアップされ、NCS180Cは利用可能コンテナ203Bのデータ・センター205Cに確立され、NCS180Dは利用可能コンテナ203Cのデータ・センター205Dに位置される。NCS180Aは、データ・センター205Aにおいて実施されている一つ以上のネットワーク・アクセス可能サービス(例えば、仮想化されたコンピューティング・サービスまたはストレージ・サービス)のインスタンス・ホスト144A、および、データ・センター205Aに位置するネットワーク装置145Aに対して分類メタデータを生成するよう構成されてもよい。同様にして、NCS180Bには、インスタンス・ホスト144Bおよびネットワーク装置145Bに対して分類メタデータを生成するタスクが割り当てられ、NCS180Cはインスタンス・ホスト144Cおよびネットワーク装置145Cに対して分類メタデータを生成する責任を担い、NCS180Dはインスタンス・ホスト144Dおよびネットワーク装置145Dに対して分類メタデータを生成するよう構成されてもよい。
図2に示す実施形態では、単一のNCSが各データ・センター205に示されているが、少なくとも幾つかの実施形態では、複数のNCSが(例えば、性能要件および/またはデータ・センターにおいてメタデータが生成されるべきノードの数に依存して)所与のデータ・センター205にセットアップされてもよい。一実施形態では、利用可能コンテナ(例えば、203A)がN個のデータ・センターを有し、帯域幅管理に対する性能要件がN個未満のNCSで満たされる場合、幾つかのデータ・センターはどの構成されたNCSも有する必要がなく、代わりに、単一のNCSが二つ以上のデータ・センターに十分となり得る。他の実施形態では、所与のNCS180は、二つ以上の利用可能コンテナにおいてノードに対するメタデータを生成するよう構成され得る。
【0028】
NCS180の数および配置は、図示する実施形態においてネットワーク構成サービス・マネージャ222によって確定されてもよい。NCSマネージャ222自体は、幾つかの実施において複数のハードウェアおよび/またはソフトウェア・コンポーネントを有し、その幾つかは様々な利用可能ゾーン203のデータ・センター205にわたって分散されてもよい。NCS180に対する構成の変化は、図示する実施形態において、必要に応じてNCSマネージャによって開始されてもよく、例えば、NCSによって使用されるソフトウェア・モジュールの新バージョンが展開されるべき場合、その展開がNCSマネージャによって調整されてもよい。
【0029】
プロバイダ・ネットワークの幾つかの他のサービスは、図示する実施形態において、ネットワーク構成システムと相互に作用してもよい。例えば、統一コンソール・サービス278が一つ以上のプログラマチック・インターフェイス240(例えば、ウェブページ、API、GUI、および/または、コマンド・ライン・ツール)を実施することで、クライアント265は関心のある資源のネットワーク・ステータスに関するクエリーを出すか、リクエストした情報をプログラムで受信することが可能となる。統一コンソール・サービス278は、
図1の統合ネットワーク・ビュー生成部152の一実施例を表してもよい。プログラマチック・インターフェイス240は、クライアントが構成リクエストを要請する、例えば、特定された時間期間にわたって様々なサービス・インスタンスまたはインスタンス・ホストに対する現在適用可能な帯域幅限界を上げるか下げることを可能にする。
【0030】
装置健康管理サービス276は、幾つかの実施形態において、様々なインスタンス・ホストおよびネットワーク装置から応答情報を(例えば、心拍メカニズムを用いて)収集するよう、プロバイダ・ネットワーク202で実施される。図示する実施形態では、健康管理サービス276は、例えば、健康ステータス・メッセージにネットワーク・メトリックスをピギーバックさせることで、NCS180によって入力として使用されるべきネット
ワーク関連のメトリックスの収集に使用されてもよい。そのため、健康管理サービス276のノードは、
図1に示すメトリックス・コレクタ125の実施例として考えられてもよい。健康管理サービスは、幾つかの実施形態においてメタデータ分散システム127として使用されてもよく、例えば、様々なインスタンス・ホストに送られる心拍メッセージはピギーバックされた分類メタデータを含んでもよい。DDOS検出サービス274は、例えば、所与のセットのIPアドレスへの或いは所与のセットのIPアドレスからの異常に重いトラフィック・パターンを検出することで、プロバイダ・ネットワーク内のターゲットにおけるサービス攻撃の拒絶および/または外部ターゲットにおけるプロバイダ・ネットワーク202内から開始され得たサービス攻撃の拒絶を検出するよう構成されてもよい。潜在的なDOS攻撃が識別されると、DDOS検出サービス274は、潜在的なネットワーク攻撃または侵入に関して適当なNCS180に入力を供給してもよく、これにより、NCS180は、潜在的な攻撃の影響を緩和させるよう幾つかのインスタンス・ホストまたはネットワーク装置について少なくとも一時的に帯域幅限界を狭めるか他のネットワーク構成オプションを変える。インスタンス配置サービス272は、NCS180から最近の利用可能なネットワーク関連メトリックスおよび構成設定を取得して、新しいインスタンスを立ち上げるに利用可能な十分な余分帯域幅を有するインスタンス・ホストを選択する、または、ネットワーク・トラフィック状態を変えることを考慮して既存のインスタンスを移動すべきインスタンス・ホストを選択する。
インスタンス・ホストにおける分類メタデータの使用
【0031】
前述の通り、異なる実施形態において、ネットワーク構成サーバーは、様々なネットワーク・アクセス可能サービスのインスタンス・ホストにトラフィック分類メタデータの表現を送信してもよい。
図3は、少なくとも幾つかの実施形態による、仮想化されたコンピューティング・サービスのインスタンス・ホスト144においてトラフィック分類メタデータを解釈することができるネットワーク・マネージャ・モジュールの実施例を例示する。インスタンス・ホスト144は、幾つかの異なるクライアント・アクセス可能バーチャル・マシンまたは計算インスタンス350、例えば、計算インスタンス350Aおよび350Bをインスタンス化し管理することができる仮想化管理ソフトウェア・スタック(VMSS)310を含んでもよい。VMSS310は、例えば、ハイパーバイザー317、および、幾つかの実施において「ドメインゼロ」または「ドム0」と呼ばれるオペレーティング・システム315の管理インスタンスを有してもよい。ドム0オペレーティング・システムは、計算インスタンス350を実行しているクライアントによってアクセスすることができないが、計算インスタンス350への或いは計算インスタンス350からのネットワーク・トラフィックを扱うことを含む、仮想化されたオペレーティング・システムの様々な管理または制御面の動作に対して責任を担う。
【0032】
図示する実施形態では、ドム0オペレーティング・システム315は、ネットワーク・マネージャ・コンポーネント357を含む様々な制御モジュールを含み、ネットワーク・マネージャ・コンポーネント357は分類メタデータ解釈部359を有する。ネットワーク・マネージャ・コンポーネントは、例えば、上述の分類ツリーおよび/または分類手順の表示を含む、インスタンス・ホスト144についてNCS180によって生成された分類メタデータを受信してもよい。解釈部359は、メタデータを解析し、様々な計算インスタンス350に或いは計算インスタンス350から方向付けられるトラフィックのパケットにメタデータに示される手順を適用し得る。例えば、様々なトラフィック・カテゴリーに対して帯域幅限界を実施するために、一つ以上のインスタンス・パケット・キュー(IPQ)319(例えば、IPQ319Aおよび319B)が構成されてもよい。特定のインスタンス350における特定のカテゴリーの入来または出発トラフィック率が所与の時間間隔中に当該カテゴリーに対する帯域幅限界を超えると、入来または出発パケットの幾つかは当該特定のインスタンスに対するIPQ319の待ち行列に入れられてもよい。幾つかの実施では、二つ以上のパケット・キューが所与の計算インスタンスに対してイン
スタンス化されてもよく、例えば、一つのトラフィック・カテゴリー当たり一つのパケット・キューがセットアップされてもよい。他の実施では、多数のインスタンス350と関連付けられるパケットを待ち行列に入れるには単一のパケット・キューで十分である。IPQまたは他の同様の構成は、様々な実施形態において、待ち時間要件、他のサービス品質の目標(例えば、異なるトラフィック・カテゴリーに対するネットワーク送信の相対的優先順位)、パケット・フラグメンテーション設定、または、パケット・サイズに依存する設定等の他のネットワーク構成オプションをNCSから受信したメタデータに応じて実施するために使用されてもよい。
【0033】
図示するように、各計算インスタンス350は、図示する実施形態において対応するクライアント・アクセス可能オペレーティング・システム370、例えば、計算インスタンス350AのOS370Aや計算インスタンス350BのOS370Bを有してもよい。オペレーティング・システム370は、入来および出発トラフィックに対してインスタンス・ホスト144のハードウェア・ネットワーク・インターフェイスを使用するようネットワーク・マネージャ357と通信し得る、独自のネットワーク・スタック372(例えば、インスタンス350Aのネットワーク・スタック372Aおよびインスタンス350Bのネットワーク・スタック372B)をそれぞれ有してもよい。計算インスタンス350を実施するクライアントの視点からすると、各インスタンスは完全に機能的なサーバーに見え、クライアントは使用されているネットワーク構成技術の実施の詳細(例えば、IPQでパケットを待ち行列に入れる)を知らない場合もある。
図3に示すのと同様の分類メタデータを解釈し使用する技術が、異なる実施形態において、様々なタイプのストレージ・サービスまたはデータベース・サービス等、他のタイプのネットワーク・アクセス可能な仮想化サービスのインスタンス・ホストにも使用されてもよいことに注意する。更に、幾つかの実施形態において、分類メタデータがVMSS310のネットワーク・マネージャ357の代わりに、或いは、それに加えて、インスタンス350のネットワーク・スタック372で少なくとも部分的に解釈および/または使用されてもよいことに注意する。
メタデータ送信モード
【0034】
NCS180によって生成されたメタデータの表現は、異なる実施形態における異なるプロトコルまたは転送モードに応じて、インスタンス・ホスト144またはネットワーク装置145等のターゲットに供給されてもよい。
図4a~
図4cは、少なくとも幾つかの実施形態による、インスタンス・ホストにトラフィック分類メタデータを送信するために使用され得るプロトコルの実施例をそれぞれ示す。一つ以上のプログラマチック・インターフェイスは、異なる実施形態においてインスタンス・ホストまたは分散システムの他のノードにメタデータを供給するために使用されてもよく、このときNCSまたはメタデータの受信部のいずれかは、使用されるプロトコルに応じてインターフェイスを呼び出す。
【0035】
図4aに示す実施形態では、分類メタデータは、NCS180によって開始されたスケジューリングされた「プッシュ」動作401を介してインスタンス・ホスト144に(または、ネットワーク装置145またはストレージ装置に)送られてもよい。例えば、各NCSはそれぞれスケジュールを有して構成されてもよく、NCSは該スケジュールに応じて所与のメタデータ・ターゲットに(例えば、一分間に一回、または、五分間に一回)メタデータを送る。幾つかの実施において所与のNCSから異なるターゲットにメタデータが送られる実時間は、メタデータ転送自体によって生ずるネットワークの混雑を回避するようずらされる。例えば、メタデータが所与のNCSから六つのインスタンス・ホストに一分間に一回プッシュされるべき場合、各インスタンス・ホストへのメタデータ送信は十秒間隔でスケジューリングされ得る。
【0036】
図4bに示す実施形態では、トリガとなるイベントはメタデータの送信につながり得る
。例えば、イベント検出部421が潜在的なDDOS検出等のイベントが検出されたことをNCSに通知し、NCSがイベントの影響を緩和するよう適当なメタデータを生成してもよい。あるタイプのイベントについては、イベントになるべく早く対応するよう、幾つかの実施形態では、メタデータが生成されるとすぐに、生成されたメタデータのトリガされたプッシュ402が高い優先順位で開始されてもよい。他のタイプのトリガとなるイベントに対して、例えば、管理者が先に生成されたメタデータを無効にするリクエストを出した場合、メタデータはすぐに或いは高い優先順位でプッシュされる必要がない。
【0037】
図4cに示す実施形態では、インスタンス・ホスト144は、最近の分類メタデータについてBA180にプル・リクエスト403を出し、メタデータは相応じて応答404でインスタンス・ホストに送られてもよい。様々な実施形態では、
図4a乃至
図4cに示す三つのアプローチ法のいずれかの組み合わせが、インスタンス・ホスト144に対して、ネットワーク装置145に対して、または、ストレージ装置に対して使用されてもよい。少なくとも一実施形態では、メタデータを送信する際に差分アプローチが使用されてもよく、つまり、現在のメタデータと最近供給されたメタデータとの間の差だけの表現がインスタンス・ホスト、ネットワーク装置、または、ストレージ装置に送られてもよい。他の実施形態では、メタデータ全体が各転送において送信されてもよい。
分類ツリー
【0038】
図5は、少なくとも幾つかの実施形態による、分散システムの装置においてネットワーク構成に対するネットワーク・トラフィック・カテゴリーを表すために使用され得る分類ツリー・データ構造501の実施例を例示する。ツリー501の各ノードは、ノードによって表されるカテゴリーについて、
図5における各ノードに対して例示されるそれぞれの帯域幅限界等のネットワーク構成オプションまたは設定の関連するセットを有してもよい。各ノードに適用され得るネットワーク構成オプションの他の実施例は、パケット待ち時間要件または目標、異なるトラフィック・カテゴリーの相対的優先順位等の他のサービス品質の目標、パケット・フラグメンテーション/再組立設定、または、パケット・サイズに依存する構成の設定を含み得る。トラフィック・カテゴリーは、異なる実施形態において様々な特性における差に基づいて定められ、例えば、トラフィックと関連付けられるアプリケーションのカテゴリー、コンポーネントが送信側または受信側にあるサービス、関連するエンドポイント(幾つかのケースでは、それ自体がアプリケーションのタイプを示す)のネットワーク・アドレス、転送のサイズ、トラフィックを生成したクライアント、互いに対するエンドポイントの場所(例えば、プロバイダ・ネットワーク・ノードからの出発パケットについては、宛先がローカル・データ・センター内、ローカル利用可能コンテナ、ローカル領域、プロバイダ・ネットワークの別の領域、またはプロバイダ・ネットワークの外部か否か)等に基づいて定められる。例示する分類ツリー501において、例えば、ノード504はアプリケーション(高性能計算)の一つのクラスに対するトラフィックを表し、ノード520はデータベース・トラフィックを表し、ノード506は高性能ブロック・ストレージ・トラフィック(即ち、高入力/出力速度を支持するよう構成されるブロック・ストレージ装置と関連付けられるトラフィック)を表す。ノード520によって表されるデータベース・カテゴリー内では、場所に基づくサブカテゴリーに対して三つのノード、即ち、データ・センター間トラフィックに対するノード522、領域間トラフィックに対するノード524、および、余剰領域トラフィックに対するノード526が定められる。
【0039】
様々なカテゴリーに対して定められるネットワーク構成オプションが帯域幅限界を含む実施形態では、様々な種類のトラフィック総和ポリシーまたはルールが分類ツリーに適用され得、それにより、親ノードに対する子ノードの帯域幅限界の間の関係に影響が与えられる。例示する実施例では、以下のルールが当てはめられる:(a)ツリーにおけるどの子ノードもその親の帯域幅限界を超える帯域幅限界を有さない、および、(b)親ノード
の子ノードの帯域幅限界の総和が親の帯域幅限界を超えたとしても、子ノードによって表されるカテゴリーに対する実際のトラフィック率の総和はどの所与の時間期間中にも親の帯域幅限界を超えてはならない。
【0040】
これらのルールによると、ルート・ノード(分類グラフが生成されるインスタンス・ホストまたはネットワーク装置に対して定められた全てのトラフィック・カテゴリーを総称的に表す)がK Gビット/秒の帯域幅限界を有するため、ルート・ノードのどの子ノードもK Gビット/秒よりも大きい帯域幅限界を有さず、A<K、B<K、C<K、および、D<Kとなる。ノード520の場合、子ノード(ノード522、525、および、526)の帯域幅限界は、総和が親ノードの帯域幅限界となるよう割り当てられるため、上述の両方のルールが満たされる。D Gビット/秒の帯域幅限界を有する包括的な「他の」トラフィック・カテゴリーを表すノード530の場合、子ノード532(他のブロック・ストレージ・トラフィック)、534(インターネット・トラフィック)、536(イントラサービス・トラフィック)、および、538(どの他のリーフ・ノードによっても表されない雑または未分類トラフィック)それぞれもD Gビット/秒の帯域幅限界を有する。子ノードに対する公称帯域幅限界の総和が(この場合4D Gビット/秒)が親ノード(D Gビット/秒)の帯域幅限界を超えるこのようなシナリオは、上述の第二のルールに応じて以下のように解釈され得る。原則としては、子ノードのカテゴリーそれぞれがD Gビット/秒までのトラフィック率を有することができるが、実際には、どの所与の一秒(または他の適当な時間単位)中にも、全ての子ノードの実際のトラフィック・フローの総和はD Gビット/秒を超えてはならない。そのため、特定の一秒中「他のブロック・ストレージ・トラフィック」(ノード532)といったカテゴリーに対するトラフィック率が0.6D Gビット/秒の場合、ノード534、536、および、538に対するトラフィック率は合わせて0.4Dを超えてはならない。
【0041】
幾つかの実施形態では、それぞれのツリーは所与のインスタンス・ホストまたはネットワーク装置において入来および出発トラフィックに対してNCS180によって生成されてもよく、ネットワーク構成オプションおよび/またはカテゴリーにおいて入来トラフィックに対するツリーは出発トラフィックに対するツリーと異なってもよい。幾つかの実施形態では、分類ツリーの幾つかの或いは全てのノードに関して、持続的帯域幅(例えば、T秒を超える時間期間にわたって平均的帯域幅使用に適用される)、および、バースト帯域幅(例えば、所与のインスタンス・ホストに対して持続的帯域幅限界が1Gビット/秒に設定されているが4Gビット/秒の短期間バースト・トラフィック率が当該インスタンス・ホストに対して二秒まで許される)に対して異なる限界が定められてもよい。前述の通り、幾つかの実施では、所与のインスタンス・ホスト、ネットワーク装置、またはストレージ装置に対するトラフィック分類階層は、多数の層を有する代わりに平坦でもよい。
【0042】
幾つかのシナリオでは、分散システムの異なるエンティティの分類ツリーを高次ツリーに組み合わせることが管理的視点から有用となり得る。
図6は、少なくとも幾つかの実施形態による、データ・センターにおいて複数のインスタンス・ホストのネットワーク・トラフィック・カテゴリー情報を組み合わすために使用され得る階層型データ構造601の実施例を例示する。図示するように、Cツリー601A、601B、601M、および、601N等、それぞれの分類ツリー(Cツリー)が多数のインスタンス・ホストに対してデータ・センターにおいて生成され得る。データ・センターは、図示する実施形態において幾つかの異なるルームに配置される複数のサーバー・ラックを有する。NCSは、所与のラックに組み込まれるインスタンス・ホストのCツリーを統合して603Aおよび603B等のラックレベルのCツリーを形成する。統合の次のレベルでは、データ・センターの所与のルームまたはサブセットにおける全てのラックに対するラックレベルCツリー603が例えば、ルームレベルCツリー605Aまたは605Bの形態で組み合わされてもよい。幾つかの実施形態では、ルームレベルのツリーを組み合わせることで、全体として
単一の合成ツリー607がデータ・センターに対して形成されてもよい。全体として利用可能コンテナ、地理的領域、または、プロバイダ・ネットワークのレベルにおける等、より高レベルのツリー階層が幾つかの実施形態で構成され得る。
【0043】
このような合成ツリー階層は、幾つかの方法で、特に、階層のカスマタイズ可能な視覚表示がプログラムで(例えば、統一コンソール・サービスを介して)利用可能にされた実施においてネットワーク構成システムやプロバイダ・ネットワークの管理者を補助する。データ・センターまたはプロバイダ・ネットワークの異なる部分における帯域幅使用の均一性または不均一性の概要は、このような階層を用いて得られ、これは、構成または配置の変化につながってネットワーク利用レベルを改善するまたはバランスを取る。トラフィックの異なるカテゴリー間の利用可能な帯域幅の分散もより高レベルの階層を検査することでより明確になり、これは、プロバイダ・ネットワークの収益の改善を補助する価格変化を行う際に助けとなる(例えば、より普及しているカテゴリーに関連するトラフィックの価格上昇)。配置サービスも、例えば、新しいサービス・インスタンスに対して適当なインスタンス・ホストを選択する際に助けとなるラックレベルの帯域幅使用を確定することで、高レベルのツリー階層から恩恵を受ける。
分類手順グラフ
【0044】
上述の通り、少なくとも幾つかの実施形態では、ネットワーク構成サーバーは、所与のインスタンス・ホストまたはネットワーク装置に対して定められたカテゴリーにパケット等のネットワーク・トラフィック単位を分類するために使用され得る手順のステップまたはルールを確定してもよい。
図7は、少なくとも幾つかの実施形態による、ネットワーク・トラフィックの単位のカテゴリーを確定するために分類ツリーと一緒に使用され得るトラフィック手順グラフ750の実施例を例示する。グラフ750は、複数の決定ノードを有し、各ノードにおいてネットワーク・トラフィックに対する分類基準のそれぞれのセットが示される。少なくとも幾つかの実施形態では、少なくとも決定ノードのサブセットがシーケンスに配置されてもよく、該シーケンスの連続するノードは連続して狭くなるカテゴリーに対応する。例えば、ノード701、702、および、703のシーケンスでは、ノード701に示される基準と一致するトラフィックのサブセットはノード702に示される基準と一致してもよく、ノード702に示される基準と一致するトラフィックのサブセットはノード703に示される基準と一致してもよい。ネットワーク・トラフィックの所与の単位がシーケンスの最後のノードの基準に一致しない場合、当該トラフィック単位は異なるシーケンスを用いて評価され得る。例えば、パケットがノード701および702の基準に一致する(ノード701および702に対して「はい」の結果によって示される)が、ノード703に示される基準と一致しない(ノード703に対して「いいえ」の結果によって示される)場合、パケットはノード704および705のシーケンスを用いて評価される必要がある。
【0045】
一般的に、所与のトラフィック単位がノードの所与のシーケンスの基準全てと一致する場合、そのカテゴリーが確定され得る、例えば、ノード701、702、および、703の基準が満たされる場合にはカテゴリーC1パケットとして分類され、ノード707および708の基準が満たされる場合にはカテゴリーC6パケットとして分類され、ノード706の基準が満たされる場合にはカテゴリーC5パケットとして分類され、または、ノード709の基準が満たされる場合にはカテゴリーC7パケットとして分類される。所与のノードにおいて示される基準は、異なる実施形態においてネットワーク・トラフィック単位の様々な特性に関して表されてもよい。例えば、ソースまたは宛先IPアドレス、ポート番号、または、使用されるネットワーク・プロトコル等のパケットの一つ以上のヘッダのコンテンツがそのカテゴリーを確定するために使用されてもよく、またはボディのコンテンツが使用されてもよい。所与のトラフィック単位が手順を用いて分類されるカテゴリーそれぞれは、図示する実施形態においてNCSによって生成される分類ツリーの対応す
るノードに対応してもよい。
【0046】
少なくとも原則としては、少なくとも幾つかの実施形態ではパケット分類のために任意に細かい基準が使用されてもよく、決定ノードの任意に長いシーケンスが生成されてもよい。例えば、分類基準は、パケット・ボディの非常に特定的なコンテンツ(パケットのオフセットO1で特定のバイトレンジ「0xff」が生じるか)、または、パケットまたはヘッダ・コンテンツの任意の組み合わせ等に基づいてもよい。分類手順グラフ750のサイズおよび複雑性を減少させるために、多数の可能な結果を有する決定ノードが幾つかの実施形態において使用されてもよい。例えば、手順グラフ750では、ルックアップ・テーブル770を有するノード705が含まれる。このようなルックアップ・テーブルそれぞれは、複数の行を有し、その中から所与のトラフィック単位(例えば、パケットの宛先IPアドレス)の特性に基づいて一行がインデックス付けされるまたは選択されて、分類の決定が達せられる。ノード705の実施例では、分類の決定とは、パケットがカテゴリーC2、C3、または、C4に属するか否かである。他の場合では、分類の決定は、決定ノードの追加的なシーケンスを用いてパケットを評価することであり、例えば、ルックアップ・テーブル・エントリーが他の分類グラフまたはサブグラフへのポインタとして機能してもよい。
【0047】
図8は、少なくとも幾つかの実施形態による、トラフィック分類手順グラフのルックアップ・テーブル・ノード805の使用の実施例を例示する。図示する実施形態では、パケットをカテゴリー化するために使用されるべきノード805のルックアップ・テーブル770Aのエントリーを識別するよう、ネットワーク・パケット810の一部分にハッシュ関数850が適用されてもよい。ルックアップ・テーブル805は、幾つかの場合では、それ自体が手順の他の決定ノードの評価後に到達され得、即ち、少なくとも幾らかのレベルのカテゴリー化がハッシュ関数850の適用前にパケット810に対して既に行われていてもよい。図示する実施例におけるパケットは宛先IPアドレス「P.Q.R.S」801を有するアウトバウンド・パケットであり、宛先IPアドレスの四つの要素のうちの第三の要素「R」がハッシュ関数850への入力として使用されて、パケット810に対応するルックアップ・テーブルのエントリーが確定される。例えば、宛先IPアドレスまたはソースIPアドレスの他の部分の値、他のヘッダ・フィールド802の値、または、パケットのボディ803のコンテンツさえも含む、パケット810の幾つかの特性のいずれもが、様々な実施形態においてハッシュ関数への入力として使用され得る。ルックアップ・テーブルのエントリーを選択するためにパケットのどの特性が使用されるべきかに関するルール、および、特性に適用されるべき関数(例えば、ハッシュ関数850)は、幾つかの実施形態において、インスタンス・ホストまたはネットワーク装置等のターゲット装置における制御モジュールにNCS180による分類メタデータと一緒に供給されてもよい。
【0048】
幾つかのケースでは、(例えば、宛先IPアドレス要素のハッシュ法の結果として)選択されたルックアップ・テーブルのエントリーが対応するパケットのトラフィック・カテゴリーを直接示してもよい。例えば、ルックアップ・テーブル770Aの要素のうちの一つを選択することは、
図8におけるカテゴリーAにつながる。ルックアップ・テーブルの他のエントリー自体も
図8のグラフ880Aおよび880Bのような追加的な手順グラフへのポインタとして機能し、その決定ノードはパケット810のカテゴリーを確定するためにナビゲートされなくてはならない。異なるグラフのノードから評価される基準の結果として到達される追加的な手順グラフは、本願ではサブグラフとも呼ばれる。図示する実施例では、決定ノード851、852(それ自体ルックアップ・テーブル770Bを有するノード)および/または853によって示される基準はハッシュ関数850が770Aの一つのエントリーにつながる場合には評価される必要があり、決定ノード854、855、および/または、856によって示される基準はハッシュ関数850がルックアップ
・テーブル770Aの異なるエントリーの選択を結果とする場合には評価される必要がある。手順グラフ880Bが到達され、要素854および855に示される基準が満たされると、例えば、パケット810は
図8の実施例においてトラフィック・カテゴリーLに属すると考えられる。分類手順グラフ750の様々なノードにルックアップ・テーブル770を組み込むことで、複雑で細かい論理が分類に使用されたとしてもトラフィック分類の論理の比較的コンパクトな表現が可能となる。
トリガとなるイベントへのネットワーク構成システムの応答
【0049】
幾つかの実施形態では、前述の通り、ネットワーク攻撃や侵入等の潜在的に損害を与えるイベントの検出等のイベントに応答して、帯域幅管理の決定がなされてもよい。ネットワーク構成システムを構成する際、例えば、分散システムの特定のサブセットに幾つのNCSがセットアップされるべきかを決定する際、または、どのタイプの計算能力およびメタデータ分散能力がネットワーク構成システムに必要かを決定する際に考慮され得る要素の一つがこのようなイベントへの所望の応答となり得る。
図9は、少なくとも幾つかの実施形態による、ネットワーク構成サービスの一つ以上のパラメータに対する値を確定するために利用され得る応答メトリックの実施例を例示する。
【0050】
時間値が左から右に増加する、模範的な時系列が
図9に示される。ブロック902に示されるように、時間T1において、中央化ネットワーク構成が実施される分散システムのセキュリティ・サービスがDDOS攻撃等の潜在的なネットワーク攻撃が検出される。起こり得る攻撃は、例えば、分散システムの一つ以上のノードにまたは一つ以上のノードから方向付けられるトラフィック率における急な増加に基づいて識別されてもよい。このような攻撃は、分散システム内(例えば、プロバイダ・ネットワークの計算インスタンスのセットを用いて実施されている電子ビジネスのウェブサイト)、または、分散システムの外部(例えば、繰り返されるリクエストがプロバイダ・ネットワークの計算インスタンスのセットから外部のウェブサイトに高い率で送られてもよい)の一つ以上のターゲットにおいて方向付けられてもよい。幾つかのケースでは、トラフィックの増加は、ウェブサイト上でのセール商品に対する急な関心といった正当な理由によるものの場合もあるが、多くの実施形態では、セキュリティ・サービスがこのような誤判定の確率を低減させるよう高度な分析技術を使用してもよい。
【0051】
潜在的な攻撃が本当に攻撃か否かに関わらず、ネットワーク構成システムは、図示する実施形態において、例えば、分散システムの適当なノードに対する帯域幅限界等、新しい分類メタデータおよび/または新しい構成オプションを生成し、新しいメタデータをなるべく早く適用することで、応答するよう構成され得る。ブロック904によって示されるように、図示する時系列の時間T2において、ノードのセットに対する変更されたメタデータが生成されてもよい。例えば、IPアドレスK.L.M.Nから発生されIPアドレスE.F.G.Hで方向付けられるアウトバウンドDDOS攻撃を表すトラフィックが検出されると、これらのIPアドレスに対して帯域幅限界を適用する責任を担うNCSは新しいメタデータを生成してもよい。例えば、新しいメタデータは、K.L.M.Nから発生されるまたはE.F.G.Hで受信される全てのトラフィックに対して単に新しい帯域幅限界を(少なくとも一時的に)課してもよい。代替的には、一つ以上の新しいトラフィック・カテゴリーが、具体的には、K.L.M.NからE.F.G.Hに流れるトラフィックに対して定められてもよく、これら特定のカテゴリーに対する帯域幅限界が生成され広められてもよい。
【0052】
ブロック906によって示されるように、
図9の模範的な時系列における時間T3において、変更された分類メタデータは、適当なインスタンス・ホストまたは他のノードに分散され、実施されてもよい(幾らかの時間の後、例えば、ネットワーク攻撃が終了した場合か攻撃を示したトラフィックが正当と分かった場合、分類メタデータは再び変更されて
もよい)。例えば、間隔(T3乃至T1)によって示されるように、トリガとなるイベントへのネットワーク構成サービスの応答は、例えば、ネットワーク構成サービス・マネージャ222によって時間とともに追跡され、使用されるNCSの数またはメタデータの分散システムの様々な特性を調節するために使用されてもよい。
中央化ネットワーク構成サービスを実施する方法
【0053】
図10は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実施される動作の態様を例示するフロー図である。要素1001に示されるように、サービスの様々な初期またはデフォルトのパラメータが、例えば、グローバル帯域幅管理ポリシー、ネットワーク構成が実施されるサービスの利用可能性および/または性能要件を考慮して、確定されてもよい。このようなパラメータは、例えば、各利用可能コンテナまたは各データ・センターに構成されるべきNCS180の数、メタデータ搬送スケジュールおよびプロトコル(例えば、NCSがメタデータ転送を開始するプッシュ・プロトコルがデフォルトとして使用されるべきか否か、または、インスタンス・ホストが必要に応じて分類メタデータをリクエストするプル・プロトコルが使用されるべきか)、メタデータ転送をもたらす追加的なトリガとなるイベントのタイプ、NCSへの入力ソースおよび/またはNCSの決定の結果が供給される出力の宛先を含んでもよい。
【0054】
少なくとも幾つかの実施形態では、プログラマチック・インターフェイスのセットが実施されてもよく(要素1004)、それによりクライアントおよび/または管理者はNCSの決定を選択的に無効にすることができる。例えば、一実施形態では、幾らかのクライアントは、(例えば、アプリケーション・ワークロード・レベルにおける予想増加に基づいて)NCSによって選択される帯域幅限界を超えて様々な帯域幅限界を増加させるリクエストを出す、または、(例えば、トラフィック関連の請求金額を下げるよう)NCSが確定する帯域幅限界より下となるようトラフィックのあるカテゴリーに対する帯域幅限界を制限するリクエストを出すことができる。様々な他のタイプのオプションに対するクライアントおよび/または管理者からの構成リクエストも、待ち時間関連の設定、サービス品質の設定等のためにサポートされてもよい。
【0055】
要素1001に対応する動作において確定されるパラメータに応じて、適当な数のNCS180が選択された場所でインスタンス化されてもよい(要素1007)。ネットワーク接続はNCSと分散システムまたはプロバイダ・ネットワークの様々な他の要素との間に確立されてもよく(要素1010)、例えば、NCSとNCSによる決定が実施されるインスタンス・ホスト144および他のネットワーク装置145との間、NCSとNCSの決定に影響を及ぼす入力データ・ソースとの間、および、NCSと継続的にNCSからネットワーク情報を取得することに関心のある全ての出力宛先との間で確立される。少なくとも幾つかの実施形態では、TLS(トランスポート層セキュリティ)やSSL(セキュア・ソケット層)等の安全なネットワーク・プロトコルがNCSと分散システムの少なくとも幾つかの他の要素との間のネットワーク接続のために使用されてもよい。
【0056】
図11は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのトラフィック分類メタデータを生成し分散するために実施され得る動作の態様を例示するフロー図である。図示する実施形態では、NCSは反復アプローチを用いてもよく、各反復中、入力のセットがターゲット・ノード(例えば、インスタンス・ホスト)のセットに分散され適用されるネットワーク管理パラメータを確定するために使用され、メトリックスがターゲット・ノードや他のソースから収集され次の反復に対するパラメータに影響を与えるまたはパラメータを確定するよう入力としてフィードバックされる。要素1101に示されるように、所与の時間間隔中、所与のNCSは、インスタンス・ホストおよび/またはスイッチ、ルーター、ゲートウェイ等のネットワーク装置を含む分散システムの様々なノー
ドから取得されるネットワーク関連メトリックスのセットを受信してもよい。例えば、測定された入来/出発トラフィック率、パケット損失率、パケット制限率等を含み得るこのようなメトリックスは、NCSによるトラフィック分類メタデータの次の反復を生成するために使用され得る。幾つかのケースでは、メトリックスは、例えば、健康管理サービスのノードのようなメトリックス収集システムのノードを介してNCSに供給されてもよい。更に、NCSは、図示する実施形態において、セキュリティ関連のサービス、IPアドレス毎のトラフィック集合部、クライアント毎のトラフィック集合部等を含む他の入力ソースから様々な入力を取得してもよい。クライアントおよび/または管理者は、NCSによって一つ以上のトラフィック・カテゴリーに先に適用された帯域幅限界を増加または低減させるためのリクエスト等の構成リクエストをNCSに要請してもよく、このような構成リクエストはトラフィック分類メタデータの次の反復を確定する際に入力として使用されてもよい。
【0057】
NCSにおいて、メトリックスや受信した入力は、例えば、グローバルおよび/またはローカル・ネットワーク管理ポリシーを考慮して、図示する実施形態においてトラフィック分類メタデータを確定するために使用されてもよい(要素1104)。グローバル・ポリシーは、例えば、ネットワーク・インフラストラクチャの様々な部分のターゲット利用限界、同様のレベルのサービスに登録した異なるクライアントからのトラフィックを扱うための公平要件、実施される異なるネットワーク・アクセス可能サービスに対してネットワーク・トラフィックに与えられるべき相対的優先順位等を示してもよい。ローカル・ポリシーは、例えば、ネットワーク・インフラストラクチャや能力が他の利用可能コンテナまたはデータ・センターのネットワーク・インフラストラクチャや能力と異なる、所与の利用可能コンテナまたは所与のデータ・センターで適用されるルールを示してもよい。分散システムの所与のターゲット・ノードに対して生成された分類メタデータは、ターゲット・ノードで使用されるべきトラフィック分類階層(例えば、
図5に示す構造と同様のツリー・データ構造において表される階層)、および、階層において定められるカテゴリーにネットワーク・トラフィックの単位を分類するために使用されるべき手順またはルールのセット(例えば、
図7に示すグラフと同様のグラフを用いて表すことができる手順)を含んでもよい。階層において定められる各トラフィック・カテゴリーに対して、例えば、平均的トラフィックに対して定められる帯域幅限界および短期間バーストに対して定められる異なる帯域幅限界、待ち時間要件、パケット・サイズに依存する要件、または、優先順位設定を含む帯域幅限界等の対応するネットワーク構成オプションが一つ以上確定されてもよい。幾つかのケースでは、カテゴリーおよび/またはオプションのそれぞれのセットが入来/出発トラフィックに対して定められてもよい。少なくとも幾つかの実施形態では、分類階層および/または手順は、異なるインスタンス・ホストおよび/またはネットワーク装置に対してカスタマイズされてもよく、例えば、一つのセットのクライアント・アプリケーションに対して使用される所与のホストH1は、異なるセットのクライアント・アプリケーションが実施される別のホストH2とは定められるトラフィック・カテゴリーが異なり、当該カテゴリーに課せられる帯域幅限界が異なる。
【0058】
トラフィック分類階層および分類手順のそれぞれのポータブルな表現または符号化は、図示する実施形態では、ターゲット・ノードへの送信のためにNCSにおいて生成され得る(要素1107)。JSON、XML、YAML等の業界標準プロトコルまたは言語が幾つかの実施において使用され、独自の符号化スキームが他の実施において使用されてもよい。ポータブルな表現は、メタデータが適用されるか使用されるべきターゲットに送信される(要素1110)。少なくとも一つの実施において、単一のまたは組み合わされた符号化が分類カテゴリーおよび手順の両方に対して使用され、他の実施において、分類カテゴリーおよび手順のそれぞれの別個の表現が使用されてもよい。幾つかの実施形態では、例えば、先の反復から変更されたメタデータの部分だけがターゲットに送信される差分メタデータ送信技術が使用され得る。他の実施形態では、メタデータ全体が各反復におい
て送信される完全送信アプローチ法が使用され得る。様々な実施形態では、スケジューリングされたプッシュ送信(メタデータがターゲットにNCS主導でプッシュされる)、プル送信(NCSがターゲットからのリクエストに応じて分類メタデータを送信する)、および、イベントにトリガされたメタデータ送信(あるタイプのイベントを検出すると、NCSがメタデータを生成しおよび/または送信する)の組み合わせが使用されてもよい。所与の反復に対するメタデータが適当なターゲットに送られた後、NCSは、例えば、要素1101以降に対応する動作を繰り返すことで次の反復を開始する。
【0059】
分散システムのターゲット・ノードでは、制御モジュール(例えば、
図3に示すネットワーク・マネージャ357等)はメタデータ表現を受信し解釈するよう構成され得る。メタデータは、パケット等のネットワーク・トラフィックの単位を分類し、対応する帯域幅限界を適用してトラフィック単位の送信をスケジューリングするおよび/または制限するために使用され得る(要素1113)。幾つかの実施では、ノードで既に利用可能な「tc」等のオペレーティング・システム・ユーティリティまたはツールがNCSによって生成された論理を実施するために使用されてもよい。他の実施では、カスタム・ツールまたはユーティリティが使用されてもよい。メトリックスは、例えば、様々な性能ツール等を用いてターゲット・ノードから収集され、NCSへの入力として使用されてもよい。
【0060】
図12は、少なくとも幾つかの実施形態による、トリガとなるイベントに応答してネットワーク管理パラメータを変更するよう実施され得る動作の態様を例示するフロー図である。要素1201に示されるように、潜在的なDDOS攻撃等、トラフィック分類メタデータに対する変更を結果としてもたらすイベントが検出され得る。幾つかの実施形態では、プロバイダ・ネットワークは一つ以上のセキュリティ・サービスを確立して様々な種類の起こり得る攻撃を示す疑いのあるトラフィック・パターンを識別してもよい。このようなサービスはネットワーク構成システムと通信されてもよい。攻撃によって影響を与えられるまたは攻撃に寄与する分散システムの特定のノード(例えば、インスタンス・ホストおよび/またはスイッチ、ルーター等のネットワーク装置)は、図示する実施形態では、例えば、セキュリティ・サービス、NCS、または、セキュリティ・サービスとNCSの組み合わせのいずれかにより識別される(要素1204)。
【0061】
トラフィック分類メタデータの変更されたセットは、攻撃の影響を緩和するようNCSで生成される(要素1207)。変更は、例えば、(例えば、疑いのあるトラフィックを送信するおよび/または受信することに関わる特定のノードのアドレスに基づいて)定められるトラフィックの新しいカテゴリー、および/または、適用されるべき新しい帯域幅限界または他のネットワーク構成オプションを含み得る。続いて、新しいメタデータは、幾つかの実施形態において、攻撃に関連するまたはターゲットとされる特定のノードおよび/または他のノード(例えば、疑いのあるトラフィックが通る路に沿った中間物であるネットワーク装置)を含み得る、分散システムのノードの選択されたセットに送信されてもよい。
【0062】
トリガとなる状態に応答するのにかかる時間、例えば、状態の検出と新しいメタデータの適用との間の間隔が測定され、記録される(要素1210)。このようなトリガとなるイベントへのネットワーク構成システムの応答における傾向および/またはネットワーク構成システムがとる動作の有効性が、時間とともに分析され、構成を変化させる必要があるか否かが確定される(要素1213)。応答が不十分とされた場合、例えば、任意の数の構成変化が行われる。例えば、検出されたイベントにより有効的に応答するよう、NCSの数が増加される、イベント検出部とNCSとの間の接続性が改善される、メタデータ分散システムが向上される、および/または、NCSまたはターゲット・ノードでの論理が変更される。
【0063】
図13は、少なくとも幾つかの実施形態による、分散システムのクライアントにネットワーク関連のステータス情報の統一ビューを提供するよう実施される動作の態様を例示するフロー図である。要素1301に示されるように、一つ以上のプログラマチック・インターフェイス(例えば、ウェブページまたはコンソール、API、GUI、または、コマンド・ライン・ツール)は、関心のある様々な分散システム資源のネットワーク・ステータスの統一されたカスタマイズ可能なビューをクライアントに提供するよう確立されてもよい。例えば、クライアントは、仮想化されたコンピューティング・サービスの多数の計算インスタンスが割り当てられてもよく、最後の15分間でどの特定のインスタンスが帯域幅の制限に影響されたかを知りたいと望む場合がある。プログラマチック・インターフェイスにより、クライアントは様々なフィルタを使用して表示されるべきネットワーク特性および/または特性が表示されるべき資源のセットを特定し得る。
【0064】
ネットワーク・ステータス・リクエストがインターフェイスを介して受信され、関心のあるメトリックスおよび資源が示される(要素1304)。ネットワーク構成システムは、例えば、メトリックス・データベース190(要素1307)から、または、NCSにおけるキャッシュからリクエストされたメトリックスを引き出してもよい。幾つかの実施形態では、リクエストに応答する際に有用となり得る適用可能な分類メタデータも分類データベース192(要素1310)またはNCSにおけるメタデータ・キャッシュから引き出されてもよい。収集された情報を用いて、ネットワーク・ステータス・リクエストに対する応答が生成され、プログラマチック・インターフェイスを介してリクエスタに供給される(要素1313)。
ネットワーク・トポロジーに対する資源使用の可視化ツール
【0065】
上述した通り、ネットワーク構成サービスはプロバイダ・ネットワークのような分散システムの様々なコンポーネントから様々なメトリックスを収集し、これらのメトリックスを用い、少なくとも幾つかのノードに対して帯域幅限界等の設定を確定する。少なくとも一つの実施形態では、性能インジケータまたは資源使用インジケータ(例えば、様々なノードでのそれぞれの測定されたネットワーク・トラフィック率とこれらのノードに対して設定されたそれぞれの帯域幅限界との間の比の色分けされた表現またはヒートマップ)を表示することができる一つ以上の可視化ツールが実施されてもよい。一実施形態によると、資源ヒートマップおよび/または他のタイプの可視化を提供するよう構成されるネットワーク・トポロジー可視化サーバーは、ネットワーク構成サーバー180のサブコンポーネントとして実施されてもよい。他の実施形態では、ネットワーク・トポロジー可視化ツールは、ネットワーク構成サーバー180とは独立して実施されてもよく、例えば、分散システムの別の中央化サービスとして、または、単独型エンティティとして実施されてもよく、NCS180と相互に作用する或いはNCS180によって収集されたデータを消費し得る。少なくとも幾つかの実施では、統合ネットワーク・ビュー生成部152(
図1に示す)は、その特徴の一つとしてトポロジー可視化インターフェイスを含み得る。
【0066】
中央化トポロジー可視化サーバー(TVS)は、少なくとも幾つかの実施形態において分散システムの様々なノード間の論理的および/または物理的関係を確定するよう構成されてもよい。例えば、仮想コンピューティング・サービスが実施される実施形態では、TVSは、インスタンス・ホストのセットで様々な計算インスタンスが割り当てられるクライアント・アカウントを確定し、アカウント情報を使用して特定のクライアント・アカウントまたはクライアント・アカウントの選択されたセットに割り当てられた計算インスタンスだけを含むトポロジーを生成してもよい。当該クライアント・アカウント(またはアカウントのセット)と関係するクライアントからの可視化リクエストに応答して、当該トポロジーのインスタンスに対する性能インジケータを示すヒートマップが提供されてもよい。一つ以上のデータ・センターで実施されるネットワーク・アクセス可能サービスの管理者に対して、様々なインスタンス、ホストおよび/またはスイッチ、ルーター等のネッ
トワーク装置間の物理的または論理的ネットワーク・リンクを示し得る、より詳細なトポロジーが生成され、サービスの非管理クライアントには典型的にはアクセス可能でない情報を用いて対応するヒートマップが生成され得る。各ケースにおいて、クライアントまたは管理者には、生成されたヒートマップを用いて、様々なタイプの資源の使用統計の理解しやすい視覚表示が提供されてもよい。続いて、使用統計が使用されて、例えば、潜在的な障害または他のタイプの問題が積極的に特定されて、応答作用が行われる。ヒートマップに表示される色の範囲、および、色間の遷移境界は、示されるメトリックのレベルを示すために選択可能である。例えば、一実施では、最近測定されたトラフィック率が当該ノードに対する帯域幅限界に非常に近いことを示すようネットワーク・トポロジーの所与のノードに対して赤色が表示され、測定されたトラフィックが限界をはるかに下回ることを示すよう緑色が使用され、赤から緑への遷移色がトラフィックの中間レベルに対して使用されてもよい。
【0067】
幾つかの実施形態によると、TVSは、分散システムにおける様々なソースからメトリックスの集まりを取得し、分散システムの様々なコンポーネントについて関係情報を取得し、収集されたメトリックスおよび関係情報に基づいて様々なタイプのネットワーク・トポリジーについて性能インジケータ(例えば、個別性能メトリックス、または、適用可能な限界へのメトリックスの比)を確定する責任を担う。クライアントまたは管理者が資源性能インジケータのカスタマイズされたまたはフィルタリングされた可視化をリクエストすることを可能にするプログラマチック可視化インターフェイスが実施されてもよく、TVSはデータ・セットの適当なサブセットを用いて性能インジケータのヒートマップおよび/または他のグラフィカル表現を合成することで可視化リクエストに応えてもよい。幾つかの実施では、一つ以上のこれらタスクは、以下により詳細に説明するように、分散システムの他のコンポーネントまたはサービスとの相互作用を伴い得る。
【0068】
図14は、少なくとも幾つかの実施形態による、分散システムの少なくともノードのサブセットについてトポロジー可視化サーバー(TVS)1410によって生成され得るカスタマイズ可能なヒートマップ1450の実施例を例示する。図示する実施形態では、TVSはネットワーク構成サーバー180の構成要素として実施される。他の実施形態では、TVS1410は、NCSとは独立した或いはNCSの外部の一つ以上のハードウェアまたはソフトウェア・コンポーネントを用いて実施されてもよく、例えば、中央化可視化サービスは幾つかのこのような実施形態ではNCSが不在の状態で実施されてもよい。TVS1410は、アカウント管理サービス1420、配置サービス151、在庫サービス1430、並びに、メトリックス・コレクタ125を含み、
図14に示す実施形態における幾つかのタイプのデータ・ソースからの入力を取得してもよい。
【0069】
アカウント管理サービス1420は、一つ以上のマルチテナントまたはシングルテナント・サービス・インスタンス(例えば、仮想化されたコンピューティング・サービス、ストレージ装置、または、データベース・サービス)の様々なサービス・インスタンスが割り当てられるクライアント・アカウント(および/または関係するユーザまたはグループ・アカウント)に関する情報をTVS1410に供給してもよい。前述の通り、配置サービス151は、様々なサービス・インスタンスが立ち上げられるインスタンス・ホストを特定する責任を担うため、ネットワーク・トポロジーを生成する上で有用となるインスタンス-ホスト・マッピングを少なくとも幾つかの実施形態において提供することができる。在庫サービス1430は、一つ以上のデータ・センター内のどこに様々なインスタンス・ホスト、スイッチ、ルーター、および、分散システムの他の機器部品が物理的に位置しているかを記録するデータベースを管理してもよい。
図1の文脈で前述した通り、メトリックス・コレクタ125は、分散システム内の様々なサービス・インスタンス、ホスト、ネットワーク装置等からネットワーク関連および/または他の資源のメトリックスを集めてもよい。例えば、ネットワーク関連のメトリックスについて、ソースは中でも(a)ネ
ットワーク・インターフェイス・カード、(b)仮想化ホストにインストールされる仮想化ソフトウェア・スタックのネットワーク・コンポーネント、(c)計算インスタンスのネットワーク・コンポーネント、(d)ネットワーク・タップ装置、(e)スイッチ、(f)ルーター、(g)ゲートウェイ、または(h)ロード・バランサを含んでもよい。幾つかの実施形態において、
図14に示される様々なタイプのデータ・ソースの全てがTVS1410によって使用されないことに注意する。例えば、幾つかの実施では、配置サービスは様々なノードに関する物理的な場所情報を供給することができるため、在庫管理サービスとの相互作用はこのような実施では必要とされない。
【0070】
これら様々なソースから収集されたデータは、TVS1410によって合成され、可視化リクエストに応答して模範的なヒートマップ1450等の様々なカスタマイズ可能なヒートマップが生成される。ヒートマップ1450は、クライアント・アカウントCA1に割り当てられた五つの計算インスタンス(CI)、例えば、利用可能コンテナ203AにおけるCI1440A、1440B、および、1440C、および利用可能コンテナ203BにおけるCI1440Dおよび1440Eを有するネットワーク・トポロジー1460を示す。幾つかのケースでは、TVS1410によって生成されたトポロジーは、様々な実施形態において、データ・センター境界、利用可能コンテナ境界(
図14に示すような)、または、他の組織的或いは物理的境界をわたる。トポロジー1460における各計算インスタンス1440について、それぞれの色点けされた性能インジケータ(PI)1470が表示され、例えば、CI1440A、1440B、1440C、1440D、および、1440Eに対してPI1470A、1470B、1470C、1470D、および、1470Eが示される。PI1470は、異なる実施形態において様々な異なるタイプのメトリックスまたはメトリックスと関連付けられる比を示し、符号化された性能情報のタイプは少なくとも幾つかの実施においてカスタマイズ可能である。例えば、入来および/または出発トラフィックに対する、現在構成されている帯域幅限界に対する測定されたトラフィック率の比が表示されてもよい。このような模範的なシナリオでは、赤色PIは測定されたトラフィックが帯域幅限界に近い(例えば、その75%より大きい)ことを示し、緑色PIは比が30%より下であることを示し、黄色PIは比が30%乃至75%の間であることを示している。幾つかの実施では、数値またはテキストメッセージが各ノードに対して示されてもよい(例えば、比の値がパーセンテージとして表示されてもよい)。異なる実施形態において、ネットワーク帯域幅関連インジケータ、待ち時間関連インジケータ(例えば、最近測定された待ち時間がパケット待ち時間に対して要求される上界にどれだけ近いか、或いは、測定された平均的パケット転送待ち時間と待ち時間に対するターゲット上界との間の比)、閾値に対するCPU利用レベル、ストレージ装置利用レベル、メモリ利用レベル等を含む、幾つかの異なるタイプの性能インジケータがTVSによって表示されてもよい。幾つかの実施形態では、ヒートマップに比が示されることに加えて或いはその代わりに(例えば、何らかの定義された閾値に対する測定された値の比)、絶対値が示されてもよい。少なくとも幾つかの実施において、ヒートマップは可視化サービスによって提供された情報に基づいてクライアント側のコンポーネント(例えば、ウェブブラウザまたはGUIツール)によって表示されてもよい。そのため、上述のような実施において、可視化サービスは、メトリックスを取得し、トポロジーや性能インジケータを確定し、クライアント側のコンポーネントに何らかの適当なフォーマットでヒートマットに含まれるようデータの選択されたセットを供給することについて、責任を担っている。クライアント側のコンポーネントは、可視化サービスによって提供されるデータを用いてヒートマップを表示する。少なくとも幾つかの実施形態では、可視化サービスは、バックエンド・コンポーネントとフロントエンド・コンポーネントの両方を有し、バックエンド・コンポーネントはヒートマップの形態で提示され得る基礎データの生成に関与し、フロントエンド・コンポーネントはヒートマップの実際の表示に関与する。
【0071】
幾つかの実施形態によると、TVS1410のユーザは、可視化において表示される情
報の粒度を調節することができる。例えば、一実施では、ネットワーク関連の性能インジケータに関して、クライアントは次の粒度のいずれかに対して好みを示し得る:(a)ポートレベルの粒度(例えば、TCPまたはUDPポートのレベルでの情報が好ましい)、(b)ネットワーク・インターフェイス・レベルの粒度、(c)バーチャル・マシン・レベルの粒度、(d)ホスト・レベルの粒度、(e)ラックレベルの粒度、(f)データ・センター・ルーム・レベルの粒度、(g)データ・センター・レベルの粒度、(h)利用可能コンテナレベルの粒度、または(i)地理的領域レベルの粒度。粒度の選択肢は、様々な実施形態において、ストレージ関連のメトリックス等、性能インジケータが表示され得る他のタイプの資源またはメトリックスに対して選択されてもよい。TVS1410は、要求された粒度で収集されたメトリックスを統合して、可視化または表示に含まれるよう性能インジケータを確定してもよい。表示されるネットワーク関連情報の粒度をカスタマイズ化することに加えて、少なくとも一実施形態では、表示が様々なトラフィック・カテゴリーについてカスタマイズ化されてもよい。例えば、分散システムの所与のノードへのまたは所与のノードからのネットワーク・トラフィックはエンドポイントIPアドレスに基づいて(例えば、トラフィックがプロバイダ・ネットワーク内の二つのインスタンス間を、または、プロバイダ・ネットワーク外にある公衆インターネット・アドレスに流れているか)、トラフィックのエンドポイントが割り当てられるクライアント・アカウントに基づいて、または、トラフィックが生成されるアプリケーションまたはアプリケーション・タイプ(例えば、データベース関連のトラフィック特有のヒートマップが要求される、または、高性能計算特有のヒートマップが要求される)に基づいて分類されてもよい。
図5に例示するようなトラフィック分類は、表示される情報をフィルタリングするために幾つかの実施形態において使用されてもよい。少なくとも幾つかの実施において、TVSのクライアントは、性能インジケータを表示したいトラフィック・カテゴリーをプログラムで定めてもよい。例えば、クライアントは、その割り当てられた計算インスタンスの一つのセットをソースセットとして指定し、インスタンスの別のセットまたは他のエンドポイント(例えば、特定のデータベース・インスタンス)を宛先として指定し、指定されたセットに基づいてトラフィック・カテゴリーを定めてもよい。
【0072】
一実施形態では、可視化リクエストは、時間的コンポーネントを含み得、例えば、リクエストは、特定されたタイプのメトリックについて、表示される性能インジケータを生成するためにメトリックスが収集される時間期間を示す。幾つかの実施形態では、クライアントは、例えば、特定された時間期間にわたる所与の性能インジケータの値における変動が示される、動的可視化をリクエストすることができる。可視化のリクエスタに割り当てられる許可能力または役割(例えば、リクエスタがサービスに対して管理的アクセス許可を有するか、非管理的アクセス許可を有するか)は、様々な実施形態において表示され得る情報の種類を制御する暗黙のフィルタとしても機能する。幾つかの実施形態では、中央化可視化サービスは、二つ以上のネットワーク・アクセス可能サービスに関連する資源メトリックスまたは性能インジケータを見ることに有用であり、可視化の消費者は性能インジケータが表示されるサービスを示すことができる。例えば、プロバイダ・ネットワークの所与のクライアント・アカウントは、プロバイダ・ネットワークによって実施される関係型データベース・サービスおよび非関係型データベース・サービスの両方を使用してもよく、別個のヒートマップが二つの異なるタイプのデータベース・サービスに対してそれぞれのトポロジーおよび関連ネットワーク性能インジケータについて生成されてもよい。
【0073】
トポロジー可視化サーバーの異なる消費者は、収集されたメトリックスの異なるサブセットにアクセスする許可が与えられるため、幾つかの実施形態では異なるレベルの詳細で可視化が提供される。
図15は、少なくとも幾つかの実施形態による、サービス管理者およびサービスの非管理クライアントに対してヒートマップを生成するために使用され得る収集されたメトリックスの異なるサブセットの実施例を例示する。図示するように、管理者アクセス可能メトリックス1510は、図示する実施形態において非管理クライアント
によってアクセス可能なメトリックスのスーパーセットでもよい。例えば、仮想コンピューティング・サービスおよび一つ以上の仮想化されたストレージ・サービス等の様々な仮想化されたマルチテナント・サービスが実施されるプロバイダ・ネットワークでは、仮想化を実施するために使用される物理的資源に関する情報(例えば、使用されるインスタンス・ホスト、使用されるネットワーク装置、様々なデータ・センター内の物理的資源の配置)が幾つかの理由により秘密と考えられている。使用されるハードウェア・プロセッサおよび装置のタイプ等の詳細をサービス・クライアントに提供することは、ハードウェアの詳細を考慮することなく様々なサービス特徴を絶えず利用するといったクライアントの能力等、仮想化されたサービスを実施する主な目標の一つに反する。しかしながら、仮想化されたサービスの管理者は、例えば、ハードウェア・サーバー、ラック、ネットワーク装置等の適当な数やタイプを提供するために、使用されるハードウェアに関する少なくとも幾らかの詳細を知る必要がある。したがって、管理者は、図示する実施形態において非管理クラアイントに提供されるよりもTVS1410によって生成されるより詳細なヒートマップを見ることができる。
【0074】
幾つかの実施形態では、非管理クライアントに曝された情報のタイプは、所与のクライアント・アカウントまたはリンク付けされたクライアント・アカウントのセットに割り当てられたインスタンスについて帯域幅限界に対する測定されたネットワーク・トラフィックの比等、サービス・インスタンス・レベルの性能インジケータを含んでもよい。幾つかの実施形態では、クライアント・アカウントは私的部門または公的部門エンティティ、或いは、このようなエンティティ内の部門を含む組織の代わりにプロバイダ・ネットワークの一つ以上のネットワーク・アクセス可能サービスで確立されてもよい。各クライアント・アカウントは、幾つかの実施において幾つかの異なるユーザ・アカウントまたはグループ・アカウントを包含してもよい。少なくとも幾つかの実施形態では、例えば、それぞれクライアント・アカウントが確立された大企業の二つの異なる部門に対する総請求のために、異なるクライアント・アカウントがリンク付けされてもよい。クライアントC2にアクセス可能なインスタンス関連メトリックス1515B等、TVSによって収集されたメトリックスの幾つかは、一つのクライアント・アカウント(例えば、該アカウントに対して定められたユーザ/グループ)にだけ可視である。クライアントC1およびC2に可視なインスタンス関連メトリックス1515A等、他のメトリックスは複数のリンク付けされたクライアント・アカウントと関係するユーザ/グループに可視である。
【0075】
様々な実施形態において、幾つかのメトリックスのタイプは、非管理ユーザにアクセス可能でない。例えば、スイッチ、ルーター、ゲートウェイ等の特定のネットワーク装置と関連付けられるメトリックス1550は、典型的には、非管理者に曝されない。同様にして、インスタンス・ホスト(複数のクライアントに対してサービス・インスタンスを潜在的に実施するハードウェア・コンピューティング装置)について収集されたメトリックスも管理者によってのみアクセスされ得る。図示する実施形態では、データ・センターに関するメトリックス(例えば、特定のデータ・センターに流入し、流出するトラフィック量)も管理的使用にのみ制限されてもよい。
【0076】
したがって、TVS1410によって異なる消費者カテゴリーについて生成されたヒートマップのタイプは異なる。図示する実施形態において、クライアントC1にはメトリックス1515Aから導出された比較的制限されたヒートマップ1450Aが提供され、クライアントC2はソース・メトリックスが1515Aおよび1515Bの両方を含むヒートマップ1450Bを見ることができる。管理ユーザは、より大きいメトリックスの集まり1510から導出されたヒートマップ1450Cを見ることができる。所与の可視化リクエストに応答するよう使用されるべきメトリックスのサブセットについての決定は、例えば、許可設定の確定、リクエスタの能力または役割に基づいて、少なくとも幾つかの実施形態では、ランタイムでTVSによってなされてもよい。
可視化のためのプログラマチック・インターフェイス
【0077】
幾つかの異なるタイプのプログラマチック・インターフェイスが、異なる実施形態において、可視化リクエストを受信し応答するために使用されてもよい。
図16は、少なくとも幾つかの実施形態による、ネットワーク・トポロジーに対するヒートマップを表示するために使用され得るウェブベースのプログラマチック・インターフェイスの実施例を例示する。図示するように、ウェブベースのインターフェイスは、ネットワーク・トポロジーのノード1610A、1610B、および、1610Cが性能インジケータ1620A、1620B、および、1620Cのそれぞれのセットと一緒に表示される、ウェブページ1602を有する。
【0078】
性能インジケータ1620は、ネットワーク帯域幅(
図16においてラベル「BW」によって示される)、CPU、ディスク、および、メモリ(ラベル「Mem」によって示される)等、図示する実施例においてノードそれぞれについて複数の資源タイプに対する色付けされたエントリーを示す。ヒートマップを変更するまたはカスタマイズ化する幾つかのウェブベースの制御が
図16に例示される。例えば、ズーム制御1650は、トポロジーの異なる部分にズームインする、または、ズームアウトするためにビューアによって使用されてもよい。資源セレクタ1652は、可視化から幾つかのタイプの資源をフィルタで除去する、または、資源タイプを追加するために使用されてもよい。同様のセレクタが、表示のための時間期間(即ち、性能インジケータに対するメトリックスの使用の集まりに対応する時間の期間)、ネットワーク・トラフィック・カテゴリー、アプリケーション・タイプ等を選択するためにも有用である。図示する実施形態では、ビューアは、可視化に使用する閾値1654を特定することも可能であり、例えば、ビューアは、帯域幅限界の80%(またはそれより高い)の測定された転送速度が赤色BW性能インジケータによって示され、30%未満の値が緑色BW性能インジケータによって示される等と示してもよい。
【0079】
図17は、少なくとも幾つかの実施形態による、プログラマチック・インターフェイス1770を介してトポロジー可視化サーバー1410によって受信され得る可視化リクエスト1720の模範的な要素を例示する。このようなリクエストは、例えば、クラアイントまたは管理者1710による制御1650、1652、または、1654と同様の一つ以上の制御の選択に応答して、幾つかの実施形態において、
図16に示すようなウェブページを介して行われてもよい。他の実施形態では、このようなリクエストは異なるGUI、API呼び出しを介してまたはコマンド・ライン・ツールから要請されてもよい。
【0080】
図示するように、リクエスト1720は、可視化に含まれるべきサービス・ノードのセットを示すターゲット・サービス・ノード・リスト1725を有してもよい。幾つかの実施形態では、特定のセットのノードの表示がリクエスタによって提供されない場合、サービス・ノードのセットに対するデフォルト設定がTVS1410によって使用されてもよい。例えば、デフォルトで、クライアント・アカウントに割り当てられた全ての計算インスタンスが可視化のために選択される、または、管理者がリクエストを要請するデータ・センター内の全てのインスタンス・ホストが可視化に含まれ得る候補として考えられる。ノードのセットは、幾つかの実施形態において明確に示されてもよい(例えば、計算インスタンス識別子等のノード識別子のリストを提供することで)、または、ノードを検索するために使用され得るフィルタリング基準を示すことで(例えば、クライアントは特定された利用可能コンテナにおける計算インスタンスがセットに含まれるべきと示してもよい)。可視化に含まれるべきネットワーク・トラフィックのカテゴリーおよび/または資源も要素1728を用いてトポロジー可視化リクエストに示されてもよい。前述した通り、トラフィック・カテゴリーは、幾つかの実施形態において、クライアントによって定められてもよい。他の実施形態では、クライアントまたは管理者1710が、クライアントが
定めたカテゴリーの代わりに或いはそれに加えて、複数の所定のトラフィック・カテゴリーの中から選択してもよい。幾つかの実施形態では、例えば、計算インスタンスだけを示すヒートマップが提供されるべきか、または、ストレージ・ノードが含まれるべきか等、資源の異なるカテゴリーも選択可能である。
【0081】
可視化の粒度1731は、例えば(ネットワーク・トラフィックに対して)ホスト・レベルのビューが望ましいか、インスタンスレベルのビューが望ましいか等、幾つかの実施形態において、リクエスト1720に示されてもよい。可視化を生成するために使用されるべき様々なソースからのメトリックスの集まりの時間範囲は要素1734を介して示されてもよい。幾つかの実施では、クライアントは動的可視化をリクエストすることができ、例えば、選択された時間期間にわたる性能インジケータの値の変化が要素1737を介して示されるクライアントの好みに応じて表示されてもよい。少なくとも幾つかの実施形態において、リクエスト1720の要素に対して利用可能な選択肢のセットがユーザ間で変わり得ることに注意する。例えば、管理者は、可視化機能性の非管理ユーザよりもより広い範囲の好みを特定することができる。少なくとも一実施形態において、管理者には非管理ユーザに提供されものとは異なるセットのプログラマチック・インターフェイス1770がTVS1410によって提供されてもよい(例えば、より広範囲のセットのAPIが他のユーザよりも管理資格を有するユーザに利用可能である)。図示する実施形態では、リクエスト1720に応答して、TVS1410はデータの適当なセットを引き出し、ヒートマップ1450の形態で対応する表示を提供してもよい。
ネットワーク・トポロジーの可視化のための方法
【0082】
図18は、少なくとも幾つかの実施形態による、分散システムの様々なノードの性能インジケータを有するトポロジーの可視化を生成するよう実施される動作の態様を例示する。要素1801に示されるように、幾つかのメトリックスが、プロバイダ・ネットワークにおいて実施される様々なネットワーク・アクセス可能サービスのサービス・インスタンス、ルーター、スイッチ、ゲートウェイ等のネットワーク装置、並びに、分散システムのインスタンス・ホスト或いは他のタイプのハードウェアまたはソフトウェア・コンポーネント等、様々なデータ・ソースからTVS1410によって収集されてもよい。収集されたメトリックスは、例えば、ネットワーク関連メトリックス(インバウンドまたはアウトバウンド・トラフィック率、現在適用可能な帯域幅限界、測定されたおよびターゲット化された待ち時間、ネットワーク・エラー・カウント、パケット・サイズ分散、または、ドロップされたパケット・カウント等)、プロセッサ関連メトリックス(全体的なCPU利用、ターゲット閾値CPU利用レベル、カーネル対ユーザ利用スプリット、アクティブ処理/スレッド・カウント等)、メモリ関連メトリックス(例えば、利用可能なフリーメモリの量、ページング速度等)、および、ストレージ関連メトリックス(ディスクまたは他のストレージ装置利用、平均的応答待ち時間、キュー長さ等)を含んでもよい。一実施形態において、現在適用されている限界(例えば、帯域幅限界)または性能ターゲット(例えば、待ち時間ターゲット)に関するメトリックスは、NCS180から取得されてもよい。幾つかの実施形態では、幾つかのまたは全てのメトリックスは、NCS180によって例えば、様々な資源の間で帯域幅分散を確定する等、他の目的のために既に収集されていてもよく、TVSはNCSの他のコンポーネントまたはメトリックス・データベース190からメトリックスを取得してもよい。一実施形態では、メトリックスは、様々なデータ・ソースによって他のタイプのメッセージにピギーバックされてもよく、例えば、前述の通り、心拍メッセージが健康管理プロトコルに応じて送られる。
【0083】
TVS1410は、例えば、プロバイダ・ネットワークのアカウント管理サービス1420から、または、アイデンティティ管理サービスから、分散システムにおいて実施されている様々なサービスに対するクライアント・アカウント情報(
図18の要素1804)も取得してもよい。アカウント情報は、異なるクライアント・アカウント間(例えば、幾
つかのクライアント・アカウントは統合請求のために他のアカウントとリンク付けされてもよい)、並びに、クライアント・アカウントとユーザ・アカウントまたはグループ・アカウント間等の関係を含んでもよい。少なくとも幾つかの実施において、TVSはサービス・ノードまたはインスタンス間およびクライアント・アカウント間のマッピング、例えば、所与の計算インスタンスを代わりに立ち上げたクライアント・アカウントを示す情報を取得してもよい。少なくとも幾つかの実施形態において、データ・センターの異なるラックやルームにおけるインスタンス・ホストの配置、分散システムの異なるノードとスイッチやルーター等の様々なネットワーク装置との間のネットワーク・リンクまたは路といった物理的なレイアウト情報が取得されてもよい(要素1807)。物理的なレイアウト情報は、例えば、在庫サービスまたは他のデータ・センター管理ツールから取得されてもよい。
【0084】
一つ以上のネットワーク・トポロジーは、例えば、アカウント情報を物理的なレイアウト情報と合成して、関連するノードまたは資源について確定されてもよい(要素1810)。分散システムのサイズやそのユーザ・ベースに依存して、総合的なネットワーク・トポロジーを生成するおよび/または記憶することは、幾つかの実施形態において相当な計算、メモリ、および/または、ストレージ資源を必要とし得る。したがって、例えば、各データ・センターに対して一つ、或いは、各地理的領域に対して一つ等、幾つかの実施形態において幾つかの異なるネットワーク・トポロジーが生成されてもよい。性能インジケータのデータ・セットは、収集されたメトリックスを用いて単一のトポロジーまたは複数のトポロジーに対応して作成されてもよい(要素1813)。最近の時間間隔中に測定されたトラフィック率および該間隔中に適用された帯域幅限界の比、ターゲット最大待ち時間に対する時間間隔中に観察されるピーク待ち時間の比、ターゲットとされた最大または最小レベルに対して測定されたCPU利用等、任意の数の性能インジケータがトポロジーの様々なノードに対して確定されるまたは導出されてもよい。
【0085】
少なくとも性能インジケータのサブセットに対する可視化リクエストが受信されてもよい(要素1816)。リクエスタの許可設定が確定され、リクエストおよび許可設定に対応する性能インジケータのデータ・セットの適当なサブセットが取得される(要素1819)。静的または動的ヒートマップの形態の色付けされた可視化が表示されてもよい(要素1822)。ブラウザ、ブラウザ・プラグイン、またはGUI等のクライアント側のコンポーネントは、バックエンドTVS1410によって提供されるデータに基づいてヒートマップを表示するために使用されてもよい。幾つかの実施形態では、性能インジケータのヒストグラム、円グラフ等他のタイプの可視化がTVS1410を用いてリクエストに応じて提供されてもよい。幾つかの実施形態では、トポロジーがオンデマンドで、例えば、可視化リクエストが受信された後、リクエストされた特定のタイプの性能インジケータに基づいて生成されてもよいことに注意する。
クライアント・リクエストされた資源使用限界の低減
【0086】
幾つかの分散システムでは、様々なサービスに対してクライアントが支払わなくてはならない金額は、クライアントの代わりにサービス・インスタンスで生成されたネットワーク・トラフィックに依存し得る。幾つかのシナリオでは、サービスは、一サービス・インスタンス当たり転送され得るデータの量(または、データ転送の速度)に対して上界を定め、トラフィックに比例する料金がこの上界より低く適用されてもよい。したがって、クライアントは、予算に合うよう、少なくとも一時的にこのような環境においてネットワーク使用を減少させるインセンティブを有する。幾つかのタイプのサービスに対して、幾つかの異なる標準化されたサービス・インスタンス・タイプがクライアントに利用可能であり、このとき、異なるネットワーク限界および/または速度が各インスタンス・タイプに適用可能である。
図19は、少なくとも幾つかの実施形態による、それぞれの帯域幅限界およびそれぞれの帯域幅使用価格決定ポリシーが異なるインスタンス・タイプに設定され
た、ネットワーク・アクセス可能サービスに対して実施され得る計算インスタンス・タイプのセットの実施例を例示する。仮想コンピューティング・サービスによって定められる、四つの異なる計算インスタンス・タイプ1902(「小」、「中」、「大」、「特大」計算インスタンス)に対するネットワーク関連設定を含む表が示される。インスタンス・タイプは、ネットワーク能力および帯域幅関連価格決定における差に加えて、計算力、ストレージ・サイズ限界、メモリ・サイズ、または、全体的な価格決定等、様々な特性において異なり得る。
【0087】
図示する実施形態では、二つの異なるトラフィック・カテゴリー(カテゴリー「A」と「B」とそれぞれラベル付けされる)のそれぞれについて、アウトバウンド・トラフィック(列1904)およびインバウンド・トラフィック(列1908)に対して別個の帯域幅限界が定められてもよい。カテゴリーは、関係するエンドポイントがプロバイダ・ネットワーク内にあるか否か、例えば、トラフィックが公衆インターネットに方向付けられているか否かに関して互いと異なってもよい。異なるインスタンス・タイプに対する帯域幅限界に加えて、
図19は、二つのトラフィック・カテゴリーそれぞれについて別個に特定され得る、アウトバウンドおよびインバウンドの帯域幅価格決定(それぞれ列1906および1910)も示す。実際には、幾つかの実施形態においてプロバイダ・ネットワーク・オペレーターによって幾つかの価格がゼロに設定されてもよく、例えば、同じデータ・センター内でたまたまインスタンス化された異なる計算インスタンス間のトラフィックが「フリー」でもよいことに注意する。
図19に例示される情報は、仮想コンピューティング・サービスの潜在的クライアントによってアクセスされ得、各タイプのインスタンスをどれだけ取得すべきかを決定する際にクライアントによって(クライアントのアプリケーションの計算性能要件、帯域幅使用に関連しない価格決定ポリシー等の他の要素とともに)考慮されてもよい。幾つかのクライアントは、例えば、
図19に提供される情報の種類を用いてネットワーク関連のコストのための予算を取っておいてもよい。クライアントのアプリケーションのニーズにより、少なくとも幾らかの時間期間中、所与のクライアントはそのインスタンス・タイプをサポートした最大帯域幅よりもはるかに小さい帯域幅を利用する必要があり、そのため、より低い限界を課すことをリクエストすることでより効果的にコストを管理することができる場合がある。例えば、所与のネットワーク・アクセス可能サービスにアクセスする権限が与えられた多数の個人ユーザを所与のビジネス組織が含む環境では、低帯域幅限界を適用することは、個別ユーザにそれぞれの帯域幅使用を自主的に制御することを単にリクエストするよりも、ネットワーク関連のコストを低減させるより信頼できる方法である。
【0088】
少なくとも幾つかの実施形態では、
図1に例示するのと同様の中央化ネットワーク構成サービスは、顧客リクエストされた帯域幅限界および/または他のタイプの資源使用減少限界を実施するために使用されてもよい。幾つかのタイプのネットワーク関連限界のいずれかが様々な実施形態ではクライアント・リクエストに応答して適用されてもよく、例えば、(a)幾らかの時間の期間にわたって超えられてはならない平均的トラフィック送信速度、(b)短い時間の期間にわたってさえも超えられてはならないピーク・トラフィック送信速度、(c)転送されたデータの合計バイト数に対する上限、または、(d)転送されたネットワーク・メッセージの数に対する上限が適用されてもよい。平均的限界および/またはピーク限界が適用される時間の期間は、幾つかの実施形態においてクライアントによって示されてもよい。
図20は、少なくとも幾つかの実施形態による、ネットワーク構成サーバー180によって受信され得る資源使用限界低減リクエスト2020の模範的な要素を例示する。幾つかの実施形態では、前述の通り、所与の請求可能な顧客アカウントは、それと関連付けられる幾つかのユーザ・アカウントを有し、異なる資源使用限界が異なるユーザ・アカウントに適用されてもよい。図示するように、プログラマチック・インターフェイス2070を介して要請されるリクエスト2020は、リクエストされた低減が適用されるべき一つ以上のユーザ・アカウントを示す要素2023を含んでもよい
。幾つかの実施形態ではグループ・アカウントも示され得る。一実施形態では、幾つかの異なる計算インスタンスまたは他の資源が割り付けられたクライアント2010は、これら資源の幾つかのサブセットにより低い資源使用限界を適用することを望む場合がある。ターゲットとされた特定ノードまたは資源の識別子は、限界低減リクエスト2020の別の要素2026を介して示されてもよい。幾つかのセットのサービス・インスタンスに対する組み合わされた資源使用限界は、幾つかの実施においてクライアントによってリクエストされてもよい。例えば、クライアントは、インスタンスI1、I2、および、I3にX GB/秒の帯域幅限界が集合的に適用されることをリクエストしてもよく、限界はインスタンスの帯域幅使用の合計が特定の時間期間中にX GB/秒を超える場合に満たされたと考えられる。
【0089】
それぞれの使用限界は、幾つかの実施形態において異なるネットワーク・トラフィック・カテゴリーに適用されてもよい。上述した通り、幾つかの実施形態では、ネットワーク・アクセス可能サービスは、例えば、エンドポイントのネットワーク・アドレスの範囲に基づいて、および、エンドポイントの地理的場所に基づいて、ネットワーク・トラフィックの様々なカテゴリーを定めてもよい。幾つかの実施形態では、例えば、それぞれの限界は、(a)一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、(b)プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、(c)プロバイダ・ネットワークによって定められる所与の地理的領域内の二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、(d)プロバイダ・ネットワークによって定められる二つの異なる地理的領域における二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、または、(e)特定のサービス・インスタンスとプロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィック、に適用されてもよい。
図20に示す実施形態では、使用の低減をターゲットとしたトラフィック・カテゴリーまたは複数のカテゴリーは、要素2029を介して示されてもよい。
【0090】
ネットワーク・トラフィックに対する限界に関して、流れ方向(低減された限界がインバウンド・トラフィック、アウトバウンド・トラフィック、または、両方に適用されるべきか)が要素2032を介して示されてもよい。新しい限界が適用されるべき時間範囲(例えば、開始時間、終了時間、または、両方)は要素2035を介して示されてもよい。リクエストされた限界値(または、現在の限界が低減されるべき程度)は、図示する実施形態では要素2038を介して示されてもよい。例えば、要素2038は、新しい限界に対して絶対値を特定する代わりに、現在の帯域幅限界が25%だけ低減されるべきと示してもよい。幾つかの実施では、新しい限界を示す場合、クライアントは使用されるべき測定アプローチの態様を示してもよく、例えば、平均的帯域幅限界への変化がリクエストされる場合、平均が計算されるべき時間期間が特定され、より低いピーク帯域幅がリクエストされた場合、ピーク帯域幅が定量化されるべき時間期間が特定されてもよい。少なくとも幾つかの実施形態では、低減された限界を特定することに加えて、クライアント2010はそれぞれの作用がネットワーク構成サーバー180によって行われる、要素2041を介して限界に対して一つ以上の閾値を定めてもよい。例えば、クライアント2010は、計算インスタンスへのまたはからの測定されたトライフィック率がクライアント・リクエストされた帯域幅限界の80%を超えた場合に通知されることを望む。幾つかの実施では、リクエストは、閾値に到達したときに通知が提供されるべき一つ以上の宛先(例えば、電子メールアカウント)の表示を含んでもよい。それぞれの作用が行われる幾つかの異なる閾値が幾つかの実施において示されてもよい。例えば、帯域幅の80%では通知が生成され、100%ではサービスがパケットをドロップするか破棄し始めることが許可される。幾つかのパケットを送信する代わりに一時的に待ち行列に入れる、限界を一時的に緩和するおよび/または増加する等、他の応答作用が、幾つかの実施形態において、クライアントの明確なリクエストに応じて、または、サービス主導で行われ得る。
【0091】
リクエスト2020を受信することに応答して、NCS180は、リクエストするクライアントに変化の承認2050を提供し、リクエストされた限界を適用するよう適当な構成の変化を開始する。例えば、低減された帯域幅限界がインスタンス・ホストで実施された計算インスタンスに適用されるべきシナリオでは、NCS180はインスタンス・ホストにおいて
図3に例示されるスタック310と同様の仮想化管理ソフトウェア・スタックのコンポーネントに新しい限界を送信してもよい。幾つかの実施形態では、NCS180は、承認2050を送る前に、構成の変化が約束されるまで待ってもよい。
【0092】
資源使用限界の低減は、仮想コンピューティング・サービス、様々なタイプのストレージ・サービス、データベース・サービス等、幾つかの実施形態において複数のネットワーク・アクセス可能サービスのいずれかのインスタンスに対してリクエストされてもよい。幾つかの実施形態では、低減された資源使用限界値を直接示す代わりに、クライアントはある示された時間期間中に満たされるべき資源予算限界を示してもよい。それに応答して、ネットワーク構成サービスは、クライアントのサービス・インスタンスの資源使用を監視し、対応する請求金額を(例えば、関連するサービスの請求管理コンポーネントと通信することで)確定してもよい。予算限界に近い閾値(または予算限界自体)が到達されると、クライアントは通知されてもよくおよび/または一つ以上の応答作用が行われてもよい。そのため、資源予算限界は、少なくとも幾つかの実施形態において資源使用限界と類似して処理されてもよい(またはそれに置換されてもよい)。少なくとも幾つかの実施形態において、資源使用限界におけるクライアント・リクエストされた低減をサポートする構成サーバーは、
図1のNCS180に関して前述した機能の少なくとも幾つかを実施する必要がないことに注意する。例えば、使用減少リクエスト2020に応答する構成サーバーは、
図7と同様の手順グラフや
図5と同様の分類ツリーを必ずしも生成する必要がない。
【0093】
上述したように、少なくとも幾つかの実施形態では、所与の請求可能なクライアント・アカウント、例えば、社員がプロバイダ・ネットワークの一つ以上のネットワーク・アクセス可能サービスを使用する組織またはエンティティのために確立されたアカウントは、それと関連する幾つかの異なるユーザ・アカウントまたはグループ・アカウントを有してもよい。このような実施形態では、別個の資源使用限界が異なるユーザまたはグループに対して設定されてもよい。
図21は、少なくとも幾つかの実施形態による、ネットワーク・アクセス可能サービスのクライアント・アカウント2104Aに対する全体的な資源使用限界設定2110の確立、および、ユーザ・グループ、個人ユーザ、および、リンク付けされたアカウントに対する関連する資源使用限界設定の確立の実施例を例示する。図示するように、クライアント・アカウント2104Aは、ユーザ・グループ2120Aおよび2120B等の、一つ以上の関係するグループ・アカウント2120が定められている。各グループは、グループ2120Bのユーザ・アカウント2123Kおよび2123L等、複数のユーザ・アカウント2123を有してもよい。幾つかのユーザ・アカウント、例えば、2123A、2123B、および、2123Cはどのユーザ・グループに属さなくてもよい。
【0094】
図示する実施形態では、全体的な資源使用限界2110(例えば、帯域幅限界)は、様々なグループ・アカウント2120およびユーザ・アカウント2123等、クライアント・アカウント2104Aと関係するアカウント全てに対して確定されてもよい。アカウント2104B等の一つ以上の追加的なクライアント・アカウントは、例えば、総合請求または他の目的のためにクライアント・アカウント2104Aとリンク付けされてもよい。一つの模範的なシナリオでは、クライアント・アカウント2104Aはプロバイダ・ネットワーク資源を用いて特定のアプリケーションを実施する組織O1に対してセットアップされる一方で、クライアント・アカウント2104BはO1とパートナーとなる或いはO
1によって実施されるアプリケーションを利用する異なる組織O2に対してセットアップされ得る。二つのクライアント・アカウントがセットアップされるエンティティの好みにより、全体的な資源使用限界2110もリンク付けされたユーザ・アカウントに適用され得る。少なくとも幾つかの実施形態では、所与の時間期間にわたる全てのユーザ、グループ、および、リンク付けされたアカウントの測定された資源使用は、例えば、使用限界総和ポリシー2190に応じて、当該期間中、親クライアント・アカウント2104Aに適用される全体的な資源使用限界を超えてはならない。
【0095】
幾つかの実施形態では、異なるユーザ、グループ、または、リンク付けされたアカウントに対して明確な資源使用限界がリクエストされてもよい。例えば、グループ2120Aおよび2120Bには、それぞれの限界2150Aおよび2150Bが割り当てられ、ユーザ2123A、2123B、2123K、および、2123Lには、それぞれの限界2160A、2160B,2160K、および、2160Lが割り当てられる。何人かのユーザ(例えば、2123C)および/またはグループはそれぞれの限界が定められていない場合があり、その場合、その親グループの限界および/またはクライアント・アカウントの限界が適用され得る。リンク付けされたアカウント2104Bには、独自の資源使用限界2170は定められ、これはリンク付けされたアカウント内で定められるユーザおよび/またはグループにも適用され得る。
図21に例示される資源使用限界に関して、クライアント・アカウント2104Aは「親」エンティティと考えられ、グループ、ユーザ、および、リンク付けされたアカウントは「子孫」エンティティと考えられる。
図21に示される異なる粒度またはレベルのいずれかで適用される資源使用限界における低減は、例えば、
図20のリクエスト2020と同様のリクエストを介して、少なくとも幾つかの実施形態において要請されてもよい。リクエストされた低減が親エンティティ(例えば、クライアント・アカウント2104A)に適用される場合、子孫エンティティに課せられる限界に対する低減の影響は使用限界総和ポリシー2190に示され得る。例えば、一実施形態では、全体として帯域幅における10%の低減がクライアント・アカウントにリクエストされた場合、クライアント・アカウントから由来する各ユーザまたはグループに適用されるべき帯域幅限界も一つの選択されたポリシー2190に応じて10%だけ低減され得る。別のポリシー2190によると、(a)任意の所与の子孫の限界が親の限界を超えない、且つ、(b)所与の時間期間にわたる全ての子孫ノードの実際の資源使用の総和が親の限界を超えない限り、子孫の限界は変更が明確にリクエストされない限り変更されてはならない。
クライアント・リクエストされた資源使用限界を低減する方法
【0096】
図22は、少なくとも幾つかの実施形態による、クライアントがネットワーク・アクセス可能サービスの一つ以上のノードに対する資源使用限界を低減することを可能にするよう実施される動作の態様を例示する。要素2201に示すように、一つ以上のプログラマチック・インターフェイスが実施されると、ネットワーク・アクセス可能サービス(プロバイダ・ネットワークで実施されるマルチテナント仮想コンピューティング・サービス等)のクライアントは資源使用限界の低減を、資源使用限界が適用される一つ以上のサービス・インスタンスについてリクエストすることができる。プログラマチック・インターフェイスは、例えば、ウェブページまたはウェブサイト、一つ以上のAPI、GUI、または、コマンド・ライン・ツールを含んでもよい。
【0097】
限界低減リクエストは、例えば、ネットワーク構成サーバーにおいて、プログラマチック・インターフェイスの一つを介して受信されてもよい(要素2204)。限界低減リクエストは、
図20に示すリクエスト2020の構成要素の何らかの組み合わせ等、適用されるべき新しい限界に関して様々な構成要素を有してもよい。低減された限界が適用されるべき特定のクライアント・アカウント、トラフィック・カテゴリー、サービス・インスタンス、および/または、時間期間がリクエストに示されてもよい。適当な構成の変化は
、リクエストに応じてなされてもよく、例えば、限界が計算インスタンスに適用されるべきシナリオでは、影響されるインスタンス・ホストにおける仮想化ソフトウェア・コンポーネントが新しい限界に関して通知されてもよい。資源使用メトリックスは、時間をかけてターゲットとされたサービス・インスタンスから取得されてもよい(要素2207)。測定された資源使用が閾値(閾値が新しく適用された限界について定められ得る)に到達したとの検出に応答して、通知が(例えば、低減された限界のリクエスタに対して、または、リクエスタによって示される一つ以上の指定された通知ターゲットに対して)生成される(要素2210)。幾つかの実施形態では、他の作用が閾値に到達したとの検出に応答して行われる。例えば、資源使用限界が帯域幅に適用される場合、一つ以上のパケットがドロップされるか待ち行列に入れられ、幾つかのケースでは、限界が一時的に緩和される。幾つかのケースでは、このような使用限界の緩和は、警告メッセージに伴われる(例えば、クライアントは、限界が一時的に緩和されるが、持続的にまたは繰り返し限界または閾値を超えることはデータ損失につながると警告されてもよい)。少なくとも幾つかの実施形態では、一つ以上のこのような閾値および/または対応する応答作用は、使用限界の低減をリクエストしたクライアントによって示される。
【0098】
図23は、少なくとも幾つかの実施形態による、クライアントが分散システムのノードにおいて資源使用限界と関連付けられるクエリーを出すことを可能にするよう実施される動作の態様を例示する。要素2301に示されるように、一つ以上のプログラマチック・インターフェイスが様々なタイプのクエリーに対して実施されてもよい。幾つかのクライアントは、例えば、現在利用可能な限界に対して資源使用の現在の状態またはメトリックを確定することを望むことがある。別のシナリオでは、クライアントは、一つ以上の特定されたサービス・インスタンスにおいて経時的な資源使用における変化に関する傾向情報を取得することを望むことがあり、それにより、例えば、クライアントは資源使用限界がいつ変えられるべきかを予想することができる。更に別のシナリオでは、資源使用に関する予算ベースのクエリーがネットワーク構成サーバーによってサポートされてもよく、例えば、クライアントは幾つかのサービス・インスタンスに関してネットワークに対するターゲット予算限界を示し、クライアントのコストを予算内で維持することを助け得る帯域幅限界に対する変更を推奨するリクエストを出してもよい。クエリーは、プログラマチック・インターフェイスの一つを介してクライアントから受信されてもよい(要素2304)。クエリーのタイプにより、クエリーが適用されるサービス・インスタンスから収集されるメトリックスに基づいて異なる作用が取られ得る。
【0099】
クエリーが資源使用の現在の状態に関係する場合(要素2310)、資源使用の最近の測定とサービス・インスタンスにおける適用可能な限界との間の差を示す応答が提供される(要素2351)。傾向クエリーが受信されると(要素2313)、選択された時間間隔にわたる資源使用の変動を示す応答が提供される(要素2354)。予算ベースの推奨クエリーが受信されると(要素2316)、ネットワーク構成サーバーは、クライアントが予算目標を実現することを可能にする一つ以上の使用限界低減を確定するのに必要な計算を実施し、計算の結果をクエリー応答で提供してもよい(要素2357)。幾つかの実施形態では、他のタイプのクエリーがサポートされてもよい。
【0100】
様々な実施形態において、
図10、
図11、
図12、
図13、
図18、
図22、および、
図23のフロー図で例示される動作以外の動作が、記載するネットワーク構成の機能性の様々な態様を実施するために使用され得、図示する動作の幾つかが実施されず、或いは、順次的でなく異なる順序でまたは並列に実施されてもよいことに注意する。例えば、幾つかの実施形態では、マルチスレッドNCSが実施されてもよく、この場合、
図10に示す動作の幾つかのストリームが並列に実行され、それぞれのターゲット・ノードに対する分類メタデータのそれぞれのセットが生成され送信される。
使用ケース
【0101】
分散システムの多数のノードでネットワーク・トラフィックをシェーピングし、ヒートマップ・ベースの資源可視化能力を提供し、資源使用限界におけるクライアント・リクエストされた低減を可能にするためにネットワーク構成サーバーの中央化セットを確立する上述の技術は、幾つかのシナリオで有用である。例えば、プロバイダ・ネットワークは幾つかのデータ・センター間で分散される数百の、或いは、数千のインスタンス・ホストおよび多数のネットワーク装置を有してもよく、プロバイダ・ネットワークの収益の少なくとも一部分はインスタンス・ホストに流入するまたは流出するネットワーク・トラフィックの量に基づいて導出される。ネットワーク管理決定を行うために各インスタンス・ホストまたはネットワーク装置でローカル・モジュールを用いることは、このような大きな環境では幾つかの問題を生ずる。第一に、所与のインスタンス・ホストで知的ネットワーク管理決定を行うのに必要な全ての入力を取得することが可能でないこともある。第二に、インスタンス・ホストで要求される決定論理の複雑性は、インスタンス・ホストの相当量の計算能力を必要とし、これは、クライアント・リクエストされたサービス・インスタンスに対して残されるコンピューティング能力を減少し得る。ネットワーク管理論理が変更される必要がある場合、全てのインスタンス・ホストに変更が送信され適用されなくてはならず、これ自体が資源集約的な且つエラーを起こしやすいエクササイズである。
【0102】
反対に、トラフィック・シェーピングに使用されるべき決定論理を幾つかのネットワーク構成サーバーに隔離することで、より大きなセットのソースからの入力が収集され、より情報を得た上での決定が下され得る。ネットワーク構成サーバーは、コンピューティング能力へのコンテンションを回避しながら、他のサービスと共有される必要がない専用のコンピューティング資源を用いて実施されてもよい。ネットワーク構成論理への更新は、数百或いは数千のインスタンス・ホストが更新される場合よりも、より簡単に適用され得る。中央化ネットワーク構成サービスは、さもなければ取得することが難しいネットワーク・ステータス(構成可能なヒートマップを含む)の統一ビューをクライアントに簡単に提供することができる。特定されたサービス・インスタンス、ユーザ・アカウント、または、グループ・アカウントに対してプログラムで資源使用限界を低減させる能力は、予算を制御しようとするクライアントには有用である。
【0103】
本開示の実施形態は、以下の付記を考慮して説明され得る。
1.プロバイダ・ネットワークのマルチテナント・ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことを少なくとも時間間隔中にクライアントがリクエストすることを可能にする一つ以上のプログラマチック・インターフェイスを実施し、該低資源使用限界が資源使用依存価格決定ポリシーでネットワーク・トラフィックの少なくとも一つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介して、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベルに到達したとの確定に応答して、通知の生成を含む一つ以上の応答作用を開始するよう構成される、複数のコンピューティング装置を備えるシステム。
2.該特定の低資源使用限界は、(a)超えられてはならない平均的トラフィック送信速度、(b)超えられてはならないピーク・トラフィック送信速度、(c)転送されたデータのバイト数に対する上限、または、(d)転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、付記1記載のシステム。
3.該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワーク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、(a)一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、(b)プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、(c)二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、(d)該特定のサービス・インスタンスと該プロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネットワーク・トラフィックの複数のカテゴリーから選択される、付記1記載のシステム。
4.該クライアント・リクエストは、(a)該特定のサービス・インスタンスから一つ以上の宛先に流れるトラフィック、(b)一つ以上のソースから該特定のサービス・インスタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用されるネットワーク・トラフィック・フローの一つ以上の方向を示す、付記1記載のシステム。
5.該クライアント・リクエストは、該マルチテナント・ネットワーク・アクセス可能サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適用される、付記1記載のシステム。
6.複数のコンピューティング装置により、
ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことをクライアントがリクエストすることを可能にするプログラマチック・インターフェイスを実施し、該低資源使用限界がサービスと関連付けられるネットワーク・トラフィックの少なくとも一つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介して、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始する、方法。
7.該特定の低資源使用限界は、(a)超えられてはならない平均的トラフィック送信速度、(b)超えられてはならないバースト・トラフィック送信速度、(c)転送されたデータのバイト数に対する上限、または、(d)転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、付記6記載の方法。
8.該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワーク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、(a)一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、(b)プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、(c)二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、(d)該サービスのノードと該プロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネットワーク・トラフィックの複数のカテゴリーから選択される、付記6記載の方法。
9.該クライアント・リクエストは、(a)該特定のサービス・インスタンスから一つ以上の宛先エンドポイントに流れるトラフィック、(b)一つ以上のソースから該特定のサービス・インスタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用されるネットワーク・トラフィック・フローの一つ以上の方向を示す、付記6記載の方法。
10.該クライアント・リクエストは、マルチテナント・ネットワーク・アクセス可能
サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適用される、付記6記載の方法。
11.該一つ以上の応答作用は、(a)一つ以上のパケットを破棄する、(b)一つ以上のパケットを待ち行列に入れる、または、(c)該特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる資源使用限界を特定の時間期間にわたって増加させることのいずれかを含む、付記6記載の方法。
12.前記一つ以上のコンピューティング装置により、更に、
該特定のサービス・インスタンスにおいてネットワーク・トラフィックと関連付けられる測定された資源使用をクライアントが確定することを可能にする異なるプログラマチック・インターフェイスを実施し、
該異なるプログラマチック・インターフェイスを介して受信されるリクエストに応答して、該測定された資源使用の表示を提供する、付記6記載の方法。
13.該クライアント・リクエストは、該特定の低資源使用限界が課せられる時間期間の表示を含む、付記6記載の方法。
14.該クライアント・リクエストは、(a)閾値レベル、または、(b)該一つ以上の応答作用のうちの特定の応答作用の一方の表示を含む、付記6記載の方法。
15.該ネットワーク・アクセス可能サービスは、プロバイダ・ネットワークのインスタンス・ホストを用いて実施され、該方法は、
該一つ以上のコンピューティング装置により、更に、
該プロバイダ・ネットワークの中央化ネットワーク構成サービスの特定のサーバーにおいて、特定されたサービス・インスタンスにおけるそれぞれの低資源使用限界に対する複数のクライアント・リクエストを受信し、
該特定されたサービス・インスタンスのそれぞれのインスタンス・ホストでインスタンス化されたそれぞれの制御モジュールに該特定のサーバーから該それぞれの低資源使用限界の表示を送信することを含む、付記6記載の方法。
16.一つ以上のプロセッサで実行されると、
プログラマチック・インターフェイスを介して、ネットワーク・アクセス可能サービスの特定のインスタンスにおいてネットワーク・トラフィックの少なくとも一つのカテゴリーに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のインスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
該特定のインスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始するプログラム命令を記憶する非一過性コンピュータ・アクセス可能記憶媒体。
17.該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの第一および第二のインスタンスにおいてネットワーク・トラフィックに集合的に課せられる組み合わされた資源使用限界を示す異なるクリアント・リクエストを受信し、
該第一および第二のインスタンスにおけるネットワーク・トラフィックと関連付けられる該資源使用の総和が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始する、付記16記載の非一過性のコンピュータ・アクセス可能記憶媒体。
18.該ネットワーク・アクセス可能サービスは、(a)仮想コンピューティング・サービス、(b)ストレージ・サービス、または、(c)データベース・サービスのいずれかを有する、付記16記載の非一過性のコンピュータ・アクセス可能記憶媒体。
19.該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの異なるインスタンスにおいて資源をネットワークすることに対するクライアント予算の上界を示す異なるクリアント・リクエストを
受信し、
該異なるインスタンスにおける資源をネットワークすることと関連付けられるクライアント請求金額が閾値を超えたとの確定に応答して、一つ以上の応答作用を開始する、付記16記載の非一過性のコンピュータ・アクセス可能記憶媒体。
20.該特定の低資源使用限界は、(a)超えられてはならない平均的トラフィック送信速度、(b)超えられてはならないバースト・トラフィック送信速度、(c)転送されたデータのバイト数に対する上限、または、(d)転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、付記16記載の非一過性のコンピュータ・アクセス可能記憶媒体。
21.プロバイダ・ネットワークの複数のクライアント・アカウントにアクセス可能な少なくとも一つのマルチテナント・ネットワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・メトリックスを含み、複数のソースからメトリックスを取得し、
少なくとも(a)該ノードのセットの第一のノードおよび第二のノードが割り当てられるそれぞれのクライアント・アカウント間の関係、および、(b)該第一のノードと該第二のノードとの間の一つ以上のネットワーク・リンクを示すネットワーク・トポロジーを確定し、
該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを含む、該ネットワーク・トポロジーの複数のネットワーク性能インジケータの表現を生成し、
プログラマチック・インターフェイスを介して受信されるリクエストに応答して表示されるカスタマイズ可能な資源ヒートマップに含まれるよう該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを提供するよう構成される一つ以上のコンピューティング装置を備える、システム。
22.該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける測定されたネットワーク・トラフィック率と、該マルチテナント・ネットワーク・アクセス可能サービスのために構成されるネットワーク構成サーバーにより該第一のノードについて確定される帯域幅限界との間の比の表示を有する、付記21記載のシステム。
23.該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは(a)エンドポイント・アドレス、(b)エンドポイント・アドレスと関連付けられるクライアント・アカウント、または、(c)ネットワーク・トラフィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうちの別のカテゴリーと異なる、付記21記載のシステム。
24.該一つ以上のコンピューティング装置は、
(a)ポートレベルの粒度、(b)ネットワーク・インターフェイス・レベルの粒度、(c)バーチャル・マシン・レベルの粒度、(d)ホスト・レベルの粒度、(e)ラックレベルの粒度、(f)データ・センター・ルーム・レベルの粒度、(g)データ・センター・レベルの粒度、(h)利用可能コンテナレベルの粒度、または、(i)地理的領域レベルの粒度のうちの一つを有する、カスタマイズ可能な資源ヒートマップに表示される一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該カスタマイズ可能なヒートマップに含まれるよう一つ以上の収集されたメトリックスを統合するよう更に構成される、付記21記載のシステム。
25.該プログラマチック・インターフェイスを介して受信される該リクエストに応答して、該一つ以上のコンピューティング装置は、
該リクエストの要請側の許可設定を取得し、
該許可設定に少なくとも部分的に基づいて、該カスタマイズ可能な資源ヒートマップに表される収集された資源メトリックスのサブセットを選択するよう更に構成される、付記
21記載のシステム。
26.一つ以上のコンピューティング装置により、
プロバイダ・ネットワークの一つ以上のクライアント・アカウントの代わりにネットワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・メトリックスを含むメトリックスをプロバイダ・ネットワークの複数のソースから取得し、
該ノードのセットの第一のノードと第二のノードとの間の一つ以上の関係を表すネットワーク・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう該第一のノードと該第二のノードの、メトリックスの一部分から少なくとも部分的に導出されるそれぞれのネットワーク性能インジケータを提供する、方法。
27.該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅限界との間の比の表示を有する、付記26記載の方法。
28.該資源ヒートマップは、(a)該第一のノードのプロセッサ性能インジケータ、(b)該第一のノードのストレージ性能インジケータ、または、(c)該第一のノードのメモリ性能インジケータのいずれかを有する、付記26記載の方法。
29.該第一のノードの該ネットワーク性能インジケータは、測定されたネットワーク待ち時間と、該第一のノードと関連付けられるトラフィックに対するネットワーク待ち時間の上界との間の比の表示を有する、付記26記載の方法。
30.該資源ヒートマップはリクエストに応答して生成され、
該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは(a)エンドポイント・アドレス、(b)エンドポイント・アドレスと関連付けられるクライアント・アカウント、または、(c)ネットワーク・トラフィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうちの別のカテゴリーと異なる、付記26記載の方法。
31.該一つ以上のコンピューティング装置により、
クライアントがネットワーク・トラフィックの一つ以上のカテゴリーを定めるよう異なるプログラマチック・インターフェイスを実施し、
該特定のカテゴリーの定義を該異なるプログラマチック・インターフェイスを介して受信する、付記30記載の方法。
32.該一つ以上のコンピューティング装置により、
(a)ポートレベルの粒度、(b)ネットワーク・インターフェイス・レベルの粒度、(c)バーチャル・マシン・レベルの粒度、(d)ホスト・レベルの粒度、(e)ラックレベルの粒度、(f)データ・センター・ルーム・レベルの粒度、(g)データ・センター・レベルの粒度、(h)利用可能コンテナレベルの粒度、または、(i)地理的領域レベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよう一つ以上のメトリックスを統合する、付記26記載の方法。
33.該一つ以上のコンピューティング装置により、
該資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された収集時間期間の表示を受信し、
該選択された収集時間期間に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよう該一つ以上のメトリックスを統合する、付記26記載の方法。
34.該複数のソースは、(a)ネットワーク・インターフェイス・カード、(b)仮想化ホストにインストールされる仮想化ソフトウェア・スタックのネットワーク・コンポーネント、(c)仮想化されたコンピューティング・サービスの計算インスタンスのネッ
トワーク・コンポーネント、(d)ネットワーク・タップ装置、(e)スイッチ、(f)ルーター、(g)ゲートウェイ、または、(h)ロード・バランサのうち一つ以上有する、付記26記載の方法。
35.該ネットワーク・アクセス可能サービスは、(a)仮想コンピューティング・サービス、(b)ストレージ・サービス、または、(c)データベース・サービスのいずれかを有する、付記26記載の方法。
36.一つ以上のプロセッサで実行されると、
複数のクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・メトリックスを含む、メトリックスを複数のソースから取得し、
(a)該ノードのセットのうちの第一のノードおよび第二のノードが割り当てられるそれぞれのクライアント・アカウント間の関係、または、(b)該第一のノードと該第二のノードとの間の一つ以上のネットワーク・リンクの少なくとも一方を表すネットワーク・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう、該メトリックスの一部分から少なくとも部分的に導出される、該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを提供する、プログラム命令を記憶する非一過性コンピュータ・アクセス可能記憶媒体。
37.該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅限界との間の比の表示を有する、付記16記載の非一過性コンピュータ・アクセス可能記憶媒体。
38.命令は、該一つ以上のプロセッサで実行されると、
トラフィック・フィルタリング基準の表示を受信し、
該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーが(a)エンドポイント・アドレス、(b)エンドポイント・アドレスと関連付けられるクライアント・アカウント、または、(c)ネットワーク・トラフィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうちの別のカテゴリーと異なる、付記36記載の非一過性コンピュータ・アクセス可能記憶媒体。
39.命令は、該一つ以上のプロセッサで実行されると、
(a)ポートレベルの粒度、(b)ネットワーク・インターフェイス・レベルの粒度、(c)バーチャル・マシン・レベルの粒度、(d)ホスト・レベルの粒度、(e)ラックレベルの粒度、(f)データ・センター・ルーム・レベルの粒度、(g)データ・センター・レベルの粒度、(h)利用可能コンテナレベルの粒度、または、(i)地理的領域レベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよう一つ以上のメトリックスを統合する、付記36記載の非一過性コンピュータ・アクセス可能記憶媒体。
40.命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスのクライアントが少なくとも該メトリックスのサブセットをリクエストするようプログラマチック・インターフェイスを実施し、
該プログラマチック・インターフェイスを介して特定のクライアントからメトリック・リクエストを受信し、
該メトリック・リクエストに示される一つ以上のメトリックスを取得する許可が該特定のクライアントに与えられているとの確定に応答して、該特定のクライアントに該一つ以上のメトリックスを提供する、付記36記載の非一過性コンピュータ・アクセス可能記憶
媒体。
例示的コンピュータ・システム
【0104】
少なくとも幾つかの実施形態では、ネットワーク構成サーバー、ネットワーク構成サービス・マネージャ、トポロジー可視化サーバー、および/または、インスタンス・ホストを実施する技術を含む、本願記載の一つ以上の技術の一部または全部を実施するサーバーは、一つ以上のコンピュータ・アクセス可能媒体を含む或いは該媒体にアクセスするよう構成される汎用コンピュータ・システムを含んでもよい。
図24は、汎用コンピューティング装置3000を示す。例示する実施形態では、コンピューティング装置3000は、入力/出力(I/O)インターフェイス3030を介してシステム・メモリ3020に接続される一つ以上のプロセッサ3010を含む。コンピューティング装置3000は、更に、I/Oインターフェイス3030に接続されるネットワーク・インターフェイス3040を含む。
【0105】
様々な実施形態では、コンピューティング装置3000は、一つのプロセッサ3010を含むユニ・プロセッサ・システム、または、幾つかのプロセッサ3010(例えば、二つ、四つ、八つ、または、別の好適な数)を含むマルチプロセッサ・システムでもよい。プロセッサ3010は、命令を実行することができる任意の好適なプロセッサでもよい。例えば、様々な実施形態では、プロセッサ3010は、x86、PowerPC、SPARC、または、MIPS ISA、或いは、任意の他の好適なISA等、様々なインストラクション・セット・アーキテクチャ(ISA)のいずれかを実施する汎用の或いは組み込みプロセッサでもよい。マルチプロセッサ・システムでは、各プロセッサ3010は、必ずではないが、同じISAを一般的に実施してもよい。幾つかの実施では、グラフィックス・プロセッシング・ユニット(GPU)が従来のプロセッサの代わりに、或いは、それに加えて使用されてもよい。
【0106】
システム・メモリ3020は、プロセッサ3010によってアクセス可能な命令およびデータを記憶するよう構成されてもよい。様々な実施形態では、システム・メモリ3020は、スタティック・ランダム・アクセス・メモリ(SRAM)、同期型ダイナミックRAM(SDRAM)、不揮発性/フラッシュ・タイプ・メモリ、または、任意の他のタイプのメモリ等、任意の好適なメモリ技術を用いて実施されてもよい。例示する実施形態では、上述の方法、技術、および、データ等、一つ以上の所望の機能を実施するプログラム命令およびデータは、コード3025およびデータ3026としてシステム・メモリ3020内に記憶されるとして示される。
【0107】
一実施形態では、I/Oインターフェイス3030は、プロセッサ3010、システム・メモリ3020、および、ネットワーク・インターフェイス3040や他の周辺インターフェイス、例えば、データ・オブジェクト・パーティションの物理的レプリカを記憶するために使用される様々なタイプの永続性および/または揮発性ストレージ装置を含む、装置における任意の周辺装置の間のI/Oトラフィックを調整するよう構成されてもよい。幾つかの実施形態では、I/Oインターフェイス3030は、任意の必要なプロトコル、タイミングまたは他のデータ変換を実施して、一つのコンポーネント(例えば、システム・メモリ3020)からのデータ信号を別のコンポーネント(例えば、プロセッサ3010)による使用に好適なフォーマットに変換してもよい。幾つかの実施形態では、I/Oインターフェイス3030は、例えば、ペリフェラル・コンポーネント・インターコネクト(PCI)バス規格またはユニバーサル・シリアル・バス(USB)規格の変形例等、様々なタイプの周辺機器用バスを介して取り付けられる装置に対するサポートを含んでもよい。幾つかの実施形態では、I/Oインターフェイス3030の機能は、例えば、ノース・ブリッジおよびサウス・ブリッジ等の二つの以上の別個の構成要素に分けられてもよい。更に、幾つかの実施形態では、システム・メモリ3020へのインターフェイス等
、I/Oインターフェイス3030の機能性の幾つかまたは全てがプロセッサ3010に直接組み込まれてもよい。
【0108】
ネットワーク・インターフェイス3040は、コンピューティング装置3000と、例えば、
図1乃至
図23に例示される他のコンピュータ・システムまたは装置等のネットワークまたは複数のネットワーク3050に取り付けられる他の装置3060との間のデータ交換を可能にするよう構成されてもよい。様々な実施形態では、ネットワーク・インターフェイス3040は、例えば、イーサネット(登録商標)・ネットワークのタイプ等、全ての好適な有線または無線の総合データ・ネットワークを介して通信をサポートしてもよい。追加的には、ネットワーク・インターフェイス3040は、アナログ音声ネットワークまたはデジタル・ファイバー通信ネットワーク等の電気通信/電話技術ネットワークを介して、ファイバー・チャネルSAN等のストレージ・エリア・ネットワークを介して、または、全ての他の好適なタイプのネットワークおよび/またはプロトコルを介して通信をサポートしてもよい。
【0109】
幾つかの実施形態では、システム・メモリ3020は、対応する方法および装置の実施形態を実施するための、
図1乃至
図23について上述したようなプログラム命令およびデータを記憶するよう構成されるコンピュータ・アクセス可能媒体の一実施形態でもよい。しかしながら、他の実施形態では、プログラム命令および/またはデータは、異なるタイプのコンピュータ・アクセス可能媒体で受信され、送信され、または、記憶されてもよい。一般的に、コンピュータ・アクセス可能媒体は、例えば、I/Oインターフェイス3030を介してコンピューティング装置3000に接続されるディスクまたはDVD/CD等の磁気的または光学的媒体を含む、非一過性ストレージ媒体またはメモリ媒体を含んでもよい。非一過性コンピュータ・アクセス可能ストレージ媒体は、システム・メモリ3020または他のタイプのメモリとして、コンピューティング装置3000の幾つかの実施形態において含まれ得る、RAM(例えば、SDRAM、DDR、SDRAM、RDRAM、SRAM等)、ROM等の全ての揮発性または不揮発性媒体を含んでもよい。更に、コンピュータ・アクセス可能媒体は、ネットワーク・インターフェイス3040を介して実施され得る、ネットワークおよび/または無線リンク等の通信媒体を介して運ばれる電気的、電磁的、または、デジタルの信号を含む送信媒体または信号を含んでもよい。
図24に例示されるような多数のコンピューティング装置の一部または全てが様々な実施形態において説明した機能性を実施するために使用されてもよく、例えば、様々な異なる装置やサーバーで実行されるソフトウェア・コンポーネントが協調して機能性を提供してもよい。幾つかの実施形態では、説明した機能性の一部分は、汎用コンピュータ・システムを用いて実施されることに加えて、または、その代わりに、ストレージ装置、ネットワーク装置、または、特殊目的コンピュータ・システムを用いて実施されてもよい。本願で使用される「コンピューティング装置」といった用語は、少なくともこれらのタイプの装置全てを含み、これらのタイプの装置に制限されない。
結論
【0110】
様々な実施形態は、更に、前述の説明に応じて実施される命令および/またはデータをコンピュータ・アクセス可能媒体で受信し、送信し、または、記憶することを含む。一般的に、コンピュータ・アクセス可能媒体は、磁気的または光学的媒体、例えば、ディスクまたはDVD/CD-ROM、RAM(例えば、SDRAM、DDR、RDRAM、SRAM等)等の揮発性または不揮発性媒体、ROM等を含むストレージ媒体またはメモリ媒体、並びに、ネットワークおよび/または無線リンク等の通信媒体を介して運ばれる電気的、電磁的、または、デジタルの信号等の送信媒体または信号を含んでもよい。
【0111】
図中に例示され、本願に記載される様々な方法は、方法の模範的な実施形態を示す。該方法は、ソフトウェア、ハードウェア、または、その組み合わせにおいて実施されてもよ
い。方法の順序は変更されてもよく、様々な要素が追加される、再順序付けされる、組み合わされる、省略される、変更されるなどされてもよい。
【0112】
本開示の恩恵を得る当業者には明らかであるように、様々な変更および変化がなされてもよい。これらの変更および変化全てを包含することが意図され、それに応じて、上述の説明は限定的でなく例示的として考えられるべきである。