OpenStack Neutron 性能与扩展性测试

图片 22

前言

在很长的一段时间里,大家都有一个相同的错误观点,OpenStack Neutron无法在生产环境使用并且存在性能缺陷。MOS-Neutron团队希望通过一系列的Neutron性能与扩展性测试,改变大家对于Neutron的错误观点。MOS-Neutron团队通过大量的控制平面、数据平面以及密度测试,得出一个结论:Neutron已经准备好在生成环境中使用

测试环境

  • MOS 9.0(Mitaka Neutron)
  • 3个物理服务器实验室
  • 其中一个实验室包括378台物理节点
  • 实现线性速率吞吐量
  • 200个物理节点创建了超过24500台VMS
  • 大规模使用OpenStack Neutron

 

概述

测试目标

MOS-Neutron团队在这篇文档中详细描述了在大规模环境中,使用MOS 9.0进行Neutron性能与扩展性测试的过程以及结果。测试主要集中在Neutron组件,但是由于测试的综合性,在生产环境中使用的其他组件(Rabbit集群,DB,Nova,Ceph,Keystone等等)都会测试可用性。

测试背景

整个测试在三个不同物理服务器配置的实验室环境进行。

Neutron 配置:

  • ML2 OVS
  • VxLAN/L2 POP
  • DVR
  • rootwrap-daemon ON
  • ovsdb native interface OFF
  • ofctl native interface OFF
  • agent report interval 10s
  • agent downtime 30s

 

完整性测试

完整性测试的想法是创建一个资源池,无论做任何操作(资源的创建与删除,压力测试等等)都保证测试环境的一致性。

测试场景

图片 1

在两个服务器组(“floating”和“no-floating”)分别创建10个VM实例,每一个服务器组都使用anti-affinity策略。不同服务器上的VM实例连接不同的子网,不同的子网连接同一个Router。位于Floating服务器的VM实例分配了Floating IP,位于No-Floating服务器的VM实例只分配了Fix IP。

每个VM实例都进行如下的连接性测试:

  • SSH登录VM实例
  • Ping云外资源(比如:8.8.8)
  • Ping其他VM实例(Fixed IP 或者Floating IPs)

图片 2

 

连通性测试流量走向

VM实例ping测试的IP列表以最小冗余度检查所有可能的测试组合。不同VM实例(分配FIPs或没有)连接不同的子网,相互Ping对方和云外资源(8.8.8.8),让我们可以检查所有可能的路由可用性。比如:

  • 相同子网的Fix IP连通性

图片 3

  • 不同子网的Fix IP连通性

图片 4

  • Floating IP到Fix IP连通性

图片 5

  • Floating IP到Floating IP连通性

图片 6

  • Fix IP到Floating IP连通性

图片 7

 

测试步骤:

  1. 使用heat模板创建完整测试环境
root@node-52:~/mos-scale-9.0# heat stack-create -f integrity_check/integrity_vm.hot -P \
“image=894bdf67-1151-49b8-9e4b-df13a1ed03c1;flavor=m1.micro;instance_count_floating=10;instance_count_non_floating=10” \
integrity_stack +———–+—————–+——————–+———————+————–+                                                                                                                          
 | id           | stack_name | stack_status | creation_time| updated_time |                                                                                                                         
 +—————————–+————+————–+————–+————–+                                                                                                                         
 |dfd99a76-694c-4425-8230-21b3e68be496| integrity_stack| CREATE_IN_PROGRESS| 2016-09-07T11:34:15 | None         |                                                                                                                        
 +———–+—————–+——————–+———————+————–+

图片 8

2.VM实例关联Floating IP

(integ) root@node-52:~/mos-scale-9.0# assign_floatingips –sg-floating nova_server_group_floating
 2016-09-07 11:35:59,983 INFO:Discovering members of group nova_server_group_floating
 2016-09-07 11:36:01,160 INFO:Created floating ip with address: 10.3.61.203  
 2016-09-07 11:36:03,044 INFO:Associated floating ip 10.3.61.203 with instance c49841d6-b49b-4374-a5f5-d5cc734905bc 
 2016-09-07 11:36:03,863 INFO:Created floating ip with address: 10.3.61.205
 2016-09-07 11:36:05,469 INFO:Associated floating ip 10.3.61.205 with instance 712e2d37-f9e1-426e-b21d-81cfae2fbb06 …… 2016-09-07 11:36:21,304 INFO:Created floating ip with address: 10.3.61.232
 2016-09-07 11:36:22,704 INFO:Associated floating ip 10.3.61.232 with instance cdefadd3-6439-4341-b93f-210c6d608963

