通过虚拟化构架节约成本

　　基础架构虚拟化不再只是厂商(如 Unix, Intel )和运作团队所关注的技术问题了，它正在日益成为诸如数据中心配置( provisioning)、服务交付，以及更重要的、可以有效控制成本的服务器整合的关键因素。和很多先进的技术一样，虚拟化技术从经济上和运作上看，也是优势与不足并存。运作团队也许更喜欢传统的操作方式，尤其在传统技术的能力和工作负荷管理方面。

　　据META Trend表示：到2003/04，IT运作团队会在促进业务单元重整以及实施更有效的自动化策略上进行大量的投资。这其中最重要的包括放弃垂直的、特定平台传输，重整不一致的处理过程，加速平台向 Intel 架构(Windows and Linux：2004-10)转换/迁移，并建立健壮的、可有效测量的系统。到 2007 年，这些运作上的改进将成为标准的计划和支持的一部分。

　　简要回顾

　　架构虚拟化并不是一个很新的技术，早在上世纪60年代末到70年代初，大型机用户就已经体验了虚拟化带来的好处。那时候IBM所提供的虚拟机技术基本为两种形式，它们都是在位于硬件层之上的微代码层实现的。其中多虚拟机形式是通过VM(虚拟机)实现的，而逻辑分区则是通过更传统的MVS(多虚拟存储)大型机来实现的。在实用使用中，虚拟化可以提供更快的预配置能力，因此和那些专门为某种目的设计的解决方案相比，用户可以更主动的利用架构特性。在较早时期，真正的计算资源非常昂贵，因此那时候的虚拟化技术的另一个优势就在于它可以支持临界虚拟资源。由于过去十年 Unix和Intel的系统平均使用率不足30%，因此这种技术使得系统可以通过更充分的利用硬件以支持更多的用户，获得更好的投资回报，这也解决了经常性业务和财务管理者所面临的问题。

　　三十年前，IT部门所面对的问题是没有足够的实际的计算资源。现在他们有了另一个麻烦：过剩的实际计算资源在不断的提升计算任务的成本。成熟的虚拟化技术和类似虚拟化的分区技术可以改变这种状况。大型机的架构虚拟化在发展了 30 年后，现在到了一个新的起点，即用在 Unix 和 Intel 平台上。不过其目的都是一样的，即实现更灵活更快速的配置( provisioning )，更好的在单一 SMP 平台上运行多个独立的工作负荷。

　　Intel 的关键动力源 : 简单非协同应用

　　随着应用程序架构逐渐向“非协同”应用服务器转变，并驱动后台数据库服务器，前台应用的错误虽然会比较烦人，但是已经不会产生很大的危害了，因为所有实际的应用都可以通过数据库来调节和恢复。另外，虽然数据中心分析指出，遗留系统会在未来三到五年内被 Intel 系统超越，但是数据中心的一个关键的制胜策略却是一个简单的事实：针对新应用程序如 SAP R/3的应用服务器，其消耗的计算能力是数据库的8-10倍。因此，会出现日益增多的更“简单的”应用服务器与大型的复杂数据库服务器共存的情况，如 图 1 所示(描绘了过去多年到未来五年内的高端数据中心的情况)。实际上，当考虑到应用架构和一些 Web 服务特点的因素， 75% 的应用需求都可以通过开发简单的 1-2 路的服务器来实现(根据摩尔定律，处理器的能力每18个月翻一倍)。虽然这个分析没有涉及到 Linux，但我们可以发现Wintel平台在五年前就已经开始在数据中心市场上占有一席之地了，这不是因为其稳定性，而是因为其使用量的增加和“简单化”的应用服务器。

　　而由于计算的增长重点还在于简单的应用服务器(如 1-2 路服务器或刀片服务器，其能力都是数据库服务器的 6-10 倍)， Linux 作为简单应用服务器正在对 Windows 构成严重威胁，这种威胁就好像当初 Windows 对 Unix 所作的一样：为每年增长 60% 的市场提供更廉价、足够好的应用服务器。

