OVN架構原理

ovn-architecture

本文最初整理在我的github上SDN-Learning-notes

本文翻譯自ovs官方手冊，有刪減

OVN架構

OVN（即Open Virtual Network）是一款支持虛擬網絡抽象的軟件系統。OVN在OVS現有功能的基礎上原生支持虛擬網絡抽象，例如虛擬L2，L3覆蓋網絡以及完全組。諸如DHCP，DNS的服務也是其關注的內容。就像OVS一樣，OVN的設計目標是可以大規模運行的高質量生產級實施方案。

OVN部署由以下幾個組件組成：

• CMS（雲管理系統）。這是OVN的最終用戶（通過其用戶和管理員）。與OVN集成需要安裝與CMS特定的插件和相關軟件（見下文）。OVN最初的目標CMS是OpenStack。我們通常會說一個CMS，但多個CMS也可以管理一個OVN的不同部分。

• 安裝在一箇中央位置的OVN數據庫，可以是物理節點，虛擬節點，甚至是一個集羣。

• 一個或多個（通常是很多）虛擬機管理程序（hypervisors）。hypervisors必須運行Open vSwitch並執行IntegrationGuide.rst在OVS源代碼樹中所述的接口。任何支持的OVS的hypervisor平臺都是可以接受的。

• 零個或多個網關。 網關通過在隧道和物理以太網端口之間雙向轉發數據包，將基於隧道的邏輯網絡擴展到物理網絡。這允許非虛擬機器參與邏輯網絡。網關可能是物理機，虛擬機或基於ASIC同時支持vtep模式的硬件交換機。

hypervisor和網關一起被稱爲傳輸節點或chassis

下圖顯示了OVN和相關的主要組件的軟件交互:

                                         CMS
                                          |
                                          |
                              +-----------|-----------+
                              |           |           |
                              |     OVN/CMS Plugin    |
                              |           |           |
                              |           |           |
                              |   OVN Northbound DB   |
                              |           |           |
                              |           |           |
                              |       ovn-northd      |
                              |           |           |
                              +-----------|-----------+
                                          |
                                          |
                                +-------------------+
                                | OVN Southbound DB |
                                +-------------------+
                                          |
                                          |
                       +------------------+------------------+
                       |                  |                  |
         HV 1          |                  |    HV n          |
       +---------------|---------------+  .  +---------------|---------------+
       |               |               |  .  |               |               |
       |        ovn-controller         |  .  |        ovn-controller         |
       |         |          |          |  .  |         |          |          |
       |         |          |          |     |         |          |          |
       |  ovs-vswitchd   ovsdb-server  |     |  ovs-vswitchd   ovsdb-server  |
       |                               |     |                               |
       +-------------------------------+     +-------------------------------+

從圖的頂部開始，依次爲：

1. 首先是如上文所述的雲管理系統。

2. OVN/CMS插件是連接到OVN的CMS組件。 在OpenStack中，這是一個Neutron插件。該插件的主要目的是轉換CMS中的邏輯網絡的配置爲OVN可以理解的中間表示。這個組件是必須是CMS特定的，所以對接一個新的CMS需要開發新的插件對接到OVN。所有在這個組件下面的其他組件是與CMS無關的。

3. OVN北向數據庫接收由OVN/CMS插件傳遞的邏輯網絡配置的中間表示。數據庫模式與CMS中使用的概念是“阻抗匹配的”，因此它直接支持邏輯交換機，路由器，ACL等概念。有關詳細信息，請參見ovn-nb。（OVN北向數據庫只有兩個客戶端：在它上面的OVN/CMS插件和在它下面的ovn-northd）

4. ovn-northd用於連接到它上面的OVN北行數據庫和它下面的OVN南行數據庫。它將傳統網絡概念（從OVN北行數據庫中取得）的邏輯網絡配置轉換爲其下面的OVN南行數據庫中的邏輯數據路徑流。

5. OVN南行數據庫是系統的中心。（OVN南向數據庫也只有兩個客戶端：它上面是ovn-northd以及在它下面的每個傳輸節點上的ovn-controller）。OVN南向數據庫包含三種類型的數據：指定如何到達hypervisor和其他節點的物理網絡（PN）表；用於描述邏輯網絡的邏輯數據路徑流的邏輯網絡（LN）表；用於將邏輯網絡組件的位置鏈接到物理網絡的綁定表。hypervisor填充PN和Port_Binding表，而ovn-northd填充LN表。

   爲了集羣的可用性，OVN南行數據庫性能必須隨傳輸節點的數量而擴展。這可能需要一些ovsdb-server上的工作。

其餘組件在每個hypervisor中都是一樣的

1. ovn-controller是每個hypervisor和軟件網關上的OVN代理。北向，它連接到OVN南行數據庫以瞭解OVN配置和狀態，並把hypervisor的狀態填充綁定表中的Chassis列以及PN表。南向，它連接到ovs-vswitchd作爲OpenFlow控制器用於控制網絡通信，並連接到本地ovsdb-server以允許它監視和控制Open vSwitch的配置。

2. ovs-vswitchd和ovsdb-server是標準的Open vSwitch組件。

OVN中的信息流

OVN中的配置數據從北向南流動。CMS通過其OVN/CMS插件，通過北向數據庫將邏輯網絡配置傳遞給ovn-northd。反過來，ovn-northd將配置信息編譯爲較低級別的表單，並通過南行數據庫將其傳遞到所有的chassis。

OVN中的狀態信息從南向北流動。OVN目前僅提供以下幾種形式的狀態信息：

• 首先，ovn-northd在北向Logical_Switch_Port表中填充up列：如果南向Port_Binding表中邏輯端口的chassis列非空，則設置爲true，否則設置爲false。這使CMS能夠檢測虛擬機的網絡連接何時可用。

