高可用解決方案--keepalived
高可用指標=MTBF/(MTBF+MTTR)
MTBF:Mean Time Between Failture [兩次故障平均間隔時間]
MTTR:Mean Time To Restoration [平均恢復時間]
從上訴公式可以得出,要提高系統的高可用性,就需要提高系統的無故障時間(MTBF)和縮短系統修復的時間(MTTR)。
縮短MTTR的辦法:引入冗余機制,當系統某一部分出現故障,備份可以快速替換。因此MTTR主要取決於檢測出故障的時間和完成故障切換的時間。
keepalived的作用:
??①生成ipvs規則;
??②實現IP漂移。
keepalived是VRRP協議在Linux系統上的實現軟件,是為了實現IP漂移。
目錄
- VRRP協議的實現
- keepalived的工作原理
- keepalived的配置文件
- keepalived的主備模型實例
- keepalived的雙主模型實例
- keepalived實現狀態切換時的消息通知
- keepalived實現高可用ipvs
- vrrp script實現特定服務的高可用
1、VRRP協議的實現
VRRP的相關術語
?虛擬路由器:由一個Master路由器和多個Backup路由器組成。通俗講就是一個路由器集群。
?VRID:虛擬路由器標識,如果多個路由器有相同的VRID,那麽這些路由器就組成了一個虛擬路由器。
?Master路由器:虛擬路由器中真正承擔報文轉發的節點。
?Backup路由器:虛擬路由器中某一時刻除Master路由器的其他都有節點。
?虛擬MAC地址:虛擬路由器擁有的MAC地址,其格式為00-00-5E-00-01-VRID。
?優先級:VRRP根據每個節點的優先級確定節點在虛擬路由器中的地位。如果優先級相同,則根據節點的IP地址大小進行比較。
?搶占方式和非搶占方式:搶占方式中只要優先級最高才會成為Master路由器,而非搶占方式中只要Master路由器沒有出現故障,則Baskup路由器的優先級再高也不會成為Master路由器。
VRRP協議的工作原理
可以參考VRRP協議工作原理
2、keepalived的工作原理
keepalived的核心組件
Checkers
VRRP Stack
:這是keepalived實現VRRP功能的模塊,VRRP功能可以實現對前端調度器集群的故障切換(failover)。SMTP
:Checkers和VRRP Stack都是對節點進行狀態監測,不同的是監測前端調度器和監測後端RS,但是這兩個模塊都可以通過SMTP通知管理員故障信息的郵件。System Call
:Checkers和VRRP Stack同樣都可以調用系統內核功能完成故障隔離和故障切換。IPVS wrapper
:Checkers通過監測後端RS的工作狀態得出信息,IPVS wrapper通過這些信息添加ipvs規則,內核中的IPVS則通過這些規則進行工作。Netlink Reflector
:在調度器發生故障切換的時候,該模塊充當調用內核NETLINK的接口,完成虛擬IP的設置和切換。Watch Dog
:keepalived的核心模塊就是Checkers和VRRP Stack,當這兩個模塊發生故障的時候怎麽辦呢,這時候Watch Dog就發生了作用,它是一個硬件檢測工具,一旦Checkers和VRRP Stack發生故障,Watch Dog就能夠檢測到並采取恢復措施(重啟)。
3、keepalived的配置文件
配置文件的結構層次
keepalived的配置文件分為三個部分,分別是:
?Global Configuration:全局配置部分
??Global definition
??static routes/address
?VRRPD Configuration:VRRPD配置部分
??VRRP instance:VRRP實例配置
??VRRP synchronization group:VRRP同步組
?LVS Configuration:LVS配置部分
??Virtual server:ipvs的RS和VS
全局配置的常用參數
參數 | 含義 |
---|---|
global_defs {...} | 全局配置區域,該參數是全局配置開始的標識 |
notification_email{...} | 設置接受郵件報警的地址。即指明郵件的接收人是誰 |
smtp_server | 設置連接郵件服務器的超時時間 |
smtp_connnet_timeout | 全局配置區域,該參數是全局配置開始的標識 |
notification_email_from | 設置郵件的發送地址。即指明郵件的發件人是誰 |
vrrp_mcast_group4 | 設置組播地址,4代表ipv4 |
router_id | 表示運行一個keepalived服務的標識 |
VRRPD配置的常用參數
??VRRP實例參數
參數 | 含義 |
---|---|
vrrp_instance | VRRP實例開始的標識,後面跟實例的名稱 |
state | 指明keepalived的角色,MASTER或者BACKUP |
interface | 指定keepalived在高可用集群中監控的網絡接口 |
virtual_router_id | 自定義的虛擬路由器標識,在同一個VRRP實例中,MASTRE和BACKUP的標識號必須一樣 |
priority | 定義高可用集群中節點的優先級,值越大優先級越高,範圍是1-254 |
advert_int | 高可用集群中主備節點之間發送心跳信息的時間間隔 |
authentication{...} | 設置高可用集群中節點之間通信時的驗證類型和驗證密碼,MASTER和BACKUP之間只有驗證密碼相同才能通信 |
virtual_ipaddress{...} | 設置虛擬IP地址,例如192.168.239.105/24 dev eth1 |
track_interface{...} | 定義要監控的網絡接口,當網卡出現故障的時候,節點的狀態變為FAULT |
nopreempt | 定義為非搶占模式 |
preempt_delay | 定義為搶占模式,並且定義節點上線後多長的時間延遲後觸發選舉操作,保證不會讓新節點剛上線就去搶占 |
notify_master | 當當前節點的keepalived進入MASTER狀態的時候觸發的腳本,格式為notify_master "script-location arg1 arg2 ..." |
notify_backup | 當前節點的keepalived進入BACKUP狀態的時候觸發的腳本,格式為notify_backup"script-location arg1 arg2 ..." |
notify_fault | 當前節點的keepalived進入FAULT狀態的時候觸發的腳本,格式類似 |
notify_stop | 當前節點的keepalived終止的時候觸發的腳本,格式類似 |
上訴notify相關的四個參數,一般用於狀態監控通知的腳本。
4、keepalived主備模型實例
在主備模型中的所有節點中,某一時刻只允許有一個節點處於MASTER狀態,其他節點均為BACKUP狀態。工作中只有MASTER節點會接受請求,BACKUP狀態的節點處於閑置狀態。只有在MASTER出現故障的時候,BACKUP節點才會重新選舉出新的節點進入MASTER狀態。
主節點的配置文件內容如下:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node1
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state MASTER # 初始化設置為MASTER節點
interface eth1
virtual_router_id 50 # 同一個VRRP實例中每個節點的虛擬路由ID必須相同
priority 100 # MASTER節點的優先級必須高於BACKUP節點
advert_int 1
authentication {
auth_type PASS # 驗證類型為密碼認證
auth_pass 1111qwer # 驗證密碼,需要註意密碼最大長度為8位
}
virtual_ipaddress {
192.168.239.250/24 dev eth1 # 主備節點的VIP一定要相同
}
}
Backup節點的配置文件內容如下:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node1
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 50
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
關閉防火墻和SELinux。
開啟兩個節點的keepalived服務。
[root@Master ~]# /etc/init.d/keepalived restart
Starting keepalived: [ OK ]
[root@Backup ~]# /etc/init.d/keepalived start
Starting keepalived: [ OK ]
查看主節點的日誌信息
查看備節點的日誌信息
利用命令ip a
查看主節點的ip狀態,可以看到VIP已經配置到了eth1網卡上
備節點因為處於BACKUP狀態,則沒有獲得VIP。
arp 192.168.239.250命令也可以看出VIP的MAC地址為主節點eth1網卡的MAC地址。
現在將主節點中的keepalived.conf中的優先級參數設置為80(低於備節點),然後重啟主節點的keepalived服務。再次查看IP狀態和ARP緩存表信息。
並且VIP對應的MAC地址也發生了變化。說明IP漂移已經實現。
5、keepalived雙主模型實例
在keepalived的主備模型中,當主節點正常的時候,備節點永遠處於閑置狀態,不會接受web請求,這樣就會浪費一半的資源。因此可以使用keepalived的雙主模型實例,使得其中的兩個節點都能夠接受web請求,這要求節點1在一個vrrp實例處於master狀態,在另一個vrrp實例中處於backup狀態;節點2在一個vrrp實例中處於backup狀態,在另一個vrrp實例中處於master狀態。
節點1的配置文件內容如下:
[root@Master ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node1
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
vrrp_instance VI_2 {
state BACKUP
interface eth1
virtual_router_id 52
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
virtual_ipaddress {
192.168.239.150/24 dev eth1
}
}
節點2的配置文件內容如下:
[root@Backup ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node2
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 50
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
virtual_ipaddress {
192.168.239.250/24 dev eth1 # VIP1的信息
}
}
vrrp_instance VI_2 {
state MASTER
interface eth1
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
virtual_ipaddress {
192.168.239.150/24 dev eth1 # VIP2的信息
}
}
節點1的VIP1信息:
節點2的VIP2信息:
當節點1的keepalived停止,節點1的VIP移除,效果如下:
節點2獲得兩個VIP,如圖:
6、keepalived狀態切換時的消息通知
當keepalived的狀態發生變化的時候,往往需要通知管理員,這個時候就需要借助notify_master、notify_backup、notify_fault三個參數,進而配合腳本來實現keepalived的消息通知機制。這三個參數的使用規範上面有說過。
實驗中每個節點使用同一個腳本,腳本內容如下:
腳本的主要功能是當keepalived的狀態發生轉換之後,keepalived會給指定收件人發送通知郵件,告訴收件人哪個節點切換為什麽狀態。
#!/bin/bash
#
recipient="root@localhost"
notify () {
local mailsubject="$(hostname) to be $1 and VIP floating"
local mailbody="$(date ‘+%F %T‘):vrrp transation,$(hostname) changed to be $1"
echo "$mailbody" | mail -s "$mailsubject" $recipient
}
case $1 in
master)
notify master
;;
backup)
notify backup
;;
fault)
notify fault
;;
*)
echo "Usage:$(basename $0) {master|backup|fault}"
exit 1
;;
esac
該實驗使用的是主備模型,其中主節點的配置文件內容如下:
[root@Master ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node1
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
track_interface {
eth1
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
備節點的配置文件內容如下:
[root@Backup ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node2
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 50
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
track_interface {
eth1
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
現在啟動主備節點的keepalived服務,其中主節點獲得VIP,進入MASTER狀態,備節點進入BACKUP狀態。然後每個節點會收到相對應的通知郵件。可以使用mail命令查看,該命令是由mailx軟件提供的。
對於keepalived的FAULT狀態,該狀態與keepalived監控的網絡接口有關,如果節點的網卡出現故障,則keepalived會進入FAULT狀態,暫停主節點的網卡,然後系統會受到通知郵件,如下圖,通知keepalived進入FAULT狀態。
[root@Master ~]# ifdown eth1
7、keepalived實現高可用ipvs
keepalived的另一個重要的配置段是關於LVS的配置,LVS配置段是實現LVS高可用功能。該配置段以virtual_server為開始標識。
LVS配置段參數 | 具體含義 |
---|---|
virtual_server | LVS配置段開始標識,格式為virtual_server vip port {...} |
delay_loop | 對後端服務器集群進行健康狀態監測的時間間隔,單位是秒 |
lb_algo | 定義負載均衡的調度算法,有rr,wrr,lc,wlc,lblc,sh,dh等 |
lb_kind | 定義LVS的工作模式,有NAT、DR和TUN三種模式 |
persistence_timeout | 定義ipvs的持久連接時長 |
protocol | ipvs服務的協議類型,目前keepalived僅支持ipvs的TCP協議 |
sorry_server | 指定備用後端服務器的IP地址,僅在所有real server失效後,備用節點才會生效,格式為sorryserver ip port |
real_server | 後端真實服務器的配置段的開始標識,格式為realserver ip port {...} |
real_server段配置參數 | 具體含義 |
---|---|
weight | 設置後端服務器節點的權值,數字越大權值越大 |
notify_up | 當後端節點切換為UP狀態觸發的腳本,格式為notifyup scriptlocation arg1 arg2 ...,功能類似於notify_master參數 |
notify_down | 當後端節點切換為DOWN狀態觸發的腳本 |
健康監測段配置 | HTTP_GET、SSL_GET、TCP_CHECK、SMTP_CHECK、MISC_CHECK |
健康監測端配置參數 | 具體含義 |
---|---|
HTTP_GET、SSL_GET | 這兩個參數是基於應用層的檢測方式,格式為HTTP_GET {...} |
TCP_CHECK | 基於四層的監測方式,格式為TCP_CHECK {...} |
應用層檢測配置段的參數:
HTTP_GET|SSL_GET {
??url {
????path /index.html
????status_code 200
????digest xxxxxxxx
??}
??nb_get_retry 3
??delay_before_retry 2
??connect_ip
??connect_port
??bindto
??bind_port
??connect_timeout
}
url:指定HTTP/SSL監控的URL信息.
path:定義要監控的詳細的URL
status_code:指定返回http檢測正常的狀態碼類型,就是當返回指定的狀態碼時即可認定節點正常,一般為200。
digest:status_code定義的狀態碼並不準確,即使返回200的狀態碼,還是有網頁內容被篡改的可能,這樣就無法發現錯誤信息,因此加入了digest參數,對網頁內容的摘要信息進行比對,如果一致則認為頁面沒有發生改變。該摘要信息可以使用命令genhash生成。
genhash -s 192.168.239.129 -p 80 -u /index.html
nb_get_retry:重試的次數
delay_before_retry:重試之前等待的時間延遲,即兩次重試之間的間隔,單位是秒
上邊的兩個參數是在檢測到錯誤信息之後才會生效。
connect_ip:向當前RS的哪個IP地址發送健康狀態監測信息
connect_port:向當前RS的哪個端口發送健康狀態監測信息
如果connect_ip和connect_port都沒有指定,則默認使用real_server參數指定的IP和port。
bindto:指定負載均衡器對RS發送健康狀態監測的源IP地址
bind_port:指定負載均衡器對RS發送健康狀態監測的源端口
connect_timeout:定義健康狀態監測的連接超時時間
基於四層監測配置段參數:
TCP_CHECK {
??connect_ip
??connect_port
??bindto
??bind_port
??connect_timeout
}
keepalived的LVS段配置實例
實驗環境:
主機名 | IP地址 | 備註信息 |
---|---|---|
Master.linux.com | 192.168.239.137 | keepalived的主節點 |
Backup.linux.com | 192.168.239.138 | keepalived的備節點 |
Web1.linux.com | 192.168.239.129 | RS1 |
Web2.linux.com | 192.168.239.133 | RS2 |
---- | 192.168.239.250 | VIP,基於keepalived的主備模型 |
開始該實驗之前先暫停上面實驗的keepalived的服務。
第一步:
配置後端真實服務器集群的每個節點,其中的HTTP服務使用Nginx實現,具體Nginx的操作可以參考博客Nginx使用,並且設置Web1.linux.com節點的首頁文件index.html的內容為This is web1 with 80 。Web2.linux.com節點的首頁文件index.html的內容為This is web2 with 80。
當出現下圖所示的頁面內容的時候表示RS集群的http服務配置成功。
第二步:
該實驗中基於LVS的DR模型,因此需要設置RS的VIP地址和ARP抑制參數等。我這裏使用腳本。
[root@Web1 data]# cat arp_depress.sh
#!/bin/bash
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
ifconfig lo:0 192.168.239.250 broadcast 192.168.239.250 netmask 255.255.255.255 up
route add -host 192.168.239.250 dev lo:0
然後在兩個RS節點上分別運行該腳本,運行效果如下:
到目前為止,客戶端ping VIP-192.168.239.250,結果顯示無法訪問目標主機。說明ARP抑制已經實現。
第三步:
配置keepalived的兩個節點的配置文件 ,配置內容是在4、keepalived的主備模型和6、keepalived的狀態切換時的消息通知機制的基礎上增加virtual_server配置段來完成的。
主節點的配置文件內容:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node1
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
track_interface {
eth1
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
# LVS配置段
virtual_server 192.168.239.250 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 192.168.239.129 80 {
weight 1
HTTP_GET {
url {
path /index.html
status 200
}
nb_get_retry 3
delay_before_retry 2
connect_ip 192.168.239.129
connect_port 80
bindto 192.168.239.137
bind_port 80
connnect_timeout 6
}
}
real_server 192.168.239.133 80 {
weight 1
HTTP_GET {
url {
path /index.html
status 200
}
nb_get_retry 3
delay_before_retry 2
connect_ip 192.168.239.133
connect_port 80
bindto 192.168.239.137
bond_port 80
connect_timeout 6
}
}
}
備節點的配置文件內容:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node2
vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 50
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
track_interface {
eth1
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
virtual_server 192.168.239.250 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 192.168.239.129 80 {
weight 1
HTTP_GET {
url {
path /index.html
status 200
}
nb_get_retry 3
delay_before_retry 2
connect_ip 192.168.239.129
connect_port 80
# 發送檢測消息的源地址和端口是調度器的真實IP,不是VIP
bindto 192.168.239.138
bind_port 80
connnect_timeout 6
}
}
real_server 192.168.239.133 80 {
weight 1
HTTP_GET {
url {
path /index.html
status 200
}
nb_get_retry 3
delay_before_retry 2
connect_ip 192.168.239.133
connect_port 80
bindto 192.168.239.138
bond_port 80
connect_timeout 6
}
}
}
第四步:
配置整個集群中的備用節點,也即sorry_server參數,假設這樣的場景,後端RS集群的每個節點都出現故障,這時候就需要備用節點返回響應內容。這裏將sorry_server配置為keepalived的兩個節點。因此在第三步的兩個keepalived節點中設置sorryserver 127.0.0.1 80,並且兩個備用節點都返回相同的頁面內容“This web is maintaining”。
主節點的操作流程:
[root@Master ~]# yum -y install httpd
[root@Master ~]# vim /var/www/html/index.html
This web is maintaining
[root@Master ~]# /etc/init.d/httpd start
備節點的操作流程:
[root@Backup ~]# yum -y install httpd
[root@Backup ~]# vim /var/www/html/index.html
This web is maintaining
[root@Backup ~]# /etc/init.d/httpd start
效果圖如下:
第五步:
接下來開啟主備節點的keepalived服務。
[root@Master ~]# /etc/init.d/keepalived start
Starting keepalived: [ OK ]
[root@Backup ~]# /etc/init.d/keepalived start
Starting keepalived: [ OK ]
然後訪問VIP地址,結果會返回後端RS的頁面內容,並且每次刷新頁面內容會發生變化。說明LVS的負載均衡已經實現。並且利用ipvsadm工具也可以查看到主備節點已經生成了ipvs規則。
第六步:
測試,暫停主節點的keepalived服務,瀏覽器能夠繼續返回頁面內容,
現在暫停兩個RS節點的http服務,然後繼續訪問VIP地址,結果返回是備用節點的信息。說明sorry_server已經實現。
8、vrrp script實現特定服務的高可用
keepalived本身是由三個配置段組成的,分別是全局配置段、VRRP配置段和LVS配置段。VRRP配置段是用來實現IP地址(VIP)漂移的,LVS配置段是用來實現生成ipvs規則的。keepalived的基本功能僅此而已,總之keepalived的基本功能就是實現LVS的高可用,如果要實現特定服務的高可用功能,就需要借助腳本來實現。例如通過keepalived實現Nginx、Apache、mysql等特定服務的高可用,則需要編寫相應的監控腳本。
腳本中priority和weight參數的關系
vrrp script在keepalived的配置文件的格式為:
vrrp_script check_server-name {
??script " ... "
??interval ...
??weight <+|-int>
}
check_script {
??check_server-name
}
其中集群中MASTER和BACKUP角色進行切換,是由priority和weight共同決定的。weight的絕對值一定為整數。
一、weight為正數(+int):
① 腳本執行成功,MASTER節點的priority和int之和小於BACKUP節點的priority和int之和,則發生角色切換;
② 腳本執行失敗,MASTER節點的priority和int之和大於BACKUP節點的priority和int之和,則不發生角色切換。
二、weight為負數(-int):
① 腳本執行失敗,MASTER節點的priority和int之差小於BACKUP節點的priority,則發生角色切換;
② 腳本執行成功,MASTER節點的priority和int之差大於BACKUP節點的priority,則不發生角色切換。
因此為了保證weight的值能夠保證腳本在成功與失敗後觸發主備切換,通常設置weight的絕對值大於主備節點priority之差
vrrp script實現Apache的http服務高可用
實驗環境:
主機名 | IP地址 | 集群中的服務 |
---|---|---|
Master.linux.com | 192.168.239.137 | http服務 |
Backup.linux.com | 192.168.239.138 | http服務 |
---- | 192.168.239.250 | 虛擬IP |
第一步:
配置兩個節點的http服務,這裏使用Apache,為了顯示請求確實發生了跳轉,將兩個節點的http主頁設置為不同的內容。
Master.linux.com節點的頁面內容:
[root@Master ~]# cat /var/www/html/index.html
This is web1
Backup.linux.com節點的頁面內容:
[root@Backup ~]# cat /var/www/html/index.html
This is web2
然後開啟兩個節點的http服務。
第二步:
配置兩個節點的keepalived配置文件和腳本文件,腳本思路:原本主節點的權值為100,備節點的權值為90,各個節點每隔一秒監控各自的http服務是否正常,如果主節點的http服務發生異常,則權值減少20(即降低至80),這樣80小於90,MASTER會變為權值90的節點。內容如下,
Master.linux.com:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node1
vrrp_mcast_group4 224.0.199.32
}
# 監控http服務的腳本
vrrp_script check_httpd {
# script "<腳本內容或者腳本文件>"
script "killall -0 httpd" # 檢測httpd進程是否運行,這裏前邊的script參數比不可少
interval 1 # 腳本運行一次的時間間隔
weight -20 # httpd進程出現異常後,該節點keepalived的權值減少20,原本權值為100
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
track_interface {
eth1
}
track_script {
check_httpd
}
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
Backup.linux.com:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 10
router_id node2
vrrp_mcast_group4 224.0.199.32
}
vrrp_script check_httpd {
script "killall -0 httpd"
internal 1
weight -20
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 50
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111qwer
}
track_interface {
eth1
}
track_script {
check_httpd
}
virtual_ipaddress {
192.168.239.250/24 dev eth1
}
}
然後依次開啟Master.linux.com和Backup.linux.com的keepalived服務。利用抓包工具tcpdump可以看到是主節點(權值100)在發送心跳信息。
通過瀏覽器訪問VIP,在會返回主節點的網頁內容。
第三步:
關閉主節點的http服務(註意是http服務,不是上面實驗做的關閉keepalived服務),抓包工具可以看到主節點的權值降低為80,然後權值90的節點獲得VIP進入MASTER狀態。
瀏覽器繼續訪問VIP,此時網頁內容已經自動跳轉到新的主節點(Backup.linux.com)。
這樣keepalived就可以實現Apache的高可用。
高可用解決方案--keepalived