企业的虚拟化早已上路

以 Amazon EC2 为代表的云服务已经将虚拟化推向了 IT 界的前台。云服务是基于虚拟化最受欢迎的特征之上建立的，即其能在硬件上很快地安装新的虚拟机。云计算的核心前提是首先拥有大量的基础设施，并且有冗余的容量可以售卖给有需要的客户。云计算本身拥有大规模基础设施的灵活性和结构，同时又能分成小块的形式出售，从而满足相对较小系统的需求。

虚拟化受欢迎之处并不仅仅因为它能将过剩的容量立即转化为新的虚拟服务器。它真正价值体现在一些更高层的优势上，例如高可靠性、灾难恢复和应用的快速安装。目前，系统管理程序 (hypervisor) 已经成了一件商品，几乎每个虚拟化提供商都已经提供了它的实现。其中，Xen 系统管理程序的开发通过免费和开源的社区形式进行。ESXi 是 VMware 企业级系统管理程序中占用系统资源最少的，从这个月开始它也可以免费下载了。不过，这两个产品系列的最复杂功能特性还是需要通过商业渠道购买。

这篇文章将探讨虚拟化的部分高层优势和它们在实际中的应用。更重要的是，我们会细致讨论 Contegix 是如何实现虚拟化和利用其解决较复杂问题，以及应用 Contegix 的时机等问题。

除快速装备这一优势外，虚拟化对企业的价值还有很多，其中最重要的几个就是资源利用的最大化、应用的高可靠性以及应对灾难时业务的连贯性。每个 CIO 和 CTO 都会把这类需求摆在显著位置，而这正是虚拟化的专长。

云计算目前还不是非常流行的企业技术部署平台，并且有可能永远会处于不温不火的状态。要知道，许多企业的制度是不允许在云上部署应用的。对供应商的不信任和对其是否会遵守规范的怀疑也是限制云计算应用的因素。对法律的和违约后的潜在负面影响的解释已经变得不那么容易了，这些都是诸如健康保险便利和责任法案 (Health Insurance Portability and Accountability Act ,HIPAA) 和萨班斯·奥克斯利法案 (Sarbanes-Oxeley ,SOX) 等一些法案的出台造成的。就算以上这些障碍都已克服，企业将所有的东西都搬到云上也并非易事。

然而，这并不意味着由于充分利用资源而得到扩展上的灵活性会跟这些组织无缘。在专有的计算资源和网络基础设施上实施的虚拟化是解决这个问题的核心。实质上，这些公司正在构建和应用私有的云（确切地讲是私有的云风格的架构）。

VMWare 和 Citrix XenServer 可以使物理硬件资源得到充分利用。它们能在虚拟化集群中平衡虚拟机资源需求和物理服务器容量。当一个虚拟机启动后，虚拟化栈会为其分配物理服务器资源。

大部分虚拟化栈拥有驱动高可靠性应用的能力。这并不完全是为了对诸如 Oracle Coherence 和 Microsoft Cluster Server 的集群技术进行补充。设计这些的目的是为了解决发生在硬件层面的一些故障和提高一般应用的可靠性。

这些应用的高可靠性一般是通过多点主从备份达到的。首先，请求会被发送到活动的主节点。如果活动的主节点没有回应，一个备份节点会被升级为活动主节点，请求会被发送到这个新的主节点。这么做的缺点原来主活动节点的内存中的数据会丢失，这个问题仍然没有得到解决。

这个问题可以通过 VMWare’s VMotion 和 Citrix XenServer XenMotion 等实时迁移技术 (live migration capabilities) 得到解决。通过这项技术，我们可以将一个运行中的虚拟机从一个实体机器迁移到另一个实体机器，在这个过程中硬盘和内存中的数据都不会丢失，甚至网络连接都会得以保持。这一点是通过虚拟机内存状态和执行状态的复制完成的。要知道虚拟机的配置和所有的状态都存储在共享存储空间中。

如果一个装有虚拟机的服务器宕机了，虚拟栈探测到故障后将在另一台服务器上激活复制的虚拟机。虚拟机的迁移过程中 , 原来机器的核心状态将得以保持，其中包括精确的执行状态、网络 ID 和活动的网络连接。这么做保证了零宕机时间，因此不会对用户的产生负面影响。

