JP2009532944A - コンピューティングノード間通信の管理 - Google Patents

Abstract

１つまたは複数の物理コンピューティングマシンまたはシステム上でホストされる、複数の仮想マシンノード（１３５）といった、複数の相互通信するコンピューティングノード（１３０ａ、１３０ｂ）間の通信の管理技術を説明する。いくつかの状況では、どの送信元ノードが特定の宛先ノードにデータを送信する許可を有するかを指定すること等によって、ユーザはコンピューティングノードグループおよび、オプションで、それらグループに対する通信管理において使用される関連アクセスポリシーを指定することができる。さらに、送信元ノードから宛先ノードへ開始されるデータ送信が許可されるかどうかの判定を、後に将来の上記データ送信をネゴシエーションなしで自動的に許可する際に使用するために、動的にネゴシエートし、記録することができる。

Description

本開示は一般に、動的に判定された送信許可を反映するためにリモート宛先ノードへのデータの対外送信を制御するというようなコンピューティングノード間通信の管理に関する。

かなり多数の相互接続コンピューティングシステムを収容するデータセンターが一般的なものとなった。そのデータセンターには、単一組織が運用するかまたはその単一組織に代わって運用されるプライベートデータセンター、および様々なビジネスモデルの下でコンピューティングリソースへのアクセスを顧客に提供するビジネスとして事業体により運用されるパブリックデータセンター等がある。例えば、いくつかのパブリックデータセンターの運用者は様々な顧客が所有するハードウェアに対してネットワークアクセス、電力、および安全な設置ファシリティを提供し、一方で他のパブリックデータセンターの運用者は、自身の顧客が使用する実際のハードウェアリソースも含む「完全サービス型」ファシリティを提供する。しかしながら、一般的なデータセンターの規模と範囲が増大したので、物理的なコンピューティングリソースの準備、運営、および管理作業は益々複雑になった。

商用ハードウェアに対する仮想化技術の出現により、多様なニーズを有する多数の顧客に対して大規模なコンピューティングリソースを管理する問題に部分的な解決方法が与えられ、様々なコンピューティングリソースを効率的且つ安全に複数の顧客間で共有することが可能となった。ＶＭＷａｒｅ、ＸＥＮ、またはＵｓｅｒ−Ｍｏｄｅ Ｌｉｎｕｘが提供するもののような仮想化技術により、単一の物理コンピューティングマシンがホストする１つまたは複数の仮想マシンをそれぞれのユーザに提供することで、その単一の物理的なコンピューティングマシンを複数のユーザ間で共有することができる。それぞれの上記仮想マシンは相違する論理コンピューティングシステムとして動作するソフトウェアシミュレーションであり、そのソフトウェアシミュレーションによりユーザには、自身が所与のハードウェアコンピューティングリソースの唯一の運用者および管理者であるという錯覚が与えられ、一方で様々な仮想マシン間でアプリケーションの隔離およびセキュリティが提供される。さらに、いくつかの仮想化技術により、実際に複数の相違する物理コンピューティングシステムに及ぶ複数の仮想プロセッサを伴う単一の仮想マシンのような、１つまたは複数の物理リソースに及ぶ仮想リソースを提供することができる。

しかしながら、一連の多様な顧客に対して多数のアプリケーションまたはシステムを仮想的または物理的にホストするデータセンターという状況で生ずる１つの問題は、それぞれの顧客が運用するかまたはその顧客に代わって運用されるシステムに、それらシステムへの他のシステムからの不要な通信を制限しつつ（顧客が望むならば）それらシステム間の通信を可能とするようなネットワーク隔離を提供することを含む。従来のファイアウォール技術を使用して有限の利益を提供できるが、問題が残る。例えば、ファイアウォールは一般に着信ネットワークトラフィックをそのトラフィックの宛先で、またはその宛先近傍でフィルタリングするように構成されるが、これにより悪意のあるアプリケーションが所与のネットワークにトラフィックを大量送信することで、ファイアウォールが完全に上記の着信ネットワークトラフィックを完全に遮断できたとしても、リソースの機能停止を引き起こす恐れがある。さらに、ファイアウォールには一般に、何千もの仮想マシンをホストする大規模データセンターという状況で発生しうるその種の高度に動的なリソースプロビジョニング（resource provisioning）を反映するためにフィルタリング規則を動的に修正する設備（ファシリティ：facilities）が含まれない。従って、例えば、新規のアプリケーションおよびシステムがオンラインになり他のものがオフラインになるとき、従来のファイアウォールには正確に動作するのに必要な適切なフィルタリング規則を動的に判定する能力が欠けており、時間がかかり誤りの発生しやすい上記フィルタリング規則の手動構成が必要である。

従って、上記問題が与えられると、複数のコンピューティングノードに対するデータ送信の管理を介して自動的に強制される通信ポリシーをユーザが効率的に指定できる技術を提供することが有益であろう。そのコンピューティングノードには、１つまたは複数のデータセンターまたは他のコンピューティングリソースファシリティ内で動作する、複数のホストされる仮想マシン等がある。

複数の相互通信するコンピューティングノードの間の通信を管理する技術を説明する。いくつかの実施形態では、コンピューティングノードには１つまたは複数の物理コンピューティングマシンまたはシステム上でホストされる仮想マシンノードが含まれ、通信には１つまたは複数のネットワーク上の相違する物理マシン上でホストされるノード間のデータ（例えば、メッセージ、データパケットまたはフレーム等）の送信が含まれる。さらに、いくつかの実施形態では送信元ノードと宛先ノードとの間のデータ送信または他の通信の管理を、その送信元と宛先ノードとの間の通信を特定および操作可能な１つまたは複数の中間コンピューティングノードにより提供する。例えば、送信元ノードおよび宛先ノードがそれぞれ、２つの相違する物理コンピューティングマシン上でホストされる仮想マシンである実施形態では、中間コンピューティングノードは、２つの物理コンピューティングマシンのうち１つまたは両方でホストされる１つまたは複数の他の仮想マシンを含むことができる。

さらに、少なくともいくつかの実施形態ではデータ送信の管理には、送信元ノードに関連付けた中間コンピューティングノードの管理下等で、送信元ノードから要求または開始した１つまたは複数の宛先ノードへの対外データ送信を分析してそのデータ送信が許可されるかどうかを判定することが含まれ、そのデータ送信は、許可が存在すると判定される場合にのみ１つまたは複数のネットワーク上でその宛先ノードに対して継続することができる。中間コンピューティングノードによる許可の判定は例えば、定義されたデータ送信ポリシーに少なくとも部分的に基づくことができる。そのポリシーは、送信元ノードおよび宛先ノードが両方とも共通ノードグループに属するとき等に、１つまたは複数の宛先ノードグループと通信する許可を有する１つまたは複数の送信元ノードグループを指定する。さらに、送信元ノードに関連する中間コンピューティングノードは、対象の宛先ノードに関連する相違する中間コンピューティングノードと通信してデータ送信に対する許可をネゴシエートすることができ、送信元ノードから宛先ノードへの将来のデータ送信で使用するためのそのネゴシエーション結果を反映する規則または他の指示をさらに格納することができる。その規則または他の指示には、現在のデータ送信に許可が与えられていることをそのネゴシエーション結果が示す場合に、将来の上記データ送信が許可されることを示す送信管理規則等がある。

いくつかの実施形態では、アプリケーション実行サービスが、それぞれが複数の仮想マシン（それぞれ、顧客向けの１つまたは複数のアプリケーションを実行できる）をホストする（例えば、１つまたは複数のデータセンター内の）複数の物理マシンを用いてサードパーティの顧客のアプリケーションを実行し、ここに説明する技術を１つまたは複数のデータ送信管理システムにより使用することができる。そのデータ送信管理システムは、アプリケーション実行サービスの一部として実行して、それぞれの顧客のアプリケーションを行き来する通信を制御する。以下でさらに詳細に議論するように、顧客は実行用のアプリケーションを実行サービスに提供することができ、その実行サービスが提供する物理または仮想ハードウェアファシリティ上の実行時間および他のリソースを予約することができる。さらに、顧客は、新規のコンピューティングノードグループ（例えば、顧客のプログラムの複数インスタンスのうち１つをそれぞれが現在実行している複数のコンピューティングノード）を生成し、そのグループに対するアクセスポリシーを指定し、そのグループのメンバシップおよび／または指定したアクセスポリシーを（自動または手動で）更新させて変更条件を反映することができる。その反映には、実行されている新規のアプリケーションインスタンス、最早実行されていない以前に実行したアプリケーションインスタンス、および／または新規のアクセスポリシーもしくは調整したアクセスポリシーを反映する（例えば、他のコンピューティングノード、グループ、および／またはアプリケーションへのアクセスが許可または拒否されるかどうかを変更すること等により、新規のセキュリティ要件を反映する）こと等がある。

いくつかの実施形態では、アクセスポリシーは、特定の宛先ノードまたはノードグループへのデータ送信を許可された送信元ノード（「送信ノード」または「送信者」とも称する）を、ネットワークアドレス範囲または他の識別子を経由して、１つまたは複数の関連送信元ノードグループとして、上記送信元ノードを（例えば、ネットワークアドレスまたは他の識別子を経由して）個々に記述すること等により記述し、一方で他の実施形態ではアクセスポリシーは代わりに同様な方法で、１つまたは複数の特定の送信元ノードまたはノードグループからデータ送信の受信を許可された宛先ノードを記述することができる。特定の開始されたデータ送信が許可されることを判定する、指定されたアクセスポリシーおよび／または能力がない場合、いくつかの実施形態は、許可が判定されなければ全てのデータ送信を拒否すること、または許可されないと判定されなければ全てのデータ送信を許可することといった、デフォルトのアクセスポリシーおよび／または許可ポリシーを提供することができる。

１つの実施形態の例では、データ送信管理（「ＤＴＭ」）システムの複数のデータ送信マネージャコンポーネントが協働して、多数の相互通信する参加コンピューティングノードのデータ送信を管理する。最初に、参加コンピューティングノードがオンラインになると、その参加ノードに関連するデータ送信マネージャコンポーネントはそのノードのネットワークアドレス（例えば、ＩＰアドレス）または他のネットワークロケーション、そのノードが属する任意のグループ、およびそのノードへのデータ送信を許可された送信元ノードを示すものを判定する。後に、参加ノードがリモート宛先ノードとの通信開始を試みると、その関連するデータ送信マネージャコンポーネントはその開始した通信を検出し、参加送信元ノードから宛先ノードへの以前の通信に対して取得した許可に基づいてその通信に対する許可が既に存在するかどうかを判定する。既存の許可が有効でない場合、関連データ送信マネージャコンポーネントは、リモート宛先ノードに関連するリモートデータ送信マネージャコンポーネントと通信すること等により（例えば、ネゴシエーションをトリガするネゴシエーション要求を送信することにより）、そのリモート宛先ノードと通信するための許可をネゴシエートすることを試みる。参加送信元ノードから宛先ノードへのデータ送信に対するネゴシエーション要求は、その参加送信元ノードのネットワーク識別子およびグループメンバシップに関する情報を含むことができる。

