Chinaunix首页 | 论坛 | 博客
  • 博客访问: 25881585
  • 博文数量: 271
  • 博客积分: 10025
  • 博客等级: 上将
  • 技术积分: 3358
  • 用 户 组: 普通用户
  • 注册时间: 2007-11-12 15:28
文章分类

全部博文(271)

文章存档

2010年(71)

2009年(164)

2008年(36)

我的朋友

分类:

2010-04-01 09:54:33

李 木, 软件工程师, IBM
李 媛, 软件工程师, IBM
潘 文斌, 软件工程师, IBM

简介: 动态分区迁移因为其快捷方便的操作及高可靠性的迁移功能越来越引起人们的重视。本文将以具体的事例,对动态分区迁移功能准备过程中最困难、最重要和最繁琐的四大方面进行讲解,即:管理源系统和目标系统的 HMC 或 IVM 配置、活动分区配置、源系统和目标系统的存储及网络配置。在这篇文章中,您不但能一窥动态分区迁移部署过程的全貌,还能看到准备过程中某些部分的具体细节。

动态分区迁移(Live Partition Mobility,以下简称 LPM)是 IBM 基于 POWER6 技术提供的新特性,它特指将运行 AIX 或 Linux 操作系统的逻辑分区从一台物理系统迁移到另外一台完全不同的物理系统的过程。在这个过程中,操作系统和应用程序不受任何破坏,对外提供的服务也不受任何影响。

LPM 给与管理员更灵活的控制职能,目前它的用途主要体现在以下几个方面:

  1. 当逻辑分区所在的系统需要 Firmware 或者硬件的升级,但是这个逻辑分区由于正对外提供服务而不能关闭时,就可以利用 LPM 功能将它先迁移到另一台物理系统上,待升级完毕后,再将逻辑分区迁移回来。
  2. 可以用来平衡日益增长的工作量和资源需求,将服务较少的多个逻辑分区迁移到同一台物理系统上,然后将多余的物理系统关闭,从而降低能耗。这个也符合了目前提倡的绿色环保的理念。
  3. 随着业务的发展,逻辑分区上的工作量可能会越来越大,这时可以利用 LPM 功能将逻辑分区迁移到资源更多的物理系统上,以提供更优质的服务。
  4. 当物理系统的硬件存在潜在问题时,可以利用 LPM 功能将其上正在提供服务的逻辑分区迁移到安全的系统上。
  5. 当用户购买了更新型号的硬件时,也可以利用 LPM 功能将以前提供服务的逻辑分区迁移到新机器上。

未来 LPM 功能将会发挥越来越大的作用。试想一下:对外提供服务的逻辑分区都将不被固定在一个硬件系统上,而是随着服务规模和硬件环境的变化,随时被迁移到另外的系统上。

在讲述 LPM 准备过程之前,让我们首先了解一下涉及到的术语:

  • 活动分区(Mobile Partition):被迁移的逻辑分区。
  • 源系统(Source System):活动分区原来所在的系统。
  • 目标系统(Target System):活动分区将要被迁移到的系统。
  • VIOS(Virtual I/O Server):即虚拟 I/O 服务器。是一个安装了特殊定制的 AIX 操作系统的逻辑分区。它可以将各种物理资源转化为虚拟资源,从而使得各个逻辑分区通过 VIOS 来共享这些物理资源。
  • HMC(Hardware Management Console):即硬件管理平台。用来管理一台或多台系统的平台,它有自己独立的硬件。用户可以通过 HMC 的可视化界面或命令行对逻辑分区和系统等进行一系列的管理工作。
  • IVM(Integrated Virtualization Manager):即集成虚拟化管理器。相比 HMC 而言,它没有独立的硬件,而是通过软件来实现对一台系统的管理。是一个轻量级的系统管理器,可以看作是简化了的 HMC。
  • FSP(Flexible Service Processor):Power 服务器中用来管理主机硬件的板卡,系统插电后 FSP 即开始工作。该板上有插口用于将系统连接到 HMC 网络。可以通过 ASMI(Advanced System Management Interface)控制 FSP 进而执行电源重启、查看系统信息等操作。
  • MSP(Mover Service Partition):即移动服务分区。VIOS 的一个系统设置,由它控制是否允许迁移逻辑分区的状态。
  • RMC(Resource Monitor and Control):RMC 是一个分布式的框架和体系结构,它允许 HMC 和被管理的逻辑分区进行通讯。

