keeplivead 高可用集群--基本配置
keeplivead 高可用集群–基本配置
集群的分类
LB负载均衡集群,将请求分发到多个节点,提升系统吞吐量和响应速度
前端负载均衡器接收请求,按算法分发至后端服务器
支持会话保持(Session Persistence)确保用户连续性
软件:Nginx、HAProxy、LVS(Linux Virtual Server)高可用性集群(High Availability Cluster, HA Cluster)
消除单点故障,保障服务持续可用(通常要求 99.999% 以上的可用性)
采用主备(Active-Standby)或双活(Active-Active)架构
通过心跳机制(Heartbeat)监控节点状态
故障发生时自动触发故障转移(Failover),将服务迁移至健康节点
软件: Keepalived
高可用集群
高可用集群就是当某一个节点或服务器发生故障时,另一个节点能够自动且立即向外提供服务,就是将有故障节点上的集群资源 转移到另一个节点上,这样另一个节点有了资源既可以向外提供服务。高可用集群适用于单个节点发生故障时,能够自动将服务进行切换,这样可以保证服务一直在线。在整个过程中,对于客户端来说是透明的 不可见的。
高可用集群的三种方式
主从方式(非对称)
这种方式组建的高可用集群通常包含2个节点和一个或多个服务器,其中一台作为主节点(active),另一台作为备份节点(standy)。备份节点随时都在检测主节点的健康状况,当主节点发生故障时,服务会自动切换到备份节点上以保证服务正常运行。这种方式下的高可用集群其中的备份节点平时不会启动服务,只有发生故障时才会启动对称方式
这种方式一般包含2个节点和一个或多个服务,其中每一个节点都运行着不同的服务且相互作为备份,两个节点互相检测对方的健康状况,这样当其中一个节点发生故障时,该节点上的服务会自动切换到另一个节点上去。这样可以保证服务正常运行。可用性会相对降低多机方式
这种集群包含多个节点和多个服务。每一个节点都可能运行或不运行服务,每台服务器都监视着几个指定的服务,当其中的一个节点发生故障时,会自动切换到这组服务器中的一个节点上去。
keepalived理论工作原理
keepalived是以VRRP协议为基础实现的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。
虚拟路由冗余协议是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播 广播 或单播,当backup收不到vrrp包时就认为master宕机,这时就需要根据VRRP的优先级来选举一个backup成为master。这样的话就可以保证路由器的高可用了。
keepalived 工作在osi的三层、四层和七层原理
Layer3:工作在三层时,keepalived会定期向热备组中的服务器发送一个ICMP数据包,来判断某台服务器是否故障,如果故障则将这台服务器从热备组移除。
Layer4:工作在四层时,keepalived以TCP端口的状态判断服务器是否故障,比如检测mysql 3306端口,如果故障则将这台服务器从热备组移除
Layer7:工作在七层时,keepalived根据用户设定的策略判断服务器上的程序是否正常运行,如果故障则将这台服务器从热备组移除
keepalived 官网http://www.keepalived.org
keepalived部署
keepalived的安装
到官网下载最新的keepalived的安装包
将安装包上传到服务器中并解压缩
1 | |
使用yum安装keepalived所需依赖包
1 | |
进入到keepalived的安装目录,安装keepalived
1 | |

