IBM Lotus Domino，Linux，虚拟化，可伸缩性：不再是相互排斥的术语

您是否对于不得不将 IBM Lotus Domino 系统被迫适应基础设施而感到厌烦？使用最新版本的 64 位 Lotus Domino on Linux® 和虚拟化技术，现在可以在单个物理基础设施内为 Lotus Domino on Linux 实现大型企业环境。本文将描述一些已完成的基准测试，以及该解决方案的早期采纳者的采用效果，展示了基础设施如何适应 Lotus Domino 并一同扩展。

虚拟化目前是计算机界的一个热门词汇。和任何流行词一样，应该谨慎看待它。虚拟化虽然有其优点，但任何新的技术都可能伴随着固有的缺陷。本文演示在一个有 Linux guest 的虚拟环境（VM）中实现 Lotus Domino，并且在生产环境中取得高度的可伸缩性。我们将讨论最新的基准测试结果和现实生产中的例子，证明 Lotus Domino 在虚拟 Linux 环境中有高度的可伸缩性。另外，本文还展示一个最新基准测试的结果，在该基准测试中，可以在一个运行在 VM 下的 Linux 内核中达到 102 K Lotus Domino NRPC 邮件基准测试用户。

我们还讨论当今市场上一些不同的虚拟环境的功能，以及它们可以为 Lotus Domino 带来的优点。通过利用这些新的功能，可以重新设计 Lotus Domino 环境的架构，进一步节省成本。

虚拟化和 Lotus Domino：有何优点？

运行虚拟化环境获得的优点取决于选择部署的虚拟化技术。并非所有的虚拟化技术都具有相同的能力或提供相同的优点。理解特定的虚拟化环境的能力和优点，可以避免每种虚拟化技术固有的局限性。

例如，在如今的环境中，如果在专用硬件上运行 Lotus Domino，当一个服务器的资源不够用时，接下来必须做什么？首先，必须购买、订购和等待安装新的硬件。接着，必须购买和安装新的 Lotus Domino 许可。然后，必须构建和配置一个新的 Lotus Domino 服务器。然后，必须将一些工作负载从资源紧张的服务器迁移到新的服务器。而在虚拟环境中，只需启用备用容量，或者向现有硬件添加更多容量，并为新的资源重新配置虚拟映像，就这么简单。当资源达到极限时，不需要管理和操纵 Lotus Domino 服务器。虚拟化可以让基础设施适应 Lotus Domino 环境的需要，而不必让 Lotus Domino 环境适应基础设施的限制。

虚拟环境的另一个优点是可以执行服务器整合和基础设施缩减，从而降低成本。在虚拟环境中，由于可以动态地扩展新的资源，因此可以设计一个能够利用这些能力的 Lotus Domino 环境。例如，通过在 VM 下作为 guest 在一个单独的 Linux 映像中运行多个 Lotus Domino 服务器，可以避免服务器之间的物理硬件连接。取决于整合的程度，还可以减少或消除围绕物理服务器的当前支持基础设施。

通过降低 Lotus Domino 环境的复杂性，可以减少需要在环境中运行的服务器的数量。这直接导致管理（即安装和升级）和支持（即性能、容量、问题诊断过程）环境的成本的降低。我们知道，打破惯性思维而不仅仅是将现有的映像移植到虚拟环境，可以大大降低运行 Lotus Domino 基础设施的成本。

图 1 显示一个从分布式物理 Lotus Domino 基础设施转移到集中式虚拟 Lotus Domino 基础设施的例子。

图 1. 虚拟化部署的例子

在这个例子中，我们从 18 个硬件系统、操作系统映像和 Lotus Domino 邮件服务器转移到 6 个 Lotus Domino 邮件服务器，这 6 个邮件服务器在一个 VM 下的两个 Linux guest 中。

该实现假定选择的 VM 和硬件具有支持这个工作负载所需的容量。而且，由于多个 Linux guest 在相同的物理足迹中运行，它们可以利用虚拟 LAN（VLAN）技术。这不仅避免了使用 hub 服务器的需求，而且 VLAN 还允许 Lotus Domino 服务器之间以内存的速度而不是 LAN 的速度相互通信。此外，也不需要使用专用的骨干网络来处理服务器之间的通信（邮件、集群、复制和管理）。

