一.高可用集群

1.1 集群類型

LB：Load Balance 負載均衡

LVS/HAProxy/nginx（http/upstream, stream/upstream）

HA：High Availability 高可用集群

數據庫、Redis

SPoF: Single Point of Failure，解決單點故障

HPC：High Performance Computing 高性能集群

1.2 系統可用性

SLA：Service-Level Agreement 服務等級協議（提供服務的企業與客戶之間就服務的品質、水準、性能

等方面所達成的雙方共同認可的協議或契約）

A = MTBF / (MTBF+MTTR）

指標 ：99.9%, 99.99%, 99.999%,99.9999%

1.3 系統故障

硬件故障：設計缺陷、wear out（損耗）、非人為不可抗拒因素

軟件故障：設計缺陷 bug

1.4 實現高可用

提升系統高用性的解決方案：降低MTTR- Mean Time To Repair(平均故障時間)

解決方案：建立冗余機制

active/passive 主/備

active/active 雙主

active --> HEARTBEAT --> passive

active <--> HEARTBEAT <--> active

1.5.VRRP：Virtual Router Redundancy Protocol

虛擬路由冗余協議,解決靜態網關單點風險

物理層:路由器、三層交換機

軟件層:keepalived

‘

2.3 Keepalived 環境準備?

各節點時間必須同步：ntp, chrony

關閉防火墻及SELinux

各節點之間可通過主機名互相通信：非必須

建議使用/etc/hosts文件實現：非必須

各節點之間的root用戶可以基于密鑰認證的ssh服務完成互相通信：非必須

在ka1

vim /etc/chrony.conf

在ka2上

時間同步

2.4 Keepalived 相關文件

軟件包名：keepalived

主程序文件：/usr/sbin/keepalived

主配置文件：/etc/keepalived/keepalived.conf

配置文件示例：/usr/share/doc/keepalived/

Unit File：/lib/systemd/system/keepalived.service

Unit File的環境配置文件：/etc/sysconfig/keepalived

注意：RHEL7中可能會遇到一下bug，RHEL9中無此問題

解決辦法：

2.5 Keepalived 安裝

2.6 KeepAlived 配置說明

2.6.1 配置文件組成部分

配置文件：/etc/keepalived/keepalived.conf

配置文件組成

GLOBAL CONFIGURATION

Global definitions： 定義郵件配置，route_id，vrrp配置，多播地址等

VRRP CONFIGURATION

VRRP instance(s)：

定義每個vrrp虛擬路由器

LVS CONFIGURATION

Virtual server group(s)

Virtual server(s)：

LVS集群的VS和RS

2.6.2 配置語法說明

幫助

man keepalived.conf

????????????????

1.全局配置

?啟動keepalived服務

?
ka2和ka1大體一樣，不一樣的下方圖片標了出來。

?啟動keepalived

2.配置虛擬路由器

?

?3.啟用keepalived日志功能

cat /var/log.messages

[root@KA1 ~]# vi /etc/sysconfig/keepalived?

啟用日志功能

[root@KA1 ~]# vim /etc/rsyslog.conf

測試：cat /var/log/keepalived.log

4.實現獨立子配置文件?

當生產環境復雜時， /etc/keepalived/keepalived.conf 文件中內容過多，不易管理

將不同集群的配置，比如：不同集群的VIP配置放在獨立的子配置文件中利用include 指令可以實現包含子配置文件

格式：

復制對話1

[root@KA1 ~]# mkdir /etc/keepalived/conf.d -p

[root@KA1 ~]# sudo vim /etc/keepalived/conf.d/webvip.conf

?

這樣就完成了獨立子配置文件。

三.Keepalived 企業應用示例

3.1 實現master/slave的 Keepalived 單主架構

3.1.1 MASTER配置

前面已經做過，這個就不細寫了。

[root@KA1 ~]# vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {

notification_email {

594233887@qq.com3.1.2 BACKUP配置

}

notification_email_from keepalived@KA1.timinglee.org

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id KA1.timinglee.org

vrrp_skip_check_adv_addr

#vrrp_strict #添加此選項無法訪問vip，可以用nft list ruleset查看

vrrp_garp_interval 1

vrrp_gna_interval 1

vrrp_mcast_group4 224.0.0.18

}

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 20

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