• 其次，OVN向CMS提供關於其配置實現的反饋，即CMS提供的配置是否已經生效。 此功能要求CMS參與序列號協議，其工作方式如下：

  1. 當CMS更新北向數據庫中的配置時，作爲同一事務的一部分，它會增加NB_Global表中的nb_cfg列的值。（這隻有當CMS想知道何時配置已經實現時纔是必要的。）
  2. 當ovn-northd根據北向數據庫的給定快照更新南行數據庫時，作爲同一事務的一部分，它將北向NB_Global表中的nb_cfg列複製到南行數據庫SB_Global表中。（因此，監視兩個數據庫的觀察者可以確定南行數據庫何時與北向數據庫一致）
  3. 在ovn-northd從南向數據庫服務器收到其更改已提交的確認後，會將北向數據庫NB_Global表中的sb_cfg列更新爲被推下去的nb_cfg版本號。（因此，CMS或其他觀察者可以確定南行數據庫何時被捕獲而沒有連接到南行數據庫）
  4. 每個chassis上的ovn-controller進程會接收更新的南行數據庫，並更新nb_cfg。該過程依次更新chassis上的Open vSwitch實例中安裝的物理流。從Open vSwitch收到確認物理流已更新的確認後，它會在南行數據庫的自己的chassis記錄中更新nb_cfg。
  5. ovn-northd監視南向數據庫中所有chassis記錄中的nb_cfg列。它跟蹤所有記錄中的最小值，並將其複製到北行NB_Global表中的hv_cfg列中。（因此，CMS或其他觀察者可以確定所有的hypervisor何時與北向數據庫裏的配置一致）

Chassis啓動

OVN部署中的每個chassis必須配置專用於OVN使用的Open vSwitch網橋，稱爲集成網橋。如果需要，系統啓動腳本可以在啓動ovn-controller之前創建此網橋。如果ovn-controller啓動時這個網橋不存在，它會自動創建，使用下面建議的默認配置。 集成橋上的端口包括：

• 在任何chassis上，OVN用來維護邏輯網絡連接的隧道端口。ovn-controller負責添加，更新並刪除這些隧道端口。
• 在hypervisor上，將要連接到邏輯網絡的任何VIF。hypervisor本身或Open vSwitch與hypervisor（IntegrationGuide.rst中描述的）之間的集成將處理此問題。（這不是OVN的一部分，也不是OVN的新功能;這是在支持OVS的虛擬機管理程序上已經完成的預先集成工作）
• 在網關上，用於邏輯網絡連接的物理端口。系統啓動腳本在啓動ovn-controller之前將此端口添加到網橋。在更復雜的設置中，這可以是到另一個橋的patch端口，而不是物理端口。

其他端口不應連接到集成網橋。特別是，連接到底層網絡的物理端口（與把物理端口連接到邏輯網絡的的網關端口相反）不能連接到集成網橋。 底層物理端口應該連接到單獨的Open vSwitch網橋（實際上它們根本不需要連接到任何網橋）

集成橋應按照如下所述進行配置。每個這些設置的效果都記錄在文件OVS-vswitchd.conf.db中：

fail-mode=secure：在ovn-controller啓動之前，避免在隔離的邏輯網絡之間切換數據包。有關更多信息，請參閱ovs-vsctl中的Controller Failure Settings部分。

other-config:disable-in-band=true：抑制集成網橋的帶內控制流。由於OVN使用本地控制器（通過Unix域套接字）而不是遠程控制器，所以這樣的控制流顯然是不常見的。然而，對於同一系統中的某個其他橋可能有一個帶內遠程控制器，在這種情況下，這可能會抑制帶內控制器通常建立的流量。請參閱有關文檔以獲取更多信息。

集成網橋的習慣命名是br-int，但是其他名字也可能被使用的。

邏輯網絡

邏輯網絡實現與物理網絡相同的概念，但它們通過隧道或其他封裝與物理網絡隔離。這允許邏輯網絡具有單獨的IP和其他地址空間，這些地址空間與用於物理網絡的地址空間可以重疊並且沒有衝突。邏輯網絡拓撲結構可以不考慮底層物理網絡的拓撲結構。

OVN中的邏輯網絡概念包括：
* 邏輯交換機，以太網交換機的邏輯版本。
* 邏輯路由器，IP路由器的邏輯版本。邏輯交換機和路由器可以連接成複雜的拓撲結構。
* 邏輯數據路徑，OpenFlow交換機的邏輯版本。 邏輯交換機和路由器都是作爲邏輯數據路徑實現的。
* 邏輯端口，邏輯交換機和邏輯路由器內外的連接點。 一些常見的邏輯端口類型是：

  * 表示VIF的邏輯端口
  * Localnet端口，代表邏輯交換機和物理網絡之間的連接點。在集成網橋與底層物理端口附加到的獨立Open vSwitch網橋之間的OVS patch端口即是Localnet端口。
  * 邏輯patch端口，表示邏輯交換機和邏輯路由器之間的連接點，在某些情況下，則是對等邏輯路由器之間的連接點。每個連接點都有一對邏輯連接端口，每端連接一個端口。
  * Localport端口，代表邏輯交換機和VIF之間的本地連接點。這些端口存在於每個chassis（不限於任何特定的chassis），並且來自它們的流量將永遠不會穿過隧道。Localport端口僅生成目的地爲本地目的地的流量，通常響應於其收到的請求。一個用例是OpenStack Neutron如何使用Localport端口將元數據提供給駐留在每個hypervisor上的虛擬機。元數據代理進程連接到每個主機上的此端口，並且同一網絡中的所有虛擬機將使用相同的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的生命週期

數據庫表和他們的模式是孤立的，很難理解。這是一個例子。

hypervisor上的VIF是連接到在該hypervisor上直接運行的虛擬機或容器的虛擬網絡接口（這與運行在虛擬機內的容器的接口不同）

本示例中的步驟通常涉及OVN和OVN北向數據庫模式的詳細信息。請分別參閱ovn-sb和ovn-nb部分了解這些數據庫的完整內容。