飞机、火车和汽车：并非所有的虚拟化都是相同的

正如本节标题的意思一样，提供运输的方式有多种，每种方式都有其特点，例如速度、容量和距离。如今，实现虚拟化的方式有很多种。有些虚拟化是在硬件中完成的，有些是在固件中完成的，还有一些是在软件中完成的。有些虚拟化则结合了这几种方式。具体的配置取决于选择的虚拟化产品和提供支持的软件、固件和硬件。

然而，并非所有这些虚拟化技术都能解决相同的业务需求，或提供相同的优点。取决于具体的虚拟化技术和实现方式，不同虚拟化技术提供的性能特征可能各不相同。虚拟化技术的开销越大，就需要越多的资源来运行它的实现。

虚拟化不是新的概念，它存在至今已经超过 40 年了。1967 年，虚拟化随 CP-67 首次作为一个产品出现。提供虚拟化的供应商有不同的历史和经历，近年来有很多新的动作。IBM 在改进虚拟化环境和提高性能方面有超过 40 年的经验。

虚拟化的不同方面有不同的相关成本。例如，与虚拟化 I/O 的成本相比，在处理器上实现线程虚拟化所需的成本是不相同的。这意味着必须看到虚拟化环境的所有成本，包括处理器、内存和 I/O，才能理解运行这个虚拟化环境的总体成本。取决于启用的特性和功能，Lotus Domino 对处理器、内存和 I/O 有重大的影响，要想评估为 Lotus Domino 实现虚拟化的成本，就必须理解这些组件是如何工作的。

如图 2 所示，有不同的方法可完成虚拟化的基本服务器实现，包括硬件分区（hardware partitioning）、裸机管理程序（bare-metal hypervisor）和托管管理程序（hosted hypervisor）。

图 2. 基本服务器虚拟化方法

还有一点很重要，那就是理解虚拟化如何构建它的管理程序（hypervisor）实现。如图 3 所示，不同的实现各有其优点和问题。

图 3. 管理程序实现方法

理解了虚拟化的实现方式，就可以更好地理解如何利用它的能力。2008 年 4 月出版的标题为 “IBM Systems Virtualization: Servers, Storage, and Software” 的 IBM Red Paper（REDP-4396）详细描述了不同的虚拟化技术以及它们的优点和存在的问题。

VM 下的一个 Linux 内核中的 102 K Lotus Domino 基准测试用户

在 2008 年第四季度，发布了用于 Linux 的本地 64 位版本的 Lotus Domino。另外，根据以下两个目标，设立了一个基准测试：

• 我们想要看到，与旧的 32 位代码相比，使用新的本地 64 位代码对一个 Lotus Domino 分区服务器中 Lotus Domino 的可伸缩性有什么影响。
• 我们想要看到，在 VM 下运行 Lotus Domino 的 64 位操作系统环境中，虚拟化 Linux 内核可以承受多大的工作负载。

我们在马里兰盖瑟斯堡的 Washington System Center 执行该基准测试。对于这个基准测试，使用了一个 z10 EC 2097-764 系统。该系统有 64 个通用处理器（不包括 I/O 处理器、备用处理器等）和 1.52 TB 内存。这个系统只有一部分被分配给这个基准测试。这个系统上构建了一个逻辑分区，即 LPAR，有 4 个处理器和 48 GB 内存的初始配置。在这个 LPAR 中，我们构建了一个 VM 操作系统映像，然后在 VM 下构建一个 Linux 内核，可以使用 4 个引擎和 10 GB 的内存。在这个拥有 4 个中央处理器（CP）或引擎/10 GB 内存的初始配置中，我们将运行初始的单个 Lotus Domino 分区服务器测试。

注意，这个系统不是专用于这个 Lotus Domino 基准测试的，它同时还运行其他工作负载。除了 Lotus Domino 基准测试外，在相同的物理硬件上还运行着另外两个客户基准测试。其中一个基准测试用于保险业的客户，另一个基准测试用于银行业的客户。在相同的物理硬件中，每个基准测试有它自己的 LPAR 和虚拟化。除了这些工作负载外，这个系统上还运行其他一些较小的 LPAR。