更多的基本概念和操作过程可以通过查看参考资源。

标准的 LPM 过程是由验证操作和迁移操作两部分组成的。即:

  • 验证操作(Validation):验证是进行 LPM 之前可选的一步操作,它可以帮助用户检查环境是否已经准备就绪。验证操作提供的错误信息和警告信息可以帮助用户及时修正错误,以保证迁移过程的顺利进行。
  • 迁移操作(Migration):由 HMC 或 IVM 提供的功能。使用迁移操作,可以完成活动分区从源系统到目标系统的动态分区迁移。

LPM 按照逻辑分区的情况分为下面两种类型的迁移:

  • 冷迁移(Inactive Migration):被迁移的逻辑分区是断电的。在参考资料中称为非活动迁移,在本文中将使用冷迁移这个翻译。
  • 热迁移(Active Migration):被迁移的逻辑分区是不断电的,且一直对外提供服务。在迁移过程中逻辑分区能继续提供服务,不会影响用户行为。在参考资源中称为活动迁移,在本文中将使用热迁移这个翻译。

LPM 按照系统的管理方式分为下面两种类型的迁移:

  • HMC 之间的动态分区迁移:逻辑分区使用 HMC 管理的 LPM。
  • IVM 之间的动态分区迁移:逻辑分区使用 IVM 管理的 LPM。

无论我们选择进行冷迁移还是热迁移,首先物理系统的硬件要符合 LPM 功能的特定要求,然后还需对其环境进行特殊的配置以满足 LPM 操作的条件。冷迁移相比于热迁移在系统配置方面要宽松一些,下面仅以热迁移为例进行说明,没有明确说明的条件均适用于冷、热迁移。

主要准备过程包括以下若干方面:

  1. 源系统和目标系统的 FSP 的设置。具体包括:
    1. PowerVM 企业版代码已被激活。
    2. 逻辑内存块的大小相同。
  2. 管理源系统和目标系统的 HMC 或 IVM 满足如下要求:
    1. HMC 的硬件支持 LPM 功能。
    2. HMC 和 IVM 的操作系统版本支持 LPM 功能。
    3. 远程的 HMC 和 IVM 之间已建立密钥认证。
  3. 源系统和目标系统的设置。具体包括:
    1. 源系统和目标系统使用 Power 6 或者更高版本的硬件。
    2. 源系统和目标系统的管理方式相同,即都使用 HMC 或都使用 IVM 进行管理。
    3. 源系统和目标系统的 Firmware 版本支持 LPM 功能。
    4. 目标系统上有足够闲置的内存和处理器用来支持 LPM 功能。
    5. 目标系统不可运行在电池系统上。
  4. 源 VIOS 和目标 VIOS 满足如下要求:
    1. VIOS 的版本支持 LPM 功能。
    2. 启用 MSP 功能(冷迁移无此要求)。
    3. 时钟同步(冷迁移无此要求)。
  5. 活动分区满足如下要求:
    1. 运行的操作系统支持 LPM 功能。
    2. RMC 连接已建立(冷迁移无此要求)。
    3. 关闭冗余错误路径报告功能。
    4. 虚拟串行适配器(Virtual Serial Adapter)不得多于 2 个,即只能通过 HMC 或 IVM 取得对活动分区的虚拟终端连接。
    5. 不属于任何一个逻辑分区负载管理组(Workload Manager Group)。
    6. 不能使用线程同步寄存器(Barrier-synchronization Register)(冷迁移无此要求)。
    7. 不能使用大页内存(Huge Page)。
    8. 不能使用物理或专属的 I/O 设备(冷迁移无此要求)。
    9. 运行的应用程序是可安全迁移的。
  6. 外部存储满足如下条件:
    1. 源系统和目标系统连接相同的 SAN 存储。
    2. 将整块的 SAN 存储以虚拟磁盘的形式分配给活动分区。
    3. SAN 逻辑单元的 reserve_policy 属性置为 no_reserve。
    4. 目标系统上有足够的虚拟插槽(Virtual Slot)。
  7. 网络配置满足 :
    1. 源 VIOS 和目标 VIOS 配置共享以太网适配器。
    2. 活动分区使用虚拟网卡。

