【IT168 服务器频道】本文主要关注在两个 JS22 Blade 之间执行 Live Partition Mobility。讨论在包含 SAP 和 Oracle 的 AIX? 真实环境中，动态转移之前、期间和之后可能遇到的情况。

　　概述

　　Live Partition Mobility 是基于 IBM? POWER6? 的 System p? 服务器的一项令人兴奋的新特性。自从 IBM 宣布此特性以来，我一直期待着在真实的场景中测试这种新技术。本文主要讨论使用 IBM JS22 Blade 服务器执行 Live Partition Mobility，描述在对 AIX 上的 SAP/Oracle 执行动态转移之前、期间和之后可能遇到的情况。还会提供一些针对转移的环境配置建议。

　　本文假设读者熟悉 AIX、逻辑分区（LPAR）和 Virtual I/O 服务器（VIOS）概念和技术，所以并不提供与 AIX 安装和 VIOS 配置相关的详细信息。

　　什么是 Live Partition Mobility 及其好处？

　　在开始之前，我们先回顾一下基本概念。Live Partition Mobility 是基于 POWER6? 的 System p? 服务器上的一个特性。它可以把一个正在运行（或停止运行）的 LPAR 从一个物理系统转移到另一个系统。Mobility 使用一个简单的过程把 LPAR 从源系统转移到目标系统，而不需要中断 LPAR 上驻留的应用程序或操作系统。这使管理员能够在不停止系统的情况下执行硬件维护，比如更换损坏的固件。在维护期间，LPAR 可以临时转移到其他物理服务器。维护完成之后，很容易把它们转移回来。工作负载可以在系统之间动态地转移，这使管理员对 System p 资源的使用情况有了更强的控制能力。

　　Live Partition Mobility 针对的目标是有计划的活动。它并不能防止系统故障，所以不能替代 IBM HACMP 高可用性集群技术等高可用性软件。

　　在我的环境中，希望能够把正在运行 SAP 和 Oracle 的 AIX LPAR 从一个 JS22 Blade 转移到另一个物理 Blade。这样就能够在 Blade 上对损坏的硬件和/或软件进行维护，而不需要停止 SAP 应用程序。例如，如果需要更新 Blade 上的一个 VIOS，就可以把工作负载转移到另一个 Blade（不需要停止 SAP），执行 VIOS 更新，重新引导 Blade，在成功完成这些活动之后把 LPAR 移回来。如果需要更新 Blade 的固件，也可以采用相同的方法。

　　JS22 Blade 环境

　　在讨论如何执行分区转移之前，先简要描述一下我的 JS22 环境和配置。在我的 IBM BladeCenter H 机架上，在插槽 13 和 14 上各有一个 JS22 Blade。每个 Blade 安装了 16GB 的内存和 4 个 4GHz 的 POWER6 处理器，启用了 'PowerVM Enterprise Edition'（转移分区要求启用此特性）。每个 Blade 安装一个 Virtual I/O 服务器（VIOS 1.5）和 Integrated Virtualization Manager（IVM）。这些系统使用的 SAN 磁盘存储是 IBM DS8100。

　　每个 VIOS 有一个主机名：bvio82（插槽 13）和 bvio83（插槽 14）。在插槽 13 中的 Blade 上配置了一个 AIX LPAR（bxaix85）而且正在运行。它运行 AIX V5.3 TL7 SP3。此系统上驻留的应用程序是一个 SAP R3 v4.7 实例和 Oracle 10G。SAP 是由我们的 SAP Basis 小组安装和配置的。一定要注意，不需要为了支持分区转移特性对 SAP（或 Oracle）安装做任何特殊处理。

　　执行分区转移需要满足几个前提条件。最重要的条件之一是，来自此 LPAR 的所有网络连接必须是虚拟化的，这意味着它必须使用 VIOS 进行通信。这意味着 VIOS 必须配置和运行一个 Shared Ethernet Adapter（SEA）。我的两个 VIOS 都配置了 SEA，它们在同一个物理 VLAN 上。我使用 Logical Host Ethernet（LHE）端口之一配置 SEA。使用 IVM 执行所有 SEA 配置，这非常简单（稍后就会看到）。Virtual I/O 客户机（VIOC）bxaix85 配置了一个具有适当 VLAN ID 的虚拟以太网接口，从而通过 VIOS 中的 SEA 与外界通信。

