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

本文翻譯自ovs官方文檔

本文檔主要是關于2017年8月底發布的Open vSwitch 2.8中添加的內容，重點介紹OVN中的新功能。同時也涵蓋了即將在2018年2月發布的Open vSwitch和OVN 2.9中的一些內容。OVN具有許多特性，本文檔不包括每個新增或增強的功能。

本文檔假定您已熟悉Open vSwitch，OVN及其相關工具。有關更多信息，請參閱Open vSwitch和OVN文檔，例如ovn-architecture的內容。

調試和故障排除

在版本2.8之前，Open vSwitch命令行工具的使用是比較痛苦的。本節介紹2.8版本中對CLI的改進。

對用戶不友好的UUID

OVN的ovn-nbctl，ovn-nbctl和ovn-trace等CLI工具，幾乎在任何地方都使用長UUID。這意味著我們平時操作會將UUID從一個命令或窗口粘貼到另一個命令或窗口。而且在許多地方，人們希望能夠使用網絡，路由器或端口名稱，但顯示的是卻是UUID。這些缺點使CLI缺乏對用戶的友好。

有一個根本的問題，南向數據庫實際上并不包含提供一個友好的用戶界面所需的所有信息。例如，在某些情況下，人們希望用于實體的人性化名稱卻不是數據庫的一部分。這些名稱對于正確性來說不是必需的，只是為了可用性。

OVN 2.8版本優化了許多這些問題。現在CLI的大部分部分都允許用戶縮寫UUID，只要縮寫在數據庫中是唯一的。CLI中的某些部分全長UUID使輸出很難讀取，現在允許縮寫它們。同時更重要的是，在許多地方，OVN CLI現在顯示并接受網絡，路由器，端口和其他實體的對人友好的名稱。在以前沒有提供名稱的地方，OVN（通過ovn-northd）現在將名稱復制到南向數據庫中。

在OVN之下的CLI，分別在OpenFlow和datapath層的ovs-ofctl和ovs-dpctl，都有一些類似的問題，其中的數字用于對用戶友好的名稱的實體。OVS 2.8也解決了一些這些問題。除此之外，最顯著的增強是ovs-ofctl dump-flows的–no-stats選項，這使得該命令的輸出在讀者不感興趣的情況下更易讀。

層之間的連接

OVN和Open vSwitch幾乎就像其他編譯器一樣工作：OVN Neutron插件將Neutron配置轉換成OVN北向配置，ovn-northd將之轉換為邏輯流，ovn-controller轉換為OpenFlow流，ovs-vswitchd轉換為數據路徑流。為了調試和排除故障，通常有必要準確理解這些控制信息的翻譯是如何工作的。從邏輯流到OpenFlow流，或從另一個方向，從OpenFlow流到產生它的邏輯流，我們通常是特別感興趣的，但是OVN并沒有為這項工作提供很好的工具。

OVN 2.8增加了一些可以增強這些工作的新功能。ovn-sbctl lflow-list有一個新的選項–ovs，它列出了從它指定的邏輯流中生成的特定chassis上的OpenFlow流。ovn-trace還添加了一個類似的–ovs選項，適用于它所跟蹤的邏輯流。

另一方面，OVN 2.8添加了一個新的實用程序ovn-detrace，針對指定的Open vSwitch所跟蹤的OpenFlow流使，對產生這些OpenFlow流的邏輯流進行注釋。

分布式防火墻

OVN支持有狀態連接跟蹤的分布式防火墻，以確保只有已建立連接的數據包或配置明確允許的數據包才能進入給定的虛擬機或容器。Neutron默認使用這個功能，在OpenStack環境中，大多數數據包通過兩次，一次是從數據包的源虛擬機出站，一次是在進入目標虛擬機之前。在OVN 2.8之前，ovn-trace程序（通過OVN邏輯網絡顯示數據包的路徑）不支持邏輯防火墻，這在實際上使Neutron幾乎無用。

在OVN 2.8中，ovn-trace增加了對邏輯防火墻的支持。默認情況下，它假設數據包是已建立連接的一部分，這通常是用戶所想要作為跟蹤的一部分。它也接受命令行選項來覆蓋這個假設，允許用戶發現防火墻應該丟棄的數據包的處理方式。

在更深層次上，在Open vSwitch 2.8之前，ofproto/trace的OpenFlow跟蹤命令既不支持OVN分布式防火墻的連接跟蹤功能，也不支持“再循環”功能。這意味著即使用戶試圖深入分析分布式防火墻機制，則會遇到更多的障礙。Open vSwitch 2.8增加了對這兩個功能的支持。

摘要顯示

ovn-nbctl show和ovn-sbctl show顯示OVN配置的概述，沒有顯示很多重要的信息。OVN 2.8在這里添加了一些更有用的信息。

DNS和IPAM

OVN 2.8添加了一個內置的DNS服務器，用于為OVN邏輯網絡中的虛擬機和容器分配名稱。DNS名稱使用OVN北向數據庫中的記錄進行分配，并與其他OVN功能一樣，在OVN南向數據庫轉換為邏輯流。指向OVN DNS服務器的DNS請求永遠不會離開發送請求的管理程序; 相反，OVN處理并響應來自其ovn-controller本地代理的請求。OVN DNS服務器不是通用DNS服務器，不能作為通用DNS服務器使用。

