目的
本文的目的是提供逐步指南,以将现有的IBM HACMP(PowerHA)集群从基于POWER6处理器的服务器迁移到新的基于POWER7处理器的服务器。 本文基于真实的客户场景。 尽管您的环境和要求可能与此处介绍的环境和要求有所不同,但在大多数其他情况下也可以使用类似的方法。
客户购买了两台基于POWER7处理器的新IBM Power Systems™795(9119-FHB)服务器。 他们需要将现有的HACMP集群从旧的POWER6硬件迁移到新系统。 随着服务器的迁移,他们还需要升级HACMP(因为其当前版本即将停止支持)。 鉴于在迁移期间无论如何群集都需要脱机,因此将群集升级作为POWER7迁移的一部分被认为是适当的。
客户的工作量分布在两个基于POWER6处理器的现有IBM Power 595(9119-FHA)系统上。 现有群集已随HACMP 5.4版一起安装。 它是一个两个节点的群集,每个Power 595服务器上都有一个群集节点。 LPAR和集群建于多年前。 因此,在迁移过程中,将更改或升级以下组件:
- 新的POWER7逻辑分区(LPAR),带有新的物理8 GB光纤通道(FC)和1 GB以太网适配器。 旧的POWER6 LPAR和Power 595服务器将一起停用。
- 引入了新的磁盘存储; 我们将需要将共享集群的卷组磁盘从IBM SystemStorage®DS8300磁盘移至Hitachi Data Systems(HDS)虚拟服务处理器(VSP)磁盘设备。
- 由于IBM存储设备将不再存在于新的LPAR上,因此需要除去子系统设备驱动程序(SDD)和关联的vpath设备。
- 为了支持新的HDS磁盘设备,我们需要安装HDS对象数据管理器(ODM)文件集(并配置新的HDS VSP hdisk设备)。
- 群集中的共享卷组将从标准模式转换为增强并发模式。
- 引入了新的网络交换机。 POWER7 LPAR中的1GB以太网适配器将连接到新交换机。
- IBMAIX®5.3 *已更新为TL12(从TL8)。
- HACMP 5.4迁移到PowerHA 6.1。
*注意:不再支持AIX 5.3。 在计划进行POWER7迁移时(2011年9月),客户希望保留在AIX 5.3上,原因是尚未验证其应用程序软件可以在AIX 7.1(或6.1)上运行。 他们计划在今年(2013年)将集群升级到AIX 7.1。
迁移概述
在开始迁移之前,我们生成了(非常)高层的清单,列出了实现我们的目标所需的步骤。 高级迁移步骤如下:
- 在新的POWER7 LPAR上通过网络安装管理(NIM)从mksysb恢复LPAR(恢复设备=是)。
- 将共享和非共享磁盘配置从IBM迁移到HDS磁盘。
- 导入非共享卷组。
- 导入共享卷组。
- 执行HACMP发现以查找新的(HDS)hdisk设备,而不是vpath(SDD)。
- 同步/验证集群。
- 启动群集服务。
- 重新配置磁盘心跳以使用hdisk而不是vpath。
- 同步/验证集群。
- 为快速磁盘接管启用共享卷组(增强并发模式)。
- 同步/验证集群。
- 在两个节点上停止集群服务。
- 在两个节点上启动群集服务。
- 验证共享卷组在增强并发模式下是否已打开。
- 在两个节点上停止集群服务。
- 在两个节点上将HACMP 5.4升级(迁移)到PowerHA 6.1 SP6。
- 重新引导两个节点。
- 启动群集服务。
- 同步/验证集群。
- 执行群集故障转移测试。
- 确保迁移完成。
迁移结束时,群集节点位于基于POWER7处理器的系统上,即每台Power 795服务器上一个节点。 每个节点都将运行PowerHA 6.1,并将对所有AIX卷组使用HDS磁盘设备。
烹饪书
接下来就是我们的“食谱”,用于将每个集群迁移到新的基于POWER7处理器的服务器。 有六个需要迁移到POWER7的两节点群集。 我们的“食谱”提供了简单的步骤,在POWER7迁移项目期间,客户UNIX管理团队的任何成员都可以遵循这些步骤。 这些步骤是在基于POWER6和POWER7处理器的系统上使用实验室/测试集群环境开发和测试的。 该团队在生产环境中实施之前,多次测试和完善了迁移程序。 此测试对于迁移项目的成功至关重要。
A.准备步骤
- POWER7系统上的新LPAR已为AIX OS(rootvg)预先配置了新的HDS磁盘。 在开始任何迁移活动之前,已分配并测试了磁盘。 测试通常包括对新的LPAR执行虚拟mksysb还原,以确保磁盘可操作并且mksysb可以成功恢复。
- 分配给新LPAR的以太网和光纤通道适配器已连接到正确的网络和SAN交换机。 重要的是要确保网络配置正确,以便PowerHA在迁移后继续运行。 我们确保在适当的虚拟局域网(VLAN)中配置了HA适配器(en0和en2)上的网络接口。 此配置与POWER6系统上节点的配置相同。 执行测试以确认接口在正确的VLAN中,并且每个节点在迁移之前都可以与其伙伴通信。
注意:如果未将网络适配器/接口分配给同一VLAN,则群集可能会出现异常情况。 例如,在测试过程中,我们发现资源组移动后,测试集群无法通过引导接口之一进行通信。 该问题可追溯到以下事实:HA(引导)接口位于网络交换机上的不同VLAN中。 将两个接口都移到交换机上的同一VLAN中可以解决此问题。
- 在开始之前,首先我们确保已禁用对两节点群集的监视。 我们将集群节点置于维护模式(在本例中,我们禁用了客户对集群节点的Nagios监视)。
在迁移过程中,节点和群集实际上将不可用。 此步骤可防止在迁移期间出现任何不需要的警报。 在实施更改之前,我们还将记录每个AIX系统的当前配置。
- 迁移之前,我们需要确保集群运行正常且稳定。 我们执行HACMP同步和验证操作以验证是否是这种情况。 如果群集不稳定或不同步,我们将在开始迁移之前纠正这种情况。 当群集损坏时,移动群集几乎没有意义。 这样做很可能导致迁移失败。 我们还使用clstat和cldump工具查看集群和节点的当前状态。
# smit hacmp Initialization and Standard Configuration Verify and Synchronize HACMP Configuration # clstat < On both nodes. Is everything UP? # cldump < On both nodes. Is the cluster currently STABLE? # vi /tmp/hacmp.out < On both nodes, checking for any events, errors or failures. # errpt
- 在对HA群集进行任何更改之前,最好对群集进行快照(从主节点开始)。 出现问题时,可以使用此快照将群集恢复到已知状态。 运行脚本来执行快照。
# /usr/local/bin/cluster_snap.sh
- 我们将LPAR的mksysb备份备份到我们的NIM主数据库中。 当我们遇到迁移问题时,可以使用此备份映像将AIX节点恢复到已知状态。 我们还将执行文件数据备份到IBMTivoli®Storage Manager。
# /usr/local/bin/saveskelvg >> /var/log/saveskelvg.log 2>&1 # /usr/local/bin/mksysb2nim -s rootvg >> /var/log/mksysb2nim.log 2>&1 # dsmc i
- 集群正在从IBM存储迁移到HDS磁盘。 我们必须在每个节点上安装最新版本的HDS ODM驱动程序,以支持此新设备。 使用NFS挂载将其安装到NIM主软件存储库。
# mount nim1:/software/HDS/HDS_odm_driver/HTCMPIO3 /mnt # cd /mnt # smit install devices.fcp.disk.Hitachi.array.mpio.rte
- 现在可以开始迁移过程。 我们首先在两个节点上停止集群服务。 此时,所有群集资源都将脱机。 所有群集应用程序不再可用。
nodeA# smit clstop
- 在迁移之前,必须关闭所有数据卷组并导出。 还必须从AIX ODM中删除关联的设备(vpath)(使用rmdev )。
# varyoffvg vgname # exportvg vgname # rmdev –dl vpathX # rmdev –dl hdiskX
- 现在,每台595服务器上的节点和LPAR都已关闭。
node1 # shutdown –F node2 # shutdown -F
B.使用NIM将LPAR迁移到POWER7
- 群集节点之前已配置了镜像rootvg磁盘。 新存储不再需要此功能; 新的LPAR用rootvg的单个磁盘配置。 为了确保成功将mksysb还原到新的POWER7 LPAR(具有单个rootvg磁盘),我们必须为每个节点创建一个自定义image.data文件。 该image.data文件将确保mksysb还原过程不会尝试镜像根卷组。 如果我们不更改image.data文件,则还原过程将失败,表明没有足够的磁盘空间来容纳mksysb映像。
我们从NIM上节点的mksysb映像中提取image.data文件。 我们更改
LV_SOURCE_DISK_LIST
,PP=
和COPIES =
值以反映rootvg的非镜像磁盘配置。 然后,我们使用自定义image.data文件创建一个新的image_data NIM资源。root@nim1 : /home/cgibson # restore -xvqf /export/images/nodeB-mksysb.530802-.Thu ./image.data root@nim1 : /home/cgibson # cp image.data node2.image.data root@nim1 : /home/cgibson # vi node2.image.data root@nim1 : /home/cgibson # grep LV_SOU node1.image.data LV_SOURCE_DISK_LIST= hdisk0 ...etc... root@nim1 : /home/cgibson # grep PP= node2.image.data PP= 1 ...etc.. root@nim1 : /home/cgibson # grep COPIES node1.image.data COPIES= 1 ...etc...
上面的过程是手动的。 您可以使用此脚本自动执行此过程(由Kristijan Milos提供)。
使用我们的自定义image.data文件定义了一个新的NIM image_data资源。
root@nim1 : / # smit nim_mkres image_data Define a Resource Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] * Resource Name [cg-node2-image-data] * Resource Type image_data * Server of Resource [master] * Location of Resource [/home/cgibson/node2.image.data]
- 现在,我们可以使用NIM将每个LPAR的mksysb还原到每个Power 795服务器。 我们必须指定在上一步中创建的自定义图像数据文件。
- 使用AIX 531204 lpp_source和SPOT。
- 选择恢复设备并导入用户数据。
to use during installation [
IMAGE_DATA
to use during installation [
cg-node2-image-data
] +
请参阅以下文章,以获取有关将AIX LPAR迁移到新的Power Systems硬件的详细信息。
- mksysb还原完成后,请检查以确保系统现在正在所需的AIX级别上运行。
# oslevel -s 5300-12-04-1119 # instfix -i |grep AIX # instfix –icqk 5300-12_AIX_ML| grep ":-:" # lppchk -m3 –v
C.验证LPAR网络配置
- 确保为每个节点上的HA正确配置了每个网络。 网络10.1.2(en0)和10.1.3(en2)用于客户的HACMP网络配置。
e.g. nodeA. en0: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN> inet 10.1.2.19 netmask 0xffffff00 broadcast 10.1.2.255 en2: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN> inet 10.1.3.14 netmask 0xffffff00 broadcast 10.1.3.255 en4: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN> inet 10.1.4.4 netmask 0xffffff00 broadcast 10.1.4.255 en6: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN> inet 10.1.5.7 netmask 0xfffffc00 broadcast 10.1.5.255 lo0: flags=e08084b<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT> inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255 inet6 ::1/0
- 确保每个引导接口都可以在备用节点上ping通其伙伴接口。 验证主机名是否解析为引导和服务标签的正确IP地址。 例如:
在nodeA上:
# ping nodeBb1 # ping nodeBb2 # host nodeAb1 # host nodeAb2 # host nodeBb1 # host nodeBb2 # host nodeAsvc # host nodeBsvc
在nodeB上:
# ping nodeAb1 # ping nodeAb2 # host nodeAb1 # host nodeAb2 # host nodeBb1 # host nodeBb2 # host nodeAsvc # host nodeBsvc
- 注释掉/etc/rc.net中的以下行。 该错误条目正在系统启动期间将群集节点主机名更改为意外值。 我们发现有必要在客户群集上禁用此功能。
# vi /etc/rc.net # Below are examples of how you could bring up each interface using # ifconfig. Since you can specify either a hostname or a dotted # decimal address to set the interface address, it is convenient to # set the hostname at this point and use it for the address of # an interface, as shown below: #
D.为存储迁移做准备
- 从每个LPAR中删除旧的SDD文件集。 由于不再访问IBM存储,因此不再需要安装IBM子系统设备驱动程序。
# stopsrc –s sddsrv # installp -u devices.sdd.53.rte # installp -u ibm2105.rte # installp -u devices.fcp.disk.ibm.rte
- 我们还借此机会删除了rootvg中的所有旧
multibos
实例(如果适用)。# multibos -R
- 重新引导两个LPAR。
E.存储迁移
-
移交给存储团队以进行数据逻辑单元号(LUN)迁移
在此阶段,存储团队将接任。 他们执行从IBM磁盘到HDS磁盘的实际数据迁移。 完成数据迁移后,数据LUN将被重新分区为与新POWER7 LPAR中新的8GB FC适配器关联的新的全球端口名(WWPN)。 本质上,当我们重新启动LPAR时,我们期望看到新的HDS磁盘(不是IBM)。 但是,所有数据都是完整的。 数据迁移是使用HDS存储复制技术实现的。 使用这种方法,我们并不需要,使用工具如migratepv,mirrorvg参与AIX逻辑卷管理器(LVM)迁移技术等采用传统的程序。 如果您想了解更多有关使用AIX LVM执行存储迁移的信息,请参考2010年关于该主题的文章 。
F.迁移集群存储设备
- 运行cfgmgr命令并在两个节点上配置HDS磁盘和FC适配器。
# cfgmgr # lsdev –Cc disk # chdev –l fscsi{y} –a fc_err_recov=fast_fail –a dyntrk=yes –P # chdev –l hdisk{x} –a reserve_policy=no_reserve -P # chdev –l hdisk{x} –a algorithm=round_robin -P # lsattr –El fscsi{y} # lsattr –El hdisk{x} where fscsi{y} is each FC adapter in LPAR where hdisk{x} is ALL disks.
- 检查物理卷标识符(PVID)是否完好(也就是说,在LUN重新分区/迁移后没有更改)并且在两个节点上都相同。
nodeA# lspv nodeB# lspv
- 导入共享和非共享的数据卷组。
- 非共享卷组:
# importvg –y appvg hdisk4
- 共享卷组:
- 在两个节点上执行importvg 。 例如:
在nodeA上 :
# importvg –y sharedvgA hdisk2 # lsvg –l sharedvgA # varyoffvg sharedvgA
一个节点B :
# importvg –y sharedvgA hdisk2 # lsvg –l sharedvgA # varyoffvg sharedvgA
- 挂载非共享文件系统。 检查文件系统的安装顺序是否正确,因为导入卷组(VG)后可能已更改。 确保没有文件系统超载。
# for i in `lsvgfs appvg` do mount $i done # lsvg –l appvg # df # lspath
- 在两个节点上执行importvg 。 例如:
- 非共享卷组:
- 执行HACMP发现。 这将为共享卷组找到新的HDS hdisk设备。
# smit hacmp Extended Configuration Discover HACMP-related Information from Configured Nodes
- 立即执行“验证和同步HACMP配置”操作。
- 在两个节点上启动群集服务。 使用
clstat
确认集群是稳定的。
G.配置新的群集心跳设备
- 重新配置磁盘心跳设备以使用hdisk而不是vpath。
# smit hacmp Extended ConfigurationConfigure HACMP Communication Interfaces/DevicesChange/Show Communication Interfaces/Devices │ Select one or more Communication Interfaces/Devices to Remove │ │ │ │ Move cursor to desired item and press F7. Use arrow keys to scroll. │ │ ONE OR MORE items can be selected. │ │ Press Enter AFTER making all selections. │ │ │ │ # Node / Network │ │ # Interface/Device IP Label/Device Path IP Address │ │ │ │ │ │ # nodeA / net_diskhb_01 │ │ vpath1 nodeA_vpath1_01 /dev/vpath │ │ │ │ # nodeA / net_ether_01 │ │ en0 node1b1 10.1.2. │ │ en2 node1b2 10.1.3. │ │ │ │ # nodeA / net_ether_02 │ │ en4 nodeA 10.1.4. │ │ │ │ # nodeB / net_diskhb_01 │ │ vpath0 nodeB_vpath0_01 /dev/vpath │ │ │ │ # nodeB / net_ether_01 │ │ en0 node2b1 10.1.2. │ │ en2 node2b2 10.1.3. │ │ │ │ # nodeB / net_ether_02 │ │ en4 nodeB 10.1.4. │ Remove Communication Interfaces/Devices │ # nodeA / net_diskhb_01 ││ vpath1 nodeA_vpath1_01 /dev/vpath ││ # nodeB / net_diskhb_01 ││ vpath0 nodeB_vpath0_01 /dev/vpath │Add Discovered Communication Interface and Devices │ Select Point-to-Point Pair of Discovered Communication Devices to Add │ │ │ │ Move cursor to desired item and press F7. │ │ ONE OR MORE items can be selected. │ │ Press Enter AFTER making all selections. │ │ │ │ # Node Device Pvid │ │ >nodeA hdisk1 00c69b9edd04057b │ │ >nodeB hdisk1 00c69b9edd04057b │ │ │ Change/Show Communication Interfaces/Devices │ Select a Communication Interface/Device to Change/Show │ │ │ │ Move cursor to desired item and press Enter. Use arrow keys to scroll. │ │ │ │ # Node / Network │ │ # Interface/Device IP Label/Device Path IP Address │ │ │ │ │ │ # nodeA / net_diskhb_01 ││ hdisk1 nodeA_hdisk1_01 /dev/hdisk ││ │ │ # nodeA / net_ether_01 │ │ en0 node1b1 10.1.2. │ │ en2 node1b2 10.1.3. │ │ │ │ # nodeA / net_ether_02 │ │ en4 nodeA 10.1.4. │ │ │ │ # nodeB / net_diskhb_01 ││ hdisk1 nodeB_hdisk1_01 /dev/hdisk ││ │ │ # nodeB / net_ether_01 │ │ en0 node2b1 10.1.2. │ │ en2 node2b2 10.1.3. │ │ │ │ # nodeB / net_ether_02 │ │ en4 nodeB 10.139.64. │
- 立即执行“验证和同步HACMP配置”操作。 等待几分钟,然后验证新的diskhb设备是否出现在
clstat
输出中。clstat - HACMP Cluster Status Monitor ------------------------------------- Cluster: HA1 (1110178227) Tue Oct 11 15:07:17 EETDT 2011 State: UP Nodes: 2 SubState: STABLE Node: nodeA State: UP Interface: nodeA (2) Address: 10.1.4.4 State: UP Interface: node1b1 (1) Address: 10.1.2.19 State: UP Interface: node1b2 (1) Address: 10.1.3.14 State: UP Interface: nodeA_hdisk1_01 (0) Address: 0.0.0.0 State: UP Interface: node1 (1) Address: 10.1.1.9 State: UP Resource Group: ResGrpA State: On line Node: nodeB State: UP Interface: nodeB (2) Address: 10.1.4.5 State: UP Interface: node2b1 (1) Address: 10.1.2.12 State: UP Interface: node2b2 (1) Address: 10.1.3.15 State: UP Interface: nodeB_hdisk1_01 (0) Address: 0.0.0.0 State: UP Interface: node2 (1) Address: 10.1.1.3 State: UP Resource Group: ResGrpA State: On line
- 验证节点是否可以通过新磁盘心跳进行通信。
在nodeA上 :
# /usr/sbin/rsct/bin/dhb_read -p hdisk1 -t DHB CLASSIC MODE First node byte offset: 61440 Second node byte offset: 62976 Handshaking byte offset: 65024 Test byte offset: 64512 Receive Mode: Waiting for response . . . Magic number = 0x87654321 Magic number = 0x87654321 Magic number = 0x87654321 Magic number = 0x87654321 Link operating normally
在nodeB上 :
# /usr/sbin/rsct/bin/dhb_read -p hdisk1 -r DHB CLASSIC MODE First node byte offset: 61440 Second node byte offset: 62976 Handshaking byte offset: 65024 Test byte offset: 64512 Transmit Mode: Magic number = 0x87654321 Detected remote utility in receive mode. Waiting for response . . . Magic number = 0x87654321 Magic number = 0x87654321 Link operating normally
H.将共享卷组转换为增强并发模式
- 启用共享卷组以进行快速磁盘接管,即增强的并发模式。 首先,确保在两个节点上都安装了
bos.clvm.enh
文件集。 对每个共享卷组执行以下任务。 之后,立即同步共享卷组定义。# smit hacmp System Management (C-SPOC) HACMP Logical Volume Management Shared Volume Groups Enable a Shared Volume Group for Fast Disk Takeover ResGrpA sharedvgA * Resource Group Name ResGrpA * SHARED VOLUME GROUP name sharedvgA # smit cl_lvm Synchronize a Shared Volume Group Definition sharedvgA
- 立即执行“验证和同步HACMP配置”操作。
- 在两个节点上停止集群服务。
- 在两个节点上启动群集服务。 验证现在所有共享卷组都以增强并发模式 启用 ,即在主节点上进行主动读/写 ,在备用节点上进行仅主动-被动方式 。
nodeA# lspv hdisk0 00c342c6c73137a9 rootvg active hdisk1 00c69b9edd04057b diskhbvg concurrent hdisk2 00c40a8e97f5cca1 sharedvgA concurrent hdisk3 00c40a8e97f5dc8a sharedvgB concurrent hdisk4 00c40a8e04e87819 appvg active hdisk5 00c40a8e97f0dda8 appvg active nodeB# lspv hdisk0 00c334b6c7cca4b1 rootvg active hdisk1 00c69b9edd04057b diskhbvg concurrent hdisk2 00c40a8e97f5cca1 sharedvgA concurrent hdisk3 00c40a8e97f5dc8a sharedvgB concurrent hdisk4 00c69b9e97fe3331 appvg active hdisk5 00c69b9e04e9bc20 appvg active nodeA# lsvg sharedvgA VOLUME GROUP: sharedvgA VG IDENTIFIER: 00c40a8e00004c000000010280d7161f VG STATE: active PP SIZE: 64 megabyte(s) VG PERMISSION: read/write TOTAL PPs: 527 (33728 megabytes) MAX LVs: 512 FREE PPs: 357 (22848 megabytes) LVs: 4 USED PPs: 170 (10880 megabytes) OPEN LVs: 4 QUORUM: 2 (Enabled) TOTAL PVs: 1 VG DESCRIPTORS: 2 STALE PVs: 0 STALE PPs: 0 ACTIVE PVs: 1 AUTO ON: no Concurrent: Enhanced-Capable Auto-Concurrent: Disabled VG Mode: Concurrent Node ID: 1 Active Nodes: 2 MAX PPs per VG: 130048 MAX PPs per PV: 1016 MAX PVs: 128 LTG size: 128 kilobyte(s) AUTO SYNC: no HOT SPARE: no BB POLICY: relocatable nodeB# lsvg sharedvgB VOLUME GROUP: sharedvgB VG IDENTIFIER: 00c40a8e00004c000000010280d7161f VG STATE: active PP SIZE: 64 megabyte(s) VG PERMISSION: passive-only TOTAL PPs: 527 (33728 megabytes) MAX LVs: 512 FREE PPs: 357 (22848 megabytes) LVs: 4 USED PPs: 170 (10880 megabytes) OPEN LVs: 0 QUORUM: 2 (Enabled) TOTAL PVs: 1 VG DESCRIPTORS: 2 STALE PVs: 0 STALE PPs: 0 ACTIVE PVs: 1 AUTO ON: no Concurrent: Enhanced-Capable Auto-Concurrent: Disabled VG Mode: Concurrent Node ID: 2 Active Nodes: 1 MAX PPs per VG: 130048 MAX PPs per PV: 1016 MAX PVs: 128 LTG size: 128 kilobyte(s) AUTO SYNC: no HOT SPARE: no BB POLICY: relocatable
I.将HACMP 5.4迁移到PowerHA 6.1
- 在两个节点上停止集群服务。
# smit clstop
- 将HACMP 5.4升级到PowerHA 6.1 SP6。 确保“ 接受新的许可协议 ?” 更改为是 。 通过查看clconvert.log日志文件,确认从5.4到6.1的HA迁移已成功完成。 验证显示正确的HA级别。
# mount nim1:/software/PowerHA6.1 /mnt # cd /mnt # smitty update_all # lslpp -L cluster*server*rte Fileset Level State Type Description (Uninstaller) ---------------------------------------------------------------------------- cluster.es.server.rte 6.1.0.0 C F ES Base Server Runtime # cd /mnt/SP6/ # smitty update_all # lslpp -L cluster*server*rte Fileset Level State Type Description (Uninstaller) ---------------------------------------------------------------------------- cluster.es.server.rte 6.1.0.6 A F ES Base Server Runtime # cd / # umount /mnt # view /tmp/clconvert.log Command line is: /usr/es/sbin/cluster/conversion/cl_convert -F -v 5.4.1 No source product specified. Assume source and target are same product. Parameters read in from command line are: Source Product is HAES. Source Version is 5.4.1. Target Product is HAES. Target Version is 6.1.0. Force Flag is set. …etc.. odmdelete -o HACMPtopsvcs: 0518-307 odmdelete: 1 objects deleted. odmadding HACMPtopsvcs odmdelete -o HACMPcluster: 0518-307 odmdelete: 1 objects deleted. odmadding HACMPcluster *************************** *** End of ODM Manager *** *************************** Done execution of ODM manipulator scripts. Cleanup: Writing resulting odms to /etc/es/objrepos. Restoring original ODMDIR to /etc/es/objrepos. Removing temporary directory /tmp/tmpodmdir. Exiting cl_convert. Exiting with error code 0. Completed successfully. --------- end of log file for cl_convert: Sat Oct 15 16:32:33 EETDT 2011 # halevel -s 6.1.0 SP6
现在,在继续下一步之前更新第二个节点。
- 立即重新启动两个节点。
- 在两个节点上启动群集服务。 使用clstat验证集群是否稳定。
- 立即执行“验证和同步HACMP配置”操作。
- 升级PowerHA的Tivoli Storage Manager客户机。
- 在两个集群节点上升级Tivoli Storage Manager客户机。 如果您的集群节点上安装了Tivoli Storage Manager客户机,请参阅我的博客以获取在PowerHA环境中升级Tivoli Storage Manager客户机的过程。
- 立即执行“验证和同步HACMP配置”。
J.测试集群资源组的移动
- 将资源组移动到另一个节点,即,将节点 A上的资源组A移动到nodeB。 验证移动是否完成。
# smit hacmp System Management (C-SPOC) Resource Group and Applications Move a Resource Group to Another Node / Site Move Resource Groups to Another Node ResGrpA ONLINE nodeA / nodeB # clGRinfo # clstat # df # lsvg –o # ping serviceipaddressssh to serviceipaddress (should connect to second node in cluster)
- 将资源组移回到主节点,例如nodeA 。 验证移动是否完成。
# clGRinfo # clstat # df # lsvg –o # ping serviceipaddressssh to serviceipaddress (should connect to home node in cluster)
K.测试群集故障转移
- 执行标准的群集故障转移测试(由客户定义)-包括针对故障转移方案的应用程序测试。
- 将旧的POWER6 LPAR配置文件定义更改为以系统管理服务(SMS)模式引导,然后将LPAR配置文件重命名为OLD_LPARname 。 这有助于防止旧的LPAR错误地启动(直到Power 595服务器退役)。
- 移交给应用程序团队以测试其应用程序。
- 确保迁移完成。
摘要
在本文中,您学习了如何将现有的两节点PowerHA集群从POWER6迁移到POWER7,如何升级PowerHA,以及如何将共享卷组转换为增强并发模式。
翻译自: https://www.ibm.com/developerworks/aix/library/au-cluster-migration/index.html