从 POWER5 升级到 POWER6

分享我从 POWER5® 595 升级到新的 POWER6® 595 的经历。

本文介绍我从 POWER5 595 升级到新的 POWER6 595 时的经历。本文不是官方指南，而是介绍我执行升级的过程，以及我在计划和执行阶段做出的决定和考虑的因素。我希望这些信息有助于别人为自己的组织或客户执行相似的任务。

我首先要指出，每个环境各不相同。大多数站点根据自己的需求定制 AIX® 操作系统和 POWER® 硬件配置，所以我在这里介绍的内容可能不适合您的环境。因此，请根据自己的判断应用本文中适合您站点的信息。只有您能够做这样的判断，因为您比任何人都更了解自己的 AIX 和 POWER 基础结构的配置方式！

关于我的 AIX 环境有一个要点：我的所有 LPAR 都是虚拟化的；也就是说，它们都是微分区的，它们对于所有磁盘和网络设备都使用 Virtual I/O (VIO)。我的 AIX LPAR 都没有任何专用的物理硬件。所有物理设备都属于 Virtual I/O 服务器 (VIOS)。

我将介绍在 POWER6 升级之前和之后执行的步骤。重点在于在硬件物理升级到 POWER6 之后执行的 VIOS、AIX 和 HACMP 任务。

回页首

我需要把现有的 System p® 595 (9119-595) 系统升级到新的 POWER6 595 (9119-FHA)。请参见图 1。我说的升级是指 MES 升级。MES 代表 Miscellaneous Equipment Specification。MES 升级包括所有服务器硬件更改，这可以是硬件的添加、改进、移除或这些操作的组合。MES 升级的一个重要特性是不改变系统序列号。

从 POWER5 升级到 POWER6 需要把现有的 I/O 设备（包括内部磁盘、FC 和以太网适配器）从 POWER5 升级到 POWER6。完成之后，启动 POWER6，然后 IBM® CE (Customer Engineer) 把系统交还给我。然后，我尝试在新的 POWER6 服务器上建立 LPAR。

这是我第一次使用 MES 升级方法迁移到新的 POWER 平台，所以有点担心。

在过去，我采用新老系统并置的方法把 AIX 系统迁移到新平台。例如，几年前，在 时，我们购买了新的 9119-595，让它与老的 p4 p690 同时运行。我们把新的 595 连接到 SAN 和网络，然后使用 Network Installation Manager (NIM) 恢复 mksysb，从而把 LPAR 从 p690 转移到新系统（每次一个）。这种方法的优点是，如果在新的 595 上出现了问题，可以很轻松地返回到 p690，因为原来的 LPAR 仍然可用。这还让我们在把工作负载转移到新系统之前有时间测试 595。这样就能够确认所有组件（比如硬件和固件）都是兼容的而且工作正常。这让我们有时间解决新硬件的所有 bug 或问题。

当时，我认为这是迁移到 POWER6 的最佳方法。

在采用 MES 升级方法时，关闭并移开老的 p5，把新的 p6 安装就位。然后，IBM CE 安装 I/O 设备，配置系统，确认其状态正常，把系统交给我，然后就走了。按照这种 “大爆炸式” 的升级方法，我无法预演或测试升级过程，有可能遇到未知的问题。

我主要担心的是，如果 9119-FHA 出现问题，我们无法方便地返回到老系统。我们无法简单地启动老的 p5 并启动 LPAR。我们也无法在启用 LPAR 并运行生产工作负载之前测试新硬件是否正常。

由于这是 MES 升级，所以我要制订升级计划。

回页首

必须做出的最重要的决定是，对 AIX LPAR 使用什么迁移方法。这里有两个选择；可以通过 mksysb 恢复重新构建 VIOS 和 LPAR，也可以从磁盘引导它们。

