OpenStack中国社区编者按：在云计算生态系统中，有两种类型的用户需要使用云计算资源：传统型(Traditional IT applications)和在互联网大潮下逐渐崛起云计算应用型(Cloud-aware applications)。国外广为流传的一个比喻是：在传统服务模式下，可以想象服务器就是IT的宠物（Pets），给他们取名字，精心抚养长大，当他们生病了，你得修复他们；在新形态的应用服务模型中，虚拟机被看做是农场中的公牛(Cattle)，名字通常都是编号，当他们生病了，你就杀掉他，用一头新牛代替。VMWare和OpenStack的云计算Vision、功能、特点对比正式这个战争或者说趋势的一个生动写照。未来的应用架构应该像对待农场中的公牛一样：VMware的“保养”、保护虚拟机的各种功能较比云计算型应用模式可能会逐渐变得越来越不那么重要。本文在国外广泛流传，热议不断，中国社区意译分享给大家，欢迎积极讨论。本文之前发表在中国社区网站，各大媒体广泛转载，评论也很多，现在发给中国社区微信朋友，希望没看的朋友不要错过：）

全文如下：

在Cloud领域，我们讨论最多的就是VMware与OpenStack的对比。事实上，这也是那些想使用OpenStack的人们热议的话题。我已经在SF Bay OpenStack会议中多次针对这个话题做了讨论，会议中很多朋友都希望我把这些讨论写下来。为了让读者能够更好地了解本文的内容，我决定通过两大云计算产品在数据中心应用的关键点对比的方式去完成本文的内容，内容可能包括：开放与非开放的软件系统，企业级传统应用与云计算应用，自由软件与授权软件，通过严格功能测试的产品与开放性功能的产品等。

本文中内容具体包括以下几个部分：设计、功能集、客户用例和价值，每点都以十分来评价，最终我们将以总分来决定赢家。

第一回合：设计

VMware软件套件是自底向上的架构，下端边界为虚拟机管理器。像VMware的vSphere和vCloud director产品都是依赖于免费的ESX(i) 虚拟机管理器， ESX(i)虚拟机管理器为他们提供了非常优秀的部署架构。本身VMware的软件套件也是经过全面测试过的，并且都有单一部署框架。总的来说，VMware的产品由于其架构的健壮性，很多高规格用户在多数据中心规模的环境中都有使用。换句话说，VMware的软件系统是封闭的，并且软件的发展路线是完全遵循VMware自己的发展目标，用户或消费者在此方面没有任何控制权。

OpenStack作为一个开源系统，没有任何一家单独的公司在控制OpenStack的发展路线。本身OpenStack是年轻的，还不满三周岁，但是他却具有巨大的市场动力，与此同时，很多大公司都在支持OpenStack发展（详见：OpenStack支持者）。有了如此多公司的资源投入，OpenStack的发展是多元化的。然而这也带来了问题，就是OpenStack部署和架构的实施和维护成本较比VMware有了陡然提高，与此同时，由于相对快速的版本更新速度，技术支持文档不能跟上产品的脚步。

VMware在设计方面稍占优势，这源于它优秀的文档资料以及便捷易用的部署和管理接口。OpenStack在这个方面也在紧追不舍，并且在硬件和虚拟机管理层其保持了它自身的灵活性，更是提供了多厂商支持。

第二回合：功能

VMware vMotion

vMotion是vSphere DRS、DPM和主机维护三大功能的合集。其中虚拟机动态迁移允许将一台虚拟机在零关机的情况下由一台宿主机迁移到另一台上，这原本是需要共享存储的支持的，但在vSphere 5.1中，VMware已经不需要通过共享存储实现动态迁移了。当一台虚拟机由一个宿主机迁移到另一个上时，虚拟机的内存状态和数据都要同步迁移过去。如果是共享存储的情况，实际上数据是不需要进行迁移的，只需要变化指向数据存储的链接而已。这在加速了迁移速度的同时也减少了在复制过程中网络的负载。

OpenStack 动态迁移

KVM动态迁移允许一个虚拟机由一个虚拟机管理器迁移到另一个，说的详细一点，你可以来来回回将一台虚拟机在AMD架构主机与Intel架构主机上进行迁移，但是需要注意的是，64位的虚拟主机只能被迁移到64位的宿主机上，但是32位的则有32位和64位两种选择。在动态迁移过程中，不能再对虚拟机进行操作，但是虚拟机内的用户还是可以在虚拟机内部继续进行工作的。KVM主要还是依赖于共享存储，某种程度上，这相对来说是需要一些资金投入的。

动态迁移需求：

虚拟机存储需要放在分布式文件系统之上，如NFS或在GlusterFS

Libvirt必须要开启listen flag

每一个计算节点（虚拟机管理器）都必须在同一个网络/子网当中

计算节点间的认证必须提前完成配置

DFS的挂载节点在每一个计算节点必须保持一致

OpenStack块存储迁移

