OVN 介绍
Open vSwitch(OVS)是一款开源的“虚拟交换机”,控制协议方面它不但支持 OpenFlow 的所有特性而且扩展了部分 OpenFlow 的功能;Overlay 协议方面它支持 GRE, VXLAN, STT, Geneve 四种主流Overlay 数据包。OVS 已经是数据平面的事实标准了。
但是长期一来 OVS 都缺乏一个统一的网络模型(Neutron 虽然花费巨大力气实现一个网络模型但是仅仅适用于 OpenStack 而无法用于容器更加无法单独使用),于是在2015年 OVS 社区宣布了一个子项目——Open Virtual Network(OVN)。它旨在为 OVS 提供一个控制平面,通过一个统一的网络模型为容器、虚拟机提供相同的网络服务。
OVN 提供的是一个轻量级控制器,提供了比 openvSwitch 更高层的抽象,与逻辑路由器和逻辑交换机而不是 flow 一起工作;这个轻量级不但体现在 OVN 本身的代码少(只有几个 C 语言文件,而且代码很少),模型简单(虽然简单但是很丰富,更懂得利用 OVS 本身的特性)而且它的流表设计(Pipeline)也容易理解。
OVN 是一系列守护程序,它们将虚拟网络配置转换为 OpenFlow,并将其安装到 openvSwitch 中;
OVN 的功能
- L2功能,分布式逻辑交换机
- L3功能,分布式逻辑路由器
- ACL,访问控制列表
- DHCP,DNS
- NAT,SNAT、DNAT都支持
- Load Balancer,支持面向内部的负载均衡和提供外部访问的负载均衡
OVN的架构
CMS
|
|
+-----------|-----------+
| | |
| OVN/CMS Plugin |
| | |
| | |
| OVN Northbound DB |
| | |
| | |
| ovn-northd |
| | |
+-----------|-----------+
|
|
+-------------------+
| OVN Southbound DB |
+-------------------+
|
|
+------------------+------------------+
| | |
HV 1 | | HV n |
+---------------|---------------+ . +---------------|---------------+
| | | . | | |
| ovn-controller | . | ovn-controller |
| | | | . | | | |
| | | | | | | |
| ovs-vswitchd ovsdb-server | | ovs-vswitchd ovsdb-server |
| | | |
+-------------------------------+ +-------------------------------+
主要组成部分包括:
- ovn northd,将 CMS 的北向配置转换为南向数据库的逻辑流。连接其上方的 ovn Northbound 数据库和下方的 ovn Southbound 数据库。它将传统网络概念中的逻辑网络配置(取自 OVN 北向数据库)转换为其下方 OVN 南向数据库中的逻辑数据路径流。
- ovn controller,一个在集群中的每个 Hypervisor 上的 OVN agent,北向连接 ovn-southbound 数据库。它将南向数据库中的逻辑流转换为 OpenFlow for Open vSwitch。它还处理某些流量,例如 DHCP 和 DNS。
- ovn nbctl,一个用于连接北向数据库的工具。
- ovn sbctl,一个用于连接南向数据库的工具。
- ovn northbound Database, 接收 OVN/CMS 插件传递的逻辑网络配置的中间件。数据库模式意味着与 CMS 中使用的概念匹配,它直接支持逻辑交换机、路由器、ACL等概念。
- OVN Southbound Database,包含三种数据:指定如何到达 hypervisor 和其他节点的物理网络(PN)表,用“逻辑数据路径流”描述逻辑网络的逻辑网络(LN)表,“”和将逻辑网络组件的位置链接到物理网络的绑定表。
OVN 引入了两个全新的 OVSDB,一个叫 Northbound DB(北向数据库,NB),一个叫 Southbound DB(南向数据库,SB);两个库都可以导出远程接口,允许用户通过 OVSDB 协议对数据库进行操作。
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 还“监听” SB 数据库中流表的变化(Flow)去更新本地的 OVS 数据库 – 流表下发。
SB 中的流表是由运行在 ovn-central 节点上的 ovn-northd 进程修改的,ovn-northd 会“监听” NB 的改变,把逻辑交换机、路由器的定义转换成流表(Flow)写入到 SB 数据库。
整个架构非常简单,OVN 仅仅提供了一组网络模型(逻辑交换机、逻辑路由器等),提供了一个OVSDB 数据库用来存放这些模型同时把数据库的访问权限开放给最终用户,让最终用户通过 OVSDB 协议来直接“写入”这些模型(北向)。通过一个叫 ovn-northd 的进程把网络模型转换成流表,放入另一个数据库让 ovn-host 自己来“取”流表(南向),以此完成流表下发。
OVN 应用
OVN 信息流
配置数据
OVN 中的配置数据从北向南传递,CMS 使用其 OVN/CMS 插件通过 northbound 数据库传递 ovn 的逻辑网络配置给 ovn−northd,反过来,ovn−northd 将配置编译为较低级别的形式,并通过 southbound 数据库将其传递给所有 chassis;
状态信息
ovn 中的状态信息从南向北传递。OVN 目前只提供几种形式的状态信息。
首先,ovn−northd 填充 northbound Logical_Switch_Port 表中的 up 表项,如果 southbound port_Binding 表中逻辑端口的 chassis column 为空,则设置为true,这允许CMS检测VM的网络何时出现。
第二,OVN 向 CMS 反馈其配置的实现情况,配置是否生效,该功能需要 CMS 参与一个序列号协议,工作方式如下:
- 当 CMS 更新北向数据库中的配置时,作为同一事务的一部分,它会增加 NB_Global 表中 nb_cfg 列的值。
- 当 ovn−northd 根据北向数据库的给定快照更新南向数据库,它将 nb_cfg 从北行 nb_Global 复制到南向数据库 SB_Global 表中,作为同一事务的一部分。
- 在 ovn−northd 从南向数据库收到其更改已提交的确认,它将 northbound nb_Global 表中的 sb_cfg 更新为 NB_cfg 版本。
- ovn−controller 进程接收更新的 southbound 数据库和更新的 nb_cfg。此过程反过来会更新 Chassis 的 Open vSwitch 实例中的物理流。当它收到 Open vSwitch 的确认时,物理流更新后,它会在 southbound 数据库中自己的机箱记录中更新 nb_cfg。
- ovn−northd 监视 southbound 数据库中所有 Chassis 记录中的 nb_cfg 列。它跟踪所有记录中的最小值,并将其复制到北行 NB_Global 的 hv_cfg 列中。
Chassis 设置
OVN 部署中的每个 Chassis 必须配置一个专用于 OVN 使用的 openvSwitch 网桥,称为集成网桥。系统启动脚本可能会在启动 ovn-controller 之前创建此网桥。如果 ovn-controller 启动时不存在此网桥,将使用下面建议的默认配置自动创建它。集成桥上的端口包括:
- 在任何 Chassis 上,OVN 用于维护逻辑网络连接的隧道端口。ovn−controller 添加、更新和删除这些隧道端口。
- openvswitch 本身存在的与 hypervisor 之间的集成工作。
- 在网关上,用于逻辑网络连接的物理端口。系统启动脚本在启动 ovn 之前将此端口添加到 ovn−controller。在更复杂的设置中,它可以是另一个网桥的 patch 端口,而不是物理端口。
逻辑网络
OVN 中的逻辑网络概念包括逻辑交换机和逻辑路由器,分别是以太网交换机和 IP 路由器的逻辑版本。就像物理实现一样,逻辑交换机和路由器可以连接到复杂的拓扑结构中。逻辑交换机和路由器通常是纯逻辑实体,也就是说,它们不关联或绑定到任何物理位置,并且在参与 OVN 的每个 Hypervisor 中以分布式方式实现。