リモート宛先ノードに関連するリモートデータ送信マネージャコンポーネントが送信元ノードの代わりにネゴシエーション要求を受信した後、そのコンポーネントは送信元ノードがそのリモートの宛先ノードと通信する許可を有するかどうかを、そのリモート宛先ノードの任意のアクセスおよび／または送信ポリシーに基づいて（例えば、そのリモート宛先ノードがメンバであるグループに基づいて）判定する。許可が存在すると判定すると、リモートデータ送信マネージャコンポーネントは、通信の許可が与えられたことを示す応答でネゴシエーション要求に応答する。参加送信元ノードに関連するデータ送信マネージャコンポーネントはこの応答を受信し、（その参加送信元ノードの代わりにデータを送信すること、その参加送信元ノードによるデータ送信の続行を許可すること等により）データをリモート宛先ノードへ送信することを許可し続ける。通信許可が得られなかったことを上記の応答が示す場合、参加送信元ノードに関連するデータ送信マネージャは、（傍受したデータ送信を除去または廃棄すること、参加送信元ノードおよび／または他ノードに、その宛先ノードに対してデータ送信を実施しないよう示すこと等により）宛先ノードへのデータ送信が発生することを防止し続ける。さらに、参加送信元ノードに関連するデータ送信マネージャコンポーネントは、将来の送信において追加のネゴシエーションステップが必要ないようにネゴシエーション結果をキャッシュまたは格納することができ、宛先ノードに関連するデータ送信マネージャコンポーネントは同様にネゴシエーション結果をキャッシュまたは格納することができる。このように、データ送信マネージャシステムは、それが管理する関連コンピューティングノードが様々なリモート宛先ノードにデータを送信する許可を有するかどうかを動的に判定する。

例示の目的のため、特定の種類の通信管理を特定の種類の状況で実施する、いくつかの実施形態を以下で説明する。これらの例は例示の目的で与え、簡潔さのため簡略化してあり、本発明の技術を多様な他の状況で使用することができる。そのいくつかを以下で議論する。本技術は仮想ノードでの使用、対外データ送信での使用、１つまたは複数のデータセンター内での使用等に限定されない。

図１は複数の送信マネージャ「ＴＭ」（Transmission Manager）コンポーネントがコンピューティングノード間の通信を管理する実施形態の例を示すネットワーク図であり、複数のＴＭコンポーネントは、データセンター１００内に位置する様々なコンピューティングノードのデータ送信を管理するデータ送信管理「ＤＴＭ」（Data Transmission Management）システムの一部である。本例では、データセンター１００は多数のラック１０５を備える。ラック１０５はそれぞれ、多数の物理コンピューティングシステム１１０ａ−ｃおよびラックサポートコンピューティングシステム１２２を含む。コンピューティングシステム１１０ａ−ｃはそれぞれ、１つまたは複数の仮想マシンノード１２０を提供する。仮想マシンノード１２０をそれぞれ使用して独立したコンピューティング環境を提供し、アプリケーションをデータセンター１００内でホストする。さらに、コンピューティングシステム１１０ａ−ｃはそれぞれＴＭコンポーネントノード１１５をホストする。ＴＭコンポーネントノード１１５は、コンピューティングシステム上でホストされる他の仮想マシンノード１２０からの対外データ送信、および（データセンター１００に対してローカルまたはリモートである）他のノードからの、コンピューティングシステム上のそれらのホストされる仮想マシンノードへの着信データ送信を管理する。この実施形態の例では、ラックサポートコンピューティングシステム１２２はラックにローカルなコンピューティングシステム向けのユーティリティサービス（例えば、データ記憶サービス、ネットワークプロキシ、アプリケーション監視および管理等）、およびデータセンター内に位置し得る他のコンピューティングシステムを提供するが、他の実施形態では上記のラックサポートコンピューティングシステムを使用しなくともよい。本例におけるラックのコンピューティングシステム１１０ａ−ｃおよびラックサポートコンピューティングシステム１２２は全て、（例えば、共有バックプレーン、１つまたは複数のハブおよび／または、特定のラックに対して物理的にローカルまたはリモートであるスイッチ等を経由して）共通で、高速なラックレベルネットワーク相互接続を共有する。これは図示していない。

さらに、データセンターの例１００はさらに追加のコンピューティングシステム１３０ａ−ｂおよび１３５を備える。その追加のコンピューティングシステム１３０ａ−ｂおよび１３５はラック上に位置せず、それらの追加のコンピューティングシステムに関連付けられたＴＭコンポーネント１２５に対する共通ネットワーク相互接続を共有するが、他の実施形態では、上記の追加の非ラックコンピューティングシステムは存在しなくともよい。本例では、コンピューティングシステム１３５は多数の仮想マシンノードもホストし、一方でコンピューティングシステム１３０ａ−ｂは単一の物理マシンノードとして動作する。ＴＭコンポーネント１２５は同様に、コンピューティングシステム１３５上でホストされる関連仮想マシンノード、およびコンピューティングシステムノード１３０ａ−ｂに対する着信および対外データ送信を管理する。データセンター１００のローカルネットワークと外部ネットワーク１７０との間の相互接続部に、多数のサービス（ネットワークプロキシ、着信および／または対外データ送信のフィルタリングまたは他の管理等）の提供に使用できるような、オプションのコンピューティングシステム１４５も示してある。その多数のサービスには、データセンター１００内部の一部または全てのノードから追加のデータセンター１６０またはデータセンター１００外部の他のシステム１８０内に位置するノードへの対外データ送信を管理すること、および／または外部ノードから一部または全ての内部ノードへの着信データ送信を管理することが含まれる。オプションのＤＴＭグループマネージャコンポーネント１４０も示してあり、これは多数のサービスをデータセンター１００にローカルなＴＭコンポーネントに提供することができる。そのサービスには、ＴＭコンポーネントに対するグローバルな状態情報（例えば、グループメンバシップ情報、アクセスポリシー等）を維持すること等がある。

データセンターの例１００をネットワーク１７０（例えば、インターネット）経由で多数の他のコンピューティングシステムに接続する。そのコンピューティングシステムには、データセンター１００の運用者またはサードパーティにより運用可能な追加のコンピューティングシステム１８０、データセンター１００の運用者またはサードパーティにより運用可能な追加のデータセンター１６０、およびオプションのＤＴＭシステムマネージャシステム１５０が含まれる。本例では、ＤＴＭシステムマネージャ１５０は、図示したデータセンター１００および追加のデータセンター１６０等、多数のデータセンター内のＴＭコンポーネントに対するグローバルな状態情報を維持することができる。ＤＴＭシステムマネージャにより維持および提供される情報は例えば、グループメンバシップ情報、アクセスポリシー等を含むことができる。この実施形態の例ではＤＴＭシステムマネージャの例１５０がデータセンター１００外部にあるとして示してあるが、他の実施形態ではデータセンター１００内部に位置してもよい。

図２は、ＴＭコンポーネントの実施形態を実行すること等により、コンピューティングノード間の通信を管理するのに適したコンピューティングシステムの例を示すブロック図である。コンピューティングシステムの例２００はＣＰＵ（central processing unit）２３５、様々なＩ／Ｏ（input/output）装置２０５、記憶装置２４０、およびメモリ２４５を含む。Ｉ／Ｏ装置にはディスプレイ２１０、ネットワーク接続２１５、コンピュータ可読媒体ドライブ２２０、および他のＩ／Ｏ装置２３０が含まれる。

図示した実施形態では、ＴＭコンポーネントの例２５０はメモリ２４５内で実行されており、管理されている関連ノード２６０ａ−ｃと他のノード（ネットワーク２６５経由で接続される図示した他のコンピューティングシステム２７５により表したもの等）との間のデータ送信を管理する。本例では、管理されたノード２６０ａ−ｃは独立したコンピューティングシステム上に存在し、物理ネットワーク経由でコンピューティングシステム２００およびＴＭ２５０に接続されるが、他の実施形態では１つまたは複数の管理されたノード２６０ａ−ｃを仮想マシンノードとして代替的にコンピューティングシステム２００上でホストしてもよい。図２はさらに、他所でさらに詳細に議論するように、１つまたは複数のＴＭコンポーネントの動作に関連する情報（アクセスポリシーおよびグループメンバシップ等）を維持および提供するもののような、コンピューティングシステム２００に接続したＤＴＭシステムマネージャシステム２７０を示す。

当然のことながら、コンピューティングシステム２００、２６０ａ−ｃ、２７０および２７５は例に過ぎず、本発明の範囲を限定するようには意図していない。例えば、インターネットのような１つまたは複数のネットワークを通したものまたはＷｅｂ（World Wide Web）経由でのものを含めて、図示していない他の装置にコンピューティングシステム２００を接続してもよい。より一般的には、「ノード」または他のコンピューティングシステムは、説明した種類の機能性と相互作用しその機能性を実施可能なハードウェアまたはソフトウェアの任意の組み合わせを備えることができる。その「ノード」または他のコンピューティングシステムには、限定ではなく、デスクトップまたは他のコンピュータ、データベースサーバ、ネットワーク記憶装置および他のネットワーク装置、ＰＤＡ、携帯電話、ワイヤレスフォン、ページャ、電子手帳、インターネット機器、テレビベースのシステム（例えば、セットトップボックスおよび／または個人用／デジタルビデオレコーダを用いたもの）および適切な相互通信能力を含む様々な他の消費者製品が含まれる。さらに、図示したコンポーネントおよびシステムにより提供する機能性をいくつかの実施形態において、より少数のコンポーネントで組み合わせるかまたは追加のコンポーネントに分散させてもよい。同様に、いくつかの実施形態では図示したコンポーネントの一部の機能性を提供せずともよく、および／または他の機能性が利用可能であってもよい。