通过不同光纤连接到这个物理系统上的直接访问存储设备（DASD）加起来超过 200 TB。对于 Lotus Domino 工作负载，根据 extended count key data（ECKD）设备的定义，我们最终有大约 20 TB 的 DASD 连接到这一个 Linux 内核。经常会遇到这样的问题：是使用 ECKD DASD 还是使用 Fibre Channel Protocol（FCP）连接的 SCSI 逻辑单元数（LUN）。每种选择各有优缺点。在 Linux 环境中使用 FCP 连接的 SCSI LUN 的最有效的方法是通过专用的 FCP 子通道，而不是使用 z/VM® 模拟设备。

在这种情况下，可以使用 Linux SCSI 栈来管理、读取和写入目标 LUN 上的数据。这种配置的缺点是，目标磁盘设备在 Conversational Monitor System（CMS）环境中是不可见的，所以不能使用 z/VM 工具和过程辅助管理这些设备。目标磁盘设备只在 Linux 环境中可见，因此必须在该环境中进行管理。IBM Boeblingen Lab 的性能研究表明，就每秒传输的兆字节数而言，使用专用的 FCP 子通道和 SCSI LUN 可以提供最佳性能。从 z/VM 角度看，这个解决方案所需的处理器开销也是最低的，因为既然 I/O 过程是基于 qdio 而不是开始子通道（start subchannel），那么就可以使用硬件 qioassist（在 z9® 和 z10 上可用）。要了解更多关于 qdio 的详细描述，请参阅参考资料小节中的文章 “Queued Direct I/O （QDIO）”。

这个解决方案的缺点是，System z® 通道子系统不能自动为目标存储设备提供多路径支持。所有多路径必须通过在 Linux 中手动定义一个多路径配置并为其使用设备映射器支持来完成。

使用 ECKD DASD 设备的优点是，它们在 z/VM CMS 环境中是可见的，因此可以从典型的 z/VM 系统编程环境中轻松地管理它们。还有一个优点是，对目标存储子系统的多路径的管理完全包含在硬件通道子系统中，不需要从 Linux 端进行任何的人为干预。缺点是，System z I/O 架构规定，一个特定的目标设备（UCB 或 DASD 子通道）上每次只能有一个活动的 I/O 操作。可以通过使用并行访问卷克服这个限制。通过最新版本的 Linux DASD 驱动器中提供的新的支持和 DS8300 hyperpav 特性，可以有效地在 Linux on System z 中使用 PAV，并取得与前面描述的那些专用 FCP 环境近似的吞吐率。

我们的环境由 ECKD 设备组成，它们是 27 个 3390 型号的设备。之所以使用 ECKD 设备，是因为它们可以立即使用，而 FCP SCSI 环境则不能。

对于第一组测试，我们为 Lotus Domino 提供 4 秒的 CP 和 10 GB 内存来建立用于在 Linux guest 中运行 Lotus Domino 服务器的基准测试。在这一系列的测试中，我们将这个 Lotus Domino 实例的负载增加到接近令它崩溃为止。这种方法使我们可以伸缩这个 Lotus Domino 实例，看它在资源不受限的情况下可以承受多大的工作负载。由于我们想比较之前的 Lotus Domino 发行版基准测试，我们重新构建了它们的环境、配置和工作负载。这个基准测试的基本定义如下：

• 无事务日志记录
• R6Mail 工作负载
• VM 下的一个 Linux guest 中的一个 Lotus Domino 服务器

R6Mail 工作负载通过使用从 Lotus Notes 客户机到服务器动作的邮件和日程表操作进行模拟。对于每个用户，它每小时将发送 4.67 条消息。要了解关于这个工作负载的更多信息，请参阅 developerWorks® 文章 “The new Domino 6 Notesbench workloads: Heavier by request!”。

如图 4 所示，我们可以在一个 Lotus Domino 实例中最多达到 19 K 到 20 K 的基准测试用户。

图 4. 单个 Domino PARrtition（DPAR）服务器测试期间已连接/活动了 15 分钟的用户

