分享

大家好，我叫蒋清野。大家都知道，OpenStack项目经过两年的发展，已经开始进入试商用的阶段。HP是最早推出基于OpenStack的公有云服务的公司，RackSpace也于最近退出了基于OpenStack的公有云服务。这两个IaaS服务在一定程度上可以反映OpenStack项目的成熟程度。我从今年4 月份起就在HP Cloud Service上进行一些测试性的项目。借OpenStack亚太峰会这个机会，将我在HP Cloud Service上获得的一些数据与各位同行进行分享，希望能够得到大家的批评和指教。

（1 分钟）

【测试介绍】

幻灯片上的这张截图，是HP Cloud Service的用户界面。在这次测试中，所有的虚拟机都是通过基于浏览器的用户界面创建的，并且集中在az-1.region-a.geo-1这个可用域里。HP Cloud Service提供了多个版本的CentOS、Debian、Fedora和Ubuntu操作系统，在我们的测试中选用的操作系统为Ubuntu 11.04 64 bit服务器版。幻灯片上着个表格列出了HP Cloud Service所提供的虚拟机规格、配置和价格。每个规格的虚拟机，至少创建3 个实例来进行比较。在有必要的情况下，还要创建更多个实例。在整个测试中，一共创建了20台虚拟机。

在这次测试中，我们使用byte-unixbench来评估vCPU性能，mbw来评估内存性能，iozone来评估磁盘IO性能，iperf来评估网络性能，pgbench来评估数据库性能，并通过Hadoop wordcount来评估复杂应用的性能。

在这次测试中，我们进行了一些数据筛选的工作。在同一规格的虚拟机中，我们展示的是性能最好的虚拟机上的测试结果。对于同一个测试项目，我们进行10次重复测试，并将其结果进行平均。

（3 分钟）

【byte-unixbench】

首先我们来看看byte-unixbench的测试结果。

UnixBench是一套具有悠久历史的性能测试工具，其测试结果反映的是一台主机的综合性能。从理论上来说UnixBench测试结果与被测试主机的CPU、内存、存储、操作系统都有直接的关系。但是根据我们的观察，对于现代的计算机系统来说，UnixBench测试结果受CPU 处理能力的影响更大一些。因此，在这里我们用UnixBench测试结果来代表虚拟机的vCPU 处理能力。

在这张图表上有两条曲线，其中蓝色的曲线代表单线程的测试结果，红色的曲线代表多线程的测试结果。在多线程测试中，线程的个数等于虚拟机的vCPU颗数。可以看到，在单线程测试中，所有虚拟机的测试结果是非常接近的，因为它反映的是单颗vCPU的处理能力。在多线程测试中，具有同样数量vCPU的虚拟机的测试结果是基本一致的，内存大小对测试结果基本上没有影响。此外，测试结果的增长慢于vCPU数量的增长。当vCPU的数量增长一倍（乘以2）的时候，测试结果的数值增长0.5倍（乘以1.5）。这样的测试结果，和我们在其他IaaS平台（例如盛大云和阿里云）上观察到的现象是一致的。

（3 分钟）

【mbw】

我们使用mbw来测试虚拟机的内存性能。mbw通常用来评估用户层应用程序进行内存拷贝操作所能够达到的带宽。这张图表上橙色、粉色和蓝色的曲线分别代表三种不同的内存拷贝方式在一秒钟里能够拷贝的内存大小。可以看到，对于任何一种测试方法，所有规格的虚拟机的内存带宽基本上是一样的。

（1 分钟）

【iozone – os disk】

HP Cloud Service所提供的虚拟机包括两块硬盘，一块是系统盘，另外一块是数据盘。这张图表展示的是通过iozone测试到的系统盘吞吐量。可以看出，所有规格的虚拟机在写性能方面是基本一致的，其吞吐量上限基本上都在200 MB/s左右。但是在读性能方面有很大的差异。 超小型（XSmall）、小型（Small）和中型（Medium）虚拟机的吞吐量只能够达到1 GB/s，而大型（Large）、超大型（XLarge）和特大型（XXLarge）虚拟机的吞吐量可以达到5 GB/s，是其他虚拟机的5 倍。

