实现 DB2 在 IBM System p 上的动态分区迁移

了解 System p™ virtualization PowerVM™ 企业版的动态分区迁移特性。看看如何将动态分区迁移特性应用到 DB2® 部署中，以及它如何帮助您迁移 AIX® 和 Linux® 分区，并且将一个物理服务器中的应用程序托管到另一个兼容的物理服务器。动态分区迁移可以实现硬件维护、固件更新、系统维护，以及应用程序的动态服务器整合等工作在不停机的情况下进行。您还将了解存储网络区域（Storage Area Network，SAN）和 DB2 的设置、配置、最佳实践和性能。

简介

System p 虚拟化技术提供了一组丰富的平台部署特性。这些特性涵盖简单的资源分离（resource isolation）和各种强大的高级功能，包括服务器资源分区、自动动态资源重分配和工作负载管理。

动态分区迁移是基于 POWER6™ 处理器的系统的新特性，旨在实现兼容系统之间的逻辑分区迁移（LPAR 或分区）。动态分区迁移使用了一个简单的自动化过程，该过程从原服务器将移动 LPAR 的运行状态（属于移动 LPAR 的主内存页面）和配置信息（例如虚拟网络接口、虚拟 Small Computer System Interface (SCSI) 接口或 LPAR 配置文件）传递给目标服务器，这个过程不会中断被托管的操作系统、网络连接和应用程序。

动态分区迁移使管理员能够更好地在数据中心控制系统资源。它提高了工作负载部署和管理的灵活性。而在以前，由于维护时窗有限，应用程序可用性的要求严格，或者服务级别协议不允许应用程序停止，因此很难实现这种灵活性。

迁移过程可以在关闭状态下的分区执行，也可以在一个活动分区中执行。可以使用两种迁移类型：

静止迁移 逻辑分区被关闭并迁移到目标系统。 活动迁移 执行分区迁移时可以提供服务，而且不会中断用户活动。

在过去执行维护活动需要停机，但是现在不会中断服务。活动包括（但不限于）：

预防性硬件维护

硬件升级

需要在服务器之间重新分配分区的服务器整合

DB2 V9.5 是行业领先的信息管理平台。DB2 V9.5 的设计目标是利用 System p 虚拟化技术。一些新的特性使 DB2 非常适合虚拟化环境，例如主机动态资源感知（host dynamic-resource awareness）、配置参数在线调优和自调优内存管理（STMM）。

实现动态分区迁移的先决条件

本文要求您了解 System p 虚拟化概念、存储管理、网络管理知识，并具备基本的系统管理技能。

动态分区迁移在操作系统级别、固件级别、DB2 数据存储布局和网络接口方面有特殊的要求。在设置迁移时，无论它是活动的还是静止的，都需要提前仔细安排部署。有时候通过采取额外的步骤可以使某个分区具有迁移资格，例如使用动态逻辑分区（DLPAR）操作删除物理适配器（非虚拟适配器）。

只有满足以下需求时，分区才可以执行迁移。对逻辑分区执行迁移一般需要满足以下要求：

使用同一个硬件管理控制台（Hardware Management Console，HMC）控制的两个基于 POWER6 处理器的系统。支持一个可选的冗余 HMC 配置。

目标系统的可用内存和处理器的数量至少要和迁移分区当前使用数量相同。在使用分区配置文件启动后，DLPAR 操作可能会在运行时改变分区资源（包括内存、处理器和适配器）。因此，分区资源的当前数量可能不同于分区配置文件中指定的 “理想” 数量。

一个分区可以具有多个配置文件。在操作系统启动时，系统管理员选择用来启动分区的配置文件。通常，分区配置文件指定了操作系统启动时的资源需求，例如内存数量、处理器权限、适配器等等。分区文件还指定了最小和最大内存量，以及虚拟处理器的数量和处理器权限。

操作系统、应用程序（DB2）安装、DB2 实例数据和 DB2 表数据必须位于外部存储子系统上的 Virtual I/O 存储中。

迁移分区的所有网络和磁盘访问必须通过一个或多个 Virtual I/O Servers (VIOS) 进行虚拟化。

在进行迁移时，迁移分区不会使用其他的物理适配器，例如串口 I/O 适配器、SCSI 适配器等。如果有任何物理适配器属于进行迁移的分区，那么迁移前的验证阶段将会失败。