执行连接性测试

root@node-52:~/mos-scale-9.0# connectivity_check -s ~/ips.json
 016-09-07 12:02:27,008 INFO:Loading instances’ ips from /root/ips.json 
 2016-09-07 12:02:30,441 INFO:Check connectivity from 10.3.61.213 to 8.8.8.8 successful. 
 2016-09-07 12:02:33,494 INFO:Check connectivity from 10.3.61.213 to 10.3.61.203 successful.
 2016-09-07 12:02:36,547 INFO:Check connectivity from 10.3.61.213 to 10.3.61.217 successful.
 2016-09-07 12:02:39,600 INFO:Check connectivity from 10.3.61.213 to 10.3.61.205 successful.
 2016-09-07 12:02:42,654 INFO:Check connectivity from 10.3.61.213 to 10.3.61.207 successful.
 ……….
 2016-09-07 12:12:25,761 INFO:Check connectivity from 10.3.61.226 to 20.20.20.8 successful.  
 2016-09-07 12:12:28,816 INFO:Check connectivity from 10.3.61.226 to 20.20.20.9 successful. 
 2016-09-07 12:12:32,210 INFO:Check connectivity from 20.20.20.8 to 8.8.8.8 successful.
 2016-09-07 12:12:35,263 INFO:Check connectivity from 20.20.20.8 to 20.20.20.9 successful.
 2016-09-07 12:12:38,658 INFO:Check connectivity from 20.20.20.9 to 8.8.8.8 successful.
 2016-09-07 12:12:38,809 INFO:Time: 0:10:11.802956

连接性测试需要在其它测试执行过程中执行。

 

密度测试

密度测试的思路是尽可能多的创建VM实例(一次创建200-1000个VM实例),保证每个VM实例都连接相应的子网并且都能访问云外网络。密度测试可以让我们评估出,在保证云平台没有操作问题的前提下,云平台可以部署的VM实例数量的范围。

VM实例在创建成功后,会尝试连接云外监控服务器。连接成功后,云外监控服务器会记录已连接的VM实例,这些VM实例通过POST请求将其IP发送到服务器。VM实例会分别报告从元数据服务器获取IP地址并连接到HTTP服务器的尝试次数。

图片 9

 

密度测试环境

密度测试在A实验室进行,A实验室包括了200个物理节点,200个物理节点包含3个控制节点,196个计算节点和1个监控节点。

A实验室物理节点的配置如下:

图片 10

 

密度测试综述

一个Heat模板会在每个计算节点创建一个VM实例,并且创建一个网络、子网和DVR路由。Heat stack是1到5批次创建(大多数是5批次),所以一次循环意味着创建5个网络/路由和196*5个VM实例。在密度测试执行过程中我们通过Grafana页面查看集群状态和agent状态。

MOS 9.0可以成功地创建125个Heat stacks,125个Heat stacks意味着成功创建24500个VM实例,这个数量是MOS 7.0的两倍。

图片 11

图片 12

下图是密度测试过程中Grafana页面监控的集群状态:

图片 13

Grafana的集群状态数据分析表明,控制节点和计算节点上的平均CPU消耗随着VM实例数量的增加而逐渐增加。密度测试的主要限制是计算节点的内存容量。

图片 14

在测试期间,我们遇到并修补了几个BUG,并且调整了节点配置,以满足每个节点创建足够多VM实例的需求。调整包括:

  • 计算和控制节点上增加ARP表大小
  • 在conf配置中将cpu_allication_ratio从8.0增加到12.0,防止计算节点创建VM实例时触发nova vCPUs限制

在创建了大约16000个VM实例后,达到了计算节点的ARP表大小限制,因此Heat stack创建开始失败。增加了ARP表大小后,我们决定删除失败的Stack。