また当然のことながら、様々な項目は使用中にメモリ内または記憶装置上に格納されるとして示してあるが、これらの項目またはその一部を、メモリ管理およびデータ完全性の目的でメモリと他の記憶装置との間で転送することができる。あるいは、他の実施形態ではソフトウエアコンポーネントおよび／またはシステムの一部または全ては別の装置上のメモリ内で実行することができ、コンピュータ間通信経由で、図示したコンピューティングシステムと通信することができる。コンポーネント、システムおよびデータ構造の一部または全てをコンピュータ可読媒体上に（例えば、ソフトウェア命令または構造化データとして）格納することもできる。そのコンピュータ可読媒体には、ハードディスク、メモリ、ネットワーク、あるいは適切なドライブによりまたは適切な接続経由で読取可能な可搬型媒体品（portable media article）等がある。システム、コンポーネントおよびデータ構造を、無線ベースおよび有線／ケーブルベースの媒体を含む様々なコンピュータ可読送信媒体上の生成されたデータ信号として（例えば、搬送波または他のアナログもしくはデジタル伝播信号の一部として）送信することもでき、そのシステム、コンポーネントおよびデータ構造は様々な形態（例えば、単一または多重のアナログ信号の一部として、または複数の離散デジタルパケットもしくはフレームとして）をとることができる。上記のコンピュータプログラム製品は他の実施形態では他の形態をとってもよい。従って、本発明を他のコンピュータシステム構成で実践することができる。

図３Ａ−３Ｂは、コンピューティングノード間の通信を管理するためにグループメンバシップ情報を使用する例を示す。図３Ａおよび３Ｂに示すデータを、図１に示すＤＴＭシステムマネージャシステム１５０により、および／または１つまたは複数の様々なＴＭコンポーネントによって（例えば、中央システムを使用せずに分散方式で）等、様々な方法で維持および提供することができる。

図３Ａは複数のノードグループに対するメンバシップ情報を含むテーブル３００を示す。特に、それぞれのデータ行３０４ｂ−３０４ｆは、列３０２ａ内に表示したノードと列３０２ｂ内に表示したグループとの間のメンバシップの関連性を記述する。従って、例えば、行３０４ｃおよび３０４ｄはノードグループＧｒｏｕｐ２が少なくともノードＡおよびＢを含むことを示し、行３０４ｅおよび３０４ｆはノードＤが少なくとも２つのグループのメンバであることを示す。例示の目的のため、本例におけるノードは全て「Ａ」、「Ｂ」、「Ｃ」等の単一文字で示してあるが、他の実施形態では代わりにそれらをＩＰ（Internet Protocol）アドレス、ＤＮＳドメインネーム等の他の方法で示すことができる。同様に、グループを本例では「Ｇｒｏｕｐ１」等の文字列で示してあるが、様々な他種の名前を使用してもよく、少なくともいくつかの実施形態ではユーザは、そのユーザが使用するグループに対して記述的なグループ名を指定することができる。列３０２ｃは、様々な種類の追加情報を指定しグループに対して使用できることを示す。その追加情報には、有効期限日、そのグループを生成または管理するユーザに対する連絡先情報等がある。

図３Ｂは、図３Ａに示すグループのいくつかに関連付けられたアクセス権を指定するテーブル３１０を示す。特に、それぞれのデータ行３１４ｂ−３１４ｇは列３１２ｂ内の名前付き送信者を示す。その名前付き送信者は、列３１２ａ内で名前付けしたグループのメンバである任意のノードにデータを送信するために送信元ノードとして動作する許可を有する。本例では、上記のアクセス権を特定の送信プロトコルに固有なように定めることができる。３つのプロトコルの例を示してあり、それらはＨＴＴＰ ３１２ｃ、ＦＴＰ ３１２ｄ、およびＳＭＴＰ（Simple Mail Transfer Protocol）３１２ｅである。さらに、送信者を本例では３つの異なる方法で特定することができる。その方法には、ＩＰアドレスによるもの、ＩＰアドレス範囲によるもの、またはグループ名によるものが含まれるが、他の実施形態では他の名前付け規則（例えば、ＤＮＳドメインネーム）を使用してもよい。例えば、行３１４ｂは、範囲０．０．０．０／０（ここでは全てのホストを表すために使用）内のＩＰアドレスを有する送信ノードはＨＴＴＰプロトコルを用いてＧｒｏｕｐ１のメンバであるノードへの通信を開始できるが、上記の送信ノードはＦＴＰまたはＳＭＴＰプロトコルの何れかを用いてＧｒｏｕｐ１のメンバであるノードへの通信を開始できないことを示す。行３１４ｃは、Ｇｒｏｕｐ１のメンバである送信元ノードはＨＴＴＰプロトコルを用いてＧｒｏｕｐ２のメンバであるノードへの通信を開始できるが、ＦＴＰまたはＳＭＴＰプロトコルでは開始できないことを示す。行３１４ｄは、Ｇｒｏｕｐ３のメンバである送信元ノードはＨＴＴＰまたはＳＭＴＰプロトコルを用いてＧｒｏｕｐ２のメンバであるノードへの通信を開始できるが、ＦＴＰプロトコルでは開始できないことを示す。行３１４ｅは、ＩＰアドレス１９６．２５．１．２３を有する単一の送信元ノードは３つの列挙したプロトコルのうち任意のものを用いてＧｒｏｕｐ２のメンバノードとの通信を開始できることを示す。後続の行３１４ｆ−３１４ｈは追加のアクセスポリシーの記述を含む。列３１２ｆは、追加の情報をアクセスポリシーに関して指定できることを示す（例えば、追加のプロトコル、操作の種類、データ形式の種類、タイムアウトのようなポリシー有効期限基準、ポリシーを生成または管理するユーザの連絡先情報等）。

図３Ｂで示す例では、アクセスポリシーを送信毎のプロトコルベースで指定することができる。本例では、送信元がＨＴＴＰのような特定のプロトコル経由でアクセスを付与されるとき、これは、送信者がＴＣＰ（Transmission Control Protocol）パケットを特定グループ内のノードに、ＨＴＴＰに対するデフォルトポートであるポート８０で送信できることを意味すると捉えることができる。他の実施形態ではアクセス権を、特定のプロトコルを示さない、特定のプロトコルで使用する特定のポートをさらに指定するといった、他の詳細レベルで指定することができる。例えば、いくつかの実施形態では、アクセス権を、特定のプロトコル内のパケットタイプ（例えば、ＴＣＰ ＳＹＮパケット、ブロードキャストパケット、マルチキャストパケット、一般にＴＣＰフラグ等）、接続制限（例えば、可能な最大同時接続数）、パケットサイズ、パケット到着または出発時刻（departure time）、パケット有効期間、パケットペイロードコンテンツ（例えば、特定の文字列を含むパケット）等のような、特定のネットワーク送信の任意の送信特性に関してより一般的に指定することができる。さらに、他の実施形態は様々な方法でアクセスポリシーを指定することができる。例えば、いくつかの実施形態では否定的なアクセスポリシーの仕様を提供することができる。その仕様には、特定の送信者を除いた全ノードが或る特定のアクセス権を有すると指定するもの等がある。または、異なる実施形態ではデフォルトの（列挙していない）アクセスポリシーに対する様々なセマンティクス（semantics）を提供することができる。例えば、いくつかの実施形態では、特定の他のポリシーが許可しなければ所与のグループのノードと通信できる送信者は存在しないというデフォルトのポリシーを提供することができ、他の実施形態では所与のユーザが運用する送信者がデフォルトで同一ユーザが運用する任意の他のノードと通信でき、または所与のグループ内のノードがデフォルトで同一グループ内の他のノードと通信できるというデフォルトのポリシーを提供することができる。最後に、様々な実施形態ではグループおよびグループメンバシップを、グループ階層を提供すること、またはグループが他のグループのメンバであることを許可すること等の様々な方法で指定し、ポリシーを、その階層内の指示ポイントより下の任意のノード、あるいは指示グループまたは指示グループの任意のサブグループのメンバである任意のノードに適用することができる。

図４Ａ−４Ｆは、コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す。実施形態の例では、その送信管理規則を所与のＴＭコンポーネントが使用して、ＴＭコンポーネントが管理する１つまたは複数の関連ノードによるデータ送信を許可するか否かに関する決定を行う。それぞれのＴＭコンポーネントは自身の規則集合を維持する。他の実施形態では、図４Ａ−４Ｆに示す規則を代替的に、図１のＤＴＭグループマネージャコンポーネント１４０、図１のＤＴＭシステムマネージャシステム１５０、または、１つまたは複数のＴＭコンポーネントへの共有アクセスを提供する１つまたは複数の他のコンポーネントにより維持することができる。

図４Ａ−４Ｆに示す例では、２つのＴＭコンポーネントの例ＤＴＭ１およびＤＴＭ２は開始したデータ送信に基づいて長時間かけて、送信管理規則を動的に生成および修正する。ＤＴＭ１は２つの関連ノードＡおよびＢを管理し、ＤＴＭ２は関連ノードＤを管理する。ＤＴＭの例の両方は、管理されているノードのグループメンバシップ、およびそのグループに対する関連アクセスポリシーに関する情報も維持する。本例では、図３Ａにおける行３０４ｂ−ｅに示すように、ノードＡはＧｒｏｕｐ１に属し、ノードＢはＧｒｏｕｐ２に属し、ノードＤはＧｒｏｕｐ３およびＧｒｏｕｐ４に属する。ＤＴＭはグループメンバシップおよびアクセスポリシーに関する情報を様々な方法で得ることができる。例えば、特定のＤＴＭが管理すべき新規のノードがオンラインになると、ＤＴＭにこの新規ノードとそのネットワークアドレス（例えば、ＩＰアドレス）を通知することができ、ＤＴＭは、その新規ノードに対するグループメンバシップおよびアクセスポリシー情報にアクセスことができる（例えば、問合せること、および／またはＤＴＭグループマネージャコンポーネント１４０もしくはＤＴＭシステムマネージャシステム１５０で通知されること、情報をネットワークアクセス可能データストアから取り出すこと等により）。さらに、グループメンバシップに関する変更（例えば、特定の既存ノードをグループに対して追加またはグループから削除）およびアクセスポリシーに関する変更（例えば、以前はそのような許可を有さなかった別のグループからのデータ送信を今回は許可すること等、特定グループに関するアクセスポリシーの修正）をＤＴＭに様々な方法で伝達することができる。いくつかの実施形態では、例えばＤＴＭグループマネージャコンポーネントおよび／またはＤＴＭシステムマネージャシステムから送信した情報を介して、特定の変更により影響を受けるノードを管理するＤＴＭのみに通知する。他の実施形態では、上記の変更を全てのＤＴＭにブロードキャストすることができ、または代わりに全てのＤＴＭを構成して定期的に適切なコンポーネントをポーリングし、上記の状態変更に関する更新情報を得ることができる。

