OVN簡介

3、OVN入門

3.1 OVN簡介

Open vSwitch（OVS）是一款開源的「虛擬交換機」，控制協議方面它不但支持OpenFlow的全部特性並且擴展了部分OpenFlow的功能；Overlay協議方面它支持GRE, VXLAN, STT, Geneve四種主流Overlay數據包。OVS已是數據平面的事實標準了，不少白盒交換機都兼容它提供的接口；還有一些x86架構的交換機則直接是基於OVS和DPDK的。因此不管「上層」的ODL、ONOS、Neutron如何的翻天覆地的「鬧騰」而OVS仍是巋然不動（最後流表的執行者仍是OVS）。

可是長期一來OVS都缺少一個統一的網絡模型（Neutron雖然花費巨大力氣實現一個網絡模型可是僅僅適用於OpenStack而沒法用於容器更加沒法單獨使用），因而在2015年OVS社區宣佈了一個子項目——Open Virtual Network（OVN）。它旨在爲OVS提供一個控制平面，經過一個統一的網絡模型爲容器、虛擬機提供相同的網絡服務。

雖然不少人不肯意認可可是事實上它瞄準的對象是三個——ODL、ONOS、Neutron。咱們能夠看一下OpenStack中networking-ovn子項目，它是基於OVN實現的「Neutron」旨在替換Neutron的L二、L3功能。對比傳統的Neutron的L二、L3的實現代碼它的代碼量很是少。這就是OVN的優勢，對比ODL、ONOS、Neutron提供的大而全、複雜龐大、緊耦合的控制器，OVN提供的是一個輕量級控制器，這個輕量級不但體如今OVN自己的代碼少（只有幾個C語言文件，並且代碼不多），模型簡單（雖然簡單可是很豐富，更懂得利用OVS自己的特性）並且它的流表設計（Pipeline）也容易理解。
OVN的功能

• L2功能，叫Logical switches（邏輯交換機）
• L3功能，叫Logical Router（邏輯路由器）
• ACL，就像咱們物理交換機能夠配置ACL，OVN能夠針對邏輯交換機添加ACL
• NAT，SNAT、DNAT都支持
• Load Balancer，支持面向內部的負載均衡和提供外部訪問的負載均衡

OVN的架構

這幅架構圖描繪了OVN的總體架構和進程分佈，爲了討論方便咱們把OVN中承擔「管理」任務的節點成爲ovn-central；把承擔實際數據轉發的節點成爲ovn-host（能夠類比成controller node、compute node）。

OVN引入了兩個全新的OVSDB，一個叫Northbound DB（北向數據庫，NB），一個叫Southbound DB（南向數據庫，SB）；兩個庫均可以導出遠程接口，容許用戶經過OVSDB協議對數據庫進行操做（沒必要擔憂OVSDB只是叫DB而已，其實它更像etcd、zookeeper這種中間件）。

NB存放的是咱們定義的邏輯交換機、邏輯路由器之類的數據，咱們能夠經過ovn提供的命令行（ovn-nbctl）完成添加、刪除、修改、查詢等操做；固然能夠寫代碼經過OVSDB協議完成相似動做。OVN的NB是面向「上層應用」的或者叫「雲管平臺（Cloud Management System，CMS）」因此叫「北向接口」。

SB進程比較特殊它同時接受兩邊的「寫入」，首先是運行在ovn-host上的ovn-controller啓動以後會去主動鏈接到ovn-central節點上的SB進程，把本身的IP地址（Chassis），本機的OVS狀態（Datapath_Binding）寫入到SB數據庫中（因此叫南向接口）。ovn-controller還「監聽」（etcd、zookeeper相似的功能）SB數據庫中流表的變化（Flow）去更新本地的OVS數據庫，這叫「流表下發」。

SB中的流表是由運行在ovn-central節點上的ovn-northd進程修改的，ovn-northd會「監聽」NB的改變，把邏輯交換機、路由器的定義轉換成流表（Flow）寫入到SB數據庫。