对于这些测试，我们度量了使用的 CP 时间（秒），而不是处理器繁忙时间所占百分比，如图 5 所示。

图 5. 单个 DPAR 测试中使用的 CP 时间（秒）

处理器繁忙时间所占百分比是将使用的资源（CP 时间）除以可用资源得到的计算结果。在过去，这个计算的分子（使用的 CP 时间）是随机的，而分母（可用的物理处理器资源）是静态的。由于等式中的一半是静态的，并且只有当一个单元被升级或替换时结果才会改变，因此处理器繁忙时间所占百分比可以很好地指示当前被使用的资源。然而，在虚拟环境中，分母现在也是随机的值。

最近 5 年多的时间里，在大型企业硬件中，一个给定的虚拟环境中处理器的数量每 10 秒就变化一次。在这些配置上，测试中的可用处理器数量现在是一个分数，因为每一分钟它都要变化数次。例如，这一分钟处理器的数量是 4.5，到下一分钟又变成了 5.166。这种变化意味着现在处理器繁忙时间所占百分比的分子和分母都是随机的，因此这个值在生产虚拟环境中没有用处。而通过度量 CP 时间，可以知道环境所使用的处理器资源的数量，而不是虚拟环境中有多少可用的处理器资源，后者是不断变化的。

在我们的测试中，我们使用一个 10 分钟的收集时间间隔。这个时间间隔意味着在 600 CP 秒（10 分钟 x 60 秒）内，使用相当于一个完整引擎的处理器容量。

虚拟环境的另一个缺点是，处理器繁忙时间所占百分比会令人在理解还剩多少容量时产生误解。如果一个系统有 2 个物理处理器，并且定义了 2 个操作系统映像，每个映像有 2 个逻辑处理器，那么这种配置总共有 4 个逻辑处理器。如果两个操作系统映像都是用虚拟化技术同等对待和管理的，那么当两个操作系统映像的处理器繁忙时间所占百分比为 50% 时，对于物理系统而言处理器是 100% 繁忙，已达到容量的极限。理解了当前使用的资源数量（CP 时间），而不是一个虚拟容量数字的百分比，就可以更好地管理和监视环境。

除了评测使用的资源外，我们还观察了运行基准测试用户的成本。图 6 显示活动了 15 分钟的 Lotus Domino 用户的处理器成本。对于每个抽样周期，将 Lotus Domino 服务器实例使用的处理器时间（秒）除以活动用户的数量，就得到这些数字。

图 6. 每个活动了 15 分钟的用户的处理器成本

图 6 表明一种有趣但又在意料之中的趋势。每个用户的最高成本发生在基准测试的开始处。由于用户在登录和验证权限，处理开销使成本增加。例如，若在繁忙时段重新启动服务器，那么需要准备好所有用户重新登录该服务器时所需的额外处理器资源。在用户完成身份验证并建立连接会话之后，稳定状态下的成本将降低。

由于这个原因，如果装载上一组用户令处理器的负载达到极限，基准测试往往缩短装载时间，留出一段时间用于评测稳定状态。此外还可以看到，在服务器崩溃之前，在运行结束时，每个用户的成本突然增高，这表明服务器在崩溃之前已经开始受到压力。该测试只有一个 DPAR，并且所有邮件都是本地传递的，因此可以理解，当使用多个 LPAR，并且同时有本地和远程邮件时，每个用户的成本将有所上升。

我们使用这个基准测试的一个目的是看看是否能在一个 Linux guest 中承受 100 K 基准测试用户。根据单个 Lotus Domino 分区服务器测试，我们计算出，在一个 Linux guest 中，6 个 Lotus Domino 分区服务器中的每个 Lotus Domino 分区服务器需要运行 17 K 基准测试用户。我们增加了 5 个额外的 Lotus Domino 分区服务器，将这一个 Linux guest 扩展到 6 个 Lotus Domino 分区服务器中。而且，我们又增加了 4 个 CP，将内存增加到 26 GB，并增加更多 DASD，以支持全部用户负载。