我发现，文档中正式记载的把 LPAR 迁移到不同硬件的惟一方法是使用 “mksysb clone” 操作，也就是在新的 p6 系统上恢复 LPAR 的 mksysb。但是，我对在新的 p6 595 上直接引导 LPAR 更感兴趣。

这种方法不一定可行，我也知道其原因。要想在新系统上引导，需要支持新平台的适当的设备驱动程序文件集。这意味着需要确保在安装所有系统时 Enable System Backups to install any system 被设置为 Yes。这样就可以在其他任何系统上安装所有设备和内核（使用克隆），从而安装系统。不能够保证系统采用这个设置。但是，当我考虑动态分区可移动性的工作方式，并注意到可以把 Virtual I/O 客户机 (VIOC) LPAR 从一个物理系统转移到另一个系统（不使用 mksysb 恢复）时，我想知道这种情况以后是否会改变？这是安装 AIX 时的默认设置，我在装载操作系统时总是确保采用这个设置。更多信息可以参见 /usr/lpp/bosinst/bosinst.template.README 文件。

AIX 论坛上的一些帖子说明这种方法可能有效。一位客户报告他在从 p5 570 升级到 p6 570 时使用了这种方法。

在选择迁移方法时要考虑的其他因素包括 I/O 总线编号和 LPAR 配置文件。根据 9119-595 到 9119-FHA MES 升级说明，I/O 总线编号在升级之后不改变。应该在 p6 上按原样恢复 LPAR 配置文件，还是需要重新构建？MES 升级说明指出，在升级之后 IBM CE 应该使用 HMC 执行 Recover Partition Data 操作。这意味着我不需要从头重新创建所有 LPAR 配置文件（使用 System Planning tool (SPT) 或脚本方法）。我也知道系统序列号肯定不会变，所以不会出现由于系统 ID 变化导致的应用程序许可证问题。

我最终决定了升级方法。我要引导 LPAR（包括 VIOS），只在建立系统（处于干净的状态）时遇到严重问题的情况下使用 mksysb 恢复。我采用的过程如下：

• 记录每个 VIOS 上当前的虚拟设备映射。我使用 lsmap –all 和 lsmap –all –net 完成这个任务。
• 收集物理磁盘支持的所有虚拟目标设备的 PVID 和 LUNID 信息。
• 确认所有 Virtual Slot ID 都大于 10。从 HMC v7 开始，HMC 保留每个 VIOS 上的前 10 个虚拟适配器槽，供 HMC 内部使用。
• 获取所有 LPAR 和 VIOS 的 mksysb。如果需要的话，使用这些 mksysb 映像进行恢复。
• 备份管理的系统分区配置文件数据。
• IBM CE 把硬件升级到 POWER6。
• IBM CE 从以前的备份恢复管理的系统配置文件数据。
• 在 HMC 上确认每个 AIX LPAR 和 VIOS 的分区配置文件数据是正确的。
• 成功地检验 LPAR 和 VIOS 的配置文件之后，引导每个 VIOS。进入 SMS 菜单，检查引导列表，引导 VIOS。
• 检验每个 VIOS 上的虚拟设备配置和状态。对每个 VIOS 执行健康状态检查。如果健康状态检查不成功，那么使用 NIM 从 mksysb 恢复 VIOS。
• 成功地检验每个 VIOS 之后，引导每个 LPAR。进入 SMS 菜单，检查引导列表，引导 LPAR。
• 如果引导 LPAR 失败，那么从 mksysb 映像恢复 VIOS。
• 纠正每个 LPAR 上的引导列表。开始对环境进行功能性检验，比如 VIOS 故障转移以及应用程序启动和测试。

我必须确保非常谨慎小心地执行这个过程。如果遇到任何出乎意料的问题，无法及时解决，就马上改用 mksysb 恢复。

