硅谷创业公司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个并发请求（创建虚拟机）。
|
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个并发请求（创建虚拟机）。
|
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并发请求（创建虚拟机）。
|
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进行测试。