図４Ａは、３つのノードのうち任意のものが他のノードとのなんらかの通信を開始する前のＤＴＭ１およびＤＴＭ２に対する初期条件を示す。テーブル４００はＤＴＭ１により維持する、送信管理規則集合および他の情報を表す。行４０１は、ＤＴＭ１により現在管理しているノードを列挙し、この場合そのノードはノードＡおよびＢである。テーブル４００はさらに、ＤＴＭ１により維持する送信管理規則を示すサブテーブル４０２を含む。それぞれの行４０４ａ−４０４ｂはノードに関して送信ポリシーを記述する送信管理規則を保持することができる。それぞれの規則は送信元４０３ａ、宛先４０３ｂ、およびアクション４０３ｃを指定する。この時点で通信を開始したノードはないので、示した規則集合は空であるが、いくつかの実施形態では優先度が低いデフォルトの規則を含めてもよい（例えば、適用される他の規則がない場合、開始したデータ送信を拒否する）。同様にテーブル４０５はＤＴＭ２により維持する送信管理規則を示す。行４０６はＤＴＭ２が単一ノード、Ｄを管理することを示す。さらに、サブテーブル４０７は空の送信管理規則集合を示す。なぜならば、ノードＤはまだどの通信も開始していないからである。

図４Ｂは、ノードＢがＨＴＴＰプロトコル経由でノードＤとの通信を開始した後の規則集合の状態を示す。ノードＢがノードＤへのデータ送信開始を試みるとき、ＤＴＭ１は最初にその規則集合を検査して、ノードＢからノードＤへのデータ送信を支配するなんらかの既存の規則が存在するかどうかを判定する。何も見つからない場合、ＤＴＭ１はＤＴＭ２とネゴシエートして、ノードＢがノードＤにデータを送信する許可を有するかどうかを判定し、そのネゴシエーションの一部としてＤＴＭ１はＤＴＭ２に対し、ノードＢがＨＴＴＰ経由でノードＤへのデータ送信を試みたこと、およびノードＢがＧｒｏｕｐ２のメンバであることを知らせる。いくつかの実施形態では、上記のネゴシエーションには、（識別子およびネットワークアドレスがＤＴＭ１に未知である）ノードＤのＤＴＭが適切な方法でネゴシエーションメッセージを傍受しそれに応答することを期待して、ＤＴＭ１がネゴシエーションメッセージを宛先ノードＤに対して生成および送信することが含まれる。上述のように、ＤＴＭ２は、図３Ａの行３０４ｅおよび３０４ｆに示すようにノードＤがグループＧｒｏｕｐ３およびＧｒｏｕｐ４のメンバであること、および図３Ｂの行３１４ｆに示すようにＧｒｏｕｐ２のメンバによるＨＴＴＰプロトコル経由での通信開始をＧｒｏｕｐ３が許可していることを知っている。望ましい通信は既定のアクセスポリシーにより許可されるので、ＤＴＭ２はノードＢがノードＤと通信する許可を示す応答をＤＴＭ１に送信することでネゴシエーション要求に応答する。ＤＴＭ２はさらに、送信元ノードＢから宛先ノードＤへのＨＴＴＰ通信を許可する送信管理規則を行４１９ａに格納する。ＤＴＭ１が許可を示す応答をＤＴＭ２から受信した後、ＤＴＭ１はさらに、送信元ノードＢから宛先ノードＤへのＨＴＴＰ通信を許可する送信管理規則を行４１４ａに格納する。本例では、ノードＢがＨＴＴＰ経由でノードＤへデータを送信する許可を付与する規則を２つのＤＴＭがネゴシエートおよび格納したので、同一プロトコルを用いたノードＢからノードＤへの将来のデータ送信では許可の再ネゴシエーションは必要ない。さらに、ここでは示していないが、いくつかの実施形態ではＤＴＭコンポーネントはさらに、ノードＤからノードＢへの少なくともいくつかのデータ送信を、対応する送信管理規則を追加することまたは上記データ送信を許可することにより、自動的に許可する（例えば、ノードＢからノードＤへのデータ送信に対するノードＤからの応答を許可する）。

いくつかの実施形態では、ネゴシエーション完了前にＤＴＭ１によりノードＢから受信したノードＤ宛の任意のデータは、ノードＢのノードＤへのデータ送信が許可されるかどうかが判定されるまで、ＤＴＭ１により待ち行列に入れられていたであろう。上記の実施形態では、ノードＢとの通信許可の指示を受信した後、ＤＴＭ１は次いで待ち行列に入れた任意のデータ、およびネゴシエーション後に到着した任意のデータをノードＤに送信するであろう。他の実施形態では、ネゴシエーション完了前にＤＴＭ１によりノードＢから受信したノードＤ宛の任意のデータはＤＴＭ１により廃棄されるであろう。上記の技術は、いくつかのデータ送信ロスが受け入れられるか、または意図した受信者により受信および受理されない任意のデータ送信を送信ノードが再送信する状況では適切であるかもしれない。例えば、多数の送信プロトコルは任意の紛失パケットを（例えば、ＴＣＰのタイムアウトおよび再送信メカニズムに基づいて）再送信し、上記の廃棄ベースのアプローチは（例えば、ネゴシエーションが成功した場合に）最終的にこの状況において配信されるべきであったいくつかのパケットの初期紛失という結果になりうるが、再送信によりそれらの初期パケットの再送信が保証されることになる。あるいは、いくつかの実施形態では、ネゴシエーションが完了するかまたはノードＢがノードＤへデータを送信するための許可が得られる前に、許可が得られるかまたは待ち行列に入れたデータ送信をＤＴＭ２がノードＤに転送すること（または許可が最終的に得られない場合はそのデータ送信を廃棄すること）を判定するまで、データ送信をノードＤに向かって送信し、（例えば、ＤＴＭ２により傍受した後）ＤＴＭ２で待ち行列に入れることができる。

図４ＣはノードＤがＳＭＴＰプロトコル経由でノードＡとの通信を開始した後の規則集合の状態を示す。ノードＤがノードＡへのデータ送信開始を試みるとき、ＤＴＭ２は最初にその規則集合を検査して、ノードＤからノードＡへのデータ送信を支配するなんらかの既存規則が存在するかどうかを判定する。何も見つからない場合、ＤＴＭ２はＤＴＭ１とネゴシエートして、ノードＤが所与のプロトコルを用いてノードＡにデータを送信する許可を有するかどうかを判定する。ＤＴＭ２はＤＴＭ１に、図３Ａの３０４ｅおよび３０４ｆに示すようにノードＤがＧｒｏｕｐ３およびＧｒｏｕｐ４のメンバであること、およびノードＤがＳＭＴＰ経由でノードＡと通信を試みたことを知らせる。ＤＴＭ１は図３Ａの行３０４ｂに示すようにノードＡがＧｒｏｕｐ１のメンバであり、図３Ｂの行３１４ｂに示すようにＧｒｏｕｐ１がＳＭＴＰではなくＨＴＴＰ経由でＧｒｏｕｐ１と通信するためのアクセスを全てのホストに付与したことを知っている。ＳＭＴＰプロトコルを用いてノードＡにデータを送信することを許可されたホストはないため、ＤＴＭ１は、ノードＤがノードＡとＳＭＴＰプロトコル経由で通信するための許可の拒否を示す応答をＤＴＭ２に送信することで、ネゴシエーション要求に応答する。ＤＴＭ１はさらに、送信元ノードＤから宛先ノードＡへのＳＭＴＰ通信を拒否する送信管理規則を行４２４ｂに格納する。ＤＴＭ１からの許可の拒否を示す応答をＤＴＭ２が受信した後、ＤＴＭ２はさらに、送信元ノードＤから宛先ノードＡへの将来のＳＭＴＰ通信に対する許可を拒否する送信管理規則を行４２９ｂに格納する。再度、ネゴシエーション完了前にノードＤがノードＡへ送信を試みた任意のデータは、少なくともいくつかの実施形態ではＤＴＭ２により待ち行列に入れられていたであろう。ネゴシエーションプロセスが完了すると、ＤＴＭ２は待ち行列に入れた任意のデータ、およびノードＤによりノードＡへＳＭＴＰプロトコル経由で送信される全ての将来のデータを除去するであろう。

図４ＤはノードＤがＨＴＴＰプロトコル経由でノードＢとの通信開始を試みた後の規則集合の状態を示す。実際には、本図を参照して説明する状況は、上記の図４Ｂを参照して説明した状況の反対の場合である。図３Ａおよび３Ｂに示すテーブルを検査すると、本通信が許可されることが分かる。なぜならば、ノードＢはＧｒｏｕｐ２に属し（図３Ａの行３０４ｃ）、Ｇｒｏｕｐ２はＧｒｏｕｐ３のメンバにＨＴＴＰプロトコル経由でデータを送信する許可を与えており（図３Ｂの行３１４ｄ）、ノードＤはＧｒｏｕｐ３のメンバである（図３Ａの行３０４ｅ）からである。従って、ＤＴＭ２はノードＤがＨＴＴＰ経由でノードＢにデータ送信するための許可をネゴシエートすることに成功し、適用規則がＤＴＭ２により行４３９ｃに追加され、ＤＴＭ１により行４３４ｃに追加され、ＨＴＴＰプロトコル経由でノードＤからノードＢに送信されるデータはＤＴＭ２により転送されるであろう。本例では、そのノードＤが複数のプロトコル（例えば、ＨＴＴＰおよびＳＭＴＰの両方）経由でノードＢにデータを送信できることにも留意されたい。いくつかの実施形態は上記の場合に、特定の送信プロトコルに関するネゴシエーション要求に対し、（要求プロトコルのみと対照的に）送信元ノードが宛先ノードとの通信で使用できる全ての送信プロトコルを示す応答で応答することにより、最適化を実施することができる。その最適化には、本例では、ノードＤがＳＭＴＰ通信をノードＢに送信することを許可されていることを示す追加の規則をＤＴＭ１およびＤＴＭ２に対して追加させること等がある。上記の最適化により他の許可されたプロトコルに関して後の追加のネゴシエーションを実施する必要性が排除される。

図４Ｅは、ノードＡがＦＴＰプロトコル経由でノードＢとの通信開始を試みた後の規則集合の状態を示す。この場合、送信元および宛先ノードの両方を同一ＤＴＭにより管理する。いくつかの実施形態ではＤＴＭ１は上記データ送信を管理しなくともよいが、示した実施形態では上記のデータ送信を管理する（が、この場合ＤＴＭ１はリモートＤＴＭとネゴシエートする必要はない）。図３Ａおよび３Ｂに示すテーブルを検査すると、この通信が許可されないことが示される。なぜならば、ノードＢはＧｒｏｕｐ２に属し（図３Ａの行３０４ｃ）、ノードＡはＧｒｏｕｐ１に属する（図３Ａの行３０４ｂ）が、Ｇｒｏｕｐ２がＧｒｏｕｐ１のメンバにＦＴＰプロトコル経由でデータ送信する許可を付与していない（図３Ｂの行３１４ｃ）からである。ＤＴＭ１は従って行４４４ｄに適用規則を追加し、ＦＴＰプロトコルを用いてノードＡからノードＢへ送信した任意のデータを除去する。

