JP2016504820A - ＯｐｅｎＦｌｏｗ有効化クラウドコンピューティングにおいてＭＰＬＳを用いる場合のテナント固有データの分離のための装置及び方法 - Google Patents

Abstract

クラウドネットワークマネージャ（ＣＮＭ）へのテナントＩＤへテナント固有データを隔離するために、テナントデータベースを用いて、テナントＩＤ情報がＣＮＭアドレスマッピングテーブルへ追加される。ＣＮＭは、複数のデータベース又はテーブル内の複数のアイテムの間のマッピングを維持する。当該複数のデータベース又はテーブルは、テナントデータベース（ＤＢ）と、テナント識別子−テナントラベル（ＴＩＴＬ）テーブルと、ＴＯＲＳ（top of rack server）ラベル−仮想スイッチリンクラベル（ＴＬＶＬＬ）テーブルと、ラベルマッピングテーブル（ＳＭＶＬ）と、ＣＮＭアドレスマッピングテーブルとを含む。ＣＮＭは、上記複数のデータベースを用いて、テナントの仮想マシン（ＶＭ）間で送信されるパケットへ付与されるテナント固有ラベルを生成する。【選択図】図１

Description

［関連出願への相互参照］
本一部継続出願は、２０１１年９月３０日に提出された米国特許出願第１３／２５１，１０７号及び２０１２年１１月２７日に提出された米国仮出願第６１／７３０，３９４の利益を主張し、これらは参照によりここに取り入れられる。

［分野］
本発明の実施形態は、クラウドコンピューティングの分野に関し、より具体的には、クラウドコンピューティングにおける仮想プライベートネットワークの隔離に関する。

多年にわたって、大規模な法人はそのコンピュータリソースをデータセンタへと集中させてきた。この傾向は、ここ数年で、サーバ仮想化技術がますます普及するにつれて加速している。データセンタがより大規模になったために、いくつかのデータセンタ事業者は、コンピューティング、ストレージ及びネットワーク通信リソースを外部の顧客へと提供し始めている。提供されるサービスは、典型的には、伸縮自在の、オンデマンドの処理、最も実用的な目的のために顧客の支払い能力によってのみ制限されるストレージ、及びインターネットへのネットワーク帯域幅からなる。この発展は、クラウドコンピューティングと呼ばれる。

サーバ仮想化技術は、複数のサーバのプールを本質的に１つの大規模なコンピュータリソースとして管理することを可能とする。オペレーティングシステムとハードウェアとの間には、ハイパーバイザと呼ばれるソフトウェアのレイヤが存在する。ハイパーバイザは、仮想化されたサーバ上での仮想マシン（“ＶＭ”）の実行をスケジューリングする。ＶＭは、いくつかのアプリケーションと共にパッケージ化されたオペレーティングシステムイメージである。ハイパーバイザは、ＶＭを一時停止し、及び負荷分散をするためにＶＭをサーバ間で移動させることを可能とする。負荷分散及びクラッシュを捕捉するためのＶＭ実行の監視は、遥かに高コストで専門化された解決策と共に達成される企業アプリケーションについて、同じ種類の耐障害性及びスケーラビリティサービスを提供する。クラウドマネージャシステムは、ＶＭの実行を監督し、実行をスケジューリングして需要を満たし、サーバ利用率を最適化し、及び電力消費を最小化する。クラウド実行マネージャは、進行中のサービス提供への影響の無い、ハードウェア及びソフトウェアのサービス中（in-service）アップグレードを可能とするように、実行をスケジューリングすることができる。

マシン間のＶＭの任意の移動をサポートするために、データセンタ内のネットワーキングもまた仮想化されなければならない。今日のほとんどのクラウドは、ハイパーバイザへ仮想スイッチを取り入れることにより、ネットワークを仮想化する。仮想スイッチは、ハイパーバイザの制御下で実行中のＶＭへの仮想ネットワークポートを提供する。仮想スイッチソフトウェアは、サーバリソースがハイパーバイザにより仮想化されるのと同様のやり方で、ネットワークリソースを仮想化することをも可能とする。ハイパーバイザ及び仮想スイッチは、それにより、サーバ間でＶＭを移動させることを可能とするように協働することができる。ハイパーバイザは、ＶＭを移動させる場合には新たなロケーションについて仮想スイッチと通信し、仮想スイッチは、ＶＭのアドレス（レイヤ２の“ＭＡＣ”（Media Access Control）アドレス、潜在的には“ＩＰ”（Internet Protocol）アドレスも）についてのネットワークのルーティングテーブルが更新され、そしてパケットがその新たなロケーションへとルーティングされることを保証する。

多くのクラウドコンピューティング施設は、ウェブサービスアプリケーションをサポートするに過ぎない。ウェブサービスアプリケーションは、リクエストをウェブサーバのプールへディスパッチする負荷分散フロントエンドからなる。リクエストは、概念的にはインターネット上のアプリケーションから発生し、従って、セキュリティ及びプライバシー要件は、プライベートな法人ネットワーク内のアプリケーションについての要件よりも遥かに緩い。新たなトレンドは、セキュアなマルチテナンシーであり、ここでは、クラウドプロバイダが、クラウドの外部におけるクライアントの分散オフィスネットワークとクラウド内における仮想プライベートネットワーク（“ＶＰＮ”）との間にＶＰＮの様な接続を提供する。このことは、クラウド内にあるクライアントのアプリケーションが、法人のワイドエリアネットワーク（“ＷＡＮ”）に類似するネットワーク環境において動作することを可能とする。データセンタを所有する法人の範囲内の顧客にのみこれらサービスが提供されるプライベートデータセンタについては、マルチテナンシーについてのセキュリティ及びプライバシー要件が緩和される。パブリックデータセンタについては、複数個のテナントからのトラフィックが隔離されること、及び、１つのクライアントからのトラフィックが他へ到達する可能性のないことを、クラウド事業者が保証しなければならない。いずれのケースにおいても、クラウドコンピューティング施設は、ＭＡＣレイヤの仮想ローカルエリアネットワーク（“ＶＬＡＮ”）を使用して、クラウドコンピュータネットワークを実装する傾向を有する。

例えば、２つの異なる外部の企業顧客に対して２つの仮想プライベートクラウド（“ＶＰＣ”）がセットアップされることが可能である。ＶＰＣは、クラウド内で空間を賃借している企業にセキュアなマルチテナンシーを提供する、ＶＭ、ストレージ、及びネットワーキングリソースの集まりからなる。企業顧客は、パブリック事業者ネットワーク上で稼働するインターネット上で、ＶＰＮを介してＶＰＣ内へ接続する。

ＶＰＣに新たなサービスインスタンス（新たなＶＭ）を追加するために、クラウド実行マネージャは、当該ＶＭを、仮想化されたサーバ上のハイパーバイザ上で稼働するように初期化する。仮想化されたサーバ上の仮想スイッチは、新たなＶＭを追加する企業についてのＶＰＮの一部分であるＶＬＡＮ内に、当該ＶＭを含むように構成される。いくつかのケースでは、新たなサービスについて仮想顧客エッジルータが更新され、その新たなサービスでクラウドコンピューティング施設内のプロバイダエッジルータが更新される。

ＶＰＮを提供するために、クラウドコンピューティング施設は、３つの解決策のうちの１つを実装する。第一に、各テナントは、別々のＶＬＡＮスライスを受信する。第二に、テナントＶＰＮは、ＩＰカプセル化を使用して実装される。第三に、テナントＶＰＮは、ＭＡＣアドレスカプセル化を使用して実装される。これら解決策の各々は、異なる欠陥に苦慮している。

クラウドがＶＬＡＮ隔離を用いる場合、各テナントには別々のＶＬＡＮタグが割り当てられ、クラウドネットワークは、フラットなレイヤ２ネットワークとして稼働する。ＶＬＡＮタグは１２ビットを有し、そのため、クラウド事業者がＶＬＡＮ隔離を使用する場合、テナントの数は、４０９６に制限される。この限度が、主たる限界を提供する。

ＶＬＡＮ隔離の他の問題は、標準的なエリアネットワーキング（例えば、ＬＡＮ、ＷＡＮ、ＭＡＮ；ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１）スイッチングがスパニングツリープロトコル（“ＳＴＰ”）を使用して、ルートをセットアップすることである。ルーティングループの可能性をなくすために、ＳＴＰは、複数個のルートが存在するかどうかに関わらず、ソースアドレスと宛て先アドレスとの間に唯一のパスを指定する。スパニングツリールートがトラフィック圧迫下に入り、且つ代替ルートが無視される場合、このことは、スイッチングファブリックの輻輳及び過少利用を招く恐れがある。

ＩＰカプセル化の場合、クラウドは、ルーテッドＩＰネットワークとして稼働され、テナントのトラフィックを隔離するためにＩＰトンネルが使用される。トンネルのエンドポイントが、ＶＭが稼働している仮想化されたソースサーバ及び仮想化された宛て先サーバ上のソース仮想スイッチ及び宛て先仮想スイッチであるという状態で、テナントからのトラフィックは、（典型的には“ＧＲＥ”（Generic Routing Encapsulation)を使用して）ＩＰパケット内にカプセル化される。

ＩＰカプセル化は、クライアントが、レイヤ２トンネリングプロトコル（“Ｌ２ＴＰ”）においてイーサネットフレームをカプセル化することにより、任意のレイヤ２サービスを最上位に定義することを可能とする。ＩＰカプセル化は、クラウドワイドなＩＰアドレス空間によってのみ制約を受ける、多数のテナントを可能にもする。テナントは、それ自体のＩＰアドレス空間をＩＰトンネルの最上位に配備することもできる。しかしながら、その他の方策が無ければ、ＩＰルーティングは単一ルートも選択し、そのため、マルチパスルートが無視されて不必要な輻輳を招く。クラウドルーティングは、複数個のリンクにわたってパケットを拡散させるために等コストマルチパスを利用することができるものの、追加的な構成の複雑さという犠牲を伴う。

概して、ＩＰルーテッドネットワークを構成することは時間を消費し、ルータは、簡素なスイッチよりも、より高価なデバイスである傾向を有する。加えて、大規模なデータフローにとって必要であり得る専用帯域幅を提供するためにＩＰネットワークが有する手段は限られている。

ＭＡＣカプセル化の場合、別々のテナントＶＰＮは、ＩＰカプセル化と同様に、ＭＡＣトンネルの内側でカプセル化されるように稼動する。ＭＡＣトンネルのエンドポイントは、典型的には、ＶＭが稼働している仮想化されたソースサーバ及び仮想化された宛て先サーバ上の仮想スイッチである。

ＭＡＣカプセル化は、ＶＬＡＮ隔離型を上回る、ＩＰカプセル化と同様の恩恵を提供し、所望であれば、クラウドをフラットなレイヤ２ネットワークとして稼働させることが可能であるという、付加された恩恵を伴う。欠点は、ＩＰとは異なり、ＭＡＣカプセル化についてのシグナリングプロトコルについての標準が少ししか存在せず、データプレーンカプセル化についての標準は存在するものの、それらがいくつかの既存のクラウド管理ソフトウェアプロダクトにおいては使用されないことである。このことは、あるタイプのハードウェアと共に作用しないというリスクを生じる。ＭＡＣカプセル化ネットワークを構成して維持することもまた、ＶＬＡＮ隔離型ネットワークを維持することよりも、より複雑である。

本発明の実施形態は、クラウドネットワークマネージャ（“ＣＮＭ”）により実行される、クラウドネットワークでのマルチプロトコルラベルスイッチング（“ＭＰＬＳ”）フローエントリを管理するための方法を含む。ＣＮＭは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための第１の仮想化されたサーバへ連結され、第１の仮想化されたサーバは、ＭＰＬＳをサポートする第１の仮想スイッチを含み、第１の仮想スイッチは、ＭＰＬＳをサポートする第１の“ＴＯＲＳ（first top of rack switch）”へ連結される。ＣＮＭは、特定のテナントへ属する第１のＶＭが仮想化されたサーバ上でのアクティブ化のためにスケジューリングされたことを示す第１の通知メッセージをを受信する。第１の通知メッセージの受信に応じて、ＣＮＭは、第１のＶＭに関連付けられる第１のＶＭメディアアクセス制御（“ＭＡＣ”）アドレスを判定する。さらに、ＣＮＭは、第１の仮想スイッチに関連付けられる第１の仮想スイッチＭＡＣアドレスを判定する。ＣＮＭは、アドレスマッピングテーブル内に、テナント識別子、第１のＶＭ ＭＡＣアドレス及び第１の仮想スイッチＭＡＣアドレスの間の関連付けを記録する。ＣＮＭは、さらに、第１のＴＯＲＳを第１の仮想スイッチに関連付ける第１のＭＰＬＳラベルと、テナントを識別するテナントＭＰＬＳラベルとを判定する。ＣＮＭは、第１のＭＰＬＳラベル、テナントＭＰＬＳラベル及び第１のＶＭ ＭＡＣアドレスに適合するデータパケットが当該テナントＭＰＬＳラベル及び第１のＭＰＬＳラベルをポップした後に第１のＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを、第１の仮想スイッチへ送信する。

本発明の実施形態は、複数の“ＴＯＲＳ（top of rack switch）”と、複数の仮想化されたサーバと、当該複数の仮想化されたサーバへ連結されるクラウド実行マネージャ（“ＣＥＭ”）と、上記複数のＴＯＲＳへ連結されるクラウドネットワークマネージャ（“ＣＮＭ”）とを含むマルチプロトコルラベルスイッチング（“ＭＰＬＳ”）クラウドネットワークを管理するためのシステムを含む。

上記複数の仮想化されたサーバは、各々が上記複数のＴＯＲＳのうちの１つへ連結され、ハイパーバイザ及び仮想スイッチを備える。上記ハイパーバイザは、仮想化されたサーバ上で１つ以上の仮想マシン（“ＶＭ”）を実行するように構成される。上記仮想スイッチは、ＭＰＬＳをサポートし、１つ以上のＶＭからその仮想化されたサーバと連結されるＴＯＲＳへデータパケットを送信するように構成される。

ＣＥＭは、複数の仮想化されたサーバへ連結される。さらに、ＣＥＭは、１つ以上のＶＭの実行をスケジューリングし、各ＶＭが上記複数の仮想化されたサーバのうちの１つの上で実行されるものとされる。ＣＥＭは、さらに、１つ以上のＶＭの実行を中断し、当該１つ以上のＶＭの実行を、上記複数の仮想化されたサーバのうちの１つから当該複数の仮想化されたサーバのうちの他の１つへと移動させる。

ＣＮＭは、複数のＴＯＲＳ、複数の仮想化されたサーバ、及びＣＥＭへ連結される。ＣＮＭは、第１の通知メッセージをＣＥＭから受信し、当該第１の通知メッセージは、第１のＶＭが複数の仮想化されたサーバのうちの第１の仮想化されたサーバ上でのアクティブ化のためにスケジューリングされたことと、テナントの識別子とを示す。第１の通知メッセージに応じて、ＣＮＭは、以下を実行する。ＣＮＭは、第１のＶＭに関連付けられる第１のＶＭメディアアクセス制御（“ＭＡＣ”）アドレスを判定する。ＣＮＭは、第１の仮想化されたサーバ内の第１の仮想スイッチに関連付けられる第１の仮想スイッチＭＡＣアドレスを判定する。ＣＮＭは、アドレスマッピングテーブル内に、上記テナント識別子、第１のＶＭ ＭＡＣアドレス及び第１の仮想スイッチＭＡＣアドレスの間の関連付けを記録する。ＣＮＭは、第１の仮想化されたサーバへ連結されるであろう第１のＴＯＲＳを第１の仮想スイッチに関連付けるための第１のＭＰＬＳラベルを判定する。ＣＮＭは、追加的に、テナント識別子に関連付けられるＭＰＬＳラベルを判定する。ＣＮＭは、第１のＭＰＬＳラベル、テナントラベル及び第１のＶＭ ＭＡＣアドレスに適合するデータパケットが第１のＭＰＬＳラベル及びテナントラベルをポップした後に第１のＶＭへ転送されるべきであることを示す第１のフローエントリ修正メッセージを、第１の仮想スイッチへ送信する。

本発明の実施形態は、ＣＮＭへのテナントＩＤへテナント固有データを隔離するために、テナントデータベースを用いてクラウドネットワークマネージャ（ＣＮＭ）アドレスマッピングテーブルへテナントＩＤ情報を追加することを含む。

１つの実施形態では、クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法が開示される。ＣＮＭは、複数のデータベース又はテーブル内の複数のアイテムの間のマッピングを維持する。当該複数のデータベース又はテーブルは、テナントデータベース（ＤＢ）と、テナント識別子−テナントラベル（ＴＩＴＬ）テーブルと、ＴＯＲＳ（top of rack server）ラベル−仮想スイッチリンクラベル（ＴＬＶＬＬ）テーブルと、ラベルマッピングテーブル（ＳＭＶＬ）と、ＣＮＭアドレスマッピングテーブルとを含む。ＣＮＭは、上記複数のデータベースを用いて、テナントの仮想マシン（ＶＭ）間で送信されるパケットへ付与されるテナント固有ラベルを生成する。１つの実施形態において、ＯｐｅｎＦｌｏｗスイッチ上のインストール又はアンインストールに先立ってデータベースアクセスが実行される。