　　执行分区转移的另一个重要前提条件是，连接到可转移 LPAR 的所有存储必须在 SAN 上，甚至包括操作系统（对于 AIX，操作系统在根卷组 rootvg 中）。这个 SAN 磁盘存储必须分配给两个 Blade，两个 VIOS 必须能够探测到它。这使目标 VIOS 能够在转移期间 "接管" 存储。我给两个 VIOS 分配两个 SAN（DS8100）磁盘。一个磁盘用于操作系统（AIX rootvg），另一个用于 SAP/Oracle 软件和数据库（sapvg）。

　　图 1 显示 JS22 环境和高层配置。

　　图 1. JS22 环境

　　为分区转移配置 JS22 环境

　　配置环境的第一步是在每个 JS22 上安装 Virtual I/O Server（VIOS）。安装方法是使用 NIM 安装 VIOS mksysb 镜像。可以使用 Blade 中的内部磁盘驻留 VIO 服务器，也可以选择用 SAN 引导 Blade，因为也支持这种方式。我选用 Blade 的内部磁盘。

　　在每个 Blade 上安装 VIOS 之后，就可以连接基于 Web 的 IVM。这个工具提供一个 "与 HMC 相似的"图形操作界面，管理员可以通过它在 Blade 和 VIOS 上配置 LPAR、虚拟网络和虚拟存储。因为这是一个基于 Web 的工具，所以只需在 Web 浏览器中访问 VIOS 主机名（例如，http://bvio82），就会显示 IVM 登录页面。使用 VIOS padmin 用户 ID 和密码登录。

　　在用 JS22 测试分区转移之前，首先应该确定环境已经配置好了，能够支持此特性。第一步是更新 JS22 的固件层和相关的组件，比如 Fibre Channel（FC）适配器。从 JS22 支持网站（网站链接参见 参考资料）下载最新的 JS22 固件镜像和 FC 适配器，并在每个 Blade 上应用它们。还应该安装最新的 VIOS 补丁包。在构建我的 VIOS 时，最新的补丁包是 1.5.1.1-FP-10.1。

　　要安装（和更新）的最后一个组件是多路径 I/O（MPIO）设备驱动程序。在连接 IBM DS8100 存储设备时，支持的 MPIO 软件是 SDDPCM v2.2.0。

　　安装了正确的软件和固件之后，现在应该为执行分区转移准备 Blade、VIOS 和 LPAR。需要通过 IVM 执行以下步骤：

　　1. 在两个 Blade 上输入 PowerVM Enterprise Edition APV 密钥。在 JS22 Blade 上启用分区转移特性需要这个密钥。

　　2. 确认两个 Blade 上的内存区域大小是相同的。此信息可以在 "View/Modify System Properties" 下面的 "Memory" 选项卡中找到。

　　3. 在两个 Blade 上配置 SEA。为以太网 "桥接" 启用 Host Ethernet Adapter。这是为了让虚拟以太网设备能够访问物理以太网适配器和外部网络。这在 "View/Modify Host Ethernet Adapter" 下面的 "Properties" 选项卡中配置。选择 Allow virtual Ethernet bridging。在 "View/Modify Virtual Ethernet" 下面的 "Virtual Ethernet Bridge" 选项卡中，选择作为 SEA 使用的物理适配器。这时会显示一条消息，指出配置操作已经成功完成。SEA 现在配置好了。

　　4. 在源 Blade 上创建一个 LPAR（在我的环境中，这是 bxaix85）。选择 View/Modify Partition, Create Partition。输入 LPAR 名称、内存和处理器需求。确认没有选择任何物理 HEA 端口。在 "Virtual Ethernet" 下面，选择要使用的 SEA（例如，ent0）。在 "Storage Type" 下面，选择 Assign existing virtual disks and physical volumes。选择分配给 VIOS 的 SAN 磁盘（在我的环境中是 DS8100 磁盘）。

　　5. 单击 Finish 创建 LPAR。下一步是安装 AIX。这可以使用 NIM mksysb（即 rte）安装来实现。

　　6. 完成 AIX 的安装和配置之后，现在可以配置 SAP 和 Oracle。

　　现在，可以执行动态分区转移了。最后做一次检查。在每个 VIOS 上，通过查看设备配置，确认已经配置了 SEA。

　　图 2. VIOS 上的 SEA 配置

　　通过以上输出，可以确认在两个 VIOS 上已经配置了 SEA（ent6），使用第一个 LHE 端口 ent0。

　　确认两个 VIOS 都可以看到同一个 SAN 磁盘。使用 lspv 命令检查两个 VIOS 中与 SAN 存储相关联的 PVID 是否相同（hdisk1、2 和 3），见图 3。

　　图 3. 两个 VIOS 的 lspv 输出

