高可用集群是指一組通過硬件和軟件連接起來的獨立計算機，它們在用戶面前表現為一個單一系統，在這樣的一組計算機內 部的一個或者多個節點停止工作，服務會從故障節點切換到正常工作的節點上運行，不會引起服務中斷。從這個定義可以看出，集群必須檢測節點和服務何時失效， 何時恢復為可用。這個任務通常由一組被稱為“心跳”的代碼完成。在Linux-HA里這個功能由一個叫做heartbeat的程序完成。
heartbeat 心跳技術原理：
heartbeat （Linux-HA）的工作原理：heartbeat最核心的包括兩個部分，心跳監測部分和資源接管部分，心跳監測可以通過網絡鏈路和串口進行，而且支持 冗 余鏈路，它們之間相互發送報文來告訴對方自己當前的狀態，如果在指定的時間內未受到對方發送的報文，那么就認為對方失效，這時需啟動資源接管模塊來接管運 行在對方主機上的資源或者服務。
通過修改Heartbeat的軟件的配置文件，可以制定那一台Heartbeat服務器作為主服務器，則另一台將自動成為熱備服務器。然后在熱備服務器上配置Heartbeat ,守護程序來監聽來自主服務器的心跳消息。如果熱備服務器在指定時間內為監聽到來自主服務器的心跳，就會啟動故障轉義程序，並取得主服務器上的相關資源服務的所有權，接替主服務器繼續不間斷的提供服務，從而達到資源以及服務高可用的目的。
以上的描述heartbeat的主備模式，heartbeat還支持主主模式，即兩台服務器互為主備，這是他們之間還會互相發送報文來告訴對方自己的當前的狀態，如果在指定的時間內未收到對方發送的心跳報文，那么，一方就會認為對方失效或者是已經宕機了，這時每個運行正常的主機就會啟動自身的資源接管模塊來接管運行在對方主機上的資源或者是服務，繼續為用戶提供服務。一般情況下，可以較好的實現一台主機故障后，企業業務能夠不間斷的持續的提供服務。注意：所謂的業務不間斷，在故障轉移期間也是需要切換時間的，heartbeat的切換時間是5-20秒。
切換的常見條件：
1）服務器宕機
2）Heartbeat服務本故障
3）中間的連接線路故障
應用服務故障則不會產生切換，可以通過服務宕機把heartbeat服務停掉。
heartbeat的心跳連接：
講過上面的描述，要部署heartbeat服務，至少需要兩台主機才能完成。那么，要實現高可用服務，這兩台主機之間，是如何做到互相通信互相監控的呢/
下面是兩台heartbeat主機之間通信的一些常用的可行的方法：
1）串行電纜，即所謂的串口（首選，缺點是距離不能太遠）
2）一根以太網電纜量網口直連（生產環境中常用的方式）
3）以太網電纜，通過交換機等網絡設備連接（次選，原因是增加了故障點，不好排查故障，同時，線路不是專用的心跳線，容易受其他數據傳輸的影響，導致心跳報文發送問題）
Heartbeat裂腦：
什么是裂腦？
由於兩台高可用服務器之間在指定的時間內，無法互相檢測到對方心跳而各自啟動故障轉移功能，取得了資源以及服務的所有權，而此時的兩台高可用服務器對都還活着並作正常運行，這樣就會導致同一個IP湖綜合服務在兩端同時啟動而發生沖突的嚴重問題，最嚴重的就是兩台主機同時占用一個VIP的地址，當用戶寫入數據的時候可能會分別寫入到兩端，這樣可能會導致服務器兩端的數據不一致或造成數據的丟失，這種情況就本成為裂腦，也有的人稱之為分區集群或者大腦垂直分隔
導致裂腦發生的原因：
一般來說，裂腦的發生，主要是由以下的幾個原因導致的：
1）高可用服務器對之間心跳線路故障，導致無法正常的通信。原因比如：
（1）.心跳線本身就壞了（包括斷了，老化）
（2）.網卡以及相關驅動壞了,IP配置及沖突問題
（3）.心跳線間連接的設備故障（交換機的故障或者是網卡的故障）
（4）.仲裁的服務器出現問題
2）高可用服務器對上開啟了防火牆阻擋了心跳消息的傳輸
3）高可用服務器對上的心跳網卡地址等信息配置的不正確，導致發送心跳失敗。
4）其他服務配置不當等原因，如心跳的方式不同，心跳廣播沖突，軟件出現了BUG等
防止腦裂發生的方法總結：
發生腦裂的時候，對業務的影響是及其嚴重的，有的時候甚至是致命的。如：兩台高可用的服務器對之間發生腦裂，導致互相競爭同一個IP資源，就如同我們局域網內常見的IP地址沖突一樣，兩個機器就會有一個或者兩個不正常，影響用戶正常訪問服務器。如果是應用在數據庫或者是存儲服務這種極重要的高可用上，那就導致用戶發布的數據間斷的寫在兩台服務器上的惡果，最終數據恢復及困難或者是難已恢復
實際的生產環境中，我們可以從以下幾個方面來防止裂腦的發生：1）同時使用串行電纜和以太網電纜連接，同時用兩條心跳線路，這樣一條線路壞了，另一個線路還是好的，依然能傳送消息（推薦的）
2）檢測到裂腦的時候強行的關閉一個心跳節點（需要特殊的節點支持，如stonith，fence），相當於程序上備節點發現心跳線故障，發送關機命令到主節點。
3）做好對裂腦的監控報警（如郵件以及手機短信等），在問題發生的時候能夠人為的介入到仲裁，降低損失。當然，在實施高可用方案的時候，要根據業務的實際需求確定是否能夠容忍這樣的損失。對於一般的網站業務，這個損失是可控的（公司使用）
4）啟用磁盤鎖。正在服務一方鎖住共享磁盤，腦裂發生的時候，讓對方完全搶不走共享的磁盤資源。但使用鎖磁盤也會有一個不小的問題，如果占用共享盤的乙方不主動解鎖，另一方就永遠得不到共享磁盤。現實中介入服務節點突然死機或者崩潰，另一方就永遠不可能執行解鎖命令。后備節點也就截關不了共享的資源和應用服務。於是有人在HA中涉及了“智能”鎖，正在服務的一方只在發現心跳線全部斷開時才啟用磁盤鎖，平時就不上鎖了
5）報警報在服務器接管之前，給人員處理留足夠的時間就是1分鍾內報警了，但是服務器不接管，而是5分鍾之后接管，接管的時間較長.數據不會丟失，但就是會導致用戶無法寫數據。
6）報警后，不直接自動服務器接管，而是由人員接管。
7）增加仲裁的機制，確定誰該獲得資源，這里面有幾個參考的思路：
1）增加一個仲裁機制。例如設置參考的IP，當心跳完全斷開的時候，2個節點各自都ping一下參考的IP，不同則表明斷點就出現在本段，這樣就主動放棄競爭，讓能夠ping通參考IP的一端去接管服務。
2）通過第三方軟件仲裁誰該獲得資源，這個在阿里有類似的軟件應用