ＣＮＭは、テナントＩＤをキーとして用いてテナントラベルをルックアップするためにＴＩＴＬテーブルを用いる。ＣＮＭは、ＴＯＲＳ（top of rack server）ラベルをキーとして用いて仮想スイッチ（ＶＳ）リンクラベルをルックアップするためにＴＬＶＬＬテーブルを用いる。

ＣＮＭは、テナントＩＤ、テナントＶＭメディアアクセス制御（ＭＡＣ）アドレス、テナントＶＭインターネットプロトコル（ＩＰ）アドレス及びサーバＭＡＣアドレスの間のマッピングを維持するために、ＣＮＭアドレスマッピングテーブルを用いる。テナントごとに１つのＣＮＭアドレスマッピングテーブルが存在する。

テナントラベルを転送エントリとして追加することにより、テナント固有データが隔離される。テナントＩＤを有するテナントラベルの使用が、テナント固有トラフィックをそれぞれのＶＭへと分離し及び隔離する。１つの実施形態では、異なるテナントへ属する複数のＶＭが同じインターネットプロトコルアドレス及びメディアアクセス制御アドレスを有する。

テナントＤＢは、ＣＮＭアドレスマッピングテーブルへのポインタを保持する。ＣＮＭは、他の全てのＣＮＭアドレスマッピングテーブルのルックアップを実行する前に、まずテナントＤＢでのルックアップを実行して、テナント固有のアドレスマッピングテーブルを見出す。

１つの実施形態では、クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法が開示される。仮想マシン（ＶＭ）が仮想化されたサーバ上でのアクティブ化のためにスケジューリングされるという通知が受信される。ＣＮＭは、ＶＭメディアアクセス制御（ＭＡＣ）アドレスを判定する。ＣＮＭは、仮想化されたサーバ上に所在する仮想スイッチ（ＶＳ）ＭＡＣアドレスを判定する。ＣＮＭは、テナント識別子（ＩＤ）、テナントＭＡＣ及びサーバＭＡＣを含むメッセージを受信する。ＶＳ−ＴＯＲＳ（top of rack switch）ラベル及びテナント固有ラベルを求めて、ラベルマッピングテーブル及びテナント識別子−テナントラベル（ＴＩＴＬ）テーブル内でルックアップが実行される。ＣＮＭマッピングテーブル内に、テナントＩＤ、ＶＭ ＭＡＣアドレス及びＶＳ ＭＡＣアドレスの間の関連付けが記録される。ＣＮＭは、ＶＳ−ＴＯＲＳラベル、テナント固有ラベル及びＶＭ ＭＡＣアドレスに適合するデータパケットがＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを、ＶＳへ送信する。

１つの実施形態では、ＣＮＭは、ＶＭから発せられるＤＨＣＰ（Dynamic Host Configuration Protocol）リクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを、ＶＳへ送信する。１つの実施形態では、ＣＮＭは、ＶＭから発せられるＡＲＰ（Address Resolution Protocol）リクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを、ＶＳへ送信する。

１つの実施形態では、クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法が開示される。宛て先仮想マシン（ＶＭ）へデータパケットを転送する目的でソースＶＳが当該データパケットへまずテナント固有ラベルをプッシュし次いでＶＳ−ＴＯＲＳ（top of rack switch）ラベルをプッシュすべきであることを示すために、第１のフローエントリ修正メッセージがソース仮想スイッチ（ＶＳ）へ送信される。ソースＴＯＲＳがＶＳ−ＴＯＲＳラベルに適合するデータパケットを受信した場合にはソースＴＯＲＳが宛て先ＴＯＲＳラベルをプッシュすべきであることを示すために、第２のフローエントリ修正メッセージがソースＴＯＲＳへ送信される。宛て先ＴＯＲＳが宛て先ＴＯＲＳラベルに適合するデータパケットを受信した場合には宛て先ＴＯＲＳがＴＯＲＳラベルをポップしてデータパケットを宛て先ＶＳへと転送すべきであることを示すために、第３のフローエントリ修正メッセージが宛て先ＴＯＲＳへ送信される。宛て先ＶＳがＶＳ−ＴＯＲＳラベル及びテナント固有ラベルに適合するデータパケットを受信した場合には宛て先ＶＳがまずＶＳ−ＴＯＲＳラベルをポップし次いでテナント固有ラベルをポップすべきであることを示すために、第４のフローエントリ修正メッセージが宛て先ＶＳへ送信される。

第１のフローエントリ修正メッセージに応じて、ソースＶＳは、パケットをソースＴＯＲＳへ転送する。第２のフローエントリ修正メッセージに応じて、ソースＴＯＲＳは、クラウドネットワークを用いてデータパケットを宛て先ＴＯＲＳへ転送する。第３のフローエントリ修正メッセージに応じて、宛て先ＴＯＲＳは、データパケットを宛て先ＶＳへ転送する。第４のフローエントリ修正メッセージに応じて、宛て先ＶＳは、パケットを宛て先ＶＭへ転送する。ＣＮＭは、ソースＶＭがパケットを同じテナントに属する宛て先ＶＭへ転送することを可能とする目的で、宛て先インターネットプロトコルアドレスをソースＶＭへ提供する。

本発明は、本発明の実施形態を例示するために使用される以下の説明及び添付の図面を参照することにより、最も良く理解され得る。図面は次の通りである：

本発明の１つの実施形態に係るクラウドコンピューティング施設内のコンポーネント群を示している。 本発明の１つの実施形態に係るクラウドコンピューティング施設内のコンポーネント群を示している。 本発明の１つの実施形態に従って仮想マシンをアクティブ化するための方法のブロック図を示している。 本発明の１つの実施形態に従って仮想マシンをアクティブ化するための方法を示している。 本発明の１つの実施形態に従ってＶＭからのＤＨＣＰリクエストを傍受するための方法のブロック図を示している。 本発明の１つの実施形態に従って仮想マシンからのＤＨＣＰリクエストを傍受するための方法を示している。 本発明の１つの実施形態に従ってＶＭからのＡＲＰリクエストを傍受するための方法のブロック図を示している。 本発明の１つの実施形態に従って仮想マシンからのＡＲＰリクエストを傍受するための方法を示している。 クラウドコンピューティングネットワークにおいて第１の仮想化されたサーバから第２の仮想化されたサーバへとＶＭを移動させる方法を示している。 本発明の実施形態に係る例示的なコンピュータシステムのブロック図を示している。 テナントＩＤのＣＮＭへの追加を示している。 ＣＮＭを用いてテナント固有データを隔離するための方法を示している。 １つの実施形態に従ってテナントごとに仮想マシンをアクティブ化するための方法のブロック図を示している。 １つの実施形態に従って仮想マシンをアクティブ化するための方法を示している。 １つの実施形態に従ってテナントＶＭからのＤＨＣＰリクエストを傍受するための方法のブロック図を示している。 １つの実施形態に従って仮想マシンからのＤＨＣＰリクエストを傍受するための方法を示している。 １つの実施形態に従って（特定のラベルにより識別される）特定のテナントが宛て先ＩＰアドレスを発見しようと試みる際のＶＭからのＡＲＰリクエストを傍受するための方法のブロック図を示している。 １つの実施形態に従って（特定のラベルにより識別される）特定のテナントが宛て先ＩＰアドレスを発見しようと試みる際の仮想マシンからのＡＲＰリクエストを傍受するための方法を示している。 ＴＯＲＳにより分けられる異なる仮想スイッチ上にある具体的なテナントＶＭへ向けてトラフィックを転送するためのテナントラベルの使用を示している。 ＣＮＭを用いてテナント固有データを隔離するための方法を示す図１２を示している。 ＶＭを移動させる際のデータパスフローを示している。 第１の宛て先ＶＳから第２の宛て先ＶＳへＣＮＭを用いて宛て先ＶＭを移動させる方法を示している。

以下の説明は、クラウドネットワーク内においてマルチプロトコルラベルスイッチング（“ＭＰＬＳ”）フローエントリを管理するための方法及び装置を説明する。以下の説明では、本発明の、より完全な理解をもたらすために、ロジック実装、オプコード、オペランドを特定する手段、リソースパーティショニング／共有／複製の実装、システムコンポーネントのタイプ及び相互関係、並びにロジックパーティショニング／統合の選択肢といった多数の特定の詳細が明記される。しかしながら、本発明がそうした特定の詳細が無くとも実践され得ることが、当業者により認識されるであろう。他の例では、本発明を不明瞭にすることのないように、制御構造、ゲートレベル回路、及び全体的なソフトウェア命令シーケンスは、詳細には示されていない。当業者は、包含される説明があれば、過度の実験を行うことなく、適切な機能性を実装することができるであろう。

明細書における、“１つの実施形態”、“一実施形態”、“例示的な実施形態”などへの言及は、記載される実施形態が特定の特徴、構造、又は特性を含み得るものの、あらゆる実施形態が当該特定の特徴、構造、又は特性を含むわけでは必ずしもないかもしれないことを示す。その上、そうしたフレーズは、必ずしも同じ実施形態を指しているわけではない。さらに、一実施形態との関係において特定の特徴、構造、又は特性が説明されている場合、明示的に記載されているか否かに関わらず、他の実施形態との関係においてそうした特徴、構造、又は特性を作用させることは、当業者の知識の範囲内であることが思量される。

以下の説明及び特許請求の範囲では、“連結される”及び“接続される”という用語が、その派生語と共に使用され得る。これら用語は互いに対して同義語として意図されないことを理解されるべきである。“連結される”は、互いに物理的に又は電気的に直接接触してもしなくておよい２つ以上の要素が互いに協働し又はインタラクションすることを示すために使用される。“接続される”は、互いに連結される２つ以上の要素間における通信の確立を示すために使用される。

理解を容易にするために、あるアイテムのオプション的な特質（例えば、本発明の所与の実装によりサポートされない特徴、所与の実装によりサポートされるものの、ある状況では使用され他では使用されない特徴）を表明するために、図中で破線が使用されている。

図に示される技法は、１つ以上の電子デバイス上で記憶されて実行されるコード及びデータを使用して実装されることができる。そうした電子デバイスは、非一時的であって有形のマシン読取可能な記憶媒体（例えば、磁気ディスク、光ディスク、読み出し専用メモリ、フラッシュメモリデバイス、相変化メモリ）及び一時的なマシン読取可能な通信媒体（例えば、電気的、光学的、音響的、又は他の形式の伝播信号−例えば、搬送波、赤外線信号、デジタル信号など）を使用して、コード及びデータを記憶し、コード及びデータを（内部的に、及び／又は、他の電子デバイスとの間でネットワーク上で）通信する。加えて、そうした電子デバイスは、典型的には、ストレージデバイス、１つ以上の入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、並びにネットワーク接続といった１つ以上の他のコンポーネントと連結されるプロセッサのセット又は１つ以上のプロセッサを含む。プロセッサのセット及び他のコンポーネントの連結は、典型的には、１つ以上のバス又はブリッジ（バスコントローラとも呼称される）を通じて行われる。ネットワークトラフィックを搬送するストレージデバイス及び信号は、それぞれ、１つ以上の非一時的かつ有形のマシン読取可能な媒体及び一時的なマシン読取可能な通信媒体の代表である。よって、所与の電子デバイスのストレージデバイスは、典型的には、当該電子デバイスの１つ以上のプロセッサのセット上での実行のためにコード及び／又はデータを記憶する。当然ながら、本発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの様々な組み合わせを使用して実装されてよい。

本発明の実施形態において、クラウドコンピューティング施設は、ＶＰＣテナントのためのＶＰＮを形成するためにＭＰＬＳを使用し、仮想スイッチ及びＴＯＲＳ内でフロールートをプログラミングする。例えば、ＭＰＬＳスイッチは、２０１１年２月のＯｐｅｎＦｌｏｗスイッチ仕様バージョン１．１．０に記述されているように、ＯｐｅｎＦｌｏｗでフロールートをプログラミングすることができる。仮想スイッチは、イーサネットＭＡＣアドレスを用いて、仮想化されたサーバ上のＶＭへパケットをルーティングし、個別のＭＰＬＳラベルスイッチパス（“ＬＳＰ”）へとパケットを分類するが、仮想スイッチの後には、イーサネットもＩＰアドレスもルーティングのために使用されない。代わりに、ルーティングは、ＩＰ宛て先アドレス及びＭＡＣ宛て先アドレスの双方に基づいて割り当てられるＭＰＬＳラベルを用いて厳密に行われる。その処理は、ワイドエリアネットワークにおける仮想プライベートワイヤサービス（“ＶＰＷＳ”）又はレイヤ３ＶＰＮ（“Ｌ３ＶＰＮ”）に類似しているが同一ではない。“Framework for Layer 2 Virtual Private Networks (L2VPNs)”（ＩＥＴＦ（Internet Engineering Task Force），ＲＦＣ（Request For Comments）４６６４）はワイドエリアネットワークのためのＶＰＷＳを説明しており、一方で“A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)”（ＩＥＴＦ ＲＦＣ４１１０）はＬ３ＶＰＮを説明している。

例えば、クラウドネットワークマネージャ（“ＣＮＭ”）は、ＯｐｅｎＦｌｏｗを使用するフロールートを、ＶＭが稼働している仮想化されたサーバ上の仮想スイッチ内にインストールすることができる。フロールートは、ルートを指定するＭＰＬＳラベルであってＴＯＲＳと宛て先側の仮想スイッチとの間でテナントに固有な当該ＭＰＬＳラベル、及びＶＭを所有するテナントのアイデンティティを指定するラベルと共に、仮想化されたサーバ上のテナントＶＭからのイーサネットフレームをカプセル化する。パケットは、次いで、ソースＶＭの仮想化されたサーバのＴＯＲＳへ転送される。ソースＴＯＲＳは、次いで、パケットをデータセンタのネットワークファブリック内へルーティングする。クラウドネットワークファブリックがＭＰＬＳネットワークである場合、ソースＴＯＲＳは、ソースＴＯＲＳと宛て先ＴＯＲＳとの間のルートを特定する他のＭＰＬＳラベルをプッシュする。宛て先ＴＯＲＳは、当該ＭＰＬＳルーティングラベルをポップし、ソース仮想スイッチによりプッシュされたラベルを使用して、パケットを適正な宛て先サーバ及び仮想スイッチへルーティングする。宛て先仮想スイッチは、ＴＯＲＳから仮想スイッチへのラベルをポップし、当該パケットを、宛て先ＭＡＣアドレスに基づいて正確なＶＭへと転送する。クラウドスイッチファブリックが光技術といった何らかの他の技術をサポートしている場合、ＴＯＲＳは、適切な適応を実行する。

本発明の実施形態は、多数の利点を提供する。例えば、データプレーン上でＩＰルーティングを要さず、それにより、コスト、電力使用量、及び、ＩＰルーテッドクラウドネットワークを有する複雑性が除去される。その設計は、高価ではないＭＰＬＳスイッチのみを要する。クラウド内のスイッチファブリックは、標準的なイーサネットスイッチ、ＭＰＬＳ対応スイッチ、光回路スイッチであることができ、又は、例えば高キャパシティフローには光スイッチであり他のトラフィックには電気的スイッチといった混成物であってさえよい。スイッチファブリックは、分散されたコンピューティングリソースの間のワイドエリアネットワークですらあり得る。ＴＯＲＳは、カプセル化を適正にハンドリングする。テナントは、（所望であれば）それ自体のＩＰアドレス空間、及び（所望であれば）ＤＮＳサーバを管理することができる。クラウドスイッチファブリック内へのルーティングの詳細は、ＴＯＲＳによってハンドリングされ、そこでスケーラビリティ及びアグリゲーションの適正な混成を達成することができる。

図１は、本発明の１つの実施形態に係るクラウドコンピューティング施設内のコンポーネント群を示している。クラウドコンピューティング施設は、クラウドネットワーク１７０を通じて連結される複数のラック内に複数の仮想化されたサーバを含む。これら仮想化されたサーバ及びラックのうち、３つのラック１００Ａ、１００Ｂ、及び１００Ｃが例示されている。例示される各ラックは、ＴＯＲスイッチ（“ＴＯＲＳ”）と、複数の仮想化されたサーバとを含む。ラック１００Ａは、ＴＯＲＳ １０１Ａと、複数の仮想化されたサーバ１０５Ａ〜１０５Ｎとを含む。ラック１００Ｂは、ＴＯＲＳ １０１Ｂと、複数の仮想化されたサーバ１１５Ａ〜１１５Ｎとを含む。ラック１００Ｃは、ＴＯＲＳ １０１Ｃ、仮想化されたサーバ１２５Ａ、及び仮想化されたサーバ１２５Ｂを含む。各ＴＯＲＳ １００Ａ〜１００Ｃは、当該ラック内において複数の仮想化されたサーバを連結し、クラウドネットワーク１７０とさらに連結される。クラウドネットワーク１７０の構造は、任意のタイプのスイッチング又はルーティングプロトコル、例えば、光回線交換ネットワーク、又はＯｐｅｎＦｌｏｗ ＭＰＬＳスイッチのネットワークをサポートすることができる。クラウドネットワーク１７０は、分散されたサーバラックの間で稼働するワイドエリアネットワーク（“ＷＡＮ”）ですらあり得る。図における接続性は、規範的であることを意図しておらず、クラウドネットワーク１７０内においてＴＯＲＳを連結する多くの方式が存在する。図１では、クラウドネットワーク１７０は、複数のスイッチングエレメント（例えば、スイッチ又はルータ）１８０Ａ〜１８０Ｄを含む。

