JP2019509680A - グローバルな実現番号に基づく論理エンティティの実現状態の識別 - Google Patents

Abstract

いくつかの実施形態は、論理ネットワークの１つ以上の論理エンティティの実現状態を判定する方法を提供する。方法は、特定のイベントが発生するたびに実現番号の値をインクリメントし、インクリメントした値を、論理ネットワークのコントローラのセットに公開し、論理ネットワークの論理エンティティの状態を特定するデータを受信した場合に、方法は、論理エンティティの状態データをコントローラのセットに公開する。いくつかの実施形態では、方法は、特定の時点までコントローラのセットに公開された論理エンティティのセットに対する状態データの実現状態についてコントローラのセットに問い合わせる。 送信された問い合わせは、いくつかの実施形態では、特定の時点と関連付けられた実現番号の特定の値を含む。

Description

分散仮想ネットワーク（例えば、論理ネットワーク）において、ネットワーク機能およびサービスは、論理ネットワーク要素（例えば、論理スイッチおよび論理ルータなどの論理フォワーディング要素のセット）によって実装される。各論理ネットワーク要素（論理エンティティ）の定義は、ユーザ（例えば、ネットワーク管理者）から受信され、論理エンティティを定義するデータは、論理ネットワークの管理プレーンに格納される。そして、管理プレーンは、これらのデータを論理ネットワークの制御プレーンにプッシュして、論理エンティティを実現する（例えば、論理エンティティを構成し実装する）。現在、特定の時点でネットワーク基盤（例えば、コントローラ、ハイパーバイザ等）において、論理エンティティのセットが実現されたか否かを判断することは困難であるか不可能である。さらに、特定の時点で論理エンティティが適切に実現されない場合、問題の原因を識別する特定の方法が存在しない。

いくつかの実施形態は、論理ネットワークの論理エンティティ（例えば、論理フォワーディング要素、論理ミドルボックス等）のセットの所望の状態が、特定の時点で、ネットワークにおいて実現されるかどうかを決定するための方法およびツールを提供する。いくつかの実施形態では、本方法は、特定の時点における論理エンティティの実現状態を識別するために、論理ネットワークの制御プレーンに問い合わせる。いくつかの実施形態の方法はまた、論理エンティティの所望の状態が実現されていない物理ノード（例えば、コントローラおよび管理フォワーディング要素）を識別することができる。いくつかの実施形態では、論理ネットワークの論理エンティティの所望の状態は、論理ネットワークの管理プレーン（ＭＰ）が、（例えば、ユーザから受信した）論理ネットワークの定義に基づいて生成し、ＭＰ構成データベースに格納するデータを含む。いくつかの実施形態では、生成されたデータ（所望の状態）は、非同期に（例えば、ＭＰチャネルを介して）中央制御プレーン（ＣＣＰ）クラスタ（例えば、ＣＣＰクラスタの１つ以上の中央コントローラ）にプッシュされる。

ＣＣＰクラスタは、受信したデータを、ＣＣＰクラスタが論理エンティティを実装する１つ以上の管理フォワーディング要素（ＭＦＥ）から受信した論理エンティティのための対応するランタイムデータと共に処理する。いくつかの実施形態は、各論理エンティティがホストマシンのハイパーバイザ上で動作するＭＦＥ上の論理エンティティを構成するために、ＣＣＰクラスタが処理された構成データを（例えば、其々が対応するＭＦＥを制御するローカルコントローラのセットを通して）ＭＦＥへプッシュダウンする場合に、（すなわち、１つ以上の論理ネットワークが実装される物理ネットワーク基盤において）論理エンティティがシステム上で実現されると判定する。いくつかの実施形態は、論理エンティティがＭＦＥ上で実際に構成される場合に、論理エンティティがシステム内で実現されると判定する。

論理エンティティの実現状態は、論理エンティティの所望の状態とは異なり、一時的なシステム状態を扱う。すなわち、論理エンティティの実現状態は、システムが所望の状態に収束しようとする際に連続的に変化している。換言すれば、システムの環境（例えば、データセンタ）が変化する（例えば、仮想マシンが移行する、ハイパーバイザが失敗する等）につれて、実現状態はいつも実現しない状態になるかもしれない。いくつかの実施形態では、論理エンティティの実現状態はまた、論理ネットワークの制御プレーンで受信されたランタイムデータ（例えば、仮想ネットワークインタフェースのＬ２およびＬ３アドレス）によって変更（更新）することができる。

論理エンティティが実現されることを確実にするために、論理エンティティを作成した後に、論理エンティティ（例えば、論理スイッチ、論理スイッチポート、論理ルータ等）の状態を問い合わせる代わりに、いくつかの実施形態は、時間の異なるインスタンスにおいて１つ以上の論理エンティティの実現状態をユーザが一緒に問い合わせることができるようにする実現判定ツールを提供する。すなわち、複数の論理エンティティが論理ネットワークに追加された場合、エンティティがシステム内で実現されることを確実にするために各論理エンティティの状態を問い合わせる代わりに、ユーザは、特定の時点までＣＣＰクラスタに公開されている全ての論理エンティティ（または論理エンティティの特定のセット）の実現状態を決定するために制御プレーンに（例えば、管理プレーンを介して）問い合わせる。

そうするために、いくつかの実施形態は、実際にＣＣＰクラスタにおける論理エンティティの所望の状態の実現を追跡する状態同期バリアであるクラスタ領域単調増加値を提供する。このグローバル実現番号（ＧＲＮ）は、いくつかの実施形態では、異なる時点で（例えば、ある時間間隔で自動的に、ユーザ要求ごとに手動で、またはあらゆる所望の状態更新ごとに）インクリメントされる。管理プレーンは、所望の状態をＣＣＰクラスタに公開することに加えて、ＧＲＮがインクリメントされるたびに新しいＧＲＮ値をＣＣＰクラスタに公開する。ＣＣＰクラスタは、そして、ＧＲＮ値が受信される時点まで、受信したＧＲＮ値を、ＣＣＰクラスタに公開される異なる論理エンティティの実現状態に関連付ける。いくつかの実施形態では、ＣＣＰクラスタはまた、ＧＲＮを、制御プレーンがＭＦＥから受信した論理エンティティの対応するランタイム状態に関連付ける。

いくつかの実施形態の管理プレーンは、その後、最新のＧＲＮまたは（例えばユーザによって与えられる）任意の特定のＧＲＮ（例えば、ユーザによって特定された）までＣＣＰクラスタに公開される、論理エンティティの特定のセットの実現状態を要求することができる。いくつかの実施形態はまた、最新のＧＲＮまたは任意の特定のＧＲＮまでＣＣＰクラスタに公開されるすべての論理エンティティの実現状態を提供する。例えば、ユーザが論理経路に沿った複数の論理要素（例えば、論理スイッチおよびルータ）を有する論理経路を定義する場合、論理経路の実現状態は、その経路に沿った各論理要素の実現に依存する。このように、論理経路の実現状況を識別するために、ユーザは、経路が定義された後に公開されるＧＲＮ値において経路の実現状態を問い合わせることができる。

そうするために、ユーザ（例えば、ネットワーク管理者）は、論理ルートが定義された後にＧＲＮのインクリメントを（例えば、ＧＲＮのインクリメント関数を呼び出すことによって）要求することができる。このような要求は、ＧＲＮをインクリメントし、そして要求がなされた時点でインクリメントされたＧＲＮ値を論理エンティティの実現状態に関連付けるだけでなく、インクリメントされたＧＲＮ値をユーザに返す。そしてユーザは、受信したＧＲＮ値まで論理経路の実現状態についてＣＣＰクラスタに問い合わせることができる。

ＣＣＰノード（例えば、コントローラ）が最後に処理した各ＧＲＮについて、ＣＣＰノードは、ＣＣＰノードが管理する各ＭＦＥ（例えば、ＣＣＰノードがマスタであるＭＦＥ）上の論理エンティティの実現状態を把握している。従って、ユーザが特定のＧＲＮにおける所望の論理オブジェクトの実現状態を求める（すなわち、ユーザが特定のＧＲＮにおける実現状態についてＭＰに問い合わせる）場合、いくつかの実施形態のＣＣＰクラスタは、特定のＧＲＮまで全ての論理エンティティの状態を返すことによって応答する。応答において、ＣＣＰクラスタは、論理エンティティをまだ実現していない任意のＭＦＥ（例えば、ＭＦＥを実行するハイパーバイザ）を含める。例えば、ハイパーバイザのサブセットに配布された分散ファイアウォール（ＤＦＷ）のルールセクション（すなわち、ルールセクションが依存する論理スイッチおよびルータが及ぶハイパーバイザのサブセット）に対して、ＣＣＰノードは、問い合わせに対する返信において、論理フォワーディング要素を実装するハイパーバイザのサブセットの状態を含める。いくつかの実施形態では、ＣＣＰノードは、返信において、論理エンティティが実現されていないハイパーバイザのみを含める。

いくつかの実施形態のＣＣＰクラスタ（例えば、ＣＣＰクラスタ内の１つ以上のＣＣＰノード）は、（論理エンティティの実現状態の問い合わせに応答して）論理エンティティの実現状態についてのメッセージを返す。いくつかの実施形態では、返されるメッセージは、成功メッセージ、不成功メッセージ、または進行中メッセージであり得る。成功状態は、いくつかの実施形態では、ＣＣＰクラスタが受信した所望の状態を処理したこと、および、処理したデータをローカル制御プレーン（例えば、同じホストマシン内のＭＦＥと並んで動作する１つ以上のローカルコントローラ）にプッシュしたことを示す。いくつかの実施形態では、ＭＰがＧＲＮをインクリメントするたびに、ＭＰはインクリメントされたＧＲＮをＣＣＰクラスタと同期させる。いくつかの実施形態では、コントローラノードの１つ（例えば、シャーディングマスタコントローラ）が、同じＧＲＮを、ＣＣＰクラスタのコントローラに保持されている現在のランタイム状態に割り当てる。いくつかの実施形態では、ＣＣＰクラスタが、特定のＧＲＮ値に対する論理エンティティの所望の状態と対応するランタイム状態の両方を処理した場合、ＧＲＮの特定の値に対する実現状態は成功したと考慮される。

いくつかの実施形態では、成功メッセージは、論理エンティティの所望の状態（および対応するランタイム状態）がＣＣＰクラスタによって処理されそして公開されたことだけでなく、論理エンティティが論理エンティティを実装する１つ以上のＭＦＥ（ホストマシンまたはゲートウェイ上で動作する）上で成功裏に構成されたことを示す。例えば、いくつかのこのような実施形態では、論理スイッチの実現状態に対する成功応答は、論理スイッチを実装する１つ以上のＭＦＥ（例えば、１つ以上のホストマシンのハイパーバイザで）が、論理スイッチと論理的に接続される１つ以上の仮想マシンと成功裏に接続されることを意味する。さらにこのことは、ＭＦＥが、論理スイッチについて、制御プレーン（例えば、論理スイッチのマスタコントローラ）および管理プレーン（例えば、論理スイッチのマスタマネージャ）とアクティブな通信を有することを意味する。

いくつかの実施形態では、論理エンティティの状態に対する不成功の実現応答は、異なる理由を有してよい。例えば、１つ以上のＣＣＰノードが所望の状態更新の処理において遅れた場合、ＣＣＰノードは、所望の状態の実現不成功を返し得る。論理エンティティの所望の状態の実現不成功に対する他の理由は、１つ以上のＭＦＥが、ＧＲＮの特定の値に対する何らかの変更の実装に失敗したことを明示的に示す場合、１つ以上のＭＦＥが所望の状態更新頻度の維持から遅れた場合、いくつかのＭＦＥが長時間にわたって未接続となった場合等、を含む。

いくつかの実施形態は、クラスタリングイベント、スライス再割り当てを識別するため、またはＭＰデータベースがインストールおよび/または復元されたときに、（例えば、ＧＲＮ内の）世代番号を提供する。いくつかの実施形態では、世代番号は、クラスタリングイベントまたはスライス再割り当てが起こるたびに、または管理プレーンデータベースが復元されるたびにインクリメントされる。いくつかの実施形態では、このようなインクリメントは、（例えば、新たなクラスタリングイベントのそれぞれにより）自動的に生じる。いくつかの実施形態では、ユーザは（例えば、ＭＰデータベースのバックアップバージョンが復元されたときなど）世代番号を（手動で）インクリメントしてもよい。

いくつかの実施形態では、ＭＰは、世代番号が全てのＣＣＰノード間で同期されることを確実にするために、（例えば、リモートプロシージャーコールを介して）ＣＣＰクラスタに問い合わせる。このようないくつかの実施形態では、各ＣＣＰノードは、最新の世代番号を有するクエリに応答する。世代番号が全ての応答にわたって同一でない場合、ＭＰは、最近起こったクラスタリングの変更がまだＣＣＰノードのいくつかで処理されていないと結論付けることができる。いくつかの実施形態では、ユニバーサル固有識別子（ＵＵＩＤ）は、世代番号とＧＲＮの両方を含む（例えば、ＧＲＮと世代番号の両方が単一の６４ビットＵＵＩＤに符号化されてよく、ここでＵＵＩＤの上位１６ビットは世代番号を保持し、下位４８ビットはＧＲＮを保持する）。

いくつかの実施形態は、所望の状態の実現における様々な問題の原因を識別するのに役立つトラブルシューティングのデータを提供する。いくつかの実施形態は、識別された問題の性質および場所に基づいて、問題の論理エンティティに対して異なるレベルの詳細を提供する。いくつかの実施形態は、実現された状態にならない特定の論理要素に関するトラブルシューティングのデータを提供する。

先行するサマリは、本発明のいくつかの実施形態に対する簡単な導入として提供されることを意図するものである。本書面において開示される発明の主題の全ての導入又は概要を意味するものではない。以下の詳細な説明および詳細な説明において参照される図面は、他の実施形態とサマリにおいて説明された実施形態を更に説明するであろう。従って、本書面によって説明される全ての実施形態を理解するため、サマリ、詳細な説明及び図面の十分な確認が必要である。更に、クレームされる主題は、主題の思想から離れることなく他の具体的な形態で具現化することができるため、クレームされる主題は、サマリ、詳細な説明及び図面における詳細な例によって限定されず、むしろ添付された特許請求の範囲によって定義されるべきである。