通过对资源调度、虚拟机实时迁移、企业存储系统复制等技术的整合，企业的连贯性得以保证。虚拟机可以方便地由一个虚拟集群复制到另一个虚拟集群，这种复制是独立于底层硬件的，并且不必考虑距离远近的问题。

尽管 Software-as-a-Service (SaaS) 一直保持着高姿态，市场还远未达到成熟的程度。这个局面是由多方面因素造成的。普遍存在的一个因素是基础设施投资占到了 SaaS 初期资金中很大一部分，而非大家常常认为的开发成本，因此达到预算平衡需要一段相对长的时间。SaaS 头一个用户往往花费不菲，而后续用户的价格会慢慢变低。另外 SaaS 部署在保持一定连续性的同时必须创造出一定的灵活性，以满足客户的修改要求。

一般的 SaaS 用户并不会在乎和关注厂商在基础设施上的大笔投资。典型的 SaaS 销售并非只适合于美国运通企业卡持有客户，虽然在公司内部软件的购买需要得到许多 C 级执行官的许可。因此，SaaS 厂商必须制定一个合理的价格策略，而非只考虑着收回基础设施的投资。需要补充是，除了硬件购买费用外，基础设施费用还包括长期的部署费用、支持和管理费用以及应用发布后的维护费用。

在谈完基础设施方面后，我们将集中谈谈 SaaS 的部署。SaaS 应用平台应该集中关注其可复制性。每个 SaaS 应用实例都应该大体相同。差异的最小化可以使每个客户的应用实例做到基本一致，也同样有利于技术支持人员进行故障诊断。单独的某个客户实例上 Apache 模块丢失这类问题，技术支持工程师们大都不愿意去解决，这正如客户也不愿意看到自己订购的实例出现问题，而这个问题是由于 SaaS 公司不能重现某个实例的操作造成的。复杂性上的最后一点还在于，从一致性和成本上考虑整个过程需要做到自动化。

（当然也存在例外情况，如应用数据、部署实例数据和潜在的可扩展性参数；然而，这些对应用来说只是修饰性数据和用户数据。在为不同的客户配置应用时，这些数据是本应单独设置的。）

为什么会有这种一致性的问题呢？了解目前应用——不管是 SaaS 应用还是传统应用——部署的复杂性是问题的重点。即使最简单的 web 应用，其本身也不会负责管理底层的数据存储层, 这通常会交给数据库特别是诸如 MySQL, PostgreSQL, Oracle 和 SQL Server 的关系型数据库系统。这些再加上诸如 Java 或者 Rails 的 web 栈组成了一个多层可扩展部署的架构。例如，一个 Rails 应用可能会需要 Apache,Mongrel 集群,memcache 和 MySQL。

最初的安装和应用基础设施间的互相缠绕并非是部署时候值得注意的唯一问题。应用的模块通常会需要特定的资源。为了保证其可用性、行为一致性和防止资源匮乏，给不同的模块分配特定的资源是非产好的选择。例如，一个 Mongrel 集群或者 Tomcat 实例会被分配一定的 CPU 和 RAM 资源，同时相关的数据库也会分配到自己单独的份额。这么做可以很好的防止由于长期独占而造成的资源缺乏。

此外，应用的敏捷本质使得通过插件、宏和 mashups 进行扩展变得容易。为一个单独实例做的扩展可能不会应用到所有其他企业实例中去。当一个客户（或者共享应用基础设施的一组用户）出现了问题，首要的事情就是隔开故障系统以避免对其他用户的潜在影响。SaaS 客户可不想看到其他客户造成的资源受限环境导致的问题。

满足这些需求的方法有很多。从基础设施方面考虑，虚拟化技术可以从云计算的角度来解决硬件问题，因为云计算是支持规模增长的。同时虚拟化在部署管理、支持和维护方面的优势也是经过实践验证的。此外，虽然也可以应用 Cfengine 和 Puppet 等工具做到物理硬件方面的部署一致性。限制资源的应用同样可以通过系统某些特殊功能达到，例如 Solaris zones 和通过 /etc/security/limits.conf 文件操控 Linux PAM。这些工具绝对好用。然而，虚拟化是解决这些问题的更好的方法，它能带来许多本质上的好处。虚拟化能实现计算机科学上的一个核心概念，即关注分离。