各ＴＯＲＳ１００Ａ〜１００Ｃ、並びに仮想化された各サーバ１０５Ａ〜１０５Ｎ、１１５Ａ〜１１５Ｎ、１２５Ａ及び１２５Ｂは、管理ネットワーク１７５とさらに連結される。管理ネットワーク１７５は、ＴＯＲＳ及び仮想化されたサーバを管理エレメント群と連結する。管理エレメント群は、クラウド実行マネージャ１５０、仮想ディスク１５５、及びクラウドネットワークマネージャ１６０を含む。

クラウド実行マネージャ（“ＣＥＭ”）１５０は、実行のためにＶＭをスケジューリングし、各ＶＭのイメージごとに永久ストレージを提供する仮想ディスク１５５との間でＶＭをマッピングするためのオブジェクトマネージャを含む。クラウドネットワークマネージャ（“ＣＮＭ”）１６０は、テナントＶＰＣのためのＶＰＮを管理する。

図２は、本発明の１つの実施形態に係るクラウドコンピューティング施設内のコンポーネント群を示している。図２は、１つ以上のフローエントリテーブル２１２Ａ〜２１２Ｚを含むＴＯＲＳ２０１Ａを示している。フローエントリテーブル２１２Ａ〜２１２Ｚは、ＯｐｅｎＦｌｏｗへの参照によって説明される通り、ＭＰＬＳラベルをＭＰＬＳアクションにマッチさせるために使用される。ＴＯＲＳ２０１Ａは、１つ以上の仮想化されたサーバ２１５Ａ〜２１５Ｎと連結される。

仮想化された各サーバ２１５Ａ〜２１５Ｎは、１つ以上のＶＭを実行するように構成される。図２において、仮想化されたサーバ２１５Ａは、ＶＭ（例えば、ＶＭ Ｔｌ及びＶＭ Ｔ２）の実行をスケジューリングするハイパーバイザ２１６Ａを含む。仮想化されたサーバ２１５Ａは、仮想スイッチ２１７Ａをさらに含む。仮想スイッチ２１７Ａは、ハイパーバイザの制御下において実行するＶＭへの仮想ネットワークポートを提供する。仮想スイッチ２１７Ａは、ＯｐｅｎＦｌｏｗへの参照によって説明される通り、ＭＰＬＳラベルをＭＰＬＳアクションにマッチさせるために使用される１つ以上のフローエントリテーブル２１８Ａ〜２１８Ｚを含む、ＭＰＬＳ対応型スイッチである。

ＴＯＲＳ２０１Ａは、図１に記載されているクラウドネットワークといったクラウドネットワーク２７０と連結される。ＴＯＲＳ２０１Ａは、管理ネットワーク２７５とさらに連結される。図２におけるように、管理ネットワーク２７５は、ＴＯＲＳ及び仮想化されたサーバを、ＣＥＭ２５０、仮想ディスク２５５、及びＣＮＭ２６０といった管理エレメントと連結する。ＣＮＭ２６０は、アドレスマッピングテーブル２６２及びラベルマッピングテーブル２６４を含む、ＶＰＮを記述するテーブル群を含む。アドレスマッピングテーブル２６２は、ＶＭのＭＡＣアドレス、ＶＭを稼働させている仮想化されたサーバのＭＡＣアドレス（これは、仮想スイッチ２１７ＡのＭＡＣアドレスである）、及びＶＭのＩＰアドレス間で、マッピングを行う。ラベルマッピングテーブル２６４は、仮想化されたサーバ２１５ＡのＭＡＣアドレス（これは、仮想スイッチ２１７ＡのＭＡＣアドレスである）を、仮想スイッチ２１７ＡとＴＯＲＳ２０１Ａとの間のリンクについてのＴＯＲＳリンクラベルにマッピングする。他の実施形態において、ＣＮＭ２６０は、どの“ＤＨＣＰ（Dynamic Host Configuration Protocol）”及び“ＤＮＳ（Domain Name Service）”サーバ（もしあれば）がどのテナントに属しているのかをトラッキングする。

１つの実施形態において、ＣＮＭは、テナントＶＭがそれらのＩＰスタックをいかに構成するかに関して良好に振る舞い、それらのＩＰ／ＭＡＣアドレスは任意に変更されないものと想定する。テナントＶＭの振る舞いが悪く、そうした変更を行う場合、そのパケットはＣＮＭへルーティングされ、ＣＮＭは、ＣＥＭへの通知を行うであろう。すると、ＣＥＭは、違反するＶＭをシャットダウンすることができる。

図３は、本発明の１つの実施形態に従って仮想マシンをアクティブ化するための方法のブロック図を示している。ブロック３００において、ＣＮＭは、ＶＭが、仮想化されたサーバ上でアクティブ化のためにスケジューリングされるという通知を受信する。例えば、ＣＥＭは、ＣＥＭがアクティブ化のためにＶＭをスケジューリングしたことをＣＮＭへ通知する。ＣＮＭは、ブロック３１０において、ＶＭのＭＡＣアドレス及びテナント識別子を判定する。１つの実施形態において、ＣＥＭは、ＣＮＭへＶＭのＭＡＣアドレス及びテナント識別子を上記通知と共に提供し、その一方で、他の実施形態では、ＣＥＭは、ＣＮＭへ別々のメッセージにおいてＶＭのＭＡＣアドレス及びテナント識別子を提供する。ブロック３１５において、ＣＮＭは、ＶＭがアクティブ化されるであろう仮想サーバ上に所在する仮想スイッチに対応する、仮想スイッチのＭＡＣアドレスを判定する。ブロック３２０において、ＣＮＭは、ＣＮＭのアドレスマッピングテーブル内に、テナント識別子、ＶＭのＭＡＣアドレス及び仮想スイッチのＭＡＣアドレスの間の関連付けを記録する。ＣＮＭは、ブロック３２５において、仮想スイッチを当該仮想スイッチと連結されるＴＯＲＳに関連付けるＭＰＬＳラベルをさらに判定する。ブロック３３０において、ＣＮＭ３３０は、ＭＰＬＳラベル、テナント識別子及びＶＭのＭＡＣアドレスに適合するデータパケットが２つのＭＰＬＳラベルをポップした後にＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを、仮想スイッチへ送信する。１つの実施形態において、ＣＮＭは、ブロック３３２において、ＶＭから発せられるＤＨＣＰリクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを仮想スイッチへ送信する。他の実施形態において、ＣＮＭは、ブロック３３３において、ＶＭから発せられるアドレス解決プロトコル（“ＡＲＰ”）リクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを仮想スイッチへ送信する。

図４は、本発明の１つの実施形態に従って仮想マシンをアクティブ化するための方法を示している。図４において、ＴＯＲＳ４０１Ａは、仮想化されたサーバ４１５Ａと連結される。仮想化されたサーバ４１５Ａは、ハイパーバイザ４１６Ａ及び仮想スイッチ４１７Ａを含む。図４において、仮想化されたサーバ４１５Ａは、２つのアクティブなＶＭ Ｔｌ ４９０Ａ及びＶＭ Ｔ２ ４９０Ｂを有する。さらに、図４は、ＣＥＭ４５０、仮想ディスク４５５、及びＣＮＭ４６０を示す。

図４において、ＣＥＭ４５０は、仮想化されたサーバ４１５Ａ上での実行のために、第３のＶＭ Ｔ３ ４９０Ｃをスケジューリングしている。この図は、仮想マシンのアクティブ化の期間中における様々なポイントを描いている。ポイントＡにおいて、ＣＥＭ４５０は、ＶＭ Ｔ３ ４９０Ｃ、例えば、テナント３に属するＶＭを、実行のためにスケジューリングする。オブジェクトファイルは、仮想ディスク４５５からＣＥＭのオブジェクトマネージャを通じてマッピングされる。ＣＥＭは、テナント３に割り当てられたＭＡＣアドレスのうちの１つにＶＭ４９０Ｃの ＭＡＣアドレスを設定するように、ＶＭ４９０Ｃのスタックを編集する。ポイントＢにおいて、ＣＥＭ４５０は、ＣＮＭ４６０へアクティブ化を通知する。ＣＥＭ４５０は、ＶＭ４９０ＣのＭＡＣアドレスと、当該ＶＭを実行する仮想化されたサーバ４１５ＡのＭＡＣアドレス（これは、仮想化されたサーバ４１５Ａの仮想スイッチ４１７ＡのＭＡＣアドレスである）と、そのテナントの識別子とを、ＣＮＭ４６０へ提供する。

ポイントＣにおいて、ＣＮＭ４６０は、ＣＮＭのアドレスマッピングテーブル（図示せず）内に、テナント識別子とＶＭ４９０ＣのＭＡＣアドレスとを、スケジューリングがなされた仮想化されたサーバ４１５ＡのＭＡＣアドレスと共に記録する。ポイントＤにおいて、ＣＮＭ４６０は、ＶＭ４９０Ｃが稼働している仮想化されたサーバ４１５ＡとＴＯＲＳ４０１Ａとの間のリンクについての、仮想スイッチ−ＴＯＲＳ４０１ＡのＭＰＬＳラベル（これは、ソースＴＯＲＳ“ＳＴＯＲＳ”リンクラベルとしても知られている）と、テナントラベルとを、ＣＮＭ４６０のラベルマッピングテーブルからルックアップする。ポイントＥにおいて、ＣＮＭ４６０は、テナントラベルとＶＭ４９０ＣのＭＡＣとＳＴＯＲＳリンクラベルとを、当該ＳＴＯＲＳリンクラベル及び当該テナントラベルをポップしてパケットをＶＭ４９０Ｃへ転送するアクションにマッチさせるルールをインストールするためのフローエントリ修正メッセージを、ＭＰＬＳ対応型仮想スイッチ２１７Ａへ送信する。

１つの実施形態において、ＣＮＭ４６０は、ポイントＦにおいて、以下のルールをインストールするために、第２のフローエントリ修正メッセージを仮想スイッチ２１７Ａへ送信する。ソースＭＡＣがＶＭ４９０ＣについてのＭＡＣアドレスに適合し、且つ、プロトコルがＡＲＰである場合、パケットをＣＮＭ４６０へルーティングして、ＣＮＭ４６０がＡＲＰリクエストにサービスすることを可能とする。このルールは、ＡＲＰトラフィックを削減し、ＣＮＭ４６０がＣＮＭアドレスマッピングテーブルから回答することを可能とする。

他の実施形態において、ＣＮＭ４６０は、ポイントＧにおいて、以下のルールをインストールするために、第３のフローエントリ修正メッセージを仮想スイッチ２１７Ａへ送信する。ソースＭＡＣがＶＭ４９０ＣについてのＭＡＣアドレスに適合し、且つ、プロトコルがＤＨＣＰである場合、パケットをＣＮＭ４６０へルーティングして、ＣＮＭ４６０がＤＨＣＰリクエストにサービスすることを可能とする。このルールは、ＣＮＭ４６０が、ＤＨＣＰサーバからの応答パケットを傍受することにより、ＣＮＭアドレスマッピングテーブル内に、ＭＡＣアドレスからＩＰアドレスへのマッピングを記録することを可能とする。テナントがＩＰアドレスを取得するためにＤＨＣＰを使用する場合、このステップを要する。

図４は、これまでに説明した全ての３つのフローエントリ修正メッセージが通信されたということを前提として、仮想スイッチ４１７Ａのフローエントリテーブル４１８Ａ内の３つのエントリを例示する。フローエントリテーブル４１８Ａには、５つの列、即ち、ソースＭＡＣ、宛て先ＭＡＣ、ＭＰＬＳラベル、ＩＰプロトコル、及びアクション、が例示されている。フローエントリは、４９０Ｃのアクティブ化に対応する。

図示したフローエントリテーブル４１８Ａ内の第１のエントリは、ソースＭＡＣアドレスとしてＶＭ Ｔ３ ４９０ＣのＭＡＣアドレスに適合する。宛て先ＭＡＣアドレス及びＭＰＬＳラベルは、いかなるエントリにも適合するように設定され、その一方で、ＩＰプロトコルは、ＡＲＰプロトコルに適合するように設定される。アクションは、次いで、ＣＮＭ４６０へ転送することである。このルールは、上記のステップＦに対応する。

図示したフローエントリテーブル４１８Ａ内の第２のエントリは、ソースＭＡＣアドレスとしてＶＭ Ｔ３ ４９０ＣのＭＡＣアドレスに適合する。宛て先ＭＡＣアドレス及びＭＰＬＳラベルは、いかなるエントリにも適合するように設定され、その一方で、ＩＰプロトコルは、ＤＨＣＰプロトコルに適合するように設定される。アクションは、次いで、ＣＮＭ４６０へ転送することである。このルールは、上記のステップＧに対応する。

図示したフローエントリテーブル４１８Ａ内の第３のエントリは、宛て先ＭＡＣアドレスとして全てのＭＡＣに適合する。宛て先ＭＡＣアドレスは、ＶＭ Ｔ３ ４９０ＣのＭＡＣアドレスに適合するように設定され、その一方で、ＭＰＬＳラベルは、ＶＳ−ＴＯＲＳ４０１のリンクラベルに設定され、その他はテナントラベルに設定される。ＩＰプロトコルは、全てのエントリに適合するように設定される。アクションは、次いで、ＭＰＬＳラベルをポップしてパケットをＶＭ Ｔ３ ４９０Ｃへ転送することである。このルールは、上記のステップＥに対応する。

上で説明したように、ＣＮＭは、ＶＭ ＭＡＣアドレス、仮想化されたサーバのＭＡＣ、及びＶＭ ＩＰアドレスの間のマッピングを維持する。テナントがＤＨＣＰアドレスを使用しないことを選んだ場合、ＣＥＭは、スケジューリングの実行に先立ってＶＭのＩＰスタックを修正し、静的なＩＰアドレスをインストールする。しかしながら、他の実施形態において、テナントは、ＤＨＣＰアドレスを使用することを選ぶであろう。そうしたケースにおいて、ＣＮＭは、“DHCP Relay Agent Information Option”（ＩＥＴＦ，ＲＦＣ３０４６、２００１年１月）に従って、ＤＨＣＰリクエストを傍受してリレーとして動作するであろう。

図５は、本発明の１つの実施形態に従ってＶＭからのＤＨＣＰリクエストを傍受するための方法のブロック図を示している。ブロック５００において、ＣＮＭは、ＶＭから発せられたＤＨＣＰリクエストを受信する。ＣＮＭは、ブロック５０５において、ＲＦＣ３０４６に従って、ＤＨＣＰリクエストをＤＨＣＰサーバへ中継する。ブロック５１０において、ＣＮＭは、ＤＨＣＰサーバからＤＨＣＰリプライを受信する。ブロック５１５において、ＣＮＭは、アドレスマッピングテーブル内に、ＶＭのＭＡＣアドレスとＤＨＣＰリプライ内で受信されたＩＰアドレスとの間の関連付けを記録する。本発明の実施形態によれば、当該関連付けは、ＶＭを実行する仮想サーバのＭＡＣアドレスをさらに含む。ブロック５２０において、ＣＮＭは、ＤＨＣＰリプライをＶＭへ転送する。

図６は、本発明の１つの実施形態に従って仮想マシンからのＤＨＣＰリクエストを傍受するための方法を示している。図６において、仮想化されたサーバ６１５Ａは、ハイパーバイザ６１６Ａ及び仮想スイッチ６１７Ａを含む。図６において、仮想化されたサーバ６１５Ａは、３つのアクティブなＶＭ Ｔｌ ６９０Ａ、ＶＭ Ｔ２ ６９０Ｂ、及びＶＭ Ｔ３ ６９０Ｃを有する。仮想スイッチ６１７Ａは、ＶＭ Ｔ３ ６９０ＣからのＤＨＣＰリクエストを、ＤＨＣＰサーバ６３０に連結されるＣＮＭ ６６０へ転送するためのルールを含むフローエントリテーブル６１８Ａを含む。