上面的 LPM 准备过程在红皮书《 IBM PowerVM Live Partition Mobility 》中都有所涉及,所以本文只就 LPM 准备环境过程中的最重要、最困难和最繁琐的部分进行着重讲解,并且结合在 LPM 测试过程中发现的问题进行分析。


LPM 是 PowerVM 企业版才支持的功能,所以在进行 LPM 操作之前,要首先确认 FSP 上已经激活了 PowerVM 企业版的代码。以 HMC 管理的系统为例,可以通过在 HMC 的 Server Management -> Servers 里选定系统,打开 Properties -> Capability 进行查看。如果 PowerVM 企业版代码已激活,则 Active Partition Mobility Capable 和 Inactive Partition Mobility Capable 的值为 True,如图 1 所示。



图 1. 通过 HMC 查看系统是否已经激活了 PowerVM 企业版代码

LPM 的详细信息可以在 Migration 标签页中查看,如图 2 所示。



图 2. 查看 LPM 的详细信息

跟操作系统管理虚拟内存类似,PowerVM Hypervisor 以逻辑内存块(Logical Memory Block,以下简称 LMB)而不是字节为单位管理服务器的物理内存。LPM 要求源系统和目标系统上 LMB 大小的设置必须相同。我们可以通过 ASMI 对其进行修改。具体的修改步骤为,打开 ASMI 页面,在 Performance Setup 部分进行 LMB 的修改,如图 3 所示。



图 3. 修改 LMB 的大小

FSP 的 LMB 设置还需要注意:LMB 的修改结果一定是要重启整台系统后才够生效。


LPM 功能仅限于在两种类型的管理方式上使用:即源服务器和目标服务器使用同一台或两台不同的 HMC 管理,或源服务器和目标服务器均使用 IVM 管理。目前还不支持 HMC 和 IVM 之间的 LPM 功能。

当 LPM 操作发生在两台 HMC 之间时,需要为这它们建立密钥认证。分别登陆到两台 HMC 上,执行 mkauthkey 命令。以 hmc-gira 和 hmc-folk 这两台 HMC 为例,后者的 IP 地址是 9.3.117.211,建立密钥认证的过程如清单 1 所示(需要在 hmc-folk 上执行类似的操作),即:先在 .ssh 目录下的 authorized_keys2 文件中查找,如果密钥已经写入该文件,则 hmc-gira 已经建立了与 hmc-folk 的密钥认证,否则执行 mkauthkey 命令。



hscroot@hmc-gira:~> cat .ssh/authorized_keys2 |grep hmc-folk
hscroot@hmc-gira:~> host hmc-folk
hmc-folk.upt.austin.ibm.com has address 9.3.117.211
hscroot@hmc-gira:~> mkauthkeys -g --ip 9.3.117.211 -u hscroot
Enter the password for user hscroot on the remote host 9.3.117.211:
hscroot@hmc-gira:~>
			

建立密钥认证后,如有需要,可以查看 authorized_keys2 文件获取具体的密钥。

在没有建立密钥认证的 HMC 之间执行 LPM 的验证操作时,会得到如图 4 所示的错误信息。



图 4. HMC 之间没有建立密钥认证时,执行 LPM 验证操作的错误信息

IVM 之间的迁移同样需要建立密钥认证,否则也会出现类似的错误信息,清单 2 给出的是在 IVM 上使用命令行进行验证操作时得到的错误信息。



$ migrlpar -o v  -m uli13 -t uli14 --ip 9.3.111.64 -p uli13lp1
[VIOSE0104202E-0409] The migration process failed because of an unknown error
 on the destination system.  Additional information: Permission denied 
 (publickey,password,keyboard-interactive).

			

