PDF虚拟化：福音还是诅咒？
大规模管理虚拟化充满了隐藏的挑战。
Evangelos Kotsovinos，摩根士丹利
虚拟化通常被吹捧为解决许多具有挑战性问题的方案，从资源利用率不足到数据中心优化和碳排放减少。然而，虚拟化的隐藏成本，主要源于其带来的复杂且困难的系统管理挑战，常常被忽视。要收获虚拟化的成果，企业需要应对可扩展性限制，改进传统的运营实践，管理性能，并实现前所未有的跨部门协作。虚拟化不是诅咒：它可以带来实际的好处，但仅限于有准备的企业。
理论
艾尔·古德曼曾说过：“完美的计算机已经被发明出来了。你只需输入你的问题，它们就再也不会出现了。” 这就是近年来虚拟化给人们的印象：仿佛是解决众多IT难题的万能药。企业引入虚拟化通常是为了降低成本，同时不影响服务质量。在更少的服务器上以虚拟机（VM）的形式运行相同的工作负载可以提高服务器利用率，并且可能更重要的是，可以推迟数据中心的扩建——相同的数据中心空间现在可以持续更长时间。
虚拟化还旨在增强企业基础设施的可管理性。由于虚拟服务器和桌面可以无停机地进行实时迁移，因此不再需要与用户协调硬件升级或协商工作窗口——升级可以随时进行，且不会对用户产生影响。此外，虚拟化产品系列提供的高可用性和动态负载均衡解决方案可以以很少的人工干预来监控和优化虚拟化环境。在非虚拟化世界中支持相同的功能将需要大量的运营工作。此外，企业使用虚拟化来提供IaaS（基础设施即服务）云服务，使用户能够以VM的形式按需访问计算资源。这可以提高开发人员的生产力并缩短上市时间，这在当今快节奏的商业环境中至关重要。由于更快地推出应用程序可以提供先发优势，因此虚拟化可以帮助促进业务增长。
实践
尽管虚拟化是一项有50年历史的技术3，但直到2001年之后它在x86平台上可用时才开始广泛普及——大多数大型企业使用这项技术的时间还不到五年1,4。因此，这是一项相对较新的技术，不出所料，它带来了一些不太为人所理解的系统管理挑战。
旧的假设。 严格来说，这不是虚拟化的错，但企业基础设施中的许多系统都是基于运行在真实物理硬件上的假设而构建的。操作系统的设计通常基于硬盘是本地的原则，因此从硬盘读取和写入速度快且成本低。因此，它们以多种方式慷慨地使用磁盘，例如缓存、缓冲和日志记录。当然，这在非虚拟化世界中是完全合理的。
随着虚拟化的加入，许多这样的假设都被颠覆了。VM通常使用共享存储而不是本地磁盘，以利用高可用性和负载均衡解决方案——将其数据存储在本地磁盘上的VM很难迁移，并且一旦本地磁盘发生故障就会注定失败。使用虚拟化后，每个读取和写入操作都会通过网络或光纤通道传输到共享存储，从而增加了NIC（网络接口控制器）、交换机和共享存储系统的负载。此外，由于整合，网络和存储基础设施必须应对潜在的更多数量的系统，从而加剧了这种影响。整个生态系统需要数年时间才能完全适应虚拟化。
系统蔓延。 传统的观点认为，管理运行多个VM的虚拟化服务器的运营工作量与管理物理的、非虚拟化的服务器的工作量相似。因此，由于数十个VM可以在一台虚拟化服务器上运行，因此整合可以减少运营工作量。并非如此：管理物理的、非虚拟化的服务器的工作量与管理VM的工作量相当，而不是与管理底层虚拟化服务器的工作量相当。企业已经收获了通用、标准化管理的成果——例如集中配置和基于镜像的配置，因为这就是他们管理其物理环境的方式。因此，管理共享一台虚拟化服务器的20个VM需要与管理20台物理服务器相同的工作量。再加上管理hypervisor和相关服务的开销，很容易看出运营工作量将会更高。
更重要的是，有证据表明，虚拟化导致系统中运行的VM数量增加，而不是仅仅整合现有的工作负载2,5。像IaaS云那样，以VM的形式轻松访问计算容量，其副作用是导致几乎不使用的VM激增，因为开发人员在项目结束后忘记将他们不使用的VM返回到池中。随着VM数量的增加，管理员以及共享基础设施（如存储、DHCP（动态主机配置协议）和启动服务器）上的负载也随之增加。
大多数企业虚拟化用户都实施了自己的VM回收系统。一些解决方案很简单，甚至有些过于简单：如果超过三个月没有人登录，则通知并随后回收（如果没有人反对）。一些解决方案很复杂，并且带有明显的过度工程的气味：基于启发式方法分析一段时间内的资源利用率，确定使用级别，并采取相应的行动。令人惊讶的是，缺乏通用且广泛适用的VM回收解决方案来解决蔓延挑战。此外，所有共享主机的VM通用的服务（例如病毒扫描、防火墙和备份）应成为虚拟化层本身的一部分。这些服务已经开始进入hypervisor，并且有可能大幅减少运营工作量。
规模。 企业花费了数年时间改进和简化其管理工具和流程，以应对规模化。他们投资了配置管理和配置系统、运营工具以及监控解决方案的骨干网络，这些系统和工具可以处理构建和管理数万甚至数十万个系统。得益于这种主要为内部开发的工具，大规模并行运营任务，例如构建数千台服务器、每日操作系统检查以及计划的数据中心断电，对于运营团队来说都是例行且直接的任务。
虚拟化出现了：大多数供应商的解决方案在规模方面并非为大型企业而构建，尤其是在其管理框架方面。它们的规模限制比企业系统低几个数量级，通常是由于基本的设计缺陷——例如过度依赖中央组件或数据源。此外，它们通常无法横向扩展；运行更多供应商解决方案的实例并不能完全解决扩展问题，因为这些实例之间不会相互通信。这种挑战并非虚拟化独有。企业在向其环境中引入新的操作系统时也会面临类似的问题。然而，当涉及到虚拟化时，扩展困难尤其重要，原因有二：首先，如前文关于系统蔓延的部分所述，虚拟化增加了需要管理的系统数量；其次，虚拟化的主要好处之一是对基础设施的集中管理，如果没有适当的可扩展管理框架，就无法实现集中管理。
因此，企业面临一个选择：要么他们必须接受使用多种框架来管理基础设施，这会增加运营复杂性；要么他们必须设计自己的解决方案来绕过这些限制——例如，现在开源的Aquilon框架扩展了Quattor 工具包。另一种选择是企业等待供应商生态系统赶上企业级规模的需求，然后再进行虚拟化。正确的答案取决于许多因素，包括企业的规模、业务需求、现有的系统和工具骨干网络、虚拟化和可虚拟化的基础设施规模、工程能力以及运营团队的成熟度和规模。
互操作性。 许多企业在其骨干系统之间实现了良好的集成水平。在配置管理系统中添加服务器使其能够获得IP地址和主机名。执行断电的工具可以从配置管理系统中无缝地提取有关要断电的内容的数据。服务器配置的更改将自动更改应用于它的结帐逻辑。这种统一性和紧密集成极大地简化了运营和管理工作。
虚拟化在这种紧密集成的企业环境中通常显得格格不入。每个虚拟化平台都有自己的API、配置、描述和配置VM的方式，以及自己的管理工具。供应商生态系统正在逐步赶上，在骨干服务和虚拟化管理之间提供更高的集成度。然而，缺乏满足以下所有三个条件的解决方案
* 它们可以相对容易地与内部系统集成。
* 它们可以处理多个虚拟化平台。
* 它们可以管理虚拟和物理基础设施。
可以肯定的是，一些企业很幸运拥有同构环境，由产品套件管理，这些产品套件已经存在可靠的虚拟化扩展。然而，在异构基础设施中，具有多个虚拟化平台、虚拟化和非虚拟化部分，以及众多紧密集成的内部系统，引入虚拟化会导致管理孤岛——基础设施的某些部分与其他所有部分的管理方式不同。这打破了企业环境的集成和统一性，并增加了运营复杂性。
许多企业会感觉他们以前经历过这种情况——例如，当他们设计系统使其能够使用相同的框架来配置和管理多个操作系统时。客户再次面临“构建还是忍受”的选择。他们应该忍受管理孤岛带来的额外运营复杂性，直到标准化和融合在市场上出现，还是应该投资于大量的工程和集成工作，以确保hypervisor不可知论并与现有骨干网络集成？
故障排除。 与传统观点相反，虚拟化环境实际上并没有将三台物理机器整合为一台物理机器；它们将三台物理机器整合到几个物理子系统上，包括共享服务器、存储系统、网络等等。
查找物理计算机速度缓慢的原因通常只需浏览本地磁盘上的一些日志文件，并可能调查本地硬件问题。需要查看的数据量相对较小、受限且易于查找。另一方面，监控性能和诊断虚拟桌面的问题需要从多个来源（包括桌面操作系统、hypervisor、存储系统和网络）中搜索日志和数据。
此外，需要聚合或链接大量不同的数据；管理员应该能够轻松地从给定时间段的所有相关系统中获取信息，或者跟踪特定数据包在存储和网络堆栈中的进度。由于这种多源和多层混淆，如果管理员必须查看多个屏幕并手动识别在时间或因果关系方面相关的位数据和日志文件，则解决速度会明显变慢。需要新的范例来存储、检索和链接来自多个来源的日志和性能数据。来自Web搜索等领域的经验可能在这方面至关重要。
孤岛？什么孤岛？ 在非虚拟化企业环境中，运行基础设施不同部分的责任在运营团队之间明确划分，例如Unix、Windows、网络和存储运营团队。每个团队都有明确的责任范围，团队之间的沟通有限，并且对基础设施问题分配功劳、责任和问责制非常简单。
虚拟化推倒了这些孤岛墙。涉及多个运营团队（在某些情况下是所有团队）的运营问题变得比完全可以在孤岛内解决的问题更为常见。因此，跨部门协作和沟通至关重要，这需要在企业基础设施组织的运营方式上进行真正的思维转变——以及可能需要进行组织变革以适应这一要求。
变更的影响。 企业花费了很长时间并投入了大量资源来了解对基础设施不同部分进行更改的影响。变更管理流程和策略已经成熟且经过时间考验，确保对环境的每次更改都经过评估并记录其影响。
虚拟化再次带来了根本性的变化。共享基础设施带来了集中化，因此也带来了尚未被充分理解的潜在瓶颈。在非虚拟化环境中，在每台主机上推出新的服务包，将磁盘利用率提高5 IOPS（每秒输入/输出操作数），影响很小——每台主机只会更频繁地使用其磁盘。在虚拟化环境中，每个VM磁盘使用率增加5 IOPS将导致共享2,000个VM的存储系统上的IOPS增加10,000，这可能会产生灾难性的后果。它还会增加共享主机的负载，因为更多的数据包将不得不通过hypervisor以及网络基础设施传输。我们已经看到防病毒更新和操作系统补丁导致整个虚拟化工厂的CPU利用率增加了大约40%——这些更改如果应用于物理系统，其影响将微乎其微。
同样，大规模重启可能会以与非虚拟化过去截然不同的方式影响共享基础设施组件。测试和变更管理流程需要改变，以考虑到可能比以前更广泛的影响。
争用。 虚拟化平台在隔离共享物理主机上的VM和管理该主机上的资源（即CPU和内存）方面做得不错。然而，在复杂的企业环境中，这仅仅是其中的一部分。大量VM将共享一个网络交换机，甚至更多的VM将共享一个存储系统。虚拟化堆栈的这些部分上的争用可能与共享主机上的争用影响一样大，甚至更大。考虑一下流氓VM使共享存储过载的情况：数百或数千个VM将变慢。
当涉及到网络和存储元素时，允许隔离和管理争用的功能现在才达到成熟阶段并进入主流虚拟化领域。设计可以利用此类功能的虚拟化技术堆栈需要企业客户方面的工程工作以及大量的网络和存储专业知识。有些人这样做，将提供硬件中正确的I/O虚拟化混合的异构网络适配器与定制的机架、存储和网络设计相结合。有些人选择风险较高但更容易的路线，即什么都不做特别的事情，希望系统管理员能够应对出现的任何争用问题。
GUI。 图形用户界面在管理电子邮件收件箱、数据文件夹甚至个人计算机的桌面时效果良好。总的来说，人机交互研究界普遍认为，GUI非常适合处理相对较少数量的元素。如果数量变得很大，GUI可能会使用户过载，这通常会导致糟糕的决策7。代理和自动化已被提议作为减少信息过载的解决方案6。
虚拟化解决方案往往带有基于GUI的管理框架。这对于管理100个VM来说效果很好，但在拥有100,000个VM的企业中就会崩溃。真正需要的是更多的智能和自动化；如果虚拟化服务器的存储断开连接，自动重新连接它比在包含数千个元素的GUI中显示一个带有感叹号的小黄三角要有效得多。还需要与企业骨干网络和其他系统的互操作性，如前所述。
此外，习惯了虚拟化前时代零散的系统管理（管理此处的服务器和彼处的存储元素）的管理员会发现他们将不得不适应。虚拟化带来了组件之间前所未有的集成和硬依赖关系——存储中断可能意味着数千名用户无法使用他们的桌面。企业需要确保其所有部门的运营团队都能够舒适地管理大规模互连的大型系统，而不是管理独立的组件集合，而无需GUI。
结论
虚拟化有望成为解决许多具有挑战性问题的方案。它可以帮助降低基础设施成本，延迟数据中心的扩建，提高我们响应快速变化的业务需求的能力，允许以更灵活和自动化的方式管理大规模基础设施，甚至有助于减少碳排放。人们的期望很高。虚拟化能实现这些目标吗？
它绝对可以，但不是开箱即用。为了使虚拟化实现其承诺，供应商和企业都需要在许多方面进行调整。供应商需要战略性地重视企业对规模的需求，确保其产品能够优雅地处理管理数十万甚至数百万个VM。公共云服务提供商非常成功地做到了这一点。标准化、自动化和集成是关键；赏心悦目的GUI不太重要。有助于端到端管理资源争用（而不仅仅是在共享主机本身上）的解决方案将大大简化虚拟化的采用。此外，行业生态系统需要考虑从根本上重新设计在虚拟化环境中性能不佳的组件，并且必须提供更好的方法来收集、聚合和解释来自不同来源的日志和性能数据。
决定大规模战略性地进行虚拟化的企业需要为实现所需的可扩展性、互操作性和运营统一性所需的巨大工程投入做好准备。另一种选择是增加运营复杂性和成本。此外，认真对待虚拟化的企业需要一种打破旧的部门界限、促进跨部门协作并在员工中灌输端到端思维方式的方法。防止VM蔓延的控制措施至关重要，并且需要新的变更管理流程和策略，因为虚拟化会放大以前影响最小的变更的影响。
虚拟化可以为企业带来显著的好处，但它也可能反噬其主。它不是诅咒，但就像运气一样，它偏爱有准备的人。
问
致谢
非常感谢Mostafa Afifi、Neil Allen、Rob Dunn、Chris Edmonds、Robbie Eichberger、Anthony Golia、Allison Gorman Nachtigal和Martin Vazquez提供的宝贵反馈和建议。我还感谢John Stanik和编辑委员会在完成本文时提供的反馈和指导。
参考文献
1. Bailey, M., Eastwood, M., Gillen, A., Gupta, D. 2006. Server virtualization market forecast and analysis, 2005-2010. IDC.
2. Brodkin, J. 2008. Virtual server sprawl kills cost savings, experts warn. NetworkWorld (December 5).
3. Goldberg, R. P. 1974. Survey of virtual machine research. IEEE Computer Magazine 7(6): 34-45.
4. Humphreys, J. 2005. Worldwide virtual machine software 2005 vendor shares. IDC.
5. IDC. 2010. Virtualization market accelerates out of the recession as users adopt "Virtualize First" mentality.
6. Maes, P. 1994. Agents that reduce work and information overload. Communications of the 37(7): 30-40.
7. Schwartz, B. 2005. The Paradox of Choice. HarperCollins.
喜欢还是讨厌？请告诉我们
Evangelos Kotsovinos 是摩根士丹利的副总裁，负责领导虚拟化和云计算工程。他的兴趣领域包括大规模配置、预测性监控、虚拟化的可扩展存储以及用于有效管理全球云的运营工具。他还担任动态初创公司生态系统 Virtual Trip 的首席战略官，并且是 NewCred Ltd. 的董事会成员。此前，Kotsovinos 曾在 T-Labs 担任高级研究科学家，在那里他帮助将云计算研发项目发展成为一家风险投资的互联网初创公司。作为云计算领域的先驱，他领导了 XenoServers 项目，该项目产生了最早的云计算蓝图之一。他拥有剑桥大学的博士学位。
© 2010 1542-7730/10/1100 $10.00
最初发表于 Queue vol. 8, no. 11—
在数字图书馆中评论本文
更多相关文章
Adam Oliner, Archana Ganapathi, Wei Xu - 日志分析的进展与挑战
计算机系统日志提供了对运行系统状态的简要了解。仪器仪表偶尔会生成短消息，这些消息收集在特定于系统的日志中。日志的内容和格式可能因系统而异，甚至在系统内的组件之间也可能不同。打印机驱动程序可能会生成消息，指示它与打印机通信时遇到问题，而Web服务器可能会记录请求了哪些页面以及何时请求。
Mark Burgess - 可测试的系统管理
系统管理方法在过去20年中变化不大。虽然核心IT技术在许多方面都得到了改进，但对于许多（如果不是大多数）组织而言，系统管理仍然基于生产线构建物流（又名配置）和被动事件处理。当我们进入信息时代时，人类将需要减少像他们使用的机器一样工作，并拥抱基于知识的方法。这意味着利用简单的（免提）自动化，使我们摆脱束缚，去发现模式并做出决策。
Christina Lear - 系统管理的软技能
系统管理既可能压力巨大，也可能回报丰厚。压力通常来自外部因素，例如SA（系统管理员）及其同事之间的冲突、资源匮乏、高干扰环境、相互冲突的优先级以及SA对超出其控制范围的失败负责。SA及其经理可以做些什么来减轻压力？有一些众所周知的人际关系和时间管理技巧可以提供帮助，但在危机时期或仅仅是由于习惯的力量，这些技巧可能会被遗忘。
Thomas A. Limoncelli - 来自系统管理员给软件供应商的呼吁 - 10条须知和禁忌
我的一个朋友是汽车修理工：那种汽车爱好者，喜欢在周六晚上为了乐趣而重建发动机。他向我解释说，某些品牌的汽车在设计时就考虑到了让机械师的工作更容易。然而，另一些汽车的设计方式就好像公司与阿司匹林行业达成了协议，以确保有大量的机械师头痛。他说那些汽车公司讨厌机械师。我完全理解，因为作为一名系统管理员，我可以分辨出软件供应商何时讨厌我。这体现在他们的产品中。
© 保留所有权利。