另一个考虑因素是支持新平台所需的软件和硬件级别。在 p6 升级之前，需要确保安装了正确的级别。我使用 IBM Fix Level Recommendation Tool (FLRT) 判断哪些软件和固件级别与 9119-FHA 兼容。FLRT 提供 IBM Power Systems 的关键组件的最低推荐补丁级别。在计划任何 AIX 或 POWER 升级活动时，强烈建议使用这个工具。可以在计划升级时使用这个工具生成的报告。参见图 2。

（单击放大）

在升级之前的几个月里，我们按以下次序把以下组件升级到以下级别：

1. HMC V7R3.4.0 + MH01152
2. 固件更新的各种 H/W（例如，FC、SCSI 和以太网适配器）
3. VIOS 1.5.2.1-FP-11.1 + SDDPCM 2.2.0.4
4. AIX 5300-07-05-0831
5. HACMP 5.4.1.3 + RSCT 补丁

在升级之前，我收集了关于环境中 595、AIX、VIOS、HACMP 和 HMC 的大量配置信息。由于可能需要从头恢复任何或所有系统，我希望手头准备好可能需要的各种信息。下面是我使用脚本和其他方法收集的一部分信息：

• 运行我的 AIXinfo 脚本收集每个 LPAR 的 AIX 配置信息。这个脚本运行 oslevel、lppchk、instfix、lsconf、lscfg、lsdev、lsattr 等系统命令。信息存储在另一个系统上的文本文件中。
• 为包含 FC 适配器或 SCSI 磁盘等物理硬件的每个 VIOS 和 LPAR 创建 Microcode Discovery Service (MDS) 报告。这需要从 IBM 支持网站下载最新的微代码目录文件，在每个 VIOS/LPAR 上运行 invscout 命令，然后把生成的 MUP 文件上传给在线 MDS 报告工具，见图 3。MDS 工具判断系统上安装的微代码是否是最新级别的。
  
  
  
  
  

  （单击放大）

• 从 HMC 收集信息，比如 LPAR 配置文件信息（CPU/内存分配）、管理的系统属性、物理 I/O 适配器分配、虚拟适配器定义。可以使用 SPT 或 HMC 的屏幕图捕捉这些信息。
• 虚拟 I/O 映射和配置（lsmap –all 和 lsmap –all –net）输出。我编写了一个脚本，它可以捕捉关于 VIOS 配置和设备的所有数据，比如 Shared Ethernet Adapter (SEA) 设置、VTD 映射、pcmpath 输出、vhost 槽编号等等。我还捕捉了 VIOS rootvg 磁盘的位置码，这是一个重要的步骤。
• 线缆位置和标签。为了把 I/O 设备转移到新的机架上，IBM CE 要断开所有适配器上的所有 SAN 和网络连接。我记录了每条线缆和它原来插入的适配器的对应关系。我还确保每条线缆都加上了标签，这样便于确保把线缆插回正确的适配器。
• 构建文档。我把原来的系统构建文档放在手边，以便随时参考。这个文档记录系统原来是如何构建和配置的。
• HACMP 信息。我有几个 HACMP 节点，所以需要使用 clstat、cltopinfo、clsnapshot、cldump、clRGinfo 和 cldisp 捕捉集群信息。我还使用 HACMP Online Planning Worksheets 导出了集群配置，比如 # smit cl_export_def_olpw.dialog。还在升级之前检查和同步了每个集群的 HACMP 配置。
• 对于任何严重的错误，使用 errpt 和 errlog 命令查看 AIX 和 VIOS 错误报告。在升级之前捕捉（并解决）这些问题可以避免以后的麻烦。
• 对任何 ‘open’ 硬件事件，检查 HMC，比如 $ lssvcevents –t hardware。
• 我运行 HMC readiness checker 识别可能影响升级的 595 硬件问题。可以在 HMC 中 “Updates” 下面找到这个任务。选择一个管理的系统之后，可以单击 Check system readiness。

