------ 什么是腦裂（split-brain）
在"雙機熱備"高可用（HA）系統中，當聯系兩個節點的"心跳線"斷開時(即兩個節點斷開聯系時)，本來為一個整體、動作協調的HA系統，就分裂成為兩個獨立的節點(即兩個獨立的個體)。由於相互失去了聯系，都以為是對方出了故障，兩個節點上的HA軟件像"裂腦人"一樣，"本能"地爭搶"共享資源"、爭起"應用服務"。就會發生嚴重后果：1）或者共享資源被瓜分、兩邊"服務"都起不來了；2）或者兩邊"服務"都起來了，但同時讀寫"共享存儲"，導致數據損壞（常見如數據庫輪詢着的聯機日志出錯）。
兩個節點相互爭搶共享資源，結果會導致系統混亂，數據損壞。對於無狀態服務的HA，無所謂腦裂不腦裂，但對有狀態服務(比如MySQL)的HA，必須要嚴格防止腦裂
[但有些生產環境下的系統按照無狀態服務HA的那一套去配置有狀態服務，結果就可想而知]。
------ 集群腦裂產生的原因
一般來說，裂腦的發生，有以下幾種原因：
1. 高可用服務器各節點之間心跳線鏈路發生故障，導致無法正常通信。
2. 因心跳線壞了（包括斷了，老化）。
3. 因網卡及相關驅動壞了，ip配置及沖突問題（網卡直連）。
4. 因心跳線間連接的設備故障（網卡及交換機）。
5. 因仲裁的機器出問題（采用仲裁的方案）。
6. 高可用服務器上開啟了iptables防火牆阻擋了心跳消息傳輸。
7. 高可用服務器上心跳網卡地址等信息配置不正確，導致發送心跳失敗。
8. 其他服務配置不當等原因，如心跳方式不同，心跳廣插沖突、軟件Bug等。
提示： Keepalived配置里同一VRRP實例如果virtual_router_id兩端參數配置不一致也會導致裂腦問題發生。
------ 如何預防HA集群腦裂 [目前達成共識的有下面四種對策]
第一種：添加冗余的心跳線 [即冗余通信的方法]
同時使用串行電纜和以太網電纜連接，同時用兩條心跳線路 (即心跳線也HA)，這樣一條線路壞了，另一個還是好的，依然能傳送心跳消息，盡量減少"腦裂"現象的發生幾率。
第二種方法：設置仲裁機制
當兩個節點出現分歧時，由第3方的仲裁者決定聽誰的。這個仲裁者，可能是一個鎖服務，一個共享盤或者其它什么東西。例如設置參考IP（如網關IP），當心跳線完全斷開時，2個節點都各自ping一下參考IP，不通則表明斷點就出在本端。不僅"心跳"、還兼對外"服務"的本端網絡鏈路斷了，即使啟動（或繼續）應用服務也沒有用了，那就主動放棄競爭，讓能夠ping通參考IP的一端去起服務。更保險一些，ping不通參考IP的一方干脆就自我重啟，以徹底釋放有可能還占用着的那些共享資源。
第三種方法：fence機制 [即共享資源的方法] [前提是必須要有可靠的fence設備]
當不能確定某個節點的狀態時 ，通過fence設備強行關閉該心跳節點，確保共享資源被完全釋放！相當於Backup備節點接收不到心跳信息，通過單獨的線路發送關機命令關閉主節點的電源。
理想情況下，以上第二、三兩者一個都不能少。但是如果節點沒有使用共享資源，比如基於主從復制的數據庫HA，也可以安全的省掉fence設備，只保留仲裁，而且很多時候線上環境里也也可能沒有可用的fence設備，比如在雲主機里。
那么可不可以省掉仲裁機制，只留fence設備呢？這是不可以的。因為，當兩個節點互相失去聯絡時會同時fencing對方。如果fencing的方式是reboot，那么兩台機器就會不停的重啟。如果fencing的方式是power off，那么結局有可能是2個節點同歸於盡，也有可能活下來一個。但是如果兩個節點互相失去聯絡的原因是其中一個節點的網卡故障，而活下來的正好又是那個有故障的節點，那么結局一樣是悲劇。所以說: 單純的雙節點，無論如何也防止不了腦裂。
第四種：啟用磁盤鎖
正在服務一方鎖住共享磁盤，"裂腦"發生時，讓對方完全"搶不走"共享磁盤資源。但使用鎖磁盤也會有一個不小的問題，如果占用共享盤的一方不主動"解鎖"，另一方就永遠得不到共享磁盤。現實中假如服務節點突然死機或崩潰，就不可能執行解鎖命令。后備節點也就接管不了共享資源和應用服務。於是有人在HA中設計了"智能"鎖。即：正在服務的一方只在發現心跳線全部斷開（察覺不到對端）時才啟用磁盤鎖。平時就不上鎖了。
------ 沒有fence設備是否安全
這里以MySQL的數據復制為例來說明這個問題。在基於復制場景下，主從節點沒有共享資源(沒有VIP)，所以2個節點都活着本身沒有問題。問題是客戶端會不會訪問到本該死掉的那個節點。這又牽扯到客戶端路由的問題。客戶端路由有幾種方式: 基於VIP，基於Proxy，基於DNS或者干脆客戶端維護一個服務端地址列表自己判斷主從。不管采用哪種方式，主從切換的時候都要更新路由：
1）基於DNS的路由是不太靠譜的，因為DNS可能會被客戶端緩存，很難清干凈。
2）基於VIP的路由有一些變數，如果本該死掉的節點沒有摘掉自己身上的VIP，那么它隨時可能出來搗亂（即使新主已經通過arping更新了所有主機上的arp緩存，如果某個主機的arp過期，發一個arp查詢，那么就會發生ip沖突）。所以可以認為VIP也是一種特殊的共享資源，必需把它從故障節點上摘掉。至於怎么摘，最簡單的辦法就是故障節點發現自己失聯后自己摘，如果它還活着的話（如果它死了，也就不用摘了）。如果負責摘vip的進程無法工作怎么辦？這時候就可以用上本來不太靠譜的軟fence設備了(比如ssh)。
3）基於Proxy的路由是比較靠譜的，因為Proxy是唯一的服務入口，只要把Proxy一個地方更新了，就不會發生客戶端誤訪問的問題了，但是也要考慮Proxy的高可用。
4）至於基於服務端地址列表的方法，客戶端需要通過后台服務判斷主從（比如PostgreSQL/MySQL會話是否處於只讀模式）。這時，如果出現2個主，客戶端就會錯亂。為防止這個問題，原主節點發現自己失聯后要自己把服務停掉，這和前面摘vip的道理是一樣的。
因此，為了不讓故障節點搗亂，故障節點應該在失聯后自己釋放資源，為了應對釋放資源的進程本身出現故障，可以加上軟fence。在這個前提下，可以認為沒有可靠的物理fence設備也是安全的。
------------------------------------------------------------------------------
什么是Fence設備？
Fence設備是集群中很重要的一個組成部分，通過Fence設備可以避免因出現不可預知的情況而造成的"腦裂"現象, Fence設備主要就是通過服務器或存儲本身的硬件管理接口或者外部電源管理設備，來對服務器或存儲直接發出硬件管理指令，將服務器重啟或關機，或者與網絡斷開連接。在設備為知故障發生時，Fence負責讓占有浮動資源的設備與集群斷開。
每個節點之間互相發送探測包進行判斷節點的存活性。一般會有專門的線路進行探測，這條線路稱為"心跳線"（上圖直接使用eth0線路作為心跳線）。假設node1的心跳線出問題，則node2和node3會認為node1出問題，然后就會把資源調度在node2或者node3上運行，但node1會認為自己沒問題不讓node2或者node3搶占資源，此時就出現了"腦裂"(split brain)。此時如果在整個環境里有一種設備直接把node1斷電，則可以避免腦裂的發生，這種設備叫做fence或者stonith(Shoot The Other Node In The Head爆頭哥)。在物理機里virsh是通過串口線管理虛擬機的，比如virsh destroy nodeX，這里我們把物理機當成fence設備。
------ 主從切換后數據能否保證不丟
主從切換后數據會不會丟和腦裂可以認為是兩個不同的問題。這里還以MySQL的數據復制為例來說明。對MySQL，即使配置成半同步復制，在超時發生后，它可能會自動降級為異步復制。為了防止MySQL的復制降級，可以設置一個超大的rpl_semi_sync_master_timeout，同時保持rpl_semi_sync_master_wait_no_slave為on(即默認值)。但是，這時如果從宕了，主也會hang住。這個問題的破解方法可以配置成一主兩從，只要不是兩個從都宕機就沒事，或者由外部的集群監視軟件動態切換半同步和異步。如果本來就是配置的異步復制，那就是說已經做好丟數據的准備了。這時候，主從切換時丟點數據也沒啥大不了，但要控制自動切換的次數。比如控制已經被failover掉的原主不允許自動上線，否則如果因為網絡抖動導致故障切換，那么主從就會不停的來回切，不停的丟數據，破壞數據的一致性。
------ 如何實現"仲裁機制+fence機制"策略，防止集群"腦裂"
可以自己完全從頭開始實現一套符合上述邏輯的腳本，但是建議使用成熟的集群軟件去搭建，比如Pacemaker+Corosync+合適的資源Agent。Keepalived可能不太適合用於有狀態服務的HA，即使把仲裁，fence都加到方案里，也總覺得別扭。
使用Pacemaker+Corosync的方案需要注意：quorum可以認為是Pacemkaer自帶的仲裁機制，集群的所有節點中的多數選出一個協調者，集群的所有指令都由這個協調者發出，可以完美的杜絕腦裂問題。為了使這套機制有效運轉，集群中至少有三個節點，並且把no-quorum-policy設置成stop，這也是默認值。（注意：no-quorum-policy最好不要設置成ignore，生產環境如果也這么搞，又沒有其它仲裁機制，是很危險的！）
但是，如果只有兩個節點該怎么辦？
1. 拉一個機器借用一下湊足三個節點，再設置location限制，不讓資源分配到那個節點上。
2. 把多個不滿足quorum小集群拉到一起，組成一個大的集群，同樣適用location限制控制資源的分配的位置。
但是如果你有很多雙節點集群，找不到那么多用於湊數的節點，又不想把這些雙節點集群拉到一起湊成一個大的集群（比如覺得不方便管理）。那么可以考慮第三種方法。
3. 第三種方法是配置一個搶占資源，以及服務和這個搶占資源的colocation約束，誰搶到搶占資源誰提供服務。這個搶占資源可以是某個鎖服務，比如基於zookeeper包裝一個，或者干脆自己從頭做一個，就像下面"corosync+pacemaker雙節點腦裂問題處理"的例子：
corosync作為HA方案中成員管理層（membership layer）,負責集群成員管理、通信方式（單播、廣播、組播）等功能，pacemaker作為CRM層。
在利用corosync+pacemaker雙節點主備模式的實踐中，可能會遇到一個問題：腦裂問題。
何謂腦裂:
在HA集群中，節點間通過心跳線進行網絡通信，一旦心跳網絡異常。導致成員互不相認，各自作為集群中的DC，這樣資源同時會在主、備兩節點啟動。
腦裂原因是corosync還是pacemaker導致的？
開始可能認為是corosync，原因在於心跳端導致corosync不能正常通信。
后來發現在pacemaker官網有找到腦裂(split-brain)的方案。pacemaker作為crm，主責是管理資源，還有一個作用是選擇leader。
1. 解決方案：為pacemaker配置搶占資源。
原理在於，pacemaker 可以定義資源的執行順序。如果將獨占資源放在最前面，后面的資源的啟動則依賴與它，成也獨占資源，敗也獨占資源。
當心跳網絡故障時候，誰先搶占到該資源，該節點就接管服務資源，提供服務。這種方案必須解決兩個問題，一是必須定義一個搶占資源，二是自定義pacemaker RA,去搶奪資源。
2. 定義搶占資源
下面利用互斥鎖來實現獨占資源。具體由python實現一個簡單的web服務，提供lock,unlock，updatelock服務。
__author__ = 'ZHANGTIANJIONG629'
import BaseHTTPServer
import threading
import time
lock_timeout_seconds = 8
lock = threading.Lock()
lock_client_ip = ""
lock_time = 0
class LockService(BaseHTTPServer.BaseHTTPRequestHandler):
def do_GET(self):
'''define url route'''
pass
def lock(self, client_ip):
global lock_client_ip
global lock_time
# if lock is free
if lock.acquire():
lock_client_ip = client_ip
lock_time = time.time()
self.send_response(200, 'ok')
self.close_connection
return
# if current client hold lock,updte lock time
elif lock_client_ip == client_ip:
lock_time = time.time()
self.send_response(200, 'ok,update')
self.close_connection
return
else:
# lock timeout,grab lock
if time.time() - lock_time > lock_timeout_seconds:
lock_client_ip = client_ip;
lock_time = time.time()
self.send_response(200, 'ok,grab lock')
self.close_connection
return
else:
self.send_response(403, 'lock is hold by other')
self.close_connection
def update_lock(self, client_ip):
global lock_client_ip
global lock_time
if lock_client_ip == client_ip:
lock_time = time.time()
self.send_response(200, 'ok,update')
self.close_connection
return
else:
self.send_response(403, 'lock is hold by other')
self.close_connection
return
def unlock(self, client_ip):
global lock_client_ip
global lock_time
if lock.acquire():
lock.release()
self.send_response(200, 'ok,unlock')
self.close_connection
return
elif lock_client_ip == client_ip:
lock.release()
lock_time = 0
lock_client_ip = ''
self.send_response(200, 'ok,unlock')
self.close_connection
return
else:
self.send_response(403, 'lock is hold by other')
self.close_connection
return
if __name__ == '__main__':
http_server = BaseHTTPServer.HTTPServer(('127.0.0.1', '88888'), LockService)
http_server.serve_forever()
上面這個例子是基於http協議的短連接，更細致的做法是使用長連接心跳檢測，這樣服務端可以及時檢出連接斷開而釋放鎖。但是，一定要同時確保這個搶占資源的高可用，可以把提供搶占資源的服務做成lingyig高可用的，也可以簡單點，部署3個服務，雙節點上個部署一個，第三個部署在另外一個專門的仲裁節點上，至少獲取3個鎖中的2個才視為取得了鎖。這個仲裁節點可以為很多集群提供仲裁服務（因為一個機器只能部署一個Pacemaker實例，否則可以用部署了N個Pacemaker實例的仲裁節點做同樣的事情。）。但是，如非迫不得已，盡量還是采用前面的方法，即滿足Pacemaker法定票數，這種方法更簡單，可靠。
------ 如何監控"腦裂"情況
1. 在什么服務器上進行"腦裂"情況監控？
在備節點服務器上進行監控，可以使用zabbix監控。
2. 監控什么信息？
備節點服務器上面如果出現vip情況，只可能是下面兩種情況
1）腦裂情況出現。
2）正常主備切換也會出現。
3. 編寫監控腦裂腳本
[root@slave-node scripts]# vim check_keepalived.sh
#!/bin/bash
# 192.168.10.10是VIP地址
while true
do
if [ `ip a show eth0 |grep 192.168.10.10|wc -l` -ne 0 ]
then
echo "keepalived is error!"
else
echo "keepalived is OK !"
fi
done
[root@slave-node scripts]# chmod 755 check_keepalived.sh
4）測試。確保兩個節點的負載均衡能夠正常負載
[root@master-node ~]# curl -H Host:www.kevin.cn 192.168.10.30 server-node01 www [root@master-node ~]# curl -H Host:www.kevin.cn 192.168.10.31 server-node01 www [root@slave-node ~]# curl -H Host:www.bobo.cn 192.168.10.31 server-node02 bbs [root@slave-node ~]# curl -H Host:www.kevin.cn 192.168.10.30 server-node03 www
Keepalived腦裂問題分享一
1）解決keepalived腦裂問題
檢測思路：正常情況下keepalived的VIP地址是在主節點上的，如果在從節點發現了VIP，就設置報警信息。腳本（在從節點上）如下：
[root@slave-ha ~]# vim split-brainc_check.sh
#!/bin/bash
# 檢查腦裂的腳本，在備節點上進行部署
LB01_VIP=192.168.1.229
LB01_IP=192.168.1.129
LB02_IP=192.168.1.130
while true
do
ping -c 2 -W 3 $LB01_VIP &>/dev/null
if [ $? -eq 0 -a `ip add|grep "$LB01_VIP"|wc -l` -eq 1 ];then
echo "ha is brain."
else
echo "ha is ok"
fi
sleep 5
done
執行結果如下：
[root@slave-ha ~]# bash check_split_brain.sh
ha is ok
ha is ok
ha is ok
ha is ok
當發現異常時候的執行結果：
[root@slave-ha ~]# bash check_split_brain.sh
ha is ok
ha is ok
ha is ok
ha is ok
ha is brain.
ha is brain.
2）keepalived腦裂的一個坑（如果啟用了iptables，不設置"系統接收VRRP協議"的規則，就會出現腦裂）
曾經在做keepalived+Nginx主備架構的環境時，當重啟了備用機器后，發現兩台機器都拿到了VIP。這也就是意味着出現了keepalived的腦裂現象，檢查了兩台主機的網絡連通狀態，發現網絡是好的。然后在備機上抓包：
[root@localhost ~]# tcpdump -i eth0|grep VRRP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:10:17.146322 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:17.146577 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:17.146972 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:18.147136 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:18.147576 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:25.151399 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:25.151942 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:26.151703 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:26.152623 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:27.152456 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:27.153261 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:28.152955 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:28.153461 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:29.153766 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:29.155652 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:30.154275 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:30.154587 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:31.155042 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:31.155428 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:32.155539 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:32.155986 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:33.156357 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:33.156979 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:34.156801 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:34.156989 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 備機能接收到master發過來的VRRP廣播，那為什么還會有腦裂現象？ 接着發現重啟后iptables開啟着，檢查了防火牆配置。發現系統不接收VRRP協議。 於是修改iptables，添加允許系統接收VRRP協議的配置： -A INPUT -i lo -j ACCEPT ----------------------------------------------------------------------------------------- 我自己添加了下面的iptables規則： -A INPUT -s 192.168.1.0/24 -d 224.0.0.18 -j ACCEPT #允許組播地址通信 -A INPUT -s 192.168.1.0/24 -p vrrp -j ACCEPT #允許VRRP（虛擬路由器冗余協）通信 ----------------------------------------------------------------------------------------- 最后重啟iptables，發現備機上的VIP沒了。 雖然問題解決了，但備機明明能抓到master發來的VRRP廣播包，卻無法改變自身狀態。只能說明網卡接收到數據包是在iptables處理數據包之前發生的事情。
3）預防keepalived腦裂問題
1. 可以采用第三方仲裁的方法。由於keepalived體系中主備兩台機器所處的狀態與對方有關。如果主備機器之間的通信出了網題，就會發生腦裂，此時keepalived體系中會出現雙主的情況，產生資源競爭。
2. 一般可以引入仲裁來解決這個問題，即每個節點必須判斷自身的狀態。最簡單的一種操作方法是，在主備的keepalived的配置文件中增加check配置，服務器周期性地ping一下網關，如果ping不通則認為自身有問題 。
3. 最容易的是借助keepalived提供的vrrp_script及track_script實現。如下所示：
# vim /etc/keepalived/keepalived.conf
......
vrrp_script check_local {
script "/root/check_gateway.sh"
interval 5
}
......
track_script {
check_local
}
腳本內容：
# cat /root/check_gateway.sh
#!/bin/sh
VIP=$1
GATEWAY=192.168.1.1
/sbin/arping -I em1 -c 5 -s $VIP $GATEWAY &>/dev/null
check_gateway.sh 就是我們的仲裁邏輯，發現ping不通網關，則關閉keepalived服務："service keepalived stop"
4）推薦自己寫腳本
寫一個while循環，每輪ping網關，累計連續失敗的次數，當連續失敗達到一定次數則運行service keepalived stop關閉keepalived服務。如果發現又能夠ping通網關，再重啟keepalived服務。最后在腳本開頭再加上腳本是否已經運行的判斷邏輯，將該腳本加到crontab里面。
Keepalived腦裂問題分享二
在部署Nginx+Keepalived高可用集群配置時可能會出行如下腦裂現象。處理過程如下：
查看兩個節點的日志, 發現Master節點和Backup節點機器都是Mastaer模式啟動的！ [root@Master-Ha ~]# tail -f /var/log/messages ......... ......... Dec 22 20:24:32 Master-Ha Keepalived_healtheckers[22518]：Activating healthchecker for server [xx.xx.xx.xx] Dec 22 20:24:35 Master-Ha Keepalived_keepalived_vrrp[22519]: VRRP_instance(VI_I) Transition to MASTER STATE Dec 22 20:24:38 Master-Ha Keepalived_keepalived_vrrp[22519]: VRRP_instance(VI_I) Entering MASTER STATE Dec 22 20:24:40 Master-Ha Keepalived_keepalived_vrrp[22519]: VRRP_instance(VI_I) setting protocol VIPs Dec 22 20:24:44 Master-Ha Keepalived_healtheckers[22518]：Netlink reflector reports IP xx.xx.xx.xx added ......... ......... [root@Slave-Ha ~]# tail -f /var/log/messages ......... ......... Dec 22 20:24:34 Slave-Ha Keepalived_healtheckers[29803]：Activating healthchecker for server [xx.xx.xx.xx] Dec 22 20:24:37 Slave-Ha Keepalived_keepalived_vrrp[29804]: VRRP_instance(VI_I) Transition to MASTER STATE Dec 22 20:24:40 Slave-Ha Keepalived_keepalived_vrrp[29804]: VRRP_instance(VI_I) Entering MASTER STATE Dec 22 20:24:43 Slave-Ha Keepalived_keepalived_vrrp[29804]: VRRP_instance(VI_I) setting protocol VIPs Dec 22 20:24:47 Slave-Ha Keepalived_keepalived_vrrp[29804]: VRRP_instance(VI_I) Sending gratuitous ARPS on ens160 xx.xx.xx.xx Dec 22 20:24:49 Slave-Ha Keepalived_healtheckers[22518]：Netlink reflector reports IP xx.xx.xx.xx added ......... .........
通過上面查看兩個節點機器的日志，發現VRRP是基於報文實現的！！Master節點會設置一定時間發送一個報文給Backup節點，如果Backup沒有收到就自己成為Master。由此可以推出導致出現上面"腦裂"問題的根源在於Backup沒有收到來自Master發送的報文！所以它自己也成為了Master。
VRRP控制報文只有一種：VRRP通告(advertisement)。它使用IP多播數據包進行封裝，組地址為224.0.0.18，發布范圍只限於同一局域網內。這保證了VRID在不同網絡中可以重復使用。為了減少網絡帶寬消耗只有主控路由器才可以周期性的發送VRRP通告報文。備份路由器在連續三個通告間隔內收不到VRRP或收到優先級為0的通告后啟動新的一輪VRRP選舉。
另外注意：Centos7安裝Keepalived后, 如果不關閉防火牆, 則需要在防火牆中放行VRRP的組播IP 244.0.0.18。否則虛擬ip不能實現漂移,雙機都為Master,不能實現雙機熱備的效果。[類似於上面"分享一"中的情況]
由於不太習慣使用Centos7下默認的Firewall防火牆，可以禁用掉Centos7默認的Firewall防火牆，使用Iptables防火牆進行設置： # systemctl stop firewalld.service # systemctl disable firewalld.service # yum install -y iptables-services # vim /etc/sysconfig/iptables 在文件中添加一下內容 -A OUTPUT -o eth0 -d 224.0.0.18 -j ACCEPT -A OUTPUT -o eth0 -s 224.0.0.18 -j ACCEPT -A INPUT -i eth0 -d 224.0.0.18 -j ACCEPT -A INPUT -i eth0 -s 224.0.0.18 -j ACCEPT # service iptables restart # systemctl enable iptables.service 此時就能實現虛擬ip的漂移，當Master掛掉時，虛擬ip會漂移到Backup上，Master啟動后虛擬ip會再次漂移回來。