keepalived vip漂移基本原理及选举算法

keepalived可以将多个无状态的单点通过虚拟IP(以下称为VIP)漂移的方式搭建成一个高可用服务,常用组合比如 keepalived+nginx,lvs,haproxy和memcached等。它的实现基础是VRRP协议,包括核心的MASTER竞选机制都是在VRRP协议所约定的。

一、配置说明:
keepalived的配置位于/etc/keepalived/keepalived.conf,配置文件格式包含多个必填/可选的配置段,部分重要配置含义如下:
global_defs: 全局定义块,定义主从切换时通知邮件的SMTP配置。
vrrp_instance: vrrp实例配置。
vrrp_script: 健康检查脚本配置。

细分下去,vrrp_instance配置段包括:
state: 实例角色。分为一个MASTER和一(多)个BACKUP。
virtual_router_id: 标识该虚拟路由器的ID,有效范围为0-255。
priority: 优先级初始值,竞选MASTER用到,有效范围为0-255。
advert_int: VRRP协议通告间隔。
interface: VIP所绑定的网卡,指定处理VRRP多播协议包的网卡。
mcast_src_ip: 指定发送VRRP协议通告的本机IP地址。
authentication: 认证方式。
virtual_ipaddress: VIP。
track_script: 健康检查脚本。

vrrp_script配置段包括:
script: 一句指令或者一个脚本文件,需返回0(成功)或非0(失败),keepalived以此为依据判断其监控的服务状态。
interval: 健康检查周期。
weight: 优先级变化幅度。
fall: 判定服务异常的检查次数。
rise: 判定服务正常的检查次数。

这里有MASTERBACKUP的参考配置。

二、选举算法
keepalived中优先级高的节点为MASTER。MASTER其中一个职责就是响应VIP的arp包,将VIP和mac地址映射关系告诉局域网内其
他主机,同时,它还会以多播的形式(目的地址224.0.0.18)向局域网中发送VRRP通告,告知自己的优先级。网络中的所有BACKUP节点只负责
处理MASTER发出的多播包,当发现MASTER的优先级没自己高,或者没收到MASTER的VRRP通告时,BACKUP将自己切换到MASTER状
态,然后做MASTER该做的事:1.响应arp包,2.发送VRRP通告。

MASTER和BACKUP节点的优先级如何调整?
首先,每个节点有一个初始优先级,由配置文件中的priority配置项指定,MASTER节点的priority应比BAKCUP高。运行过程中keepalived根据vrrp_script的weight设定,增加或减小节点优先级。规则如下:

1. 当weight > 0时,vrrp_script script脚本执行返回0(成功)时优先级为priority + weight, 否则为priority。当BACKUP发现自己的优先级大于MASTER通告的优先级时,进行主从切换。
2. 当weight < 0时,vrrp_script script脚本执行返回非0(失败)时优先级为priority + weight, 否则为priority。当BACKUP发现自己的优先级大于MASTER通告的优先级时,进行主从切换。
3. 当两个节点的优先级相同时,以节点发送VRRP通告的IP作为比较对象,IP较大者为MASTER。

以上文中的配置为例:
HOST1: 10.15.8.100, priority=91, MASTER(default)
HOST2: 10.15.8.101, priority=90, BACKUP
VIP: 10.15.8.102
weight = 2
抓包命令: tcpdump -nn vrrp

示例一:HOST1和HOST2上keepalived和nginx均正常。

1
2
3
4
16:33:07.697281 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102,
prio 93, authtype simple, intvl 1s, length 20
16:33:08.697588 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102,
prio 93, authtype simple, intvl 1s, length 20

此时HOST1优先级为priority + weight = 93,HOST2优先级为priority + weight = 92,HOST1仍为MASTER。

示例二:关闭HOST1上的nginx。

1
2
3
4
5
6
7
8
16:33:09.697928 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102,
prio 93, authtype simple, intvl 1s, length 20
16:33:10.698285 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102,
prio 91, authtype simple, intvl 1s, length 20
16:33:10.698482 IP 10.15.8.101 > 224.0.0.18: VRRPv2, Advertisement, vrid 102,
prio 92, authtype simple, intvl 1s, length 20
16:33:11.699441 IP 10.15.8.101 > 224.0.0.18: VRRPv2, Advertisement, vrid 102,
prio 92, authtype simple, intvl 1s, length 20

HOST1上的nginx关闭后,killall -0 nginx返回非0,HOST1通告的优先级为priority = 91,HOST2的优先级为priority + weight = 92,HOST2抢占成功,被选举为MASTER。相关日志可tail /var/log/messages。

由此可见,主从的优先级初始值priority和变化量weight设置非常关键,配错的话会导致无法进行主从切换。比如,当MASTER初始值定 得太高,即使script脚本执行失败,也比BACKUP的priority + weight大,就没法进行VIP漂移了。所以priority和weight值的设定应遵循: abs(MASTER priority - BAKCUP priority) < abs(weight)。 另外,当网络中不支持多播(例如某些云环境),或者出现网络分区的情况,keepalived BACKUP节点收不到MASTER的VRRP通告,就会出现脑裂(split brain)现象,此时集群中会存在多个MASTER节点。

转载:http://fengchj.com/?p=2156

时间: 2024-10-10 00:45:17