整個架構很是簡單，OVN僅僅提供了一組網絡模型（邏輯交換機、邏輯路由器等），提供了一個OVSDB數據庫用來存放這些模型同時把數據庫的訪問權限開放給最終用戶，讓最終用戶經過OVSDB協議來直接「寫入」這些模型（北向）。經過一個叫ovn-northd的進程把網絡模型轉換成流表，放入另外一個數據庫讓ovn-host本身來「取」流表（南向），以此完成流表下發。

3.2 拓撲規劃

通常OVS試驗環境建議建立N臺虛擬機或者使用mininet做爲試驗環境，這種試驗環境有三方面的缺陷1. 不具有「真實性」過於簡單 2. 不便於藉助Wireshark等分析工具來分析網絡原理 3. 沒有辦法融入到真實環境，好比如何和傳統L二、L3設備互聯。

因此筆者這裏推薦一種新的實驗方式——藉助GNS3完成實驗。

GNS3提供OVS在2.6以上版本纔會提供OVN支持（2.5的版本不太靠譜，跟如今的命令沒法兼容），你們能夠去官方網站上下載OVS本身來編譯（目前版本是2.7）。固然若是你像我同樣懶得話能夠直接用編譯好的，Centos沒有提供OVS源，你們能夠經過ovirt的yum源安裝2.7版本。我我的的選擇的版本是Ubuntu17（Ubuntu16帶的是OVS2.5），它內置了OVS2.6版本的源，直接apt-get install就能夠完成安裝了。
經過GNS3建立一個拓撲

端口鏈接方式和服務器列表

服務器 | 業務IP|角色
ovn-node1 | 10.10.10.11 | central
ovn-node2 | 10.10.10.12 | host
ovn-node3 | 10.10.10.13 | host

截圖中是ovn-node1的IP地址配置，注意我使用第二塊網卡做爲OVN互聯網的網絡（也是經過SW1互聯的網卡），第一塊網卡是NAT配置，由VMWare DHCP分配的，此處做爲單純的管理IP（用於SSH登陸）。

3.3 安裝配置

在ovn-node1上做爲「管理節點」（架構圖中叫 ovn-central，Ubuntu中軟件包也叫 ovn-central）

安裝成功後能夠看到ovn相關進程，

在ovn-central啓動了ovn-northd守護進程，兩個OVSDB進程（分別是SB和NB）。
驗證SB（6642）、NB（6641）的遠程端口已經打開，

在ovn-node一、ovn-node2上安裝ovn-host

安裝成功後能夠看到ovn相關進程


啓動了ovn-controller進程和openvswtich進程
經過下面的命令把ovn-host節點鏈接到ovn-central（overlay封裝協議爲vxlan）

 

 

 

 

Java

 

1	`sudo ovs-vsctl set Open_vSwitch . external_ids:ovn-remote="tcp:10.10.10.11:6642" external_ids:ovn-encap-ip="10.10.10.12" external_ids:ovn-encap-type=vxlan`

在ovn-node1上執行驗證ovn-node2添加成功（chassis）

3.4 學會排錯

因爲環境不同因此實驗的過程當中確定會碰到各類問題，咱們又不太可能枚舉出全部的常見問題挨個說明。最有效的方式是「授人以漁」，因此後續的文章中我會盡可能把若是排錯寫錯來。今天咱們先學習閱讀OVN產生的日誌。
ovn-central上的/var/log/openvswitch/如下幾個文件：

• ovn-northd.log ，ovn-northd進程產生的日誌，相似下面的輸出

能夠看到ovn-northd進程經過unix domain socket（Linux下一種IPC通信方式）鏈接上了SB、NB數據庫進程。