两个系统上的 VIOS 都必须配置一个共享的 Ethernet 适配器，通过它桥接迁移分区使用的 Ethernet 网络。

两个系统上的 VIOS 必须能够向迁移分区使用的所有存储资源提供虚拟访问。

图 1 展示了实现迁移的总体结构。每个基于 POWER6 的系统都配置了一个 VIOS 分区。迁移分区只能通过虚拟适配器访问网络和磁盘资源。目标系统上的 VIOS 被连接到同一个网络，并配置为访问迁移分区使用的相同存储。

图 1. 分区迁移基础架构

动态分区迁移配置

本节提供动态分区迁移的配置设置参考清单。一般而言，检验该清单中的条目的一个方法是导航到各自的 Property 屏幕。例如，对于 Systems 清单中的条目，导航到 System -> Property screen。对于 VIOS 分区，则导航到它的 Property 屏幕。红皮书 PowerVM Live Partition Mobility on IBM System p（参见 参考资料）详细介绍了检验和修改这些设置的方法。

系统

源服务器和目标服务器必须至少位于基于 POWER6 处理器架构的系统中。两个系统必须使用同一个 HMC 控制。动态分区迁移要求使用 HMC Version 7.3.2 或更高版本。

源系统和目标系统的内存区域大小，也称为逻辑内存块（LMB）大小，必须相同。可以在 HMC 上进行检验，方法是导航到主机系统的 Properties 屏幕的 Memory 选项卡。参见下面的 图 2。

要实现迁移，目标系统不能使用电池作为电源。

目标系统必须与主机迁移分区具有相同数量的内存和处理器（在活动分区配置文件已经指定）。

图 2. 在 HMC 上检验系统内存区域（LMB）大小

VIOS 分区

在源系统和目标系统上至少要安装一个版本为 1.5 的 VIOS 发行版或更高版本。

在源系统和目标系统 VIOS 上必须同时启用分区属性 “Mover service partition” (MSP) 。启用方法有二个：在创建 VIOS 分区配置文件时选择复选框，或在稍后导航到分区属性并选择复选框，如 图 3 所示。

对于启用了 MSP 的 VIOS，必须定义和配置一个 Virtual Asynchronous Service Interface (VASI) 设备，将它作为一个有效的 MSP 替补。

迁移分区使用的虚拟磁盘需要使用设备备份；它们不应属于 VIOS 上的任何逻辑卷组的一部分。

图 3. 启用或检查 mover service partition 的状态

迁移分区

AIX 5.3 technology level 07 或更高。

确保建立了 Resource Monitoring and Control (RMC) 连接。

需要在迁移分区中禁用冗余错误路径报告。

迁移分区不能有任何必要的虚拟串口适配器，为 HMC 预留的两个除外。

迁移分区不应属于分区工作负载组的一部分。分区工作负载组是一个逻辑分区的集合，其中的资源由一个工作负载管理应用程序统一管理。

工作负载管理应用程序可以平衡逻辑分区组内的内存和处理器资源，并且不需要 HMC 的介入。

迁移分区不能使用 Barrier Synchronization Register (BSR) 阵列。

迁移分区不能使用大内存页（16GB）。然而可以使用 64KB 和 16MB 大小的 AIX 页面。

迁移分区没有物理或专用的 I/O 适配器和设备。

迁移分区不能配置有任何逻辑主机 Ethernet 适配器（LHEA）设备。

主机 Ethernet 适配器（HEA）是物理 Ethernet 适配器，它直接集成到托管系统中的系统（GX+ 总线）中。HEA 为 Ethernet 连接提供高吞吐量、低延迟和虚拟化支持。HEA 与其他类型的物理 Ethernet 适配器具有相同的用途。例如，可以使用 HEA 建立到一个逻辑分区的控制台连接。

外部存储

迁移分区用作虚拟磁盘的存储区域网络（SAN）磁盘必须分配给源和目标虚拟 I/O 逻辑分区。

VIOS 上的共享物理卷的 reserve_policy 属性必须设置为 no_reserve。

物理卷必须具有相同的惟一标识符、物理标识符或一个 IEEE 卷属性。这可以通过 AIX lsattr 命令进行检验。

VIOS 在每次启动时必须能够准确地识别物理卷，即使这时 SAN 进行了重新配置或适配器发生改变。由于 SAN 进行了重新配置，物理卷属性可能在系统重启后会发生改变，例如名称、地址和位置。然而，VIOS 必须能够识别出这是同一个设备并更新虚拟设备映射。