IVM 之间密钥认证的建立方法与 HMC 相同,这里不再累述。


源系统和目标系统的 Firmware 版本要分别符合 LPM 功能的要求,才能够进行 LPM 的操作。仅仅满足这个条件还不够,还要注意源系统和目标系统的 Firmware 版本是否兼容。在表 1 中,我们可以看到在各种 Firmware 版本的对 LPM 的支持。



目标系统 Firmware 版本
源系统 Firmware
版本
EM320_031 EM320_040 EM320_046 EM320_061 EM320_028 EM320_039
EM320_031 支持 支持 支持 禁止 禁止 禁止
EM320_040 支持 支持 支持 禁止 禁止 禁止
EM320_046 支持 支持 支持 支持 支持 支持
EM320_061 禁止 禁止 支持 支持 支持 支持
EM320_028 禁止 禁止 支持 支持 支持 支持
EM320_039 禁止 禁止 支持 支持 支持 支持

清单 3 列出的是 Firmware 不兼容时出现的错误信息。



HSCLA359 The destination managed system has failed the compatibility data 
checking performed on the migrating partition with the following error: 
Partition Firmware Incompatible. 


激活 MSP 功能后,VIOS 就具备了分区迁移的功能,它可以通过 VASI 适配器与 hypervisor 进行通讯,进行数据拷贝等操作。因为热迁移涉及到对内存、处理器和其它各种资源状态等动态数据的拷贝,所以需要 MSP 参与进来。对于冷迁移则没有这个要求。

为了满足不同迁移类型的要求,建议打开源系统和目标系统的 MSP 功能,否则会出现如图 5 所示的的错误信息。



图 5. 没有启用 MSP 功能时,执行 LPM 验证操作的错误信息

具体的开启 MSP 功能的步骤是:

  1. 打开 HMC,进 System Management -> Servers 选项。
  2. 选择要修改的系统。
  3. 选择 VIOS 的逻辑分区,在左键菜单中选择 Property。
  4. 在 Property 的 General 标签页中进行修改。

具体如图 6 所示:



图 6. 设置 MSP 功能

活动分区运行一般的程序时,是不需要对 VIOS 的内存进行特殊设置的。但是当活动分区负载较大时,就要为 VIOS 分配较多的内存(建议至少为 2GB),以满足分区迁移过程中 VIOS 大量拷贝并传送活动分区内存时的资源需求。如果被迁移分区是共享内存(Active Memory Sharing,更多内容请查看参考资源)分区或 VIOS 是页面交换分区时,则 VIOS需要配置更多的内存(建议至少为 3GB)来避免内存的不足。否则 LPM 在迁移期间会停滞在 0% 的进度,但是在验证阶段不会出现任何错误或者警告。

这是因为:

  1. VIOS 的 MSP 代码会因为得不到足够的内存而中止。
  2. entstat 是 AIX 操作系统提供的命令,用于显示以太网设备驱动器和设备统计信息。该命令在内存不足的时也会中止。

在执行热迁移的活动分区上需要建立 RMC 连接,否则在 LPM 验证阶段会得到如图 7 所示的错误信息:



图 7. 活动分区没有建立 RMC 连接时,执行 LPM 验证操作的错误信息

使用 lsrsrc IBM.ManagementServer 命令来查看 RMC 连接是否建立,当该命令没有输出或者返回的 ManagerType 属性值不为 HMC 时,说明该活动分区上的 RMC 连接没有建立。清单 4 给出了在一个已经建立 RMC 连接的逻辑分区上执行 lsrsrc IBM.ManagementServer 命令的输出。



giftlp3:~ # lsrsrc IBM.ManagementServer
Resource Persistent Attributes for IBM.ManagementServer
resource 1:
        Name             = "9.3.117.84"
        Hostname         = "9.3.117.84"
        ManagerType      = "HMC"
        LocalHostname    = "9.3.111.77"
        ClusterTM        = "9078-160"
        ClusterSNum      = ""
        ActivePeerDomain = ""
        NodeNameList     = {"giftlp3"}
