keepalived主要是通過虛擬路由冗餘來實現高可用功能。本文將不對keepalived的基本原理進行闡述,可參考文章keepalived詳細介紹簡介、keepalived vip漂移基本原理及選舉演算法。本文記錄了在實踐過程中使用keepalived時,在weight值變化的情況下vip不漂移的問題及解決方法。
3個keepalived節點, vip為172.31.23.6:
三個節點初始都設為backup,按照優先順序(priority)選舉master;
在三個節點上檢查memcached服務狀態,失敗則降低優先順序;
如果master(假設為devops1a-zoocassa0)上檢查失敗,backup上檢查成功,則優先順序高的backup節點(假設為devops1a-zoocassa1)切換為master節點;
之前檢查失敗的master(devops1a-zoocassa0)上的服務恢復時, 之前的backup節點(devops1a-zoocassa1)服務檢查也成功,即使devops1a-zoocassa0優先順序恢復到高於devops1a-zoocassa1,也不再成為master(不搶占)。
# devops1a-zoocassa0
vrrp_script chk_memcached
vrrp_instance vi_1
virtual_ipaddress
track_script
}
# devops1a-zoocassa1
vrrp_script chk_memcached
vrrp_instance vi_1
virtual_ipaddress
track_script
}
# devops1a-zoocassa2
vrrp_script chk_memcached
vrrp_instance vi_1
virtual_ipaddress
track_script
}
以上述配置檔案內容作為keepalived配置檔案/etc/keepalived/keepalived.conf,在三個節點上啟動keepalived:
service keepalived start
會發現存在如下問題:
優先順序高的devops1a-zoocassa0可能沒有成為master節點(多試幾次,可能每次選舉的master節點都不同),不符合預期中的第1點;
假設devops1a-zoocassa0成為了master節點,關掉devops1a-zoocassa0上的memcached服務:
service memcached stop
此時執行service keepalived status,發現devops1a-zoocassa0的weight值降低且低於devops1a-zoocassa1,但是devops1a-zoocassa1並沒有成為master節點,不符合預期中的第3點。
將配置檔案中的nopreempt去掉以後,可以解決上述問題,符合預期中的第1,2,3點,但是當原master節點上服務恢復後,原master會重新成為master角色,這不符合預期中的第4點(不搶占);
在網上查閱到的資料中,大都認為按照上述配置後可以完全符合預期中的4個點,不會出現master節點服務檢查失敗後vip不漂移的問題。但是實踐是檢驗真理的唯一標準,配置nopreemt後,不僅是會讓原master節點服務恢復後不搶占,而是會完全的不選舉新master(從頭到尾永遠不切換,除非backup認為當前集群中不存在master, 才會重新選舉),這樣便可以解發布現的問題1和問題2了:
問題1的原因在於:
先啟動的節點將自己選舉為master, 在收到其他節點的vrrp報文後不會按照優先順序調整自己的角色;
後啟動的節點收到了master的vrrp報文,發現已經存在master,由於不搶占,自動進入backup狀態;
問題2的原因在於:
設定了nopreempt, 永遠不發生角色切換;
下面是官方文件中對於nopreempt的解釋:
"nopreempt" allows the lower priority machine to maintain the master role,
even when a higher priority machine comes back online.
note: for this to work, the initial state of this entry must be backup.
要想同時滿足預期中的效果,其實只要做到兩點:
當master上的服務檢查失敗時,觸發重新選舉;
設定不搶占(已經做到);
那麼如何實現第一點呢?重新選舉意味著:
backup成為master,要求backup節點認為當前節點中沒有master節點;
master成為backup,要求master節點感知到環境中存在別的master節點,從而進入backup狀態;
節點之間通過vrrp報文獲得相互的優先順序及狀態資訊,因此,可以通過在服務檢查失敗時,配置防火牆,禁止本機的vrrp報文發出即可。這樣,backup節點收不到master節點的vrrp報文,認為master節點不存在,同時master節點能收到其他節點的vrrp報文,感知到新master的產生,從而進入backup狀態。
配置如下(僅以devops1a-zoocassa0為例,其他節點類推):
# devops1a-zoocassa0 /etc/keepalived/keepalived.conf
vrrp_script chk_memcached
vrrp_instance vi_1
virtual_ipaddress
track_script
}
# devops1a-zoocassa0 /etc/keepalived/chk_memcached.sh
#!/bin/bash
killall -0 memcached #檢查memcached服務
if [[ $? == 0 ]];then #檢查成功
/sbin/iptables -l | grep vrrp
if [[ $? == 0 ]]; then #如果iptable中有vrrp的配置,刪除它
/sbin/iptables -d output -p vrrp -j drop
fiexit 0
else #檢查失敗
/sbin/iptables -l | grep vrrp
if [[ $? != 0 ]]; then
/sbin/iptables -a output -p vrrp -j drop #如果iptable中沒有vrrp的條目,禁止vrrp發出
fiexit 1
fi
重啟keepalived服務,測試成功。 keepalived 不搶占模式
ha 的實際執行過程中,當主機發生異常,且後期恢復正常後,存在搶占或非搶占兩種情況。結合實際需求,可能有很多使用者需要非搶占的ha工作模式。keepalived能夠很好的支援這一需求。下面直接展示keepalived的非搶占配置。主機配置如下 vrrp instance vi 1 virtual i...
Keepalived設定不搶占資源
keepalived做ha時,經常會遇到搶占式的master和backup之間的切換 example 通常如果master服務死掉後backup會變成master,但是當master服務又好了的時候 master此時會搶占vip,這樣就會發生兩次切換對業務繁忙的 來說是不好的。所以我們要在配置檔案加...
Keepalived監測指令碼一直不執行
今天在搭建nginx keepalived集群時,啟動keepalievd發現檢查指令碼不執行,指令碼本身是沒有問題的。a ps c nginx no header wc l if a eq 0 then root nginx sbin nginx if ps c nginx no header w...