每个 DPAR 在 /notesdatax/mail 路径下都有它自己的 notesdata 目录和 4 个惟一的邮件目录。我们将用于用户邮件箱的 DASD 分布在这些挂载点上。每个 Lotus Domino 分区服务器被定义为在一个单独的用户 ID 下运行，并且有一个惟一的 IP 地址。由于所有这些 Lotus Domino 分区服务器都在相同的物理足迹上，因此可以利用 VLAN，在 Lotus Domino 分区服务器之间以内存速度（从 TCP/IP 缓冲区到 TCP/IP 缓冲区之间的传输）传输数据，而不必通过物理骨干网在服务器之间传输。

第一个 100 K 测试被定义为以和单个服务器测试相同的速度增加到 60 K，然后放缓增加用户的速度。但是，当到达 50 K 用户时，我们开始观察到运行出现问题。邮件开始备份，客户机上的响应时间开始加长。根据对 Lotus Domino 和平台数据的分析，我们检测到一个 I/O 瓶颈。虽然 DS8000® 的响应时间少于 2 毫秒，VM 的响应时间也少于 2 毫秒，但是我们观察到 Linux 内核的响应时间却超过 80 毫秒。

在调查这个问题的过程中，我们尝试了一些测试，看是否能克服这个 I/O 瓶颈。当运行不同的测试时，我们做了以下事情：

• 减少写入到 log.nsf 的数据量
• 将 Linux guest 内存增加到 48 GB
• 增加 NSF_Buffer_Pool 大小
• 将 mail.box（每个 DPAR 有 6 个）移到一个 RAM 磁盘上
• 将 names.nsf 移到一个 RAM 磁盘上
• 将 log.nsf 移到一个 RAM 磁盘上
• 将 mail.box、log.nsf、names.nsf 移到一个 RAM 磁盘上
• 更改 mail.box 的数量
• 更改服务器任务中的线程数
• 更改用于本地和远程邮件传递的路由器任务中的线程数
• 将 Lotus Domino 服务器升级至黄金级 GA 代码
• 设置 MailLeaveSessionsOpen=1

虽然这些变化对于我们遇到的 I/O 瓶颈和可伸缩性问题无济于事，但将 notes.ini 参数 MailLeaveSessionsOpen 设为 1 的确对使用的处理器资源有可观的影响。我们看到，每个活动了 15 分钟的用户的处理器成本从 .07 减少至 .05 秒，这意味着运行相同工作负载所需的处理器资源减少大约 28%。这个参数告诉 Lotus Domino 将不同服务器之间传递邮件的会话保持在开启状态。在设置该参数之前，Lotus Domino 需要建立与接收消息的邮件服务器的会话，进行认证，发送消息，然后撤销会话。如果使会话保持开启状态，Lotus Domino 可以重用已有的会话，而不必重复地建立会话。

最终，我们确定，I/O 问题是由 Linux 支持 ECKD 卷的方式和逻辑设备级别上请求的排队方式引起的。SLES 11 中为并行访问卷（PAV）提供了一个修复，但是这个修复不能用于这一次的基准测试。我们重新配置了 I/O 子系统，将卷划分成较小的 3 GB 的逻辑设备，从而为等量的 DASD 创建更多的逻辑设备。这种配置可以为 Linux 提供更多的逻辑驱动器，从而可以将 I/O 分散到相同的 DS8000 系统上。

重新配置 DASD 后，对于 8 个 CP 的容量而言，最高可以将负载加到大约 85 K 用户。我们再增加 4 个 CP，将 VM 和 Linux guest 可用的 CP 增加到 12 个，以便运行接下来的测试。在不必重新构建、重新分布或者为附加容量而对 Lotus Domino 做出任何更改的情况下，虚拟 guest 和 Lotus Domino 服务器的 CP 数量增加了 50%。

有了这些额外的容量，对于 VM 下运行的一个 Linux guest 中共 102 K 用户的稳定状态，在 6 个 DPAR 的每个 DPAR 中可以达到 17 K 用户的稳定状态。图 7 显示活动了 15 分钟和已连接的用户数。

图 7. 102 K 运行期间的用户数

在稳定状态期间，测试期间平均每 10 分钟有大约 150 万 Lotus Domino 事务，即每小时大约有 900 万 Lotus Domino 事务，如图 8 所示。