本発明の新規な特徴は添付の特許請求の範囲によって明らかになる。しかしながら、説明の目的のため、本発明のいくつかの実施形態は以下の図において明らかになる。

論理ネットワークのための論理エンティティのセットの生成および公開を示す。

グローバル実現番号（ＧＲＮ）を使用して論理ネットワークの論理エンティティの実現状態を追跡するユーザを示す。

分散ファイアウォールルールを生成し、ファイアウォールルールの実現状態を（例えば、管理プレーンを介して）制御プレーンに問い合わせる例を示す。

ある時間間隔で自動的にＧＲＮ値を更新する、いくつかの実施形態におけるＧＲＮを更新（インクリメント）する１方法を示す。

中央管理プレーンクラスタと、中央制御プレーンクラスタと、データセンタ等のホスティングシステム内のホストマシンのセットとの間の関係を概念的に示す。

特定のＧＲＮについてＣＣＰクラスタに問い合わせ、プロセスがＣＣＰクラスタから受信する応答に基づいて論理エンティティの実現状態をレポートする、いくつかの実施形態の処理を概念的に示す。

特定のＧＲＮにおける１つ以上の論理エンティティの実現状態に関するクエリを受信した後に、いくつかの実施形態の制御プレーンが返す応答の例を示す。

特定のＧＲＮにおける１つ以上の論理エンティティの実現状態に関するクエリを受信した後に、いくつかの実施形態の制御プレーンが返す応答の他の例を示す。

本発明のいくつかの実施形態が実装される電子システムを概念的に示す。

本発明の以下の詳細な説明では、本発明の多くの詳細、例、および実施例が説明され、記載される。しかしながら、本発明は、説明された実施形態に限定されず、本発明は、いくつかの説明された特定の詳細および例なしに実施されてよいことが理解されるべきである。

いくつかの実施形態は、論理ネットワークの論理エンティティ（例えば、論理フォワーディング要素、論理ミドルボックス等）のセットの所望の状態が、特定の時点で、ネットワークにおいて実現されるかどうかを決定するための方法およびツールを提供する。いくつかの実施形態では、本方法は、特定の時点における論理エンティティの実現状態を識別するために、論理ネットワークの制御プレーンに問い合わせる。いくつかの実施形態の方法はまた、論理エンティティの所望の状態が実現されていない物理ノード（例えば、コントローラおよび管理フォワーディング要素）を識別することができる。いくつかの実施形態では、論理ネットワークの論理エンティティの所望の状態は、論理ネットワークの管理プレーン（ＭＰ）が、（例えば、ユーザから受信した）論理ネットワークの定義に基づいて生成し、ＭＰ構成データベースに格納するデータを含む。いくつかの実施形態では、生成されたデータ（所望の状態）は、非同期に（例えば、ＭＰチャネルを介して）中央制御プレーン（ＣＣＰ）クラスタ（例えば、ＣＣＰクラスタの１つ以上の中央コントローラ）にプッシュされる。

ＣＣＰクラスタは、受信したデータを、ＣＣＰクラスタが論理エンティティを実装する１つ以上の管理フォワーディング要素（ＭＦＥ）から受信した論理エンティティのための対応するランタイムデータと共に処理する。いくつかの実施形態は、ＭＦＥ上の論理エンティティを構成するために、ＣＣＰクラスタが処理された構成データを（例えば、其々が対応するＭＦＥを制御するローカルコントローラのセットを通して）ＭＦＥへプッシュダウンする場合に、（すなわち、１つ以上の論理ネットワークが実装される物理ネットワーク基盤において）論理エンティティがシステム上で実現されると判定する。いくつかの実施形態は、論理エンティティがＭＦＥ上で実際に構成される（いくつかの実施形態ではトランスポートノードとしても参照される）場合に、論理エンティティがシステム内で実現されると判定する。

論理エンティティの実現状態は、論理エンティティの所望の状態とは異なり、一時的なシステム状態を扱う。すなわち、論理エンティティの実現状態は、システムが所望の状態に収束しようとする際に連続的に変化している。換言すれば、システムの環境（例えば、データセンタ）が変化する（例えば、仮想マシンが移行する、ハイパーバイザが失敗する等）につれて、実現状態はいつも実現しない状態になるかもしれない。いくつかの実施形態では、論理エンティティの実現状態はまた、論理ネットワークの制御プレーンで受信されたランタイムデータ（例えば、仮想ネットワークインタフェースのＬ２およびＬ３アドレス）によって変更（更新）することができる。

論理エンティティが実現されることを確実にするために、論理エンティティを作成した後に、論理エンティティ（例えば、論理スイッチ、論理スイッチポート、論理ルータ等）の状態を問い合わせる代わりに、いくつかの実施形態は、時間の異なるインスタンスにおいて１つ以上の論理エンティティの実現状態をユーザが一緒に問い合わせることができるようにする実現判定ツールを提供する。すなわち、複数の論理エンティティが論理ネットワークに追加された場合、エンティティがシステム内で実現されることを確実にするために各論理エンティティの状態を問い合わせる代わりに、ユーザは、特定の時点までＣＣＰクラスタに公開されている全ての論理エンティティ（または論理エンティティの特定のセット）の実現状態を決定するために制御プレーンに（例えば、管理プレーンを介して）問い合わせる。

いくつかの実施形態では、論理ネットワークは、ネットワークの異なる論理パス上に配置される論理エンティティのセットを含む。論理ネットワークにおける論理エンティティの例は、論理Ｌ２スイッチおよび論理Ｌ３ルータなどの論理フォワーディング要素（ＬＦＥ）、論理ファイアウォールおよび論理ロードバランサなどの論理ミドルボックスなどを含む。論理ネットワークエンティティはまた、いくつかの実施形態では、送信元または宛先のデータ計算ノード（ＤＣＮ）およびトンネルエンドポイント（例えば、ＭＦＥによって実装される）を含む他のネットワーク要素を含む。ＤＣＮまたはトンネルエンドポイントが、典型的に単一のホストマシン（またはゲートウェイ）上で動作する一方で、論理フォワーディング要素または論理ミドルボックスは、異なるマシン上で動作するいくつかの異なるＭＦＥ（例えば、ソフトウェアおよび/またはハードウェア管理フォワーディング要素）にまたがる。

論理ネットワークの論理フォワーディング要素は、異なるホストマシン上で動作するいくつかの異なるＤＣＮ（例えば、仮想マシン（ＶＭ）、コンテナ、物理マシン等）を、相互に、および他の論理および/または物理ネットワークに論理的に接続する。いくつかの実施形態では、ＤＣＮを論理的に接続する論理フォワーディング要素は、ホスティングシステム（例えば、データセンタ）のユーザ（例えば、テナント）のための論理ネットワークトポロジを定義する。いくつかの実施形態では、ＤＣＮの異なるサブセットは、ソフトウェア管理フォワーディング要素（ＭＦＥ）を実行する異なるホストマシン上に存在する。各ＭＦＥは、ホストマシン上で動作し、ホストマシン上で実行されるＤＣＮのサブセットが論理的に接続されている論理ネットワークのＬＦＥを実装する。

ソフトウェアＭＦＥは、いくつかの実施形態では、ホストマシンの仮想化ソフトウェア（例えば、ハイパーバイザ）においてインスタンス化されるソフトウェアインスタンスである。いくつかの実施形態では、ホストマシン上でＬＦＥを実装することは、ＭＦＥが動作するホストマシン上に存在するＤＣＮのセットから送信された、および/またはこれを宛先とするパケットに対するネットワークトラフィックフォワーディング処理を実行することを含む。ハードウェアＭＦＥに接続されている物理マシン（サーバ、ホストマシン等）を論理ネットワークの他のＤＣＮに論理的に接続するために、ＬＦＥはまた、１つ以上のハードウェアＭＦＥ（たとえばトップオブランク（Top of Rack）（ＴＯＲ）スイッチ）によって実装される。さらに、特定の物理ホストマシンが複数の論理ネットワークの（例えば、異なるテナントに属する）ＤＣＮをホストしてもよいため、ホストマシン（またはハードウェアＭＦＥ）上で実行されるソフトウェアＭＦＥは、異なる論理ネットワークに属すＬＦＥの異なるセットを実装するために、仮想化されてよい。

いくつかの実施形態では、中央管理プレーン（ＣＭＰ）クラスタ（例えば、ＣＭＰクラスタ内のマスタマネージャ）は、論理ネットワークトポロジのための論理オブジェクトデータを生成する。いくつかの実施形態では、ユーザ（例えば、ネットワーク管理者）は、アプリケーションプログラミングインターフェイス（ＡＰＩ）コールを介して、論理ネットワーク定義（例えば論理ネットワークトポロジ）をＣＭＰクラスタに提供する。ＣＭＰクラスタは、受信した論理ネットワーク定義に基づいて、（論理スイッチ、論理ルータ、論理ミドルボックスなどを定義することによって）論理エンティティデータを生成し、生成したデータ（すなわち、論理エンティティの所望の状態）を管理プレーンデータベースに格納する。

いくつかの実施形態のＣＭＰクラスタはまた、中央制御プレーン（ＣＣＰ）クラスタ内の１つ以上のコントローラに所望の状態をプッシュする。ＭＦＥ（例えば、ホストマシンおよびゲートウェイマシンで動作するＭＦＥ）はまた、ＭＦＥが実装する論理エンティティ（すなわち、論理エンティティの発見された状態）に関するランタイムデータを、ＣＣＰクラスタにプッシュする。典型的なランタイムデータは、いくつかの実施形態では、仮想トンネルエンドポイント（ＶＴＥＰ）テーブル、メディアアクセス制御（ＭＡＣ）テーブル、アドレス解決プロトコル（ＡＲＰ）テーブルなどのレイヤ２制御プレーンテーブルと、ルーティング情報ベース（ＲＩＢ）テーブル、フォワーディング情報ベース（ＦＩＢ）テーブルなどのレイヤ３ルーティングテーブルと、ＭＦＥから集められた統計データとを含む。

ＣＣＰクラスタは、ＭＦＥ上の論理エンティティを構成するため（すなわち、システム内の論理エンティティを実現するため）に、ＭＦＥから受信したランタイムデータ（すなわち、発見された状態）とともに、管理プレーンから受信した論理エンティティの定義データ（すなわち、所望の状態）を処理する。換言すれば、論理ネットワークの１つ以上の論理エンティティに対する処理済みの構成データと、ＣＣＰクラスタに格納された対応するランタイムデータとが、論理エンティティの実現状態を構成する。そして、ＣＣＰクラスタは、論理エンティティの実現状態をホストマシン（およびゲートウェイ）にプッシュダウンする。いくつかの実施形態は、ＣＣＰクラスタ（例えば、ＣＣＰクラスタ内のコントローラ）が処理済みの構成データをＭＦＥにプッシュダウンする場合に、論理エンティティの所望の状態が実現されると判定する。いくつかの実施形態は、構成データがコントローラによって処理されて配信されるだけでなく、論理エンティティを実装するＭＦＥ上に実際に構成された論理エンティティでもあるとき、論理エンティティの状態が実現されると判定する。

ホストマシンに配信される構成データは、論理エンティティを実装するためにホストマシン上で動作するＭＦＥの共通のフォワーディング動作を定義する。いくつかの実施形態では、（例えば、ホストマシンのハイパーバイザ内の）各ホストマシン上で動作するローカルコントローラは、まずＣＣＰクラスタから構成データを受信する。次に、ローカルコントローラは、ローカルコントローラが動作するのと同一のホストマシン上で動作する各ＭＦＥの特定のフォワーディング動作を定義する、カスタマイズされた構成データを生成する。ＣＣＰクラスタは、異なるＭＦＥ間の論理ネットワークトラフィックの通信を容易にするために、各ＭＦＥに実装された論理エンティティの実現状態を、論理エンティティを実装する他のＭＦＥと共有する。

要約すると、論理ネットワークのＭＦＥ（すなわち管理フォワーディング要素）は、論理エンティティのランタイム状態または発見された状態の送信元であり、ＭＰは、論理エンティティの所望の状態の送信元である。ＣＣＰクラスタは、論理エンティティを実現するためにこれら２つの状態を処理（結合）します。ローカルコントローラは、それらの対応するＭＦＥ上の論理ネットワークの論理エンティティを構成するために、ＣＣＰクラスタから実現状態を受信する。

現在、（ユーザが生成した）論理エンティティのセットの所望の状態がネットワーク基盤（例えば、ＣＣＰクラスタおよびＭＦＥ）において実現されたかどうかを、ユーザが判定することは困難または時には不可能である。図１は、論理ネットワークのための論理エンティティのセットの生成および公開を示す。より具体的には、この図は、１つ以上の論理エンティティを生成し、これらの論理エンティティを制御プレーンに公開するために、ユーザがどのように管理プレーンに（ＡＰＩ呼び出しなどを介して）要求することができるか示す。図１は、マネージャ１１０（例えば、中央管理プレーンクラスタ内のマネージャコンピュータまたはアプリケーション）、所望状態トランザクションキュー１２０、コントローラ１３０（例えば、ＣＣＰクラスタ内のコントローラコンピュータまたはアプリケーション）、および所望状態のトランザクションが制御プレーンにおいて処理（実現）されるか否かを示す実現状態キュー１４０を含む。

この図は、マネージャ１１０が、（例えば、ユーザＡＰＩ要求を介して）論理スイッチＬＳ１、論理スイッチＬＳ１の論理ポートＬＰ１、論理スイッチＬＳ２、および論理スイッチＬＳ２の論理ポートＬＰ２を生成したことを示す。しかしながら、マネージャがＬＰ２を作成する前に、論理ポートＬＰ１を変更する変更要求１５０が所望状態トランザクションキュー１２０で受信される。この変更要求は、ユーザから受信されてもよいし、論理ネットワークまたは論理ネットワークを実装する物理基盤における（例えば、ランタイムデータ内の）変更を介して受信されてもよい。

