全网最详细且最容易理解的高可用集群KEEPALIVED

在海边听风声

已于 2024-08-16 23:49:33 修改

阅读量801

点赞数 24

分类专栏： keepalived Linux 文章标签： linux keepalived 负载均衡

于 2024-08-14 23:25:20 首次发布

本文链接：https://blog.csdn.net/qq_26553949/article/details/141188719

版权

Linux 同时被 2 个专栏收录

13 篇文章 0 订阅

订阅专栏

keepalived

2 篇文章 0 订阅

订阅专栏

1.5.VRRP：Virtual Router Redundancy Protocol

2.5：Keepalived 安装以及实现master/slave的 Keepalived 单主架构

2.6：如何使VIP能够在relserver上通信

3.2：抢占延迟模式 preempt_delay

3.3：VIP单播配置

3.4：Keepalived 通知脚本配置

3.5:实现 master/master 的 Keepalived 双主架构

3.6：实现IPVS的高可用性

3.6.1 IPVS相关配置

3.6.1.1 虚拟服务器配置结构

3.6.1.2 virtual server （虚拟服务器）的定义格式

3.6.2.1 实战案例1：实现单主的 LVS（DR模式）+keepalived

3.7 实现其它应用的高可用性 VRRP Script

3.7.1 VRRP Script 配置

3.7.1.1 定义 VRRP script

3.7.1.2 调用 VRRP script

3.7.2:实战案例：利用脚本实现主从角色切换

3.7.3 实战案例：keepalived+haproxy的高可用集群

一：高可用集群

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.95%:(60*24*30)*(1-0.9995)=21.6 分钟 # 一般按一个月停机时间统计

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

1.5.1 VRRP 相关术语

虚拟路由器：Virtual Router
虚拟路由器标识：VRID(0-255)，唯一标识虚拟路由器
VIP：Virtual IP
VMAC：Virutal MAC (00-00-5e-00-01-VRID)
物理路由器：

master：主设备
backup：备用设备
priority：优先级

1.5.2 VRRP 相关技术

通告：心跳，优先级等；周期性

工作方式：抢占式，非抢占式

安全认证：

无认证
简单字符认证：预共享密钥
MD5

工作模式：

主/备：单虚拟路由器
主/主：主/备（虚拟路由器1），备/主（虚拟路由器2）

二：Keepalived 部署

2.1 keepalived 简介

vrrp 协议的软件实现，原生设计目的为了高可用 ipvs 服务

功能：

基于vrrp协议完成地址流动
为vip地址所在的节点生成ipvs规则(在配置文件中预先定义)
为ipvs集群的各RS做健康状态检测
基于脚本调用接口完成脚本中定义的功能，进而影响集群事务，以此支持nginx、haproxy等服务

2.2 Keepalived 架构

用户空间核心组件：

vrrp stack：VIP消息通告
checkers：监测real server
system call：实现 vrrp 协议状态转换时调用脚本的功能
SMTP：邮件组件
IPVS wrapper：生成IPVS规则
Netlink Reflector：网络接口
WatchDog：监控进程

控制组件：提供keepalived.conf 的解析器，完成Keepalived配置
IO复用器：针对网络目的而优化的自己的线程抽象
内存管理组件：为某些通用的内存管理功能（例如分配，重新分配，发布等）提供访问权限

2.3 Keepalived 环境准备

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

2.5：Keepalived 安装以及实现master/slave的 Keepalived 单主架构

安装 keepalived

yum install keepalived -y

配置文件组成部分

配置文件： /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

配置部分

KA1的全局配置和虚拟路由器配置

首先进入配置文件

vim /etc/keepalived/keepalived.conf

KA2的全局配置和虚拟路由器配置

把两边的keepalived服务都开启

systemctl start keepalived.service

查看VIP是不是在KA1上

测试：10的主机关闭keepalived服务，查看是不是BACKUP主机20在工作

首先查看VIP是不是到20主机上了

然后开始抓包命令测试

测试成功1！！！

2.6：如何使VIP能够在relserver上通信

在主10中和从20中修改/etc/keepalived/keepalived.conf文件

在主机10和主机20上面加上这两句话，然后重启服务

然后测试一下VIP在relserver110上是否能够通信

测试成功！！！！！！！

2.7：启用keepalived日志功能

首先进入配置文件中修改配置文件

vim /etc/sysconfig/keepalived

然后修改 /etc/rsyslog.conf中的文件

root@ka1 ~]# vim /etc/rsyslog.conf