この図は、仮想マシンからのＤＨＣＰリクエストの傍受の期間中における、様々なポイントを描いている。ポイントＡにおいて、ＶＭ Ｔ３ ６９０Ｃは、ＩＰアドレス、及び、ＤＮＳサーバといった他の構成情報を取得するためのＤＨＣＰリクエストを発行する。ポイントＢにおいて、仮想スイッチ６１７Ａは、ＤＨＣＰリクエストを、当該リクエストをＣＮＭ２６０へルーティングするためのフロールールに照合する。ポイントＣにおいて、ＣＮＭ２６０は、ＤＨＣＰリレーとして動作し、標準的なＤＨＣＰリレーオプションを挿入し、リクエストをテナントのＤＨＣＰサーバ６３０へ転送する。ＣＮＭ６６０は、ＤＨＣＰリクエストのソースＭＡＣアドレスを調査することにより、どのテナントにＶＭ Ｔ３ ６９０Ｃが属しているのかを判定することができる。ポイントＤにおいて、テナントのＤＨＣＰサーバ６３０は、ＶＭ Ｔ３ ６９０ＣについてのＩＰアドレス及び他の構成情報を包含するＤＨＣＰリプライで応答する。ポイントＥにおいて、ＣＮＭ６６０は、ＣＮＭのアドレスマッピングテーブル２６２内に、ＶＭ Ｔ３ ６９０ＣのＭＡＣアドレスとＩＰアドレスとの間のマッピングを記録する。ポイントＦにおいて、ＣＮＭ６６０は、ＤＨＣＰリレーオプションを取り除き、ＤＨＣＰリプライを仮想スイッチ６１７Ａへ転送し、仮想スイッチ６１７Ａは、ポイントＧにおいて、当該リクエストをＶＭ Ｔ３ ６９０Ｃへ返送する。

典型的なＩＰ ＬＡＮのシナリオにおいて、宛て先アプリケーションと通信することを望む、サーバ内で稼働するソースアプリケーションは、ＤＮＳを使用して、宛て先アプリケーションのＩＰアドレスを発見する。ＩＰアドレスが見つかった後に、ソースサーバ内のＩＰスタックは、宛て先のＩＰアドレスとＭＡＣアドレスとの間のマッピングを発見するためにＡＲＰメッセージをブロードキャストする。宛て先は、ローカルＬＡＮ上に存在する場合、ＡＲＰに応答する。宛て先がローカルＬＡＮ上で稼働していない場合、ソースサーバのＩＰスタックは、ローカルルータのＭＡＣアドレスを、他のサブネットへのゲートウェイとして使用する。

クラウド内において、ＶＭは、仮想化されたＬＡＮの最上位で稼働する。テナントは、それ自体のＤＮＳサーバを稼働させるか、又は、クラウド事業者からＤＮＳサービスを購入する。ＶＭは、当該ＶＭが使用することになるＤＮＳサーバのアドレスと共に構成される。テナントは、サービスにコンタクトすることを望む場合、ちょうど正規の法人ＬＡＮ内におけるように、ＩＰアドレスを発見するためのＤＮＳリクエストをＤＮＳサーバへ送信する。ＤＮＳサーバは、クラウド事業者の制御下にあるか、又は、個々のテナントにより制御されることが可能である。ＤＮＳリプライが返ってきた場合、ＶＭは、ＩＰからＭＡＣアドレスへのマッピングを判定するためのＡＲＰリクエストをブロードキャストする。

本発明の実施形態において、仮想スイッチは、ＡＲＰメッセージを傍受して、それをブロードキャストするよりもむしろ、ＣＮＭへ中継する。ＣＮＭは、ＡＲＰメッセージがクラウドネットワークの全体にわたってブロードキャストされる必要がないように、アドレスマッピングサービスを提供する。

図７は、本発明の１つの実施形態に従ってＶＭからのＡＲＰリクエストを傍受するための方法のブロック図を示している。ブロック７００において、ＣＮＭは、ＶＭから発せられたＡＲＰリクエストを受信する。ＣＮＭは、ブロック７０５において、ＡＲＰリクエストから宛て先ＩＰアドレスを判定する。ブロック７１０において、ＣＮＭは、ＩＰアドレスに対応する、宛て先ＶＭ ＭＡＣアドレス及び宛て先仮想スイッチＭＡＣアドレスを判定する。例えば、ＣＮＭは、ＡＲＰリクエスト内のＩＰアドレスに基づいて、ＣＮＭのアドレスマッピングテーブルからマッピングをルックアップすることができる。ブロック７１５において、ＣＮＭは、宛て先仮想スイッチＭＡＣアドレスに対応する宛て先ＭＰＬＳラベルを判定する。ブロック７２０において、ＣＮＭは、ソースＶＭを実行している仮想サーバ上の仮想スイッチへフローエントリ修正メッセージを送信する。当該エントリ修正メッセージは、ソースＶＭ ＭＡＣアドレス及び宛て先ＶＭ ＩＰアドレスに適合するパケットに、まずテナントｉｄラベルがプッシュされ、次に宛て先ＭＰＬＳラベルがプッシュされ、そして当該パケットがソース仮想スイッチについてのＴＯＲＳへと転送されるべきであることを示す。ブロック７２５において、ＣＮＭは、宛て先ＶＭ ＭＡＣアドレスが宛て先ＩＰアドレスに対応していることを示すＡＲＰリプライを生成する。ＣＮＭは、ブロック７３０において、ＡＲＰリプライをソースＶＭへ転送する。なお、宛て先ＶＭがパケットのソースであることから、ＣＮＭは、厳密に同じルールを、宛て先ＶＭのＭＡＣアドレス及びソースＶＭのＩＰアドレスと共に、宛て先ＶＳ内にインストールする。

図８は、本発明の１つの実施形態に従って仮想マシンからのＡＲＰリクエストを傍受するための方法を示している。図８において、仮想化されたサーバ８１５Ａは、ハイパーバイザ８１６Ａ及び仮想スイッチ８１７Ａを含む。図８において、仮想化されたサーバ８１５Ａは、アクティブなＶＭ Ｔ３ ８９０Ｃを有する。仮想スイッチ８１７Ａは、ＶＭ Ｔ３ ８９０ＣからのＡＲＰリクエストをＣＮＭ８６０へ転送するためのルールを含むフローエントリテーブル８１８Ａを含む。仮想化されたサーバ８１６Ａは、ＴＯＲＳ８０１と連結され、ＴＯＲＳ８０１は、クラウドネットワーク８７０を通じて他のＴＯＲＳ８０１Ｃへ連結される。ＴＯＲＳ８０１Ｃは、ハイパーバイザ８２６Ｂ及び仮想スイッチ８２７Ｂを含む、仮想化されたサーバ８２５Ｂと連結される。仮想化されたサーバ８２５Ｂは、ＶＭ Ｔ４ ８９５Ｂを実行している。

この図は、ＶＭ Ｔ３ ８９０ＣからのＡＲＰリクエストの傍受の期間中における、様々なポイントを描いている。ポイントＡにおいて、ＶＭ Ｔ３ ８９０Ｃは、ＡＲＰリクエストをブロードキャストする。傍受の残りの部分は、ＡＲＰリクエストが、仮想サーバ８２５Ｂ上に所在する宛て先ＶＭ Ｔ４ ８９５ＢのＩＰアドレスを示すことを前提とする。仮想スイッチ８１７Ａは、ポイントＢにおいて、ＡＲＰリクエストを傍受して、当該リクエストを、フローエントリテーブル８１８Ａ内の、ＡＲＰリクエストをＣＮＭ２６０へルーティングするためのルールと照合する。

ポイントＣにおいて、ＣＮＭ８６０は、要求された宛て先ＩＰアドレス（“ＤＩＰ”）をキーとして使用して、ＣＮＭのアドレスマッピングテーブル２６２内で宛て先ＭＡＣアドレス（“ＤＭＡＣ”）をルックアップする。ＤＩＰが存在しない場合、その宛て先は、クラウド内に存在せず、ＣＮＭは、ＡＲＰリクエストに応答しない。その場合、ＶＭは、提供されたローカルルータのＭＡＣアドレスを使用することになる。ＤＩＰアドレスがＣＮＭのアドレスマッピングテーブル８６２内に存在する場合、ＣＮＭ８６０は、ＤＭＡＣ ＶＭアドレス及びＤＭＡＣ仮想化されたサーバアドレスを取り出す。このケースにおいて、ＣＮＭは、ＶＭ Ｔ４ ８９５ＢのＭＡＣをＤＭＡＣ ＶＭアドレスとして、及び、仮想スイッチ８２７Ｂ ＭＡＣをＤＭＡＣ仮想化されたサーバアドレスとして取り出すであろう。

ポイントＤにおいて、ＣＮＭは、宛て先ＴＯＲＳ（“ＤＴＯＲＳ”）リンクラベルとしても知られる、ＣＮＭのラベルマッピングテーブル８６４からの、宛て先ＴＯＲＳと、ＤＭＡＣ仮想化されたサーバアドレスとの間のリンクについてのＭＰＬＳフローラベルをルックアップする。このフローラベルは、ＴＯＲＳ８０１Ａと、ＤＭＡＣ仮想化されたサーバでの仮想化されたサーバとの間のルートを記述する。このケースでは、ＴＯＲＳ８０１ＡからＴＯＲＳ８０１Ｃへのルートを示すために、ラベルＴＯＲＳ：ＶＳ２０１Ｃ：８２７Ｂ ＬＬが取り出されるであろう。

ポイントＥにおいて、ＣＮＭ８６０は、仮想スイッチの８１７Ａのフローエントリテーブル８１８Ａ内にフロールートをインストールする。ルールは、ＶＭ Ｔ４ ８９５ＢについてのＤＭＡＣ ＶＭ アドレスに適合する。アクションは、ＶＭ Ｔ３ ８９０ＣによりＶＭ Ｔ４ ８９５Ｂへ送信されるトラフィックパケット上にＤＴＯＲＳリンクラベルＴＯＲＳ：ＶＳ８０１Ｃ：８２７Ｂ ＬＬをプッシュし、次いで、当該パケットをＴＯＲＳ８０１Ａへ転送する。ポイントＦにおいて、ＣＮＭ８６０は、ＡＲＰリプライを仮想スイッチ８１７Ａに返し、仮想スイッチ８１７Ａは、当該リプライをＶＭ Ｔ３ ８９０Ｃへ転送する。

１つの実施形態において、ＣＮＭ８６０は、ＶＭへのＡＲＰリプライの返却に先立って、ＶＳ−ＴＯＲＳルール及びアクションを、ＴＯＲＳ８０１のフローエントリテーブル（図示せず）内にインストールする。クラウドネットワーク８７０がＭＰＬＳネットワークである場合、ＡＲＰリプライが返されたときには、クラウドネットワーク８７０のスイッチファブリック内のＴＯＲＳ間のＬＳＰについてのルールは、インストールされる必要がない。クラウドネットワーク８７０のスイッチが追加的にＯｐｅｎＦｌｏｗをサポートする場合、ＣＮＭ８６０は、新たなＴＯＲＳがインストールされるか、又は既存のＴＯＲＳがデコミッションされた時にＯｐｅｎＦｌｏｗを使用する、より高レベルのクラウドネットワーク８７０のスイッチ内に、ＭＰＬＳ転送ルールをインストールするだけでよい。それらルールは、ＴＯＲＳと同じラック内のサーバへのリンク上のＴＯＲＳ−ＶＳラベルを認識し、ラベルにより識別されるリンクを有するパケットをサーバへと転送する。それらルールは、ラックがブートアップされる際に、ＯｐｅｎＦｌｏｗテーブル２へとインストールされる。しかしながら、より高レベルのデータセンタスイッチがＯｐｅｎＦｌｏｗをサポートしない場合、ＴＯＲＳは、その代りにＬＤＰ（label distribution protocol）を使用して、自身と他のＴＯＲＳとの間のＬＳＰをセットアップし、そうするとＬＳＰが構成されるはずである。クラウドネットワーク８７０のスイッチは、ＩＰルーティングプロトコルをサポートする必要も、ルーティングを実行する必要もない。

テーブル１は、本発明の実施形態に係る、宛て先ＴＯＲＳへルーティング中のトラフィック、即ちアウトゴーイングトラフィック及びカレントラック内に宛て先サーバがあるトラフィック、を扱うフローテーブルの一部について、ＴＯＲＳのＯｐｅｎＦｌｏｗフローテーブルのルール構造を示している。インカミングトラフィックについてのルール構造は、後でさらに解説される。ラック内のソースＶＭにより宛て先としてその時点で使用されている、ＤＴＯＲＳ（宛て先ＴＯＲＳ）−ＤＶＳ（宛て先の仮想化されたサーバ）リンクラベルの各々について、テーブル内にフロールールが存在する。ＴＯＲＳは、ＶＭの移動時にインカミングトラフィックを捕捉するためのいくつかのフロールールを追加的にキャッシュしてもよい。ラック内のソースＶＭから来るトラフィックは、仮想スイッチによりプッシュされたＭＰＬＳ ＤＴＯＲＳリンクラベルに適合することによりルーティングされ、当該ルールに関連付けられるアクションがアクティブ化されてパケットに適用される。アクションは、クラウドネットワークの性質に依存して異なる。

クラウドネットワークがＭＰＬＳネットワークではない場合、ＴＯＲＳは、ＯｐｅｎＦｌｏｗ仮想ポートを通じて、トラフィックをクラウドネットワークに適応させる。フローマッチングルール上のアクションに関連付けられる仮想ポートは、パケットを処理し、当該パケットをクラウドネットワーク内へルーティングするために必要な何らかのヘッダを追加する。例えば、ネットワークが光回線交換ネットワークである場合、仮想ポートは、光クロスコネクトを通じてパケットをルーティングしてもよい。当業者は、他のタイプのクラウドネットワークは他の適応仮想ポートを利用することになると理解するであろう。

しかしながら、クラウドネットワークがＭＰＬＳネットワークである場合、（ＯｐｅｎＦｌｏｗテーブル１に対応する）テーブル２において、例示的なアクションが示されている。各アクションは、ＳＴＯＲＳからＤＴＯＲＳへのルーティングラベルをプッシュし、次いでパケットをＯｐｅｎＦｌｏｗ ＳＥＬＥＣＴグループへ送信する。ＳＥＬＥＣＴグループは、等コストマルチキャスト（ＥＣＭＰ）又は何らかの他の負荷分散アルゴリズムを使用して、出力ポートバケットリストから１つの出力ポートバケットを選択し、パケットを出力ポートへ転送する。負荷分散は、輻輳を回避することを助け、２つのＴＯＲＳ間の全てのルートのマルチパス利用を促進する。

パケットは、宛て先ＴＯＲＳへ一旦到着すると、（ＯｐｅｎＦｌｏｗテーブル１に対応する）テーブル３及び（ＯｐｅｎＦｌｏｗテーブル２に対応する）テーブル４に示されるようなＯｐｅｎＦｌｏｗフローテーブルを通じてルーティングされる。パケットが宛て先ＴＯＲＳにおいて“ＬＡＢＥＬ−Ｎ”というラベルを有するものと想定すると、ルールは、パケットがこのＴＯＲＳ宛てであることを示すＤＴＯＲＳルーティングラベル“ＬＡＢＥＬ−Ｎ”に適合する。アクションは、ＤＴＯＲＳルーティングラベルをポップし、処理のためにパケットをテーブル４へ送出する。テーブル４のルールは、パケットがどの仮想化されたサーバ宛てであるのかを示す、ラック内のサーバについてのＶＳ−ＴＯＲＳラベルに適合する。アクションは、パケットを、当該仮想化されたサーバに到達するための適切なポートから転送する。

仮想スイッチ８２７Ｂにおいて、ＶＭ Ｔ４ ８２７Ｂの ＭＡＣアドレスと、テナントラベルと、ＶＳ−ＴＯＲＳルーティングラベルとに適合するルールがトリガされる。ＶＳ−ＴＯＲＳルーティングラベル及びテナントラベルはポップされ、パケットは、ＶＭ Ｔ４ ８２７Ｂへ転送される。

クラウドネットワーキングの最も困難な局面のうちの１つは、ＶＭの、第１の仮想化されたサーバから第２の仮想化されたサーバへの移動を扱うことである。ＣＥＭは、ＶＭを１つのサーバから他のサーバへといつでも移動させることができる。移動は、サーバ利用率を最適化するため、電力消費若しくは発熱を低減するため、又は、データベースといった外部リソースへのアクセスへより近いアクセスを有するようにＶＭを位置させるために、行われ得る。そうした移動が生じる場合、古いサーバにおけるＶＭへのルートは、もはや有効ではない。ＶＭを移動させている間の“転送中（in flight）”のパケットは、破棄される恐れがあり、新たなパケットは、ルートを整備する方策が取られない限り、ＶＭの新たなロケーションへ到達しないかもしれない。

図９は、クラウドコンピューティングネットワーク内において第１の仮想化されたサーバから第２の仮想化されたサーバへとＶＭを移動させる方法を示している。図９において、第１の仮想化されたサーバ９１５Ａ（古い仮想化されたサーバとも称される）は、クラウドネットワーク９７０へ連結されるＴＯＲＳ９０１Ａと連結される。クラウドネットワーク９７０は、ＴＯＲＳ９０１Ａを他のＴＯＲＳ９０１Ｃと連結し、ＴＯＲＳ９０１Ｃは、第２の仮想化されたサーバ９２５Ａ（新たな仮想化されたサーバとも称される）へ連結される。