要将物理卷作为虚拟设备导出，物理卷必须使用惟一标识符（UDID）、物理标识符（PVID）或 IEEE 卷属性其中之一。

迁移分区必须能够通过 VIOS 访问存储区域。

目标 VIOS 必须具有足够的空闲的虚拟槽（slot）来创建托管迁移分区所需的虚拟 SCSI 适配器。

迁移分区必须同时从源环境和目标环境访问 SAN 中相同的物理存储。

网络方面的注意事项

在源 VIOS 和目标 VIOS 上必须同时配置一个共享 Ethernet 适配器。

在迁移分区上必须配置一个虚拟 Ethernet 适配器。

实际迁移

从最终用户的角度来看，活动迁移过程只需在 HMC 图形用户界面上单击几下。而在幕后，需要做大量工作将移动 LPAR 状态和配置信息从源系统传递到目标系统（包括移动 LPAR 中配置的数千兆内存），同时保持 LPAR 的所有服务可以正常工作，并维护源系统和目标系统之间的一致性。一次活动迁移包括：

一个验证阶段，确保达到迁移标准。验证阶段实际上检验是否满足上面列出的先决条件。

在目标系统中创建新的 LPAR。

在两个 VIO 服务器上设置 MSP。

在目标 VIO 服务器上设置虚拟 SCSI 适配器。

从源系统将内存复制到目标系统。

在源系统中暂停 LPAR 并在目标系统上重新运行。

从源 VIO 服务器删除虚拟 SCSI。

通知迁移分区和 VIO 服务器迁移完成。

从源系统删除 LPAR。

测试计划

测试计划列出了测试环境和测试用例。

测试环境

下表列出了概念证明中使用的系统、存储和软件。

表 1. 环境

测试用例

测试用例的设计目的是在活动迁移中理解以下 DB2 性能特征。DB2 服务器实例在进行迁移时将继续为客户机提供服务。

在迁移各个阶段的性能影响。

观察执行活动迁移期间客户机或终端用户感受到的吞吐量。

在目标服务器上多长时间重新恢复一次原始吞吐量。

迁移阶段的负载影响。

迁移设置

图 4 展示了 DB2 使用的设置和动态分区迁移的性能特征。在整个测试过程中，围绕最佳实践进行的设置可以确保简化管理并提供高性能吞吐量。如前所述，迁移的准备过程需要谨慎的存储和网络规划。

图 4. DB2 动态分区迁移的硬件设置

硬件设置

本节介绍了要启动活动迁移所需的系统、存储和网络设置。

上面的 图 4 中的系统 #1 被作为源系统。LPAR（运行一个 DB2 服务器实例）最初在该系统中定义。系统 #2 被设置为接收一个迁移 DB2 服务器 LPAR。DB2 服务器 LPAR 没有任何属于它的物理资源（包括物理适配器或逻辑磁盘）。这是实现成功迁移的主要要求。所需的网络和存储接口分别是一个共享 Ethernet 适配器（SEA）和一个虚拟 SCSI。DB2 网络客户机通过 SEA 连接到 DB2 服务器，而 DB2 服务器数据则使用虚拟 SCSI 适配器断开 DS4500 的托管。

存储系统使用一个 SAN 交换机连接，以便连接到目标系统和源系统。配置 SAN 存储的重要一步是确保恰当地声明全球通用端口号（worldwide port numbers，WWPN），以便目标系统和源系统可以访问数据（但是，在任何时刻，只能有一个系统访问存储系统）。启用动态分区迁移配置 详细介绍了设置和配置步骤。

PowerVM 企业版是一个独立颁发许可的需要支付费用的特性，必须在两个系统上启用该特性才能实现分区迁移。AIX 操作系统的最低需求为版本 5.3 technology level 07。还需要特定的最低要求的 HMC 和固件版本。有关该环境的完整细节请参见 测试环境。

您必须将 AIX 操作系统安装到由 SAN 存储设备备份的虚拟存储上，因为这样 AIX 安装介质（具体指 rootvg）就会随迁移分区一起移动。

要减少迁移的延迟时间，建议在源系统和目标系统两端使用高速网络基础设施，例如 Gigabit 或 10 Gigabit 接口。要改善网络吞吐量，如果可以的话，使用相同的高速 Ethernet 交换机连接源系统和目标系统以及 HMC，如 图 4 所示。