172.25.254.100/24 dev eth0 label eth0:0

}

}

#配置文件和master基本一致，只需修改三行

[root@KA2 ~]# vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {

notification_email {

594233887@qq.com

}

notification_email_from keepalived@timinglee.org

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id KA2.timinglee.org

vrrp_skip_check_adv_addr

#vrrp_strict

vrrp_garp_interval 1

vrrp_gna_interval 1

vrrp_mcast_group4 224.0.0.18

}

vrrp_instance VI_1 {

state BACKUP

interface eth0

virtual_router_id 20 #相同id管理同一個虛擬路由

priority 80 #低優先級

advert_int 1

抓包觀察

3.2 搶占模式和非搶占模式

3.2.1 非搶占模式 nopreempt

默認為搶占模式preempt，即當高優先級的主機恢復在線后，會搶占低先級的主機的master角色， 這樣會使vip在KA主機中來回漂移，造成網絡抖動，

建議設置為非搶占模式 nopreempt ，即高優先級主機恢復后，并不會搶占低優先級主機的master角色非搶占模塊下,如果原主機down機, VIP遷移至的新主機, 后續也發生down時,仍會將VIP遷移回原主機

注意：要關閉 VIP搶占，必須將各 keepalived 服務器state配置為BACKUP

ka1和ka2上：

?

3.2.2 搶占延遲模式 preempt_delay

搶占延遲模式，即優先級高的主機恢復后，不會立即搶回VIP，而是延遲一段時間（默認300s）再搶回VIP

preempt_delay # #指定搶占延遲時間為#s，默認延遲300s

注意：需要各keepalived服務器state為BACKUP,并且不要啟用 vrrp_strict

?關掉并迅速啟動服務

?

?

3.3 VIP單播配置?

默認keepalived主機之間利用多播相互通告消息，會造成網絡擁塞，可以替換成單播，減少網絡流量

注意：啟用 vrrp_strict 時，不能啟用單播

ka1和2都按照這個原理配置

[root@KA2 ~]# vi /etc/keepalived/keepalived.conf

測試：

ka1

?

ka2

?

搶占模式：ka1停止ka2就進行，ka2停止就回到ka1這邊，那邊優先級高先從那邊開始，電腦卡頓，就不展示了。

3.4 Keepalived 通知腳本配置

當keepalived的狀態變化時，可以自動觸發腳本的執行，比如：發郵件通知用戶

默認以用戶keepalived_script身份執行腳本

如果此用戶不存在，以root執行腳本可以用下面指令指定腳本執行用戶的身份

當前節點成為主節點時觸發的腳本

notify_master <STRING>|<QUOTED-STRING>

當前節點轉為備節點時觸發的腳本

notify_backup <STRING>|<QUOTED-STRING>

當前節點轉為“失敗”狀態時觸發的腳本

notify_fault <STRING>|<QUOTED-STRING>

3.4.2 腳本的調用方法

在 vrrp_instance VI_1 語句塊的末尾加下面行

notify_master "/etc/keepalived/notify.sh master"

notify_backup "/etc/keepalived/notify.sh backup"

notify_fault "/etc/keepalived/notify.sh fault”

3.4.3 創建通知腳本

[root@KA1 ~]# vim /etc/keepalived/mail.sh

#!/bin/bash

mail_dest='594233887@qq.com'

mail_send()

{

mail_subj="$HOSTNAME to be $1 vip 轉移"

mail_mess="`date +%F\ %T`: vrrp 轉移,$HOSTNAME 變為 $1"

echo "$mail_mess" | mail -s "$mail_subj" $mail_dest

}

case $1 in

master)

mail_send master

;;

backup)

mail_send backup

;;

fault)

mail_send fault

;;

*)

exit 1

;;

esac

#!/bin/bash
rm -fr /mnt/{master,backup,faild}
case $1 in
master)
echo master > /mnt/master
;;
backup)
echo backup > /mnt/backup
;;
faild)
echo faild > /mnt/faild
esac

/mnt/test.sh 必須存在且 可執行，否則 Keepalived 會不斷報警。

sudo chmod +x /mnt/test.sh

測試：

3.4.4 郵件配置

安裝郵件發送工具

[root@KA1 ~]# dnf install s-nail sendmail -y