図４Ｆは、ノードＢがＦＴＰプロトコル経由でノードＤとの通信開始を試みた後の規則集合の状態を示す。本図は、送信元ノードが、以前に許可された宛先ノードに異なるプロトコルを用いてデータを送信することを試みる例を示す。図３Ａおよび３Ｂに示すテーブルを検査すると、本通信は許可されないことが示される。なぜならば、ノードＢはＧｒｏｕｐ２に属し（図３Ａの行３０４ｃ）、ノードＤはＧｒｏｕｐ３に属するが（図３Ａの行３０４ｅ）、Ｇｒｏｕｐ３はＧｒｏｕｐ２のメンバにＦＴＰプロトコル経由でデータを送信する許可を付与していない（図３Ｂの行３１４ｆ）からである。従って、ＤＴＭ１はノードＢがＦＴＰ経由でノードＤにデータ送信するための許可をネゴシエートすることに成功せず、適用規則がＤＴＭ１により行４５４ｅに追加され、ＤＴＭ２により行４５９ｄに追加されるであろう。さらに、ＤＴＭ１はＦＴＰプロトコルを用いてノードＢからノードＤへ送信した任意のデータを除去するであろう。

このように、示した方法で送信マネージャコンポーネントは、開始したデータ送信の管理に基づいて送信管理規則を動的に生成することができる。ここでは示していないが、他の実施形態では送信マネージャコンポーネントに対する規則集合および／または特定のノードに対する規則集合を他の方法で修正してもよい。その方法とは、その関連グループメンバシップまたは他の関連情報が変化した後（例えば、仮想マシンノード上で第１の顧客の代わりに実行されているプログラムが終了した後）にノードに対応する全ての規則を除去すること等であり、その結果、そのノード（またはそのノードが以前使用したものと同じネットワークアドレスのような、同一の関連情報を後に割り当てた別のノード）は適切な許可を判定するために再ネゴシエートする必要があるか、または特定の変更により影響を受けた規則のみを除去する必要がある。例えばＧｒｏｕｐ３に対するアクセスポリシーが現時点で動的に変化し、その結果Ｇｒｏｕｐ２は最早Ｇｒｏｕｐ３にＨＴＴＰ通信を送信する許可を有さない場合、（Ｇｒｏｕｐ２の）ノードＢは最早（Ｇｒｏｕｐ３の）ノードＤにＨＴＴＰ送信を送信する許可を有さないことになる。従って、ＤＴＭ１に対する規則４５４ａおよびＤＴＭ２に対する規則４５９ａは最早有効ではなく、アクセスポリシーに対する変更によりそれらの２つの規則の除去が促進されるが、ノードＢおよびＤを含む他の規則（例えば、それぞれ、ＤＴＭ１およびＤＴＭ２に対する規則４５４ｅおよび４５９ｄ）を少なくともいくつかの実施形態では維持することができる。

図５は、２つの相互通信するコンピューティングノードと、その通信を管理する関連送信マネージャコンポーネントとの間のデータ送信の例を示す。そのデータ送信は時間ベースの順序（時間は下流に進む）で示してある。本例におけるメッセージ名およびメッセージ内容はノードＢおよびＤを管理しつつＤＴＭ１とＤＴＭ２との間で渡すことができるメッセージを例示するが、他の実施形態では他のメッセージパッシング（message passing）または他の相互作用方式が可能である。さらに、いくつかの実施形態ではデータ送信の開始および使用している対応プロトコルを、検出される基本的なデータおよび／または制御パケット（例えば、ＴＣＰパケット、ＵＤＰ（User Data gram Protocol）パケット等）を検査することで判定することができる。特に、図５は、図４Ｂを参照して説明した成功ネゴシエーション中にノードとＤＴＭとの間で渡されるメッセージの例を示す。最初に、ノードＢ５０５は送信メッセージ５３０を送信することで、ＨＴＴＰプロトコル経由でノードＤ５２０にデータ送信を試みる。ＤＴＭ１ ５１０はこのメッセージを受信し、それを、ノードＢがノードＤにデータ送信を試みていることを示すのものとして捉える。この時点で、ＤＴＭ１は上記送信を支配する規則を有さず、従ってＤＴＭ１はＤＴＭ２ ５１５と許可をネゴシエートすることを試みる。本例では、他所でさらに詳細に議論するように、ＤＴＭ１は、ＤＴＭ２により受信される「許可されるか？」メッセージ５３２を送信することでそれを行うが、少なくともいくつかの実施形態では、メッセージ５３２はリモート宛先ノードＤ宛で、そのリモートノードに対するデータ送信を管理するＤＴＭにより傍受される（このように、送信ＤＴＭはリモートＤＴＭのネットワークロケーションを知らずに動作することができる）。ＤＴＭ２は、適切なデータを検査することでノードＤが上記送信を許可したと判定し、従ってＤＴＭ１により受信する「許可される」メッセージ５３４を送信する。送信許可を受信したので、示した実施形態ではＤＴＭ１は第２の送信メッセージ５３６内の送信メッセージ５３０から待ち行列に入れたデータをノードＤに送信する。そのデータを再度ＤＴＭ２により受信する。ＤＴＭ２はこのデータを送信メッセージ５３８経由でその最終の宛先であるノードＤ５２０に転送する。前述したように、他の実施形態ではＤＴＭ１はネゴシエーションの実施中に送信メッセージ５３０を待ち行列に入れなくともよく、従って本例では送信メッセージ５３６を送信しないであろう。ネゴシエーションに続いて、ノードＢは送信メッセージ５４０を送信することでノードＤにさらなるデータを送信することを試みる。ＤＴＭ１は以前にこの種のデータ送信に対する許可をネゴシエートしたので、ＤＴＭ１はそのデータを追加のネゴシエーションなしに送信メッセージ５４２を介して転送する。ＤＴＭ２は送信メッセージ５４２を受信し、同様にそのデータを、送信メッセージ５４４を介してノードＤに転送する。

次に、図５は図４Ｄを参照して説明した成功ネゴシエーション中にノードとＤＴＭとの間で渡されるメッセージの例を示す。最初に、ノードＤは送信メッセージ５５０を介してデータをＨＴＴＰ経由でノードＢに送信することを試みる。データ送信が、以前に許可されたＨＴＴＰを用いたノードＢからノードＤへのデータ送信に関する（例えば、受信した送信メッセージ５４４に対する応答であるかまたは同一セッションの一部である）場合、他所でさらに詳細に議論するように、いくつかの実施形態ではＤＴＭ１およびＤＴＭ２は上記の応答データ送信を以前のネゴシエーションプロセスの一部として自動的に許可しているであろう。上記応答を自動的に許可するこの能力により、いくつかの種類の送信プロトコル（例えば、ＴＣＰ）を効率的に機能させうるといった、様々な利益を提供することができる。しかしながら本例では、ＤＴＭ２はデータ送信に対する別個の許可ネゴシエーションを「許可される？」メッセージ５５２で開始する。ＤＴＭ１は、適切なデータを検査することでノードＢが上記送信を許可したと判定し、従って「許可される」メッセージ５５４で応答する。最後に、ＤＴＭ２は、送信メッセージ５５０から待ち行列に入れたデータを新規の送信メッセージ５５６を介して転送する。ＤＴＭ１は送信メッセージ５５６を送信メッセージ５５８を介してその最終の宛先に転送する。最後に、図５は、図４Ｆを参照して説明した、許可の拒否に終わるネゴシエーション中にノードとＤＴＭとの間で渡されるメッセージの例を示す。最初に、ノードＢは送信メッセージ５６０を介してＦＴＰ経由でデータをノードＤに送信することを試みる。ＤＴＭ１は「許可される？」メッセージ５６２経由でＤＴＭ２とのネゴシエーションを開始する。ＤＴＭ２は、適切なデータを検査することでノードＤが上記送信を許可しなかったと判定し、従って「許可されない」メッセージ５６４で応答する。応答において、ＤＴＭ１は送信メッセージ５６０を介して受信したデータを除去する。

図６は、ノード通信ルーチン６００の実施形態の例のフロー図を示す。本ルーチンを、図１に示す仮想マシンノード１２０またはコンピューティングシステムノード１３０ａのような、通信ノードのアクションの一部として実施することができる。

本ルーチンはステップ６０５で開始し、別のノードから送信したデータ、またはリモートノードへのデータ送信指示を（例えば、ノードのアクションの別部分から）受信する。ステップ６１０で、ルーチンはデータを別ノードから受信したかどうかを判定する。そうならば、ルーチンはステップ６１５に進んで受信データを処理する。ステップ６１０でデータ送信指示を受信したと判定した場合、ルーチンはステップ６２５に進んで適切な宛先にデータを送信する。ステップ６２５または６１５の後、ルーチンはステップ６２０に進んで、継続するかどうかを判定する。そうならば、ルーチンはステップ６０５に戻り、そうでなければステップ６９９に継続して終了する。

図７Ａ−７Ｂは送信マネージャルーチン７００の実施形態の例のフロー図を示す。図１に示すＤＴＭ１１５またはＤＴＭ１２５のようなデータ送信マネージャコンポーネントの実行により、本ルーチンを提供することができる。

ルーチンはステップ７０５で開始し、対外送信、着信送信、ネゴシエーション要求、または管理メッセージを受信する。ルーチンは次いでステップ７１０に進んで、ステップ７０５で受信したメッセージまたは要求の種類を判定する。ルーチンが対外送信の指示を受信したとステップ７１０で判定する場合、ルーチンはステップ７１５に進んで以前の許可ネゴシエーションを示す適用規則を有するかどうかを判定する。適用規則は、対外送信が示す送信元ノードから宛先ノードへの送信に対して許可または拒否の何れかを行うものであることができる。上記規則が存在しないと判定する場合、ルーチンはステップ７２０に進んで、要求を宛先ノードに送信することで許可ネゴシエーションを開始する。実施形態の例では、要求を宛先ノードに送信する一方で、その要求を、宛先ノードを管理するリモートＤＴＭにより傍受（従って、リモートＤＴＭのネットワークアドレスを特に知ることなくＤＴＭがネゴシエーションを開始することを許可）するが、他の実施形態ではネゴシエーション要求メッセージを（例えば、宛先ノードの、それらを管理するリモートＤＴＭへのマッピングを介して）適切なＤＴＭに直接送信するか、または別の方法で送信してもよい。次に、ルーチンはステップ７２５に進んで応答またはタイムアウトの何れかを受信する。何らかの理由でリモートＤＴＭがオフラインになったかまたは到達不能である場合に、タイムアウトを受信する可能性がある。所定のタイムアウト内にリモートＤＴＭから応答を受信しない場合、本実施形態では、応答がないことを、通信許可を拒否する応答として扱うが、他の実施形態では応答がないことを許可として扱うことができ、または応答がないことにより許可ネゴシエーションのさらなる試みを引き起こすことができる。ルーチンは次いでステップ７３０に進んで、送信元から宛先ノードへデータを送信する許可が付与されたかどうかを判定する。明示的な許可（例えば、許可指示を含むメッセージ）を受信した場合、ルーチンはステップ７３５に進んで、送信元から宛先ノードへの将来のデータ送信を許可する許可送信管理規則を追加する。ルーチンが明示的な許可拒否またはタイムアウトを受信する場合、ルーチンはステップ７６５に進んで、許可拒否を示す規則を追加して、送信元ノードから受信し所与の宛先ノードにバインドした任意のデータを除去する。本例では、追加した許可拒否規則には有効期限基準が含まれる。その有効期限基準には、タイムアウトまたは有効期限日、定期的にデータ送信規則の再ネゴシエーションを強制してグループメンバシップ、アクセスポリシー、および／またはノードネットワーク識別子に対する動的な変更が様々なＤＴＭにより維持する規則集合内に正確に反映されることを保証すること等がある。

