一 . 初識 HACMP 心跳
HACMP 軟件主要監控 4 種故障： 節點，網卡，網絡，應用 。其中前三種都是通過心跳來監控并產生事件響應的，我們可以看出使用 HACMP 集群，可謂玩的就是心跳。如果不了解心跳的過程和基本原理，使用 HACMP 搭建起來的高可用的平臺就可能是高不可用。
其實 HACMP 的心跳并不復雜高深，像所有的 HA 軟件一樣，心跳包是用來傳遞節點的狀態信息， HACMP 的心跳包從最高的 IP 地址依次單向流動到最低 IP 地址，然后再返回到 IP 地址最高的節點形成一個單向循環的環路。 每一個物理子網都會有一個心跳環路，包括串口心跳和磁盤心跳這些點對點的心跳，在廣義上也是各自獨立的心跳環路。 每個環路我們稱之為一個心跳網絡 。其心跳過程我們可以參看下圖， Node3 有最高的 IP 地址 192.168.1.3 ，它是該心跳環路的 Group Leader 。 Node3 產生的心跳包發送給 Node2 ， Node2 產生的心跳包發送給 Node1 ， Node1 則發送給 Node3 形成一個環路。
對于 HACMP 集群來說，至少需要 2 個心跳網絡來保證心跳網絡的冗余，而且更進一步， 至少需要 2 種不同類型的心跳網絡保證更高的可靠性，比如，一個 IP 網絡心跳，一個磁盤心跳 。之所以對心跳網絡可靠性有如此高的要求，除了我們之前描述的心跳網絡的重要作用以外，還有更重要的原因：如果 2 個節點間心跳通信完全中斷后，他們都會認為對方已經宕機，然后都在本地啟動應用，并同時去爭搶磁盤資源，有可能導致數據出現風險，即所謂的 split-brain 事件 。所以 HACMP 包括其他的 HA 的集群應用都有一個很重要的前提，就是要求在任何時刻至少存在一個可用的心跳網絡在節點間傳遞信息 。
二 . 再看 HACMP 心跳
從 HACMP5.1 版本以后， HACMP 的心跳已經交由 RSCT （ Reliable Scalable Cluster Technology ） 這一套中間層軟件來實現。 RSCT 相當于是一個集群應用與集群管理的中間通訊平臺，它提供了豐富的集群功能簡化了集群應用開發的復雜性。在其他的一些軟件，比如 IBM CSM 集群管理軟件和 HMC 上的部分管理功能都是通過 RSCT 的組件來實現的。
再細分來看，負責心跳的是 RSCT 中的 Topology Services 模塊。我們下面先了解一下 Topology Services 的初始化過程。 Topology Services 的核心進程是 /usr/sbin/rsct/bin/hatsd 。 hatsd 啟動后就開始廣播本節點信息同時偵聽其他節點的信息，經過自舉、推舉、還有一段時間等待（其過程有點類似于以太網交換機通過 spanning-tree 協議選舉 root 節點）， 最后在該子網中找出所有節點里一個 IP 地址最高的，將它定義為 group leader 。 Group leader 作為一個權威節點負責該子網中節點狀態信息的收集，管理，更新和發布 。至此，心跳網絡就完成了其初始化過程開始正常心跳。另外， 為防止 Group Leader 宕機，還定義了 IP 地址第二高的節點作為 Group Leader 的監控節點稱之為 Group Leader Successor ，它負責監控 Group Leader 狀態，在必要時可以彈劾并成為 Group Leader 。
在心跳網絡建立以后， 網絡狀態的監控被分為兩部分，一是網卡物理狀態的監控；一是邏輯上的網絡鏈路狀態監控。 網卡 物理狀態的監控 是通過為每一塊網塊創建一個監控進程（ NIM ）來實現的，當網卡狀態改變會立刻通知 RSCT ，比如網卡 Link down 的信息就會被 NIM 立刻發現并產生 Network adaptor failure 的事件。
另一方面， hacmp 心跳故障判斷還能從 邏輯上分析判斷網絡狀態 。我們以下圖為例。假設在運行過程中， Node3 到 Node2 之間的網絡發生意外中斷，但是 Node3 網卡的鏈路狀態仍然為 UP ，此時物理的網卡監控不會做出反應。然而心跳包會開始丟包， Node2 會發現無法收到 Node3 的心跳包，但此時并不能確定到底是 Node2 還是 Node3 網絡出現故障。為了進一步確定故障， Node3 會通過 RSCT 走別的心跳網絡發命令給第三個節點（ node1 ），讓第三個節點（ Node1 ）分別去 ping Node2 和 Node3 。如果故障點在 Node3 上面，那么顯然 ping Node3 會失敗，于是確定故障位置在 Node3 上面，最后產生一個的 Network adaptor failure 的事件通知給 HACMP 。
三 . 2 個節點的 HACMP 集群
我們從上文可以發現，準確判斷網絡故障點的位置需要“第三個節點”做仲裁。只有 2 個節點的 HA 集群如何實現正確判斷？從一般的邏輯判斷上來說， 2 個節點之間出問題一定是公說公有理，婆說婆有理，必須要有第三方來做仲裁。
在只有 2 個節點的 HA 集群中，為了解決這個問題， HACMP 需要配置一個文件來設置一些第三方的一個仲裁 IP 地址。當心跳故障發生時， 2 個節點都會去試圖從本機去 ping 這些仲裁 IP 地址。 能正確的 ping 通則表明本節點的網絡正常，從而判斷出故障點需要注意的是，僅僅是在網絡心跳發生問題時， RSCT 才會調用網絡診斷的進程去使用這些仲裁 IP ，在正常狀態下，這些仲裁 IP 不會參與到心跳過程。
這些仲裁 IP 的選擇可以是子網的網關，也可以是子網中其他的某一節點 IP 地址。如果有多個子網，需要為每個子網挑選一個仲裁 IP 地址，把他們寫成一個 list 保存到一個配置文件（ netmon.cf ）中。 該配置文件的存放位置在 /usr/es/sbin/cluster/netmon.cf 。在兩個節點的 HA 群里同步配置的過程中，如果沒有配置 netmon.cf 可能會彈出一個 warning 的信息提示該文件需要配置 。
在配置 netmon.cf 后， RSCT 的進程啟動后，會逐條把其中的 IP 讀取進來，作為仲裁 IP 使用。我們可以在 nmDiag.nim.topsvcs.xxx 這個日志文件中看到這樣的信息。
06/18 19:01:55.387: read_ping_configuration:Entered for adapter en0
06/18 19:01:55.387: read_ping_configuration:File /usr/es/sbin/cluster/netmon.cf opened
06/18 19:01:55.387: read_ping_configuration:Read [192.168.21.130 ] from file.
06/18 19:01:55.387: read_ping_configuration:gethostbyname (192.168.21.130) was successful.
06/18 19:01:55.387: read_ping_configuration:Read [172.32.16.3] from file.
06/18 19:01:55.387: read_ping_configuration:gethostbyname (172.32.16.3) was successful.
06/18 19:01:55.387: read_ping_configuration:Read 2 ping addresses.
四 . 其他一些細節
4.1 RSCT/HACMP 日志文件
關于 HACMP 心跳的日志存放在 /var/ha/log 目錄下 。其主要可供分析的有：
（ 1 ） nim.topsvcs.enX (enX 為網絡端口名 ) 該文件對應的記錄了網卡 enX 的網絡監控進程的啟動，心跳和退出的詳細日志。
（ 2 ） nmDiag.nim.topsvcs.enX 該文件記錄了在心跳出現丟失后， RSCT 對網絡拓撲的邏輯分析判斷的過程。
（ 3 ） Topsvcs.<pid 進程號 >.<cluster name> 該文件是 topsvcs 的主進程日志文件，記錄 topsvcs 進程的啟動過程，以及心跳網絡拓撲改變等重要的事件信息。
4.2 心跳網絡狀態查詢命令
我們一般都知道 hacmp 的狀態可以通過 /usr/sbin/cluster/clstat 來查看，還有一個命令可以更詳細的查看當前集群心跳狀態。 lssrc – ls topsvcs 如下圖：
# lssrc -ls topsvcs | more
Subsystem Group PID Status
topsvcs topsvcs 315610 active
Network Name Indx Defd Mbrs St Adapter ID Group ID
net_ether_01_0 [ 0] 2 1 S 192.168.21.150 192.168.21.150
net_ether_01_0 [ 0] en0 0x808820f2 0x808820fc
HB Interval = 1.000 secs. Sensitivity = 10 missed beats
Missed HBs: Total: 0 Current group: 0
Packets sent : 1078 ICMP 0 Errors: 0 No mbuf: 0
Packets received: 866 ICMP 0 Dropped: 0
NIM's PID: 307250
net_ether_01_1 [ 1] 2 1 S 172.16.21.1 172.16.21.1
net_ether_01_1 [ 1] en1 0x808820f3 0x808820fc
HB Interval = 1.000 secs. Sensitivity = 10 missed beats
Missed HBs: Total: 0 Current group: 0
Packets sent : 1078 ICMP 0 Errors: 0 No mbuf: 0
Packets received: 434 ICMP 0 Dropped: 0
通過分析心跳包的丟包數量和頻率可以判斷網絡的可靠性和負載情況 ，一方面可以用來分析和解釋異常的 HA 備機切換動作，另一方面可以用來分析系統問題并通過調整系統參數來均衡負載。 建議在設計 HA 集群的時候不要使用負載過大的 TCP/IP 網絡或者 IO 負載很大的磁盤來做心跳。
HACMP 集群的各種網絡故障的分析和判斷都是由 RSCT 心跳來實現的，網絡故障的判斷正確與否也直接影響了 HACMP 對應用的切換和還原，所以了解心跳的過程與原理對于設計與配置 HACMP 高可用集群具有重要的意義。
From:
http://www.ibm.com/developerworks/cn/aix/library/0811_wangrong_hacmp/index.html
------------------------------------------------------------------------------
Blog ： http://blog.csdn.net/tianlesoftware
網上資源： http://tianlesoftware.download.csdn.net
相關視頻： http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
DBA1 群： 62697716( 滿 ); DBA2 群： 62697977( 滿 )
DBA3 群： 62697850 DBA 超級群： 63306533;
聊天 群： 40132017
-- 加群需要在備注說明 Oracle 表空間和數據文件的關系，否則拒絕申請
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