DB2 设置

正如需要在 SAN 存储上安装 AIX 一样，DB2 安装位置、DB2 实例目录、DB2 编目和所有其他存储（包括 DB2 表空间容器）也必须位于 SAN 存储。DB2 数据库不能使用本地存储设备。

确保 DB2 实例没有使用任何物理网络适配器、磁盘适配器或设备。迁移不能使用属于移动 LPAR 的物理适配器。物理适配器在迁移前 可以通过 DLPAR 操作删除。如果 DB2 正在访问这类设备，那么删除操作 DLPAR 将会失败，从而造成迁移验证失败。避免这种情况的最佳方法是遵守一条规则：不要使用属于 LPAR 的物理适配器。所有适配器（网络、存储）必须是虚拟适配器。

如果 LPAR 使用大 AIX 内存页（16GB 页面大小），则不支持分区迁移。必须确保 DB2 没有使用 AIX 的大内存页配置；例如，使用 DB2 注册变量 DB2_LARGE_PAGE_MEM=DB:16GB。分区迁移支持 AIX 4KB、64KB 和 16MB 页面大小（受 DB2 支持）。

DB2 数据库管理器配置参数 INSTANCE_MEMORY 控制 DB2 实例使用的内存的数量。如果迁移的目的是为了目标系统上的 DB2 实例分配更多的内存（通过在迁移后执行 DLPAR 操作来向托管 DB2 的 LPAR 添加更多内存），在迁移后需要注意 INSTANCE_MEMORY 配置参数，以便能够在目标系统上使用更多的内存。其他 DB2 配置无需修改。

迁移分析

本节将讨论迁移性能、LPAR 暂停/恢复时间、工作负载强度影响和资源需求。

活动迁移性能配置文件

图表 1 中的阴影区域显示了移动 LPAR 何时开始迁移。源系统上的移动 LPAR 的执行最终暂停（使用绿色表示）。随后执行一个恢复操作（红色阴影区域），处于源系统中的暂停操作和目标系统上的恢复操作之间。

图表 1. DB2 活动迁移的性能配置文件

注意，内存复制超过了目标系统中移动 LPAR 的恢复执行点。当 LPAR 暂停时，最近修改的内存页没有被复制到目标系统。当程序访问仍然处于源系统上的内存页时，内存页将按照需求从源系统分页。因此，程序可以在目标系统上继续执行，而不需等待剩余的所有内存页被复制完。

图表 1 还显示出，只要移动 LPAR 重新开始执行，将继续处理数据库事务，并且将在几秒内达到完全性能。所需时间取决于工作负载。

下面的表 2 总结了活动迁移的各个阶段花费的时间。这里显示的时间只用于演示目的，不具有代表性。时间完全取决于工作负载、工作负载类型、DB2 内存消耗、存储系统等等。

表 2. DB2 动态分区迁移总结

整个迁移过程只使用了 3 分 24 秒。这个时间是 LPAR 中有关内存量的函数，以及迁移过程中内存页的更新频率。总迁移时间可以进一步划分为两个主要活动：状态传输使用了 3 分钟 15 秒，暂停/恢复持续时间大约为 9 秒。目标系统几乎立即实现了原始吞吐量（“Begin migration” 标记处或之前的吞吐量）。

如 图表 1 所示，事务吞吐量在状态传输阶段受到了影响。在 “Begin migration” 和 “Suspend on source system” 标记之间平均吞吐量下降了大约 12%。

需要重新强调一下，这里提到的所有性能分析指标和使用的时间都仅供演示使用。对于不同的环境，这些数据会产生很大的变化。

下一小节将讨论结合不同的 VIOS 配置的情况下，在移动 LPAR 中使用不同级别负载的测试结果。

加载场景

下一组测试将检验在迁移时进行 LPAR 加载的效果。根据 DB2 客户机的数量，会产生三种加载级别。产生的平均 DB2 事务吞吐量大约为 1500、1800 和 2200 事务/秒（TPS），如图表 2 所示。

图表 2. 分区加载对迁移配置文件的影响

这里没有对 LPAR、AIX 或 DB2 配置做其他修改。加载量显然会影响迁移性能指标，包括总迁移时间、状态传输时间和暂停/恢复时间。表 3 详细分析了这些指标。

表 3. 工作负载强度对动态分区迁移的影响

处理器消耗