この図はまた、マネージャ１１０が（例えば、ＣＣＰハンドラモジュールを介して）ＣＣＰクラスタに所望の状態を公開する場合、生成された論理エンティティの全てが、論理ポートＬＰ１の変更を除いてコントローラ１３０において実現されることを示す。換言すれば、論理ポートＬＰ１は、生成されて、ある時点で制御プレーン内に実現されるが、ＬＰ１の変更は制御プレーンでは実現されていない。ＣＣＰクラスタが、異なる段階で論理エンティティの状態を維持する機構を有していない限り、これらの異なる段階での論理エンティティの実現状態を判定することは、ほぼ不可能である。

論理エンティティの状態を維持するために、いくつかの実施形態は、実際にＣＣＰクラスタにおける論理エンティティの所望の状態の実現を追跡する状態同期バリアである、クラスタ領域単調増加値を提供する。このグローバル実現番号（ＧＲＮ）は、いくつかの実施形態では、異なる時点で（例えば、ある時間間隔で自動的に、ユーザ要求ごとに手動で、またはあらゆる所望の状態更新ごとに）インクリメントされる。管理プレーンは、所望の状態をＣＣＰクラスタに公開することに加えて、ＧＲＮがインクリメントされるたびに新しいＧＲＮ値をＣＣＰクラスタに公開する。ＣＣＰクラスタは、そして、ＧＲＮ値が受信される時点まで、受信したＧＲＮ値を、ＣＣＰクラスタに公開される異なる論理エンティティの実現状態に関連付ける。いくつかの実施形態では、ＣＣＰクラスタはまた、ＧＲＮを、制御プレーンがＭＦＥから受信した論理エンティティの対応するランタイム状態に関連付ける。

いくつかの実施形態の管理プレーンは、その後、最新のＧＲＮまたは（例えばユーザによって与えられる）任意の特定のＧＲＮ（例えば、ユーザによって特定された）までＣＣＰクラスタに公開される、論理エンティティの特定のセットの実現状態を要求することができる。いくつかの実施形態はまた、最新のＧＲＮまたは任意の特定のＧＲＮまでＣＣＰクラスタに公開されるすべての論理エンティティの実現状態を提供する。例えば、ユーザが論理経路に沿った複数の論理要素（例えば、論理スイッチおよびルータ）を有する論理経路を定義する場合、論理経路の実現状態は、その経路に沿った各論理要素の実現に依存する。このように、論理経路の実現状況を識別するために、ユーザは、経路が定義された後に公開されるＧＲＮ値において経路の実現状態を問い合わせることができる。

そうするために、ユーザ（例えば、ネットワーク管理者）は、論理ルートが定義された後にＧＲＮのインクリメントを（例えば、ＧＲＮのインクリメント関数を呼び出すことによって）要求することができる。このような要求は、ＧＲＮをインクリメントし、そして要求がなされた時点でインクリメントされたＧＲＮ値を論理エンティティの実現状態に関連付けるだけでなく、インクリメントされたＧＲＮ値をユーザに返す。そしてユーザは、受信したＧＲＮ値まで論理経路の実現状態についてＣＣＰクラスタに問い合わせることができる。

図２は、グローバル実現番号（ＧＲＮ）を使用して論理ネットワークの論理エンティティの実現状態を追跡するユーザを示す。具体的には、この図は、ユーザが異なるＧＲＮ値を使用して、論理ネットワークの論理スイッチ用に生成した論理ポートの実現を追跡することを示している。マネージャ１１０は、図１のマネージャ１１０と同様に、論理スイッチＬＳ１、論理スイッチＬＳ１の論理ポートＬＰ１、論理スイッチＬＳ２、および論理スイッチＬＳ２の論理ポートＬＰ２を保持する所望状態トランザクションキュー１２０を含む。所望状態トランザクションキュー１２０はまた、論理ポートＬＰ２を受信する前に、論理ポートＬＰ１への変更１５０を受信している。

しかしながら、図１とは異なり、この図は、所望状態トランザクションキュー１２０における各所望の状態の更新後にＧＲＮの値をインクリメントし、インクリメントした値をコントローラ１３０に公開するＧＲＮジェネレータモジュール２１０を、マネージャ１１０が含むことを示す。図４を参照して以下に更に説明するように、各所望の状態の更新後にＧＲＮ値をインクリメントし、インクリメントされたＧＲＮを公開することは、いくつかの実施形態の管理プレーンが実行する制御プレーンへのＧＲＮの公開の１つの方法に過ぎない。

いくつかの実施形態では、管理プレーンがユーザ要求を受信する場合にＧＲＮ値をインクリメントするが、他のいくつかの実施形態では、ＧＲＮ値は、（例えば、ユーザによって調整することができる）ある時間間隔で自動的にインクリメントされる。さらにいくつかの他の実施形態では、ＧＲＮ値は、前述の３つの方法のうちの２つまたは全てを使用してインクリメントされ、制御プレーンに公開され得る。すなわち、ＧＲＮ値が予め設定された時間間隔でインクリメントされて公開される一方、所望の状態への更新が発生した場合、管理プレーンはＧＲＮ値をインクリメントし、それを制御プレーンに公開する。さらに、ユーザは、ＧＲＮ値のインクリメントおよび公開を手動で強制することができる。

図２では、各所望の状態の更新後に、ＧＲＮジェネレータ２１０はＧＲＮの値をインクリメントし、コントローラ１３０に新しい値を公開する。図が示すように、論理スイッチＬＳ１を実現状態キュー１４０に公開した後、ＧＲＮジェネレータ２１０はＧＲＮの値をＧからＧ１にインクリメントし、この新しい値をコントローラ１３０に公開した。同様に、論理ポートＬＰ１、論理スイッチＬＳ２、および論理ポートＬＰ１への変更のそれぞれの公開の後に、新らたな値Ｇ２、Ｇ３、およびＧ４が生成され、コントローラ１３０に公開される。この図はまた、（実現状態キュー１４０のＬＰ１上のバツ印が示すように）論理ポートＬＰ１への変更がシステム内で実現されていないことを示す。

最後に、図は、ユーザ３０がＧＲＮ値Ｇ４における論理ポートＬＰ１の実現状態について、管理プレーンに問い合わせを発行したことを示している。このクエリに応答して、管理プレーンは制御プレーンに同じことを問い合わせ、ユーザに「実現されていない」応答を返す。したがって、ユーザは、論理ポートＬＰ１への変更が失敗し、システム内で実現されていないことを識別する。次に、ユーザは、ＧＲＮ値Ｇ３における（これは、ポートの変更前のある時点におけるこのポートの実現状態を示す）ＬＰ１の実現状態をもう一度管理プレーンに問い合わせる。今度は、管理プレーンは、ＧＲＮがＧ３におけるものを示すクエリに応答して、（制御プレーンに問い合わせた後に）「実現」を返す。上記２つのクエリから、ユーザは、論理ポートＬＰ１が生成された後にシステム内で実現されるが、論理ポートが変更された後は実現されなかったと結論付けることができる。図示するように、ユーザは、異なるＧＲＮ値を用いることによって、異なる時点で論理ポートＬＰ１を追跡することができる。

上述したように、ＣＣＰノード（例えば、コントローラ）が最後に処理した各ＧＲＮについて、ＣＣＰノードは、ＣＣＰノードが管理する各ＭＦＥ（例えば、ＣＣＰノードがマスタであるＭＦＥ）上の論理エンティティの実現状態を把握している。すなわち、ＣＣＰノードが論理エンティティの所望の状態とランタイム状態を受信した場合、ＣＣＰノードは、ネットワークの特定のＭＦＥのセットに対してのみ論理エンティティを構成する責任を負う。この特定のＭＦＥのセット（すなわち、ＭＦＥが動作するハイパーバイザ）は、いくつかの実施形態では、ネットワーク管理者によって割り当てられる。代替的に、または結合的に、いくつかの実施形態では、ＣＣＰノードが管理するハイパーバイザのセットは、マネージャコンピュータまたはシャーディングコントローラによって自動的に割り当てられ、ＣＣＰノードのワークロードに基づく。

従って、ユーザが特定のＧＲＮにおける所望の論理オブジェクトの実現状態を求める（すなわち、ユーザが特定のＧＲＮまで実現状態についてＭＰに問い合わせる）場合、いくつかの実施形態のＣＣＰクラスタは、特定のＧＲＮまで全ての論理エンティティの状態を返すことによって応答する。応答において、ＣＣＰクラスタは、論理エンティティをまだ実現していない任意のＭＦＥ（例えば、ＭＦＥを実行するハイパーバイザ）を含める。例えば、ハイパーバイザのサブセットに配布された分散ファイアウォール（ＤＦＷ）のルール（すなわち、ファイアウォールのルールが依存する論理スイッチおよびルータが及ぶハイパーバイザのサブセット）に対して、ＣＣＰノードは、問い合わせに対する返信において、論理フォワーディング要素を実装するハイパーバイザのサブセットの状態を含める。いくつかの実施形態では、ＣＣＰノードは、返信において、論理エンティティが実現されていないハイパーバイザのみを含める。

図３は、分散ファイアウォールルールを生成し、ファイアウォールルールの実現状態を（例えば、管理プレーンを介して）制御プレーンに問い合わせる例を示す。図は、ユーザ３１０が（例えば、ＡＰＩ呼び出しを介して）２つの論理スイッチを作成し、その後に論理スイッチに依存する論理ファイアウォール３２０を作成することを示す。より具体的には、ユーザは、第１の論理スイッチＬＳ１、第１の論理スイッチ用の第１の論理ポートＬＰ１、第２の論理スイッチＬＳ２、第２の論理スイッチ用の第２の論理ポートＬＰ２、および論理ファイアウォールＦＷを作成した。次に、ユーザは、論理スイッチＬＳ１から論理スイッチＬＳ２への任意のネットワークトラフィックをブロックすべきことを指定するファイアウォールルール３２０をファイアウォールＦＷに追加した。図示されるように、ファイアウォールルール３２０は、論理スイッチＬＳ１の送信元アドレス（例えば、ＩＰアドレス）とＬＳ２の宛先アドレスとを有する任意のパケットがシステム内でブロックされるべきであることを指定する。

ユーザは、この時点で（すなわち、ファイアウォールルールが追加された後）、論理ファイアウォールがシステム内で実現されているかどうかを判定できるようになることを望む。図示された例が示すように、単一の分散ファイアウォール（ＤＦＷ）ルールの実現は、多くの論理スイッチ、それらのポート、および図示されていない他のネットワーク要素（例えば、論理ルータへの接続、論理ルーターポートに構成されるＩＰプレフィックス、スプーフィングガード構成、コンテナ構成等）に依存してもよい。このように、ＤＦＷルールの実現の状況を識別するために、ユーザは、ルールが依存する全ての論理エンティティの実現状態を判定するために、ＤＦＷルールの作成後にＧＲＮについて問い合わせることができる。

この例では、管理プレーンは、それぞれの状態更新の後にＧＲＮ値をインクリメントする。したがって、各所望の状態の公開後に、ＧＲＮの新しいインクリメントされた値も制御プレーンに公開される。すなわち、インクリメントされた値Ｇ１、Ｇ２、Ｇ３、およびＧ４は、それぞれ論理エンティティＬＳ１、ＬＰ１、ＬＳ２およびＬＰ２に関連付けられる。しかし、論理ポート３３０上のバツ印が示すように、ファイアウォールルールが依存するすべての論理エンティティは、論理ポートＬＰ２を除いてシステム内で実現される。このように、ユーザ３１０がＧＲＮがＧ４におけるファイアウォールＦＷの実現状態をシステムに問い合わせる場合、いくつかの実施形態では、管理プレーンは、論理ポートＬＰ２が実現されていない唯一の論理エンティティであることを示すことによって応答する。

いくつかの他の実施形態は、それらが実現状態のレポートを提供する場合に、そのような粒度のレベルを提供しない。代わりに、そのような実施形態のいくつかは、１つ以上の論理エンティティが適切に実現されていない物理ノード（例えば、ホストマシン、ゲートウェイマシン等）に関する情報を提供する。図示した例では、ＤＦＷルールの実現状態が問い合わせられた場合、いくつかの実施形態は、実現されていない論理ポートＬＰ２を実装する１つ以上の物理ノード（すなわち、１つ以上のＭＦＥ）を識別するレポートを提供する。以下においてより詳細に説明するように、論理要素は制御プレーンに公開され得るが、論理エンティティを実装する物理ノードのセット内の１つ以上の物理ノードでは実現されない。すなわち、上述したように、論理エンティティは、いくつかの異なる物理ノード（すなわち、物理ノード上で実行するいくつかの異なるＭＦＥ）に及ぶ。したがって、論理エンティティは異なる物理ノードにプッシュされてもよいが、物理ノードのサブセットでは実現されない。いくつかの実施形態は、論理エンティティが適切に実現されていない物理ノードのサブセット（および/またはノードのサブセットで実行されるＭＦＥ）のみをレポートする。

いくつかの実施形態では、管理プレーンが特定の論理エンティティが実現されていないとレポートした場合、そのようなレポートは必ずしも論理エンティティが失敗した（そして例えば再生成されるべきである）ことを意味しない。いくつかの実施形態は、論理エンティティの実現処理が特定の時点で制御プレーンによって完了されていないため、その時点で単に論理エンティティが実現されないことを報告する。したがって、後にユーザーが新らたなＧＲＮを用いてシステムに問い合わせた場合、以前には実現されていないとレポートされた同一の論理エンティティは、新らたな問い合せへの応答において実現されたとして示され得る。

上述の例では、各ＡＰＩ呼び出しの後に（すなわち、各論理エンティティが生成されて制御プレーンに公開された後に）ＧＲＮがインクリメントされるが、いくつかの実施形態では、論理エンティティが生成された後に、ユーザが手動でＧＲＮをインクリメントすることができる。例えば、論理的な変更を実装するために１００のＡＰＩ呼び出しを必要とする論理的変更（例えば、データセンタへのアプリケーションのプロビジョニング）をユーザが行う場合、ユーザは２０番目或いは３７番目の呼び出しの実現状態に関心はないであろう。ユーザは、おそらく、アプリケーションの実現状態（すなわち、１００回のＡＰＩ呼び出しのすべてが行われた後の実現状態）に関心を持つであろう。この種の状況では、個々のＡＰＩ呼び出しの後にＧＲＮをインクリメントするシステムの代わりに、またはこれに関連して、ユーザが最後のＡＰＩ呼び出しの後にＧＲＮをインクリメントする。換言すれば、ＧＲＮを手動でインクリメントする行為は、論理的な変更の実現状態を追跡するために使用することができるＧＲＮ値をユーザが受け取ることを可能にする。

