分类： 虚拟化
2011-03-25 14:00:37
说起免费的VMware Server，浮目前人们脑海里的第一印象就是：这非常可能是拿来用作研究用的，肯定不如商业产品性能好、够稳定。所以在考虑构建结构复杂、需求稳定的商业虚拟化系统时，这种根深蒂固的偏见首先就把VMware Server排除在外。
事实真的如人们所想的那样，免费的VMware Server就真的那么不稳定吗？我们有必要来回顾一下历史。还在VMware推行他宏伟的虚拟化蓝图之前，ESX Server的上一代版本GSX Server已销售了五年之久，他当时的售价接近目前的ESX Server。和ESX Server相同，GSX Server也是专注于数据中心的布置，后来VMware发布了企业管理工具VirtualCenter，能使管理GSX Server和 ESX Server完全相同。
自从2001年VMware推出GSX Server至今，已有300多家著名大公司采用了该系统。2005年末，VMware终于推出了该公司史上第一款虚拟化产品VMware Play。接下来，又做出决定把即将推出的GSX Server 4.0转为免费，并重新命名为Server 1.0。这就是VMware Server的由来。
既然Server的前身GSX Server经过了那么多稳定性的考验，那么我们也有理由对其抱有信心，而未必将他认为是研究用的测试品。
[NextPage]
性能：ESX Server更强
撇开价格的因素，购买人员要考虑的更有性能的要素。目前还没有在同一硬件、同一虚拟机的两平台下的性能比较报告，不过系统构建方式的不同还是能使我们推测出两者性能的差异。
VMware Server需要一个底层的操作系统的支持才能运行，而其同门大师兄ESX Server却不必，他采用的是一种业界称为bare metal的解决方案。也就是说ESX Server部分起到了操作系统的功用，他能充分调动硬件资源去实现各种虚拟化下的任务，这一点和虚拟设备类似。
由于VMware Server和ESX Server设计方案的不同产生了不同的性能表现。Server有主机OS的束缚，无法完全利用硬件资源；而ESX Server则极力压缩了OS层，使得虚拟机尽可能直接面对硬件，调动资源的效率更高。
ESX Server这样设计的好处不仅体目前性能上，他还带来了更高的合并率。合并率指的是同一台服务器中的每个CPU内核能正常处理的最大虚拟机数量。VMware官方推荐的合并率：Server为2-4，而ESX Server则为4-8。从中不难看出ESX Server 的优势所在。
不过合并率是要受到虚拟机上的负载量和内部应用程式运行状况的影响。一个工作状态非常忙的ESX Server可能每核的合并率达不到3；相反，一个状态非常轻松的Server 则有可能每核支持十个Web服务器。
总得来说，从架构分析及其带来的性能和合并率的差异能看出VMware Server和ESX Server之间的差别。但同一个特性，从另一个角度来看，好处也有可能变成缺点。
[NextPage]
方便性：VMware Server更好
比如，ESX Server直接控制硬件带来性能提升的一个具体表现：VMFS，这是VMware自己研发的一种文件系统格式，用于存储虚拟机数据。相比目前OS提供的多功用文件系统格式，VMFS读取更快、更可靠。不幸的是，以VMFS格式存储的虚拟机想要迁移到VMware其他的虚拟环境下，却不得不面临转化格式的繁琐和风险。同为VMware环境下的迁移已是麻烦不断，其他环境就更不好说了。
相比而言，VMware Server没有采用VMFS，他的性能只能取决于主机OS，如视窗系统或Linux的文件系统，但其虚拟机文件却能烧录在DVD或存储于USB设备中，方便地在各计算机间传输，我们甚至能把他理解成一个拥有许多文件的标准目录。
除了文件格式带来的迁移和传输的困难，ESX Server还面临着驱动的问题。比如说VMware没有给ESX Server装载本地SATA接口的硬盘，所以ESX Server的用户不得不考虑本地SCSI接口硬盘，或远程的存储设备，像NAS、SAN之类。
驱动的短缺不仅会影响某个硬件设备的使用，还会影响到整个系统的运行。VMware出于战略上的考虑，只是对市场上一部分硬件提供了官方驱动支持。所以 说，不是所有数据中心的硬件都能运行ESX Server。相反，Server依附于底层的OS，而这些OS一般都提供了丰富的驱动，大大扩展了Server的使用范围。像OS支持的远程iSCSI硬盘连接、本地磁带备份单元等，都能被Server虚拟机所支持。
应用软件的可用性和支持度也是两者差别的一个方面。ESX上除了一些固有的有限的服务程式和工具外，用户自行安装新的软件一般会由于缺乏必要的库文件而无法运行。可想而知，解决这个问题对于一般用户来说简直就是天方夜谭。
这样设计的确降低了安装不明软件带来的风险，但和此增加的是用户无法自主的烦恼，VMware也没有提供所有的辅助工具来帮助解决问题。Server由于
底层OS的支持，一如既往地保持着良好的可用性，用户能自行在上面安装磁盘碎片整理工具、备份工具、性能监视器、远程管理等。
[NextPage]
安全性：两种模式，各取所需
安全性是两个产品不同的另一个重要方面。ESX Server具有虚拟设备的所有特点：自封装的专用系统、针对性能进行的优化、最小的攻击界面，更有预设置的应用程式（比如防火墙、防毒软件）。ESX Server内部只有一些必要的管理工具，厂商并不支持用户自行安装所有可能带来安全漏洞的软件。
从有利的角度来说，ESX Server这种虚拟设备的方案简化了系统维护的手续，净化了系统的安全，同时管理者无需再关注系统补丁的发布。只要有新的漏洞出现，用户只需等待 VMware提供最新的系统替换文件。以上措施直接的好处就是降低了TCO（total cost of ownership）。
然而，在用双刃剑一面杀敌的同时，也有可能被朝向自己的另一面剑刃所伤。在ESX Server中，由VMware给我们补漏洞是一件省心的事情，但如果VMware延迟了发布时间呢？我们有漏洞的系统岂不是暴露在各种网络攻击之下，这是件非常让人不安的事情。
前面更有提到的就是ESX Server的黑箱封闭系统不容许用户进行操作，也就是说用户对系统没有完全的控制权，对于某些公司来说是不可接受的。他们能选用完全可操控的 Server，然而这一个好处站在另一个角度又成了缺点：这意味着需要有大量的专业知识，知道该怎么去巩固、健全和保卫这个系统，其中重要、也是最花时间 的工作就是不断寻找、测试、发现和修补系统的漏洞，如果你不想被恶意入侵的话。
你每天要关注最新的安全公告，下载安全补丁，然后安装完毕。但这并没有结束，我们知道，安全漏洞补丁虽然补上了系统漏洞，但有时却会影响到整个系统的稳定性。评估升级后的系统是否比升级前了的更可靠，这又是个重点。
当然了，不是说采用了Server类似系统的公司就必须要成立一个专门的研究实验室，得有昂贵的检测仪器，更有QA小组专门负责此事。不过总得付出一定的代价请得一些专门的技术人员来管理系统，毕竟这是关系企业安全的大事。
以上两种选择方案：要么完全操控式方案，升级测试完全自己做主；要么选用黑箱式方案，把这些升级测试的烦事交给厂商（比如VMware）。两种选择要看那种符合自己的需要，个人觉得如果不是太重要的服务器，能采用第一种方案。如果是需求稳定性比较高的虚拟环境，第二种方案更为保险一点。
[NextPage]
安全性：两种模式，各取所需
安全性是两个产品不同的另一个重要方面。ESX Server具有虚拟设备的所有特点：自封装的专用系统、针对性能进行的优化、最小的攻击界面，更有预设置的应用程式（比如防火墙、防毒软件）。ESX Server内部只有一些必要的管理工具，厂商并不支持用户自行安装所有可能带来安全漏洞的软件。
从有利的角度来说，ESX Server这种虚拟设备的方案简化了系统维护的手续，净化了系统的安全，同时管理者无需再关注系统补丁的发布。只要有新的漏洞出现，用户只需等待 VMware提供最新的系统替换文件。以上措施直接的好处就是降低了TCO（total cost of ownership）。
然而，在用双刃剑一面杀敌的同时，也有可能被朝向自己的另一面剑刃所伤。在ESX Server中，由VMware给我们补漏洞是一件省心的事情，但如果VMware延迟了发布时间呢？我们有漏洞的系统岂不是暴露在各种网络攻击之下，这是件非常让人不安的事情。
前面更有提到的就是ESX Server的黑箱封闭系统不容许用户进行操作，也就是说用户对系统没有完全的控制权，对于某些公司来说是不可接受的。他们能选用完全可操控的 Server，然而这一个好处站在另一个角度又成了缺点：这意味着需要有大量的专业知识，知道该怎么去巩固、健全和保卫这个系统，其中重要、也是最花时间 的工作就是不断寻找、测试、发现和修补系统的漏洞，如果你不想被恶意入侵的话。
你每天要关注最新的安全公告，下载安全补丁，然后安装完毕。但这并没有结束，我们知道，安全漏洞补丁虽然补上了系统漏洞，但有时却会影响到整个系统的稳定性。评估升级后的系统是否比升级前了的更可靠，这又是个重点。
当然了，不是说采用了Server类似系统的公司就必须要成立一个专门的研究实验室，得有昂贵的检测仪器，更有QA小组专门负责此事。不过总得付出一定的代价请得一些专门的技术人员来管理系统，毕竟这是关系企业安全的大事。
以上两种选择方案：要么完全操控式方案，升级测试完全自己做主；要么选用黑箱式方案，把这些升级测试的烦事交给厂商（比如VMware）。两种选择要看那种符合自己的需要，个人觉得如果不是太重要的服务器，能采用第一种方案。如果是需求稳定性比较高的虚拟环境，第二种方案更为保险一点。