[root@KA1 ~]# systemctl enable --now sendmail.service

[root@KA1 ~]# echo hello | mailx -s test xxxxx@163.com

?

?

3.4.5 實戰案例：實現 Keepalived 狀態切換的通知腳本?

編寫腳本：

#!/bin/bash
mail_dest='xxxx@163.com'
mail_send()
{
mail_subj="$HOSTNAME to be $1 vip 轉移"
mail_mess="`date +%F\ %T`: vrrp 轉移,$HOSTNAME 變為 $1"
echo "$mail_mess" | mail -s "$mail_subj" $mail_dest
}
case $1 in
master)
mail_send master
;;
backup)
mail_send backup
;;
fault)
mail_send fault
;;
*)
exit 1
;;
esac
~ ? ? ? ? ? ? ? ? ? ? ?

[root@KA1 ~]# vim /etc/keepalived/keepalived.conf?

[root@KA1 ~]# systemctl restart keepalived.service

3.5 實現 master/master 的 Keepalived 雙主架構?

?

?

?

3.6 實現IPVS的高可用性

3.6.1 IPVS相關配置

1.虛擬服務器配置結構

2.virtual server （虛擬服務器）的定義格式

virtual_server IP port #定義虛擬主機IP地址及其端口

virtual_server fwmark int #ipvs的防火墻打標，實現基于防火墻的負載均衡集群

virtual_server group string #使用虛擬服務器組

3.虛擬服務器配置

virtual_server IP port { #VIP和PORT

delay_loop <INT> #檢查后端服務器的時間間隔

lb_algo rr|wrr|lc|wlc|lblc|sh|dh #定義調度方法

lb_kind NAT|DR|TUN #集群的類型,注意要大寫

persistence_timeout <INT> #持久連接時長

protocol TCP|UDP|SCTP #指定服務協議,一般為TCP

sorry_server <IPADDR> <PORT> #所有RS故障時，備用服務器地址

real_server <IPADDR> <PORT> { #RS的IP和PORT

weight <INT> #RS權重

notify_up <STRING>|<QUOTED-STRING> #RS上線通知腳本

notify_down <STRING>|<QUOTED-STRING> #RS下線通知腳本

HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... } #定義當前主機健康狀

態檢測方法

}

}

注意:括號必須分行寫,兩個括號寫在同一行,如: }} 會出錯

4.應用層監測

應用層檢測：HTTP_GET|SSL_GET

HTTP_GET|SSL_GET {

url {

path <URL_PATH> #定義要監控的URL

status_code <INT> #判斷上述檢測機制為健康狀態的響應碼，一般為 200

}

connect_timeout <INTEGER> #客戶端請求的超時時長, 相當于haproxy的timeout server

nb_get_retry <INT> #重試次數

delay_before_retry <INT> #重試之前的延遲時長

connect_ip <IP ADDRESS> #向當前RS哪個IP地址發起健康狀態檢測請求

connect_port <PORT> #向當前RS的哪個PORT發起健康狀態檢測請求

bindto <IP ADDRESS> #向當前RS發出健康狀態檢測請求時使用的源地址

bind_port <PORT> #向當前RS發出健康狀態檢測請求時使用的源端口

}

5.TCP監測

傳輸層檢測：TCP_CHECK

TCP_CHECK {

connect_ip <IP ADDRESS> #向當前RS的哪個IP地址發起健康狀態檢測請求

connect_port <PORT> #向當前RS的哪個PORT發起健康狀態檢測請求

bindto <IP ADDRESS> #發出健康狀態檢測請求時使用的源地址

bind_port <PORT> #發出健康狀態檢測請求時使用的源端口

connect_timeout <INTEGER> #客戶端請求的超時時長

#等于haproxy的timeout server

}

3.6.2 實戰案例

準備web服務器并使用腳本綁定VIP至web服務器lo網卡

rs1和rs2安裝

[root@KA2 ~]# dnf install ipvsadm-1.31-6.el9.x86_64 -y

ka1和2上配置

virtual_server 192.168.12.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
protocol TCP

? ? real_server 192.168.12.110 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 2
retry 3
delay_before_retry 3
}
}