然后重启keepalived服务和rsyslog服务并查看日志是否生成

[root@ka1 ~]# systemctl restart keepalived.service
[root@ka1 ~]# systemctl restart rsyslog.service
[root@ka1 ~]# ll /var/log/keepalived.log
-rw-------. 1 root root 383089 Aug 14 02:33 /var/log/keepalived.log

测试成功！！！！！！！！

2.8：实现独立子配置文件

当生产环境复杂时， /etc/keepalived/keepalived.conf 文件中内容过多，不易管理

将不同集群的配置，比如：不同集群的 VIP 配置放在独立的子配置文件中利用 include 指令可以实现包含子配置文件

首先进入配置文件添加内容

vim /etc/keepalived/keepalived.conf

include "/etc/keepalived/conf.d/*.conf" ####记得把上面写的vrrp全部注释掉，不然会影响

然后创建放子配置文件目录并且把子配置文件放进去

mkdir -p /etc/keepalived/conf.d

vim /etc/keepalived/conf.d/172.25.254.100.conf

vrrp_instance web {
state MASTER
interface eth0
virtual_router_id 100
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.254.100 dev eth0 label eth0:1
}
}
}

这样就实现了子配置文件的独立！！！

三：Keepalived 企业应用示例

3.1：抢占模式和非抢占模式

默认为抢占模式 preempt ，即当高优先级的主机恢复在线后，会抢占低先级的主机的 master 角色，

这样会使 vip 在 KA 主机中来回漂移，造成网络抖动，

建议设置为非抢占模式 nopreempt ，即高优先级主机恢复后，并不会抢占低优先级主机的 master 角色

非抢占模块下 , 如果原主机 down 机 , VIP 迁移至的新主机 , 后续也发生 down 时 , 仍会将 VIP 迁移回原主机

注意：要关闭 VIP 抢占，必须将各 keepalived 服务器 state 配置为 BACKUP

在KA1上的配置

在KA2上的配置

此时就处于非抢占模式了

测试。假设主机10的主机坏掉了，看此时VIP会不会到20上去

[root@ka1 ~]# systemctl stop keepalived.service

测试成功！！！！

3.2：抢占延迟模式 preempt_delay

抢占延迟模式，即优先级高的主机恢复后，不会立即抢回 VIP ，而是延迟一段时间（默认 300s ）再抢回 VIP

preempt_delay # # 指定抢占延迟时间为 #s ，默认延迟 300s

注意：需要各keepalived服务器state为BACKUP,并且不要启用 vrrp_strict

KA1上的配置

KA2上的配置

测试：首先把KA1的keepalived服务关掉，此时VIP到主机20上，然后重启KA1的keepalived服务，此时VIP会延迟10s才会到达KA1

测试成功！！！！！！

3.3：VIP单播配置

默认 keepalived 主机之间利用多播相互通告消息，会造成网络拥塞，可以替换成单播，减少网络流量

注意：启用 vrrp_strict 时，不能启用单播

# 在所有节点 vrrp_instance 语句块中设置对方主机的 IP ，建议设置为专用于对应心跳线网络的地址，而非使

用业务网络

unicast_src_ip <IPADDR> # 指定发送单播的源 IP

unicast_peer {

<IPADDR> # 指定接收单播的对方目标主机 IP

......

}

在KA1中的配置

在KA2中的配置

做这个实验时，记得注释掉以下内容

否则与VIP单播模式冲突！！！！

此时在KA1中测试单播

测试成功！！！！！！！！！！！！！！

3.4：Keepalived 通知脚本配置

这个我单独写了一篇博客，请看

https://blog.csdn.net/qq_26553949/article/details/141138520

3.5:实现 master/master 的 Keepalived 双主架构

master/slave 的单主架构，同一时间只有一个 Keepalived 对外提供服务，此主机繁忙，而另一台主机却很空闲，利用率低下，可以使用master/master 的双主架构，解决此问题。

master/master 的双主架构：

即将两个或以上 VIP 分别运行在不同的 keepalived 服务器，以实现服务器并行提供 web 访问的目的，提高服务器资源利用率

KA1配置：（新加的第二个从）

KA2配置（新加的第二个主）

然后两边都重启keepalived服务

此时两边都有自己的VIP，查看两边的VIP

KA1：

KA2：

此时关闭KA2的keepalived服务，看VIP会不会跑到KA1来继续工作！

实验成功！！！！！！！！！

3.6：实现IPVS的高可用性