在启动了大约20000个VM实例,集群开始遇到RabbitMQ和Ceph的问题;当VM实例数量达到24500时,服务和agent开始大规模出现故障。初始故障可能是由于每个OSD节点缺少足够的PID引起,最终Ceph故障导致所有服务都故障。例如:Neutron服务中的mysql错误导致agent服务故障,大量资源重新调度/同步。Ceph故障后,集群无法恢复,因此必须在计算节点的容量耗尽之前停止密度测试。

Ceph团队给出建议,3个Ceph Monitors不足以支撑超过20000个VM实例(每个具有2个drives),并且建议每1000个客户端连接至少有1个monitor。也可以使用专用节点部署Ceph Monitor。

    注意:即使群集发生错误,完整性测试的连接性检查也会通过。这是控制平面故障不会影响数据平面的一个很好的例证。

    最终结果:集群创建了24500个VM实例

 

Shaker测试

Shaker是一个用于OpenStack的分布式数据平面测试工具。Shaker包含了主流的网络测试工具,如iperf3和netperf(借助flent的帮助)。Shaker能够在不同的拓扑中部署OpenStack实例和网络。Shaker场景指定要执行的测试部署和测试列表。

Shaker使用Heat模板部署所需的拓扑,使用agent执行测试并将结果报告回Server。

图片 15

 

测试场景

我们测试以下几种场景。

  1. L2 same domain

        此场景测试同一虚拟网络(L2域)中的实例之间的网络带宽。每个实例都部署在自己的计算节点上。测试负载从1对VM实例开始增加,直到使用所有可用VM实例。

图片 16

 

  1. L3 east-west

此测试场景测试部署在同一路由器的不同虚拟网络中的VM实例之间的网络带宽。每个实例都部署在自己的计算节点上。测试负载从1对VM实例开始增加,直到使用所有可用实例。

图片 17

 

  1. L3 north-south

此场景测试部署在不同虚拟网络中的VM实例之间的带宽。具有主agent的实例位于一个网络中,具有从agent的实例通过它们的Floating IP访问。每个实例都部署在自己的计算节点上。测试负载从1对VM实例开始,直到使用所有可用实例。

图片 18

 

测试过程与结果

数据平面性能测试在A实验室(QA 200节点实验室)进行,A实验室部署了标准的DVR/VxLAN/L2pop配置。运行Shaker测试组件后,我们看到令人不安的低吞吐量:在东西双向测试中,上传/下载吞吐量约为561/528 Mbits/sec!这些结果表明,在生成环境中,将MTU从默认值1500更新为9000是合理的。

修改MTU值之后,在相同测试用例中吞吐量达到3615/3844 MBits/sec, 增加了近7倍。
测试结果的巨大差异表明,网络性能取决于实验室的配置。

图片 19

图片 20

Shaker results for Lab A

MTU 1500 MTU 9000
dense_l2

dense_l3_east_west

dense_l3_north_south

dense_l2

dense_l3_east_west

full_l2

full_l3_east_west

full_l3_north_south

full_l2

full_l3_east_west

perf_l2

perf_l3_east_west

perf_l3_north_south

perf_l2

perf_l3_east_west

udp_l2

udp_l3_east_west

udp_l3_north_south

udp_l2

udp_l3_east_west

在网络性能方面重要的另一个特性是硬件offloads。当VxLAN隧道(带有50字节开销)建立时,硬件offloads是尤其重要的。VxLAN硬件offloads可以显着增加吞吐量,同时减少CPU上的负载。 [6]并非所有硬件都支持此功能,它需要具有NIC(Intel X540或X710)。为了充分利用这个功能,需要安装有新的修复和改进的4.7版本内核。 [7]实验室A没有满足要求的硬件设备,所以我们必须转到具有更高级硬件的实验室。

在新的实验室B拥有6台节点(3controllers+3computes)物理节点,所有物理节点安装了Ubuntu 14.04。实验室B的配置如下:

图片 21

在这里,我们使用Shaker测试不同实验室配置(MTU 1500/9000和硬件offloads开/关)的网络性能。

注意:使用如下命令禁用网卡上的硬件offloads特性:

ethtool -K <interface> tx off rx off tso off gso off gro off tx-udp_tnl-segmentation off

Shaker results for Lab B

MTU 1500 MTU 9000
HW offloads on dense_l2

dense_l3_east_west

