关于在虚拟 I/O 环境中实现 PowerHA 的提示

在本文中,对于在虚拟 I/O 环境中实现 PowerHA 给出一些提示。了解一个简单的两节点 PowerHA 集群的设计和布局,理解虚拟网络配置为什么是 PowerHA 配置的重要方面。

Chris Gibson, AIX 专家, Australia Post

Chris Gibson 是一位 AIX 系统专家,居住在澳大利亚墨尔本市。他是 IBM CATE(System p 平台和 AIX 5L),同时也是 IBM Redbook “NIM from A to Z in AIX 5L” 的作者之一。


developerWorks 投稿作者

2010 年 4 月 22 日

简介

在本文中,我要提出我对在虚拟 I/O (VIO) 环境中构建 PowerHA™ 集群的一些建议。我将简要介绍一个简单的两节点 PowerHA 集群的 LPAR 和 VIO server (VIOS) 设计和布局。但是,并不讨论具体的 PowerHA 配置,因为这个主题太大了,无法在这里详细讨论。深入的信息请参考官方 IBM PowerHA 文档(见 参考资料)。本文还假设您有使用 AIX®、VIO 和 PowerHA 的经验。


概况

本文讨论的示例环境由两台 POWER6® 595 服务器组成。为了实现冗余,每台 595 配置两个 VIO 服务器,跨两个物理 frame 构建了一个两节点集群,即每台 Power 595 服务器上有一个 PowerHA 节点。LPAR 运行 AIX 5.3 TL7 SP5 和 PowerHA 5.4.1.3。跨虚拟 I/O 环境用 1.5.2.1-FP11.1 版构建每个 VIOS。图 1 给出这个配置。

图 1. PowerHA 集群概况
显示两台 595 服务器以及 vios、RAM 和 LPAR 信息

在下面几节中,简要讨论集群节点的虚拟网络和虚拟(共享)存储配置。主要讨论以下方面:

  • PowerHA 引导与服务网络和地址
  • PowerHA 网络的 Shared Ethernet Adapter (SEA) 配置
  • 共享卷组的考虑事项

虚拟网络

虚拟网络配置是 PowerHA 配置的重要方面。图 2 说明如何配置 VIOS 网络;在这个示例中,在一台 595 frame 上进行配置,然后在另一台 frame 上复制 VIOS 网络配置。(单击 查看大图。)

图 2. VIOS 网络概况
595-1 VIOS 网络

如图 2 所示,同一 VIOS 对的客户机包括 PowerHA 和非 HA LPAR。您还会注意到有多个 SEA,即每个 VLAN 和使用类型有一个:PUBLICBACKUPPowerHA。每个 VLAN 有惟一的 IP 范围:PUBLIC 10.2.2、BACKUP 10.3.3 和 PowerHA 10.1.1。在 10.4.4 网络上,每个 LPAR 上还有一个接口,这个网络用于 LPAR 之间通过 POWER Hypervisor 虚拟网络进行内部(私有)通信。

HA 节点通过 VLAN40 (PVID40/41)(这是 PowerHA 网络)与外部通信。非 HA LPAR 通过 VLAN10 (PVID10) 和 PUBLIC 网络通信。每个 VIOS 在 VLAN20 上还有另一个 SEA,这是用于网络备份的复制 VLAN,因此这个网络名为 BACKUP

为 PUBLIC 和 BACKUP 网络配置了 Shared Ethernet Adapter Fail Over (SEA FO)。PowerHA 网络没有 SEA FO。如果 VIOS 上用于 PowerHA 网络的 SEA 发生故障,那么服务 IP 会转移到由冗余 VIOS 提供的另一个引导适配器。

对于任何 SEA 都没有使用 VLAN 标签。因为这个网络中只有几个 VLAN,所以不需要 VLAN 标签。但是,您的需求可能不一样。

cltopinfo 命令查看 PowerHA 集群网络,可以看到每个节点的网络定义如下:

清单 1. 网络定义
# cltopinfo
Cluster Name: CLUSTER-A
Cluster Connection Authentication Mode: Standard
Cluster Message Authentication Mode: None
Cluster Message Encryption: None
Use Persistent Labels for Communication: No
There are 2 node(s) and 3 network(s) defined