giftlp3:~ #


RMC 连接的建立方法可以查看参考资源。


执行热迁移的活动分区不允许分配任何物理或者专属的 I/O 设备,否则在 LPM 验证阶段就会得到如图 8 所示的错误信息。如果活动分区的物理 I/O 设备在当前的概要文件 (Profile) 中被标为 desired,可以使用 DLPAR(Dynamic Logical Partitioning)操作将其移除,如果被标为 required,则只能在关闭该活动分区后,修改概要文件来将其删除。

进行冷迁移的活动分区虽然不受此条件的约束,但是物理或者专属的 I/O 设备是不会被迁移的,只有虚拟设备才会被成功迁移。



图 8. 活动分区使用物理 I/O 设备时,执行 LPM 验证操作的错误信息

执行 LPM 操作的源系统和目标系统都必须以 SAN 存储作为它们的外部存储。将源系统和目标系统物理上连接到相同的 SAN 存储,然后通过 SAN 交换机(SAN Switch)进行分组(Zone)操作使它们能够访问相同的 SAN 逻辑单元。

判断系统上是否连接了 SAN 存储,可以登陆到 VIOS 上,如清单 5 所示的方法进行查看,要注意观察第二个数据是否为“Available”,如果为 Defined,则系统并不是真的可以访问 SAN 存储。



$ lsdev -type disk |grep Available |grep MPIO
hdisk21          Available   MPIO Other FC SCSI Disk Drive
hdisk22          Available   MPIO Other FC SCSI Disk Drive
hdisk23          Available   MPIO Other FC SCSI Disk Drive
hdisk24          Available   MPIO Other FC SCSI Disk Drive
hdisk25          Available   MPIO Other FC SCSI Disk Drive
hdisk26          Available   MPIO Other FC SCSI Disk Drive
hdisk27          Available   MPIO Other FC SCSI Disk Drive
hdisk28          Available   MPIO Other FC SCSI Disk Drive
hdisk29          Available   MPIO Other FC SCSI Disk Drive
hdisk30          Available   MPIO Other FC SCSI Disk Drive
hdisk31          Available   MPIO Other FC SCSI Disk Drive
hdisk32          Available   MPIO Other FC SCSI Disk Drive
$


源系统和目标系统是否连接相同的 SAN 逻辑单元,可以通过 SAN 逻辑单元的唯一标识字符串进行验证。登陆到 VIOS,使用下面的命令分别查看源系统和目标系统的每个 SAN 逻辑单元,比较对应的 SAN 逻辑单元的 lun_id 属性值是否相同,如清单 6 所示。



$ lsdev -dev hdisk21 -attr
attribute       value                            description              user_settable

PCM             PCM/friend/fcpother              Path Control Module              False
algorithm       fail_over                        Algorithm                        True
clr_q           no                               Device CLEARS its Queue on error True
dist_err_pcnt   0                                Distributed Error Percentage     True
dist_tw_width   50                               Distributed Error Sample Time    True
hcheck_cmd      test_unit_rdy                    Health Check Command             True
hcheck_interval 60                               Health Check Interval            True
hcheck_mode     nonactive                        Health Check Mode                True
location                                         Location Label                   True
lun_id          0x400040fa00000000               Logical Unit Number ID           False
lun_reset_spt   yes                              LUN Reset Supported              True
max_retry_delay 60                               Maximum Quiesce Time             True
max_transfer    0x40000                          Maximum TRANSFER Size            True
node_name       0x5005076304ffce9f               FC Node Name                     False
pvid            none                             Physical volume identifier       False
q_err           yes                              Use QERR bit                     True
q_type          simple                           Queuing TYPE                     True
queue_depth     16                               Queue DEPTH                      True
reassign_to     120                              REASSIGN time out value          True
reserve_policy  no_reserve                       Reserve Policy                   True
rw_timeout      30                               READ/WRITE time out value        True
scsi_id         0x89800                          SCSI ID                          False
start_timeout   60                               START unit time out value        True
unique_id       200B75CMRY200FA07210790003IBMfcp Unique device identifier         False
ww_name         0x50050763043bce9f               FC World Wide Name               False
$