从不同规格的虚拟机具有类似的写性能这一点来看，HP Cloud Service不太可能是利用cgroup blkio throttling或者是qemu blk throttle对虚拟机的磁盘IO进行限制。读性能比较低的虚拟机，其磁盘映像可能存储在SATA或者是SAS硬盘上；读性能比较高的虚拟机，其磁盘映像可能存储在SSD硬盘上。

（2 分钟）

【iozone – data disk】

这张图表展示的是通过iozone测试到的数据盘吞吐量。同样，所有规格的虚拟机在写性能方面是基本一致的，其吞吐量上限基本上都在200 MB/s左右。但是在读性能方面有很大的差异。 超小型（XSmall）、小型（Small）、中型（Medium）和大型（Large）虚拟机的吞吐量只能够达到1 GB/s，而超大型（XLarge）和特大型（XXLarge）虚拟机的吞吐量可以达到5 GB/s，是其他虚拟机的5 倍。

我们将这张图表和上一张图表进行一下比较。各位注意一下这两张图表上的大型主机（Large），它的系统盘具有较高的读性能，但是数据盘具有较低的读性能。大型主机（Large）可能代表了HP Cloud Service设计团队的一个思路：配置更高的主机，系统盘和数据盘都需要更好的磁盘IO性能。

需要指出的是，不同规格的虚拟机在磁盘IO性能方面的差异，并没有在HP Cloud Service的文档中加以说明。

（2 分钟）

【iperf】

接下来我们看一下HP Cloud Service的内网带宽状况。在如图所示的这个矩阵中，数据点(X, Y)的数值代表两台虚拟机之间的带宽。可以看出，两台虚拟机之间的内网带宽是由配置较低的虚拟机所决定的。超小型主机（XSmall）与其他任意主机之间只有25 Mbps的带宽，小型主机（Small）与其他任意主机之间只有50 Mbps的带宽，中型主机（Medium）是100 Mbps，大型主机（Large）是200 Mbps，超大型主机（XLarge）是400 Mbps，特大型主机（XXLarge）是650 Mbps。

和前面提到的磁盘IO性能差异类似，不同规格的虚拟机在内网带宽方面的差异，也没有在HP Cloud Service的文档中加以说明。

限制虚拟机之间的内网带宽，从某些角度来看也许是合适的。譬如说，一些用户可能会运行某些大量消耗内网带宽的恶意程序，导致整个内网发生拥塞，从而影响到同一内网中的其他用户。

在这样一个前提下，我想潜在的问题就是这些具体数字是合适的吗？以内网带宽最小的超小型主机（XSmall）为例，通过内网拷贝一个2 GB的文件，实际需要5 分钟到8 分钟左右，这样的速度是客户可以接受的吗？或者，请在座的各位回想一下，你们现在还有任何服务器是接在百兆交换机上的吗？

（4 分钟）

【hadoop wordcount single node】

在分析完HP Cloud Service的处理器、内存、磁盘和网络性能之后，我们以目前比较流行的Hadoop为例，看看它在不同的虚拟机上的性能如何。在我们下载到的Hadoop软件包中包含了一些作为例子的应用，其中的wordcount应用估计很多人都运行过。这个应用读取输入目录中的文件，计算这些文件中一共有多少个不同的单词以及他们出现的次数。在这个测试中，我使用了三个700MB左右的文件作为测试数据，测试数据一共有2 GB。我们不同规格的虚拟机上运行wordcount应用对这些测试数据进行分析，并分别记录完成分析所需要的时间。显然，完成测试所需要的时间越长，表示虚拟机的性能越低。

