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 协议栈来实现。