当然，我还确认了升级所涉及的所有组件都有良好的备份，比如所有 AIX LPAR 的 mksysb、所有卷组结构的 savevg、所有应用程序和数据库的数据备份、每个 VIOS 的备份、DVD-RAM 上的 HMC 备份等等。最重要的是，我使用 HMC 对管理的系统分区配置文件数据执行了备份。备份的分区数据见图 4。这是一个重要的步骤，因为 IBM CE 在升级之后要使用这个备份恢复分区数据。如果没有这个备份，我就必须重新构建所有 LPAR 配置文件。

回页首

在升级那一天，我关闭所有 LPAR，把系统交给 IBM CE。他花了 6 小时执行硬件升级。我们有 HACMP 集群系统，所以在一个系统进行停机升级时在另一个 595 上处理生产工作负载。

当 CE 把系统交还给我时，我首先检查是否正确地插入了所有线缆。没问题。接下来，检查是否在新系统上成功地恢复了所有 LPAR 配置文件。也没问题，见 图 5。我仔细检查了每个配置文件，发现分区 id 和总线号都没有变，见 图 6。另外，所有适配器的位置码（例如 TY-P1-C02）也没有变。序列号没有变。这些都是好消息！

（单击放大）

595 的属性表明 “Type/Model” 已经从 9119-595 变成了 9119-FHA，见图 7 和图 8。

回页首

下一步是引导 VIOS。我启动一个 VIOS，等待它开始引导。这花费了很长时间，因为我给这个 VIOS 分配了许多磁盘（超过 100 个），而且有四条到 SAN 的路径，这些都必须扫描。几分钟之后，我进入了 SMS 菜单，确认了引导列表包含这个 VIOS 的 rootvg 磁盘（把我的文档放在手边，可以非常方便地检查）。这里需要非常小心。

我注意到，识别出了几个安装了 AIX 的磁盘，但是它们不属于我的 VIOS rootvg！这些是属于客户机 LPAR 的 rootvg 磁盘。如果我选择了错误的磁盘，就会引导了错误的系统。因此，在升级之前收集 VIOS rootvg 磁盘的位置码是很重要的。

我退出 SMS 菜单，让 VIOS 以正常方式引导。系统正常启动，没有遇到错误。我使用控制台作为 padmin 登录，运行 lsmap –alcl 和 lsmap –all –net。所有虚拟适配器映射和 SEA 都是可用的。我发现的惟一变化是，vhost 的位置码有变化，其中的 595 变成了 FHA（如下所示）；但是，槽号和序列号是相同的。

< vhost0          U9119.595.8369B40-V2-C20                     0x00000000
---
> vhost0          U9119.FHA.8369B40-V2-C20                     0x00000000

我注意到，每个 VIOS 上的引导列表改变了。列表中只有 hdisk0 和第一个网络适配器 (ent0)。VIOS 上的 root 卷组是镜像的，所以需要修改引导列表，包含 rootvg 中的可引导磁盘：# bootlist –m normal hdisk0 hdisk8。这是正常的，因为 NVRAM（其中包含引导列表）没有从老的 p5 转移到新的 p6。

回页首

在启动 LPAR 之前，先在每个 VIOS 上执行几个健康状态检查。健康状态检查见表 1。这些步骤检查 VIOS 的健康状态。我寻找任何异常情况，比如处于 Defined 状态的设备或错误日志中持久的硬件错误。

VIOS 检查	描述
lsconf	确认处理器显示 POWER6
ioslevel	检查 VIOS 级别
cfgdev	检查任何缺失的设备文件集
lsmap –all	检查 VTD 映射
lsmap –all -net	检查 SEA 配置
lsdev -virtual	检查虚拟设备是 Available
lsdev –type disk	检查磁盘设备是 Available
lsdev –type adapter	检查适配器是 Available
entstat -all	检查 SEA 状态和优先级
errlog	检查错误日志中的严重错误
lsdev –dev fscsiX –attr	检查设备属性
lsdev –dev hdiskX -attr	检查磁盘设备属性
lspv	检查磁盘 pvid
pcmpath query adapter	检查 SDDPCM 适配器状态
pcmpath query device	检查 SDDPCM 磁盘设备状态和 LUNID
pcmpath query wwpn	检查 SDDPCM 已知的 FC 适配器 WWPN
pcmpath query version	检查 SDDPCM 级别
lspath	检查是否启用了所有磁盘路径
netstat -nr	检查默认网关

