2019-06-15-服务器内部虚拟接入技术

在《网络虚拟化概述》一文中,我们提到了数据中心内部网络虚化技术是一种端到端的解决方案,在不同的网络层面其具体实现的技术各不相同。按照分层的架构,主要分为服务器内部的I/O虚拟化,服务器内部虚拟接入实现、服务器与外部的网络连接虚拟化和外部交换网络的虚拟化4部分。其中,服务器内部的I/O虚拟化技术可以参见本站《计算虚拟化之I/O虚拟化》一文,本文主要阐述服务器内部的虚拟接入技术。

虚拟交换机概述

如下图所示,服务器内部虚拟网络的划分是以物理网卡为界,物理网卡往上为虚拟资源,物理网卡及其往下为物理资源。服务器内部的虚拟接入技术分为虚拟机网卡、虚拟交换端口和端口组、上行链路和虚拟交换机四部分。

其中,虚拟网卡就是用虚拟机中用软件模拟网络环境,提供类似真实网卡的功能,无需连接。虚拟交换端口是虚拟交换机上的端口,用来连接虚拟网卡,为虚拟机提供接入网络的服务。端口组是为了方便管理,将具有同样属性的一组虚拟交换端口称为端口组。通常情况下,一个端口组就是一个VLAN。在同一个物理服务器内部,相同端口组的虚拟机之间通信无需进过物理网络,但是不同端口组的虚拟机通信必须经过物理网络。上行链路是虚拟交换机与主机物理网卡之间之间虚拟链路,通过上行链路虚拟交换机与主机的物理网络适配器相连,使得主机中的虚拟机能够与另一主机中的虚拟机或外部网络进行通信。虚拟交换机原理与物理交换机一样,构建起虚拟机之间的网络,并提供虚拟机与外部网络互通的能力。

虚拟交换机属于二层设备,在虚拟化网络中起到承上启下的作用。虚拟交换机的交换端口连接虚拟机网卡,上行链路与物理网卡绑定,从而打通虚拟网络和物理网络;物理网卡与物理交换机相连,使虚拟机发出的数据能够转发到物理网络中。同一主机内相同端口组的虚拟机通过虚拟交换机就能通信,不需要通过物理交换机;不同主机相同端口组的虚拟机需要通过物理交换机才能互相通信。

虚拟交换机按照实现的范围分为标准虚拟交换机分布式虚拟交换机两种,标准虚拟交换机不支持跨物理服务器,只能为同一主机内部的虚拟机之间提供二层交换功能。比如:VMware Workstations的主机网络适配器、Virtual Box的内部网络适配器、Hyper-V的内部网路适配器、VMware vSphere中的标准虚拟交换机都是这类虚拟交换机。分布式交换机支持跨物理服务器提供二层交换的功能,一台分布式虚拟交换机可以分布在多台物理服务器上。比如:华为FusionSphere中的虚拟交换机(上图所示),VMware vSphere中的分布式虚拟交换机、开源的OVS交换机、Linux原生的Linux Bridge等都是这种分布式交换机。

虚拟交换机按照I/O虚拟化的方式可以分为三种类型:普通、VMDqSR-IOV。如下图所示:

普通模式。基于CPU实现的虚拟交换,天生会消耗一部分CPU资源。在服务器的CPU中实现完整的虚拟交换的功能,虚拟机的虚拟网卡对应虚拟交换的一个虚拟端口,服务器的物理网卡作为虚拟交换的上行链路接入物理TOR交换机。虚拟机的报文收发流程如下:虚拟交换机首先从虚拟端口/物理端口接收以太网报文,之后根据虚拟机MAC、VLAN,查找二层转发表,找到对应的虚拟端口/物理端口,然后按照具体的端口,转发报文。采用普通模式的虚拟交换机,同一服务器上的虚拟机间报文由虚拟交换机实现实现虚拟机之间报文的二层软件转发, 报文不出服务器,转发路径短,性能高。但是,跨服务器通信时,需要经物理交换机进行转发,相比物理交换机实现虚拟交换,虚拟交换模块的消耗,性能稍低于物理交换机。与物理交换机相比,由于采用纯软件实现虚拟交换,相比采用L3芯片的物理交换机,功能扩展灵活、快速,可以更好的满足云计算的网络需求扩展。同时,由于服务器内存大,相比物理交换机,在L2交换容量、ACL容量等,远大于物理交换机。

