[转载]越过服务器联合
[转载]越过服务器联合
|||
【原题】Beyond Server Consolidation
【译题】越过服务器联合
【作者】Werner Vogels
【主题】虚拟化
【题注】服务器联合帮助公司发展了资源利用，不过虚拟化可以另外的角度去作帮助。
为了更有效的使用硬件资源的虚拟技术是在1960年代后期产生的。硬件很昂贵，而且不太够用。处理过程常常是外包到少数几个有计算机的地方。在单独的一台 IBM/系统360上，可以跑在并行诸环境中，即够维护完全独立的各个环境，并给其上的用户以拥有硬件的假象1。虚拟化是分时（time sharing）的的粗粒度实现，而且“隔离（isolation）”是该技术的关键一步。虚拟化同样有效的提供了资源管理的能力，这是因为那些资源会被赋予给虚机，从而可以符合截止期的限制，且可进行一定数量的服务。
第一次瞥见好像是没什么变化。今天公司中虚拟技术的主要应用是“通过所谓基于虚拟的联合去因应服务器耗用过多资源（combat server sprawl through virtualization-based consolidation.）”。隔离，安全，以及效率仍旧是在这种环境中（译注：应指服务器耗用过多资源的环境）使用虚拟机的主要收益。
虽然改篇文献主要是关注提升资源利用率，不过如果我们把虚拟化只是当成一种之于服务器联合（server consolidation）的工具，我们就低估了虚拟化的真正潜能。虚拟化打破了介于应用和操作系统及硬件之间的1：1关系。移除这种约束不仅仅能给我们带来所谓N:1关系，即可以在单一共享资源上跑多个独立的应用之收益，而且使得 1:N关系，即应用可以通过对它们的资源使用提供弹性，更容易的跨越多个物理资源 。
联合（CONSOLIDATION）
经典联合（consolidation ）关注于在若干虚拟化环境之上的物理资源之多路复用（multiplexing physical resources over a number of virtualized environments）。立刻的好处是很明显的：减少了硬件数量，减少了对数据中心的涉及，而且间接的减少了能量消耗。后者（译注：指能源消耗）是之于联合的不断增长的重要驱动，因为能源公司开始在削减消耗上提供显著的激励。“联合”对一个成本削减动作是至关重要的。通过显著的降低服务足迹（the server footprint）（约30到50个百分比升至更多），资本投资需求直接受到了影响，这导致缩减人员需求和降低操作成本。
公司中所谓“服务蔓延（server sprawl）”背后的一个主要原因是供应商们的需求是要独立的运行他们的应用。这就要求IT部门对一应用投入一个或更多的服务器，即使是服务器提供了较应用所需为多的资源。同样在基础设施级别我们看到当代公司有许多专属服务器（dedicated servers）：DNS, DHCP, SMTP，打印，动态目录/LDAP，等等。服务蔓延的另外一个驱动因素是操作系统的异构：一台邮件服务器需要的是Windows Server，一个数据库最好是运行在Solaris，一个网络管理包最初需要和AIX一起使用，等等。
还加上吸收兼并（mergers and acquisitions）和其它项目整合的效应，而且你会发现一个有大量服务器的公司，其中每个服务器都致力于一项任务，这是常见的模式。特别是吸收兼并带来了新的应用或应用版本，附加的服务器以及常常是新的复杂的整合中间件。再一次吸收兼并后，以下情况并非是不常见的：用于支持新的基础架构的服务器数量较“独立公司的服务器数量加和”为多。考虑到这些整合项目的复杂性，IT组织为了达到整合的目的，严重赖于粗粒度的服务驱动隔离（coarse-grained server-driven isolation ）。
大量未充份利用的服务器成为许多IT部门的一个主要问题。独自的公司对服务利用率不提供官方数字，不过许多大型的分析公司评估说资源使用率在15到20个百分点是很常见的。从个人与来自全球各地的其它CTOs 和CIOs交谈 的经验来说，我相信这些数字还算是偏高了（on the high side ），真实的利用率常常只是在5到12间徘徊。随着更加强大的服务器每天进驻数据中心，利用率的数字是在下降而不是上升。
单独的平均很少会讲述整个故事。服务器的利用率是高度依赖于工作负载的类型的，而且常常受制于周期性影响。如果你在一长段时间中检视利用率的话，你会发现利用率会以更精确的方式，对一个有差异的依赖于应用的范围作出反馈。在Luiz André Barroso和Urs Hölzle 关于能量比率计算（energy －proportional computing）的文献中，他们显示了在类似谷歌的利用率这样一个的高度调优环境中，经过长时期的检查， 趋向于在10到50百分因子之间波动2。图1显示了谷歌中多于5000台服务器在6个月的时间中平均CPU使用率。该数据折射出我们在亚马逊的经历；一些利用率是由客户行为驱动的，但是另外一些是由实行“处理模式或数字资产转换（fulfillment process patterns or digital asset conversions.）”触发的。
图1.谷歌的平均服务CPU利用率（译注：请看原图）
降低成本对许多IT部门来说是一个重要目标，而且“服务联合（server consolidation ）”一定处于关注列表的焦点之中。虚拟化在驱动服务联合中开始变成主要的工具：经由最近对CIO研究的调查3， 81%的CIOs 都在使用虚拟化技术去驱动联合，尽管策略看上去是成熟的，联合的体系架构仍旧是要面对重要的技术障碍。
于“联合处理（the consolidation process）”而言，第一个挑战就是“如何精确的刻画应用的资源需求”。一个工程师的有根据的推测（educated guess would）总体上会导致对真实约束的一个不完全观点。构建一应用的资源使用轮廓是必要的，并且这样一个轮廓不仅仅会关注何种资源最终绑定到该应用，而且还分析随着时间的资源使用以决定周期，还分析是否依赖于其它系统或应用系统组件而存在。该资源使用轮廓的第二部分是当应用超负荷运行时，它是去如何去表现的 ：应用之于资源短缺是如何敏感，它能适应这种短缺么？或者说环境需要维护严格的界限么？
这个分析之前的通常一步是打破应用在共享环境下的运行，并且把各个应用放到独立的环境中去，期望可以更加容易的去预测独立应用之于请求模式的响应下的资源使用情况。那些资源然后就可以通过它们自己的资源轮廓作独立管理了。
下一个面临的挑战就是，一旦有了关于资源使用和切片的清晰图景之时：如何得以最佳的把宿有应用的虚机分布到物理资源上去。这是领域有许多涌现出来的工具以支持系统体系架构来找出最优解，不过来自该领域的报告指出，在符合一个合理的平衡之前，这个问题仍旧大体上是一个试错的过程。这不是一个琐碎的任务。如图1所见，资源使用率随着时间变化可能极度的震荡，这就使得相关的装载测试很为难了。
整个联合过程的最大挑战，毫无疑问还是所谓“运行时的服务平衡（the balancing of server workloads at runtime）”；在作CIO 研究调查时，64%的CIOs提到了这一点。由于系统的“不通畅（reduced slack）”，应用被更多的暴露于资源短缺，特别是“工作负载高度动态可变”的情况。
一个关于有变更需求的业务的好例子是所谓“幂集（Powerset）”。最初构建索引和随着时间更新索引对资源的需求有很大的差异。“幂集”释出一个数据中心资源分析工具，帮助分析何种特定业务场景对购买，租用或者使用虚拟资源来说是有意义的。考虑到变化着的资源需求，在大多数情况下虚拟服务器是成本效率最高的4。
目标是追求百分百的利用率么？
有许多理由使得我们永远不会见到百分百的利用率：公司内的工作负载是异构的，需求是不确定的，而且常常是在峰值时出现的。比如，当你在一个较大的时间尺度上测量使用率时，某些CPU周期或者IOPS （指：I/O操作每秒）总不会被用到（译注：何种情况？）。 即便是在独立的操作系统级别，我们要知道精确的利用率也是不可能的。比方说，类似Linux 一样的操作系统在合并了的高CPU/IO装载下，会表现的不可预测 。我们对某些这类操作系统所表现出来的行为开玩笑的称之以“爱因斯坦效应（Einstein Effect）”，即在高利用率情形下的， 空间和时间不再被保证说是行为一致。
结果就是，对“联合”的成功测量更加的实际了：对纯CPU绑定的环境而言，70%看上去是高度调优了的应用可以达到的；对有复合工作负载的那些环境，能达到40%就不错了，达到50%就是吃上天鹅肉了。
对那些确实是变得过载了的应用和服务而言，迁移可能是一个潜在的解决方案。但是所谓“透明迁移（Transparent migration）”却很难企及，而且许多遗留应用在和“透明迁移”的合作上是问题的（do not respond favorably to this）。有两个更加粗粒度的技术看上去会有效果：应用检查点以及重启（checkpoint and restart）已经作为灾难恢复工具（disaster recovery tool）被内建到多个应用之中，并被用于把应用移到不通的物理服务器之中；而且一系列的应用可以被跑在集群模式中（比如，激活了的MS集群服务 Cluster Service enabled），在该集群中可以供给第二个节点，而且在应用级别，状态和工作可以从第一个节点被迁移到第二个节点。
一个使用虚机作迁移的极端例子是所谓的“应用停车场（application parking）”。在这个例子中，几乎不使用什么资源的几个应用，各自运行于其自己的虚机上，不过当它们处于休息状态时，就会共享一个物理服务器（sharing one physicalserver）。一旦一个应用开始使用更多的资源，该应用就被迁移到“可得的，能匹配该应用的轮廓的，有充足资源的”服务器。
超越成本节约（Beyond cost saving）
到目前为止，我们以已经讨论了传统的联合，正如许多IT部门所运用的那样，其中的主要关注焦点是对公司范围内的资源使用情况作彻底的分析，并使用虚拟化去尽可能有效的实现那些资源之多路复用。业务优先级决定了对任何给定时间来说，效率是怎样被衡量的。在典型的环境中我们会见到一个起伏趋势；一个应用通常是发生在它自己的服务器之中，或者发生在一次合并整合的一部分之中。这是由“一个资源使用和风险分析的阶段（a phase of resource usage and risk analysis）”导致的，这（译注：指该使用和分析阶段）决定了，在一个服务池再一次收缩以后，应用可以用虚拟化的手段被分配到哪儿去。
就所有这些而言，虚拟化（virtualization ）被用来作为一个传统的IT成本节约工具。当你考虑虚拟化在应用部署和管理上扮演的角色时，其作为“一项战略性的激励技术（a strategic enabling technology）”的真实能力登上了舞台。有正确的虚拟化管理工具之助，你可以进入一个“显著的提升新应用市场化的时间（significantly speed up the time to market of new applications），而且随用户所需有效的进行扩缩”的环境。
这样说的一个好的例子就是虚拟化在亚马逊的基础架构中所扮演的角色。亚马逊是全球最大的面向服务的软件组织，其中不仅仅技术是面向服务的，而且人也是以和软件组织进行相映射方式（mirror）组织在团队里的。这给了亚马逊“关注用户业务和技术开发方面的”非常大的灵活性 。在跑了将近1000台服务器情形中，在亚马逊中最后总是会出现“许多工程师执行类似的任务，这些任务的大多数都是相关于资源管理的”：管理应用部署，配置服务器，处理存储失效，配置负载平衡，诸如此类。保守的估计显示说工程师耗费了他们70%的时间用于“不是直接和他们的服务之业务功能相关的普通任务”。
我们决定把这些常见动作计入一个“基础设施－服务器平台（an infrastructure-services platform）”，之中这些动作可以更有效的进行管理,与此同时仍旧可以把亚马逊的关注保持在可靠性和性能上头。当基础设施服务时（as infrastructure services），存储、计算和消息都会虚拟化。一系列的这些服务自此之后可以在“亚马逊简单存储服务 （Amazon Simple Storage Service， short for 3S）， 弹性计算云（Elastic Compute Cloud， short for EC2），简单队列服务（Simple Queue Service ，short for SQS ），以及SimpleDB”外获得5，
在设计这些基础架构服务时的两个关键需求，很明显的改变了资源管理的方式：这些服务是完全的自服务（fully self-service），允许工程师以最小的阻力开始使用它们；而且资源可以动态的进行管理，这给了工程师一种快速获取和释放资源的能力。
统一应用部署（Uniform Application Deployment）
亚马逊EC2，和传统的虚拟化非常类似的系统，使用了一个模型，其中工程师可以程序化的开启和关闭那些他们先前构建的实例5。这些实例是应用构建过程产出的虚机图像（virtual machine images），这些实例存储在亚马逊S3 存储服务之中。“EC2管理环境”基于资源需求，将该虚机放置在一台物理服务器之上。这提供给工程师一种“基于客户需求和其它扩展性质去增加和降低其服务器使用的资源”能力。
这带给我们一项虚拟化的主要策略优势：它生成一“统一应用部署环境（a uniform application deploymentenvironment）”，之中工程师可以不受来自底下的硬件之细节的影响。一个单一虚机跑在一个物理服务器上，这并非不常见，这里其目标不是对有效资源共享作最大化，而是加速应用的部署，和一会儿就可以看到的扩缩（scale up and down at a moment’s notice）。
从亚马逊EC2 客户处的回馈显示了他们仍旧要面对传统的显著的日常开销（overhead）对“从他们IT组织中的”资源的需求。服务获得的时间常常要等上数月（Server acquisition times often run into several months），而且一旦一个资源被分配给一个应用，考虑到再一次需要资源又要有常常的等待时间（given the long lead times in reacquiring the resource when needed again），团队是不愿意释放它的。
这种保守方式需要长长的资源规划周期：团队需要在部署和执行之前很早就开始预测他们的资源使用，这触发了过度的扩展（overscaling）以应对未预料的对应用的更高需求。该模型对那些“期望对需求更快的和更高效的回应”的公司而言是一块绊脚石（a stumbling block ）。当“产品和服务的生命周期被压缩，且加剧的竞争使得产品的成功更难预测”时，在许多市场上有不断增长的不确定性。为了适应这些新的现实，公司需要把他们的资源管理迁移到不同的模型上去，之中基于需求来获取和释放资源（acquiring and releasing resources based on demand），正在变成一个本质的策略性工具。在这种上下文中，亚马逊基础架构服务的现收现付（pay-as-you-go）模型非常有吸引力。
让虚机作为标准部署单元，在对迁移资源需求的适应中很关键的，之中不但获取资源是重要的，而且当这些资源不再被需要时，释放掉它们也是很重要的。许多亚马逊的EC2 公司客户声称他们的获取周期从月变到了分（months to minutes）。
一个获取资源需要非常长久的领域就是政府IT领域。提供资金和位置的决策常常要求团队，在“软件完成的许多个月，而且是在一个好的使用模式被开发出来”以前，在一个项目的开始去购置服务器。这导致了带最终配置的低下利用率的极端保守计划（ultra-conservative planning）， 并导致“原型设计和实验之间的严重隔阂（significant barriers to prototyping and experimentation.）”。一个DoD IT建筑师报告说：部门的软件原型常规情况下会在服务其资源上耗费 30,000。不过通过在亚马逊EC2的虚机中构建它，最后在资源上只是耗费了 57。
该新的敏捷同样迎合了（caters）使用虚拟基础设施的其它优势。尽管传统的联合基于虚拟化只增加了资源使用的密度（the density of resource usage），但在“改变在任何时间跑的服务和应用的混合（changing the mix of applications and services running at any given time）”上， 仍旧有障碍。将虚机和管理过程的变化相合并，以及添加的资质管理特性，显著的提升了公司的敏捷性。对“自动化资源配置以优化商业价值”使用经济模型，在现在还是最高（a Holy Grail）想法。
虚拟化和数据中心（Virtualization of the Datacenter）
虚拟化在“使得IT组织能够超过其数据中心而成长中，以及开发效用计算基础架构过程中”扮演了一个关键的角色。效用计算就是对资源的包装，诸如计算和存储作为可测量的服务，类似于公共设施（电力，水力，天然气，和电话网络）。优势在于，这之于获取硬件的最初成本是很低或甚至是没有的；取而代之的是，计算资源本质上是租用的（译注：更确切应该说是，多路复用的）。
在一个虚拟化已经普遍用于支持“联合，和或应用部署场景”的组织中，应用/操作系统和物理硬件之间的紧密关联已经被移除了。在硬件上运行虚机，这不是由组织直接控制的，是逻辑上的下一步。
效用计算服务不同于传统的应用外包，在于基础设施拥有者是代表用户利益来运行应用的，而且有特定应用的知识。这些服务也和网格环境有差异，因为它们不会对应用开发实施特定的程序模型。取而代之的是一个效用计算服务允许其用户在他们的硬件上，“以一种类似在它们的私有数据中心里头运行这些虚机的方式”启动虚机实例 。亚马逊EC2 是一个主要的服务：使用虚机来以公共设施的风格提供对计算资源的获取 。EC2 客户可以，当“他们在其数据中心里头运行这些虚机”时，对虚机打包，运行EC2也是一样。
使用效用计算服务能有益于使成本节省目标，这常是联合努力的基础（underlie consolidation efforts）；通过使用“你只在实际使用它们时才和这些资源打交道（ where you pay for the resources only for the period of time that you actually use them. ）”的模型，资本消耗极大的缓解了。经常性的，公司会开始使用这些效用计算服务以应对他们在溢出和峰值容量时的需求；通过这种方式他们可以对付需求的不确定性，而无需在硬件上大量投资，这中投资的硬件在大多时候是空闲的。这种随需获取释放资源，是有吸引力的；一旦公司对在处理峰值时，对使用一个计算效用服务变得开始很自然时，他们就会很快的用它来处理其它任务，特别是那些不需要日夜不停的（around-the-clock ）资源分配的任务，比如文档索引，日常价格计算，数字资产转换，诸如此类。
一个很好的之于超额容量任务之使用效用计算的例子就是纽约时报的项目：将1千多万篇历史文献从TIFF转换到PDF。公司服务器上获取足够的容量是困难的，考虑到项目的截止期，以及为这么个一次性任务去购置附加的硬件不会很有效率。纽约时报生成了一个虚机图像（a virtual machine image），包括了特定的转换应用，把4TB的图像搬到亚马逊S3中，而且在亚马逊EC2开启了100个虚机实例。 在24小时以内所有的文献都被转变到1.5 TB的PDF，代价只是单一服务器的零头（a fraction of）5。
这个模型的一个收益就是衡量“所有权总成本（total cost of ownership， short for TCO）”变得容易了；取代了摊销“服务器、网络、能源、以及在运行于一台服务器上的一系列应用的制冷”成本，一定要付的基础架构成本只是效用成本（the absolute infrastructure costs are metered utility cost.）。
看看许多公司广泛各异的使用虚拟化去在亚马逊EC2上跑他们的应用，你就可以猜到那个（that）效用计算（译注：应指虚拟化式的效用计算）有许多应用出超越了公司的容量管理（beyond enterprise capacity management.）。使用的范围“从金融与制药公司的经典并行计算到开始跑在Web services上，从大型软件公司使用它用于产品和发布测试到动画工作室的图像渲染。对应用打包和实例化（for packaging and instantiating the applications），管理安全，和随需获取需求资源，所有这些都是由虚机技术激发的 。
测试测试（Testing, testing, …）
软件测试是通常对于获取资源是短缺的另一个领域 ，而且从虚拟化中所获颇丰。对基础设施的测试需求会在开发周期（译注：是RUP开发方式？）中有所改变。在这个循环（cycle）的早期阶段，某人可以使用一个持续集成技术（a continuous integrating technique）配以对该环境的夜间重构（nightly rebuilds），以对装载进行变更以及该循环中之后作扩展测试（Changing to load and scale testing later in the cycle. ）。测试工程师常常需要让许多不通的服务器保持运行的状态，每台都有一操作系统的不同版本去管理释放测试（release testing）。
传统上，QA部门管理他们自己的资源，而且在许多情况下他们在对其可用的资源方面受到高度约束。即便是在该受限环境中，还是会周期性的在某一天，某周，某年中硬件变得不可用。虚拟化通过“当这些资源被特定测试需要时，随需的获取它们；或者当测试结束的时候，释放掉这些资源 ”，已经剧烈的改变了QA过程。这已经非常惊人的提升对脱离其环境后而言的试验装载效用（the utilization the testers）。不再需要让许多不通的操作系统去跑，或者缠绕于复杂的多重启动环境了；开启和关闭不同的操作系统图像变成了“一项随需活动（an on-demand activity）”。变得虚拟在任何时候对QA而言， 因为（as ）物理资源池可以和产品环境共享（the pool of physical resources can be shared with the production environment. ）,在许多情况下增加了可用资源的数量。这使规模装载测试更加的现实（realistic）。
扩展，可靠性和安全（Scale, reliability, and securit）
虽然这篇文献关注的是虚拟化在效用管理上的角色，还是有其它一些领域让虚机有用武之地（play an important role.）。这样的领域中就有安全（security），之中许多革新用户，即便是最简单的亦有可能获得许多收益（where many innovative uses are possible but where even the simplest brings many benefits）（译注：2008年时的蓝海？）。把一个应用从一共享环境搬到其专属虚机，这允许直接的操作员和用户的存取控制（operator and user access control）。它可以减低开放端口的数量，就其本身而论，潜在的把暴露于缺陷的可能性降低了。许多IT组织使用这个技术来满足那些“没有足够存取控制和审计”的技术需求。
类似的，对统一应用部署使用虚机（the use of VMs for uniform application deployment），可以成为灾难管理中的基石。一个简单的“检查点－重启设施（checkpoint-restart facility ）”对介于机器之间的宕机执行一个恢复足够快了。如果应用是通过增量扩展构建而来的（applications are built for incremental scalability）话，那么类似那些在效用计算基础设施中的适应管理设施（the adaptive management facilities ） 就可以允许组织有随需的快速扩缩能力。
总结（Summary）
虚拟化在公司中的主要应用仍旧是“服务器联合（server consolidation）”。由于那很有效，我们乐于去看看从现在开始的数年后非常不同的图景，那里对IT中一系列策略变更而言，虚拟化会是“核心激励技术（the key enabling technology）”。
使用效用计算的适应资源管理（Adaptive resource management using utility computing）将对处于增加的不确定性中的一项经济成功会是本质重要。快速的适应新的客户需求，新的商业关系，以及取消合约（cancelled contracts）这对当代公司而言会是一个商业利器（a key business enabler），无论公司“执行所谓软件即服务策略，或者以更传统的方式使用该资源”与否。
虚拟化会改变我们测试的方式，QA部门会获得较他们以前所得多得多的资源，以低得多的成本。类似的，那些不精于把控可靠性，容错，以及商业连续性的公司，会发现虚拟化是一个使得他们朝向其目标大踏步前进的新工具，而无需重写所有他们的软件。
索引（References）
【1】 Gum, P. H. 1983.
System/370 extended architecture: Facilities for virtual machines.
IBM Journal of Research and Development 27(6): 530-544.
【2】 Barroso, L. A., Hölzle, U. 2007.
The case for energy-proportionalcomputing
IEEE Computer 40(12).
【3】 CIO Research. 2008.
Virtualization in the enterprise survey: Your virtualized state in 2008
CIO Magazine(January).
【4】 Powerset Datacenter Dashboard
http://www.powerset.com/flash/datacenter_model.
【5】 Amazon Web Services
http://aws.amazon.com.
【6】 Amazon Elastic Compute Cloud (EC2)
http://aws.amazon.com/ec2.
【7】 Brewin, B. 2006.
Amazon.mil? DISA is intrigued by Web services model for creating systems.
Federal Computer Week (October 30).
【8】 Gottfrid, D. 2007.
Self-service, prorated super computing fun!
New York Times (November 1).
(完)