安装完成之后,可以看到keepalived的默认安装目录就是在/usr/local下面,我们需要将他的配置文件以及可执行文件拷贝到常用的目录中方便管理
1 | |
现在就可以使用systemctl的方式管理keepalived了
1 | |
keepalived默认在安装好之后,在
/etc/keepalived/中是有一个默认的keepalived.conf.sample的示例脚本的,后续可以通过复制这个脚本来修改keepalived的配置。
keepalived配置
keepalived,VRRP双主机热备(简单配置)
要使用keepalived的服务,就需要修改配置文件,通过复制keepalived.conf.sample示例文件,或者是直接创建一个新的keepalived.conf配置文件
1 | |
添加如下配置:
1 | |
配置说明:
全局定义(global_defs)
1 | |
router_id:本节点的唯一标识符,用于日志和集群内部识别。
此处命名为 haweb_1,通常主备节点应设置不同(如 haweb_1 和 haweb_2)。
VRRP 同步组(vrrp_sync_group)
1 | |
将多个 VRRP 实例(此处仅 VI_HA)绑定为一个同步组。
当组内任一实例状态变化(如 MASTER ↔ BACKUP 切换),其他实例会同步切换,避免状态分裂。
适用于多虚拟 IP 或多服务需统一主备切换的场景。
VRRP 实例配置(vrrp_instance VI_HA)
Keepalived 配置项说明表
| 配置项 | 说明 | ⚠️ 注意事项 |
|---|---|---|
state MASTER |
声明本节点初始角色为主节点(MASTER) | • Keepalived 不严格区分大小写,但规范写法应为大写 MASTER• 实际角色由优先级决定:若对端节点 priority > 90,本节点仍会降级为 BACKUP |
interface eth0 |
VRRP 通告发送和 VIP 绑定的物理网卡 | • 需确认该接口在系统中存在(ip link show eth0)• 主备节点必须在同一二层网络(可直接通信) |
virtual_router_id 51 |
VRRP 虚拟路由器组 ID(范围 0–255) | • 主备节点必须完全一致,否则无法组成 VRRP 集群 • 同一网络中不同业务应使用不同 ID 避免冲突 |
priority 90 |
本节点优先级(范围 1–255,值越大越优先) | • ⚠️ 逻辑矛盾:声明为 MASTER 但优先级仅 90• 通常主节点设为 100,备节点设为 90• 优先级决定实际角色, state 仅影响启动时的初始状态 |
advert_int 5 |
VRRP 通告间隔时间(秒) | • 默认值为 1 秒,此处设为 5 秒• 故障检测延迟 ≈ 3 × advert_int(约 15 秒)• 生产环境建议保持默认 1 秒以加快故障切换 |
authenticationauth_type PASSauth_pass test |
VRRP 通信认证配置 | • PASS 为明文密码认证,安全性较低• auth_pass 值在主备节点必须完全一致• 生产环境建议配合防火墙限制 VRRP 组播(224.0.0.18) |
virtual_ipaddress10.201.9.177/24 dev eth0 |
虚拟 IP 地址(VIP) | • 由 MASTER 节点持有并响应 ARP 请求 • MASTER 故障时,BACKUP 自动接管此 IP(IP 漂移) • 客户端始终访问此 VIP,实现服务无缝切换 |
检查配置文件语法格式是否正确
1 | |
到目前为止第一台keepalived就搭建好,因为keepalived是高可用,一台肯定是不行的,所以我这里还需要再搭建一台keepalived的服务器。按照以上搭建方法搭建即可备机的keepalived配置如下
1 | |
修改state为BACKUP,priority 为90(比主机小即可)。
keepalived测试
启动两台服务器的keepalived服务
1 | |
这个时候可以看到,在keepalived的master上面会多一个IP地址,就是刚刚在配置文件中配置的虚拟IP
1 | |
在两台keepalived的服务器中,都安装上nginx,并修改nginx的默认访问页面,进行测试
在Master中修改如下:
1 | |
修改默认访问页面中的H1标签带有IP地址,方便后续切换时测试查看
在BACKUP中修改如下:
这里我的master主机和backup的nginx使用的安装方式不一样,所以配置文件所在路径不一样,按照实际的配置即可。
1
2[root@node1 html]# cd /usr/share/nginx/html
[root@node1 html]# echo "<h1> This is Backup 10.201.9.133 </h1>" > index.html
重启nginxnginx -s reload 或者是 systemctl restart nginx
测试访问
我在上面配置的虚拟IP是10.201.9.177,那么我这边再访问的时候,也是使用虚拟IP进行访问
可以看到在浏览器中输入虚拟IP的地址优先访问的是我们的主机Master,现在把master上面的keepalived服务停止,模拟服务器故障。systemctl stop keepalived
1 | |
在访问虚拟IP测试,可以看到,keepalived已经自动切到了backup节点上提供服务了。
将Master的keepalived服务在启动起来,大约过5秒左右,Master并会成功抢占服务,又Master节点正常提供服务。
简易架构如如下: