keepalived的配置解析&安装与爬坑

一. 前情提要

以下试验以及说明是经过试验确定了的，准确！！另外，如果想知道每个参数的真正含义，建议看官网

解决的问题：

1，当一个节点(Linux设备)挂了，2个VIP都浮动到一个节点上

2，当这个节点(Linux设备)好了，由于业务有一定的延时，所以还不想浮动IP立马漂移回来

3，如果一个节点的业务(设备上运行的业务进程)完蛋了，需要自己主动交出VIP

4，等自己节点的业务(设备上运行的业务进程)又好了，那么不能立马夺权，而是有一个过渡再夺权

二. 官方配置说明

官方文档：https://www.keepalived.org/manpage.html

概述：

keepalived的具体实现原理这里就不做阐述，但是从其配置文件的角度大致将其工作模块分成两部分: 全局部分，和VRRP实例部分。

全局部分，顾名思义就是整体相关的配置；

VRRP实例部分：

首先，keepalived通过创建一个个VRRP实例来实现浮动IP的管理，一个VRRP实例可以看做是一个连接实例(使用VRRP协议)；

一个实例对应一个VIP，一台设备可以配置多个VRRP实例即参与多个VIP的抢占；

然后，具有相同VRRP实例配置的一对设备，会因为实例匹配而成功配对；

最后，通过协商得到谁是master谁是slave，以及谁来占有VIP。

全局配置部分

1. 预定义一个脚本以及脚本管理方式，之后用于VRRP实例引用

vrrp_script <SCRIPT_NAME> {

    #脚本的路径，或者直接就是脚本本身

    script <STRING>|<QUOTED-STRING>


    # 间隔多长时间执行一次脚本
    interval <INTEGER>


    #脚本执行如果没有正确返回，则这段时间后就算超时，然后算作是failed了
    timeout <INTEGER>   


    # adjust priority by this weight, (default: 0).For description of reverse, see track_script.
    # 'weight 0 reverse' will cause the vrrp instance to be down when the script is up, and vice versa.
    weight <INTEGER:-253..253> [reverse]


    # required number of successes for OK transition
    rise <INTEGER>


    # required number of successes for KO transition
    fall <INTEGER>


    # 以哪个用户身份去执行脚本的人是谁
    user USERNAME [GROUPNAME]


    # 假设初始时脚本是执行失败的
    init_fail
}

2. VRRP实例部分

# Ignore VRRP interface faults (default unset)
dont_track_primary    #表示的含义是，一旦接口有问题，则忽略之，否则keepalived的代码中对链路有做检查，发现链路down则进入fault状态，于是将放弃所有浮动ip


# optional, monitor these as well. go to FAULT state if any of these go down if unweighted.
# 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), unless reverse is specified, in which case the direction of adjustment of the priority is reversed.
# The weight must be comprised between -253 and +253 inclusive.0 is the default behaviour which means that a failure implies a
# FAULT state. The common practice 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. Use reverse to increase priority if an interfaces is down
track_interface {
    eth0
    eth1
   &nbs