图 8. Lotus Domino 事务数量

在运行这些负载时，这个 Linux guest 的总体 I/O 工作负载达到每秒 27 K I/O 的高峰。在 DS8000、VM 和 Linux 内核中的平均响应时间少于 2 毫秒。当运行这些负载时，之前提到的其他工作负载也在同一个服务器上活动，因此这个服务器每秒 I/O 总量要远远大于 Lotus Domino 工作负载导致的 27 K。

对于不同的用户数量，每个用户的处理器成本一直保持稳定，直到达到 80 K 用户。此时，当增加最后 20 K 用户时，每个用户的成本开始增加。我们没有在达到 17 K 用户的单个 DPAR 测试中看到这种处理器成本的增长，也没有在 51 K 用户测试中看到这样的增长，本文后面的小节将描述这个测试，在这个测试中，我们运行多个有 17 K 用户的 Lotus Domino 服务器。每个用户的处理器成本的这种增长似乎与 Linux 内核本身的开销有关。

对于这个基准测试和其他测试，我们看到 VM 下第一个 guest 占用了大约 10% 的开销。此外，此后每个附加的 VM guest（不是 Lotus Domino 分区服务器）有大约 1% 到 2% 的开销。这 10% 的开销分布在 6 个 Lotus Domino 服务器实例上，这意味着对于这种配置，对于这个基准测试，虚拟环境中每个 Lotus Domino 服务器有大约 2% 的开销。但是请注意，并不是所有虚拟化技术和平台都能在单个物理足迹中取得这种级别的可伸缩性、吞吐率和低开销。因此，这些数字不能用于不同于本文的 Lotus Domino 虚拟实现。

垂直和水平可伸缩性

当将 Lotus Domino 基础设施迁移到一个虚拟环境时，应该查看一下已有的基础设施。最快、最容易的方式是将已有的 Lotus Domino 服务器转移到新的环境中。这种方法通常无法充分利用新的虚拟环境。我们执行过一个评测，以估计在两种不同的配置上运行一个给定的工作负载有何不同。为度量这种不同，我们在两种配置上运行相同的工作负载，这两种配置的惟一区别是 Lotus Domino 分区服务器的数量。

在第一个测试中，我们在 3 个 DPAR 上运行 51 K 基准测试用户，并测定每个用户的成本。然后，在相同的虚拟配置中，我们在 6 个 DPAR 上运行同样的 51 K 用户，并测定每个用户的成本。图 9 显示这两个测试的结果。

图 9. 每个用户的处理器成本比较

我们可以看到，通过将工作负载整合到更少的 Lotus Domino 分区服务器上，每个用户的处理器成本下降了 20%。在客户和 IBM 的生产环境中，当他们能够执行服务器整合时，我们也看到过服务器成本的这种下降。通过垂直伸缩 Lotus Domino 基础设施（图 1 就是一个例子），不仅可以节省用于运行环境的资源，还可以节省管理成本，因为需要管理、升级和支持的服务器更少了。

要充分利用虚拟技术的优点，关键在于物理/虚拟实现允许为环境增加资源，首先允许垂直增长，而不必水平地重新构建环境。

基准测试已成为事实！

您可能要问：“听起来不错，但是在生产中如何做这些实际工作？”IBM 已经与一个客户合作，成功地将 14 K 生产用户迁移到 2 个 Linux 内核中。VM 下的每个 Linux guest 支持大约 8 TB 的 DASD。每个内核中大约有 7 K 生产用户，每个 guest 运行多个 DPAR。除了邮件服务器外，他们在这两个 Lunch guest 中还有名称服务器和管理服务器，总共在每个 Linux guest 中占 4 个 DPAR。在 64 位 8.5 版 Lotus Domino 代码（允许更大的服务器整合）出现之前，这种配置使用 Lotus Domino 7。这个客户看到他们管理的 Lotus Domino 实例和基础设施设置得到了减少。

