(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-08-02
(45)【発行日】2022-08-10
(54)【発明の名称】分散システムにおける集中ネットワーク構成
(51)【国際特許分類】
H04L 41/0894 20220101AFI20220803BHJP
H04L 41/0823 20220101ALI20220803BHJP
【FI】
H04L41/0894
H04L41/0823
(21)【出願番号】P 2020108579
(22)【出願日】2020-06-24
(62)【分割の表示】P 2018178867の分割
【原出願日】2014-11-04
【審査請求日】2020-07-27
(32)【優先日】2013-11-04
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2013-11-04
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】507303550
【氏名又は名称】アマゾン・テクノロジーズ・インコーポレーテッド
(74)【代理人】
【識別番号】100098394
【氏名又は名称】山川 茂樹
(74)【代理人】
【識別番号】100064621
【氏名又は名称】山川 政樹
(72)【発明者】
【氏名】リザック,アヴィチャイ・メンドル
【審査官】野元 久道
(56)【参考文献】
【文献】特開2008-219149(JP,A)
【文献】特開2003-283552(JP,A)
【文献】特表2013-535171(JP,A)
【文献】米国特許出願公開第2011/0317557(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 41/40
(57)【特許請求の範囲】
【請求項1】
分散計算環境の構成サーバから前記分散計算環境の第1のノードに、ネットワークパケットに適用されるべ
きカスタマイズされたトラフィック分類規則
の少なくとも第1のセットを提供するステップであって、
前記第1のセットの特定
のトラフィック分類規則は、前記ネットワークパケットのヘッダコンテンツに少なくとも部分的に基づいて
おり、前記分散計算環境の第2のノードのためにカスタマイズされたトラフィック分類規則の少なくとも第2のセットとは異なるようにカスタマイズされている、ステップと、
前記構成サーバから前記分散計算環境の
前記第2のノードに
、カスタマイズされたトラフィック分類規則
の少なくとも前記第2のセットを提供するステップであって、前記第2のセットは、前記第1のセットと異なる、ステップと、
前
記カスタマイズされたトラフィック分類規則
の前記第1のセットに少なくとも部分的に基づいて、前記第1のノードにおいて第1のネットワークパケットの送信を開始するステップと、
前
記カスタマイズされたトラフィック分類規則
の前記第2のセットに少なくとも部分的に基づいて、前記第2のノードにおいて第2のネットワークパケットの送信を開始するステップと、
を備え
、
前記カスタマイズは、1つまたは複数のネットワーク構成オプションを変更することを含む
方法。
【請求項2】
前記構成サーバから前記第1のノードに、前
記カスタマイズされたトラフィック分類規則
の前記第1のセットに示された第1のトラフィックカテゴリのトラフィックに対する性能制約の指示を提供するステップ
を更に備え、前記第1のネットワークパケットの前記送信は、前記性能制約が前記送信によって妨害されないであろうと判断することに少なくとも部分的に基づいている
、
請求項1に記載の方法。
【請求項3】
前記構成サーバにおいて、前記第1のノードから
ネットワーク構成オプションの構成要求を受信するステップ
を更に備え、前
記カスタマイズされたトラフィック分類規則
の前記第1のセットを前記提供するステップは、前記
構成要求に対して少なくとも部分的に応
じたものである、
請求項1又は請求項2に記載の方法。
【請求項4】
前記第1のノードは、仮想化計算サービスのインスタンスホストの
ネットワークマネジャ
、または、(a)スイッチ、(b)ルータ、(c)ゲートウェイ、(d)ロードバランサ、若しくは(e)記憶装置のうちの1つまたは複数の少なくとも一部分を備える、請求項1から請求項3のいずれか一項に記載の方法。
【請求項5】
前記構成サーバにおいて、
前記分散計算環境の1つまたは複数のイベント検出器から特定のネットワークトラフィックパターンの検出の
表示を取得するステップ
を更に備え、前
記カスタマイズされたトラフィック分類規則
の前記第1のセットを前記提供するステップは、前記検出の前記
表示に対して少なくとも部分的に応
じたものである、
請求項1から請求項4のいずれか一項に記載の方法。
【請求項6】
計算装置の第1の集まりのうちの各計算装置において実施される1つ以上の構成サーバと、
分散計算環境の複数のノードであって、前記ノードの個々のものは、計算装置の第2の集まりの各計算装置において実施される、複数のノードと、
を備えるシステムであって、
前記1つ以上の構成サーバのうちの構成サーバは、
ネットワークパケットに適用されるべき
、カスタマイズされたトラフィック分類規則
の少なくとも第1のセットを、前記複数のノードの第1のノードに提供し、
前記第1のセットの特定のトラヒック分類規則は、前記分散計算環境の第2のノードのためにカスタマイズされたトラフィック分類規則の少なくとも第2のセットとは異なるようにカスタマイズされ、
前記ネットワークパケットに適用されるべき
、カスタマイズされたトラフィック分類規則
の少なくとも前記第2のセットを、前記複数のノードの
前記第2のノードに提供し
、前記第2のセットは前記第1のセットと異なる、
ように構成され、
前記第1のノードは、
前
記カスタマイズされたトラフィック分類規則
の前記第1のセットに少なくとも部分的に基づいて、第1のネットワークパケットの送信を開始する、
ように構成され、
前記第2のノードは、
前
記カスタマイズされたトラフィック分類規則
の前記第2のセットに少なくとも部分的に基づいて、第2のネットワークパケットの送信を開始する、
ように構成さ
れ、
前記カスタマイズは、1つまたは複数のネットワーク構成オプションを変更することを含む
システム。
【請求項7】
前記第1の
ネットワークパケットの送信を開始することは、前記
第1のネットワークパケットのヘッダコンテンツに少なくとも部分的に基づいて
、前記第1のセットのカスタマイズされた所定のトラフィック分類規則を呼び出すことを含む、請求項6に記載のシステム。
【請求項8】
前記第1のノードは、(a)スイッチ、(b)ルータ、(c)ゲートウェイ、(d)ロードバランサ、又は(e)記憶装置のうちの1つ以上の少なくとも一部分を備える、請求項6又は請求項7に記載のシステム。
【請求項9】
前記構成サーバは、
前記分散計算環境の1つまたは複数のイベント検出器から特定のネットワークトラフィックパターンの検出を示す通信を取得し
、前記カスタマイズされたトラフィック分類規則
の前記第1のセットは、前記通信に応じ
て提供されたものである、
ように構成される、請求項6から請求項8のいずれか一項に記載のシステム。
【請求項10】
前記構成サーバは、
前記第1のノードで実行しているアプリケーションの指示に少なくとも部分的に基づいて、前記第1のノード
のために、前記第1のセットの前記トラフィック分類規則をカスタマイズする、
ように更に構成される、請求項6から請求項9のいずれか一項に記載のシステム。
【請求項11】
分散計算環境の構成サーバから前記分散計算環境の
第1のノードに、ネットワークパケットを類別するのに使用されるべき
、トラフィック分類
規則の
少なくとも第1の列を提供するステップであって、前記第1
の列内では、連続的なトラフィック分類
規則は、より狭いトラフィックカテゴリに連続的に対応する、ステップと、
前記第1
の列を使用して、前記ノードにおいて、特定のネットワークパケットが、トラフィックカテゴリのヒエラルキの親カテゴリの子カテゴリに属するということを判断するステップと、
前記判断された子カテゴリに少なくとも部分的に基づいて、前記ノードにおいて、前記特定のネットワークパケットの送信を開始するステップと、
を備える方法。
【請求項12】
前記構成サーバから前記
第1のノードに、前記子カテゴリのトラフィックに対する性能制約の指示を提供するステップ
を更に備え、前記ネットワークパケットの前記送信は、前記性能制約が前記送信によって妨害されないであろうと判断することに少なくとも部分的に基づいている
、
請求項11に記載の方法。
【請求項13】
前記構成サーバにおいて、前記
第1のノードから
ネットワーク構成オプションの構成要求を受信するステップ
を更に備え、前記第1
の列を前記提供するステップは、前記
構成要求に対して少なくとも部分的に応
じたものである、
請求項11又は請求項12に記載の方法。
【請求項14】
前記ノードは、(a)スイッチ、(b)ルータ、(c)ゲートウェイ、(d)ロードバランサ、(e)記憶装置、又は(f)仮想化計算サービスのインスタンスホストの
ネットワークマネジャのうちの1つ以上の少なくとも一部分を備える、請求項11から請求項13のいずれか一項に記載の方法。
【請求項15】
前記ノードの1つ以上のメトリックスに少なくとも部分的に基づいて、前記ノード
のために前記第1
の列をカスタマイズするステップと、
前記構成サーバから、前記分散計算環境の別のノードにトラフィック分類
規則の第2
の列を提供するステップ
を更に備え、前記第2
の列は、
前記別のノード
のためにカスタマイズされており、且つ、前記第2
の列は、前記第1
の列と異なる
、
前記カスタマイズは、1つまたは複数のネットワーク構成オプションを変更することを含む、
請求項11から請求項14のいずれか一項に記載の方法。
【発明の詳細な説明】
【背景技術】
【0001】
多くの企業及び他の組織は、同一場所に配置された(例えば、ローカルネットワークの一部として)、またはその代わりに地理的に異なる複数の場所に配置された(例えば、1以上のプライベートまたは公衆中間ネットワークを介して接続された)計算システムなど、数多くの計算システムを相互接続してそれらの動作を支援するコンピュータネットワークを運用している。例えば、単一の組織によりその組織のために運用されているプライベートデータセンタや、ビジネスとして顧客に計算資源を提供するエンティティによって運用されている公共データセンタなど、膨大な数の相互接続された計算システムを収容するデータセンタが一般的になってきている。公共データセンタの運営者の中には、ネットワークアクセス、電力、及び多様な顧客が所有するハードウェア用の安全な設置施設を提供するものもあれば、顧客が利用可能なハードウェア資源も含め「フルサービス」施設を提供するものもある。しかしながら、標準的なデータセンタの規模及び範囲が増大するにつれ、物理的な計算資源の提供、管理、及び運営タスクがますます複雑化してきている。
【0002】
市販ハードウェアを対象とした仮想化技術が出現したことで、多様なニーズを有する数多くの顧客に大規模計算資源を管理する恩恵がもたらされ、多様な計算資源を複数の顧客が効率的にかつ安全に共有することが出来るようになった。例えば、仮想化技術により、1台の物理コンピュータマシンにホストされた1以上の仮想マシンを各ユーザに提供することで1台の物理コンピュータマシンを複数のユーザで共有できるようにしてもよい。そのような各仮想マシンは、個別の論理計算システムとして動作するソフトウェアシミュレーションであり、ユーザに所定のハードウェア計算資源の唯一のオペレータ及びアドミニストレータであると思わせ、一方、多様な仮想マシン間でアプリケーションを隔離し安全性も提供する。さらに、仮想化技術の中には、別個の複数の物理計算システムを繋ぐ複数の仮想プロセッサを有する単一の仮想マシンなど、2以上の物理資源を繋ぐ仮想資源を提供できるようにするものがある。
【0003】
仮想化した計算、記憶、及びネットワーク資源のプロバイダがサポートする機能が増大し特徴が多様になるにつれ、また、大規模プロバイダが使用するハードウェアプラットフォームグループが増大するにつれ、管理ネットワークトラフィックフローなど、プラットフォームでの管理制御動作の実施は、かなり複雑になる。多くの場合、そのようなプラットフォーム上で実行されるアプリケーションの機能性及び操作性は、プロバイダネットワークのその他の部分との、及び/または、クライアントまたは第三者などの外部エンティティとのネットワーク通信に広く依存してもよい。所望のアプリケーション実行レベルを達成しようとする場合、そのような分散システムのオペレータは、一般的に高帯域幅ネットワークインフラをセットアップしてもよい。しかし、高帯域幅ネットワークデバイス及びリンクを設けても、特に、配置したアプリケーションの多くのタイプに対する時変位置依存の帯域幅要件では、多くの場合ネットワーク帯域幅がボトルネック資源となるかもしれない。単一のハードウェアプラットフォームで実施される多様な仮想マシンは、幅広いネットワーク要件をプラットフォームの共有ネットワークコンポーネントを用いて満たさなければならず、また、一連のアプリケーション、及び、所定のハードウェアプラットフォームでインスタンス化される仮想マシンが、時間とともに変化するため、仮想化すると、管理ネットワーク帯域幅(レイテンシ及び他のネットワーク特性についても)がさらに難しい問題となるかもしれない。
【図面の簡単な説明】
【0004】
【
図1】少なくともいくつかの実施形態において、集中ネットワーク構成サービスを実施し、分散型計算環境の複数ノードでネットワークトラフィックを管理するシステムの実施例を示す。
【
図2】少なくともいくつかの実施形態において、それぞれのネットワーク構成サーバが複数の可用コンテナのそれぞれに設置されたプロバイダネットワーク環境の実施例を示す。
【
図3】少なくともいくつかの実施形態において、仮想化計算サービスのインスタンスホストにおいてトラフィック分類メタデータを解釈可能なネットワーク管理モジュールの実施例を示す。
【
図4a-4c】少なくともいくつかの実施形態において、インスタンスホストへのトラフィック分類メタデータの送信に用いられてもよいプロトコルのそれぞれの実施例を示す。
【
図5】少なくともいくつかの実施形態において、分散システムの装置におけるネットワーク構成のネットワークトラフィックカテゴリの表示に使用されてもよい分類ツリーデータ構造の実施例を示す。
【
図6】少なくともいくつかの実施形態において、データセンタにおける複数のインスタンスホストに関するネットワークトラフィックカテゴリ情報の結合に使用されてもよい階層式データ構造の実施例を示す。
【
図7】少なくともいくつかの実施形態において、分類ツリーと併せて使用しネットワークトラフィック単位のカテゴリを判断してもよいトラフィック分類プロシージャグラフの実施例を示す。
【
図8】少なくともいくつかの実施形態において、トラフィック分類プロシージャグラフでのルックアップテーブルノードの使用実施例を示す。
【
図9】少なくともいくつかの実施形態において、ネットワーク構成サービスの1以上のパラメータ値の判断に利用されてもよい応答性メトリクスの実施例を示す。
【
図10】少なくともいくつかの実施形態において、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実施されてもよい動作態様を示すフロー図である。
【
図11】少なくともいくつかの実施形態において、ネットワーク構成サービスのトラフィック分類メタデータを生成し配布するよう実施されてもよい動作態様を示すフロー図である。
【
図12】少なくともいくつかの実施形態において、トリガイベントに応答してネットワーク管理パラメータを変更するよう実施されてもよい動作態様を示すフロー図である。
【
図13】少なくともいくつかの実施形態において、ネットワーク関連状態情報の統合図を分散システムのクライアントに提供するよう実施されてもよい動作態様を示すフロー図である。
【
図14】少なくともいくつかの実施形態において使用されてもよい例示的な計算装置を示すブロック図である。
【0005】
本明細書では、複数の実施形態及び説明図を例に挙げ実施形態を説明するが、当業者であれば実施形態が説明の実施形態または図に限定されるものではないとわかるであろう。図及び図の詳細説明は、開示した特定の形態に実施形態を限定する意図はなく、反対に、あらゆる変更、均等物及び代替物を、添付の請求項で定める趣旨及び範囲に含めることを意図する。本明細書で使用する見出しは、単に構成上の理由によるものであり、本説明または本請求項の範囲を限定するものではない。本出願を通して用いるように、「してもよい」「かもしれない」は許容を意味し(すなわち、可能性があることを意味する)、命令の意味(すなわち、しなければならないを意味する)ではない。同様に、「含む(include)」、「含んでいる(including)」、「含む(includes)」は、含むがそれに限定されないことを意味する。
【発明を実施するための形態】
【0006】
プロバイダネットワークなど大規模分散システムでのネットワーク運用の構成方法及び
構成装置の多様な実施形態を説明する。ある実施形態において、分散システムの多数のノード(ホスト及びネットワークデバイスなど)の帯域幅制限、レイテンシ管理、及び、その他トラフィック形成パラメータについて1以上のネットワーク構成サーバ(NCS)においてなされた様々な判断に従い、集中ネットワーク構成管理スキームを実行してもよい(ある実施形態において、ネットワーク構成サーバを、「帯域幅調整サーバ」としてもよい。多様なトラフィックカテゴリにそれぞれの帯域幅制限を課した、分散システムのコンポーネントでの帯域幅使用管理が、サーバの第一義的責任であるためである)。例えば、判断を実施するのに使用するメタデータは、トラフィック分類プロシージャまたは規則、及び、多様なトラフィックカテゴリに対するネットワーク構成オプションを含むが、当該メタデータは、NCSから分散システムのノードに、移動可能な解析しやすいフォーマットで送信されてもよい。分散システムのノードにおいて、受信メタデータを、例えば、仮想化管理ソフトウェア内のネットワーク管理モジュールにより解釈し、ネットワークトラフィック予定のパケットまたはその他単位を、パケットまたはその他単位が生成または受信された時に分類し、BASでの判断を適用してトラフィック送信の予定組み及び/または調整を行ってもよい。トラフィック形成(少なくともいくつかの場合において、多様なソースから得られる重要な一連の入力データの解析を要してもよい)に使用するロジックを生成する役割を集中ネットワーク構成サーバが担い、比較的単純な制御モジュールがロジックを多様なノードに適用してもよい。所定のノードに送信されたメタデータは、少なくともいくつかの実施形態において、ノードから収集したメトリクス、及び、当該ノードで実行されるアプリケーションの特性などに基づいて、当該ノード専用にカスタマイズされてもよい。いくつかの実施形態において、ネットワーク構成管理技術はプログラマチックインタフェースをサポートしてもよく、当該プログラマチックインタフェースにより、分散システムのクライアントが、対象資源のネットワークの関係性を示す統合または連結図を入手し得る。また、少なくともいくつかの実施形態において、プログラマチックインタフェースを実施し、クライアント及び/またはアドミニストレータが、集中ネットワーク構成システムに多様な構成要求を出せるようにし、そのことで、例えば、NCSで判断され多様なノードに発信された分類関連規則及び/またはネットワーク設定を変更することになってもよい。少なくともいくつかの実施において、一部または全てのネットワーク構成スキームを、例えば1以上のウェブサービスなどのウェブサービスとして実施し、プログラマチックインタフェースによるネットワーク構成サーバとの多様な対話をサポートしてもよい。
【0007】
以下の説明において多くの場合、プロバイダネットワークを分散システムの実施例としており、当該分散システムでは、集中ネットワーク構成技術を実施してもよい。ネットワークは、企業または公共組織などの主体により設定され、インターネット及び/またはその他ネットワークを介して一連の分散クライアントにアクセス可能な1以上のネットワークアクセス可能サービス(様々なクラウド型のデータベース、計算または記憶サービスなど)を提供する。当該ネットワークを、本明細書ではプロバイダネットワークと呼んでもよい。少なくともいくつかのサービスを、クライアントが使用できるよう「インスタンス」と呼ばれるサービス単位にまとめ、例えば、仮想化計算サービスによりインスタンス化された仮想マシンを「計算インスタンス」とし、記憶サービスによりインスタンス化されたブロックレベルボリュームなどの記憶装置を「記憶インスタンス」としてもよい。いくつかの実施形態において、上位サービスのインスタンスを計算インスタンス及び/または記憶インスタンスを用いてまとめてもよく、例えば、いくつかの実施形態において、計算及び記憶インスタンスを組み合わせて、データベースインスタンスを構築してもよい。プロバイダネットワークの多様なネットワークアクセス可能サービスをそのような単位にしたサーバ及び/または記憶装置などの計算装置を、本明細書では「インスタンスホスト」、またはより簡潔に「ホスト」とするかもしれない。以降本書では、所定の通信元(ソース)または通信先として使用される用語「クライアント」を、計算装置、プロセス、ハードウェアモジュールまたはソフトウェアモジュールのいずれかとしてもよく、当該計算装
置、プロセス、ハードウェアモジュールまたはソフトウェアモジュールは、プロバイダネットワークの少なくとも1つのネットワークアクセス可能サービスへのアクセス及び使用が可能な主体(組織、複数ユーザグループ、または単独ユーザなど)により所有され、または管理され、あるいは主体に割り当てられている。
【0008】
所定のプロバイダネットワークは、多くのデータセンタ(地理的に異なる地域に分散されてもよい)を備えてもよく、当該データセンタは、物理及び/または仮想コンピュータサーバ、それぞれが1以上の記憶装置を有する記憶サーバ、ネットワーク設備などの集まりなど、多様な資源プールをホストし、プロバイダが提供するインフラ及びサービスの実施、構成及び分散には必要である。多種多様なハードウェア及び/またはソフトウェアコンポーネントの中には、種々のデータセンタで、または地理的に異なる地域でインスタンス化または実行されるものがあるが、多様な実施形態において、当該多種多様なハードウェア及び/またはソフトウェアコンポーネントをまとめて使用し、各サービスを実施してもよい。クライアントは、クライアントが所有またはクライアントが管理する設備、または、プロバイダネットワークの外部にあるデータセンタに設置された装置から、及び/または、プロバイダネットワーク内にある装置からの資源及びサービスとプロバイダネットワークにおいて対話してもよい。少なくともいくつかの実施形態において、多様な計算インスタンスを提供する仮想化計算サービスをプロバイダネットワーク内で実施し、そのような計算インスタンスをクライアントに割当ててもよい。外部からのアクセスと同様、そのような計算インスタンスからプロバイダネットワークの別のサービスにアクセスしてもよい。本明細書で説明する帯域幅管理技術の多くを実施する1つの例示的なコンテキストとしてプロバイダネットワークは機能を果たしているが、当該技術をプロバイダネットワーク以外の別の分散システム、例えば、アプリケーションの種々のコンポーネントが時変帯域幅を要するような大規模分散型環境に、適用してもよいことに注意する。
【0009】
少なくとも一つの実施形態によれば、NCSの数及び分散を、例えば、以下で説明する性能及び/または可用性基準に基づき判断し、多数のNCSをプロバイダネットワーク内の様々な位置でインスタンス化してもよい。プロバイダネットワークで実施される多様なサービスのインスタンスホストから、及び/または、多様なネットワークデバイス(スイッチ、ルータ、ゲートウェイなど)からなど、プロバイダネットワークの多様なノードから、ネットワーク関連メトリクスを取得するようNCSを構成し、帯域幅管理での判断をしやすくしてもよい。多様な実施形態において、例えば、ある時間間隔における所定ホストでの実流入出ネットワークトラフィック、ある時間間隔に破棄したパケット数、現帯域幅制限で送信が遅延したパケット数、パケットサイズ、アプリケーションのために所定ノードで流入出トラフィックが発生するアプリケーション、クライアントのためにトラフィックが開始されるクライアント、及び/または、多様な送信に係わるエンドポイントのIPアドレスなど、多様な情報を収集してもよい。また、いくつかの実施形態において、別のソースからの入力を帯域幅管理の判断に使用してもよい。例えば、セキュリティサービスをいくつかのプロバイダネットワークで実施し、分散サービス妨害(DDOS)攻撃などのネットワーク侵入または攻撃を特定しようとし、潜在的攻撃を警戒し、帯域幅制限を変更するかトラフィックカテゴリの定義に反映させてもよい。少なくとも一つの実施形態において、プロバイダネットワークは、例えば、管理及び/または課金するため、IPアドレス毎にまたはクライアント毎にネットワークトラフィックメトリクスを集めるサービスを備え、そのようなアグリゲータがNCSに入力を行ってもよい。いくつかの実施形態において、プロバイダネットワークの1以上のネットワークアクセス可能サービスのクライアント及び/またはアドミニストレータは、帯域幅関連要求またはその他構成要求をNCSに出し、例えば、特定のインスタンスホストまたはネットワークデバイスの1以上の帯域幅管理パラメータをオーバーライドしてもよい。また、そのような要求をNCSで行う判断に反映させてもよい。
【0010】
少なくとも一部のそのような入力に基づいて、所定のNCSは、プロバイダネットワークの所定ノードで使用する、多様なネットワーク構成オプション及び/またはプロシージャを判断してもよい。パラメータを判断する際は場合により、1以上のグローバル及び/またはローカルネットワーク管理方針も考慮してもよい。一実施形態において、一連のトラフィックカテゴリまたはトラフィックカテゴリのヒエラルキを、カテゴリ毎に、帯域幅制限、レイテンシ目標または制約などの多様なネットワーク構成オプションと合わせ、判断してもよい。いくつかの実装では、フラットな分類(1階層しかないヒエラルキに相当する)を使用してもよいが、その他の実装では、種々の階層のノード間で親子関係を有する複数階層ヒエラルキを使用してもよい。以下の説明において、本明細書で使用する用語「ヒエラルキ」は、1階層分類またはフラット分類、及び、親子関係を示す複数階層分類の両方を包含するものとする。ヒエラルキに加えて、任意の所定のネットワークパケット(または、データ転送に適した任意の単位)をいずれかのカテゴリに分類するために使用されるプロシージャ(例えば、一連の判断ステップまたは適用される規則)も判断してもよい。トラフィックカテゴリに関する情報、及び、カテゴリに対するトラフィック単位のマッピングに用いるロジックまたは規則を、本明細書ではまとめて「トラフィック分類メタデータ」または「分類メタデータ」と呼んでもよい。少なくともいくつかの実施形態において、所定のホストが、他のホストとは異なるサービスインスタンスの組合せを備えてもよく、また、所定のホストのサービスインスタンスで実行されるアプリケーションのネットワーク要件は、他のアプリケーション(同一ホストか他のホストのいずれかにおいて)のネットワーク要件とは異なってもよいので、ホスト毎に、適する一連のネットワーク構成パラメータが異なってもよい。これにより、少なくともいくつかの実施形態において、分類メタデータは、少なくともいくつかのノード用にカスタマイズされてもよい。例えば、インスタンスホストIH1などプロバイダネットワークの1つのノード用に生成された分類メタデータは、インスタンスホストIH2など別のノード用に生成された分類メタデータとは異なってもよい。種々の一連のトラフィックカテゴリを種々のノード用に定義してもよく、例えば種々の帯域幅制限またはレイテンシ要件を同一のトラフィックカテゴリに設定してもよく、あるいは、トラフィック単位分類プロシージャの少なくともいくつかのステップが異なってもよい。少なくともいくつかの実装において、スイッチ、ルータ、ゲートウェイ、またはロードバランサなどの多様なネットワークデバイス用、またはネットワークに取り付けられた記憶装置用に判断されたネットワーク構成パラメータを、デバイスに関連するかデバイスに影響を受ける一連のホストの帯域幅管理パラメータの少なくとも一部から導出してもよい。例えば、特定のスイッチを8つのホストとの流入出トラフィックに使用する場合、あるトラフィックカテゴリ用のスイッチの帯域幅制限を8つのホストの帯域幅制限から導出してもよい。
【0011】
所定ノードのNCSにより定義されるトラフィックカテゴリは、種々の実施形態で様々な特性において互いに異なってもよい。一実施形態において、種々の一連のネットワークエンドポイントに種々のカテゴリが生成されてもよい。例えば、トラフィック先(またはソース)のIP(インタネットプロトコル)アドレスを使用し、トラフィックを分類してもよい。別の実施形態において、アプリケーションのためにトラフィックが流れるアプリケーションの種類をトラフィック分類に使用してもよい。例えば、データベース関連トラフィックを1つのカテゴリとし、高性能計算関連トラフィックをまた別のカテゴリとしてもよい。いくつかの実施形態において、クライアントのためにトラフィックが生成されるクライアントを作成し、及び/または、クライアントの予算、または、クライアントとの契約上の合意の態様を用いて、トラフィックカテゴリを定義してもよい。分散システムで複数のネットワークアクセス可能サービスを実施するいくつかの実施形態において、サービスのために特定のトラフィック単位が生成されるサービスに基づき、トラフィックカテゴリを定義してもよい。サービスベースの分類を現在使用し、所定パケットが2以上のサービスに関連する場合、例えば、データパケットを、データベースサービスのデータベースインスタンスのために記憶サービスから転送すれば、多様な実施形態において、パケッ
トは、ソースサービス(すなわち、送信側)または通信先サービス(受信側)に属するとして分類されてもよい。少なくとも一つの実施形態において、クライアントは、ネットワーク構成サービスにより使用されトラフィック単位を分類できる1以上のプロパティを指示してもよい。例えば、クライアントは、少なくとも一時的にいくつかの一連の計算インスタンスが優先度の高いインスタンスであると特定されるよう要求し、当該インスタンスとの流入出トラフィックを、帯域幅制限が広く優先度が高いトラフィックとして分類してもよい。
【0012】
いくつかの実施形態において、NCSは、ツリー型などの階層データ構造を用いて、各帯域幅制限及び/またはその他ネットワーク構成オプションをツリーの各ノードに割当て、所定プロバイダネットワークノードのトラフィックカテゴリをモデル化するか表示してもよい。少なくともいくつかの実施において、帯域幅集計方針を分類ツリーに適用してもよい。そのような方針に従い、ツリーにおいて子ノードC1、C2・・・、Ckを有する所定の親ノードPがXビット/秒の帯域幅制限を有している場合、所定時間間隔の子ノードC1、C2・・・、Ckに関連する実トラフィックの合計が親の帯域幅制限を超えなくてもよい。Pの流出トラフィックの帯域幅制限を1Gビット/秒に設定し、Pが2つの子ノードC1及びC2を有し、それぞれの流出トラフィックの帯域幅制限も1Gビット/秒に設定する一実施例を例にとる。所定秒中に、C1のトラフィックとして分類された0.6Gビットのトラフィックがインスタンスから流れた場合、C2に対し定義された個別の制限が高くても、C2のトラフィックとして分類されたわずか0.4Gビットのトラフィックを許容することができる。多様な実施形態において、当然、レイテンシ制約または目標、サービス品質目標、パケットフラグメンテーション設定、または少なくとも一部のパケットサイズに応じた設定など、NCSが判断するネットワーク構成オプションの中には、親子関係に基づく集計方針が適さないか、有用でないものがあってもよい。
【0013】
一連のトラフィックカテゴリの表示にツリー構造またはツリー状構造を用いる他に、いくつかの実施形態において、NCSは第二データ構造も生成し、トラフィック単位をカテゴリに分類するのに使用するプロシージャをモデル化してもよい。第二データ構造は、分類プロシージャグラフと呼ばれ、いくつかの実装において、1以上の列の判断ノードを備えており、所定列の一続きのノードにより、トラフィック単位をより詳細なカテゴリに分類するのに使用する1以上の基準を示してもよい。少なくとも一つの実装において、分類プロシージャグラフの判断ノードの中には、複数のカテゴリ選択の中から1カテゴリを選択するのに使用するルックアップテーブル(例えばハッシュテーブル)を備えるものがあってもよい。ルックアップテーブルのエントリを、分類対象のネットワークトラフィック単位の1以上のプロパティに基づいてインデックス化してもよい。例えば、送付先またはソースIPアドレスの一部または全てをインデックス化するのに使用し、あるいは、別のパケットヘッダフィールドまたはパケット本体コンテンツの一部を使用しテーブル内の特定のエントリを探すようにしてもよい。少なくともいくつかの実施形態において、ルックアップテーブルのエントリが、順番に別の分類プロシージャグラフまたはサブグラフに繋がっていてもよい。このため、そのような実装において、パケットの所定プロパティが、まず、複数あるルックアップテーブルのエントリ候補の中からルックアップテーブルのエントリを一つ選択することに繋がり、選択したルックアップテーブルのエントリを処理することで、順番に別の1連の判断ノード(判断ノード自体が別のルックアップテーブルを備えてもよい)をトラバースすることになり、最終的にパケットのカテゴリを特定してもよい。多様な実施形態において、そのようなプロシージャステップを用いて、ネットワークパケット及び/またはその他トラフィック単位をかなり詳細に分類するきめの細かいカテゴリマッピングを定義し、高性能なトラフィック形成を可能にしてもよい。少なくともいくつかの実装において、流入出トラフィックに種々の分類ヒエラルキ及び/またはプロシージャを生成してもよい。
【0014】
いくつかの実施形態において、NCSは、ネットワーク構成オプションと関連する一連のトラフィックカテゴリ、及び、ネットワークトラフィック単位をカテゴリにマッピングするロジックを備えるメタデータを前もって生成しておき、メタデータが適用されるノードに送信するためのメタデータの移動可能表示を生成してもよい。例えば、多様な実装において、メタデータの1つまたは双方のコンポーネントを、JSON(JavaScript(登録商標) Object Notation)、XML(Extensible
Markup Language)、YAML(シリアライゼーション形式であり、そのアクロニムの由来は、「Yet Another Markup Language(また別のマークアップ言語)」または「YAML Ain’t Markup Language(YAMLはマークアップ言語ではない)」など多数ある)などの業界標準プロトコルまたは言語に従い、コード化してもよい。別の実装において、独自コード化技術またはプロトコルを使用し、移動可能型データ構造を生成してもよい。
【0015】
移動可能表示を、プロバイダネットワークまたは分散システムの対象ノードに送信してもよく、当該ノードは、例えば、ネットワーク管理モジュールなどの制御/管理モジュールなどであるが、表示解析も、プロシージャグラフが示すプロシージャの実施もできるわけではない。受信メタデータを用いて、多様なトラフィック単位を対象ノードで適切なカテゴリに継続して分類し、各トラフィックカテゴリに示す帯域幅制限またはレイテンシ要件などのネットワーク構成オプションに従い、多様なネットワーク送信の予定し、及び/または、調整しまたは延期してもよい。そのような送信中に収集したメトリクスをNCSにフィードバックし、後のためにメタデータを改良可能にしてもよい。フィードバックループをNCSとノードとの間に確立し、NCSでなされた決定を当該ノードで最終的に実施する。こうして、ネットワーク管理パラメータの長期的な動的調整が可能になる。多様な実施形態において、そのようなカスタム可能なトラフィック分類及び構成技術を用いることにより、集中ネットワーク構成システムがプロバイダネットワークの様々な部分でトラフィックを所望する粒度まで制御し形成できるようになる。
【0016】
種々の実施形態において、多様な手法を用いて対象ノードに分類メタデータを配布してもよい。例えば、一実施形態において、NCSは、当該NCSを割り当てられた各ホスト及び/または各ネットワークデバイスに定期的に(例えば、少なくともX分毎に1回)分類メタデータを「プッシュ」するよう設定されてもよい。いくつかの実施形態において、多様なトリガイベント(潜在的なネットワーク侵入または攻撃の検出など)を要因として、新規の分類メタデータを配布してもよい。例えば、攻撃による影響を軽減または限定的にするために、以下で詳述するように、いくつかの1連のノードで帯域幅制限を狭めるか、低帯域幅制限の新しいカテゴリを定義してもよい。別の実施形態において、プロバイダネットワークの少なくともいくつかのノードは、割り当てられたNCSからトラフィック分類メタデータを「プル」してもよく、例えば、NCSにメタデータ要求を送信し、応答でメタデータを受信する。いくつかの実施形態において、予定プッシュ技術、トリガイベント型メタデータ配布、及び/またはノード開始型プル技術を組み合わせて用いてもよい。
【0017】
いくつかの実施形態において、プロバイダネットワークまたは別の分散システムを、地理的に異なる複数地域に構成し、各地域は1以上の可用コンテナを備えてもよい。可用コンテナを本明細書では「可用ゾーン」とも呼ぶ。また、可用コンテナは1以上の異なる地点またはデータセンタを備え、所定の可用コンテナにある資源を別の可用コンテナで起きた故障から切り離すよう設計されてもよい。つまり、1つの可用コンテナでの故障が、時間的にまたは原因となって別の可用コンテナでの故障に繋がることがないようにし、資源インスタンスまたは制御サーバの可用プロファイルが、別の可用コンテナの資源インスタンスまたは制御サーバの可用プロファイルから分離されるようにしてもよい。クライアントは、各可用コンテナで複数のアプリケーションインスタンスを起動させて、単一の地点
で起きた故障からクライアントのアプリケーションを保護できるようしてもよい。それと同時に、いくつかの実装において、同じ地理的地域内にある資源インスタンス間を安価でレイテンシの少ないネットワークで接続してもよい(また、同じ可用コンテナの資源間でのネットワーク送信を一層高速にしてもよい)。ネットワーク構成システムの可用性及び/または性能を所望のレベルまで引き上げるために、そのようないくつかの実施形態において、少なくとも一つのネットワーク構成サーバを各可用ゾーンにセットアップしてもよい。いくつかの実施形態において、少なくも一つのNCSを各データセンタ内に設置してもよい。いくつかの実施形態において、所与の地域、可用コンテナ、またはデータセンタに設置するNCSの数を、少なくとも一部の性能要件に基づき判断してもよい。例えば、ネットワーク構成システムが、変更帯域幅制限を生成し、適した一連のノードに変更制限を適用して、ネットワーク攻撃またはその他トリガイベントに対応できる即応性に基づき判断する。
【0018】
一実施形態によれば、ネットワーク構成システムにより1以上のプログラマチックインタフェース(API(アプリケーションプログラミングインタフェース)、ウェブページ、コマンドラインツール、グラフィカルユーザインタフェースなど)を実施し、プロバイダネットワークのクライアント及び/またはその他サービスにより使用可能にしてもよい。そのような一実施形態において、上述したように、多様なサービスのクライアントまたはアドミニストレータは、帯域幅オーバーライド要求などの構成要求を出し、特定のサービスインスタンスまたはホストのネットワーク構成オプションを設定または変更してもよい。クライアントの中には、例えば、少なくともある時間間隔の少なくともいくつかのアプリケーションに対する帯域幅制限の拡大(または縮小)を望むものがあるかもしれない。いくつかの実施形態において、所定のクライアントに、多数のサービスインスタンス(何百何千もの計算インスタンス、記憶インスタンス、データベースインスタンスなど)を割り当て、当該クライアントが、サービスインスタンスのサブセットの最新ネットワーク連結図(利用可能帯域幅制限、レイテンシ設定などを含む)の入手を希望するかもしれない。いくつかの実施形態において、例えば、プロバイダネットワークのコンソールサービス、または、その他連結ネットワーク図作成装置で、ネットワーク構成サービスのプログラマチックインタフェースを用いて、そのような統合図を提供してもよい。また、いくつかの実施形態において、起動予定の新サービスインスタンス用のインスタンスホストの特定を担うインスタンス配置サービスなどの他のサービスで、プログラマチックインタフェースを用いてもよい。新サービスインスタンスの候補として特定のインスタンスホストを検討する場合、そのような配置サービスは、プログラマチックインタフェース上で用いてネットワーク構成サービスから情報を入手し、新サービスインスタンスの配置判断にそのような情報を使用してもよい。当該情報は、例えば、当該候補での最近の帯域幅使用傾向、最近調整されたネットワーク送信回数、及び/または、当該インスタンスホストの現在確立されているネットワーク帯域幅制限またはレイテンシ設定などである。
システム環境の実施例
【0019】
図1は、少なくともいくつかの実施形態において、集中ネットワーク構成サービスを実施しネットワークトラフィックを分散計算環境の複数のノードで管理する、システム100の実施例を示す。図示したように、NCS180A及びNCS180Bなどのネットワーク構成サーバ180のプール182を設置してもよい。いくつかの実施形態において、
図2に示し以下で説明するように、複数のNCS180を計算環境の多様なデータセンタに分散させてもよい。種々の実施形態において、所定のNCS180は、例えば、1以上のソフトウェア及び/またはハードウェアモジュールを備えてもよく、場合により、NCS自体を複数の計算装置を用いて実施してもよい。多種多様なソースから入力を受信するようNCS180を構成してもよい。NCSは、分散計算環境の多様な要素で適用される帯域幅制限など、カスタム可能トラフィック分類ロジック及びネットワーク構成オプションを、入力に基づいて、及び/または、図の実施形態のグローバルネットワーク管理方針
122を考慮して、判断してもよい。ネットワーク構成サービスの面から、分散計算環境の要素を、測定関連コンポーネント107、判断コンポーネント108、及び実施コンポーネント109の3つの上位カテゴリに分類してもよい。測定関連コンポーネント107は、NCSへの多様な入力ソースを備えてもよい。判断コンポーネント108は、NCS自体を備えてもよい。実施コンポーネント109は、判断を実行してネットワークトラフィックを形成するか、判断コンポーネントによって生成された出力を他の目的に利用するエンティティであってもよい。フィードバックループについては、従来通りの制御システムフィードバックループと類似のフィードバックループが構築され、いくつかの実施コンポーネント(サービスインスタンスホスト144及び/またはネットワークデバイス145など)から測定値を入手し、メトリクスを用いてNCS180により以後の判断を行ってもよい。当該判断の結果、測定をさらに行い、以後の判断に影響を与えることになってもよい。
【0020】
図の実施形態において、例えば、多種多様なネットワーク関連メトリクスが、メトリクスコレクタ125によりインスタンスホスト144及び/またはネットワークデバイス145から集められ、NCS180がアクセス可能なメトリクスデータベース190に配置されてもよい。例えば、そのようなメトリクスは、ある時間間隔における所定のホストでの流入出ネットワークトラフィクレート(例えば、バイトまたはパケットで表示する)、TCP(Transmission Control Protocol)またはUDP(User Datagram Protocol)など多様なプロトコルに対応するネットワーク接続数、ある時間間隔における廃棄パケット数及びパケット廃棄原因、現帯域幅制限の実施による通信遅延パケット数、パケットサイズ分布、アプリケーションのために所定ノードとのトラフィック流入出がなされるアプリケーション、クライアントのためにトラフィックが開始されるクライアント、パケット送出に関連するレイテンシ、及び/または多様な送信に係わるエンドポイントのIPアドレスを含んでもよい。データベース190に保存されたメトリクスの他に、NCSは、例えば、セキュリティサービス111またはトラフィックメトリクスアグリゲータ112などの、システム100の追加入力データソース110からの入力も受信してもよい。システム100の様々な部分でトラフィックパターンを監視するようセキュリティサービス111を構成し、ネットワーク侵入または攻撃(システム100の外部の、例えば、公衆インターネットの多様な位置が送信元であるものもあれば、インスタンスホスト144自体が送信元であるものもあるかもしれない)を検出してもよい。不審なトラフィックパターンを検出した場合、例えば、所定のネットワークアドレスに向けたトラフィックが突如連続してバーストした場合、セキュリティサービス111は、NCS180に知らせ軽減対策を取ってもよい。例えば、NCS180が新トラフィックカテゴリ、及び、対応する適用帯域幅制限を設けるか、既存のカテゴリの帯域幅制限を変更し、新規変更または生成した分類メタデータを適したホストに送信し、潜在的なセキュリティイベントの影響を限定的にしてもよい。トラフィックメトリクスアグリゲータ112は、コレクタ125から送信されたメトリクスを、例えば、各IPアドレス専用バケットまたは各クライアント専用バケットなどのバケットにまとめ、バケット表示をNCSに対し利用可能にし、ネットワーク構成の判断をする際に検討する。
【0021】
図1に示す実施形態において、クライアントオーバーライド要求130及び/またはアドミニストレータオーバーライド要求131も、NCS180が行う判断に寄与してもよい。例えば、グローバル方針122及びその他のメトリクスに基づき、NCS180は、インスタンスホスト144におけるトラフィックの所定のカテゴリC1に対する帯域幅制限を、次回時間間隔を考慮して2Gビット/秒に設定すると判断してもよい。しかし、図に示す実施形態において、あるクライアントの計算インスタンスが当該インスタンスホストでインスタンス化されることになった場合、当該クライアントは、当該計算インスタンスに対し5Gビット/秒の帯域幅を要求してもよく、または、当該インスタンスホストで
実施されるサービスのアドミニストレータが帯域幅を1Gビット/秒に制限する要求を出してもよく、NCSがそのような要求を用いて別の因子をオーバーライドしてもよい。クライアントのトラフィック量に応じてクライアントにネットワークトラフィックの課金を行う実施形態において、クライアントの中には、帯域幅使用に上限を設けるコスト管理を要望してもよく、そのような上限もオーバーライド要求130の実施例であるとしてもよい。
【0022】
いくつかの実施形態によれば、所定のNCS180は、当該NCSを割り当てられた1以上のインスタンスホスト144及び/またはネットワークデバイス145のトラフィック分類メタデータを生成してもよい。少なくともいくつかの実施形態において、分類メタデータを、ネットワーク接続ストレージ(NAS)デバイスなどの記憶装置についても生成してもよい。メタデータは、ツリーデータ構造で表されるトラフィックカテゴリの1以上のレベルを有するヒエラルキを備え、例えば、当該構造では、ツリーの各ノードが各トラフィックカテゴリを表し、関連する一連のネットワーク構成オプションまたは設定(帯域幅制限またはレイテンシ要件)を有する。いくつかの実施形態において、
図5を参考に以下で説明するように、1つの親ノードに複数の子ノードがあるように表すトラフィックカテゴリに対する実トラフィックレートが親ノードの帯域幅制限を超えないよう、トラフィック集計方針を分類ツリーに適用してもよい。インスタンスホスト144毎に各分類ツリーを生成するようないくつかの実施形態において、
図6を参考に以下で説明するように、ホストレベル分類ツリーは、NCS180によりラックレベルツリーまたはデータセンタレベル分類ツリーに連結されてもよい。そのような上位レベルツリーを用い、例えば、ネットワークトラフィックの流れに関するより広い視点を取得し、及び/または、インスタンスホスト毎またはネットワークデバイス毎ではなく、より上位の判断を行ってもよい。
【0023】
分類ツリーの他に、トラフィック分類メタデータは、図に示す実施形態における分類ツリーで定義された多様なカテゴリにパケットなどのネットワークトラフィック単位をマッピングするのに使用するプロシージャも備える。プロシージャステップを、例えば、プロシージャグラフの判断ノードとして表示してもよい。所定のプロシージャグラフは、いくつかの実装において1以上の判断ノード列を備え、連続したノードが、より詳細なトラフィックカテゴリにネットワークトラフィック単位をマッチさせるのに用いる基準を指示することを含む。少なくとも一つの実装において、判断ノードの中にはハッシュテーブルなどのルックアップテーブルを備えるものがあってもよい。そのようなルックアップテーブルノードを用いて、所定パケットまたはトラフィック単位を、単一グラフノードを用いて多種多様なカテゴリの1つにマッピングして、プロシージャグラフのサイズを小さくし、複雑さを低減してもよい。場合により、ルックアップテーブルのノードのエントリを別のプロシージャグラフまたはサブグラフへのポインタにし、細かく分類するロジックまたは基準を使用できるようにさせてもよい。プロシージャグラフ及びルックアップテーブルに組み込まれている判断ノードの実施例を、
図6及び
図7に示し、以下で詳述する。少なくともいくつかの実施形態において、分類メタデータを分類データベース192で保存し、さらに、適切なインスタンスホスト144及び/またはネットワークデバイス145に配布してもよい。
【0024】
いくつかの実施形態によれば、NCS180で生成されたメタデータを、所望の配布先に配布システム127を介して送信してもよい。配布システム127は、いくつかの実装において、それ自体で複数の中間ノードを備え、ルーティング情報及び/またはアクセス制御リストなど、他のタイプのメタデータをシステム100の多様なノードに配布するために使用してもよい。データベース192を生成メタデータのリポジトリとして使用する実施形態において、配布システム127のノードに、例えば、データベース192が更新された時に通知し(例えば、通知機構をサブスクライブして)、新規メタデータを適した
配布先に転送してもよい。いくつかの実施形態において、NCS自体か配布システム127かのいずれかにより、JSON、XML、YAMLなどのプロトコル、あるいは、独自技術または言語などを用いて、メタデータの移動可能表示(例えば、分類ツリー及びプロシージャ)を生成してもよい。一つの実装において、移動可能表示をデータベース192に保存してもよい。送付先において受信メタデータ表示を解析してもよく、例えば、
図3に示し以下で詳述するようにインスタンスホスト144の場合では、仮想管理ソフトウウェアスタックのネットワーク管理モジュールにより解析する。
【0025】
一実施形態において、1以上のAPIサーバ170をセットアップし、実施サブシステム109の他の出力先150からNCS180に向けた要求を処理してもよい。例えば、1以上のサーバを連結ネットワーク図作成装置152として構成し、分散環境の選択位置でのネットワーク状態の統合図をクライアントに提供してもよい。一実装において、例えば、多様なインスタンスホストでクライアントに何百何千ものサービスインスタンスを割り当て、当該インスタンスが、図作成装置152で実施されるコンソールを介してインスタンスの多様なメトリクス(最新の流入出トラフィックレート、廃棄パケットレート、適用帯域幅制限など)を見えるようにしてもよい。少なくとも一つの実施形態において、配置サービス151はネットワーク帯域幅制限及びその他メトリクスをNCSからAPIサーバ170を介して入手可能にしてもよく、開始予定の新サービスインスタンスに使用するインスタンスホストについて判断するか、既存のサービスインスタンスを帯域幅の競合が少ないインスタンスホストに動かすのに役立てもよい。
【0026】
図2は、少なくともいくつかの実施形態において、ネットワーク構成サーバが複数の可用コンテナそれぞれに設置されているプロバイダネットワーク環境の実施例を示す。図のように、図に示す実施形態において、プロバイダネットワーク202は、203A、203B、及び203Cなど複数の可用コンテナ203を備えてもよい。各可用コンテナはさらに、可用コンテナ203Aはデータセンタ205A及び205B、可用コンテナ203Bはデータセンタ205C、及び可用コンテナ203Cはデータセンタ205Dというように、1以上のデータセンタ205を備えてもよい。前述したように、各可用コンテナ203は、任意の所定可用コンテナでの多様な故障イベントの影響が一般的に当該可用コンテナに限定されるよう(例えば、電源などのそれぞれ独立したインフラ要素において、可用コンテナ同士を地理的に離して)、計画設計されてもよい。従って、故障及び/またはエラーは一般的に可用コンテナの境界を超えて広がらず、種々の可用コンテナは独立した故障プロファイルまたは独立した可用プロファイルを有するものと見なしてもよい。例えば、所定の可用コンテナが自然災害に遭った場合でも、他の可用コンテナは引き続き動作可能であることを期待されてもよい。
【0027】
可用コンテナ同士の依存関係を防ぎまたは低減させることを設計目標とし、図に示す実施形態において、少なくとも一つのNCS180を各可用コンテナ203に設置してもよい。例えば、NCS180A及び180Bを、可用コンテナ203Aのデータセンタ205A及び205Bにそれぞれセットアップし、NCS180Cを可用コンテナ203Bのデータセンタ205Cに設置し、NCS180Dを可用コンテナ203Cのデータセンタ205Dに配置する。データセンタ205Aで実施される1以上のネットワークアクセス可能サービス(仮想化計算サービスまたは記憶サービス)のインスタンスホスト144A用、及び、データセンタ205Aに配置されたネットワークデバイス145A用の分類メタデータを生成するよう、NCS180Aを構成してもよい。同様に、NCS180Bにインスタンスホスト144B及びネットワークデバイス145B用の分類メタデータを生成するタスクを割り当て、NCS180Cにインスタンスホスト144C及びネットワークデバイス145C用の分類メタデータの生成を担当させ、インスタンスホスト144D及びネットワークデバイス145D用の分類メタデータを生成するようNCS180Dを構成してもよい。
図2に示す実施形態において、単一のNCSを各データセンタ205に
表示しているが、少なくともいくつかの実施形態において、複数のNCSを所定のデータセンタ205にセットアップしてもよい(例えば、性能要件に応じ、及び/または、データセンタでのメタデータ生成を要するノード数に応じる)。一実施形態において、可用コンテナ(203Aなど)がN個のデータセンタを備え、帯域幅管理についての性能要件をN個より少ない数のNCSで満たしてしまう場合、データセンタの中にはNCSを構成する必要がないものがあるとするのではなく、一以上のデータセンタであっても単一のNCSで足りるとしてもよい。他の実施形態において、一以上の可用コンテナでノード用メタデータを生成するよう所定のNCS180を構成してもよい。
【0028】
図に示す実施形態において、ネットワーク構成サービスマネジャ222がNCS180の数及び配置を判断してもよい。NCSマネジャ222は、いくつかの実装において、それ自体で複数のハードウェア及び/またはソフトウェアコンポーネントを備え、当該ハードウェア及び/またはソフトウェアコンポーネントの中には、多様な可用ゾーン203のデータセンタ205に分散されるものがあってもよい。図に示す実施形態において、NCSマネジャが、必要に応じてNCS180の構成変更を起動してもよい。例えば、NCSが用いる新型ソフトウェアモジュールを展開する場合、NCSマネジャが指示して展開させてもよい。
【0029】
図に示す実施形態において、プロバイダネットワークの多数の他のサービスが、ネットワーク構成システムと対話してもよい。例えば、統合コンソールサービス278は、クライアント265が所望の資源のネットワーク状態を問い合わせ、要求情報をプログラムで受信することが可能な、1以上のプログラマチックインタフェース240(ウェブページ、API、GUI、及び/またはコマンドラインツールなど)を実施してもよい。統合コンソールサービス278は、
図1の連結ネットワーク図作成装置152の一つの実施例であってよい。プログラマチックインタフェース240により、クライアントが、例えば、特定の時間間隔中、多様なサービスインスタンスまたはインスタンスホストに対する現在の適用帯域幅制限を上下させるなどの構成要求を出せるようにしてもよい。
【0030】
いくつかの実施形態において、デバイス正常性管理サービス276をプロバイダネットワーク202で実施し、多様なインスタンスホスト及びネットワークデバイスから応答性情報を収集(例えば、ハートビート機構を用いて)してもよい。図に示す実施形態において、正常性管理サービス276を用いて、NCS180による入力として使用するネットワーク関連メトリクスを収集してもよく、例えば、正常性状態メッセージ上でネットワークメトリクスをピギーバック伝送するなどする。このように、正常性管理サービス276のノードは、
図1に示すメトリクスコレクタ125の実施例であると見なしてもよい。また、いくつかの実施形態において、正常性管理サービスをメタデータ配布システム127として用いてもよい。例えば、多様なインスタンスホストに送信されるハートビートメッセージが、ピギーバック伝送された分類メタデータを備えてもよい。プロバイダネットワーク内での対象へのサービス妨害攻撃、及び/または、外部対象にプロバイダネットワーク202内から開始されたサービス妨害攻撃を検出するようDDOS検出サービス274を構成し、例えば、所定の一連のIPアドレスに対する異常な高流入出トラフィックパターンの検出などを行ってもよい。潜在的なDOS攻撃を認識すると、DDOS検出サービス274は、潜在的なネットワーク攻撃または侵入について該当するNCS180に入力し、潜在攻撃の影響を軽減するため、NCS180に帯域幅制限を狭くさせるか、少なくとも一時的に、いくつかのインスタンスホストまたはネットワークデバイスに対し他のネットワーク構成オプションへ変更させてもよい。インスタンス配置サービス272は、最新の入手可能なネットワーク関連メトリクス及び構成設定をNCS180から取得し、帯域幅に新規インスタンスを起動する余裕があるインスタンスホストを選択するか、ネットワークトラフィックの変更状態の面から見て既存のインスタンスから移すべきだとするインスタンスホストを選択してもよい。
インスタンスホストにおける分類メタデータの使用
【0031】
種々の実施形態において、上述したように、ネットワーク構成サーバはトラフィック分類メタデータの表示を多様なネットワークアクセス可能サービスのインスタンスホストに送信してもよい。
図3は、少なくともいくつかの実施形態において、仮想化計算サービスのインスタンスホスト144においてトラフィック分類メタデータの解釈が可能なネットワークマネジャモジュールの実施例を示す。インスタンスホスト144は、多種多様なクライアントアクセス可能仮想マシンのインスタンス化及び管理が可能な仮想化管理ソフトウェアスタック(VMSS)310、または計算インスタンス350A及び350Bなどの計算インスタンス350を備えてもよい。いくつかの実装において、VMSS310は、例えば、ハイパーバイザ317、及び、「ドメインゼロ」または「dom0」オペレーティングシステムと呼ばれるオペレーティングシステム315の管理インスタンスを備えてもよい。dom0オペレーティングシステムは、クライアントのために計算インスタンス350が実行を行うクライアントによりアクセスできなくてもよく、むしろ、計算インスタンス350への流入出ネットワークトラフィックの処理を含む、仮想化オペレーティングシステムの多様な管理動作または制御プレーン動作を担当してもよい。
【0032】
図に示す実施形態において、dom0オペレーティングシステム315は、ネットワークマネジャコンポーネント357を含む多様な制御モジュールを備え、当該ネットワークマネジャコンポーネントは、さらに、分類メタデータインタプリタモジュール359を備えてもよい。ネットワークマネジャコンポーネントは、例えば、上記の分類ツリー及び/または分類プロシージャの表示を含む、NCS180により生成されたインスタンスホスト144用の分類メタデータを受信してもよい。インタプリタ359はメタデータを解析し、メタデータに示されたプロシージャを、多様な計算インスタンス350との流入出トラフィックパケットに適用してもよい。例えば、多様なトラフィックカテゴリの帯域幅制限を実施するために、1以上のインスタンスパケットキュー(IPQ)319(例えば、IPQ319A及び319B)を構成してもよい。特定のインスタンス350での特定のカテゴリの流入出トラフィックレートが、所定の時間間隔において当該カテゴリの帯域幅制限を超える場合、流入出パケットの一部を特定の当該インスタンスのIPQ319内のキューに入れてもよい。いくつかの実装において、一以上のパケットキューを所定の計算インスタンスのためにインスタンス化し、例えば、1トラフィックカテゴリにつき1パケットキューを設定してもよい。他の実装において、複数のインスタンス350に関連するキュー状パケットには、単一パケットキューで対応するとしてもよい。また、多様な実施形態において、IPQまたは他の類似構造を用いて、NCSから受信したメタデータに従い、例えば、レイテンシ要件、その他サービス品質目標(例えば、種々のトラフィックカテゴリに関する相対ネットワーク送信プロパティ)、パケットフラグメンテーション設定、またはパケットサイズに応じた設定など、他のネットワーク構成オプションを実施してもよい。
【0033】
図のように、図の実施形態において、各計算インスタンス350は、計算インスタンス350AにはOS370A、計算インスタンス350BにはOS370Bというように、対応するクライアントアクセス可能オペレーティングシステム370を備えてもよい。オペレーティングシステム370はそれぞれ、自身のネットワークスタック372(例えば、インスタンス350Aにはネットワークスタック372A、インスタンス350Bにはネットワークスタック372B)を備え、ネットワークマネジャ357と通信し、流入出トラフィック用のインスタンスホスト144のハードウェアネットワークインタフェースを使用してもよい。クライアントのために計算インスタンス350が実施されるクライアント側から見ると、各インスタンスは不足なく機能的なサーバであり、使用するネットワーク構成技術の実施(IPQでのパケットキュー状態など)をクライアントが詳細に承知していなくてもよい。
図3に示す分類メタデータと同様の分類メタデータの解釈及び使用
技術を、種々の実施形態においても同じく、多様なタイプの記憶装置またはデータベースサービスなど、他のタイプのネットワークアクセス可能仮想化サービスのインスタンスホストに用いてもよいことに注意する。また、いくつかの実施形態において、分類メタデータの少なくとも一部を、VMSS310のネットワークマネジャ357の代わりに、またはネットワークマネジャ357に加え、インスタンス350のネットワークスタック372で解釈及び/または使用してもよいことにも注意する。
メタデータ送信モード
【0034】
種々の実施形態において、NCS180が生成したメタデータ表示を、種々のプロトコルまたは転送モードに従いインスタンスホスト144またはネットワークデバイス145などの対象に提供してもよい。
図4aから
図4cはそれぞれプロトコルの実施例を示し、少なくともいくつかの実施形態において、当該プロトコルを使用して、トラフィック分類メタデータをインスタンスホストに送信してもよい。種々の実施形態において、1以上のプログラマチックインタフェースを用い、NCSまたはメタデータの受信側が使用プロトコルに従いインタフェースを呼び出して、メタデータをインスタンスホストに、または分散システムの他のノードに提供してもよい。
【0035】
図4aに示す実施形態において、分類メタデータを、NCS180により開始された予定「プッシュ」動作401でインスタンスホスト144に(あるいは、ネットワークデバイス145または記憶装置に)送信してもよい。例えば、各自の予定を組んで各NCSを構成し、NCSが所定のメタデータ対象にメタデータを送信する(例えば、毎分、または5分に一度など)ようにしてもよい。いくつかの実装において、メタデータが所定のNCSから種々の対象に送信された実回数は、メタデータの転送自体が引き起こすネットワーク輻輳が起きないよう調整されてもよい。例えば、メタデータが毎分6つのインスタンスホストに所定のNCSからプッシュされる場合、10秒間隔での各インスタンスホストへのメタデータ転送の予定を組んでもよい。
【0036】
図4bに示す実施形態において、トリガイベントがメタデータを転送させるようにしてもよい。例えば、イベント検出器421は、潜在的なDDOSの検出などのイベントを検出したことをNCSに知らせ、NCSはイベントの影響軽減に適したメタデータを生成してもよい。いくつかの実施形態において、特定のタイプのイベントに関し、イベントに即応できるよう、メタデータが生成されるとすぐに最優先で、生成したメタデータのトリガ型プッシュ402を開始してもよい。他のタイプのトリガイベントに関し、例えば、アドミニストレータが既に生成済みのメタデータにオーバーライドするよう要求を出した場合には、メタデータのプッシュを即時または最優先で行う必要はない。
【0037】
図4cに示す実施形態において、インスタンスホスト144は最新分類メタデータのプル要求403をBA180に出してもよく、メタデータは応答404でインスタンスホストに送信されてもよい。多様な実施形態において、
図4aから4cに示す3つの手法のいずれかを組合せて、インスタンスホスト144、ネットワークデバイス145、または記憶装置のいずれかに使用してもよい。少なくとも一つの実施形態において、メタデータ送信に差分手法を用いてもよく、つまり、現メタデータと最新の提供メタデータとの差分のみの表示を、インスタンスホスト、ネットワークデバイス、または記憶装置に送信してもよい。他の実施形態において、メタデータ全体を転送の各回に送信してもよい。
分類ツリー
【0038】
図5は、少なくともいくつかの実施形態において、分散システムのデバイスにおけるネットワーク構成のネットワークトラフィックカテゴリの表示に使用されてもよい分類ツリーデータ構造501の実施例を示す。ツリー501の各ノードは、
図5の各ノードに示す個々の帯域幅制限など、ノードに表示された各カテゴリに関連する一連のネットワーク構
成オプションまたは設定を有してもよい。各ノードに適用するネットワーク構成オプションの他の実施例として、パケットレイテンシ要件または目標、種々のトラフィックカテゴリ間の相対的な優先順位などの他のサービス品質目標、パケットフラグメンテーション/リアセンブリ設定、または、パケットサイズに応じた構成設定を含んでもよい。種々の実施形態において、多様なプロパティの差分に基づきトラフィックカテゴリを定義してもよい。当該プロパティの差分は、例えば、トラフィックと関連するアプリケーションのカテゴリ、対応するコンポーネントが受送信端部にあたるサービス、エンドポイントでのネットワークアドレス(場合により、アドレス自体がアプリケーションタイプを示してもよい)、転送サイズ、クライアントのためにトラフィックが生成されるクライアント、互いに関連したエンドポイントの位置(例えば、プロバイダネットワークノードからの下りパケットの向先がローカルデータセンタ内か、ローカル可用コンテナか、ローカル領域か、プロバイダネットワークの別領域か、またはプロバイダネットワークの外部か)などである。図に示した分類ツリー501において、例えば、ノード504は、一つのクラスのアプリケーション(高性能計算)のトラフィックを示し、ノード520はデータベーストラフィックを示し、ノード506は高性能ブロックストレージトラフィック(すなわち、高入/出力レートをサポートするよう構成されたブロック記憶装置と関連するトラフィック)を示す。ノード520で示されるデータベースカテゴリ内には、位置に基づくサブカテゴリのノードが3つ定義されており、ノード522はイントラデータセンタトラフィック、ノード524はイントラ領域トラフィック、及びノード526は外部領域トラフィックがある。
【0039】
多様なカテゴリ用に定義されるネットワーク構成オプションが帯域幅制限を含む実施形態において、多様なトラフィック集計方針または規則を分類ツリーに適用してもよく、親ノードに対する子ノードの帯域幅制限間の関係性を決定してもよい。例示した実施例において、次に挙げる規則を適用してもよい。(a)ツリー内の子ノードはいずれも、当該親の帯域幅制限を超える帯域幅制限を持たない。(b)ある親ノードの子ノードの帯域幅制限の合計は当該親の帯域幅制限を超えるかもしれないが、所定時間間隔における、子ノードが示すカテゴリの実トラフィックレートの合計は、当該親の帯域幅制限を超えない。
【0040】
当該規則に従い、ルートノード(分類グラフが作成されたインスタンスホストまたはネットワークデバイスに定義されたトラフィックカテゴリの全てをまとめて示す)の帯域幅制限は、K Gビット/秒であり、当該ルートノードのいずれの子ノードの帯域幅制限もK Gビット/秒を超えない。よって、A<K、B<K、C<K、及び、D<Kである。ノード520の場合、子ノード(ノード522、525及び526)の帯域幅制限の合計が親ノードの帯域幅制限になるよう割り当てられ、上記の両規則を満たす。ノード530の場合、総称「その他」トラフィックカテゴリを示し帯域幅制限はD Gビット/秒であり、子ノード532(その他のブロックストレージトラフィック)、534(インターネットトラフィック)、536(イントラサービストラフィック)、及び538(他のいずれのリーフノードにも当てはまらない雑多なまたは未分類トラフィック)の帯域幅制限もそれぞれ、D Gビット/秒である。子ノードの名目帯域幅制限の合計が(この場合4D
Gビット/秒)親ノードの帯域幅制限(D Gビット/秒)を超えるような設定では、上記の第2の規則に従うものと捉えてもよい。原則的に子ノードの各カテゴリのトラフィックレートは最大D Gビット/秒であるが、実際には、任意の所定秒間(またはその他適した時間単位)における全ての子ノードの実トラフィックフロー合計はD Gビット/秒を超えない。このため、「その他のブロックストレージトラフィック」カテゴリ(ノード532)のトラフィックレートが特定秒間に0.6D Gビット/秒である場合、ノード534、536及び538を組み合わせたトラフィックレートは、0.4Dを超えることはない。
【0041】
いくつかの実施形態において、NCS180により所定インスタンスホストまたはネッ
トワークデバイスでの流入出トラフィックについて、それぞれツリーが生成されてもよいが、ネットワーク構成オプション及び/またはカテゴリにおいて、流入トラフィックについてのツリーが流出トラフィックについてのツリーとは異なってもよい。いくつかの実施形態において、分類ツリーの一部または全てのノードに関し、持続的な帯域幅について(例えば、T秒を超える期間での平均帯域幅使用に適用する)、及びバースト帯域幅について(例えば、所定インスタンスホストの持続的な帯域幅制限が1Gビット/秒に設定されている場合であっても、当該インスタンスホストでは、4Gビット/秒の短期バーストトラフィックレートを最長2秒間許可するとしてもよい)、種々の制限値を定義してもよい。既に述べたが、いくつかの実装において、所定インスタンスホスト、ネットワークデバイス、または記憶装置に関するトラフィック分類ヒエラルキを、複数階層に分けず、フラットにしてもよい。
【0042】
いくつかの設定において、分散システムの種々のエンティティの分類ツリーをより高次のツリーに統合することは、管理面の面では有用であってもよい。
図6は、少なくともいくつかの実施形態において、データセンタにおける複数のインスタンスホストに関するネットワークトラフィックカテゴリ情報の結合に使用されてもよい階層式データ構造601の実施例を示す。図のように、データセンタにおける多数のインスタンスホストについてそれぞれ、分類ツリー(Cツリー)を生成してもよく、Cツリー601A、601B、601M、及び601Nなどがある。図に示した実施形態において、データセンタは、多数の種々の空間に配置された複数のサーバラックを備えてもよい。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アドレス、ポートナンバ、または使用するネットワークプロトコルなど、パケットの1以上のヘッダのコンテンツを用いて、パケットのカテゴリを判断してもよく、ボディコンテンツを用いてもよい。プロシージャを用いて所定のトラフィック単位が分類された各カテゴリは、図に示す実施形態において、NCSが生成した分類ツリーの対応ノードに該当してもよい。
【0046】
少なくともいくつかの実施形態において、少なくとも原則として、パケット分類に任意の細かい基準を用い、判断ノード列を任意に長くしてもよい。例えば、分類基準を、パケットボディの具体的なコンテンツを基にするか(例えば、特定のバイト領域「0xff」がパケットのオフセットO1に発生するかどうか)、パケットまたはヘッダコンテンツの任意の組合せを基にするなどしてもよい。分類プロシージャグラフ750のサイズを小さくし複雑さを低減するために、いくつかの実施形態において、複数の結果が得られる判断ノードを用いてもよい。例えば、プロシージャグラフ750において、ルックアップテーブル770を備えるノード705を備える。そのようなルックアップテーブルには列が複数あり、所定のトラフィック単位のプロパティ(パケットの送付先IPアドレスなど)を基にしてそれぞれインデックス化または選択され分類判断されてもよい。ノード705の実施例において、分類判断は、パケットがカテゴリC2、C3またはC4に属するかどうかについてなされる。判断ノード列を追加してパケットを評価し、分類判断する場合もある。例えば、ルックアップテーブルのエントリが、他の分類グラフまたはサブグラフへのポインタとしての機能を果たしてもよい。
【0047】
図8は、少なくともいくつかの実施形態において、トラフィック分類プロシージャグラフでのルックアップテーブルノード805の使用実施例を示す。図に示す実施形態において、ハッシュ関数850をネットワークパケット810部に適用し、パケットのカテゴリ分けに使用するノード805のルックアップテーブル770Aのエントリを特定してもよい。ルックアップテーブルノード805自体には、プロシージャの他の判断ノードで評価された後に達した場合もある。すなわち、ハッシュ関数850を適用する前に、少なくともいくつかのレベルのカテゴリ分けがパケット810に対し既になされていてもよい。図に示す実施例でのパケットは、送付先IPアドレス「P.Q.R.S」801であるアウトバウンドパケットであり、送付先IPアドレスの4つの要素のうち第三要素「R」をハッシュ関数850のへの入力に使用し、パケット810に該当するルックアップテーブルのエントリを判断する。多様な実施形態において、パケット810の複数プロパティのい
ずれかをそのようなハッシュ関数への入力に使用してもよく、例えば、送付先IPアドレスまたはソースIPアドレスの他の部分の値、他のヘッダフィールド802の値、またはパケットのボディ803のコンテンツなどを使用してもよい。いくつかの実施形態において、パケットのどのプロパティを使用しルックアップテーブルのエントリを選択するかについての規則、及び、プロパティに適用する関数(ハッシュ関数850など)は、分類メタデータと合わせてNCS180が、インスタンスホストまたはネットワークデバイスなどの対象デバイスでのコントロールモジュールに提供してもよい。
【0048】
場合により、選択する(例えば、送付先IPアドレス要素をハッシュ化した結果として)ルックアップテーブルのエントリは、該当するパケットのトラフィックカテゴリを直接示してもよい。例えば、
図8において、ルックアップテーブル770Aの要素から1つを選択するとカテゴリAになる。ルックアップテーブルの他のエントリはそれ自体が、
図8のグラフ880A及び880Bなど、追加プロシージャグラフへのポインタとしての役割を果たし、パケット810のカテゴリを判断するためには、当該追加プロシージャグラフの判断ノードはナビゲートされなくてはならない。異なるグラフのノードで基準を評価した結果到達するような追加プロシージャグラフを、本明細書ではサブグラフともいう。図に示した実施例において、判断ノード851、852(それ自体がルックアップテーブル770Bを備えたノード)、及び/または853に示す基準は、ハッシュ関数850が770Aの一つのエントリに繋がっているかどうかを評価する必要があるが、判断ノード854、855及び/または856が示す基準は、ハッシュ関数850がルックアップテーブル770Aの異なるエントリを選択したかを評価する必要があってもよい。
図8の実施例において、プロシージャグラフ880Bに達し、要素854及び855に示す基準を満たせば、例えば、パケット810はトラフィックカテゴリLに属すると見なしてもよい。ルックアップテーブル770を分類プロシージャグラフ750の多様なノードに含めることで、複雑な細分化ロジックを使って分類する場合でも、トラフィック分類ロジックを大幅に縮小して表示できるようにしてもよい。
トリガイベントに対するネットワーク構成システムの応答性
【0049】
いくつかの実施形態において、上述したように、ネットワーク攻撃または侵入など、損害を与え得るイベントの検出などのイベントに応答して、帯域幅管理を判断してもよい。例えば、分散システムの特定のサブセットに設定すべきNCSの数、または、ネットワーク構成システムに必要な計算能力及びメタデータ分散能力の種類を決定する際など、ネットワーク構成システムを構成する際に検討すべき要素の一つに、そのようなイベントに対する応答性が必要であるとしてもよい。
図9は、少なくともいくつかの実施形態において、ネットワーク構成サービスの1以上のパラメータ値の判断に利用されてもよい応答性メトリクスの実施例を示す。
【0050】
図9は、時間値が左から右に向かって増加する例示的なタイムラインを示す。時間T1において、ブロック902に示すように、集中ネットワーク構成を実施している分散システムのセキュリティサービスが、DDOS攻撃などの潜在的なネットワーク攻撃を検出する。潜在的な攻撃を、例えば、分散システムの1以上のノードに対する流出入トラフィックレートが突如増加したことを基に特定してもよい。そのような攻撃は、分散システムの内部(プロバイダネットワークの一連の計算インスタンスを用いて実施されているe-ビジネスのウェブサイトなど)、または、分散システムの外部(例えば、高レートでプロバイダネットワークの一連の計算インスタンスから外部のウェブサイトに、要求が繰り返し送信されるかもしれない)の、1以上の対象に向けられるかもしれない。正当な理由でトラフィックが増加する場合があってもよい。例えば、ウェブサイトで、販売開始する製品への関心が突如バーストするなどである。しかし、多くの実施形態において、セキュリティサービスは高度な分析技術を採用してそのような誤検出が起きる可能性を低減してもよい。
【0051】
潜在的な攻撃が実際の攻撃となるかどうかにかかわらず、図に示す実施形態において、例えば、新規の分類メタデータ、及び/または、分散システムに適したノードに対する帯域幅制限などの新規の構成オプションを設け、早急に新規メタデータを適用するなどして対応するようネットワーク構成システムを構成してもよい。ブロック904に示すように、一連のノードに関する変更メタデータを、図に示すタイムラインにおける時間T2で生成してもよい。例えば、IPアドレスK.L.M.NからIPアドレスE.F.G.Hに向けられたアウトバウンドDDOS攻撃を表すトラフィックが検出された場合、当該IPアドレスに対し帯域幅制限の適用を担うNCSは新規メタデータを生成してもよい。新規メタデータは、例えば、K.L.M.Nから発するか、E.F.G.Hで受信する全てのトラフィックに、単に新規帯域幅制限(少なくとも一時的に)を課すだけでもよい。或いは、1以上の新規トラフィックカテゴリを、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】
適切な数のNCS180を、要素1001に対応する動作で判断したパラメータに従い、選択した位置でインスタンス化してもよい(要素1007)。NCSと、分散システムまたはプロバイダネットワークの他の多様な要素との間にそれぞれ、ネットワーク接続を
確立してもよい(要素1010)。例えば、NCSとインスタンスホスト144との間、NCSとNCSによる判断を実施するその他ネットワークデバイス145との間、NCSとNCSの判断に影響を与える入力データソースとの間、及び、NCSとNCSからのネットワーク情報の継続的な取得に関与する任意の出力先との間などがある。少なくともいくつかの実施形態において、TLS(Transport Layer Security)、SSL(Secure Sockets Layer)などの安全なネットワークプロトコルを、NCSと、分散システムのその他要素の少なくとも一部との間のネットワーク接続に使用してもよい。
【0056】
図11は、少なくともいくつかの実施形態において、ネットワーク構成サービスのトラフィック分類メタデータを生成し配布するよう実施されてもよい動作態様を示すフロー図である。図に示す実施形態において、NCSは反復手法を採用してもよい。当該手法では、イテレーション毎に一連の入力を用い、一連の対象ノード(例えば、インスタンスホスト)に配布され適用されるネットワーク管理パラメータを判断する。その後、メトリクスは、対象ノード及びその他ソースから収集され、入力値としてフィードバックされ、次のイテレーションに対するパラメータに反映させる、またはパラメータを判断する。要素1101に示すように、所定のNCSは、インスタンスホスト、及び/または、スイッチ、ルータ、ゲートウェイなどのネットワークデバイスなど、分散システムの多様なノードから入手された一連のネットワーク関連メトリクスを、所定の時間間隔に受信してもよい。例えば、測定流入出トラフィックレート、パケットロスレート、パケット調整レートなどを含むメトリクスを使用し、NCSが次のイテレーションのトラフィック分類メタデータを生成してもよい。場合により、例えば、正常性監視サービスノードなど、メトリクス収集システムノードを介してNCSにメトリクスを提供してもよい。さらに、NCSは、図に示す実施形態において、セキュリティ関連サービス、各IPアドレス専用トラフィックアグリゲータ、各クライアント専用トラフィックアグリゲータなどを含む他の入力ソースから多様な入力も取得してもよい。クライアント及び/またはアドミニストレータは、NCSが1以上のトラフィックカテゴリに以前適用した帯域幅制限を広げるか狭くする要求などの構成要求をNCSに出してもよい。また、そのような構成要求を、トラフィック分類メタデータの次のイテレーションを判断する時に、入力として使用してもよい。
【0057】
図に示す実施形態において、NCSでは、メトリクス及び受信入力値を用いて、例えば、グローバル及び/またはローカルネットワーク管理方針の面から、トラフィック分類メタデータを判断してもよい(要素1104)。グローバル方針は、例えば、ネットワークインフラの様々な部分での対象利用制限、同様のサービスレベルを契約した多様なクライアントからのトラフィック処理に関する公平性要件、実施中の多様なネットワークアクセス可能サービスへのネットワークトラフィックに対する相対的な優先度などを示してもよい。ローカル方針は、例えば、他の可用コンテナまたはデータセンタとはネットワークインフラ及び能力が異なるような所定の可用コンテナまたは所定のデータセンタに適用する規則を示してもよい。分散システムの所定対象ノード用に生成された分類メタデータは、対象ノードで使用されるトラフィック分類ヒエラルキ(例えば、
図5で示すツリーデータ構造に類似した構造で表示可能なヒエラルキ)、及び、当該ヒエラルキで定義されたカテゴリにネットワークトラフィック単位を分類するのに使用されるプロシージャまたは一連の規則(例えば、
図7で示すグラフに類似したグラフで表示可能なプロシージャ)を含んでもよい。ヒエラルキで定義されたトラフィックカテゴリ毎に、1以上の該当する帯域幅制限などのネットワーク構成オプションを判断してもよく、例えば、平均トラフィックに対し定義した帯域幅制限、及び、短期バースト、レイテンシ要件、パケットサイズに応じた要件、または優先度設定に対し定義した異なる帯域幅制限などである。場合により、一連のカテゴリ及び/またはオプションのそれぞれを流入出トラフィックについて定義してもよい。少なくともいくつかの実施形態において、分類ヒエラルキ及び/またはプロシージャを、種々のインスタンスホスト及び/またはネットワークデバイス用にカスタマイズ
してもよい。例えば、1組のクライアントアプリケーションに使用している所定のホストH1には、別の1組のクライアントアプリケーションが実施されている別のホストH2とは異なるトラフィックカテゴリが定義され、異なる帯域幅制限が当該カテゴリに課されてもよい。
【0058】
図に示す実施形態において、トラフィック分類ヒエラルキ及び分類プロシージャの各移動可能表示またはコード化を、NCSが対象ノードへの送信用に生成してもよい(要素1107)。いくつかの実装においてJSON、XML、YAMLなどの業界の標準プロトコルまたは言語を使用してもよく、他の実装では独自コード化スキームを使用してもよい。移動可能表示を、メタデータが適用または使用される対象に送信してもよい(要素1110)。少なくとも一つの実装において、分類カテゴリ及びプロシージャ双方に対し、個別コード化または統合コード化してもよく、他の実装では分類カテゴリ及びプロシージャの個別表示が使用されてもしてもよい。いくつかの実施形態において、例えば、前回イテレーションから変更があったメタデータ部分のみを対象に送信する差分メタデータ送信技術を用いてもよい。他の実施形態において、イテレーション毎にメタデータ全体を送信するフル送信手法を用いてもよい。多様な実施形態において、予定プッシュ送信(NCSが主導して対象にメタデータをプッシュする)、プル送信(対象からの要求に応答してNCSが分類メタデータを送信する)、及び、イベントトリガ型メタデータ送信(所定のイベントタイプを検出するとNCSがメタデータを生成及び/または送信する)を組み合せて用いてもよい。所定のイテレーションでメタデータを適切な対象に送信した後、NCSは、例えば、要素1101に対応する動作から次へと繰り返すなどして、次のイテレーションを開始してもよい。
【0059】
分散システムの対象ノードにおいて、メタデータ表示を受信し解釈するよう制御モジュール(
図3に示すネットワークマネジャ357など)を構成してもよい。メタデータを用いて、パケットなどのネットワークトラフィック単位を分類し、該当する帯域幅制限を適用してトラフィック単位送信の予定策定及び/または調整してもよい(要素1113)。いくつかの実装において、ノードで既に利用可能な「tc」などの、オペレーティングシステムのユーティリティまたはツールを用いて、NCSが生成したロジックを実行してもよい。他の実装において、カスタムツールまたはユーティリティを使用してもよい。メトリクスは、例えば、多様なパフォーマンスツールなどを用いてターゲットノードから収集され、NCSへの入力として用いられてもよい。
【0060】
図12は、少なくともいくつかの実施形態において、トリガイベントに応答してネットワーク管理パラメータを変更するよう実施される動作態様を示すフロー図である。要素1201に示すように、潜在的なDDOS攻撃などの、トラフィック分類メタデータの変更に繋がるイベントを検出してもよい。いくつかの実施形態において、プロバイダネットワークは1以上のセキュリティサービスを設定し、多様にある潜在的攻撃を示す不審なトラフィックパターンを特定してもよい。そのようなサービスはネットワーク構成システムと通信してもよい。図に示す実施形態において、攻撃から影響を受けるか、攻撃に加担してしまう分散システムの特定ノード(例えば、インスタンスホスト、及び/または、スイッチ、ルータなどのネットワークデバイス)を、例えば、そのようなセキュリティサービスによって、NCSによって、または、セキュリティサービスとNCSとの組み合わせによってのいずれかで特定してもよい(要素1204)。
【0061】
一連の変更トラフィック分類メタデータをNCSで生成し、攻撃の影響を軽減させてもよい(要素1207)。変更部分には、例えば、新しく定義された(例えば、不審なトラフィックの送信及び/または受信にかかわる特定ノードのアドレスを基に)トラフィックカテゴリ、及び/または、新しく適用される帯域幅制限またはその他ネットワーク構成オプションを含んでもよい。いくつかの実施形態において、次に、新メタデータを、分散シ
ステムの一連の選択ノードに送付してもよく、当該選択ノードには、攻撃に係わるか攻撃対象となる特定のノード、及び/またはその他ノード(例えば、不審なトラフィックが使うパス上で仲介となるネットワークデバイス)を含んでもよい。
【0062】
例えば、状態の検出から新規メタデータの適用までの時間など、トリガ状態の対応に要する時間を計測し記録してもよい(要素1210)。そのようなトリガイベントに対するネットワーク構成システムの応答性、及び/または、ネットワーク構成システムが取る動作の効果について傾向を継続して分析し、構成変更が必要かを判断してもよい(要素1213)。応答性が不十分であるとわかれば、例えば、多数ある構成変更のうちいずれかを実行してもよい。例えば、NCSの数を増やす、イベントデテクタとNCSとの間の接続性を向上させる、メタデータ分散システムを向上させる、及び/または、NCSまたは対象ノードにおけるロジックを変更し、より効果的に検出イベントに対応させるなどである。
【0063】
図13は、少なくともいくつかの実施形態において、ネットワーク関連状態情報の統合図を分散システムのクライアントに提供するよう実施されてもよい動作態様を示すフロー図である。要素1301に示すように、1以上のプログラマチックインタフェース(ウェブページまたはコンソール、API、GUI、或いは、コマンドラインツールなど)を、クライアントに係わる多様な分散システム資源のネットワーク状態の統合カスタマイズ図を提供するために設定してもよい。例えば、クライアントは、割り当てられた仮想化計算サービスの計算インスタンスを多数有し、直近15分間の帯域幅調整でどの特定インスタンスが影響を受けたかを判別しようとしてもよい。プログラマチックインタフェースにより、クライアントは多様なフィルタが使用可能になり、表示するネットワークプロパティ、及び/または、プロパティが表示される一連の資源を指定してもよい。
【0064】
メトリクス及び関連資源を指定するネットワーク状態要求を、そのようなインタフェースを介して受信してもよい(要素1304)。ネットワーク構成システムは、例えば、メトリクスデータベース190から、またはNCSにおけるキャッシュから、要求されたメトリクスを検索してもよい(要素1307)。いくつかの実施形態において、要求対応に適した分類メタデータを分類データベース192から、またはNCSにおけるメタデータキャッシュから検索してもよい(要素1310)。収集した情報を用いて、ネットワーク状態要求に対する応答を作成しプログラマチックインタフェースを介して要求側に提供してもよい(要素1313)。
【0065】
多様な実施形態において、
図10、11、12、及び13のフロー図で示す動作以外の動作で、ネットワーク構成サービス機能を実行してもよく、また、示した一部の動作を実施しなくてもよく、或いは、異なる順でまたは経時的ではなく平行して実行してもよいことに注意する。例えば、いくつかの実施形態において、
図10に示した複数の動作流れを平行して実行し、各対象ノード用の一連の分類メタデータをそれぞれ生成し送信するような、複雑化したNCSを実施する場合もあってよい。
【0066】
本開示の実施形態を次に挙げる条項の観点で説明する。
1. 複数の計算装置を備えるシステムにおいて、当該計算装置は、
ネットワーク構成サービスの1以上の集中サーバにおいて複数のソースからメトリクスを取得し、当該メトリクスは、プロバイダネットワークのネットワークアクセス可能サービスを実施するよう構成された一連のノードにおいて収集されたトラフィックメトリクスを含み、
当該ネットワーク構成サービスにおいて、当該メトリクスの少なくとも一部及びネットワーク管理方針の少なくとも一部に基づき、当該一連ノードの特定ノードにおいて当該ネットワークアクセス可能サービスのサービスインスタンスと関連する特定のトラフィック
カテゴリにネットワーク構成オプションを適用するのに使用されるメタデータを判断し、
当該一連ノードの特定ノードにおいて制御モジュールに当該メタデータの表示を送信し、
当該特定ノードにおいて、ネットワーク構成サービスで判断された当該メタデータにより示されるプロシージャを実施し、1以上のネットワーク送信の予定を組むよう実装される。
2. 1項に記載のシステムにおいて、
当該ネットワーク構成オプションが、1以上の(a)帯域幅制限、(b)レイテンシ制約、(c)サービス品質目標、(d)パケットフラグメンテーション構成設定、または(e)少なくとも一部のパケットサイズに応じた構成設定、を備える、当該システム。
3. 1項に記載のシステムにおいて、
当該複数ソースが、1以上の(a)サービス妨害検出器、(b)各ネットワークアドレス専用トラフィックメトリクス収集サービス、または(c)各クライアント専用トラフィックメトリクス収集サービスを備える、当該システム。
4. 1項に記載のシステムにおいて、
当該メタデータの当該表示が、(a)既定予定、(b)トリガイベントの発生、または(c)当該特定ノードからの要求、のうち一つの少なくとも一部に基づき送信される、当該システム。
5. 1項に記載のシステムにおいて、
当該ネットワーク構成サーバで判断された当該メタデータが、ネットワークトラフィック単位を当該特定カテゴリに、(a)当該ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、(b)クライアントのために当該ネットワークトラフィック単位が生成されるクライアント、または(c)アプリケーションのために当該ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される1以上の規則を備える、当該システム。
6. 1項に記載のシステムにおいて、
当該複数計算装置はさらに、
(a)当該ネットワークアクセス可能サービスのクライアントまたは(b)当該ネットワークアクセス可能サービスのアドミニストレータ、のどちらかにより出された構成要求の指示を受信し、
当該構成要求に従い当該メタデータの1以上の要素を変更する、
よう構成された、当該システム。
7. 複数の計算装置によって実行する方法において、当該実行では、
ネットワーク構成サーバにおいて、プロバイダネットワークのネットワークアクセス可能サービスに関連する複数のソースからメトリクスを取得し、
当該ネットワーク構成サーバにおいて、当該メトリクスの少なくとも一部に基づき、当該ネットワークアクセス可能サービスのサービスインスタンスと関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用されるプロシージャを判断し、
当該ネットワーク構成サーバから、当該サービスインスタンスに関連する当該プロバイダネットワークの特定ノードに、当該プロシージャの表示を送信し、
当該特定ノードにおいて、当該ネットワーク構成サーバで判断された当該プロシージャを実施し、当該ネットワーク構成オプションに従い1以上のネットワーク送信の予定を組む。
8. 7項に記載の方法において、当該ネットワーク構成オプションが、1以上の(a)帯域幅制限、(b)レイテンシ制約、(c)サービス品質目標、(d)パケットフラグメンテーション構成設定、または(e)少なくとも一部のパケットサイズに応じた構成設定、を備える、当該方法。
9. 7項に記載の方法において、当該複数ソースが、1以上の(a)当該特定ノード、(b)サービス妨害検出器、(c)各ネットワークアドレス専用トラフィック収集サービス
、または(d)各クライアント専用トラフィック収集サービス、を備える、当該方法。
10. 7項に記載の方法において、当該表示の該送信が、(a)既定予定、(b)トリガイベントの発生、または(c)当該特定ノードからの要求、のうち一つの少なくとも一部に基づき開始される、当該方法。
11. 7項に記載の方法において、当該ネットワーク構成サーバで判断された当該プロシージャが、ネットワークトラフィック単位を当該特定カテゴリに、(a)当該ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、(b)クライアントのために当該ネットワークトラフィック単位が生成されるクライアント、または(c)アプリケーションのために当該ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される1以上の規則を備える、当該方法。
12. 7項に記載の方法において、当該プロバイダネットワークが、個々に故障プロファイルを有する複数の可用コンテナを備え、当該複数計算装置による実行ではさらに、
少なくとも一つのネットワーク構成サーバを、当該複数可用コンテナの各可用コンテナにおいて構成する、当該方法。
13. 7項に記載の方法において、当該複数計算装置による実行ではさらに、
ネットワーク構成オプションの変更に繋がるイベントの検出から、変更されたプロシージャを実施し当該変更を当該ネットワーク構成オプションに適用するまでの時間間隔に関連する性能要件の少なくとも一部に基づき、インスタンス化される多数のネットワーク構成サーバを判断する、当該方法。
14. 7項に記載の方法において、当該プロシージャの該判断を、(a)当該ネットワークアクセス可能サービスのクライアント、または(b)当該ネットワークアクセス可能サービスのアドミニストレータ、のどちらかからの要求に応答して実行する、当該方法。
15. 7項に記載の方法において、当該プロシージャの当該表示の送信先である当該特定ノードが、(a)サービス単位で当該ネットワークアクセス可能サービスを実施するよう構成可能なインスタンスホスト、(b)スイッチ、(c)ルータ、(d)ゲートウェイ、(e)ロードバランサ、または(f)記憶装置、のいずれか一つを備える、当該方法。
16. 7項に記載の方法において、当該複数計算装置による実行ではさらに、
1以上のプログラマチックインタフェースを介して、当該ネットワークアクセス可能サービスをサポートするよう構成可能な複数のノードのネットワーク状態の連結図を提供する、当該方法。
17. 7項に記載の方法において、当該複数計算装置による実行ではさらに、
当該ネットワーク構成サーバから、当該ネットワークアクセス可能サービスに関連するインスタンス配置コンポーネントに、当該ネットワークアクセス可能サービスの複数のインスタンスホストのネットワーク状態情報の指示を提供し、また、当該ネットワークアクセス可能サービスのサービスインスタンスが開始される特定のインスタンスホストを選択するのに当該指示を利用するよう当該インスタンス配置コンポーネントが構成される、当該方法。
18. プログラム命令を保存する非一時的コンピュータアクセス可能記憶媒体において、1以上のプロセッサ上で当該プログラム命令が実行されると、当該プログラム命令は、
ネットワーク関連メトリクスを複数のソースから取得し、
1以上のネットワーク管理方針に従い当該ネットワーク関連メトリクスの少なくとも一部に基づき、計算装置に関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用される一連の規則を判断し、
当該計算装置にネットワーク構成サーバから、当該ネットワーク構成オプションに従い1以上のネットワーク送信の予定を組むのに使用される当該一連規則の表示を送信する。19. 18項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該ネットワーク構成オプションが、1以上の(a)帯域幅制限、(b)レイテンシ制約、(c)サービス品質目標、(d)パケットフラグメンテーション構成設定、または(e)少なくとも一部のパケットサイズに応じた構成設定、を備える、当該記憶媒体。
20. 18項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該複数ソースが、1以上の(a)当該計算装置、(b)サービス妨害検出器、(c)各ネットワークアドレス専用トラフィック収集サービス、または(d)各クライアント専用トラフィック収集サービス、を備える、当該記憶媒体。
21. 18項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該命令が当該1以上のプロセッサ上で実行されると、当該命令が、
当該1以上のネットワーク管理方針に従い当該ネットワーク関連メトリクスの少なくとも一部に基づき、別の計算装置において個々のトラフィックカテゴリに1以上のネットワーク構成オプションを適用するのに使用される別の一連の規則を判断し、
当該別の計算装置に、当該別の一連規則の表示を送信する、当該記憶媒体。
22. 18項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該一連規則が、ネットワークトラフィック単位を当該特定のカテゴリに、(a)当該ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、(b)クライアントのために当該ネットワークトラフィック単位が生成されるクライアント、または(c)アプリケーションのために当該ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される1以上の規則を備える、当該記憶媒体。
23. 18項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該計算装置が、(a)仮想化計算サービス、(b)記憶サービス、または(c)データベースサービス、のいずれか一つを備えるネットワークアクセス可能サービスのサービスインスタンスを実施するよう構成される、当該記憶媒体。
24. 複数の計算装置を備えるシステムにおいて、当該計算装置は、
ネットワーク構成サーバにおいて、分散システムのネットワーク管理方針の少なくとも一部に基づき、ネットワークトラフィックカテゴリのヒエラルキ、及び、当該ヒエラルキの当該ネットワークトラフィックカテゴリに関連する個々のネットワーク構成オプションを構築して、当該分散システムの特定の計算装置に適用し、
当該特定計算装置においてネットワークトラフィック単位を当該ヒエラルキのネットワークトラフィックカテゴリに分類するのに使用可能なプロシージャの1以上のステップを、当該ネットワーク構成サーバにおいて判断し、
当該ネットワーク構成サーバから当該特定計算装置に、当該ヒエラルキを示す第一データ構造及び当該プロシージャを示す第二データ構造のそれぞれの表示を送信し、
当該特定計算装置において当該第二データ構造に示された当該プロシージャを使って、特定ネットワークトラフィック単位が属する当該ヒエラルキの特定ネットワークトラフィックカテゴリを特定し、
当該特定ネットワークトラフィックカテゴリについて当該第一データ構造に示された特定のネットワーク構成オプションに従い、当該特定ネットワークトラフィック単位を送信する、よう構成される。
25. 24項に記載のシステムにおいて、当該特定ネットワーク構成オプションは、1以上の(a)帯域幅制限、(b)レイテンシ制約、(c)サービス品質目標、(d)パケットフラグメンテーション構成設定、または(e)少なくとも一部のパケットサイズに応じた構成設定、を備える、当該システム。
26. 24項に記載のシステムにおいて、当該第一データ構造が特定の親ノードが複数の子ノードを有するツリーを備え、また、当該ツリーに関連する帯域幅集計方針に従い、特定の時間間隔中では当該複数子ノードに関連するトラフィックの実転送レートの合計値が、当該特定親ノードに対し示された帯域幅制限を超えない、当該システム。
27. 24項に記載のシステムにおいて、カテゴリの当該ヒエラルキが、当該特定ネットワークカテゴリとは、(a)当該ネットワークトラフィックの1以上のネットワークエンドポイントアドレス、(b)クライアントのために当該トラフィックが生成されるクライアントにより指示される1以上のプロパティ、または(c)アプリケーションのために当該トラフィックが生成されるアプリケーションカテゴリ、の少なくとも一つが異なる別の
ネットワークトラフィックカテゴリを備える、当該システム。
28. 24項に記載のシステムにおいて、当該第二データ構造が、続けて詳細分類された当該ヒエラルキのカテゴリを表す列に配列された複数の判断ノードを備える、当該システム。
29. 24項に記載のシステムにおいて、当該第二データ構造が、当該第二データ構造を用いて分類される当該ネットワークトラフィック単位の1以上のプロパティに基づきインデックス化された複数のエントリを有するルックアップテーブルを表示する少なくとも一つの判断ノードを備える、当該システム。
30. 複数の計算装置によって実行する方法において、当該実行では、
ネットワーク構成サーバにおいて、1以上の階層を備えるネットワークトラフィックカテゴリのヒエラルキ、及び、当該ヒエラルキの当該ネットワークトラフィックカテゴリに関連する個々のネットワーク構成オプションを生成し、
当該ネットワーク構成サーバにおいて、ネットワークトラフィック単位を当該ヒエラルキのネットワークトラフィックカテゴリに分類するのに使用可能なプロシージャの1以上のステップを判断し、
当該ネットワーク構成サーバから特定の計算装置に、当該ヒエラルキ及び当該プロシージャを示す1以上のデータ構造のそれぞれの表示を提供し、
当該プロシージャを使って、当該ネットワークトラフィックカテゴリについて当該ヒエラルキに示された特定のネットワーク構成オプションに従いネットワークトラフィックカテゴリが判断されるネットワークトラフィック単位を、当該特定計算装置から送信する。31. 30項に記載の方法において、当該特定ネットワーク構成オプションが、1以上の(a)帯域幅制限、(b)レイテンシ制約、(c)サービス品質目標、(d)パケットフラグメンテーション構成設定、または(e)少なくとも一部のパケットサイズに応じた構成設定、を備える、当該方法。
32. 30項に記載の方法において、当該1以上のデータ構造が当該ヒエラルキを示す第一データ構造を備え、当該第一データ構造は特定の親ノードが複数の子ノードを有するツリーを備え、また、当該ツリーに関連する帯域幅集計方針に従い、特定の時間間隔中では当該複数子ノードに関連するトラフィックの実転送レートの合計値が、当該特定親ノードに対し示された帯域幅制限を超えない、当該方法。
33. 30項に記載の方法において、カテゴリの当該ヒエラルキが、当該特定ネットワークトラフィックカテゴリとは、(a)当該ネットワークトラフィックの1以上のネットワークエンドポイントアドレス、(b)クライアントのために当該トラフィックが生成されるクライアントにより指示される1以上のプロパティ、(c)アプリケーションのために当該トラフィックが生成されるアプリケーションカテゴリ、または、(d)当該トラフィックが生成されるネットワークアクセス可能サービスの指示、の少なくとも一つが異なる別のネットワークトラフィックカテゴリを備える、当該方法。
34. 30項に記載の方法において、当該1以上のデータ構造が、続けて詳細分類された当該ヒエラルキのカテゴリを表す列に配列された複数の判断ノードを備える特定のデータ構造を備える、当該システム。
35. 34項に記載の方法において、当該特定データ構造が、当該特定データ構造を用いて分類される当該ネットワークトラフィック単位の1以上のプロパティに基づきインデックス化された複数のエントリを有するルックアップテーブルを備える少なくとも一つの判断ノードを備える、当該方法。
36. 35項に記載の方法において、当該1以上のプロパティが、(a)送信先IPアドレスの少なくとも一部、(b)ソースIPアドレスの少なくとも一部、(c)ヘッダの少なくとも一部、(d)ボディコンテンツの少なくとも一部、または(e)ネットワークトラフィック単位に関連するクライアント識別子の少なくとも一部、のいずれか一つを備える、当該方法。
37. 36項に記載の方法において、当該複数エントリの特定エントリが、当該特定エントリに関連する基準を満たすネットワークトラフィック単位を分類するのに使用される別
の判断ノードの指示を備える、当該方法。
38. 30項に記載の方法において、当該1以上のデータ構造の当該表示が、当該特定計算装置に、(a)既定予定、(b)トリガイベントの発生、または(c)当該特定計算装置からの要求、のうち一つの少なくとも一部に基づき提供される、当該方法。
39. 30項に記載の方法において、該1以上のデータ構造が、1以上の(a)サービス妨害検出器、(b)各ネットワークアドレス専用トラフィックメトリクス収集サービス、(c)各クライアント専用トラフィックメトリクス収集サービス、または(d)当該分散システムの複数の計算装置、から受信されたメトリクスに応答して生成される、当該方法。
40. 30項に記載の方法において、当該1以上のデータ構造の当該表示が、(a)JSON(JavaScript Object Notation)、(b)YAML、(c)XML(Extensible Markup Language)、または(d)独自コード化スキーム、のうちの一つに従いフォーマットされる、当該方法。
41. プログラム命令を保存する非一時的コンピュータアクセス可能記憶媒体において、1以上のプロセッサ上で当該プログラム命令が実行されると、当該プログラム命令は、
ネットワーク構成サーバにおいて、ネットワークトラフィックカテゴリの分類、及び、当該分類の当該ネットワークトラフィックカテゴリに関連する個々のネットワーク構成オプションを生成し、
当該ネットワーク構成サーバにおいて、ネットワークトラフィック単位を当該分類のネットワークトラフィックカテゴリに分類するのに使用可能なプロシージャの1以上のステップを判断し、
当該ネットワーク構成サーバにおいて、当該分類及び当該プロシージャを示す1以上のデータ構造を構成し、
当該ネットワーク構成サーバから特定の計算装置に、当該特定計算装置においてネットワーク送信の予定を組むのに使用される当該1以上のデータ構造の表示を提供する。
42. 41項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該分類のネットワークトラフィックカテゴリに関連する特定のネットワーク構成オプションが、1以上の(a)帯域幅制限、(b)レイテンシ制約、(c)サービス品質目標、(d)パケットフラグメンテーション構成設定、または(e)少なくとも一部のパケットサイズに応じた構成設定、を備える、当該記憶媒体。
43. 41項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該1以上のデータ構造が特定の親ノードが複数の子ノードを有するツリーを備え、また、当該ツリーに関連する帯域幅集計方針に従い、特定の時間間隔中では当該複数子ノードに関連するトラフィックの実転送レートの合計値が、当該特定親ノードについて示された帯域幅制限を超えない、当該記憶媒体。
44. 41項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該分類が第一ネットワークトラフィックカテゴリ及び第二ネットワークトラフィックカテゴリを備え、当該第一ネットワークトラフィックカテゴリは、当該第二ネットワークトラフィックカテゴリとは、(a)当該ネットワークトラフィックの1以上のネットワークエンドポイントアドレス、(b)クライアントのために当該トラフィックが生成されるクライアントにより指示される1以上のプロパティ、(c)アプリケーションのために当該トラフィックが生成されるアプリケーションカテゴリ、または(d)当該トラフィックが生成されるネットワークアクセス可能サービスの指示、の少なくとも一つが異なる、当該記憶媒体。45. 41項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該1以上のデータ構造が、続けて詳細分類されたヒエラルキのカテゴリを表す列に配列された複数の判断ノードを備える、当該記憶媒体。
46. 41項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該以上のデータ構造の当該表示が、(a)JSON(JavaScript Object Notation)、(b)YAML、(c)XML(Extensible Markup
Language)、または(d)独自コード化スキーム、のうちの一つに従いフォー
マットされる、当該記憶媒体。
ユースケース
【0067】
一組に集中させたネットワーク構成サーバを構築し分散システムの多数のノードにおいてネットワークトラフィックを形成する前述の技術は、多くの場合有用であってもよい。例えば、プロバイダネットワークは、複数のデータセンタに分散された何百何千ものインスタンスホスト及び多数のネットワークデバイスを備え、プロバイダネットワークの収入の少なくとも一部をインスタンスホストとのネットワーク流入出トラフィック量に基づき得てもよい。各インスタンスホストまたはネットワークデバイスにおいて、ローカルモジュールを用いてネットワーク管理判断を行うと、そのような大規模環境においては数多くの問題を引き起こすかもしれない。第一に、所定のインスタンスホストにおいて、高度なネットワーク管理判断に要する全ての入力を入手することは出来ないかもしれない。第二に、インスタンスホストにおいて必要とされる判断ロジックが複雑なため、インスタンスホストには相当な量の計算能力が必要となり、クライアントに求められる、残るサービスインスタンス用計算能力が減少するかもしれない。ネットワーク管理ロジックの変更が必要な場合、変更内容が全インスタンスホストに送信、適用される必要があり、資源が集中した間違いが起きやすい実行といえるかもしれない。
【0068】
上記とは違い、トラフィック形成に使用される判断ロジックを少数のネットワーク構成サーバに分離することで、一連のより多くのソースから入力が収集され、より豊富な情報量での判断を行えるようにしてもよい。ネットワーク構成サーバは、他のサービスと共有される必要がない専用計算資源を使って実施され、計算能力の競合が起きないようにしてもよい。何百何千ものインスタンスホストを更新しなければならない場合に比べ、ネットワーク構成ロジックの更新が各段に容易になるかもしれない。最後に、集中ネットワーク構成サービスは、集中ネットワーク構成サービスでなければ入手困難であろうネットワーク状態統合図を、クライアントに容易に提供できてもよい。
例示的なコンピュータシステム
【0069】
少なくともいくつかの実施形態において、ネットワーク構成サーバ、ネットワーク構成サービスマネジャ、及び/またはインスタンスホストを実施する技術を含む、本明細書で説明する1以上の技術の一部または全てを実行するサーバは、1以上のコンピュータアクセス可能媒体を含むか当該媒体にアクセスするよう構成された汎用コンピュータシステムを含んでもよい。
図14は、そのような汎用計算装置3000を示す。図に示す実施形態において、計算装置3000は、入力/出力(I/O)インタフェース3030を介してシステムメモリ3020と接続された1以上のプロセッサ3010を備える。計算装置3000はさらに、I/Oインタフェース3030に接続されたネットワークインタフェース3040を備える。
【0070】
多様な実施形態において、計算装置3000は、一つのプロセッサ3010を備えるユニプロセッサシステムであってもよく、複数のプロセッサ3010(例えば、2つ、4つ、8つ、または他の適切な数)を備えるマルチプロセッサシステムであってもよい。プロセッサ3010は、命令実行が可能で命令実行に適した任意のプロセッサであってよい。例えば、多様な実施形態において、プロセッサ3010は、x86、PowerPC、SPARC、またはMIPS ISA、あるいは、その他任意の適した命令セットアーキテクチャ(ISA)など、多様なISAのいずれでも実行する汎用プロセッサまたは埋め込み型プロセッサであってもよい。マルチプロセッサシステムにおいて、プロセッサ3010はそれぞれ一般的には同じISAを実施するが、必ずしも同じでなくてもよい。いくつかの実装において、一般的なプロセッサの代わりにまたは追加して、グラフィック処理ユニット(GPU)を使用してもよい。
【0071】
システムメモリ3020は、プロセッサ3010により入手可能に命令及びデータを保存するよう構成されてもよい。多様な実施形態において、システムメモリ3020は、スタティックランダムアクセスメモリ(SRAM)、同期式ダイナミックRAM(SDRAM)、不揮発性/フラッシュ型メモリ、またはその他メモリタイプなど、任意の適したメモリ技術を用いて実施されてもよい。図に示す実施形態において、上記のような方法、技術及びデータなど、1以上の所望の機能を実施するプログラム命令及びデータを示し、コード3025及びデータ3026としてシステムメモリ3020に保存する。
【0072】
一実施形態において、I/Oインタフェース3030は、プロセッサ3010、システムメモリ3020、及び、装置の任意の周辺デバイスの間のI/Oトラフィックを調整するよう構成されてもよく、当該周辺デバイスには、ネットワークインタフェース3040、または、データ対象パーティションの物理レプリカの保存に使用される多様な持続的及び/または揮発性記憶装置などのその他周辺インタフェースを含む。いくつかの実施形態において、I/Oインタフェース3030は、任意の必要なプロトコル、タイミング、またはその他データ変換を実行し、あるコンポーネント(例えば、システムメモリ3020)からのデータ信号を別のコンポーネント(例えば、プロセッサ3010)での使用に適したフォーマットに変換してもよい。いくつかの実施形態において、I/Oインタフェース3030は、例えば、Peripheral Component Interconnect(PCI)バス標準またはUniversal Serial Bus(USB)標準の変種など、多様なタイプの周辺バスを介して取付けられたデバイスへのサポートを含んでもよい。いくつかの実施形態において、I/Oインタフェース3030の機能を、例えば、ノースブリッジ及びサウスブリッジなど、二以上の個別コンポーネントに分割してもよい。また、いくつかの実施形態において、システムメモリ3020に対するインタフェースなど、I/Oインタフェース3030の一部または全ての機能をプロセッサ3010に直接組み込んでもよい。
【0073】
ネットワークインタフェース3040は、計算装置3000とその他装置3060との間でデータ交換が出来るよう構成されてもよく、当該その他装置は、例えば、
図1から
図13に示すその他コンピュータシステムまたは装置などで、ネットワーク3050に接続している。多様な実施形態において、ネットワークインタフェース3040は、例えば、Ethernetネットワークのタイプなど、一般的な有線または無線の任意のデータネットワークを介した通信をサポートしてもよい。さらに、ネットワークインタフェース3040は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークなどのテレコミュニケーション/テレフォニネットワークを介し、Fibre Channel SANなどのストレージエリアネットワークを介し、或いはその他任意のタイプのネットワーク及び/またはプロトコルを介し、通信をサポートしてもよい。
【0074】
いくつかの実施形態において、システムメモリ3020は、コンピュータアクセス可能媒体の一つの実施形態であり、
図1から
図13に関し上述したように、対応する方法及び装置の実施形態を実施するプログラム命令及びデータを保存するよう構成されてもよい。しかし、他の実施形態において、種々のタイプのコンピュータアクセス可能媒体上で、プログラム命令及び/またはデータを受信し、送信し、保存してもよい。一般的には、コンピュータアクセス可能媒体は、例えば、I/Oインタフェース3030を介して計算装置3000に接続されたディスクまたはDVD/CDなど、磁気または光メディアといった非一時的な記憶媒体またはメモリ媒体を含んでもよい。また、非一時的コンピュータアクセス可能記憶媒体は、システムメモリ3020または他のタイプのメモリとして計算装置3000のいくつかの実施形態に含まれる、RAM(例えば、SDRAM、DDR SDRAM、RDRAM、SRAMなど)、ROMなど、任意の揮発性または不揮発性媒体を含んでもよい。さらに、コンピュータアクセス可能媒体は、ネットワークインタフェース3040を介して実施されるような、ネットワーク及び/または無線リンクなど通信媒体
を介し搬送される電気、電磁またはデジタル信号などの伝送媒体または信号を含んでもよい。多様な実施形態において、
図14に示す複数の計算装置の一部または全てを使用して、説明した機能を実施してもよい。例えば、多種多様な装置及びサーバ上で実行するソフトウェアコンポーネントは、連携により機能を提供してもよい。いくつかの実施形態において、説明した機能の一部を、汎用コンピュータシステムを使用した実施に加えまたは代わりに、記憶装置、ネットワークデバイス、または専用コンピュータシステムを使って実施してもよい。本明細書で使用する用語「計算装置」は、少なくともあらゆるこれらのタイプの装置をいい、これらのタイプの装置に限定するものではない。
結論
【0075】
多様な実施形態には、コンピュータアクセス可能媒体上で前述の内容に従い実施された命令及び/またはデータの受信、送信または保存を含んでもよい。一般的に、コンピュータアクセス可能媒体は記憶媒体またはメモリメディアを含んでもよく、当該媒体には、ネットワーク及び/または無線リンクなど通信媒体を介し搬送される電気、電磁またはデジタル信号などの伝送媒体或いは信号の他に、例えば、ディスクまたはDVD/CD―ROMなどの磁気または光メディア、及び、RAM(例えば、SDRAM、DDR、RDRAM、SRAMなど)、ROMなどの揮発性または不揮発性媒体がある。
【0076】
本図及び本明細書にて説明する多様な方法は、例示的な方法の実施形態を表す。当該方法をソフトウェア、ハードウェア、またはそれらの組合せで実施してもよい。方法の順番を変更し、多様な要素を追加し、再配列し、組み合わせ、削除し、変更するなどしてもよい。
【0077】
本開示の恩恵を受ける当業者には明らかなように、多様な変形及び変更を行ってもよい。本開示は、そのようなあらゆる変形及び変更を包含し、従って、上記の説明は例示であって限定な意味とするものではないと見なすものである。