ステップ７１５で送信元ノードから宛先ノードへのデータ送信を支配する規則が存在すると判定する場合、ルーチンはステップ７５５に進んでその規則が上記送信を許可するかどうかを判定する。そうである場合、またはステップ７３５の後で、ルーチンはステップ７４０に進んでそのデータを送信元ノードから宛先ノードへ送信する。規則が送信元ノードから宛先ノードへのデータ送信許可を拒否するとステップ７５５で判定する場合、ルーチンはステップ７６０に進んで、所与の宛先ノードにバインドした送信元ノードからの任意のデータを除去する。未解決の許可ネゴシエーション中に受信したデータを待ち行列に入れず廃棄する実施形態においては、７２５および７４０のようなステップを幾分簡略化してもよいことに留意されたい。例えば、ネゴシエーション要求に対する応答の待機中にデータを待ち行列に入れない実施形態では、上記ステップ７２５を参照して説明したようにタイムアウトの受信を待たなくてもよい。なぜならば、未解決のネゴシエーション結果に依存して廃棄または送信の何れかを行うべき待ち行列データが蓄積されないからである。さらに、上記の場合、送信データがないため（許可ネゴシエーションを開始した任意のデータは待ち行列に入れられず、廃棄されていたであろうという理由で）、ルーチンはステップ７４０を省略してステップ７３５からステップ７４５に直接進むことができる。

ステップ７１０でルーチンがリモートＤＴＭからネゴシエーション要求を受信したと判定する場合、ルーチンはステップ７７０に進んで送信元ノードアドレスおよび送信元ノードが属するグループを判定する。そのリモートＤＴＭは、ＤＴＭが管理する宛先ノードの１つと送信元ノードが通信するための許可の取得を試みている。いくつかの実施形態では、情報の一部または全てを、リモートＤＴＭから受信したネゴシエーション要求の一部としてＤＴＭに提供する。あるいは、ＤＴＭはこの情報の一部または全てを、別のシステムコンポーネント（例えば、図１のＤＴＭグループマネージャ１４０またはＤＴＭシステムマネージャ１５０）からといった、他の方法で取得することができる。次に、ルーチンはステップ７７２に進んで、宛先ノードと通信する許可を送信元ノードのネットワークアドレスに付与したかどうかを判定する。そうでなければ、ルーチンはステップ７７４に継続して、宛先ノードと通信する許可を少なくとも１つの送信元ノードのグループに付与したかどうかを判定する。そうでなければ、ルーチンはステップ７７６に継続して、送信元ノードから宛先ノードへの送信許可を拒否する規則を追加する。その規則は、データ送信規則の再ネゴシエーションを定期的に強制する有効期限基準を含むことができる。次に、ルーチンはステップ７７８に継続して、通信許可を拒否する応答をリモートＤＴＭに送信する。しかしながら宛先ノードと通信する許可を送信元ノードに付与したとステップ７７２または７７４で判定する場合、ルーチンはステップ７８２に進んで、送信元ノードから宛先ノードへの通信を許可する規則を追加する。次に、ルーチンはステップ７８４に進んで、送信元ノードが宛先ノードと通信する許可を示す応答をリモートＤＴＭに送信する。

ステップ７１０でルーチンが着信データを受信したと判定する場合、ルーチンはステップ７８６に進む。ステップ７８６で、ルーチンは、着信データの送信元ノードから着信データの宛先データへの通信を許可する規則が規則集合内に存在するかどうかを判定する。ステップ７８８でそのように判定する場合、ルーチンはステップ７９０に継続し、データを最終宛先ノードに転送する。上記通信の許可を拒否する規則が存在しないか、または上記通信の許可を明示的に拒否する規則が存在する場合、ルーチンはステップ７９２に進んで着信データを除去する。さらに、いくつかの実施形態では、ＤＴＭはこの場合、上記通信が許可されなかったデータを最初に送信したリモートＤＴＭにメッセージを送信し、それによりリモートＤＴＭに対し、この特定の宛先ノードに関する規則の一部または全てを無効にすべきことを知らせることができる。

ステップ７１０でルーチンが管理メッセージを受信したと判定する場合、ルーチンはステップ７９４に進む。管理メッセージは、ＤＴＭが管理する１つまたは複数のノードがオフラインになったという通知、ＤＴＭが管理すべき新規ノードがオンラインになったという通知等を含むことができる。いくつかの実施形態では、新規ノードがオンラインになると、その新規ノードを管理するＤＴＭはその新規ノードのネットワークロケーション（例えば、ネットワークアドレス）、その新規ノードが属するグループ、その新規ノードとの通信許可を付与された送信元ノードまたは他の送信者（個々のノードまたはグループ）、送信者がその新規ノードと通信するために使用できる特定のプロトコル等を判定することができる。他の実施形態では、ＤＴＭは代替的に、新規ノードが最初にアウトバウンド通信を送信するとき、またはその新規ノード宛の最初のインバウンド通信が到着するとき等の後の時点まで上記情報の取得を遅延させることができる。上記情報を、図１のＤＴＭグループマネージャ１４０またはＤＴＭシステムマネージャのような他のシステムコンポーネントと通信することで、またはネットワークアクセス可能データストアを参照することで、ＤＴＭにより取得することができる。同様に、ＤＴＭが管理するノードがオフラインになるとき、ＤＴＭは、送信元または宛先ノードの何れかとしてそのノードを参照する任意の規則をその規則集合から消去することができる。ＤＴＭはノードのネットワーク識別子、グループメンバシップ、および／またはアクセスポリシーに関する任意の情報を消去することもできる。

ステップ７６０、７４０、７６５、７８４、７７８、７９０、７９２または７９４の後、ルーチンはステップ７８０に継続して、ハウスキーピングタスク（例えば、ＴＭコンポーネントの規則集合に格納した規則に関連付けられた有効期限基準をチェックすること）をオプションで実施する。いくつかの実施形態では、指定の時間間隔の後に自動的に有効期限が切れるように規則を設定することができる。他の実施形態では、ＤＴＭは定期的に規則集合内の規則を検査して、或る特定の年代に達したものを消去または削除する。他のハウスキーピングタスク（housekeeping task）は、ログの更新もしくは循環、または上記フローチャートで示していない追加のメッセージもしくは要求の処理等の操作を含むことができる。例えば、いくつかの場合では、上記ＤＴＭの実施形態の例は陳腐化した許可規則、即ち、初期許可ネゴシエーション後の何らかの時点でオフラインになった宛先ノードを参照する許可規則を有するであろう。上記の場合、ＤＴＭは、ＤＴＭの管理下で送信元ノードの１つがそのノードへのデータ送信を試みるまで、宛先ノードがオフラインになったことに気づくことができない。ＤＴＭは上記送信を許可する規則を有するので、ＤＴＭはそのデータを宛先ノードに送信するであろう。しかしながら、リモートＤＴＭはその送信を拒否し、上記送信を許可した規則（あるいはそのノードを宛先ノードとして参照する全ての規則）を無効にするようＤＴＭに知らせるメッセージで応答する。それに応じて、ＤＴＭは所与の宛先ノードに関する、格納した規則の一部または全てを必要に応じて消去するであろう。

ステップ７４５の後、ルーチンはステップ７５０に進んで、継続するかどうかを判定する。そうならば、ルーチンはステップ７０５に戻り、そうでなければステップ７９９に継続して終了する。

図８はＤＴＭシステムマネージャルーチン８００の実施形態の例のフロー図を示す。本ルーチンを、例えば図１に示すＤＴＭシステムマネージャ１５０の実行により提供することができる。ルーチンはステップ８０５で開始し、ユーザアカウント操作の実施要求またはグループ情報の構成要求を受信する。次に、ルーチンはステップ８１０に進んで、ユーザアカウント操作の実施要求を受信したかどうかを判定する。そうならば、ルーチンはステップ８４０に進んで、要求されたユーザアカウント操作（例えば、ユーザアカウントの生成または削除、課金情報のようなユーザアカウント設定に対する修正、データセンターが提供する計算時間または他のリソースの予約、マシンイメージまたはアプリケーションプロファイルの準備および管理等）を必要に応じて実施する。ユーザアカウント操作をステップ８１０で要求したと判定されない場合、ルーチンはステップ８１５に継続してグループアクセスポリシーの構成要求を受信したかどうかを判定する。そうである場合、ルーチンはステップ８４５に継続して、要求に応じて、または必要に応じてグループアクセスポリシーを設定または構成する。これらのアクセスポリシーは例えば、図３Ｂのテーブルに示したものと類似してもよい。いくつかの場合では、ルーチンはさらに、いくつかのＤＴＭ（例えば、指定アクセスポリシーの影響を受けるノードを管理するもののみ）または全てのＤＴＭに指定アクセスポリシーを通知することができる。グループアクセスポリシーの構成要求を受信したとステップ８１５で判定しない場合、ルーチンはステップ８２０に進んで、グループメンバシップの指定要求を受信したかどうかを判定する。そうであれば、ルーチンはステップ８５０に継続して、必要に応じてグループメンバシップ情報に対する修正を実施する。いくつかの場合、ルーチンはさらに、いくつかのＤＴＭ（例えば、グループメンバシップの仕様の影響を受けるノードを管理するもののみ）または全てのＤＴＭにグループメンバシップの修正を通知することができる。グループメンバシップの指定要求を受信したとステップ８２０で判定しない場合、ルーチンはステップ８２５に進んで他の要求を処理する。他の要求は新規グループの生成、グループの削除、上記ステップにより処理されない既存グループまたはユーザアカウントに対する修正等の操作を含むことができる。ステップ８３０、８４０、８４５、または８５０の後、ルーチンはステップ８３０に進んで、追加のハウスキーピング操作（例えば、ユーザに対する課金情報の定期的生成、アクセスおよび操作のロギングまたはログの循環、システムバックアップ、あるいは他の管理または管理機能）をオプションで実施する。次に、ルーチンはステップ８３５に進んで、継続するかどうかを判定する。そうである場合、ルーチンはステップ８０５に進んで追加の着信要求を処理する。そうでなければ、ルーチンはステップ８９９に進んで戻る。