　　合理的虚拟化整合

　　运作团队与数据中心都面临两个与架构有关的挑战：

　　降低成本：提供改进的硬件、软件以及更高的员工工作效率。

　　加快市场响应时间：提供更灵活有效的业务驱动的体系架构。

　　物理主机托管以及逻辑上的整合可以帮助解决成本上的问题，比如：

　　第一步，简单的主机托管。可以通过改进并引入重要的处理减少人员配备，如变动、配置以及问题管理等。正如我们前面提到的，一个计划良好的逻辑整合也可以提供一定的好处，但是它很难实现更多的。在很多情况下，尤其是被 META Group 成熟度模型定义为一级或者二级(总共五级)的不成熟企业，物理上的整合是唯一可以快速收到效果的解决方案。

　　第二步也是非常合理的步骤就是整合，虽然这听起来比较容易，但不成熟的管理负载以及资源会使得在 Intel 甚至 Unix 服务器上运行多个应用变得非常困难。一般来说运作团队都需要经验丰富的技术员和操作人员来完成这样的工作。

　　进入虚拟化和分区技术。运作团队有了可以被厂商支持的虚拟化技术，可以保证 Intel 平台的独立的虚拟机或 Unix 平台扩展的分区方案(虽然分区并不是真正的虚拟化，但它可以增加系统的利用率并提高操作灵活性)。另外，扩展的 Unix负载管理( WLM )可以提供更好的共享能力( 图 2 和 图 3 显示了它们的不同)。 Intel 的虚拟机解决方案，如 VMware 和 Connectix ( Microsoft 的一个部门)，可以在 Intel 平台之上提供一个虚拟层用于物理和逻辑分区。

　　最后一步，应用程序集成，这是最难的一步。随着技术发展，Unix、Windows以及Linux都改进了自己的负载管理方案，使得这一步骤变得更加可行。到 2006 年 8 月，这些代码会具有足够的功能来实现在单一的逻辑或物理分区上运行多个应用程序。

　　整合方案不可避免的挑战：越大越昂贵

　　对于所有的整合工作或者服务器集成来说，至少有三点挑战是不可避免的，而第一个挑战也是最难克服的：

　　对于所有系统来说，没有类似于大规模经济效益这样的观念。简单来说，一个事务在大型系统上运行的成本要高于在小型系统上运行的成本。一个8路系统的运行成本很明显要大于八个单路系统的成本总合。比如在一个单路系统上运行一个事务(最经济的设计)的成本只是在一个8路的 Intel 系统上跑同样事务的成本的一半。因此从一开始，整合就面临着“成本”的挑战。整合基本上就是将多个服务器集中起来，将其硬件资源重新组合，比如生成一个8路系统。为了满足需要，虚拟化解决方案也有类似的机制，不过它是采用生成多个虚拟的服务器的方式来满足对服务器数量上的需求的。

　　整合所面对的第二个挑战是必须深刻了解目标服务器的使用情况。虽然这听上去很简单，但变化的负载曲线带有不确定的峰值，需要服务器具有足够的能力来应付。要使整合后的服务等级(SLA)符合已经确立的单系统标准，则需要大量易于获得的处理能力，以及对大量独立服务器使用情况的深入分析。这都需要强大的运算能力规划与性能管理能力，以及各种工具的辅助。

　　第三个挑战是关于整合效果的。比如说，在整合后，系统是否运行的更好、更快或者成本更加低廉。这需要对整合前后的平台成本和成本比率(硬件、软件以及员工)进行深入分析。基本上说，我们在找一种针对硬件、软件和员工的最优方案。因此，我们必须依靠强大的操作过程，比如可以通过更简单、更具重复性的组织架构和处理过程(如设计 / 建造 / 运行)来帮助降低成本，而不是靠成本更高需要更多资源的以系统管理为中心的组织架构。