上述したように、いくつかの実施形態では、ＧＲＮ値を異なる方法でインクリメントすることができる。いくつかの実施形態では、ＧＲＮは、周波数（例えば、ミリ秒で定義される）を使用して周期的に自動的にインクリメントされる。そのようないくつかの実施形態では、各インクリメントの後に、ＣＣＰクラスタが管理プレーンによって管理される最新のバリア番号（すなわち、ＧＲＮ）を追跡することができるように、要求がすべてのＣＣＰノードに送信される。代替的に、または結合的に、いくつかの実施形態は、ＧＲＮの強制インクリメント（すなわち、手動インクリメント）を可能にする。すなわち、ユーザは、（例えば、ＲＥＳＴ ＡＰＩ呼び出しなどのＡＰＩ呼び出しを用いて）ＧＲＮを手動でインクリメントすることもできる。いくつかの実施形態では、ＧＲＮを手作業でインクリメントし、同時に最新のＧＲＮ値を識別するために、特定のＧＲＮのインクリメント関数がユーザによって呼び出され、この関数はＧＲＮ値をインクリメントして、同時にインクリメントした値をユーザに返す。

いくつかの実施形態は、それぞれの所望の状態更新の後にＧＲＮをインクリメントする。すなわち、いくつかの実施形態は、論理エンティティの生成、修正、または削除のための新たなＡＰＩ呼び出しが受信されるたび、および、生成された論理エンティティが実現のためにＣＣＰクラスタに送信された後に、ＧＲＮをインクリメントする。例えば、論理スイッチのＡＰＩ呼び出し（例えば、ＲＥＳＴ ＡＰＩ呼び出しのＰＯＳＴ／ＰＵＴ／ＤＥＬＥＴＥ）が受信されると、ＧＲＮがインクリメントされ、論理スイッチメッセージがＣＣＰクラスタに公開された後に制御クラスタに送信される。このＧＲＮ生成の方法では、ＣＣＰクラスタは、所与のＧＲＮに基づいて論理スイッチの実現状態を返す良好な位置にある。

いくつかの実施形態は、各所望の状態更新の後に、上記で説明した方法とは異なる方法でＧＲＮをインクリメントする。すなわち、いくつかの実施形態は、論理エンティティの生成、修正、または削除のための新たなＡＰＩ呼び出しが受信される直後、および生成された論理エンティティが実現のためにＣＣＰクラスタに送信される前に、ＧＲＮをインクリメントする。しかしながら、ＧＲＮ生成のこのような方法では、ＣＣＰクラスタは問い合わせた論理エンティティの実現状態を判定することができず、それ自体、論理エンティティの実現状態が進行中であるか、代替的に論理エンティティがまだ実現していないとレポートする。いくつかの実施形態は、上記の方法のうちの２つ以上の組み合わせを同時に用いるが、他の実施形態では、ユーザは、（例えば、異なるクラスタごとに）１つ以上のＧＲＮ生成方法を選択することができる。

いくつかの実施形態では、ＧＲＮは、ＡＰＩ呼び出しごとに正確に１回だけインクリメントされる必要はない。例えば、２人のユーザ（例えば、データセンタの２つのテナント、同じテナントの２人のネットワーク管理者など）がＤＦＷ構成を変更し、その後、ＧＲＮをインクリメントするために（例えば、閾値期間内に）ＡＰＩ呼び出しを発行する場合、いくつかの実施形態は、ＧＲＮ値を１回だけインクリメントし、両方のユーザに同じ数を返す。この種の緩和は、そのようないくつかの実施形態において、ＧＲＮに課される同時修正の例外を制限することを可能にする。

更に、いくつかの実施形態では、ＧＲＮは、一度に１つの値を含む変数である必要はない。ＧＲＮの変数は、いくつかの実施形態において、数字のベクタ（配列）である。例えば、いくつかの実施形態のＧＲＮは、すべての論理スイッチに１つの要素（数）、すべての論理スイッチポートに１つの要素、すべての論理ルータに１つの要素などを有する配列である。これらの実施形態では、ＧＲＮに対する１つの単一の値の代わりには値の配列を有することで、より高い伝送コストおよびわずかに高い複雑さを犠牲にして、より高い同時実行性をもたらす。

図４は、いくつかの実施形態におけるＧＲＮを更新（インクリメント）する１方法を示す。図示される方法は、所定の時間間隔（例えば、１０秒毎）でＧＲＮ値を自動的に更新する。いくつかの実施形態では、各更新の間の期間は（例えば、ネットワーク管理者、オペレータなどによって）調整可能である。この図は、１つ以上の論理エンティティがこれらの時点の間に更新される（または時間間隔の間に論理エンティティが作成または更新されない）が、異なる時点で管理プレーン（例えば、中央管理プレーン（ＣＭＰ）クラスタ）がＧＲＮをインクリメントし、インクリメントされた値を制御プレーン（例えば、ＣＣＰクラスタ）に公開することを示す。

この図に示すように、時間インスタンスＴ１において、管理プレーン４１０は、論理スイッチＬＳ１を制御プレーン４２０に公開する。時間インスタンスＴ２（例えば、Ｔ１の５秒後）に、管理プレーンは、ＧＲＮ値１を有するＧＲＮを制御プレーンに公開する。次に、管理プレーンは、時間インスタンスＴ３（例えば、Ｔ２の５秒後）に第２の論理スイッチＬＳ２を公開する。しかしながら、第２の論理スイッチを公開した後、管理プレーンはＧＲＮをインクリメントせず、代わりに、図示のように、（時間インスタンスＴ４において）論理ルータＬＲを制御プレーンに公開する。これは、時間Ｔ３から５秒後である時間Ｔ４におけるＧＲＮ更新時間にはまだ達していない（この例の時間間隔は１５秒ごとに設定されている）ためである。

Ｔ４の５秒後である時間インスタンスＴ５において、管理プレーンは、Ｔ２（最後のＧＲＮが更新される）と最初にＧＲＮの公開時間として設定されたＴ５の間の時間間隔が１５秒であるため、制御プレーンにＧＲＮの新たな値Ｇ２を発行する。その後、時間Ｔ６において、管理プレーン４１０は、以前に生成された論理エンティティ（すなわち、論理ルータＬＲ）に対する変更を制御プレーン４２０に発行する。時間Ｔ７では、制御プレーンと管理プレーンとの間にトランザクションは存在しない。これは、この時点では、ユーザまたは管理プレーンが何らの論理エンティティも変更または生成しておらず、同時に、Ｔ７が最後のＧＲＮ更新のわずか１０秒後であるため、それゆえこの時点でＧＲＮも公開されるべきでない。最後に、管理プレーン４１０は、ＧＲＮ値をＧ３にインクリメントし、Ｔ５（すなわちＧＲＮがインクリメントされて公開された最後の時間）の１５秒後である時点Ｔ８において、この新しい値を制御プレーン４２０に公開する。

上述したように、いくつかの実施形態のＣＣＰクラスタは、ホスティングシステム（例えば、データセンタ）の１つ以上のテナントのための１つ以上の論理ネットワークを構成する１つ以上のコントローラを含む。いくつかの実施形態では、ＣＣＰクラスタ（１）は、（例えば、ＣＭＰクラスタからの）論理ネットワークを定義するデータを受信し、（２）（例えば、対応するローカルコントローラのセットを介して）ＭＦＥのセットからランタイムデータを受信し、（３）受信した定義及びランタイムデータに基づいて、論理ネットワークのための論理フォワーディング要素のセットのフォワーディング動作を定義する構成およびフォワーディングデータを計算し、（４）計算されたデータをホストマシンのセット上で動作するローカルコントローラのセットに配信する。

いくつかの実施形態では、各ローカルコントローラは、管理されたフォワーディング要素と共に、論理ネットワークの１つ以上のＤＣＮを実行するホストマシン上（たとえば、ホストマシンの仮想化ソフトウェア内）に存在する。異なるホストマシン上で動作する論理ネットワークのＤＣＮは、論理フォワーディング要素のセット（例えば、論理スイッチ、論理ルータなど）を介して、互いに論理的に（および他の物理または論理ネットワークに）接続する。

いくつかの実施形態では、各ローカルコントローラは、ＣＣＰクラスタから論理ネットワークデータを受信した後に、ローカルコントローラと同じホストマシン上に存在するＭＦＥのフォワーディング動作を定義する構成およびフォワーディングデータを生成する。次に、ローカルコントローラは、生成されたデータを同一のホストマシン上で動作するＭＦＥに配信する。ＭＦＥは、ローカルコントローラから受信した設定およびフォワーディングデータに基づいて、論理フォワーディング要素のセットを実装する。各ＭＦＥはいくつかの異なるＤＣＮに接続され、その異なるサブセットは異なるテナントの異なる論理ネットワークに属してよい。したがって、ＭＦＥは、異なる論理ネットワークに対して論理フォワーディング要素の異なるセットを実装することができる。

図５は、中央管理プレーンクラスタと、中央制御プレーンクラスタと、ホスティングシステム（例えばデータセンタ等）内のホストマシンのセットとの間の関係を概念的に示す。この図は、中央制御プレーン（ＣＣＰ）クラスタが、どのように、中央管理プレーン（ＣＭＰ）クラスタから論理ネットワーク定義（例えば、論理トポロジ）およびＧＲＮを受信し、要求されたフォワーディングおよび構成データをホストマシンのセットに公開するかを示す。公開された構成およびフォワーディングデータは、論理ネットワークの論理エンティティ（例えば、論理フォワーディング要素）を構成および実装するために、管理フォワーディング要素のセットがホストマシン上で動作することを可能にする。

図５は、ＣＭＰクラスタ５１５、ＣＣＰクラスタ５２０、および２つのホストマシン５３５および５４０を含む。図に示すホストマシンは、管理フォワーディング要素５４５（すなわちＭＦＥ１−２）およびデータ計算ノード５５０（すなわちＭＶ１−４）を含む。いくつかの実施形態では、ＭＦＥ５４５は、ホストマシン５３５および５４０の仮想化ソフトウェア（たとえば、ハイパーバイザ）に実装される（ハイパーバイザは、説明を簡単にするために図示されていない）。ＣＭＰクラスタ５１５は、中央マネージャ５２５のセットを含む一方で、ＣＣＰクラスタ５２０は中央コントローラ５３０のセットを含む。各ホストマシンはまた、（例えば、ホストマシンのハイパーバイザ内の）ＭＦＥ５４５とともに動作し、論理ネットワークの論理エンティティを実装するために関連付けられたＭＦＥを構成しおよび管理するローカルコントローラ５６０を含む。

マネージャ５２５およびコントローラ５３０の各々は、物理コンピューティングデバイス（例えば、サーバ、コンピュータ等）、仮想マシン（ＶＭ）、コンテナなどのデータ計算ノード（ＤＣＮ）、または物理的コンピューティングデバイスまたはＤＣＮ上で動作するソフトウェアインスタンス（またはプロセス）を含む。いくつかの実施形態では、マネージャは、ホスティングシステム内の１つ以上の論理ネットワークの管理、構成、監視、およびトラブルシューティングのための異なるユーザインタフェースアプリケーションを含む。いくつかの実施形態の１つ以上のコントローラのサブセットは、論理ネットワークの論理要素を実装する異なる管理フォワーディング要素（ＭＦＥ）の間のデータ通信を制御する。

上述したように、中央制御プレーン（ＣＣＰ）クラスタ５２０は、ＭＦＥ５４５間のデータ通信を制御することによって、論理ネットワークの異なるＤＣＮ間（例えば図示の例ではＶＭ５５０のいくつかの間）のネットワークデータ通信を制御する。ＣＣＰクラスタ５２０は、ＭＦＥが最終的にＤＣＮ間で論理ネットワークデータを交換する仮想トンネルエンドポイント（ＶＴＥＰ）を実装するので、ＭＦＥ間のデータ交換を制御するためにＭＦＥ５４５と通信する。データ交換を制御するために、いくつかの実施形態のＣＣＰクラスタは、各ＭＦＥから論理ネットワークエンティティ（例えば、ＶＭ５５０、論理ネットワークのＬＦＥなど）のランタイムデータを受信する。ＣＣＰクラスタ５２０はまた、論理ネットワークのデータ通信を制御するために、ＣＭＰクラスタ５１５から論理トポロジデータを受信し、ランタイムデータとともに定義データを使用する。

すなわち、ＣＣＰクラスタは、ＭＦＥ（例えば、ローカルコントローラ５６０を介して）から受信したランタイムデータと、ＣＭＰクラスタから受信したネットワーク定義データ（すなわち、所望の状態）とに基づいて、 ＭＦＥにプッシュされて、（例えば、ローカルコントローラ５６０を介して）ＭＦＥと共有されるデータのセット（すなわち変換された/共有された状態）を生成する。いくつかの実施形態では、ＣＣＰクラスタは、変換された状態を生成するために、ＣＣＰクラスタ（例えば、シャーディングテーブル）によって生成され格納される他のデータを使用する。変換された状態は、ＭＦＥが実装する１つ以上のＬＦＥによって論理的にフォワードされる、データを物理的に交換するために、ＭＦＥによって使用される。

典型的な論理ネットワーク定義データは、いくつかの実施形態では、ＤＣＮの位置（例えば、ホストマシン上のＶＭの位置）を定義するデータ、トポロジ内のＤＣＮとＬＦＥの位置との間の接続トポロジを定義するデータ、 ＬＦＥ（例えば、分散型ファイアウォールポリシ）に適用されるミドルボックスサービスを定義するデータ等を含む。典型的なランタイムデータは、いくつかの実施形態では、仮想トンネルエンドポイント（ＶＴＥＰ）テーブル、メディアアクセス制御（ＭＡＣ）テーブル、アドレス解決プロトコル（ＡＲＰ）テーブルなどのレイヤ２制御プレーンテーブルや、ルーティング情報ベース（ＲＩＢ）テーブル、フォワーディング情報ベース（ＦＩＢ）テーブルなどのレイヤ３ルーティングテーブルや、ＭＦＥから収集された統計データ等を含む。