1. 當CMS管理員使用CMS用戶界面或API創建新的VIF並將其添加到交換機（由OVN作爲邏輯交換機實現的交換機）時，VIF的生命週期開始。CMS更新其自己的配置，主要包括將VIF唯一的持久標識符vif-id和以太網地址mac相關聯。
2. CMS插件通過向Logical_Switch_Port表添加一行來更新OVN北向數據庫以包括新的VIF信息。在新行中，名稱是vif-id，mac是mac，交換機指向OVN邏輯交換機的Logical_Switch記錄，而其他列被適當地初始化。
3. ovn-northd收到OVN北向數據庫的更新。然後通過添加新行到OVN南向數據庫Logical_Flow表中反映新的端口來對OVN南向數據庫進行相應的更新，例如，添加一個流來識別發往新端口的MAC地址的數據包應該傳遞給它，並且更新傳遞廣播和多播數據包的流以包括新的端口。它還在“綁定”表中創建一個記錄，並填充除識別chassis列之外的所有列。
4. 在每個hypervisor上，ovn-controller接收上一步ovn-northd在Logical_Flow表所做的更新。但只要擁有VIF的虛擬機關機，ovn-controller也無能爲力。例如，它不能發送數據包或從VIF接收數據包，因爲VIF實際上並不存在於任何地方。
5. 最終，用戶啓動擁有該VIF的VM。在VM啓動的hypervisor上，hypervisor與Open vSwitch（IntegrationGuide.rst中所描述的）之間的集成是通過將VIF添加到OVN集成網橋上，並在external_ids：iface-id中存儲vif-id，以指示該接口是新VIF的實例。（這些代碼在OVN中都不是新功能;這是已經在支持OVS的虛擬機管理程序上已經完成的預先集成工作。）
6. 在啓動VM的hypervisor上，ovn-controller在新的接口中注意到external_ids：iface-id。作爲響應，在OVN南向數據庫中，它將更新綁定表的chassis列中鏈接邏輯端口從external_ids：iface-id到hypervisor的行。之後，ovn-controller更新本地虛擬機hypervisor的OpenFlow表，以便正確處理去往和來自VIF的數據包。
7. 一些CMS系統，包括OpenStack，只有在網絡準備就緒的情況下才能完全啓動虛擬機。爲了支持這個功能，ovn-northd發現Binding表中的chassis列的某行更新了，則通過更新OVN北向數據庫的Logical_Switch_Port表中的up列來向上指示這個變化，以指示VIF現在已經啓動。如果使用此功能，CMS則可以通過允許VM執行繼續進行後續的反應。
8. 在VIF所在的每個hypervisor上，ovn-controller注意到綁定表中完全填充的行。這爲ovn-controller提供了邏輯端口的物理位置，因此每個實例都會更新其交換機的OpenFlow流表（基於OVN數據庫Logical_Flow表中的邏輯數據路徑流），以便通過隧道正確處理去往和來自VIF的數據包。
9. 最終，用戶關閉擁有該VIF的VM。在VM關閉的hypervisor中，VIF將從OVN集成網橋中刪除。
10. 在VM關閉的hypervisor上，ovn-controller注意到VIF已被刪除。作爲響應，它將刪除邏輯端口綁定表中的Chassis列的內容。
11. 在每個hypervisor中，ovn-controller都會注意到綁定錶行中空的Chassis列。這意味着ovn-controller不再知道邏輯端口的物理位置，因此每個實例都會更新其OpenFlow表以反映這一點。
12. 最終，當VIF（或其整個VM）不再被任何人需要時，管理員使用CMS用戶界面或API刪除VIF。CMS更新其自己的配置。
13. CMS插件通過刪除Logical_Switch_Port表中的相關行來從OVN北向數據庫中刪除VIF。
14. ovn-northd收到OVN北向數據庫的更新，然後相應地更新OVN南向數據庫，方法是從OVN南向d數據庫Logical_Flow表和綁定表中刪除或更新與已銷燬的VIF相關的行。
15. 在每個hypervisor上，ovn-controller接收在上一步中的Logical_Flow表更新並更新OpenFlow表。儘管可能沒有太多要做，因爲VIF已經變得無法訪問，它在上一步中從綁定表中刪除。

VM內部容器接口的生命週期

OVN通過將寫在OVN_NB數據庫中的信息轉換成每個hypervisor中的OpenFlow流表來提供虛擬網絡抽象。如果OVN控制器是唯一可以修改Open vSwitch中的流的實體，則只能爲多租戶提供安全的虛擬網絡連接。當Open vSwitch集成網橋駐留在虛擬機管理程序中時，虛擬機內運行的租戶工作負載無法對Open vSwitch流進行任何更改的。

如果基礎架構提供程序信任容器內的應用程序不會中斷和修改Open vSwitch流，則可以在hypervisors中運行容器。當容器在虛擬機中運行時也是如此，此時需要有一個駐留在同一個VM中由OVN控制器控制的Open vSwitch集成網橋。對於上述兩種情況，工作流程與上一節（“VIF的生命週期”）中的示例所解釋的相同。

本節討論在虛擬機中創建容器並將Open vSwitch集成網橋駐留在虛擬機管理程序中時，容器接口（CIF）的生命週期。在這種情況下，即使容器應用程序發生故障，其他租戶也不會受到影響，因爲運行在VM內的容器無法修改Open vSwitch集成橋中的流。

在虛擬機內創建多個容器時，會有多個CIF關聯。爲了便於OVN支持虛擬網絡抽象，與這些CIF關聯的網絡流量需要到達hypervisor中運行的Open vSwitch集成網橋。OVN還應該能夠區分來自不同CIF的網絡流量。有兩種方法可以區分CIF的網絡流量：

• 第一種方法是爲每個CIF提供一個VIF（1:1）。這意味着hypervisor中可能有很多網絡設備。由於管理所有VIF額外的CPU消耗，這會使OVS變慢。 這也意味着在VM中創建容器的實體也應該能夠在hypervisor中創建相應的VIF。

