HACMP7配置.doc

《HACMP7配置.doc》由会员分享，可在线阅读，更多相关《HACMP7配置.doc（13页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、+PowerVM 环境下实施 PowerHA7.1 要点本文主要介绍 PowerVM 环境下实施 PowerHA 的一些要点，包括 PowerHA 对虚拟网络监控、光纤心跳在虚拟化环境下的实施等。需要注意的是，本文测试所得到的数据是试验中的测试数据，非 IBM 公司官方数据。0 评论： 魏 新宇, 高级 IT 专家, IBM China2013 年 9 月 26 日 内容前言随着 PowerVM 使用的越来越多，在虚拟化环境下实施 PowerHA 的案例会越来越多。传统 PowerHA6.1 在物理分区下实施是比较经典的配置，PowerHA7.1 为了适应 PowerVM，在开发的时候进行了相

2、关考虑，主要包含三点：PowerHA7.1 中允许 1 个 HA 节点只有 1 个网卡、1 个 BootIP 和一个 ServiceIP，并且 ServieIP 可以和 BootIP 在相同网段；netmon.cf 的功能在虚拟化环境中能够成功实施，解决了 PowerHA 监控虚拟网卡状态的问题；FC 心跳在虚拟环境下能够成功实施。本文讲主要介绍虚拟化环境下实施的相关要点。回页首PowerHA7.1 对虚拟网络的监控netmon.cf 的配置在 传统的 HA 环境下，PowerHA 可以通过监控物理网卡的状态来进行网络监控。而虚拟化环境下，VIOC 中虚拟网卡永远不会处于 down 或者 de

3、tach 的状态（除非人为操作），带来的结果是可能 VIOC 已经无法对外通信，但是由于其虚拟网卡状态仍然是 up 的状态，HA 不会识别网络故障，资源组也不会发生切换，结果就是业务中断，也就是“该它干的活它没干”，HA 失去了其本来的意义。因此，在 PowerVM 环境下实施 PowerHA7.1 的时候，就必须要引入 netmon.cf 的配置。在 netmon.cf 中，我们通过设备 HA 本地网卡 ping 目标地址的方法，来判断虚拟网卡通讯是否正常。针对 netmon.cf 文件的配置。在 PowerHA7.1 中推荐的格式是：# cat /usr/es/sbin/cluster/n

4、etmon.cf!REQD 172.16.25.175 172.16.24.82其中：172.16.25.175 是 HA 节点的 bootIP，172.16.24.82 是目标 IP。在这个配置文件中，通常建议写入多个 IP 地址（这个文件最多写 32 行），这样增加本机将会在 ping 不通第一个 IP 的时候，尝试 ping 第二个，直到配置文件中的所有 IP 地址都 ping 不通。这样做的好处是避免由于网络不稳定造成资源组错误切换。不同的 HA 节点的配置文件中，目标 IP 可以不同。netmon.cf 能够检测到虚拟网络问题并且触发资源组切换的条件是：1. 配置 netmon.cf

5、 的分区的 IP 地址 ping 不通 netmon.cf 中配置的目标地址。2. HA 节点之间的网络多播心跳不通。netmon.cf 的功能验证我们以一个双节点的 PowerHA7.1 作为实验环境。实验环境中有两个物理服务器，每个物理服务器上有一个 VIOS，一个 VIOC，两个 VIOC 之间配置了 PowerHA，并且在两个 HA 节点上都配置了 netmon.cf。查看配置文件内容：# cat /usr/es/sbin/cluster/netmon.cf!REQD 172.16.25.175 172.16.24.82查看资源组状态，资源组 rg1 运行在 HA1 上，浮动 IP 1

6、72.16.25.178 处于 up 状态。# clRGinfo-Group Name State Node -rg1 ONLINE node1 OFFLINE node2 # netstat -inName Mtu Network Address Ipkts Ierrs Opkts Oerrs Collen0 1500 link#2 ce.2.cc.e.30.a 181132 0 14699 0 0en0 1500 172.16.25 172.16.25.178 181132 0 14699 0 0en0 1500 172.16.25 172.16.25.175 181132 0 14699

