Keepalived高可用切换过程

IT那活儿发布于2023-01-11 11:34 / 822人阅读

Keepalived高可用切换过程

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

一

keepalived简介

Keepalived对于运维人员来说是一款熟悉的高可用工具，在很多没有原生实现分布式高可用的中间件和数据库中都得到了广泛的使用，例如keepalived+nginx实现对nginx的高可用，keepalived+MySQL实现对MySQL的高可用。

在各种分布式集群通过多副本多节点方式或者微服务的服务发现机制实现高可用大行其道的今天，keepalived实现高可用的方式较为传统，通过VIP飘逸的方式实现应用的高可用。虽然这种方式有其存在的问题，例如切换动作较慢；没有分布式选举机制，容易在网络环境较差的场景下产生脑裂等问题；但也有其优势，就是对中间件几乎做到了0侵入，上手容易且适配简单。

由于keepalived存在的时间很长，所以网络上对于其部署和应用的案例很多，这里我不再赘述其安装步骤，这里主要介绍其一些模式和使用场景，以及通过抓包的方式展现其高可用切换的流程。

二

Keepalived模式分类

Keepalived可以按照抢占模式和心跳机制分为5种模式。

2.1 非抢占模式

非抢占意思为当master宕机，在backup中选取主机为新的master，并修改将VIP给予新的master后。当原来的master恢复后，VIP依旧保持在新的master上，不再迁移。

这种情况主要针对崩溃主机恢复后依然会崩溃的场景下，例如需要对旧master的MySQL进行检查修复，此时需要启动MySQL，防止启动后VIP进行切换。

2.1.1 配置方式

1）将所有主机的优先级priority配置相同；
2）将所有主机的主备模式配置为BACKUP。

2.1.2 适用场景

1）适合master和backup的服务器配置相同，backup具有master相同的承载能力，能长时间稳定承载业务的场景。
2）适合master与backup网络波动较大的场景，减少vip在master和backup上频繁飘逸。

2.2 抢占模式

抢占意思为当master宕机，在backup中选取主机为新的master，并修改将VIP给予新的master后。当原来的master恢复后，VIP从新的master转移到旧的master上面。

这样配置有缺点：如果短时间内网络抖动频繁，vip会频繁飘移，而vip的飘逸需要时间，进而可能会影响业务。

2.2.1 配置方式

1）将master主机的优先级大于其他的BACKUP。
2）将master主机的主备模式配置为BACKUP，将其他主机主备模式配置为BACKUP。

2.2.2 适用场景

1）适合master与backup服务器配置不同，backup性能低于master，无法长时间承载业务。backup仅作为master临时备份的场景。
2）适合master与backup网络波动较小的场景，当master恢复后能及时切换回去。

2.3 灵活模式

灵活模式就是利用vrrp_script的weight值对节点的优先级priority进行重新计算。这种场景适用于脚本监听的情况，例如当脚本检测到应用宕机后，就给master优先级减去相应的优先级，此时就会发生切换。

2.3.1 配置方式

1）将master主机的优先级大于其他的BACKUP。
2）在检测脚本中配置weight值，可以影响每个节点的优先级。

注：当两个节点优先级相同时，发送VRRP通告报文的IP作为比较对象，IP较大者为MASTER。

2.3.2 适用场景

适合需要灵活配置的场景。

2.4 组播模式

组播模式是指keepalived发送VRRP心跳报文是通过组播的方式。

默认情况下keepalived启动后会自动加入设置的组播地址，进而就能收到来自master的VRRP组播报文。组播地址可以在配置文件中通过 vrrp_mcast_group 配置。同一虚拟路由组播地址必须配置相同，默认的组播地址为 224.0.0.18。master每隔固定频率向组播地址发送VRRP报文。BACKUP收到master的VRRP报文根据优先级判断是否需要抢占VIP，如果在规定时间3倍时间内未收到来自master的VRRP报文，也会判断master宕机，进而抢占VIP。

所有BACKUP节点只负责处理MASTER发出的多播包，当发现master的优先级没自己高，或者没收到master的VRRP通告时，BACKUP将自己切换到master状态。

#以下示例为三台服务器都部署了keepalived组播模式，我们查看三台服务器的组播地址发现，三台服务器都加入了组播地址。

2.4.1 组播的优势

配置方便，由于配置文件中并未指定BACKUP的IP地址，而是通过组播的方式来进行通讯。所以我们可以随时向集群中添加节点，而不用重启已运行的节点。

2.4.2 适用场景

1）适用于支持组播的网络的场景。
2）适用于后期需要向keepalived组内添加其他节点的场景。可以不用修改重启其他的keepalived，可以作为无感添加。

2.5 单播模式