• 第二種方法是爲所有CIF提供一個VIF（1:n）。然後，OVN可以通過每個數據包中寫入的標籤來區分來自不同CIF的網絡流量。OVN使用這種機制並使用VLAN作爲標記機制。

  1. CIF的生命週期始於在虛擬機內部創建容器開始，該容器可以是由創建虛擬機同一CMS創建或擁有該虛擬機的租戶創建，甚至可以是與最初創建虛擬機的CMS不同的容器編制系統所創建。無論創建容器的實體是誰，它需要知道需要知道與虛擬機的網絡接口關聯的vif-id，容器接口的網絡流量將通過該網絡接口經過。創建容器接口的實體也需要在該虛擬機內部選擇一個未使用的VLAN。
  2. 創建容器的實體（直接或間接通過管理底層基礎結構的CMS）通過向Logical_Switch_Port表添加一行來更新OVN南向數據庫以包含新的CIF。在新行中，name是任何唯一的標識符，parent_name是CIF網絡流量預計要經過的VM的vif-id，tag是標識該CIF網絡流量的VLAN標記。
  3. ovn-northd收到OVN北向數據庫的更新。反過來，它通過添加相應行到OVN南向數據庫的Logical_Flow表來反映新的端口，並通過在Binding表中創建一個新行並填充除了標識列以外的所有列，來相應地更新OVN南向數據庫的chassis。
  4. 在每個hypervisor上，ovn-controller訂閱綁定表中的更改。當由ovn-northd創建的新行中包含Binding表的parent_port列中的值時，擁有與external_ids：iface-id中的vif-id相同值的ovn集成網橋上的ovn-controller更新本地hypervisor的OpenFlow流表，這樣來自具有特定VLAN標記的VIF的數據包得到正確的處理。之後，它會更新綁定表的chassis列以反映物理位置。
  5. 底層網絡準備就緒後，只能在容器內啓動應用程序。爲了支持這個功能，ovn-northd在綁定表中通知更新的chassis列，並更新OVN Northbound數據庫的Logical_Switch_Port表中的up列，以表示CIF現在已經啓動。負責啓動容器應用程序的實體查詢此值並啓動應用程序。
  6. 最後，創建並啓動容器的實體如果要停止它。實體則通過CMS（或直接）刪除Logical_Switch_Port表中的行。
  7. ovn-northd接收OVN Northbound更新，並相應地更新OVN Southbound數據庫，方法是從OVN Southbound數據庫Logical_Flow表中刪除或更新與已經銷燬的CIF相關的行。同時也會刪除該CIF的綁定表中的行。
  8. 在每個hypervisor中，ovn-controller接收在上一步中Logical_Flow表的更新.ovn-controller更新本地OpenFlow表以反映更新。

數據包的物理處理生命週期

本節介紹數據包如何通過OVN從一個虛擬機或容器傳輸到另一個虛擬機或容器。這個描述着重於一個數據包的物理處理。有關數據包邏輯生命週期的描述，請參考ovn-sb中的Logical_Flow表。

爲了清楚起見，本節提到了一些數據和元數據字段，總結如下：

1. 隧道密鑰。當OVN在Geneve或其他隧道中封裝數據包時，會附加額外的數據，以使接收的OVN實例正確處理。這取決於特定的封裝形式，採取不同的形式，但在每種情況下，我們都將其稱爲“隧道密鑰”。請參閱文末的“隧道封裝”以瞭解詳細信息。
2. 邏輯數據路徑字段。表示數據包正在被處理的邏輯數據路徑的字段。OVN使用OpenFlow 1.1+簡單地（並且容易混淆）調用“元數據”來存儲邏輯數據路徑字段。 （該字段作爲隧道密鑰的一部分通過隧道進行傳遞。）
3. 邏輯輸入端口字段。表示數據包從哪個邏輯端口進入邏輯數據路徑的字段。OVN將其存儲在Open vSwitch擴展寄存器14中。Geneve和STT隧道將這個字段作爲隧道密鑰的一部分傳遞。雖然VXLAN隧道沒有明確的攜帶邏輯輸入端口，OVN只使用VXLAN與網關進行通信，從OVN的角度來看，只有一個邏輯端口，因此OVN可以在輸入到OVN時將邏輯輸入端口字段設置爲該邏輯輸入的邏輯管道。
4. 邏輯輸出端口字段。表示數據包將離開邏輯數據路徑的邏輯端口的字段。在邏輯入口管道的開始，它被初始化爲0。 OVN將其存儲在Open vSwitch擴展寄存器15中。Geneve和STT隧道將這個字段作爲隧道密鑰的一部分傳遞。VXLAN隧道不傳輸邏輯輸出端口字段，由於VXLAN隧道不在隧道密鑰中攜帶邏輯輸出端口字段，所以當OVN管理程序從VXLAN隧道接收到數據包時，將數據包重新提交給流表8以確定輸出端口。當數據包到達流表32時，通過檢查當數據包從VXLAN隧道到達時設置的MLF_RCV_FROM_VXLAN標誌，將這些數據包重新提交到表33以供本地傳送。
5. 邏輯端口的conntrack區域字段。表示邏輯端口的連接跟蹤區域的字段。值只在本地有意義，跨chassis之間是沒有意義的。在邏輯入口管道的開始，它被初始化爲0。OVN將其存儲在Open vSwitch擴展寄存器13中。
6. 路由器的conntrack區域字段。表示路由器的連接跟蹤區域的字段。值只在本地有意義，跨chassis之間是沒有意義的。OVN在Open vSwitch擴展寄存器11中存儲DNATting的區域信息，在Open vSwitch擴展寄存器12中存儲SNATing的區域信息。
7. 邏輯流標誌。邏輯標誌旨在處理保持流表之間的上下文以便確定後續表中的哪些規則匹配。值只在本地有意義，跨chassis之間是沒有意義的。OVN將邏輯標誌存儲在Open vSwitch擴展寄存器10中。
8. VLAN ID。VLAN ID用作OVN和嵌套在VM內的容器之間的接口（有關更多信息，請參閱上面VM內容器接口的生命週期）。

首先，hypervisor上的VM或容器通過連接到OVN集成網橋的端口上發送數據包。詳細的生命週期如下：

1. OpenFlow流表0執行物理到邏輯的轉換。它匹配數據包的入口端口。其操作通過設置邏輯數據路徑字段以標識數據包正在穿越的邏輯數據路徑 以 及設置邏輯輸入端口字段來標識入口端口，從而實現用邏輯元數據標註數據包。然後重新提交到表8進入邏輯入口管道。

   如果源自嵌套在虛擬機內的容器的數據包有稍微不同的方式處理。可以根據VIF特定的VLAN ID來區分始發容器，因此物理到邏輯轉換流程在VLAN ID字段上還需要匹配，並且動作將VLAN標頭剝離。在這一步之後，OVN像處理其他數據包一樣處理來自容器的數據包。

   流表0還處理從其他chassis到達的數據包。它通過入口端口（這是一個隧道）將它們與其他數據包區分開來。與剛剛進入OVN流水線的數據包一樣，這些操作使用邏輯數據路徑和邏輯入口端口元數據來註釋這些數據包。另外，動作設置了邏輯輸出端口字段，這是可用的，因爲在進行ovn隧道封裝前，邏輯輸出端口是已知的。這三個信息是從隧道封裝元數據中獲取的（請參閱隧道封裝瞭解編碼細節）。然後操作重新提交到表33進入邏輯出口管道。