回页首

在启动 VIOS 并检查虚拟适配器映射和健康状态之后，我启动一个 AIX LPAR。我引导这个 LPAR，进入 SMS，查看引导列表，检查列表中是否包含正确的 rootvg 磁盘。没问题。以正常方式引导 LPAR。

回页首

我在每个 AIX LPAR 上执行几个健康状态检查。同样，我检查操作系统是否运行正常。健康状态检查见表 2。升级之后需要做的惟一修改是，用镜像的 rootvg 重新设置 LPAR 的引导列表（就像在 VIOS 上所做的）：# bootlist -m normal hdisk0 blv=bos_hd5 hdisk1 blv=bos_hd5。如果在 AIX 系统上使用 multibos，执行这个操作时就要特别小心，因为可能有两个引导逻辑卷 (BLV)。必须选择正确的磁盘分区（例如下面所示的 part=2 或 part=4）；否则，就会引导 AIX 系统的老映像。

PowerPC Firmware
 Version EH340_039
 SMS 1.7 (c) Copyright IBM Corp. 2000,2008 All rights reserved.
------------------------------------------------------------------------
 Select Device
 Device  Current  Device
 Number  Position  Name
 1.        -      SCSI 136 GB Harddisk, part=2 (AIX 5.3.0)
        ( loc=U9119.FHA.8369B40-V22-C46-T1-L8100000000000000 )
 2.        -      SCSI 136 GB Harddisk, part=4 (AIX 5.3.0)
        ( loc=U9119.FHA.8369B40-V22-C46-T1-L8100000000000000 )

我建议在升级之前删除 multibos 实例 (multibos –R)，以避免混淆。

AIX 检查	描述
lsconf	确认处理器显示 POWER6
cfgmgr	检查任何缺失的设备文件集
lsdev –C | grep Defined lsdev –Cc adapter lsdev –Cc disk	检查设备是否处于正确的状态
lparstat –i	检查 LPAR 配置
oslevel –s	检查 AIX SP 级别
oslevel –r	检查 AIX TL
bootlist –m normal -o	检查引导列表设置 预期的输出如下： - 对于镜像的 rootvg（包括 VIOS）： # bootlist -m normal -o hdisk0 blv=bos_hd5 hdisk4 blv=bos_hd5 - 对于 SAN 引导 rootvg： # bootlist -m normal -o hdisk0 blv=bos_hd5 hdisk0 blv=bos_hd5
instfix –i |grep AIX instfix –i |grep SP instfix –icqk 53-07-050831_SP | grep “:-:” instfix –icqk 5300-07_AIX_ML |grep “:-:”	检查任何缺失的 AIX TL 或 SP 文件集
lsvg –l rootvg |grep stale	检查 rootvg 中的 ‘stale’ 分区
df mount lsvg | lsvg –il | grep close	检查是否挂载了所有必需的文件系统
df /var	检查 /var 是否满了
df /tmp	检查 /tmp 是否满了
sysdumpdev –l	检查系统转储配置是否正确
lsattr –El mem0	检查内存配置是否正确
emgr –l	检查 ‘efix’ 清单（如果有的话）
lppchk –v –m3	检查安装的文件集
lppchk –c –m3	对安装的文件集进行校验和检查
lsps –a	检查分页空间
smtctl	检查 smt 是否可以打开/关闭所有节点
lssrc –ls xntpd | grep “Reference Id”	检查节点上的 ntp
vmo –a	检查所有 vmo 设置
no –a	检查所有网络选项设置
netstat –nr	检查路由表
lspath	检查是否启用了所有路径
errpt	检查任何持久的硬件错误或其他严重错误
tail -100 /var/log/syslog	检查任何严重的错误
alog –of /var/adm/ras/conslog	检查控制台日志中的错误
cat /etc/qconfig lpstat	检查是否定义并启用了打印队列
lssrc –a	检查 active 和 inoperative 文件系统
pstat –a | grep aio lsattr –El aio0	检查是否配置了 AIO
lsattr -El sys0 -a minpout -a maxpout	检查 I/O pacing 设置
date	检查日期和时间是否正确
echo $TZ grep TZ /etc/environment	检查 TZ 变量的设置是否合适
lsattr –El hdiskX –a queue_depth	检查所有 hdisk 上的队列深度
topas –C	从一个 VIOS 运行 ‘topas –C’。检查所有 LPAR 是否能够报告性能数据

