三位 IBM 专家将介绍 Rational 视角下的虚拟化，以及虚拟化环境从 Rational 应用程序中
获取最优性能的关键要求。他们还将分享两个案例分析的细节和故障排除技巧。每个人都在谈论虚拟化。根据宣传，虚拟化将引发 IT 革命（众所周知），优化稀缺资源，并节省每个人的钱。服务器虚拟化有望成为 10 年内最重要的发展之一。但是，虚拟化已经存在了很长时间，而且 IBM 已
借助 IBM® System z® 和 Power Systems 平台成为这一领域的领导者。在过去几年中，System x® 和基于 Intel 的 x86 架构上的虚拟化技术已发展成熟并变得更加
普遍。只要使用得当，虚拟化是 IT 工具箱中一个不可或缺的部分。毋庸置疑，虚拟化已有牢固的根基。
但每种技术都存在风险。管理不良的虚拟化可能导致应用程序运行得更慢，这可能导致最终用户厌烦和不满。IBM 为其部署在虚拟化环境中的产品提供了全面支持。或许由于它的普遍性和诱人的承诺，我们看到客户深受管理不良的虚拟化环境所害，导致他们未能获得任何承诺的收益。
这个由两部分组成的文章系列将通过具体示例探讨虚拟化的优缺点。在第 1 部分中，我们将从总体上解释虚拟化，尤其是它与 IBM Rational 软件的关系。我们将讨论管理良好的虚拟化环境的主要要求，展示 IBM® Rational® ClearCase® 和 IBM® Rational Team Concert 在配置不良的虚拟化环境中的行为的示例。我们将提供正确管理虚拟化基础架构的建议和技巧，总结我们测试 Rational 软件和为客户提供咨询的经验。
第 2 部分将继续讨论建议和技巧，包括故障排除和特定于供应商的示例。
关于云的预测
虚拟化通常与云技术密不可分。认识二者的关系至关重要。最宽泛地讲，云技术致力于以服务的形式提供服务器功能。虚拟化是一项管理提供该功能的服务器资源的关键技术。
我们还需要区分公有云和私有云。简单地讲，私有云是隔离的，可在一个公司内管理和托管，有时也可以在外部管理和托管。私有云受防火墙、身份验证、VPN 等保护。公有云通常没有这么安全，可以高效地由任何人共享和访问。许多流行的公共服务都是 “在云中” 提供的，比如电子邮件、文件和照片存储。公有云模型吸引了一些组织，因为在理论上，组织或个人仅需要为他们所需的内容付费，服务始终可在任何地方享受，而且云提供商处理了大部分 IT 管理任务。
我们发现，一些 IBM Rational 客户对公有云环境的不稳定性和安全问题呲之以鼻。他们喜欢在内部托管、管理更紧密的私有云方法，在这里，他们可以控制服务器资源分配的所有方面，设置特定的服务质量目标，并采用成熟的高可用性和灾难恢复解决方案。
但是，一些客户喜欢基于 IBM 云的解决方案，因为它们是使用软件开发和托管战略最佳实践来设计和管理的。IBM 也在私有云中提供了 Rational 软件。
基本概念
简单地讲，虚拟化允许将一个较大的服务器（主机或虚拟机管理程序）分割为更小的服务器（Guest、客户端或虚拟机），并共享组合的资源池。众所周知，大多数服务器都不会始终以全容量运行。因此，为什么不共享和组合它们？两个平均剩余 25% 的容量的服务器可变成虚拟机 (VM) 并托管在单个虚拟机管理程序上，这样该虚拟机管理程序就拥有平均大约 50% 的容量。当然，主机操作系统和虚拟机管理程序软件占用了大量的开销，而且还涉及到其他细节。
主机通过软件或模拟来管理客户端的资源。一般而言，虚拟机中没有任何信息能表明它实际上是虚拟的。在大多数情况下，在虚拟机上安装软件的管理员无法确定他们是否在使用虚拟服务器。最新的创新，比如内置于虚拟机管理程序的芯片组中的虚拟化技术，允许更准确地使用优化过的方式来处理硬件资源，比如外围设备驱动程序。
Rational 视角下的虚拟化
IBM 支持虚拟化，因此 IBM Rational 产品受虚拟化的服务器支持。但是，我们坚信虚拟化的基础架构可适当地进行管理和监视。至关重要的是理解您的虚拟化基础架构如何使用关联性 (affinity) 和过度承诺 (overcommitment)，而且还要确保您使用关联性和过度承诺的方式可获得 IBM Rational 软件的最佳性能。
何为 “关联性”？
关联性（Affinity）（也称为entitlement、pinning 和dedication）是将一个虚拟机上的一种或多种资源（例如内存或处理器）专门用于虚拟机管理程序上的相应资源的能力。主机会在虚拟机需要时分配资源。关联性可确保专用于该虚拟机的已请求资源在虚拟机需要时始终可用。
请记住，相同主机上的所有虚拟机都会共享系统资源。
过度承诺 是指虚拟镜像资源分配总量超过硬件的物理资源（一定要计算虚拟机资源）。为了满足虚拟机的峰值需求，虚拟机管理程序可从其他虚拟机获取资源。有时，所有虚拟机的组合需求可能超过虚拟机管理程序的实际资源量。有时，过度承诺可能导致主机上的所有虚拟机都受到影响。
虚拟化的 4 个维度
与任何可配置的技术一样，虚拟化也需要进行权衡。从 Rational 产品角度讲，如果使用虚拟化，我们建议您留意 4 个重要维度。这些维度或许是任何服务器最重要的特征：
CPU 和内存
磁盘输入/输出 (I/O) 存储 网络
表 1. 虚拟化的 4 个维度
最差的（未管理的）虚拟化特征 最佳的（受管理的）虚拟化特征 CPU 芯片组没有 VT 或 V-chip 支持 共享资源池 没有授权的、有保障的或有优先级的调度 其他 VM 的容量未知 vCPU 是物理 CPU 的一小部分 模拟超线程或多线程（非 Nehalem 类） 芯片组具有 VT 支持 CPU 关联性允许 VM 具有专用的 vCPU 在与物理 CPU 相等的水平上分配 vCPU 内存 内存和 CPU 不在同一位置 过度承诺导致过量交换（包括跨其他 VM 交换） 设置了关联性 内存和 CPU 在同一位置 磁盘 I/O 和存储 具有低 IOPS 的单一的本地 SATA 或 IDE 磁盘 本地 RAID，但驱动器槽有限 访问相同存储的通道数量未知 光纤通道连接的存储 文件存储 网络 一个 1G（或更少）网络端口由所有 VM 共享 专用网络端口 10G 或更好的网络 链接聚合
CPU
现代 CPU 的设计已考虑了虚拟化。例如，Intel 的 VT 和 AMD 的 V 芯片技术可确保 x86 CPU 最佳地处理虚拟化的负载。其他平台可使用硬件协助的虚拟化，这有望通过对主机 CPU 的直接寻址实现更高效的虚拟化。
在管理最差的虚拟化环境中，实际硬件和 CPU 不支持虚拟化，或者仅通过模拟和较慢的软件层来提供非常有限的支持。在管理最差的环境中，没有投入精力来跟踪其他 VM。事实上，其他 VM 可随意地从其他 VM 轻松地盗走 CPU 周期。零散的 CPU 有时可能会出现，或者是不可避免的，但在经过理想管理的虚拟化环境中，VM 可访问所有物理 CPU。
内存
在管理最差的虚拟化环境中，服务器内存和 CPU 未在同一个总线上。现代硬件利用了非一致内存访问 (NUMA)，因此，处理器访问本地内存的速度比访问位于另一个总线上的远程内存的速度更快。在现代硬件上，与专为高速和可伸缩性而设计的 NUMA 架构背道而驰是毫无意义的。
请提防您的虚拟化软件可能提供的选项和设置，因为它常常很容易与本来高效的 NUMA 架构相抵触。让位于位置 A 的内存引用位于位置 B 的 CPU 似乎很有用，但这种安排会为服务器带来额外的工作，可能导致性能下降。在理想的托管 VM 中，内存和 CPU 位于同一个总线上。
磁盘 I/O 和存储
在管理最差的虚拟化环境中，单个本地驱动器支持所有 VM。由于多个服务器共享同一个磁盘，所以实际的 I/O 活动现在发生在磁盘上的多个位置。本地硬盘驱动器可能因为活动量增加而更快地遇到故障。理想情况下，VM 被分配到特定的驱动器上，每个驱动器都有自己的 I/O 和机制。在一些理想环境中，存储可能位于 filer 上，它们非常适合虚拟化的需求并可通过光纤通道进行访问。
网络
可能很容易想到一种糟糕的虚拟化网络配置。网卡是根据它们的容量（例如 1 Gb/秒）来度量的。当由 VM 共享时，它们的容量就会被细分（2 个 VM 共享 1 Gb 将得到最大 500 Mb/秒）。管理最差的虚拟化环境中，环境中托管的所有 VM 都共用一个网卡或端口，总吞吐量会由 VM 瓜分。在管理非常理想的虚拟化环境中，每个 VM 都有一个专用的网络端口，或者 VM 共享一个 10 Gb 或更快的网络连接。链路聚合 是一种网络技术，其中结合使用了多个网络连接来实现冗余和吞吐量优化。
（管理）最佳的虚拟化特征
对于管理最佳、最理想的虚拟化环境，我们可将前面的要点简单地总结为：
虚拟 CPU 的数量绝不会超过物理 CPU 的数量。 每个 VM 的 CPU 分配与实际的物理 CPU 对应。 虚拟 RAM 量绝不会超过实际 RAM 量。 有充足的存储和网络可供访问。
一些人可能会争辩说，此建议违背了虚拟化的宗旨，或者我们有些担忧过度。在理想的世界中，每个 VM 能够按需访问无限多的资源。但是，在实际中，VM 必须共享资源。我们发现，在通过严格管理资源以确保始终有专用的 CPU、内存和其他资源时，Rational 软件在虚拟化服务器上的运行效率是最高的，且操作行为最有效。
如果管理得当，过量使用的资源分配可能是一种可行的虚拟化战略，但这只在实际资源得到紧密监视时才会有效。当确实出现过量使用时，组织必须愿意接受缓慢或无法预测的性能与优化的管理成本之间的折衷方案。
就像一种抢椅游戏
在管理糟糕的虚拟化环境中，虚拟机可任意地共享主机的资源。任何 VM 都可以请求获得比分配给它的更多的内存或 CPU，管理较差的虚拟机管理程序会提供这些资源，对来自其他 VM 的那些请求进行时间分片（time-slicing）。
这实际上就像抢椅游戏。一个 16 处理器、64 GB RAM 服务器可能托管 5 个不同的 4 处理器、16 GB RAM 服务器。当虚拟机 A 需要处理器周期时，它会向主机请求它们。主机将从任何其他 4 个 VM 获取任何未用的处理器时间，或者将其他 VM 的数据写入磁盘以释放资源。
如果 5 个服务器决不会同时以较高容量运行，那么此模型可能会完美地运行。最终用户决不会看到的后端进程可能运行得更慢，存在更多的中断。但是，在应用程序停止或变得缓慢时，最终用户接触的任务关键型应用程序可能会受到过量使用的影响。
案例分析 1. “The Mystery Menu”，3 个管理较差的云中的 Rational Team Concert
IBM® Rational® Performance Engineering 团队分析了来自某个云提供商的 3 个 VM 镜像。每个镜像都是不同的，就像我们从一个菜单中选择了小、中和大的分区大小。除了知道每个 VM 所提供的虚拟 CPU 和内存的理论容量之外，我们对 VM 的实际规格知之甚少（存储类型、网络、处理器速度等）。
VM A 有 4 个虚拟 CPU 和 8GB RAM；VM B 有 8 个虚拟 CPU 和 16GB RAM；VM C 有 16 个虚拟 CPU 和 16GB RAM。我们打算向每个镜像提供相同的负载量，查看不同大小的镜像的行为。
我们向 VM A（4 个 vCPU、8GB）提供了一个模拟的多用户负载，CPU 和内存容量使用率很快达到了 100%。性能还可以接受，但我们希望改进它。如果使用物理机器，我们可以立即增加核心数量和 RAM 量，我们过去就是这么做的。
我们向 VM B（8 个 vCPU，16GB）提供了相同的负载，结果令我们大吃一惊：性能显著下降，但与使用的 CPU 和内存成比例。CPU 和内存不再是瓶颈。相反，磁盘 I/O 成为了瓶颈。
当向 VM C（16 个 vCPU，18GB）提供相同的负载时，性能变得更糟糕，而且使用的 CPU 比例进一步降低。瓶颈仍然是磁盘 I/O。（澄清一下，我们将磁盘 I/O 平均分配到每个测试上，以 25% 的增量表示平均值。）
图 1. 未管理的云中的 3 个 VM
我们的解释是，这些镜像托管在一个未管理的云上，更大的 VM（B 和 C）事实上从其他 VM 盗取了核心和内存。由于不知道虚拟机管理程序的管理方式，所以我们只能推测过量使用的资源导致了磁盘交换。由于系统将大部分时间用于将其他镜像写入磁盘中，以获取我们的 VM 请求的资源，所以 CPU 未得到充分利用。（在其他 VM 请求周期和 RAM 时，我们的镜像可能也正写入磁盘中。）
图 2 提供了另一种查看相同的数据的方式，显示了未用和已用的内存、未用和已用的 CPU、未用和已用的磁盘的结果。这可以更清楚地解释所发生的事情。
图 2. 同样的 3 个 VM 的另一种分析
对于图 2，我们描绘了 3 个 VM，以便 CPU 和内存量彼此成比例，我们在图表中使用了 wicket 或未填充的条来表示 3 个 VM 未用的 CPU 和内存容量。VM A 使用了分配给它的所有 CPU 和内存，但没有使用太多磁盘。VM B 访问了更多的 CPU 和内存，但无法完全使用它们，因为增多的磁盘活动成为了它的瓶颈。VM C 提供了更多的 CPU，该 VM 仅使用了其中的一少部分，因为像 VM B 一样，VM C 的瓶颈也在磁盘上。
记得管理物理环境的人们可能对这些结果感到惊讶。在大多数具有物理硬件的情况下，增加 CPU 和内存也会提高性能。但是，在管理较差的虚拟化环境中，CPU 和内存是不受限制的，增加 VM 的 CPU 和内存有时可能导致更慢的性能。
我们的结论
我们的第一个结论是确认，在管理得当的 VM 中，Rational 软件将会正确地执行。案例分析 1 提供了未管理的云中行为不当的应用程序的示例。
第二，我们重申，VM 必须在托管的 环境中使用。在此案例分析中，我们没有环境中的虚拟机管理程序或其他 VM 的任何知识。我们相信性能取决于相同环境中其他 VM 的配置和行为，但我们无法确认这一点。
第三，我们告诫不要假设适用于物理硬件的原则也同样适用于 VM 环境。如果拥有过量的 CPU 和内存资源，那么增加 VM 的大小可能会带来提高，但我们实际上会过量使用资源。
最后，我们重申过量使用资源会得到糟糕的 VM，进而导致糟糕的应用程序性能的观点。在此示例中，我们的应用程序是 Rational Team Concert，但我们观察到，无论采用何种虚拟化技术和操作系统，其他 Rational 软件在管理较差的环境中的性能也很差。
案例分析 2. “那么，关联性有多重要？”ClearCase 具有异常负载，并运行在会产生“过量使用”的云中
我们的下一个示例是在一次会议中实时演示的。我们演示了设置关联性（有时称为授权 或专用资源）可稳定 IBM Rational 应用程序，而不使用关联性可能导致其他 VM 镜像能够接管资源，并严重减缓您的应用程序性能。
我们使用了一个具有 32 个虚拟 CPU 和 32GB RAM 的 Intel Sandy Bridge 服务器，它托管着两个独立的 IBM® Rational® ClearCase® 部署。每个 ClearCase 部署包含同等的 Red Hat Enterprise Linux (RHEL) 5.5 VM（4 个 vCPU、8GB RAM），以及一个 ClearCase VOB 服务器和托管 Web 视图的 ClearCase CM 服务器。我们使用了 VMware ESX 来托管 VM。部署 A 中托管 ClearCase 的 VM 未使用关联性，而部署 B 中的 ClearCase VM 同时拥有 CPU 和内存关联性。在云外部，在物理硬件上，我们使用了两个 IBM® Rational® Performance Tester 工作台对每个部署进行 100 个用户的负载模拟。
在 ESX 服务器上，我们创建了几个 VM，它们什么都不做，只创造 CPU、内存和磁盘需求。这些 VM 包含执行数学运算和分配所有空闲内存的简单程序，这会得到 100% 的内存使用率和 100% 的 CPU 使用率。我们启动了这些程序，以便以过量使用 ESX 服务器，使其使用率达到 300%。（我们要求这些行为异常的 VM 在虚拟机管理程序上使用 3 倍的物理 CPU 和内存量。）
图 3 和图 4 是从 Rational Performance Tester 获取的。它们展示了部署 A 和部署 B 所执行的 ClearCase 事务的平均响应时间（以毫秒度量）。两种部署的行为一致，直到到达 1,200 秒标记后我们在这些行为异常的 VM 上激活这些程序时。部署 A（其中 ClearCase VM 没有使用关联性运行）的响应时间迅速增加。部署 B（其中 ClearCase VM 使用关联性运行）偶尔会变得缓慢，但是，除了几个峰值外，它一直表现得很稳定。在到达 4000 秒标记时，这些行为异常的镜像停止了，部署 A 返回到正常状态。（请注意，y 轴上的刻度（它显示以毫秒度量的平均事务响应时间）在两个图表中是不同的。）
图 3. 没有关联性的部署 A
图 4. 具有 CPU 和内存关联性的部署 B
对比这些测试，没有关联性的部署 A 上的 ClearCase 操作平均花费了 118 秒才完成，而具有关联性的部署 B 平均仅花费了 18 秒。平均而言，具有关联性的部署 B 快 6 到 7 倍。
我们的结论
案例分析 2 可能是一种极端情况，因为我们创建了一个可能不切实际的行为异常的 VM。但是，我们能够清晰地表明，如果不知道虚拟机管理程序在做什么或者其他 VM 需要请求资源，那么应用程序的性能可能降低。
设置处理器和内存关联性，允许我们关注的 VM 上的应用程序保持一致的性能和行为，甚至在环境中的剩余 VM 执行极端负载时也是如此。
请注意，在没有关联性的部署 A 中，在行为异常的 VM 停止后，性能会恢复正常。如果您的环境中有 VM 允许过量使用资源或不受限制地运行，那么您可能会在自己的 VM 中看到类似的行为。
在此示例中，我们的 Rational 应用程序是 ClearCase，但我们已在管理较差的类似环境中的其他 Rational 软件中看到了类似的糟糕性能，无论采用何种虚拟化技术和操作系统。
虚拟化建立牢固根基，所以请学习如何聪明地使用它
毋庸置疑，虚拟化已建立牢固根基。越来越多的 IBM Rational 客户开始使用它和依赖它。但是，正如我们所展示的，如果使用不当，虚拟化会给软件的操作带来不利影响。
重要的是理解虚拟化和知道如何管理它。我们希望，我们的案例分析展示了管理较差的虚拟化环境的一些可能的负面影响。在考虑我们的案例分析后，您有可能会识别管理较差的虚拟化环境的症状。在第 2 部分中，我们将探索虚拟化异常的更多症状。我们还会提供故障排除技巧并展示特定于供应商的示例。