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

本文翻譯自ovs官方文檔

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

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

調試和故障排除

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

對用戶不友好的UUID

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

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

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

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

層之間的連接

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

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

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

分布式防火墻

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

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

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

摘要顯示

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

DNS和IPAM

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

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

高可用

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

ovn-northd高可用

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

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

L3網(wǎng)關高可用

在OVN 2.8中，現(xiàn)在可以為L3網(wǎng)關指定多個chassis。當指定多個chassis時，OVN管理該網(wǎng)關的高可用性。每個hypervisor使用BFD協(xié)議跟蹤當前正在運行的網(wǎng)關節(jié)點。在任何時候，hypervisor都使用當前最高優(yōu)先級的網(wǎng)關節(jié)點。

OVSDB

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

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

高可用

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

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

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

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

RBAC安全

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

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

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

更多的功能

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