keepalived weight正负值问题(实现主服务器nginx故障后迅速切换到备服务器)

有两台负载均衡,lb01,lb02.  lb02, priority值为100

编辑keepalived配置文件   vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {
   router_id lb01            #定义节点名称,在一个高可用集群中不能重复
}
vrrp_script check_web {
   script "/server/scripts/check_web.sh"
   interval 2
   weight 20                   #正数时
}
vrrp_instance oldboy {       #定义族群名字
    state MASTER             #定义主备信息注释  (MASTER BACKUP)
    interface eth0           #指定VIP地址,在哪个网卡生成
    virtual_router_id 51     #标识
    priority 90              #优先级越高越有可能成为主
    advert_int 1             #发送组播包间隔时间   224.0.0.18
    authentication {         #认证,为明文认证
        auth_type PASS
        auth_pass 12345
    }
    virtual_ipaddress {
        10.0.0.3
    }
    track_script {
       check_web
     }
}

编写脚本文件vim /server/scripts/check_web.sh

#!/bin/bash 
nginx_count=`ps -ef|grep -c [n]ginx`
if [ $nginx_count -ge 2 ]            #判断 nginx进程数大于等于2是为真
then                                  #为了让逻辑不那么绕,采用判断结果为真,exit 就为真的方式,更好的理解weight正负值
exit
0 else exit 1 fi

weight 为正数时

nginx服务启动  脚本结果为真  ,故  priority+weight 为最终优先级数

nginx服务故障  脚本结果为假  ,故  priority    为最终优先级数

weight 为负数时

nginx服务启动  脚本结果为真  ,故  priority   为最终优先级数

nginx服务故障  脚本结果为假  ,故  priority+weight    为最终优先级数

图片所有权为老男孩所有,侵权请联系删除.

转载于:https://www.cnblogs.com/snuglove/p/10433481.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
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”值之差。对于

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值