从这张图表中可以看出，完成同样的测试，小型主机（Small）需要的时间比超小型主机（XSmall）有显著的减少。但是，随着主机配置的进一步提高，完成测试所需要的时间并没有进一步减少。中型（Medium）、大型（Large）、超大型（XLarge）和特大型（XXLarge）主机完成测试所需要的时间基本上维持在同一水平上。一个可能的解释是Hadoop wordcount是磁盘IO密集型应用，由于受到磁盘IO性能的限制，配置较多vCPU的虚拟机不能够发挥其计算能力方面的优势。

（3 分钟）

【hadoop wordcount multiple nodes】

在上一张胶片中，我们比较的是不同规格的虚拟机的Hadoop wordcount性能。接下来我们看看由多台虚拟机组成的Hadoop集群会有什么样的性能。从上面这张图表中可以看出，随着计算集群中主机数目的增加，完成测试所需要的时间越来越短，表明计算集群的整体处理能力越来越强。由两台超小型主机（2 x XSmall）组成的集群，其性能与单台小型主机（Small）接近。由三台超小型主机（3 x XSmall）组成的集群，其性能明显超过单台特大型主机（XXLarge）。

前面一张幻灯片中我们已经提到Hadoop wrdcount是磁盘IO密集型应用。由多台配置较低的虚拟机组成的计算集群，由于磁盘IO方面的压力被分散到多台虚拟机上，因此其性能超过了由单台配置较高的虚拟机组成的伪集群。这样的测试结果和之前我在盛大云和阿里云上观察到的现象是一致的。（盛大云和阿里云选择的虚拟化技术是Xen，HP Cloud Service选择的虚拟化技术是KVM。）当我们在IaaS平台上运行类似于Hadoop这样的应用的时候，应该尽可能考虑横向扩展，才能够获得最大的性能和性价比。

需要说明的是，如上所述数据仅仅包括进行Hadoop wordcount运算的时间，不包括将数据文件从本地文件系统拷贝到HDFS的时间。

（3 分钟）

【pgbench】

最后我们来看一看在HP Cloud Service上的数据库性能。这张图表展示的是在不同主机上的pgbench测试结果，其中蓝色的曲线是单线程的测试结果，粉色的曲线是多线程的测试结果。在多线程测试中，线程的个数等于虚拟机的vCPU颗数。可以看到，在单线程测试中，所有虚拟机的测试结果是非常接近的，因为它反映的是单颗vCPU的处理能力。在多线程测试中，vCPU以及内存的增加都会提高系统的性能，但是提升的幅度非常有限。例如，特大型主机（XXLarge）的vCPU数量是小型主机（Small）的4 倍，内存大小是小型主机的16倍，但是其pgbench多线程性能仅仅是小型主机（Small）的1.5倍。

数据库基准测试是典型的磁盘IO密集型应用，由于受到磁盘IO性能的限制，配置较多vCPU的虚拟机不能够发挥其计算能力方面的优势。

（2 分钟）

【defects – pgbench single thread】

在pgbench测试中，我们还发现了一些令人困惑的现象。同一规格的虚拟机，其pgbench单线程测试结果存在非常大的差异。就像这张图表所展示的一样，在存在问题的虚拟机上，pgbench单线程的性能只有正常虚拟机的1/10不到。在统一规格的虚拟机上运行同样的应用，竟然存在如此之大的性能差距，从常理来推断应该不是设计行为。因此，我们将这一现象定性为缺陷。

在大量测试的基础上，我们总结出如下几条规律：

1、这个缺陷可能出现在任何规格的虚拟机上；
2、在同一虚拟机实例上，测试结果是一致的（不会出现有时正常有时不正常的情况）；
3、这个缺陷并不显著影响byte-unixbench、mbw和iperf测试结果。换句话说，在出现缺陷的虚拟机上，处理器、内存和网络的配置应该是正常的。

（3 分钟）

【defects – iozone write results】

