Sdn

OVNアーキテクチャの原則



Ovn Architecture Principle



OVNアーキテクチャ
OVN（Open Virtual Network）は、仮想ネットワークの抽象化をサポートするソフトウェアシステムです。 OVNは、仮想L2、L3オーバーレイネットワーク、完全なグループなど、既存のOVS機能に基づく仮想ネットワークの抽象化をネイティブにサポートします。 DHCPやDNSなどのサービスも彼らの関心事です。 OVSと同様に、OVNは、大規模に実行できる高品質の実稼働グレードの実装になるように設計されています。

OVN展開は、次のコンポーネントで構成されています。



CMS（クラウド管理システム）。これは、OVNのエンドユーザーです（ユーザーと管理者を介して）。 OVNとの統合には、CMS固有のプラグインと関連ソフトウェアのインストールが必要です（以下を参照）。 OVNの最初のターゲットCMSはOpenStackでした。通常はCMSと言いますが、複数のCMSでOVNのさまざまな部分を管理することもできます。

中央の場所にインストールされるOVNデータベースは、物理ノード、仮想ノード、またはクラスターにすることができます。



1つ以上（通常は多数）のハイパーバイザー。ハイパーバイザーは、Open vSwitchを実行し、OVSソースツリーのIntegrationGuide.rstで説明されているインターフェイスを実行する必要があります。サポートされているOVSハイパーバイザープラットフォームはすべて受け入れられます。

ゼロ個以上のゲートウェイ。ゲートウェイは、トンネルと物理イーサネットポート間でパケットを転送することにより、トンネルベースの論理ネットワークを物理ネットワークに拡張します。これにより、非仮想マシンが論理ネットワークに参加できるようになります。ゲートウェイは、ASICに基づくvtepモードの両方をサポートする物理マシン、仮想マシン、またはハードウェアスイッチの場合があります。

ハイパーバイザーとゲートウェイを合わせて、トランスポートノードまたはシャーシと呼びます。



次の図は、OVNと関連する主要コンポーネントのソフトウェアの相互作用を示しています。


図の上部から、次の順序で開始します。

1つ目は、前述のクラウド管理システムです。

OVN / CMSプラグインは、OVNに接続するCMSコンポーネントです。 OpenStackでは、これはNeutronプラグインです。プラグインの主な目的は、CMSの論理ネットワークの構成を、OVNが理解できる中間表現に変換することです。このコンポーネントはCMS固有である必要があるため、新しいCMSをドッキングするには、OVNに接続するための新しいプラグインを開発する必要があります。このコンポーネントの下にある他のすべてのコンポーネントは、CMSから独立しています。

OVNノースバウンドデータベースは、OVN / CMSプラグインによって渡された論理ネットワーク構成の中間表現を受け取ります。データベースモードとCMSで使用される概念は「インピーダンス整合」であるため、論理スイッチ、ルーター、ACLなどの概念を直接サポートします。詳細については、ovn-nbを参照してください。 （OVNノースバウンドデータベースには、OVN / CMSプラグインとその下のovn-northdの2つのクライアントしかありません）

Ovn-northdは、その上のOVNノースバウンドデータベースとその下のOVNサウスバウンドデータベースに接続するために使用されます。これは、従来のネットワーク概念（OVNノースバウンドデータベースから取得）の論理ネットワーク構成を、その下のOVNサウスバウンドデータベースの論理データパスフローに変換します。

OVNサウスバウンドデータベースはシステムの中心です。 （OVNサウスバウンドデータベースにも2つのクライアントしかありません。それはovn-northdであり、その下の各トランジットノードにovn-controllerがあります）。 OVNサウスバウンドデータベースには、3種類のデータが含まれています。ハイパーバイザーに到達する方法を指定する物理ネットワーク（PN）テーブルと、論理ネットワークの論理データパスフローを記述し、論理に使用される論理ネットワーク（LN）テーブルです。ネットワークコンポーネント場所は、物理ネットワークのバインディングテーブルにリンクされています。ハイパーバイザーはPNテーブルとPort_Bindingテーブルを埋め、ovn-northdはLNテーブルを埋めます。

クラスターの可用性については、OVNサウスバウンドデータベースのパフォーマンスをトランスポートノードの数に応じて拡張する必要があります。これには、ovsdb-serverでの作業が必要になる場合があります。

残りのコンポーネントはすべてのハイパーバイザーで同じです

ovn-controllerは、各ハイパーバイザーおよびソフトウェアゲートウェイ上のOVNエージェントです。北向きに、OVNサウスバウンドデータベースに接続してOVNの構成と状態を理解し、ハイパーバイザーの履歴にシャーシ列とバインディングテーブルのPNテーブルを入力します。南部では、ネットワークトラフィックを制御するためのOpenFlowコントローラーとしてovs-vswitchdに接続し、ローカルovsdb-serverに接続して、OpenvSwitchの構成を監視および制御できるようにします。

Ovs-vswitchdおよびovsdb-serverは、標準のOpenvSwitchコンポーネントです。

OVNの情報フロー
OVNの構成データは、北から南に流れます。 CMSは、OVN / CMSプラグインを介して、ノースバウンドデータベースを介して論理ネットワーク構成をovn-northdに渡します。次に、ovn-northdは構成情報を下位レベルの形式にコンパイルし、サウスバウンドデータベースを介してすべてのシャーシに渡します。

OVNのステータス情報は、南から北に流れます。 OVNは現在、次の形式でのみステータス情報を提供します。

まず、ovn-northdが北向きのLogical_Switch_Portテーブルのup列を埋めます。southboundPort_Bindingテーブルの論理ポートのシャーシ列が空でない場合はtrueに設定され、それ以外の場合はfalseに設定されます。これにより、CMSは仮想マシンのネットワーク接続が利用可能になったことを検出できます。

次に、OVNは、構成の実装、つまりCMSによって提供された構成が有効になっているかどうかについてCMSにフィードバックを提供します。この機能では、CMSがシリアル番号プロトコルに参加する必要があります。これは次のように機能します。

CMSがノースバウンドデータベースの構成を更新すると、同じトランザクションの一部としてNB_Globalテーブルのnb_cfg列の値が増加します。 （これは、CMSが構成がいつ実装されたかを知りたい場合にのみ必要です。）
ovn-northdは、ノースバウンドデータベースの特定のスナップショットに対してサウスバウンドデータベースを更新すると、同じトランザクションの一部として、ノースバウンドNB_Globalテーブルのnb_cfg列をサウスバウンドデータベースSB_Globalテーブルにコピーします。 。 （したがって、両方のデータベースを監視しているオブザーバーは、サウスバウンドデータベースがノースバウンドデータベースといつ整合しているかを判断できます）
ovn-northdは、変更が南からデータベースサーバーに送信されたという確認を受信すると、ノースバウンドデータベースNB_Globalテーブルのsb_cfg列をプッシュされたnb_cfgバージョン番号に更新します。 （したがって、CMSまたは他のオブザーバーは、サウスバウンドデータベースがキャプチャされ、サウスバウンドデータベースに接続されていない時期を判断できます）
各シャーシのovn-controllerプロセスは、更新されたサウスバウンドデータベースを受信し、nb_cfgを更新します。このプロセスは、シャーシ上のOpenvSwitchインスタンスにインストールされている物理フローを順番に更新します。物理ストリームがOpenvSwitchから更新されたという確認応答を受信した後、サウスバウンドデータベース内の独自のシャーシレコードのnb_cfgを更新します。
ovn-northdは、サウスバウンドデータベースのすべてのシャーシレコードのnb_cfg列を監視します。すべてのレコードの最小値を追跡し、それらをノースバウンドNB_Globalテーブルのhv_cfg列にコピーします。 （したがって、CMSまたは他のオブザーバーは、すべてのハイパーバイザーがノースバウンドデータベースの構成と一致する時期を判断できます）
シャーシが起動します
OVN展開の各シャーシは、統合ブリッジと呼ばれるOVN専用のOpenvSwitchブリッジで構成する必要があります。必要に応じて、システム起動スクリプトは、ovn-controllerを起動する前にこのブリッジを作成できます。 ovn-controllerの起動時にブリッジが存在しない場合は、以下に示すデフォルト構成を使用して、ブリッジが自動的に作成されます。統合ブリッジのポートは次のとおりです。

