SR-IOV技术在OpenStack中的应用①

张 驰, 张 傲

1(武汉邮电科学研究院,武汉 430074)2(烽火信息集成技术有限公司,武汉 430074)

SR-IOV技术在OpenStack中的应用①

张 驰1, 张 傲2

1(武汉邮电科学研究院,武汉 430074)2(烽火信息集成技术有限公司,武汉 430074)

在OpenStack云平台中,一台物理服务器上可能同时运行着十几台虚拟机,这对于物理服务器的I/O性能要求是非常高的.因此,I/O虚拟化技术的效率对于整个OpenStack云平台的网络性能提升都有着至关重要的作用.为了提高系统整体的网络性能,在OpenStack云平台中入SR-IOV技术成为了一种可选的方式.本文通过对比实验测试了SR-IOV技术对于OpenStack云平台上网络I/O性能的影响.最终对实验结果进行分析可知,在入SRIOV技术后,OpenStack云平台上的计算节点I/O虚拟化性能提升了大概50%.

云计算;OpenStack云平台;I/O虚拟化;网络性能;SR-IOV技术

随着云时代的来临,各种各样的云计算平台应运而生,例如亚马逊公司的AWS云平台以及微软公司的Azure云平台等.而围绕着开源的优势,OpenStack云平台在近几年得到了越来越多的个人开发者和企业的支持,成为当今最火的云平台之一.

而在虚拟化技术中,内存虚拟化技术和CPU虚拟化技术发展都已较为成熟,但是I/O虚拟化技术的发展却相对缓慢,远远没有达到业界的要求.I/O虚拟化技术的落后不仅影响了物理服务器的I/O虚拟化效率,更是影响了虚拟机的整体性能[1].SR-IOV(Single-Root I/O Virtualization,单根I/O虚拟化)技术是一种基于物理硬件的虚拟化解决方案,可以提高物理I/O设备的性能与可扩展性.SR-IOV技术允许在虚拟机之间高效共享PCIe设备,由于该技术是基于硬件实现的,可以使虚拟机获得与宿主机相似的I/O性能[2].

随着云环境里虚拟机(Virtual Machine,VM)的数量增多,云平台中虚拟机相互之间的通信,以及虚拟机和互联网之间的通信,导致了网络虚拟化的基本需求.在OpenStack云平台中,负责网络功能的组件称为Neutron组件.Neutron组件具有灵活部署虚拟网络的能力,但是其性能问题一直是影响OpenStack大规模应用的瓶颈之一,特别是I/O性能问题更是其中重要的一环.由于Neutron组件需要在物理服务器中创建大量的虚拟设备,例如虚拟端口以及虚拟交换机等,这些虚拟的网络组件会对所在的物理服务器CPU造成比较大的开销,并且这些虚拟设备本身具有的一定的性能瓶颈,因此会对整个OpenStack云平台的网络I/O性能造成极大的影响.同时,在OpenStack环境中,一台物理服务器上必然会同时运行多台虚拟机,如果所使用的虚拟化I/O方案不支持将单个物理I/O设备同时共享给多台虚拟机,那么给云平台中的每台虚拟机都分配单独的物理I/O设备显然是不现实的.考虑到SRIOV技术的特点以及优势,将SR-IOV技术入到OpenStack云平台便成为了解决OpenStack云平台中Neutron组件网络I/O虚拟化性能较差的一种非常合适的方式.

1 OpenStack云平台介绍

云计算平台事实上是一种以虚拟化技术为基础,以提高服务器CPU和网络资源利用率为后的新型服务系统和运营模式.从云计算所提供的服务层次来划分,云计算从上层到下层可以分为软件即服务(SaaS)、平台即服务(PaaS)和基础设施即服务(IaaS)[3].OpenStack是一个典型的IaaS层的云计算平台.

OpenStack诞生于2010年7月,是由美国国家航空航天局和RackSpace公司合作研发而成,后前由OpenStack社区进行管理[4].OpenStack社区每隔几个月便会发布一个新的版本,以26个英文字母为首字母按照从A到Z的顺序依次命名新的版本,第一个版本的OpenStack被命名为Austin.OpenStack是一个开源的云操作系统,最显著的特点便是体现在开源上,任何公司和个人开发者都可以参加到该项后中,参与代码开发与测试,从而为OpenStack的发展做出贡献.