VMDq模式。相比普通模式,交换、安全、QoS等功能从服务器CPU上卸载至网卡上,CPU开销较少。采用零拷贝、VLAN、Bonding等关键技术使得虚拟机网络报文通过缓冲区到达物理网卡,并支持物理网卡的绑定操作,同时支持基于队列的VLAN和二层广播域的隔离。在ACL方面支持基于五元组的包过滤,支持状态规则,完全兼容当前的安全组功能。且ACL规则表基于队列,不受其它队列规则数的干扰。在QoS方面还支持带宽限制,可以预留最小带宽,动态调整带宽比例以及带宽优先级。VMDq采用网桥交换技术,在硬件层面完成MAC和VLAN的交换功能。最重要一点,相比SR-IOV,VMDq的支持虚拟机热迁移,华为的iNIC网卡就采用了这种技术。

SR-IOV模式。设计思想是将虚拟交换功能从服务器的CPU移植到服务器物理网卡,通过网卡硬件改善虚拟交换机占用CPU资源而影响虚拟机性能的问题,同时借助物理网卡的直通的能力,加速虚拟交换的性能。传统的SR-IOV商业网卡,可以支持简单的虚拟交换的功能,高级特性较少,并且由于自身设计以及缺乏与Hypervisor的配合存在一些缺陷,如热迁移等。

Linux原生网络设备虚拟化

TAP/TUN是Linux内核实现的一对虚拟网络设备,TAP工作在二层,TUN工作在三层。Linux内核通过TAP/TUN设备向绑定该设备的用户空间程序发送数据,反之,用户空间程序也可以像操作物理网络设备那样,向TAP/TUN设备发送数据。

基于TAP驱动,即可实现虚拟机vNIC的功能,虚拟机的每个vNIC都与一个TAP设备相连,vNIC之于TAP就如同NIC之于eth。当一个TAP设备被创建时,在Linux设备文件目录下会生成一个对应的字符设备文件,用户程序可以像打开一个普通文件一样对这个文件进行读写。比如,当对这个TAP文件执行 write操作时,相当于TAP设备收到了数据,并请求内核接受它,内核收到数据后将根据网络配置进行后续处理,处理过程类似于普通物理网卡从外界收到数据。当用户程序执行read请求时,相当于向内核查询TAP设备是否有数据要发送,有的话则发送,从而完成TAP设备的数据发送。

TUN则属于网络中三层的概念,数据收发过程和TAP是类似的,只不过它要指定一段IPv4地址或IPv6 地址,并描述其相关的配置信息,其数据处理过程也是类似于普通物理网卡收到三层 IP 报文数据。

VETH设备总是成对出现,一端连着内核协议栈,另一端连着另一个设备,一个设备收到内核发送的数据后,会发送到另一个设备上去,这种设备通常用于容器中两个namespace之间的通信。

Linux Bridge详解

Bridge也是 Linux内核实现的一个工作在二层的虚拟网络设备,但不同于TAP/TUN这种单端口的设备,Bridge实现为多端口,本质上是一个虚拟交换机,具备和物理交换机类似的功能。

Bridge可以绑定其他Linux网络设备作为从设备,并将这些从设备虚拟化为端口,当一个从设备被绑定到Bridge上时,就相当于真实网络中的交换机端口上插入了一根连有终端的网线。如下图所示,Bridge 设备br0绑定了实际设备eth0和虚拟设备设备tap0/tap1,当这些从设备接收到数据时,会发送给br0 ,br0会根据MAC地址与端口的映射关系进行转发。

Linux下的Bridge和vlan有点相似,它依赖于一个或多个从设备。与VLAN不同的是,它不是虚拟出和从设备同一层次的镜像设备,而是虚拟出一个高一层次的设备,并把从设备虚拟化为端口port,且同时处理各个从设备的数据收发及转发 。