各仮想化されたサーバ９１５Ａ及び９２５Ａは、複数のＶＭを稼働させ、対応するハイパーバイザ９１６Ａ及び９２６Ａ、並びにＭＰＬＳ対応型仮想スイッチ９１７Ａ及び９２７Ａを含む、ように構成される。各仮想スイッチ９１７Ａ及び９２７Ａは、対応する仮想スイッチがそれ自体が受信するパケットをいかに処理すべきかを示すためのＭＰＬＳルール群を含むフローエントリテーブル９１８Ａ及び９２８Ａを含む。ＶＭの移動のために使用される固有のエントリについて、以下に詳細に議論する。図９の例示に先立ち、古い仮想化されたサーバ９１５Ａは、３つのアクティブなＶＭ、即ち、ＶＭ Ｔｌ ９９０Ａ、ＶＭ Ｔ２ ９９０Ｂ、及びＶＭ Ｔ３ ９９０Ｃを有する。図９は、管理ネットワーク９７５を通じてＣＮＭ９６０と連結されるＣＥＭ９５０をさらに例示する。管理ネットワークは、ＣＥＭ９５０及びＣＮＭ９６０をＴＯＲＳ９１５Ａ及び９２５Ａとさらに連結し、それにより、仮想化されたサーバ９１５Ａ及び９２５Ａへの通信パスを提供する。

この図は、古い仮想化されたサーバ９１５Ａから新たな仮想化されたサーバ９２５Ａへの、ＶＭ Ｔ３ ９９０Ｃの移動の期間中における様々なポイントを描いている。古い仮想化されたサーバ及び新たな仮想化されたサーバという用語は、移動に先立ってＶＭ Ｔ３ ９９０Ｃが古い仮想化されたサーバにおいてアクティブであったこと、及び、移動の後にＶＭ Ｔ３ ９９０Ｃが新たな仮想化されたサーバ９２５Ａにおいてアクティブになるであろうことを反映している。

ポイントＡにおいて、ＣＥＭ９５０は、古い仮想化されたサーバ９１５Ａから新たな仮想化されたサーバ９２５ＡへのＶＭ Ｔ３ ９９０Ｃの移動を開始させる。ポイントＡにおいて、ＣＥＭ９５０から古い仮想化されたサーバ９１５Ａへ送信されているメッセージは、９ Ｔ３ ９９０Ｃの移動が開始されようとしていることを示す。ＶＭ Ｔ３ ９９０Ｃが古い仮想化されたサーバ９１５Ａ上においてアクティブである限り、ＶＭ Ｔ３ ９９０Ｃは、トラフィックに引き続きサービスすることができ、フローエントリテーブル９１８Ａ内では古いフロールールが維持される。ハイパーバイザ９１６Ａは、ＶＭ Ｔ３ ９９０Ｃのステート情報を保存すること、及び、ＶＭ Ｔ３ ９９０Ｃがスタンバイステート又は非アクティブステートに入るように指示することにより、ＶＭ Ｔ３ ９９０Ｃが新たな仮想化されたサーバ９２５Ａへ移行するように準備する。ポイントＢにおいて、ＶＭ Ｔ３ ９９０Ｃのステート情報は、古い仮想化されたサーバ９１５Ａから新たな仮想化されたサーバ９２５Ａへ移行される。

ＶＭ Ｔ３ ９９０Ｃの非アクティブ化の期間中における何らかのポイント、ポイントＣにおいて、ＣＥＭ９５０は、ＶＭ Ｔ３ ９９０Ｃがトラフィックにもはやサービスできないことを決定する。この時、ＣＥＭ９５０は、ＶＭ Ｔ３ ９９０Ｃが移動されているが故にその時点でトラフィックにサービスできないことを、ＣＮＭ９６０へ通知する。このメッセージに反応して、ＣＮＭ９６０は、仮想スイッチ９１７Ａのフローエントリテーブル９１８Ａ内のルールを修正する。よって、ポイントＤにおいて、ＣＮＭ９６０は、宛て先ＭＡＣとしてのＶＭ Ｔ３ ９９０ＣのＭＡＣアドレスに適合し、仮想化されたサーバ９１５ＡをＴＯＲＳ９０１ＡとリンクするＭＰＬＳラベルを伴うトラフィックが、ＣＮＭ９６０へ（又は何らかの他のエンティティへ）転送されるべきであることを示すルールをフローエントリテーブル９１８Ａ内にインストールする。ＣＮＭ９６０、又はオプションとして何らかの他のエンティティは、ＶＭ Ｔ３ ９９０Ｃへ向けての古い仮想化されたサーバ９１５Ａへ方向付けられたトラフィックをいかに扱うべきかを、知能部（intelligence）へ提供するであろう。

１つの実施形態において、ＣＮＭ９６０、又は、この目的のために設計された何らかの他のエンティティは、移行ピリオドの期間中にＶＭ Ｔ３ ９９０Ｃ向けのパケットを記憶するために使用されるパケットバッファ９６６を含む。このようにして、パケットバッファ９６６内の、ＶＭ Ｔ３ ９９０向けのパケットは、ＶＭ Ｔ３ ９９０が新たな仮想化されたサーバ９２５Ａにおいて一旦アクティブになると、ＶＭ Ｔ３ ９９０へ送信されることが可能である。

１つの実施形態において、ＶＭ Ｔ３ ９９０が、新たな仮想化されたサーバ９２５Ａにおいてデータにサービスする準備が整うと、ＣＥＭ９５０は、ポイントＥにおいて、ＶＭ Ｔ３ ９９０が再度アクティブになったことをＣＮＭ９６０へ通知する。他の実施形態において、ＣＮＭ９６０は、ＶＭ Ｔ３ ９９０が再度アクティブ化された後にＶＭ Ｔ３ ９９０から発せられる（ＡＲＰリクエストなどの）パケットを当該ＣＮＭ９６０が受信したが故に、ＶＭ Ｔ３ ９９０がアクティブになっていることを検出することができる。ＣＮＭ９６０は、フローエントリテーブル９２８Ａを修正することにより、ＶＭ Ｔ３ ９９０がデータにサービスする準備が整っていることに反応する。

ポイントＦにおいて、ＣＮＭ９６０は、１つ以上のエントリをフローエントリテーブル９２８Ａに追加する。ＣＮＭ９６０は、宛て先ＭＡＣとしてのＶＭ Ｔ３ ９９０ＣのＭＡＣアドレスに適合すると共に、仮想化されたサーバ９２５ＡをＴＯＲＳ９０１ＣとリンクするＭＰＬＳラベル、及びテナントｉｄラベルに適合するフロールールを、フローエントリテーブル９２８Ａに追加する。このルールは、適合するパケットが双方のＭＰＬＳラベルをポップされてＶＭ Ｔ３ ９９０Ｃへ転送されるべきであることを、仮想スイッチ９２７Ａへ知らせる。本発明の他の実施形態は、追加的なルールをサポートする。例えば、１つの実施形態は、テナントがそのＩＰアドレスを取得するためにＤＨＣＰを使用する場合に、ＶＭ Ｔ３ ９９０Ｃから発せられるＤＨＣＰパケットがＣＮＭ９６０へ転送されるべきであることを示すルールを追加する。他の実施形態は、ＶＭ Ｔ３ ９９０Ｃから発せられるＡＲＰリクエストがＣＮＭ９６０へ転送されるべきであることを示すルールを追加する。

ポイントＧにおいて、ＣＮＭ９６０（又は、古い仮想化されたサーバから新たな仮想化されたサーバへのＶＭの移行の期間中にパケットをバッファリングするように設計された何らかの他のエンティティ）は、ＶＭ Ｔ３ ９９０Ｃ宛ての累積されたパケットを、仮想化されたサーバ９２５Ａへ転送し、それにより、それらパケットはＶＭ Ｔ３ ９９０Ｃへデリバリされ得る。

ポイントＨにおいて、ＣＮＭ９６０は、ＣＮＭ９６０のアドレスマッピングテーブルを修正して、ＶＭ Ｔ３ ９９０Ｃについての仮想化されたサーバのＭＡＣアドレスのエントリを、宛て先である新たな仮想化されたサーバ９２５のＭＡＣアドレスへと変更する。それら変更の後に、図７に従ったＶＭ Ｔ３ ９９０Ｃについてのいかなる新たなＡＲＰリクエストも、ソース仮想スイッチでのフローエントリにて、トラフィックが９２５Ａへとルーティングされるべきであることを示す結果となる。

１つの実施形態において、ＣＮＭ９６０は、ＶＭ Ｔ３ ９９０Ｃとの間でトラフィックを依然として交換しているかもしれない任意のピアＶＭのために、古い仮想化されたサーバ９１５Ａの仮想スイッチ９１７Ａ上の所定の位置にフロールールを保持しており、なぜなら、それらピアＶＭは古い仮想化されたサーバ９１５Ａ上でＶＭ Ｔ３ ９９０Ｃがアクティブであることを依然として期待するかもしれないためである。そうしたピアＶＭがピアデータパケットをＶＭ Ｔ３ ９９０Ｃへ送信することになる場合、当該ピアデータパケットは、ポイントＤにおいてインストールされたルールに従って、ＣＮＭ９６０へ転送されるであろう。ＣＮＭ９６０は、次いで、ピアＶＭの仮想化されたサーバ上におけるフロールールを、パケット上のＭＡＣ及びＩＰアドレスを使用してＶＭ Ｔ３ ９９０Ｃの位置を特定することで新たな仮想化されたサーバ９２５Ａ上のＶＭ Ｔ３ ９９０Ｃへトラフィックを転送するように修正する。ＣＮＭ９６０は、ピアデータパケットを、新たな仮想化されたサーバ９２５Ａ上のＶＭ Ｔ３ ９９０Ｃへ転送する。このようにして、全てのフロールールは、究極的には、タイムアウトになるか、又は、新たな仮想化されたサーバ９２５Ａ上のＶＭ Ｔ３ ９９０Ｃへトラフィックを送信するように修正されるか、のいずれかである。１つの実施形態では、ＴＯＲＳフローテーブルは、古いＴＯＲＳ−ＶＳリンクラベルを除去して新たなＶＳへのＴＯＲＳ−ＶＳリンクラベルをインストールするための変更をも要し得る。ＣＮＭは、ソース仮想スイッチのフロールール及びＴＯＲＳルールが予め定義されたグレースピリオドの後にタイムアウトになることを可能とすることができる。

図１０は、本発明の実施形態に係る例示的なコンピュータシステムのブロック図を示している。図１０の例示的なコンピュータシステム１０００は、図１〜９及び１１〜２２において説明したようなＴＯＲＳ、仮想化されたサーバ、ＣＥＭ又はＣＮＭを実装するために使用されることが可能である。当業者は、これらデバイスを実装するために使用される他のコンピュータシステムが、より多くの又はより少ないコンポーネントを有してよいこと、及び、本発明の実施形態において使用されてよいことを認識するであろう。

コンピュータシステム１０００は、処理システム１０１５、電源１０２０、揮発性メモリ１０２５（例えば、ダブルデータレートランダムアクセスメモリ（ＤＤＲ−ＲＡＭ）、シングルデータレート（ＳＤＲ）ＲＡＭ）、不揮発性メモリ１０３０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）と連結されるバス１０５０を含む。処理システム１０１５は、処理システムキャッシュ１０１０へさらに連結され得る。処理システム１０１５は、揮発性メモリ１０２５及び／又は不揮発性メモリ１０３０から命令を取り出して、当該命令を実行して上記の動作を実行し得る。バス１０５０は、上記のコンポーネントを共に連結し、ディスプレイコントローラ１０７０、１つ以上の入力／出力デバイス１０８０（例えば、ネットワークインタフェースカード、カーソルコントロール（例えば、マウス、トラックボール、タッチスクリーン、タッチパッドなど）、キーボードなど）、及びオプションとして１つ以上の無線送受信機（例えば、ブルートゥース、ＷｉＦｉ、赤外線など）をさらに連結する。１つの実施形態において、ディスプレイコントローラ１０７０は、ディスプレイデバイス１０７５へさらに連結される。

さらなる実施形態において、ＣＮＭは、テナントｉｄと、ＴＯＲＳラベルと、ＶＭ及びサーバのＭＡＣ及びＩＰアドレスとの間のマッピングを維持するために使用する追加的なデータベースを有する。ＣＮＭは、それらデータベースを使用して、テナントＶＭの間で送信されるパケットへ付与されるテナント固有ラベルを生成する。それらデータベースへのアクセスは、ＯｐｅｎＦｌｏｗスイッチ上のインストール又はアンインストールに先立って実行される。

図１１は、ＣＮＭにより維持される追加的なデータベースを示している。ＣＮＭは、テナントＩＤ−テナントラベル（ＴＩＴＬテーブル）を使用し、テナントＩＤをキーとして用いてテナントラベルをルックアップする。ＣＮＭは、ＴＯＲＳラベル−ＶＳリンクラベルテーブル（ＴＬＶＬＬテーブル）を使用し、ＴＯＲＳラベルをキーとして用いてＶＳリンクラベルをルックアップする。ＣＮＭは、ＣＮＭマッピングテーブル（ＣＮＭテーブル）を使用して、テナントｉｄと、テナントＶＭのＭＡＣ及びＩＰアドレスと、サーバＭＡＣアドレスとの間のマッピングを維持する。テナントごとに１つのＣＮＭマッピングテーブルが存在する。

テナントＩＤは、テナント固有データを、同じクラウド基盤を使用する他のテナントとは別に保持することで隔離する。この隔離を達成するために、転送エントリとしてテナントラベルが追加される。テナントＩＤを有するテナントラベルの使用は、テナント固有トラフィックをそれらそれぞれのＶＭへ分離し及び隔離する。それにも関わらず、このさらなる実施形態では、異なるテナントに属するＶＭが同じネットワーク（ＩＰ／ＭＡＣ）アドレスを有することができる。

図１１において見られるように、テナントデータベースは、ＣＮＭアドレスマッピングテーブルへテナントＩＤ情報を追加するために使用される。テナントデータベースは、テナントに固有の詳細を記憶するために使用され、テナントＩＤをキーとして有する。テナントデータベースは、ＣＮＭアドレスマッピングテーブルへのポインタを保持する。本実施形態では、ＣＮＭは、まず、他の全てのＣＮＭアドレスマッピングテーブルのルックアップを実行する前に、テナント固有のアドレスマッピングテーブルを見つけ出すためのルックアップをテナントデータベースに対して実行する。一旦テナント固有のアドレスマッピングテーブルを見つけ出すと、上で説明した追加的なステップ群が遂行される。

図１２は、クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法を示している。ブロック１２０５において、ＣＮＭは、複数のデータベース又はテーブル内の複数のアイテムの間のマッピングを維持する。当該複数のデータベース又はテーブルは、テナントデータベース（ＤＢ）と、テナント識別子−テナントラベル（ＴＩＴＬ）テーブルと、ＴＯＲＳ（top of rack server）ラベル−仮想スイッチリンクラベル（ＴＬＶＬＬ）テーブルと、ラベルマッピングテーブル（ＳＭＶＬ）と、ＣＮＭアドレスマッピングテーブルとを含む。ブロック１２１０において、ＣＮＭは、上記複数のデータベースを用いて、テナントの仮想マシン（ＶＭ）間で送信されるパケットへ付与されるテナント固有ラベルを生成する。１つの実施形態では、ＯｐｅｎＦｌｏｗスイッチ上のインストール又はアンインストールに先立ってデータベースアクセスが実行される。

ＣＮＭは、テナントＩＤをキーとして用いてテナントラベルをルックアップするためにＴＩＴＬテーブルを用いる。ＣＮＭは、ＴＯＲＳ（top of rack server）ラベルをキーとして用いて仮想スイッチ（ＶＳ）リンクラベルをルックアップするためにＴＬＶＬＬテーブルを用いる。

ＣＮＭは、テナントＩＤ、テナントＶＭメディアアクセス制御（ＭＡＣ）アドレス、テナントＶＭインターネットプロトコル（ＩＰ）アドレス及びサーバＭＡＣアドレスの間のマッピングを維持するために、ＣＮＭアドレスマッピングテーブルを用いる。テナントごとに１つのＣＮＭアドレスマッピングテーブルが存在する。

テナントラベルを転送エントリとして追加することにより、テナント固有データが隔離される。テナントＩＤを有するテナントラベルの使用が、テナント固有トラフィックをそれぞれのＶＭへと分離し及び隔離する。１つの実施形態では、異なるテナントへ属する複数のＶＭが同じインターネットプロトコルアドレス及びメディアアクセス制御アドレスを有する

テナントＤＢは、ＣＮＭアドレスマッピングテーブルへのポインタを保持する。ＣＮＭは、他の全てのＣＮＭアドレスマッピングテーブルのルックアップを実行する前に、まずテナントＤＢでのルックアップを実行して、テナント固有のアドレスマッピングテーブルを見出す。