? ? real_server 192.168.12.120 80 {
weight 1
TCP_CHECK {
connect_timeout 2
retry 3
delay_before_retry 3
connect_port 80
}
}
}

?

for i in {1..6}; do curl 192.168.12.100; done

以上就是ipvs的高可用！

3.7 實現其它應用的高可用性 VRRP Script

3.7.1 VRRP Script 配置

分兩步實現：

定義腳本

vrrp_script：自定義資源監控腳本，vrrp實例根據腳本返回值，公共定義，可被多個實例調用，定

義在vrrp實例之外的獨立配置塊，一般放在global_defs設置塊之后。

通常此腳本用于監控指定應用的狀態。一旦發現應用的狀態異常，則觸發對MASTER節點的權重減至低于SLAVE節點，從而實現 VIP 切換到 SLAVE 節點

vrrp_script <SCRIPT_NAME> {

script <STRING>|<QUOTED-STRING> #此腳本返回值為非0時，會觸發下面OPTIONS執行

OPTIONS

}

調用腳本

track_script：調用vrrp_script定義的腳本去監控資源，定義在VRRP實例之內，調用事先定義的

vrrp_script

track_script {

SCRIPT_NAME_1

SCRIPT_NAME_2

}

1.定義 VRRP script

vrrp_script <SCRIPT_NAME> { #定義一個檢測腳本，在global_defs 之外配置

script <STRING>|<QUOTED-STRING> #shell命令或腳本路徑

interval <INTEGER> #間隔時間，單位為秒，默認1秒

timeout <INTEGER> #超時時間

weight <INTEGER:-254..254> #默認為0,如果設置此值為負數，

#當上面腳本返回值為非0時

#會將此值與本節點權重相加可以降低本節點權重，

#即表示fall.

#如果是正數，當腳本返回值為0，

#會將此值與本節點權重相加可以提高本節點權重

#即表示 rise.通常使用負值

fall <INTEGER> #執行腳本連續幾次都失敗,則轉換為失敗，建議設為2以上

rise <INTEGER> #執行腳本連續幾次都成功，把服務器從失敗標記為成功

user USERNAME [GROUPNAME] #執行監測腳本的用戶或組

init_fail #設置默認標記為失敗狀態，監測成功之后再轉換為成功狀態

}

2.調用 VRRP script

vrrp_instance test {

... ...

track_script {

check_down

}

}

3.7.2實戰案例：利用腳本實現主從角色切換

# vim /mnt/check_lee.sh

#!/bin/bash

[ ！ -f "/mnt/lee" ]

chmod +x /mnt/check_lee.sh

vim /etc/keepalived/keepalived.conf

腳本：

vrrp_script check_lee {
script "/mnt/check_lee.sh"
interval 1
weight -30
fall 2
rise 2
timeout 2
}
vrrp_instance web {
state MASTER
interface ens33
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.254.100 dev ens33 label ens33:0
}
track_script {
check_lee
}
}

touch /mnt/lee

?tail -f /var/log/messages

3.7.3 實戰案例：實現HAProxy高可用

在ka1和ka2先實現haproxy的配置

listen webserver
bind 192.168.12.100:80
server web1 192.168.12.120:80 check
server web2 192.168.12.110:80 check

在兩個ka1和ka2兩個節點啟用內核參數

vim /etc/sysctl.conf

net.ipv4.ip_nonlocal_bind = 1

sysctl -p

在ka1中編寫檢測腳本

vim /etc/keepalived/scripts/haproxy.sh

#!/bin/bash

killall -0 haproxy

?

?chmod +X /etc/keepalived/scripts/haproxy.sh

在ka1中配置keepalived

vrrp_script check_haproxy {

script "/etc/keepalived/scripts/haproxy.sh"

interval 1

weight -30

fall 2

rise 2

timeout 2

}

vrrp_instance web {

state MASTER

interface ens33

virtual_router_id 50

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

192.168.12.100 dev ens33?label ens33:0

}

track_script {

check_haproxy

}

}

?

測試

systemctl stop haproxy.service

?

成功！

以上就是對高可用集群KEEPALIVED的詳細部署！！

四.注意事項

Keepalived 高可用集群在生產落地時，有 8 條「踩坑率最高」的注意事項，務必提前規避：

以上就是高可用集群KEEPALIVED的詳細部署！?

?