Linux Bridge的功能主要在内核里实现。当一个从设备被attach到Linux Bridge上时,这时在内核程序里,netdev_rx_handler_register()被调用,一个用于接受数据的回调函数被注册。以后每当这个从设备收到数据时都会调用这个函数把数据转发到Linux Bridge上。当Linux Bridge接收到此数据时br_handle_frame()被调用,进行一个和现实世界中的交换机类似的处理过程:判断包的类别(广播/单点),查找内部MAC端口映射表,定位目标端口号,将数据转发到目标端口或丢弃,自动更新内部MAC端口映射表以自我学习。

Linux Bridge和现实世界中的二层交换机有一个区别:数据被直接发到Linux Bridge上,而不是从一个端口接受。这种情况可以看做Linux Bridge自己有一个MAC可以主动发送报文,或者说Linux Bridge自带了一个隐藏端口和宿主Linux系统自动连接,Linux上的程序可以直接从这个端口向Linux Bridge上的其他端口发数据。所以,当一个Linux Bridge拥有一个网络设备时,如bridge0加入了eth0时,实际上bridge0拥有两个有效MAC地址,一个是bridge0的,一个是eth0的,他们之间可以通讯。

通过上面的描述,也就解释了Linux Bridge为什么可以设置IP地址。通常来说IP地址是三层协议的内容,不应该出现在二层设备上。但是Linux里Bridge是通用网络设备抽象的一种,只要是网络设备就能够设定IP地址。当一个bridge0拥有IP后,Linux便可以通过路由表或者IP表规则在三层定位bridge0,此时相当于Linux拥有了另外一个隐藏的虚拟网卡和Linux Bridge的隐藏端口相连,这个网卡就是名为 virbr0的通用网络设备,如下图所示,IP可以看成是这个网卡的。

当有符合此IP的数据到达时,内核协议栈认为收到了一个目标地址为本机的数据包,此时应用程序可以通过Socket接收到它。其实,在实际中3层交换机设备,它也拥有一个隐藏的MAC地址,供设备中的三层协议处理程序和管理程序使用。设备里的三层协议处理程序,对应名为 bridge0 的通用网络设备的三层协议处理程序,即宿主Linux系统内核协议栈程序。设备里的管理程序,对应bridge0宿主Linux系统里的应用程序。

对于一个被attach到Linux Bridge上的设备来说,只有它收到数据时,此数据包才会被转发到Linux Bridge上,进而完成查表广播等后续操作。当请求是发送类型时,数据是不会被转发到Linux Bridge 上的,它会寻找下一个发送出口。我们在配置网络时经常忽略这一点从而造成网络故障。

Bridge的实现当前有一个限制:当一个设备被attach到Bridge上时,那个设备的IP会变的无效,Linux不再使用那个IP在三层接受数据。比如:如果eth0本来的IP是192.168.1.2,此时收到一个目标地址是192.168.1.2的数据,Linux的应用程序能通过Socke 操作接受到它。而当eth0被attach到一个br0 时,尽管eth0的IP还在,但应用程序是无法接受到上述数据的。此时应该把192.168.1.2赋予 br0。

借助Linux Bridge功能,同主机或跨主机的虚拟机之间能够轻松实现通信,也能够让虚拟机访问到外网,这就是我们所熟知的桥接模式,一般在装VMware虚拟机或者VirtualBox虚拟机的时候,都会提示我们要选择哪种模式,常用的两种模式是桥接和NAT。

Bridge本身是支持VLAN功能的,如下图所示,通过配置,Bridge可以将一个物理网卡设备eth0划分成两个子设备eth0.10,eth0.20,分别挂到Bridge虚拟出的两个VLAN上,VLAN id分别为VLAN 10和VLAN 20。同样,两个VM的虚拟网卡设备vnet0和vnet 1也分别挂到相应的VLAN 上。这样配好的最终效果就是VM1不能和VM2通信,达到了隔离。

OVS详解