OpenStack为用户提供了简单易用的Web操作界面和详细而全面的API接口.通过浏览器访问OpenStack的Web管理界面,用户可以以租户或管理员的身份进行登录.租户可以创建自己的私有网络,以及启动虚拟机实例进行操作,管理员则可以管理用户资源的配额和其他控制权限.而通过OpenStack提供的API,开发者可以轻易地对云平台进行开发和学习.OpenStack云平台内的各组件是通过交互模式来提供云服务的,各个组件可以任意分配到不同的物理服务器上,具有非常好的灵活性与扩展性.

2 Neutron组件与虚拟网络

在OpenStack中负责云平台虚拟网络的是Neutron组件.Neutron组件的主要作用是在云环境下为不同租户提供建网组网、分配虚拟机IP地址、防火墙、负载均衡等服务.Neutron组件将真实物理网络世界中的网络(network)、子网(subnet)和端口(port)等概念抽象化,应用到云环境的虚拟网络中,使得云平台中的虚拟机可以像物理服务器一样直接连接到虚拟网络上,从而实现在虚拟网络中的数据通信.虽然云平台中网络都是虚拟的,但是这些虚拟的网络、子网等在OpenStack提供的操作界面Horizon上都是可视化的,用户可以非常轻易地去部署完成一个虚拟私有网络.

2.1 Neutron组件原理

云计算中所用到的网络技术与传统的网络技术原理类似,只是将原有的传统网络技术运用到了云环境下的虚拟网络环境中.对于Neutron组件来说,为了给OpenStack平台提供虚拟网络能力,事实上在底层使用到了非常多Linux系统中的相关技术.

图1所示为Neutron组件在Vlan网络环境下的原理图.图的左边是OpenStack平台上充当计算节点的一台物理服务器,右边是充当网络节点的物理服务器.当租户创建一台虚拟机时,Neutron组件会相应地给该虚拟机创建一张虚拟网卡,该虚拟网卡设备在计算节点看来类似于Linux中的Tap设备.该Tap设备上包含了Neutron组件提供给该虚拟机的IP以及MAC等信息,虚拟机可以直接通过对Tap设备进行数据的读写,从而实现数据的通信.在图1中的设备A与设备Q便是分别属于VM1与VM2的两个Tap设备.

虚拟机的虚拟网卡Tap设备连接到了一个名为qbr的Linux网桥上.在qbr网桥上,Neutron组件利用了Linux上的Iptables来实现虚拟机的安全组功能,因此qbr也称之为安全网桥.

Linux网桥设备qbr通过一对Veth设备qvb与qvo直接连接到OVS(Open VSwitch)软件所创建的虚拟交换机br-int上.OVS是一套可以创建高性能虚拟交换机的软件,它所创建的虚拟交换机相比于传统的Linux网桥设备,具有更好的性能以及支持更多的功能.从虚拟交换机br-ethx方向转发过来的数据报文,都需要在虚拟交换机br-int上进行Vlan id的转换.同理,从虚拟交换机br-int传向虚拟交换机br-ethx的数据报文,也需要在虚拟交换机br-ethx上进行Vlan id的转换.这是因为qvo设备所分配到的Vlan id是只属于云平台虚拟网络内部的,该Vlan id会对应一个真正能在云平台业务网段上进行传输的Vlan id.这样虚拟机所产生的带有内部Vlan id的数据报文在通过虚拟交换机br-ethx后,经过Vlan id的转换,便可以在云平台的物理业务网上进行传输.从外界业务网上发来的数据报文经过虚拟交换机br-int后,所带有的Vlan id会被转换成内部的Vlan id,然后发送给对应的虚拟机,这样便实现了虚拟网络与物理网络的对应.这些Vlan id的映射都是通过虚拟交换机br-int与br-ethx中的流表来控制实现的,而流表的规则则是由Neutron组件进行下发的.

图1 Neutron组件原理图

2.2 虚拟机流量走向

在OpenStack云环境中,如果虚拟机需要访问外网或者进行跨网段的访问,都需要经过网络节点上虚拟路由器的配合.而同一租户里相同网段的两台虚拟机进行互访是不需要经过网络节点的.由于本文只涉及到计算节点,因此下面介绍同一租户下相同网段的两台虚拟机进行互访的情况.