2. OpenFlow流表8至31執行OVN Southbound數據庫中的Logical_Flow表的邏輯入口管道。這些流表完全用於邏輯端口和邏輯數據路徑等邏輯概念的表示。ovn-controller的一大部分工作就是把它們轉換成等效的OpenFlow（尤其翻譯數據庫表：把Logical_Flow表0到表23翻譯爲成爲OpenFlow流表8到31）。

   每個邏輯流都映射到一個或多個OpenFlow流。一個實際的數據包通常只匹配其中一個，儘管在某些情況下它可以匹配多個這樣的數據流（這不是一個問題，因爲它們都有相同的動作）。 ovn-controller使用邏輯流的UUID的前32位作爲OpenFlow流的cookie。（這不一定是唯一的，因爲邏輯流的UUID的前32位不一定是唯一的。）

   一些邏輯流程可以映射到Open vSwitch“連接匹配”擴展（參見ovs-field部分文檔）。流連接操作使用的OpenFlow cookie爲0，因爲它們可以對應多個邏輯流。一個OpenFlow流連接匹配包含conj_id上的匹配。

   如果某個邏輯流無法在該hypervisor上使用，則某些邏輯流可能無法在給定的hypervisor中的OpenFlow流表中表示。例如，如果邏輯交換機中沒有VIF駐留在給定的hypervisor上，並且該hypervisor上的其他邏輯交換機不可訪問（例如，從hypervisor上的VIF開始的邏輯交換機和路由器的一系列跳躍），則邏輯流可能不能在那裏所表示。

   大多數OVN操作在OpenFlow中具有相當明顯的實現（具有OVS擴展），例如，next實現爲resubmit，field =常量; 至於set_field，下面有一些更詳細地描述：

   output

   通過將數據包重新提交給表32來實現。如果流水線執行多於一個的輸出動作，則將每個單獨地重新提交給表32.這可以用於將數據包的多個副本發送到多個端口。（如果數據包在輸出操作之間未被修改，並且某些拷貝被指定給相同的hypervisor，那麼使用邏輯多播輸出端口將節省hypervisor之間的帶寬。）

   get_arp(P, A)

   get_nd(P, A)

   通過將參數存儲在OpenFlow字段中來實現，然後重新提交到表66，ovn-controller使用OVN南向數據庫中的MAC_Binding表生成的此66流表。如果表66中存在匹配，則其動作將綁定的MAC存儲在以太網目的地地址字段中。

   OpenFlow操作保存並恢復用於上述參數的OpenFlow字段，OVN操作不必知道這個臨時用途。

   put_arp(P, A, E)

   put_nd(P, A, E)

   通過將參數存儲在OpenFlow字段中實現，通過ovn-controller來更新MAC_Binding表。

   OpenFlow操作保存並恢復用於上述參數的OpenFlow字段，OVN操作不必知道這個臨時用途。

3. OpenFlow流表32至47在邏輯入口管道中執行輸出動作。具體來說就是表32處理到遠程hypervisors的數據包，表33處理到hypervisors的數據包，表34檢查其邏輯入口和出口端口相同的數據包是否應該被丟棄。

   邏輯patch端口是一個特殊情況。邏輯patch端口沒有物理位置，並且有效地駐留在每個hypervisor上。因此，用於輸出到本地hypervisor上的端口的流表33也自然地將輸出實現到單播邏輯patch端口。但是，將相同的邏輯應用到作爲邏輯多播組一部分的邏輯patch端口會產生數據包重複，因爲在多播組中包含邏輯端口的每個hypervisor也會將數據包輸出到邏輯patch端口。因此，多播組執行表32中的邏輯patch端口的輸出。

   表32中的每個流匹配邏輯輸出端口上的單播或多播邏輯端口，其中包括遠程hypervisor上的邏輯端口。每個流的操作實現就是發送一個數據包到它匹配的端口。對於遠程hypervisor中的單播邏輯輸出端口，操作會將隧道密鑰設置爲正確的值，然後將隧道端口上的數據包發送到正確的遠端hypervisor。（當遠端hypervisor收到數據包時，表0會將其識別爲隧道數據包，並將其傳遞到表33中。）對於多播邏輯輸出端口，操作會將數據包的一個副本發送到每個遠程hypervisor，就像單播目的地一樣。如果多播組包括本地hypervisor上的一個或多個邏輯端口，則其動作也重新提交給表33. 表32還包括：

   • 根據標誌MLF_RCV_FROM_VXLAN匹配從VXLAN隧道接收到的數據包的高優先級的規則，然後將這些數據包重新提交給表33進行本地傳遞。 從VXLAN隧道收到的數據包由於缺少隧道密鑰中的邏輯輸出端口字段而到達此處，因此需要將這些數據包提交到表8以確定輸出端口。
   • 根據邏輯輸入端口匹配從localport類型的端口接收到的數據包並將這些數據包重新提交到表33以進行本地傳送的較高優先級規則。每個 hypervisor都存在localport類型的端口，根據定義，它們的流量不應該通過隧道出去。
   • 如果沒有其他匹配，則重新提交到流表33的備用流。

   對於駐留在本地而不是遠程的邏輯端口，表33中的流表類似於表32中的流表。對於本地hypervisor中的單播邏輯輸出端口，操作只是重新提交給表34.對於在本地hypervisor中包括一個或多個邏輯端口的多播輸出端口，對於每個這樣的邏輯端口P，操作將邏輯輸出端口改變爲P ，然後重新提交到表34。

   一個特殊情況是，當數據路徑上存在localnet端口時，通過切換到localnet端口來連接遠程端口。在這種情況下，不是在表32中增加一個到達遠程端口的流，而是在表33中增加一個流以將邏輯輸出端口切換到localnet端口，並重新提交到表33，好像它被單播到本地hypervisor的邏輯端口上。

   表34匹配並丟棄邏輯輸入和輸出端口相同並且MLF_ALLOW_LOOPBACK標誌未被設置的數據包。它重新提交其他數據包到表40。