不仅客户正在在大型环境中实现 Linux 上的 Lotus Domino，IBM 也在这么做。IBM 正在将生产工作负载转移到 Lotus Domino on Linux for System z 上。文章 “Consolidation of Lotus Domino and Lotus Notes to Linux on System z” 对迁移期间发生的活动作了总结。这篇文章描述了将具有 35,100 个 Lotus Domino 应用程序的 103 个硬件系统迁移到 Lotus Domino on Linux for System z 上的过程。至于这项工作如何延伸到邮件环境，请参阅更多的文章。

换个角度看待虚拟化

前面提到，虚拟化的一个优点是可以动态扩展基础设施，以支持 Lotus Domino 环境。有了这个优点，再加上企业硬件可以动态更改和增长它的配置，可以让您以新的、不同的方式运行 Lotus Domino 环境。

目前，大多数使用集群的客户都采用 active/active 配置。这种配置意味着工作负载均衡地分布在集群的两端，同等地使用资源。运行 Lotus Domino 集群的另一种方式是采用 active/passive 配置，所有工作负载落在集群中积极的一端，只有用于维护同步的工作负载落在消极的一端。这种配置的主要缺点是一个服务器看上去几乎是空闲的，因为它的存在只是为了 “以防万一”。

active/active 配置的缺点是，整个工作负载被均匀地分为两半。当出现故障时，所有工作负载从一端转移到另一端。虽然一开始大多数配置的规模都经过精确的计算，但是随着时间的推移，集群的两端都在增长。难以判断集群的某一端是否还能容纳整个工作负载。您是否在峰值转换期间真正禁用了集群的一半，以验证仍然可以承受工作负载？而且，并不是所有的瓶颈都是处理器瓶颈。您是否有足够的 I/O 和网络带宽来支持峰值故障转移工作负载？如果没有在峰值负载下积极测试和验证集群，那么在真正发生故障时，故障转移的一端可能受到资源限制，响应时间较长，甚至出现故障。

在虚拟环境中，可以运行 active/passive Lotus Domino 集群，并清楚地知道它在一端上使用什么资源运行所有工作负载，因为工作负载已经在集群的一端上。在虚拟环境中，passive 端有几种选项。可以将 passive 端上的资源另外用于较低优先级的工作负载（测试、开发和其他非 Lotus Domino 工作负载），当出现故障时，这些工作负载是可以暂时牺牲的。这是一种容量随需应变的解决方案。这种解决方案使您可以事先为部分的故障转移（单个服务器故障）做准备，而剩下的容量则直到全面出现故障时才动态地开启。容量随需应变解决方案的优点是，除非真正需要用到，否则无需购买硬件。您可以选择重用资源，或者直到需要时再购买资源，但是不再需要保留备用容量 “以防万一”。

结束语

并非所有虚拟化技术都具有相同的优点或相同的成本开销。有些虚拟化技术（例如我们使用的虚拟化技术）存在已经有 40 多年了，有很多的改进和增强。从 Lotus Domino 4.5.1 起，IBM 就一直在虚拟环境中运行 Lotus Domino。IBM 已经将大多数 Lotus Domino 应用服务器整合到 VM 下的 Linux for System z 中。IBM 还宣布了将邮件服务器迁移到这个环境的计划。

在本文的基准测试使用的 System z 的虚拟化环境中，虽然每个 Lotus Domino 服务器实例的累积开销不到 2%，但这个基准测试不是典型的，不能代表大多数的虚拟化技术。理解虚拟化环境的成本对于构建成功的虚拟部署十分关键。而且，由于这些例子（基准测试和生产）中虚拟化大量 I/O 的成本较低，因此可以显著提高垂直可伸缩性和节省成本。

Lotus Domino 环境的虚拟化很大程度上有助于优化和减少总体拥有成本（TCO）。虽然转移已有的服务器已经可以节省成本，但真正节省的地方在于可以整合服务器（减少环境的复杂性），以便垂直伸缩。而且，通过为 Lotus Domino 部署优化环境和减少复杂性（减少需要管理、升级和支持的 Lotus Domino 服务器），可以大量节省治理和管理成本。最后，让基础设施适应 Lotus Domino，而不是让 Lotus Domino 适应基础设施，可以降低 TCO，并能够以更快的速度、更大的灵活性应对业务需求。