如图2中所示,虚拟机1存在于计算节点1上,虚拟机4存在于计算节点2上,并且虚拟机1和虚拟机4属于同一个租户网络的同一个子网内,两者之间的数据通信将会经过连接到计算机点1与计算节点2的物理交换机上进行传输.当虚拟机1想发送一个报文给位于不同计算节点上的虚拟机4时,首先会发送一个ARP广播报文来确定虚拟机4的MAC地址.该ARP广播报文会通过Tap设备以及qbr网桥,然后被计算节点1上的虚拟交换机br-int转发到所有与br-int相连的接口上.当广播报文经过计算节点1上br-ethx时,会被带上一个外部Vlan id.需要注意的是,同一租户的相同网络里所有的虚拟机发出与接收的报文都会带有相同的外部Vlan id,因此该ARP报文会被物理交换机转发到所有其他节点上.当ARP报文到达计算节点2上时,该数据报文的Vlan id会在虚拟交换机br-int上被转换成对应的内部Vlan id,并被广播到所有与br-int所连的接口上,最后虚拟机4会应答该ARP广播.当虚拟机1知道虚拟机4的MAC地址后,就可以直接与虚拟机4进行数据通信了.

图2 虚拟机之间互相访问

2.4 Neutron组件性能瓶颈

通过上面的分析可以看到,为了实现OpenStack中的虚拟网络,Neutron组件在计算节点上创建了非常多的虚拟网络设备.这其中包括虚拟机的虚拟网卡Tap设备、OVS虚拟交换机br-int和br-ethx等.利用这些虚拟网络设备,Neutron组件不仅完成了云平台中虚拟网络的创建,还将整个虚拟网络与真实物理网络相连通,实现了对整个服务器集群网络资源的虚拟化.但是另一方面,这些虚拟网络设备的建立和运行会给云平台上的计算节点带了很大的CPU开销,加上这些虚拟网络设备本身存在一定的缺陷和性能瓶颈,会极大地减少计算节点上的网络带宽.

举个例子,假如在一台计算节点上,使用一般的英特尔82599ES万兆网卡,那么该计算节点最大的网络I/O吞吐量可能只能达到5～6 Gbps左右.考虑到在云计算中心,可能拥有数以万计的物理服务器,那么这种程度的I/O性能损耗显然是一种极大的浪费.因此寻找一种更加优秀的I/O虚拟化方案来替代后前Neutron实现虚拟化网络的方式,有可能解决OpenStack云平台网络I/O性能瓶颈问题.

3 SR-IOV技术与Neutron组件

3.1 SR-IOV技术简介

为提高服务器里虚拟机收发报文的性能和可伸缩性,解决I/O虚拟化最后一公里的问题,提出了基于硬件的SR-IOV虚拟化解决方案.SR-IOV规范定义了一种虚拟化PCIe设备的标准机制.该机制能将一个PCIe以太网设备虚拟成多个PCIe设备.用户可以将每个虚拟的PCIe设备直接分配给虚拟机,绕过虚拟机监控层(VMM),从而实现低延时和近线速[5].

SR-IOV中具有两种功能类型:物理功能(Physical Function,PF)和虚拟功能(Virtual Function,VF),PF用于支持SR-IOV的PCI功能,拥有完全配置或控制PCIe设备资源的能力.而VF是一种轻量级的PCIe功能,与PF相关联,可以与同一物理功能关联的其他VF共享一个或多个物理资源[6].

SR-IOV技术允许将单个物理网络设备同时共享给多台虚拟机,这样不仅可以实现对物理网卡的共享,同时还可以使虚拟机的流量绕过Neutron所创建的虚拟网络设备,直接到达物理网卡上.虚拟机数据处理逻辑跳过了计算节点的虚拟网络设备,由物理网卡决定数据如何处理,从而释放了计算节点的CPU资源.这种方式使得虚拟机达到近线速的性能,并且不需要为每台虚拟机单独去分配独立的物理网卡端口.

3.2 在Neutron中引入SR-IOV技术

将SR-IOV技术入到OpenStack中后,可以将虚拟机的虚拟端口与支持SR-IOV功能的物理网卡上所虚拟出来的虚拟功能VF相关联,而不再需要Neutron组件额外地去创建Tap设备、qbr网桥以及OVS虚拟交换机了,这样极大地减少了计算机点上的CPU开销.

如图3所示,虚拟机1处于计算节点1上,虚拟机4处于计算节点2上,两台虚拟机属于同一租户下同一网段内.两台计算节点上均有一张带有SR-IOV功能的物理网卡,其中虚拟网卡功能VF1是分配给虚拟机1的,虚拟网卡功能VF4是分配给虚拟机4的.虚拟机所发出的报文会直接发送到与虚拟机相关联的VF上,然后由物理网卡来决定如何对数据报文进行处理.在图3中可以看到,从虚拟机1发出的报文直接发送到VF1上,然后此报文经过物理网卡的处理后流入到物理交换机上,通过物理交换机到达计算节点2上,最终到达虚拟机4.与传统Neutron组件中Linux网桥和OVS虚拟交换机方式相比,在计算节点内部没有了网桥qbr和虚拟交换机br-int与br-ethx等虚拟设备,虚拟机的数据报文直接通过VF传到了物理网卡上.