• ovsdb-server.log ，本機OVS數據庫進程日誌。通常咱們不會讓ovn-central加入到網絡轉發中因此這個進程以及日誌都用不到。
• ovsdb-server-nb.log，NB數據庫日誌
• ovsdb-server-sb.log ，SB數據庫日誌
• ovs-vswitchd.log，本機OVS進程，通常咱們不會讓ovn-central加入到網絡轉發中因此這個進程以及日誌都用不到。

ovn-host上的/var/log/openvswitch/如下幾個文件：

• ovn-controller.log ，ovn-controller產生的日誌，輸入以下

以紅線爲分割，上面彙報了ovn-controller鏈接了兩個OVSDB數據——經過unix domain socket鏈接到本地OVS數據庫；經過TCP鏈接到遠程OVS數據庫。下面彙報了ovn-controller發現的本地網橋（Datapath）。

• ovsdb-server.log ，本機OVS數據庫進程日誌
• ovs-vswitchd.log，本機OVS進程日誌

ovn-host承擔數據轉發功能，因此本機OVS須要參與轉發的，日誌是頗有價值的

重點分析一下， ovs-vswitchd.log的內容。首先是彙報系統的硬件狀態，經過unix domain socket鏈接到本地OVS數據庫。**後面的「system@ovs-sytem」輸出很是重要**，OVS有不少特性體如今容許使用一些OpenFlow沒有定義的流表定義關鍵字（好比NAT，learn），這些特性中有一部分是須要系統支持的（內核模塊）日誌的輸出說明了OVS相關特性是否工做正常。

總結

本章咱們學習了GNS3如何使用以及抓包，除此之外，對OVN主要有一個入門的瞭解，以及瞭解如何解決問題、技術架構，安裝了一個OVN的實驗環境，學會了分析OVN產生的日誌。接下來的一章咱們會開始OVN的正式學習——學習OVN網絡模型中的第一部分「邏輯交換機」。

1、爲何OVN會出現？

OpenvSwitch （OVS） 以其豐富的功能和相對優秀的性能，成爲OpenStack中普遍使用的虛擬交換機。下圖是2年前的一個調查，時過境遷，nova-network已經被廢棄，OpenvSwitch現在的佔有率確定會更高。

OVS甚至能夠說是網絡虛擬化裏最重要的工業級開源產品，OVS模仿物理交換機設備的工做流程，實現了不少物理交換機當時才支持的許多網絡功能。OVN提供了許多原生的虛擬網絡功能，提高了OVS的工做效率和性能。
OVN是OpenvSwitch項目組爲OpenvSwitch開發SDN控制器，同其餘SDN產品相比，OVN對OpenvSwitch 及OpenStack有更好的兼容性和性能。
在2016年的OpenStack Austin 峯會上，OVN項目組有個演講提到了的OVN存在的意義（目標），原文是

• Production-quality
• Straightforward design
• Scale to 1000s of hypervisors (each with many VMs/containers)
• Improved performance and stability over existing OpenStack OVS plugin
• Become preferred method for OpenStack+OVS integration for the majority of use cases

中文翻譯以下：

• 可用於生產環境
• 簡潔的設計
• 支持1000臺以上的物理機環境（也支持至關數量的虛擬機/容器環境）
• 基於已有的OpenStack OVS 插件 來提高性能和穩定性
• 成爲OpenStack+OVS集成場景下的首選方案

已經實現從OVS 平滑升級到 OVN
OVN 對於運行平臺沒有額外的要求，只要可以運行 OVS，就能夠運行 OVN，因此從 OVS 升級到 OVN 是很是簡單快捷的。原有的網絡、路由等數據不會丟失，也不須要對這些數據導入導出來進行數據遷移

另外 OVN 能夠和不少 CMS（Cloud Management System）集成到一塊兒，尤爲是 OpenStack Neutron，這些 CMS 只須要添加一個 plugin 來配置 OVN 便可。

2、OVN使得Neutron組件數量減小

以最新的Ocata版本中的OVN和OVS 2.6版原本看OVN帶來的變化：

