目錄
- 一、Keepalived介紹
- 二、Keepalived的應用場景
- 三、Keepalived的工作原理
- 1 VRRP協議
- 2 核心組件
- 3 分層工作
- 4 工作狀態
- 四、Keepalived使用
- 1 配置介紹
- 2 使用keepalived對nginx進行高可用搭建
- 2.1 環境準備
- 2.2 nginx軟件安裝和配置
- 2.3 Keepalived軟件安裝
- 2.4 監聽存活腳本
- 2.5 最終配置文件
- 2.6 啟動主從的Keepalived
- 2.7 查看VIP是否啟動
- 2.8 測試
- 五、需要注意的問題:
- 1 腦裂介紹
- 1.1 產生腦裂的原因
- 1.2 常見的解決辦法
- 1.3 Keepalived監控nginx防止腦裂
- 2 Keepalived設置故障恢復后不重新搶回VIP
- 3 組播地址沖突問題
一、Keepalived介紹
摘抄自官網的介紹:
Keepalived is a routing software written in C. The main goal of this project is to provide simple and robust facilities for loadbalancing and high-availability to Linux system and Linux based infrastructures.
項目地址:github.com/acassen/kee…
- Keepalived的作用是檢測服務器狀態,如果一臺服務器宕機或者出現其他故障導致當前服務器不可用,keep alived就會檢測到并將故障的服務器從系統中剔除,同時使用備用服務器替代該服務器的工作,當服務器工作正常后Keepalived自動將服務器加入到服務器群中,這些工作全部自動完成,不需要人工干涉,需要人工做的只是修復故障的服務器。
- Keepalived軟件起初是專為LVS負載均衡軟件設計的,用來管理并監控LVS集群系統中各個服務節點的狀態,后來又加入了可以實現高可用的VRRP功能。因此,Keepalived除了能夠管理LVS軟件外,還可以作為其他服務(例如:Nginx、Haproxy、MySQL等)的高可用解決方案軟件。
- Keepalived軟件主要是通過VRRP協議實現高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗余協議)的縮寫,VRRP出現的目的就是為了解決靜態路由單點故障問題的,它能夠保證當個別節點宕機時,整個網絡可以不間斷地運行。
所以,Keepalived 一方面具有配置管理LVS的功能,同時還具有對LVS下面節點進行健康檢查的功能,另一方面也可實現系統網絡服務的高可用功能。
二、Keepalived的應用場景
- 管理LVS軟件
- 基于VRRP實現高可用
- 健康檢查,故障切換
通過官網的介紹我們可以看到Keepalived提供了兩個重要的功能:loadbalancing和high-availability。最初是專門為LVS負載均衡軟件設計,可以用來管理并監控LVS集群系統中各個服務節點的狀態,后來的版本中又加入了可以實現高可用的VRRP功能。
因此,Keeaplived主要有兩種應用場景,一個是通過配置keepalived結合ipvs做到負載均衡(LVS+Keepalived);
另一個是通過自身健康檢查、資源接管等功能做高可用(雙機熱備),實現故障轉移,功能近似于Heartbeat。
目前全球監控的分布式MySQL集群,使用了Keeaplived來實現proxy的雙機熱備功能,所以下面只介紹在高可用場景下的相關知識。
三、Keepalived的工作原理
1 VRRP協議
keepalived是以VRRP協議為實現基礎的,VRRP全稱Virtual Router Redundancy Protocol,即虛擬路由冗余協議,可以認為是實現路由器高可用的協議。
- VRRP是用來實現路由器冗余的協議。
- VRRP協議是為了消除在靜態缺省路由環境下路由器單點故障引起的網絡失效而設計的主備模式的協議,使得發生故障而進行設計設備功能切換時可以不影響內外數據通信,不需要再修改內部網絡的網絡參數。
- VRRP協議需要具有IP備份,優先路由選擇,減少不必要的路由器通信等功能。
- VRRP協議將兩臺或多臺路由器設備虛擬成一個設備,對外提供虛擬路由器IP(一個或多個)。然而,在路由器組內部,如果實際擁有這個對外IP的路由器如果工作正常的話,就是master,或者是通過算法選舉產生的,MASTER實現針對虛擬路由器IP的各種網絡功能,如ARP請求,ICMP,以及數據的轉發等,其他設備不具有該IP,狀態是BACKUP。除了接收MASTER的VRRP狀態通告信息外,不執行對外的網絡功能,當主機失效時,BACKUP將接管原先MASTER的網絡功能。
- VRRP協議配置時,需要配置每個路由器的虛擬路由ID(VRID)和優先權值,使用VRID將路由器進行分組,具有相同VRID值的路由器為同一個組,VRID是一個0-255的整整數;同一個組中的路由器通過使用優先權值來選舉MASTER。優先權大者為MASTER,優先權也是一個0-255的正整數。
對應到高可用的場景,實際上就是把路由器換成了服務器或者服務器上的應用: 通常情況下是將兩臺linux服務器組成一個熱備組(master-backup),同一時間熱備組內只有一臺主服務器(master)提供服務,同時master會虛擬出一個共用IP地址(VIP),這個VIP只存在master上并對外提供服務。 如果keepalived檢測到master宕機或服務故障,備服務器(backup)會自動接管VIP成為master,keepalived并將master從熱備組移除,當master恢復后,會自動加入到熱備組,默認再搶占成為master,起到故障轉移功能。
2 核心組件
keepalived是模塊化設計,不同模塊負責不同的功能,主要有三個模塊,分別是core、check和VRRP,其中:
- **core模塊:**為keepalived的核心組件,負責主進程的啟動、維護以及全局配置文件的加載和解析;
- **check:**負責健康檢查,包括常見的各種檢查方式,這里的配置決定了工作在哪個層;
- **VRRP模塊:**是來實現VRRP協議的。
此外還有:
- system call:系統調用
- watch dog:監控check和vrrp進程的看管者
- libipfwc:iptables(ipchains)庫,配置LVS會用到
- libipvs*:配置LVS會用到
3 分層工作
keepalived做負載均衡時工作在TCP/IP協議的3/4/5層,做高可用時工作在OSI七層協議模型的3/4/7層,基本上是一樣的,叫法不同而已
分層 | 功能 | 相關協議 |
---|---|---|
應用層 | 網絡服務和最終用戶的一個接口 | TFTP,HTTP,SNMP,DNS,FTP,SMTP,TELNET |
表示層 | 數據的表示、安全、壓縮 | 無協議 |
會話層 | 會話的建立、管理、中止 | 無協議 |
傳輸層 | 定義傳輸數據的協議端口號,以及流控和差錯校驗 | TCP,UDP |
網絡層 | 進行邏輯地址尋址,實現不同網絡之間的路徑選擇 | IP,ICMP,RIP,OSPF,BGP,IGMP |
數據鏈路層 | 建立邏輯連接、硬件地址尋址、差錯校驗等功能 | SLIP,CSLIP,PPP,ARP,RARP,MTU |
物理層 | 建立、連接、斷開物理連接 | ISO2110,IEEE802,IEEE802.2 |
具體工作在哪一層的區別就在于用什么樣的網絡協議來進行健康檢查:
Layer3:工作在三層時,keepalived會定期向熱備組中的服務器發送一個ICMP數據包,來判斷某臺服務器是否故障,如果沒有響應則將這臺服務器從熱備組移除。
Layer4:工作在四層時,keepalived以TCP端口的狀態判斷服務器是否故障,比如檢測MySQL的3306端口,如果無法訪問則將這臺服務器從熱備組移除。
Layer7:工作在七層時,keepalived根據用戶設定的策略判斷服務器上的程序是否正常運行,比如使用HTTP請求的方式,如果返回錯誤的狀態碼則將這臺服務器從熱備組移除。
在Keepalived服務器群之間,只有作為主的服務器不斷發送VRRP廣播包,告訴備它還活著,此時備不會搶占主,只有當主不可用,既備接受不到主的VRRP廣播包,這時候備就會啟動相關的服務接管主的任務向外提供服務,以保證服務的正常使用。
4 工作狀態
keepalived正常啟動的時候,共啟動3個進程: 一個是父進程,負責監控其子進程;
一個是VRRP子進程,另外一個是checkers子進程;
兩個子進程都被系統watchlog看管,Healthcheck子進程檢查各自服務器的健康狀況。
如果healthchecks進程檢查到master上服務不可用了,就會通知本機上的VRRP子進程,讓他刪除通告,并且去掉虛擬IP,轉換為BACKUP狀態。 生產服務器上的keepalived進程
四、Keepalived使用
1 配置介紹
keepalived配置文件按層級和模塊劃分的,每層由"{ }"來界定。在主配置文件中可以通過include來涵蓋多個子配置文件。 詳細語法說明:官方文檔 配置文件包括以下幾個模塊:
- LOBAL CONFIGURATION
- BFD CONFIGURATION
- VRRPD CONFIGURATION
- LVS CONFIGURATION
[root@localhost ~]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { #全局定義部分 notification_email { #設置報警郵件地址,可設置多個 acassen@firewall.loc #接收通知的郵件地址 } notification_email_from test0@163.com #設置 發送郵件通知的地址 smtp_server smtp.163.com #設置 smtp server 地址,可是ip或域名.可選端口號 (默認25) smtp_connect_timeout 30 #設置 連接 smtp server的超時時間 router_id LVS_DEVEL #主機標識,用于郵件通知 vrrp_skip_check_adv_addr vrrp_strict #嚴格執行VRRP協議規范,此模式不支持節點單播 vrrp_garp_interval 0 vrrp_gna_interval 0 script_user keepalived_script #指定運行腳本的用戶名和組。默認使用用戶的默認組。如未指定,默認為keepalived_script 用戶,如無此用戶,則使用root enable_script_security #如過路徑為非root可寫,不要配置腳本為root用戶執行。 } vrrp_instance VI_1 { #vrrp 實例部分定義,VI_1自定義名稱 state MASTER #指定 keepalived 的角色,必須大寫 可選值:MASTER|BACKUP interface ens33 #網卡設置,lvs需要綁定在網卡上,realserver綁定在回環口。區別:lvs對訪問為外,realserver為內不易暴露本機信息 virtual_router_id 51 #虛擬路由標識,是一個數字,同一個vrrp 實例使用唯一的標識,MASTER和BACKUP 的 同一個 vrrp_instance 下 這個標識必須保持一致 priority 100 #定義優先級,數字越大,優先級越高。 advert_int 1 #設定 MASTER 與 BACKUP 負載均衡之間同步檢查的時間間隔,單位為秒,兩個節點設置必須一樣 authentication { #設置驗證類型和密碼,兩個節點必須一致 auth_type PASS auth_pass 1111 } virtual_ipaddress { #設置虛擬IP地址,可以設置多個虛擬IP地址,每行一個 192.168.119.130 } track_script { #腳本監控狀態 chk_nginx_service #可加權重,但會覆蓋聲明的腳本權重值。chk_nginx_service weight -20 } notify_master "/etc/keepalived/start_haproxy.sh start" #當前節點成為master時,通知腳本執行任務 notify_backup "/etc/keepalived/start_haproxy.sh stop" #當前節點成為backup時,通知腳本執行任務 notify_fault "/etc/keepalived/start_haproxy.sh stop" #當當前節點出現故障,執行的任務; } virtual_server 192.168.119.130 80 { #定義RealServer對應的VIP及服務端口,IP和端口之間用空格隔開 delay_loop 6 #每隔6秒查詢realserver狀態 lb_algo rr #后端調試算法(load balancing algorithm) lb_kind DR #LVS調度類型NAT/DR/TUN #persistence_timeout 60 同一IP的連接60秒內被分配到同一臺realserver protocol TCP #用TCP協議檢查realserver狀態 real_server 192.168.119.120 80 { weight 1 #權重,最大越高,lvs就越優先訪問 TCP_CHECK { #keepalived的健康檢查方式HTTP_GET | SSL_GET | TCP_CHECK | SMTP_CHECK | MISC connect_timeout 10 #10秒無響應超時 retry 3 #重連次數3次 delay_before_retry 3 #重連間隔時間 connect_port 80 #健康檢查realserver的端口 } } } }
2 使用keepalived對nginx進行高可用搭建
2.1 環境準備
主機ip | 角色 | 部署軟件 |
---|---|---|
192.168.73.135 | master | keepalived、nginx |
192.168.73.136 | salve | keepalived、nginx |
192.168.73.100 | 虛ip |
|
2.2 nginx軟件安裝和配置
在192.168.73.136操作為例,135上把index改成135即可
[root@localhost ~]# yum -y install nginx [root@localhost ~]# cd /usr/share/nginx/html/ [root@localhost html]# mv index.html index.html.back [root@localhost html]# echo "I am 192.168.73.136" > index.html [root@localhost html]# systemctl start nginx [root@localhost html]# curl 192.168.73.136 I am 192.168.73.136
2.3 Keepalived軟件安裝
[root@localhost ~]# yum install keepalived -y [root@localhost ~]# rpm -ql keepalived /etc/keepalived /etc/keepalived/keepalived.conf # 主配置文件 /etc/sysconfig/keepalived /usr/bin/genhash /usr/lib/systemd/system/keepalived.service /usr/libexec/keepalived /usr/sbin/keepalived
2.4 監聽存活腳本
[root@localhost ~]# vim /etc/keepalived/check_port.sh #!/bin/bash #keepalived 監控端口腳本 #使用方法: #在keepalived的配置文件中 #vrrp_script check_port {#創建一個vrrp_script腳本,檢查配置 # script "/etc/keepalived/check_port.sh 80" #配置監聽的端口 # interval 2 #檢查腳本的頻率,單位(秒) #} CHK_PORT=$1 if [ -n "$CHK_PORT" ];then PORT_PROCESS=`ss -lnt|grep $CHK_PORT|wc -l` if [ $PORT_PROCESS -eq 0 ];then echo "Port $CHK_PORT Is Not Used,End." exit 1 fi else echo "Check Port Cant Be Empty!" fi [root@localhost ~]# chmod +x /etc/keepalived/check_port.sh
2.5 最終配置文件
(1)Master配置
[root@localhost ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id 192.168.73.136 } vrrp_script chk_nginx { script "/etc/keepalived/check_port.sh 80" interval 2 weight -20 } vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 251 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 11111111 } track_script { chk_nginx } virtual_ipaddress { 192.168.73.100 } }
(2)Slave配置
! Configuration File for keepalived global_defs { router_id 192.168.73.135 } vrrp_script chk_nginx { script "/etc/keepalived/check_port.sh 80" interval 2 weight -20 } vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 251 priority 90 advert_int 1 authentication { auth_type PASS auth_pass 11111111 } track_script { chk_nginx } virtual_ipaddress { 192.168.73.100 } }
2.6 啟動主從的Keepalived
[root@localhost ~]]systemctl start keepalived && systemctl enable keepalive
2.7 查看VIP是否啟動
[root@localhost keepalived]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:6f:74:0a brd ff:ff:ff:ff:ff:ff inet 192.168.73.136/24 brd 192.168.73.255 scope global noprefixroute ens33 valid_lft forever preferred_lft forever inet 192.168.73.100/32 scope global ens33 valid_lft forever preferred_lft forever inet6 fe80::af0e:a936:d997:18da/64 scope link noprefixroute valid_lft forever preferred_lft forever
2.8 測試
首先在瀏覽器中訪問vip,可以看到我們訪問的是BACKUP上的web地址
關掉master上的nginx,查看VIP是否漂移到備機。
# 關閉主nginx [root@localhost ~]# systemctl stop nginx # 查看備上的IP信息,我們發現vip已經偏移到備機上了 [root@localhost ~]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:6f:74:0a brd ff:ff:ff:ff:ff:ff inet 192.168.73.136/24 brd 192.168.73.255 scope global noprefixroute ens33 valid_lft forever preferred_lft forever inet6 fe80::af0e:a936:d997:18da/64 scope link noprefixroute valid_lft forever preferred_lft forever
在瀏覽器中訪問vip,可以看到我們訪問的是master上的web地址
五、需要注意的問題:
1 腦裂介紹
在高可用系統中,如果兩個節點的心跳線斷開,本來兩個節點為一個整體、動作協調的一個HA系統,現在由于兩個之間的心跳線斷開導致它們分裂成了兩個單獨的個體。由于雙方互相失去了聯系,都會以為對方出了故障。這時候這兩個單獨的個體就像"腦裂人"一樣互相爭搶共享資源、爭用應用服務,這樣就會造成嚴重問題:
- 共享資源被瓜分,兩邊服務都起不來;
- 兩邊服務都起來了,同時提供服務,同時讀寫存儲,導致數據不一致甚至損壞。
1.1 產生腦裂的原因
一般來說,腦裂的發生,有以下幾種原因:
- (1)HA服務器之間心跳線故障,導致無法正常通信;
- (2)HA服務器上開啟了防火墻,阻擋了心跳線的信息傳輸;
- (3)HA服務器上心跳網卡配置不正確,導致心跳信息發送失敗;
- (4)其他服務器配置不當的原因。比如心跳方式不同,心跳廣播沖突,軟件BUG等;
- (5)Keepalived配置里同一 VRRP實例中如果 virtualrouterid兩端參數配置不一致也會導致裂腦問題發生。
1.2 常見的解決辦法
在實際環境中,我們可以從以下幾個方面來防止腦裂的問題:
- (1)同時使用串行線路或者以太網電纜連接,同時使用兩條心跳線路,如果一條壞了,另外一條還能正常提供服務;
- (2)當檢測到腦裂時強行關閉一個節點(該功能需要特殊設備支持,如Stonith,feyce),相當于備節點接受不到心跳心跳消患,通過單獨的線路發送關機命令關閉主節點的電源;
- (3)做好腦裂監控報警(用zabbix等來監控),在問題發生時能在第一時間介入仲裁,降低損失。
- (4)啟動磁盤鎖。正在服務一方鎖住共享磁盤,“裂腦”發生時,讓對方完全“搶不走”共享磁盤資源。但使用鎖磁盤也會有一個不小的問題,如果占用共享盤的一方不主動“解鎖”,另一方就永遠得不到共享磁盤。現實中假如服務節點突然死機或崩潰,就不可能執行解鎖命令。后備節點也就接管不了共享資源和應用服務。于是有人在HA中設計了“智能”鎖。即:正在服務的一方只在發現心跳線全部斷開(察覺不到對端)時才啟用磁盤鎖,平時就不上鎖了;
- (5)加入仲裁機制。例如設置網關IP,當腦裂發生時,兩個節點都各自ping以下這個網關IP,不通則表明斷點就在本端,不僅“心跳”、還兼對外“服務”的本端網絡鏈路斷了,即使啟動(或繼續)應用服務也沒有用了,那就主動放棄競爭,讓能夠ping通網關IP的一端去起服務。更保險一些,ping不通網關IP的一方干脆就自我重啟,以徹底釋放有可能還占用著的那些共享資源。
1.3 Keepalived監控nginx防止腦裂
(1)執行腳本,用來檢測
[root@zdd211-11 ~]# vim /etc/keepalived/check_keepalived.sh #!/bin/bash NGINX_SBIN="which nginx" NGINX_PORT=80 function check_nginx(){ NGINX_STATUS="nmap localhost -p ${NGINX_PORT} | grep "80/tcp open" | awk '{print $2}'" NGINX_PROCESS="ps -ef | grep nginx|grep -v grep|wc -l" } check_nginx if [ "$NGINX_STATUS" != "open" -o $NGINX_PROCESS -lt 2 ] then ${NGINX_SBIN} -s stop ${NGINX_SBIN} sleep 3 check_nginx if [ "$NGINX_STATUS" != "open" -o $NGINX_PROCESS -lt 2 ];then systemctl stop keepalived fi fi [root@localhost ~]# chmod +x /etc/keepalived/check_port.sh
(2)安裝nmap 因為上面腳本有用到這個工具,因此兩個主機都需要安裝
[root@localhost ~]# yum install nmap -y
(3) 修改master配置
[root@localhost ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id 192.168.73.136 } vrrp_script chk_nginx { script "/etc/keepalived/check_port.sh 80" interval 2 weight -20 } vrrp_script chk_nginx { script "/etc/keepalived/check_keepalive.sh" # 腳本路徑 interval 2 # 執行時間間隔 weight -5 # 計算權重值,腳本結果導致的優先級變更,檢測失敗(腳本返回非0)則優先級 -5 fall 3 # 檢測連續3次失敗才算確定是真失敗。會用weight減少優先級(1-255之間) rise 2 # 檢測2次成功就算成功。但不修改優先級 vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 251 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 11111111 } track_script { chk_nginx } virtual_ipaddress { 192.168.73.100 } }
(4) 修改Slave配置配置
! Configuration File for keepalived global_defs { router_id 192.168.73.135 } vrrp_script chk_nginx { script "/etc/keepalived/check_keepalive.sh" interval 2 # 執行時間間隔 weight -5 # 計算權重值,腳本結果導致的優先級變更,檢測失敗(腳本返回非0)則優先級 -5 fall 3 # 檢測連續3次失敗才算確定是真失敗。會用weight減少優先級(1-255之間) rise 2 # 檢測2次成功就算成功。但不修改優先級 vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 251 priority 90 advert_int 1 authentication { auth_type PASS auth_pass 11111111 } track_script { chk_nginx } virtual_ipaddress { 192.168.73.100 } }
2 Keepalived設置故障恢復后不重新搶回VIP
通常生產環境是不允許VIP來回漂移,當主機的業務出問題之后,vip漂移到備機上保證業務不中斷,就算故障恢復keepalived也不會把vip切到主機上;
需要進行對應的問題問題,確認主機環境沒有問題之后手動重啟主機上keepalived服務,讓vip切回到主機上。 為
了滿足這樣的業務場景,可以使用nopreempt參數,不搶占VIP的機制實現 修改master配置如下
[root@localhost ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id 192.168.73.136 } vrrp_script chk_nginx { script "/etc/keepalived/check_keepalive.sh" # 腳本路徑 interval 2 # 執行時間間隔 weight -5 # 計算權重值,腳本結果導致的優先級變更,檢測失敗(腳本返回非0)則優先級 -5 fall 3 # 檢測連續3次失敗才算確定是真失敗。會用weight減少優先級(1-255之間) rise 2 # 檢測2次成功就算成功。但不修改優先級 } vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 251 priority 100 advert_int 1 nopreempt ##不搶VIP 機制 authentication { auth_type PASS auth_pass 11111111 } track_script { chk_nginx } virtual_ipaddress { 192.168.73.100 } }
可以自己重啟keepalived,然后停止web,然后再啟動web,驗證是否能夠自動漂移回主機
3 組播地址沖突問題
當在同一個局域網內部署了多組keepalived服務器時,可能會發生高可用接管的嚴重故障問題。 因為keepalived高可用功能是通過VRRP協議實現的,VRRP協議默認通過IP多播的形式實現高可用對之間的通信,如果同一個局域網內存在多組Keepalived服務器對,就會造成IP多播地址沖突問題,導致接管錯亂. 不同組的keepalived都會使用默認的224.0.0.18作為多播地址。此時的解決辦法是,在同組的keepalived服務器所有的配置文件里指定獨一無二的多播地址,配置如下:
global_defs { ``router_id LVS_19 ``vrrp_mcast_group4 224.0.0.19` `#指定多播地址 }
以上就是keepalived對nginx進行高可用搭建及原理詳解的詳細內容,更多關于keepalived搭建nginx的資料請關注其它相關文章!