keepalived不仅支持组播，还支持单播。组播是master在局域网内向组播地址进行发送VRRP报文，加入组播地址的BACKUP主机就会收到来自master的VRRP心跳报文，就可以判断目前master的状态。单播就是master通过点对点只向配置文件中指定的BACKUP发送VRRP报文。

2.5.1 单播的优势

1）虚拟路由ID只是在组播的模式下有意义，因为在组播模式下，BACKUP用来区分收到的组播VRRP报文是不是给自己的，所以在组播的模式下virtual_router_id在不同虚拟路由组不能重复。但是在单播中，采用的是点对点模式，所以在一个局域网内virtual_router_id重复也是可以的。
2）对环境的要求更低。可能某些环境下不支持组播。

2.5.2 适用场景

1）适用于不支持组播的网络环境，例如有些公有云不支持组播。
2）适用于keepalived组内成员后期变动小场景。

三

组播模式配置

#这里进行了配置的简化，只对关键的配置进行了整理：

global_defs {
router_id k8s-11 #表示这台主机的ID，默认情况下为主机名
vrrp_skip_check_adv_addr #此配置为如果收到的报文和上一个报文是同一个路由器则跳过检查报文中的源地址。主要为了提高性能
vrrp_iptables #避免生成iptables input链 规则
vrrp_strict #严格遵守VRRP协议,不允许状况:1,没有VIP地址,2.配置了单播,3.在VRRP版本2中有IPv6地址
vrrp_garp_interval 0 #ARP报文发送延迟
vrrp_gna_interval 0 #消息发送延迟
vrrp_mcast_group 224.0.0.18    #指定组播IP地址，默认为224.0.0.18
}

vrrp_script check_nginx { #脚本配置
pass
}

vrrp_instance VI_1 {
state BACKUP #当前节点在此虚拟路由器上的状态，状态为MASTER或者BACKUP，一般都配置为backup，最终需要权重来进行比较
interface ens33 #绑定为当前虚拟路由器使用的物理接口，如eth0
virtual_router_id 11 #每个虚拟路由器唯一标识，范围0-255。同一组虚拟路由器的vrid需要保持一致。
priority 100 #当前物理节点在此虚拟路由器的优先级，范围1-254
advert_int 1 #vrrp通告的时间间隔（心跳），默认1s
authentication { #认证机制
auth_type PASS
auth_pass 88888888
}

virtual_ipaddress { #配置虚拟IP
192.168.200.16 #指定VIP，不指定网卡，默认为eth0。默认为/32
192.168.200.17/24 dev ens33
#指定VIP的网卡
192.168.200.18/24 dev ens33 label ens33:1
#指定VIP的网卡label
}

track_script { #执行脚本
check_nginx
}
}

注：最开始学习keepalived的时候很好奇，keepalived是怎么知道其他BACKUP节点的。后来发现默认情况下keepalived的组播地址为224.0.0.18，master只需要将VRRP报文发送到这个地址就能被同一局域网内所有其他启动keepalived并加入相同组播地址的服务器接收到。

组播模式下服务器抓包情况：

以下三台服务器192.168.100.11-13服务器配置了keepalived组播模式，分别对三台服务器进行了抓包。

我们可以看到，由于三台服务器都加入了224.0.0.18这个组播地址，此时192.168.100.11为MASTER，192.168.100.11服务器向组播地址224.0.0.18发送了VRRP心跳报文，所以加入此组播地址的三台服务器都收到了VRRP心跳报文。

四

单播模式配置

#和上面组播模式相似的配置不再进行解释。

global_defs {
router_id k8s-21
vrrp_skip_check_adv_addr
vrrp_iptables
# vrrp_strict #此选项必须关闭
vrrp_garp_interval 0
vrrp_gna_interval 0
}

vrrp_script check_nginx {
pass
}

vrrp_instance VI_2 {
state MASTER
interface ens33
virtual_router_id 21
priority 100
advert_int 2

authentication {
auth_type PASS
auth_pass 88888888
}

unicast_src_ip 192.168.100.21 #本机IP地址
unicast_peer {
192.168.100.22 #同一keepalived组内其他节点IP地址
192.168.100.23 #同一keepalived组内其他节点IP地址
}

virtual_ipaddress {
192.168.100.200/24 dev ens33 #虚拟VIP地址
}

track_script {
check_nginx
}
}

单播模式下服务器抓包情况：

以下三台服务器192.168.100.21-23服务器配置了keepalived单播模式，此时192.168.100.21服务器为MASTER，我们在其上进行抓包。发现在同一时刻，192.168.100.21分别向192.168.100.22-23发送了单播的VRRP心跳报文。

五

keepalived切换选举过程

这里通过抓包的方式简单分析keepalived一些切换场景。