keepalived vip漂移基本原理及选举算法的相关文章

Zabbix监控LVS状态及keepalived VIP漂移

此文只说lvs监控,lvs+keepalived的部署,请参考我另外的文章. http://yangrong.blog.51cto.com/6945369/1575909 1.监控目标 lvs的每秒会话连接数 lvs的每秒包转发数 lvs每秒转发带宽 VIP切换情况 keepalived进程的存活 2.zabbix_sender汇报脚本 主要汇报内容: 会话连接数,每秒包转发数,每秒转发带宽,VIP值 监控python脚本,采用zabbix_sender上报方式: # cat/usr/local

MHA集群(gtid复制)和vip漂移

在上一片博客中,讲述了怎么去配置MHA架构!这片博客不再细说,只说明其中MySQL主从搭建,这里使用的是gtid加上半同步复制! 步骤与上一片博客一样,不同之处在于MySQL主从的搭建!详细的gtid搭建过程https://www.cnblogs.com/wxzhe/p/10055154.html 上一片博客中,把MySQL主从的搭建由filename和pos的过程改变为如下的基于gtid的过程就可以,因此不再详细说明,只展示gtid的搭建! 四台服务器分配如下: MHA管理节点: 10.0.1

图解zookeeper FastLeader选举算法【转】

转自:http://codemacro.com/2014/10/19/zk-fastleaderelection/ zookeeper配置为集群模式时,在启动或异常情况时会选举出一个实例作为Leader.其默认选举算法为FastLeaderElection. 不知道zookeeper的可以考虑这样一个问题:某个服务可以配置为多个实例共同构成一个集群对外提供服务.其每一个实例本地都存有冗余数据,每一个实例都可以直接对外提供读写服务.在这个集群中为了保证数据的一致性,需要有一个Leader来协调一些

Zookeeper实现分布式选举算法

分布式系统中经常采用Master/Slave架构.(截止到目前为止我还没有碰到过其他架构...)这种架构中如果Master发生故障就会导致整个集群停止服务,为了提高系统的高可用性通常采用选举算法来选出Master.这样Master如果出现故障,Slave经过选举算法重新选择Master.通过Zookeeper可以非常容易实现这个功能,关键代码如下:(完整代码见文章最后的GitHub地址) //申请做 leaderString prefix = "/ticket-";String myV

分布式选举算法

分布式选举算法-Paxos (2011-03-20 10:12:56) 转载▼ http://blog.sina.com.cn/s/blog_4b6e0fbb0100q9zh.html 标签: 文化 分类: 计算机杂文 (ZZ)分布式选举算法-Paxos 技术日志 2009-12-04 10:42:05 阅读589 评论0   字号:大中小 订阅 在分布式算法领域,有个非常重要的算法叫Paxos, 它的重要性有多高呢,Google的Chubby [1]中提到 all working protoc

分布式-选举算法

分布式-选举算法 2013-06-01 19:48 2540人阅读 评论(0) 收藏 举报 版权声明:本文为博主原创文章,未经博主允许不得转载. 本文是<分布式系统原理与范型>读书笔记. 分布式选举,现在大家都知道的是Paxos算法..... 许多分布式算法需要一个进程充当协调者.发起者或者其他某种特殊的角色.通常由哪个进程充当这个较色并不重要,重要的是它们中要有一个进程来充当.我们假设每个进程有一个唯一的编号,同时还假设每个进程知道所有其他进程的编号.但是进程不知道当前哪个进程正在运行,以及

Zookeeper中的FastLeaderElection选举算法简述

Zookeeper是一个开源的分布式应用协调项目, 当中为了保证各节点的协同工作,Zookeeper在工作时须要有一个Leader. 而Leader是怎样被选举出来的?Zookeep中使用的缺省算法称为FastLeaderElection. Zookeeper的基本前提是多个节点都具备全局其他全部节点的基本信息(IP/port/SID),而SID是节点的唯一编号. 正常工作时"从节点"会从"主节点"(Leader)同步版本号信息,称为zxid. 一旦整个系统重新启动

图解zookeeper FastLeader选举算法

zookeeper配置为集群模式时,在启动或异常情况时会选举出一个实例作为Leader.其默认选举算法为FastLeaderElection. 不知道zookeeper的可以考虑这样一个问题:某个服务可以配置为多个实例共同构成一个集群对外提供服务.其每一个实例本地都存有冗余数据,每一个实例都可以直接对外提供读写服务.在这个集群中为了保证数据的一致性,需要有一个Leader来协调一些事务.那么问题来了:如何确定哪一个实例是Leader呢? 问题的难点在于: 没有一个仲裁者来选定Leader 每一个

分布式系统选举算法剖析

1.概述 我们在了解分布式选举算法之前,我们需要这样一种算法产生的背景.在一个分布式系统中,因为各种意外的因素,有的服务器可能会崩溃或变得不可靠,它就不能和其他服务器达成一致状态.因而这样就需要一种Consensus协议,来确保服务器的容错性,也就是说即使系统中有一两个服务器节点Crash,也不会影响其处理过程.为了让容错方式达成一致,我们不可能要求所有的服务器节点100%都达成Consensus状态,只要超过半数的大多数服务器节点Consensus即可,假设有N台服务器节点,(N/2)+1 就