高可用解決方案--keepalived

阿新 • • 發佈：2018-08-19

文件的分享圖片 ali 頁面 url 主備引入 base 摘要

高可用指標=MTBF/(MTBF+MTTR)
MTBF：Mean Time Between Failture [兩次故障平均間隔時間]
MTTR：Mean Time To Restoration [平均恢復時間]

從上訴公式可以得出，要提高系統的高可用性，就需要提高系統的無故障時間（MTBF）和縮短系統修復的時間（MTTR）。
縮短MTTR的辦法：引入冗余機制，當系統某一部分出現故障，備份可以快速替換。因此MTTR主要取決於檢測出故障的時間和完成故障切換的時間。

keepalived的作用：
??①生成ipvs規則；
??②實現IP漂移。
keepalived是VRRP協議在Linux系統上的實現軟件，是為了實現IP漂移。

1、VRRP協議的實現

VRRP的相關術語

?虛擬路由器：由一個Master路由器和多個Backup路由器組成。通俗講就是一個路由器集群。
?VRID：虛擬路由器標識，如果多個路由器有相同的VRID，那麽這些路由器就組成了一個虛擬路由器。
?Master路由器：虛擬路由器中真正承擔報文轉發的節點。
?Backup路由器：虛擬路由器中某一時刻除Master路由器的其他都有節點。

?虛擬IP（VIP）：虛擬路由器的IP，VIP是用於客戶接入的IP地址。
?虛擬MAC地址：虛擬路由器擁有的MAC地址，其格式為00-00-5E-00-01-VRID。
?優先級：VRRP根據每個節點的優先級確定節點在虛擬路由器中的地位。如果優先級相同，則根據節點的IP地址大小進行比較。
?搶占方式和非搶占方式：搶占方式中只要優先級最高才會成為Master路由器，而非搶占方式中只要Master路由器沒有出現故障，則Baskup路由器的優先級再高也不會成為Master路由器。

VRRP協議的工作原理

可以參考VRRP協議工作原理

2、keepalived的工作原理

keepalived的核心組件

技術分享圖片
Checkers

：對後端服務器節點（RS）進行健康狀態監測和故障隔離，我們知道，LVS本身是沒有健康狀態監測功能，keepalived起初就是為LVS生成ipvs規則和增加健康狀態檢測功能而設計的。
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

文件的分享圖片 ali 頁面 url 主備引入 base 摘要高可用指標=MTBF/(MTBF+MTTR)MTBF：Mean Time Between Failture [兩次故障平均間隔時間]MTTR：Mean Time To Restoration [平均恢復時間

高可用解決方案--keepalived

目錄

1、VRRP協議的實現

VRRP的相關術語

VRRP協議的工作原理

2、keepalived的工作原理

keepalived的核心組件

3、keepalived的配置文件

配置文件的結構層次

全局配置的常用參數

VRRPD配置的常用參數

??VRRP實例參數

4、keepalived主備模型實例

5、keepalived雙主模型實例

6、keepalived狀態切換時的消息通知

7、keepalived實現高可用ipvs

8、vrrp script實現特定服務的高可用

腳本中priority和weight參數的關系

vrrp script實現Apache的http服務高可用

高可用解決方案--keepalived

紅帽5、紅帽6、紅帽7 高可用解決方案的組合程序

MySQL高可用解決方案---MHA

MYSQL高可用解決方案：PHXSQL（騰訊微信）編譯實錄

北京三木聯合---雙機雙櫃高可用解決方案

這可能是史上最全 Redis 高可用解決方案總結

高可用開源方案 Keepalived VS Heartbeat對比

雲資料庫高可用解決方案技術解析

基於Docker的高可用解決方案

mysql高可用解決方案MHA架構

AnTiPro專業為棋牌遊戲提供高防解決方案

我們賣的不是高防服務器，而是高防解決方案！

負載均衡器HAProxy,高可用集群keepalived,keepalived+lvs

Linux集群概述及高可用軟件keepalived配置、測試

Redis 高可用基於Sentinel + keepalived 實現

大規模分散式應用之海量資料和高併發解決方案總結視訊教程網盤

Keepalivaed +Nginx proxy 高可用架構方案與實施過程細節

高併發解決方案（負載均衡）

高併發解決方案 -負載均衡

（五）mysql高可用搭建，keepalived配置

高可用解決方案--keepalived

目錄

1、VRRP協議的實現

VRRP的相關術語

VRRP協議的工作原理

2、keepalived的工作原理

keepalived的核心組件

3、keepalived的配置文件

配置文件的結構層次

全局配置的常用參數

VRRPD配置的常用參數

??VRRP實例參數

4、keepalived主備模型實例

5、keepalived雙主模型實例

6、keepalived狀態切換時的消息通知

7、keepalived實現高可用ipvs

8、vrrp script實現特定服務的高可用

腳本中priority和weight參數的關系

vrrp script實現Apache的http服務高可用

相關推薦