为了找出这个缺陷的具体原因，我们又对虚拟机的iozone测试结果进行了对比。由于PostgreSql缺省地将数据存储在系统盘上，我们这里仅对比了系统盘的测试结果。这张图表上的蓝色曲线是表现正常的虚拟机的磁盘写入性能，粉色曲线则是出现缺陷的虚拟机的磁盘写入性能。可以看出，在出现缺陷的虚拟机上，其磁盘写入性能与正常的虚拟机有非常大的差距，大概只有正常虚拟机的1/10甚至是更低。

（1 分钟）

【defects – iozone read results】

我们再看一下磁盘读取性能方面的比较数据。

这张图表上的蓝色曲线是表现正常的虚拟机的磁盘读取性能，粉色曲线则是出现缺陷的虚拟机的磁盘读取性能。可以看出，在出现缺陷的虚拟机上，其磁盘读取性能与正常的虚拟机没有本质差别。

刚才我们已经提到，数据库基准测试是典型的磁盘IO密集型应用。可以推断，出现缺陷的虚拟机后端的存储系统可能存在配置方面的问题。这个配置影响到磁盘写入性能，但是对磁盘读取性能没有显著影响。

（2 分钟）

【defect rate】

在这次测试中，我们一共创建了20台不同规格的虚拟机，其中7 台观察到了前面所说的缺陷。换句话说，在我们进行测试的可用域（Availability Zone）中，创建任意虚拟机出现缺陷的概率是35%。如此之高的缺陷概率，对于任何生产系统来说都是无法容忍的。因此，我个人不建议往HP Cloud Service上部署任何生产系统。

此外，如果你通过API自动地在HP Cloud Service上创建虚拟机实例，一定要重复验证每一个实例是否存在缺陷。

值得注意的是，这个缺陷的出现概率非常之高，对磁盘IO性能的影响也非常明显，应该可以通过简单的测试来找出问题的根源。因此，我们有充分的理由相信，HP Cloud Service的研发和运维团队，并没有对他们所推出的产品和服务进行最小限度的测试。恰恰相反，对HP Cloud Service进行测试的任务交给了像我这样的小白鼠。更重要的是，我在帮助他们寻找缺陷的同时，还要向他们支付昂贵的服务费！

（3 分钟）

【conclusion】

在开始的时候我介绍过，HP是第一家推出基于OpenStack的公有云服务的公司。我们在测试过程中遇到的缺陷，显然不是由于OpenStack本身所造成，但是它反映了OpenStack还缺乏一个商用系统中必不可少的监控和报警功能。由于类似功能的缺乏，HP Cloud Service的研发和运维人员长期以来对系统中的严重缺陷一无所知。所以，我个人还是坚持我之前的观点，OpenStack项目的成熟度还不够高，离一个商用系统的要求还是存在较大的距离。

从另外一个角度来看，基础构架服务（IaaS）是一个比较复杂的系统工程，不是简单地拿一个开源软件过来安装配置就能够搞定的事情。各种计算、存储、网络硬件之间的排列组合，操作系统、虚拟化软件、虚拟化管理软件的选择和配置，都会对云平台的性能产生巨大的影响。即使是HP这样具有雄厚技术实力并且亲力亲为参与OpenStack研发的著名公司，也会在生产系统当中出现重大缺陷。我个人认为，在系统集成和数据中心运维领域缺乏经验的中小型公司、研究所、政府部门，在构建自己的私有云或者是混合云的时候，应该积极与专业从事云计算的公司进行合作，借助其长期积累的经验和教训避免缺陷和提高性能。可以这么认为，开源IaaS软件的市场前景，在于基于开源IaaS软件为客户提供私有云和混合云方面的支持和服务。这就是Piston、Nebula和RackSpace这样的公司的价值所在。

我在一年之前发表过一篇题为《开源IaaS软件的比较 — 构架、功能、社区、商业及其他》的博客文章，其中最后一章引用了引用了鸠摩罗什大师所译的《维摩诘所说经》中有这么一句话：“先以欲勾牵，后令入佛智。” 一年后的今天，我依然认为这句话完美地阐释了开源IaaS软件的发展趋势。

分享