どのシャーシでも、OVNは論理ネットワーク接続用のトンネルポートを維持するために使用されます。 ovn-controllerは、これらのトンネルポートの追加、更新、および削除を担当します。
ハイパーバイザー上で、論理ネットワークに接続するすべてのVIF。ハイパーバイザー自体またはOpenvSwitchとハイパーバイザー（IntegrationGuide.rstで説明）間の統合により、この問題が処理されます。 （これはOVNの一部ではなく、OVNの新機能でもありません。これはOVSをサポートするハイパーバイザーですでに行われている統合前の作業です）
ゲートウェイで、論理ネットワーク接続に使用される物理ポート。システム起動スクリプトは、ovn-controllerを起動する前に、このポートをブリッジに追加します。より複雑な設定では、これは物理ポートではなく、別のブリッジへのパッチポートである可能性があります。
他のポートは統合ブリッジに接続しないでください。特に、（物理ポートを論理ネットワークに接続するゲートウェイポートとは対照的に）基盤となるネットワークに接続されている物理ポートは、統合ブリッジに接続できません。基盤となる物理ポートは、個別のOpen vSwitchブリッジに接続する必要があります（実際には、ブリッジに接続する必要はまったくありません）。

統合ブリッジは、以下のように構成する必要があります。これらの各設定の効果は、ファイルOVS-vswitchd.conf.dbに記録されます。

Fail-mode = secure：ovn-controllerが起動する前に、分離された論理ネットワーク間でパケットを切り替えないようにします。詳細については、ovs-vsctlの「コントローラー障害設定」セクションを参照してください。

Other-config：disable-in-band = true：統合ブリッジの帯域内制御フローを抑制します。 OVNはリモートコントローラーの代わりに（Unixドメインソケットを介して）ローカルコントローラーを使用するため、このような制御フローは明らかにまれです。ただし、同じシステム内の他のブリッジ用のインバンドリモートコントローラーが存在する場合があります。その場合、インバンドコントローラーによって通常確立されるトラフィックが抑制される可能性があります。詳細については、ドキュメントを参照してください。

統合ブリッジのカスタム名はbr-intですが、他の名前を使用することもできます。

論理ネットワーク
論理ネットワークは物理ネットワークと同じ概念を実装しますが、トンネルまたはその他のカプセル化によって物理ネットワークから分離されます。これにより、論理ネットワークは、物理ネットワークのアドレススペースとオーバーラップでき、競合しない個別のIPおよびその他のアドレススペースを持つことができます。論理ネットワークトポロジは、基盤となる物理ネットワークのトポロジを無視できます。

OVNの論理ネットワークの概念は次のとおりです。
*論理スイッチ、イーサネットスイッチの論理バージョン。
*論理ルーター、IPルーターの論理バージョン。論理スイッチとルーターは、複雑なトポロジに接続できます。
*論理データパス、OpenFlowスイッチの論理バージョン。論理スイッチとルーターの両方が論理データパスとして実装されます。
*論理ルーターの内外の論理ポート、論理スイッチ、および接続ポイント。一般的な論理ポートタイプは次のとおりです。

