开发者社区> 德哥> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

keepalived which time exec track script , notify script when vrrp transition

简介:
+关注继续查看
keepalived什么时候调用track script, track interface, notify_* script, notify; 搞清楚这些对设计HA很有必要.
以下这张图大概的画出了跟踪脚本, 跟踪接口, 状态转换, 以及notify脚本的先后关系 : 
当然实际的程序设计和这个没有关系, keepalived是3个进程组成的, 主进程, vrrp进程和health_check进程. 这里不作体现.


keepalived which time exec track script , notify script when vrrp transition - 德哥@Digoal - PostgreSQL research
 
keepalived.conf配置项 : 
跟踪脚本或跟踪接口配置 :
    track_interface {                   # Interfaces state we monitor
      <STRING>
      <STRING>
      <STRING> weight <INTEGER:-254..254>
      ...
    }
    track_script {                     # Scripts state we monitor
      <STRING>
      <STRING> weight <INTEGER:-254..254>
      ...
    }
    dont_track_primary                  # (default unset) ignore VRRP interface faults.
                                        #  useful for cross-connect VRRP config.

When a weight is specified in track_interface, instead of setting the vrrp
instance to the FAULT state in case of failure, its priority will be
increased by the weight when the interface is up (for positive weights),
or decreased by the weight's absolute value when the interface is down
(for negative weights). The weight must be comprised between -254 and +254
inclusive. 0 is the default behaviour which means that a failure implies a
FAULT state. The common practise is to use positive weights to count a
limited number of good services so that the server with the highest count
becomes master. Negative weights are better to count unexpected failures
among a high number of interfaces, as it will not saturate even with high
number of interfaces.

The same principle can be applied to track_script entries, except that an
unspecified weight means that the default weight declared in the script
will be used.


进入状态后的notify脚本配置 : 
vrrp_sync_group <STRING> {      # VRRP sync group declaration
    group {                     # group of instance to sync together
      <STRING>                  #   a
      <STRING>                  #       set
      ...                       #             of VRRP_Instance string
    }
    notify_master <STRING>|<QUOTED-STRING> # Script to run during MASTER transit
    notify_backup <STRING>|<QUOTED-STRING> # Script to run during BACKUP transit
    notify_fault <STRING>|<QUOTED-STRING>  # Script to run during FAULT transit
    notify <STRING>|<QUOTED-STRING>        # Script to run during ANY state transit (1)
    smtp_alert           # Send email notif during state transit
}

(1) The "notify" script is called AFTER the corresponding notify_* script has
    been called, and is given exactly 4 arguments (the whole string is interpreted
    as a litteral filename so don't add parameters!):

    $1 = A string indicating whether it's a "GROUP" or an "INSTANCE"
    $2 = The name of said group or instance
    $3 = The state it's transitioning to ("MASTER", "BACKUP" or "FAULT")
    $4 = The priority value

    $1 and $3 are ALWAYS sent in uppercase, and the possible strings sent are the
    same ones listed above ("GROUP"/"INSTANCE", "MASTER"/"BACKUP"/"FAULT").

Important: for a SYNC group to run reliably, it is vital that all instances in
           the group are MASTER or that they are all either BACKUP or FAULT. A
           situation with half instances having higher priority on machine A
           half others with higher priority on machine B will lead to constant
           re-elections. For this reason, when instances are grouped, their
           tracking weights are automatically set to zero, in order to avoid
           inconsistent priorities across instances.

notify也可以直接配置在instance下.
    notify_master <STRING>|<QUOTED-STRING>      # Same as vrrp_sync_group
    notify_backup <STRING>|<QUOTED-STRING>      # Same as vrrp_sync_group
    notify_fault <STRING>|<QUOTED-STRING>       # Same as vrrp_sync_group
    notify_stop <STRING>|<QUOTED-STRING>        # Script to launch when stopping vrrp
    notify <STRING>|<QUOTED-STRING>             # Same as vrrp_sync_group


notify是在进入状态后调用的, 也就是Entering后. 截取几段代码 : 
vrrp_scheduler.c

                        log_message(LOG_INFO, "VRRP_Instance(%s) Entering BACKUP STATE",
                               vrrp->iname);

                        /* Set BACKUP state */
                        vrrp_restore_interface(vrrp, 0);
                        vrrp->state = VRRP_STATE_BACK;
                        vrrp_smtp_notifier(vrrp);
                        notify_instance_exec(vrrp, VRRP_STATE_BACK);
............
                                log_message(LOG_INFO, "VRRP_Instance(%s) Entering BACKUP STATE",
                                       vrrp->iname);
                                vrrp->state = VRRP_STATE_BACK;
                                vrrp_smtp_notifier(vrrp);
                                notify_instance_exec(vrrp, VRRP_STATE_BACK);
................
        if (!VRRP_ISUP(vrrp)) {
                vrrp_log_int_down(vrrp);
                log_message(LOG_INFO, "VRRP_Instance(%s) Now in FAULT state",
                       vrrp->iname);
                if (vrrp->state != VRRP_STATE_FAULT)
                        notify_instance_exec(vrrp, VRRP_STATE_FAULT);
                vrrp->state = VRRP_STATE_FAULT;
                vrrp->ms_down_timer = 3 * vrrp->adver_int + VRRP_TIMER_SKEW(vrrp);
                notify_instance_exec(vrrp, VRRP_STATE_FAULT);


[参考]
1. keepalived/vrrp/vrrp_scheduler.c
2. keepalived/vrrp/vrrp_notify.c

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
error: %preun(keepalived-1.2.7-3.el6.x86_64) scriptlet failed, exit status 1 解决
重装 lvs 之前装了 ipvsadm 和 keepalived 用 rpm -e ipvsadm 意见通过 但 rpm -e keepalived 时,提示 [root@lvs1 ipvs]# rpm -e keepalived-1.2.7 error reading information on service keepalived: No such file or dire
1009 0
+关注
德哥
公益是一辈子的事, I am digoal, just do it.
文章
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载