図１３は、テナントごとに仮想マシンをアクティブ化するための方法のブロック図を示している。ブロック１３０５において、ＣＮＭにより、ＶＭが仮想化されたサーバ上でのアクティブ化のためにスケジューリングされるという通知が受信される。例えば、ＣＥＭがアクティブ化のためにＶＭをスケジューリングしたことを、ＣＥＭがＣＮＭへ通知する。ブロック１３１０において、ＣＮＭは、ＶＭ ＭＡＣアドレスを判定する。ブロック１３１５において、ＣＮＭは、ＶＭがアクティブ化されることになる仮想化されたサーバ上に所在する仮想スイッチ（ＶＳ）に対応する、仮想スイッチのＭＡＣアドレスを判定する。ブロック１３２０において、ＣＮＭは、ＣＥＭから、テナントＩＤ、テナントＭＡＣ及びサーバＭＡＣを含むメッセージを受信する。ブロック１３２５において、ＣＮＭは、（ＶＳ ＭＡＣアドレスをＶＳ−ＴＯＲＳラベルへ関連付けるラベルマッピングテーブルである）ＳＭＶＬテーブル及びＴＩＴＬテーブルにおいてルックアップを実行する。ＣＮＭは、ＳＭＶＬテーブル内でＶＳからＴＯＲＳへのリンクラベルを見出す。ＣＮＭは、ＴＩＴＬテーブルにおいてテナントラベルを見出す。ブロック１３３０において、ＣＮＭは、ＣＮＭマッピングテーブル内に、テナントＩＤ、ＶＭ ＭＡＣアドレス及びＶＳ ＭＡＣアドレスの間の関連付けを記録する。

ブロック１３３５において、ＣＮＭは、ＭＰＬＳラベル、ＶＭ ＭＡＣアドレス及びテナント固有ラベルに適合するデータパケットがそのＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを、当該ＶＳへ送信する。言い換えれば、（宛て先スイッチにおいて）第１のＭＰＬＳラベルがＶＳ−ＴＯＲＳリンクラベルに適合し、第２のＭＰＬＳラベルがテナント固有ラベルに適合し、及びＭＡＣがテナントＶＭ ＭＡＣアドレスに適合する場合、それらＭＰＬＳラベルがポップされて、テナントＶＭへの転送が行われる。このルールは、パケットが適切なＭＡＣアドレスを有する場合に、ＶＳ−ＴＯＲＳリンク上へ到来するＶＳへのトラフィックがテナントＶＭへ転送されることを保証する。

１つの実施形態では、ブロック１３４０において、ＣＮＭは、ＶＭから発せられるＤＨＣＰリクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを、ＶＳへ送信する。パケットのソースＭＡＣがテナント固有ＭＡＣに適合し、宛て先ポート番号がＤＨＣＰポート番号に適合する場合、リクエストは、ＣＮＭへ転送される。このルールは、ＣＮＭが応答としてルーティングの修正を行い得るようにアドレスルックアップ及び構成のそれぞれに割り込むことを可能とする。１つの実施形態では、ＤＨＣＰは、ＢＯＯＴＰと同じポート番号を使用し、そのためこれはＢＯＯＴＰプロトコルのポート番号となる。

１つの実施形態では、ブロック１３４５において、ＣＮＭは、ＶＭから発せられるＡＲＰリクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを、ＶＳへ送信する。パケットのソースＭＡＣがテナント固有ＭＡＣに適合し、イーサタイプがＡＲＰに適合する場合、リクエストは、ＣＮＭへ転送される。このルールは、ＣＮＭが応答としてルーティングの修正を行い得るようにアドレスルックアップ及び構成のそれぞれに割り込むことを可能とする。

図１４は、１つの実施形態に従って仮想マシンをアクティブ化するための方法を示している。図１４において、ＴＯＲＳ１４０１Ａは、仮想化されたサーバ１４１５Ａへ連結されている。仮想化されたサーバ１４１５Ａは、ハイパーバイザ１４１６Ａ及び仮想スイッチ１４１７Ａを含む。図１４では、仮想化されたサーバ１４１５Ａは、２つのアクティブなＶＭ Ｔ１ １４９０Ａ及びＶＭ Ｔ２ １４９０Ｂを有する。さらに、図１４は、ＣＥＭ１４５０、仮想ディスク１４５５、及びＣＮＭ１４６０を示す。

図１４において、ＣＥＭ１４５０は、仮想化されたサーバ１４１５Ａ上での実行のために、第３のＶＭ Ｔ３ １４９０Ｃをスケジューリングする。この図は、仮想マシンのアクティブ化の期間中における様々なポイントを描いている。ポイントＡにおいて、ＣＥＭ１４５０は、ＶＭ Ｔ３ １４９０Ｃ、例えば、テナント３に属するＶＭを、実行のためにスケジューリングする。オブジェクトファイルは、仮想ディスク１４５５からＣＥＭのオブジェクトマネージャを通じてマッピングされる。ＣＥＭは、テナント３に割り当てられたＭＡＣアドレスのうちの１つにＶＭ１４９０ＣのＭＡＣアドレスを設定するように、ＶＭ１４９０Ｃのスタックを編集する。ポイントＢにおいて、ＣＥＭ１４５０は、ＣＮＭ１４６０にアクティブ化について知らせる。ＣＥＭ１４５０は、ＶＭ１４９０ＣのＭＡＣアドレスと、ＶＭを実行している、仮想化されたサーバ１４１５ＡのＭＡＣアドレス（これは、仮想化されたサーバ１４１５Ａの仮想スイッチ１４１７ＡのＭＡＣアドレスである）と、テナントの識別子とを、ＣＮＭ１４６０へ提供する。

ポイントＣにおいて、ＶＭ、即ちＶＭ１４９０Ｃが仮想化されたサーバ１４１５Ａ上でアクティブ化のためにスケジューリングされるという通知が、ＣＮＭ１４６０により受信される。例えば、ＣＥＭ１４５０がアクティブ化のためにＶＭ１４９０Ｃをスケジューリングしたことを、ＣＥＭ１４５０がＣＮＭ１４６０へ通知する。ポイントＤにおいて、ＣＮＭ１４６０は、ＶＭ１４９０ＣのＭＡＣアドレスを判定する。ポイントＥにおいて、ＣＮＭは、ＶＭ１４９０Ｃがアクティブ化されることになる仮想化されたサーバ１４１５Ａ上に所在する仮想スイッチ（ＶＳ）１４１７Ａに対応する、仮想スイッチのＭＡＣアドレスを判定する。ポイントＦにおいて、ＣＮＭ１４６０は、ＣＥＭ１４５０から、テナントＩＤ、テナントＭＡＣ及びサーバＭＡＣを含むメッセージを受信する。ポイントＧにおいて、ＣＮＭは、ＳＭＶＬテーブル１４６４及びＴＩＴＬテーブル１４２４においてルックアップを実行する。ＣＮＭは、ＳＭＶＬテーブル１４６４内でＶＳからＴＯＲＳへのリンクラベルを見出す。ＣＮＭは、ＴＩＴＬテーブル１４２４においてテナントラベルを見出す。ポイントＨにおいて、ＣＮＭ１４６０は、ＣＮＭマッピングテーブル１４３４内に、テナントＩＤ、ＶＭ ＭＡＣアドレス及びＶＳ ＭＡＣアドレスの間の関連付けを記録する。

ポイントＩにおいて、ＣＮＭは、ＭＰＬＳラベル、ＶＭ ＭＡＣアドレス及びテナント固有ラベルに適合するデータパケットがそのＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを、ＶＳ１４１７Ａへ送信する。言い換えれば、第１のＭＰＬＳラベルがＶＳ−ＴＯＲＳリンクラベルに適合し、第２のＭＰＬＳラベルがテナント固有ラベルに適合し、及びＭＡＣがテナントＶＭ ＭＡＣアドレスに適合する場合、それらＭＰＬＳラベルがポップされて、テナントＶＭへの転送が行われる。このルールは、パケットが適切なＭＡＣアドレスを有する場合に、ＶＳ−ＴＯＲＳリンク上へ到来するＶＳへのトラフィックがテナントＶＭへ転送されることを保証する。

１つの実施形態において、ＣＮＭ１４６０は、ポイントＪにおいて、ＶＭ１４９０Ｃから発せられるＤＨＣＰリクエストがＣＮＭ１４６０へ転送されるべきであることを示す第２のフローエントリ修正メッセージを、ＶＳ１４１７Ａへ送信する。パケットのソースＭＡＣがＶＭ１４９０Ｃについてのテナント固有ＭＡＣに適合し、宛て先ポート番号がＤＨＣＰポート番号に適合する場合、リクエストは、ＣＮＭ１４６０へ転送される。このルールは、ＣＮＭが応答としてルーティングの修正を行い得るようにアドレスルックアップ及び構成のそれぞれに割り込むことを可能とする。１つの実施形態では、ＤＨＣＰは、ＢＯＯＴＰと同じポート番号を使用し、そのためこれはＢＯＯＴＰプロトコルのポート番号となる。

１つの実施形態では、ＣＮＭは、ポイントＫにおいて、ＶＭ１４９０Ｃから発せられるＡＲＰリクエストがＣＮＭ１４６０へ転送されるべきであることを示す第３のフローエントリ修正メッセージを、ＶＳ１４１７Ａへ送信する。パケットのソースＭＡＣがＶＭ１４９０Ｃについてのテナント固有ＭＡＣに適合し、イーサタイプがＡＲＰに適合する場合、リクエストは、ＣＮＭ１４６０へ転送される。このルールは、ＣＮＭが応答としてルーティングの修正を行い得るようにアドレスルックアップ及び構成のそれぞれに割り込むことを可能とする。

図１４は、これまでに説明した全ての３つのフローエントリ修正メッセージが通信されたということを前提として、仮想スイッチ１４１７Ａのフローエントリテーブル１４１８Ａ内の３つのエントリを例示する。フローエントリテーブル１４１８Ａには、６つの列、即ち、ソースＭＡＣ、宛て先ＭＡＣ、ＭＰＬＳラベル、テナント固有ラベル、ＩＰプロトコル、及びアクション、が例示されている。それらフローエントリは、１４９０Ｃのアクティブ化に対応する。

図示したフローエントリテーブル１４１８Ａ内の第１のエントリは、ソースＭＡＣアドレスとしてＶＭ Ｔ３ １４９０ＣのＭＡＣアドレスに適合する。宛て先ＭＡＣアドレス及びＭＰＬＳラベルは、いかなるエントリにも適合するように設定され、その一方で、テナント固有ラベルはラベル_ｔｉｄ３に適合するに設定され、ＩＰプロトコルはＡＲＰプロトコルに適合するように設定される。アクションは、次いでＣＮＭ１４６０へ転送することである。このルールは、上記のステップＫに対応する。

図示したフローエントリテーブル１４１８Ａ内の第２のエントリは、ソースＭＡＣアドレスとしてＶＭ Ｔ３ １４９０ＣのＭＡＣアドレスに適合する。宛て先ＭＡＣアドレス及びＭＰＬＳラベルはいかなるエントリにも適合するように設定され、その一方で、テナント固有ラベルはラベル_ｔｉｄ３に適合するに設定され、ＩＰプロトコルはＤＨＣＰプロトコルに適合するように設定される。アクションは、次いでＣＮＭ１４６０へ転送することである。このルールは、上記のステップＪに対応する。

図示したフローエントリテーブル１４１８Ａ内の第３のエントリは、宛て先ＭＡＣアドレスとして全てのＭＡＣに適合する。宛て先ＭＡＣアドレスは、ＶＭ Ｔ３ １４９０ＣのＭＡＣアドレスに適合するように設定され、その一方で、１つのＭＰＬＳラベルはＶＳ−ＴＯＲＳ１４０１のリンクラベルに設定され、１つはテナントラベルＭＡＣ ＶＭ Ｔ３に設定され、第３のラベルであるテナント固有ラベルはラベル_ｔｉｄ３に設定される。ＩＰプロトコルは、全てのエントリに適合するように設定される。アクションは、次いでＭＰＬＳラベル及びテナント固有ラベルをポップしてパケットをＶＭ Ｔ３ １４９０Ｃへ転送することである。このルールは、上記のステップＩに対応する。

上で説明したように、ＣＮＭは、テナントＩＤ、ＶＭ ＭＡＣアドレス、仮想化されたサーバのＭＡＣ、及びＶＭ ＩＰアドレスの間のマッピングを維持する。テナントがＤＨＣＰアドレスを使用しないことを選んだ場合、ＣＥＭは、スケジューリングの実行に先立ってＶＭのＩＰスタックを修正し、静的なＩＰアドレスをインストールする。しかしながら、他の実施形態において、テナントは、ＤＨＣＰアドレスを使用することを選ぶであろう。そうしたケースにおいて、ＣＮＭは、ＤＨＣＰリクエストを傍受してリレーとして動作するであろう。

図１５は、１つの実施形態に従ってテナントＶＭからのＤＨＣＰリクエストを傍受するための方法のブロック図を示している。ＤＨＣＰメッセージは、テナントＶＭにより送信される。このＤＨＣＰメッセージは、仮想スイッチにより傍受され、仮想スイッチからＣＮＭへと転送される。ブロック１５０５において、ＣＮＭは、テナントＶＭから発せられたＤＨＣＰリクエストを仮想スイッチから受信する。ＣＮＭは、ブロック１５１０において、ＤＨＣＰサーバ又はＤＨＣＰリレーとして動作することによりＶＭのアドレスを見出す。ＣＮＭは、ブロックにおいて、ＲＦＣ３０４６に従ってＤＨＣＰサーバへＤＨＣＰリクエストを中継する。ＣＮＭは、ＤＨＣＰサーバからＤＨＣＰリプライを受信する。ブロック１５１５において、ＣＮＭは、ＣＮＭマッピングテーブル内に、ＶＭのアドレスを記録する。また、ＣＮＭは、テナントＶＭのＭＡＣアドレスと、ＤＨＣＰリプライ内で受信されたＩＰアドレスとの間の関連付けを記録する。ある実施形態によれば、当該関連付けは、テナントＶＭを実行する仮想サーバのＭＡＣアドレスをさらに含む。ブロック１５２０において、ＣＮＭは、ＤＨＣＰリプライをＶＭへ転送する。

図１６は、本発明の１つの実施形態に従って仮想マシンからのＤＨＣＰリクエストを傍受するための方法を示している。図６において、仮想化されたサーバ１６１５Ａは、ハイパーバイザ１６１６Ａ及び仮想スイッチ１６１７Ａを含む。図１６において、仮想化されたサーバ１６１５Ａは、３つのアクティブなＶＭ Ｔｌ １６９０Ａ、ＶＭ Ｔ２ １６９０Ｂ、及びＶＭ Ｔ３ １６９０Ｃを有する。仮想スイッチ１６１７Ａは、ＶＭ Ｔ３ １６９０ＣからのＤＨＣＰリクエストを、ＤＨＣＰサーバ１６３０に連結されるＣＮＭ６６０へ転送するためのルールを含むフローエントリテーブル１６１８Ａを含む。

この図は、仮想マシンからのＤＨＣＰリクエストの傍受の期間中における、様々なポイントを描いている。ポイントＡにおいて、ＶＭ Ｔ３ １６９０Ｃは、ＩＰアドレス、及び、ＤＮＳサーバといった他の構成情報を取得するためのＤＨＣＰリクエストを発行する。ポイントＢにおいて、仮想スイッチ１６１７Ａは、例えばメッセージのようなＤＨＣＰリクエストを、当該リクエストをＣＮＭ１６６０へルーティングするためのフロールールに照合する。

ポイントＣにおいて、ＣＮＭは、ＤＨＣＰサーバ又はＤＨＣＰリレーとして動作することにより、ＶＭのアドレスを見出す。１つの実施形態において、ＣＮＭ１６６０は、ＤＨＣＰリレーとして動作し、標準的なＤＨＣＰリレーオプションを挿入し、リクエストをテナントのＤＨＣＰサーバ１６３０へ転送する。ＣＮＭ１６６０は、ＤＨＣＰリクエストのソースＭＡＣアドレスを調査することにより、どのテナントにＶＭ Ｔ３ １６９０Ｃが属しているのかを判定することができる。

ポイントＤにおいて、テナントのＤＨＣＰサーバ１６３０は、ＶＭ Ｔ３ １６９０ＣについてのＩＰアドレス及び他の構成情報を包含するＤＨＣＰリプライで応答する。ポイントＥにおいて、ＣＮＭ１６６０は、ＣＮＭのアドレスマッピングテーブル１６３４内に、ＶＭ Ｔ３ １６９０ＣのＭＡＣアドレスとＩＰアドレスとの間のマッピングを記録する。

ＣＮＭは、上記アドレスを包含するＤＨＣＰリプライでＶＭへ返答する。１つの実施形態では、ポイントＦにおいて、ＣＮＭ１６６０は、ＤＨＣＰリレーオプションを取り除き、ＤＨＣＰリプライを仮想スイッチ１６１７Ａへ転送し、仮想スイッチ１６１７Ａは、ポイントＧにおいて、当該リクエストをＶＭ Ｔ３ １６９０Ｃへ返送する。

