OVS简介

Open vSwitch简称OVS,OVS是一个支持多层数据转发的高质量虚拟交换机,主要部署在服务器上,相比传统交换机具有很好的编程扩展性,同时具备传统交换机实现的网络隔离和数据转发功能,运行在每个实现虚拟化的物理机器上,并提供远程管理。OVS提供了两种在虚拟化环境中远程管理的协议:一个是OpenFlow,通过流表来管理交换机的行为,一个是OVSDB管理协议,用来暴露交换机的端口状态。其中OpenFlow协议可用于定于SDN网络,实现网络转发平面和控制平面分离。

一、OVS架构

![在这里插入图片描述](https://img-blog.csdnimg.cn/b720112bbce14d1eaf05f9666bf0bdcf.png
OVS主要包含三个基本组件:ovs-vswtichd、ovsdb-server、openvswitch.ko
OVS简介_第1张图片

1、ovs-vswitchd组件是交换机的主要模块,运行在用户态,其主要负责基本的转发逻辑、地址学习、外部物理端口绑定等。还可以运用OVS自带的ovs-ofctl工具采用openflow协议对交换机进行远程配置和管理。

2、ovsdb-server组件是存储OVS的网桥等配置、日志以及状态的轻量级数据库。它与ovs-vswitchd都是以一个单独的进程存在于系统中。ovsdb是一个可提供持久化存储的数据库,可借助ovs-vsctl工具配置OVS交换机,配置信息将保存在ovsdb中,设备重启后,相关OVS配置不会丢失。ovs-vswitchd组件与ovsdb-server组件间的通信采用OVSDB管理协议,通信内容包括加载配置信息,同时将运行过程中变化的OVS的配置信息保存到数据库中。

3、openvswitch.ko组件运行在内核态,属于快速转发平面,主要负责流表匹配、报文修改、隧道封装、转发或者上送,并且维护底层转发表。在原始OVS中,报文首先经过该组件完成报文解析和封装、转发规则匹配,若找到转发规则不再经过用户空间,直接转发。否则转交用户空间的ovs-vswitchd组件进行处理。ovs-vswitchd组件与openvswitch.ko组件之间采用netlink执行进程间的通信。netlink是一种进程间通信机制,可用于处理用户态和内核态的通信。

二、OVS功能

OVS是一种以软件形式存在于虚拟网络中的交换机,它与传统的网络部署中的物理交换机充当的角色相似,可进行划分局域网、搭建隧道、模拟路由。下图展示了OVS再虚拟网络中的应用,地址OVS0是中心交换机,主要负责边缘交换机间的数据通信。OVS1至OVS4是边缘交换机,直接与虚拟机相连,主要负责同主机的虚拟机间通信和跨主机的虚拟机间通信和跨主机的虚拟机间数据包转发。
OVS简介_第2张图片

1、划分局域网

边缘OVS通过划分VLAN,将同主机内的虚拟机加入到不同的VLAN,可实现同主机上的多台虚拟机间局域网隔离。对中心交换机的端口进行VLAN配置,使边缘OVS归属到不同的VLAN中,可阻碍边缘OVS间的二层通信,实现跨主机的虚拟机间局域网隔离。

2、搭建隧道

作为边缘设备的OVS可以参与隧道的搭建,例如GRE隧道和VXLAN隧道。隧道指报文采用某种特定协议进行传输的通道。例如VXLAN隧道,原始报文在经过上层报文封装后,到达VTEP节点再进行VXLAN协议封装,然后经过VXLAN隧道转发路径发出。VXLAN隧道中的VTEP节点可以有OVS实现,OVS能实现VTEP负责的VXLAN报文解析封装、转发、地址学习等功能。OVS的VXLAN隧道技术被广泛运用于云服务的多租户隔离中。

3、模拟路由

OVS在虚拟网络中还可以结合控制器的相关操作实现不同局域网网络拓扑下主机的数据转发,实现路由转发功能,上图的虚拟主机B和虚拟主机F所连接的边缘OVS属于不同的局域网,无法进行原始的二层转发。而可以通过将局域网中的ARP报文送到控制器让控制节点对Openflow网络中的网络节点进行感知,获取openflow中的网络设备信息,然后将相应的ARP流表下发到组网中的边缘OVS上,使得属于非同一局域网的主机可以互相通信。

三、OVS报文处理机制

1、传统OVS

在传统OVS中,网卡在加载网络过程中被绑定到OVS端口上,端口的数据包接送和发送函数在datapath中定义,因此报文的接收和发送统一由位于内核空间的datapath进行,内核空间负责报文的解析封装、流表匹配、流表匹配失败上送、报文转发或丢弃等报文处理操作。用户空间只在内核空间将报文上送用户空间时,对报文进行流表匹配操作,根据匹配结果通知内核datapath报文该如何处理,并下发匹配到的流表项至内核态流表,以备后续类似报文匹配。
OVS简介_第3张图片
传统OVS接收报文处理机制: 当报文到达网卡设备,网卡将接收到的报文交给该网卡绑定的端口在OVS中定义的数据包接收函数处理。在datapath中主要首先进行报文头信息的获取,根据报文头信息生成匹配流表项的key值,得到key值后进行内核态流表匹配。在OVS中有两个流表,一个为位于内核空间的内核态流表,另一个是位于用户空间的用户态流表。内核态流表主要是存储近期匹配过得流表项,用户态流表主要由控制器或人为通过OVS提供的ovs-ofctl工具下发。当数据包的key值在内核态流表中匹配到流表项,数据包将不经过用户空间,直接由内核进行action操作并将报文转发或丢弃。若未匹配到内核态流表项,将使用Linux系统的Netlink通信机制实现内核进程和用户进程的通信,把数据包上送到用户空间进行用户态流表匹配,若命中用户态流表项,则在用户空间中完成流表项中相应的action操作,最终获得数据包的出端口信息并告知内核将数据包转发出去,同时将命中到的用户态流表项以内核态流表的规则生成对应的内核态流表项下发至内核态流表。若未命中,则将数据包丢弃或者上送至控制器,由控制器决定如何转发该数据包。

传统OVS发送报文处理机制: OVS接收到数据包后对数据包的处理主要分为修改数据包后转发出去,向上层应用发送、丢弃三种情况。当需要将修改的数据包转发出去时,首先也是进行流表匹配,匹配过程与接收报文一致。通过命中的流表项获得要转发出去的端口号,最终将报文从OVS端口号绑定的网卡发送出去。

2、OVS+DPDK

DPDK平台提供的接口库,可以将底层环境资源做抽象,即在系统中新增了环境抽象层(EAL),将网卡驱动在用户态实现,系统只需在网卡初始化时设置网卡驱动接口即可将网卡收到的报文直接交给用户空间进程进行处理,网卡发送报文时也通过调用用户态定义的发送报文接口将报文直接发送到对应网卡。在OVS的vswitchd进程中新起一个数据收发接管线程(TO-Thread)用于接管系统的OVS中由datapath执行的数据包接收和发送的功能。数据包的流表匹配则直接进行用户态流表匹配。
OVS简介_第4张图片

OVS+DPDK接收报文处理机制: 当报文到达网卡,EAL层根据网卡初始化和驱动层初始化中绑定的用户态网卡驱动,将报文发送到用户空间交给TO-Thread线程进行接管,在该线程中将进行报文的解析、与内核协议栈通信和获取报文key值的操作,然后在vswitchd进程中凭借报文key值完成用户态流表匹配。用户态流表匹配的操作与传统的OVS一样,但若命中流表项本系统将直接交由TO-Thread线程进行action处理,最终将报文通过该接管线程转发出去或丢弃。接收报文的过程中不经过OVS中内核态的datapath进程的处理和内核态流表的匹配。

OVS+DPDK发送报文处理机制: 发送报文时,先经过协议栈的封装处理,将封装好的报文匹配用户态流表,获取action操作。若为隧道转发则还需进行隧道头封装,将报文发往对应的VTEP端口。在隧道转发过程中可能涉及OVS中内部端口多次转发,并在相应端口做报文处理,报文最终要发出的端口通过流表匹配获得。TO-Thread线程将报文直接发往OVS出端口绑定的网卡,由网卡发送到网络中。

3、OVS数据路径

Open vSwitch 在不同的平台支持不同的数据路径。不同的数据路径支持不同的功能集合。

目前支持4种数据路径:

Linux upstream:通过上游Linux 内核自带的内核模块实现的datapath。由于openvswitch功能已经引入内核,可以根据不同发行版Linux 的内核版本查看支持的功能。

Linux OVS tree:通过OVS源代码生成的内核模块实现的。

Userspace: 也称为DPDK,dpif-netdev 或者dummy datapath。这是NetBSD,FreeBSD 和Mac OSX 仅支持的数据路径。

Hyper-V: Windows 平台的数据路径。

下面是不同的数据路径可以实现的功能:
OVS简介_第5张图片

四、OpenFlow技术

OpenFlow的核心思想是将传统网络设备的转发动作进行分解,原来一步完成的动作现由OpenFlow虚拟交换机和控制器协作完成,从而将网络设备转发过程中的数据平面和控制平面分离以实现网络处理层次的扁平化。在这种分离架构中,研究人员可以通过高层的控制平面灵活、高效地定制个性化的转发策略或测试新的网络协议等,从而在现有网络结构的基础上实现和部署新型网络架构。

在OpenFlow虚拟网络中,通常包括两类最重要的组件:OpenFlow虚拟交换机和控制器。虚拟交换机通过其维护的流表(Flow Table)决定数据包如何转发,流表定义了许多包括一系列匹配字段(如数据包入口、IP地址、协议类型、链路层地址、端口号等)、计数器机动作(如转发、丢弃、修改包头域等)的流表项(Flow entry),在转发时虚拟交换机将抽取数据包信息并与流表项中的字段进行匹配,一旦匹配成功就执行相应的动作。虚拟交换机只负责根据流表指示转发数据却不关心流表如何制定,实际上流表由控制器制定并下发给虚拟交换机,并且控制器可以随时经网络以OpenFlow定义的形式维护虚拟交换机中的流表,OpenFlow就是通过这种方式实现数据平面与控制平面分离的。

1、流表结构

流表在OVS中充当传统物理交换机的MAC表和路由表的角色,数据包在交换机内部端口间的转发规则由流表中的流表项决定。OVS中的流表由多个流表项组成,流表项结构如图:
在这里插入图片描述

OpenFlow 1.0 匹配域

在这里插入图片描述

其中匹配域是流表匹配的关键字段,主要包括入端口号和报文各层头字段信息。匹配域和优先级唯一指定一条流表项,由于匹配字段包含了链路层、网络层和传输层的大部分标识,会存在一个数据包可与多个流表项中的匹配字段相匹配,优先级则在存在冲突时用于标识流表项的执行顺序。计数器用于统计数据量的相关信息,例如匹配成功的报文数和丢弃的报文数等。指令集表示当数据包匹配到该流表项时,需要执行的动作。超时时间用于设定流表项的超时时间,当流表项到达超时时间将被系统删除。

2、OpenFlow多级流表

在OpenFlow 1.0版本中流表的匹配域有十二元组,使得匹配域的宽度已经达到了252位,比Ipv4 RIB TCAM的匹配字段长度增加了3倍左右。在OpenFlow 1.1版本里流表的匹配域已经达到了356位,而且不同匹配域的组合使得OpenFlow流表的流表项爆炸式的增长,这将使得TCAM的存储成本大大的增加,怎么解决流表的开销是OpenFlow面临的一个比较重要的问题。

为了减少流表的开销,从OpenFlow 1.1版本开始设计了多级流表,每个OpenFlow交换机中由一个或多个流表组成。流表的匹配过程因为多级流表被分解了多个步骤,以流水线的方式进行匹配处理,由于将数据包的匹配过程分解到了不同的流表中,每个表匹配不同的匹配域,从而避免了单流表过度膨胀的问题。

多级流表查询采用流水线型多级流表匹配的模式进行,流水线包含多级流表,每个流表由多个流表项组成,流水线处理只能从表号低向表号高的进行,避免环路。流表工作流程:
OVS简介_第6张图片

数据包到达OVS,根据入端口数据包头字段信息按照流表编号顺序由低到高与流表中流表项进行匹配,找出匹配流表项中优先级最高的一项,执行流表项中的指令。若流表项中的指令是指向其他流表,则继续匹配下一个流表中的流表项。否则终止流水线处理,数据包根据动作集进行处理或转发。若数据包未能匹配到流表中的流表项,则系统将该情况认为是table-miss,table-miss表项依据流表配置指出如何处理无匹配项的数据包,例如传递到其他流表、丢弃或上送控制器。

通过这样一个多级流表匹配的过程,形成流水线处理,流表的处理效率可以被提升,同时由于分成了多个流表,使得每个流表的流表项的数目减少,且每个流表的匹配域宽带减少,进而减少了流表的开销。但是由于是一级一级的流水线匹配,这就增加了Openflow交换机的流表匹配的延时,而且也增加了维护这个多级流表查找的复杂度。

五、VXLAN技术

当前主流的网络隔离技术是VLAN虚拟局域网隔离技术,VLAN技术主要用于将二层网络划分成不同的广播域。在IEEE 802.1Q协议中定义的VLAN Tag域只有12个比特,使得网络中最多只能划分4096个虚拟局域网,已不能满足大规模租户隔离需求。由此新起了VXLAN网络技术,它通过将L2层的以太网帧封装在L4层的UDP报文中,并使用物理网络设备IP和设备MAC地址作为外层头封装,然后再将封装好的报文发送到网络中,网络只需感知封装后的二层参数,即不需要了解物理设备中虚拟机的IP和MAC地址,这很大程度降低了大二层网络对MAC地址规格的需求,解决了虚拟机数量受网络规格的限制问题。VXLAN协议中引入了VXLAN标识VNI,由24比特组成,相比VLAN标识的范围多了2^12倍,可划分的网络区域量更加庞大,也降低了网络隔离能力的限制。

1、VXLAN报文格式

VXLAN报文实际上是进行了二次封装的UDP报文,在原始以太帧上增添了VXLAN报文头后,再进行UDP报文封装。
OVS简介_第7张图片

VXLAN封装包括VXLAN header、Outer UDP header、Outer IP header、Outer Ethernet header四个部分的封装。

VXLAN header包括Flags、24bits保留字段、VNI字段、8bit保留字段。Flags是占8bits的标识位,取值固定为00001000。VNI字段是用于标识VXLAN段。两个Reserved字段是保留字段,规定设置为0。

Outer UDP header由4个字段组成,源端口由发送设备的VTEP提供,目的端口为用户自定义的VXLAN端口号,一般默认使用4789号端口。Checksum校验字段固定为全0。

Outer IP header中的Protocol协议字段用于标识上层所使用的协议类型。VXLAN外层封装中第四层的协议类型是UDP,因此该字段固定值为0x11。源IP字段由发送端的VTEP提供,是发送端的隧道IP。目的IP字段填接收端的隧道IP。

Outer Ethernet header为二层以太头,其中源MAC地址字段值为发送端虚拟机所属的VTEP的MAC地址,目的MAC地址字段值为接收端虚拟机所属VTEP上路由表中直连的下一跳MAC地址。VLANType字段为可选字段,当封装后的报文携带VLAN Tag时,该字段取值为0x8100,同时VLAN ID字段标识报文所带的VLAN值。Ethernet Type字段用于标识以太报文类型,值设置为0x0800,表示数据包为IPv4报文。

VXLAN报文先由发送端将原始报文封装成包含了VXLAN报文头的UDP报文,经过隧道传输到接收端VXLAN口,接收端再进行解封装获取原始报文,报文传输过程结束。

2、VXLAN隧道创建

VXLAN组网中需要进行VXLAN隧道创建,然后通过下发流表让报文经过指定端口转发,在不同端口对报文进行相应处理。VXLAN隧道中关键是VTEP(VXLAN隧道终端)的实现,本文设计的虚拟交换机在VXLAN组网中充当VTEP角色,虚拟机发送的报文都将经过OVS设备转发,OVS设备负责对报文进行识别,以及VXLAN隧道头封装和解封装。以OVS作为VTEP角色的隧道实现如下:
OVS简介_第8张图片

在两台服务器上的OVS中各创建一个网桥,并给网桥配置隧道IP。在网桥中创建虚拟机虚端口、VXLAN口和DPDK口。其中虚拟机虚端口绑定虚拟机创建过程中生成的虚端口,DPDK口绑定支持DPDK组件的网卡设备。网桥中的internal口试网桥创建时生成的网桥内部口,VXLAN转发机制中不使用该端口进行转发。网桥中端口作用如下:

vnet:接收虚拟机发来的原始报文,或者将OVS接收到的报文转发给虚拟机。

vxlan:实现报文VXLAN封装和解封装。

dpdk:从网卡设备接收报文或将报文发往网卡设备。

除了网桥和端口创建外,虚拟交换机系统中用一张vtep-ip映射表记录MAC地址、隧道VNI和隧道IP的对应关系。vtep-ip表中的表项通过对报文解析学习获得。vtep-ip映射表表项结构如下图:
在这里插入图片描述

当虚拟机发送原始报文到OVS的vnet端口时,根据流表匹配将报文发送到VXLAN端口,在VXLAN端口下,查看vtep-ip映射表,判断报文源MAC地址和目的MAC地址对应的VNI值是否相同,若不相同则表示发送端虚拟机和接收端虚拟机不在一个隧道里,VXLAN二层转发结束。若VNI值相同,则根据表项的VTEP IP值将报文进行VXLAN封装,然后发往隧道。

3、报文转发机制

OVS虚拟交换机创建的网桥中所添加的各端口对报文有相应的处理,报文发送和接收过程中需要按照特定规则在网桥各端口间进行转发。报文在端口间的报文流向如下:

OVS简介_第9张图片当虚拟机发送原始报文到OVS的vnet端口时,根据流表匹配将报文发送到VXLAN端口,在VXLAN端口下,查看vtep-ip映射表,判断报文源MAC地址和目的MAC地址对应的VNI值是否相同,若不相同则表示发送端虚拟机和接收端虚拟机不在一个隧道里,VXLAN二层转发结束。若VNI值相同,则根据表项的VTEP IP值将报文进行VXLAN封装,然后发往隧道。

接收隧道报文: 报文首先到达dpdk绑定的网卡设备,由dpdk网卡驱动将网卡中的报文接收,报文到达网桥中的dpdk口,然后通过流表匹配,将报文转发到vxlan口,在vxlan口完成隧道头解析,根据解析的报文隧道ID(VNI字段值)进行流表项匹配,若能命中隧道ID为接收端VNI的流表项,则将报文外层头剥掉,获得原始二层以太帧并转发给vnet口。在vxlan口处理隧道报文过程中,将根据报文内层源MAC、VNI、外层源IP字段,获得对端虚拟机所属的VNI域和隧道IP,完成vtep-ip映射表学习过程。

发送隧道报文: 虚拟机向隧道中发送报文,原始报文首先到达vnet口,通过流表匹配,将报文转发到vxlan口。报文到达VXLAN口,首先通过查询vtep-ip映射表,判断目的虚拟机所属的VNI域是否与发送端的VNI域相同,若相同则将报文进行隧道封装(否则终止VXLAN二层转发),将封装好的报文进行流表匹配,根据匹配结果转报文至DPDK口,由DPDK口把报文交给所绑定的网卡,最后由网卡发送到隧道中去。

原文链接:OVS技术介绍(四十一)_bob62856的博客-CSDN博客_ovs

你可能感兴趣的:(OVS,信息与通信)