OVS和OVN 2.8新功能

OVS和OVN 2.8新功能

本文最初整理在我的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文件。如果您對Open vSwitch或OVN功能有任何疑問,請隨時寫信到[email protected]上的Open vSwitch郵件列表。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章