在确认了源系统和目标系统能访问相同的 SAN 逻辑单元后,还要注意 SAN 逻辑单元的 reserve_policy 属性值是否已经修改为 no_reserve,如上面的清单 6 所示。

如果 reserve_policy 的属性值不是 no_reserve,则使用下面的命令进行修改。

chdev -dev hdiskX -attr reserve_policy=no_reserve   

如果参与迁移的 SAN 逻辑单元的 reserve_policy 属性没有被设置为 no_reserve,则在执行 LPM 验证操作时会得到如图 9 所示的错误信息:



图 9. SAN 硬盘的 reserve_policy 属性值不为 no_reserve 时,执行 LPM 验证操作的错误信息

进行 LPM 操作的系统必须使用虚拟网卡。如果使用的是物理网卡,则需要自己创建 SEA(Shared Ethernet Adapter),并且对其进行配置,使系统能够通过它连接到外部网络。

当源系统和目标系统属于同一网段时,他们只要都使用虚拟网卡即可。但是当源系统和目标系统分属于不同的网段时,则需要在路由器上进行特殊配置,使目标系统的网络也位于源系统的网络之内,这样活动分区从源系统迁移到目标系统后,该分区还可以通过网络进行访问。除此之外 HMC 上还要进行额外的 VLAN 添加操作。

举例说明,比如源系统是 dock,它位于 9.3.103 网段,目标系统是 solar,它位于 9.3.111 网段。为了使活动分区能够成功的从 dock 系统迁移到 solar 系统,且迁移后的活动分区仍然可以访问,需要为 solar 系统添加 9.3.103 这个 VLAN。这样 solar 系统也被置于 dock 系统的 VLAN 之内了。同样如果还想将活动分区从 solar 系统迁移回 dock 系统,就需要为 dock 系统添加 9.3.111 这个 VLAN。这样活动分区就可以在 dock 系统和 solar 系统之间来回迁移了。

具体的 VLAN 添加过程是:在 HMC 上选定要进行添加操作的 VIOS,依次选择 Configuration -> Manage Profile -> Virtual Adapter -> Edit Ethernet,输入要添加的 VLAN ID, 然后点击添加,如图 10 所示。当然,在 HMC 上进行 VLAN 的添加操作之前,必须首先在路由器上进行设置,以保证物理上的确可以访问这个 VLAN。



图 10. 分别为源 VIOS 和目标 VIOS 添加额外虚拟网络

当源系统或目标系统上的 VIOS 使用 HEA 网卡作为基础网络时,要将 VIOS 所使用的 HEA 网卡的物理端口设置为混杂模式,如图 11 所示。该过程不需要重启整个系统。然后将其创建成 SEA,使用虚拟网络。



图 11. 设置 HEA 网卡的物理端口为混杂模式

LPM 功能允许用户对活动分区迁移后的概要文件(Profile)进行重新命名,如图 12 所示。如果用户不指定新的名字,迁移后在目标系统上将继续使用源系统上的概要文件的名字,如果用户给出的概要文件的名字与源系统上的另一个概要文件的名字相同,则另一个概要文件将被覆盖。



图 12. 给迁移后的 Profile 重命名

在源系统上对活动分区执行的 DLPAR 操作将使它的内存、处理器、虚拟适配器或者其它某一方面发生改变,它的状态就不再与当前概要文件的描述一致。对于这种情况,活动分区在目标系统上应该尽量不要使用原来的概要文件名字,以免引起混淆。这时在迁移过程中就可利用 LPM 的概要文件重命名功能,而且新概要文件的名字要尽量反映出当前活动分区上用户最关注的特征。