4. OpenFlow表40至63執行OVN Southbound數據庫中的Logical_Flow表的邏輯出口流程。出口管道可以在分組交付之前執行驗證的最後階段。 最終，它可以執行一個輸出動作，ovn-controller通過重新提交到表64來實現。流水線從不執行輸出的數據包被有效地丟棄（雖然它可能已經通過穿過物理網絡的隧道傳送）。

   出口管道不能改變邏輯輸出端口或進行進一步的隧道封裝。

5. 當設置MLF_ALLOW_LOOPBACK時，表64繞過OpenFlow環回。邏輯環回在表34中被處理，但是OpenFlow默認也防止環回到OpenFlow入口端口。因此，當MLF_ALLOW_LOOPBACK被設置時，OpenFlow表64保存OpenFlow入口端口，將其設置爲0，重新提交到表65以獲得邏輯到物理轉換，然後恢復OpenFlow入口端口，有效地禁用OpenFlow回送防止。當MLF_ALLOW_LOOPBACK未被設置時，表64流程僅僅重新提交到表65。

6. OpenFlow表65執行與表0相反的邏輯到物理翻譯。它匹配分組的邏輯輸出端口。 其操作將數據包輸出到代表該邏輯端口的OVN集成網橋端口。如果邏輯出口端口是一個與VM嵌套的容器，那麼在發送數據包之前，會加上具有適當VLAN ID的VLAN標頭再進行發送。

邏輯路由器和邏輯patch端口

通常，邏輯路由器和邏輯patch端口不具有物理位置，並且實際上駐留在hypervisor上。邏輯路由器和這些邏輯路由器後面的邏輯交換機之間的邏輯patch端口就是這種情況，VM（和VIF）連接到這些邏輯交換機。

考慮從一個虛擬機或容器發送到位於不同子網上的另一個VM或容器的數據包。數據包將按照前面“數據包的物理生命週期”部分所述，使用表示發送者所連接的邏輯交換機的邏輯數據路徑，遍歷表0至65。在表32中，數據包本地重新提交到hypervisor上的表33的回退流。在這種情況下，從表0到表65的所有處理都在數據包發送者所在的hypervisor上進行。

當數據包到達表65時，邏輯出口端口是邏輯patch端口。表65中的實現取決於OVS版本，雖然觀察到的行爲意圖是相同的：

• 在OVS版本2.6和更低版本中，表65輸出到代表邏輯patch端口的OVS的patch端口。在OVS patch端口的對等體中，分組重新進入OpenFlow流表，標識其邏輯數據路徑和邏輯輸入端口都是基於OVS patch端口的OpenFlow端口號。

• 在OVS 2.7及更高版本中，數據包被克隆並直接重新提交到入口管道中的第一個OpenFlow流表，將邏輯入口端口設置爲對等邏輯patch端口，並使用對等邏輯patch端口的邏輯數據路徑（其實是表示邏輯路由器）。

分組重新進入入口流水線以便再次遍歷表8至65，這次使用表示邏輯路由器的邏輯數據路徑。處理過程繼續，如前一部分“數據包的物理生命週期”部分所述。當數據包到達表65時，邏輯輸出端口將再次成爲邏輯patch端口。以與上述相同的方式，這個邏輯patch端口將使得數據包被重新提交給OpenFlow表8至65，這次使用目標VM或容器所連接的邏輯交換機的邏輯數據路徑。

該分組第三次也是最後一次遍歷表8至65。如果目標VM或容器駐留在遠程hypervisor中，則表32將在隧道端口上將該分組從發送者的hypervisor發送到遠程hypervisor。最後，表65將直接將數據包輸出到目標VM或容器。

以下部分描述了兩個例外，其中邏輯路由器或邏輯patch端口與物理位置相關聯的情況。

網關路由器

網關路由器是綁定到物理位置的邏輯路由器。這包括邏輯路由器的所有邏輯patch端口以及邏輯交換機上的所有對等邏輯patch端口。在OVN Southbound數據庫中，這些邏輯patch端口的Port_Binding條目使用l3gateway類型而不是patch類型，以便區分這些邏輯patch端口綁定到chassis。

當hypervisor在代表邏輯交換機的邏輯數據路徑上處理數據包時，並且邏輯出口端口是表示與網關路由器連接的l3網關端口時，該暑假包將匹配表32中流表，通過隧道端口將數據包發送給網關路由器所在的chassis。表32中的處理過程與VIF相同。

網關路由器通常用於分佈式邏輯路由器和物理網絡之間。分佈式邏輯路由器及其後面的邏輯交換機（虛擬機和容器附加到的邏輯交換機）實際上駐留在每個hypervisor中。分佈式路由器和網關路由器通過另一個邏輯交換機連接，有時也稱爲連接邏輯交換機。另一方面，網關路由器連接到另一個具有連接到物理網絡的localnet端口的邏輯交換機。

當使用網關路由器時，DNAT和SNAT規則與網關路由器相關聯，網關路由器提供可處理一對多SNAT（又名IP僞裝）的中央位置。

分佈式網關端口

分佈式網關端口是邏輯路由器patch端口，可以將分佈式邏輯路由器與具有本地網絡端口的邏輯交換機連接起來。

分佈式網關端口的主要設計目標是儘可能多地在VM或容器所在的hypervisor上本地處理流量。只要有可能，應該在該虛擬機或容器的hypervisor上完全處理從該虛擬機或容器到外部世界的數據包，最終遍歷該hypervisor上的所有localnet端口實例到物理網絡。只要有可能，從外部到虛擬機或容器的數據包就應該通過物理網絡直接導向虛擬機或容器的hypervisor，數據包將通過localnet端口進入集成網橋。

爲了允許上面段落中描述的分組分佈式處理，分佈式網關端口需要是有效地駐留在每個hypervisor上的邏輯patch端口，而不是綁定到特定chassis的l3個網關端口。但是，與分佈式網關端口相關的流量通常需要與物理位置相關聯，原因如下：