• OVN自帶的（時髦的說法叫"原生"）ML2 driver替換掉 OVS ML2 driver 和 Neutron的OVS agent；
• OVN原生支持L3和DHCP功能，這樣就再也不須要Neutron 的L3 agent、 DHCP agent 和DVR。

看明白了沒有？隨着OVN不斷添加新的功能，大量的Neutron agents就被幹掉了。這樣的話，組件數量將會大大減小。後面會詳細講OVN 給 Neutron帶來實現機制方面的變化。

3、OVN L3 對比 Neutron L3

Neutron 的三層功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通 Linux kernel 的namespace 來實現的，每一個路由器對應一個 namespace，利用 Linux TCP/IP 協議棧來作路由轉發。

OVN 支持原生的三層功能，不須要藉助 Linux TCP/IP stack，用OpenFlow 流表來實現路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分佈式的，路由器在每一個計算節點上都有實例，有了 OVN 以後，不須要 Neutron L3 agent 了 和DVR了。

4、OVN和其它通用SDN控制器（好比OpenDayLight）的主要區別

• OVN專一於實現雲計算管理平臺場景下的SDN控制器
• OVN專一於實現二層和三層網絡功能。除了在傳輸層實現了基於L4的ACL 外，基本上不在L4 ~ L7層實現某些功能。

5、OVN的實現了哪些功能？擁有哪些特性？

最新版本OVN的高級特性，英文原文以下：

（能夠和OVS的特性對比一下，就知道OVN和OVS 的側重點。見個人另外一篇博文http://blog.csdn.net/zhengmx100/article/details/54729272）
Provides virtual networking abstraction for OVS, implemented using L2 and L3 overlays, but can also manage connectivity to physical networks
Supports flexible ACLs (security policies) implemented using flows that use OVS connection tracking
Native support for distributed L3 routing using OVS flows, with support for both IPv4 and IPv6
ARP and IPv6 Neighbor Discovery suppression for known IP-MAC bindings
Nativesupport for NAT and load balancing using OVS connection tracking
Native fully distributedsupport for DHCP
Works with any OVS datapath (such as the default Linux kernel datapath, DPDK, or Hyper-V) that supports all required features (namely Geneve tunnels and OVS connection tracking. See the datapath feature list in the FAQ for details.)
Supports L3 gateways from logical to physical networks
Supports software-based L2 gateways
Supports TOR (Top of Rack) based L2 gateways that implement the hardware_vtep schema
Can provide networking for both VMs and containers running inside of those VMs, without a second layer of overlay networking

選取幾個重點講一下：
Logical switches：邏輯交換機，用來作二層轉發。
L2/L3/L4 ACLs：二到四層的 ACL，能夠根據報文的 MAC 地址，IP 地址，端口號來作訪問控制。
Logical routers：邏輯路由器，分佈式的，用來作三層轉發。
Multiple tunnel overlays：支持多種隧道封裝技術，有 Geneve，STT 和 VXLAN。
TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者軟件邏輯 switch 看成網關來鏈接物理網絡和虛擬網絡。

6、OVN的架構和分析

先來一張簡單明瞭的架構圖

看完上圖，感受OVN的架構很簡單是不？ 再看看我從網上找的另外一張更詳細的架構圖：

OVN/CMS Plugin 是Neutron的一個插件，做爲OVN 和 CMS 之間的接口 。它將CMS中的數據（存儲在Neutron DB）翻譯成一種「中間格式」。

這種中間格式就是邏輯網絡配置數據，這樣CMS中的網絡配置數據就可以被OVN理解 （準確的說是可以被OVN的Northbound DB 所理解）。

Northbound DB 裏面存的就是上面OVN/CMS Plugin翻譯以後的邏輯網絡的相關數據。好比 logical switch，logical router，logical port和ACL。

Northbound DB 裏面的幾乎全部的內容都是由 CMS 產生的

