在第 2 部分，他们将展现更多的案例及和故障排除技巧。这个由两部分组成的系列文章将通过具体示例探讨虚拟化的优缺点。在第 1 部分中，我们将从总体上解释虚拟化，尤其是它与 IBM Rational 软件的关系。我们将覆盖虚拟化的四个维度，CPU、内存、
磁盘输入/输出（I/O）及存储、网络等应如何通过关联性（专用资源）被恰当地管理而不会过度承诺。我们所给出的例子展示了被恰当管理的虚拟化是如何彻底影响 IBM® Rational® 产品。尤其是我们所展示的两个">案例分析，其中的 IBM® Rational Team Concert 及 IBM® Rational® ClearCase® 托管在没有关联性配置的虚拟机中，虚拟环境配置欠佳，从而使之性能糟糕。
在第 2 部分中，我们将更加深入探究针对过度承诺的折中考虑。基于我们在 Rational 产品和曾服务客户身上测试得来的经验，我们将提供建议和技巧，故障排除和特定于供应商的示例来帮助您更好地管理您的虚拟化基础设施。所有提及的故障排除场景和建议都来自 jazz.net Deployment wiki。
案例分析 3. 结合 ClearCase 探索过度承诺（overcommitment）
案例分析 2 演示了当托管在没有专用资源的虚拟机（VM）上时，IBM Rational ClearCase 是如何糟糕。我们建议要为 IBM Rational 产品配置关联性和专用资源，来避免可能存在的过度承诺。然而，我们也认识到受管理的过度承诺对于虚拟化而言仍然具有显著的价值。案例分析 3 着眼于不同程度的过度承诺。
在我们其中之一的测试中，我们考察了一台拥有 4 个八核 CPU 及 64 GB内存的 Intel Westmere-EX 服务器。这台服务器启用了超线程，对于虚拟机管理程序（hypervisor）而言，这台拥有 32 个核心的服务器就如同拥有 64 个逻辑处理器（64 vCPU）。ClearCase CM 服务器安装在其中一个拥有 4 vCPU 和 8 GB RAM 的 VM 上，但没有专用资源或关联性。
在同一个虚拟机管理程序上我们还创建了 96 个拥有 4 vCPU 和 4 GB RAM 的 VM（64-位 RHEL 5.5）。这些 96 个镜像被用于产生背景负载。这 96 个镜像被组织成六组 16 VM 群组。每一个 16-VM 群组包括 64 vCPU 和 64 GB RAM，这与 Westmere-EX 自身的硬件维度是相符合的。因此每一个 16-VM 群组都 100% 体现了 Westmere-EX 服务器的硬件配给。
为了捕获基线平均响应时间数据（如表 1 a 行所示），我们仿真了 100 个用户的 UCM 负载并传递给 ClearCase CM 服务器。所有六组 VM 则处于挂起状态。
在下一个测试（表 1 中 b 行到 g 行），我们使用了六组 16 VM 的群组来创建背景负载。每一个 VM 都托管一个本机程序，运行多线程的平方根数学计算并分配了内存。这一“贪婪”程序确保每一个 VM 客户端将会 100% 消耗为它分配的处理器和内存。每一个测试以 16 个 VM 或 100% 相应的 Westmere-EX 服务器物理硬件为单位增加背景负载。
行 b 显示了 100 个用户 CC CM 服务器测试的平均响应时间数据，以及相应的 100% 的 Westmere-EX 负载（一组 16 VM 都运行“贪婪”程序）。行 c 到行 g 显示了 100 用户 CC CM 服务器测试随着逐步增加每一组 16 VM 的平均响应时间数据（每一步都逐步增加 100% 相应的 Westmere-EX 服务器负载）。
行 g 显示了在所有 96 个 VM 都在运行“贪婪”程序，即 600% 物理 Westmere-EX 服务器容量的情况下，我们的 100 个用户 CC CM 服务器测试的平均响应时间。响应时间非常糟糕。我们过度承诺的服务器无法在合理的响应时间内为 100 个用户 CC 负载提供服务。
让我们的服务器保证合理的性能的唯一办法是运行在一个具有专用资源的 VM 上。行 h 显示了与行 g 相同的测试，但 CC CM 服务器具有关联性和专用资源。在 600% 的负载下，CC CM 服务器以可接受的性能进行了响应。
表 1：使用 ClearCase 来展示关联性效果的性能测试
a
物理机器 b
100% 无关联性的负载 c
200% 无关联性的负载 d
300% 无关联性的负载 e
400% 无关联性的负载 f
500% 无关联性的负载 g
600% 无关联性的负载 h
600% 有关联性的负载 产生流 1.03 1.57 1.87 3.48 29.81 39.76 153.29 1.88 产生活动 0.33 0.50 0.55 1.64 24.84 44.35 176.21 0.61 集活动 0.59 0.92 1.04 3.59 68.55 69.45 159.14 0.99 产生目录 1.98 2.78 3.04 4.93 64.72 70.43 161.33 3.35 检出目录 0.72 0.91 0.97 2.08 30.82 38.17 125.30 1.12 检入目录 0.61 0.78 0.82 1.35 11.86 13.73 68.03 0.91 产生文件 1.40 1.78 1.93 3.23 33.10 37.54 95.58 2.28 检出文件 0.91 1.25 1.45 1.51 3.81 5.42 68.12 1.47
这个例子展示了多个情况。没有关联性，产品的性能会大幅度降低到不可用的程度。更进一步，仅仅拥有 CC CM 服务器访问权限的 ClearCase 管理员无法理解甚至无法猜测究竟发生了什么情况。这个背景负载也许过于极端，但非常清晰地演示了过度承诺的影响。
不过，虚拟化并不是一个无助的命题。比较表 1 中的 c 和 h 行，这两行显示了 CC CM 服务器在没有关联性而虚拟机管理程序承担 200% 负载时，以及 CC CM 服务器有关联性而虚拟机管理程序承担 200% 负载时的情形。两种情形相似的响应时间足以表明，如果不可能有专用资源时虚拟机管理程序的能力无法承担超过 200% 负载，而对于资源有关联性的配置则可以提供可接受的响应时间。这个事实表明，如果管理得当的话，过度承诺可以成为一个切实可行的选择。
案例分析 4. 过度承诺或低于承诺：性能 vs. 能力
案例分析 4 比较了两个不同 VM 配置在同一台 ESX 服务器，即一台 32 vCPU 及 32 GB RAM 的 Intel SandyBridge 服务器（E5-2680 @ 2.70GHz）上时 ClearCase 的响应时间。配置 A 使用了 100% 的 VMware ESX 的能力，而配置 B 则使用了 150%。
在配置 A 中，ESX 服务器托管 VOB 服务器，一个 ClearCase Remote Client（CCRC）服务器以及两个 VM 运行案例 3 中描述的“贪婪”程序。每一个 ESX 服务器上的 VM 运行 RHEL 5.6，并分配了 8 vCPU 和 8 GB RAM。配置 A 拥有 100% 专用的 ESX 硬件资源。
配置 B 使用配置 A 相同的四个 VM；不过，额外的两个 VM 被增加到 ESX 服务器上。这两个额外的 VM 具有 8 vCPU 及 8 GB RAM 来和其他四个 VM 对齐。当所有六个镜像都在使用时（48 vCPU 及 46 GB RAM），ESX 服务器被分配了 150% 的能力。两个额外的 VM 创建了一个二级 CC 区域，并执行在两个 CC 区域之间的活动来创建在 ESX 服务器上的负载。这些活动包括导入、mklabel 及构建操作，并在测试期间持续运行。
在本案例的背景负载中有两台其他的 ClearCase 虚拟机组成：一台 VOB 服务器及一台 ClearCase 客户端来作为视图（view）和构建服务器，也同样执行 mklabel 和导入操作。一个专用的 1 GB 网络连接着这些服务器和其他镜像。
这一 ClearCase 测试环境是实际 ClearCase 开发 VOB 的一个备份。100 VOB 被散布到两台服务器上。10 个最高容量的 VOB 被托管在 VM 镜像（VOB 服务器）上。剩余的 90 个 VOB 被托管在一个分离的物理服务器上，在此服务器上还有许可证服务器（license server）和注册服务器（registry server）。
这一用于比较的工作负载仿真了在一个 12 小时的时间段内大约 250 个并发用户。背景工作负载由以下方面组成：
200 个 CCRC 用户每小时执行 15 次事务 50 个动态视图用户用户每小时执行 15 次事务 38 个持续 clearmake 构建运行在 12 个不同的额外构建主机上（Unix 及 Windows） 1 台独立的 Unix 客户端运行集成任务
表 2. 两个 ESX 服务器配置
配置 A
（运行 100% 能力的 ESX 服务器） 配置 B
（运行 150% 能力的 ESX 服务器） ESX 服务器
(32 vCPU，32 GB RAM) 服务器托管 4 个镜像: 1 台 VOB 服务器 1 台 CCRC 服务器 2 台“贪婪”服务器 服务器托管 6 个镜像: 1 台 VOB 服务器 1 台 CCRC 服务器 2 台“贪婪”服务器 2 台 CC 服务器在分离的区域
图 1 比较了两个配置在超过 12 个小时的平均相应时间。相比配置 A，对于基本 ClearCase 操作配置 B 慢了 35%，UCM 操作慢了 25%。构建时间也慢了 22%。
图 1. 比较两种 ClearCase 环境
进一步探讨关联性和预订
在第 1 部分，我们定义了关联性来作为在一台虚拟机上专用一个或更多资源的能力，这些资源来自虚拟机管理程序的相应资源。在一些虚拟机管理程序中，还有预订（reservation）的概念。预订在含义上与我们用来表达关联性的概念相一致。在这些系统中关联性标志着更多的是一个 VM 的 CPU 可以恰好指派给多少个物理核心。如果您指派您的专用 VM 到特定的 CPU，您也应同样分配您其余的 VM 到不同的 CPU 上。具有 CPU 关联性的 VM 或许性能更糟糕，因为他们也许无法被安排到多线程任务上。
我们建议 VM 拥有对虚拟机管理程序专用资源的访问。对于虚拟机管理程序是超线程，或者虚拟机管理程序被设计用于执行资源的自动化加载平衡的情形，还有一些额外的概念需要记住。
CPU 关联性注意事项
如果使用 CPU 关联性，考虑以下问题：
如果您的虚拟机管理程序使用自动化加载平衡，CPU 关联性将会阻止虚拟机管理程序有效地工作。 在一个 VM 上的 CPU 关联性可能会阻止同一个虚拟机管理程序上的其他 VM 虚拟机管理程序。 在从一个虚拟机管理程序上将一个具有 CPU 关联性的 VM 移动到另外一个虚拟机管理程序上时，有可能会需要不同的处理器配置。 在多核或超线程机器上的 CPU 关联性将有可能阻止 VM 安排多线程任务，因为它对指定核心的请求是有限的。
总结和结论
这一由两部分组成的系列文章探讨了虚拟化的优点和缺点，并使用了两个特定于 IBM Rational 产品的示例。
在第 1 部分中，我们覆盖了四个重要的维度，这些参数在使用虚拟化时必须被恰好判断：CPU、内存、磁盘 I/O 和存储，以及网络。我们强调了关联性（专用资源）的重要性，以及演示了当资源被过度承诺时有可能会发生的情况。
我们还提供了关于管理较差的虚拟化可能会大幅影响 IBM Rational 产品性能的示例。我们也展示了两个案例，其中的 IBM Rational Team Concert 和 IBM Rational ClearCase 当它们被托管在没有配置关联性，配置较差的虚拟环境上时性能很糟糕。
在第 2 部分中，我们更深入地了解了对过度承诺的权衡。
根据我们测试 IBM Rational 产品以及我们以往建议客户的经验，我们提供了建议和提示，故障排除策略和特定用户的示例，来帮助管理您的虚拟化基础设施。故障排除情形和建议可以从 jazz.net Deployment wiki 上看到。
虚拟化的关键优势
当前市场上所提供的硬件倾向于使它们自身更好地被分割和被虚拟机管理程序所使用，来托管多虚拟机。这些新机器节省空间和电力消耗，而且更加有效利用资源。 虚拟化基础设施可以增加部署新 VM 的速度（复制已
有的 VM 或新的可立即使用的 VM）。 高可用（High-availability，HA）以及灾难恢复（Disaster Recovery，DR）解决方案可以与虚拟化一起集成，来获得更完整和有效成本的企业级配置。然而，需要注意的是，在一个单独的虚拟机管理程序上托管多个 VM 可能会导致一个单点失败。您可以了解这一特定领域，并使用 SAN 或 NAS 存储来为 VM 镜像和/或在一个备用的虚拟机管理程序上部署已准备要用的 VM。 VM 及它们的虚拟机管理程序可以从任何地点通过终端被管理（而不仅仅是在一个实验室中），从而可以优化和减少管理成本。
了解完所给出关于较差管理的虚拟化可能出现的陷阱，您可能仍旧疑问这是否真的值得投资和劳神。但答案是非常值得！虚拟化是一个值得的投资，但我们也强调，虚拟化必须被恰当管理。在一些组织里，虚拟化是必然和永久的。消失的是专用的物理硬件、专用于托管一个单独应用的单台服务器。那些硬件厂商都在趋向于生产能增加更多处理器和内存的平台，切分新的硬件给虚拟机是最佳的方式来确保资源的有效性。
这一系列所讨论的关键原则
尽可能分配 CPU、内存和网络作为专用资源。确保可以通过专用的 I/O 访问充足的共用存储。 只要可能，考虑 CPU 及内存关联性。在某些案例中，这将导致同一台主机上的其他 VM 性能变差。在某些案例中，虚拟机管理程序会作为集群的一部分，牵制资源可能会阻止整个家族的 VM 得以优化运行。这些是针对所有 VM 在 CPU 和内存资源无法被专用或预订时的一些性能权衡策略。 只要可能，通过监管资源消耗来管理您的虚拟化资源。了解有哪些其他的产品被托管在同一台 VM 上，以及那些被同一个虚拟机管理程序所托管的其它 VM 在做些什么。 只要可能，避免资源过度承诺。也就是说，任何 VM 或 VM 组合的资源永远不应超过虚拟机管理程序的物理资源。 如果您怀疑有与虚拟化相关的问题，收集关于 VM 配置、虚拟机管理程序和其他被同一个虚拟机管理程序托管的 VM 的特定数据。避免有偏见的信息，并使用脚本来收集特定，也许是定期的度量信息。
IBM Rational 产品应特别考虑的因素
不同的软件产品的表现很不同。在某一个 VM 上的某一个产品上使用得很好虚拟化参数不一定对其他的产品有效。在这一系列文章中，我们检验了 Rational Team Concert 及 Rational ClearCase。其他 Rational 产品也许会表现得类似，也或许完全不同，这就是我们强调要理解虚拟化的各个关键维度的原因。
例如复杂多层应用程序，例如 Rational 协作化生命周期管理（Rational Collaborative Lifecycle Management）产品或 Rational ClearCase 要求就近访问专用资源。我们曾一起工作过的客户就曾遇到过由于并未强制执行上诉所列出的关键原则，而导致其在虚拟环境中的 Rational 产品性能很差的情形。