3.6.1 IPVS相关配置

3.6.1.1 虚拟服务器配置结构

virtual_server IP port {

...

real_server {

...

}

real_server {

...

}

…

}

3.6.1.2 virtual server （虚拟服务器）的定义格式

virtual_server IP port # 定义虚拟主机 IP 地址及其端口

virtual_server fwmark int #ipvs 的防火墙打标，实现基于防火墙的负载均衡集群

virtual_server group string # 使用虚拟服务器组

3.6.1.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 { ... } # 定义当前主机健康状

态检测方法

}

}

# 注意 : 括号必须分行写 , 两个括号写在同一行 , 如 : }} 会出错

3.6.1.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 发出健康状态检测请求时使用的源端口

}

3.6.1.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：实战案例

3.6.2.1 实战案例1：实现单主的 LVS（DR模式）+keepalived

准备 web 服务器并使用脚本绑定 VIP 至 web 服务器 lo 网卡

# 准备两台后端 RS 主机

[root@relserver1 ~]# yum install httpd -y

[root@relserver1 ~]# echo RS1 - 172.25.254.110 > /var/www/html/index.html

[root@relserver1 ~]# ip a a 172.25.254.100/32 dev lo
[root@relserver1 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
[root@relserver1 ~]# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
[root@relserver1 ~]# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce[root@relserver1 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

[root@relserver2 ~]# yum install httpd -y

[root@relserver2 ~]# echo RS1 - 172.25.254.120 > /var/www/html/index.html

[root@relserver2 ~]# ip a a 172.25.254.100/32 dev lo
[root@relserver2 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
[root@relserver2 ~]# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
[root@relserver2 ~]# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce[root@relserver2 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

配置keepalived

KA1的配置

KA2的配置

然后把两边的keepalived服务重启一下

然后在KA1和KA2上安装ipvsadm，

yum install ipvsadm -y

然后都把策略清空

ipvsadm -C

然后重启keepalived服务，看KA1和KA2的策略

KA1：

KA2：

然后在测试一下，看是否成功

3.7 实现其它应用的高可用性 VRRP Script

keepalived 利用 VRRP Script 技术，可以调用外部的辅助脚本进行资源监控，并根据监控的结果实现优先动态调整，从而实现其它应用的高可用性功能

参考配置文件： /usr/share/doc/keepalived/keepalived.conf.vrrp.localcheck

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

}

3.7.1.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 # 设置默认标记为失败状态，监测成功之后再转换为成功状态

}

3.7.1.2 调用 VRRP script

vrrp_instance test {

... ...

track_script {

check_down

}

}

3.7.2:实战案例：利用脚本实现主从角色切换

KA1上操作：

首先在/etc/keepalived下创建chl.sh脚本，并且授权

[root@ka1 ~]# vim /etc/keepalived/chl.sh
[root@ka1 ~]# chmod +x /etc/keepalived/chl.sh
[root@ka1 ~]# cat /etc/keepalived/chl.sh
#!/bin/bash
[ ! -f /mnt/chl ]

然后在修改/etc/keepalived/keepalived.conf中的文件

然后 touch /mnt/chl 会发现KA1的VIP没有了，跑到KA2去了

3.7.3 实战案例：keepalived+haproxy的高可用集群

首先在主机10和主机20中安装haproxy

yum install haproxy -y

在两个ka1和ka2先实现haproxy的配置

listen webserver
bind 172.25.254.100:80
mode http
balance roundrobin
server web1 172.25.254.110:80 check inter 2 fall 3 rise 5
server web2 172.25.254.120:80 check inter 2 fall 3 rise 5

在两个ka1和ka2两个节点启用内核参数

vim /etc/sysctl.conf

在ka1和ka2中编写检测脚本

[root@ka1 ~]# cat /etc/keepalived/chl.sh
#!/bin/bash
/usr/bin/killall -0 haproxy

并且给这个文件赋予权限

chmod +x /etc/keepalived/chl.sh

在KA1和KA2中配置keepalived文件

KA1:

KA2:

然后重启服务！！！

客户端测试：

[C:\~]$ curl 172.25.254.100
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21 100 21 0 0 9868 0 --:--:-- --:--:-- --:--:-- 10500
rs1 - 172.25.254.110

[C:\~]$ curl 172.25.254.100
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21 100 21 0 0 8410 0 --:--:-- --:--:-- --:--:-- 10500
rs2 - 172.25.254.120

测试成功！！！！！！！！！！！！