　　确认已经适当地配置了磁盘的 MPIO。在两个 VIOS 上，运行 pcmpath 命令（从 oem_setup_env），确认所有路径都能够正常工作。

　　最后，确认 AIX LPAR（bxaix85）只配置了虚拟设备（即没有配置物理适配器，这是分区转移的另一个前提条件）。图 4 显示这个 LPAR 配置了虚拟以太网和虚拟 SCSI 适配器。

　　图 4. 配置的虚拟以太网和虚拟 SCSI 适配器

　　执行动态分区转移

　　现在，Blade 上的两个 VIOS（bvio82 和 bvio83）已经配置好了，在第一个 Blade 上有一个正在运行的 AIX LPAR（bxaix85），它作为 VIO 客户机（VIOC）。现在可以执行动态分区转移了。在转移期间，第一个 Blade（插槽 13 中的 bvio82）作为源 系统（见图 5），第二个 Blade（插槽 14 中的 bvio83）作为目标 系统（见图 6）。

　　图 5. IVM Web 界面显示的源 Blade 视图

　　图 6. IVM Web 界面显示的目标 Blade 视图

　　此示例的目的是把 LPAR bxaix85 从插槽 13 中的 Blade 转移到插槽 14 中的 Blade。转移结束之后，bxaix85 将作为另一个物理 Blade 服务器上的 bvio83 的 VIOC 运行。在整个转移过程中，AIX、SAP 和 Oracle 一直持续运行。

　　在转移之前，从 AIX 运行 lsconf 命令并记住系统序列号：

　　图 7. 转移前的 lsconf 输出

　　在转移期间，在 LPAR 上有正在运行的 SAP 作业，见图 8。使用 topas 命令监视系统，可以看到在转移期间 SAP（disp+work）和 Oracle 进程一直在使用处理器。

　　图 8. topas 会话显示 bxaix85 上的 SAP 工作负载

　　执行分区转移所需的所有任务都是在源 Blade 上通过 IVM 执行的。为了开始转移，要选中 LPAR（bxaix85）旁边的框并从 "More Tasks" 下拉菜单中选择 Migrate，见图 9。

　　图 9. 启动 bxaix85 的转移过程

　　在显示的屏幕上，输入目标系统的详细信息。然后，单击 Validate，见图 10。

　　图 10. 检验转移

　　在检验阶段，会执行几项配置检查。包括：

　　" 确认目标系统有足够的内存和处理器资源，可以满足 LPAR 当前的需求。

　　" 确认没有给这个 LPAR 分配专用的物理适配器。

　　" 确认 LPAR 没有任何虚拟 SCSI 磁盘被定义为任何 VIOS 上的逻辑卷。所有虚拟 SCSI 磁盘都必须映射到 SAN 上的整个 LUN。

　　" 在 LPAR 与源和目标 VIOS 之间建立 RMC 连接。

　　" 分区的状态是活跃的，也就是 Running。

　　" 在目标系统上没有使用这个 LPAR 的名称。

　　" 生成把源虚拟适配器/设备映射到目标 VIOS 的虚拟适配器映射。在实际转移期间将使用这个映射。

　　成功地完成检验之后，会出现一条消息，指出可以转移 LPAR 了（图 11）。单击 Migrate，开始向另一个 Blade 转移。通过经常单击 Refresh 图标监视转移的状态（图 12）。

　　图 11. 转移 LPAR

　　图 12. 监视转移的状态

　　在目标 Blade 上，可以看到已经创建了一个新的 LPAR，其名称与源 Blade 上的 LPAR 相同。它的状态是 Migrating - Running，见图 13。

　　图 13. 目标系统上正在转移的 shell LPAR

　　在分区转移阶段会发生什么？

　　在动态转移 LPAR 期间，状态信息会从源系统传输到目标系统。这些 "状态信息" 包括分区内存、处理器状态、虚拟适配器状态、NVRAM 和 LPAR 配置等。下面是在转移期间发生的一部分 事件和活动：

　　" 在目标系统上创建一个分区 shell。这个分区 shell 用来保留创建 LPAR 所需的资源（即处理器权利）、内存配置和虚拟适配器配置。

　　" 通过 VIOS 上的 Virtual Asynchronous Service Interface（VASI）设备在源和目标系统与它们的 POWER Hypervisor 之间建立连接。源和目标 VIOS 使用这个新的虚拟设备与 POWER Hypervisor 通信，从而访问 LPAR 的状态并协调转移过程。可以在 VIOS 上使用 lsdev 命令检查是否存在此设备。

　　图 14. VIOS 上的 VASI 设备