いくつかの実施形態では、ホストマシンの各ハイパーバイザのローカルコントローラ５６０は、ＣＣＰクラスタ５２０の中央コントローラ５３０から論理ネットワークデータを受信する。次に、ローカルコントローラは、ローカルコントローラーが動作するのと同一のホストマシン上で動作するローカルＭＦＥ５４５のために受信した論理ネットワークデータを変換し、カスタマイズする。次に、ローカルコントローラは、変換され、カスタマイズされたデータを各ホストマシン上のローカルＭＦＥ５４５に配信する。いくつかの実施形態では、エンド・マシンのＬＦＥ（例えば、論理スイッチ）への接続は、ＭＦＥの物理ポートにマップされる論理ポートを使用して定義される。

上述したように、いくつかの実施形態では、論理ネットワークのＬＦＥ（論理ルータおよびスイッチ）は、論理ネットワークに接続された各ＭＦＥによって実装される。すなわち、いくつかの実施形態では、ＭＦＥがＤＣＮからパケットを受信すると、ＭＦＥは、ＤＣＮが論理的に結合する論理スイッチのためのネットワークフォワーディング処理と、任意の追加的なＬＦＥに対する処理（例えば、パケットが外部ネットワークに送信される場合の論理ルータ処理、論理ルータ処理、およびパケットが他の論理スイッチに結合されたエンドマシン（ＤＣＮ）に送信される場合のネットワーク内の他の論理スイッチに対する処理）とを実行する。ＣＭＰクラスタ５１５が生成し、ＣＣＰクラスタ５２０に公開するＧＲＮは、システムが、ＭＦＥが実装する論理フォワーディング要素（および他の論理エンティティ）がＭＦＥ内で適切に構成されているかどうかを判定できるようにする。すなわち、ＧＲＮは、システム（またはユーザ）が、１つ以上の論理ネットワークに対して定義された論理エンティティがシステム内で実現されているかどうかを判定できるようにする。

当業者であれば、図に示すホストマシン、中央マネージャおよび中央コントローラ、および仮想マシンの数は例示的であり、ホスティングシステムのテナントのための論理ネットワークは、多数のホストマシン（およびサードパーティのスイッチ）に広がり、多数のＤＣＮを論理的に相互に（および他のいくつかの物理デバイス）接続してもよいことを理解するであろう。更に、この図および以下の他の図においてＶＭとして示すが、いくつかの実施形態において、他の種別のデータ計算ノード（例えばネームスペース、コンテナ等）が論理フォワーディング要素と接続することが理解されるべきである。

いくつかの実施形態は、クラスタリングイベント、スライス再割り当てを識別するため、またはＭＰデータベースがインストールおよび/または復元されたときに、（例えば、ＧＲＮ変数内の）世代番号を提供する。クラスタリングイベントは、いくつかの実施形態において、クラスタの現在のワーキングセットを変更する、ＣＣＰクラスタ内の変化または修正を含む。たとえば、クラスタリングイベントは、ＣＣＰクラスタ内の１つのコントローラがクラッシュする、またはクラスタへの接続が失われるときに発生する。また、クラスタリングイベントは、ネットワーク管理者が既存のコントローラを削除する、または新しいコントローラをＣＣＰクラスタに追加するときに発生する。

スライスの移動は、クラスタの特定のコントローラに割り当てられたワークスライスが別のコントローラに再割り当てされたとき、または、一般に、コントローラに割り当てられたワークスライスに変更があるときに発生する。いくつかの実施形態では、各コントローラに割り当てられたワークロードは、異なる目的のために実行される異なるワークスライスを含む。たとえば、コントローラは、２つの異なる論理ネットワークに属する２つの異なる論理エンティティのセットに対する構成およびフォワーディングデータを計算するために割り当てられてよい。このような状況では、コントローラは、第１のワークスライス内の第１の論理ネットワークのためのデータと、第２の異なるワークスライス内の第２の論理ネットワークのためのデータとを計算する。コントローラ上のワークロードが重くなった場合、いくつかの実施形態では、ワーク分散プロシージャがアクティブになり、１つ以上のワークスライスを別のコントローラに移動する。したがって、クラスタリングイベントがない場合（すなわち、コントローラ自体に変更がない）であっても、クラスタ上のワーク割り当てが変更され、新しい世代番号が必要となる。

ＭＰは、すべての論理ネットワークについて所望の状態のすべてを格納するので、いくつかの実施形態は、事故の場合に、ある時間間隔でＭＰをバックアップする。事故が発生した場合、ネットワークのオペレータは最新のバックアップのスナップショットをＭＰにコピーする。この種のイベントは、ＭＰデータベースの復元と呼ばれ、新しい世代番号も必要とする。したがって、いくつかの実施形態では、世代番号は、クラスタリングイベントまたはスライス再割り当てが起こるたびに、または管理プレーンデータベースがインストールされまたは復元されるたびにインクリメントされる。いくつかの実施形態では、このようなインクリメントは、（例えば、新たなクラスタリングイベントのそれぞれにより）自動的に生じる。いくつかの実施形態では、ユーザは（例えば、ＭＰデータベースのバックアップバージョンが復元されたときなど）世代番号を（手動で）インクリメントすることができる。

いくつかの実施形態では、ＭＰは、世代番号が全てのＣＣＰノード間で同期されることを確実にするために、（例えば、リモートプロシージャ―コールを介して）ＣＣＰクラスタに問い合わせる。このようないくつかの実施形態では、各ＣＣＰノードは、最新の世代番号を有するクエリに応答する。世代番号が全ての応答にわたって同一でない場合、ＭＰは、最近起こったクラスタリングの変更がまだＣＣＰノードのいくつかで処理されていないと結論付けることができる。いくつかの実施形態では、世代番号は、ＧＲＮとは別個の変数である。しかしながら、いくつかのこのような実施形態では、各世代番号はＧＲＮに関連付けられる。いくつかの実施形態では、ユニバーサル固有識別子（ＵＵＩＤ）は、世代番号とＧＲＮの両方を含む（例えば、ＧＲＮと世代番号の両方が単一の６４ビットＵＵＩＤに符号化されてよく、ここでトップ１６ビットは世代番号を保持し、下位４８ビットはＧＲＮを保持する）。

いくつかの実施形態では、管理プレーンは、所望の状態バージョン番号（すなわち、ＧＲＮ）のコンテキスト内で所与のエンティティ（またはエンティティのセット）の実現状態をユーザが問い合わせることができるようにするＧＲＮインタフェースをユーザに提供する。そのようないくつかの実施形態の各ＣＣＰノードは、次に、実現状態メッセージ（またはタイムアウトに達するメッセージ）とともにこのクエリに応答する。１つ以上のＣＣＰノードが応答しない場合、いくつかの実施形態の管理プレーンは、予め設定された回数だけ再試行し、ＣＣＰノードから依然として応答がない場合、エラーメッセージまたは（ＣＣＰノードが応答しないことを示す）利用不可メッセージのいずれかを返す。いくつかの他の実施形態の管理プレーンは、ＣＣＰノードのいくつかがユーザから提出されたクエリに応答しない場合、ユーザのクエリに対してエラーメッセージまたは利用不可メッセージを返す。

一方、すべてのＣＣＰノードが応答するが、世代番号がすべての応答にわたって同じでない場合、いくつかの実施形態の管理プレーンは、最近起こったいくつかのクラスタリングの変化（例えば、クラスタリングイベント、スライス移動等）がいくつかのＣＣＰノードによってまだ処理されていないと結論づける。いくつかの実施形態では、ＭＰが、ユーザＡＰＩ呼び出しの実現の失敗を示すメッセージと共に応答する一方で、いくつかの他の実施形態では、ＭＰは、失敗の実現メッセージを返す前にＣＣＰクラスタに再度１回以上問い合わせる。世代番号がＣＣＰクラスタ全体で同一である場合、ＭＰはＣＣＰノードから受信したすべての応答の実現状態を評価し続けることができる。

実現メッセージの少なくとも１つが成功を示さない場合、いくつかの実施形態のＭＰは、対応するＣＣＰノードが指定された所望の状態バージョンまたは対応するランタイム状態バージョンを処理していないことを認識する。この場合、ＭＰは応答におけるＭＦＥ状態を調べずに、実現が進行中である（または対応するコントローラがまだ論理エンティティを処理していない）ことをユーザに返信する。後述されるように、いくつかの実施形態のＣＣＰクラスタノードは、実現状態に対する問い合わせされたときに、まだ論理エンティティを実現していないＭＦＥをＭＰに返す。

いくつかの実施形態では、ＣＣＰクラスタからのすべての応答における実現状態が成功を示す場合、いくつかの実施形態のＭＰは、ＣＣＰクラスタが失敗した実現状態を返したＭＦＥ状態を調べる。すなわち、いくつかの実施形態では、ＣＣＰクラスタから受信した実現状態応答は、所望の状態に対して適切に実現されていないＭＦＥを識別する１つ以上の特定のフィールドを含む。いくつかのそのような実施形態では、ＣＣＰクラスタからの応答が任意のＭＦＥに対する不成功の実現メッセージを搬送しない場合、ＭＰは、クエリで指定されたＧＲＮ値までのすべての論理エンティティが実現され、適切に動作していることを意味する、成功の実現メッセージを返す。

図６は、特定のＧＲＮについてＣＣＰクラスタに問い合わせ、処理がＣＣＰクラスタから受信する応答に基づいて論理エンティティの実現状態をレポートする、いくつかの実施形態の処理６００を概念的に示す。いくつかの実施形態では、処理は、マネージャコンピュータまたはマネージャコンピュータ上で動作するマネージャアプリケーションによって実行される。いくつかのそのような実施形態のマネージャコンピュータ（またはアプリケーション）は、１人以上のユーザ（例えば、データセンタの異なるテナント）のための物理ネットワーク基盤（例えば、データセンターネットワーク）上に１つ以上の論理ネットワークを生成し管理する。

処理６００は、特定のＧＲＮ値に関連付けられた１つ以上の論理エンティティ（例えば、論理スイッチ、論理ルータ、論理ファイアウォール、論理ロードバランサ等）の実現状態について、ＣＣＰクラスタのコントローラ（コンピュータおよび/またはアプリケーション）に問い合わせる（６１０において）ことによって開始する。いくつかの実施形態では、処理は、ユーザがＣＣＰクラスタから問い合わせるべき論理エンティティおよびＧＲＮ値を指定する、ユーザ（例えば、データセンターのネットワーク管理者）からのクエリを受信する。いくつかの実施形態では、ユーザは、管理プレーンに提出されるクエリ内のＧＲＮ値のみを指定し、そして、処理は、生成されてＣＣＰクラスタに公開された論理エンティティの全ての実現状態について問い合わせる。

次に、処理は、問い合わせに対する応答がＣＰＰクラスタにわたって同じ世代番号を含むかどうかを（６２０において）判定する。上述したように、ＣＣＰクラスタの最近の変化（例えば、クラスタリングイベント、ワークスライスの移動等）のために、１つ以上のクラスタノードは、他のノードとは異なる世代番号を有してもよい。したがって、応答における実現状況は信頼されるべきではない。処理がコントローラの世代番号に相違があると判定した場合、いくつかの実施形態の処理は、応答の更なる検査を先送りして（６２５において）失敗メッセージをユーザに返す。いくつかの実施形態では、メッセージは実現の失敗を示さず、単純にクラスタリングイベントのために問い合わせを後で送信すべきであることを示す。さらにいくつかの他の実施形態では、処理は、障害および/または進行中のメッセージを返す前に、数回にわたって（例えば、ユーザによって設定および調整可能な回数）ＣＣＰクラスタに問い合わせを自動的に再試行する。メッセージを返信した後、処理は終了する。

処理は、問い合わせへの応答がＣＣＰクラスタにわたって同じ世代番号を含むと（６２０において）判定した場合、処理は、すべての応答における実現状態が、論理エンティティの所望の状態およびそれらの対応するランタイム状態に基づいてコントローラが適切に構成およびフォワーディングデータを計算した、ことを示すかどうかを（６３０において）判定する。換言すれば、処理は、すべてのコントローラが、（１）管理プレーンから受信した１つ以上の論理エンティティの所望の状態とＭＦＥから受信した同じ論理エンティティの対応するランタイム状態とを処理したかどうかを判定し、（２）処理されたデータをＭＦＥに（例えば、ＭＦＥの対応するローカルコントローラを介して）プッシュダウンして、論理エンティティを実装したかを判定する。

処理が、１つ以上のＣＣＰノードが構成データを処理し、その構成データを成功裏に配信しなかったと（６３０において）判定した場合、処理は、まだデータを処理していないコントローラのレポートを（６３５において）返す。いくつかの実施形態の処理は、レポートにおいて、これらのコントローラが依然として論理エンティティを実現する処理中にあることを示す。いくつかの実施形態では、処理は、コントローラのいくつかが依然としてデータを処理中であるというメッセージを返す前に、すべてのコントローラが論理エンティティを実現したかどうかを判定するための更なるいくつかの試みを行う。レポートを返信した後、処理は終了する。

処理が、コントローラから受信したすべての応答の実現状態が、コントローラが構成およびフォワーディングデータを適切に計算したことを示すと判定した場合、処理は、すべての応答の実現状態が、論理エンティティを実装するために、ＣＣＰクラスタから受信した構成およびフォワーディングデータに基づいてローカルコントローラがＭＦＥを適切に構成したことを示すかどうかを（６４０において）判定する。いくつかの実施形態では、各コントローラは、コントローラが論理エンティティの構成データを生成し、対応するＭＦＥにデータをプッシュしたことを（例えば、コントローラが生成する応答の１つ以上のフィールドを通じて）示すだけでなく、（応答内に生成された別のフィールドのセットを通じて）ＭＦＥがまだ論理エンティティ（存在する場合）を実装するように構成されていないことも示す。

