PowerVM 環境下實施 PowerHA 7.1的要點

前言

隨著 PowerVM 使用的越來越多，在虛擬化環境下實施 PowerHA 的案例會越來越多。傳統 PowerHA6.1 在物理分區下實施是比較經典的配置，PowerHA7.1 為了適應 PowerVM，在開發的時候進行了相關考慮，主要包含三點：PowerHA7.1 中允許 1 個 HA 節點只有 1 個網卡、1 個 BootIP 和一個 ServiceIP，並且 ServieIP 可以和 BootIP 在相同網段；netmon.cf 的功能在虛擬化環境中能夠成功實施，解決了 PowerHA 監控虛擬網卡狀態的問題；FC 心跳在虛擬環境下能夠成功實施。本文講主要介紹虛擬化環境下實施的相關要點。

PowerHA7.1 對虛擬網絡的監控 netmon.cf 的配置

在傳統的 HA 環境下，PowerHA 可以通過監控物理網卡的狀態來進行網絡監控。而虛擬化環境下，VIOC 中虛擬網卡永遠不會處於 down 或者 detach 的狀態（除非人為操作），帶來的結果是可能 VIOC 已經無法對外通信，但是由於其虛擬網卡狀態仍然是 up 的狀態，HA 不會識別網絡故障，資源組也不會發生切換，結果就是業務中斷，也就是“該它干的活它沒干”，HA 失去了其本來的意義。

因此，在 PowerVM 環境下實施 PowerHA7.1 的時候，就必須要引入 netmon.cf 的配置。在 netmon.cf 中，我們通過設備 HA 本地網卡 ping 目標地址的方法，來判斷虛擬網卡通訊是否正常。

針對 netmon.cf 文件的配置。在 PowerHA7.1 中推薦的格式是：

# cat /usr/es/sbin/cluster/netmon.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 能夠檢測到虛擬網絡問題並且觸發資源組切換的條件是：

配置 netmon.cf 的分區的 IP 地址 ping 不通 netmon.cf 中配置的目標地址。 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 172.16.25.178 處於 up 狀態。

# clRGinfo ----------------------------------------------------------------------------- Group Name State Node ----------------------------------------------------------------------------- rg1 ONLINE node1 OFFLINE node2

# netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en0 1500 link#2 ce.2.cc.e.30.a 181132 0 14699 0 0 en0 1500 172.16.25 172.16.25.178 181132 0 14699 0 0 en0 1500 172.16.25 172.16.25.175 181132 0 14699 0 0 lo0 16896 link#1 16237 0 16237 0 0 lo0 16896 127 127.0.0.1 16237 0 16237 0 0 lo0 16896 ::1%1 16237 0 16237 0 0

初始情況下，HA1 節點可以 ping 通 netmon.cf 中的目標地址（172.16.24.82），目標地址與源地址互發網絡包正常。

# tcpdump host 172.16.24.82 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type 1, capture size 96 bytes 21:33:18.669852 IP node1 > 172.16.24.82: ICMP echo request, id 488, seq 587, length 43 21: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 節點依然會正常工作，資源組不會發生切換。

從下面的輸出信息中，可以看到 HA1 與目標地址交互不正常。

#tcpdump host 172.16.24.82 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type 1, capture size 96 bytes 21:00:59.785591 ARP, Request who-has 172.16.24.82 tell 172.16.24.1, length 46 21:01:01.071314 IP node1 > 172.16.24.82: ICMP echo request, id 488, seq 184, length 43 21:01:01.426657 IP node1 > 172.16.24.82: ICMP echo request, id 488, seq 184, length 43 21:01:01.782209 IP node1 > 172.16.24.82: ICMP echo request, id 488, seq 184, length 43

在這個時候，可能我們會理所當然地認為本機網卡將會標示出故障。其實不然，這個時候，在 PowerHA 的日志 hacmp.out 和 PowerHA 命令 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 網絡故障，會引起資源組切換。-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.

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 node1 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 中的實施 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 一般使用虛擬 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 的時候，只需要對兩個/多個 VIOS 上的物理光纖卡劃 zone。在 VIOC 上，虛擬光纖卡不是必須的（由於生產環境下多使用 NPIV，所以在 VIOC 下都會有 vfc 設備），在 VIOC 沒有 vfc 卡的情況下，vfc 心跳可以通過 vscsi client 實現。

3.虛擬光纖卡心跳的實現，是通過 VIOS 與 VIOC 之間的 sfwcomm 設備實現的，也就是 VLAN 3358 對應的設備名稱。

4.如果 VIOS 上有單獨可用於 FC 心跳的物理光纖口，那麼可以單獨給這兩個 WWPN 劃 zone。如果資源緊張，那麼使用存儲映射的光纖卡也可以，但是最好將兩個 WWPN 單獨配置在一個新的 zone 裡（由於存儲映射已經有了一個 zone 把兩個 WWPN 劃分在了一起，不增加新的 zone 也能實現功能，但是為了避免存儲的干擾，單獨增加一個 ZONE 效果會更好。）。 PowerVM 中 FC 心跳的實施步驟

1.在配置 fc 心跳之前，在 HA 節點（VIOC）進行查看：

# lscluster -i sfwcom

Interface sfwcom not found 提示沒有 sfwcom 設備。

圖 1.虛擬環境下 FC 心跳的架構圖

2.在 VIOS 中調整物理光纖卡的參數：

chdev -P -l fcs0 -a tme=yes
chdev -P -l fscsi0 -a dyntrk=yes -a fc_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。如果是 DLPAR 一個新的 PVID 為 3358 的虛擬網卡，那麼就不需要 de-active 和 re-active VIOS。

在 VIOC 上，用 DLPAR 增加一個新的虛擬網卡（然後在 HMC 上 save configuration），指向 VIOS 上的 3358 VLAN：

圖 3 查看虛擬網卡

圖 4 查看虛擬網卡

查看本欄目更多精彩內容：http://www.bianceng.cn/OS/unix/

在 VIOC 上 cfgmgr 重新掃描設備信息。

然後在 HA 節點上（vioc）查看， sfwcom 已經可見。

# lscluster -i sfwcom
Network/Storage Interface Query
    
Cluster Name: wxycluster
Cluster UUID: 397cd38e-8bdc-11e2-844a-ce02cc0e300a
Number of nodes reporting = 1
Number of nodes stale = 0
Number of nodes expected = 1
    
Node node1
Node UUID = 398263b2-8bdc-11e2-844a-ce02cc0e300a
Number of interfaces discovered = 1
        Interface number 1, 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 flags for interface = 0x00000000
                NDD flags for interface = 0x00000009
                Interface state = UP
# lsdev -C|grep sfw
sfw0           Available             Storage Framework Module
sfwcomm0       Available 20-T1-01-FF Fibre Channel Storage Framework Comm
sfwcomm1       Available             vLAN Storage Framework Comm

這樣，在虛擬化環境下實現 PowerHA7.1 的 FC heartbeat 就完成了。

測試將 node1 節點 halt -q，然後再 node2 上觀察 node1 節點的 sfwcom 接口狀態，處於 stale 狀態，而 node2 自身的 sfwcom 狀態正常，這符合預期：

Node node1
Node UUID = 398263b2-8bdc-11e2-844a-ce02cc0e300a
Number of 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 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 cluster 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 flags 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 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 更加穩定，有效地預防腦裂。