1、SDN（软件定义网络）

（1）基本概念

SDN是一种数据控制分离、软件可编程的新型网络架构，采用了集中（逻辑集中）式的控制平面和分布式的转发平面，两个平面相互分离，

控制平面利用控制转发通信接口对转发平面上的网络设备进行集中式控制，并提供灵活的可编程能力，也就是说SDN架构分为三层：业务层、控制层、转发层。

 

而在传统网络中数据平面和控制平面没有分离，他们虽然在逻辑上相互独立，运行于独立的处理器或板卡，但是物理层面上紧耦合。

在同一个网络设备中，设备的转发行为基于控制协议生成的转发表；比如：二层交换机基于MAC地址表进行转发；而各种转发表是由设备的控制平面，基于不同的策略生成的；

（2）从路由器理解控制层面和数据层面分离

路由器要实现2个功能：

1、为主机间的通信提供转发服务

2、路由选择

传统路由器内部结构也分为路由选择和数据转发部分；

     路由选择：路由器利用路由算法得出路由表，再根据路由表得出转发表；在控制层面中，每一个路由器无法独自创建出自己的路由表，路由器需要和周边的路由器周期地交换路由信息，才能创建出自己的路由表；根据路由选择协议所使用的路由算法计算路由；

     数据转发：数据层面中每一个路由器基于自己生成的转发表，来转发分组；

在sdn中路由器的路由软件都不存在了，路由器之间不需要交换路由信息，在控制层面中，有一个逻辑上集中的远程控制器；可由物理上不同地点的多个服务器组成；

远程控制器可以掌握各主机和整个网络的状态，能够为每一个分组计算出最佳的路由，能够为每个路由器生成其正确的转发表；

（3）sdn架构

应用层：这一层主要是体现用户意图的各种上层应用程序，此类应用程序称为协同层应用程序，典型的应用包括OSS（Operation support system 运营支撑系统）、Openstack等。

控制层：控制层是系统的控制中心，负责网络的内部交换路径和边界业务路由的生成，并负责处理网络状态变化事件；

转发层：转发层主要由转发器和连接器的线路构成基础转发网络，这一层负责执行用户数据的转发，转发过程中所需要的转发表项是由控制层生成的。

北向接口：应用层和控制层通信的接口，应用层通过控制开放的API，控制设备转发功能；

南向接口：控制层和数据层通信的接口，SDN控制器通过OpenFlow或其他协议下发流表。

那么现在可以理解kubeovn、ovn和ovs的关系

可以将kubeovn比作是sdn体系中的应用层，ovn是sdn的控制器，而ovs虚拟化中网络设备

2、ovn

（1）ovn架构

从图表的最上面开始，主要有：

OVN/CMS（ Cloud management system） 插件：插件是用作OVN接口的CMS组件。在OpenStack中，就是一个Neutron插件。插件的主要目的就是将CMS的逻辑网络配置概念，以CMS可识别的特定格式存储在CMS的配置数据库中，转换为OVN可以理解的中间格式。

OVN北向数据库（Northbound Database）：接收OVN/CMS插件传递的逻辑网络配置的中间表示。OVN北向数据库有两个客户端：它上面的OVN/CMS插件还有它下面的ovn-northd；

ovn-northd: 它上连OVN北向数据库，下连OVN南向数据库。它将从北向数据库中获得的传统网络概念中的逻辑网络配置，转换为它下面的南向数据库所能理解的逻辑数据路径流（logical datapath flow）。

OVN南向数据库（Southbound Database）：这是本系统的中心。它的客户端(client)包括其上的ovn-northd，以及其下每个传输节点上的ovn-controller。

        OVN南向数据库包含三种数据

        物理网络(Physical Network (PN))表：指明如何访问hypervisor和其他节点

        逻辑网络(Logical Network (LN))表：用逻辑数据路径流（logical datapath flows）来描述逻辑网络，绑定表：将逻辑网络组件的位置链接到物理网络

     OVN南向数据库的性能必须随着传输节点的变化而变化。