下面将用一个反例说明恰当使用概要文件重命名功能的重要性。源系统 A,目标系统 B,活动分区 mlpar,mlpar 在源系统上的当前概要文件为 memory2G。在迁移前使用 DLPAR 操作为 mlpar 添加了 1GB 内存,然后对 mlpar 执行 LPM 操作将其从系统 A 迁移到系统 B,并没有重新命名概要文件。这样 mlpar 在系统 B 的当前概要文件仍为 memory2G。将 mlpar 从系统 B 迁移回系统 A 时,仍然没有对概要文件重新命名。这样虽然概要文件是 memory2G,但 mlpar 的实际内存已经是 3GB 了。此时概要文件的名称并没有真正的描述出逻辑分区的实际情况,会给用户造成错觉。


活动分区上运行的操作系统,有时候因为版本低的原因无法支持某些新型的处理器,这会限制活动分区在处理器型号不同的系统之间进行迁移的灵活性。处理器兼容模式为这种情况提供了解决的方法,而不需要升级活动分区上正在运行的操作系统。

处理器兼容模式是一个由 hypervisor 指定给逻辑分区的值,它指明了该逻辑分区正常工作时所处的处理器环境。处理器兼容模式能让目标系统提供一个目前处理器环境的子环境,使得被迁移的活动分区使用的版本较低的操作系统能够成功地在这个子环境下运行,从而实现不同处理器的系统之间的 LPM。

可以通过 HMC 设置逻辑分区的处理器兼容模式,如图 13 所示:



图 13. 设置逻辑分区的处理器兼容模式

举例说明一下处理器兼容模式在 LPM 中的应用:源系统的处理器型号为 POWER6,目标系统的处理器型号为 POWER6+,活动分区的处理器兼容模式为默认,如图 14 所示,此时这个活动分区获得的处理器环境为 POWER6。将活动分区从源系统迁移到目标系统后,它的处理器兼容模式仍为默认,且它当前获得的处理器环境实际上仍为 POWER6。但当我们在目标系统上重新激活了该活动分区后,它的处理器环境会变为 POWER6+。从这个例子中可以看到处理器兼容模式在这次 LPM 的操作中发挥的作用。但是因为处理器兼容模式的限制,该活动分区不可以迁移回来了,除非将它的处理器兼容模式修改为 POWER6,重新激活该活动分区使设置生效才能够再次进行 LPM 操作。



图 14. 不同的处理器兼容模式:POWER6+、POWER6

目标系统所支持的处理器模式可以在 HMC 上使用 lssyscfg 命令进行查看,如清单 7 所示。



hscroot@sqh10lte:~> lssyscfg -r sys -F lpar_proc_compat_modes,name
null,fsp-aurora
unavailable,9.3.111.177
"default,POWER6,POWER6+,POWER6+_enhanced",fsp-solar
"default,POWER6,POWER6+,POWER6+_enhanced",fsp-cloud
unavailable,9.3.117.242
"default,POWER6_enhanced,POWER6",fsp-tap


表 2 给出了热迁移的处理器兼容模式支持矩阵表。该表由两大部分构成,即源系统环境和目标系统环境,系统环境又由系统处理器型号、用户设定处理器兼容模式、实际处理器兼容模式三部分组成。

用户设定处理器兼容模式是指用户在 HMC 中为逻辑分区所指定的处理器兼容模式。逻辑分区实际所获得的处理器兼容模式不一定与用户设定一致。Hypervisor 为逻辑分区指定实际处理器兼容模式时主要考虑以下两方面因素:

  1. 逻辑分区上正运行的操作系统所支持的处理器能力。
  2. 用户所设定的处理器兼容模式。

当用户激活一个逻辑分区时,hypervisor 会首先查看用户设定的处理器兼容模式,然后判断逻辑分区上正运行的操作系统是否支持该模式。如果支持,则它会被指定为该处理器兼容模式。在这种情况下,逻辑分区的实际处理器兼容模式与用户设定一致。否则,hypervisor 会给逻辑分区指定最满足操作系统所支持的且最贴近于用户设定的处理器兼容模式。

从表 2 可以得出如下规律:

  1. 如果能够进行迁移,则在迁移前后,用户设定处理器兼容模式不变。
  2. 如果能够进行迁移,则在迁移前后,实际处理器兼容模式不变。
  3. 从低版本到高版本系统进行迁移时,如果操作系统支持,则重新激活逻辑分区后,将得到更多的处理器兼容模式。
  4. 不支持从高版本到低版本系统的迁移。