7、 0 0lo0 16896 link#1 16237 0 16237 0 0lo0 16896 127 127.0.0.1 16237 0 16237 0 0lo0 16896 :1%1 16237 0 16237 0 0初始情况下，HA1 节点可以 ping 通 netmon.cf 中的目标地址（172.16.24.82），目标地址与源地址互发网络包正常。# tcpdump host 172.16.24.82tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on en0, l

8、ink-type 1, capture size 96 bytes21:33:18.669852 IP node1 172.16.24.82: ICMP echo request, id 488, seq 587, length 4321:33:18.670058 IP 172.16.24.82 node1: ICMP echo reply, id 488, seq 587, length 43接下来，让 HA1 节点与目标地址无法通讯（可以通过删除路由、将目标地址网卡 down 掉或者将目标分区 down 等方法），即 HA1 节点 ping 不通 172.16.24.82 地址时，HA1

9、节点依然会正常工作，资源组不会发生切换。从下面的输出信息中，可以看到 HA1 与目标地址交互不正常。#tcpdump host 172.16.24.82tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on en0, link-type 1, capture size 96 bytes21:00:59.785591 ARP, Request who-has 172.16.24.82 tell 172.16.24.1, length 4621:01:01.071314 IP no

10、de1 172.16.24.82: ICMP echo request, id 488, seq 184, length 4321:01:01.426657 IP node1 172.16.24.82: ICMP echo request, id 488, seq 184, length 4321:01:01.782209 IP node1 172.16.24.82: ICMP echo request, id 488, seq 184, length 43在 这个时候，可能我们会理所当然地认为本机网卡将会标示出故障。其实不然，这个时候，在 PowerHA 的日志 hacmp.out 和 Po

11、werHA 命令 lscluster -m 的输出信息中，不会有任何报错,网络是正常的。资源组也不会发生切换。因为 HA1 节点 HA2 节点发送多播信息是可以成功的。将为 HA1 节点提供网络服务的 VIOS 上的 SEA 删掉（或者拔掉 VIOS 的网线）。通过 console 登陆 HA1，发现 hacmp.out 中会有网络报错：Mar 13 21:19:34 EVENT COMPLETED: network_down_complete node1 net_ether_01 0 需要注意的是，HA 识别网络错误分为 0 和-1 两种。0 标示 local 网络故障，会引起资源组切换。-

12、1 是全局网络故障，不会引发资源组切换此时，通过 PowerHA 命令行查看网络状态：lscluster -m 中网卡状态为 down:#lscluster -m Points of contact for node: 2 - Interface State Protocol Status - dpcom DOWN none RESTRICTED en0 DOWN IPv4 none此时，如果资源组中包含浮动 IP 资源资源，将会引发资源组切换。HACMP Event Preamble-Enqueued rg_move release event for resource group rg1.

13、Reason for recovery of Primary instance of Resource group rg1 from TEMP_ERROR state on node node1 was Local network failure.查看 PowerHA 的日志 hacmp.out,可以看到过了大约不到 30 秒，资源组在 HA2 节点启动成功：.Mar 13 21:51:00 EVENT COMPLETED: resource_state_change_complete node1 0# clRGinfo-Group Name State Node -rg1 OFFLINE n

14、ode1 ONLINE node2检测 HA 节点间 Mutil-cast 通讯的方法以双节点 HA 为例，HA 的多播地址为 228.16.25.175，HA 两个节点的名字分别为:node1 和 node2.HA 节点间多播协议通讯正常的表现如下：On HA node1：从 node1 向多播 IP 发包：在 node2 上，从多播地址获取包，显示可以获取到。On HA node2:如果 HA 节点 node2 上 mping 是没有输出，则说明节点之间的多播通讯 mutil-cast 有问题。需要在交换机上进行配置，打通 Mutil-Cast 协议。回页首FC 心跳在 PowerVM 中