本节将查看活动迁移操作各个阶段的处理器消耗行为。下面的图表 3 展示了与 图表 1 相同的运行场景，但是这里展示的是每个涉及到的分区的处理器利用情况。每个 VIOS（位于源系统和目标系统上）被配置为一个专用的 LPAR，使用一个处理器和 512MB 的物理内存。DB2 LPAR 被配置为使用 2 个处理器、9GB 物理内存的专用 LPAR。

图表 3. 活动迁移操作期间 VIOS 和 DB2 LPAR 的处理器利用情况

在 “Begin migration” 活动之前，DB2 LPAR 处理器利用率为 85% 左右。触发迁移后，DB2 LPAR 处理器利用率稍微增长，提高至 87% 左右，并且一直保持这个水平，直到 “End migration” 标记。DB2 分区处理器利用率有轻微的增长，是因为 DB2 分区参与到状态传输中。将其与 图表 1 比较，在相同的时间中，DB2 吞吐量开始逐渐下降，在图表中的时间标记 120 处降至最低。在 120 标记后，DB2 吞吐量保持在同一水平（与迁移前相比，下降了大约 12%）。

在迁移前，源 VIOS 服务于 DB2 磁盘和网络 I/O 请求，因此它的处理器利用率为 18% 左右。由于目标系统上没有进行其他活动，因此 VIOS 处理器利用率为 0%。在 120 标记以后，两个系统上的 VIOS 处理器利用率都大幅度增加，因为它们都执行状态传输操作。源 VIOS 除了执行状态传输操作外，仍然服务于 DB2 磁盘和网络 I/O，因此使处理器利用率猛增至 90%。

同时，目标 VIOS 处理器从 0% 增长至 60% 左右，并一直保持在该水平，直到完成状态传输操作。在执行完暂停/恢复操作后，目标系统 VIOS 处理器利用率将增至 95%，源 VIOS 表现出类似的趋势，DB2 LPAR 也是一样。

注意，在 “End migration” 事件后，VIOS 处理器利用率开始逆转。目标系统 VIOS 处理器利用率和源系统 VIOS 处理器利用率保持在同一水平，因为现在目标系统在为 DB2 客户机服务，反之亦然。

要减少总的活动迁移持续时间，必须恰当地设置 VIOS 的大小。建议您使用共享的专用容量的分区类型，或者使用一个无上限的共享式处理器 VIOS 分区。要获得初始的处理容量，将 VIOS 分区类型设置为无上限的共享式处理器 VIOS 分区。试运行一个峰值负载，执行活动迁移，并记录 VIOS 允许实现的容量使用率（例如，使用 VIOS viostat 命令）。为了防止意外，向已记录的允许实现的峰值容量添加 10% 的空闲容量。如果使用共享式专用分区，则向上取整这个值。如果将 VIOS 设置为无上限的共享式处理器分区类型，则将 VIOS 无上限容量设置为最高值，并在上面的步骤中计算允许实现的容量。

结束语

动态分区迁移使管理员能够更好地控制数据中心的资源使用情况。迁移过程可以在关闭状态下的分区执行，也可以在一个活动分区中执行。可以使用两种迁移类型。如果使用静止迁移，逻辑分区被关闭并迁移到目标系统。如果使用活动迁移，执行分区迁移时可以提供服务，而且不会中断用户活动。

在过去执行维护活动需要停机，但是现在不会中断服务。活动包括（但不限于）：预防性硬件维护、硬件升级、需要在服务器之间重新分配分区的服务器整合。

需要独立购买许可的 PowerVM 企业版来支持迁移。PowerVM 企业版包括动态分区迁移、共享专用容量、微分区、VIOS 等。

本文详细分析了在 DB2 9.5 中运行 PowerVM 企业版动态分区迁移特性。DB2 9.5 实例托管了一个 OLTP 工作负载。DB2 实例为多个客户机服务，超过 2000 事务/每秒（TPS）吞吐率被迁移到另一个系统。客户机网络连接仍然保持完整，应用程序可能会出现几秒钟的暂停。

致谢

本文的一些内容取自 Horace Tong 以前的工作，因此在这里向他表示感谢；同时感谢 Sunil Kamath 和 Peter Kokosielis 在 DB2 设置和配置方面提供的帮助；Rich Bassemir 对本文进行了审校；而 Pete Jordan 提供了实验支持以及系统和存储应用方面的管理帮助。