网站导航
> 技术文档 > Keepalived 深度技术解析与高可用实践指南

Keepalived 深度技术解析与高可用实践指南

网友: 技术文档 2025-07-26 20:49:51

简介：

基本概念

Keepalived 是一款基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议 ）协议实现的高可用（HA）解决方案，常用于保障服务器集群中关键服务的持续运行，避免单点故障。它能自动检测服务器状态，当主服务器出现故障时，快速将虚拟 IP（VIP）切换到备用服务器，确保业务不中断。

核心功能

（一）健康检查

通过配置的检测脚本或机制，持续监控服务器上运行的服务（如 Nginx、Apache、MySQL 等 ）状态。例如，定期检查 Web 服务端口是否可访问、服务进程是否存活，一旦发现服务异常，触发故障转移。

（二）高可用性

基于 VRRP 协议，Keepalived 集群中的服务器分为主（Master）、备（Backup）角色。主服务器正常时，对外提供虚拟 IP 服务；当主服务器故障，备服务器通过 VRRP 协商，抢占虚拟 IP，接管服务，保证业务连续性。这个过程实现了自动故障转移。当主服务器宕机时，备份服务器几乎可以瞬间（毫秒级）接管 VIP 和服务，对客户端来说服务几乎是连续的（短暂中断或 TCP 重连）。

（三）负载均衡（结合 LVS ）

Keepalived 可与 Linux 虚拟服务器（LVS）集成，实现负载均衡功能。它能根据预设的调度算法（如轮询、加权轮询、最少连接等 ），将客户端请求合理分配到后端多台真实服务器，提升服务整体响应能力和吞吐量。

一、高可用集群

1.1.集群类型

  1. LB：Load Balance 负载均衡
  2. LVS/HAProxy/nginx（http/upstream, stream/upstream）
  3. HA：High Availability 高可用集群
  4. 数据库、Redis
  5. SPoF: Single Point of Failure，解决单点故障
  6. HPC：High Performance Computing 高性能集群

1.2.系统可用性 