　　非大规模经济：一个不变的问题

　　Intel 系列的 SMP 和其他的 SMP 系列( 1 路到 32 路服务器)一样，并没有产生大规模经济的效益，也就是说，并不是服务器规模越大，效益就越高。实际上，一个事务运行于多路服务器上的成本要大于其在单路服务器上运行的成本。假设在单路服务器上运行的成本是 1 ，那么在 8 路服务器上运行的成本就要超过 2 ，而如果将事务移动到更大型的服务器( 16 路到 32 路)上，那么成本将更高昂，比如在 32 路服务器上，其成本就变为 4 。因此越大型的服务器一般来说运行成本也就越高。

　　在低端系统中，单路服务器只是一个简单的系统，并没有可伸缩的 SMP 性能。因此它的价格低廉并且对于每个事务来说，其吞吐量与价格之比要优于 8 路系统。而在大型系统中，比如为了实现 8 路应用而设计的更高速的缓存以及更强大的 SMP 预期，都增加了运算成本。因此，小型系统的数量在快速的增加，虽然这使得维护成本也在不断上升，但由于其低价格以及较高的事务处理“价值”，使得 Intel 平台的整合工作变得更加困难。

　　一个整合模型框架

　　从我们上面的介绍不难看出，仅仅是将八个单路 Intel 服务器整合成一个 Intel 8路服务器，似乎并不能带来财务或者操作上的成功。一个真正的整合模型应该是这样的：鉴于三年的硬件生命周期，一个基本的 Intel单路服务器处理器(刨除存储介质和软件)的平均成本大于每年2000美元。而一个8路Intel服务器处理器(刨除存储介质和软件)每年的成本约 42000 美元，按处理器算即每年每个处理器成本超过 5000 美元。对于一个无损的整合来说，需要至少 20 个单路服务器整合才相当于一个 8 路服务器的成本。

　　上面复杂的计算推出了一个简单的结果，那就是八个单路服务器整合的效果不如 20 个独立的应用服务器。这也许会让客户感到非常不快。而在一个 8 路服务器上运行那 20 个单路服务器的负载从财务或操作上看也不是办法。因为负载管理目前还不成熟，对性能和用户预期的管理还具有一定的风险。因此，一个更好的解决方案是通过虚拟机技术，将硬件和应用隔离开，而掌握这个技术的两大厂商分别是 VMware 和 Connectix (Microsoft 的一个部门 ) 。

　　虚拟化技术的游戏规则

　　虽然这两个厂商在技术细节上有所不同，但都为我们提供了相当真实的产品。如前所述，虚拟机技术从上世纪 70 年代就出现了。它在实现完全的操作独立和提供有效的虚拟集合方面取得了成功，这使得在一个真正的系统上运行多个虚拟机成为可能。而这又引出了一个问题，为什么 Intel 平台迈向虚拟化耗费了这么长时间。为了获得这个答案，我们必须回顾市场，并了解一下 IA32 技术。

　　IA32/X86 — 虚拟化进程上的绊脚石

　　对于市场来说，答案很简单。很多出售 Intel 架构系统的供应商都有不错的业绩，而这些供应商的大部分利润都是通过不断向计算能力已经过剩的市场销售更多的电脑而获得的。事实上直到最近，这个问题一直很少被人提起。另外，虽然自从上世纪 60 年代末，虚拟化技术就是大型机的一个关键技术，但 IA32 架构从来都不是为虚拟化而设计的，与之有关的研究也不多，因此才会使得后来的 Vmware 在虚拟化技术的研究上获得了大量专利。

　　虚拟化层的魔术