• localnet端口所連接的物理網絡通常使用L2學習。任何通過分佈式網關端口使用的以太網地址都必須限制在一個物理位置，這樣上游的L2學習就不會混淆了。從分佈式網關端口向具有特定以太網地址的localnet端口發出的流量必須在特定chassis上發送出分佈式網關端口的一個特定實例。具有特定以太網地址的localnet端口（或來自與localnet端口相同的邏輯交換機上的VIF）的流量必須定向到該特定chassis上的邏輯交換機的chassis端口實例。

  由於L2學習的含義，分佈式網關端口的以太網地址和IP地址需要限制在一個物理位置。爲此，用戶必須指定一個與分佈式網關端口關聯的chassis。請注意，使用其他以太網地址和IP地址（例如，一對一NAT）穿過分佈式網關端口的流量不限於此chassis。

  對ARP和ND請求的回覆必須限制在一個單一的物理位置，在這個位置上應答的以太網地址。這包括分佈式網關端口的IP地址的ARP和ND回覆，這些回覆僅限於與分佈式網關端口關聯的用戶的chassis。

• 爲了支持一對多SNAT（又名IP僞裝），其中跨多個chassis分佈的多個邏輯IP地址被映射到單個外部IP地址，將有必要以集中的方式處理特定chassis上的某些邏輯路由器。由於SNAT外部IP地址通常是分佈式網關端口IP地址，並且爲了簡單起見，使用與分佈式網關端口相關聯的相同chassis。

ovn-northd文檔中描述了對特定chassis的流量限制的詳細信息。

雖然分佈式網關端口的大部分物理位置相關方面可以通過將某些流量限制到特定chassis來處理，但還需要一個額外的機制。當數據包離開入口管道，邏輯出口端口是分佈式網關端口時，需要表32中兩個不同的動作集中的一個：

• 如果可以在發送者的hypervisor上本地處理該分組（例如，一對一的NAT通信量），則該分組應該以正常的方式重新提交到表33，用於分佈式邏輯patch端口。
• 但是，如果數據包需要在與分佈式網關端口關聯的chassis（例如，一對多SNAT流量或非NAT流量）上處理，則表32必須將該數據包在隧道端口上發送到該chassis。

爲了觸發第二組動作，已經添加了chassisredirect類型的南向數據庫的Port_Binding表。將邏輯出口端口設置爲類型爲chassisredirect的邏輯端口只是一種方式，表明雖然該數據包是指向分佈式網關端口的，但需要將其重定向到不同的chassis。在表32中，具有該邏輯輸出端口的分組被髮送到特定的chassis，與表32將邏輯輸出端口是VIF或者類型爲13的網關端口的分組指向不同的chassis的方式相同。一旦分組到達該chassis，表33將邏輯出口端口重置爲代表分佈式網關端口的值。對於每個分佈式網關端口，除了表示分佈式網關端口的分佈式邏輯patch端口外，還有一個類型爲chassisredirect的端口。

分佈式網關端口的高可用性

OVN允許您爲分佈式網關端口指定chassis的優先級列表。這是通過將多個Gateway_Chassis行與OVN_Northbound數據庫中的Logical_Router_Port關聯來完成的。

當爲網關指定了多個chassis時，所有可能向該網關發送數據包的chassis都將啓用到所有配置的網關chassis的通道上的BFD。當前網關的主chassis是目前最高優先級的網關chassis，當前是根據BFD狀態判斷爲主chassis。

有關L3網關高可用性的更多信息，請參閱
http://docs.openvswitch.org/en/latest/topics/high-availability

VTEP網關的生命週期

網關其實是一種chassis，用於在邏輯網絡的OVN管理部分和物理VLAN之間轉發流量，將基於隧道的邏輯網絡擴展到物理網絡。

以下步驟通常涉及OVN和VTEP數據庫模式的詳細信息。請分別參閱ovn-sb，ovn-nb和vtep，瞭解關於這些數據庫的全文。

1. VTEP網關的生命週期始於管理員將VTEP網關注冊爲VTEP數據庫中的Physical_Switch表項。連接到此VTEP數據庫的ovn-controller-vtep將識別新的VTEP網關，並在OVN_Southbound數據庫中爲其創建新的Chassis表條目。

2. 然後，管理員可以創建一個新的Logical_Switch表項，並將VTEP網關端口上的特定vlan綁定到任何VTEP邏輯交換機。一旦VTEP邏輯交換機綁定到VTEP網關，ovn-controller-vtep將檢測到它，並將其名稱添加到OVN_Southbound數據庫中chassis表的vtep_logical_switches列。請注意，VTEP邏輯交換機的tunnel_key列在創建時未被填充。當相應的vtep邏輯交換機綁定到OVN邏輯網絡時，ovn-controller-vtep將設置列。

3. 現在，管理員可以使用CMS將VTEP邏輯交換機添加到OVN邏輯網絡。爲此，CMS必須首先在OVN_Northbound數據庫中創建一個新的Logical_Switch_Port表項。然後，該條目的類型列必須設置爲“vtep”。 接下來，還必須指定options列中的vtep-logical-switch和vtep-physical-switch密鑰，因爲多個VTEP網關可以連接到同一個VTEP邏輯交換機。

4. OVN_Northbound數據庫中新創建的邏輯端口及其配置將作爲新的Port_Binding表項傳遞給OVN_Southbound數據庫。 ovn-controller-vtep將識別更改並將邏輯端口綁定到相應的VTEP網關chassis。禁止將同一個VTEP邏輯交換機綁定到不同的OVN邏輯網絡，則會在日誌中產生警告。

5. 除綁定到VTEP網關chassis外，ovn-controller-vtep會將VTEP邏輯交換機的tunnel_key列更新爲綁定OVN邏輯網絡的相應Datapath_Binding表項的tunnel_key。

6. 接下來，ovn-controller-vtep將對OVN_Northbound數據庫中的Port_Binding中的配置更改作出反應，並更新VTEP數據庫中的Ucast_Macs_Remote表。這使得VTEP網關可以瞭解從哪裏轉發來自擴展外部網絡的單播流量。