在OpenStack当中，KVM支持块存储迁移，这也就是说虚拟机迁移不是必须需要共享存储的支持的。在块迁移的场景下，虚拟机的内存状态与数据都将被迁移，但是迁移操作也需要消耗两端的CPU资源并且操作花费时间较比共享存储来说要长一些。在某些用户场景当中，如果我们比较关注于主机的可维护性，并且不想花费过多经费，那么应用块存储迁移将是好的解决方案。同时，如果在没有共享存储的环境中，我们想对计算节点进行内核维护、安全升级，那么保证虚拟机服务不被打断，块存储迁移也是理想选择。

用户场景：

用户没有分布式文件系统，可能是由于企业的资金支持或者网络延迟，但是却想实现虚拟机的高可用性。

VMware DRS 和 DPM

基于vMotion，DRS可以动态监控虚机机及宿主机的当前使用状况，并且为宿主机的负载均衡提供支持。

用户场景：

部署阶段：可以对监控虚拟机执行自定义自动化脚本

监控阶段：DRS可以在ESX(i)主机上分布式部署虚拟机，并且持续监控活跃虚拟机和可用资源，以动态迁移虚拟机来实现资源利用率最大化

基于vMotion， DPM将虚拟机从低负载宿主机迁移掉，并且关闭以达到减少电能损耗。当负载增长，DPM将宿主机重启，并且部署新的虚拟机以满足负载需要。

OpenStack 调度器

OpenStack包含了对于compute和volume的调度器，通过一系列的管理员设定的规则参数和过滤器，OpenStack调度器将虚拟机部署到合适的宿主机上。在过滤器方面，调度器是非常灵活的，用户可以自己完成JSON格式的过滤器，并且过滤器还包含很多预定义的过滤器。虽然OpenStack调度器非常灵活，但是还是不能完全替代DRS，原因如下：

调度器用于选择哪个宿主机进行虚拟机部署的静态参考数据来源于Nova的数据库。换句话说，就是发现宿主机已经有了4台虚拟机了，那么我们需要选择一个新的宿主机去部署下一台虚拟机。

调度器只能在虚拟机部署阶段影响部署的位置，一旦部署完成，虚拟机运行后则无法挪动虚拟机了。如果需要基于动态数据进行调度，那么调度器需要与外部监控解决方案如Nagios合作。总而言之，目前OpenStack调度器将只会对部署虚拟机环节有影响。

VMware High Availability(高可用)

在vSphere中，虚拟机级别的高可用性是允许在虚拟机或者ESX(i)主机出错时，在不同宿主机部署相同的虚拟机。这里不要和容错（FT）机制混淆，高可用的意义在于当有一些东西出错了，可以在一定时间内自我修复。高可用是在硬件出问题的时候保证虚拟机的正常个工作，如果真的出错了，那么只能在不同的ESX(i)主机上启动虚拟机，这也可能造成服务的中断。

OpenStack High Availability(高可用)

目前并没有官方声明OpenStack支持虚拟机级别的高可用性，这个特性在Folsom版本被提出，但是后续又被放弃了。目前OpenStack有一个孵化项目Evacuate, 其作用是为OpenStack提供虚拟机级别高可用支持。

VMware Fault Tolerance（容错）

VMware容错机制是通过监控虚拟机的状态和所有变化，将这些变化同步到第二台备份ESX(i)服务器之上。容错的概念在于无论是主还是从宿主机出现问题，只要一方能正常工作，那么宿主机上的虚拟机都保持正常工作。抛开营销中的噱头，这种机制还是无法解决虚拟机中的应用程序崩溃，因为一旦一方崩溃，则这个变化也会同步到从节点，当你停止虚拟机的服务去修复它，从节点也会同样停止服务。所以这个机制只能保证单点失效的问题不再出现，而真正的应用层面的容错则需要MSCS或者WCS来解决。考虑到其他方面如最高资源使用、内存、硬盘、CPU、带宽的容错，这些方面都有局限性，并且是使用量相对比较小的功能。如实现这些则这需要双倍的内存，由于内存不能跨主机复制，并且还需要CPU lockstepping去同步每一个CPU指令。这将导致只有单独一个虚拟CPU被容错机制所监控。

OpenStack Fault Tolerance（容错）

在OpenStack中没有针对于容错的功能，并且截至目前也没有计划去完成这些功能。未来，KVM也不再支持镜像操作功能。

我们可以看到，在功能的支持方面和功能细节，OpenStack与VMware还是有差距的，但是这对OpenStack还是有优势的，因为较比VMware的昂贵价格，OpenStack免费、开放的优势显现出来。VMware高投入带来的功能，OpenStack大部分可以免费提供给客户。

从VMware在功能方面的领先可以看出，VMware还在继续研发除了vMotion、高可用、容错以外其他的新功能去保护他们的虚拟机；OpenStack一方面跟随VMware的脚步，另一方面他们投入精力在支持更多硬件厂商解决方案的上面。