5.1 组播模式下master优先级降低选举过程

此处模拟192.168.100.11-13为一组keepalived，且192.168.11为master。

1）默认情况下会master会一直发送组播消息，每隔一秒钟向配置的组播地址发送报文，报文信息会包含此时master的优先级的值。组播的默认地址为224.0.0.18。

2）当master上的检测脚本发现nginx服务宕机，此时master的优先级由100变为70。master还是依旧每秒一次向组播地址发送自己的优先级报文，此时BACKUP收到网络中优先级变化（优先级不高于自己）的VRRP组播报文，所有BACKUP会立即激活抢占功能，向组播地址发送VRRP报文，报文包含自身目前的优先级。

注：可以看到，当BACKUP收到master优先级变化的报文，几乎是立即向组播地址内发送自己优先级的VRRP报文。

3）两个BACKUP经过优先级对比，最终由于192.168.100.12优先级为80，获得VIP。并开始向组播地址发送优先级VRRP报文。

5.2 组播模式下当BACKUP超时未收到master的报文

#这种情况为master宕机，或者master的keepalived进程被kill。当BACKUP超过配置文件中配置的VRRP报文频率advert_int 3倍时长后，BACKUP会发出VRRP报文，将VIP抢占。

通过以上抓包分析可见，keepalived的选举机制是很简单的，就是简单利用心跳报文+节点优先级进行选举master，这种方式不可避免的会产生分区脑裂的故障。如果要避免分区脑裂的问题，目前成熟的解决方案是采用分布式选举算法，例如zookeeper使用的ZAB算法，kafka使用的Raft算法。

六

VRRP协议报文头

#共20byte。

6.1 通过抓包可以发现，VRRP协议是属于网络层上面的协议，不基于传统的传输层TCP和UDP，所以它的通讯没有端口的概念。VRRP协议内置在Linux内核的网络协议栈中。

6.2 通过抓包我们可以发现VRRP报文只有20byte，但是包含了Virtual_ID，优先级等信息。所以配置文件中这些配置非常重要。

6.3 通过抓包我们也可以很容易解释为什么网上说keepalived配置文件中的Virtual_ID必须要配置一样，因为在同一个组播地址中同一组keepalived的其他节点只会识别Virtual_ID与自己相同的VRRP报文。当然，在同一个局域网中如果有多组keepalived都采用组播模式，那么必须满足不同组keepalived的Virtual_ID必须不同，或者不同组keepalived的组播地址配置不同。不然会发生干扰，VIP可能会出现”跨组飘移”。

感谢大家的阅读，VRRP还有一些小的细节处，需要大家共同的发掘探讨。

本文作者：王旭东(上海新炬中北团队）

本文来源：“IT那活儿”公众号

GPU云服务器云服务器 ECS可用区切换高可用高可用集群云计算高可用

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129108.html

Nginx+Keepalived实现站点高可用

摘要：在协议实现里，虚拟路由器使用作为虚拟地址，就是唯一的，这个地址同一时间只有一个物理路由器占用。在虚拟路由器里面的物理路由器组里面通过多播地址来定时发送通告消息。负责健康检查，包括常见的各种检查方式。公司内部 OA 系统要做线上高可用，避免单点故障，所以计划使用2台虚拟机通过 Keepalived 工具来实现 nginx 的高可用（High Avaiability），达到一台nginx...

Songlcy 2019-07-25 13:32 评论0 收藏0
MySQL高可用方案测试

MySQL高可用方案测试 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin...

IT那活儿 2023-01-11 13:19 评论0 收藏2496
基于腾讯云CVM自建高可用Redis实践

摘要：环境说明需求与目标本文将通过对目前主流的几种高可用方案进行对比分析，并基于腾讯云和等基础产品进行搭建配置测试总结。本文来源 | 云+社区专栏文章作者 | 万守兵，腾讯云资深架构师。8年以上大型互联网公司运维工作经验，腾讯云资深迁云架构师，一直从事大型互联网服务端架构设计和优化工作。个人专注于云计算、k8s和 DevOps领域。导读：在企业实际生产环境中为了能够给业务上层应用提供高...

DataPipeline 2019-06-24 18:23 评论0 收藏0
实现高可用的两种方案与实战

摘要：高可用的首要想法就是双机热备，故障时自动切换，所以我们要给加一个备机。注下面实现高可用都用的是双机热备，为了方便，把调度服务器简称为主机，把调度服务器的备机简称为备机。我之前在一片文章用Nginx+Redis实现session共享的均衡负载中做了一个负载均衡的实验，其主要架构如下： showImg(https://segmentfault.com/img/bVushO); 把de...

seal_de 2019-08-15 17:45 评论0 收藏0