通过使用 lsconf 命令，可以快速地确认 LPAR 现在已经在新的 POWER6 平台上运行了。下面是升级之前和之后一个 LPAR 的输出。“System Model” 已经由 9119-595 变成了 9119-FHA，处理器类型和速度也改变了。

p6 升级之前：

	System Model: IBM,9119-595
	Machine Serial Number: XXXXXXX
	Processor Type: PowerPC_POWER5
	Number Of Processors: 4
	Processor Clock Speed: 2302 MHz
	CPU Type: 64-bit
	Kernel Type: 64-bit
	LPAR Info: 6 bxaix03
	Memory Size: 2048 MB
	Good Memory Size: 2048 MB
	Platform Firmware level: SF240_338
	Firmware Version: IBM,SF240_338

p6 升级之后：

	System Model: IBM,9119-FHA
	Machine Serial Number: XXXXXXX
	Processor Type: PowerPC_POWER6
	Number Of Processors: 4
	Processor Clock Speed: 5000 MHz
	CPU Type: 64-bit
	Kernel Type: 64-bit
	LPAR Info: 6 bxaix03
	Memory Size: 2048 MB
	Good Memory Size: 2048 MB
	Platform Firmware level: EH340_039
	Firmware Version: IBM,EH340_039

回页首

确认每个 VIOS 状态正常而且 VIO 客户机 (VIOC) LPAR 运行正常之后，我执行了几次 VIOS 故障转移测试。这确认升级没有破坏双 VIOS 设置的冗余能力。测试包括：

• 关闭一个 VIOS，确认所有客户机 LPAR 不受影响。例如，SEA 故障转移、IP 连接、路径（和/或镜像）的丢失和磁盘通信流都是正常的。
• 重新启动 VIOS，确认可以执行故障复原。例如，SEA 故障复原、IP 连接、路径恢复（和/或镜像重新同步）和磁盘通信流都是正常的。
• 确认在每次 VIOS 关闭/重新启动前后（重新）同步所有使用镜像 rootvg 的 LPAR。
• 对另一个 VIOS 重复相同的检查过程。

我还拔出了每条 FC 和网络线缆（每次一条），从而确认 VIOS 上的磁盘和网络 I/O 不受影响。

回页首

如果由于某种原因从磁盘引导不成功，我就采用备用计划。也就是在新的 POWER6 平台上使用 NIM 从一个 mksysb 恢复 VIOS 和 LPAR。NIM master 在另一台 595 上。实际上，我在以后的一次 POWER6 升级中测试了这种方法，它与从磁盘引导同样有效。不需要重新配置（引导列表除外），即使对于 VIOS 也是如此。如果需要从 mksysb 恢复 VIOS，那么最好在 NIM master 上为每个 VIOS 创建一个新的 SPOT。从 VIOS 的 mksysb 创建 SPOT（如下所示）。

                    Define a Resource

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                     [Entry Fields]
* Resource Name                                      [hvio3-spot]
* Resource Type                                       spot
* Server of Resource                                 [master]           +
* Source of Install Images                           [hvio3-mksysb]     +
* Location of Resource                               [/export/nim/spot] /
...