NODE aix01adm:
        Network net_diskhb_01
                aix01adm_hdisk1_01    /dev/hdisk1
        Network net_ether_01
                aix01adm		10.2.2.8
        Network net_ether_02aix01			10.1.1.12
                aix01b2v1		10.1.1.76
                aix01b1v2		10.1.1.140

NODE aix02adm:
        Network net_diskhb_01
                aix02adm_hdisk1_01    /dev/hdisk1
        Network net_ether_01
                aix02adm		10.2.2.15
        Network net_ether_02
                aix01			10.1.1.12
                aix02b1v3		10.1.1.77
                aix02b2v4		10.1.1.141

Resource Group HARG1
        Startup Policy		Online On Home Node Only
        Fallover Policy	Fallover To Next Priority Node In The List
        Fallback Policy	Never Fallback
        Participating Nodes	aix01adm aix02adm
        Service IP Label	aix01

可以看到服务和引导适配器都在同一个子网化(分段)IP 网络中,其中的 b1v1 定义与第一个 VIOS (v1) 相关联的第一个引导适配器 (b1),以此类推。服务地址是 hostname,后面不附加 adm

清单 2. 服务和引导适配器
Service address:	aix01		10.1.1.12	
							Netmask 255.255.255.192 
							IP range 10.1.1.1 - 62

boot1 address:		aix01b1v1		10.1.1.76	
							Netmask 255.255.255.192
							IP range 10.1.1.65 - 126

boot2 address:		aix01b2v2		10.1.1.140	
							Netmask 255.255.255.192
							IP range 10.1.1.129 - 190

boot1 address:		aix02b1v3		10.1.1.77	
							Netmask 255.255.255.192
							IP range 10.1.1.65 - 126

boot2 address:		aix02b2v4		10.1.1.141
							Netmask 255.255.255.192
							IP range 10.1.1.129 - 190

通常,在 VIOS 上配置 SEA 时,会部署 SEA Fail Over 以便在发生 VIOS 故障时保护网络连接。但是,在这个 PowerHA 环境中,采用的方法不同。PowerHA 网络不使用 SEA FO。这样,由 PowerHA 感知网络故障并控制故障转移。在这个环境中,在每个 VIOS 上有一个用于 PowerHA 网络的 SEA。如果一个 VIOS 发生故障,服务地址会转移到由冗余 VIOS 提供的引导适配器。

采用这种方式主要是由于 PowerHA 集群在虚拟网络环境中的通信方式。如果配置 SEA FO 并发生了故障,HA 就无法探测到故障。同样,如果物理层的所有通信中断了,HA 仍然会认为网络是正常的,因为它仍然能够通过 Hypervisor 上的虚拟 LAN 路由通信流。

由于这个原因,在集群中的所有节点上配置 netmon.cf 文件是很重要的。

这个文件告诉 HA 如何判断它与网络或其伙伴 HA 节点的连接是否中断了。如果没有适当地配置这个文件,PowerHA 就无法探测到网络故障。

netmon.cf 文件和 VIO

在 VIO 环境中配置 netmon.cf 文件时,建议参考两个 APAR。您很快就会理解这个文件为什么很重要以及什么时候应该实现它。

APAR IZ01331 描述在 PowerHA 集群中使用 VIO 的场景以及在探测网络故障方面面对的困难。例如,如果 “从网络上拔掉整个 CEC,frame 上的 PowerHA 节点不会探测到本地适配器关闭事件,因为从 LPAR 的 OS 的角度来看,(同一 frame 上)VIO 客户机之间的通信流与正常的外部通信流一样。”

为了解决这个问题,客户可以使用 netmon.cf 文件声明:指定的适配器只有在能够 ping 通一组指定目标的情况下 才认为是打开的。

如果 VIOS 有同一网络上的多个物理接口,或者有两个或更多 PowerHA 节点使用同一 frame 中的一个或更多 VIOS,PowerHA 就不会收到物理接口故障的通知(因此不会做出反应)。

如果出现由 VIO Server 管理的所有物理接口都发生故障的极端情况,VIOS 会继续在同一 frame 中的 LPAR 之间路由通信流,PowerHA 使用的虚拟以太网接口不会报告故障,PowerHA 不会做出反应。

