在本文中，我将分享一些在虚拟I / O（VIO）环境中构建PowerHA™集群的技巧。 我将简要描述一个简单的两节点PowerHA集群的LPAR和VIO服务器（VIOS）设计和布局。 但是，我将不涉及特定的PowerHA配置，因为该主题太大而无法在此处详细介绍。 有关详细信息，请参考IBM PowerHA官方文档（请参阅参考资料 ）。 本文还假定您具有AIX®，VIO和PowerHA的经验。
总览
本文涵盖的示例环境由两个POWER6®595服务器组成。 每个595都配置有双VIO服务器以实现冗余，并且已经在两个物理框架之间构建了两个节点的群集，即，一个PowerHA节点驻留在每个Power 595服务器上。 LPAR正在运行带有PowerHA 5.4.1.3。的AIX 5.3 TL7 SP5。 每个VIOS都在整个虚拟I / O环境中使用1.5.2.1-FP11.1版构建。 图1显示了此配置。
图1. PowerHA集群概述
在以下各节中，我将简要介绍群集节点的虚拟网络和虚拟（共享）存储配置。 我将特别强调以下方面：
- PowerHA引导和服务网络以及地址
- PowerHA网络的共享以太网适配器（SEA）配置
- 共享卷组注意事项
虚拟网络
虚拟网络配置是PowerHA配置的重要方面。 图2显示了VIOS网络的配置方式。 在此示例中，在一个595帧上。 VIOS网络配置在第二帧上重复。 （ 单击以查看大图。）
图2. VIOS网络概述
如图2所示，有PowerHA和非HA LPAR作为同一VIOS对的客户端。 您还将注意到多个SEA，即每个VLAN和一种使用类型： SEB ， BACKUP和PowerHA 。 每个VLAN都有一个唯一的IP范围： PUBLIC 10.2.2， BACKUP 10.3.3和PowerHA 10.1.1。 10.4.4网络上的每个LPAR上也都有一个接口，用于通过POWER Hypervisor虚拟网络在LPAR之间进行内部（专用）通信。
HA节点通过VLAN40（PVID40 / 41）（即PowerHA网络）与外界通信。 非HA LPAR通过PUBLIC网络通过VLAN10（PVID10）进行通信。 每个VIOS还在VLAN20上还有另一个SEA，用作网络上备份的专用VLAN，因此称为网络名称BACKUP 。
同时为PUBLIC和BACKUP网络配置了共享以太网适配器故障转移（SEA FO）。 PowerHA网络没有SEA FO。 如果针对PowerHA网络的VIA上的SEA失败，则服务IP将移至由冗余VIOS服务的另一个引导适配器。
没有任何SEA使用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），依此类推。 服务地址是没有附加adm的hostname 。
清单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故障转移以确保在VIOS发生故障时保护网络连接。 但是，在此PowerHA环境中，方法不同。 SEA FO不用于PowerHA网络。 这样，PowerHA可以知道并控制网络故障和故障转移。 在这种情况下，每个VIOS中都有一个针对PowerHA网络的SEA。 如果VIOS发生故障，服务地址将移至冗余VIOS服务的引导适配器。
此方法的主要驱动因素是PowerHA集群在虚拟网络环境中进行通信的方式。 如果配置了SEA FO且发生了故障，则HA将无法检测到故障。 同样，如果物理层上的所有通信都丢失了，则HA仍会认为网络正常，因为它仍然能够在虚拟机管理程序上通过虚拟LAN路由流量。
这就是为什么在群集中的所有节点上配置netmon.cf文件很重要的原因。
该文件指导HA如何确定何时失去与网络或其伙伴HA节点的连接。 如果未正确配置此文件，那么PowerHA可能无法检测到网络故障。
netmon.cf文件和VIO
与在VIO环境中配置netmon.cf文件有关，我建议您回顾两个APAR。 您很快就会了解此文件为何如此重要以及何时应实施。
APAR IZ01331描述了将VIO与PowerHA集群一起使用的场景以及检测网络故障时面临的挑战。 例如，如果从网络上拔出了整个CEC，则该Frame上的PowerHA节点将不会检测到本地适配器关闭事件，因为在VIO客户端之间（在同一框架上）传递的流量看起来像来自该VEC客户端的正常外部流量。 LPAR操作系统的视角 。”
为了解决此问题，netmon.cf文件用于允许客户声明给定的适配器仅在可以ping通一组指定目标的情况下才应考虑使用。
如果VIOS在同一网络上具有多个物理接口，或者在同一帧中有两个或多个使用一个或多个VIOS的PowerHA节点，则不会通知PowerHA（因此不会对单个物理接口故障做出React）。
在极端情况下，由VIO服务器管理的所有物理接口均发生故障，VIOS将继续在同一帧中将流量从一个LPAR路由到另一个LPAR，PowerHA使用的虚拟以太网接口不会被报告为发生故障，而PowerHA将不React。
群集中的每个节点都有一个自定义的netmon.cf文件，该文件列出了它必须能够ping通以将接口标记为向上或向下的所有IP地址。 例如， aix01adm驻留在框架1（595-1）上，而aix02adm驻留在框架2（595-2）上。 如果595-1上所有VIOS上所有物理接口的所有网络连接丢失，则aix01adm仍将继续运行，因为它仍能够通过虚拟网络路由数据包。 为了使该节点（和其他节点）能够检测到问题，请在netmon.cf文件中填充它应该能够在特定接口上访问的地址。 如果不能，则将这些接口标记为已关闭，并且PowerHA能够做出相应的React。
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显示了来自两个节点的两个不同物理帧上的一些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标记指定适配器（aix01b1v1）可以对目标（aix02b1v3）进行ping操作。 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 1en2将用于连接到aix02b1v3，这是其595-2上其伙伴节点上的接口。 如果无法通信，则接口en2（aix01b1v1）将被标记为关闭。 不要在此文件中包含同一框架上存在的任何节点。 所有条目都应针对驻留在物理框架之外的系统，以确保检测到物理（非虚拟）网络上外界发生的实际物理网络故障。
注意不要在netmon.cf文件中指定接口名称，例如：
!REQD en2 10.1.1.10 包括接口名称在VIO环境中不起作用。 我上次检查时，HA开发团队加入了设计变更请求（DCR），以解决此问题。 由于RSCT（netmon）确定netmon.cf中的第二个字段是IP /主机名还是接口名称，某些客户的接管速度很慢。 在某些情况下，netmon将尝试解析主机名的IP地址，例如$ host en2 ，它将失败。 IBM开发人员正在研究一种新的算法，以防止接口名称被视为主机名，特别是对于诸如enX之类的明显格式。 现在，最好在netmon.cf文件中取消使用接口名称，例如en X。
建议仅在您的VIO环境中使用netmon.cf方法。 使用此方法可以从“我可以接收任何网络流量吗？”来更改所谓的良好适配器的定义。 到“我可以成功ping通某些地址吗？（无论我能看到多少流量）”。
这会使适配器更容易被错误地认为是宕机。 如果必须使用此新功能，建议您为需要监视的每个接口包含尽可能多的目标。
虚拟（共享）存储
有关PowerHA和虚拟SCSI（VSCSI）的IBM技术文档明确定义了VIO环境中受支持的存储配置。 共享卷组（VG）必须定义为“增强的并发模式”。 通常，增强型并发模式是在PowerHA集群中共享卷组的推荐模式。 在这种模式下，多个PowerHA节点可以访问共享的卷组，从而在发生节点故障时可以更快地进行故障转移（磁盘接管）。 这些共享磁盘上的所有卷组管理都是通过PowerHA节点而不是VIOS完成的。
在示例环境中，在主节点上运行lspv确认共享卷组处于并发模式。
清单7.在主节点上运行lspv
root@aix01adm / # lspv
hdisk0 00c79a70a6858137 rootvg
hdisk1 00c79a70a20c321c sapvg concurrent 图3显示每个节点上有两个卷组。 每个节点都有自己的（非共享的）根卷组（ rootvg ）。
图3. VIOS VSCSI概述
主节点拥有共享卷组并处于激活状态，因此拥有所有权。 我可以通过在主服务器上运行lsvg命令并注意其某些特征来确认这一点。 VG STATE处于活动状态， VG Mode为并发， Concurrent设置为增强型功能，并且VG PERMISSION处于读/写状态。 共享卷组中的逻辑卷处于打开状态。
清单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设置为“仅被动”。 共享卷组中的逻辑卷已关闭。
清单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。
清单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请参阅IBM技术文档和PowerHA文档，以获取有关PowerHA和虚拟存储支持的更多信息。
摘要
这只是这种配置的一种方法。 我希望这些简短的提示为您提供一些有关如何在VIO环境中使用PowerHA的想法。
翻译自: https://www.ibm.com/developerworks/aix/library/au-powerha/index.html
1434
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