15、的实施FC 心跳的概念PowerHA7.1 中心跳分为三类：以太网络 Mutil-Cast 心跳、FC 心跳和 Repository disk 心跳。为了使 HA 更加稳定，有效预防脑裂，通常建议客户在实施的时候配置 FC 心跳。当 IP 心跳或者 SAN 心跳正常时，Repository Disk 处于 UP RESTRICTED AIXCONTROLLED 状态，只是作为 Standby，不进行心跳数据的传输。当 IP 心跳或者 SAN 心跳均不可用时，Repository Disk 处于 UP AIX_CONTROLLED 状态，传输心跳消息。在 PowerVM 环境下，VIOC 一般使

16、用虚拟 HBA 卡，而不配置物理 HBA 卡。在这种情况下，FC 心跳如何实施？下面是实施的要点：1. 首先需要将两个 VIOS 上的一个物理光纤卡端口接在一个光纤交换机上，然后配置一个 ZONE，将两个 FC Port 划分在内。需要在 VIOS 和 VIOC 中新建一个虚拟网卡（或者给 VIOS 的 SEA 增加一个 3358 的 VLAN tag 也可以），VLAN ID 设置 3358 即可。不需要物理交换机与 SEA 的接口打 3358 的 VLAN ID，VIOC 和 VIOS 上的 3358 的虚拟网卡上也不能配置 IP 地址。2.划 ZONE 的时候，只需要对两个/多个 VIO

17、S 上的物理光纤卡划 zone。在 VIOC 上，虚拟光纤卡不是必须的（由于生产环境下多使用 NPIV，所以在 VIOC 下都会有 vfc 设备），在 VIOC 没有 vfc 卡的情况下，vfc 心跳可以通过 vscsi client 实现。3.虚拟光纤卡心跳的实现，是通过 VIOS 与 VIOC 之间的 sfwcomm 设备实现的，也就是 VLAN 3358 对应的设备名称。4.如果 VIOS 上有单独可用于 FC 心跳的物理光纤口，那么可以单独给这两个 WWPN 划 zone。如果资源紧张，那么使用存储映射的光纤卡也可以，但是最好将两个 WWPN 单独配置在一个新的 zone 里（由于存储

18、映射已经有了一个 zone 把两个 WWPN 划分在了一起，不增加新的 zone 也能实现功能，但是为了避免存储的干扰，单独增加一个 ZONE 效果会更好。）。PowerVM 中 FC 心跳的实施步骤1.在配置 fc 心跳之前，在 HA 节点（VIOC）进行查看：# lscluster -i sfwcomInterface sfwcom not found 提示没有 sfwcom 设备。图 1.虚拟环境下 FC 心跳的架构图2.在 VIOS 中调整物理光纤卡的参数：chdev -P -l fcs0 -a tme=yeschdev -P -l fscsi0 -a dyntrk=yes -a fc

19、_err_recov=fast_fail需要注意的是，由于 HBA 卡下挂有设备，因此直接修改 HBA 卡的参数是不能成功的，这就需要增加-P 参数，先行修改 ODM 库中的配置信息。配置成功后，重启才能生效。3.创建 VLAN在 VIOS 的 SEA 上增加 3358 的 VLAN(或者直接在 VIOS 中 DLPAR 增加一个 PVID 为 3358 的虚拟网卡，然后保存修改到分区 profile 中)：图 2 VIOS 增加 SEA 的 VLAN tag如 果是在 SEA 上增加 3358 的 VLAN，那么创建完毕以后，需要 de-active 和 re-active VIOS。如果是

20、 DLPAR 一个新的 PVID 为 3358 的虚拟网卡，那么就不需要 de-active 和 re-active VIOS。在 VIOC 上，用 DLPAR 增加一个新的虚拟网卡（然后在 HMC 上 save configuration），指向 VIOS 上的 3358 VLAN：图 3 查看虚拟网卡图 4 查看虚拟网卡在 VIOC 上 cfgmgr 重新扫描设备信息。然后在 HA 节点上（vioc）查看， sfwcom 已经可见。# lscluster -i sfwcomNetwork/Storage Interface QueryCluster Name: wxyclusterClus