すなわち、ＣＣＰクラスタのコントローラが、（ＭＰから）論理エンティティの実現状態に対する要求を受信すると、コントローラは、まずコントローラが保持する最新の世代番号を識別し、識別された世代番号を要求に対する実現応答に挿入する。次に、コントローラは、管理プレーンから受信した論理エンティティ定義データを、ＭＦＥから受信した論理エンティティのランタイムデータと共に、コントローラが処理したかどうかを判定する。コントローラがこれらのデータ（すなわち、生成された論理エンティティの構成データおよびフォワーディングデータ）を正常に処理し、処理されたデータをホストマシンのセット上で実行されている対応するローカルコントローラのセットに配信した場合、コントローラはまた、実現応答に成功メッセージを挿入する。

最後に、いくつかの実施形態のコントローラはまた、論理エンティティがコントローラが管理する対応するＭＦＥ上で（ローカルコントローラによって）正常に構成されているかも判定する。コントローラは、論理エンティティがまだ構成されていない１つ以上のＭＦＥを識別した場合、まだ論理エンティティが構成されていないＭＦＥ（ＭＦＥの識別子）を実現応答に挿入する。

処理は、１つ以上のコントローラから受信した１つ以上の応答の送信実現状態が、ローカルコントローラのいくつかが依然として対応するＭＦＥを構成中であることを示すと判定した場合、処理は、いくつかのＭＦＥが論理エンティティをまだ実現していないことを（６４５において）レポートする。いくつかの実施形態の処理は、レポートにおいて、ＭＦＥが依然として論理エンティティを実現する処理中（構成中）にあることを示す。前の動作と同様に、いくつかの実施形態では、処理は、ローカルコントローラのいくつかが依然としてＭＦＥを構成中であるというメッセージを返す前に、ローカルコントローラの全てがＭＦＥ上に論理エンティティを構成したかどうかを判定するための更なるいくつかの試みを行う。レポートを返信した後、処理は終了する。

一方、処理が、すべての応答の実現状態が、論理エンティティを実装するためにローカルコントローラがすべてのＭＦＥを適切に構成したと（６４０において）判定した場合、処理は、問い合わせたＧＲＮにおいてすべての論理エンティティがネットワーク内で正常に実現されていることのメッセージを（６５０において）返す。その後処理は終了する。

上記の動作の多くは、ユーザがシステムに問い合わせる論理エンティティのセット内の最後の論理エンティティの作成および/または変更の後にユーザが受け取るＧＲＮ値を用いて、ユーザが管理プレーンに問い合わせるという前提に基づいて記載されていることに注意することが重要である。したがって、いくつかの動作は、進行中（データを処理している）メッセージを返すものとして記載される。ユーザが論理エンティティの最後の変更の前に生成された以前のＧＲＮ値を用いてシステムに問い合わせる場合、いくつかの実施形態の処理は、論理エンティティが以前のＧＲＮ値で実現されなかったことを最初の応答が示す場合に、ＣＣＰクラスタに再度問い合わせる努力を行わないことを理解されたい。

更に、処理６００の特定の動作は、図示及び説明された正確な順序で実行されないかもしれない。特定の動作は、１つの連続する動作の流れで実行されないかもしれず、異なる特定の動作が異なる実施形態において実行され得る。例えば、いくつかの実施形態では、ＣＣＰノードから受信した応答の世代番号を検査する前に、まずすべてのコントローラが問い合わせに応答したことを確認する。いくつかのこのような実施形態は、１つ以上のＣＣＰノードが問い合わせに応答しないときにエラーメッセージを返す。いくつかの他の実施形態は、すべての単一クラスタノードからの応答を取得しようとする間に、短時間でＣＣＰクラスタに再び問い合わせる。すべてのクラスタノードが返信を送信した後でのみ、これらの実施形態は、論理エンティティの世代番号および実現状態に関する応答を検査することを開始する。最後に、当業者は、処理６００がいくつかのサブプロセスを使用して、またはより大きなマクロプロセスの一部として実施され得ることを認識するであろう。

図７は、特定のＧＲＮまでの１つ以上の論理エンティティの実現状態に関するクエリを受信した後に、いくつかの実施形態の制御プレーンが返す応答の例を示す。この図は、２つの別個の段階７０５および７１０において、制御プレーンが、生成されたおよび/またはＧＲＮの特定の値まで変更された、すべての論理要素の実現状態をＣＣＰクラスタに問い合わせることを示す。この図は、（例えば、ＣＭＰクラスタ内の）マネージャ７２０、（例えば、ＣＣＰクラスタ内の）２つのコントローラ７３０、および（例えば、４つの異なるホストマシン（図示せず）内）の４つのローカルコントローラ７４０を含む。

第１段階７０５では、マネージャ７１０は、生成された、および/またはＧＲＮ＝１０まで変更されたすべての論理要素の実現状態に対する要求を送信した。マネージャは、４つのローカルコントローラ７４０が動作する４つのホストマシン（すなわち、ホストマシン上のハイパーバイザ）上の論理エンティティの構成に責務を負う、２つのコントローラ７３０に問い合わせる。図示するように、ＣＣＰクラスタのコントローラ１は、ローカルコントローラＬＣ１およびＬＣ２の構成およびフォワーディングデータの生成に責務を負う一方、コントローラ２は、ローカルコントローラＬＣ３およびＬＣ４の構成およびフォワーディングデータの生成に責務を負う。各ローカルコントローラ６４０は、ローカルコントローラと同一のハイパーバイザ上で動作するＭＦＥの共通フォワーディング動作を定義するデータを、ＣＣＰクラスタ内のその対応するコントローラから受信する。各ローカルコントローラは、次に、論理エンティティを実装するためにその対応するＭＦＥに固有の構成およびフォワーディングデータを生成し、生成したカスタマイズされたデータをＭＦＥに配信する。

第２段階は、２つのコントローラ７３０が、２つの異なる世代番号（すなわち、Gen＃２およびGen＃３）をマネージャ７２０に返すことを示す。上述したように、マネージャがＣＣＰクラスタから受信した応答において異なる世代番号を持つ異なる理由が存在し得る。例えば、ＣＣＰクラスタの最近の変化（例えば、クラスタリングイベント、ワークスライスの移動等）のために、１つ以上のクラスタノードは、他のノードとは異なる世代番号を有してもよい。このように、マネージャ７２０は、ＣＣＰクラスタから受信した世代番号に不一致があることを認識すると、ＣＣＰクラスタから受信した、実現状態を識別するための応答をさらに調べることを停止する。いくつかのそのような実施形態のマネージャは、失敗メッセージを返すか、代替的に、最新のクラスタリングイベントが発生し、ユーザが後に論理エンティティの実現状態を問い合わせる必要があることをユーザにレポートする。

上述したように、いくつかの実施形態のＣＣＰクラスタ（例えば、ＣＣＰクラスタ内の１つ以上のＣＣＰノード）は、（論理エンティティの実現状態クエリに応答して）論理エンティティの実現状態についてのメッセージを返す。いくつかの実施形態では、返されるメッセージは、成功メッセージ、不成功メッセージ、または進行中メッセージであり得る。成功状態は、いくつかの実施形態では、ＣＣＰクラスタが受信した所望の状態を処理したこと、および、処理したデータをローカル制御プレーン（例えば、同じホストマシン内のＭＦＥと並んで動作する１つ以上のローカルコントローラ）にプッシュしたことを示す。いくつかの実施形態では、ＭＰがＧＲＮをインクリメントするたびに、ＭＰはインクリメントされたＧＲＮをＣＣＰクラスタと同期させる。いくつかの実施形態では、コントローラノードの１つ（例えば、シャーディングマスタコントローラ）が、同じＧＲＮを、ＣＣＰクラスタのコントローラに保持されている現在のランタイム状態に割り当てる。いくつかの実施形態では、ＣＣＰクラスタが、特定のＧＲＮ値に対する論理エンティティの所望の状態と対応するランタイム状態の両方を処理した場合、ＧＲＮの特定の値に対する実現状態は成功したと考慮される。

いくつかの実施形態では、成功メッセージは、論理エンティティの所望の状態（および対応するランタイム状態）がＣＣＰクラスタによって処理されそして公開されたことだけでなく、論理エンティティが論理エンティティを実装する１つ以上のＭＦＥ（ホストマシンまたはゲートウェイ上で動作する）上で成功裏に構成されたことを示す。例えば、いくつかのこのような実施形態では、論理スイッチの実現状態に対する成功応答は、論理スイッチを実装する１つ以上のＭＦＥ（例えば、１つ以上のホストマシンのハイパーバイザで）が、論理スイッチと論理的に接続される１つ以上の仮想マシンと成功裏に接続されることを意味する。さらにこのことは、ＭＦＥが、論理スイッチについて、制御プレーン（例えば、論理スイッチのマスタコントローラ）および管理プレーン（例えば、論理スイッチのマスタマネージャ）とアクティブな通信を有することを意味する。

いくつかの実施形態では、ＭＰがＧＲＮをインクリメントするたびに、ＭＰはインクリメントされたＧＲＮをＣＣＰクラスタと同期させる。いくつかの実施形態では、コントローラノードの１つ（例えば、クラスタ内のシャーディングコントローラ）は、同じＧＲＮを、ＭＦＥから論理エンティティのために受信され、かつＣＣＰクラスタのコントローラに保持されていた、現在のランタイム状態に割り当てる。いくつかの実施形態では、ＣＣＰクラスタが、特定のＧＲＮ値における論理エンティティの所望の状態と対応する論理エンティティのランタイム状態との両方を処理した場合、ＧＲＮの特定の値に対する論理エンティティのＣＣＰ実現状態は成功したと考慮される。

いくつかの実施形態では、論理エンティティの状態に対する不成功の実現応答は、異なる理由を有してよい。例えば、１つ以上のＣＣＰノードが所望の状態更新の処理において遅れた場合、ＣＣＰノードは、所望の状態の実現不成功を返し得る。論理エンティティの所望の状態の実現不成功に対する他の理由は、１つ以上のＭＦＥが、ＧＲＮの特定の値に対する何らかの変更の実装に失敗したことを明示的に示す場合、１つ以上のＭＦＥが所望の状態更新頻度の維持から遅れた場合、いくつかのＭＦＥが長時間にわたって未接続となった場合、を含む。

いくつかの実施形態は、所望の状態の実現における様々な問題の原因を識別するのに役立つトラブルシューティングのデータを提供する。いくつかの実施形態は、識別された問題の性質および場所に基づいて、問題の論理エンティティに対して異なるレベルの詳細を提供する。いくつかの実施形態は、実現された状態にならない特定の論理要素に関するトラブルシューティングのデータを提供する。

図８は、特定のＧＲＮにおける１つ以上の論理エンティティの実現状態に関するクエリを受信した後に、いくつかの実施形態の制御プレーンが返す応答の他の例を示す。この図は、ツリーの別々の段階８０５、８１０および８１５において、制御プレーンが、ＧＲＮの特定の値まで制御プレーンに公開された、特定の論理要素の実現状態をＣＣＰクラスタに問い合わせることを示す。図は、（例えば、ＣＭＰクラスタ内の）マネージャ７２０、（例えば、ＣＣＰクラスタ内の）２つのコントローラ７３０、４つのローカルコントローラ７４０、および４つのＭＦＥ８２０を含み、それぞれが、ローカルコントローラの１つ（すなわちローカルコントローラとその関連付けられたＭＦＥの両方が、別々のホストマシンのハイパーバイザで動作する）と関連付けられる。

第１段階８０５では、マネージャ７１０は、ＧＲＮ＝２０において論理スイッチＬＳ１の実現状態に対する要求を送信した。マネージャは、論理スイッチＬＳ１を実装するＭＦＥ８２０上の論理スイッチＬＳ１の構成に責務を負う、２つのコントローラ７３０に問い合わせる。図示するように、ＭＦＥ２‐４のみが論理スイッチＬＳ１を実装する。すなわち、各ホストマシン上のエンドマシンのセットが接続するＬＳ１の論理ポートは、ＭＦＥ２、ＭＦＥ３、およびＭＦＥ４でのみ実装される。換言すれば、ＬＳ１のこれらの論理ポートは、ＭＦＥ２が動作するホストマシン上にあるエンドマシンのセットを、ＭＦＥ３とＭＦＥ４が動作するホストマシン上にある他のエンドマシンに、論理的に接続する。反対に、ＭＦＥ１は論理スイッチＬＳ２と論理ルータＬＲ１とを実装する。

第１段階はまた、この時点（すなわち、ＧＲＮ＝２０）で、コントローラ７３０の両方の世代番号が同一であることを示している。これは、（最新のクラスタリングイベントに関して）ＣＣＰノードが同期されていることを意味し、実現判定処理は継続できる。さらに、図は、ＣＣＰクラスタのコントローラ１が、ローカルコントローラＬＣ１及びＬＣ２に対する、ＬＳ１、ＬＳ２およびＬＲ１の構成およびフォワーディングデータの生成に責務を負い、一方、ＣＣＰクラスタのコントローラ２は、ローカルコントローラＬＣ３およびＬＣ４に対するＬＳ１の構成およびフォワーディングデータの生成に責務を負う。図示の例では、コントローラ７３０の両方が、論理スイッチＬＳ１の論理構成およびフォワーディングデータを生成と配信を行うが、いくつかの実施形態では、ＣＣＰクラスタの各コントローラが、論理エンティティの特定のセット（すなわち、いくつかの実施形態では、２つのＣＣＰノードは同じ論理エンティティを同時に管理しない）の構成に責務を負う。

第２段階では、ＭＦＥ１は論理スイッチＬＳ１を実装しないため、ＣＣＰクラスタはこのＭＦＥ（すなわちＬＳ１）に関連付けられているローカルコントローラに問い合わせをせず、このため、このローカルコントローラは、管理プレーンへのフォワーダになるための応答をＣＣＰクラスタに送信しない。換言すれば、各特定のＧＲＮにおいて、各コントローラ７３０は、コントローラが処理し、異なるＭＦＥにプッシュダウンした論理要素を把握している。すなわち、各コントローラは、コントローラが管理するＭＦＥと、コントローラが管理するＭＦＥにどの論理要素が実装されているかを把握している。したがって、ユーザが特定のＧＲＮ（すなわち、ＧＲＮ＝２０）で所望の論理エンティティ（すなわちこの例ではＬＳ１）の実現状態を要求する場合、コントローラ７３０は、ＬＳ１の構成データがＧ＝２０までプッシュされたＭＦＥの実現状態を要求するだけである。