図１７は、本発明の１つの実施形態に従って、（特定のラベルにより識別される）特定のテナントが宛て先ＩＰアドレスを発見しようと試みる際にＶＭからのＡＲＰリクエストを傍受するための方法のブロック図を示している。ブロック７０５において、ＣＮＭは、ＶＭから発せられたＡＲＰリクエストを受信する。テナントは、宛て先ＩＰアドレスと共にＡＲＰリクエストを送出する。仮想スイッチは、ＡＲＰリクエストを傍受し、コントローラ上で稼働しているＣＮＭへ当該ＡＲＰリクエストを送信する。ＣＮＭは、ブロック７１０において、特定のテナントについてのＣＮＭマッピングテーブルをルックアップし、宛て先ＶＭが稼動しているサーバの宛て先ＭＡＣアドレスを抽出する。ブロック７１５において、ＣＮＭは、宛て先サーバＭＡＣアドレスを用いて、宛て先ＶＳリンクラベルを判定する。ＣＮＭは、ＶＳリンクラベルを判定する目的で、ＳＭＶＬテーブルを使用する。ブロック１７２０において、ＣＮＭは、アップリンク及びダウンリンクトラフィックのためのフロールートでソースＴＯＲＳをプログラミングする。ブロック１７２５において、ＣＮＭは、ソースＶＭを実行している仮想サーバ上の仮想スイッチへフローエントリ修正メッセージを送信する。当該フローエントリ修正メッセージは、宛て先ＭＡＣアドレスに適合するパケットが宛て先テナント固有ラベル及び宛て先ＶＳ−ＴＯＲＳラベルをプッシュしてソースＴＯＲＳへパケットを転送すべきであることを示すために、ＶＳへ送信される。ブロック１７３０において、ＣＮＭは、特定のテナントのＶＭへ、所与の宛て先ＩＰアドレスについての正確なＭＡＣアドレスと共にＡＲＰリプライを転送する。

図１８は、１つの実施形態に従って、（特定のラベルにより識別される）特定のテナントが宛て先ＩＰアドレスを発見しようと試みる際に仮想マシンからのＡＲＰリクエストを傍受するための方法を示している。図１８において、仮想化されたサーバ１８１５Ａは、ハイパーバイザ１８１６Ａ及び仮想スイッチ１８１７Ａを含む。図８において、仮想化されたサーバ１８１５Ａは、アクティブなＶＭ Ｔ３ １８９０Ｃを有する。仮想スイッチ１８１７Ａは、ＶＭ Ｔ３ １８９０ＣからのＡＲＰリクエストをＣＮＭ１８６０へ転送するためのルールを含むフローエントリテーブル１８１８Ａを含む。仮想化されたサーバ１８１６Ａは、ＴＯＲＳ１８０１Ａと連結され、ＴＯＲＳ１８０１Ａは、クラウドネットワーク１８７０を通じて他のＴＯＲＳ１８０１Ｃへ連結される。ＴＯＲＳ１８０１Ｃは、ハイパーバイザ１８２６Ｂ及び仮想スイッチ１８２７Ｂを含む、仮想化されたサーバ１８２５Ｂと連結される。仮想化されたサーバ１８２５Ｂは、ＶＭ Ｔ４ １８９５Ｂを実行している。

この図は、ＶＭ Ｔ３ １８９０ＣからのＡＲＰリクエストの傍受の期間中における、様々なポイントを描いている。ポイントＡにおいて、ＶＭ Ｔ３ １８９０Ｃは、ＡＲＰリクエストをブロードキャストする。傍受の残りの部分は、ＡＲＰリクエストが、仮想サーバ１８２５Ｂ上に所在する宛て先ＶＭ Ｔ４ １８９５ＢのＩＰアドレスを示すことを前提とする。仮想スイッチ１８１７Ａは、ポイントＢにおいて、ＡＲＰリクエストを傍受し、当該リクエストを、フローエントリテーブル１８１８Ａ内の、ＡＲＰリクエストをＣＮＭ１８６０へルーティングするルールと照合する。

ポイントＣにおいて、ＣＮＭ１８６０は、要求された宛て先ＩＰアドレス（“ＤＩＰ”）をキーとして使用して、ＣＮＭのアドレスマッピングテーブル１８３４内で宛て先ＭＡＣアドレス（“ＤＭＡＣ”）をルックアップする。ポイントＤにおいて、ＣＮＭは、ＤＭＡＣを所与として、宛て先ＶＳリンクラベルを判定する。ＣＮＭは、ＶＳリンクラベルを判定する目的で、ＳＭＶＬテーブルを使用する。ポイントＥにおいて、ＣＮＭ１８６０は、アップリンク及びダウンリンクトラフィックのためのフロールートでソースＴＯＲＳ１８０１Ａをプログラミングする。ＶＳリンクラベルは、ＤＭＡＣ仮想化サーバ１８２５Ｂにおいて、ＴＯＲＳ１８０１ＡとＶＭ Ｔ４ １８９５Ｂとの間のルートを記述する。

ポイントＦにおいて、ＣＮＭ１８６０は、ソースＶＭ１８９０Ｃを実行中の仮想サーバ上の仮想スイッチ１８１７Ａへフローエントリ修正メッセージを送信する。当該フローエントリ修正メッセージは、宛て先ＭＡＣアドレスに適合するパケットが宛て先テナント固有ラベル及び宛て先ＶＳ−ＴＯＲＳラベルをプッシュしてパケットをソースＴＯＲＳ１８０１Ａへ転送すべきであることを示すために、ＶＳ１８１７Ａへ送信される。ポイントＧにおいて、ＣＮＭは、仮想スイッチ１８１７ＡへＡＲＰリプライを転送し、仮想スイッチ１８１７Ａは、次いで、ポイントＨにおいて、所与の宛て先ＩＰアドレスについての正確なＭＡＣアドレスと共に、ＡＲＰリプライを特定のテナントのＶＭ１８９０Ｃへ転送する。

図１９は、１つの実施形態に従って、固有のテナントのＶＭへ向けてトラフィックを転送するためのテナントラベルの使用を示している。固有のテナントのＶＭは、ＴＯＲＳにより分けられる異なる仮想スイッチに関連付けられる。トラフィックが正確に転送されるように、仮想スイッチ及びＴＯＲＳ上でＯｐｅｎＦｌｏｗルールがプログラミングされなければならない。図１９は、テナントＶＭ１から同じテナントのＶＭ２へのトラフィックの転送のための方法を例示している。

サーバＡ上の仮想スイッチ（ＶＳ）Ａは、複数の転送命令を含むフローエントリテーブル１９１８Ａを有する。ＶＳ Ａは、ポート１上でサーバＡに適合するサーバラベルを有するパケットを受信すると、サーバＡラベルをポップし、パケットを、例えばテナント固有ラベルへの照合のために、次のテーブルへ転送する。ＶＳ Ａは、受信したパケット上のＶＭ１及びＭＡＣアドレス（Ｍａｃ１）に適合する場合、テナント固有ラベルをポップし、ポート２上でＶＭ１へ転送する。ＶＳ Ａは、ポート２上でＭａｃ１及びＡＲＰ又はＤＨＣＰに適合するパケットを受信すると、当該パケットをＯＦコントローラ１９６０へ転送する。ＶＳ Ａは、ポート２及び宛て先Ｍａｃアドレスについて適合するパケットを受信すると、まずＶＳ２についてのテナント固有ラベルをプッシュし、次いでサーバＢ用のラベルをプッシュし、そして当該パケットをソースＴＯＲＳへ転送する。

ＴＯＲＳ Ａは、複数の転送命令を含むフローエントリテーブル１９１２Ａを有する。ＴＯＲＳ Ａは、サーバＢについて適合するパケットを受信すると、ＭＰＬＳクラウド１９７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、ＴＯＲＳ Ｂ用のラベルをプッシュし、当該パケットをポート１上で転送する。ＴＯＲＳ Ａは、ポート１について適合し及びＴＯＲＳ Ａに適合するパケットを受信すると、ＴＯＲＳ Ａラベルをポップし、次のテーブルへ転送する。当該パケットがサーバＡについて適合する場合、ＴＯＲＳ Ａは、当該パケットをポート２へ転送する。

サーバＢ上の仮想スイッチ（ＶＳ）Ｂは、複数の転送命令を含むフローエントリテーブル１９１８Ｂを有する。ＶＳ Ｂは、ポート１上でサーバＢに適合するサーバラベルを有するパケットを受信すると、サーバＢラベルをポップし、パケットを、例えばテナント固有ラベルへの照合のために、次のテーブルへ転送する。ＶＳ Ｂは、受信したパケット上のＶＭ２及びＭＡＣアドレス（Ｍａ２）に適合する場合、テナント固有ラベルをポップし、ポート２上でＶＭ２へ転送する。ＶＳ Ｂは、ポート２上でＭａｃ１及びＡＲＰ又はＤＨＣＰに適合するパケットを受信すると、当該パケットをＯＦコントローラ１９６０へ転送する。

ＴＯＲＳ Ｂは、複数の転送命令を含むフローエントリテーブル１９１２Ｂを有する。ＴＯＲＳ Ｂは、サーバＡについて適合するパケットを受信すると、ＭＰＬＳクラウド１９７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、ＴＯＲＳ Ａ用のラベルをプッシュし、当該パケットをポート１上で転送する。ＴＯＲＳ Ｂは、ポート１について適合し及びＴＯＲＳ Ｂに適合するラベルを有するパケットを受信すると、ＴＯＲＳ Ｂラベルをポップし、次のテーブルへ転送する。当該パケットがサーバＢについて適合する場合、ＴＯＲＳ Ｂは、当該パケットをポート２へ転送する。

図１９は、テナントＶＭ１を有する仮想化されたサーバ、サーバＡを示している。サーバＡは、ＴＯＲＳ Ａに関連付けられる。仮想化されたサーバ、サーバＢは、同じテナントの仮想マシンＶＭ２を有する。サーバＢは、ＴＯＲＳ Ｂに関連付けられる。前に議論したように、ＶＭ１は、宛て先ＩＰアドレスを発見し及び同じテナントの宛て先仮想マシンＶＭ２へパケットを転送する目的で、ＡＲＰ、及び例えばＣＮＭといったＯｐｅｎＦｌｏｗコントローラ１９６０を使用することができる。パケットは、ＭＰＬＳクラウドネットワーク１９７０上でソースＴＯＲＳから宛て先ＴＯＲＳへ転送される。

テナントＶＭ１は、パケットをサーバＡへ転送する。ソース仮想スイッチＡは、フローエントリテーブル１９１８Ａを用いて、ポート及び及び宛て先ＭＡＣについて照合を行う。ソース仮想スイッチＡは、２つのラベル、即ちサーバＢラベル及びテナント固有ラベルをプッシュする。１つの実施形態において、テナント固有ラベルがまずプッシュされる。ソース仮想スイッチＡは、ついで、パケットをソースＴＯＲＳ Ａへ転送する。ソースＴＯＲＳ Ａは、パケットを転送する目的で、フローエントリテーブル１９１２Ａに関連付けられるルールを使用する。ソースＴＯＲＳ Ａは、サーバＢラベル（例えば、サーバＢのＭＡＣアドレスに関連付けられるＶＳ−ＴＯＲＳラベル）について照合を行い、ＴＯＲＳ−ＴＯＲＳ転送のためにＴＯＲＳ Ｂラベルをプッシュする。ＴＯＲＳ Ａは、（ＴＯＲＳ Ｂラベル、サーバＢラベル及びテナント固有ラベルと共に）パケットをＭＰＬＳクラウド１９７０上でＴＯＲＳ Ｂへ転送する。

宛て先ＴＯＲＳ Ｂは、ＴＯＲＳ Ｂラベル及びポートについて照合を行う。次いで、宛て先ＴＯＲＳ Ｂは、ＴＯＲＳ Ｂラベルをポップし、フローエントリテーブル１９１２Ｂ内のルールに従って、サーバＢ上に所在する宛て先仮想スイッチＢへ送信する。

宛て先仮想スイッチＢは、サーバＢラベル及びポートについて照合を行い、サーバＢラベルをポップする。宛て先仮想スイッチＢは、テナント固有ラベルについて照合を行い、パケットを正確な宛て先ＭＡＣアドレスへ転送する。

図２０は、クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法を示している。ブロック２００５において、ソース仮想スイッチ（ＶＳ）へ、宛て先仮想マシン（ＶＭ）へデータパケットを転送する目的でソースＶＳが当該データパケットへまずテナント固有ラベルをプッシュし次いでＶＳ−ＴＯＲＳ（top of rack switch）ラベルをプッシュすべきであることを示す第１のフローエントリ修正メッセージが送信される。ブロック２０１０において、ソースＴＯＲＳへ、ソースＴＯＲＳがＶＳ−ＴＯＲＳラベルに適合するデータパケットを受信した場合にはソースＴＯＲＳが宛て先ＴＯＲＳラベルをプッシュすべきであることを示す第２のフローエントリ修正メッセージが送信される。ブロック２０１５において、宛て先ＴＯＲＳへ、宛て先ＴＯＲＳが宛て先ＴＯＲＳラベルに適合するデータパケットを受信した場合には宛て先ＴＯＲＳがＴＯＲＳラベルをポップしてデータパケットを宛て先ＶＳへと転送すべきであることを示す第３のフローエントリ修正メッセージが送信される。ブロック２０２０において、宛て先ＶＳへ、宛て先ＶＳがＶＳ−ＴＯＲＳラベル及びテナント固有ラベルに適合するデータパケットを受信した場合には宛て先ＶＳがまずＶＳ−ＴＯＲＳラベルをポップし次いでテナント固有ラベルをポップすべきであることを示す第４のフローエントリ修正メッセージが送信される。

第１のフローエントリ修正メッセージに応じて、ソースＶＳは、パケットをソースＴＯＲＳへ転送する。第２のフローエントリ修正メッセージに応じて、ソースＴＯＲＳは、クラウドネットワークを用いてデータパケットを宛て先ＴＯＲＳへ転送する。第３のフローエントリ修正メッセージに応じて、宛て先ＴＯＲＳは、データパケットを宛て先ＶＳへ転送する。第４のフローエントリ修正メッセージに応じて、宛て先ＶＳは、パケットを宛て先ＶＭへ転送する。ＣＮＭは、ソースＶＭがパケットを同じテナントに属する宛て先ＶＭへ転送することを可能とする目的で、宛て先インターネットプロトコルアドレスをソースＶＭへ提供する。

図２１は、１つの実施形態に従って、ＶＭが新たなサーバへ移動した後にテナントラベルを用いてトラフィックを正確なＶＭへ転送するための方法を示している。固有のテナントのＶＭは、ＴＯＲＳにより分けられる異なる仮想スイッチに関連付けられる。トラフィックが正確に転送されるために、仮想スイッチ及びＴＯＲＳ上でＯｐｅｎＦｌｏｗルールがプログラミングされなければならない。図２１は、移動したＶＭへトラフィックを転送するための方法を示している。

サーバＡ上の仮想スイッチ（ＶＳ）Ａは、複数の転送命令を含むフローエントリテーブル２１１８Ａを有する。ＶＳ Ａは、ポート１上でサーバＡに適合するサーバラベルを有するパケットを受信すると、サーバＡラベルをポップし、パケットを、例えばテナント固有ラベルへの照合のために、次のテーブルへ転送する。ＶＳ Ａは、受信したパケット上のＶＭ１及びＭＡＣアドレス（Ｍａｃ１）に適合する場合、テナント固有ラベルをポップし、ポート２上でＶＭ１へ転送する。ＶＳ Ａは、ポート２上でＭａｃ１及びＡＲＰ又はＤＨＣＰに適合するパケットを受信すると、当該パケットをＯＦコントローラ１９６０（図示せず）へ転送する。ＶＳ Ａは、ポート２及び宛て先Ｍａｃアドレスについて適合するパケットを受信すると、まずＶＭ２についてのテナント固有ラベルをプッシュし、次いでサーバＣラベルをプッシュし、そして当該パケットをソースＴＯＲＳ、ＴＯＲＳ Ａへ転送する。

ＴＯＲＳ Ａは、複数の転送命令を含むフローエントリテーブル２１１２Ａを有する。ＴＯＲＳ Ａは、サーバＢについて適合するパケットを受信すると、ＭＰＬＳクラウド２１７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、ＴＯＲＳ Ｂ用のラベルをプッシュし、当該パケットをポート１上で転送する。ＴＯＲＳ Ａは、サーバＣについて適合するパケットを受信すると、ＴＯＲＳ Ｃ用のラベルをプッシュし、当該パケットをポート１上で転送する。ＴＯＲＳ Ａは、ポート１について適合し及びＴＯＲＳ Ａに適合するラベルを有するパケットを受信すると、ＴＯＲＳ Ａラベルをポップし、次のテーブルへ転送する。当該パケットがサーバＡについて適合する場合、ＴＯＲＳ Ａは、当該パケットをポート２へ転送する。