7. 最終，當管理員從VTEP數據庫取消註冊VTEP網關時，VTEP網關的生命週期結束。ovn-controller-vtep將識別該事件並刪除OVN_Southbound數據庫中的所有相關配置（chassis表條目和端口綁定）。

8. 當ovn-controller-vtep終止時，將清除OVN_Southbound數據庫和VTEP數據庫中的所有相關配置，包括所有註冊的VTEP網關及其端口綁定的Chassis表條目以及所有Ucast_Macs_Remote表項和Logical_Switch隧道密鑰。

安全

針對南向數據庫的基於角色的訪問控制

爲了提供額外的安全性以防止OVNchassis受到攻擊，從而防止流氓軟件對南向數據庫狀態進行任意修改，從而中斷OVN網絡，從而有了針對南向數據庫的基於角色的訪問控制策略（請參閱ovsdb-server部分以獲取更多詳細信息）。

基於角色的訪問控制（RBAC）的實現需要在OVSDB模式中添加兩個表：RBAC_Role表，該表由角色名稱進行索引，並將可以對給定角色修改的各個表的名稱映射到權限表中的單個行，其中包含該角色的詳細權限信息，權限表本身由包含以下信息的行組成：

Table Name

關聯表的名稱。本欄主要作爲幫助人們閱讀本表內容。

認證標準

一組包含列名稱的字符串。至少一個列或列的內容：要修改，插入或刪除的行中的鍵值必須等於嘗試作用於該行的客戶端的ID,以便授權檢查通過。如果授權標準爲空，則禁用授權檢查，並且該角色的所有客戶端將被視爲授權。

插入/刪除

行插入/刪除權限(布爾值)，指示相關表是否允許插入和刪除行。 如果爲true，則授權客戶端允許插入和刪除行。

可更新的列

一組包含可能由授權客戶端更新或變異的列或列名稱的密鑰對。只有在客戶的授權檢查通過並且所有要修改的列都包含在這組可修改的列中時，才允許修改行中的列。

OVN南行數據庫的RBAC配置由ovn-northd維護。啓用RBAC時，只允許對Chassis，Encap，Port_Binding和MAC_Binding表進行修改，並且重新分配如下：

Chassis

• 授權：客戶端ID必須與機箱名稱匹配。
• 插入/刪除：允許授權的行插入和刪除。
• 更新：授權時可以修改列nb_cfg，external_ids，encaps和vtep_logical_switches。

Encap授權

• 授權：禁用（所有客戶端都被認爲是授權的)。未來在這個表格中添加一個“創建chassis名稱”列，並用它來進行授權檢查。
• 插入/刪除：允許授權的行插入和刪除。
• 更新：列類型，選項和IP可以修改。

Port_Binding

• 授權：禁用（所有客戶端都被認爲是授權的)。未來的增強可能會添加列（或關鍵字external_ids），以控制哪個chassis允許綁定每個端口。
• 插入/刪除：不允許行插入/刪除（ovn-northd維護此表中的行）
• 更新：只允許對機箱列進行修改。

MAC_Binding

• 授權：禁用（所有客戶被認爲是授權
• 插入/刪除：允許行插入/刪除。
• 更新：logical_port，ip，mac和datapath列可以由ovn-controller修改。

爲ovn-controller連接到南行數據庫啓用RBAC需要以下步驟：

1. 爲證書CN字段設置爲chassis名稱的每個chassis創建SSL證書（例如，對於帶有external-ids：system-id = chassis-1的chassis，通過命令“ovs-pki -B 1024 -u req + sign chassis-1 switch“）。

2. 當連接到南向數據庫時配置每個ovn-controller使用SSL。（例如通過”ovs-vsctl set open . external-ids:ovn-remote=ssl:x.x.x.x:6642”)。

3. 使用“ovn-controller”角色配置南向數據庫SSL遠程。(例如通過 “ovn-sbctl set-connection role=ovn-controller pssl:6642”)。

設計決策

隧道封裝

OVN標註它從一個hypervisor發送的邏輯網絡數據包到另一個hypervisor，包含以下三個元數據，這是在封裝特定的方式編碼：

1. 24位邏輯數據路徑標識符，來自OVN Southbound數據庫Datapath_Binding表中的隧道密鑰列。
2. 15位邏輯入口端口標識符。ID 0保留在OVN內部供內部使用。可以將ID 1到32767（包括端點）分配給邏輯端口（請參閱OVN Southbound Port_Binding表中的tunnel_key列）。
3. 16位邏輯出口端口標識符。ID 0到32767與邏輯入口端口具有相同的含義。可以將包含32768到65535的ID分配給邏輯組播組（請參閱OVN Southbound Multicast_Group表中的tunnel_key列）。

對於hypervisor到hypervisor的流量，OVN僅支持Geneve和STT封裝，原因如下：

1. 只有STT和Geneve支持OVN使用的大量元數據（每個數據包超過32位）（如上所述）。
2. STT和Geneve使用隨機化的UDP或TCP源端口，允許在底層使用ECMP的環境中在多個路徑之間進行高效分發。
3. NIC支持對STT和Geneve封裝和解封裝。

由於其靈活性，hypervisor之間的首選封裝是Geneve。對於Geneve封裝，OVN在Geneve VNI中傳輸邏輯數據路徑標識符。OVN將類別爲0x0102，類型爲0x80的TLV中的邏輯入口端口和邏輯出口端口從MSB傳輸到LSB，其編碼爲32位，如下所示：

         1       15          16
       +---+------------+-----------+
       |rsv|ingress port|egress port|
       +---+------------+-----------+
         0

網卡缺少支持Geneve的環境可能更喜歡STT封裝以達到性能的原因。對於STT封裝，OVN將STT 64位隧道ID中的所有三個邏輯元數據編碼如下，從MSB到LSB：

           9          15          16         24
       +--------+------------+-----------+--------+
       |reserved|ingress port|egress port|datapath|
       +--------+------------+-----------+--------+
           0

爲了連接到網關，除了Geneve和STT之外，OVN還支持VXLAN，因爲在機架交換機(ToR）上只支持VXLAN。目前，網關具有與由VTEP模式定義的能力匹配的特徵集，因此元數據的比特數是必需的。 將來，不支持封裝大量元數據的網關可能會繼續減少功能集。