集群中的每个节点有一个定制的 netmon.cf 文件,其中列出一些 IP 地址,为了判断一个接口是打开的 还是关闭的,它必须能够 ping 通这些地址。例如,aix01adm 驻留在 Frame 1 (595-1) 上,aix02adm 驻留在 Frame 2 (595-2) 上。如果 595-1 上所有 VIOS 的所有物理接口的所有网络连接都中断了,那么 aix01adm 仍然会继续工作,因为它仍然能够通过虚拟网络路由数据包。要想让这个节点(和其他节点)探测到问题,应该在 netmon.cf 文件中指定在特定接口上它应该能够到达的地址。如果它 ping 不通这些地址,就把这些接口标为关闭的,PowerHA 能够做出相应的反应。

APAR IZ01874 解释如何为 netmon.cf 文件选择 IP 地址。这个文件应该包含这样的远程 IP 地址和主机名:它们不包含在集群配置中,但可以通过 PowerHA 网络接口访问。这些地址前面必须加上 !REQD

比较合适的目标包括名称服务器(DNS 服务器)和网关(路由器),或者会响应 ping 操作的可靠的外部 IP 地址(比如 NTP 服务器)。可以使用下面的 ping 命令检查 ping 在特定的接口上是否会得到响应:

# ping -S <Boot IP address> <IP addr in netmon.cf>

其中的 <Boot IP address> 是在引导接口上配置的 IP 地址。例如:

清单 4. 特定的接口上 ping 命令的响应
# ping -c5 -S aix01b1v1 aix02b1v3
PING bxaix04b1v1: (10.1.1.77): 56 data bytes
64 bytes from 10.1.1.77: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=1 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=2 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=3 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=4 ttl=255 time=0 ms

----aix02b1v3 PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms

清单 5 给出来自两个物理 frame 上两个节点的 netmon.cf 示例。

清单 5. netmon.cf 示例
HOST: aix01adm 595-1
--------------------
# Care is required when modifying this file!
# The nature of the VIO/PowerHA environment means the contents
# of netmon.cf on each cluster node is different.
# IP labels/addresses on virtual interfaces in any VIO client LPAR
# within this server frame, must be excluded from this file!
!REQD aix01b1v1 10.2.2.1
!REQD aix01b2v2 10.2.2.1
!REQD aix01b1v1 10.1.1.1
!REQD aix01b2v2 10.1.1.1
!REQD aix01b1v2 10.1.1.77
!REQD aix01b2v2 10.1.1.141
!REQD aix01b1v1 aix02b1v3
!REQD aix01b2v2 aix02b2v4
!REQD aix01b1v1 10.1.9.2
!REQD aix01b2v2 10.1.9.3
10.2.2.1
10.1.9.2
10.1.9.3
ntp-srvr
ntp-srvr

HOST: aix02adm 595-2
--------------------
# Care is required when modifying this file!
# The nature of the VIO/PowerHA environment means the contents
# of netmon.cf on each cluster node is different.
# IP labels/addresses on virtual interfaces in any VIO client LPAR
# within this server frame, must be excluded from this file!
!REQD aix02b1v3 10.2.2.1
!REQD aix02b2v4 10.2.2.1
!REQD aix02b1v3 10.1.1.1
!REQD aix02b2v4 10.1.1.1
!REQD aix02b1v3 10.1.1.76
!REQD aix02b2v4 10.1.1.140
!REQD aix02b1v3 aix01b1v1
!REQD aix02b2v4 aix01b2v2
!REQD aix02b1v3 10.1.9.2
!REQD aix02b2v4 10.1.9.3
10.2.2.1
10.1.9.2
10.1.9.3
ntp-srvr
ntp-srvr

以下面这行为例

!REQD aix01b1v1 aix02b1v3

!REQD 标记指出,只有在可以 ping 通目标 (aix02b1v3) 的情况下,才认为这个适配器 (aix01b1v1) 是打开的。aix01b1v1 指定测试使用哪个接口,aix01b1v1 解析为 10.1.1.76,这是 en2 接口上的地址。如果可以 ping 通目标 aix02b1v3,就认为这个接口是打开的。

清单 6. 判断适配器主机名
# host aix01b1v1
aix01b1v1 is 10.1.1.76

# ifconfig en2
en2: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,
GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
        inet 10.1.1.76 netmask 0xffffffc0 broadcast 10.1.1.127
        inet 10.1.1.12 netmask 0xffffffc0 broadcast 10.1.1.63
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