ovn-controller ：是每个hypervisor和软件网关上的agent。

                            北向而言，它连接到南向数据库来获取OVN的配置及状态，并用hypervisor的状态填充绑定表中的PN表和Chassis列。

                            南向而言，它作为OpenFlow controller连接到 ovs-vswitchd 来控制网络流量 ，并连接到本地ovsdb-server来监控和控制Open vSwitch的配置。

ovs-vswitchd 和 ovsdb-server：Open vSwitch的传统组件。

（2）ovn北向数据库表

         Logical_Switch：每一行代表一个逻辑交换机

        Logical_Switch_Port：每一行代表一个逻辑端口

        ACL：每一行代表一个应用到逻辑交换机上的 ACL 规则

        Logical_Router：每一行代表一个逻辑路由器

        Logical_Router_Port：每一行代表一个逻辑路由器端口 

       NAT：每行数据表示一行NAT表项，仅在集中式路由器生效

（3）ovn南向数据库表

   Chassis：每一行表示一个 HV 或者 VTEP 网关，每个ovn-controller启动的时候，会将ovs的物理网络的信息写入到这里；

   Encap：保存着 tunnel 的类型和 tunnel endpoint IP 地址

   Logical_Flow：每一行表示一个逻辑的流表

   Multicast_Group：每一行代表一个组播组

   Datapath_Binding：每一行代表一个 datapath 和物理网络的绑定关系

   Port_Binding：这张表主要用来确定 logical port 位于哪个 chassis 上面数据库表：

（4）ovn里的逻辑概念

逻辑交换机（Logical switch）：以太网交换机的逻辑版本
逻辑路由器（Logical router）：IP路由器的逻辑版本。逻辑交换机及路由器都可以接入复杂的拓扑里。
逻辑数据通路（Logical datapath）：逻辑版本的OpenFlow交换机。逻辑交换机及路由器都以逻辑数据通路形式实现。
逻辑端口（Logical port）：代表了逻辑交换机和逻辑路由器之间的连接点。一些常见类型的逻辑端口有：
       逻辑端口（Logical port）:代表VIF。
       本地网络端口（Localnet port）：代表逻辑交换机与物理网络之间的连接点，他们实现为OVS补丁端口（OVS patch port），架设在集成网桥和单独的Open vSwitch网桥之间，从而作为底层网络连接的端口。
       逻辑补丁端口（Logical patch port）：代表了逻辑交换机和逻辑路由器之间的连接点，有时候还可作为对等逻辑路由器（peer logical router）连接点。每个这样的连接点都有一对逻辑补丁端口，每侧一个。
       本地端口端口（Localport port）：代表了逻辑路由器和VIF之间的本地连接点。这些端口存在于每个机箱中（未绑定到任何特定的机箱），来自它们的流量永远不会通过隧道（tunnel）。本地端口一般来说只生成目标指向本地目的地的通信，通常是对其接收到请求的响应。其中一个用例便是：OpenStack Neutron如何使用Localport端口为每个hyperviso上的VM提供元数据（metadata）服务。元数据代理进程连接到每个主机（host）上的此端口，同一个网络中的所有VM都将通过相同的IP/MAC地址来访问它，所有流量都不通过隧道发送。

3、ovs

（1）ovs和linux bridge的区别

Open vSwitch（下文简称 OvS）就是一个开源的虚拟交换机实现不光支持基本的二层交换，还支持标准的管理机接口和协议（e.g. NetFlow,sFlow,SPAN,RSAPN,CLI,LACP,802.1ag），可以很好的与 SDN 体系融合。

Linux bridge也是一个交换机，具有交换机处理数据包的能力

Ovs与linux bridge相比，具有的优点：

• 网络管理更轻松——通过Open vSwitch，管理员可以方便地管理和监控云环境中的网络状态和数据流。
• 支持更多隧道协议——OVS 支持 GRE、VXLAN、IPsec 等。但是，Linux Bridge 仅支持 GRE 隧道。
• 并入 SDN – Open vSwitch 被并入软件定义网络 (SDN)，它可以通过使用 OpenStack 插件或直接从 SDN 控制器（如 OpenDaylight）驱动。

