彩票走势图

在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的脚步，另一方面他们投入精力在支持更多硬件厂商解决方案的上面。

本文转载自