*はVIFの論理ポートを示します
*ローカルネットポート。論理スイッチと物理ネットワーク間の接続ポイントを表します。統合ブリッジと、基盤となる物理ポートが接続されている独立したOpen vSwitchブリッジとの間のOVSパッチポートは、Localnetポートです。
*論理スイッチと論理ルーター間の接続ポイント、場合によってはピア論理ルーター間の接続ポイントを表す論理パッチポート。各接続ポイントには、両端に1つずつ、論理接続ポートのペアがあります。
*ローカルポートポート。論理スイッチとVIF間のローカル接続ポイントを表します。これらのポートはすべてのシャーシ（特定のシャーシに限定されない）に存在し、それらからのトラフィックがトンネルを通過することはありません。 Localportポートは、通常、受信した要求に応答して、ローカル宛先宛てのトラフィックのみを生成します。 1つのユースケースは、OpenStack NeutronがLocalportポートを使用して、各ハイパーバイザーに存在する仮想マシンにメタデータを提供する方法です。メタデータエージェントプロセスは各ホストのこのポートに接続し、同じネットワーク内のすべての仮想マシンは、トンネルを介してトラフィックを送信することなく、同じIP / MACアドレスを使用してポートに到達します。詳細については、[https://docs.openstack.org/developer/networking/ovn/design/metadata_api.html]（https://docs.openstack.org/developer/networking/ovn/design/metadata_api）をご覧ください。 html）私はそれを見ました。
VIFライフサイクル
データベーステーブルとそのスキーマは分離されており、理解するのが困難です。これは一例です。

ハイパーバイザー上のVIFは、ハイパーバイザー上で直接実行されている仮想マシンまたはコンテナーに接続する仮想ネットワークインターフェイスです（これは、仮想マシン内のコンテナー上で実行されているインターフェイスとは異なります）。

この例の手順には、通常、OVNおよびOVNノースバウンドデータベーススキーマの詳細が含まれます。これらのデータベースの完全な内容については、ovn-sbおよびovn-nbのセクションを参照してください。

CMS管理者がCMSユーザーインターフェイスまたはAPIを使用して新しいVIFを作成し、それをスイッチ（OVNによって論理スイッチとして実装されたスイッチ）に追加すると、VIFのライフサイクルが始まります。 CMSは、主にVIFの一意の永続識別子vif-idをイーサネットアドレスmacに関連付けるなど、独自の設定を更新します。
CMSプラグインは、Logical_Switch_Portテーブルに行を追加することにより、OVNノースバウンドデータベースを更新して新しいVIF情報を含めます。新しい行では、名前はvif-id、macはmac、スイッチはOVN論理スイッチのLogical_Switchレコードを指し、他の列は適切に初期化されています。
ovn-northdは、OVNノースバウンドデータベースの更新を受け取りました。次に、OVNサウスバウンドデータベースは、データベースのLogical_Flowテーブルに新しいポートを反映するようにOVNサウスに新しい行を追加することによって更新されます。たとえば、新しいポートのMACアドレスにアドレス指定されたパケットを識別するためのストリームを追加する必要があります。また、ブロードキャストパケットとマルチキャストパケットを配信するストリームは、新しいポートを含むように更新されます。また、Bindingsテーブルにレコードを作成し、認識シャーシ列を除くすべての列にデータを入力します。
各ハイパーバイザーで、ovn-controllerは、Logical_Flowテーブルの前のステップovn-northdによって行われた更新を受け取ります。ただし、VIFを備えた仮想マシンがある限り、ovn-controllerはそれについて何もできません。たとえば、VIFは実際にはどこにも存在しないため、VIFからパケットを送信したり、VIFからパケットを受信したりすることはできません。
最後に、ユーザーはVIFを所有するVMを起動します。 VMによって開始されるハイパーバイザーでは、ハイパーバイザーとOpen vSwitch（IntegrationGuide.rstで説明）間の統合は、VIFをOVN統合ブリッジに追加し、vif-idをexternal_ids：iface-idに格納することによって行われます。インターフェイスが新しいVIFのインスタンスであることを示します。 （これらのコードはOVNでは新しいものではありません。これは、OVSをサポートするハイパーバイザーですでに行われている統合前の作業です。）
VMを起動するハイパーバイザーで、ovn-controllerは新しいインターフェースのexternal_ids：iface-idに気づきます。それに応じて、OVNサウスバウンドデータベースで、バインディングテーブルのシャーシ列にあるリンクされた論理ポートをexternal_ids：iface-idからハイパーバイザー行に更新します。その後、ovn-controllerはローカル仮想マシンハイパーバイザーのOpenFlowテーブルを更新して、VIF宛てのパケットとVIFからのパケットを適切に処理します。
OpenStackを含む一部のCMSシステムは、ネットワークの準備ができている場合にのみ仮想マシンを完全に起動できます。この機能をサポートするために、ovn-northdは、Bindingテーブルのchassis列の行が更新されていることを検出します。この変更は、OVNノースバウンドデータベースのLogic_Switch_Portテーブルのup列を更新して、VIFが開始されたことを示すことで上向きに示されます。この機能を使用すると、CMSはVMの実行を許可することにより、後続の反応を続行できます。
VIFが配置されている各ハイパーバイザーで、ovn-controllerは、バインディングテーブルの完全に入​​力された行に気づきます。これにより、ovn-controllerの論理ポートの物理的な場所が提供されるため、各インスタンスは、トンネルを介してVIFとの間で適切に処理されるように、スイッチのOpenFlowフローテーブル（OVNデータベースLogical_Flowテーブルの論理データパスフローに基づく）を更新します。 。データパック。
最後に、ユーザーはVIFを所有するVMを閉じます。 VMがシャットダウンされているハイパーバイザーでは、VIFはOVN統合ブリッジから削除されます。
VMがダウンしているハイパーバイザーで、ovn-controllerはVIFが削除されたことを認識します。それに応じて、論理ポートバインディングテーブルのChassis列の内容を削除します。
各ハイパーバイザーで、ovn-controllerは、バインドされたテーブル行の中空のChassis列に気付きます。これは、ovn-controllerが論理ポートの物理的な場所を認識しなくなったことを意味します。そのため、各インスタンスはこれを反映するようにOpenFlowテーブルを更新します。
最後に、VIF（またはそのVM全体）が誰にも必要なくなった場合、管理者はCMSユーザーインターフェイスまたはAPIを使用してVIFを削除します。 CMSは独自の設定を更新します。
CMSプラグインは、Logical_Switch_Portテーブルの関連する行を削除することにより、OVNNorthからデータベースへのVIFを削除します。
ovn-northdは、OVNノースバウンドデータベースの更新を受信し、それに応じてOVNサウスバウンドデータベースをdデータベースLogical_Flowテーブルおよびバインディングテーブルから削除または更新することにより、OVNサウスバウンドデータベースを更新します。 VIF関連の行を破棄します。
各ハイパーバイザーで、ovn-controllerは前のステップでLogical_Flowテーブルの更新を受信し、OpenFlowテーブルを更新します。やることはあまりないかもしれませんが、VIFにアクセスできなくなったため、前の手順でバインディングテーブルから削除されました。
VM内部コンテナインターフェイスのライフサイクル
OVNは、OVN_NBデータベースに書き込まれた情報を各ハイパーバイザーのOpenFlowフローテーブルに変換することにより、仮想ネットワークの抽象化を提供します。 OVNコントローラーがOpenvSwitchのフローを変更できる唯一のエンティティである場合、OVNコントローラーはマルチテナントに安全な仮想ネットワーク接続のみを提供できます。 Open vSwitch統合ブリッジがハイパーバイザーに存在する場合、仮想マシン内で実行されているテナントワークロードはOpenvSwitchフローに変更を加えることができません。

インフラストラクチャプロバイダーが、コンテナー内のアプリケーションがOpen vSwitchストリームを中断および変更しないことを信頼している場合は、ハイパーバイザーでコンテナーを実行できます。コンテナーが仮想マシンで実行されている場合も同様です。この場合、同じVMに存在し、OVNコントローラーによって制御されるOpenvSwitch統合ブリッジがあります。どちらの場合も、ワークフローは前のセクションの例（「VIFライフサイクル」）で説明したものと同じです。

このセクションでは、コンテナーが仮想マシンで作成され、OpenvSwitch統合ブリッジがハイパーバイザーに存在する場合のコンテナーインターフェイス（CIF）のライフサイクルについて説明します。この場合、VM内で実行されているコンテナーは、Open vSwitch統合ブリッジのフローを変更できないため、コンテナーアプリケーションに障害が発生しても、他のテナントは影響を受けません。

仮想マシン内に複数のコンテナーを作成する場合、複数のCIFアソシエーションがあります。 OVNが仮想ネットワークの抽象化をサポートするには、これらのCIFに関連付けられたネットワークトラフィックが、ハイパーバイザーで実行されているOpenvSwitch統合ブリッジに到達する必要があります。 OVNは、異なるCIFからのネットワークトラフィックを区別できる必要もあります。 CIFネットワークトラフィックを区別する方法は2つあります。

最初の方法は、各CIFにVIF（1：1）を提供することです。これは、ハイパーバイザーに多くのネットワークデバイスが存在する可能性があることを意味します。これにより、すべてのVIFの余分なCPU消費を管理することにより、OVSの速度が低下します。これは、VMでコンテナーを作成するエンティティが、ハイパーバイザーで対応するVIFも作成できる必要があることも意味します。

2番目の方法は、すべてのCIFにVIF（1：n）を提供することです。 OVNは、各パケットに書き込まれたタグによって、ネットワークトラフィックをさまざまなCIFから区別できます。 OVNはこのメカニズムを使用し、VLANをタグ付けメカニズムとして使用します。

CIFのライフサイクルは、仮想マシン内にコンテナを作成することから始まります。これは、同じCMS、または最初に作成したCMSとは異なるコンテナシステムで仮想マシンを作成または所有したテナントが作成できます。仮想マシン。作成します。コンテナを作成したエンティティが誰であるかに関係なく、コンテナインターフェイスのネットワークトラフィックが通過する仮想マシンのネットワークインターフェイスに関連付けられたvif-idを知っている必要があることを知っている必要があります。コンテナインターフェイスを作成するエンティティは、仮想マシン内の未使用のVLANも選択する必要があります。
コンテナを作成するエンティティ（基盤となるインフラストラクチャを管理するCMSを介して直接的または間接的に）は、Logical_Switch_Portテーブルに行を追加することにより、OVNサウスバウンドデータベースを更新して新しいCIFを含めます。新しい行では、nameは任意の一意の識別子、parent_nameはCIFネットワークトラフィックが通過すると予想されるVMのvif-id、tagはCIFネットワークトラフィックを識別するVLANタグです。
ovn-northdは、OVNノースバウンドデータベースの更新を受け取りました。逆に、対応する行をOVNサウスデータベースのLogical_Flowテーブルに追加することで新しいポートを反映し、Bindingテーブルに新しい行を作成してID列を除くすべての列にデータを入力することでOVNサウスバウンドデータベースを更新します。シャーシ。
各ハイパーバイザーで、ovn-controllerはバインディングテーブルの変更をサブスクライブします。 ovn-northdによって作成された新しい行に、Bindingテーブルのparent_port列の値が含まれている場合、external_ids：iface-idのvif-idと同じ値を持つovn統合ブリッジのovn-controllerがのOpenFlowを更新します。ローカルハイパーバイザーフローテーブルは、特定のVLANタグを持つVIFからのパケットが正しく処理されるようになっています。その後、物理的な場所を反映するようにバインディングテーブルのシャーシ列を更新します。
基盤となるネットワークの準備が整うと、アプリケーションはコンテナ内でのみ起動できます。この機能をサポートするために、ovn-northdは、バインディングテーブルの更新されたシャーシ列に通知し、OVNノースバウンドデータベースのLogical_Switch_Portテーブルのup列を更新して、CIFが開始されたことを示します。コンテナアプリケーションの起動を担当するエンティティは、この値を照会してアプリケーションを起動します。
最後に、コンテナを停止する場合は、コンテナのエンティティを作成して開始します。エンティティは、CMSを介して（または直接）Logical_Switch_Portテーブルの行を削除します。
ovn-northdは、OVNノースバウンド更新を受信し、それに応じて、破壊されたCIFに関連付けられた行をOVNサウスバウンドデータベースLogical_Flowテーブルから削除または更新することにより、OVNサウスバウンドデータベースを更新します。また、CIFのバインディングテーブルの行も削除されます。
各ハイパーバイザーで、ovn-controllerは前のステップでLogical_Flowテーブルの更新を受け取ります。 ovn-controllerは、更新を反映するためにローカルOpenFlowテーブルを更新します。
パケットの物理的な処理ライフサイクル
このセクションでは、OVNを介してパケットが1つの仮想マシンまたはコンテナから別の仮想マシンまたはコンテナに転送される方法について説明します。この説明は、パケットの物理的な処理に焦点を当てています。パケットロジックのライフサイクルの説明については、ovn-sbのLogical_Flowテーブルを参照してください。

わかりやすくするために、このセクションでは、次のように要約されたいくつかのデータフィールドとメタデータフィールドについて説明します。

トンネルキー。 OVNがパケットをジュネーブまたは他のトンネルにカプセル化すると、受信したOVNインスタンスを正しく処理できるように、追加のデータが追加されます。これはカプセル化の特定の形式に依存し、異なる形式を取りますが、いずれの場合も「トンネルキー」と呼びます。詳細については、記事の最後にある「トンネルカプセル化」を参照してください。
論理データパスフィールド。パケットが処理されている論理データパスを表すフィールド。 OVNはOpenFlow1.1 +を使用して、論理データパスフィールドを格納するために「メタデータ」を単純に（そして簡単に混乱させて）呼び出します。 （このフィールドは、トンネルキーの一部としてトンネルを通過します。）
論理入力ポートフィールド。パケットがどの論理ポートから論理データパスに入るのかを示すフィールド。 OVNはそれをOpenvSwitch拡張レジスタ14に格納します。GeneveトンネルとSTTトンネルは、トンネルキーの一部としてこのフィールドを渡します。 VXLANトンネルは論理入力ポートを明示的に伝送しませんが、OVNはVXLANを使用してゲートウェイと通信するだけです。 OVNの観点からは、論理ポートは1つしかないため、OVNは、OVNに入力するときに、論理入力ポートフィールドを論理入力に設定できます。論理パイプライン。
論理出力ポートフィールド。パケットが論理データパスを離れる論理ポートを示すフィールド。論理エントリパイプの開始時に、ゼロに初期化されます。 OVNはそれをOpenvSwitch拡張レジスタ15に格納します。GeneveトンネルとSTTトンネルは、トンネルキーの一部としてこのフィールドを渡します。 VXLANトンネルは、論理出力ポートフィールドを送信しません。 VXLANトンネルはトンネルキーの論理出力ポートフィールドを伝送しないため、OVNハイパーバイザーはVXLANトンネルからパケットを受信すると、パケットをフローテーブル8に再送信して、出力ポートを決定します。 。パケットがフローテーブル32に到着すると、パケットがVXLANトンネルから到着したときに設定されたMLF_RCV_FROM_VXLANフラグをチェックすることにより、これらのパケットはローカル送信のためにテーブル33に再送信されます。
論理ポートのconntrackareaフィールド。論理ポートの接続追跡領域を表すフィールド。値はローカルでのみ意味があり、クロスシャーシ間には意味がありません。論理エントリパイプの開始時に、ゼロに初期化されます。 OVNはそれをOpenvSwitch拡張レジスタ13に保存します。
ルーターの接続領域。ルーターの接続追跡領域を表すフィールド。値はローカルでのみ意味があり、クロスシャーシ間には意味がありません。 OVNは、DNATting領域情報をOpen vSwitch拡張レジスタ11に格納し、SNATing領域情報をOpenvSwitch拡張レジスタ12に格納します。
論理フローフラグ。論理フラグは、後続のテーブルのどのルールが一致するかを判断するために、フローテーブル間のコンテキストの維持を処理するように設計されています。値はローカルでのみ意味があり、クロスシャーシ間には意味がありません。 OVNは、論理フラグをOpenvSwitch拡張レジスタ10に格納します。
VLANID。 VLAN IDは、OVNとVM内にネストされたコンテナーとの間のインターフェースとして使用されます（詳細については、上記のVM内部オーガナイザーインターフェースのライフサイクルを参照してください）。
まず、ハイパーバイザー上のVMまたはコンテナーは、OVN統合ブリッジに接続されたポートを介してパケットを送信します。詳細なライフサイクルは次のとおりです。

OpenFlowフローテーブル0は、物理から論理への変換を実行します。パケットの入力ポートと一致します。この操作では、論理データパスフィールドを設定してパケットが通過する論理データパスを識別し、論理入力ポートフィールドを設定してパケットに論理メタデータのタグを付けることにより、入力ポートを識別します。次に、表8に再サブミットして、論理エントリー・パイプラインに入ります。

仮想マシン内にネストされたコンテナーから発信されたパケットがわずかに異なる方法で処理される場合。発信元コンテナはVIF固有のVLANIDに基づいて区別できるため、物理から論理への変換プロセスもVLAN IDフィールドで一致する必要があり、アクションによってVLANヘッダーが削除されます。このステップの後、OVNは他のパケットと同じようにコンテナからのパケットを処理します。

フローテーブル0は、他のシャーシから到着するパケットも処理します。入力ポート（トンネル）を介して他のパケットと区別します。 OVNパイプラインに入るパケットと同様に、これらの操作では、論理データパスと論理入力ポートメタデータを使用して、これらのパケットに注釈を付けます。さらに、このアクションは論理出力ポートフィールドを設定します。これは、論理出力ポートがovnトンネルカプセル化の前に認識されているために使用できます。これらの3つの情報は、トンネルカプセル化メタデータから取得されます（コーディングの詳細については、トンネルカプセル化を参照してください）。次に、操作は表33に再サブミットし、論理出口パイプに入ります。

OpenFlowフローテーブル8〜31は、OVNサウスバウンドデータベースのLogical_Flowテーブルの論理エントリパイプを実行します。これらのフローテーブルは、論理ポートや論理データパスなどの論理概念の表現に完全に使用されます。 ovn-controllerの作業の大部分は、それらを同等のOpenFlowに変換することです（特にデータベーステーブルの変換：Logical_Flowテーブル0からテーブル23をOpenFlowフローテーブル8から31に変換します）。

各論理フローは、1つ以上のOpenFlowフローにマップされます。実際のパケットは通常、そのうちの1つにのみ一致しますが、場合によってはそのような複数のストリームに一致することもあります（これらはすべて同じアクションを持つため、これは問題ではありません）。 ovn-controllerは、論理ストリームのUUIDの最初の32ビットをOpenFlowストリームのCookieとして使用します。 （ロジックフローのUUIDの最初の32ビットは必ずしも一意ではないため、これは必ずしも一意ではありません。）

一部のロジックフローは、Open vSwitchの「接続一致」拡張機能にマップできます（ovs-fieldセクションのドキュメントを参照）。ストリーム接続操作で使用されるOpenFlowCookieは、複数のロジックストリームに対応できるため、0です。 OpenFlowストリーム接続の一致には、conj_idの一致が含まれています。

ハイパーバイザーでロジックフローを使用できない場合、一部のロジックフローは、特定のハイパーバイザーのOpenFlowフローテーブルに表示されない場合があります。たとえば、論理スイッチ内の特定のハイパーバイザーにVIFが存在せず、ハイパーバイザー上の他の論理スイッチにアクセスできない場合（たとえば、ハイパーバイザー上のVIFで始まる論理スイッチおよびルーターからの一連のホップ）、フローが表示されない場合があります。

ほとんどのOVN操作には、OpenFlow（OVS拡張機能付き）でかなり明白な実装があります。たとえば、次の実装は再送信、field =定数、set_fieldについては、以下で詳しく説明します。

出力

これは、パケットをテーブル32に再送信することによって行われます。パイプラインが複数の出力アクションを実行する場合、それぞれが個別にテーブル32に再送信されます。これを使用して、パケットの複数のコピーを複数のポートに送信できます。 （出力操作間でパケットが変更されず、一部のコピーが同じハイパーバイザーに割り当てられている場合、論理マルチキャスト出力ポートを使用すると、ハイパーバイザー間の帯域幅を節約できます。）

get_arp（P、A）

get_nd（P、A）

これは、OpenFlowフィールドにパラメーターを保存してから、テーブル66に再送信することで実行されます。テーブル66は、EVN Southを使用して、データベースのMAC_Bindingテーブルからこの66ストリームテーブルを生成します。表66に一致するものがある場合、そのアクションにより、バインドされたMACがイーサネット宛先アドレスフィールドに格納されます。

OpenFlow操作は、上記のパラメーターのOpenFlowフィールドを保存および復元し、OVN操作はこの一時的な使用を知る必要はありません。

put_arp（P、A、E）

put_nd（P、A、E）

MAC_Bindingテーブルは、OpenFlowフィールドにパラメーターを格納することにより、ovn-controllerによって更新されます。

OpenFlow操作は、上記のパラメーターのOpenFlowフィールドを保存および復元し、OVN操作はこの一時的な使用を知る必要はありません。

OpenFlowフローテーブル32から47は、論理エントリパイプで出力アクションを実行します。具体的には、表32はリモートハイパーバイザーへのパケットを処理し、表33はハイパーバイザーへのパケットを処理し、表34は同じ論理入力ポートと出力ポートを持つパケットを破棄する必要があるかどうかを確認します。

論理パッチポートは特殊なケースです。論理パッチポートには物理的な場所がなく、各ハイパーバイザーに効果的に存在します。したがって、ローカルハイパーバイザーへのポート出力のフローテーブル３３は、当然、ユニキャスト論理パッチポートへの出力も実装する。ただし、論理マルチキャストグループの一部である論理パッチポートに同じロジックを適用すると、パケットが重複します。これは、マルチキャストグループに論理ポートを含む各ハイパーバイザーもパケットを論理パッチポートに出力するためです。したがって、マルチキャストグループは、表32の論理パッチポートの出力を実行します。

表32の各フローは、リモートハイパーバイザーの論理ポートを含む、論理出力ポートのユニキャストまたはマルチキャスト論理ポートと一致します。各ストリームの運用上の実装は、一致するポートにパケットを送信することです。リモートハイパーバイザーのユニキャスト論理出力ポートの場合、操作はトンネルキーを正しい値に設定してから、トンネルポート上のパケットを正しいリモートハイパーバイザーに送信します。 （リモートハイパーバイザーがパケットを受信すると、表0はそれをトンネルパケットとして識別し、表33に渡します。）マルチキャスト論理出力ポートの場合、操作は、ユニキャストのように、パケットのコピーを各Aリモートハイパーバイザーに送信します。先。マルチキャストグループにローカルハイパーバイザー上の1つ以上の論理ポートが含まれている場合、そのアクションも表33に再送信されます。表32には次のものも含まれます。

VXLANトンネルから受信したパケットの優先度の高いルールは、フラグMLF_RCV_FROM_VXLANに従って照合され、これらのパケットはローカル配信のために表33に再送信されます。トンネルキーに論理出力ポートフィールドがないため、VXLANトンネルから受信したパケットがここに到着するため、これらのパケットを表8に送信して、出力ポートを決定する必要があります。
論理入力ポートに基づいてローカルポートタイプのポートから受信したパケットを照合し、ローカル配信のためにこれらのパケットを表33に再送信する、より優先度の高いルール。各ハイパーバイザーには、localportタイプのポートがあります。定義上、彼らのトラフィックはトンネルを通って出てはいけません。
他に一致するものがない場合、フローテーブル３３への代替ストリームが再送信される。
表33のフロー表は、リモートではなくローカルに存在する論理ポートの表32のフロー表に似ています。ローカルハイパーバイザーのユニキャスト論理出力ポートの場合、操作は表34に再送信されます。ローカルハイパーバイザーに1つ以上の論理ポートを含むマルチキャスト出力ポートの場合、そのような論理ポートPごとに、操作には論理があります。出力ポートがPに変更され、表34に再送信されます。

特殊なケースは、ローカルネットポートがデータパスに存在し、ローカルネットポートに切り替えてリモートポートに接続する場合です。この場合、表32のリモートポートにストリームを追加する代わりに、表33にストリームを追加して、論理出力ポートをローカルネットポートに切り替え、ユニキャストされているかのように表33に再送信します。ローカルハイパーバイザー。

表34は、論理入力ポートと出力ポートが同じで、MLF_ALLOW_LOOPBACKフラグが設定されていないパケットを照合して破棄します。他のパケットを表40に再送信します。

OpenFlowテーブル40から63は、OVNサウスバウンドデータベースのLogical_Flowテーブルの論理出口フローを実行します。出口パイプラインは、パケットが配信される前に検証の最終フェーズを実行できます。最後に、出力アクションを実行できます。ovn-controllerは、表64に再送信することで実装されます。パイプラインが出力を実行しないパケットは、事実上破棄されます（ただし、物理ネットワークを介してトンネルを介して送信された可能性があります）。

出口パイプは、論理出力ポートを変更したり、トンネルカプセル化をさらに実行したりすることはできません。

表64は、MLF_ALLOW_LOOPBACKが設定されている場合、OpenFlowループバックをバイパスします。論理ループバックは表34で処理されますが、OpenFlowは、ループがデフォルトでOpenFlow入力ポートに戻ることも防ぎます。したがって、MLF_ALLOW_LOOPBACKが設定されると、OpenFlowテーブル64はOpenFlow入力ポートを保存して0に設定し、論理から物理への変換のためにテーブル65に再送信してから、OpenFlow入力ポートを復元し、OpenFlowループバック防止を効果的に無効にします。 MLF_ALLOW_LOOPBACKが設定されていない場合、表64のフローは表65にのみ再送信されます。

OpenFlowテーブル65は、表0とは対照的に、論理から物理への変換を実行します。これは、パケットの論理出力ポートと一致します。その動作により、論理ポートを表すOVN統合ブリッジポートにパケットが出力されます。論理出力ポートがVMにネストされたコンテナである場合、パケットを送信する前に、適切なVLANIDを持つVLANヘッダーが追加されます。

論理ルーターと論理パッチポート
通常、論理ルーターと論理パッチポートには物理的な場所がなく、実際にはハイパーバイザー上にあります。これは、VM（およびVIF）が接続されている論理ルーターとこれらの論理ルーターの背後にある論理スイッチ間の論理パッチポートの場合です。

ある仮想マシンまたはコンテナから別のサブネット上の別のVMまたはコンテナに送信されたパケットについて考えてみます。パケットは、前の「パケットの物理的ライフサイクル」セクションで説明したように、送信者が接続されている論理スイッチを表す論理データパスを使用してテーブル0〜65を通過します。表32では、パケットはハイパーバイザー上の表33のフォールバックストリームにローカルで再送信されます。この場合、表0から表65までのすべての処理は、パケット送信者が配置されているハイパーバイザーで実行されます。

パケットがテーブル65に到着すると、論理出力ポートは論理パッチポートになります。表65の実装は、OVSのバージョンによって異なりますが、観察された動作の意図は同じです。

OVSバージョン2.6以前では、表65が論理パッチポートを表すOVSのパッチポートに出力されます。 OVSパッチポートのピアで、パケットはOpenFlowフローテーブルに再入力され、その論理データパスと論理入力ポートの両方がOVSパッチポートに基づくOpenFlowポート番号であることを示します。

OVS 2.7以降では、パケットはクローン化され、入力パイプラインの最初のOpenFlowフローテーブルに直接再送信され、論理入力ポートはピア論理パッチポートに設定され、ピア論理パッチポートのロジックが使用されます。データパス（実際には論理ルーターを表します）。

パケットは入力パイプラインに再び入り、表8から65を再び通過します。今回は、論理ルーターを表す論理データパスを使用します。前のセクション「パケットの物理的ライフサイクル」で説明したように、処理は続行されます。パケットが表65に到着すると、論理出力ポートが再び論理パッチポートになります。上記と同じ方法で、この論理パッチポートにより、データパケットがOpenFlowテーブル8〜65に再送信されます。今回は、ターゲットVMまたはコンテナが接続されている論理スイッチの論理データパスを使用します。

グループは、3回目で最後に表8から65をトラバースしました。ターゲットVMまたはコンテナがリモートハイパーバイザーに存在する場合、表32は、送信者のハイパーバイザーからトンネルポート上のリモートハイパーバイザーにパケットを送信します。最後に、表65は、パケットをターゲットVMまたはコンテナーに直接出力します。

次のセクションでは、論理ルーターまたは論理パッチポートが物理的な場所に関連付けられている2つの例外について説明します。

ゲートウェイルーター
ゲートウェイルーターは、物理的な場所にバインドされている論理ルーターです。これには、論理ルーターのすべての論理パッチポートと、論理スイッチのすべてのピア論理パッチポートが含まれます。 OVNサウスバウンドデータベースでは、これらの論理パッチポートのPort_Bindingエントリは、パッチタイプではなくl3gatewayタイプを使用して、これらの論理パッチポートをシャーシへのバインドから区別します。

ハイパーバイザーが論理スイッチを表す論理データパスでパケットを処理し、論理出力ポートがゲートウェイルーターとの接続を示すl3ゲートウェイポートである場合、サマーパッケージは表32のフローテーブルと一致し、パケットは次のようになります。トンネルポートを介してトンネルポートに送信されます。ゲートウェイルーターが配置されているシャーシ。表32の処理は、VIFと同じです。

ゲートウェイルーターは通常、分散論理ルーターと物理ネットワークの間で使用されます。分散論理ルーターとその背後にある論理スイッチ（仮想マシンとコンテナーが接続されている論理スイッチ）は、実際には各ハイパーバイザーに存在します。分散ルーターとゲートウェイルーターは、接続された論理スイッチと呼ばれることもある別の論理スイッチを介して接続されます。一方、ゲートウェイルーターは、ローカルネットポートが物理ネットワークに接続されている別の論理スイッチに接続されています。

ゲートウェイルーターを使用する場合、DNATルールとSNATルールはゲートウェイルーターに関連付けられます。ゲートウェイルーターは、1対多のSNAT（別名IPマスカレード）を処理できる中央の場所を提供します。

分散ゲートウェイポート
分散ゲートウェイポートは、分散論理ルーターをローカルネットワークポートを備えた論理スイッチに接続する論理ルーターパッチポートです。

分散ゲートウェイポートの主な設計目標は、VMまたはコンテナが存在するハイパーバイザーで可能な限りローカルでトラフィックを処理することです。可能な限り、仮想マシンまたはコンテナから外部へのパケットは、仮想マシンまたはコンテナハイパーバイザーで完全に処理され、最終的にハイパーバイザー上のすべてのローカルネットポートインスタンスを通過して物理ネットワークに到達する必要があります。可能な場合は常に、外部から仮想マシンまたはコンテナへのパケットは、物理ネットワークを介して仮想マシンまたはコンテナのハイパーバイザーに送信される必要があり、パケットはローカルネットポートを介して統合ブリッジに入ります。

上記の段落で説明したパケット分散処理を可能にするには、分散ゲートウェイポートは、特定のシャーシにバインドされたl3ゲートウェイポートではなく、各ハイパーバイザーに効果的に存在する論理パッチポートである必要があります。ただし、分散ゲートウェイポートに関連付けられているトラフィックは、通常、次の理由から物理的な場所に関連付ける必要があります。

ローカルネットポートが接続されている物理ネットワークは、通常、L2を使用して学習します。分散ゲートウェイポートを介して使用されるイーサネットアドレスは、アップストリームL2学習が混乱しないように、物理的な場所に制限する必要があります。分散ゲートウェイポートから特定のイーサネットアドレスを持つローカルネットポートへのトラフィックは、特定のシャーシ上の分散ゲートウェイポートの特定のインスタンスを送信する必要があります。特定のイーサネットアドレスを持つローカルネットポート（またはローカルネットポートと同じ論理スイッチからのVIF）へのトラフィックは、その特定のシャーシ上の論理スイッチのシャーシポートインスタンスに転送する必要があります。

L2学習の意味により、分散ゲートウェイポートのイーサネットアドレスとIPアドレスは1つの物理的な場所に制限する必要があります。これを行うには、ユーザーは分散ゲートウェイポートに関連付けられたシャーシを指定する必要があります。分散ゲートウェイポートを介して他のイーサネットアドレスとIPアドレス（たとえば、1対1のNAT）を使用するトラフィックは、このシャーシに限定されないことに注意してください。

ARPおよびND要求への応答は、イーサネットアドレスが応答される単一の物理的な場所に制限する必要があります。これには、分散ゲートウェイポートのIPアドレスに対するARPおよびND応答が含まれます。これらは、分散ゲートウェイポートに関連付けられているユーザーのシャーシに限定されます。

複数のシャーシに分散された複数の論理IPアドレスが単一の外部IPアドレスにマップされる1対多のSNAT（別名IPマスカレード）をサポートするには、特定のシャーシ上の特定の論理ルーターを一元的に処理する必要があります。 SNAT外部IPアドレスは通常分散ゲートウェイポートのIPアドレスであるため、簡単にするために、分散ゲートウェイポートに関連付けられているのと同じシャーシが使用されます。

特定のシャーシのトラフィック制限に関する詳細情報は、ovn-northdのドキュメントに記載されています。

分散ゲートウェイポートの物理的な場所に関連する側面のほとんどは、特定のトラフィックを特定のシャーシに制限することで処理できますが、追加のメカニズムが必要です。パケットが入力パイプを出て、論理出力ポートが分散ゲートウェイポートである場合、表32の2つの異なるアクションセットのいずれかが必要です。

パケットを送信者のハイパーバイザーでローカルに処理できる場合（たとえば、1対1のNATトラフィック）、分散論理パッチポートに対して通常の方法でパケットを表33に再送信する必要があります。
ただし、分散ゲートウェイポートに関連付けられたシャーシでパケットを処理する必要がある場合（たとえば、1対多のSNATトラフィックまたは非NATトラフィック）、テーブル32のトンネルポートにパケットが送信される必要があります。シャーシ。
2番目のアクションのセットをトリガーするために、chassisredirectタイプのサウスバウンドデータベースのPort_Bindingテーブルが追加されました。論理出力ポートをタイプchassisredirectの論理ポートに設定することは、一方向にすぎません。これは、パケットが分散ゲートウェイポートを指しているにもかかわらず、別のシャーシにリダイレクトする必要があることを示しています。表32では、論理出力ポートを備えたパケットが特定のシャーシに送信されます。これは、表32が論理出力ポートVIFまたはタイプ13ゲートウェイポートを備えたパケットを別のシャーシにポイントするのと同じ方法です。パケットがシャーシに到着すると、表33は、論理出力ポートを分散ゲートウェイポートを表す値にリセットします。分散ゲートウェイポートごとに、分散ゲートウェイポートを表す分散論理パッチポートに加えて、chassisredirectタイプのポートもあります。

分散ゲートウェイポートの高可用性
OVNを使用すると、分散ゲートウェイポートのシャーシの優先順位リストを指定できます。これは、複数のGateway_Chassis回線をOVN_NorthboundデータベースのLogical_Router_Portに関連付けることによって行われます。

ゲートウェイに複数のシャーシが指定されている場合、ゲートウェイにパケットを送信する可能性のあるすべてのシャーシは、構成されているすべてのゲートウェイシャーシのチャネルでBFDを有効にします。現在のゲートウェイのメインシャーシは、優先度が最も高いゲートウェイです。現在のシャーシは、BFDステータスに基づいて判断されます。

L3ゲートウェイの高可用性の詳細については、を参照してください。
http://docs.openvswitch.org/en/latest/topics/high-availability

VTEPゲートウェイのライフサイクル
ゲートウェイは、実際には、論理ネットワークのOVN管理部分と物理VLANの間でトラフィックを転送し、トンネルベースの論理ネットワークを物理ネットワークに拡張するためのシャーシです。

次の手順には、通常、OVNおよびVTEPデータベーススキーマの詳細が含まれます。これらのデータベースの全文については、ovn-sb、ovn-nb、およびvtepを参照してください。

VTEPゲートウェイのライフサイクルは、管理者がVTEPデータベースのPhysical_SwitchエントリとしてVTEPゲートウェイを登録することから始まります。このVTEPデータベースに接続されたovn-controller-vtepは、新しいVTEPゲートウェイを識別し、OVN_Southboundデータベースにそのゲートウェイ用の新しいChassisテーブルエントリを作成します。

管理者は、新しいLogical_Switchエントリを作成し、VTEPゲートウェイポート上の特定のVLANを任意のVTEP論理スイッチにバインドできます。 VTEP論理スイッチがVTEPゲートウェイにバインドされると、ovn-controller-vtepはそれを検出し、その名前をOVN_Southboundデータベースのシャーシテーブルのvtep_logical_switches列に追加します。 VTEP論理スイッチのtunnel_key列は、作成時に入力されていないことに注意してください。対応するvtep論理スイッチがOVN論理ネットワークにバインドされると、ovn-controller-vtepが列を設定します。

管理者は、CMSを使用してVTEP論理スイッチをOVN論理ネットワークに追加できるようになりました。これを行うには、CMSは最初にOVN_Northboundデータベースに新しいLogical_Switch_Portエントリを作成する必要があります。次に、このエントリのタイプ列を「vtep」に設定する必要があります。次に、複数のVTEPゲートウェイが同じVTEP論理スイッチに接続できるため、オプション列でvtep-logical-switchキーとvtep-physical-switchキーも指定する必要があります。

OVN_Northboundデータベースに新しく作成された論理ポートとその構成は、新しいPort_BindingテーブルエントリとしてOVN_Southboundデータベースに渡されます。 Ovn-controller-vtepは変更を認識し、論理ポートを対応するVTEPゲートウェイシャーシにバインドします。同じVTEP論理スイッチを異なるOVN論理ネットワークにバインドすることは禁止されており、ログに警告が生成されます。

ovn-controller-vtepは、VTEPゲートウェイシャーシへのバインドに加えて、VTEP論理スイッチのtunnel_key列を、OVN論理ネットワークにバインドされた対応するDatapath_Bindingエントリのtunnel_keyに更新します。

次に、ovn-controller-vtepは、OVN_NorthboundデータベースのPort_Bindingの構成変更に反応し、VTEPデータベースのUcast_Macs_Remoteテーブルを更新します。これにより、VTEPゲートウェイは、拡張された外部ネットワークからユニキャストトラフィックを転送する場所を知ることができます。

最後に、管理者がVTEPデータベースからVTEPゲートウェイの登録を解除すると、VTEPゲートウェイのライフサイクルが終了します。 Ovn-controller-vtepはイベントを認識し、OVN_Southboundデータベース内の関連するすべての構成（シャーシテーブルエントリとポートバインディング）を削除します。

ovn-controller-vtepが終了すると、OVN_SouthboundデータベースとVTEPデータベースの関連するすべての構成がクリアされます。これには、登録されているすべてのVTEPゲートウェイとそのポートにバインドされたChassisテーブルエントリ、すべてのUcast_Macs_RemoteエントリとLogical_Switchトンネルキーが含まれます。

安全性
サウスバウンドデータベースの役割ベースのアクセス制御
OVNchassisが攻撃されるのを防ぐための追加のセキュリティを提供し、それによって不正なソフトウェアがサウスバウンドデータベースの状態を任意に変更するのを防ぎ、それによってOVNネットワークを中断し、それによってサウスバウンドデータベースの役割ベースの役割を持つようにします。アクセス制御戦略（詳細については、ovsdb-serverセクションを参照してください）。

ロールベースのアクセス制御（RBAC）の実装では、OVSDBモードで2つのテーブルを追加する必要があります。RBAC_Roleテーブルは、ロール名でインデックスが付けられ、特定のロールに対して変更できる個々のテーブルの名前をアクセス許可にマップします。テーブル。ロールの詳細な権限情報を含む単一の行。それ自体は、次の情報を含む行で構成されます。

テーブル名

関連するテーブルの名前。この列は主に、人々がこの表の内容を読むのを助けるために使用されます。
1
認証基準

列名を含む文字列のセット。少なくとも1つの列または列の内容：変更、挿入、または削除される行のキー値は、許可検査に合格するために、その行を操作しようとしているクライアントのIDと同じである必要があります。承認基準が空の場合、承認チェックは無効になり、ロールのすべてのクライアントが承認されたと見なされます。
1
挿入/削除

関連するテーブルが行の挿入と削除を許可するかどうかを示す行の挿入/削除権限（ブール値）。 trueの場合、許可クライアントは行の挿入と削除を許可します。
1
更新可能な列

許可されたクライアントによって更新または変更される可能性のある列名または列名を含むキーペアのセット。行の列の変更は、顧客の承認チェックに合格し、変更するすべての列が変更可能な列のセットに含まれている場合にのみ許可されます。
1
OVNサウスバウンドデータベースのRBAC構成は、ovn-northdによって維持されます。 RBACが有効になっている場合、次のように、Chassis、Encap、Port_Binding、およびMAC_Bindingテーブルのみを変更および再割り当てできます。

シャーシ

許可：クライアントIDはシャーシ名と一致する必要があります。
挿入/削除：許可された行の挿入と削除を許可します。
更新：列nb_cfg、external_ids、encaps、およびvtep_logical_switchesは、許可中に変更できます。
カプセル化の承認

承認：無効（すべてのクライアントが承認されていると見なされます）。将来的には、このテーブルに「シャーシ名の作成」列を追加し、それを許可チェックに使用します。
挿入/削除：許可された行の挿入と削除を許可します。
更新：列タイプ、オプション、およびIPを変更できます。
Port_Binding

承認：無効（すべてのクライアントが承認されていると見なされます）。将来の機能拡張では、列（またはキーワードexternal_ids）を追加して、各ポートへのバインドを許可するシャーシを制御する可能性があります。
挿入/削除：行の挿入/削除は許可されていません（ovn-northdはこのテーブルの行を維持します）
更新：変更できるのはシャーシ列のみです。
MAC_Binding

承認：無効（すべての顧客は承認されたと見なされます
挿入/削除：行の挿入/削除を許可します。
更新：logical_port、ip、ma​​c、およびdatapath列は、ovn-controllerによって変更できます。
サウスバウンドデータベースへのovn-controller接続に対してRBACを有効にするには、次の手順が必要です。

証明書CNフィールドをシャーシ名に設定して、シャーシごとにSSL証明書を作成します（たとえば、external-ids：system-id = schema-1のシャーシの場合、コマンド 'ovs-pki -B 1024 -u req +を渡します。サインシャーシ '-1スイッチ'）。

サウスバウンドデータベースに接続するときにSSLを使用するように各ovn-controllerを構成します。 （たとえば、 'ovs-vsctl set open .external-ids：ovn-remote = ssl：x.x.x.x：6642'を介して）。

'ovn-controller'ロールを使用して、サウスバウンドデータベースSSLリモートを構成します。 （例： 'ovn-sbctl set-connection role = ovn-controller pssl：6642'）。

設計上の決定
トンネルカプセル化
OVNは、あるハイパーバイザーから別のハイパーバイザーに送信する論理ネットワークパケットにラベルを付けます。これには、特定の方法でエンコードされた次の3つのメタデータが含まれます。

OVNサウスバウンドデータベースDatapath_Bindingテーブルのトンネルキー列からの24ビット論理データパス識別子。
15ビットの論理入力ポート識別子。 ID 0は、OVN内での内部使用のために予約されています。 ID 1〜32767（エンドポイントを含む）を論理ポートに割り当てることができます（OVNサウスバウンドPort_Bindingテーブルのtunnel_key列を参照）。
16ビットの論理出口ポートID。 ID 0〜32767は、論理入力ポートと同じ意味を持ちます。 32768〜65535を含むIDを論理マルチキャストグループに割り当てることができます（OVNサウスバウンドマルチキャストグループテーブルのtunnel_key列を参照）。
ハイパーバイザーへのハイパーバイザートラフィックの場合、OVNは次の理由でGeneveおよびSTTカプセル化のみをサポートします。

STTとGeneveのみが、OVNで使用される大量のメタデータをサポートします（各パケットは32ビットを超えます）（上記のとおり）。
STTとGeneveは、ランダム化されたUDPまたはTCP送信元ポートを使用して、基盤となるECMP環境内の複数のパス間で効率的に分散できるようにします。
NICは、STTとGeneveのカプセル化とカプセル化解除をサポートします。
柔軟性があるため、ハイパーバイザー間で推奨されるパッケージはGeneveです。 Geneveカプセル化の場合、OVNはGeneveVNIで論理データパス識別子を送信します。 OVNは、次のように、タイプ0x0102、タイプ0x80のTLVの論理入力ポートと論理出力ポートをMSBからLSBに転送します。LSBは32ビットとしてエンコードされます。



GeneveをサポートしていないNICは、パフォーマンス上の理由からSTTカプセル化を好む場合があります。 STTカプセル化の場合、OVNは、MSBからLSBまで、STT64ビットトンネルID内の3つの論理メタデータすべてを次のようにエンコードします。


ゲートウェイに接続するために、GeneveとSTTに加えて、OVNはVXLANもサポートします。これは、VXLANのみがラックスイッチ（ToR）でサポートされているためです。現在、ゲートウェイにはVTEPモードで定義された機能と一致する機能セットがあるため、メタデータのビット数が必要です。将来的には、大量のメタデータのカプセル化をサポートしないゲートウェイは、機能セットを削減し続ける可能性があります。
元の： https://blog.csdn.net/ptmozhu/article/details/78644825?utm_source=blogxgwz3