尽管有这些优势，Open vSwitch 也面临一些挑战：

• 1、缺乏稳定性——Open vSwitch 存在一些稳定性问题，例如 Kernetl 恐慌、ovs-switched segfaults 和数据损坏。
• 2、复杂的操作——Open vSwitch 本身就是一个复杂的解决方案，它拥有如此多的功能。它很难学习、安装和操作；

Linux Bridge 仍然很受欢迎，主要有以下几个原因：

• 稳定可靠——Linux Bridge 已经使用多年，其稳定性和可靠性得到认可。
• 易于安装——Linux Bridge 是标准 Linux 安装的一部分，无需安装或学习其他软件包。
• 故障排除方便——Linux Bridge 本身就是一个简单的解决方案，其操作比 Open vSwitch 更简单。便于故障排除。

但是，有一些限制：

• 功能更少——Linux Bridge 不支持一些可扩展的 VXLAN 模型以及其他一些功能。
• 更少的支持者——许多企业希望确保有一个开放的模型将他们的服务集成到 OpenStack 中。但是 Linux Bridge 无法保证需求，所以它的用户比 Open vSwitch 少。

 

（2）ovs架构

整体架构

详细架构：

目前了解来看，Open vSwitch有三个比较核心的东西：
用户空间：

• 1. ovs-vswitchd：一个实现交换机的守护进程。
• 2. ovsdb-server：一个轻量级的数据库服务器，用于ovs-vswitchd查询以获取其配置。
  ovsdb-server将ovs-vswitchd的配置持久化到db中，ovs-vswitchd是一个守护进程，它会向ovsdb-server读取相关配置信息，并且如果有配置需要更新也会将其同步到ovsdb-server中。ovsdb通常是一个文件保存在linux的存储系统里面，一般它的路径是/etc/openvswitch/conf.db

内核空间：

• openvswitch.ko：一个配套的基于流来实现交换的Linux内核模块。
• datapath: 网桥或交换机的实体，在OVS中datapath负责执行数据交换，也就是把从接收端口收到的数据包在流表中进行匹配，并执行匹配到的动作。
• Flow table: 每个datapath都和一个flow table关联，当datapath接收到数据之后，OVS会在flow table中查找可以匹配的 flow，执行对应的操作， 例如转发数据到另外的端口。一个flow table包含多个条目，每个条目包括两个内容：一个match/key和一个action

（3）ovs数据流向

普通数据流向和存在ovs的数据流向：

一般的数据包在 Linux 网络协议中的流向为上图中的蓝色箭头流向：网卡eth0 收到数据包后判断报文走向，如果是本地报文把数据传送到用户态，如果是转发报文根据选路（二层交换或三层路由）把报文送到另一个网卡如eth1。

当有 OVS 时，数据流向如红色所示：从网卡 eth0 收到报文后进入ovs 的端口，根据 key 值进行流表匹配，如果匹配成功执行流表对应的 action；如果失败通过upcall 送入用户态处理。

① kernel datapath从网卡中读取数据包。
② 数据包进入到OVS后的匹配分为Fast Path（快速通道）和Slow Path（慢通道）。快速通道是指数据包由datapath模块直接处理，匹配内核态缓存流表项，匹配成功直接转发；若匹配失败，datapath将数据包upcall到ovs-switchd模块，ovs-switchd模块处理之后通过netlink将数据包交给datapath转发，这个过程为慢通道。
③ ovs-switchd接收到数据包，会去匹配用户态流表，若匹配不成功，根据OpenFlow协议规范处理，如把数据包上报给控制器或者丢弃。
④ 如果控制器处理成功，则下发Flow_mod报文，OVS将对应Flow_mod报文中的流表写入到用户态的流表中，用于后续的匹配。
⑤-⑥ 数据包匹配用户态流表，成功则交由datapath转发