既然Linux原生的Bridge就能实现二层虚拟交换功能,为什么还有很多厂商都在做自己的虚拟交换机,比如比较流行的有 VMware virtual switch、Cisco Nexus 1000V以及 Open vSwitch。究其原因,主要有以下几点:

1)方便网络管理与监控。OVS的引入,可以方便管理员对整套云环境中的网络状态和数据流量进行监控,比如可以分析网络中流淌的数据包是来自哪个VM、哪个OS及哪个用户,这些都可以借助OVS 提供的工具来达到。

2)加速数据包的寻路与转发。相比Bridge单纯的基于MAC地址学习的转发规则,OVS引入流缓存的机制,可以加快数据包的转发效率。

3)基于 SDN 控制面与数据面分离的思想。上面两点其实都跟这一点有关,OVS控制面负责流表的学习与下发,具体的转发动作则有数据面来完成,可扩展性强。

4)隧道协议支持。Bridge只支持VxLAN,OVS支持gre/vxlan/IPsec等。

5)适用于 Xen、KVM、VirtualBox、VMware 等多种 Hypervisors。

Open vSwitch(OVS)是一个开源的虚拟交换机,遵循Apache2.0许可,其定位是要做一个产品级质量的多层虚拟交换机,通过支持可编程扩展来实现大规模的网络自动化。它的设计目标是方便管理和配置虚拟机网络,能够主动检测多物理主机在动态虚拟环境中的流量情况。针对这一目标,OVS具备很强的灵活性,可以在管理程序中作为软件交换机运行,也可以直接部署到硬件设备上作为控制层。此外,OVS还支持多种标准的管理接口,如NetFlow、sFlow、IPFIX、RSPAN、CLI、LACP、802.1ag。

对于其他的虚拟交换机设备,如VMware的vNetwork分布式交换机、思科Nexus 1000V虚拟交换机等,它也提供了较好的支持。由于OVS提供了对OpenFlow协议的支持,它还能够与众多开源的虚拟化平台(如KVM、Xen)相整合。在现有的虚拟交换机中,OVS作为主流的开源方案,发展速度很快,它在很多的场景下都可灵活部署,因此也被很多SDN/NFV方案广泛支持。

OVS在实现中分为用户空间内核空间两个部分。用户空间拥有多个组件,它们主要负责实现数据交换和OpenFlow流表功能,还有一些工具用于虚拟交换机管理、数据库搭建以及和内核组件的交互。内核组件主要负责流表查找的快速通道。

其中,OVS最重要的组件是ovs-vswitchd,它实现了OpenFlow交换机的核心功能,并且通过Netlink协议直接和OVS的内核模块进行通信。用户通过ovs-ofctl可以使用OpenFlow协议去连接交换机并查询和控制。另外,OVS还提供了sFlow协议,可以通过额外的sFlowTrend等软件(不包含在OVS软件包中)去采样和监控数据报文。

ovs-vswitchd通过UNIX socket通信机制和ovsdb-server进程通信,将虚拟交换机的配置、流表、统计信息等保存在数据库ovsdb中。当用户需要和ovsdb-server通信以进行一些数据库操作时,可以通过运行ovsdb-client组件访问ovsdb-server,或者直接使用ovsdb-tool而不经ovsdb-server就对ovsdb数据库进行操作。

ovs-vsctl组件是一个用于交换机管理的基本工具,主要是获取或者更改ovs-vswitchd的配置信息,此工具操作的时候会更新ovsdb-server的数据库。同时,我们也可以通过另一个管理工具组件ovs-appctl发送一些内部命令给ovs-vswitchd以改变其配置。另外,在特定情况下,用户可能会需要自行管理运行在内核中的数据通路,那么也可以通过调用ovs-dpctl驱使ovs-vswitchd在不依赖于数据库的情况下去管理内核空间中的数据通路。

openvswitch.ko则是在内核空间的快速通路,主要是包括datapath(数据通路)模块,datapath负责执行报文的快速转发,也就是把从接收端口收到的数据包在流表中进行匹配,并执行匹配到的动作,实现快速转发能力。通过netlink通信机制把ovs-vswitchd管理的流表缓存起来。

