1.1 Heartbeat簡介
Heartbeat是一款開源提供高可用（Highly-Available）服務的軟件，通過Heartbeat可以將資源（IP及程序服務等資源）從一臺已經故障的計算機快速轉移到另一臺可以正常運轉的機器上繼續提供服務，一般稱之爲高可用服務。在實際生產應用場景中，heartbeat的功能和keepalived有很多相同之處，但在生產中，對實際的業務應用也是有區別的。如：keepalived主要是控制ip的漂移，配置、應用簡單，而heartbeat則不但可以控制ip漂移，更擅長對資源服務的控制，配置、應用比較複雜。
1.2 Heartbeat工作原理
通過修改Heartbeat的配置文件，可以指定哪臺Heartbeat服務器作爲主服務器，則另一臺服務器自動成爲熱備服務器，然後在熱備服務器上配置Heartbeat守護程序來監聽來自主服務器的心跳消息。如果熱備服務器在指定的時間內未監聽到來自主服務器的心跳，就會啓動故障轉移程序，並取得主服務器上的相關資源服務的所有權，接替主服務器繼續不間斷的提供服務，從而達到資源及服務高可用性的目的。
以上描述是heartbeat主備的模式，heartbeat還
支持主主模式，即兩臺服務器互爲主備，這時它們之間會相互發送報文來告訴對方自己當前的狀態，如果在指定的時間內未收到對方發送的心跳報文，那麼，一方就
會認爲對方失效或者宕機了，這每個運行正常的主機就會啓動自身的資源接管模塊來接管運行在對方主機上的資源或者服務，繼續爲用戶提供服務。一般情況下，可
以較好的實現一臺主機故障後，企業業務仍能不間斷的持續運行。注意：所謂的業務不間斷，在故障轉移期間也是需要切換時間的<例如：停止數據庫及存儲服務等>heartbeat的主備高可用的切換時間一般是在5-20秒左右(服務器宕機的切換比人工切換要快)
另外，和keepalived高可用軟件一樣，heartbeat高可用是操作系統級別的，不是服務（軟件）級別的，可以通過簡單的腳本控制，實現服務級別的高可用
高可用服務器切換的常見場景：
1）主服務器物理宕機（硬件損壞，操作系統故障），主要解決目標
2）Heartbeat服務軟件本身故障
3）兩臺主備服務器之間心跳連接故障
服務故障不會導致切換，可以通過服務宕機把heartbeat服務停掉
1.3 Heartbeat心跳連接
要部署heartbeat服務，至少需要兩臺主機來完成，那麼，要實現高可用服務，這兩臺主機之間是如何做到互相通信和互相監測的呢？
下面是兩臺heartbeat主機之間通信的一些常用可行方法：
1）利用串行電纜，即所謂的串口線連接兩臺服務器
2）一根以太網電纜兩網卡直連
3）以太網電纜，通過交換機等網絡設備連接（不推薦）
1.3.1 如何爲高可用服務器端選擇心跳通信方案？
1）串口線信號不好和以太網網絡交集，也不需要單獨配置IP地址等信息，因此傳輸穩定不容易出現問題，使用串口線的缺點是兩個服務器之間的距離不能太遠，串口線對應服務端設備爲/dev/ttvS0
高可用方案一般都在同一局域網內，跨越公網沒法用
2）使用以太網網線（無需特殊的交叉線）直連網卡的方式，配置也比較簡單，只需對這兩塊直連網線的網卡配好獨立的IP段地址能夠互相通信即可，普通網線就可以
3）使用聯網以太網網線和網卡作爲心跳線是次選方案，因爲這個鏈路增加了交換機設備這樣的故障點，且這個線路不是專用心跳線路，容易受以太網其他數據傳輸的影響，導致心跳報文發送延遲或者無法送達的問題
生產中經常採用串口線和以太網線直連搭配使用
1.3.2hearbeat心跳類型：
heartbeat集羣心跳可以在/etc/ha.d/ha.cf文件中進行配置，心跳類型有4種
①串口
serial 串口名稱
serial /dev/ttyS0 # Linux
serial /dev/cuaa0 # FreeBSD
serial /dev/cuad0 # FreeBSD 6.x
serial /dev/cua/a # Solaris
②廣播
廣播heartbeats的接口
bcasteth0 #Linux
bcast eth1 eth2 # Linux
bcast le0 # Solaris
bcast le1 le2 # Solaris
③多播
設置一個多播心跳介質
mcast [dev] [mcast group] [port] [ttl] [loop]
[dev]發送/接收heartbeats的設備
[mcast group]加入到的多播組（D類多播地址224.0.0.0- 239.255.255.255）
[port]端口用於發送/接收udp（設置這個值跟上面的udpport爲相同值）
[ttl]外流的heartbeats的ttl值。這個影響多播包能傳播多遠。（0-255）必須要大於0。
[loop]爲多播heartbeat開關loopback。如果enabled，一個外流的包將被迴環到原處並由發送它的接口接收。（0或者1）設置這個值爲0。
mcast eth1 225.0.0.10 694 1 0
④單播
配置一個unicast /udp heartbeat介質
ucast [dev] [peer-ip-addr]
[dev]用於發送/接收heartbeat的設備
[peer-ip-addr]包被髮送到的對端的IP地址
ucast eth0 172.10.25.27
選擇方案小結：
1、和數據相關的業務，要求較高，可以串口和網線直連的方式並用
2、WEB相關的業務可以選擇串口，網線直連或者聯網的方式使用
1.4 Heartbeat腦裂
1.4.1什麼是腦裂？
在“雙機熱備”高可用（HA）系統中，當聯繫2個節點的“心跳線”斷開時，本來爲一整體、動作協調的HA系統，就分裂成爲2個獨立的個體。由於相互失去了聯繫，都以爲是對方出了故障，2個節點上的HA軟件像“裂腦人”一樣，“本能”地爭搶“共享資源”、爭起“應用服務”，就會發生嚴重後果：或者共享資源被瓜分、2邊“服務”都起不來了；或者2邊“服務”都起來了，但同時讀寫“共享存儲”，導致數據損壞（常見如數據庫輪詢着的聯機日誌出錯）。
1.4.2腦裂發生的原因？
A：高可用服務之間的心跳線路故障，導致無法正常通信
1）心跳線壞了（斷了或者老化）
2）網卡及相關驅動壞了，IP配置及衝突問題（網卡直連）
3）心跳線之間連接的設備故障（網卡及交換機）
4）仲裁的機器出問題（仲裁方案）
B：高可用服務器上開啓瞭如iptables防火牆阻擋了心跳消息傳輸
C：高可用服務器上心跳網卡地址等信息配置不正確，導致發送心跳失敗
D：其他服務配置不當等原因，如心跳方式不同，心跳廣播衝突，軟件bug等
提示：另外keepalived配置如果virtual_router_id參數，兩端配置不一致，也會導致腦裂問題
1.4.3防止腦裂發生的方案：
1）同時使用串行電纜和以太網電纜連接，同時使用兩條心跳線路（網卡設備和網線設備）
2）當檢測到腦裂時強行關閉一個心跳節點（這個功能需特殊設備支持，如stonith、fence），相當於程序上備節點發現心跳線故障，發送關機命令到主節點（銀行）
3）做好腦裂的監控報警（如郵件及手機短信，值班），在問題發生時人爲第一時間介入仲裁，降低損失。百度的報警監控是上行和下行。人工交互的過程。當然在實施高可用方案時，要根據業務實際需要確定是否能容忍這樣的損失。對於一般的網站常規業務，這個損失是可控的
4）
啓用磁盤鎖。正在服務一方鎖住共享磁盤，腦裂發生時，讓對方完全搶不走共享資源，但使用鎖磁盤也會有個問題，如果佔用共享盤的一方不主動解鎖，另一方就永
遠得不到共享磁盤。現實中假如服務節點突然死機或崩潰，就不可能執行解鎖命令。後備節點也就接管不了共享資源和應用服務。於是有人在HA中設計了智能鎖即，正在服務的一方只在發現心跳線全部斷開（察覺不到對端）時才啓用磁盤鎖，平時就不上鎖，此功能適合共享場景
5）報警報在服務器接管之前，給人員處理留足夠的時間，就是1分鐘內報警了，但是服務器不接管，而是5分鐘之後接管，接管的時間較長。數據不會丟失，但就是會導致用戶無法寫數據。
6）報警後，不直接自動服務器接管，而是由人員接管。
7）增加仲裁的機制，確定誰該獲得資源，這裏面有幾個參考的思路：
a）增加一個仲裁機制。例如設置參考的IP，當心跳完全斷開的時候，2個節點各自都ping一下參考的IP，不同則表明斷點就出現在本段，這樣就主動放棄競爭，讓能夠ping通參考IP的一端去接管服務
b）通過第三方軟件仲裁誰該獲得資源，這個在阿里有類似的軟件應用
小結：如何寫腳本判斷出現腦裂
1）簡單判斷，只要備節點出現VIP就報警（a.主機宕機了，備機接管了。b.主機沒有宕，腦裂了），不管哪種情況，人工查看
2）嚴謹判斷，備機出現VIP,並且主機及服務還活着，，腦裂了
1.4.4有關fence設備和仲裁機制
fence只是HA集羣環境下的術語，在硬件領域，fence設備其實就是一個智能電源管理設備（IPMI）或遠程管理卡，fence有外部fence和內部fence(插在服務器裏)，不管是內部還是外部fence,這些設備都是帶有以太網口的，用來在HA切換觸發時通過網絡重啓提供資源服務的服務器
內部fence:
IBM：RSA,RSAII
HP:ILO,ILO2
DELL:iDRAC,iDRAC3
外部fence設備：
Stonith概述
stonith是“shoot the other node in the head”的首字母簡寫，它是Heartbeat軟件包的一個組件，它允許使用一個遠程或“智能的”連接到健康服務器的電源設備自動重啓失效服務器的電源，stonith設備可以關閉電源並響應軟件命令，運行Heartbeat的服務器可以通過串口線或網線向stonith設備發送命令，它控制高可用服務器對中其他服務器的電力供應，換句話說，主服務器可以復位備用服務器的電源，備用服務器也可以復位主服務器的電源。
注意：儘管理論上連接到遠程或“智能的”循環電源系統的電力設備的數量是沒有限制的，但大多數stonith實現只使用兩臺服務器，因爲雙服務器stonith配置是最簡單的，最容易理解，它能夠長時間運行且不會降低系統的可靠性和高可用性
Stonith事件觸發工作步驟：
1）、當備用服務器聽不到心跳時Stontih事件開始。
注意：這並不一定意味着主服務器沒有發送心跳，心跳可能有多種原因而沒有抵達備用服務器，這就是爲什麼建議至少需要兩條物理路徑傳輸心跳以避免出現假象的原因了。
2）、備用服務器發出一個Stonith復位命令到Stonith設備。
3）、Stonith設備關閉主服務器的電力供應。
4）、一經切斷主服務器的電源，它就不能再訪問集羣資源，也不能再爲客戶端提供資源，保證客戶端計算機不能訪問主服務器上的資源，排除可能發生的頭腦分裂狀態。
5）、然後備用服務器獲得主服務器的資源，Heartbeat用start參數運行資源腳本，並執行ARP欺騙廣播以便客戶端計算機發送它們的請求到它的網絡接口上。
1.5 Heartbeat消息類型
Heartbeat在工作過程中，一般來說，有三種消息類型
1)心跳消息
2）集羣轉換消息
3）重傳請求
心跳消息
心跳消息爲約150字節的數據包，可能爲單播，廣播或多播的方式，控制心跳頻率及出現故障要等待多久進行故障切換
集羣轉換消息
ip-request和ip-request-resp
當主服務器恢復在線狀態時，通過ip-request消息要求備機釋放主服務器失敗時備服務器取得的資源，然後備服務器關閉釋放主服務器失敗時取得的資源及服務
備服務器釋放主服務器失敗時取得的資源及服務後，就會通過ip-request-resp消息通知主服務器它不再擁有該資源及服務，主服務器收到來自備節點的ip-request-resp消息通知後，啓動失敗時釋放的資源及服務，並開始提供正常的訪問服務
重傳請求
rexmit-request控制重傳心跳請求，此消息不太重要
提示：以上心跳控制消息都使用UDP協議發送到/etc/ha.d/ha.cf文件指定的任意端口，或指定的多播地址
1.6 Heartbeat IP地址接管和故障轉移
Heartbeat是通過IP地址接管和ARP廣播進行故障轉移的
ARP廣播：在主服務器故障時，備用節點接管資源後，會立即強制更新所有客戶端本地的ARP表，（即清除客戶端本地緩存的失敗服務器的vip地址和mac地址的解析記錄）確保客戶端和新的主服務器對話。
1.7 VIP/IP 別名/輔助IP
真實IP,又稱爲管理IP,一般是配置在物理網卡上的實際IP,在負載均衡及高可用環境中，管理IP是不對外提供用戶訪問服務的，僅是管理服務器用，如ssh可以通過這個管理ip連接服務器
VIP是虛擬IP,實際上就是heartbeat臨時綁定在物理網卡上的別名IP(heartbeat3以上也採用了輔助IP),如eth0:x,x爲0-255的任意數字，你可以在一塊網卡上綁定多個別名，這個VIP可以看作是你的網名。在實際生產環境中，需要把DNS配置中把網站域名地址解析到這個VIP地址，由VIP對用戶提供服務
這樣做的好處就是當提供服務的服務器宕機以後，在接管的服務器上會直接自動配置上同樣的VIP提供服務。如果是使用管理IP,來回遷移就難以做到，而且，管理IP遷移走了，我們就只能去機房連接服務器了，VIP的實質就是確保兩臺服務器各有一個管理IP不動，就是隨時可以連上機器，然後，增加綁定其他的IP,這樣就算VIP轉移走了，也不至於服務器本身連不上，因爲管理IP不變
手動配置VIP的方法：
ifconfig eth0:1 172.26.10.50 netmask 255.255.255.224up (ip別名)
#==》heartbeat2默認使用這個命令來添加VIP
ip addr add 10.25.16.30/24 broadcast 10.25.16.255 dev eth1(輔助ip)
#==>keepalived,heartbeat3採用的方案
ip add可以查看包括別名和輔助ip,用ifconfig無法查看輔助ip
手動刪除VIP的方法：
ifconfig eth0:1 172.26.10.50 netmask 255.255.255.224 down
ip addr del 10.25.16.30/24 broadcast 10.25.16.255 dev eth1
1.8 Heartbeat相關目錄及文件
啓動腳本：/etc/init.d/
重要資源目錄：/etc/ha.d/resource.d/ 存放控制服務的腳本
默認配置文件目錄：/etc/ha.d/
Heartbeat常用的配置文件有3個，分別是：
1.9 Heartbeat發展分支
Heartbeat3個分支說明：
從2.1.4之後，heartbeat分了3個不同的分支，Heartbeat、Cluster Glue 、Resource Agents，以前CRM功能也獨立出一個版本Pacemaker
3.0之後開始有分支，之前純粹是心跳引擎
1.10 Heartbeat生產應用場景
1、WEB高可用雙機之間，Heartbeat配合nginx，haproxy較好，LVS+keepalived較好
2、數據庫的主的高可用<最好使用Heartbeat>
3、存儲方面（MFS）使用Heartbeat+Drbd較好
本文出自 “一步小心踏破了紅塵” 博客，請務必保留此出處http://lorne.blog.51cto.com/9062483/1775861