SLA：Service-Level Agreement 服务等级协议（提供服务的企业与客户之间就服务的品质、水准、性能 等方面所达成的双方共同认可的协议或契约） A = MTBF / (MTBF+MTTR）

99.95%:(60*24*30)*(1-0.9995)=21.6分钟 #一般按一个月停机时间统计

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

1.3 系统故障 

硬件故障：设计缺陷、wear out（损耗）、非人为不可抗拒因素 软件故障：设计缺陷 bug

1.4 实现高可用 

提升系统高用性的解决方案：降低MTTR- Mean Time To Repair(平均故障时间) 解决方案：建立冗余机制

  1. active/passive 主/备
  2. active/active 双主
  3. active --> HEARTBEAT --> passive
  4. active HEARTBEAT active

1.5.VRRP：Virtual Router Redundancy Protocol 

VRRP 协议栈工作流程

sequenceDiagram participant Master participant Backup Master->>Backup: 周期性发送Advertisement报文(组播224.0.0.18) Backup->>Master: 监听Master状态 alt Master正常 Backup->>Backup: 保持BACKUP状态 else Master超时(3*adv_int) Backup->>Backup: 切换为MASTER Backup->>Network: 发送GARP宣告VIP接管 end

 虚拟路由冗余协议,解决静态网关单点风险

物理层:路由器、三层交换机

软件层:keepalived

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

工作方式：

  1. 抢占式
  2. 非抢占式

安全认证：

  1. 无认证
  2. 简单字符认证：预共享密钥
  3. MD5

工作模式：

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

 二、Keepalived 部署和实验

实验环境要求

  1. 各节点时间必须同步：ntp, chrony
  2. 关闭防火墙及SELinux
  3. 各节点之间可通过主机名互相通信；非必须
  4. 建议使用/etc/hosts文件实现；非必须
  5. 各节点之间的root用户可以基于密钥认证的ssh服务完成互相通信；非必须

KeepAlived 配置说明

配置文件组成部分

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

配置文件组成GLOBAL CONFIGURATIONGlobal definitions： 定义邮件配置，route_id，vrrp配置，多播地址等VRRP CONFIGURATIONVRRP instance(s)： 定义每个vrrp虚拟路由器LVS CONFIGURATIONVirtual server group(s)Virtual server(s)： LVS集群的VS和RS
全局配置

 配置虚拟路由器

 实验环境搭建如下

主机 IP 需安装的软件 KA1 172.25.254.50/24 keepalived KA2 172.25.254.60/24 keepalived RS1 172.25.254.10/24 nginx、mysql-server RS2 172.25.254.20/24 nginx、mysql-server

 准备四台主机，两keepalived两后端服务器RS，全部关闭火墙和selinux，时间同步 

 关闭火墙：
systemctl disable firewalld
时间同步：

 

 KA1和KA2

 安装keepalived：

修改配置文件：
vim /etc/sysconfig/keepalived

 测试：

 RS1和RS2

ip a a 172.25.254.100/32 dev lovim /etc/sysctl.conf

 启用keepalived日志功能

将 Keepalived 日志从系统日志（如 /var/log/messages）中分离出来，是生产环境运维的关键实践。

默认情况下，Keepalived 的日志会混在系统日志中（如 /var/log/messages 或 /var/log/syslog），单独配置 Keepalived 日志可以：

  1. 更方便地监控和排查 Keepalived 相关问题

  2. 避免与其他系统日志混杂

  3. 便于日志轮转和管理

配置：
vim /etc/sysconfig/keepalived

vim /etc/rsyslog.conf

 

重启服务 

systemctl restart keepalived.servicesystemctl restart rsyslog.service

 测试：

 

 独立子配置文件

PS：接下来的实验不需要用到，可以不配置，配置了的为了不影响接下来的实验，也尽量去还原实验环境。

在复杂的生产环境中，Keepalived 主配置文件(/etc/keepalived/keepalived.conf)可能变得非常庞大和难以管理。使用子配置文件可以：

  1. 模块化管理：将不同功能的配置分离到不同文件

  2. 便于维护：单独修改某个服务配置而不影响其他部分

  3. 降低风险：减少因修改配置导致的整体服务中断

  4. 团队协作：不同管理员可以负责不同部分的配置

配置：
创建子配置文件目录mkdir -p /etc/keepalived/conf.d修改主配置文件vim /etc/keepalived/keepalived.conf重启服务systemctl restart keepalived.service

vim /etc/keepalived/conf.d/webvip.conf

 

 延迟抢占

 抢占模式(preempt) 与 非抢占模式(nopreempt)

  • 抢占模式：当高优先级节点恢复后，立即夺回MASTER角色

  • 非抢占模式：节点保持当前状态，即使高优先级节点恢复

延迟抢占(preempt_delay)

折中方案：高优先级节点恢复后，等待指定时间再抢占MASTER角色

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

优势：

  • 避免网络抖动导致的频繁切换

  • 给原MASTER节点完成现有连接的时间

  • 减少服务中断时间

配置： 

KA1和KA2

vim /etc/keepalived/keepalived.confsystemctl restart keepalived.service

 测试：

 先关闭KA1的keepalived服务，在KA2上开监视器，方便查看变化

KA1systemctl stop keepalived.serviceKA2watch -n1 ifconfig ——监视tcpdump -i ens160 -nn host 224.0.0.44 ——测试

 再开启KA1的keepalived服务

 约10秒以后（即刚刚设定的延迟抢占时间）由60变成50了，即KA2变成KA1

 组播和单播

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

Keepalived 组播 vs 单播对比表

对比项 组播 (Multicast) 单播 (Unicast) 通信机制 使用组播地址 224.0.0.18 广播通告 点对点定向通信，需手动指定对端 IP 配置复杂度 简单（自动发现节点，无需配置对端） 较复杂（需显式配置每个对端节点的 IP） 网络流量 广播流量，可能占用较多带宽 定向传输，仅限对端节点，流量更可控 云环境兼容性 多数云平台（如 AWS、Azure）默认禁用组播 普遍支持，无限制 安全性 较低（任何主机可监听组播流量） 较高（仅允许指定对端通信） 适用规模 中小规模集群（≤10 节点） 大规模集群（节点数多或跨地域部署） 故障检测速度 依赖组播网络可靠性，延迟可能较高 直接检测对端，响应更快 典型场景 本地局域网、测试环境 公有云、安全要求高的网络、跨机房部署 配置示例 vrrp_mcast_group4 224.0.0.18 unicast_peer { 192.168.1.11 } 与 vrrp_strict 兼容性 兼容 不兼容（需注释 vrrp_strict 选项）

 配置

设置单播
vim /etc/keepalived/keepalived.conf

KA1

 KA2：

测试 

Keepalived 通知脚本配置

Keepalived 可以通过邮件通知管理员关于 VRRP 状态变化、故障切换等重要事件。

当keepalived的状态变化时，可以自动触发脚本的执行

接下来模拟当出现状态变化时，通过邮箱来通知管理员

配置

dnf -y install s-nail sendmailsystemctl enable --now sendmailvim /etc/mail.rc

解释：

set smtp=smtp.163.com —— 这里的163是因为邮箱是网易的，如果你的是别的，如qq，那就写smtp.qq.com，其他邮箱类似
set smtp-auth=login —— 登录
set smtp-auth-user=XXX@163.com —— 这里输入自己的邮箱
set smtp-auth-password=ABCDEFG1234567 —— 这里的码是邮箱stmp认证得到的码
set from=XXX@163.com —— 这里输入自己的邮箱
set ssl-verify=ignore —— 忽略认证

 测试：

echo hello world | mailx -s test +自己的邮箱地址

 

注：如果是QQ邮箱的话，可能会在垃圾箱里

实现keepalived状态切换的通知邮箱脚本

mkdir -p /etc/keepalived/scriptsvim /etc/keepalived/scripts/mail.sh#!/bin/bashmail_dest=\'自己的邮箱\' 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:wq添加可执行权限chmod +x /etc/keepalived/scripts/mail.shvim /etc/keepalived/keepalived.conf

 

 

 

 双主架构

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

双主架构是指两个或多个Keepalived节点同时作为不同VIP的主节点，相互备份，实现：

  • 负载均衡：不同VIP的服务流量分散到不同节点

  • 资源利用：避免单主架构下备用节点闲置

  • 高可用性：单个节点故障不影响所有服务

配置

KA1和KA2上 

dnf -y install ipvsadm vim /etc/keepalived/keepalived.confvirtual_server 172.25.254.100 80 { delay_loop 6 lb_algo rr lb_kind DR protocol TCP real_server 172.25.254.10 80 { weight 1 HTTP_GET { url {  path /  status_code 200 } connect_timeout 2 retry 3 delay_before_retry 3 } } real_server 172.25.254.20 80 { weight 1 TCP_CHECK { connect_timeout 2 retry 3 delay_before_retry 3 connect_port 80 } }}:wqsystemctl restart keepalived.serviceipvsadm -Ln

可以看到KA1是100ip的主，KA2是备

停掉KA1的keepalived，他会自动转到KA2这个备上：

关掉单播

让KA1做DBVIP的BACKUP 

KA2是DBVIP的master： 

测试: 

在KA2上看，就能发现另一个组播，这就是双主

关掉KA2的keepalived之后KA1变为MASTER： 

 数据库mariadb的双主实验

两台RS配置新的ip与启动mariadb服务

ip a a 172.25.254.200/32 dev losystemctl start mariadb.servicesystemctl enable --now mariadb

两台KA配置数据库双主 

vim /etc/keepalived/keepalived.confsystemctl restart keepalived.service

查看策略 

测试：

mysql -ulee -plee -h 172.25.254.200 -e \'select @@server_id\'

关掉RS2的mariadb服务再测试 

 KA2查看一下，就能看到200ip的主是KA2

关闭KA2的keepalived服务再测试

 

 实现HAProxy高可用

配置：

两KA安装haproxy：

dnf -y install haproxyvim /etc/haproxy/haproxy.cfgsystemctl start haproxy.servicesystemctl enable --now haproxy.service

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

 

在两KA中编写检测脚本来检测自己的haproxy程序有没有挂，如果挂了的话就要降低keepalived优先级把MASTER转移 

mkdir -p /etc/keepalived/scripts/vim /etc/keepalived/scripts/haproxy.shchmod +x /etc/keepalived/scripts/haproxy.sh

 配置keepalived配置文件：

测试

 

运行脚本sh /etc/keepalived/scripts/haproxy.sh

关闭KA1的haproxy服务

网络标签：

相关问题