Hyper-V pk VMWare ESX
前言
在目前的虚拟技术市场上，VMware是掌握了绝对的市场份额。但微软公司即将正式发布的Windows Server2008中也整合了Hyper-V虚拟技术，看来软件的巨头微软公司已经将其触手伸向了这个越来越热的虚拟技术市场，毫无疑问，Hyper-V借助低廉的价格以及Windows的迅速普及，将VMware的垄断地位会有一定的打击。
有意或无意，在Microsoft Windows Server2008发布时间很接近的时候，VMware也发布了新的VMWare Infrastructure 3.5，Infrastructure 3.5包涵了全套的服务器ESX虚拟平台和管理套件。无论如何，巨头之间的技术和市场的直接竞争，对用户来说，尤其是对信息化预算投入不多的中小企业，还是好处更多一些。
测试目的：
在单一基于VMWare ESX的虚拟服务器上进行ERP压力测试，不断加大并发用户数来体现系统性能极限，另外在保持高性能压力的状态下，通过长时间运行疲劳测试以考察虚拟系统的稳定性。
测试方法：
建立虚拟服务器作为测试的服务端，采用PS-ERP最常用的物流功能6模块作为测试脚本，在客户端利用Loadrunner虚拟用户并发并记录系统资源占用、响应时间、通过事务数等参数。
测试用数据库系统为MS SQL Server 2005，数据大小为5G。5G数据库大约是一个中等规模企业使用浪潮PS-ERP的数据大小。
测试环境：
| 硬件组成 | 客户机 | 星盈G129-Q，Intel Xeon 5335*2，4*146G SAS 15K转/ RAID5/ 16G内存 |
| 服务器 | VMWare虚拟服务器 | |
| 网络 | 1000M交换机 | |
| 软件组成 | OS:
VMWare Infrastructure 3.5 Microsoft Windows Server 2003 Enterprise Edition ON VMWare ESX |
|
| Microsoft SQL Server 2005 with SP2 | ||
| 浪潮通软ERP-PS9.1 | ||
| Loadrunner8.1 | ||
| 测试脚本 | 浪潮ERP物流6功能模块 | |
评测工程师评点：
上次我们在Windows Server 2008整合的Hyper-V虚拟服务器上进行了ERP压力测试，这次我们利用VMWare ESX虚拟服务器，继续在同一套硬件平台上进行了同样的测试项目，以此来对比两种不同的虚拟技术不同的性能表现。
VMWare的虚拟服务器目前占据了大部分的市场不是没有原因的，其技术也有着自己的独特之处。在测试中VMWare的虚拟服务器表现稳定，即使是运行大压力的重要业务的应用程序也没有出现宕机，这和很多人认为的虚拟机只能跑非核心应用的观念有很大的出入，虚拟服务器同样胜任物理服务器所能做的大部分任务。
一、测试简介：
建立虚拟服务器作为测试的服务端，采用浪潮ERP最常用的6种功能模块对象作为测试脚本，在客户端利用Loadrunner虚拟用户并发并记录系统资源占用、响应时间、通过事务数等参数。
性能测试方面，对虚拟服务器进行ERP压力测试，通过不断加大并发用户数来测试系统性能极限；稳定性方面，在保持高性能压力的状态下，进行12-20小时左右的长时间疲劳测试来考察虚拟虚拟系统的稳定性。
硬件方面的物理服务器是配置较高的星盈G129-Q企业级服务器，星盈G129-Q是高集成度的IU机架式服务器，使用两路Intel Xeon 5345 CPU，16G内存，存储系统为4块15，000转的SAS 146G硬盘组成的硬件RAID5。该服务器先前在Windows Server2008中的Hyper-V进行过同样测试项目。我们给ESX的虚拟服务器划分同样的系统资源（4CPU以及8G的物理内存），以此来对比基于同样硬件平台使用不同虚拟技术的虚拟服务器的差异（Hyper-V测试结果见《全球首发！Windows Server 2008虚拟机ERP压力测试 》）。
二、性能测试：
性能测试的项目中我们为VMWare ESX 选取了和Hyper-V同样的测试并发数，分别是50、100、200、240并发的响应时间来进行对比。
图 1
图1、2两套虚拟系统性能比较（点击放大）
上图左边是本次的VMWare的测试结果，右边是Windows Server 2008的Hyper-V测试结果。为了方便各位对两种虚拟技术有更直观的比较，我们将它们都放到一起。简单的对比，除了库存入库单记帐模块在VMWare平台上响应时间比较领先之外，其他的5个功能模块都不同程度的落后于Hyper-V的虚拟平台。
不同的功能模块在不同的虚拟服务器系统中应该有着不同的表现，但VMWare和Hyper-V其实都是属于同一种虚拟架构的虚拟技术，都是裸金属架构，即都是虚拟服务器上的系统直接驱动底层硬件，而我们测试的都是在同一套硬件之上，安装的操作系统以及所使用的系统资源都是一样的，理论上这两种虚拟机上的性能表现应该是一样的，原来我们曾经在同一个物理服务器上进行过同样压力的性能测试项目，前后的测试成绩相差都不会超过10%。对于虚拟服务器，我们原来猜想也是如此，但现实往往在想象之外。
虽然现在对具体的原因还很难分析清楚，不过根据虚拟技术的原理，可以做出一个基本判断：不论是Hyper-V还是VMWare，虚拟层的主要作用就是给客户操作系统（微软称为访客操作系统）提供模拟的单独硬件环境，另外更重要的作用就是调度核心资源例如CPU、内存以及IO。实际上在之前的Hyper-V，还有这次VMWare测试中我们都发现，分配给虚拟机的虚拟CPU和物理CPU没有映射关系（当然VMware提供这个选项），测试中不论我们分配给虚拟机1个还是4个CPU，虚拟机的性能上限都变化不大。这就意味着在CPU资源调度这个关键功能而言，虚拟层都将所有的物理CPU当成一个资源池，根据虚拟机实时的资源申请进行分配。在我们这个场景的测试中，因为只有一个虚拟机，因此基本上物理CPU资源池仅仅保留虚拟层进程必要的CPU时间片，其他资源都可以按需要分配给虚拟机。
很明显，虚拟层进程的时间占用和对资源申请的调度效率就很大程度决定了虚拟机的表现。虽然VMware描述的技术是虚拟机直接在物理CPU上运行，但是对CPU资源的调度就像操作系统对处理器的调度一样，仍然是虚拟层的核心任务，而Hyper-V与VMWare在调度效率上显然有所侧重，这也没什么奇怪的地方。
实际上，VMware已经证明能够很好的支持异构操作系统，例如同时支持微软和Linux，而目前Hyper-V对Linux的支持还需要完善。目前我们还没有办法测试在完全异构环境下的资源调度效率，从这个意义上说，Hyper-V在Windows平台的优胜还不是两种方案的全部。
这其实是由于Hyper-V和VMWare ESX Server两种虚拟技术所使用的底层编译语言是不一样的，在硬件层和虚拟服务器客户机系统之间的虚拟平台，它实现的是客户机操作系统对硬件的驱动，但各自使用的方式及编译语言是不一样的。这好比BENZ和BMW，虽然都是汽车，都表现出相似的运动方式。但说到核心技术，诸如发动机、底盘、驱动方式、制动方式都有着自己的标准，所以差别并不少。
在深入研究过测试的数据后我们大致的发现VMWare响应时间比较慢的原因。对于VMWare ESX Server上的虚拟系统资源，有3种会比较影响性能的参数，1是对虚拟系统的资源保留值，即每个系统保留的CPU个数、内存大小，磁盘大小等等。2、是各个系统在物理硬件资源池中所占的资源权重，比如说多个系统都对物理资源申请调用时，哪得系统会得到优先使用权的设置。3、是虚拟系统资源的限制值（Limit），这个数值是指虚拟系统不能占用超过物理资源的百份比例。这三个设置其实是互相影响的，在物理服务机上安装的虚拟系统不多的情况下，如果没有对虚拟系统设置限制值，那么保留值的设置并没有太大的意义，因为只要物理资源有空闲的时候，虚拟系统提出申请，那么这些系统资源，尤其是CPU的计算能力，都是被虚拟系统所调用。
图3 IOmeter测试结果
在压力测试之余，我还特意的对两种虚拟平台上磁盘文件系统的性能做了IOmeter的性能测试。从上图可以看出，Hyper-V下的虚拟磁盘性能曲线平稳一些，而VMWare ESX 的磁盘对压力的表现更直观。就性能而言，在队列深度的不断增加，虚拟磁盘的读写速度差别不是很大，两种磁盘的性能都很接近，但在压力增加的时候，VMWare ESX 的下降趋势比较明显，这多少解释了为什么VMWare ESX 的ERP高并发时响应时间变得更慢的原因。
| 读写速度（MBps） | 队列深度 | |
| 物理服务器磁盘 | 29.172204 | 64 |
| VMWare ESX Server | 9.73768 | 16 |
| Hyper-V | 9.502278 | 32 |
表1 IOmeter磁盘峰值速度
从上表可以看出，虚拟文件系统与物理文件系统的差别巨大，性能仅仅是物理系统的30%！这就是为什么重要的解决方案例如高可用和容灾一定要在单独的阵列上运行。原因之一就在于虚拟文件系统实际上需要虚拟层的翻译。例如Hyper-v其实是在Windows 2008文件系统上创建一个扩展名为VHD文件来模拟虚拟机文件系统，所有对虚拟文件系统的操作实际上是对这个Windows2008文件的操作来实现。VMware给虚拟机一个单独的分区，但是根据测试来看，其虚拟机仍然不是直接操作物理磁盘系统。这样虚拟文件系统相当于所有的操作都要通过虚拟层的翻译，效率自然高不到哪里去。
在我们进行的虚拟机Windows 2008和Windows 2003文件传送效率对比测试中，虚拟文件就造成更惊人的差别：Windows2008的文件传输效率居然是Windows2003的9倍！主要的原因也出在这个虚拟机文件系统上。
因此对实际生产的系统而言，不论采用Hyper-v还是VMware方案，我们都强烈建议将虚拟机安装在单独的SAN存储上，而不要和虚拟层共同安装在服务器直连存储上！
三、稳定性测试
对于VMWare ESX虚拟系统的稳定性，我们同样的进行了100并发中等压力下的12小时长时间的压力测试来验证VMWare ESX系统的稳定性能。同样的，测试项目顺利的完成，没有出现宕机死锁的现象。在测试中VMWare的虚拟服务器表现稳定，这和很多人认为的虚拟机只能跑象备份、邮件等非核心低压力应用的观念有很大的出入，虚拟服务器同样胜任物理服务器所能做的大部分任务。
图4 长时间的测试结果
因为测试项目运行的时间很长，同样的ERP业务动作会被重复的执行很多次，而由于数据的冗余，执行的事务的时间会越来越长，最小和最大的响应时间之间会出现很大的偏差，所以在稳定性测试中，平均响应时间有更多的参考价值。值得一提的是，在稳定性测试中，VMWare每个模块的平均响应时间又都领先于之前的Hyper-V的同样测试的结果（见图）。难道VMWare对数据冗余有更好的优化技术？这个问题我们会继续咨询相关的技术人员，随后给大家一个合理的答案。
四、资源使用率
在进行压力的测试的同时，我们会不断的记录虚拟系统的资源占用情况，这也是从去年在物理服务器上测试时遗留下来的习惯。系统资源的占用情况会直观的表现系统的压力程度，不过在虚拟平台上，这就和我们的使用习惯相去甚远了。
图5 VMWare不同并发压力下的资源使用率
正如上文提到的虚拟资源的3个很重要的参数。没有添加限制值的时候，CPU资源的会自动进行动态的调配。持续长时间占用的100%CPU计算时间在物理服务器上是很少见到的，而在虚拟机上，不同的压力下，CPU也一直维持为接近100%的水平，这个现象在之前的Hyper-V上的虚拟服务器上已经出现过了，所以在这样高系统占用的情况下，只要虚拟服务器的计算申请没有达到或者超过物理服务器的资源水平，仍然没有宕机也不算奇怪。
这样的设置其实是体现了虚拟技术的最大特点，就是以不同应用来划分系统资源，将闲置的系统资源分配给合适的应用，同时保证每一个应用都最大程度的利用系统资源的，使物理服务器的硬件价值得到最大化的体现。
四、结论
图6 VMWare Infrastructure架构
VMWare ESX是VMWare Infrastructure的主要组成部分，ESX运行在物理服务器上的一个虚拟层，它将要调配的处理器、内存、存储器和网络资源抽象到多台虚拟机中。这大大的改变了以往一台物理服务器负责一个或多个主要应用的旧有习惯，提高了系统资源的利用率的同时，也很大的节约了服务器的摆放空间和能耗。现在的数据中心机房服务器托管都是按U计算费用，同时国家也出台了关于高能计算的单位能源损耗标准，无疑，虚拟技术的出现和普及有其必然性。
从本次在虚拟平台上的测试，如果单以物理性能来的衡量，测试的成绩虽然没有给我们带来太多的惊喜，但我们至少在虚拟平台上进行了高压力的应用项目测试。单个虚拟服务器的测试成绩不算很出色，不过我们并只划分了部分的硬件资源，如果全部利用起来就可以构造多个的虚拟服务器以应付不同的应用，在象VMWare的企业级的虚拟服务器平台上，依靠单台的物理服务器，架构出一个中小型企业的全部应用平台也不是不可能的。在虚拟技术这个大舞台上，微软还是VMWare，我们看看谁能笑到最后吧?
之前有网友评点过微软Server2008的测试，说目前虚拟系统的最大用途是用于测试。诚然，虚拟系统中有很多诸如快照这样的可回溯的功能，对一些破坏性的测试有很大的帮助。但经过我们的自己的测试，这样来定义虚拟服务器，确实是有点大材小用。由于时间的关系，VMWare ESX的一些其他的应用象是高可用方案（HA），VMotion管理等功能的测试会陆续进行，测试结果也会分批次的与网友见面。
【相关文章】
| 【内容导航】 | ||||
|
