以下の本発明の詳細な説明において、本発明の多くの詳細、例及び実施形態が記載され且つ説明される。しかし、本発明は記載される実施形態に限定されず、本発明は説明される特定の詳細及び例のうちのいくつかを用いずに実施されてもよいことが理解されるべきである。
本発明のいくつかの実施形態は、(i)ネットワーク管理/制御システムが転送要素にアクセス及び制御できるプライベートデータセンタと、(ii)システムが転送要素にアクセスできない1つ以上のパブリックマルチテナントデータセンタとにまたがる論理ネットワークを管理する機能を有するネットワーク管理/制御システムを提供する。いくつかの実施形態のプライベートデータセンタでは、ネットワーク管理/制御システム(本明細書中、ネットワーク制御システムと呼ぶ)は、ホストマシンの仮想化ソフトウェア(例えば、ハイパーバイザ)内で実行するソフトウェア転送要素を管理し、従って、管理者の所望のネットワーク転送ポリシー及びセキュリティポリシーを実現できる。しかし、パブリックデータセンタでは、ネットワーク制御システムは仮想化ソフトウェアにアクセスできず、従って、パブリックデータセンタ内で動作するワークロードに対して同一のネットワークポリシーを実現できない場合がある。
いくつかの実施形態は、プライベートデータセンタの管理及び制御をパブリックデータセンタに拡張するために階層型ネットワーク制御システムを使用する。詳細には、いくつかの実施形態は、データ計算ノード(DCN)との間で送受信されるパケットに対するネットワークセキュリティ規則及び転送規則を実施するために、パブリックデータセンタ内で動作する仮想マシン(VM)又は他のDCN内のネットワーク制御器及び被管理転送要素を動作させる。いくつかの実施形態において、パブリックデータセンタは、テナントが制御できる1つ以上の隔離されたリソース(すなわち、データ計算ノード)セットをテナントに提供する。これを仮想プライベートクラウド(VPC)とも呼ぶ。一部のクラウドプロバイダでは、テナントはネットワークサブネット及びルーティングテーブルを用いて仮想ネットワークを定義すること及び/又はパブリッククラウドプロバイダにより定義されたセキュリティグループに自身のDCNを入れることが可能である。
階層型ネットワーク制御システムを実現するために、いくつかの実施形態は、各VPC内の第1のDCN(又は、各VPC内のアクティブ/スタンバイゲートウェイ制御器としてのDCNのセット)において第1のレベルのネットワーク制御器(ゲートウェイ制御器と呼ぶ)を実現する。また、これらのゲートウェイDCNは、いくつかの実施形態において、同じデータセンタの他のVPC又は他のデータセンタ(プライベートデータセンタ又は別のパブリックデータセンタ)内の論理ネットワークとの通信及び外部ネットワークと通信のためにゲートウェイデータパスを動作させる。各ワークロードDCN(すなわち、ウェブサーバ、アプリケーションサーバ、データベースサーバ等のワークロードアプリケーションを実行するDCN)内で、被管理転送要素(MFE)がワークロードアプリケーションとDCNのネットワークインタフェースとの間のデータパスに挿入される。更に、各MFEを構成するために、ローカル制御エージェントが各ワークロードDCN上で実行する。
プライベートデータセンタ(又は、別個のVPC)内で動作する中央制御プレーンクラスタは、構成規則の範囲に基づいて、プライベートデータセンタ内のホストマシン上で動作するローカル制御器に(すなわち、規則の種類及び規則が適用される論理ポートに基づいて、規則を実施する必要があるMFEに)構成規則を配布する。パブリックデータセンタVPC内で動作する制御システムに当該規則を配布する場合、中央制御器は、VPC内のDCNに対応する全ての論理ポートがゲートウェイ制御器により制御されるMFEに接続されていると見なす。そのため、当該規則は全て、中央制御器によりゲートウェイ制御器に出力される。
次に、ゲートウェイ制御器は、中央制御器から受信した各規則を必要とするVPC内のMFEを識別するために、独自の別個の適用範囲の計算を行い、MFEを制御するように動作するローカル制御エージェントに当該規則を配布する。ローカル制御エージェントは、規則を受信すると、DCNで動作するMFEに特有のフォーマットに規則を変換する。例えばいくつかの実施形態は、パブリックデータセンタVPC内のDCN上で実行するOpen vSwitch(OVS)インスタンス等のフローベースMFEを使用し、その場合、ローカル制御エージェントは、OVSインスタンスに対するフローエントリ及び/又は他の構成データに規則を変換する。
いくつかの実施形態において、ゲートウェイ制御器は、VPC内のオーバーレイトンネルを管理する責任も有する。中央制御器は、VPC全体を単一のMFEと見なすため、ゲートウェイ制御器ノードに対するトンネルエンドポイント(すなわち、ゲートウェイDCN上に構成されたデータパス)のみを構成する。しかし、VPC内のワークロードアプリケーション間(及びワークロードアプリケーションとゲートウェイデータパスとの間)の通信に対して、中央制御器はオーバーレイを構成しない。そのため、ゲートウェイ制御器は、MFE毎にMACから仮想トンネルエンドポイント(VTEP)へのIPバインディングを構成することにより、これらのDCNの間にトンネル(例えば、STT、GENEVE等のトンネル)を設定する。当該情報はワークロードDCN上の種々のローカル制御エージェントにも渡されるため、各MFEは同じVPC内の他のMFEにパケットをトンネリングすることができる。
上述したように、ゲートウェイDCNはゲートウェイ制御器とデータパスとを含む。いくつかの実施形態において、データパスは、(i)他のVPC及び他のデータセンタ内で動作し且つ論理ネットワークに接続されたワークロード及び(ii)外部ネットワークに自身のVPC内のワークロードを接続するゲートウェイとして動作する。いくつかの実施形態において、ゲートウェイDCNは、3つのネットワークインタフェース、すなわち、外部ネットワークとの間で(クラウドプロバイダインターネットゲートウェイを介して)パケットを送受信するアップリンクインタフェースと、ローカルVPCサブネット上のアドレスを有するVTEPインタフェースと、制御トラフィック専用の制御インタフェースとを含む。データパス及びゲートウェイ制御器に加えて、いくつかの実施形態は、VPC内のMFE(場合によっては、ゲートウェイデータパスを含む)によるトラフィックをセキュリティ保護するために使用される暗号鍵を処理するための分散型ネットワーク暗号化(DNE)マネージャと、VPC内のDHCPを処理するためのDHCPモジュールと、管理プレーン及びゲートウェイ制御器がパブリッククラウド管理システムと対話できるようにするパブリッククラウドマネージャ(PCM)とを含んでもよい。
例えばPCMは、パブリッククラウドマネージャをポーリングして、DCNが属することになる論理スイッチ及び/又はセキュリティグループを示すDCNに関連するタグを含めて新しいDCNを識別する機能を有する。更に、いくつかの実施形態のPCMは、パブリッククラウド管理システムと対話して、DCNが不正アクセスされたという通知を受信した場合にDCNを隔離できる。例えば、MFEを実行するDCNへのアクセスをハッカーが取得した場合、ハッカーは、(i)ローカル制御エージェント及び/又はMFEをアンインストールするか、(ii)MFEを介してトラフィックを送信しない新しいインタフェースを作成するか、(iii)既存のインタフェースをMFEから切断するか、又は(iv)MFEをローカル制御エージェントから切断することによりMFEを直接リプログラミングすることができる。インタフェースが編集された場合又は制御エージェントがMFEから切断された場合、エージェントは変更を検出し、ゲート制御器に問題を通知する。エージェント自体が削除された場合、ゲートウェイ制御器はエージェントへの接続が失われたことを検出し、DCNが不正アクセスされたことを識別する。いずれの場合も、ゲートウェイ制御器は不正アクセスされたDCNをPCMに通知する。PCMは、不正アクセスされたDCNを隔離セキュリティグループに入れるためにパブリッククラウド管理システムと対話する機能を有し、それにより(例えば、ホストマシンのハイパーバイザ内の)パブリッククラウド転送要素は不正アクセスされたDCNからのトラフィックを遮断できる。
階層型ネットワーク制御システムは、プライベートデータセンタからパブリックデータセンタにまたがる論理ネットワークの実現を可能にする。異なる実施形態において、異なる論理トポロジがデータセンタにまたがり異なる方法で実現されてもよい。例えばいくつかの実施形態は、所定の論理スイッチに接続されたDCNをプライベートデータセンタ内の単一のVPCに制限するか又は単一のVPCと同様に動作するためにピア接続される同じデータセンタ内の複数のVPCに制限する(当該論理スイッチは、論理ルータを介して、別のVPC又は別のデータセンタ内で実現される論理スイッチに論理的に接続されてもよい)。他の実施形態において、単一の論理スイッチは、同じパブリックデータセンタの複数のピア接続されていないVPC内のDCN、複数のパブリックデータセンタの複数のVPC内のDCN、並びに/又はパブリックデータセンタとプライベートデータセンタの双方のDCNを有してもよい。
以上、VPCへの制御プレーンの拡張及び当該拡張を可能にするゲートウェイ制御器を説明したが、いくつかの実施形態において、VPC内のこれらの種々の構成要素は初期構成され且つ管理プレーン及び中央制御プレーンと共に搭載される必要がある。いくつかの実施形態において、パブリッククラウドにおけるネットワーク及び制御システムの初期設定は運用マネージャ(ライフサイクルマネージャ又はLCMとも呼ばれる)により管理される。ネットワーク管理者は、ネットワーク管理者のパブリッククラウド資格情報を使用する当該LCMと対話して(例えば、ユーザインタフェースを介して)LCMにアクセスし、VPC内の種々のVMを初期構成する。
LCMは、管理者が論理ネットワークを実現したい各VPCを識別し、これらのVPCの各々においてゲートウェイDCN(又はアクティブ/スタンバイゲートウェイDCNセット)を自動的にインスタンス化する。いくつかの実施形態において、ゲートウェイDCNは、特定のパブリッククラウドプロバイダ用にフォーマットされたプリパッケージインスタンスとして提供される。更に、いくつかの実施形態のLCMは、ネットワーク制御システムにより管理される必要があるVPC内の既存のDCNに関する情報を管理者から受信し、それらのDCNに関する論理スイッチ及びセキュリティグループ情報を管理プレーンに提供する。
初期構成の一部として、ゲートウェイ制御器は管理プレーンに認定され(且つ管理プレーンアプリケーションが有効であることを検証し)、ゲートウェイ制御器が対話する中央制御器アプリケーションに同様に認定される必要がある。更に、ワークロードDCNのうちの1つにおいて動作する各ローカル制御エージェントは、構成規則を配布する場合と同様の階層的方法でゲートウェイ制御器に自身を検証させる。
上記の段落における説明は、制御器が動作するVMが既に存在すると仮定する。場合によっては、ユーザ(例えば、非管理者ユーザ)は、パブリックデータセンタVPC内に新規のワークロードDCNを作成し、正確な構成規則セットがDCN上のMFEに提供されることを保証する必要がある。これはいつでも生じ得るため、従って、理想的には、その時点でネットワーク管理者による作業又は認可を必要としないようにするべきである。そのため、いくつかの実施形態において、ネットワーク制御システムは、これらの新規のワークロードDCNのMFEを自動的に提供するように構成される。
DCNを起動する前に、ユーザは、ワークロードが接続することになる論理スイッチ(及び/又はセキュリティグループ)に対するトークンと、インスタンスにインストールする制御エージェントパッケージとを管理者から受け取る。DCNを設定する際、ユーザは、論理スイッチ及び/又はセキュリティグループに対するトークンをインスタンスのラベルとして追加する。いくつかの実施形態において、ユーザがクラウドプロバイダユーザインタフェースを介してインスタンスを作成する場合、インタフェースは、VMインスタンスに関するデータとしてパブリッククラウドデータリポジトリに格納されているタグをVMに追加する機能を含む。例えばタグは、VMがセキュリティグループSG1に属し且つ論理スイッチLS1に接続する必要があることを示すために、「token‐ls1」及び「token‐sg1」というラベルが付けられてもよい。これらのタグは、何らかのアウトオブバンド機構を介して(例えば、口頭で、電子メール又はメッセージ送信等で)ネットワーク制御システム管理者からユーザに提供されてもよい。
いくつかの実施形態のPCMは、当該データリポジトリを定期的にポーリングして、そのVPC内に作成された何らかの新規のDCNを識別する。新規のDCNがVPC内に作成されたという判定に応答して、PCMはいくつかの動作を実行する。PCMは、管理プレーンのインベントリに新規のDCNを追加し、DCNに対する管理プレーン内に作成されたオブジェクトにDCNの種々のパブリッククラウドプロバイダ属性(VM識別子、VPC識別子、インタフェースID等)の全てをタグとして追加する。これにより、ネットワーク管理者はDCN及びその属性を管理プレーンインベントリで閲覧できる。また、PCMは、クラウドプロバイダAPIを使用して論理スイッチ及び/又はセキュリティグループのタグを読み出す。PCMは論理スイッチタグを使用して、新規のポートを作成する論理スイッチを判定する。PCMは新規のポートを作成し、DCNのインタフェースを当該論理ポートに接続する(例えば、クラウドプロバイダからのインタフェース識別子を使用して)。更にPCMは、インタフェースのIPアドレス及びMACアドレスを読み出し、これらを新規に作成された論理ポート上のMAC/IPバインディングとして構成する。また、いくつかの実施形態は、要望に応じて、論理ポートに対してDFW規則を設定できるように、何らかの必要な特徴を有効にする。更に、PCMはセキュリティグループタグに基づいて新規のDCNのセキュリティグループを識別し、管理プレーンを介して当該セキュリティグループに論理ポートを追加する。
上述したように、いくつかの実施形態のMFEはOVSインスタンス等のフローベースMFEである。異なる実施形態において、これらのOVSインスタンスは、非オーバーレイモード、別個の内部IPアドレスと外部IPアドレスとを使用する第1のオーバーレイモード又はそのVTEP及び内部ワークロードアプリケーションに同じIPアドレスを使用する第2のオーバーレイモードのいずれで設定されてもよい。3つの場合の全てにおいて2つのブリッジがOVSインスタンスに設定されるが、3つのオプションに対して3つの異なる方法がある。ワークロードアプリケーションは、ネットワークセキュリティ及び/又は論理転送動作を実行する統合ブリッジの内部ポートに接続する。物理インタフェース(PIF)ブリッジは、MFEが動作するDCNの仮想ネットワークインタフェース制御器(VNIC)に接続する。
いくつかの実施形態の非オーバーレイモードにおいて、ワークロードアプリケーションのIPアドレスは、クラウドプロバイダネットワーク(本明細書中、アンダーレイネットワークと呼ぶ)に対するVMネットワークインタフェースのIPアドレス(クラウドプロバイダにより割り当てられる)と同じである。この場合、MFEはパケット転送を一切実行せず、その代わりに、マイクロセグメンテーション及び/又は分散型ファイアウォール規則処理等のネットワークセキュリティ処理を実行するように構成される。このネットワークセキュリティ処理は統合ブリッジにより実行され、パケットはデフォルトで2つのブリッジ間のパッチポートを介してPIFブリッジへ送信される。
他の実施形態において、MFEは、ワークロードアプリケーションが接続する内部インタフェース(例えば、統合ブリッジ上)が外部インタフェース(PIFブリッジ上)と異なるIPアドレスを有するように構成される。この場合、MFE(例えば、統合ブリッジ)は、何らかのネットワークセキュリティ又は他の処理に加えて、論理ネットワーク構成に従ってパケット転送を実行する。パケットは、ワークロードDCNが接続する論理スイッチポートにマッピングされる第1の内部IPアドレスを使用してワークロードアプリケーションにより送信され、その後、クラウドプロバイダにより割り当てられたIPアドレス(すなわち、VNICのIPアドレス)を使用してカプセル化される。いくつかの実施形態において、統合ブリッジはカプセル化を実行し、第2のネットワークスタックを介してPIFブリッジ上のVTEPへパケットを送信する。
最後に、ネットワーク管理者は、既存のワークロードに対して同じIPアドレスを保持したいが、パケット処理、トンネリング等のために論理ネットワークを利用したい場合がある。この第3の場合では、MFEはアプリケーションとは別個のワークロードVMの名前空間内に構成される。これにより、ワークロードアプリケーションは、既存のIPアドレスを有する名前空間のインタフェースに接続し、次にvethペアを使用して、当該VTEPに同じIPアドレスを使用する別個の名前空間内のMFEに当該インタフェースを接続できる。いくつかの実施形態において、ワークロードアプリケーションとMFEとに別個の名前空間を使用することにより、別個のネットワークスタックが同じIPアドレスを使用できる。
上述したオーバーレイカプセル化の使用は、主に、パブリッククラウドVPC内のワークロードDCN間のイースト/ウエストトラフィックに対して行われる。しかし、多くの論理ネットワークは、外部クライアントがアクセスできる必要のあるワークロードを含む。例えば、一般的な3層(ウェブサーバ、アプリケーションサーバ、データベースサーバ)設定では、少なくともウェブサーバがインターネットを介してクライアントに接続できる必要がある。通常、VPCサブネットは、異なるテナントの多くのVPCにより再利用され(且つ種々の異なるデータセンタにおいて再利用され)てもよいプライベートIPアドレスであるため、発信パケットの送信元IPアドレス(及び、それに対応して着信パケットの宛先IPアドレス)を内部使用されるプライベートIPアドレスからパブリックIPアドレスに変更するために、ネットワークアドレス変換(NAT)が一般に使用される。
更に、論理ネットワークがパブリックデータセンタ内で少なくとも部分的に実現される場合、パブリックIPアドレスへの実際の変換は、ネットワーク制御システムにより管理される何れかのMFEではなく、クラウドプロバイダのインターネットゲートウェイにより実行される必要がある場合がある。しかし、クラウドプロバイダはオーバーレイモードで使用される内部IPアドレスを割り当てていないため、パケットはこれらの内部アドレスを使用してプロバイダのゲートウェイへ送信されるべきでない。その代わりに、いくつかの実施形態のMFEは、内部IPアドレスをクラウドプロバイダに登録されているアドレスに変換するために独自のNATを実行する。
異なる実施形態は、このアドレス変換を異なる方法で実現してもよい。いくつかの実施形態は、ゲートウェイデータパスの一部としてNATを適用する。この場合、ノースバウンドパケットは送信元MFEからゲートウェイにトンネリングされ、そこでIPアドレスは一貫した方法で2次IPアドレスに変換される。いくつかの実施形態は、各内部ワークロードIPアドレスをクラウドプロバイダに登録されている2次IPアドレスにマッピングするNATテーブルを使用する。その後、これらの2次IPアドレスは全て、ゲートウェイのノースバウンドインタフェースに関連付けられ、クラウドプロバイダのゲートウェイはこれらの2次IPアドレスからパブリックIPアドレスへの変換を実行する。集中型の場合、サービスチェイニング(種々のミドルボックス処理のための第3者サービスアプライアンスへのパケットの送信)、侵入検出、ノース/サウスファイアウォール、VPN、監査ロギング等の他のネットワークサービスがゲートウェイで更に適用されてもよい。更に、ゲートウェイがNATを実行する場合、何らかの負荷分散がゲートウェイにおいて更に実行される必要がある(この場合、プロバイダのゲートウェイが関係する限り、全てのトラフィックがゲートウェイインタフェースへ送信されるため、クラウドプロバイダが負荷分散を実行できない場合がある)。
他の実施形態は、送信元DCN(着信トラフィックの場合は宛先DCN)上で動作するMFEにおいて、第1のレベルのNATを分散して実行する。この場合、発信パケットに対して、送信元DCNのMFEはアドレス変換を実行し、変換されたパケットをゲートウェイを経由せずにクラウドプロバイダゲートウェイへ直接送信する。そのため、送信元MFEは、自身のVTEP IPを使用してカプセル化するオーバーレイトラフィックと、カプセル化せずにクラウドプロバイダアンダーレイネットワークへ送信する(いくつかの実施形態において、VTEPと同じIPアドレスを使用して)ノース/サウストラフィックとを区別する。このトラフィックは(両方向で)ゲートウェイを通過しないため、何らかのサービスチェイニンング、侵入検出、ノース/サウスファイアウォール規則、ロギング等はワークロードVM上で動作するMFEにおいて実行される。
負荷分散のために、分散型内部NATはクラウドプロバイダの既存の負荷分散特徴を使用できるようにする。複数のパブリックIPアドレスを使用する代わりに、単一のパブリックIPアドレス(又は少数のアドレスのみ)を使用することができ、全ての着信接続は当該アドレスへ送信される。クラウドプロバイダのインターネットゲートウェイ(又は特別な負荷分散アプライアンス)は負荷分散を実行し、これらの接続を異なるワークロードVM(依然として独自の内部NATを実行する必要がある)に均等に分散する。
論理ネットワークワークロード間で送信されるパケットに対して、いくつかの実施形態は、ネットワーク制御システムにより管理される分散型ネットワーク暗号化(DNE)を使用することを可能にする。いくつかの実施形態において、パブリックデータセンタ内のDCNに対するDNEは同じVPC内又はピア接続されたVPC内で動作するDCN間でのみ可能であるが、他の実施形態において、DNEは論理ネットワークの論理ポートに接続されたいずれか2つのDCN間で可能である(ワークロードDCNとゲートウェイとの間を含む)。
いくつかの実施形態において、分散型ネットワーク暗号化は、ネットワーク制御システム管理者がパケットに対する暗号化規則及び/又は整合性規則を設定できるようにする。これらの規則は、(i)規則が適用されるパケットと、(ii)それらのパケットに対する暗号化要件及び/又は整合性要件とを定義する。いくつかの実施形態は、規則が適用されるパケットをパケットの送信元及び宛先に関して定義する。これらの送信元エンドポイント及び宛先エンドポイントは、IPアドレス又はアドレスの範囲、MACアドレス、論理スイッチポート、仮想インタフェース、L4ポート番号及びその範囲等、並びにそれらの組み合わせに基づいて定義されてもよい。
更に、各規則は、送信元及び宛先の特徴に合致するパケットが暗号化(認証を伴う)を必要とするか、認証のみを必要とするか、あるいはプレーンテキスト(ブロードキャストパケットを許可するための設定として使用されてもよい)を必要とするかを指定する。暗号化は、パケットの一部分又は全部(例えば、内部パケット全体、L4以上のヘッダのみ、トンネリングされるパケットの場合の内部/外部パケット全体等)を暗号化するために鍵を使用する必要があるが、認証はパケットを暗号化せず、送信中にパケットが改竄されていないことを検証するために宛先が使用できる認証データを作成するために鍵を使用する。
ネットワーク内のMFEにDNE規則を実現させるために、ネットワーク制御システムはMFEに鍵をセキュアに配布する必要がある。いくつかの実施形態は、ネットワーク制御システムのDNE態様と通信し且つそのVPC内のワークロードDCN内で動作するMFEに鍵を配布するために、ゲートウェイDCN内のDNEモジュールを使用する。暗号鍵の使用を必要とする規則毎に、DNEモジュールは中央制御器から鍵に対するチケットを受信する。DNEモジュールはチケットを使用してセキュア鍵管理記憶装置に鍵を要求する。これは、チケットが本物であることを検証して、マスタ鍵を返す。いくつかの実施形態のDNEモジュールは、規則により指定された接続毎にセッション鍵を計算し(例えば、VPC内の2つのワークロード間の単一の接続、VPC内の複数の接続、ワークロードとゲートウェイとの間の接続等)、これらの鍵を適切なローカル制御エージェントに配布する。
以上、いくつかの実施形態のネットワーク管理/制御システムを説明した。以下の節では、システムのパブリックデータセンタへの拡張の様々な態様を更に詳細に説明する。第I節では、いくつかの実施形態の階層型ネットワーク制御システムを説明し、第II節では、ゲートウェイDCNのアーキテクチャを説明する。次に、第III節では、パブリッククラウドVPCの初期構成を説明する。第VI節では、論理トポロジの様々な物理的実現例、複数のVPC及び/又はデータセンタにまたがるトポロジの拡張を説明する。第V節では、ワークロードDCN内で動作するMFEの様々な構成を説明し、第VI節では、集中型及び分散型の双方でのNAT及び他のサービスの提供を説明する。次に、第VII節では、パブリックデータセンタにおける分散型ネットワーク暗号化の実現を説明し、第VIII節では、脅威の検出及び処理を説明する。最後に、第IX節では、本発明のいくつかの実施形態が実現される電子システムを説明する。
I. 階層型ネットワーク制御システム
上述したように、いくつかの実施形態は、プライベートデータセンタの管理をAmazon Web Services、Microsoft Azure等のパブリックマルチテナントデータセンタ(「パブリッククラウド」)に拡張するために階層型ネットワーク制御システムを使用する。図1は、プライベートデータセンタ105及びパブリックデータセンタ110の双方の転送要素を管理するいくつかの実施形態のそのような階層型ネットワーク制御システム100を概念的に示す。データセンタ105及び110の双方は、仮想マシン(VM)又は他のデータ計算ノード(DCN)をホストするためのホストマシンを含む。プライベートデータセンタ105において、ネットワーク制御システムは、ハイパーバイザ(仮想化ソフトウェア)及びそれらのハイパーバイザと統合される転送要素を管理する機能を有する。しかし、パブリックデータセンタ110において、ハイパーバイザはデータセンタの所有者により制御されるため、ネットワーク制御システムはハイパーバイザにアクセスできない。
示されるように、プライベートデータセンタ内のネットワーク制御システムは、管理プレーン/中央制御プレーン(MP/CCP)クラスタ115と、多くのホストマシン125の各々におけるローカル制御器120とを含む。ローカル制御器120は、ホストマシン上の被管理転送要素(MFE)セット130を直接制御する。示されるように、ホストマシン上のVM(又は他のデータ計算ノード)は、データトラフィックを送受信するためにMFEセット130に接続する(例えば、仮想ネットワークインタフェース制御器(VNIC)を介して)。ネットワーク制御システムを介して受信した転送/構成データに基づいて、MFEセット130は、これらのVMとの間で送受信されるデータパケットに対して転送動作及びネットワークセキュリティ(例えば、分散型ファイアウォール(DFW)規則、アクセス制御リスト(ACL)規則等)動作を実行する。MFEセットは、いくつかの実施形態では単一の被管理転送要素(例えば、L2、L3及び更なる処理を実行する単一の仮想スイッチ)であってもよく、あるいは種々の被管理転送要素及びセキュリティ要素の組み合わせ(例えば、全てが仮想化ソフトウェア内で動作するフィルタ、L2スイッチ、L3ルータ等のセット)であってもよい。
本明細書で説明するように、MP/CCPクラスタ115は、異なる特徴を有する管理プレーン(MP)と中央制御プレーン(CCP)とを含む。いくつかのそのような実施形態において、MP及びCCPは、同じ物理マシン又は異なる物理マシン上で動作してもよい別個のアプリケーションである。更に、いくつかの実施形態のMP/CCPクラスタ115は、単一の管理プレーンアプリケーション及び単一の中央制御プレーンアプリケーション、管理プレーンアプリケーションのクラスタ及び中央制御プレーンアプリケーションのクラスタ、単一の管理プレーンアプリケーション及び中央制御プレーンアプリケーションのクラスタ、あるいは単一の中央制御プレーンアプリケーション及び管理プレーンアプリケーションのクラスタを含んでもよい。他の実施形態において、本発明から逸脱することなく、これらのアプリケーションの種々の特徴を単一のマネージャ又は制御器アプリケーション(又はそのようなアプリケーションのクラスタ)に組み合わせることができることが理解されるべきである。
いくつかの実施形態において、管理プレーンは、プライベートデータセンタ105の管理者が(例えば、クラウド管理アプリケーションを介して)プライベートデータセンタ105及び/又は1つ以上のパブリックデータセンタ内で実現されるべき1つ以上の論理ネットワークを構成するための構成データを入力するアプリケーションプログラミングインタフェース(API)を提供する。管理者からの論理ネットワーク構成は、論理L2スイッチ及び論理L3ルータのネットワークを含んでもよい(論理ルータは、論理ネットワーク外部の他の論理ルータ及び/又はサブネットへの接続を含む場合がある(例えば、インターネットに接続するために))。論理ネットワーク構成データは、ネットワークアドレス変換(NAT)規則、負荷分散規則、第3者サービスへパケットを送信するための規則、ネットワークセキュリティ規則(例えば、DFW規則)等を更に含んでもよい。
いくつかの実施形態の管理プレーンは、論理転送要素(例えば、論理スイッチ及び論理ルータ)、論理転送要素に対する論理ポート、論理ポートに対するセキュリティ規則及び暗号化規則等を定義する規則に論理ネットワーク構成を変換する。いくつかの実施形態の中央制御プレーンは、これらの規則の適切なMFEへの配布を処理する。いくつかの実施形態において、中央制御プレーンは、各論理ポートの物理ネットワーク内の位置及び当該論理ポートのファーストホップ被管理転送要素を追跡する。特定の論理ポート及び/又は論理転送要素に対する規則を受信すると、中央制御プレーンは当該規則の適用範囲(すなわち、論理ネットワークを適切に実現するために規則を受信する必要があるMFE)を識別し、それぞれのホストマシン125上のMFE130と直接対話するローカル制御器120に規則を配布する。論理ポートに関する規則の適用範囲は、当該論理ポートが存在するホスト上のMFE(すなわち、論理ポートに接続されたDCNをホストするホストマシン上のMFEセット)のみであってもよく、あるいは多くのMFE(例えば、当該論理ポートと同じ論理ネットワークに接続されたDCNをホストするホストマシン上の全てのMFE)であってもよい。
以上、ネットワーク制御システムがホストマシンの仮想化ソフトウェアにアクセスでき、従って単一のホストマシン上の多くのDCNのネットワーク接続を制御できる(仮想化ソフトウェアにおいてMFEを制御することにより)データセンタに対するいくつかの実施形態のネットワーク制御システムを説明した。しかし、論理ネットワークをパブリッククラウドに拡張すると、パブリッククラウドプロバイダのネットワーク管理システムがホストマシンを管理するため、ネットワーク制御システムは仮想化ソフトウェアにアクセスできなくなる。パブリッククラウドプロバイダにより提供されるネットワーク接続及びセキュリティは、テナント予定者にとって十分な場合もあれば、十分でない場合もあるが、いずれの場合も、当該テナントの直接管理下になく、テナントのオンプレミスネットワーク(プライベートデータセンタ内の)と適切に連携しない場合がある。
従って、図1は、パブリックデータセンタ内のホストマシンの仮想化ソフトウェアに対する制御を必要とせずにネットワーク制御システム100をパブリックデータセンタ110に拡張するいくつかの実施形態の技術を示す。図1は、プライベートデータセンタ105の所有者(本明細書中、パブリックデータセンタのテナントと呼ぶ)のためにパブリックデータセンタ110内に作成された仮想プライベートクラウド(VPC)135を示す。仮想プライベートクラウド135(又はパブリッククラウドプロバイダに応じて、同様の構造)は、テナントが制御できるパブリックデータセンタ110の論理的に隔離されたリソースのセットである。一部のクラウドプロバイダでは、テナントはネットワークサブネット及びルーティングテーブルを使用して仮想ネットワークを定義すること及び/又は自身のVMをセキュリティグループ(パブリッククラウドプロバイダにより定義される)に入れることができる。しかし、テナントはクラウドプロバイダ内の転送要素を直接制御することができず、自身のネットワークセキュリティ特徴を要望どおり構成できない場合がある。
図1は、ゲートウェイ制御器150を有するVM145をホストする第1のホストマシン140と、ワークロードアプリケーション165を有するVM160をホストする更なるホストマシン155のセットとをVPC内に示す。ホストマシン140及び155はVPCの一部として示されるが、いくつかの実施形態において、これらのホストマシンは(同じ又は他のテナントの)異なるVPCに属する更なるVMをホストしてもよいことが理解されるべきである。示されるように、ホストマシン140及び155の各々は転送要素170を含む。いくつかの実施形態において、ホストマシンは、パブリッククラウドプロバイダにより管理される自身の仮想化ソフトウェア内に転送要素を含む。しかし、これらの転送要素がクラウドプロバイダネットワークの一部であるため、ネットワーク制御システム100は当該転送要素にアクセスできない。
ここでは単一のVM145として示されるが、いくつかの実施形態において、ゲートウェイ制御器を有する少なくとも2つのVMがVPC135内でインスタンス化される。アクティブ制御器が機能停止した(例えば、それが動作しているホストマシンの機能停止、VMの機能停止又は再起動が必要である等により)場合、ゲートウェイ制御器のうちの一方がアクティブ制御器として動作し、他方がスタンバイ制御器として動作する。いくつかの実施形態において、ゲートウェイVMの他の態様(後述する)も同様にアクティブ/スタンバイモードで動作する。すなわち、いくつかの実施形態において、アクティブゲートウェイVM及びスタンバイゲートウェイVMがインスタンス化される。
いくつかの実施形態において、VM145は、ゲートウェイ制御器150を含むプリパッケージマシンイメージである。ゲートウェイ制御器150は、VPC135内で実現された全ての論理ポートについて、MP/CCPクラスタ115から(例えば、中央制御プレーンアプリケーションから)データを受信する。いくつかの実施形態において、MP/CCPクラスタ115の観点では、ゲートウェイ制御器は多くの論理ポートが接続されたMFEに対するローカル制御器120と等価である(VPC135内で動作するVMにマッピングされた多くの論理ポートが存在すると仮定する)。そのため、MP/CCPクラスタ115は、VPC135内の論理ポートのいずれかに必要な構成規則を全て受信するのはゲートウェイ制御器150であると識別する。ここでは示さないが、いくつかの実施形態において、ゲートウェイVM145は、集中型サービス(例えば、NAT、負荷分散等)を提供し且つVM160と外部送信元との間で送信される(例えば、インターネットを介して)パケットを処理/ルーティングするためのゲートウェイデータパスを更に動作させる。いくつかの実施形態において、当該データパスが必要とする規則もゲートウェイ制御器150に配布される。図7を参照して、いくつかの実施形態のゲートウェイVMを以下に更に詳細に説明する。
VM160はワークロードVMであり、各々がワークロードアプリケーション165(例えば、ウェブサーバ、アプリケーションサーバ、データベースサーバ等)を実行する。更に、ネットワーク制御システム100により構成可能なファーストホップ処理を可能にするために、これらのVMの各々は、制御エージェント170及び被管理転送要素175(例えば、Open vSwitch等の仮想スイッチ)を更に動作させる。構成規則を受信すると、ゲートウェイ制御器150はVPC135内での当該規則の適用範囲(すなわち、規則を必要とする種々のMFE175)を識別し、それらの構成規則を適切な制御エージェント170に渡す。制御エージェント170は、当該データを使用して、ローカル制御器120がMFE130を構成する方法と同様に、ワークロードアプリケーション165との間で送受信されるパケットにネットワーク接続及び/又はセキュリティ規則を適用するようにMFE175を構成する。
図2は、ネットワーク制御システム100を通る制御データの流れを概念的に示す。MP/CCPクラスタ115は、新規の構成規則を生成する(例えば、ネットワーク内の変更、管理者が論理ネットワークを変更する際に管理プレーンが受信した構成データ等に基づいて)。いくつかの実施形態において、管理プレーンは当該規則を生成して中央制御プレーンに提供し、中央制御プレーンは構成規則の適用範囲を判定する。示されるように、MP/CCPクラスタ115は、当該データを必要とするプライベートデータセンタ105内のローカル制御器120にデータ205を渡す。プライベートデータセンタ内では、情報は制御チャネルを介して配布される。当該データ205を受信したローカル制御器は、そのホストマシンに存在するMFEの特定の種類に適したフォーマットにデータを変換する。いくつかの実施形態において、データセンタは、ESXハイパーバイザ等の特徴ベース転送要素、Open vSwitch(OVS)を実行するカーネル仮想マシン(KVM)ハイパーバイザ等のフローベース転送要素又は他の種類のソフトウェア転送要素を使用するホストマシンを含む場合がある。ローカル制御器120は構成データ205を受信し、それを適切なフォーマット(例えば、OVS用のフローエントリ)に変換し、当該構成データ210をローカルMFE130に配布する。
適用範囲がパブリックデータセンタ110内のVPC135を含む構成規則の場合、MP/CCPクラスタ115はゲートウェイ制御器150へ構成データ215を送信する。MP/CCPクラスタはゲートウェイ制御器を単に別のローカル制御器であると見なすため、いくつかの実施形態において、構成データ215は構成データ205と同じフォーマットである。しかし、ゲートウェイ制御器150へ構成データ215を送信するために、いくつかの実施形態はプライベートデータセンタ105とVPC135との間の仮想プライベートネットワーク(VPN)設定を使用する。いくつかの実施形態は、プライベートデータセンタとVPCとの間の論理ネットワークデータトラフィックと同じVPNを制御トラフィックに使用し、他の実施形態は別個のデータを使用する。クラウドプロバイダの転送要素には、制御トラフィックはVPNを介して送信されている他の何らかのデータと同じように見える。ゲートウェイ制御器150は構成データ215を受信し、規則毎にVPC135内での適用範囲を計算する。VPC135内の各MFE175に対して、ゲートウェイ制御器150は、MFEと同じVM上で動作するローカル制御エージェント170へ適切な構成データ220を送信する。当該構成データ220は、クラウドプロバイダのネットワークを介して(例えば、転送要素170を介して)制御エージェント170へ送信される。
更に、いくつかの実施形態において、ゲートウェイ制御器150は、VPC135内のオーバーレイネットワークを管理する責任を有する。MP/CCPクラスタ115は単一の被管理転送要素を有するものとしてVPC全体を見なすため、クラスタはゲートウェイ制御器ノードに対するトンネルエンドポイント(すなわち、ゲートウェイVM145上に構成されたデータパス)のみを構成する。しかし、VPC内のワークロードアプリケーション間(及びワークロードアプリケーションとゲートウェイデータパスとの間)の通信に対して、MP/CCPクラスタはオーバーレイを構成しない。そのため、ゲートウェイ制御器150は、MAC:VTEP IPバインディング等を構成することにより、これらのVMの間にトンネル(例えば、STT、GENEVE等のトンネル)を設定する。過剰なデータ(例えば、MAC:VTEP IPバインディング)も構成データ220の一部として種々の制御エージェント170に渡される。
制御エージェント170が構成データを受信すると、制御エージェント170は当該データをMFE175に特有のフォーマットに変換し、MFEに特有の構成データ225をMFE175に提供する。いくつかの実施形態において、この構成データ225は、フローベースMFEに対するフローエントリ及び/又はMFE構成データベースに対するデータベースエントリを含む。例えばいくつかの実施形態において、MFEがOVSインスタンスである場合、制御エージェント170はOpenFlow及び/又はOVSDBプロトコルを使用してMFE175と通信する。
一例として、MP/CCPクラスタ115からゲートウェイ制御器へ送信される初期構成データは、新規の論理ポートが論理スイッチに追加されたこと及び当該論理ポートがVPC内で動作するMFEに接続されることを指定してもよい。本例において、同じ論理スイッチの少なくとも1つの論理ポートは、VPC内で動作する異なるMFEに既に接続されている。CCPにとって論理ポートはゲートウェイに接続するため、ゲートウェイ制御器150により受信される構成データは特定の位置を特定しない。
ゲートウェイ制御器150は、同じ論理スイッチ上の更なる論理ポートの全てが接続するVPC内のMFEとして当該構成データの適用範囲を計算する。これらのMFEは、新規の論理ポートに対応するワークロードアプリケーションにパケットを適切に転送できるように情報を必要とし、従って、ゲートウェイ制御器150は、これらの識別されたMFEの各々に対するローカル制御エージェント170に当該データを配布する。また、ゲートウェイ制御器150は、新規の論理ポートが接続するMFEに対するオーバーレイ情報(例えば、MAC:VTEP IPバインディング)を識別された各MFEに配布し、これらの他の識別されたMFEに対するオーバーレイ情報を新規の論理ポートが接続するMFEに配布する。
特定のMFE175に対する制御エージェント170は、当該情報を使用して論理転送フローエントリを生成し(すなわち、論理ポートに関連付けられたMACアドレスにアドレス指定されたパケットが当該論理ポートに論理的に転送されることを指定し)、そのMFEに対する出口マッピング/物理的転送(トンネリング)フローエントリを更に生成する(すなわち、論理ポートを物理的宛先にマッピングし、パケットを他のMFEへ送信するためにカプセル化情報を付加する)。同様に、新規の論理ポートが接続するMFE175に対する制御エージェント170は、他の論理ポートの位置に関する情報を受信し、対応するMFEとの間でパケットを送受信できるように、対応するフローエントリを生成する。
図3は、プライベートデータセンタ及びパブリックデータセンタの双方に位置する被管理転送要素に構成データを配布するいくつかの実施形態の処理300を概念的に示す。いくつかの実施形態において、処理300は、管理プレーンアプリケーションから受信した構成データに基づいて中央制御器(すなわち、中央制御プレーンアプリケーション)により実行される。いくつかの実施形態において、クラスタ内の異なる制御器が異なる転送要素への配布を処理してもよいため、構成データの配布が実際はクラスタ内の複数の中央制御器により実行されてもよいことが理解されるべきである。更に、本処理は、管理プレーン及び中央制御プレーンがプライベート(企業)データセンタに位置すると仮定する。MP/CCPクラスタがパブリックデータセンタのVPC内で動作している場合、これは構成データ毎に同様の適用範囲の計算を実行し、論理ネットワークが動作する各VPCに対するゲートウェイ制御器にデータを配布する。
示されるように、処理300は、論理ネットワーク構成データを受信する(305において)ことにより開始する。上記で説明したように、いくつかの実施形態において、管理プレーンは、管理者から受信した(例えば、クラウド管理アプリケーションを介して)入力に基づいて、論理ネットワークに対する構成規則を生成する。管理プレーンは、これらの規則を中央制御プレーンに提供する。この構成データは、論理転送要素又はこれらの論理転送要素の論理ポートの作成又は削除、これらの論理エンティティのうちの1つに関する新規の構成データ、新規のセキュリティグループ定義又は分散型ファイアウォール規則等に関係してもよい。
次に、処理は、アトミックデータ毎(例えば、規則毎)に、当該データを受信するべきMFEのセットを識別する(310において)。中央制御器は、論理ネットワークのトポロジ及びその物理的実現と、規則の種類及び規則が関係する論理エンティティ(例えば、論理転送要素及び論理ポート)とに基づいて、各規則の適用範囲を判定する。例えば、2つの論理ポート間の通信に対する分散型ネットワーク暗号化規則は、それらの論理ポートが直接接続するMFEに配布するだけでよいだろう。一方、論理ポートからMACアドレスへのバインディングに関する規則は、論理ポートが接続するMFEだけでなく、論理ポートを宛先とするパケットを処理している可能性のある他の何らかのMFE(例えば、論理ポートが接続し且つパケットの集中型処理を必要とせずに特定の論理ポートへパケットを送信できる何らかのMFE)にも配布される。
構成データの各アトミックデータの適用範囲を判定した後、処理は、プライベートクラウド内の識別されたMFEに対するローカル制御器へ構成データを送信する(315において)。すなわち、中央制御プレーンは、同じデータセンタ内の適切なローカル制御器にデータを配布する。
処理は、いずれかのデータの適用範囲がパブリッククラウドに位置する論理ポートを含むかを更に判定する(320において)。上述したように、中央制御プレーンは、パブリッククラウドVPC内の全ての論理ポートが単一のMFEに接続されていると見なす。本処理は、図1に示すように、単一のパブリックデータセンタに単一のVPCが存在すると仮定する。以下に説明するように、いくつかの実施形態では、1つ以上のパブリックデータセンタに複数のVPCが存在することが可能であり、その場合、VPC毎に同様の判定を行う必要がある。データをパブリッククラウド内のMFEへ送信する必要がある場合、処理はパブリッククラウド内で動作するゲートウェイ制御器へ当該データを送信する(325において)。いくつかの実施形態において、データは、中央制御器とゲートウェイが動作するDCNとの間のVPN接続を使用して配布される。
図4は、VPC内のMFEに論理ネットワーク構成データを配布するためのいくつかの実施形態の処理400を概念的に示す。いくつかの実施形態において、処理400は、データを必要とするVPC内のMFEに当該データを配布するために、ゲートウェイ制御器400により実行される。示されるように、処理は、中央制御器から論理ネットワーク構成データを受信する(405において)ことにより開始する。この中央制御器は、パブリックデータセンタのテナントが管理するプライベートデータセンタに位置してもよく、ゲートウェイ制御器と同じパブリックデータセンタの別のVPCに位置してもよく、あるいは別のパブリックデータセンタに位置してもよい。
アトミックデータ毎(例えば、規則毎)に、処理400は、データを受信するべきVPC内のデータ計算ノードを識別する(410において)。図3に関して説明したように、各規則は、論理ネットワークのトポロジ及びその物理的実現と、規則の種類及び規則が関係する論理エンティティ(例えば、論理転送要素及び論理ポート)とに基づいて、適用範囲(すなわち、規則を必要とするMFE)を有する。従って、VPC内では、各規則がゲートウェイ制御器により全ての制御エージェントに配布される必要がない場合がある。次に、処理は、規則に対して識別されたデータ計算ノード上のローカル制御エージェントへ各構成規則を送信する(415において)。いくつかの実施形態において、構成データは、標準的なデータパケットと同じ方法でパブリッククラウドプロバイダの物理ネットワークを介して送信される。
また、処理400は、VPC内の各データ計算ノードに対するローカルオーバーレイデータを生成する(420において)。中央制御器はVPC全体が単一のMFEに接続されていると見なすため、中央制御器はゲートウェイVMに対する仮想トンネルエンドポイント(VTEP)のみを定義する。しかし、VPC内の通信では、種々のMFEはオーバーレイネットワークも使用する。従って、ゲートウェイ制御器は、これらのVTEPに対するMAC:IPバインディングを定義する(VPC内のVMに対してテナントにより構成されたプライベートIPアドレス(又は、構成に応じて、パブリックIPアドレス)に基づいて判定されたIPアドレスを用いて)。これらのオーバーレイの設定は、以下の第IV節及び第V節で更に詳細に説明する。
次に、処理は、VPC内のデータ計算ノード間にトンネルを作成するために、VPC内の各データ計算ノードへローカルオーバーレイデータを送信する(425において)。これにより、これらのデータ計算ノードの各々におけるMFEは、自身のVTEPからVPC内の他のMFEのVTEPへ送信されるパケットを適切にカプセル化できる(以下に更に詳細に説明するように、パブリックデータセンタの設定に応じて、これらのパケットはホストマシン上のプロバイダにより制御される転送要素により再度カプセル化される)。
処理400は概念的な処理であり、ゲートウェイ制御器は例示された直線的な方法でこれらの動作を実行しなくてもよいことが理解されるべきである。例えばいくつかの実施形態は、新規のデータ計算ノードがVPC内に作成される場合は常に動作420及び425を実行し、新規の構成規則を中央制御器から受信した(新規のデータ計算ノードが作成される場合に受信されるが、他の構成の態様が変更される場合にも常に受信される)場合は常に動作405~415を実行する。
図1及び図2に示す例は、論理ネットワークがプライベートデータセンタ105とパブリックデータセンタ内の単一のVPC135との双方にまたがる場合を示す。他の実施形態では異なる変形も可能であることが理解されるべきである。例えば図5は、パブリックデータセンタ500内で完全に実現される論理ネットワークに対するネットワーク制御システムの一例を概念的に示す。この場合、MP/CCPクラスタ505は、第1のVPC515内のホストマシン510上で動作する。ゲートウェイ制御器と同様に、管理プレーン及び/又は中央制御プレーンアプリケーションは、パブリックデータセンタ500内でインスタンス化可能な事前に構成されたVMイメージの一部として提供され得る。いくつかの実施形態において、管理プレーン及び/又は中央制御プレーンアプリケーションは、同じ1つ又は複数のVM上で又は別個のVM上で動作することができ、各々が複数のホストマシン上の複数のVMのクラスタとして動作できる。VPC520は図1に示すVPC135と同様に構成され、第1のVM525(又はアクティブ/スタンバイ構成では2つのVM)がゲートウェイ制御器530をホストし、制御エージェント535がワークロードVM545上のMFE540を管理する。
図6は、論理ネットワークを複数のパブリックデータセンタ610及び615に拡張するいくつかの実施形態のネットワーク制御システム600を概念的に示す。図6に示すように、MP/CCPクラスタ620はプライベートデータセンタ605内で動作し、上述したようにローカル制御器を介してデータセンタ内のMFEを管理する。本例では、論理ネットワークは第1のパブリックデータセンタ610及び第2のパブリックデータセンタ615に拡張され、各パブリックデータセンタは、ゲートウェイVMインスタンス(又はアクティブ/スタンバイ対)を有するVPCと、図1を参照して説明したように構成される複数のホストマシンとを含む。MP/CCPクラスタ620は、これらのゲートウェイ制御器の各々を単一のローカル制御器と同様であると見なし、従って、各VPC内のワークロードに対する構成データの全てを各ゲートウェイ制御器へ送信する。
図1、図5及び図6におけるこれらの異なるアーキテクチャは、多くの可能なアーキテクチャのうちの3つにすぎないことが理解されるべきである。例えばネットワーク制御システムは、各VPCに1つのゲートウェイ制御器(又はアクティブ/スタンバイ対)を用いて、あるいは全てのVPCを管理するためにVPCのうちの1つ(又は別個のVPC)内の単一のゲートウェイ制御器(又はアクティブ/スタンバイ対)を使用して、1つのクラウドプロバイダ内の複数のVPCにわたり延在することができる。
II. ゲートウェイVMのアーキテクチャ
上記の節では、いくつかの実施形態のゲートウェイVMのネットワーク制御器機能(適用範囲の計算及びオーバーレイ管理)を説明した。いくつかの実施形態において、これらのゲートウェイVMは、パブリッククラウドAPIとのインタフェース、DHCP、DNE管理、並びにVPC内のDCNとの間で送受信されるデータパケットに対するゲートウェイを含むいくつかの他の機能を更に実行する。
図7は、いくつかの実施形態のそのようなゲートウェイVM700のアーキテクチャを概念的に示す。上述したように、いくつかの実施形態において、ゲートウェイVMは、論理ネットワークの管理者がパブリックデータセンタVPC内のVMのうちの1つとしてインスタンス化することができる特定のクラウドプロバイダに対する事前に構成されたVMイメージ(例えば、Amazon Machine Image)としてパッケージ化される。示されるように、ゲートウェイVM700は、ゲートウェイ制御器705、パブリッククラウドマネージャ(PCM)710、ゲートウェイデータパス715、DNE管理モジュール720及びDHCPモジュール725を含む。異なる実施形態において、ゲートウェイVMは、これらのモジュールの異なる組み合わせ、並びにこれらのモジュールの全部又は一部と他のモジュールとの組み合わせを含んでもよいことが理解されるべきである。
更に、ゲートウェイVMは、制御VNIC730、アップリンクVNIC735及びローカルオーバーレイVNIC740である3つのインタフェースを含む。いくつかの実施形態において、制御VNIC730は、VPC内の他のホスト上のローカルエージェントとゲートウェイ制御器705との間の制御パス通信及びMP/CCPクラスタとゲートウェイ制御器705との間の制御パス通信(並びにDNEマネージャ720又はPCMの何らかの通信)にのみ使用される。いくつかの実施形態は、VPC内の不正アクセスされたVMからのサービス拒否(DoS)攻撃を防止するために、クラウドプロバイダ内のセキュリティグループがCCP及びローカルエージェントからの特定のトラフィックのみを当該インタフェース上で許可するようにプログラムする。更に、悪意のあるVMがゲートウェイデータパス715に大量のトラフィックを送信している場合でも制御チャネルが実行し続けることを保証するために、いくつかの実施形態は、ゲートウェイ制御器処理(及びVPC内の他のVM内で動作するエージェント)をデータプレーン処理を実行しない特定の仮想CPUに固定する。アップリンクVNIC735は、ゲートウェイデータパス715から外部の宛先に向けて送信される(及びそれら外部の宛先から受信される)ノース/サウスパケットを処理する。一般に、そのようなパケットはデータパスによりカプセル化されない。ローカルオーバーレイVNIC740は、VPC内のワークロードアプリケーションと他のVPC、他のパブリックデータセンタ及び/又はオンプレミスデータセンタ内のデータ計算ノードとの間でパケットを送信するためにゲートウェイデータパスが処理するイースト/ウエストデータパケットを処理する。
いくつかの実施形態のゲートウェイ制御器705は、上記の第I節で説明した機能を実行する。制御VNIC735を介して、ゲートウェイ制御器705の中央制御プレーンインタフェース745は中央制御器から構成規則を受信し、中央制御器に情報を提供する(例えば、新規のVMが作成されたため、新規の論理ポートをゲートウェイに関連付ける必要がある場合)。エージェントインタフェース750は、VPC内のデータ計算ノード上で動作するローカルエージェントに構成データを配布し、データ計算ノード上でイベント(例えば、データ計算ノード上でのインタフェースの作成等)が発生した場合にこれらのローカルエージェントから更新を受信する。いくつかの実施形態において、これらのインタフェース745及び750の双方は、ゲートウェイVM上で動作するnetcpaエージェントの一部である。
ゲートウェイ制御器705は、適用範囲マネージャ755及びローカルオーバーレイマネージャ760を更に含む。適用範囲マネージャは、中央制御器から送信された構成規則を受信し(CCPインタフェース745を介して)、VPC内のデータ計算ノード上で実行するMFE(場合によっては、ゲートウェイデータパス715を含む)を判定し、これらの構成規則をVPC内の適切なエージェントへ送信する。いくつかの実施形態は、VPC内の各エージェントに対して異なるアダプタ及び/又は異なるキューを使用し、受信した各規則を1つ以上のそのようなキューに入れる。
ローカルオーバーレイマネージャ760は、VPC内のオーバーレイネットワークの管理を処理する(第V節で後述するように、オーバーレイモードで動作するMFEに対して)。いくつかの実施形態において、VPC内のMFEがオーバーレイモードで動作していると仮定した場合、VPC内のVM上の各エージェント(及びゲートウェイデータパス715)は、自身のVTEP IPアドレス及び当該VTEP IPアドレスにバインディングされたMACアドレスを制御器に提供する。いくつかの実施形態のローカルオーバーレイマネージャ760は、提供された各バインディングを必要とするVPC内のMFEを識別し、MACアドレスへ送信されるデータパケットを対応するVTEP IPアドレスを使用してカプセル化できるように、VPC内のMFEへの当該情報の提供を処理する。第1のMFEに接続されたワークロードアプリケーションが、データパケットにゲートウェイデータパス715を通過させる必要なく第2のMFEに接続されたワークロードアプリケーションにデータパケットを送信する可能性がある場合、第1のMFEは第2のMFEのMAC:VTEP IPバインディングを必要とする。
いくつかの実施形態のパブリッククラウドマネージャ(PCM)710は、ネットワーク制御システムがパブリッククラウドプロバイダの計算管理システムと対話できるようにする。詳細には、いくつかの実施形態のPCMはパブリッククラウドAPIを使用して、パブリッククラウドプロバイダからインベントリ情報、構成情報、状態情報及び統計情報を検索する。ここで示す例では、PCM710はゲートウェイVM上で動作するが、他の実施形態において、PCMはMP/CCPクラスタ(例えば、プライベートデータセンタ内の)で動作してもよい。
示されるように、PCMは、パブリッククラウドAPI765と、エージェント及びMP/CCPクラスタと通信するためのインタフェース770及び775とを含む。いくつかの実施形態において、PCMは管理プレーンとのみ直接通信し、エージェントとの間のあらゆる通信はゲートウェイ制御器を通過する。パブリッククラウドAPI765は、パブリッククラウドの計算マネージャと通信するために使用される。
例えばいくつかの実施形態のPCM710は、パブリッククラウドマネージャからインベントリ情報を取り出し、変更が検出された場合にこれらの更新を管理プレーンへ送信する。管理プレーンは、当該情報を使用して、論理ネットワークが実現される1つ以上のパブリックデータセンタ及び/又はプライベートデータセンタ内のデータ計算ノードのインベントリを保持する。いくつかの実施形態において、パブリッククラウドからの当該インベントリは、サブネット、セキュリティグループ、データ計算ノード(例えば、VM)及びネットワークインタフェースのうちのいくつか又は全てを含んでもよい。
更に、いくつかの実施形態において、PCM710は、パブリッククラウド内のVM上に構成されたタグを使用して、これらのVMのネットワーク及びセキュリティ設定を管理プレーンに指定する(例えば、VMを追加する必要がある論理スイッチ及びセキュリティグループ)。ローカルエージェント及びMFEがインストールされていないVMがVPCにおいて起動される場合、いくつかの実施形態のPCMは、これらのパッケージのVMへのインストールも処理する。PCMは更に、そのVPC内のVMが不正アクセスされた場合に通知され、パブリッククラウドAPI765を使用してパブリッククラウドマネージャを介して当該VMを隔離セキュリティグループに入れることができる。
ゲートウェイデータパス715は、いくつかの実施形態ではデータ処理ゲートウェイとして動作し、(i)ローカルVPC内のデータ計算ノードと、同じクラウドプロバイダの異なるVPC、異なるクラウドプロバイダの異なるVPC及び/又はプライベートデータセンタに位置する同じ論理ネットワークの他のデータ計算ノードとの間、並びに(ii)ローカルVPC内のデータ計算ノードと論理ネットワーク外部の送信元/宛先(例えば、インターネットを介してデータ計算ノードにアクセスするクライアント)との間のデータパケットに対するパケット処理を処理する。データパス715は、データパス内のサービスルータ780(いくつかの実施形態の論理ルータの集中型ルーティング構成要素)を示すが、データパスはVPC内で実現される1つ以上の論理スイッチ及び1つ以上の分散型ルーティング構成要素の構成を更に含んでもよいことが理解されるべきである。
異なる実施形態において、データパス715は、データパス開発キット(DPDK)ベースのデータパス、いくつかの実施形態のデータ計算ノードで使用されるようなOVSデータパス又はVM内で実現可能な別の種類のデータパスであってもよい。OVSデータパスが実現される場合、いくつかの実施形態は、論理スイッチ及び/又は分散型ルータ処理のためにOVSデータパスを使用し、集中型ルーティング構成要素処理を処理するために別個の名前空間を実現する。一方、DPDKベースのデータパスを使用するいくつかの実施形態は、同じデータパス内の全ての論理転送要素構成要素に対する構成を実現する。いくつかの実施形態のゲートウェイデータパスの更なる説明は、本明細書に参考として取り入れられる米国特許出願公開第2016/0226759号明細書に記載される。
示されるように、データパス715は、ローカルオーバーレイVNIC740に接続するVTEPポート785及びアップリンクVNIC735に接続するアップリンクポート790である2つのポートを使用する。ゲートウェイデータパス715は、VPCサブネット上の(すなわち、VPC内の他のVMに割り当てられたアドレスと同じサブネット上の)クラウドプロバイダにより割り当てられたIPアドレスを使用するVTEP785を介してVPC内のローカルワークロードから送信されたパケットを受信する。いくつかの実施形態では全てのトラフィックが論理に対してカプセル化されるため、当該VTEPポート785は、プライベートデータセンタ内のデータ計算ノードとの間、並びに同じパブリックデータセンタ又は他のパブリックデータセンタ内の他のVPC内のデータ計算ノードとの間で送受信されるパケットにも使用される。
アップリンクポート790は、VPC内のワークロードと外部の送信元/宛先との間でノース/サウスデータトラフィックを送受信するためにデータパス715により使用される。これらのデータパケットは、カプセル化されずにアップリンクポートから送信される(但し、クラウドプロバイダネットワーク上でクラウドプロバイダゲートウェイに別個にトンネリングされてもよい)。更に、これらのパケットは、NAT、ノース/サウストラフィックに対する分散型ファイアウォール規則、サービスチェイニング等の集中型サービスを必要とする場合がある。
複数のVPC及び/又はデータセンタにまたがる論理L2スイッチの場合、ゲートウェイデータパス715は、別のVPCの同様に構成されたゲートウェイに又はプライベートデータセンタ内の宛先転送要素に(VPNを介して)パケットを単にトンネリングする(VTEP785を使用して)中間転送要素として機能する。いくつかの実施形態は、セキュリティ動作(例えば、そのようなパケットに対する分散型ファイアウォール規則の適用)を更に実行し、暗号化を必要とする2つのエンドポイント間で送信されるパケットを復号化してから再暗号化する(検査し、場合によっては処理するために)。2つの異なる論理スイッチ間で送信されるパケットは、集中型サービス(NAT、負荷分散等)がそのようなパケットに必要とされる場合、サービスルータ処理780を更に必要としてもよい。
ネットワーク内に位置するデータ計算ノードに対する暗号化規則及び鍵を管理するために、DNEマネージャ720はネットワーク制御システムと対話する。ローカルVPC内で動作するワークロードのいずれかとの間で送受信されるパケットに対する暗号化及び/又は認証の要件を指定する規則を中央制御プレーンが受信すると、中央制御器はこれらの規則をDNEマネージャ720に配布する(直接又はゲートウェイ制御器705を介して)。以下及び参考として本明細書に取り入れられる米国特許出願第62/380,338号で更に詳細に説明されるように、いくつかの実施形態の暗号化規則は、多くの場合はプライベートデータセンタに位置する鍵記憶装置(鍵マネージャとも呼ばれる)から鍵を取得するために制御器(この場合は、DNEマネージャ)により使用されるチケットを含む。
DNEマネージャ720は、このチケットを使用して鍵マネージャに鍵を要求し、鍵マネージャは暗号化規則に対するマスタ鍵を提供する。DNEマネージャ720はマスタ鍵を受信し、この鍵を使用して規則に対するセッション鍵を生成する。いくつかの実施形態において、セッション鍵は、マスタ鍵と暗号化を実行する2つのエンドポイントに特有の1つ以上の更なるパラメータとの関数として生成される。DNEマネージャは、生成されたセッション鍵を適切なエンドポイントに配布する(例えば、ゲートウェイ制御器705を介して)。
最後に、DHCPモジュール725はVPC内でIPアドレス管理を実行するためのDHCPサーバとして機能する。いくつかの実施形態は、複数の論理スイッチがVPC内で実現される場合、複数のサブネットに対して同一のDHCPモジュール725を使用する。VPC内のVMが起動すると、いくつかの実施形態では、VMはネットワークアドレスを受信するためにローカルゲートウェイ内のDHCPサーバを使用する。
III. 初期VPC構成
上記の節では、VPCへの制御プレーンの拡張及び当該拡張を可能にするゲートウェイ制御器を説明したが、いくつかの実施形態において、VPC内のこれらの種々の構成要素は最初に構成され且つ管理プレーン及び中央制御プレーンと共に搭載される必要がある。いくつかの実施形態において、パブリッククラウドにおけるネットワーク及び制御システムの初期設定は、運用マネージャ(ライフサイクルマネージャ又はLCMとも呼ばれる)により管理される。ネットワーク管理者は、ネットワーク管理者のパブリッククラウド資格情報を使用する当該LCMと対話して(例えば、ユーザインタフェースを介して)LCMにアクセスし、VPC内の種々のVMを初期構成する。
図8は、プライベートデータセンタを管理するネットワーク制御システムをパブリックデータセンタの1つ以上のVPCに初期拡張するいくつかの実施形態の処理800を概念的に示す。いくつかの実施形態において、処理800は、この初期設定を実行するためにプライベートデータセンタ管理システムと(例えば、計算マネージャと)対話するライフサイクルマネージャ(LCM)により実行される。LCMはパブリックデータセンタ内のDCN(PCMが実行するゲートウェイDCNを含む)の初期構成を処理するがPCMはパブリックデータセンタ管理システムとの継続的対話を処理するという点で、LCMは上述のPCMと異なる。処理800は、LCMの1つの可能なワークフローにすぎず、DCNがパブリックデータセンタ内で既にインスタンス化されていると仮定されることが理解されるべきである。いくつかの実施形態において、例えばVPCは定義されているがDCNがこれらのVPCにまだ存在していない場合、他のワークフローが存在するだろう。
示されるように、処理800は、ネットワークを構成しようとするデータセンタのパブリッククラウドプロバイダに対する管理者資格情報を受信する(805において)ことにより開始される。資格情報は、ユーザ名及びパスワードを含んでもよく、場合によっては、データセンタが必要とする他の資格情報を含んでもよい。いくつかの実施形態のLCMは、ユーザがAmazon、Google、Microsoft等の複数のパブリッククラウドプロバイダと統一された方法で対話することを可能にし且つそれを介してユーザがこれらの資格情報を入力することを可能にする単一のインタフェースを提供してもよい。次に処理は、これらの資格情報を使用して、ユーザに登録されているパブリッククラウド内のVPCのリストを検索する(810において)。このために、LCMはこれらの資格情報をパブリッククラウド管理システムのインタフェースに提供し、ユーザのVPCに関する要求したデータを提供される。いくつかの実施形態において、ユーザは、割り当てられたサブネット等を用いてパブリッククラウド内に多くのVPCを既に構成している。
次に、処理800は、ネットワーク制御システムにより管理しようとするVPCに関する識別を管理者/ユーザから受信する(815において)。いくつかの実施形態において、これらは論理ネットワークが拡張されることになるVPCである。いくつかの実施形態において、LCMはユーザインタフェースを介して管理者にリストを提示し、管理者はインタフェースを介して利用可能なVPCのうちのいくつか又は全てを選択する。処理は、識別されたVPCの各々にゲートウェイインスタンスを自動的に配置する(820において)。いくつかの実施形態において、ゲートウェイインスタンスは、第II節で上述した構成要素を有するVMである。説明したように、いくつかの実施形態において、各ゲートウェイVMは、ゲートウェイVMがデータセンタ内に配置されるパブリッククラウドプロバイダ専用に設計されたプリパッケージマシンイメージのインスタンスである。
更に、処理800は、管理者により識別されたVPC内のDCN(例えば、VM)のリストを検索する(825において)。VPCの検索と同様に、いくつかの実施形態において、LCMはこの情報をパブリッククラウド管理システムに問い合わせる。処理は、既存のDCNのうちネットワーク制御システムにより管理するべきDCNに関する管理者からの指示と、当該DCNに対する論理スイッチ及び/又はセキュリティグループの指定とを受信する(830において)。この場合、論理ネットワークトポロジ及びセキュリティグループの定義は既に構成されており、パブリッククラウド内のDCNはこれらのエンティティにマッピングされる。処理800は、これらのDCNとの間で送受信されるパケットを処理するための適切な構成規則が生成され且つネットワーク制御システムを介して配布されるように、論理スイッチ及びセキュリティグループのマッピングを管理プレーンに提供する(835において)。
上記の処理は、LCMがゲートウェイDCNをパブリッククラウド内でインスタンス化すると説明する。しかし、いくつかの実施形態において、そのゲートウェイDCN上のゲートウェイ制御器も、中央制御器からデータを受信するためにMP/CCPクラスタに認定される必要がある。図9は、管理プレーン及び制御プレーンにゲートウェイ制御器を認定させるためのいくつかの実施形態の処理900を概念的に示す。処理900は、ゲートウェイ制御器を含むゲートウェイDCNをインスタンス化する際にゲートウェイ制御器により実行される。
示されるように、処理900は、管理プレーン証明書及びIPアドレスを識別する(905において)ことにより開始する。いくつかの実施形態において、管理プレーン証明書は、特定の管理プレーンインスタンス又はインスタンスのクラスタに対するゲートウェイDCNのインスタンス化と共に提供される。いくつかの実施形態において、当該情報はゲートウェイDCNに提供される(例えば、ゲートウェイ制御器がアクセスできる構成ファイルにおいて)。また、処理は、管理プレーンとのセキュアな通信チャネルに使用される共有シークレットを生成する(910において)。いくつかの実施形態は、管理者又はLCMにより入力されるコマンドラインインタフェース(CLI)コマンドに基づいて、この共有シークレットを生成する。
次に、共有シークレット及び管理プレーンのIPアドレスを使用して、処理900は管理プレーンに接続し(915において)、管理プレーンの真正性を検証する(すなわち、認可されている管理プレーンアプリケーションに接続したことを確認する)。いくつかの実施形態において、管理プレーンアプリケーションは自身の証明書(又は証明書から生成されたハッシュ等の値)を提供し、ゲートウェイは証明書が一致することを検証する。また、処理は、自身の証明書を管理プレーンに登録する(920において)。いくつかの実施形態において、この証明書は管理プレーンにより同様に検証される。この時点で、ゲートウェイは管理プレーンクラスタに接続しているが、中央制御プレーンに接続していないため、構成規則を受信できない。
次に、処理900は、設定された管理プレーンとの通信チャネルを介して管理プレーンから中央制御プレーン証明書を受信する(925において)。中央制御プレーン証明書を使用して、処理は中央制御プレーンとのチャネルを有効にする(930において)。管理プレーンは中央制御プレーンにゲートウェイ証明書を提供し、中央制御プレーンはゲートウェイから受信した証明書が当該証明書と一致するかを検証する。同様に、ゲートウェイ制御器は、中央制御プレーンから受信した証明書が管理プレーンから受信した証明書と一致するかを検証する。このチャネル設定により、中央制御プレーンがゲートウェイ制御器に配布する構成データを判定すると、ゲートウェイ制御器は中央制御プレーンから構成データを受信することを開始できる。
ゲートウェイが管理プレーン及び中央制御プレーンと共に搭載されると、VPCのDCN内のエージェントも同様に搭載できる。しかし、プライベートデータセンタ内のゲートウェイ又はローカル制御器と異なり、これらのエンティティはゲートウェイ制御器がこれらの論理ポートの全てに対する制御器であると見なすため、これらのローカルエージェントはプライベートデータセンタで動作するMP/CCPクラスタと通信しない。従って、これらのエージェントはゲートウェイ制御器に対してのみ自身を検証する。
図10は、パブリッククラウドVPC内のDCNで実行するローカル制御エージェントが当該VPCに対するゲートウェイ制御器に自身を認定させるために実行するいくつかの実施形態の処理1000を概念的に示す。示されるように、処理1000は、ゲートウェイ名及び証明書を識別する(1005において)ことにより開始する。いくつかの実施形態において、ゲートウェイ名は、制御エージェントに対する構成ファイル内のURLとして提供される(例えば、nsx‐gw.aws.com)。いくつかの実施形態において、この構成ファイルは、インタフェース及びそれらの種類(例えば、オーバーレイ又は非オーバーレイ)のリストを更に含む。処理は、ゲートウェイ名に基づいてゲートウェイIPアドレスを分析する(1010において)。例えばいくつかの実施形態は、データセンタ内のDNSサーバを使用して、ゲートウェイ名をVPC内でのIPアドレスに分析する。
次に、処理1000は、ゲートウェイ制御器への制御チャネルを開始する(1015において)。当該制御チャネルを介して、処理はゲートウェイへエージェント証明書を送信し(1020において)、ゲートウェイからゲートウェイ証明書を受信する。いくつかの実施形態において、ゲートウェイは、各エージェントの証明書がゲートウェイに事前登録されていることを必要とせずに、初回使用時にエージェント証明書を信頼することを認可される。しかし、エージェントにおける処理1000は、ゲートウェイから受信した証明書を検証し(1025において)、有効なゲートウェイ制御器に接続したことを確認する。
上記の処理は、ネットワーク制御システムを介して構成データを受信するためにパブリックデータセンタ内の種々のネットワーク制御システムエンティティ(すなわち、ゲートウェイ制御器及び制御エージェント)を認定することに関する。更に、これらの処理は、制御器が動作するVMが既に存在すると仮定する。場合によっては、ユーザ(例えば、非管理者ユーザ)は、パブリックデータセンタVPC内に新規のワークロードVMを作成し、VM上のMFEが正しい構成規則セットを提供されることを保証する必要がある。これはいつでも発生する可能性があり、従って、理想的には、その時点でネットワーク管理者による作業又は認可を必要としないようにする必要がある。そのため、いくつかの実施形態において、ネットワーク制御システムは、これらの新規のワークロードVMを自動的に提供するように構成される。
図11は、新規のワークロードDCN(本例では、VM)が既存の被管理VPC内に作成される場合のいくつかの実施形態のネットワーク制御システム1100におけるデータの流れを概念的に示す。示されるように、図11は、VPC内のゲートウェイVM1100及び(新規の)ワークロードVM1105と、VPC外のパブリッククラウドデータリポジトリ1110(例えば、パブリッククラウドを管理するためにパブリッククラウド管理者により使用される計算管理システム)とを含む。更に、図11は、ネットワーク制御システムの管理プレーン1115及び中央制御プレーン1120を含み、これらは異なるVPC、プライベートデータセンタ等に位置してもよい。パブリッククラウドマネージャ1125及びゲートウェイ制御器1130がゲートウェイVM1100の構成要素として示されるが、いくつかの実施形態のゲートウェイVMは、図7を参照して上述した他の機能(例えば、ゲートウェイデータパス、DNEマネージャ等)を更に含んでもよい。
VMを起動する前に、ユーザは、(i)ゲートウェイIPアドレス及びトークン/証明書(いくつかの実施形態では、エージェント構成ファイル内に事前に構成されてもよい)、(ii)ワークロードが接続することになる論理スイッチ及び/又はワークロードが属することになるセキュリティグループに対するトークン、並びに(iii)インスタンスにインストールする制御エージェントパッケージのうちのいくつか又は全てを管理者から受け取る。VMを設定する場合、ユーザはVMがゲートウェイIP及び証明書を有することを確認する。それらは、構成ファイル及びエージェント設定において(図10を参照して上述したように)又はパブリッククラウドプロバイダのAPIを使用して提供され得る。また、ユーザは、論理スイッチ及び/又はセキュリティグループに対するトークンをインスタンスのラベルとして追加する。いくつかの実施形態において、ユーザがクラウドプロバイダユーザインタフェースを介してインスタンスを作成する場合、インタフェースは、VMインスタンスに関するデータとしてパブリッククラウドデータリポジトリ1110に格納されているタグをVMに追加する機能を含む。例えばタグは、VMがセキュリティグループSG1に属し且つ論理スイッチLS1に接続する必要があることを示すために、「token‐ls1」及び「token‐sg1」というラベルが付けられてもよい。これらのタグは、何らかのアウトオブバンド機構を介して(例えば、口頭で、電子メールを介して又はメッセージ送信等で)ネットワーク制御システム管理者からユーザに提供されてもよい。
この時点で、VMデータはパブリッククラウドデータリポジトリ1110に格納される。当該データは、VM1105が特定のVPC(すなわち、ゲートウェイVM1100のVPC)内でインスタンス化されることを示し、ユーザにより入力された論理スイッチ及びセキュリティグループタグを含むVMに関する他のデータを更に含んでもよい。パブリッククラウドリポジトリはタグとこれらのエンティティとを関連付けないが、VMに添付されたものとしてこれらのタグを格納する。丸囲み文字1で示すように、PCM1125は、この新規のVMに関する情報をパブリッククラウドデータリポジトリ1110から検索する。この情報は、新規のVMの存在と、そのクラウドプロバイダ識別子、それが関連付けられるVPC等のクラウドプロバイダに関連する種々の属性と、地域及び/又はユーザの情報を含む。いくつかの実施形態において、PCM1125は、ポーリング機構又はパブリッククラウドリポジトリ1110との通知チャネルを使用して、新規のインスタンスがVPC内に作成されたと判定する。
新規のVMがVPC内に作成されたという判定に応答して、PCM1125はいくつかの動作を行う。丸囲み文字2で示すように、PCMは、管理プレーン1115のインベントリに新規のVMを追加し(例えば、新規のVMオブジェクトを作成するためのAPIコールを介して)、VMに対する管理プレーン内に作成されたオブジェクトにVMの種々のパブリッククラウドプロバイダ属性(VM識別子、VPC識別子、インタフェースID等)の全てをタグとして追加する。これにより、ネットワーク管理者はVM及びその属性を管理プレーンインベントリで閲覧できる。
また、PCM1125は、クラウドプロバイダAPIを使用して論理スイッチ及び/又はセキュリティグループのタグを読み出す。PCM1125は論理スイッチタグを使用して、管理プレーンにおいて新規のポートを作成する論理スイッチを判定する(例えば、管理プレーンAPIを介して)。丸囲み文字3で示すように、PCM1125は新規のポートを作成し、VMのインタフェースを当該論理ポートに接続する(例えば、クラウドプロバイダからのインタフェース識別子を使用して)。更にPCMは、インタフェースのIPアドレス及びMACアドレスを読み出し、これらを新規に作成された論理ポート上のMAC/IPバインディングとして構成する。また、いくつかの実施形態は、要望に応じて、論理ポートに対してDFW規則を設定できるように、何らかの必要な特徴を有効にする。更に、丸囲み文字3で更に示すように、PCM1125はセキュリティグループタグに基づいて新規のVM1105のセキュリティグループを識別し、管理プレーン1115を介して論理ポートを当該セキュリティグループに追加する。
VM1105が最初に電源投入されると(エージェント1135が既にインストールされていると仮定する)、当該エージェントはゲートウェイIPを読み出し、ゲートウェイとの接続を確立する(例えば、上述した処理1000を介して)。接続が確立されると、丸囲み文字4Aで示すように、エージェント1135はゲートウェイに接続要求を送信する。これは、VMのインタフェースを論理ネットワークに接続することを要求するが、エージェントはインタフェースが接続することになる論理スイッチに関する情報をまだ有さない場合がある。いくつかの実施形態において、接続要求はクラウドプロバイダインタフェース識別子を使用して、論理スイッチに接続されるべきインタフェースを指定する。丸囲み文字4Bで示すように、ゲートウェイ制御器1130は当該要求を中央制御プレーン1120に転送する。
CCPは、インタフェースに対する論理ポートの作成に関する情報をMPから受信している。要求内の識別子は操作2でPCMにより提供されたクラウドプロバイダ識別子と一致する必要があるため、CCPは要求内で使用される識別子に基づいて正確な論理ポートを識別できる。CCPはゲートウェイ制御器1130が論理ポートの位置であると見なし、丸囲み文字5Aで示すように、論理ポート情報及び何らかの関連するポリシー規則をゲートウェイ制御器1130に提供する。丸囲み文字5Bで示すように、ゲートウェイ制御器は当該データをエージェント1135に渡し、それにより、エージェント1135は、ワークロードVM1105上で動作するMFEに対する構成データを生成し、ワークロードアプリケーションとの間で送受信されるパケットの処理を開始することができる。ゲートウェイ制御器も当該データをキャッシュするため、VM1105が再起動した場合、以降の接続要求を中央制御プレーンに転送する必要はない。更に、論理ポート及びそのポリシー規則に関する情報は、必要に応じてゲートウェイ制御器1130によりVPC内の他のエージェントへ送信される。また、ゲートウェイ制御器1130は、上述したようにVM1105に対するオーバーレイ設定を実行し、オーバーレイ情報をエージェント1135に配布し(丸囲み文字6で示すように)、VPC内の他のVM上のエージェントにも配布する。
このワークフローは、ユーザがDCNを手動で作成する場合を説明するが、自動スケーリングされたDCNの場合も同様の処理が行われる。いくつかの実施形態において、管理者は、使用を監視される特定のDCN(例えば、ウェブサーバ等の同一又は同様のワークロードのグループ)を設定でき(クラウドプロバイダインタフェースを介して)、DCNが過負荷になった場合にクラウドプロバイダ管理システムに更なるインスタンスを自動的に作成させることができる。この場合、新規のDCNはクラウドプロバイダシステムによりパブリッククラウドデータリポジトリ1110に自動的に追加され、図に示すようにデータフローが行われる。更に、いくつかの実施形態のPCM1125は、クラウドプロバイダデータリポジトリ1110を定期的にポーリングし、インタフェースの作成/削除/修正を含むVPC内の既存のDCNに対する変更(例えば、IPアドレス及び/又はMACアドレスの変更)及びDCNのタグの変更を識別する。これらの変更が生じた場合、PCM1125はそれらを管理プレーン1115に伝搬する。
いくつかの実施形態において、ユーザは、ネットワーク制御システムに転送を実行させるのではなく、マイクロセグメンテーション及び/又は分散型ファイアウォール規則の施行のみを実行させたい場合がある。この非オーバーレイモードも以下の第V.A節で更に詳細に説明する。いくつかのそのような実施形態において、管理プレーンは、同じ論理スイッチに対して作成された全ての添付ファイルを用いてフラット論理スイッチ(実際はスイッチングを全く含まない)を作成する。この場合、クラウドプロバイダインタフェースを介して新規のDCNを指定する際に、ユーザは特定の論理スイッチタグではなくネットワークのデフォルトタグを入力する。その後、ユーザはサブネット(すなわち、VPC)内に新規のDCNを作成し、クラウドプロバイダはインスタンスに対するIPアドレスを提供する。新規のDCNがインスタンス化されると、PCMはVPC内の新規のDCNを識別し、新規のDCNがこのフラット論理スイッチに接続できるようにデータをMPに提供する。その後、ネットワーク制御システムは、必要に応じて、新規のDCN上で動作するMFEにセキュリティ規則をプッシュダウンできる。
IV. 論理トポロジの物理的実現
上述したように、論理ネットワークを1つ以上のパブリックデータセンタに拡張することにより、論理トポロジがこれらのデータセンタにまたがり拡張されてもよい。いくつかの実施形態は、所定の論理スイッチに接続されるVMを1つのVPC(又はプライベートデータセンタ)に限定し、他の実施形態は、単一の論理スイッチでも複数のVPC又は複数のデータセンタにまたがることを可能にする。
図12は、管理者が管理プレーンに論理トポロジを入力してもよい場合のいくつかの実施形態の論理トポロジ1200を概念的に示す。示されるように、論理トポロジ1200は、論理ルータ1205と2つの論理スイッチ1210及び1215とを含む。4つの仮想マシンが論理スイッチ1210に接続され、論理ルータは外部ネットワークへのアップリンクポートを含む。この場合、1層の論理ルータのみが論理ネットワーク内に示されるが、いくつかの実施形態は複数層の論理ルータを含むこともできる。更に、いくつかの実施形態の管理プレーンは、論理ルータ1205に対して複数の論理ルーティング構成要素(例えば、分散型ルータ及び1つ以上の集中型サービスルータ)を定義してもよい。複数層の論理ルータ及び論理ルータに対する複数のルーティング構成要素の作成は、本明細書に参考として取り入れられる米国特許出願公開第2016/0226754号明細書に更に詳細に記載される。
いくつかの実施形態において、論理ルータに接続された論理スイッチ1210及び1215の各々にサブネットが割り当てられ、従って、特定の論理スイッチに接続するように作成されたワークロードVMに適切なサブネットにおけるIPアドレスを割り当てる必要がある。しかし、以下の第V.B節で更に詳細に説明するように、いくつかの実施形態において、クラウドプロバイダネットワークに対するIPアドレスはVM上で動作するMFEに対して作成されたトンネルエンドポイントのIPアドレスであるため、クラウドプロバイダに関するVMのIPアドレスは当該VMにマッピングされる論理ポートのIPアドレスと異なる。この場合、論理スイッチ1210はサブネット192.168.1.0/24を割り当てられる。更に、4つのVMが論理スイッチ1210に接続されると示される。
図13は、単一のパブリッククラウドプロバイダの単一のVPC1300内に実現される場合の論理スイッチ1210に接続された4つのVM1305~1320の一例を示す。本例において、論理スイッチ1210に接続された全てのVMは同じVPC内でインスタンス化され、当該論理スイッチに接続されたVMのみがVPC内でインスタンス化される。このVPC1300にはサブネット10.1.0.0/16が割り当てられる。これは、管理者がパブリッククラウドでVPCを構成した方法に応じて、パブリックサブネットであってもよく、プライベートサブネットであってもよい。本例(及び本節の他の例)において、MFEは全てオーバーレイモードで動作しているため、VM IPアドレスはワークロードアプリケーションIPアドレス(すなわち、論理スイッチポートに関連付けられたIPアドレス)と異なる。
示されるように、各VMには、192.168.1.0/24サブネットにおける異なるワークロードIP(192.168.1.1、192.168.1.2、192.168.1.3及び192.168.1.4)が割り当てられる。ワークロードアプリケーションがパケットを送信する場合、このIPアドレスが当該パケットのヘッダで使用される送信元IPになる。しかし、これらのVMで動作するMFEは、10.1.0.0/16サブネットにおける異なるIPアドレス(10.1.0.1、10.1.0.2、10.1.0.3及び10.1.0.4)を有するVTEPを有する。従って、VPC内の他の宛先へ送信するためには、VMから送信されるパケットは当該VTEP IPアドレスを送信元IPアドレスとして使用してカプセル化される(論理処理が送信元VM内のMFEにより実行された後に)。
図13は、これら4つのMFEとVPC内のゲートウェイ1325との間のトンネルを更に示す。これらのトンネルは、パブリッククラウドプロバイダの下層ネットワーク(本明細書中、「アンダーレイ」と呼ぶ)を通過する。更に、簡潔にするため図示しないが、VM1305~1320上で動作するMFEの各対の間にトンネルが作成される(アンダーレイネットワークを介して)。
ゲートウェイは、オンプレミスプライベートデータセンタ1330内の宛先にパケットを送信する(及び当該宛先からパケットを受信する)こともできる。これらのパケットを送信するためにゲートウェイ1325は自身のVTEP IP(10.1.0.5)を使用してパケットをカプセル化するため、宛先は受信パケットを論理ネットワークパケットとして識別する。いくつかの実施形態において、VPC1300内のゲートウェイ1325とプライベートデータセンタ1330内の宛先(例えば、論理スイッチ1215に接続されたVM)との間のトラフィックをセキュリティ保護するために、パケットはVPNトンネル1335を介して送信される。本例では、外部ネットワークへのゲートウェイの接続を図示しない。これについては、集中型及び分散型のネットワークアドレス変換及び他のサービスに関する以下の節で更に詳細に説明する。
図14は、論理スイッチ1210が単一のデータセンタ内の(すなわち、同じクラウドプロバイダの)2つの別個のVPC1400及び1405にまたがる一例を示す。この場合、4つのVM1410~1425は、単一のサブネット上のワークロードアプリケーションに対して同じIPアドレスを有する(192.168.1.0/24)。しかし、2つのVPCは異なるサブネットを有するため(第1のVPCは10.1.0.0/16が割り当てられ、第2のVPCは10.2.0.0/16が割り当てられる)、MFEのVTEPの全てが同じサブネット上に存在するわけではない。従って、第1のVPC1400内の2つのVM1410及び1415上のVTEPはIPアドレス10.1.0.1及び10.1.0.2が割り当てられ、第2のVPC1405内の2つのVM1420及び1425上のVTEPはIPアドレス10.2.0.1及び10.2.0.2が割り当てられる。
ゲートウェイ1435及び1440も各VPC内でインスタンス化され、各々が各自のVPCのサブネット上のVTEPを有する。VPCがピア接続されていない状況では、2つのゲートウェイ間で送信されるパケットはVPN接続を使用して送信される(すなわち、VPCは別個のデータセンタに位置してもよい)。しかし、一部のクラウドプロバイダではVPCのピア接続が可能であり、その場合、一方のVPCの1つのエンドポイントから別のピア接続VPCの第2のエンドポイントへパケットを直接送信できる。従って、2つのVPC1400及び1405がピア接続される場合、VM1410及び1415の一方からVM1420及び1425の一方へ送信されるパケットはVPN1430を介して送信される必要はない。実際、いくつかの実施形態は、これらのパケットがゲートウェイ1435及び1440を介して送信されることさえ必要せず、プロバイダネットワークを介して一方のVMから他方のVMに直接トンネリングすることができる。しかし、VPC1400及び1405がピア接続されない場合、そのようなVPC間パケットは、VMからVPC内トンネルを介してゲートウェイへ送信され、第1のゲートウェイからVPNを介して宛先VPC内の第2のゲートウェイへ送信され、第2のゲートウェイから宛先VMへ送信される必要がある。
プライベートデータセンタ1445に接続する(例えば、第2の論理スイッチ1215に接続されたVMに到達するために)場合、ゲートウェイはVPN1430を使用する。このVPN1430は、プライベートデータセンタと1つ以上のクラウドプロバイダにおける1つ以上のVPCとをリンクするために使用される種々の可能なVPN構成を表す。例えば、いくつかの実施形態は各宛先との間にフルメッシュのVPNトンネルを使用するが、他の実施形態はハブアンドスポークVPN又はそれら2つの組み合わせを使用する。更に、異なる実施形態は、パブリッククラウドプロバイダ又はネットワーク制御システムにより提供されるVPN、あるいはそれらの組み合わせ(例えば、VPNのメッシュを使用する場合)を使用してもよい。
図15は、図14と同様の構成を示すが、VM1510~1525は2つの全く異なるクラウドプロバイダのデータセンタに位置するVPC1500及び1505にまたがる論理スイッチ1210に接続される。この状況は、一般に2つの異なるデータセンタ(特に、異なるクラウドプロバイダの2つの異なるデータセンタ)間でVPCをピア接続することができないためデータセンタ内のワークロード間のあらゆる通信がVPN1530を介して送信される点において、図14と異なる。図14で説明したように、いくつかの実施形態は、マルチパブリッククラウド構成においてハブアンドスポークVPNを使用してもよく、他の実施形態は、(i)各パブリッククラウドと他のパブリッククラウドとの接続及び(ii)各パブリッククラウドとプライベートデータセンタとの接続に対して別個のVPN接続を使用する。
これらの図に示される例に加えて、他の構成も可能であることが理解されるべきである。例えば単一の論理スイッチは、プライベートデータセンタと1つ以上のパブリックデータセンタ間にまたがることができる。図13~図15のいずれにおいても、論理スイッチに接続された1つ以上のVMはパブリッククラウドVPCのうちの1つではなくオンプレミスデータセンタにおいて実現可能である。
V. ワークロードVMにおけるMFEの構成
上述したように、ネットワーク制御システムがパブリッククラウド内のワークロードDCNとの間で送受信されるデータトラフィックに対するパケット処理規則を構成できるようにするために、いくつかの実施形態は、被管理転送要素とMFEを構成するローカル転送エージェントとをワークロードDCNにインストールする。このMFEはDCNのネットワークインタフェースに接続されるため、これらのDCNで実行するワークロードアプリケーションとの間で送受信される全てのパケットは、ローカル制御エージェントによりインストールされた構成データに従ってMFEを通過する(且つMFEにより処理される)。
本発明の異なる実施形態において、これらのMFEは異なる方法で構成されてもよい。例えばいくつかの実施形態は、ワークロードアプリケーションのIPアドレスがDCNのネットワークインタフェースのIPアドレスと同じである非オーバーレイモードでMFEを構成する。この場合、MFEはパケット処理を実行せず、代わりに、マイクロセグメンテーション及び/又は分散型ファイアウォール規則処理等のネットワークセキュリティ処理を実行するように構成される。他の実施形態において、MFEは、ワークロードアプリケーションが接続するインタフェースがVTEPに使用されるDCNの外部インタフェースと異なるIPアドレスを有するように構成される。この場合、MFEは、何らかのネットワークセキュリティ又は他の処理に加えて、論理ネットワーク構成に従ってパケット転送を実行する。最後に、管理者は、既存のワークロードに対して同じIPアドレスを保持したいがパケット処理、トンネリング等のために論理ネットワークを利用したい場合がある。この第3の例では、MFEはワークロードアプリケーションとは別のDCNの名前空間に構成される。これにより、ワークロードアプリケーションは、既存のIPアドレスを有するインタフェースに接続した後、vethペアを使用して、VTEPに対して同じIPアドレスを使用する別の名前空間内のMFEに当該インタフェースを接続することができる。
A. 非オーバーレイモードのMFE
図16は、非オーバーレイモードで構成された被管理転送要素1600を有するVM1605を概念的に示す。本例において、MFEはOpen vSwitch(OVS)インスタンスである。これら例の全てにおいて、MFEは2つのブリッジを含むように構成され、すなわち、統合ブリッジ(アプリケーションワークロードがVMのネットワークスタックを介して接続する)とVMの仮想ネットワークインタフェース制御器(VNIC)に接続する物理インタフェース(PIF)ブリッジとを含むように構成される。
図16に示すように、VM1605上で動作するワークロードアプリケーション1610(例えば、ウェブサーバ、アプリケーションサーバ等)は、内部ポートを介してMFEの統合ブリッジ1615に接続する。この内部ポートはVMのネットワークスタックに関連付けられ、従って、パブリッククラウドプロバイダにより提供されるVMのIPアドレス(例えば、図13の例では10.1.0.0/24のIPアドレス)を有する。いくつかの実施形態において、統合ブリッジ1615は転送及びカプセル化を実行しない。その代わりに、統合ブリッジ1615は、何らかのセキュリティ処理を実行した後に(パケットが破棄又は拒否されないと仮定する)、パッチポートを介して全てのパケットをPIFブリッジ1620に自動的に転送する。
また、統合ブリッジは、何らかのネットワークセキュリティ又は他の非転送ポリシーを実現するフローエントリを使用して、アプリケーション1610から受信した(又はPIFブリッジから受信してアプリケーション1610へ送信する)パケットを処理する。例えば統合ブリッジは、VM1605が接続する論理ポートに適用されるDFW規則を実現する。いくつかの実施形態において、これらの規則は、送信元及び/又は宛先MACアドレスに関して指定されてもよく、これらの指定されたアドレスとの間で及び/又は特定の条件下(例えば、接続開始)で送信されるパケットを許可、破棄、拒否等してもよい。更に、異なる実施形態は、ロギング、分散型暗号化規則(発信パケットの暗号化及び着信パケットの復号化の双方)、並びに第3者サービスアプライアンス(例えば、ミドルボックスアプライアンス)へのトンネリングの組み合わせを実現してもよい。
図17は、非オーバーレイモードで動作するMFEによるVPCを介するパケット処理の一例を示し、詳細には、同じVPC上の別のワークロードアプリケーション1710へパケットを送信する第1のワークロードアプリケーション1705を示す。図17は、パブリックデータセンタ内の同じVPC内でVMを動作する2つのホストマシン1715及び1720を含む。第1のVM1725は第1のホストマシン1715上で動作し、ワークロードアプリケーション1705及びMFE1735は第1のVM内で実行する。第2のVM1730は第2のホストマシン1720上で動作し、ワークロードアプリケーション1710及びMFE1740は第2のVM内で実行する。この場合、双方のMFEが非オーバーレイモードで動作する。更に、ホストマシン1715及び1720はそれぞれ、各々のVMが接続する各々のパブリッククラウド転送要素1745及び1750を含む。これらのパブリッククラウド転送要素は、ソフトウェア仮想スイッチであってもよい(実際は、MFE1735及び1740と同じ種類の仮想スイッチであり得る)。しかし、MFE1735及び1740と異なり、これらの転送要素はパブリッククラウドプロバイダにより制御されるため、ネットワーク制御システムはこれらの転送要素にアクセスできない。
示されるように、第1のワークロードアプリケーション1705は、VM1725上のMFE1735へパケット1755を送信する。パケット1755は、送信元IPアドレス及び宛先IPアドレスと、種々のヘッダ(例えば、TCP/UDP、IP、イーサネット等)と、ペイロードとを含む。本明細書中で使用される場合、パケットは、ネットワークを介して送信される特定のフォーマットのビットの集合を示す。本明細書において、用語「パケット」は、イーサネットフレーム、IPパケット、TCPセグメント、UDPデータグラム等のネットワークを介して送信されてもよい種々のフォーマットのビットの集合を示すために使用されてもよいことが理解されるべきである。以下の例はパケットを示すが、本発明は何らかの特定のフォーマット又は種類のデータメッセージに限定されるべきではないことが理解されるべきである。
パケット1755を受信すると、MFE1735は、それがローカル制御エージェント(不図示)により構成される際に用いられた何らかの適用可能なセキュリティポリシー(例えば、ファイアウォール規則)又は他の非転送ポリシーを適用する。パケットが破棄されないと仮定して、MFE1735は、パブリッククラウド転送要素1745に接続するVMインタフェースからパケット1755を出力する。パブリッククラウドネットワークがホストマシン間のトンネリングを使用すると仮定して、パブリッククラウド転送要素1745は、独自のアンダーレイカプセル化を用いてパケットをカプセル化し、このカプセル化されたパケット1760を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、第1のホストマシン1715のインタフェースのIPを送信元アドレスとして使用し、宛先ホストマシン1720のインタフェースのIPを宛先アドレスとして使用する。
その後、パケット1760はホストマシン1720により受信され、パブリッククラウド転送要素1750によりカプセル解除される。転送要素1750は宛先アドレスに基づいてワークロードVM1730のインタフェースにパケット1755を送信し、MFE1740は当該パケットを処理する。MFE1740はネットワークセキュリティ処理を実行し、そしてワークロードアプリケーション1710にパケットを出力する。いくつかの実施形態において、送信元VM及びそのMFEが攻撃者により不正アクセスされる場合、送信元及び宛先の双方におけるMFEがネットワークセキュリティを実行する。
ネットワーク制御システムは転送を提供しないため、いくつかの実施形態において、論理スイッチは2つ以上のVPCにまたがることができない(L2ドメインは下層VPCサブネットに制限される)。更に、L3転送は、ピア接続又はVPNを使用するVPC内又はVPC間のルーティングに限定される。しかし、非オーバーレイモードを使用すると、アプリケーションはクラウドプロバイダからのIPアドレスで動作し続けることができるため、ストレージ又は負荷分散サービス等にクラウドプロバイダにより提供される他のサービスとのシームレスな統合が容易になる。ノース/サウストラフィックは、ゲートウェイデータパスをデフォルトゲートウェイとして使用する。この場合、クラウドプロバイダにより提供され且つゲートウェイのノースバウンドインタフェースに接続される別個のルーティングテーブルは、クラウドプロバイダのインターネットゲートウェイをデフォルトゲートウェイとして指す。
B. オーバーレイモードのMFE
図18は、(i)アプリケーションにより使用される内部ポートと(ii)同じVPC上の他のVMへ送信されるパケットをカプセル化するVTEPとに対して異なるIPアドレスを有するオーバーレイモードで構成された被管理転送要素1800を有するVM1805を概念的に示す。図16と同様に、MFE1800は、統合ブリッジ1815及びPIFブリッジ1820を用いて構成されたOVSインスタンスである。VM1805上で動作するワークロードアプリケーション1810(例えば、ウェブサーバ、アプリケーションサーバ等)は、内部ポートを介してMFEの統合ブリッジ1815に接続する。しかし、この場合、内部ポートは、ワークロードが接続される論理ポートに対応するIPアドレスに対するネットワークスタックに関連付けられ、従って、論理ポートが関連付けられる論理スイッチのサブネットに属する(例えば、図13の192.168.1.0/24アドレス)。
この場合、統合ブリッジ1815は、ワークロードアプリケーション1810との間で送受信されるパケットに対して論理L2及び/又はL3処理を実行する。これは、論理トポロジ内の各論理転送要素に対する入力/出力コンテキストマッピング及び入力/出力ACLと論理スイッチング及び/又はルーティングとを含んでもよい。更に、いくつかの実施形態において、統合ブリッジは、非オーバーレイMFEの場合と同様に、分散型ファイアウォール、分散型暗号化、第3者サービスアプライアンスへのトンネリング等を実行する。
MFE1600と異なり、MFE1800は、2つのブリッジ間でパケットを送信するためのパッチポートを用いて構成されない。その代わりに、統合ブリッジ1815は、PIFブリッジ1820上のVTEPに接続するオーバーレイポートを含む(例えば、クラウドプロバイダIPアドレスに対する第2のネットワークスタックを介して)。このVTEPは、統合ブリッジ1815がVM1805から送信されるパケットをカプセル化するために使用し且つゲートウェイデータパスを含む同じVPC内の他のMFEがワークロードアプリケーションに対するパケットをMFE1800にトンネリングするために使用するクラウドプロバイダIPアドレス(例えば、図13の10.1.0.0/16アドレス)を有する。VTEPのIPアドレスへ送信される(クラウドプロバイダIPアドレスを有するVM1805のVNICを介して)これらのパケットは、ワークロードアプリケーション1810に出力される前に統合ブリッジ1815によりカプセル解除される。
図19は、オーバーレイモードで動作するMFEによるVPCを介するパケット処理の一例を示し、詳細には、同じVPC上の別のワークロードアプリケーション1910へパケットを送信する第1のワークロードアプリケーション1905を示す。図19は、パブリックデータセンタ内の同じVPC内でVMを動作させる2つのホストマシン1915及び1920を含む。第1のVM1925は第1のホストマシン1915上で動作し、ワークロードアプリケーション1905及びMFE1935は第1のVM内で実行する。第2のVM1930は第2のホストマシン1920上で動作し、ワークロードアプリケーション1910及びMFE1940は第2のVM内で実行する。この場合、双方のMFEがオーバーレイモードで動作し、内部IPは論理スイッチポートに関連付けられ、VTEP IPはクラウドプロバイダのVPCサブネットに関連付けられる。更に、ホストマシン1915及び1920はそれぞれ、各々のVMが接続する各々のパブリッククラウド転送要素1945及び1950を含む。これらのパブリッククラウド転送要素は、ソフトウェア仮想スイッチであってもよい(実際は、MFE1935及び1940と同じ種類の仮想スイッチであり得る)。しかし、MFE1935及び1940と異なり、これらの転送要素はパブリッククラウドプロバイダにより制御されるため、ネットワーク制御システムはこれらの転送要素にアクセスできない。
示されるように、第1のワークロードアプリケーション1905は、VM1925上のMFE1935へパケット1955を送信する。パケット1955は、送信元IPアドレス及び宛先IPアドレスと、種々のヘッダ(例えば、TCP/UDP、IP、イーサネット等)と、ペイロードとを含む。この場合、送信元IPアドレスはワークロードアプリケーションの内部IPアドレスである(VMインタフェースのIPアドレスではない)。
パケット1955を受信すると、MFE1935は、ローカル制御エージェントによる構成に従って、何らかのアプリケーションセキュリティポリシー(例えば、ファイアウォール規則)に加えて論理転送を実行する。パケットの宛先MACアドレスが送信側ワークロードと同じ論理スイッチ上にある場合、トポロジを介する処理は当該論理スイッチに対するL2処理のみを含む。宛先が異なる論理スイッチ上にある場合、複数のルーティング構成要素が関係する場合は、論理処理は、送信元論理スイッチに対する処理と、少なくとも1つの分散型論理ルータに対する処理と、宛先MACアドレスが属する論理スイッチに対する処理とを含む(場合によっては、論理ルーティング構成要素間の何らかの遷移論理スイッチに加えて)。
パケットが破棄されないと仮定して、MFE1935は、パケットを宛先にトンネリングするようにパケット1955をカプセル化し(例えば、GENEVE、STT等を使用して)、このカプセル化パケット1960をパブリッククラウド転送要素1945に接続するVMインタフェースから出力する。パブリッククラウドネットワークがホストマシン間のトンネリングを使用する場合、パブリッククラウド転送要素1945は、独自のアンダーレイカプセル化を用いてパケットの2回目のカプセル化を行い、この二重カプセル化パケット1965を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、第1のホストマシン1915のインタフェースのIPアドレスを送信元アドレスとして使用し、宛先ホストマシン1920のインタフェースのIPアドレスを宛先アドレスとして使用する。
アンダーレイ(クラウドプロバイダ)ネットワークを通過した後、パケット1965はホストマシン1920により受信され、パブリッククラウド転送要素1950は外側(アンダーレイ)カプセル化を除去する。転送要素1950は、宛先VTEPアドレスに基づいて、単カプセル化パケット1960をワークロードVM1930のインタフェースへ送信し、MFE1940は当該パケットを処理する。MFE1940は、オーバーレイカプセル化を除去し、何らかの更なる論理処理及びネットワークセキュリティ処理を実行し、内部パケット1955をワークロードアプリケーション1910に出力する。
また、ワークロードアプリケーションは、論理ネットワーク上であるがVPCの外側(例えば、同じデータセンタの異なるVPC、同じ又は異なるクラウドプロバイダの異なるパブリックデータセンタ、あるいはテナント自身のプライベートデータセンタ)に位置する宛先へパケットを送信してもよい。いくつかの実施形態において、これらのパケットはVPC内のゲートウェイにトンネリングされ、VPN(又は別のセキュアな方法)を介して別のデータセンタにおける宛先へ送信される。宛先は、同じ論理スイッチ上であるか(上記の第IV節で示した例のように)、あるいは別の論理スイッチ上である(その場合、ゲートウェイは必要に応じて集中型ルータ処理を提供してもよい)ことができる。
図20は、VPC外部の論理ネットワーク宛先へ送信されるパケットに対するオーバーレイモードのMFEによるVPCを介するパケット処理の一例を示す。図20は、パブリックデータセンタ内の同じVPC内でVMを動作させる2つのホストマシン2015及び2020を含む。ワークロードVM2025は第1のホストマシン2015上で動作し、ワークロードアプリケーション2005及びMFE2035(オーバーレイモード)はワークロードVM内で実行する。ゲートウェイVM2030は第2のホストマシン2020上で動作し、ゲートウェイデータパス2010はVM上で実行する(パケット処理に関係しないため、ここでは不図示の制御器、PCM等に加えて)。前述のように、MFE2035はオーバーレイモードで動作し、ワークロードが接続する論理スイッチポートに関連付けられた内部IPアドレスと、クラウドプロバイダのVPCサブネットに関連付けられたVTEP IPアドレスとを用いる。更に、ホストマシン2015及び2020はそれぞれ、各々のVMが接続する各々のパブリッククラウド転送要素2045及び2050を含む。上記の場合と同様に、これらのパブリッククラウド転送要素はソフトウェア仮想スイッチであってもよく、ネットワーク制御システムはこれらにアクセスできない。
示されるように、ワークロードアプリケーション2005は、VM2025上のMFE2035へパケット2040を送信する。前述のパケットと同様に、このパケット2040は、送信元IPアドレス及び宛先IPアドレス(並びに、送信元MACアドレス及び宛先MACアドレス)と、種々のヘッダと、ペイロードとを含む。図19と同様に、送信元IPアドレスはワークロードアプリケーション2005の内部IPアドレスである(VMインタフェースのIPアドレスではない)。パケットの宛先IPアドレスは、VPCの外側(及び同じデータセンタ内のピア接続VPCの外側)に位置する論理ネットワーク宛先に対応する。これは、プライベートデータセンタ、(同じ又は異なるプロバイダからの)異なるパブリックデータセンタ等に位置するDCNであり得る。宛先がワークロードアプリケーションと同じ論理スイッチ上にある場合、パケット2040内の宛先MACアドレスも当該宛先のアドレスである。一方、宛先が異なる論理スイッチ上にある場合、宛先MACはワークロードの論理スイッチが接続する論理ルータポートのアドレスである。
パケット2040を受信すると、MFE2035は、ローカル制御エージェントによる構成に従って、何らかのアプリケーションセキュリティポリシー(例えば、ファイアウォール規則)に加えて論理転送を実行する。パケットの宛先MACアドレスが送信側ワークロードと同じ論理スイッチ上にある場合、トポロジを介する処理は当該論理スイッチに対する論理スイッチ処理のみを含む。宛先が異なる論理スイッチ上にある場合、論理処理は、(ワークロードアプリケーション2005が)接続する送信元論理スイッチに対する処理と、少なくとも1つの分散型ルータに対する処理と、宛先MACアドレスが属する論理スイッチに対する処理とを含む。いずれの場合も、MFEは宛先論理スイッチポートがゲートウェイVTEPにマッピングされていると識別する(VPCの外部の全ての論理ポートはゲートウェイにマッピングされるため)。
パケットが破棄されないと仮定して(例えば、分散型ファイアウォール規則に基づいて)、MFE2035は、パケットをゲートウェイにトンネリングするようにパケット2040をカプセル化し(例えば、GENEVE、STT等を使用して)、このカプセル化されたパケット2055パブリッククラウド転送要素2045に接続するVMインタフェースからを出力する。示されるように、このカプセル化に対する送信元IPアドレスはMFE2035のVTEPのアドレス(すなわち、VMインタフェースのアドレス)であり、宛先IPアドレスはゲートウェイデータパス2010のVTEPのアドレス(すなわち、トンネルトラフィックに使用されるゲートウェイVMインタフェースのアドレス)である。
パブリッククラウド転送ネットワークがホストマシン間のトンネリングを使用すると仮定して、パブリッククラウド転送要素2045は、独自のアンダーレイカプセル化を用いてパケットの2回目のカプセル化を行い、この二重カプセル化パケット2060を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、ホストマシン2015のインタフェースのIPアドレスを送信元IPアドレスとして使用し、ホストマシン2020のインタフェースのIPアドレスを宛先IPアドレスとして使用する。
アンダーレイ(クラウドプロバイダ)ネットワークを通過した後、パケット2065はホストマシン2020により受信され、パブリッククラウド転送要素2050はアンダーレイカプセル化を除去する。転送要素2050は、オーバーレイカプセル化の宛先IPアドレスに基づいて、トンネリングされるトラフィックに対するゲートウェイVMのインタフェースを介して、まだカプセル化されているパケット2055をゲートウェイVM2030へ送信する。ゲートウェイデータパス2010は、カプセル化を除去し、内部パケット2040の宛先論理ポートを識別し、当該ポートを宛先トンネルエンドポイントにマッピングすることにより、当該パケット2055を処理する。この特定の例において、宛先はオンプレミスMFE(すなわち、テナント自身のプライベートデータセンタ内の)にマッピングされる。いくつかの実施形態はこれをトンネルエンドポイントとして使用するが、他の実施形態はプライベートデータセンタに対するゲートウェイにパケットをトンネリングする。示されるように、新規のカプセル化パケット2065について、送信元IPアドレスはゲートウェイVTEPのアドレス(すなわち、元のカプセル化パケット2055の宛先アドレス)であり、宛先はオンプレミスMFEのVTEPである。更に、パケットが宛先データセンタに到達するためにインターネットを通過する必要がある場合があるため、プライベートデータセンタにおける宛先に到達するためにカプセル化パケット2065はセキュアなVPNトンネルを介して送信される。このVPNトンネルは、いくつかの実施形態ではゲートウェイにおいて適用されてもよく、あるいはパブリッククラウドプロバイダにより提供される別個のVPNゲートウェイにより適用されてもよい。その後、VPNトンネリングパケット2070はデータセンタから送信される。
C. 単一のIPを用いるオーバーレイモードのMFE
場合によっては、データセンタのテナントは、ワークロードのIPアドレスを変更せずに、パブリックデータセンタ内で動作する既存のDCNのセットに自身のネットワーク制御システムを適用させたい場合がある。この要求に応えるために、いくつかの実施形態は、パブリックデータセンタDCN内のMFE及びワークロードアプリケーション(例えば、ウェブサーバ、アプリケーションサーバ等)がDCNの異なる名前空間において動作することを可能にする。これにより、同じIPアドレスに関連付けられた独立したネットワークスタックを2つの名前空間が有することができるようになる(同じ名前空間内で動作する2つのネットワークスタックを同じIPアドレスに関連付けるができない第B節で上述した標準的なオーバーレイモードと異なる)。
図21は、オーバーレイモードで構成されるがVTEPポートと同じIPアドレスを内部ポートに使用する被管理転送要素を有するVM2100を概念的に示す。前述の例と同様に、MFEは、統合ブリッジ2115及びPIFブリッジ2120を用いて構成されたOVSインスタンスである。しかし、この場合、VM2100は、ルート名前空間2105と第2の名前空間2110との双方を含む。MFEブリッジが第2の名前空間内でインスタンス化されるため、第2の名前空間2110をMFE名前空間と呼ぶ。
VM2105上で動作するワークロードアプリケーション2125は名前空間2105内で実行する。VMのユーザがVMにログインする場合、通常はこのように見える(ネットワーク管理者と異なり)。MFE名前空間2110は統合ブリッジ2115及びPIFブリッジ2120を含み、それらは上述したMFE1800の場合と同様に動作する。すなわち、統合ブリッジ2115は、ワークロードアプリケーション2125との間で送受信されるパケットに対して論理L2/L3処理を実行する。これは、論理トポロジ内の各論理転送要素に対する入力/出力ACLと論理スイッチング及び/又はルーティングとを含んでもよい。更に、統合ブリッジ2115は、MFEの他のモードと同様に、分散型ファイアウォール、分散型暗号化、第3者サービスアプライアンスへのトンネリング等を実行する。更に、この場合、2つのブリッジ2115及び2120の間でパケットを送信するように構成されたパッチポートは存在しない。その代わりに、統合ブリッジ2115は、PIFブリッジ2120上のVTEPに接続するオーバーレイポートを含む。
しかし、2つの異なる名前空間を使用することにより、PIFブリッジ上のVTEP及びアプリケーション2125の双方がクラウドプロバイダからの同一のIPアドレス(すなわち、VM2100のVNIC2130に関連付けられたIPアドレス)を使用できる。2つの名前空間の各々において実行する異なるネットワークスタックの双方に同一のクラウドプロバイダIPアドレスを関連付けることができる。これら2つの名前空間2105及び2110は、2つの名前空間の各々に構成されるvethインタフェースを接続するveth(仮想ネットワークインタフェース)ペアにより接続される。
従って、ワークロードアプリケーションが論理ネットワーク宛先(同じVPC内又は異なるVPC/データセンタ内)へパケットを送信する場合、パケット(クラウドプロバイダIPを送信元IPとして有する)はvethペアを介して統合ブリッジ2115へ送信され、統合ブリッジ2115は必要な論理ネットワーク処理をパケットに実行する。また、統合ブリッジ2115は、VPC上の別のVM(ワークロードVM又はゲートウェイVM)へ送信されるパケットをカプセル化する。カプセル化ヘッダ内の送信元IPは内部パケットの送信元IPと同じである。しかし、いくつかの実施形態の論理ネットワークが更なるコンテキスト情報(例えば、統合ブリッジにより実行される論理処理に関する)を搬送するためにカプセル化ヘッダを使用するため、カプセル化が依然として使用される。同様に、ワークロードアプリケーションへ送信されるパケット(VPC内のゲートウェイ又は他のMFEから)は、内部ヘッダ及び外部ヘッダの双方に同じ宛先IPアドレスを有する状態でPIFブリッジ2120において受信される。統合ブリッジは、外側(カプセル化)ヘッダを除去し、何らかの論理コンテキストを識別し、vethペアを介してワークロードアプリケーション(すなわち、ルート名前空間内のネットワークスタック)にパケットを出力する。従って、MFE、パブリッククラウド転送要素、ゲートウェイ等によるパケット処理は、図19及び図20に示す種々の構成要素からの入力及び出力に関して図19及び図20に示すパケット処理と同様である。但し、MFEの内部動作は異なる。
VI. NAT及び他のサービス
上記の第V節において、パケット処理の例は全て、パブリッククラウドVPC内のワークロードDCNから発信されるイースト/ウエストトラフィック(VPC又は異なるデータセンタ内であるが依然として論理ネットワークに接続する別のワークロードへ送信される)に関し、これらのワークロードDCN内で動作するMFEにより実行される様々な種類の処理を中心に説明された。しかし、多くの論理ネットワークは、外部クライアントがアクセスできる必要があるワークロードを含む。例えば一般的な3層(ウェブサーバ、アプリケーションサーバ、データベースサーバ)設定では、少なくともウェブサーバがインターネットを介してクライアントに接続できる必要がある。通常、VPCサブネットはデータセンタ内の異なるテナントの多くのVPCにより再利用されてもよい(及び種々の異なるデータセンタにおいて再利用されてもよい)プライベートIPアドレスであるため、発信パケットの送信元IPアドレス(及びそれに対応して着信パケットの宛先IPアドレス)を内部使用プライベートIPアドレスからパブリックIPアドレスに変更するために、ネットワークアドレス変換(NAT)が一般に使用される。
更に、論理ネットワークがパブリックデータセンタ内で少なくとも部分的に実現される場合、パブリックIPアドレスへの実際の変換は、何れかの被管理転送要素ではなく、クラウドプロバイダのインターネットゲートウェイにより実行される必要がある場合がある。クラウドプロバイダゲートウェイは、データセンタ内でのパケットのラストホップであり、データセンタ内部にある間、パケットはプライベートIPアドレスを有する必要がある。しかし、クラウドプロバイダはワークロードアプリケーションが使用する内部IPアドレス(論理スイッチポートに対応するアドレス)を割り当てていないため、パケットはこれらのアドレスを使用してプロバイダのゲートウェイへ送信されるべきでない。その代わりに、いくつかの実施形態のネットワーク制御システムにより管理されるMFEは、内部IPアドレスをクラウドプロバイダに登録されているアドレスに変換するために独自のNATを実行する。
異なる実施形態は、このネットワークアドレス変換を異なる方法で実現してもよい。いくつかの実施形態は、ゲートウェイデータパスの一部としてNATを適用する。この場合、ノースバウンドパケットは送信元MFEからゲートウェイにトンネリングされ、そこでIPアドレスは一貫した方法で2次IPアドレスに変換される。いくつかの実施形態は、各内部ワークロードIPアドレスをクラウドプロバイダに登録されている2次IPアドレスにマッピングするNATテーブルを使用する。その後、これら2次IPアドレスは全て、ゲートウェイのノースバウンドインタフェースに関連付けられ、クラウドプロバイダのゲートウェイはこれら2次IPアドレスからパブリックIPアドレスへの変換を実行する。集中型の場合、サービスチェイニンング(種々のミドルボックス処理のための第3者サービスアプライアンスへのパケットの送信)、侵入検出、ノース/サウスファイアウォール、VPN、監査ロギング等の他のネットワークサービスがゲートウェイで更に適用されてもよい。更に、ゲートウェイがNATを実行する場合、何らかの負荷分散がゲートウェイにおいて更に実行される必要がある(この場合、プロバイダのゲートウェイが関係する限り、全てのトラフィックがゲートウェイインタフェースへ送信されるため、クラウドプロバイダが負荷分散を実行できない場合がある)。
他の実施形態は、送信元VM(着信トラフィックの場合は宛先VM)上で動作するMFEにおいて、第1のレベルのNATを分散して実行する。この場合、発信パケットに対して、送信元MFEはアドレス変換を実行し、変換されたパケットをゲートウェイを経由せずにクラウドプロバイダゲートウェイへ直接送信する。そのため、送信元MFEは、自身のVTEP IPを使用してカプセル化するオーバーレイトラフィックと、カプセル化せずにクラウドプロバイダアンダーレイネットワークへ送信するノース/サウストラフィックとを区別する。このトラフィックは(両方向で)ゲートウェイを通過しないため、何らかのサービスチェイニング、侵入検出、ノース/サウスファイアウォール規則、ロギング等はワークロードVM上で動作するMFEにおいて実行される。
負荷分散のために、分散型内部NATはクラウドプロバイダの既存の負荷分散特徴を使用できるようにする。複数のパブリックIPアドレスを使用する代わりに、単一のアドレス(又は少数のアドレスのみ)を使用することができ、全ての着信接続は当該アドレスへ送信される。クラウドプロバイダのインターネットゲートウェイ(又は特別な負荷分散アプライアンス)は負荷分散を実行し、これらの接続を異なるワークロードVM(依然として独自の内部NATを実行する必要がある)に均等に分散する。
A. 集中型NAT
集中型NATの場合、ワークロードVM内で動作するMFEは、第V.B節において上述したのと同じオーバーレイモード方式で構成される。非オーバーレイモード又は移行されたIPアドレスを使用するオーバーレイモードでは、パケットの送信に使用されるIPアドレスがVMのネットワークインタフェースのIPアドレスと一致するため、NATの内部レイヤは不要である。しかし、オーバーレイモードの場合、前述のように、NATの内部レイヤは、送信元(又は着信パケットの場合は宛先)のVPC内のゲートウェイVMで動作するゲートウェイデータパスにより実行される。
図22は、ワークロードアプリケーションから論理ネットワーク外部の宛先(例えば、インターネットクライアント、完全に別個の論理ネットワーク上の宛先等)へ送信されるノースバウンドパケットに対するクラウドプロバイダネットワークを介するパケット処理の一例を概念的に示す。図22は、パブリックデータセンタ内の同じVPC内でVMを動作させる2つのホストマシン2205及び2210と、同じVPC内ではないが同じパブリックデータセンタ内で動作するパブリッククラウドゲートウェイ2215とを含む。ワークロードVM2220は第1のホストマシン2220上で動作し、ワークロードアプリケーション2225及びMFE2230(オーバーレイモード)はワークロードVM内で実行する。ゲートウェイVM2235は第2のホストマシン2210上で動作し、ゲートウェイデータパス2240はVM上で実行する(ここでは不図示の制御器、PCM等に加えて)。前述のように、MFE2230はオーバーレイモードで動作し、ワークロードが接続する論理スイッチポートに関連付けられた内部IPアドレスAと、クラウドプロバイダのVPCサブネットに関連付けられたVTEP IPアドレスとを用いる。更に、ホストマシン2205及び2210はそれぞれ、各々のVMが接続する各々のパブリッククラウド転送要素2245及び2250を含む。上記の場合と同様に、これらのパブリッククラウド転送要素はソフトウェア仮想スイッチであってもよく、ネットワーク制御システムはこれらにアクセスできないよい。パブリッククラウドゲートウェイ2215は、別個の物理アプライアンス、VM又は他の何らかのフォームファクタとして動作してもよい。このゲートウェイ2215は、パブリックデータセンタ内に位置するVPCとパブリックデータセンタの外側のマシンとの間の非VPNトラフィックを処理する。
示されるように、ワークロードアプリケーション2225は、VM2220上のMFE2230へパケット2245を送信する。前述の例のパケットと同様に、このパケット2245は、送信元IPアドレス及び宛先IPアドレス(並びに、各MACアドレス)と、種々のヘッダと、ペイロードとを含む。送信元IPアドレスAは、ワークロードアプリケーション2225の内部IPアドレスであり(VMインタフェースIPアドレスと異なる)、宛先IPアドレスQは論理ネットワーク外部の宛先のアドレスである。
この時点で、MFE2230は、論理スイッチ及び論理ルータ処理を実行し(単層論理ルータトポロジを仮定して)、パケットを論理ルータのアップリンクポートへ送信する必要があると判定する。このアップリンクポートはゲートウェイデータパス2240にマッピングされるため、MFE2230はゲートウェイのVTEPにトンネリングされるパケット2245をカプセル化する。MFE2230は、このカプセル化されたパケット2250をパブリッククラウド転送要素2235に接続するVMインタフェースから出力する。示されるように、このカプセル化に対する送信元IPアドレスはMFEのVTEPのアドレス(すなわち、VMインタフェースのアドレス)であり、宛先IPアドレスはゲートウェイデータパス2240のVTEPのアドレス(すなわち、トンネルトラフィックに使用されるゲートウェイVMインタフェースのアドレス)である。
パブリッククラウド転送ネットワークがホストマシン間のトンネリングを使用すると仮定して、パブリッククラウド転送要素2235は、独自のアンダーレイカプセル化を用いてパケット2250の2回目のカプセル化を行い、この二重カプセル化パケット2255を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、ホストマシン2205のインタフェースのIPアドレスを送信元IPアドレスとして使用し、ホストマシン2210のインタフェースのIPアドレスを宛先IPアドレスとして使用する。
アンダーレイネットワークを通過した後、パケット2255はホストマシン2210により受信され、パブリッククラウド転送要素2240はアンダーレイカプセル化を除去する。転送要素2240は、オーバーレイカプセル化の宛先IPアドレスに基づいて、トンネリングされるトラフィックに対するゲートウェイVMのインタフェースを介して、まだカプセル化されているパケット2250をゲートウェイVM2235へ送信する。ゲートウェイデータパス2240は、カプセル化を除去し且つ宛先IPアドレスが自身のアップリンクポートに対応することを識別することにより、当該パケット2055を処理する。
次に、ゲートウェイデータパス2240(例えば、データパス内の集中型ルーティング構成要素)は、パケットが論理ネットワークからその宛先Qへ送信されるためには、パケットにネットワークアドレス変換が必要であると判定する。そのため、ゲートウェイデータパスは、NATテーブルを使用して、送信元アドレスAがマッピングされるパブリッククラウドプロバイダにより提供されたIPアドレスを識別する。ゲートウェイ2240が負荷分散を実行していない場合、いくつかの実施形態はワークロードアプリケーション毎に1つのIPアドレスを割り当てる。集中型NATの場合、着信パケットはパブリッククラウドゲートウェイ2215からワークロードVMに直接向けられるのではなくゲートウェイ2240に向けられるべきであるため、いくつかの実施形態はVMインタフェースIPを使用しない。その代わりに、テナントはパブリッククラウドプロバイダから割り当てられた多くの「2次」IPアドレスを有する。これらは全て、ゲートウェイデータパス2240のアップリンクインタフェースにマッピングされる。この場合、ゲートウェイはNATを実行して、パケット2245の送信元IPアドレスをAからB1に変更し、宛先IPアドレスをQのまま変更しない。
ゲートウェイは、この変換されたパケット2260をパブリッククラウド転送要素2240に出力し、パブリッククラウド転送要素2240は、パブリッククラウドプロバイダアンダーレイトンネルのためにパケット2260をカプセル化し、クラウドプロバイダネットワークを介してパブリッククラウドゲートウェイ2215へカプセル化パケット2265を送信する。ここで、パブリッククラウドゲートウェイ2215は、種々の2次IPアドレスをパブリックIPアドレスに(例えば、動的に割り当て可能なエラスティックIPに)マッピングする別個のNATテーブルを使用して独自のNATを実行する。この場合、パブリッククラウドゲートウェイのNATテーブルは、2次IPアドレスB1をパブリックIPアドレスC1にマッピングするように指定する。その後、パブリッククラウドゲートウェイは、この新しい変換されたパケット2270をその宛先Qに向けて外部ネットワーク(例えば、インターネット)へ送信する。
図23は、着信パケット2300が送信元QからテナントのVPCに関連付けられたパブリックIPアドレス(C1)のうちの1つへ送信される場合のパブリッククラウドゲートウェイ内の処理を示す。図23では、パケットは前述の図22に示した経路と逆の経路を通る。すなわち、パケット2300は、パブリッククラウドゲートウェイ2215により受信され、パブリッククラウドゲートウェイ2215は、自身のNATテーブルに従って宛先アドレスに対してNATを実行する。いくつかの実施形態において、このNATテーブルは静的(例えば、2次IPとパブリックIPとの間の1:1静的マッピング)である。
パブリッククラウドゲートウェイは、宛先IPアドレスC1をB1に変換し、変換されたパケットをアンダーレイに出力し、アドレスB1に関連付けられたゲートウェイVM2235へカプセル化パケット2305を送信する。パブリッククラウド転送要素2240は、アンダーレイカプセル化を除去し、このパケット2310をゲートウェイのアップリンクインタフェースへ送信する。ゲートウェイデータパス2240は、それ独自の内部NAT処理を実行して、2次IPアドレスB1を新しい宛先アドレスAに変換する。更に、ゲートウェイデータパス2240は、論理ネットワーク処理を実行して宛先アドレスAがMFE2220に位置する論理スイッチポートにマッピングされることを識別し、従って、独自のサウスバウンドインターフェースを送信元IPとして使用し且つMFE2220のVTEP IPアドレスを宛先IPとして使用して、変換されたパケットをカプセル化する。その後、このパケットは何らかのVPC内パケットの経路を通り、ホストマシン2210上のパブリッククラウド転送要素2240により再度カプセル化され、ホストマシン2205上のパブリッククラウド転送要素2235によりカプセル解除され、MFE2220に出力され、MFE2220はオーバーレイカプセル化をカプセル解除し、何らかの必要なセキュリティ処理を実行して、パケットをワークロードアプリケーションに出力する。
図24は、ワークロードアプリケーション2225と同じVPC上の異なるワークロードアプリケーションから送信されるパケットに対する図22のクラウドプロバイダネットワークを介するパケット処理を示す。図24は、ゲートウェイVM2235を有するホストマシン2210と、パブリッククラウドゲートウェイ2215と、VM2405が動作するホストマシン2400とを含む。ワークロードアプリケーション2410及びMFE2415はVM2405上で実行する。ワークロードアプリケーション2410は、それが接続する論理スイッチに関連付けられた内部IPアドレスDを有し、MFE2415のVTEPは異なるIPアドレスを有する。
本例において、ワークロードアプリケーション2410は送信元アドレスDを用いてパケット2420を送信する。このパケットは、ゲートウェイデータパス2240に到達するまで、図22のパケット2245と同様の経路を通る。当該データパス2240は、送信元NATがパケット2245に必要であると識別し、従って、自身の内部NATテーブルを調べて、IPアドレスAがマッピングされるアドレスとは異なる2次IPアドレスB2にアドレスDをマッピングする必要があると判定する。ゲートウェイデータパスは、前述の例とは異なるIPアドレスを使用して、変換されたパケット2425を同じアップリンクインタフェースから送信する。その結果、変換されたパケット2425が送信元アドレスB2を用いてパブリッククラウドゲートウェイ2215に到達すると、パブリッククラウドゲートウェイ2215はこの送信元アドレスを異なるパブリックIPアドレスC2に変換し、パケット2430を外部ネットワークへ送信する。
上記の図は、少なくともいくつかのクラウドプロバイダの場合と同様に、パブリッククラウドプロバイダがDCNの単一のインタフェースに対して複数のIPアドレスを許可すると仮定する。クラウドプロバイダがこの特徴を有効にしない場合、集中型NATを使用する際に1つのパブリックIPアドレスしか使用できない。この場合、アウトバウンド接続のみが開始された場合、複数の内部IPアドレスが使用されてもよく、ゲートウェイのNATテーブルはステートフル変換規則を使用して戻りトラフィックに正確な宛先IPアドレスを割り当てる。インバウンド接続の発信の場合、異なるワークロードアプリケーションが異なるL4ポートで実行する限り、トラフィックを正確なアプリケーション/VMに転送するようにL4ポートベースのDNAT規則をゲートウェイにおいて構成できる。
B. 分散型NAT
いくつかの実施形態の分散型NATの場合、ワークロードDCN内で動作するMFEも上記と同じオーバーレイモードで構成されているが、これらのMFEはノース/サウスパケットに対するNATを更に実行する。その結果、VPC内で動作するゲートウェイにノース/サウストラフィックを送信する必要がない。図25は、別々のIPアドレスを用いてオーバーレイモードで構成され、ノース/サウストラフィックに対するNATを更に実行する被管理転送要素2500を有するVM2505を概念的に示す。MFE2500は図18に示すMFE1800と同様に構成され、ワークロードアプリケーション2510は内部IPアドレスを有する内部インタフェースを介して統合ブリッジ2515に接続され、統合ブリッジはパケットがPIFブリッジ2520上のVTEPへ送信されるオーバーレイポートを有する。VTEPは、クラウドプロバイダにより提供される別個のIPアドレス有し、これはVMのインタフェースに関連付けられる。
この場合、パッチポートが統合ブリッジ2515とPIFブリッジ2520との間に更に構成される点が異なる。統合ブリッジは、発信パケットに対して論理処理を実行し、イースト/ウエストトラフィックの場合(例えば、宛先が論理ルータのアップリンクポート以外の論理ポートに対応すると識別される場合)、パケットをカプセル化してオーバーレイポートから送信する。一方、ノース/サウスパケット(論理ルータのアップリンクポートにマッピングされる)の場合、統合ブリッジ2515は代わりに、これらのパケットに対して送信元NATを実行し、カプセル化せずにパッチポートを介してPIFブリッジ2520へ直接送信する(非オーバーレイの場合のトラフィックと同様に)。いくつかの実施形態において、MFEは更に、接続に対する戻りトラフィックを処理するためのステートフル規則を作成する。他の実施形態において、単一の内部IPアドレスからクラウドプロバイダにより割り当てられたIPアドレスへの単独マッピングが全ての接続に対して使用されるため、ステートフル規則は不要である。いくつかの実施形態において、NATアドレスはVTEP IPアドレスと同じであってもよく、そのため、テナントは、クラウドプロバイダに複数のIPアドレスを割り当てさせる必要がない。他の実施形態において、2つのIPアドレスは異なり、その場合、VMは複数のインタフェースを有するか又は同じインタフェースに対して複数のIPアドレスを有する。
着信トラフィックの場合、PIFブリッジ2520は、パケットがトンネルトラフィックであるか又は外部送信元からのサウスバウンドトラフィックであるかを識別する。いくつかの実施形態は、ゲートウェイを含むVPC内の他のVTEPに対応する限定されたIPアドレスセットの中の宛先IPアドレスをパケットが有するかを識別して、着信トラフィックをVPC内オーバーレイトラフィックとして分類する。オーバーレイトラフィックは、統合ブリッジ2515がトラフィックをオーバーレイポートで受信してパケットをカプセル解除するようにVTEPへ送信され、サウスバウンドトラフィックは、パッチポートを介して統合ブリッジ2515へ送信される。このサウスバウンドトラフィックの場合、統合ブリッジ2515は、格納状態(例えば、戻りトラフィックの場合、状態が格納されているか)に基づいて又は自身のNAT規則を使用して(例えば、新規に開始された着信接続の場合又はステートフルNATルールが格納されていない場合)、宛先NATを実行する。
図26及び図27は、分散型NAT設定におけるノースバウンド及びサウスバウンドに対するクラウドプロバイダネットワークを介するパケット処理の例を示す。詳細には、図26は、ワークロードアプリケーションから論理ネットワーク外部の宛先(例えば、インターネットクライアント、完全に別個の論理ネットワーク上の宛先等)へ送信されるノースバウンドパケットに対するパケット処理の一例を示す。図26は、VPC内で動作するVMをホストする単一のホストマシン2605のみを含む。ワークロードVM2610はホストマシン2605上で動作し、ワークロードアプリケーション2615(内部IPアドレスAを有する)及びMFE2620はワークロードVM内で実行する。前述の例と同様に、ホストマシン2605はパブリッククラウド転送要素2625を更に含み、これは、ネットワーク制御システムがアクセスできないソフトウェア仮想スイッチであってもよい。更に、図26は、パブリックデータセンタ内に位置するVPCとデータセンタ外のマシンとの間の非VPNトラフィックを処理するための別個の物理アプライアンス、VM等として動作してもよいパブリッククラウドゲートウェイ2630を示す。
示されるように、ワークロードアプリケーション2615は、VM2605上のMFE2620へパケット2635を送信する。このパケットは、送信元IPアドレスA(論理スイッチポートに関連付けられたワークロードアプリケーションの内部IPアドレス)とリモートの外部の宛先の宛先IPアドレスQとを有する。MFE2620は論理スイッチ/ルータ処理を実行し、この宛先アドレスをアップリンク論理ルータポートにマッピングする。この場合、MFEは当該論理ポートへ送信されるパケットに対してNATを実行するように構成され、従って、NAT設定に従って送信元IPアドレスをAからNに変換する。上述したように、IPアドレスNは、VPC内のトンネリングに使用されるVTEPアドレスと同じでもよく、あるいはクラウドプロバイダにより同様に割り当てられた異なるIPアドレスであってもよい。
次に、MFE2620は、この変換されたパケット2640をカプセル化せずにパブリッククラウド転送要素2625へ送信する。当該パケットは転送要素2625によりカプセル化され、アンダーレイ(パブリッククラウド)ネットワーク上でパブリッククラウドゲートウェイ2630へ直接送信され、それにより、集中型NATの場合にノース/サウストラフィックに必要なVPCゲートウェイをスキップする。パブリッククラウドゲートウェイ2630は独自のNATテーブルを有し、アンダーレイカプセル化を除去した後、送信元IPアドレスをNからテナントに登録されているパブリックIPアドレスであるMに変換する。
図27は、パブリッククラウドゲートウェイ2630を介してIPアドレスQを有する外部送信元からワークロードアプリケーション2615へ送信されたサウスバウンドパケットに対する処理を示す。図27において、パブリッククラウドゲートウェイ2630は、送信元IPアドレスQと、上述したように)ワークロードVM2610に関連付けられたパブリックIPアドレスである宛先IPアドレスMとを有するパケット2705を受信する。このパケットは、図26で説明したパケットと反対の経路を通る。パブリッククラウドゲートウェイ2630は、NATを実行して宛先IPアドレスをプライベートIPアドレスNに変換し、パケットをVM2610に転送する(プロバイダアンダーレイネットワーク上で)。パブリッククラウド転送要素2625がアンダーレイカプセル化を除去した後、MFE2620はパケットがカプセル化されていないサウスバウンドパケットであることを識別し、パケットに論理ルータ/論理スイッチ処理を実行する。論理ルータ処理の一部として、MFE2620は宛先IPアドレスをNからワークロードアプリケーション2615のIPアドレスであるAに変換する。その後、MFE2620は当該パケットをワークロードアプリケーション2615に出力する。
図28は、ワークロードVM上のMFEがオーバーレイモードで動作し且つ分散型NATを実行するように構成される場合に、発信パケットを処理するためにMFEにより実行される処理2800を概念的に示す。そのようなMFEの一例は、図25に示すMFE2500である。処理2500は概念的な処理であり、MFE(特に、フローベースMFE)が図示されるような判定を行わなくてもよいことが理解されるべきである。その代わりに、そのようなMFEは自身のフローテーブルを介してパケットを処理し、一致したフローエントリに従って動作を実行する。すなわち、特定の動作を行うかに関するイエス/ノーの決定をMFEが評価するのではなく、行うべき動作又は動作セットは処理の結果により指示される。しかし、処理2800は、与えられた異なる種類のパケットに対してMFEが実行する異なる動作を表す。
示されるように、処理2800は、ローカルワークロードアプリケーションからパケットを受信する(2805において)ことにより開始する。MFEがオーバーレイモードで動作しているため、このパケットは送信元アドレスとして内部IPアドレスを有する(MFEは不正アクセスされていないと仮定する)。次に、処理は、自身の構成(すなわち、ローカル制御エージェントによりプッシュダウンされた構成規則)に従って論理ネットワーク/セキュリティ処理を実行する(2810において)。これは、論理スイッチ及び/又は論理ルータ処理、分散型ファイアウォール処理等を含んでもよい。
処理2800は、パケットの宛先がMFEが動作するVMと同じVPC内であるかを判定する(2815において)。パケットの宛先が同じVPC内である場合、処理は、カプセル化に対する送信元IPアドレスにローカルVTEP IPアドレスを用い且つ宛先IPアドレスにVPC内の宛先MFEのVTEPを用いてパケットをカプセル化する(2820において)。本処理の一例は、上述した図19に示される。
宛先が同じVPC内でない場合、処理2800は、宛先が外部の宛先であるか(すなわち、パケットがノースバウンドパケットであるか)を判定する(2825において)。宛先が外部の宛先でない場合、パケットは異なるVPC又はデータセンタ内に位置する論理ポートにアドレス指定され、処理は、カプセル化に対する送信元IPアドレスにローカルVTEP IPアドレスを用い且つ宛先IPアドレスにVPC内のゲートウェイのVTEPを用いてパケットをカプセル化する(2830において)。そのような処理の一例は、同様に上述した図20に示される。いずれの状況においても、MFEは、論理ネットワーク内の論理スイッチポート(必ずしもローカルワークロードアプリケーションと同じ論理スイッチ上にあるとは限らない)をパケットの宛先として識別し、パケットを別のローカルVM又はゲートウェイにトンネリングする(後者の場合、それにより、ゲートウェイはパケットを最終的な宛先に向けて送信できる)。
しかし、宛先が外部の宛先である場合(例えば、宛先IPアドレスがアップリンク論理ルータポートにマッピングされる場合)、処理は、送信元IPアドレスを内部ワークロードアプリケーションIPアドレスからクラウドプロバイダにより割り当てられたIPアドレスに変更するためにNATを実行する(2835において)。このIPアドレスは、ローカルVTEP IPアドレスと同じであってもよいが、この場合、GENEVE、STT等のトンネルヘッダにおける送信元IPアドレスとしてではなく、内部パケットの送信元IPアドレスとして(カプセル化せずに)使用される。本処理の一例は、図26に示される。最後に、処理は、ホストマシン上のクラウドプロバイダ転送要素へパケットを送信し(2840において)、パケットはクラウドプロバイダのネットワーク上で送信される。
ここで示されるように、分散型NATを使用することにより、いくつかの実施形態において、ストレージサービス等の外部クラウドプロバイダサービスとのシームレスな統合が可能になる。これらの外部リソースは、自身にアクセスしているVPC上のDCNを容易に判定できるため、識別に基づくポリシーを使用してこれらのリソースへのアクセスを制御できる。集中型NATの場合、ワークロードDCNのインタフェースに対応しないIPアドレスを使用して、そのようなリソースの全てにゲートウェイを介してアクセスできる。更に、分散型NATを使用することにより、多くのクラウドプロバイダにより提供される負荷分散サービスと容易に統合できる。
図29は、ワークロードVM内で動作するMFEによる分散型NATと共にパブリッククラウドゲートウェイ2900における負荷分散の使用を示す。図29は、VPC内でVMを動作させる2つのパブリッククラウドホストマシン2905及び2910を示す。詳細には、第1のVM2915は第1のホストマシン2905上で動作し、第2のVM2920は第2のホストマシン2910上で動作する。第1のVM2915は内部IPアドレスAを有するワークロードアプリケーション2925を実行し、第2のVM2920は内部IPアドレスBを有するワークロードアプリケーション2930を実行する。本例において、2つのワークロードアプリケーションは同一の外部アクセス可能アプリケーションのインスタンスである(例えば、複数のウェブサーバーインスタンス)。更に、MFE2935及び2940がそれぞれ2つのVM2915及び2920上で実行され、ホストマシン2905及び2910はそれぞれパブリッククラウド転送要素2945及び2950を含む。
パブリッククラウドゲートウェイ2900(又はVPCに対するサウスバウンドトラフィックを誘引するためにパブリッククラウドにより提供される別個の負荷分散アプライアンス)は、2つのパケット2955及び2960を受信する。これらのパケットの双方は宛先IPアドレスX(ワークロードアプリケーション2925及び2930に関連付けられたパブリックIPアドレス)を有するが、異なる送信元Q及びRからのパケットである。従って、パブリッククラウドゲートウェイ2900が受信すると、当該ゲートウェイは、これら2つのワークロード間(及び場合によっては更なるVM上の更なるインスタンス間)でトラフィックを分散させるために負荷分散/宛先ネットワークアドレス変換動作を実行する。
種々の要因(IPアドレス及び/又は他のヘッダのハッシュ、異なるワークロードにおける現在のトラフィック負荷の監視等)に基づいて、パブリッククラウドゲートウェイ2900は第1のパケット2955に対する宛先IPアドレスY及び第2のパケット2960に対する宛先IPアドレスZを選択する。これら2つのIPはそれぞれ、VM2915及び2920のクラウドプロバイダ割り当てVMインタフェースに対応し、従って、ゲートウェイは2つのホストマシン2905及び2910にパケットをトンネリングする。これらが接続における最初のパケットであると仮定した場合、ゲートウェイは更に、接続に対する何らかの発信トラフィックが同じワークロードアプリケーションへ送信されるように、接続及びNATマッピングを格納する(いくつかの実施形態において、それらが最初のパケットでない場合、ゲートウェイは以前に格納された状態に従ってパケットを処理する)。
MFE2935及び2940がパケットを受信すると、それらはトラフィックをカプセル化されていないサウスバウンドトラフィックと認識し、従って、パケットに対して独自のNATを実行する。これらのNAT動作は、第1のMFE2935において第1のパケットの宛先IPアドレスYをAに変換し、第2のMFE2940の第2のパケットに対して宛先IPアドレスZをBに変換する。
負荷分散をこのように使用することにより、クラウドプロバイダによりサポートされている場合に新規のワークロードVMの自動スケーリングも可能になる。自動スケーリングでは、ワークロードの負荷が高すぎると、クラウドプロバイダは同じアプリケーションを実行する新規のインスタンスを自動的に作成し、プロバイダの負荷分散器は、負荷分散を決定する際に新規のインスタンスを考慮し始める。第II節で上述したように、新規のVMがクラウドプロバイダインベントリに現れると、PCMはその存在を識別し、ネットワーク制御システムが新規のインスタンスに必要な構成データを配布できるように、ネットワーク制御システムに通知する。
VII. 分散型ネットワーク暗号化
いくつかの実施形態は、パブリックデータセンタ内において、ネットワーク制御システムにより管理される分散型ネットワーク暗号化(DNE)を使用することを可能にする。いくつかの実施形態において、DNEは同じVPC内又はピア接続されたVPC内で動作するDCN間でのみ可能であるが、他の実施形態において、DNEは論理ネットワークの論理ポートに接続されたいずれか2つのDCN間で可能である(ワークロードDCNとゲートウェイとの間を含む)。
いくつかの実施形態において、分散型ネットワーク暗号化は、ネットワーク制御システム管理者がパケットに対する暗号化規則及び/又は整合性規則を設定できるようにする。これらの規則は、(i)規則が適用されるパケットと、(ii)それらのパケットに対する暗号化要件及び/又は整合性要件とを定義する。いくつかの実施形態は、規則が適用されるパケットをパケットの送信元及び宛先に関して定義する。これらの送信元エンドポイント及び宛先エンドポイントは、IPアドレス又はアドレスの範囲、MACアドレス、論理スイッチポート、仮想インタフェース、L4ポート番号及びその範囲等、並びにそれらの組み合わせに基づいて定義されてもよい。
更に、各規則は、送信元及び宛先の特徴に合致するパケットが暗号化(場合によっては認証を伴う)を必要とするか、認証のみを必要とするか、あるいはプレーンテキスト(ブロードキャストパケットを許可するための設定として使用されてもよい)を必要とするかを指定する。暗号化は、パケットの一部分又は全部(例えば、内部パケット全体、L4以上のヘッダのみ、トンネリングされるパケットの場合の内部/外部パケット全体等)を暗号化するために鍵を使用する必要があるが、認証はパケットを暗号化せず、送信中にパケットが改竄されていないことを検証するために宛先が使用できる認証データを生成するために鍵を使用する(例えば、パケット又はその一部分のハッシュ)。
ネットワーク内のMFEにDNE規則を実現させるために、ネットワーク制御システムはMFEに鍵をセキュアに配布する必要がある。いくつかの実施形態は、ネットワーク制御システムのDNE態様と通信し且つそのVPC内のワークロードDCN内で動作するMFEに鍵を配布するために、ゲートウェイDCN内のDNEモジュールを使用する。図30は、いくつかの実施形態のそのようなDNE規則/鍵配布システム3000と、パブリックデータセンタ内のMFE上でDNE規則を実現するためのデータの流れとを概念的に示す。
DNE規則/鍵配布システム3000は、管理プレーン3005、中央制御プレーン3010及び鍵マネージャ3015をプライベートデータセンタ内に含む。これらの構成要素は、パブリックデータセンタの別個のVPC(又は同じVPC)に位置することもできるが、DNEシステムにおいて使用するために鍵マネージャ3015がマスタ鍵をセキュアに格納するため、ネットワーク管理者は一般に、これらの構成要素を自身のプライベートデータセンタに保持することを望む。これらの構成要素の動作の簡単な説明を本明細書に示すが、チケット及び鍵配布処理は、参考として上記に取り入れられる米国特許仮出願第62/380,338号に更に詳細に記載されている。
管理プレーン3005及び中央制御プレーン3010は、ネットワーク転送規則及びセキュリティ規則を配布する際のそれらの動作に関連して上記で説明された。転送構成と同様に、管理プレーン3005がDNE規則を受信する(例えば、管理プレーンAPIを用いて構成されたクラウド管理プラットフォームから)と、それは当該規則をフォーマットし、規則を中央制御プレーン3010に渡す。中央制御プレーン3010は、規則を必要とするパブリックデータセンタVPC内の何らかのゲートウェイ制御器を含むローカル制御器を識別するために、規則の適用範囲の計算を実行する。
いくつかの実施形態の鍵マネージャ3015は、ネットワーク制御システム3000により管理されるMFEにより使用される暗号鍵を格納するセキュアな記憶装置である。いくつかの実施形態において、鍵マネージャ3015は、ハードウェアアプライアンス、プライベートデータセンタ内でセキュアに動作するVM等である。いくつかの実施形態において、鍵マネージャは、管理容易性のために、構造及び機構を指定して鍵のグループを定義し、鍵にアクセスするための種々のセキュリティ制御(例えば、アクセス制御及び認証)を提供する。いくつかの実施形態において、認証機構は、公開鍵基盤(PKI)証明書、ユーザ資格情報及び/又は共有シークレットを含む。また、いくつかの実施形態の鍵マネージャは、悪意のある要求者の脅威に対処するために要求者の認証を強化する。
鍵マネージャ3015は管理プレーン3005に登録し、管理プレーン3005、中央制御プレーン3010(すなわち、中央制御プレーンクラスタ内の1つ以上の制御器)及びローカル制御器(何らかのゲートウェイ制御器を含む)の証明書を取得する。登録時に鍵マネージャ3015にこれらの証明書を取得させることにより、ネットワーク制御システム3000は、ローカル制御器が特定のDNE規則のための鍵を要求する際の重複した通信(すなわち、鍵を要求するローカル制御器が有効な制御器であることを検証するための通信)を回避する。
いくつかの実施形態において、鍵マネージャ3015は、鍵の要求に基づいて生成された鍵を格納することに加えて、鍵の要求に基づいて鍵を生成する。同一の鍵に対する後続の要求が必要である場合(例えば、鍵を必要とするVMの電源が切られて再度投入される場合又は再起動する場合)、格納された鍵が使用されてもよい。いくつかの実施形態は、パスワード保護された読み出し専用ファイルにおいてセキュリティ保護され且つ管理者からの入力を用いる初期段階において鍵マネージャ3015のメモリにロードされる鍵用暗号鍵を用いて暗号化された鍵マネージャ3015に鍵を格納する。
パブリックデータセンタVPC内において、システム3000は、ゲートウェイ制御器3025及びDNEモジュール3030を有するゲートウェイVM3020と、ワークロードVM3035とを含む。ゲートウェイVM3020及びそのゲートウェイ制御器3025は上記で詳細に説明された。また、ゲートウェイVM3020は、第II節で上述したゲートウェイデータパス、パブリッククラウドマネージャ等の種々の他の特徴を更に実行してもよいことが理解されるべきである。
DNEモジュール3030は、ゲートウェイVM3020のVPC内の何らかのMFEが必要とする何らかの鍵を処理する責任を有する。DNEモジュール3030は、VPC内のMFEに対する暗号鍵を管理するために鍵マネージャ3015と対話する。中央制御プレーン3010がVPC内で動作する何らかのワークロードとの間で送受信されるパケットに対する暗号化及び/又は認証の要件を指定する規則を受信すると、中央制御器はこれらの規則をゲートウェイ制御器3035に配布する)。いくつかの実施形態の暗号化規則は、鍵マネージャ3015から鍵を取得するために制御器により使用されるチケットを含む。DNEモジュール3030又はゲートウェイ制御器3025は、このチケットを使用して鍵マネージャ3015に鍵を要求し、鍵マネージャ3015は暗号化規則に対するマスタ鍵を提供する。DNEモジュール3030はマスタ鍵を受信し、この鍵を使用して規則に対するセッション鍵を生成する。いくつかの実施形態において、セッション鍵は、マスタ鍵と暗号化を実行することになる2つのエンドポイントに特有の1つ以上の更なるパラメータとの関数として生成される。DNEモジュール3030は(例えば、ゲートウェイ制御器3025を介して)、生成されたセッション鍵を適切なエンドポイントに配布する。
ワークロードVM3035は、パブリックデータセンタの同一のVPC内で動作する複数のワークロードVMのうちの1つである。VMは、ローカル制御エージェント3040と、DNE規則を実際に実現するMFE及びワークロードアプリケーション等(不図示)とを含む。
システム3000の構成要素の動作について説明したので、次に図30に示すデータフローの例を説明する。丸囲み文字1Aで示すように、管理プレーン3005は中央制御プレーン3015にDNE規則3050を渡す。このDNE規則3050は、管理プレーンのAPIを介して入力として(例えば、おそらくクラウド管理インタフェースを介してネットワーク管理者から)受信されたものである。DNE規則3050は、上述したように、規則が適用されるパケットと、(ii)それらのパケットに対する暗号化要件及び/又は整合性要件とを指定する。いくつかの実施形態において、規則は、使用する暗号化の種類、使用時に鍵を回転させる(すなわち、特定の方法で変更する)頻度、特定の時間が経過後に鍵を無効にするか等のポリシーを更に含んでもよい。
中央制御プレーン3010は当該規則3050を受信し、その適用範囲を判定する。規則が特定の送信元エンドポイント及び宛先エンドポイントを有する場合、適用範囲はそれらのエンドポイントの2つのファーストホップMFEのみであってもよい。一方、規則は暗号化される特定の論理ポートから送受信される全てのトラフィックを指定してもよく、その場合、特定の論理ポートと通信している可能性のある全てのエンドポイントに対するファーストホップMFEが規則を受信する必要がある。本例では、少なくともVM3035上で動作しているアプリケーションが規則のエンドポイントであるため、中央制御プレーンは、その規則の適用範囲がゲートウェイ制御器3025を含むと判定する。丸囲み文字1Bで示すように、中央制御プレーン3010は当該DNE規則3050をゲートウェイ制御器3025に配布する。ゲートウェイ制御器3025は、そのVPCにおける規則の適用範囲を判定し、当該規則を必要とする1つのMFEとしてワークロードVM3035上のMFEを識別し(VPC内の暗号化の場合、少なくとも1つの更なるエンドポイントが規則を必要とし、VPC外の暗号化の場合、ゲートウェイVM上のデータパスが規則を必要とする)、丸囲み文字1Cで示すように、VM3035上のローカル制御エージェント3040に規則3050を配布する。
規則自体に加えて、いくつかの実施形態では、丸囲み文字2で示すように、CCPはゲートウェイ制御器3025にチケット3055を配布する。いくつかの実施形態において、暗号鍵チケットは、鍵識別子及びセキュリティパラメータインデックス(SPI)に基づいてゲートウェイ制御器に対して生成される。いくつかの実施形態において、セキュリティパラメータインデックスは、鍵長、暗号化アルゴリズム等のDNEが使用される接続(例えば、2つのエンドポイント間の)のセキュリティ性を識別する。当該チケット3055は、鍵マネージャ3015から鍵を検索するためのセキュリティトークンとして機能する。いくつかの実施形態において、チケットは、鍵識別子、ローカル制御器識別子、有効期限及び署名を含む。
チケット3055を受信すると、ゲートウェイ制御器はDNEモジュール3030にチケット(不図示)を渡し、DNEモジュール3030は、丸囲み文字3で示すように、鍵マネージャ3015へ鍵要求3060を送信する。いくつかの実施形態において、実際はゲートウェイ制御器3025が鍵マネージャ自体へ鍵要求を送信する。要求は、ゲートウェイ制御器が中央制御プレーンにより鍵の受信を認可されていることを認定するチケット又はチケットからの情報を含む。鍵マネージャ3015は、当該要求を検証し、丸囲み文字4で示すように、ゲートウェイVM3020へマスタ鍵3065を送信する。図30では、DNEモジュール3030が当該マスタ鍵3065を受信する。いくつかの実施形態では、マスタ鍵3065はゲートウェイ制御器3025へ送信され、ゲートウェイ制御器3025がDNEモジュール3030に鍵を渡す。
DNEモジュール3030は、マスタ鍵を使用して、VM3035(及び鍵を使用する予定の他の何らかのVM)におけるMFEに対するセッション鍵を生成する。いくつかの実施形態において、セッション鍵は、マスタ鍵と、接続の2つのエンドポイントに関連するSPI及び/又は2つのエンドポイントのVTEP IPアドレスと、乱数との関数である。いくつかの実施形態において、規則が複数の接続(例えば、送信元Aから宛先B又は宛先Cのいずれかへ)を指定する場合、DNEモジュール3030は、2つのエンドポイント間の各接続に対して異なるセッション鍵を生成する。すなわち、上記の例では、AとBとの間の接続及びAとCとの間の接続に対する2つのセッション鍵が生成される。いくつかの実施形態は対称鍵暗号化を使用し、その場合、同一のセッション鍵が接続の各エンドポイントに配布される。丸囲み文字5で示すように、DNEモジュール3030は、ローカル制御エージェント3040にセッション鍵3070を配布する(直接又はゲートウェイ制御器を介して)。
いくつかの実施形態において、エージェント上での暗号化はMFE自体により(すなわち、統合ブリッジ又はPIFブリッジにより)実行されない。その代わりに、ワークロードVM上で動作するDNEモジュールがネットワークスタック(すなわち、VMインタフェースのIPアドレスに対して、統合ブリッジとPIFブリッジとの間のネットワークスタック)と統合する。ネットワークスタックのIPsec機能性は適切なセッション鍵を使用して、発信パケットの整合性情報を暗号化及び/又は生成し、着信パケットを復号化及び/又は認証する。MFEにおけるフローエントリは、暗号化/復号化及び/又は認証を所定のパケットに対して実行する必要があるかを示す。
図31は、パブリックデータセンタVPCのゲートウェイにおいてDNE鍵を管理するためのいくつかの実施形態の処理3100を概念的に示す。いくつかの実施形態において、処理3100は、VPC内のゲートウェイVMにより(例えば、ゲートウェイVMのゲートウェイ制御器及び/又はDNEモジュールにより)実行される。いくつかの実施形態において、ゲートウェイVMは、受信したDNE規則毎に当該処理又は同様の処理を実行する。
示されるように、処理3100は、VPC内の少なくとも1つの論理ポートに対するDNE規則を指定する中央制御器から規則を受信する(3105において)ことにより開始する。上述したように、中央制御器はゲートウェイ制御器がVPC内で動作する全てのワークロードに対するローカル制御器であると見なす。DNE規則は、VPC内の2つのエンドポイント間の接続、VPC内の複数のエンドポイント間の複数の接続、VPC内のエンドポイントと他の場所に位置する論理ネットワークエンドポイントとの間の接続、ゲートウェイデータパスとVPC内の別のエンドポイントとの間の接続、あるいはそれらの組合せに関係してもよい。いくつかの実施形態のDNE規則は、指定された接続のエンドポイント間のパケットの暗号化及び/又は認証も要求する。
更に、処理3100は、暗号化及び/又は認証処理で使用するための鍵に対するチケットを中央制御器から受信する(3110において)。いくつかの実施形態において、当該チケットは、鍵識別子及び/又はSPIに基づいて中央制御器により生成される。チケットは、ネットワーク暗号化システムの鍵マネージャから鍵を検索するためのセキュリティトークンとして機能する。いくつかの実施形態において、チケットは、鍵識別子、ローカル制御器識別子、有効期限及び署名を含む。
次に、処理は、チケットを使用して鍵マネージャへ鍵の要求を送信する(3115において)。いくつかの実施形態はチケット自体を送信し、他の実施形態はチケットから導出されたデータを送信する。鍵マネージャは、チケット又は要求内の他の情報を使用して、必要な鍵を識別し、ゲートウェイ制御器が鍵を受信することを認可されていることを検証する。
鍵マネージャが要求を検証したと仮定した場合、処理は鍵マネージャからマスタ鍵を受信する(3120において)。マスタ鍵は、要求時に鍵マネージャにより生成される。次に、処理は、受信したマスタ鍵に基づいて1つ以上のセッション鍵を計算する(3125において)。規則により統制される複数の可能な接続を規則が指定する場合、いくつかの実施形態は、そのような接続毎にマスタ鍵から異なるセッション鍵を生成する。いくつかの実施形態は、マスタ鍵、特定の接続の2つのエンドポイントに関する特徴(例えば、VTEPラベル、VTEP IPアドレス、エンドポイントに関連するSPI等)及び/又はランダムに生成された数の関数としてセッション鍵を計算する。
次に、処理は、鍵を必要とする何らかのMFEに対するローカル制御エージェント(すなわち、各接続の両端に存在するMFEに対するエージェント)へセッション鍵を送信する(3130において)。これは、必要に応じて鍵をゲートウェイデータパスへ送信することを更に含んでもよい。更に、いくつかの実施形態において、ワークロードVM又はそのエージェントが再起動され且つエージェントが以前に配布された情報を必要とする場合に鍵を再配布できるように、ゲートウェイ上のDNEモジュールは鍵をセキュアに格納する。
VIII. 脅威の検出及び処理
特に、パブリッククラウド内で動作するDCNワークロード及びそれらのDCN上で動作するMFEの場合、セキュリティが問題となり得る。セキュリティポリシーはDCNが動作するマシンの仮想化ソフトウェア内ではなくDCN自体で動作するMFEにより実施されるため、ハッカーがDCNへのルートアクセスを取得した場合、ハッカーはネットワークセキュリティポリシーの実施を回避できる(従って、これらのポリシーに反してトラフィックを送信できる)可能性がある。
不正アクセスされたDCN上のハッカー(又は他の不正ユーザ)は、いくつかの異なる方法のうちの1つでネットワークセキュリティポリシーを回避する可能性がある。例えばユーザは、(i)ローカル制御エージェントを除去すること(例えば、アンインストールすること)、(ii)セキュリティポリシーの実施を回避するために、ネットワークインタフェースをMFEから切断し、ネットワークスタックをインタフェース上で直接実行すること、あるいは(iii)ローカル制御エージェントが(例えば、セキュリティポリシーを実施する統合ブリッジの)MFEの制御器でなくなるように構成を修正することにより、MFEを直接構成する(例えば、新規のフローエントリをインストールする)。
しかし、いくつかの実施形態のパブリッククラウドマネージャは、不正アクセスされたDCNをパブリッククラウドに関して隔離することにより、ネットワーク制御システムがこれらの状況を処理できるようにする。従って、DCNが接続するパブリッククラウド転送要素(例えば、ホストマシン内の仮想スイッチ)は、不正アクセスされたDCNがデータトラフィックを送信するのを防止する。PCMは、影響を受けたDCNのVPC内のゲートウェイ制御器により、影響を受けたDCNを通知され、パブリッククラウドマネージャAPIを使用して、不正アクセスされたDCNをパブリッククラウドの管理システム内の隔離セキュリティグループに入れることができる。
不正アクセスされたDCN上のローカル制御エージェントは、上記に列挙した第2の状況及び第3の状況を検出し、ゲートウェイ制御器に通知できる。エージェントが除去された場合、ゲートウェイ制御器は当該制御器への接続が存在しないことを認識する。いずれの場合も、DCNが不正アクセスされたとゲートウェイ制御器が判定すると、ゲートウェイ制御器はPCMに通知し、それによりPCMは不正アクセスされたDCNを隔離できる。
図32は、不正アクセスされたDCNを処理するためにPCMにより実行されるいくつかの実施形態の処理3200を概念的に示す。示されるように、処理は、VPC内のデータ計算ノードが不正アクセスされたらしいという通知をゲートウェイ制御器から受信する(3205において)ことにより開始する。これは、不正ユーザ又はハッカーがMFEからネットワークインタフェースを切断した場合、MFEに接続されない新規のネットワークインタフェースを追加した場合、又はMFEの制御器としてのエージェントを切断した場合のDCN上のローカル制御エージェントからのメッセージに基づいて発生する。MFEエージェント自体がアンインストール又は除去された場合、ゲートウェイ制御器はエージェントとの接続が失われた時にエラーを検出する。
次に、処理3200は、不正アクセスされたDCNを再分類するためのパブリッククラウドプロバイダのセキュリティグループを判定する(3210において)。いくつかの実施形態において、パブリッククラウドプロバイダは、自身がホストするDCNの例えば隔離、開放、カプセル化トラフィックの許可を含む分類を行うことができるセキュリティグループのセットを有する。隔離されると、DCNの制御を取り戻すための特定のトラフィックを除いて、DCNはホストマシン上のクラウドプロバイダ転送要素を介してトラフィックを送受信することを許可されない。従って、処理3200は、パブリッククラウドプロバイダのAPIを使用して、不正アクセスされたDCNを識別されたセキュリティグループ(例えば、隔離グループ)に追加する(3215において)。いくつかの実施形態において、PCMは、これらのAPIを使用して、DCNに対する新規のセキュリティグループを指定するパブリッククラウド管理システムへコマンドを送信する。脅威が除去され且つDCNが正常な状態に回復すると、いくつかの実施形態のPCMは、DCNを以前のセキュリティグループに戻す同様のコマンドを送信する。
図33及び図34は、パブリックデータセンタVPC内の不正アクセスされたVMを識別するゲートウェイ制御器3330と、不正アクセスされたVMをパブリックデータセンタプロバイダと共に隔離するPCM3325の例を示す。詳細には、図33は、エージェントがアンインストールされる場合を4つの段階3305~3320で示す。第1の段階に示されるように、ゲートウェイVM3300はゲートウェイ制御器3330及びPCM3325を含み(他の構成要素に加えて)、VPC内のVM3335はエージェント3340を実行する(ワークロードアプリケーションとエージェントにより制御されるMFEとに加えて)。第1の段階3305では、ゲートウェイ制御器3330とエージェント3340との間に接続が存在する。
しかし、この第1の段階3305において、VMが不正アクセスされ、VMにログインしたユーザがエージェント3340を削除(例えば、アンインストール)したため、VM上のMFEはセキュリティポリシーを受信できない。しかし、第2の段階3310に示すように、これによりエージェントとゲートウェイ制御器3330との間の接続が除去されたため、ゲートウェイ制御器はエージェントが動作していないことを検出する。尚、これは、VMが不正アクセスされたのではなくエージェントが再起動又は故障した場合に起こり得るが、いくつかの実施形態は、いずれにしても、これらの場合はエージェントがバックアップされるまでVMを隔離する。
第3の段階3315において、ゲートウェイ制御器3330はエージェントが停止していることをPCM3325に通知する。いくつかの実施形態はPCMに特定の問題(エージェントの停止、無認可のインタフェース等)を通知し、他の実施形態は単に特定のVMが不正アクセスされたことをPCMに通知する。いずれの場合も、第4の段階3320は、不正アクセスされたVMを隔離する(例えば、不正アクセスされたVMを隔離セキュリティグループに入れることにより)ために、PCMがクラウドプロバイダ管理システム3345へメッセージを送信することを示す。
本例はエージェントが完全にアンインストールされた場合を示すが、ハッカーが異なる制御器(すなわち、ハッカーによる1つの制御器)から構成規則を受信するようにエージェントの構成を単に変更した場合も同様の接続の消失が生じる。エージェントがゲートウェイ制御器から構成を受信するように構成されなくなるため、エージェントはゲートウェイ制御器との通信を切断し、ゲートウェイ制御器にはエージェントが削除されたように見える。
図34は、攻撃者が不正アクセスされたVM3400上に新規のインタフェースを作成する場合を4つの段階3405~3420で示す。VM3400は、その上で実行するエージェント3425を有し、ゲートウェイVM3300と同じVPC内で動作する。第1の段階3405において、新規のインタフェースがVM3400上に作成されており、当該インタフェースは非セキュアデータを送信するために使用されている。インタフェースはMFEに接続されていないため、VM上のアプリケーションは、何らかの種類のセキュリティ処理を行うことなく、ネットワークスタックを介してインタフェースへパケットを直接送信できる。
しかし、第2の段階3410において、エージェントは新規のインタフェースの存在を検出し、ゲートウェイ制御器3330に当該インタフェースを報告する。いくつかの実施形態において、新規のインタフェースは、エージェントにより管理されるデータベース(例えば、OVSDBデータベース)に自動的にポピュレートされるため、エージェントはこの変更を検出する。インタフェースはMFEに接続されていないため、エージェントは当該インタフェースを信頼できないインタフェースとしてゲートウェイ制御器に報告する。同様に、既存のインタフェースがMFEの仲介処理なしにワークロードアプリケーションからパケットを直接受信するように変更された場合、エージェントはゲートウェイ制御器に通知する。
第3の段階3415において、ゲートウェイ制御器3330は、VM3400が不正アクセスされていることをPCM3325に報告する。前述の例と同様に、PCMは、不正アクセスされたVMを隔離する(例えば、VMを隔離セキュリティグループに入れることにより)ためにクラウドプロバイダ管理システム3345へメッセージを送信する。
IX. 電子システム
上述した特徴及びアプリケーションの多くは、コンピュータ可読記憶媒体(コンピュータ可読媒体とも呼ばれる)に記録された命令のセットとして指定されるソフトウェア処理として実現される。これらの命令が1つ以上の処理装置(例えば、1つ以上のプロセッサ、プロセッサのコア又は他の処理装置)により実行される場合、それらは命令において示される動作を処理装置に実行させる。コンピュータ可読媒体の例は、CD‐ROM、フラッシュドライブ、RAMチップ、ハードドライブ、EPROM等を含むが、それらに限定されない。コンピュータ可読媒体は、無線又は有線接続を介する搬送波及び電子信号を含まない。
本明細書において、用語「ソフトウェア」は、プロセッサによる処理のためにメモリに読み込むことができる読み出し専用メモリに常駐するファームウェア又は磁気記憶装置に格納されたアプリケーションを含むことを意味する。また、いくつかの実施形態において、個別のソフトウェア発明を残しつつ、複数のソフトウェア発明をより大きなプログラムの一部として実現することができる。いくつかの実施形態において、複数のソフトウェア発明を別個のプログラムとして実現することもできる。最後に、本明細書に記載のソフトウェア発明を共に実現する別個のプログラムの何らかの組み合わせは本発明の範囲内である。いくつかの実施形態において、ソフトウェアプログラムは、1つ以上の電子システム上で動作するようにインストールされた場合、ソフトウェアプログラムの動作を遂行及び実行する1つ以上の特定のマシン実現例を定義する。
図35は、本発明のいくつかの実施形態が実現される電子システム3500を概念的に示す。電子システム3500を使用して、上述した制御、仮想化又はオペレーティングシステムアプリケーションのいずれも実行することができる。電子システム3500は、コンピュータ(例えば、デスクトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ、サーバコンピュータ、メインフレーム、ブレードコンピュータ等)、電話、PDA又は他の何らかの種類の電子装置であってもよい。そのような電子システムは、様々な種類のコンピュータ可読媒体及び様々な他の種類のコンピュータ可読媒体に対するインタフェースを含む。電子システム3500は、バス3505、処理装置3510、システムメモリ3525、読み出し専用メモリ3530、永久記憶装置3535、入力装置3540及び出力装置3545を含む。
バス3505は、電子システム3500の多くの内部装置を通信可能に接続するシステムバス、周辺バス及びチップセットバスの全てを一括して表す。例えばバス3505は、処理装置3510を読み出し専用メモリ3530、システムメモリ3525及び永久記憶装置3535に通信可能に接続する。
これらの種々のメモリ装置から、処理装置3510は、本発明の処理を実行するために実行する命令及び処理するデータを検索する。異なる実施形態において、処理装置は単一のプロセッサ又はマルチコアプロセッサであってもよい。
読み出し専用メモリ(ROM)3530は、処理装置3510及び電子システムの他のモジュールにより必要とされる静的データ及び命令を格納する。一方、永久記憶装置3535は読み出し/書き込みメモリ素子である。当該装置は、電子システム3500の電源が入っていない場合でも命令及びデータを格納する不揮発性メモリ装置である。本発明のいくつかの実施形態は、永久記憶装置3535として大容量記憶装置(磁気ディスク又は光ディスク及び対応するディスクドライブ等)を使用する。
他の実施形態は、永久記憶装置として取り外し可能記憶装置(フロッピディスク、フラッシュドライブ等)を使用する。永久記憶装置3535と同様に、システムメモリ3525は読み出し/書き込みメモリ素子である。しかし、記憶装置3535と異なり、システムメモリはランダムアクセスメモリ等の揮発性読み出し/書き込みメモリである。システムメモリは、プロセッサが実行時に必要とする命令及びデータの一部を格納する。いくつかの実施形態において、本発明の処理は、システムメモリ3525、永久記憶装置3535及び/又は読み出し専用メモリ3530に格納される。これらの種々のメモリ装置から、処理装置3510は、いくつかの実施形態の処理を実行するために実行する命令及び処理するデータを検索する。
バス3505は、入力装置3540及び出力装置3545に更に接続する。入力装置により、ユーザは電子システムに対して情報を伝達し且つコマンドを選択することができる。入力装置3540は、英数字キーボード及びポインティング装置(「カーソル制御装置」とも呼ばれる)を含む。出力装置3545は、電子システムにより生成された画像を表示する。出力装置は、プリンタとブラウン管(CRT)又は液晶ディスプレイ(LCD)等の表示装置とを含む。いくつかの実施形態は、入力装置及び出力装置の双方として機能するタッチスクリーン等の装置を含む。
最後に、図35に示すように、バス3505は、ネットワークアダプタ(不図示)を介して電子システム3500をネットワーク3565に更に結合する。このように、コンピュータは、コンピュータのネットワーク(ローカルエリアネットワーク(「LAN」)、ワイドエリアネットワーク(「WAN」)又はイントラネット等)又はインターネット等のネットワークのネットワークの一部となり得る。電子システム3500のいずれか又は全ての構成要素が本発明と関連して使用されてもよい。
いくつかの実施形態は、マイクロプロセッサ、機械可読媒体又はコンピュータ可読媒体(又はコンピュータ可読記憶媒体、機械可読媒体又は機械可読記憶媒体とも呼ばれる)にコンピュータプログラム命令を格納する記憶装置及びメモリ等の電子部品を含む。そのようなコンピュータ可読媒体のいくつかの例は、RAM、ROM、読み出し専用コンパクトディスク(CD‐ROM)、記録可能コンパクトディスク(CD‐R)、書き換え可能コンパクトディスク(CD‐RW)、読み出し専用デジタル多用途ディスク(例えば、DVD‐ROM、2層DVD‐ROM)、種々の記録可能/書き換え可能DVD(例えば、DVD‐RAM、DVD‐RW、DVD+RW等)、フラッシュメモリ(例えば、SDカード、mini‐SDカード、micro‐SDカード等)、磁気ハードドライブ及び/又はソリッドステートハードドライブ、読み出し専用Blu‐Ray(登録商標)ディスク及び記録可能Blu‐Ray(登録商標)ディスク、超高密度光ディスク、他の何らかの光媒体又は磁気媒体、並びにフロッピディスク等を含む。コンピュータ可読媒体は、少なくとも1つの処理装置により実行可能であり且つ種々の動作を実行するための命令のセットを含むコンピュータプログラムを格納してもよい。コンピュータプログラム又はコンピュータコードの例は、コンパイラにより生成されるようなマシンコードと、インタプリタを使用してコンピュータ、電子構成要素又はマイクロプロセッサにより実行される高水準コードを含むファイルとを含む。
上記の説明はソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサを主に参照するが、いくつかの実施形態は、特定用途向け集積回路(ASIC)又はフィールドプログラマブルゲートアレイ(FPGA)等の1つ以上の集積回路により実行される。いくつかの実施形態において、そのような集積回路は、回路自体に格納されている命令を実行する。
本明細書中で使用される場合、用語「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」は全て、電子装置又は他の技術的装置を示す。これらの用語は、人間又は人間のグループを含まない。本明細書の目的のために、用語「表示する」は、電子装置上に表示することを意味する。本明細書中で使用される場合、用語「コンピュータ可読媒体」及び「機械可読媒体」は、コンピュータが読み出し可能な形態で情報を格納する有形物理物体に完全に限定される。これらの用語は、何らかの無線信号、有線ダウンロード信号及び他の何らかの一時的信号を含まない。
本明細書は、全体を通して、仮想マシン(VM)を含む計算環境及びネットワーク環境を参照する。しかし、仮想マシンは、アドレス指定可能ノードとも呼ばれるデータ計算ノード(DNC)又はデータ計算エンドノードの一例にすぎない。DCNは、非仮想化物理ホスト、仮想マシン、ハイパーバイザ又は別個のオペレーティングシステムを必要とせずにホストオペレーティングシステム上で実行するコンテナ、並びにハイパーバイザーカーネルネットワークインターフェイスモジュール等を含んでもよい。
いくつかの実施形態において、VMは、仮想化ソフトウェア(例えば、ハイパーバイザ、仮想マシンモニタ等)により仮想化されたホストのリソースを使用して、ホスト上の自身のゲストオペレーティングシステムと共に動作する。テナント(すなわち、VMの所有者)は、ゲストオペレーティングシステム上で動作させるアプリケーションを選択できる。一方、一部のコンテナは、ハイパーバイザ又は別個のゲストオペレーティングシステムを必要とせずにホストオペレーティングシステム上で実行する構造である。いくつかの実施形態において、ホストオペレーティングシステムは、異なるテナントに対するコンテナを分離し、従って、異なるコンテナ内で動作する異なるアプリケーショングループのオペレーティングシステムレベルでの分離を提供する。この分離は、ハイパーバイザ仮想化環境において提供されるVMの分離と類似するため、異なるコンテナ内で動作する異なるアプリケーショングループを分離する仮想化の一形態であると見なすことができる。そのようなコンテナはVMより軽量である。
いくつかの実施形態において、ハイパーバイザカーネルネットワークインタフェースモジュールは、ハイパーバイザカーネルネットワークインターフェースと受信/送信スレッドとを有するネットワークスタックを含む非VM DCNである。ハイパーバイザカーネルネットワークインターフェイスモジュールの一例は、VMware IncのESXハイパーバイザの一部であるvmknicモジュールである。
本明細書はVMを参照するが、記載された例は、物理ホスト、VM、非VMコンテナ及びハイパーバイザカーネルネットワークインターフェースモジュールを含む何らかの種類のDCNであり得ることが当業者には認識されるだろう。実際、いくつかの実施形態において、例示的なネットワークは異なる種類のDCNの組み合わせを含むことができる。
多くの特定の詳細を参照して本発明を説明したが、本発明の主旨から逸脱することなく本発明を他の特定の形態で実現できることが当業者には認識されるだろう。更に、多くの図面(図3、図4、図8~図10、図28、図31及び図32を含む)は処理を概念的に示す。これらの処理の特定の動作は、図示及び説明された正確な順序で実行されなくてもよい。特定の動作は、一連の動作で連続して実行されなくてもよく、異なる実施形態では異なる特定の動作が実行されてもよい。更に、処理は、いくつかのサブ処理を使用して又はより大きいマクロ処理の一部として実現され得る。従って、本発明は前述の例示的な詳細により限定されるべきでなく、むしろ添付の特許請求の範囲により定義されるべきであることが当業者には理解されるだろう。