第２段階はまた、論理スイッチＬＳ１の実現状態を送信するように要求された３つのローカルコントローラのうち、ローカルコントローラＬＣ２およびＬＣ４が、ＧＲＮ＝２０までの論理スイッチの状態を実現されたものとして返すことによって応答し、ローカルコントローラＬＣ３は、ＬＳ１の状態を（まだ）実現していない状態として返すことによって応答する。ＭＦＥ３上の論理スイッチＬＳ１の実現の不成功の理由は、ＭＦＥ３上でＬＳ１を構成するためのカスタマイズされたデータを生成する際に、コントローラＬＣ３が遅れたことであり得る。他の理由は、コントローラ２が、ＬＳ１の構成データの生成およびローカルコントローラＬＣ３への配信において遅れたことであり得る。しかしながら、以下の第３段階で説明するように、このコントローラは、コントローラ上の論理スイッチの実現において成功メッセージを送信する。これはコントローラ２がこの例では遅れていないことを示す。

第３段階では、各コントローラ７３０は、論理スイッチＬＳ１の実現において、（クエリに対する応答において）成功メッセージを送信するが、コントローラ２の成功メッセージは、（例えば、メッセージの１つ以上のフィールドに）ＧＲＮ＝２０においてＬＳ１の構成データをまだ処理しているローカルコントローラを含む。一方、コントローラ１は、マネージャ７２０に返す成功メッセージにあらゆるローカルコントローラを有しない。マネージャ７２０は、マネージャがＣＣＰクラスタから受信したメッセージに基づいて、どのレベルで論理エンティティの実現が成功しなかったかを判定することができる。すなわち、ＣＣＰクラスタの両方のコントローラが成功メッセージを返す場合、マネージャは、論理スイッチＬＳ１がＣＣＰクラスタ内で実現されている（すなわち、スイッチの構成データが処理され、ローカルコントローラにプッシュされた）と結論付ける。しかし、１つ以上のＣＣＰノードが、そのメッセージにおいて、いくつかのＭＦＥが論理要素を実現していないことを示す場合、マネージャは、問い合わせられた論理エンティティの（ＧＲＮ＝２０までの）データをまだ処理しているＭＦＥおよびホストマシンを識別することができる。

上述の多くの特徴及び適用例は、コンピュータで読み出し可能な記録媒体（コンピュータ可読媒体としても参照される）上に記録された命令の組として特定されるソフトウェア処理として実施され得る。これらのプログラムの命令が１つ以上の計算または処理ユニットによって実行される場合（例えば、１つ以上のプロセッサ、プロセッサのコア、又は他の処理ユニット）、これらのプログラムの命令は、命令に示されているアクションを（複数の）処理ユニットに実行させる。コンピュータで読み出し可能なメディアの例は、これに限定されないが、ＣＤ−ＲＯＭ、フラッシュドライブ、ランダムアクセスメモリ（ＲＡＭ）チップ、ハードドライブ、消去可能なプログラム可能読出し専用メモリ（ＥＰＲＯＭ）等を含む。コンピュータで読出し可能なメディアは、キャリア波及び、無線又は有線接続を通過する電子信号を含まない。

本明細書では、「ソフトウェア」の語は、読出専用メモリにあるファームウェア、又は磁気記録に格納されたアプリケーションを含み、プロセッサによる処理のためにメモリに読み込むことができる。また、いくつかの実施形態では、複数のソフトウェア発明は、個別のソフトウェア発明を維持する一方で、より大きなプログラムのサブ部分として実施されてもよい。いくつかの実施形態では、複数のソフトウェア発明はまた、個別のプログラムとして実施されてもよい。最後に、ここで説明されるソフトウェア発明をともに実施する個別のプログラムの任意の組み合わせは、発明の範囲内である。いくつかの実施形態では、ソフトウェアプログラムが、１以上の電子システムを動作させるためにインストールされる場合、１以上の特定の機械的実施を定義し、ソフトウェアプログラムの動作を実行する。

図９は、本発明のいくつかの実施形態が実施される電子システム９００を概念的に示す。電子システム９００は、コンピュータ（例えば、デスクトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ等）、サーバ、分散スイッチ、電話、ＰＤＡ、又は任意の他の種類の電子デバイスであり得る。そのような電子システムは、様々な種別のコンピュータで読み出し可能なメディア、及び様々な他の種別のコンピュータで読み出し可能なメディアに対するインタフェースを含む。電子システム９００は、バス９０５、処理ユニット９１０、システムメモリ９２５、読出専用メモリ９３０、永続的ストレージデバイス９３５、入力デバイス９４０、及び出力デバイス９４５を含む。

バス９０５は、電子システム９００の多くの内部デバイスを通信可能に接続する、全てのシステムバス、周辺バス、及びチップセットバスを集約的に表す。例えば、バス９０５は、処理ユニット９１０を、読出専用メモリ９３０、システムメモリ９２５、及び永続的ストレージデバイス９３５に通信可能に接続する。

処理ユニット９１０は、本発明の処理を実行するために、これらの様々なメモリユニットから実行する命令及び処理するデータを検索する。処理ユニットは、異なる実施形態において単一のプロセッサ又はマルチコアプロセッサであり得る。

読出専用メモリ（ＲＯＭ）９３０は、処理ユニット９１０及び電子システムの他のモジュールによって必要とされる静的データ及び命令を記録する。永続的ストレージデバイス９３５は、一方で、読出・書込メモリデバイスである。このデバイスは、電子システム９００がオフの場合であっても命令及びデータを記録する不揮発性メモリユニットである。本発明のいくつかの実施形態は、（磁気又は光学ディスク、及び対応するディスクドライブなどの）マスストレージデバイスを永続的ストレージデバイス９３５として用いる。

他の実施形態は、（フロッピーディスク、フラッシュメモリデバイス等およびその対応するドライブのような）取り外し可能なストレージデバイスを永続的ストレージデバイスとして用いる。永続的ストレージデバイス９３５のように、システムメモリ９２５は、読出・書込メモリデバイスである。しかしながら、ストレージデバイス９３５とは異なり、システムメモリ９２５は、ランダムアクセスメモリのような揮発性の読出・書込メモリである。システムメモリ９２５は、プロセッサがランタイムにおいて必要とする、いくつかの命令及びデータを格納し得る。いくつかの実施形態では、本発明の処理は、システムメモリ９２５、永続的ストレージデバイス９３５、及び／又は読出専用メモリ９３０に記録される。処理ユニット９１０は、いくつかの実施形態の処理を実行するために、これらの様々なメモリユニットから実行する命令及び処理するデータを検索する。

バス９０５はまた、入力デバイス９４０と出力デバイス９４５に接続する。入力デバイス９４０は、ユーザが情報を通信し、電子システムへのコマンドを選択できるようにする。入力デバイス９４０は、英数字キーボードおよびポインティングデバイス（「カーソル制御デバイス」とも呼ばれる）、カメラ（例えば、ウェブカメラ）、マイクロフォンまたは音声コマンドを受信するための類似デバイス等を含む。出力デバイス９４５は、電子システムによって生成された画像を表示し、そうでなければデータを出力する。出力デバイス９４５は、プリンタ、真空管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）などの表示デバイス、およびスピーカや類似の音声出力デバイスをを含む。いくつかの実施形態は、入力及び出力デバイスの両方として機能するタッチスクリーンのようなデバイスを含む。

最後に、図９に示すように、バス９０５はまた、電子システム９００をネットワークアダプタ（不図示）を介してネットワーク９６５に接続する。このようにして、コンピュータは、（ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、イントラネット、インターネットなどのネットワークのネットワーク、などのコンピュータのネットワークの一部になることができる。電子システム９００の任意又は全ての構成要素は、本発明に関連して用いられ得る。

いくつかの実施形態は、マイクロプロセッサ、コンピュータプログラムの命令を機械で読み出し可能な又はコンピュータで読み出し可能な媒体（或いはコンピュータで読み出し可能なストレージメディア、機械で読み出し可能な媒体、又は機械で読み出し可能なストレージメディアとして参照される）に格納した、ストレージ及びメモリのような電子構成要素を含む。コンピュータで読み出し可能な媒体のいくつかの例は、ＲＡＭ、ＲＯＭ、読出専用コンパクトディスク（ＣＤ−ＲＯＭ）、記録可能コンパクトディスク（ＣＤ−Ｒ）、再書込可能コンパクトディスク（ＣＤ−ＲＷ）、読出専用デジタル多用途ディスク（例えばＤＶＤ−ＲＯＭ、デュアルレイヤＤＶＤ−ＲＯＭ）、様々な記録可能／再書込可能ＤＶＤ（ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ等）、フラッシュメモリ（例えばＳＤカード、ミニＳＤカード、マイクロＳＤカード等）、磁気及び／又はソリッドステートハードドライブ、読出専用及び記録可能Ｂｌｕ−Ｒａｙ（登録商標）ディスク、超高密度光ディスク、任意の他の光又は磁気メディア、及びフロッピーディスクを含む。コンピュータで読み出し可能な媒体は、少なくとも１つの処理ユニットによって実行可能であり、様々な動作を実行するための命令の組を含む、コンピュータプログラムを記録する。コンピュータプログラム又はコンピュータコードの例は、コンパイラによって生成されたような機械コードと、コンピュータ、電子構成要素、又はインタプリタを用いるマイクロプロセッサによって実行される、より高レベルなコードを含んだファイルとを含む。

上述の説明は、ソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサを主に参照したが、いくつかの実施形態は、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のような、１つ以上の集積回路によって実行される。ある実施形態では、そのような集積回路は回路自体に格納された命令を実行する。更に、いくつかの実施形態は、プログラマブルロジックデバイス（ＰＬＤ）、ＲＯＭ、またはＲＡＭデバイスに格納されるソフトウェアを実行する。

本明細書および本出願の任意のクレームにおいて使用されるように、「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」の語は、全て電子的又は他の技術的デバイスを参照する。これらの語は、人及び人のグループを含まない。本明細書の目的のため、表示及び表示するの語は電子デバイス上に表示することを意味する。本明細書および本出願の任意のクレームにおいて使用されるように、「コンピュータで読み出し可能な媒体」、「コンピュータで読み出し可能なメディア」及び「機械で読み出し可能な媒体」の語は、全体として、コンピュータによって読み出し可能な形式の情報を記録する、有体物、物理的なオブジェクトに制限される。これらの語は、任意の無線信号、有線でダウンロードされた信号、及び任意の他のその場限りの信号を含まない。

本明細書は、終始、仮想マシン（ＶＭ）を含む、計算環境及びネットワーク環境を参照している。しかしながら、仮想マシンは単なるデータ計算ノード（ＤＣＮ）又はデータ計算エンドノードの一例であり、アドレス可能なノードとしても参照される。ＤＣＮは、非仮想化物理ホスト、仮想マシン、ハイパーバイザや別のオペレーティングシステムを必要とすること無くホストオペレーティングシステム上で動作するコンテナ、及びハイパーバイザカーネルネットワークインタフェースモジュールを含み得る。

いくつかの実施形態では、ＶＭは、仮想化ソフトウェア（例えばハイパーバイザ、仮想マシンモニタ等）によって仮想化されたホストのリソースを用いて、ホスト上の自身のゲストオペレーティングシステムとともに動作する。テナント（すなわちＶＭのオーナー）は、どのアプリケーションをゲストオペレーティングシステム上で動作させるか選択することができる。一方、いくつかのコンテナは、ハイパーバイザ又は別のゲストオペレーティングシステムを必要とせずに、ホストオペレーティングシステム上で動作する構成物である。いくつかの実施形態では、ホストオペレーティングシステムはネームスペースを使用して、コンテナを互いに個別化し、従って、異なるコンテナ内で動作するアプリケーションの異なるグループの、オペレーティングシステムレベルのセグメンテーションを提供する。このセグメンテーションは、システムハードウェアを仮想化するハイパーバイザ-仮想化環境で提供されるＶＭセグメンテーションと類似し、従って、異なるコンテナ内で動作するアプリケーションの異なるグループを個別化する、仮想化の形式としてみることができる。このようなコンテナはＶＭより軽量である。

いくつかの実施形態では、ハイパーバイザ・カーネル・ネットワーク・インタフェース・モジュールは、ハイパーバイザ・カーネル・ネットワーク・インタフェースを有するネットワークスタックと受信／送信スレッドを含む、非ＶＭ・ＤＣＮである。ハイパーバイザ・カーネル・ネットワーク・インタフェース・モジュールの一例は、ＶＭｗａｒｅ社のＥＳＸｉ（登録商標）ハイパーバイザの一部であるｖｍｋｎｉｃモジュールである。

本明細書はＶＭを参照したが、所与の例は、物理ホスト、ＶＭ、非ＶＭコンテナ、及びハイパーバイザ・カーネル・ネットワーク・インタフェース・モジュールを含む、任意の種別のＤＣＮであってよい。事実、ネットワークの例は、いくつかの実施形態では異なる種別のＤＣＮの組み合わせを含んでよい。

さらに、用語「パケット」は、本出願を通じて、ネットワークを介して送信される特定のフォーマットにおけるビットの集合を指すために使用される。用語「パケット」は、本明細書では、ネットワークを介して送信され得る、様々なフォーマットされたビットの集合を指すために使用され得る、ことが理解されるべきである。そのようなフォーマットされたビットの集合のいくつかの例は、イーサネット（登録商標）フレーム、ＴＣＰセグメント、ＵＤＰデータグラム、ＩＰパケット等である。

本発明は多数の特定の詳細を参照して説明されたが、当業者は、本発明が発明の思想から離れることのない他の特定の形式で実施可能であることを認識する。加えて、多数の図（図６を含む）は処理を概念的に示すものである。これらの処理の特定の動作は、図示及び説明された正確な順序で実行されないかもしれない。特定の動作は、１つの連続する動作の流れで実行されないかもしれず、異なる特定の動作が異なる実施形態において実行され得る。更に、処理はいくつかの副処理（sub-process）を用いて、又は大きなマクロ処理の部分として実施され得る。従って、当業者は、発明が上述の詳細に限定されず、むしろ添付の請求項の範囲によって定義されることを理解する。