OVS数据流转发的大致流程如下:

1)OVS的datapah接收到从OVS连接的某个网络端口发来的数据包,从数据包中提取源/目的IP、源/目的MAC、端口等信息。

2)OVS在内核态查看流表结构(通过HASH),如果命中,则快速转发。

3)如果没有命中,内核态不知道如何处置这个数据包。所以,通过netlink upcall机制从内核态通知用户态,发送给ovs-vswitchd组件处理。

4)ovs-vswitchd查询用户态精确流表和模糊流表,如果还不命中,在SDN控制器接入的情况下,经过OpenFlow协议,通告给控制器,由控制器处理。如果没有SDN控制器接入,则进行丢弃处理。

5)如果模糊命中,ovs-vswitchd会同时刷新用户态精确流表和内核态精确流表;如果精确命中,则只更新内核态流表。

6)刷新后,重新把该数据包注入给内核态datapath模块处理。

7)datapath重新发起选路,查询内核流表,匹配;报文转发,结束。

虽然OVS作为虚拟交换机已经很好,但是它在NFV的场景下,在转发性能、时延、抖动上离商业应用还有一段距离。Intel利用DPDK的加速思想,对OVS进行了性能加速。从OVS2.4开始,通过配置支持两种软件架构:原始OVS(主要数据通路在内核态)DPDK加速的OVS(数据通路在用户态)。所谓DPDK加速的OVS,也就是华为常用来宣传的EVS。

根据上面的描述,跟数据包转发性能相关的主要有两个组件:ovs-vswitchd(用户态慢速通路)openvswitch.ko(内核态快速通路)。如下所示,显示了OVS数据通路的内部模块图,DPDK加速的思想就是专注在这个数据通路上。

ovs-vswitchd主要包含ofproto、dpif、netdev模块ofproto模块实现openflow的交换机;dpif模块抽象一个单转发路径;netdev模块抽象网络接口(无论物理的还是虚拟的)。

openvswitch.ko主要由数据通路模块组成,里面包含着流表。流表中的每个表项由一些匹配字段和要做的动作组成。

OVS在2.4版本中加入了DPDK的支持,作为一个编译选项,可以选用原始OVS还是DPDK加速的OVS。DPDK加速的OVS利用了DPDK的PMD驱动,向量指令,大页、绑核等技术,来优化用户态的数据通路,直接绕过内核态的数据通路,加速物理网口和虚拟网口的报文处理速度。如下图所示,虚线框内就是DPDK加速的部分。

DPDK加速的OVS数据流转发的大致流程如下:

1)OVS的ovs-vswitchd接收到从OVS连接的某个网络端口发来的数据包,从数据包中提取源/目的IP、源/目的MAC、端口等信息。

2)OVS在用户态查看精确流表和模糊流表,如果命中,则直接转发。

3)如果还不命中,在SDN控制器接入的情况下,经过OpenFlow协议,通告给控制器,由控制器处理。

4)控制器下发新的流表,该数据包重新发起选路,匹配;报文转发,结束。

DPDK加速的OVS与原始OVS的区别在于,从OVS连接的某个网络端口接收到的报文不需要openvswitch.ko内核态的处理,报文通过DPDK PMD驱动直接到达用户态ovs-vswitchd里。

对DPDK加速的OVS优化工作还在持续进行中,重点在用户态的转发逻辑(dpif)和vhost/virtio上,比如采用DPDK实现的cuckoo哈希算法替换原有的哈希算法去做流表查找,vhost后端驱动采用mbuf bulk分配的优化,等等。

以上,就是服务器内部的虚拟接入技术实现,主要就是虚拟交换机的原理和作用。此外,我们还介绍了Linux原生的虚拟网络设备,分布式交换机Linux Bridge,以及目前被广泛应用在电信云NFV领域的开源OVS虚拟交换机的原理和数据转发加速思路。

-------------本文结束感谢您的阅读-------------
坚持原创技术分享,您的支持将鼓励我继续创作!