OVN-northd 相似於一個集中的控制器，監聽Northbound DB 數據庫的內容變化，它把 Northbound DB 裏面的邏輯網絡的相關數據翻譯成 Southbound DB 能夠理解的格式（logical datapath flows），並傳遞給 Southbound DB 進行存儲，進而被全部的chassis 讀取和應用。 （關於chassis這個概念 ，本人會在下一篇博文中進行介紹。）

Southbound DB 處在 OVN 架構的核心，它是 OVN 中最重要的部分，它跟 OVN 的其餘組件都有交互。 裏面存的數據和 Northbound DB 語義徹底不同，主要包含 3 類數據(第二類數據就是OVN-northd 從Northbound DB 翻譯過來的)：

1、物理網絡數據，好比 hypervisor的 IP 地址，hypervisor的 tunnel 封裝格式；

2、邏輯網絡數據，好比報文如何在邏輯網絡中轉發；

3、物理網絡和邏輯網絡的綁定關係，好比邏輯端口關聯到哪一個 hypervisor上面。這類數據存儲在binding表中，字段有uuid,chassis, logical_datapath, logical_port, mac, parent_port, tag, tunnel_key。

若是對這裏的2次翻譯不太明白的話，我舉個例子：
有四我的在一塊兒聊天，他們分別來自不一樣國家。
一個英國人只會英語，
一個伊拉克人同時掌握英語和阿拉伯語，
一個伊朗人同時掌握阿拉伯語和俄羅斯語，
一個俄羅斯人只會俄羅斯語。
英國人講的話要被俄羅斯人理解是否是要先被伊拉克人翻譯爲阿拉伯語，再被伊朗人翻譯俄羅斯語。 這個過程須要2我的進行翻譯。

ovn-controller 是 OVN 裏面的 agent，相似於 Neutron 裏面的 ovs-agent，它也是運行在每一個 hypervisor和軟件網關之上。

它有下面2種功能：
（1）把物理網絡的信息寫到 Southbound DB 裏面（這類信息就包括 Southbound DB中的第一類數據）；
（2）把 Southbound DB 裏面存的一些數據轉化成 Openflow flow 配到本地的 OVS table 裏面，來實現報文的轉發。

第2個功能的具體實現機制就是：
ovn-controller鏈接到到本地的ovsdb-server ，監控、讀取、管理OpenvSwitch的配置信息；

ovn-controller做爲ovs-vswitchd 的Openflow 控制器來控制流量的轉發。另外，從架構圖中就可看出ovn-controller是一種分佈式SDN控制器。

ovs-vswitchd 和 ovsdb-server 是 OVS 的兩個進程：

• ovs-vswitchd ：核心模塊，實現交換功能，和Linux內核模塊一塊兒，實現基於流的交換；
• ovsdb-server ：是一個數據庫。其保存了整個OVS的配置信息，包括接口，流表和VLAN等；ovs-vswitchd從其查詢配置信息；

小結：OVN 給 Neutron帶來實現機制方面的變化

從 OVN 的架構能夠看出，OVN 裏面數據的讀寫都是經過 OVSDB來作的，取代了 Neutron 的消息隊列機制，因此有了 OVN 以後，Neutron 裏面全部的 agent 都不須要了，Neutron 變成了一個 API server 來處理用戶的 REST 請求，其餘的功能都交給 OVN 來作，只須要在 Neutron 裏面加一個 plugin 來調用配置 OVN。

Neutron 裏面的子項目 networking-ovn 就是實現 OVN 的 plugin。Plugin 使用 OVSDB 協議來把用戶的配置寫在 Northbound DB 裏，ovn-northd 監聽到 Northbound DB 配置發生改變，而後把配置翻譯到 Southbound DB 裏面。 ovn-controller 監控到 Southbound DB 數據的發生變化以後，進而更新本地的流表。

OVN 裏面報文的處理都是經過 OVS OpenFlow 流表來實現的，而在 Neutron 裏面二層報文處理是經過 OVS OpenFlow 流表來實現，三層報文處理是經過 Linux TCP/IP 協議棧來實現。