Claims (40)

1. 論理ネットワークの１つ以上の論理エンティティの実現状態を判定する方法であって、前記方法は、
   特定のイベントが発生するたびに実現番号の値をインクリメントすることと、
   前記インクリメントすることの後に、前記実現番号を、前記論理ネットワークのコントローラのセットに公開することと、
   前記論理ネットワークの論理エンティティの状態を特定するデータを受信した場合に、前記論理エンティティの状態データを前記コントローラのセットに公開することと、
   前記コントローラのセットに公開された論理エンティティのセットに対する前記状態データの実現状態について、特定の時点まで前記コントローラのセットに問い合わせることであって、前記問い合わせは、前記特定された時点に関連付けられた前記実現番号の特定の値を含む、問い合わせることと、を含む、方法。
2. 請求項１に記載の方法であって、前記特定のイベントが発生するたびに前記実現番号の前記値をインクリメントすることは、所定の時間間隔で前記実現番号の前記値を自動的にインクリメントすることを含む、方法。
3. 請求項１に記載の方法であって、前記特定のイベントが発生するたびに前記実現番号の前記値をインクリメントすることは、前記実現番号の前記値をインクリメントする新たな要求をユーザから受信するたびに、前記実現番号の前記値をインクリメントすることを含む、方法。
4. 請求項１に記載の方法であって、前記特定のイベントが発生するたびに前記実現番号の前記値をインクリメントすることは、論理エンティティデータが前記コントローラのセットに公開されるたびに、前記実現番号の前記値をインクリメントすることを含む、方法。
5. 請求項１に記載の方法であって、前記論理エンティティに対する前記受信した状態データは、ユーザから受信した前記論理エンティティの定義を含む、方法。
6. 請求項１に記載の方法であって、前記論理エンティティに対する前記受信した状態データは、管理プレーンデータベースに格納される前記論理エンティティの所望の状態を含む一方、前記論理エンティティの実現状態は前記コントローラのセットに格納される、方法。
7. 請求項６に記載の方法であって、前記論理エンティティの前記実現状態は、前記論理エンティティを実装する複数の管理フォワーディング要素（ＭＦＥ）の論理エンティティを構成するために必要な構成データを含む、方法。
8. 請求項７に記載の方法であって、前記論理エンティティは、前記コントローラのセットにおける各コントローラが、前記コントローラが前記ＭＦＥのサブセットから受信した、前記論理エンティティの前記所望の状態と前記論理エンティティのランタイム状態とに基づいて前記構成データを生成するときに、実現される、方法。
9. 請求項７に記載の方法であって、前記論理エンティティは更に、（ｉ）前記コントローラのセットにおける特定のコントローラが、前記特定のコントローラが前記ＭＦＥのサブセットから受信した、前記論理エンティティの前記所望の状態と前記論理エンティティのランタイム状態とに基づいて前記構成データを生成するとき、および、（ｉｉ）前記特定のコントローラが、前記構成データを、それぞれがＭＦＥの前記サブセットにおけるＭＦＥと共にホストマシン上で動作する、ローカルコントローラのセットに配信するとき、に実現される、方法。
10. 請求項９に記載の方法であって、各ローカルコントローラは、前記構成データを前記特定のコントローラから受信し、前記ローカルコントローラと共に動作するＭＦＥの前記論理エンティティを構成するために、前記ＭＦＥに特有の構成データを生成する、方法。
11. 請求項９に記載の方法であって、前記論理エンティティは、ホストマシン上で動作する第１のデータ計算ノードから受信したパケットを論理的に第２のデータ計算ノードにフォワードする、論理フォワーディング要素を含む、方法。
12. 請求項１１に記載の方法であって、前記ホストマシンは、第１のホストマシンであり、前記第２のデータ計算ノードは第２のホストマシン上で動作し、前記第１のホストマシン上で動作する第１のＭＦＥは前記論理フォワーディング要素のフォワーディング処理機能を実行して、前記パケットを前記第２のホストマシン上で動作する第２のＭＦＥにフォワードする、方法。
13. 請求項１に記載の方法であって、更に、前記問い合わせに対する応答を受信することを含み、前記応答は、少なくとも特定の論理エンティティが、前記実現番号の前記特定の値と関連付けられた前記特定の時点まで実現されていないことを示す、方法。
14. 請求項１３に記載の方法であって、前記特定の論理エンティティは、前記実現番号が前記特定の値より大きい新たな値を有するときに、実現される、方法。
15. 少なくとも１つの処理ユニットで実行されるマネージャアプリケーションを格納する非一時的機械可読媒体であって、前記マネージャアプリケーションは、１つ以上の論理エンティティの実現状態を決定し、前記マネージャアプリケーションは、
    特定のイベントが発生するたびに実現番号の値をインクリメントし、前記インクリメントした値を、前記論理ネットワークのコントローラのセットに公開し、
    前記論理ネットワークの論理エンティティの状態を特定するデータを受信した場合に、前記論理エンティティの状態データを前記コントローラのセットに公開し、
    前記コントローラのセットに公開された論理エンティティのセットに対する前記状態データの実現状態について、特定の時点まで前記コントローラのセットに問い合わせ、前記問い合わせは、前記特定された時点に関連付けられた前記実現番号の特定の値を含む、ための命令のセットを含む非一時的機械可読媒体。
16. 請求項１５に記載の非一時的機械可読媒体であって、前記特定のイベントが発生するたびに前記実現番号の前記値をインクリメントするための前記命令のセットは、所定の時間間隔で前記実現番号の前記値を自動的にインクリメントするための命令のセットを含む、非一時的機械可読媒体。
17. 請求項１５に記載の非一時的機械可読媒体であって、前記特定のイベントが発生するたびに前記実現番号の前記値をインクリメントするための前記命令のセットは、前記実現番号の前記値をインクリメントする新たな要求をユーザから受信するたびに、前記実現番号の前記値をインクリメントするための命令のセットを含む、非一時的機械可読媒体。
18. 請求項１５に記載の非一時的機械可読媒体であって、前記特定のイベントが発生するたびに前記実現番号の前記値をインクリメントするための前記命令のセットは、論理エンティティデータが前記コントローラのセットに公開されるたびに、前記実現番号の前記値をインクリメントするための命令のセットを含む、非一時的機械可読媒体。
19. 請求項１５に記載の非一時的機械可読媒体であって、前記論理エンティティに対する前記状態データを受信するための前記命令のセットは、ユーザから前記論理エンティティの定義を受信する命令のセットを含む、非一時的機械可読媒体。
20. 請求項１５に記載の非一時的機械可読媒体であって、前記論理エンティティに対する前記受信した状態データは、管理プレーンデータベースに格納される前記論理エンティティの所望の状態を含む一方、前記論理エンティティの実現状態は前記コントローラのセットに格納される、非一時的機械可読媒体。
21. １つ以上の論理ネットワークにおけるネットワークデータ通信を制御する中央制御プレーン（ＣＣＰ）クラスタのコントローラのための、論理ネットワークの１つ以上の論理エンティティの実現状態を識別する方法であって、前記方法は、
    実現番号の特定の値と関連付けられた特定の時点における論理エンティティのセットの実現状態に対する要求を受信することと、
    前記要求に応答して、前記セットの各論理エンティティに対する、前記特定の時点まで構成データが処理され、ホストマシンのセット上で動作するローカルコントローラのセットに配信されたかどうかを判定することと、
    前記セットの各論理エンティティに対する、前記特定の時点までの前記構成データが処理され、前記ローカルコントローラのセットに配信された場合に、成功の実現メッセージを含む実現応答を返すことと、を含む方法。
22. 請求項２１に記載の方法であって、更に、前記論理エンティティのサブセットに対する、前記特定の時点までの前記構成データが処理されず、前記ローカルコントローラのセットに配信されなかった場合に、不成功の実現メッセージを含む実現応答を返すことを含む、方法。
23. 請求項２２に記載の方法であって、前記不成功の実現メッセージは、前記論理エンティティのサブセットにおける各実現されなかった論理エンティティに対する識別情報を含む、方法。
24. 請求項２２に記載の方法であって、前記実現応答は、更に、前記ＣＣＰクラスタに公開された最新のクラスタリングイベントに関連付けられた、世代番号を含む、方法。
25. 請求項２４に記載の方法であって、前記要求は、前記論理ネットワークを管理するマネージャコンピュータから受信され、前記マネージャコンピュータは、実現応答を受信して、前記実現応答における前記世代番号と前記ＣＣＰクラスタの他のコントローラから受信された他の世代番号とを比較する、方法。
26. 請求項２５に記載の方法であって、前記マネージャコンピュータは、前記ＣＣＰクラスタの全てのコントローラから受信した前記世代番号が一致しない場合に、実現失敗メッセージを返す、方法。
27. 請求項２４に記載の方法であって、前記最新のクラスタリングイベントは、前記ＣＣＰクラスタへの新たなコントローラの追加と、前記ＣＣＰクラスタからの既存のコントローラの削除とのうちの一つを含む、方法。
28. 請求項２１に記載の方法であって、更に、
    特定のイベントが発生するたびに、前記ＣＣＰクラスタにわたってグローバルである前記実現番号のインクリメントされた値を受信することと、
    前記実現番号の前記受信した値を、前記インクリメントされた値が受信される時点まで前記コントローラに公開される、全ての論理エンティティの実現状態に関連付けることと、を含む、方法。
29. 請求項２８に記載の方法であって、特定の期間が経過すると、前記特定のイベントは自動的に発生する、方法。
30. 請求項２８に記載の方法であって、実現番号をインクリメントする新たな要求をユーザから受信した場合、前記特定のイベントが発生する、方法。
31. 請求項２１に記載の方法であって、前記実現番号は、前記論理ネットワークを管理するマネージャアプリケーションから受信され、前記マネージャアプリケーションは、前記マネージャアプリケーションがユーザから論理エンティティの定義を受信したときに、前記論理エンティティを前記コントローラに公開する、方法。
32. 請求項２１に記載の方法であって、更に、
    前記特定の時点まで全ての論理エンティティに対する前記構成データが処理されて前記ローカルコントローラに配信された場合に、前記ローカルコントローラのセットのうちの、１つ以上の管理フォワーディング要素（ＭＦＥ）の前記論理エンティティを構成していない１つ以上のローカルコントローラを識別することであって、それぞれがホストマシンにおいてローカルコントローラと共に動作する、識別することと、
    前記識別されたローカルコントローラを、前記成功実現メッセージと共に、前記実現応答に追加することと、を含む、方法。
33. 請求項３２に記載の方法であって、前記ＭＦＥがホストマシン上の前記論理エンティティを実装するように、前記論理エンティティは各ＭＦＥ上に構成されなければならず、前記ホストマシンは、前記論理ネットワークに論理的に接続されるデータ計算ノードのセットをホストする、方法。
34. 請求項３３に記載の方法であって、前記論理エンティティは、少なくとも１つの論理スイッチを含み、前記ＭＦＥは、前記データ計算ノードが論理的に接続される前記論理スイッチのフォワーディング機能を実行することにより、前記論理スイッチを実装する、方法。
35. １つ以上の論理ネットワークにおけるネットワークデータ通信を制御する中央制御プレーン（ＣＣＰ）クラスタのコントローラアプリケーションを格納する非一時的機械可読媒体であって、前記コントローラアプリケーションは、少なくとも１つの処理ユニットにより実行可能であり、前記コントローラアプリケーションは、
    実現番号の特定の値と関連付けられた特定の時点における論理エンティティのセットの実現状態に対する要求を受信し、
    前記要求に応答して、前記セットの各論理エンティティに対する、前記特定の時点まで構成データが処理され、ホストマシンのセット上で動作するローカルコントローラのセットに配信されたかどうかを判定し、
    前記セットの各論理エンティティに対する、前記特定の時点まで前記構成データが処理され、前記ローカルコントローラのセットに配信された場合に、成功の実現メッセージを含む実現応答を返し、
    前記論理エンティティのサブセットに対する、前記特定の時点まで前記構成データが処理されず、前記ローカルコントローラのセットに配信されなかった場合に、不成功の実現メッセージを含む実現応答を返す、ための命令のセットを含む非一時的機械可読媒体。
36. 請求項３５に記載の非一時的機械可読媒体であって、前記不成功の実現メッセージは、前記論理エンティティのサブセットにおける各実現されなかった論理エンティティに対する識別情報を含む、非一時的機械可読媒体。
37. 請求項３５に記載の非一時的機械可読媒体であって、前記実現応答は、更に、前記ＣＣＰクラスタに公開された最新のクラスタリングイベントに関連付けられた、世代番号を含む、非一時的機械可読媒体。
38. 請求項３５に記載の非一時的機械可読媒体であって、前記成功実現メッセージを含む前記実現応答を返す前記命令のセットは、
    前記ローカルコントローラのセットのうちの、１つ以上の管理フォワーディング要素（ＭＦＥ）の前記論理エンティティを構成していない１つ以上のローカルコントローラを識別することであって、それぞれがホストマシンにおいてローカルコントローラと共に動作する、識別することと、
    前記識別されたローカルコントローラを、前記成功実現メッセージと共に、前記実現応答に追加することと、を含む非一時的機械可読媒体。
39. 請求項３８に記載の非一時的機械可読媒体であって、前記ＭＦＥがホストマシン上の前記論理エンティティを実装するように、前記論理エンティティは各ＭＦＥ上に構成されなければならず、前記ホストマシンは、前記論理ネットワークに論理的に接続されるデータ計算ノードのセットをホストする、非一時的機械可読媒体。
40. 請求項３９に記載の非一時的機械可読媒体であって、前記論理エンティティは、少なくとも１つの論理スイッチを含み、前記ＭＦＥは、前記データ計算ノードが論理的に接続される前記論理スイッチのフォワーディング機能を実行することにより、前記論理スイッチを実装する、非一時的機械可読媒体。

Images