阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

Keepalived中Master和Backup角色选举策略

168次阅读
没有评论

共计 2345 个字符,预计需要花费 6 分钟才能阅读完成。

在 Keepalived 集群中,其实并没有严格意义上的主、备节点,虽然可以在 Keepalived 配置文件中设置“state”选项为“MASTER”状态,但是这并不意味着此节点一直就是 Master 角色。控制节点角色的是 Keepalived 配置文件中的“priority”值,但并它并不控制所有节点的角色,另一个能改变节点角色的是在 vrrp_script 模块中设置的“weight”值,这两个选项对应的都是一个整数值,其中“weight”值可以是个负整数,一个节点在集群中的角色就是通过这两个值的大小决定的。

在一个一主多备的 Keepalived 集群中,“priority”值最大的将成为集群中的 Master 节点,而其他都是 Backup 节点。在 Master 节点发生故障后,Backup 节点之间将进行“民主选举”,通过对节点优先级值“priority”和““weight”的计算,选出新的 Master 节点接管集群服务。

在 vrrp_script 模块中,如果不设置“weight”选项值,那么集群优先级的选择将由 Keepalived 配置文件中的“priority”值决定,而在需要对集群中优先级进行灵活控制时,可以通过在 vrrp_script 模块中设置“weight”值来实现。下面列举一个实例来具体说明。

假定有 A 和 B 两节点组成的 Keepalived 集群,在 A 节点 keepalived.conf 文件中,设置“priority”值为 100,而在 B 节点 keepalived.conf 文件中,设置“priority”值为 80,并且 A、B 两个节点都使用了“vrrp_script”模块来监控 MySQL 服务,同时都设置“weight”值为 10,那么将会发生如下情况。

在两节点都启动 Keepalived 服务后,正常情况是 A 节点将成为集群中的 Master 节点,而 B 自动成为 Backup 节点,此时将 A 节点的 mysql 服务关闭,通过查看日志发现,并没有出现 B 节点接管 A 节点的日志,B 节点仍然处于 Backup 状态,而 A 节点依旧是 Master 状态,在这种情况下整个 HA 集群将失去意义。

下面就分析一下产生这种情况的原因,这也就是 Keepalived 集群中主、备角色选举策略的问题。下面总结了在 Keepalived 中使用 vrrp_script 模块时整个集群角色的选举算法,由于“weight”值可以是正数也可以是负数,因此,要分两种情况进行说明。

1.“weight”值为正数时

在 vrrp_script 中指定的脚本如果检测成功,那么 Master 节点的权值将是“weight 值与”priority“值之和,如果脚本检测失败,那么 Master 节点的权值保持为“priority”值,因此切换策略为:

Master 节点“vrrp_script”脚本检测失败时,如果 Master 节点“priority”值小于 Backup 节点“weight 值与”priority“值之和,将发生主、备切换。

Master 节点“vrrp_script”脚本检测成功时,如果 Master 节点“weight”值与“priority”值之和大于 Backup 节点“weight”值与“priority”值之和,主节点依然为主节点,不发生切换。

2.“weight”值为负数时

在“vrrp_script”中指定的脚本如果检测成功,那么 Master 节点的权值仍为“priority”值,当脚本检测失败时,Master 节点的权值将是“priority“值与“weight”值之差,因此切换策略为:

Master 节点“vrrp_script”脚本检测失败时,如果 Master 节点“priority”值与“weight”值之差小于 Backup 节点“priority”值,将发生主、备切换。

Master 节点“vrrp_script”脚本检测成功时,如果 Master 节点“priority”值大于 Backup 节点“priority”值时,主节点依然为主节点,不发生切换。

在熟悉了 Keepalived 主、备角色的选举策略后,再来分析一下刚才实例,由于 A、B 两个节点设置的“weight”值都为 10,因此符合选举策略的第一种,在 A 节点停止 Mysql 服务后,A 节点的脚本检测将失败,此时 A 节点的权值将保持为 A 节点上设置的“priority”值,即为 100,而 B 节点的权值将变为“weight”值与“priority”值之和,也就是 90(10+80),这样就出现了 A 节点权值仍然大于 B 节点权值的情况,因此不会发生主、备切换。

对于“weight”值的设置,有一个简单的标准,即“weight”值的绝对值要大于 Master 和 Backup 节点“priority”值之差。对于上面 A、B 两个节点的例子,只要设置“weight”值大于 20 即可保证集群正常运行和切换。由此可见,对于“weight 值的设置,要非常谨慎,如果设置不好,将导致集群角色选举失败,使集群陷于瘫痪状态。

CentOS 6.3 下 Haproxy+Keepalived+Apache 配置笔记 http://www.linuxidc.com/Linux/2013-06/85598.htm

Haproxy + KeepAlived 实现 WEB 群集 on CentOS 6 http://www.linuxidc.com/Linux/2012-03/55672.htm

Keepalived+Haproxy 配置高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm

Haproxy+Keepalived 构建高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/55880.htm

正文完
星哥说事-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-20发表,共计2345字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中