OVN包括對IP地址管理（IPAM）的簡單內置支持，OVN將IP地址分配給管理員委派給它的一個或多個IP地址池中的VM或容器。 在OVN 2.8之前，OVN IPAM只支持IPv4地址; OVN 2.8增加了對IPv6的支持。OVN 2.8還增強了地址池支持，允許排除特定的地址。注意：Neutron自己分配IP地址，不使用OVN IPAM。

高可用

作為一個分布式系統，在OVN運行中可能會出不少的錯。所以有必要在單一故障可能干擾整個系統運行的地方增加冗余。OVN 2.8增加了兩種新的高可用性。

ovn-northd高可用

ovn-northd程序位于OVN北向和南向數據庫之間，并將邏輯網絡配置轉換為邏輯流。如果ovn-northd本身或其運行所在的主機失敗，則OVN北向配置的更新將不會傳播到hypervisors，OVN配置會凍結，直到ovn-northd重新啟動。

OVN 2.8增加了對ovn-northd的主動備份HA的支持。當運行多個ovn-northd實例時，它將使用OVSDB鎖定功能自動選擇單個活動實例。當該實例死亡或無響應時，OVSDB服務器將自動選擇剩下的一個實例來接管。

L3網關高可用

在OVN 2.8中，現在可以為L3網關指定多個chassis。當指定多個chassis時，OVN管理該網關的高可用性。每個hypervisor使用BFD協議跟蹤當前正在運行的網關節點。在任何時候，hypervisor都使用當前最高優先級的網關節點。

OVSDB

OVN架構在很大程度上嚴重依賴OpenSwitch數據庫OVSDB來托管北向和南向數據庫。OVSDB最初是為此目的而選擇的，因為它已經在Open vSwitch中用于配置OVS本身，因此它與OVS可以很好地集成在一起，并且在OpenVSwitch中使用的兩種語言C和Python都得到很好的支持。

OVSDB的最初設計目的是為了配置Open vSwitch的。它支持ACID事務處理，具有一個小型，高效的服務器，一個靈活的模式系統，以及對故障排除和調試的良好支持。但是，它缺少一些對于OVN而言非常重要的功能。隨著OVN的發展，這些缺失的特征已經成為越來越多的問題。一種選擇是切換到已經具有許多這些功能的其他數據庫，但是經過仔細的搜索，沒有找到理想的現有數據庫，因此項目選擇在必要時改進OVSDB以加快速度。以下部分將詳細討論最近和將來的改進。

高可用

當ovsdb-server僅用于OVS配置時，高可用性并不重要。如果系統崩潰，ovsdb-server能夠自動重新啟動，而且如果整個系統出現故障，Open vSwitch本身也會死機，所以數據庫服務器的故障并不重要。

相反，北向和南向的數據庫是分布式系統的集中式組件，因此它們不是整個系統的單一故障點。在發布的OVN版本中，ovsdb-server只支持一對服務器上的“主動備份復制”。這意味著如果一臺服務器出現故障，另一臺服務器可以在另一臺服務器停止的地方將其重新啟動。服務器在任何時候都沒有內置的支持來決定哪個是活動的，哪個是備份的，所以管理員必須配置一個外部代理來進行這種管理。

主動備份復制并不完全令人滿意，原因有很多。復制只是近似的，配置外部代理需要額外的工作。備用服務器沒有任何好處，除非主用服務器出現故障。最多可以使用兩臺服務器。

基于分布式共識的Raft算法，OVN 2.9版本正在開發針對OVSDB的高可用的新形式。而主動備份復制使用的是兩臺服務器，使用Raft進行集群需要三個或更多（通常是一個奇數），并且只要有一半以上的服務器運行，就會繼續運行。集群實現內置在ovsdb-server中，不需要外部代理。群集保留數據庫的ACID屬性，以保證提交的事務保持持久。最后，讀取（這是OVN工作負載的大部分）隨集群大小而擴展，因此，隨著OVN部署中hypervisor的數量的增加，添加更多服務器應該可以提高性能。在撰寫本文時，OVSDB對群集的支持正在進行開發和早期部署測試。

RBAC安全

在Open vSwitch 2.8之前，ovsdb-server幾乎不支持數據庫中的訪問控制。如果OVSDB客戶端可以修改數據庫，則可以進行任意更改。這對于大多數用例來說已經足夠了。

OVN部署中的hypervisor需要訪問OVN南向數據庫。他們的大部分訪問是讀取，以了解OVN的配置。hypervisor確實需要對南向數據庫進行一些寫入訪問，主要是讓其他hypervisor知道正在運行的虛擬機和容器以及如何訪問到它們。因此，OVN為OVN部署中的所有hypervisor提供對OVN南向數據庫的寫訪問權限。這一切都很好，但如果任何hypervisor被破壞，那么他們可能會破壞整個OVN部署，破壞數據庫。

OVN開發人員考慮了幾種方法來解決這個問題。一種方法是引入一個新的中央服務（可能在ovn-northd中），只提供hypervisor合法的需要的寫入類型，然后授予hypervisor直接訪問南向數據庫的權限，以便讀取。但最終開發人員決定引入一種新的OVSDB訪問控制形式，稱為OVSDB RBAC（基于角色的訪問控制）功能。OVSDB RBAC允許對訪問進行足夠精細的控制，hypervisor只能被賦予添加，修改和刪除與自身相關的記錄的能力，從而防止它們作為整體破壞數據庫。

更多的功能

有關OVN和Open vSwitch中新增功能的更多信息，請參閱與源代碼樹一起分發的NEWS文件。