サーバＢ上の仮想スイッチ（ＶＳ）Ｂは、複数の転送命令を含むフローエントリテーブル２１１８Ｂを有する。ＶＳ Ｂは、ポート１上でサーバＢに適合するサーバラベルを有するパケットを受信すると、サーバＢラベルをポップし、パケットを、例えばテナント固有ラベルへの照合のために、次のテーブルへ転送する。ＶＳ Ｂは、受信したパケット上のＶＭ２及びＭＡＣアドレス（Ｍａ２）に適合する場合、テナント固有ラベルをポップし、新たな命令に従って転送を行う。それら新たな命令は、まずＶＭ２（テナント固有）ラベルをプッシュすることと、次いでサーバＣラベルをプッシュすることと、パケットをポート１へと転送することと、を含む。ＶＳ Ｂは、ポート２上でＭａｃ１及びＡＲＰ又はＤＨＣＰに適合するパケットを受信すると、当該パケットをＯＦコントローラ（図示せず）へ転送する。

ＴＯＲＳ Ｂは、複数の転送命令を含むフローエントリテーブル２１１２Ｂを有する。ＴＯＲＳ Ｂは、サーバＡについて適合するパケットを受信すると、ＭＰＬＳクラウド２１７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、ＴＯＲＳ Ａ用のラベルをプッシュし、当該パケットをポート１上で転送する。ＴＯＲＳ Ｂは、サーバＣについて適合するパケットを受信すると、ＴＯＲＳ Ｃ用のラベルをプッシュし、ＭＰＬＳクラウド２１７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、当該パケットをポート１上で転送する。ＴＯＲＳ Ｂは、ポート１について適合し及びＴＯＲＳ Ｂに適合するラベルを有するパケットを受信すると、ＴＯＲＳ Ｂラベルをポップし、次のテーブルへ転送する。当該パケットがサーバＢについて適合する場合、ＴＯＲＳ Ｂは、当該パケットをポート２へ転送する。

サーバＣ上の仮想スイッチ（ＶＳ）Ｃは、複数の転送命令を含むフローエントリテーブル２１１８Ｃを有する。ＶＳ Ｃは、ポート１上でサーバＡに適合するサーバラベルを有するパケットを受信すると、サーバＡラベルをポップし、例えばテナント固有ラベルへの照合のために、次のテーブルへ転送する。ＶＳ Ｃは、受信したパケット上のＶＭ２及びＭＡＣアドレス、Ｍａｃ２に適合する場合、テナント固有ラベルをポップし、ポート２への転送を行う。ＶＳ Ｃは、ポート２、Ｍａｃ１及びＡＲＰ又はＤＨＣＰについて適合するパケットを受信すると、当該パケットをＯＦコントローラ（図示せず）へ転送する。

ＴＯＲＳ Ｃは、複数の転送命令を含むフローエントリテーブル２１１２Ｃを有する。ＴＯＲＳ Ｃは、サーバＡについて適合するパケットを受信すると、ＭＰＬＳクラウド２１７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、ＴＯＲＳ Ａ用のラベルをプッシュし、当該パケットをポート１上で転送する。ＴＯＲＳ Ｃは、サーバＢについて適合するパケットを受信すると、ＴＯＲＳ Ｂ用のラベルをプッシュし、ＭＰＬＳクラウド２１７０上でのＴＯＲＳ−ＴＯＲＳ転送のために、当該パケットをポート１上で転送する。ＴＯＲＳ Ｃは、ポート１について適合し及びＴＯＲＳ Ａに適合するラベルを有するパケットを受信すると、ＴＯＲＳ Ａラベルをポップし、次のテーブルへ転送する。当該パケットがサーバＡについて適合する場合、ＴＯＲＳ Ｃは、当該パケットをポート２へ転送する。

図２１は、テナントＶＭ１を有する、仮想化されたサーバであるサーバＡを示している。サーバＡは、ＴＯＲＳ Ａに関連付けられる。仮想化されたサーバであるサーバＢは、同じテナントの仮想マシンＶＭ２を有する。サーバＢは、ＴＯＲＳ Ｂに関連付けられる。ＶＭ２がサーバＢからサーバＣへ移動する場合、ＶＭ２宛てのパケットがＭＰＬＳクラウドネットワーク１９７０上でＴＯＲＳ Ｃを通じてサーバＣへ転送されることを確実化する目的で、ＶＳ Ｂ用のフローエントリテーブル内に転送命令が含められる。

図２１は、ＶＭが移動する際のデータパスを示している。本実施形態において、テナントラベルは、ＶＭが移動した後に正確なＶＭへトラフィックを転送するために使用される。図１３において見られるように、当初は、トラフィックは、仮想スイッチＡに関連付けられるＶＭ１から仮想スイッチＢ上のＶＭ２へと進む。最終的には、ＶＭは、仮想スイッチＣへと移動し、トラフィックは正確な仮想スイッチへ適切に移動させられる。

上で述べたように、当初は、フローは、ＶＳ Ａ上のソーステナント仮想マシンＶＭ１からＶＳ Ｂ上の宛て先仮想マシンＶＭ２へとトラフィックを送信するようにセットアップされる。

ＶＭ２がサーバＢからサーバＣへと移動される場合、ＶＭ２宛てのパケットが正確な場所へ送信されることを確かにする目的で、フローエントリテーブルは修正される必要がある。ＶＳ Ａ上のフローエントリテーブル２１１８Ａは、ＶＳ Ｂの代わりにＶＳ Ｃのためのラベルをプッシュするように修正される。サーバＡラベルについて照合し、次いでテナント固有ラベルＶＭ２について照合するためのエントリがフローエントリテーブル２１１８Ｃへ追加される。次いで、ＶＳ Ｃは、それらラベルをポップし、ＶＳ Ｃ上の正確なポートへの転送を行う。ＶＭ２へ向けてＶＳ Ａから到来するトラフィックについて照合されるＶＳ Ｂ上のエントリは除去される。ＶＭ２の移動の期間中にＶＳ Ｂにより受信されるいずれの暫定的なパケットも、まずテナント固有ラベルをプッシュし、次いでサーバＢ用のラベルをプッシュし、そしてＭＰＬＳクラウド２１７０上でのＴＯＲＳ ＣへのＴＯＲＳ−ＴＯＲＳ転送のためにＴＯＲＳ Ｂへ転送することにより、転送されることができる。

図２２は、第１の宛て先ＶＳから第２の宛て先ＶＳへ、ＣＮＭを用いて宛て先ＶＭを移動させる方法を示している。ブロック２２０５において、ソースＶＳへ、第１の宛て先ＶＳの代わりに第２の宛て先ＶＳのためのラベルをプッシュする目的で第１のフローエントリ修正メッセージが送信される。ブロック２２１０において、第２の宛て先ＶＳへ、ソースＶＳラベル及びテナント固有ラベルが適合するデータパケットを第２の宛て先ＶＳが受信した場合には当該第２の宛て先ＶＳがまずソースＶＳラベルをポップし次いでテナント固有ラベルをポップすべきであることを示す第２のフローエントリ修正メッセージが送信される。ブロック２２１５において、第１の宛て先ＶＳへ、第１の宛て先ＶＳラベル及びテナント固有ラベルについて適合するデータパケットを第１の宛て先ＶＳが暫定ピリオドの期間中に受信した場合には第１の宛て先ＶＳ及びテナント固有ラベルがポップされるべきであって次いで第１の宛て先ＶＳがパケットをまずテナント固有ラベルをプッシュし次いで第２の宛て先ＶＳラベルをプッシュすることにより転送すべきであることを示す第３のフローエントリ修正メッセージが送信される。

ここで説明されるように、命令は、ある動作を実行するように構成され若しくは予め決定される機能性を有する特定用途向け集積回路（ＡＳＩＣ）といったハードウェアの特定の構成、又は、メモリ内に記憶され非一時的なコンピュータ読取可能な媒体内で具現化されるソフトウェア命令の特定の構成を指し得る。よって、図面中に示した技法は、１つ以上の電子デバイス（例えば、終端局、ネットワークエレメント）上で記憶されて実行されるコード及びデータを使用して実装されることが可能である。そうした電子デバイスは、非一時的なコンピュータ読取可能な記憶媒体（例えば、磁気ディスク、光ディスク、ランダムアクセスメモリ、読み出し専用メモリ、フラッシュメモリデバイス、相変化メモリ）及び一時的なコンピュータ読取可能な通信媒体（例えば、電気的、光学的、音響的、又は他の形式の伝播信号−例えば、搬送波、赤外線信号、デジタル信号）などのコンピュータ読取可能な媒体を使用して、コード及びデータを記憶し、コード及びデータを（内部的に、及び／又は、他の電子デバイスとの間でネットワーク上で）通信する。加えて、そうした電子デバイスは、典型的には、１つ以上のストレージデバイス（非一時的なマシン読取可能な記憶媒体）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、並びにネットワーク接続といった１つ以上の他のコンポーネントへ連結される１つ以上のプロセッサのセットを含む。プロセッサのセットと他のコンポーネントとの連結は、典型的には、１つ以上のバス及びブリッジ（バスコントローラとも呼称される）を通じて行われる。よって、所与の電子デバイスのストレージデバイスは、典型的には、当該電子デバイスの１つ以上のプロセッサのセット上での実行のためにコード及び／又はデータを記憶する。当然ながら、本発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの様々な組み合わせを使用して実装されてよい。

図面中のフロー図は、本発明のある実施形態により実行される動作の特定の順序を示しているが、そうした順序は例示的であることが理解されるべきである（例えば、代替的な実施形態は、異なる順序で動作を実行し、ある複数の動作を組み合わせ、ある複数の動作を重複させるなどしてもよい）。

本発明を、いくつかの実施形態の観点で説明してきたが、当業者は、本発明が、説明された実施形態に限定されないこと、並びに、添付の特許請求の範囲の思想及び範囲内の修正及び変形と共に実践し得ることを認識するであろう。よって、本説明は、限定的である代わりに、例示的であるとみなされるべきである。

Claims (20)

1. クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法であって、
   テナントデータベース（ＤＢ）と、テナント識別子−テナントラベル（ＴＩＴＬ）テーブルと、ＴＯＲＳ（top of rack server）ラベル−仮想スイッチリンクラベル（ＴＬＶＬＬ）テーブルと、ラベルマッピングテーブル（ＳＭＶＬ）と、ＣＮＭアドレスマッピングテーブルとを含む複数のデータベース又はテーブル内の複数のアイテムの間のマッピングを維持すること（１２０５）と、
   前記複数のデータベースを用いて、テナントの仮想マシン（ＶＭ）間で送信されるパケットへ付与されるテナント固有ラベルを生成すること（１２１０）と、
   を含む方法。
2. ＯｐｅｎＦｌｏｗスイッチ上のインストール又はアンインストールに先立ってデータベースアクセスが実行される、請求項１の方法。
3. 前記ＣＮＭは、テナントＩＤをキーとして用いて前記テナントラベルをルックアップするために前記ＴＩＴＬテーブルを用いる、請求項１の方法。
4. 前記ＣＮＭは、ＴＯＲＳ（top of rack server）ラベルをキーとして用いて前記仮想スイッチ（ＶＳ）リンクラベルをルックアップするために前記ＴＬＶＬＬテーブルを用いる、請求項１の方法。
5. 前記ＣＮＭは、テナントＩＤ、テナントＶＭメディアアクセス制御（ＭＡＣ）アドレス、テナントＶＭインターネットプロトコル（ＩＰ）アドレス及びサーバＭＡＣアドレスの間のマッピングを維持するために、前記ＣＮＭアドレスマッピングテーブルを用いる、請求項１の方法。
6. テナントごとに１つのＣＮＭアドレスマッピングテーブルが存在する、請求項５の方法。
7. テナントラベルを転送エントリとして追加することにより、テナント固有データが隔離される、請求項１の方法。
8. テナントＩＤを有する前記テナントラベルの使用が、テナント固有トラフィックをそれぞれのＶＭへと分離し及び隔離する、請求項７の方法。
9. 異なるテナントへ属する複数のＶＭが同じインターネットプロトコルアドレス及びメディアアクセス制御アドレスを有する、請求項８の方法。
10. 前記テナントＤＢは、前記ＣＮＭアドレスマッピングテーブルへのポインタを保持する、請求項１の方法。
11. 前記ＣＮＭは、他の全てのＣＮＭアドレスマッピングテーブルのルックアップを実行する前に、まず前記テナントＤＢでのルックアップを実行して、テナント固有のアドレスマッピングテーブルを見出す、請求項１０の方法。
12. クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法であって、
    仮想マシン（ＶＭ）が仮想化されたサーバ上でのアクティブ化のためにスケジューリングされるという通知を受信すること（１３０５）と、
    ＶＭメディアアクセス制御（ＭＡＣ）アドレスを判定すること（１３１０）と、
    前記仮想化されたサーバ上に所在する仮想スイッチ（ＶＳ）ＭＡＣアドレスを判定すること（１３１５）と、
    テナント識別子（ＩＤ）、テナントＭＡＣ及びサーバＭＡＣを含むメッセージを受信すること（１３２０）と、
    ＶＳ−ＴＯＲＳ（top of rack switch）ラベル及びテナント固有ラベルを求めて、ラベルマッピングテーブル及びテナント識別子−テナントラベル（ＴＩＴＬ）テーブル内でのルックアップを実行すること（１３２５）と、
    ＣＮＭマッピングテーブル内に、テナントＩＤ、ＶＭ ＭＡＣアドレス及びＶＳ ＭＡＣアドレスの間の関連付けを記録すること（１３３０）と、
    前記ＶＳ−ＴＯＲＳラベル、前記テナント固有ラベル及び前記ＶＭ ＭＡＣアドレスに適合するデータパケットが前記ＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを、前記ＶＳへ送信すること（１３３５）と、
    を含む方法。
13. 前記ＣＮＭは、前記ＶＭから発せられるＤＨＣＰ（Dynamic Host Configuration Protocol）リクエストが前記ＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを、前記ＶＳへ送信する（１３４０）、請求項１２の方法。
14. 前記ＣＮＭは、前記ＶＭから発せられるＡＲＰ（Address Resolution Protocol）リクエストが前記ＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを、前記ＶＳへ送信する（１３４５）、請求項１２の方法。
15. クラウドネットワークマネージャ（ＣＮＭ）を用いてテナント固有データを隔離するための方法であって、
    ソース仮想スイッチ（ＶＳ）へ、宛て先仮想マシン（ＶＭ）へデータパケットを転送する目的で前記ソースＶＳが当該データパケットへまずテナント固有ラベルをプッシュし次いでＶＳ−ＴＯＲＳ（top of rack switch）ラベルをプッシュすべきであることを示す第１のフローエントリ修正メッセージを送信すること（２００５）と、
    ソースＴＯＲＳへ、前記ソースＴＯＲＳが前記ＶＳ−ＴＯＲＳラベルに適合するデータパケットを受信した場合には前記ソースＴＯＲＳが宛て先ＴＯＲＳラベルをプッシュすべきであることを示す第２のフローエントリ修正メッセージを送信すること（２０１０）と、
    宛て先ＴＯＲＳへ、前記宛て先ＴＯＲＳが前記宛て先ＴＯＲＳラベルに適合するデータパケットを受信した場合には前記宛て先ＴＯＲＳが前記ＴＯＲＳラベルをポップして前記データパケットを宛て先ＶＳへと転送すべきであることを示す第３のフローエントリ修正メッセージを送信すること（２０１５）と、
    前記宛て先ＶＳへ、前記宛て先ＶＳが前記ＶＳ−ＴＯＲＳラベル及び前記テナント固有ラベルに適合するデータパケットを受信した場合には前記宛て先ＶＳがまず前記ＶＳ−ＴＯＲＳラベルをポップし次いで前記テナント固有ラベルをポップすべきであることを示す第４のフローエントリ修正メッセージを送信すること（２０２０）と、
    を含む方法。
16. 前記第１のフローエントリ修正メッセージに応じて、前記ソースＶＳは、前記パケットをソースＴＯＲＳへ転送する、請求項１５の方法。
17. 前記第２のフローエントリ修正メッセージに応じて、前記ソースＴＯＲＳは、クラウドネットワークを用いて前記データパケットを宛て先ＴＯＲＳへ転送する、請求項１６の方法。
18. 前記第３のフローエントリ修正メッセージに応じて、前記宛て先ＴＯＲＳは、前記データパケットを宛て先ＶＳへ転送する、請求項１７の方法。
19. 前記第４のフローエントリ修正メッセージに応じて、前記宛て先ＶＳは、前記パケットを前記宛て先ＶＭへ転送する、請求項１８の方法。
20. 前記ＣＮＭは、ソースＶＭがパケットを同じテナントに属する宛て先ＶＭへ転送することを可能とする目的で、宛て先インターネットプロトコルアドレスを前記ソースＶＭへ提供する、請求項１５の方法。
    

Images