dense_l3_north_south

 

full_l2

full_l3_east_west

full_l3_north_south

dense_l2

dense_l3_east_west

dense_l3_north_south

 

full_l2

full_l3_east_west

full_l3_north_south

 

perf_l2

perf_l3_east_west

perf_l3_north_south

 

udp_l2

udp_l3_east_west

udp_l3_north_south

HW offloads off full_l2

full_l3_east_west

full_l3_east_west

从下面的图表可以看出,VXLAN硬件offloads对于较小的MTU(即1500)是最有效的。

  • 在双向吞吐量测试中,相对于关闭硬件vxlan offloads的配置,采用硬件vxlan offload有3.5倍的性能提升;
  • 在下载/上传吞吐量测试中,有2.5倍的性能提升;

将MTU从1500增加到9000,性能仍然有显着的提升:

  • 双向测试中吞吐量增加75%(offloads on)
  • 下载/上传测试中吞吐量增加41%(offloads on)

图片 22

图片 23

实验室B,L3东西向测试,MTU 9000, offloads on

图片 24

    实验结果表明,尽可能在生产环境中启用巨型帧和硬件offloads是有意义的。

下一步部署一个大型实验室,其硬件配置等于或优于实验室B。新实验室C包含378个节点(3个控制器,375个计算),每个节点有4个绑定的10G X710网卡。

Shaker result for Lab C

MTU 9000, offloads on
dense_l2

dense_l3_east_west

dense_l3_north_south

full_l2

full_l3_east_west

full_l3_north_south

perf_l2

perf_l3_east_west

在实验室C中,通过Shaker测试可以看出,在L2和L3东西向测试中可以实现接近线性速率的结果,即使并发> 50:

  • 下载/上传测试速率9800 Mbits/sec
  • 双向测试中单向速率6100 Mbits/sec

图片 25

下面的图表对比了实验室A和实验室C上产生的结果.

图片 26

这里可以看出,在启用巨型帧和支持硬件offloads属性的实验室上运行相同的测试,吞吐量的显著增加,即使在高并发测试中依旧保持性能稳定。

图片 28

L3南北方向的性能仍然不够好,可以通过进一步研究来改进。尽管吞吐量测试结果取决于许多因素,包括交换机和实验室拓扑的配置(节点是否位于相同机架中等等)以及MTU在外部网络有可能被设置为1500。同时,还应该记住,在L3南北方向测试所有的流量通过controller节点,高并发性能测试可能会是性能瓶颈。

下图显示的结果很重要,因为在真实生产环境中通常有业务进出流量,因此业务进出吞吐量的稳定是非常重要。在这里我们可以看到,在实验室C上,两个方向的平均吞吐量几乎是具有相同MTU 9000配置的实验室A的3倍。

图片 29

上图所示的结果通常会由于各种原因导致通道阻塞,吞吐量会显着下降。要更全面地了解实际的吞吐量,可以看以下结果的图表。

图片 30

通过与MOS 7.0在相同环境(Lab A,MTU 9000)进行相同的测试进行的结果对比,可以看出测试结果保持稳定,没有任何性能下降。在具有更优网卡配置的实验室观察的吞吐量测试结果证明Neutron DVR + VxLAN + L2pop配置能够具有非常高的性能,其瓶颈是硬件配置和MTU设置。

实验结论

  • 在测试期间没有发现Neutron的严重问题(所有实验室,所有测试)
  • 实验发现的问题已经解决,并且patch已合入或正在合入mitaka版本
    • 数据平面测试显示在所有硬件上性能都很稳定。同时也证明,即使在不支持VxLAN offloads特性的硬件上也可以实现高网络性能,只需要合适的MTU设置。在具有高性能NIC的服务器上,吞吐量几乎达到线性速率
    • 即使控制平面存在严重问题,也不会影响数据平面的性能
    • 密度测试清楚地表明,Neutron能够在200个节点(3个控制器)上管理超过24500个VM实例,而没有严重的性能下降。测试过程中没有因为Nuetron的问题导致测试中止。事实上,我们没有发现Neutron控制平面的明显瓶颈
  • Neutron已经可以在350多个节点上进行大规模生产部署

发表评论

电子邮件地址不会被公开。 必填项已用*标注