第三回合：用例

在我们评价上述功能的价值之前，首先我们需要考虑用例问题。在云计算生态系统中，有两种类型的用户需要使用云计算资源：传统型和云计算应用型。云计算应用型用户将自己处理HA和DR策略，而传统型用户将依赖于云平台提供的HA和DR。看下面出自VMware云计算架构文章的图表。

云计算型应用共同特点

分布式

无状态、软状态

失效切换在应用端

扩展性在应用端

传统型应用共同特点

客户端-服务器架构

难以横向扩展

失效切换在服务端

扩展性在服务端

传统型应用将需要如FT、VM级别的高可用性、自动病毒扫描等功能，而云计算型应用则不需要，当一台虚拟机出问题后，新的一台虚拟机将替代它。

Pet vs. Cattle

换一种思路去想这件事，那就可以从微软 William Baker的出名文章 Pets vs. Cattle 的比喻看出OpenStack和Vmware的关系。

比喻是这样说的：在传统服务模式下，你可以想象你的主机就是你的宠物，你给他们取名字，比如dusty、cern等等，他们被精心抚养长大。当他们生病了，你得修复他们。在云计算型应用服务模型中，虚拟机被看做是农场中的公牛，他们的名字通常都是编号，牛和牛长得也差不多，当他们生病了，你就杀掉他，用一头新牛代替。

未来的云应用架构应该像对待农场中的公牛一样。VMware的保养、保护虚拟机的各种功能较比云计算型应用模式变得越来越不那么重要了。

在这轮比赛中，OpenStack追了上来，虽然VMware有很多OpenStack所不具有的功能，但是针对云计算型应用，这些功能变得不那么重要。未来，你很可能为那些你用不上的、不可控的VMware添加功能买单。

第四回合：价值

现在是最后一回合，我们将决定比赛结果。虽然，OpenStack还是VMware更有价值，这个问题并没有很清晰的答案，并且答案也取决于部署规模。虽然OpenStack是免费使用的，但是他需要有大量工程资源和领域专家才行，并且他还需要很多架构和搭建方面的工作，因为它支持很多部署场景，并且安装过程都不尽相同。VMware则需要花费一些经费购买权限，并且相对来说更加容易安装和运行，另外较比命令行，VMware则学习成本更低一些。

总得来说，OpenStack入门门槛较高，但是随着项目规模的扩大，你将从中受益，因为不必支付高额的版权费用。VMware虽然在小规模安装时相对容易，但是随着规模扩大，事情就变了。这就是说，随着云应用大规模化，大家也更加熟悉OpenStack，那么OpenStack的入门门槛就低得多了。

胜利者是：OpenStack

在云计算领域，OpenStack和VMware这两位重量级玩家，VMware在功能和架构上稍微领先，但是OpenStack作为一只弱旅，却在第三回合迎头赶上并在最后一回合给予对方毁灭性打击。

后记

巧合的是，在写这篇文章的时候，VMware股价在一月29日一天就下跌了22%,市场分析称VMware缺乏清晰、优秀的云计算策略。

我也了解为什么大家不同意我的给分，并且不明我为何在四轮对比中权重相同。说实话，这个评分不是那么完美，也没有那么客观，但是他有他的存在的意义，他让这场云计算这场战争变得更加有趣，请大家积极评论并提出您的观点。

译者补充：针对此文章精华评论

OpenStack社区：Toby Ford

这是一篇非常出色的深入挖掘两者区别的文章，比如 Pets vs. Cattle的比喻就非常好，另外，我认为评价标准应该再增加几个纬度。

在DRS与OS Scheduler对比中，目前，DRS对比OpenStack Scheduler是有优势的，因为DRS采用各种关键指标去决策部署虚拟机时的主机节点选择，另外，DRS还会对虚拟机整个生命周期进行监控。

但是，DRS是封闭的，这些权重指标都无法配置，举一个简单的例子：如果在晚上很短的时间内，CPU的负载突然增高，这并不意味着我们需要将虚拟机迁移到另一台宿主机之上，或者如果管理员知道在未来一段时间将会虚拟机将会发生一些问题而又不想DRS介入其中，这就变得非常难办了。相反，OpenStack Scheduler则会逐步与DRS拉开距离，特别是当其变得更加可扩展。

针对为什么说vMotion采用动态/全生命周期地去维护虚拟机很重要：vMotion/DRS/HA都是处理传统型虚拟机的必备功能，显而易见，这跟虚拟机的类别其实没什么关系，而我要说的是vMotion/DRS 对于资源的最大化利用还是很重要的。

在我们的实际环境中，我就因为需要自定义调度规则而不得不关闭了DRS，虽然我们自定义了调度规则，但是VMware的升级使这种自定义的调度器变得非常难以维护。

我想要说的是，OpenStack不单单面向cattle模式的应用场景，对于处理pets模式的虚拟机也会越来越好。

文章转载自 开源中国社区[https://www.oschina.net]