前言：HA中最複雜的，也是最難處理的就是叢集腦裂問題，如果處理不好會導致資料丟失、資料不一致等一系列問題。HA解決方案中大多數都是基於VIP也就是虛擬IP的方式，虛擬IP的實現又依賴於ARP協議，讓我們先來看下一些基礎知識。
一、ARP請求過程：
1：傳送ARP請求
2層網路中需要透過IP地址訪問另一臺機器，需要先找到它的MAC地址，這個過程就是透過ARP協議來實現的。請求傳送方會先查詢本機的ARP快取表如果其中找不到對應的記錄，就會透過往同網段中所有機器傳送ARP廣播。
如上圖我們ping 192.168.1.111，同網段所有機器都會收到下圖所示的arp廣播內容。
2：回應ARP請求
如上圖是一個arp回應包，閘道器詢問誰是192.168.1.195， 192.168.1.195機器傳送了ARP reply包，告訴閘道器它是192.168.1.195並且自己的MAC地址是fa:16:3e:74:cd:8f。網段內機器受到arp廣播後，首先會檢查請求的IP地址是不是在本機網口上，具體的回應策略根據核心的一些引數（arp_ignore）來決定是隻回應接收ARP廣播網路卡上的IP還是本機所有網路卡上的IP，最後如果在本機找到了請求的IP地址，則傳送arpReply回應包。
3：接收ARP回應並快取
傳送ARP請求的機器接收到ARP回應包後，把其快取在本機的ARP快取表後，下次再次請求時直接從ARP快取表中獲取請求目標的MAC地址，不再傳送ARP廣播。
二、ARP狀態流轉過程：
下圖中我們執行 ip neigh可以看到本機arp快取表的條目，顯示了快取在本機ARP快取表中的機器對應的MAC資訊。
1：傳送ARP請求
2：如果收到ARP回應包，則進入REACHABLE狀態
3：如果沒有收到ARP回應包，則進入INCOMPLETE狀態
4：進入REACHABLE狀態超過一定的時間後（base_reachable_time引數設定的時間），會進入STALE狀態
5：如果再次請求ARP快取表中的MAC，則該ARP狀態從STALE短暫進入DELAY狀態
6：如果進入DELAY狀態後收到了回應包，則再次從DELAY狀態轉為REACHABLE狀態
7：如果進入DELAY狀態並在DELAY定時器到期後還沒收到回應包，則進入probe狀態重新探測
8：進入probe狀態後會在一定時間內持續傳送ARP請求，如果成功收到回應包則進入REACHABLE狀態，如果沒有收到則進入failed狀態
9：INCOMPLETE狀態下嘗試一定次數到最大嘗試次數後會轉為failed狀態
10：處理ARP快取的gc垃圾器會定期進行回收，清除STALE和failed狀態的條目來釋放空間
關鍵點：其實說了這麼多，這裡最關鍵的部分就是回收STALE和failed狀態條目的時機，我們在本機測試發現arp快取表裡面STALE狀態和failed狀態的條目會一直存在，貌似不會被清除。STALE狀態正常的清除週期是60S，由gc_stale_time引數確定，reachable狀態轉為STALE狀態的時間預設是30S，由base_reachable_time引數確定，所以正常來說90S後STALE狀態的資訊就應該被GC回收器清除了，那為什麼實際STALE狀態的條目實際並未在90S後被清除，而是一直存在。
這裡的關鍵就在net.ipv4.neigh.default.gc_thresh1引數，預設的值是128，也就是ARP快取的最大條目，只有超過這個條數後才會觸發ARP的GC機制開始回收，因為正常ARP快取表的條目都很難達到這個數目所以會導致不會被清除。
我們把net.ipv4.neigh.default.gc_thresh1的值設為3，再次測試發現STALE狀態和failed狀態的條目60S後自動消失了，說明被GC自動回收了，這再次驗證了我們的說法。
三、HA腦裂原因：
瞭解了ARP後我們再來看HA腦裂的情況。
腦裂過程：如上圖，192.168.1.11和192.168.1.12是HA 雙機的原IP，而192.168.1.10是VIP，正常主備模式下只有主機才會啟用vip，備機是關閉的，這樣客戶端和其他機器就可以透過vip訪問到主機上的服務。但是在腦裂場景下，比如HA主備機器因為心跳檢測埠被防火牆攔截導致雙機無法透過心跳檢測到對方狀態，故都被提升成了主節點，所以2臺機器都啟用了VIP。
造成問題：這樣造成的問題是 其他機器訪問VIP後，可能一會訪問的是node1，一會訪問的是node2，這樣會把資料一部分寫到node1上，一部分寫到node2上，造成資料不一致甚至檔案系統損壞等眾多問題。這裡為什麼會出現這種情況呢？就是上面的ARP機制導致的，我們來結合ARP機制來分析HA腦裂後客戶端訪問的VIP會在雙機之間來回漂移的原因。
原因分析：核心在於我們二里面的說的關鍵點，
我們先看下上圖，比如vip是192.168.1.254，我們訪問vip後對應的arp快取就會快取在arp快取表裡面，下次訪問的時候直接從ARP快取表裡面獲取。這種情況下即使HA腦裂後出現了2個VIP，由於ARP快取表的原因，其訪問的還是其中某一臺機器，但是下面2種情況下就會出問題：
1：如果使用者手動設定了net.ipv4.neigh.default.gc_thresh1引數，比如設定成了5或者10，那麼再和該機互動的ip超過5條後 192.168.1.254的快取資訊就會很快被回收掉；
2：即使使用者不手動修改net.ipv4.neigh.default.gc_thresh1引數，雖然預設的128條數目正常很難達到，但這個沒法100%保證，在某些場景下如果有大量的IP和本機互動 ，條數也很可能超過128導致192.168.1.254的快取被清理；
3：客戶端首次訪問，由於之前arp快取表沒有192.168.1.254的快取資訊，導致它只能從HA雙機裡面隨機選一個，這時候誰最先回它的arp請求它就會選誰。
4：如果客戶端和HA不在一個網段，需要透過閘道器來訪問HA節點的話，則取決於閘道器的ARP快取表上192.168.1.254的重新整理時間，這個閘道器可能是路由器、3層交換機、軟路由等，主要取決於其ARP快取重新整理週期（也就是ARP快取老化時間），這個時間沒有一個固定值，不同的品牌機器都不一樣，比如思科是 5分鐘，華為是 20分鐘等。
所以上面4種情況都可能導致在HA腦裂期間，客戶端資料一部分寫到node1，一部分寫到node2，這會造成不可逆的損失，顯然是無法接受的。
四、常用HA腦裂解決方案：
瞭解了上面的原理後其實再去解決腦裂問題就相對來說比較簡單了，我們先來看下目前市面上和一些HA元件官方提供的解決方案：
1：多節點
實現方式：部署多個節點，如果主節點網路故障，則可以在剩餘節點裡面透過選舉機制重新選取新的主節點。
優點：能解決網路恢復後主節點不會切換到腦裂之前的節點去，因為新主節點是選舉產生的，少數服從多數原理。
缺點：
1：無法徹底解決腦裂問題，特別是腦裂後雙vip問題，腦裂期間資料依然可能被分別寫入2個主節點中；
2：需要機器數量增多，硬體成本上升；
3：多節點資料同步開銷增大，因為主節點資料需要同步到多個節點中去，降低可靠性。
2：STONITH隔離
實現方式：STONITH機制的實現方式是透過一個專業的STONITH硬體裝置（通常稱為爆頭裝置），透過STONITH硬體裝置來檢測雙機的網路通訊情況，如果有一方網路無法連通了，就判定其網路故障將其直接透過控制電源裝置強制關機從而達到隔離的目的。
優勢：能解決一定場景下的腦裂隔離問題，透過強制關機能保證很強的隔離成功率。
缺點：
1：需要專業的STONITH硬體裝置，部署成本高；
2：STONITH硬體本身可能存在可靠性問題；
3：相容性差，STONITH硬體裝置方式只能部署在物理機場景下，虛擬機器環境無法使用；部分其他STONITH虛擬機器方案（使用伺服器本身的的硬體介面稱為內部Fence）也必須在宿主機上安裝、配置相應的fence服務，且很多系統都無法完全支援；雲平臺則完全無法支援。
4：部分客戶機器業務不允許隨意關機和重啟。
3：仲裁節點
實現方式：在叢集之外啟用一個仲裁節點，其上部署Quorum Device，仲裁節點必須部署在HA網段之外的一個獨立網段中。叢集主節點故障後，會重新進行選舉，仲裁節點具有更高的投票權；
優勢：適合部署在偶數節點中特別是雙節點叢集中，由於其部署在單獨的一個網段中，不受叢集網路的影響，能解決主節點選舉問題，網路恢復後主節點不會切換到之前的主節點上；
缺點：仲裁節點本身可靠性問題，如果仲裁節點本身故障，或者仲裁節點所在網路故障，則會導致更大的問題，比如在雙節點部署下，由於啟用了選舉機制且2個主節點都各只有1票的情況下2個節點都將不可用，導致無法對外提供服務；
五：我的HA腦裂解決方案：
整體思路：
1：往往越簡單的方法有時候越可靠，很多解決方案往往是把事情考慮的過於複雜了而忽略了簡單的方法
2：網路故障歸類，其實導致HA雙機網路無法連通的原因就那麼多，可以把所有可能的情況按型別歸類並按型別採取統一的處理策略
導致HA雙機網路無法連通的原因無非是，1：物理網路故障（網路卡、鏈路、交換機等），2：網路系統故障（網路協議棧、網路引數配置、負載過高等），3：埠開放問題（心跳檢測的埠未開放）
實現方案：
一、網路鏈路故障
鏈路故障無非是網路卡、網線、交換機介面故障，透過檢測鏈路來判定鏈路狀態是否異常，如果鏈路狀態不是yes，則可以判定該機的網路100%故障，直接將其隔離；
二、網路連通性
檢測機制：
1：如果當前節點鏈路狀態正常，則檢測和對端網路的連通性
這裡利用了ping功能，最簡單的檢測網路連通的方式往往最可靠，因為幾乎所有的機器上ping都是可以ping通的，ping對端節點的ip，如果無法ping通，則代表和對端的網路無法連通了。
2：判定和閘道器的連通性
HA的很多方案裡面引入了各自第三方仲裁裝置，但往往卻忽略了現成的可以作為第三方的裝置，那就是閘道器，閘道器是最穩定和可靠的第三方裝置。
透過ping閘道器來判定當前節點和閘道器之前的網路連通性，如果無法無法ping通對端 + ping通閘道器，則可以判定當前節點網路故障，直接將當前節點隔離。
隔離機制：
1、自身鏈路正常 + 無法ping通對端，可以判定有這些可能情況，1：對方節點鏈路故障； 2：自身網路系統故障（網路協議棧、系統超載等）3：交換機故障
2、自身鏈路正常 + 無法ping通對端 + ping通閘道器，可以排除：自身網路系統故障（網路協議棧、系統超載等）、交換機故障、和對端心跳埠不通，所有隻剩下：對方節點鏈路故障，故至少可以判定當前節點是正常的無需隔離；
3、自身鏈路正常 + 無法ping通對端 + ping不通閘道器，則有可能是：自身網路系統故障（網路協議棧、系統超載等），直接將當前節點身隔離；
// 這裡有個極端情況，閘道器故障+對端網路故障，這種情況下隔離當前節點也無影響，因為閘道器掛了代表外部已經無法訪問到HA所在網路了。
三、網路埠連通性
檢查機制：
如果自身網路鏈路正常且能ping通對端，代表和對端的網路是連通的，但不能排除和對端的心跳檢測埠是連通的，所以這個步驟核心是判定和對端心跳檢測埠連通性。
這裡同樣和ping、閘道器一樣，運用了最簡單的一個功能，ssh 22埠預設開放。ssh的埠和ping功能一樣是所有系統預設開放的，目前沒有遇到過這2個最基礎功能無法使用的場景。
HA由於部署時候不僅需要開放雙機之間的SSH埠，還需要配置了雙機免密登入，使得雙機之間SSH埠無法連通的可能性幾乎為0，排除了極少客戶未開放ssh 22埠的可能性。
隔離機制：
1：如果心跳元件返回的資訊裡對端節點下線了，代表和對端的心跳檢測失敗了，則透過ssh免密登入登入到對端節點，然後透過叢集狀態和vip資訊判定是否出現了雙主；
2：如果出現雙主則隔離之前的主節點，因為在提升新的主節點後會強制重新整理網段內其他機器的ARP快取，所以在短時間內的請求都會傳送到最新的主節點，之前的主節點會被記錄在特定檔案中；
3：同時在提升主節點中寫入檢測邏輯，如果叢集已經有一個主節點，則會阻止其提升行為，從而保證了叢集中始終有一個主節點；
透過2和3雙重保障，進一步保障了因為心跳檢測埠被錯誤操作導致不通的情況下叢集可能出現腦裂導致2個主節點的行為。