第1章 keepalived服務說明
1.1 keepalived是什么？
Keepalived軟件起初是專為LVS負載均衡軟件設計的，用來管理並監控LVS集群系統中各個服務節點的狀態，后來又加入了可以實現高可用的VRRP功能。因此，Keepalived除了能夠管理LVS軟件外，還可以作為其他服務（例如：Nginx、Haproxy、MySQL等）的高可用解決方案軟件。
Keepalived軟件主要是通過VRRP協議實現高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗余協議）的縮寫，VRRP出現的目的就是為了解決靜態路由單點故障問題的，它能夠保證當個別節點宕機時，整個網絡可以不間斷地運行。
所以，Keepalived 一方面具有配置管理LVS的功能，同時還具有對LVS下面節點進行健康檢查的功能，另一方面也可實現系統網絡服務的高可用功能。
keepalived官網http://www.keepalived.org
1.2 keepalived服務的三個重要功能
管理LVS負載均衡軟件
實現LVS集群節點的健康檢查中
作為系統網絡服務的高可用性（failover）
1.3 Keepalived高可用故障切換轉移原理
Keepalived高可用服務對之間的故障切換轉移，是通過 VRRP (Virtual Router Redundancy Protocol ,虛擬路由器冗余協議）來實現的。
在 Keepalived服務正常工作時，主 Master節點會不斷地向備節點發送（多播的方式）心跳消息，用以告訴備Backup節點自己還活看，當主 Master節點發生故障時，就無法發送心跳消息，備節點也就因此無法繼續檢測到來自主 Master節點的心跳了，於是調用自身的接管程序，接管主Master節點的 IP資源及服務。而當主 Master節點恢復時，備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。
那么，什么是VRRP呢？
VRRP ,全 稱 Virtual Router Redundancy Protocol ,中文名為虛擬路由冗余協議 ，VRRP的出現就是為了解決靜態踣甶的單點故障問題，VRRP是通過一種競選機制來將路由的任務交給某台VRRP路由器的。
1.4 keepalived 原理
1.4.1keepalived高可用架構示意圖
1.4.2 文字，表述
Keepalived的工作原理：
Keepalived高可用對之間是通過VRRP通信的，因此，我們從 VRRP開始了解起：
1) VRRP,全稱 Virtual Router Redundancy Protocol,中文名為虛擬路由冗余協議，VRRP的出現是為了解決靜態路由的單點故障。
2) VRRP是通過一種竟選協議機制來將路由任務交給某台 VRRP路由器的。
3) VRRP用 IP多播的方式（默認多播地址（224.0_0.18))實現高可用對之間通信。
4) 工作時主節點發包，備節點接包，當備節點接收不到主節點發的數據包的時候，就啟動接管程序接管主節點的開源。備節點可以有多個，通過優先級競選，但一般 Keepalived系統運維工作中都是一對。
5) VRRP使用了加密協議加密數據，但Keepalived官方目前還是推薦用明文的方式配置認證類型和密碼。
介紹完 VRRP,接下來我再介紹一下 Keepalived服務的工作原理：
Keepalived高可用對之間是通過 VRRP進行通信的， VRRP是遑過競選機制來確定主備的，主的優先級高於備，因此，工作時主會優先獲得所有的資源，備節點處於等待狀態，當主掛了的時候，備節點就會接管主節點的資源，然后頂替主節點對外提供服務。
在 Keepalived服務對之間，只有作為主的服務器會一直發送 VRRP廣播包,告訴備它還活着，此時備不會槍占主，當主不可用時，即備監聽不到主發送的廣播包時，就會啟動相關服務接管資源，保證業務的連續性.接管速度最快可以小於1秒。
第2章 keepalived軟件使用
2.1 軟件的部署
2.1.1 第一個里程碑 keepalived軟件安裝
yum install keepalived -y
/etc/keepalived /etc/keepalived/keepalived.conf #keepalived服務主配置文件 /etc/rc.d/init.d/keepalived #服務啟動腳本 /etc/sysconfig/keepalived /usr/bin/genhash /usr/libexec/keepalived /usr/sbin/keepalived
第二個里程碑： 進行默認配置測試
2.1.2 配置文件說明
1-13行表示全局配置
global_defs { #全局配置
notification_email { 定義報警郵件地址
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc #定義發送郵件的地址
smtp_server 192.168.200.1 #郵箱服務器
smtp_connect_timeout 30 #定義超時時間
router_id LVS_DEVEL #定義路由標識信息，相同局域網唯一
}
15-30行 虛擬ip配置 brrp
vrrp_instance VI_1 { #定義實例
state MASTER #狀態參數 master/backup 只是說明
interface eth0 #虛IP地址放置的網卡位置
virtual_router_id 51 #同一家族要一直，同一個集群id一致
priority 100 # 優先級決定是主還是備 越大越優先
advert_int 1 #主備通訊時間間隔
authentication { # ↓
auth_type PASS #↓
auth_pass 1111 #認證
} #↑
virtual_ipaddress { #↓
192.168.200.16 設備之間使用的虛擬ip地址
192.168.200.17
192.168.200.18
}
}
配置管理LVS
2.1.3 最終配置文件
主負載均衡服務器配置
[root@lb01 conf]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id lb01 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.3 } }
備負載均衡服務器配置
[root@lb02 ~]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id lb02 } vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.3 } }
2.1.4 啟動keepalived
[root@lb02 ~]# /etc/init.d/keepalived start Starting keepalived: [ OK ]
2.1.5 【說明】在進行訪問測試之前要保證后端的節點都能夠單獨的訪問。
測試連通性. 后端節點
[root@lb01 conf]# curl -H host:www.etiantian.org 10.0.0.8 web01 www [root@lb01 conf]# curl -H host:www.etiantian.org 10.0.0.7 web02 www [root@lb01 conf]# curl -H host:www.etiantian.org 10.0.0.9 web03 www [root@lb01 conf]# curl -H host:bbs.etiantian.org 10.0.0.9 web03 bbs [root@lb01 conf]# curl -H host:bbs.etiantian.org 10.0.0.8 web01 bbs [root@lb01 conf]# curl -H host:bbs.etiantian.org 10.0.0.7 web02 bbs
2.1.6 查看虛擬ip狀態
[root@lb01 conf]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:90:7f:0d brd ff:ff:ff:ff:ff:ff inet 10.0.0.5/24 brd 10.0.0.255 scope global eth0 inet 10.0.0.3/24 scope global secondary eth0:1 inet6 fe80::20c:29ff:fe90:7f0d/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:90:7f:17 brd ff:ff:ff:ff:ff:ff inet 172.16.1.5/24 brd 172.16.1.255 scope global eth1 inet6 fe80::20c:29ff:fe90:7f17/64 scope link valid_lft forever preferred_lft forever
2.1.7 【總結】配置文件修改
Keepalived主備配置文件區別：
01. router_id 信息不一致
02. state 狀態描述信息不一致
03. priority 主備競選優先級數值不一致
2.2 腦裂
在高可用（HA）系統中，當聯系2個節點的“心跳線”斷開時，本來為一整體、動作協調的HA系統，就分裂成為2個獨立的個體。由於相互失去了聯系，都以為是對方出了故障。兩個節點上的HA軟件像“裂腦人”一樣，爭搶“共享資源”、爭起“應用服務”，就會發生嚴重后果——或者共享資源被瓜分、2邊“服務”都起不來了；或者2邊“服務”都起來了，但同時讀寫“共享存儲”，導致數據損壞（常見如數據庫輪詢着的聯機日志出錯）。
對付HA系統“裂腦”的對策，目前達成共識的的大概有以下幾條：
1）添加冗余的心跳線，例如：雙線條線（心跳線也HA），盡量減少“裂腦”發生幾率；
2）啟用磁盤鎖。正在服務一方鎖住共享磁盤，“裂腦”發生時，讓對方完全“搶不走”共享磁盤資源。但使用鎖磁盤也會有一個不小的問題，如果占用共享盤的一方不主動“解鎖”，另一方就永遠得不到共享磁盤。現實中假如服務節點突然死機或崩潰，就不可能執行解鎖命令。后備節點也就接管不了共享資源和應用服務。於是有人在HA中設計了“智能”鎖。即：正在服務的一方只在發現心跳線全部斷開（察覺不到對端）時才啟用磁盤鎖。平時就不上鎖了。
3）設置仲裁機制。例如設置參考IP（如網關IP），當心跳線完全斷開時，2個節點都各自ping一下參考IP，不通則表明斷點就出在本端。不僅“心跳”、還兼對外“服務”的本端網絡鏈路斷了，即使啟動（或繼續）應用服務也沒有用了，那就主動放棄競爭，讓能夠ping通參考IP的一端去起服務。更保險一些，ping不通參考IP的一方干脆就自我重啟，以徹底釋放有可能還占用着的那些共享資源。
2.2.1 腦裂產生的原因
一般來說，裂腦的發生，有以下幾種原因：
😶 高可用服務器對之間心跳線鏈路發生故障，導致無法正常通信。
因心跳線壞了（包括斷了，老化）。
因網卡及相關驅動壞了，ip配置及沖突問題（網卡直連）。
因心跳線間連接的設備故障（網卡及交換機）。
因仲裁的機器出問題（采用仲裁的方案）。
😶 高可用服務器上開啟了 iptables防火牆阻擋了心跳消息傳輸。
😶 高可用服務器上心跳網卡地址等信息配置不正確，導致發送心跳失敗。
😶 其他服務配置不當等原因，如心跳方式不同，心跳廣插沖突、軟件Bug等。
提示： Keepalived配置里同一 VRRP實例如果 virtual_router_id兩端參數配置不一致也會導致裂腦問題發生。
2.2.2 常見的解決方案
在實際生產環境中，我們可以從以下幾個方面來防止裂腦問題的發生：
🎑 同時使用串行電纜和以太網電纜連接，同時用兩條心跳線路，這樣一條線路壞了，另一個還是好的，依然能傳送心跳消息。
🎑 當檢測到裂腦時強行關閉一個心跳節點（這個功能需特殊設備支持，如Stonith、feyce）。相當於備節點接收不到心跳消患，通過單獨的線路發送關機命令關閉主節點的電源。
🎑 做好對裂腦的監控報警（如郵件及手機短信等或值班）.在問題發生時人為第一時間介入仲裁，降低損失。例如，百度的監控報警短倍就有上行和下行的區別。報警消息發送到管理員手機上，管理員可以通過手機回復對應數字或簡單的字符串操作返回給服務器.讓服務器根據指令自動處理相應故障，這樣解決故障的時間更短.
當然，在實施高可用方案時，要根據業務實際需求確定是否能容忍這樣的損失。對於一般的網站常規業務.這個損失是可容忍的。
2.3 如何進行腦裂情況監控
2.3.1 在什么服務器上進行監控？
在備服務器上進行監控，可以使用zabbix監控，參考http://www.cnblogs.com/clsn/p/7885990.html
2.3.2 監控什么信息？
備上面出現vip情況：
1）腦裂情況出現
2）正常主備切換也會出現
2.3.3 編寫監控腦裂腳本
[root@lb02 scripts]# vim check_keepalived.sh #!/bin/bash while true do if [ `ip a show eth0 |grep 10.0.0.3|wc -l` -ne 0 ] then echo "keepalived is error!" else echo "keepalived is OK !" fi done
編寫完腳本后要給腳本賦予執行權限
2.3.4 測試 確保兩台負載均衡能夠正常負載
[root@lb01 ~]# curl -H Host:www.etiantian.org 10.0.0.5 web01 www [root@lb01 ~]# curl -H Host:www.etiantian.org 10.0.0.6 web01 www [root@lb01 ~]# curl -H Host:bbs.etiantian.org 10.0.0.6 web02 bbs [root@lb01 ~]# curl -H Host:www.etiantian.org 10.0.0.5 web03 www
2.4 排錯過程
1）利用負載均衡服務器，在服務器上curl所有的節點信息（web服務器配置有問題）
2）curl 負載均衡服務器地址，可以實現負載均衡
3）windows上綁定虛擬IP，瀏覽器上進行測試
keepalived日志文件位置 /var/log/messages
2.5 更改nginx反向代理配置 只監聽vip地址
修改nginx監聽參數 listen 10.0.0.3:80;
修改內核參數，實現監聽本地不存在的ip
echo 'net.ipv4.ip_nonlocal_bind = 1' >>/etc/sysctl.conf sysctl -p [root@lb02 conf]# cat /proc/sys/net/ipv4/ip_nonlocal_bind
2.6 讓keepalived監控nginx
ps -ef |grep nginx |grep -v grep |wc -l
編寫執行腳本
#!/bin/bash while true do if [ `ps -ef |grep nginx |grep -v grep |wc -l` -lt 2 ] then /etc/init.d/keepalived stop exit fi done
注意腳本的授權
[root@lb01 scripts]# chmod +x check_www.sh
2.6.1 使用keepalived的監控腳本
說明 執行的腳本名稱盡量不要和服務名稱相同或相似
[root@lb01 scripts]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id lb01 } vrrp_script check { #定義腳本 script "“/server/scripts/check_web.sh" --- 表示將一個腳本信息賦值給變量check_web interval 2 --- 執行監控腳本的間隔時間 weight 2 ---利用權重值和優先級進行運算，從而降低主服務優先級使之變為備服務器（建議先忽略） } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.3/24 dev eth0 label eth0:1 } track_script { #調用腳本 check } }
2.7 多實例的配置
2.7.1 lb01的keepalived配置文件
[root@lb01 scripts]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id lb01 } vrrp_script check { script "/server/scripts/check_www.sh" interval 2 weight 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.3/24 dev eth0 label eth0:1 } track_script { check } } vrrp_instance VI_2 { state BACKUP interface eth0 virtual_router_id 52 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.4/24 dev eth0 label eth0:2 } }
2.7.2 修改lb02的keepalived配置文件
[root@lb02 conf]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id lb02 } vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.3 dev eth0 label eth0:1 } } vrrp_instance VI_2 { state MASTER interface eth0 virtual_router_id 52 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.4 dev eth0 label eth0:2 } }
修改nginx配置文件，讓bbs 與www分別監聽不同的ip地址
worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream server_pools { server 10.0.0.7:80; server 10.0.0.8:80; server 10.0.0.9:80; } server { listen 10.0.0.3:80; server_name www.etiantian.org; location / { proxy_pass http://server_pools; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } } server { listen 10.0.0.4:80; server_name bbs.etiantian.org; location / { proxy_pass http://server_pools; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } } }
lb01
[root@lb01 scripts]# netstat -lntup |grep nginx tcp 0 0 10.0.0.3:80 0.0.0.0:* LISTEN 84907/nginx tcp 0 0 10.0.0.4:80 0.0.0.0:* LISTEN 84907/nginx
lb02
[root@lb02 conf]# netstat -lntup |grep nginx tcp 0 0 10.0.0.3:80 0.0.0.0:* LISTEN 12258/nginx tcp 0 0 10.0.0.4:80 0.0.0.0:* LISTEN 12258/nginx
2.8 keepalived雙主模式示意圖
本文出自“慘綠少年”，歡迎轉載，轉載請注明出處！http://blog.nmtui.com