另外，在为 BOS 安装配置 VIOS NIM 客户机时，一定要把 "Remain NIM client after install?" 改为 no（如下所示）。这会防止在安装所用的物理网络适配器上配置 IP 地址。如果在这个物理接口上配置了 IP，而且它属于 SEA 配置，SEA 的配置就可能失败，因为这个物理设备已经在使用了。

    Install the Base Operating System on Standalone Clients

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* Installation Target                                 hvio3
* Installation TYPE                                   mksysb
* SPOT                                                hvio3-spot
  LPP_SOURCE                                         []                 +
  MKSYSB                                              hvio3-mksysb
  BOSINST_DATA to use during installation            []                 +
  IMAGE_DATA to use during installation              []                 +
  RESOLV_CONF to use for network configuration       []                 +
  Customization SCRIPT to run after installation     []                 +
  Customization FB Script to run at first reboot     []                 +
    ACCEPT new license agreements?                   [yes]              +

  Remain NIM client after install?                   [no]               +
...

正如前面在 引导每个 VIOS 中提到的，需要小心地选择用哪个 rootvg 磁盘恢复 VIOS mksysb。我的 VIOS 上连接了许多磁盘，其中一些安装了 AIX 映像。如果选择了错误的磁盘，就会覆盖客户机 LPAR AIX rootvg。同样，在恢复 VIOS mksysb 之前记录 VIOS rootvg 磁盘的位置码是非常重要的。

对于 VIOS 和 LPAR，还要确保在 BOS 安装菜单中把 Recover Devices 设置为 Yes。这确保在 mksysb 恢复期间恢复所有设备，因此对于 VIOS，这确保恢复虚拟适配器映射。另外，对于 AIX LPAR，还要检查 Import User Volume Groupsc 是否设置为 Yes。这会在恢复期间导入非 rootvg 卷组。如果要恢复到相同的系统（序列号相同，在我的升级场景中就是这样），就要把 Recover Devices 和 Import User Volume Groups 设置为 Yes。

注意，在 mksysb 恢复之后，在 AIX 5.3 上需要重新配置 Asynchronous I/O (aio0) 设备（如果使用它的话）。在 AIX 6.1 上已经不需要这么做了。

回页首

完成 POWER6 升级并成功地完成所有检查和健康状态检查之后，我把 HACMP 节点重新并入集群中，执行故障转移和故障复原测试。没有发现问题。

升级完成之后，还需要执行几个升级后任务。这些任务包括：

• 再次备份 LPAR 配置文件数据！
• 执行 HMC 的备份。
• 建立每个 VIOS 和所有 AIX LPAR 的 mksysb。
• 在 HMC 上检查所有 ‘open’ 硬件事件。

回页首

我最初对这种升级方法有点担心。但是，我在升级过程中没有遇到什么问题。现在，我可以肯定在某些情况下 MES 升级和从磁盘引导 LPAR 是值得考虑的方法，尤其是如果您的 LPAR 都是 VIO 客户机、使用共享的处理器而且没有任何专用的物理设备。这种方法并不一定可行，所以您应该小心地选择并在自己的环境中进行充分的测试。当然，mksysb 克隆也是支持的迁移方法。

根据我的经验，这两种方法都能够获得令人满意的结果。mksysb 恢复的缺点是所需的时间比较长。如果有大量 LPAR，恢复所需的停机时间在某些情况下可能是不可接受的，比如如果有不属于高可用性集群的系统。

如何从 POWER5 升级到 POWER6 最终由您自己决定。如果您不确定使用哪种方法或者需要帮助或指导，可以向 IBM 支持人员或 IBM 业务伙伴求助。我希望本文有助于其他人进行相似的升级。