使用 en2 连接 aix02b1v3,这是 595-2 上它的伙伴节点上的接口。如果无法通信,接口 en2 (aix01b1v1) 就被标为关闭的。不要在这个文件中包含同一 frame 上的任何节点。所有条目都应该针对驻留在这个物理 frame 之外的系统,以便探测外边的物理网络(而不是虚拟网络)上真正的物理网络故障。

注意,在 netmon.cf 文件中不要指定接口名,比如:

!REQD en2 10.1.1.10

在 VIO 环境中包含接口名是无效的。我上次检查时,有一个 Design Change Request (DCR) 请求 HA 开发团队解决这个问题。一些客户遇到了接管过程缓慢的问题,这是由 RSCT (netmon) 判断 netmon.cf 中的第二个字段是 IP/主机名还是接口名的方式造成的。在某些情况下,netmon 会尝试解析主机名的 IP 地址,例如 $ host en2,这时解析会失败。IBM 开发人员正在开发一种新算法,以避免把接口名当作主机名对待,尤其是对于 enX 等明显的格式。目前,最好不要在 netmon.cf 文件中使用接口名,例如 enX

如果 netmon.cf 方法在您的 VIO 环境中是合适的,建议只使用这种方法。通过使用这种方法,判断所谓的 “好适配器” 的标准不再是 “是否能够接收到任何网络通信流?”,而是 “是否可以成功地 ping 通某些地址?(无论可以看到的通信流有多大)”。

这可能导致适配器被误以为关闭了。如果必须使用这个新功能,建议为需要监视的每个接口指定尽可能多的目标。


虚拟(共享)存储

关于 PowerHA 和 Virtual SCSI (VSCSI) 的 IBM 技术文档明确地定义了在 VIO 环境中支持的存储配置。共享的卷组 (VG) 必须定义为 “Enhanced Concurrent Mode”。在一般情况下,对于 PowerHA 集群中的共享卷组,推荐使用 Enhanced Concurrent Mode 模式。在这种模式下,多个 PowerHA 节点都可以访问共享卷组,这会加快发生节点故障时的故障转移(磁盘接管)。对这些共享磁盘的所有卷组管理操作都应该通过 PowerHA 节点执行,而不应该通过 VIOS。

在示例环境中,在主节点上运行 lspv 以确认共享卷组处于并发模式。

清单 7. 在主节点上运行 lspv
root@aix01adm / # lspv
hdisk0  00c79a70a6858137          rootvg
hdisk1  00c79a70a20c321c          sapvg           concurrent

图 3 显示每个节点上有两个卷组。每个节点有自己的(非共享)根卷组 (rootvg)。

图 3. VIOS VSCSI 概况
显示两个服务器,每个节点上有两个卷组

主节点在启动并处于活跃状态时拥有共享卷组。通过在主节点上运行 lsvg 命令并观察它的一些属性可以确认这一点。VG STATE 是 active,VG Mode 是 Concurrent,Concurrent 设置为 Enhanced-Capable,VG PERMISSION 是 read/write。共享卷组中的逻辑卷是打开的。

清单 8. 在主节点上运行 lsvg

点击查看代码清单

清单 8. 在主节点上运行 lsvg

root@aix01adm / # lsvg sapvg
VOLUME GROUP:       sapvg           VG IDENTIFIER:  00c79a6000004c0000000123a2278720VG STATE:           active            PP SIZE:        64 megabyte(s)
VG PERMISSION:      read/write               TOTAL PPs:      6398 (409472 megabytes)
MAX LVs:            256                      FREE PPs:       1596 (102144 megabytes)
LVs:                13                       USED PPs:       4802 (307328 megabytes)
OPEN LVs:           13                       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:     32512
MAX PPs per PV:     4064                     MAX PVs:        8
LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable

root@aix01adm / # lsvg -l sapvg
sapvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
oraclelv            jfs2       192     192     1    open/syncd    /oracle
sapmnt_CG1lv        jfs2       144     144     1    open/syncd    /sapmnt
usrsap_CG1lv        jfs2       144     144     1    open/syncd    /usr/sap
oraclestagelv       jfs2       128     128     1    open/syncd    /oracle/stage
sapreorg_CG1lv      jfs2       64      64      1    open/syncd    /oracle/CG1/sapreorg
sapbackup_CG1lv     jfs2       16      16      1    open/syncd    /oracle/CG1/sapbackup
mirrlogA_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/mirrlogA
mirrlogB_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/mirrlogB
origlogA_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/origlogA
origlogB_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/origlogB
sapdata1_CG1lv      jfs2       1600    1600    1    open/syncd    /oracle/CG1/sapdata1
oraarch_CG1lv       jfs2       80      80      1    open/syncd    /oracle/CG1/oraarch
loglv01             jfs2log    1       1       1    open/syncd    N/A