当業界の技術者は、上で議論したルーチンにより提供する機能性をいくつかの実施形態では代替手段により提供してもよいことも理解するであろう。その代替手段には、より多数のルーチン間で分割することまたはより少数のルーチンに統合すること等がある。同様に、いくつかの実施形態では、示したルーチンは説明したものより多数または少数の機能性を、他の示したルーチンが上記機能性をそれぞれ欠くかもしくは含むとき、または提供した機能性の量が変更されるとき等に提供してもよい。さらに、様々な操作を特定の方法で（例えば、逐次的に、または並行して）、および／または特定の順序で実施されるとして示すことができる一方で、他の実施形態ではその操作を他の順序または他の方法で実施してもよいことを、当業界の技術者は理解するであろう。当業界の技術者は、上で議論したデータ構造を異なる方法で構造化してもよいことも理解するであろう。その方法には単一のデータ構造を複数のデータ構造に分割させることによるもの、または複数のデータ構造を単一のデータ構造に統合させることによるもの等がある。同様に、いくつかの実施形態では、示したデータ構造は説明したものより多数または少数の情報を、他の示したデータ構造が上記情報をそれぞれ欠くかまたは含むとき、あるいは格納した情報の量または種類が変更されるとき等に格納してもよい。

前述したように、いくつかの実施形態ではコンピューティングノードによるデータ送信または他の通信の開始を、関連するデータ送信マネージャコンポーネントにより様々な方法で実施および特定することができる。いくつかの実施形態では、コンピューティングノードは明示的なメッセージを、リモートノードと通信する許可を要求してそのメッセージを管理するＴＭコンポーネントに送信することができるが、他の実施形態ではＴＭおよびそれが実施する許可ネゴシエーションの存在はコンピューティングノードに完全に透過的であってよい。そうならば、コンピューティングノードは単純にデータをリモートノードに送信し、ＴＭコンポーネントはコンピューティングノードからの全ての対外送信を監視および処理する。ＴＭコンポーネントがコンピューティングノードから開始したデータ送信を（そのコンピューティングノードから明示的な要求メッセージを受信すること、またはそのコンピューティングノードがまだ許可をネゴシエートしていないアウトバウンド送信を、ＴＣＰまたはＵＤＰパケットの送信元および宛先ネットワークアドレスをそれらのパケットがネットワークインタフェースを渡って流れるときに検査すること等により検出すること、等により）特定するとき、ＴＭコンポーネントは許可が存在する場合または許可の拒否がまだ存在しない場合に許可ネゴシエーションを開始する。ＴＭコンポーネントが許可をネゴシエートする間、ＴＭコンポーネントは、リモート宛先ノードにバインドしたコンピューティングノードからの発信データを待ち行列に入れ、許可ネゴシエーション結果に従って（例えば、データ送信が宛先ノードに進むことを許可または防止することで）そのデータを処理し、宛先ノードへの転送前にデータをオプションで操作することができる（例えば、データ送信の許可および／または信頼性の検証において宛先コンピューティングノードおよび／または宛先送信コンポーネントにより使用される取得した許可の指示を含めること、データ形式および／または送信プロトコルを変更して宛先コンピューティングノードの優先度を反映すること等または他の理由でデータ送信方法を修正すること、データを追加および／または除去する等で、送信したデータを修正すること等）。

さらに、様々な実施形態では顧客ユーザおよび他のユーザがＤＴＭシステムの実施形態と相互作用するためのメカニズムを提供することができる。例えば、いくつかの実施形態では、インタラクティブコンソール（例えば、インタラクティブユーザインタフェース、Ｗｅｂブラウザベースのインタフェース等を提供するクライアントアプリケーションプログラム）を提供することができる。ユーザはそのインタラクティブコンソールから、グループの生成または削除、および通信アクセスポリシーまたはグループメンバシップの仕様、およびホストされるアプリケーションの操作および管理に関するより一般的な管理機能（例えば、ユーザアカウントの生成または修正、新規アプリケーションの準備、ホストされるアプリケーションの開始、終了、または監視、アプリケーションのグループへの割り当て、時間または他のシステムリソースの予約等）を管理することができる。さらに、いくつかの実施形態では、他のコンピューティングシステムおよびプログラムがプログラム的に上記機能性を起動できるＡＰＩ（application programming interface）を提供することができる。上記ＡＰＩを、（例えば、Ｃ，Ｃ＋＋、またはＪａｖａ（登録商標）で書いたプログラムにより起動される）ライブラリまたはクラスインタフェースおよび／またはＷｅｂサービス経由のもののようなネットワークサービスプロトコルにより提供することができる。

さらに、様々な実装アーキテクチャがＤＴＭシステムの実施形態に対して可能である。いくつかの実施形態では、それぞれが独立した自律プログラムとして動作することで、または他のＴＭコンポーネントと協調することで、複数のＴＭコンポーネントは分散方式で動作してそれぞれは１つまたは複数の関連ノードのデータ送信を管理することができる。その複数のＴＭコンポーネントは、ノードを管理している同一コンピューティングシステム上でホストされる仮想マシンであることができ、または自分が管理するノードからリモートであるコンピューティングシステム上で動作することができる。許可ネゴシエーションを、その中でＴＭコンポーネントが互いに直接相互作用するとして説明したが、他の実施形態では上記ＴＭコンポーネントは他の方法で許可をネゴシエートすることができる。その方法には、システム全体に対する通信ポリシーを管理する中央コンポーネントと通信することによるもの、または構成ファイルを参照することもしくはローカルまたはネットワーク上で利用可能な他の静的情報ストアを参照することによるもの等がある。さらに、ＴＭコンポーネントにより実施する許可ネゴシエーションは様々な形態を有することができる。例えば、いくつかの実施形態では、リモートＴＭコンポーネントの実際のネットワークアドレスまたは他の識別子は、ネゴシエーションを開始するＴＭコンポーネントに既知であってよく、そうならば、そのＴＭコンポーネントはそのリモートＴＭコンポーネントと直接相互作用することができ、一方で他の実施形態ではＴＭコンポーネントは、送信した情報が適切なリモートＴＭコンポーネントにより傍受されることを期待して、情報を宛先コンピューティングノードのネットワークアドレスに送信することができる。他の実施形態では、単一の中央ＴＭコンポーネントまたは他のコンポーネントは多数のコンピューティングノード（例えば、データセンター全体）に対するデータ送信を、（そのノードの構成のため、またはネットワーク構造もしくは上記アクセスを提供する他のメカニズムのため）その単一コンポーネントがそれらノードにより開始されたデータ送信へのアクセスを有する場合に、管理することができる。さらに他の実施形態では、管理しているコンピューティングノードの各々に取り込むこと等で（例えば、全てのノードによるネットワーク通信に用いるシステムライブラリに組み込むことで）ＴＭコンポーネントの機能性を分散させることができ、または相違するＴＭコンポーネントがそれぞれのコンポーネントに代わって動作することができる。

さらに、ＤＴＭシステムの機能性を様々なシステムコンポーネント間で分散させる実施形態では、様々なネゴシエーション方式およびプロトコルが可能である。ＴＭコンポーネント間またはＴＭコンポーネントと他のシステムコンポーネントとの間で渡されるデータ送信ポリシーおよび許可に関するネゴシエーション要求および他のメッセージを様々な方法で実装することができる。その方法には、関連情報を含む低レベルＵＤＰパケットの送信によるもの、またはＨＴＴＰのようなより高レベルのプロトコル上に実装したプロトコル（例えば、ＸＭＬ−ＲＰＣ、ＳＯＡＰ等）によるもの等がある。

前述したように、ここに説明する技術を多数のコンピューティングノードの代わりに使用してそれらのコンピューティングノードに様々な利益を提供することができる。さらに、少なくともいくつかの実施形態では、上記のコンピューティングノードは、それぞれが着信通信に対して独自のファイアウォール、アンチウイルス保護および他のマルウェアに対する保護等を構成および提供すること等により、代わりにさらに追加の技術を使用して他の能力を提供することができる。

いくつかの定義した境界内部のコンピューティングノードグループ（例えば、データセンター内部のノード）が、それらのコンピューティングノードにより開始したデータ送信へアクセスできる等のため、ここに説明する技術を使用するとき、いくつかの実施形態ではここに説明する技術をその定義した境界の端に拡張することができる。従って定義した境界内部のコンピューティングノード間のデータ送信管理に加えて、内部と外部のコンピューティングノード間の境界を通る通信にアクセス可能な１つまたは複数の送信マネージャコンポーネントは、それらの通信に対してここに説明する技術の少なくとも一部を同様に提供することができる。例えば内部コンピューティングノード宛のデータ通信を外部コンピューティングノードから境界で受信するとき、端に関連付けられた送信管理コンポーネントは同様にその通信を管理されたコンピューティングノードが開始した対外データ送信として扱うことができる。それは、その通信を待ち行列に入れて（例えば、宛先コンピューティングノードに関連付けられた送信管理コンポーネントとネゴシエートすること、または全ての内部コンピューティングノードの代わりに動作するコンポーネントとネゴシエートすることにより）許可がネゴシエートおよび取得される場合にのみ内部ネットワークへその通信を渡すことを許可すること等により行うことができる。

当業界の技術者は、いくつかの実施形態ではここに説明する技術を複数の相互通信ノードを収容するデータセンターという状況で使用するが、他の実装シナリオも可能であることも理解するであろう。例えば、ここに説明する技術を、ビジネスまたは他の施設（例えば、大学）が運営する組織規模のイントラネットという状況で、その従業員および／またはメンバの利益のために使用してもよい。あるいは、ここに説明する技術をネットワークサービスプロバイダにより使用してネットワークセキュリティ、可用性、および分離を改善することができる。さらに、実施形態の例を様々な目的でデータセンターまたは他の状況で使用することができる。例えば、ホストされるアプリケーションへのアクセスを顧客に販売するデータセンターのオペレータまたはユーザはいくつかの実施形態ではここに説明する技術を使用して、その顧客のアプリケーションとデータとの間のネットワーク分離を提供することができる。ソフトウェア開発チームはいくつかの実施形態では本技術を使用して、自分が使用する様々な環境（例えば、開発、構築、テスト、配置、生産等）の間でネットワーク分離を提供することができる。組織はいくつかの実施形態ではここに説明する技術を使用して、或る個人グループまたは部門（例えば、人事）が利用するコンピューティングリソースを、別の個人グループまたは部門（例えば、経理）が利用するコンピューティングリソースから分離することができる。または、マルチコンポーネントアプリケーション（例えば、多層ビジネスアプリケーション）を配置しているデータセンターのオペレータまたはユーザはいくつかの実施形態ではここに説明する技術を使用して、様々なコンポーネントタイプ（例えば、Ｗｅｂフロントエンド、データベースサーバ、ビジネスルールエンジン等）に対する機能分解および／または分離を提供する。より一般的には、ここに説明する技術を使用して仮想マシンを分割し、従来では相違するコンピューティングシステムを物理的に分割する必要があったであろうほとんどいかなる状況をも反映することができる。