将应用分割成“在功能上重叠尽可能小的独立部件”（引自 Wikipedia）是关注分离的前提。在虚拟化上，这个概念很适合用于基础设施上。人们可以在每个应用、每个客户或每个集群的基础上进行关注分离，这么做可以在充分利用底层硬件容量的同时拥有垂直和水平的方向上的扩展的能力。这对想进入 SaaS 市场的单租用应用（single tenant applications）特别有用。它可以以近乎零代码修改的代价在底层硬件上部署多重承租 (multi-tenancy) 实例。

在 Contegix 的 SaaS 平台上，有两种通用的部署模式。两者区别在于应用是如何开发——每次部署支持单个客户还是每次部署支持多个客户（单重租用 (single-tenancy) vs. 多重租用 (multi-tenancy)）。

在单客户 SaaS 中，用于发布客户应用实例的虚拟机数量很少，通常只有一到两个。例如，一个虚拟机承担整个应用从 Web 层到数据库层所有的功能，或者将这些分配到两个虚拟机上，每个负责其中一部分的任务。利用资源的虚拟配置能力，更多的 CPU 核可以快速地配置给某个 PostgreSQL 虚拟机。动态资源配置 ( Dynamic Resource Allocation) 可以将虚拟机快速地迁移到一个能够满足资源需求的物理机器上。

另外一种通用的的部署模式提供了更高程度的分离。底层的基础设施上的应用被分配在多个虚拟机上，每个虚拟机都可以在需要的层面进行扩展。例如，一个应用由一个 PostgreSQL 数据库、两个承载不同 Java Web 应用的 Tomcat 容器组成，另一个应用为 Rails Web 应用 Mongrel 集群，这两个模块会被配置到两个单独的虚拟机上。比单租户模式进步是，这种模式在虚拟机资源和实例个数方面不仅仅只支持单个模块的扩展。所有的 Web 层都会利用 nginx 或者 Apache 代理进行包装，这样可以做到对前端客户透明的无缝切换。而在文件层次的多机数据访问会利用共享网络或者基于集群文件系统的块设备。再次强调一下，这个模型非常适合在大规模实例或者多客户应用中采用。

对两种部署模型来说，将操作系统和应用程序的安装与应用数据分离是至关重要的。这涉及到升级的处理方式。操作系统和应用程序的安装可以说是易失性的，重做或者版本更新都是常事。升级后的操作系统、应用和配置会覆盖老版本。这更说明了如果要发布一个应用的话，发布的机制是非常重要的。

采用虚拟化的方式发布应用有很多内在优势。前面提到的虚拟化的一个特征——可以将虚拟机由一个机器迁移到另外一个机器——是一个关键的优势。如果采用物理硬件上的解决方案 (如 PAM )，那么就要求在宿主操作系统的层面移动用户数据和同步配置文件。除此之外，虚拟化能支持快速构建、开发、对虚拟机进行沙箱测试和应用标准工具进行比较等。还记得可以在两个映像间运行 Unix 的 "diff -r"命令或者进行 MF5 校验和运算吗？

就像任何行业新概念一样，虚拟化有成为一切新旧问题解决方案的趋势。但是事实是虚拟化并非对所有的系统和应用都合适，例如有些对资源要求很高的应用。而这种情况在高速 I/O 环境中是比较普遍的，例如大规模数据服务器和高强度 UDP 网络。

获得合理方案的方法很简单，实验、实验再实验。

作者简介：

Matthew E. Porter 是 Contegix LLC 公司的 CEO。 在 Contegix 创办之前，Matthew 是 Contegix 的母公司 Metissian LLC 的合伙人。Matthew 毕业于 St. Louis 大学计算机系并获得学士学位。

阅读英文原文： More Than Just Spin (Up) : Virtualization for the Enterprise 。

感谢郭晓刚对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。