　　直接的实现处理器虚拟化。一般来说，操作系统和驱动软件享有最高优先级，而应用程序(在虚拟世界中，操作系统也被看作是一个应用程序)使用较低的优先级。简单来说，虚拟机的原理就是通过在无优先级模式下运行 VM 代码，并让 VM 代码控制硬件(或部分特殊软件)的中断并捕获应用程序及 VM 的全部操作，然后通过虚拟机管理器( VMM ，一个运行在硬件层之上的很薄的层)来模拟这个指令。这就是 IBM 的虚拟机或 Vmware 的 ESX 所依据的原理，它可以模拟全部硬件资源。由于 VMM 的输出接口与系统硬件的接口是一致的，因此像 Windows 或 Linux 之类的操作系统不会察觉到硬件层之上的 VMM 层。这个 40 年前的理论指出了一个简单的事实，那就是大部分处理器都会忠实的生成异常(也就是处理器不会处理没有优先级的任务，如虚拟机 );而 VMM 层模拟了这些异常并继续控制着系统硬件。不幸的是， IA32/X86 处理器架构并不支持这个简单的规则。

　　实际上， 17 个 IA32/x86 优先级指令不提供这种功能。另外，在 IA32/x86 系统中，相同的机器操作码对于不同的 IA32/x86 “保护环”(或优先等级)也有不同的意义。因此， IA32/x86 架构的系统只能实现“部分”虚拟化。实际上， VMware 和 Connectix 都花费大量精力开发框架和方法用以弥补这个不足，由此便产生了虚拟机管理( VMM )层。

　　数以万计的 PC 设备制造商和各种驱动器都在增加 Intel 系统虚拟化的复杂程度。毫无疑问，除了一些小问题(如性能和扩展 SMP 的支持等)，两个厂商都解决了这一难题。而且随着每个新版本的发布，虚拟机解决方案都变得越来越健壮。虽然我们都相信基于 x86 系统的虚拟机会不断提升基本效率，但要达到大型机的效率，还需要三到五年的时间。在很多情况下，大型机架构由于更适于进行虚拟化，因此其效率一般都在 90% 以上(除了 2%-3% 的虚拟化损耗)。而 x86 架构上的虚拟化性能最初大约有 40% 的虚拟化损耗，随着技术的发展，目前的损耗大约为 20% ，而在三年内，这个损耗就会降低到 10% 以下。

　　虚拟化之战

　　平台虚拟化对实现按需计算和适应企业的要求来说是一个关键能力。当然，倘若所有的资源是充足的，数据处理团队只需提供机器而不用购买它们。在多数情况下，一个VMM供应商，如Vmware，会为一整类的服务器提供参考平台环境，使领导者大体上了解虚拟化和计算体系的实现方式以及购买原因。无疑，虚拟化是一个非常强的特性。考虑到这种情况，Intel最近宣布了它的Vanderpool计划，其目标是提供它自己的虚拟化平台甚至是与 Vmware 的 EX 产品类似的虚拟机监视器。这样，虚拟机市场上就有 Microsoft、Intel和VMware 三大玩家，而其他公司也在蓄势待发。

　　众所周知，IA32/x86虚拟化要求很高的技术和努力，而IA64，也要求付出同样的或更大的努力，因为它的体系非常难以虚拟化，或者很难有效地虚拟化。了解了如此情形，再加上Intel表示五年后才能交付产品，消费者们将会继续评估现有的各个公司的虚拟化产品，而不会干等着Intel的成果出来。对大多数企业来说，目前的提供商如VMware，所提供的解决方案已经可以为企业带来巨大的运作收益了，尽管其产品大多仍然处于半成品模式。此外，在12到18个月里，Intel超过20%的高端市场将对产品应用实现开发虚拟化。由于虚拟化层是硬件层之上的一个很薄的层，用户们可以尝试不同公司的解决方案。虽然其效果可能不会完全透明，但起码对资源的需求不会高到令人无法容忍。

　　商业影响：基础架构虚拟化能带来巨大的运作收益，例如改进对市场响应速度、增加机构弹性，以及降低运作成本。

　　总结：基础架构虚拟化能提供巨大的操作灵活性。要成功，运作团队必须有丰富的操作经验，以保证对日益复杂的计算体系提供适当的管理。