本明細書では例示の目的で特定の実施形態を説明したが、前述したことから当然のことながら、本発明の精神および範囲から逸脱せずに様々な修正を加えうる。従って、本発明は添付請求項とその中で列挙した要素によって以外は限定されない。さらに、本発明の或る特定の態様を或る特定の請求項の形で提示するが、本発明者は任意の可能な請求項の形で本発明の様々な態様を意図している。例えば、コンピュータ可読媒体で具現化されているとして本発明のいくつかの態様のみを現時点では列挙しているが、他の態様も同様にそのように具現化することができる。

複数の送信マネージャコンポーネントがコンピューティングノード間の通信を管理する実施形態の例を示すネットワーク図である。 コンピューティングノード間の通信を管理するシステムの実施形態を実行するのに適したコンピューティングシステムの例を示すブロック図である。 コンピューティングノード間の通信を管理するためのグループメンバシップ情報を用いる例を示す図である。 コンピューティングノード間の通信を管理するためのグループメンバシップ情報を用いる例を示す図である。 コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す図である。 コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す図である。 コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す図である。 コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す図である。 コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す図である。 コンピューティングノード間の通信管理に使用する、動的に修正した送信管理規則の例を示す図である。 ２つの相互通信するコンピューティングノードと、その通信を管理する関連送信マネージャコンポーネントとの間のデータ送信の例を示す図である。 ノード通信ルーチンの実施形態の例のフロー図である。 送信マネージャルーチンの実施形態の例のフロー図である。 送信マネージャルーチンの実施形態の例のフロー図である。 ＤＴＭシステムマネージャルーチンの実施形態の例のフロー図である。

Claims (25)

1. コンピューティングシステムにおけるデータ送信マネージャに関する方法であって、
   送信元ノードから宛先ノードへのデータ送信に関する要求を受信するステップと、
   送信管理規則を適用することによって前記データ送信が許可されるかどうかを判定するステップであって、前記判定ステップは、前記送信管理規則の適用により前記データ送信が許可されない場合に、
   前記宛先ノードに関連付けられた第２のデータ送信マネージャと許可に関するネゴシエーションを開始するステップと、
   前記第２の送信マネージャ装置から、前記データ送信が許可されるかどうかを示すメッセージを受信するステップと
   を含むステップと、
   前記データ送信が許可される場合、前記宛先ノードに対するデータを前記第２のデータ送信マネージャに送信するステップと、
   前記データ送信が許可されない場合、前記データ送信を終了するステップと
   を備えることを特徴とする方法。
2. 前記第２の送信マネージャからの前記受信メッセージ内で前記データ送信が許可されると示される場合、前記送信管理規則を更新して前記送信元ノードから前記宛先ノードへのデータ送信を許可するステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記データ送信が許可されるかどうかを判定するステップは、
   前記送信元ノードがメンバである１つまたは複数のノードグループから成る第１の集合を判定するステップと、
   前記宛先ノードがメンバである１つまたは複数のノードグループから成る第２の集合を判定するステップと、
   前記第１および第２の集合の前記ノードグループに適用した送信規則に少なくとも部分的に基づいて、前記送信元ノードが前記宛先ノードと通信することが許可されるかどうかを判定するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
4. 前記送信元ノードと前記宛先ノードとの間のネゴシエーションに関する要求を受信するステップと、
   前記送信元ノードがノードグループの一部であるかどうかを判定するステップと、
   前記送信元ノードがノードグループの一部であると判定される場合、
   前記ノードグループが前記データ送信に対する許可を有するかどうかを判定するステップと、
   前記ノードグループが許可を有すると判定される場合、
   前記送信規則を更新するステップと、
   前記送信元ノードから前記宛先ノードへのデータ送信が許可されることを示すネゴシエーション応答を前記第２のデータ送信マネージャに送信するステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
5. 前記ネゴシエーション応答は、前記送信元ノードのネットワークアドレスを示すものおよび前記送信元ノードに対する前記ノードグループを示すものを含むことを特徴とする請求項４に記載の方法。
6. 前記ネゴシエーション応答は、前記宛先ノードに対するデータ送信で使用するための送信プロトコルを示すものを含むことを特徴とする請求項４に記載の方法。
7. 前記宛先ノードからおよび前記送信元ノードへの第２のデータ送信に関する要求を受信するステップと、
   送信管理規則を適用することで前記第２のデータ送信が許可されるかどうかを判定するステップと、
   前記第２のデータ送信が許可される場合、データを前記送信元ノードに転送するステップと、
   前記第２のデータ送信が許可されない場合、前記第２のデータ送信を終了するステップ
   と
   をさらに備えることを特徴とする請求項１に記載の方法。
8. 前記データ送信マネージャおよび前記第２のデータ送信マネージャは、ソフトウェアシミュレーションにより実装した仮想マシンであることを特徴とする請求項１に記載の方法。
9. それぞれの仮想マシンは相違する論理コンピューティングシステムを表すことを特徴とする請求項８に記載の方法。
10. 前記データ送信マネージャはデータ送信マネージャグループマネージャからデータ送信管理規則を受信すること、および前記データ送信マネージャグループマネージャはグループメンバシップおよびグループデータ送信管理規則を維持することを特徴とする請求項１に記載の方法。
11. 前記データ送信が許可されるかどうかを判定するステップは、前記送信元ノードを含むグループを特定するステップをさらに含み、適用される前記送信管理規則は当該グループに対する送信管理規則であることを特徴とする請求項１に記載の方法。
12. 請求項１から１１に記載のいずれかの方法を実施するコンピュータプログラム。
13. コンピューティングシステムにおけるデータ送信管理に関する装置であって、
    送信元ノードから宛先ノードへのデータ送信に関する要求を受信する手段であって、前記要求をデータ送信マネージャに送信する手段と、
    送信管理規則を適用することによって前記データ送信が許可されるかどうかを判定する手段であって、前記判定することは、前記送信管理規則の適用により前記データ送信が許可されない場合に、
    前記宛先ノードに関連付けられた第２のデータ送信マネージャと許可に関するネゴシエーションを開始することと、
    前記第２の送信マネージャ装置から、前記データ送信が許可されるかどうかを示すメッセージを受信することと
    を含む手段と、
    前記データ送信が許可される場合、前記宛先ノードに対するデータを前記第２のデータ送信マネージャに送信する手段と、
    前記データ送信が許可されない場合、前記データ送信を終了する手段と
    を備えることを特徴とする装置。
14. 前記第２の送信マネージャからの前記受信メッセージ内で前記データ送信が許可されると示される場合、前記送信管理規則を更新して前記送信元ノードから前記宛先ノードへのデータ送信を許可する手段をさらに備えることを特徴とする請求項１３に記載の装置。
15. 前記データ送信が許可されるかどうかを判定する手段は、
    前記送信元ノードがメンバである１つまたは複数のノードグループから成る第１の集合を判定する手段と、
    前記宛先ノードがメンバである１つまたは複数のノードグループから成る第２の集合を判定する手段と、
    前記ノードグループに適用した送信規則に少なくとも部分的に基づいて、前記送信元ノードが前記宛先ノードと通信することが許可されるかどうかを判定する手段と
    をさらに含むことを特徴とする請求項１３に記載の装置。
16. 前記送信元ノードと前記宛先ノードとの間のネゴシエーションに関する要求を受信する手段と、
    前記送信元ノードがノードグループの一部であるかどうかを判定する手段と、
    前記送信元ノードがノードグループの一部であると判定される場合、前記送信元ノードが許可を有するかどうかを、
    前記ノードグループが前記データ送信に対する許可を有するかどうかを判定することと、
    前記ノードグループが許可を有すると判定される場合、
    前記送信規則を更新することと、
    前記送信元ノードから前記宛先ノードへのデータ送信が許可されることを示すネゴシエーション応答を前記第２のデータ送信マネージャに送信することと
    により判定する手段と
    をさらに備えることを特徴とする請求項１３に記載の装置。
17. 前記ネゴシエーション応答は、前記送信元ノードのネットワークアドレスを示すものおよび前記送信元ノードに対する前記ノードグループを示すものを含むことを特徴とする請求項１６に記載の装置。
18. 前記ネゴシエーション応答は、前記宛先ノードに対するデータ送信で使用するための送信プロトコルを示すものを含むことを特徴とする請求項１６に記載の装置。
19. 前記データ送信マネージャおよび前記第２のデータ送信マネージャはソフトウェアシミュレーションにより実装した仮想マシンであることを特徴とする請求項１６に記載の装置。
20. それぞれの仮想マシンは相違する論理コンピューティングシステムを表すことを特徴とする請求項１９に記載の装置。
21. 前記データ送信マネージャはデータ送信マネージャグループマネージャからデータ送信管理規則を受信すること、および前記データ送信マネージャグループマネージャはグループメンバシップおよびグループデータ送信管理規則を維持することを特徴とする請求項１６に記載の装置。
22. 前記データ送信が許可されるかどうかを判定する手段は、前記送信元ノードを含むグループを特定し、前記グループに対して送信管理規則を適用する手段を含むことを特徴とする請求項１６に記載の装置。
23. 前記宛先ノードからおよび前記送信元ノードへの第２のデータ送信に関する要求を受信する手段と、
    送信管理規則を適用することで前記第２のデータ送信が許可されるかどうかを判定する手段と、
    前記第２のデータ送信が許可される場合、データを前記送信元ノードに転送する手段と、
    前記第２のデータ送信が許可されない場合、前記第２のデータ送信を終了する手段と
    をさらに備えることを特徴とする請求項１３に記載の装置。
24. 前記装置は前記データ送信マネージャを実装する手段を備えることを特徴とする請求項１３から２３のいずれかに記載の装置。
25. 前記装置は前記第２のデータ送信マネージャを実装する手段を備えることを特徴とする請求項２４に記載の装置。

Images