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的L2、L3功能。对比传统的Neutron的L2、L3的实现代码它的代码量非常少。这就是OVN的优点，对比ODL、ONOS、Neutron提供的大而全、复杂庞大、紧耦合的控制器，OVN提供的是一个轻量级控制器，这个轻量级不但体现在OVN本身的代码少（只有几个C语言文件，而且代码很少），模型简单（虽然简单但是很丰富，更懂得利用OVS本身的特性）而且它的流表设计（Pipeline）也容易理解。
OVN的功能
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自己来“取”流表（南向），以此完成流表下发。
一般OVS试验环境建议创建N台虚拟机或者使用mininet作为试验环境，这种试验环境有三方面的缺陷1. 不具备“真实性”过于简单 2. 不便于借助Wireshark等分析工具来分析网络原理 3. 没有办法融入到真实环境，比如如何和传统L2、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登录）。
在ovn-node1上作为“管理节点”（架构图中叫 ovn-central，Ubuntu中软件包也叫 ovn-central）
安装成功后可以看到ovn相关进程，
在ovn-central启动了ovn-northd守护进程，两个OVSDB进程（分别是SB和NB）。
验证SB（6642）、NB（6641）的远程端口已经打开，
在ovn-node1、ovn-node2上安装ovn-host
安装成功后可以看到ovn相关进程
启动了ovn-controller进程和openvswtich进程
通过下面的命令把ovn-host节点连接到ovn-central（overlay封装协议为vxlan）
|
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）
由于环境不一样所以实验的过程中肯定会碰到各种问题，我们又不太可能枚举出所有的常见问题挨个说明。最有效的方式是“授人以渔”，所以后续的文章中我会尽量把如果排错写错来。今天我们先学习阅读OVN产生的日志。
ovn-central上的/var/log/openvswitch/以下几个文件：
可以看到ovn-northd进程通过unix domain socket（Linux下一种IPC通讯方式）连接上了SB、NB数据库进程。
ovn-host上的/var/log/openvswitch/以下几个文件：
以红线为分割，上面汇报了ovn-controller连接了两个OVSDB数据——通过unix domain socket连接到本地OVS数据库；通过TCP连接到远程OVS数据库。下面汇报了ovn-controller发现的本地网桥（Datapath）。
ovn-host承担数据转发功能，所以本机OVS需要参与转发的，日志是很有价值的
重点分析一下， ovs-vswitchd.log的内容。首先是汇报系统的硬件状态，通过unix domain socket连接到本地OVS数据库。**后面的“system@ovs-sytem”输出非常重要**，OVS有很多特性体现在允许使用一些OpenFlow没有定义的流表定义关键字（比如NAT，learn），这些特性中有一部分是需要系统支持的（内核模块）日志的输出说明了OVS相关特性是否工作正常。
本章我们学习了GNS3如何使用以及抓包，除此以外，对OVN主要有一个入门的了解，以及了解如何解决问题、技术架构，安装了一个OVN的实验环境，学会了分析OVN产生的日志。接下来的一章我们会开始OVN的正式学习——学习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存在的意义（目标），原文是
中文翻译如下：
已经实现从OVS 平滑升级到 OVN
OVN 对于运行平台没有额外的要求，只要能够运行 OVS，就可以运行 OVN，所以从 OVS 升级到 OVN 是非常简单快捷的。原有的网络、路由等数据不会丢失，也不需要对这些数据导入导出来进行数据迁移
另外 OVN 可以和很多 CMS（Cloud Management System）集成到一起，尤其是 OpenStack Neutron，这些 CMS 只需要添加一个 plugin 来配置 OVN 即可。
以最新的Ocata版本中的OVN和OVS 2.6版本来看OVN带来的变化：
看明白了没有？随着OVN不断添加新的功能，大量的Neutron agents就被干掉了。这样的话，组件数量将会大大减少。后面会详细讲OVN 给 Neutron带来实现机制方面的变化。
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了。
最新版本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 当作网关来连接物理网络和虚拟网络。
先来一张简单明了的架构图
看完上图，感觉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 翻译过来的)：
一、物理网络数据，比如 hypervisor的 IP 地址，hypervisor的 tunnel 封装格式；
二、逻辑网络数据，比如报文如何在逻辑网络中转发；
三、物理网络和逻辑网络的绑定关系，比如逻辑端口关联到哪个 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 的两个进程：
从 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 协议栈来实现。
转载于:https://www.cnblogs.com/liuhongru/p/11121731.html
