硅谷创业公司Mirantis不久前进行了一项基准测试,测试在OpenStack Havana版本上创建75000台虚拟机的性能数据。就启动时间和成功率而言,当应用250个并发部署75000台虚拟机是最好结果。而测试过程中最高并发请求可达到500个。
以下内容对该测试的信息进行一些整理,并给出测试结果,供大家了解参考。
内容整理自:
http://www.openstack.cn/p963.html
http://www.mirantis.com/blog/benchmarking-openstack-megascale-tested-mirantis-openstack-softlayer/
测试目的
当部署上万台虚拟机的情况下,OpenStack能否成功应对。出于这个目的,Mirantis进行了基准测试,主要有以下两个考量。
- 虚拟数据中心(VDC)能否支撑上百个并发请求?
- 随着虚拟机数量的增加,用户体验是否会受到影响?
为了得到第一个问题的答案,需要针对递增的并发请求数进行一系列测试。Mirantis的目标是最大并发数能达到500。
对于第二个问题,可以用创建虚拟机所花费的时间来进行衡量。更重要的是,创建时间与已有虚拟机数目之间的依赖关系。
这次测试的目的不仅聚焦在Nova API及调度器(scheduler),VMM上的计算代理(computer agent)也有所涉及。
测试中想要验证的SLA(Service-level agreement)参数基线有:
- 虚拟机实例启动时间的方差,包括任何时间与云数据库中已有虚拟机数量间的依赖关系。
- 虚拟机实例启动的成功率,换句话说,每100个请求中因各种原因失败的请求数目。
前提及假设
由于测试只是要获取创建虚拟机时间(deployment time)的基准,衡量OpenStack Compute service不需要在虚拟机中产生任何负载。
因此,采用了最小的flavor来创建虚拟机,并且不在虚拟机中进行任何任务。OpenStack默认的flavor大小对创建时间的影响不大。
测试规模
本次基准的目标:在单一个OpenStack集群中,运行100,000台虚拟机。
这个规模,大致与一个小型的移动应用服务相若。另一个与该工作负载相配的可能的用例是:一个对于跑在成千上万个独立移动终端上的移动服务的测试环境。
测试环境
【虚拟机配置】
测试使用的flavor大小:1VCPU,64MB内存,2GB硬盘空间。该flavor比AWS的m1.micro规格更小,仅刚好够启动Cirros的测试镜像。
由于测试目标是100,000台虚拟机,所以总共的虚拟机资源如下:
- 100,000个VCPU
- 6250Gb大小的内存
- 200TB的硬盘空间
【物理机配置】
每台物理机的配置情况:
- 4个物理核(由于开启超线程,共计8个逻辑cpu),16Gb内存及250GB硬盘空间。
- CPU过载:1:32(OpenStack默认值的2倍)
- 内存过载:1:1.5(不会在虚拟机中产生负载)
因此,单台物理机可提供的资源如下:
- (4+4)*32 = 256VCPU
- 16*1.5 = 24Gb内存
- 250GB硬盘
通过与虚拟机配置进行比较可以得出:每个物理几点上应创建250台虚拟机。大约需要400台物理机才可支撑100,000台虚拟机的规模。
【测试机配置】
除了提供OpenStack环境的物理机之外,还需要有测试机来产生大并发请求。原文中称这种测试机为controller。
每个controller的配置为:128GB内存及SSD硬盘(大小不详),CPU信息不详。
软件版本及参数
测试中使用的软件为Mirantos OpenStack 4.0,包含了OpenStack 2013.2(Havana),并将OpenStack部署到SoftLayer。
配置部分只针对三个服务:Nova,Glance及Keystone。 对于网络,使用Nova Network的FlatDHCP模式并开启Multi-host功能。
基准测试中,需要增大特定的参数,最主要的是SQLAlchemy模块连接池的数量(nova.conf中的maxpoolsize及max_overflow参数)
【测试引擎】
采用的测试引擎为Rally,Rally允许配置每个轮次的相关参数,并记录各个请求完成的时间。
测试结果
原文提供了部分用例的结果,首先对较小的规模进行测试。
已有5000台虚拟机,100个并发请求(创建虚拟机)。
![Mirantis对OpenStack的性能测试:高并发创建75000台虚拟机 - 网易杭州QA - 网易杭州 QA Team](http://img0.ph.126.net/pEklduabHVL6gozFBQAt1w==/2979975578535839160.png)
Total
|
Success Rate %
|
Min (sec)
|
Max (sec)
|
Avg (sec)
|
90 percentile
|
95 percentile
|
5000
|
98.96
|
33.54
|
120.08
|
66.13
|
78.78
|
83.27
|
已有25000虚拟机,250个并发请求(创建虚拟机)。
![Mirantis对OpenStack的性能测试:高并发创建75000台虚拟机 - 网易杭州QA - 网易杭州 QA Team](http://img2.ph.126.net/vZCAU110kEgZx-Bg_Ui64g==/3190800336092191376.png)
Total
|
Success Rate %
|
Min (sec)
|
Max (sec)
|
Avg (sec)
|
90 percentile
|
95 percentile
|
25000
|
99.96
|
26.83
|
420.26
|
130.25
|
201.1
|
226.04
|
测试中出现了瓶颈,通过调整sqlalchemy及haproxy的连接池参数后瓶颈消失。其中,sqlaclchemy的连接数从5调整到100,haproxy从4000调整到16000。
测试中出现了haproxy的失败率上升的现象,这是由于haproxy连接池的连接被用尽导致Pacemaker将虚拟IP地址转移到了另一个controller的节点上。当失败发生后,负载均衡器失去响应。这个问题通过提高haproxy的连接限制而得以解决。
上述准备工作完成后,开始向100,000台虚拟机的目标进发。虚拟机数量逐渐递增:从10,000、25,000、40,000、50,000、75,000到100,000。测试结果显示250个并发请求是系统能维持稳定的最高值。在此基础上追加了150个物理节点,即共有350台物理机,外加3台测试机(controller server)。
根据前面的测试结果,修正了测试目标,从100,000下降到75,000台。最后,创建75,000台虚拟机共花费了8个小时的时间,下图显示了创建时间(boot time)与正在运行虚拟机个数(the number of running VMs)间的关系:
已有75000台虚拟机,500并发请求(创建虚拟机)。
![Mirantis对OpenStack的性能测试:高并发创建75000台虚拟机 - 网易杭州QA - 网易杭州 QA Team](http://img2.ph.126.net/mmPxArHR9RuWMvqSKt8Bhw==/869757678136119641.png)
Total
|
Success Rate %
|
Min (sec)
|
Max (sec)
|
Avg (sec)
|
90 percentile
|
95 percentile
|
75000
|
98.57
|
23.63
|
614.29
|
197.6
|
283.93
|
318.96
|
结果中可以看出,500并发请求时,平均时间为197.6秒。
【总结】
Mirantis OpenStack可以容纳500个并发请求,并维持在250个并发请求在单个集群中创建75000台虚拟机。
本章中提到的一个重要的成功因素是,测试采用了IBM SoftLayer的硬件和网络架构,因而很方便的管理了网络连接,也能够很容易的扩展成多个OpenStack集群。
Mirantis下一步打算测试虚拟机中运行的基准测试,针对硬盘和网络IO进行测试。