介紹OVN中的新功能

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

本文翻譯自ovs官方文檔

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

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

調(diào)試和故障排除

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

對用戶不友好的UUID

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

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

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

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

層之間的連接

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

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

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

分布式防火墻

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

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

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

摘要顯示

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

DNS和IPAM

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

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

高可用

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

ovn-northd高可用

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

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

L3網(wǎng)關(guān)高可用

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

OVSDB

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

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

高可用

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

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

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

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

RBAC安全

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

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

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

更多的功能

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