在执行故障转移之前,备用节点上的文件系统没有挂载,所以不可能意外地使用备用节点上的数据。在备用节点上,可以访问共享的增强型并发卷组,但是只能采用被动只读模式。VG PERMISSION 设置为 passive-only。共享卷组中的逻辑卷是关闭的。

清单 9. 备用节点
root@aix02adm / # lsvg sapvg
VOLUME GROUP:       sapvg              VG IDENTIFIER:  00c79a6000004c0000000123a2278720
VG STATE:           active             PP SIZE:        64 megabyte(s)
VG PERMISSION:      passive-only       TOTAL PPs:      6398 (409472 megabytes)
MAX LVs:            256                      FREE PPs:       1596 (102144 megabytes)
LVs:                13                       USED PPs:       4802 (307328 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:            1                        Active Nodes:       2
MAX PPs per VG:     32512
MAX PPs per PV:     4064                     MAX PVs:        8
LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable

root@aix02adm / # lsvg -l sapvg
sapvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
oraclelv            jfs2       192     192     1    closed/syncd  /oracle
sapmnt_CG1lv        jfs2       144     144     1    closed/syncd  /sapmnt
usrsap_CG1lv        jfs2       144     144     1    closed/syncd  /usr/sap
oraclestagelv       jfs2       128     128     1    closed/syncd  /oracle/stage
sapreorg_CG1lv      jfs2       64      64      1    closed/syncd  /oracle/CG1/sapreorg
sapbackup_CG1lv     jfs2       16      16      1    closed/syncd  /oracle/CG1/sapbackup
mirrlogA_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/mirrlogA
mirrlogB_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/mirrlogB
origlogA_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/origlogA
origlogB_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/origlogB
sapdata1_CG1lv      jfs2       1600    1600    1    closed/syncd  /oracle/CG1/sapdata1
oraarch_CG1lv       jfs2       80      80      1    closed/syncd  /oracle/CG1/oraarch
loglv01             jfs2log    1       1       1    closed/syncd  N/A

为了支持增强型并发卷组,必须(在集群中的所有节点上)安装 bos.clvm.enh 文件集。增强型并发卷组引入了一个新的子系统 (gsclvmd)。可以通过查询这个子系统查明活跃的增强型并发卷组。

清单 10. 查询 gsclvmd 子系统
# lssrc -s gsclvmd
Subsystem         Group            PID          Status
 gsclvmd                           327756       active

# ps -fp 462906
UID     PID    PPID   C    STIME    TTY TIME CMD
root  462906  327756   0   Nov 04   -   0:02 /usr/sbin/gsclvmd -r 30 -i 300 -t 300 -c 
00c79a6000004c0000000123a2278720 -v 0

# lssrc -ls gsclvmd
 Subsystem       Group           PID     Status
 gsclvmd         gsclvmd        327756  active

 Active VGs # 1
 vgid                                   pid
 00c79a6000004c0000000123a2278720       462906

可以使用 CSPOC 为共享卷组启用增强型并发模式(Fast Disk Takeover)。

清单 11. 启用增强型并发模式
# smit cl_vg
                                                                    Shared Volume Groups

Move cursor to desired item and press Enter.

  List All Shared Volume Groups
  Create a Shared Volume Group
  Create a Shared Volume Group with Data Path Devices
  Enable a Shared Volume Group for Fast Disk Takeover
  Set Characteristics of a Shared Volume Group
  Import a Shared Volume Group
  Mirror a Shared Volume Group
  Unmirror a Shared Volume Group

关于 PowerHA 和虚拟存储支持的更多信息,请参见 IBM 技术文档和 PowerHA 文档。


结束语

这只是实现这种配置的方法之一。我希望这些简短的提示有助于您了解如何在 VIO 环境中实现 PowerHA。

参考资料

学习

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=AIX and UNIX
ArticleID=484743
ArticleTitle=关于在虚拟 I/O 环境中实现 PowerHA 的提示
publish-date=04222010