源系统环境 目标系统环境
源系统 迁移前设定模式 迁移前实际模式 目标系统 迁移后设定模式 迁移后实际模式
POWER6TM 缺省 POWER6 或 POWER5TM POWER6 缺省 POWER6 或 POWER5
POWER6 POWER6 POWER6 或 POWER5 POWER6 POWER6 Power6 或 POWER5
POWER6 POWER6 加强 POWER6 加强或 POWER5 POWER6 POWER6 加强 Power6 加强或 POWER5
POWER6 默认 POWER6 或 POWER5 POWER6+TM 默认 POWER6+(重新激活逻辑分区后)或 POWER6 或 POWER5
POWER6 POWER6 POWER6 或 POWER5 POWER6+ POWER6 POWER6 或 POWER5
POWER6 POWER6 加强 Power6 加强或 Power5 POWER6+ 不能迁移,因为 POWER6+ 不支持 POWER6 加强 不能迁移,因为 Power6+ 不支持 Power6 加强
POWER6+ 默认 POWER6+,POWER6,POWER5 POWER6+ 默认 POWER6+ 或 POWER6 或 POWER5
POWER6+ POWER6+ POWER6+,POWER6,
POWER5
POWER6+ POWER6+ POWER6+ 或 POWER6 或 POWER5
POWER6+ POWER6+ 加强 POWER6+ 加强或 POWER5 POWER6+ POWER6+ 加强 POWER6+ 加强或 POWER5
POWER6+ POWER6 POWER6 或 POWER5 POWER6+ POWRE6 POWER6 或 POWER5
POWER6+ 默认 POWER6+ 或 POWER6 或 POWER5 POWER6 默认 如果是 POWER6+ 则不能进行迁移,因为 POWER6 不支持 POWER6+,如果是 POWER6 或 POWER5 则迁移后也为 POWER6 或 POWER5
POWER6+ POWER6+ POWER6+ 或 POWER6 或 POWER5 POWER6 不能迁移,因为 POWER6 不支持 POWER+ 如果是 POWER6+ 则不能进行迁移,因为 POWER6 不支持 POWER6+,如果是 POWER6 或 POWER5 则迁移后也为 POWER6 或 POWER5
POWER6+ POWER6+ 加强 POWER6+ 加强或 POWER5 POWER6 不能迁移,因为 POWER6 不支持 POWER6+ 加强 如果是 POWER6+ 加强则不能迁移,因为 POWER6 不支持 POWER6+ 加强;如果是 POWER5 则迁移后也为 POWER5
POWER6+ POWER6 POWER6 或 POWER5 POWER6 POWER6 POWER6 或 POWER5


通常情况下,用户更习惯于使用 HMC 和 IVM 提供的可视化界面进行 LPM 操作,但是 LPM 也提供了命令行模式供用户使用。和可视化界面相比,命令行模式省去了和 HMC、IVM 交互带来的滞后操作,所以速度更快。在进行 LPM 的准备过程中,命令行模式会被频繁的使用,甚至可以被编写到脚本中进行环境的自动化检查。

主要的命令行为:

  1. HMC 上的 LPM 操作:

    migrlpar -o m -m 源系统 -t 目标系统 -p 活动分区 -w 等待时间

  2. IVM 上的 LPM 操作:

    migrlpar – o m – async – t 目标 IVM – id 活动分区 ID – ip 目标 IVM 的 IP -u 目标 IVM 用户名

  3. 其他命令:
    1. 验证操作:

      migrlpar – o v

    2. 恢复操作:

      migrlpar – o r

    3. 停止操作:

      migrlpar – o s


本文归纳了 LPM 的准备过程中涉及到的工作,重点介绍了 FSP、 HMC、源系统和目标系统、活动分区、存储和网络的准备过程。并结合在 LPM 测试过程中遇到的种种问题,着重介绍了 LPM 中概要文件重命名和处理器兼容模式的问题。


阅读(3548) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~