　　vasistat 命令显示 VASI 设备的统计数据。在转移期间，在源 VIOS 上运行此命令。在输出中，"Total Bytes to Transfer" 表示内存复制量，"Bytes Left to Transfer" 表示传输的进度，见图 15。

　　图 15. vasistat 命令

　　" 在目标系统上创建虚拟目标设备和虚拟 SCSI 适配器。在转移之前，在目标 VIOS 上使用 lsmap 命令，会看到没有虚拟 SCSI 适配器或虚拟目标设备映射，见下图。

　　图 16. 转移之前目标 VIOS 上的 lsmap

　　在转移之后运行相同的命令，可以看到在转移过程中已经自动创建了虚拟磁盘映射。

　　图 17. 转移之后目标 VIOS 上的 lsmap

　　" LPAR 的物理内存页面被复制到目标系统上的 shell LPAR。在源 VIOS 上使用 topas 命令，可以看到 SEA（ent6）上有一些网络通信流，这是内存复制产生的通信流。

　　图 18. 源 VIOS 上的 topas 显示 SEA 通信流

　　" 因为 LPAR 仍然在运行，SAP 也正在运行，所以在复制内存时它的状态会继续改变。在传输期间修改的内存页面被标为 dirty。内存复制过程会重复进行，直到标为 dirty 的页面数量不再减少为止。这时，目标 系统就通知源 系统上的 Hypervisor 暂停 LPAR。

　　" LPAR 通过停止所有正在运行的线程暂停运行。LPAR 现在处于 suspended 状态。

　　" 在 LPAR 暂停期间，源 LPAR 继续把分区状态信息发送给目标 服务器。然后，LPAR 处于 resumed 状态。

　　" LPAR 在目标 系统上恢复执行。如果 LPAR 需要还没有转移的页面，那么它会根据需要从源 系统获取页面。

　　" LPAR 恢复它的 I/O 操作。一个 ARP 请求被发送到所有虚拟以太网，从而更新网络上所有外部交换机和系统上的 ARP 缓存。LPAR 现在重新活跃。

　　" 当目标系统从源系统接收到最新的脏页面时，转移过程结束。LPAR 暂停和恢复之间的时间只持续几秒。在我们的测试中，我们没有注意到这个操作使 LPAR 产生任何 中断。

　　完成内存复制之后，源系统上的 Virtual I/O Server 删除与 LPAR 相关联的虚拟 SCSI 服务器适配器，删除现有的设备到 LUN 映射。

　　然后，从源 Blade 中自动删除 LPAR（见图 19）。

　　图 19. 转移之后 IVM 显示的源 Blade 视图，LPAR 已经被删除

　　这个 LPAR 现在转移到了目标 Blade 上并处于 Running 状态，见图 20。

　　图 20. 转移之后 IVM 显示的目标 Blade 视图，LPAR 处于 Running 状态

　　转移过程已经完全完成了，见图 21。

　　图 21. 转移过程完全完成

　　既然 LPAR 已经在另一个 Blade 上运行了，现在再次运行 lsconf 命令，确认物理硬件的序列号已经改变了：

　　图 22. 转移之后的 lsconf

　　为了确认 SAP 和 Oracle 没有受到转移的影响，检查 Oracle 警告日志中是否有任何错误。没有发现任何错误，见图 23。

　　图 23. Oracle 警告日志表明在转移期间没有发生错误

　　在 SAP 中，在转移之前和之后运行 lsconf 命令，从而确认物理服务器已经改变了：

　　图 24. 在转移之前和之后在 SAP 中执行 lsconf

　　我在 bxaix85 上的 ssh 登录会话仍然是有效的，这意味着动态转移没有造成任何连接问题。SAP 用户不会注意到在 LPAR 上运行的 SAP GUI 客户机会话或作业出现任何中断。

　　转移活动被记录在 LPAR 以及源和目标 VIOS 上的日志中。用 errpt（AIX）和 errlog（VIOS）命令检查日志。在 AIX 上，会看到与 CLIENT_PMIG_STARTED 和 CLIENT_PMIG_DONE 相似的消息。在 AIX 上，来自 DRMGR 的相关信息还被记录在系统日志中，例如 Starting CHECK phase for partition migration。在 VIOS 上，会找到与 VIOS 的暂停和转移状态相关的消息（Client partition suspend issued 和 Migration completed successfully）。

　　结束语

　　最终目标已经实现了。LPAR 现在在另一个物理服务器上运行（图 25）。现在能够在 Blade 上按计划执行维护活动，而不需要停止 SAP。