图3 入SR-IOV技术后的流量路径

4 测试与分析

在之前的章节中详细介绍了Neutron组件和SR-IOV技术的原理,在本章节,会对SR-IOV技术在OpenStack云平台上进行具体的测试,证明之前理论分析的正确性,同时得出实验结果.

4.1 测试环境介绍

在测试实验中,一共使用了三台物理服务器组成OpenStack环境.其中一台物理服务器用作OpenStack云平台的控制节点和网络节点,另外两台物理服务器用作OpenStack的计算节点.这三台物理服务器都运行了Ubuntu 14.04LTS操作系统.

在表1中可以看到,作为OpenStack云平台的控制节点/网络节点,这台物理服务器使用的是因特尔六核的处理器,其内存为64GB.该服务器上存在有三张网卡,其中两张是博通公司BCM5720千兆网卡,该网卡用于OpenStack平台的管理网络与外网网络.还有一张是因特尔公司的82599ES万兆光卡,主要用于云平上虚拟机的业务网络.计算节点上的配置信息基本与控制/网络节点类似,唯一的区别是控制/网络节点的因特尔82599ES万兆网卡没有开启SR-IOV功能,而计算节点上是开启了该功能的.

此次测试环境中物理网络布局图如图4所示.测试环境一共包含了三个网络.第一个网络为OpenStack云平台的管理网络,其网段为192.168.1.0/24,主要提供OpenStack各个组件之间的内部通信,以及API访问端点(Endpoint).第二个网络为外部网络,网络段位10.89.0.0/24,此网络是实验环境的外网网络,通过这个网络可以访问到外界互联网,从而可在服务器中进行软件以及各种服务的下载.第三个网络为虚拟机的业务网络.该网络的作用是提供虚机在计算节点之间,以及计算节点和网络节点之间的通信.该网络所连接的网卡均为支持SR-IOV功能的网卡,也就是图中的eth3设备.

图4 网络布局

表1 测试环境配置信息表

4.2 性能测试

在性能测试中使用Iperf软件作为测试工具,通过在同一租户内的两台虚拟机之间发送数据包来测试计算节点带宽.测试实验一共分为三组场景,分别为同一个网段同一台物理服务器上的两台虚拟机的带宽测试,同一个网段不同物理服务器上的两台虚拟机的带宽测试,以及不同网段同一物理服务器上的两台虚拟机的带宽测试.每组测试都会使用Iperf工具测试1个网络连接,3个网络连接以及5个网络连接的情况.

虚拟机的IP以及所在节点的示意图如图5所示.第一组测试为处于同一网段内同一物理节点上两台VM的带宽测试,因此对比图5可知,我们只需要在虚拟机vm1与vm5之间使用Iperf工具进行测试即可.这种场景下,虚拟机的流量是直接被带有SR-IOV功能的物理网卡进行处理,数据包从vm1发出到达计算节点1上网卡后便直接到达了vm5上.第二组测试为处于同一网段不同物理节点两台VM的带宽测试,因此只需要在vm1与vm2之间进行测试即可.数据包从vm1出来后到达计算节点1的网卡,然后经过物理交换机到达计算节点2的网卡上,最终数据包流入到vm2上.第三组测试为处于不同网段同一物理节点上两台VM的带宽测试.因此只需要在vm2与ins2之间进行测试即可.该场景下,数据包从vm2发出后,会先到达网络节点的虚拟路由上,然后再回到计算节点2的网卡上,最终到达ins2上.

最终的测试结果如图6所示.在测试结果柱状图中纵坐标表示计算节点的网络I/O吞吐量,其单位为Gbit/sec,横坐标表示一共进行了三组场景的测试,每组测试实验都有三组数据,分别为使用Iperf工具进行一个连接、三个连接、五个连接下的测试结果.其中场景一为同一个网段同一台物理服务器上的两台虚拟机的带宽测试.场景二为同一个网段不同物理服务器上的两台虚拟机的带宽测试.场景三为不同网段同一物理服务器上的两台虚拟机的带宽测试

图5 虚拟机所在节点示意图

图6 Iperf工具测试结果

将此次实验的测试数据做出统计后,与传统Neutron组件虚拟网桥方式的I/O吞吐量作对比,如图7所示.可以看出SR-IOV技术对于云平台上计算节点的I/O性能有巨大的提升.

图7 网络I/O性能对比

4.3 测试结果分析

