首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

从 POWER5 升级到 POWER6

从 POWER5 升级到 POWER6

本文介绍我从 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 升级的一个重要特性是不改变系统序列号。
图 1. 9119-595 和 9119-FHA从 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。
图 2. FLRT 报告在升级之前的几个月里,我们按以下次序把以下组件升级到以下级别:
  • HMC                V7R3.4.0 + MH01152
  • 固件更新的各种 H/W(例如,FC、SCSI 和以太网适配器)
  • VIOS                 1.5.2.1-FP-11.1 + SDDPCM 2.2.0.4
  • AIX                5300-07-05-0831
  • 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 工具判断系统上安装的微代码是否是最新级别的。图 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 配置文件。
图 4. 备份分区数据
返回列表