Keepalived中Master和Backup角色选举策略

Keepalived中Master和Backup角色选举策略

在Keepalived集群中，实际上没有严格的主节点和次节点。尽管在Keepalived环境变量中可以将“state”选项设置为“MASTER”,但这并不意味着该节点一直是主角色。Keepalived环境变量中的“priority”值 *** 纵节点的角色，但它不 *** 纵所有节点的角色。另一个可以改变节点角色的是vrrp_script控制模块中设置的“权重”值。这两个选项都匹配一个整数值，其中“权重”值可以是负整数，节点在集群中的角色是根据这两个值的大小决定的。

在具有一个主节点和多个备用节点的Keepalived集群中，具有较大“优先级”值的节点将成为集群中的主节点，而其他节点都是备份节点。主节点发生常见故障后，在备份节点间进行“间接选举”，根据节点优先级和权重的计算，选择新的主节点对接集群的服务方案。

在vrrp_script控制模块中，如果没有设置“weight”选项值，那么集群优先级的选择将由Keepalived环境变量中的“priority”值决定，当需要为集群 *** 作提供优先级时，可以通过在vrrp_script控制模块中设置“weight”值来完成。这里有一个案例可以展示。

假设有一个由节点A和B组成的Keepalived集群，在节点A的keepalived.conf文档中，“优先级”的值设置为100，而在节点B的keepalived.conf文档中，“优先级”的值设置为80。而且，节点A和B2都应用了“vrrp_script”控制模块来监管mysql服务项目，还设置了“权重”。

两个节点都启动Keepalived服务后，一切正常，即节点A会成为集群中的主节点，而节点B会自动成为备份节点。此时，节点A的mysql服务将被关闭。根据查询日志，没有nodeB与nodeA对接的日志，nodeB仍处于备份状态，nodeA仍处于主用状态。在这种情况下，所有HA集群都将失去实际意义。

这里分析一下造成这种情况的原因，这就是Keepalived集群中主备角色选举对策的难题。下面总结了在Keepalived中应用vrrp_script控制模块时，所有集群角色的通用选举优化算法。因为“权重”的值可以是正的，也可以是负的，所以要分两种情况显示。

1.当“权重”值为正时

在vrrp_script中，如果特定脚本检查成功，主节点的权重将是“权重”和“优先级”之和。如果脚本检查不成功，主节点的权重将保持为“优先级”，因此转换对策如下:

如果主节点“vrrp_script”脚本检查失败，如果主节点“优先级”值低于备份节点“权重”值和“优先级”值之和，将发生主备转换。

如果主节点的“vrrp_script”脚本验证成功，如果主节点的“weight”和“priority”值之和超过备份节点的“weight”和“priority”值之和，则主节点仍将是主导节点，不会发生转换。

2.当“权重”值为负时

在“vrrp_script”中，如果特定脚本检查成功，主节点的权重仍然是“优先级”值；当脚本检查不成功时，主节点的权重将是“优先级”值和“权重”值之间的差值，因此转换对策如下:

如果主节点“vrrp_script”脚本检查失败，如果主节点“优先级”值和“权重”值之差低于备份节点“优先级”值，将发生主备转换。

当主“vrrp_script”脚本验证成功时，如果主节点“优先级”值超过备份节点“优先级”值，则主节点仍然是主导节点，并且不生成转换。

了解了Keepalived主备角色的大选对策后，我们来分析一下之前的案例。因为节点A和B2的“权重”值都是10，所以符合第一种大选对策。节点A终止Mysql服务后，节点A的脚本测试会不成功，节点A的权重会维持为节点A上设置的“优先级”值，即100。并且节点B的权重会变成“权重”值和“优先级”值之和，即90(10^80)，这样节点A的权重仍然超过节点B的权重，所以不容易产生主备转换。

设置“权重”值有一个简单的规范，即“权重”值的平方根应该超过主节点和备份节点的“优先级”值之差。以上面的节点A和B2为例，如果“权重”的值超过20，就可以保证集群的正常运行和转换。不难看出，“权重”值的设置应该是非常小心的。如果设置不好，会导致集群角色选举失败，集群陷入偏瘫。