在此次实验中使用的是万兆以太网卡,因此在单台物理服务器上网络带宽所能达到的理论值应该为10Gbit/sec.第一种测试场景是相同网段同一节点的两台虚拟机互相测试,数据包的处理是直接在SRIOV网卡的上进行的,虚拟机的数据包发送到该虚拟机绑定的VF上,经网卡处理直接转发到了另一台虚拟机所绑定的VF上,在这过程中并没有真正进行两张网卡之间的发包与收包,而是仅仅在一张网卡上对包进行了逻辑处理,因此在物理网卡上对数据包的处理速度接近了14Gbit/sec,超过了网卡的理论值10Gbit/sec,这是可以理解的.

而在第二种与第三种测试场景下,数据包的路径经过了多个物理服务器节点,在网卡上有真正的发包与收包过程,可以看到在一个网络连接下,带宽达到了8.3Gbit/sec.由于单个连接较少,并没有达到带宽的极限值,当将连接数增加到3个以及5个时,可以明显看到,网络的I/O吞吐量已经到达极限值约9.4Gbit/sec,这已经与该网卡的理论速率10Gbit/sec非常接近了.基本上可以证明在此次试验中,SR-IOV技术的用,的确可以让OpenStack云平台中虚拟机的I/O吞吐量达到近线速.而在图7中可以非常清楚的看到,在入了SR-IOV技术后,OpenStack云平台上计算节点的最大I/O吞吐量有了非常巨大的提升,提升空间在40%～60%之间.

5 结语

本文探讨了OpenStack云平台中Neutron组件的原理以及不足,发现将SR-IOV技术入到OpenStack云平台是一种可以解决云平台上计算节点网络瓶颈的一种很好的方式.SR-IOV技术入后,通过改变计算节点上虚拟机的访问方式,使虚拟机不再去依赖Neutron组件创建的各种虚拟网桥,而是利用物理网络硬件的SR-IOV功能,使虚拟机的数据报文直接到达物理网络设备上.经过测试,这种方式可以使得云平台的计算节点最大吞吐量提高约50%左右.

在其他方面,还存在部分问题.第一点,在SRIOV技术入到OpenStack云平台后,用户操作界面Horizon暂时不能支持SR-IOV技术,但可以通过命令行调用API去创建带有SR-IOV接口的虚拟机,并不会影响正常使用.第二点,后前的SR-IOV技术存在一定的缺陷,例如物理网卡设备最多能虚拟出来的VF数量有限制,但能满足当前OpenStack的需求.第三点,SR-IOV技术解决了OpenStack云平台中计算节点的网络I/O问题,但是对网络节点的I/O性能瓶颈却没有影响.想要解决此问题,需要入DVR技术或者是DPDK等技术才能实现.

1 李超.SR-IOV虚拟化技术的研究与优化[硕士学位论文].长沙:国防科学技术大学,2010.

2 杨洪波.高性能网络虚拟化技术研究[博士学位论文].上海:上海交通大学,2012.

3 罗军舟,金嘉晖,宋爱波,等.云计算:体系架构与关键技术.通信学报,2011,32(7):3–21.

4 陈陶,顾双双,柳钮滔,等.基于OpenStack Juno版的私有云平台部署及实践.物联网技术,2015,(6):64–67,69.

5 黄智强.基于SR-IOV的高性能I/O虚拟化研究与优化[硕士学位论文].上海:上海交通大学,2013.

6 龚珊珊.基于SR-IOV技术的网卡虚拟化研究与实现[硕士学位论文].北京:中国舰船研究院,2015.

Application of SR-IOV Technology in OpenStack

ZHANG Chi1,ZHANG Ao21(FiberHome Technologies Group,Wuhan 430074,China)2(Wuhan Fiberhome Integration Technologies Co.Ltd.,Wuhan 430074,China)

On an OpenStack cloud platform,a server may simultaneously run more than a dozen virtual machines,which requires high system network I/O performance.Therefore,the efficiency of I/O virtualization is important for the improvement of network performance on OpenStack cloud platform.In order to improve the overall network performance of the system,introducing SR-IOV technology into the OpenStack cloud platform is an option.The influence of SR-IOV technology on network I/O performance of OpenStack cloud platform is tested by contrast experiments.Finally,the experiment results show that,after the introduction of SR-IOV technology,the I/O virtualization performance of computing nodes in OpenStack cloud platform have increased by about 50%.

cloud computing;OpenStack cloud platform;I/O virtualization;network performance;SR-IOV technology

张驰,张傲.SR-IOV技术在OpenStack中的应用.计算机系统应用,2017,26(9):246–252.http://www.c-s-a.org.cn/1003-3254/5925.html

2016-12-20;采用时间:2017-01-09