21、ter UUID: 397cd38e-8bdc-11e2-844a-ce02cc0e300aNumber of nodes reporting = 1Number of nodes stale = 0Number of nodes expected = 1Node node1Node UUID = 398263b2-8bdc-11e2-844a-ce02cc0e300aNumber of interfaces discovered = 1 Interface number 1, sfwcom IFNET type = 0 (none) NDD type = 304 (NDD_SANCOMM)

22、Smoothed RTT across interface = 0 Mean deviation in network RTT across interface = 0 Probe interval for interface = 100 ms IFNET flags for interface = 0x00000000 NDD flags for interface = 0x00000009 Interface state = UP# lsdev -C|grep sfwsfw0 Available Storage Framework Modulesfwcomm0 Available 20-T

23、1-01-FF Fibre Channel Storage Framework Commsfwcomm1 Available vLAN Storage Framework Comm这样，在虚拟化环境下实现 PowerHA7.1 的 FC heartbeat 就完成了。测试将 node1 节点 halt -q，然后再 node2 上观察 node1 节点的 sfwcom 接口状态，处于 stale 状态，而 node2 自身的 sfwcom 状态正常，这符合预期：Node node1Node UUID = 398263b2-8bdc-11e2-844a-ce02cc0e300aNumber of

24、 interfaces discovered = 3 Interface number 1, en0 IFNET type = 6 (IFT_ETHER) NDD type = 7 (NDD_ISO88023) MAC address length = 6 MAC address = CE:02:CC:0E:30:0A Smoothed RTT across interface = 7 Mean deviation in network RTT across interface = 3 Probe interval for interface = 100 ms IFNET flags for

25、interface = 0x1E080863 NDD flags for interface = 0x0021081B Interface state = STALE Number of regular addresses configured on interface = 2 IPv4 ADDRESS: 172.16.25.175 broadcast 172.16.25.255 netmask 255.255.255.0 IPv4 ADDRESS: 172.16.25.178 broadcast 172.16.25.255 netmask 255.255.255.0 Number of cl

26、uster multicast addresses configured on interface = 1 IPv4 MULTICAST ADDRESS: 228.16.25.175 Interface number 2, sfwcom IFNET type = 0 (none) NDD type = 304 (NDD_SANCOMM) Smoothed RTT across interface = 0 Mean deviation in network RTT across interface = 0 Probe interval for interface = 100 ms IFNET f

27、lags for interface = 0x00000000 NDD flags for interface = 0x00000009 Interface state = STALE Interface number 3, dpcom IFNET type = 0 (none) NDD type = 305 (NDD_PINGCOMM) Smoothed RTT across interface = 76 Mean deviation in network RTT across interface = 7 Probe interval for interface = 830 ms IFNET

28、 flags for interface = 0x00000000 NDD flags for interface = 0x00000009 Interface state = STALE回页首总结通过目前的实施案例来看，在 PowerVM 环境下实施 PowerHA7.1 是完全没有问题的，PowerHA 也能实现其在物理分区中相同的功能。关于技术要点，总结如下： PowerHA7.1 中允许 1 个 HA 节点只有 1 个网卡、1 个 BootIP 和一个 ServiceIP，并且 ServieIP 可以和 BootIP 在相同网段，这为在 VIOC 中简化网络结构提供了便利（网络的高可用通过 VIOS 上 SEA 的 NIB 或 EtherChannel 来实现） 。 netmon.cf 的功能的成功实现，解决了 PowerHA 监控虚拟网卡状态的问题 FC 心跳的虚拟环境下的实施保证了 VIOC 在没有物理 HBA 卡的情况下，通过虚拟 FC 心跳的功能，使 PowerHA 更加稳定，有效地预防脑裂。