安装

 yum install keepalived -y 
# 启动
systemctl start keepalived.service
# 停止
systemctl stop keepalived.service
# 重启
systemctl restart keepalived.service

文件路径

/etc/keepalived
/etc/keepalived/keepalived.conf     #keepalived服务主配置文件
/etc/rc.d/init.d/keepalived         #服务启动脚本
/etc/sysconfig/keepalived
/usr/bin/genhash
/usr/libexec/keepalived
/usr/sbin/keepalived

配置keepalived 主机

通过命令vim keepalived.conf打开配置文件

global_defs { 
    # 路由id：当前安装keepalived的节点主机标识符，保证全局唯一 
    router_id keep_171 
} 

vrrp_instance VI_1 { #当前节点所属的虚拟路由的名称
    # 表示状态是MASTER主机还是备用机BACKUP 
    state MASTER 
    # 该实例绑定的网卡 
    interface eth0
    # 保证主备节点一致即可 
    virtual_router_id 51 
    # 权重，master权重一般高于backup，如果有多个，那就是选举，谁的权重高，谁就当选 
    priority 100 
    # 主备之间同步检查时间间隔，单位秒 
    advert_int 2 
    # 认证权限密码，防止非法节点进入 
    authentication { 
        auth_type PASS 
        auth_pass 1111 
    } 
    # 虚拟出来的ip，可以有多个（vip） 
    virtual_ipaddress { 
        192.168.1.161 
    }
}

注意：interface需要查看网卡信息命令，如下就是eth0

ip addr

执行结果：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:4e:db:c4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.4.8/22 brd 10.0.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4e:dbc4/64 scope link 
       valid_lft forever preferred_lft forever

查看进程

启动keepalived

systemctl start keepalived

[root@ydh keepalived]# ps aux|grep keepalived
root       5164  0.0  0.0 123012  1404 ?        Ss   21:18   0:00 /usr/sbin/keepalived -D
root       5165  0.0  0.1 133984  3404 ?        S    21:18   0:00 /usr/sbin/keepalived -D
root       5166  0.0  0.1 138152  2964 ?        S    21:18   0:00 /usr/sbin/keepalived -D
root       5183  0.0  0.0 112824   992 pts/0    S+   21:18   0:00 grep --color=auto keepalived

访问虚拟IP 即可方法该主机 IP

在Keepalived启动后，通常会有三个关键的进程在运行，它们的作用如下：

Keepalived进程（keepalived）：这是Keepalived的主要进程，负责管理整个Keepalived的运行。它读取配置文件，启动和停止其他子进程，并处理来自其他进程的通信和控制信息。

VRRP子进程（vrrp）：VRRP子进程是Keepalived的关键组件之一。它负责实现VRRP协议，与其他设备进行通信，并执行VRRP的状态转换和路由器间的选举过程。该进程监控主机的状态，包括主机的可用性和健康状况，并根据配置的规则决定主备路由器的切换。

路由检测子进程（checkers）：路由检测子进程是Keepalived的另一个重要组件。它负责进行网络健康检查，以确定各个后端服务器的可用性。检测器可以使用各种协议，如ICMP、TCP、HTTP等，来监测后端服务器的状态。如果检测到服务器故障或不可用，它将通知VRRP子进程进行状态转换。

这三个进程之间相互协作，形成了Keepalived的完整功能。Keepalived进程负责协调和管理这些子进程的工作，确保VRRP协议的正确运行和故障切换的顺利进行。VRRP子进程负责实现VRRP协议，维护虚拟IP地址的所有权和主备状态的切换。路由检测子进程负责监测后端服务器的可用性，提供健康检查和故障检测的功能。

配置是否成功

[root@ydh keepalived]# ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:10:22:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.24/24 brd 192.168.2.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 192.168.2.188/32 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe10:223d/64 scope link 
       valid_lft forever preferred_lft forever

inet 192.168.2.188/32 scope global ens33出现这个就显示成功了

vip漂移

VIP（Virtual IP）漂移是指在高可用性环境中，将虚拟IP地址（VIP）从一个节点（主节点）快速切换到另一个节点（备份节点）的过程。这种切换通常发生在主节点发生故障或无法提供服务时，为了确保服务的连续性和可用性。

VIP漂移的详细过程如下：

• 主节点失效检测：系统会监测主节点的状态，例如网络连通性、服务器运行状态等。一旦检测到主节点发生故障或无法提供服务，触发VIP漂移的条件将被满足。

• 触发漂移事件：一旦触发条件满足，系统会通知备份节点执行VIP漂移。这可以通过一种心跳检测机制、集群管理软件或网络设备的协作实现。

• VIP切换：备份节点接收到漂移事件后，会接管虚拟IP地址。它会在自己的网络接口上添加VIP，并通过更新路由表或通知相关网络设备来确保数据包正确地传输到备份节点。

• 通告其他节点：一旦备份节点成功接管VIP，它会向其他节点发送通告，以便更新它们的路由表或配置，确保数据包正确地路由到新的VIP所在的节点。

• 服务恢复：一旦VIP成功漂移到备份节点，备份节点将开始处理来自客户端的请求，并提供服务。这样，故障期间的服务中断将被最小化，用户将继续获得可用的服务。

VIP漂移通常是在高可用性环境中使用的一种机制，例如负载均衡集群、高可用数据库集群等。它可以确保服务在主节点故障时能够快速地恢复到备份节点，从而保证了系统的连续性和可用性。

问题：

master挂了吗，vip漂移到backup服务器上，如果master好了,vip会漂移回master上吗？

在 Keepalived 中，默认情况下，一旦 VIP 漂移到备份服务器上，即使主服务器恢复正常，VIP 不会自动漂移回主服务器。这是为了避免频繁的 VIP 切换和可能的服务中断。

如果你希望在主服务器恢复后，VIP 能够自动漂移回主服务器上，你可以使用 track_script 配置项。track_script 允许你指定一个脚本，用于监测主服务器的可用性。当主服务器恢复时，脚本返回成功状态，Keepalived 将会触发 VIP 漂移回主服务器。

以下是一个示例的 Keepalived 配置，演示了如何使用 track_script 配置项来实现 VIP 漂移回主服务器

vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 58
priority 100
advert_int 1
authentication {
  auth_type PASS
  auth_pass 1111
}
virtual_ipaddress {
  192.168.2.188
}
track_script {
  script "/path/to/monitor_script.sh"
  fall 2
  rise 2
  weight -1
}
}

在上面的配置中，/path/to/monitor_script.sh 是一个自定义的脚本，用于监测主服务器的可用性。你需要编写一个脚本来检测主服务器是否已经恢复正常。脚本返回成功状态时，Keepalived 将会触发 VIP 漂移回主服务器。

在脚本中，你可以使用各种方法和命令来检测主服务器的可用性，例如 ping 命令、HTTP 请求等。根据你的具体需求和环境，自定义脚本来实现主服务器的可用性监测。

需要注意的是，使用 track_script 配置项需要在 Keepalived 配置中启用 vrrp_strict 选项。可以将 vrrp_strict 设置为 “on” 来启用严格模式。

配置完成后，当主服务器恢复正常并 track_script 返回成功状态时，Keepalived 将自动触发 VIP 漂移回主服务器。这样，主服务器将重新成为服务的主要提供者。

简单的实现单VIP架构：

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
  # vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.16
        192.168.1.251
        192.168.1.12
    }
}

虚拟出3个 VIP 192.168.1.16，192.168.1.251，192.168.1.12 放访问 VIP 时会访问到当前主机

实现双机主备高可用

修改备机配置

global_defs { 
    router_id keep_172 
} 
vrrp_instance VI_1 { 
    # 备用机设置为BACKUP 
    state BACKUP 
    interface eth0
    virtual_router_id 51 
    # 权重低于MASTER 
    priority 80 
    advert_int 2 
    authentication { 
        auth_type PASS 
        auth_pass 1111 
    }
    virtual_ipaddress {
        # 注意：主备两台的vip都是一样的，绑定到同一个vip 
        192.168.1.161 
    } 
}

启动 Keepalived
访问vip即可访问主机，当主机失效时访问vip就会访问到备机

keepalived配置nginx自动重启

Nginx默认监听在所有的IP地址上，VIP会飘到一台节点上，相当于那台nginx多了VIP这么一个网卡，所以可以访问到nginx所在机器 但是…如果nginx宕机，会导致用户请求失败，但是keepalived没有挂掉不会进行切换，所以需要编写一个脚本检测Nginx的存活状态，如果不存活则kill掉keepalived

(1)编写脚本
在/etc/keepalived/下创建脚本check_nginx_alive_or_not

#!/bin/bash 
nginxpid=$(ps -ef | grep [n]ginx | wc -l)

#1.判断Nginx是否存活,如果不存活则尝试启动Nginx
if [ $nginxpid -eq 0 ];then
    systemctl start nginx &>/dev/null
    sleep 3
    #2.等待3秒后再次获取一次Nginx状态
    nginxpid=$(ps -ef | grep [n]ginx | wc -l) 
    #3.再次进行判断, 如Nginx还不存活则停止Keepalived,让地址进行漂移,并退出脚本  
    if [ $nginxpid -eq 0 ];then
        systemctl stop keepalived
        #killall keepalived 
    fi
fi

添加运行权限

chmod +x /etc/keepalived/check_nginx_alive_or_not.sh

配置keepalived监听nginx脚本

vrrp_script check_nginx_alive { 
    script "/etc/keepalived/check_nginx_alive_or_not.sh" 
    interval 2 # 每隔两秒运行上一行脚本 
    weight 10 # 如果脚本运行失败，则升级权重+10 
}

在vrrp_instance中新增监控的脚本

vrrp_instance VI_1 { 
    ...其他配置
    ...其他配置
    track_script { 
        check_nginx_alive # 追踪 nginx 脚本
    }
}

重启Keepalived使得配置文件生效

systemctl restart keepalived

修改nginx.conf配置
把配置的是当前机器IP的server_name，更改一下成虚拟地址ip：

sever{  
    listen    80;  
    # 这里从机器的本地IP改为虚拟IP  
    server_name 虚拟IP;    
}

keepalived双主热备

配置DNS轮询
在同一个域名下配置两个ip，自行百度

配置第一台主机

global_defs {
    router_id keep_171 
} 
vrrp_instance VI_1 { 
    state MASTER 
    interface ens33 
    virtual_router_id 51 
    priority 100 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass 1111 
    } 
    virtual_ipaddress { 
        192.168.1.161 
    } 
} 

vrrp_instance VI_2  {
    state BACKUP 
    interface ens33 
    virtual_router_id 52 
    priority 80 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass 1111 
    } 
    virtual_ipaddress { 
        192.168.1.162 
    }
}

配置第二台主机

global_defs {
    router_id keep_172 
} 
vrrp_instance VI_1 { 
    state BACKUP 
    interface ens33 
    virtual_router_id 51 
    priority 80 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass 1111 
    } 
    virtual_ipaddress { 
        192.168.1.161
    }
} 

vrrp_instance VI_2 {
    state MASTER 
    interface ens33 
    virtual_router_id 52 
    priority 100 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass 1111 
    } 
    virtual_ipaddress { 
        192.168.1.162 
    }
}

重启两台Keepalived

systemctl restart keepalived

keepalived虚拟IP无法访问

排查过程：

1. tcpdump抓包，发现能够报文都正常到达了
2. iptables -nL 发现keepalived增加了如下规则，导致报文被丢弃

解决方案：
删除配置中的 vrrp_strict，重启keepalived,访问成功

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
  # vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

keepalive高可用抢占式和非抢占式

（1）默认配置为抢占式：
master挂掉，backup上台，master重新启动则将IP抢占过去。
（2）非抢占式配置：
两台均为backup，在优先级上做区分，如master挂掉，backup上台，则backup变成master，master变为backup。
a.两个节点的state均为backup(官方建议)
b.两个节点都在vrrp_instance中添加nopreempt
c.其中一个节点的优先级要高于另外一个节点
两台服务器角色都启用了nopreempt后，必须修改角色状态统一为backup，唯一的区别就是优先级不同。

#Master
    vrrp_instance VI_1 {
        state BACKUP
        priority 150
        nopreempt
    }

#Backup
    vrrp_instance VI_1 {
        state BACKUP
        priority 100
        nopreempt
    } 

脑裂解决的办法

由于某些原因，导致两台keepalive高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器又都还活着。
a.服务器网线松动等网络故障
b.服务器硬件故障发生损坏现象而奔溃
c.主备服务器都开启了firewalld防火墙

#如果发生脑裂，则随机kill掉一台即可
#在备上编写检测脚本, 测试如果能ping通主并且备节点还有VIP的话则认为产生了脑裂,
` 因为是大家互PING，所以主节点以及备用节点，都需要编写并执行此脚本。
[root@lb02 ~]# vim check_keepalive.sh 
#!/bin/sh
vip=10.0.0.3
lb01_ip=172.16.1.4
while true;do
    ssh $lb01_ip 'ip addr | grep 10.0.0.3' &>/dev/null
    if [ $? -eq 0 -a `ip add|grep "$vip"|wc -l` -eq 1 ];then
        echo "ha is split brain.warning."
    else
        echo "ha is ok"
    fi
sleep 3
done

keepalived架构

• 单VIP架构：

  • 在单VIP架构中，只有一个虚拟IP地址（VIP）被配置，用于将客户端的请求导向到主节点。

  • 主备节点通过Keepalived进行状态同步和心跳检测。主节点持有VIP，而备节点监视主节点的状态。

  • 如果主节点发生故障或不可用，备节点将接管VIP，并开始提供服务，以确保服务的高可用性。

  • 当主节点恢复时，它会重新获得VIP，并继续提供服务。

• 双VIP架构：

  • 在双VIP架构中，有两个虚拟IP地址（VIP1和VIP2），分别用于主节点和备节点。
  • 主VIP（VIP1）用于将客户端的请求导向到主节点，而备VIP（VIP2）用于将客户端的请求导向到备节点。
  • 主备节点之间进行状态同步和心跳检测。主节点持有主VIP，备节点持有备VIP。
  • 如果主节点发生故障或不可用，备节点将接管主VIP，并开始提供服务。备节点的备VIP保持不变。
  • 当主节点恢复时，它会重新获得主VIP，并继续提供服务。备节点仍然持有备VIP，但不提供服务。

双VIP架构相对于单VIP架构提供了更高的冗余性和故障切换的灵活性。它允许同时在主备节点上提供服务，并且客户端可以选择性地连接到主节点或备节点，从而在故障发生时可以更快地切换到备节点。然而，双VIP架构也需要更多的IP地址和网络资源。

选择单VIP架构还是双VIP架构取决于具体的需求和应用场景。对于大多数常见的情况，单VIP架构已经足够实现高可用性和故障切换。双VIP架构通常用于更复杂的环境，需要更高级的灵活性和可扩展性。

双vip架构

192.168.2.24的配置文件代码

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 58
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.2.188
    }
}

vrrp_instance VI_2 {
    state BACKUP
    interface ens33
    virtual_router_id 59
    priority 100 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.2.199
    }
}

查看ip

[root@ydh ~]# ip add
    inet 192.168.2.24/24 brd 192.168.2.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 192.168.2.188/32 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe10:223d/64 scope link 
       valid_lft forever preferred_lft forever

192.168.2.23的配置文件设置

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 58
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.2.188
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface ens33
    virtual_router_id 59
    priority 120 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.2.199
    }
}

查看ip

[root@ydh ~]# ip add
    inet 192.168.2.23/24 brd 192.168.2.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 192.168.2.199/32 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe03:b281/64 scope link 
       valid_lft forever preferred_lft forever

Healthcheck 健康检测

健康检测段允许多种检查方式，常见的有 HTTP_GET、SSL_GET、TCP_CHECK、SMTP_CHECK、MISC_CHECK 。

如果负载均衡器上的nginx出现了问题，keepalived还有没有价值？

keepalived的价值是建立在nginx能正常工作的情况下，如果nginx异常，这台机器就不是负载均衡器了，需要停止它的master身份了，将优先级降低，让为给其他的机器，背后有健康检测功能。

Keepalived的Healthcheck（健康检查）是一种用于监测服务器或服务状态的功能。在Keepalived中，Healthcheck用于定期检查服务器的可用性，以确保主备节点的状态以及它们提供的服务的正常运行。

健康检查的目的是在故障或服务不可用时及时检测并采取相应的措施，比如切换到备用节点，以保持服务的高可用性。Healthcheck的工作方式是定期发送请求或监测服务器状态，然后根据响应结果来判断服务器是否处于健康状态。通常，主备节点会相互监测对方的健康状态，以便在发现故障时自动进行故障转移。

在Keepalived中，可以配置多种类型的Healthcheck，其中两个常见的类型是：

• TCP连接检查：这种类型的Healthcheck会定期尝试建立到服务器端口的TCP连接。如果连接成功建立，表示服务器健康。如果连接失败，表示服务器不可用，需要进行故障转移。
• HTTP健康检查：这种类型的Healthcheck会发送HTTP请求到服务器，并根据服务器的响应状态码来判断服务器是否健康。例如，如果服务器返回200 OK状态码，表示服务器正常运行；如果返回其他状态码，可能表示服务器出现故障或服务不可用。

Healthcheck的频率和超时时间可以根据需要进行配置。通常，健康检查的频率较高，以便及时发现服务器故障，并且超时时间要足够短，以避免等待过长时间才判定为故障。如果连续多次健康检查失败，则会触发故障转移操作，将服务从故障节点切换到备用节点。

Keepalived中的Healthcheck是用于监测服务器或服务状态的功能，以确保主备节点的状态和服务的正常运行，并在发现故障时自动触发故障转移操作，从而实现服务的高可用性。

实现

实例：监控本机的nginx进程是否运行，如果nginx进程不运行就立马将优先级降低30

• 编写监控nginx的脚本

  • 如何判断nginx是否运行，方法很多？

    pidof nginx
    killall -0 nginx
    #如果返回的是0代表是正常运行，否则nginx没有正常运行。
    

  • [root@ydh nginx]# cat check_nginx.sh 
    #!/bin/bash
    
    if /usr/sbin/pidof nginx &>/dev/null;then
    	exit 0
    else
    	exit 1
    fi
    

• 在keepalived里定义监控脚本

  #定义监控脚本chk_nginx
  vrrp_script chk_nginx {
      script "/nginx/check_nginx.sh"
      intervel 1
      weight -30
  }	
  

  • vrrp_script chk_nginx：这是定义监控脚本的起始行，chk_nginx是脚本的名称。
  • script “/nginx/check_nginx.sh”：这是脚本文件的路径和名称。根据路径，脚本文件位于/nginx/check_nginx.sh。脚本文件可能包含一些逻辑和命令，用于检测Nginx服务的健康状态。
  • interval 1：这是监控脚本的执行间隔，表示每隔1秒运行一次脚本。根据需求，您可以根据自己的要求进行调整。
  • weight -30：这是脚本的权重，用于决定主备节点之间进行故障转移时的优先级。较低的权重值表示脚本优先级较高，当监控脚本执行失败时，会影响节点的优先级，从而可能导致故障转移。

• 在keepalived里调用监控脚本

  • keepalived 会通过看脚本执行的返回看脚本是否成功执行

  • 返回0代表成功，否则失败

  • vrrp_instance VI_1 {
        state MASTER
        interface ens33
        virtual_router_id 58
        priority 120
        advert_int 1
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {
            192.168.2.188
        }
        #调用监控脚本
        track_script {
        	chk_nginx
        }
    }
    

注意：

• 监控nginx的脚本主要设置在master里面，实现master不灵的时候，实现vip漂移到backup上
• weight -30需要实现master和backup的优先级大小调换才有效果，否则不会是实现vip漂移

TCP_CHECK检测方式

TCP_CHECK { 
    connect_port 80 
    connect_timeout 3 
    nb_get_retry 3 
    delay_before_retry 3 
} 

参数	说明
connect_port	健康检查的端口，如果无指定，默认是 real_server 指定的端口。
connect_timeout	表示无响应超时时间，单位是秒，这里是3秒超时。
nb_get_retry	表示重试次数，这里是3次。
delay_before_retry	表示重试间隔，这里是间隔3秒。

HTTP_GET 和 SSL_GET 检测方式

HTTP_GET |SSL_GET {
    url { 
        path /index.html 
        digest e6c271eb5f017f280cf97ec2f51b02d3 
        status_code 200 
    }
    connect_port 80 
    bindto 192.168.12.80 
    connect_timeout 3 
    nb_get_retry 3 
    delay_before_retry 2 
}

参数	说明
url	用来指定 HTTP/SSL 检查的URL信息，可以指定多个 URL 。
path	后跟详细的 URL 路径
digest	SSL 检查后的摘要信息，这些摘要信息可以通过 genhash 命令工具获取。例如：genhash -s 192.168.12.80 -p 80 -u /index.html
status_code	指定HTTP检查返回正常状态码的类型，一般是200。
bindto	表示通过此地址来发送请求对服务器进行健康检查。

MISC_CHECK检测方式

MISC_CHECK 
{
    misc_path /usr/local/bin/script.sh 
    misc_timeout 5 
    ! misc_dynamic 
}

MISC 健康检查方式可以通过执行一个外部程序来判断 real server 节点的服务状态，使用非常灵活。以下是常用的几个选项的含义。

参数	说明
misc_path	用来指定一个外部程序或者一个脚本路径。
misc_timeout	设定执行脚本的超时时间。
misc_dynamic	表示是否启用动态调整 real server 节点权重，!misc_dynamic 表示不启用，相反则表示启用。在启用这功能后，Keepalived 的healthchecker 进程将通过退出状态码来动态调整 real server 节点的 weight 值，如果返回状态码为 0 ，表示健康检查正常，real server 节点权重保持不变；如果返回状态码为 1 ，表示健康检查失败，那么就将 real server 节点权重设置为 0 ；如果返回状态码为2~255 之间任意数值，表示健康检查正常，但 real server 节点的权重将被设置为返回状态码减 2 ，例如返回状态码为10 ，real server 节点权重将被设置为 8（10-2）。

notify

当本节点服务器成为某个角色的时候，我们去执行某个脚本

notify_master:当当前节点成为master时，通知脚本执行任务(一般用于启动某服务)

notify_backup:当当前节点成为backup时，通知脚本执行任务(一般用于关闭某服务

notify_fault：当当前节点出现故障，执行的任务;

如果检测到nginx进程关闭了，里面关闭keepalived的软件

定义脚本

[root@ydh nginx]# cat halt_keepalived.sh 
#!/bin/bash

service keepalived stop

配置文件中使用

notify_backup "nginx/halt_keepalived.sh"

关闭nginx后，按照之前的配置，master会变为backup。随后可以看keepalived进程是否关闭了，关闭了就代表配置成功了.

VRRP

简单案例参考

链接地址：
keepalived + HAProxy + mysql
keepalived + nginx
keepalived + zabbix

LVS配置

virtual_server 10.0.0.100 80 {    #定义虚拟主机IP地址及其端口
    delay_loop 6    #检查后端服务器的时间间隔
    lb_algo wrr    #定义调度方法，可选rr|wrr|lc|wlc|lblc|sh|dh
    lb_kind DR    #集群的类型,注意要大写，可选NAT|DR|TUN
    #persistence_timeout 20    #持久连接时长，LVS在多少时间内没有与后端服务进行数据传输，就会断开
    protocol TCP    #指定服务协议，可选TCP|UDP|SCTP
    sorry_server 10.0.0.101 80    #所有RS故障时，备用服务器地址（报错服务器）
 
    real_server 10.0.0.11 80 {    #RS的IP和PORT
        weight 1    #RS权重
        notify_up <STRING>|<QUOTED-STRING>    #RS上线通知脚本 
        notify_down <STRING>|<QUOTED-STRING>    #RS下线通知脚本
 
        HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK {         #定义当前主机的健康状态 检测方法
            ... 
        }
 
    }
 
}

应用层检测：HTTP_GET、SSL_GET（Nginx、Tomcat）

HTTP_GET|SSL_GET {
 
    url {
        path <URL_PATH>          #定义要监控的URL
        status_code <INT>        #判断上述检测机制为健康状态的响应码，一般为 200
    }
 
    connect_timeout <INTEGER>    #客户端请求的超时时长, 相当于haproxy的timeout server，多久连接不上就报错
    nb_get_retry <INT>           #重试次数
    delay_before_retry <INT>     #重试之前的延迟时长
    connect_ip <IP ADDRESS>      #向当前RS哪个IP地址发起健康状态检测请求
    connect_port <PORT>          #向当前RS的哪个PORT发起健康状态检测请求
    bindto <IP ADDRESS>          #向当前RS发出健康状态检测请求时使用的源地址
    bind_port <PORT>             #向当前RS发出健康状态检测请求时使用的源端口
 
}

配置举例

virtual_server 10.0.0.100 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind DR
    persistence_timeout 120
    protocol TCP
    sorry_server 10.0.0.101 80
 
    real_server 10.0.0.11 80 {
        weight 1
        
        HTTP_GET {
            
            url {
                path /
                status_code 200
            }
 
            connect_timeout 1
            nb_get_retry 3
            delay_before_retry 1
 
        }
 
    }
 
    real_server 10.0.0.12 80 {
        weight 1
        
        HTTP_GET {
 
            url {
                path /
                status_code 200
            }
 
            connect_timeout 1
            nb_get_retry 3
            delay_before_retry 1
 
        }
 
    }
 
}

传输层检测：TCP_CHECK（Redis、MySQL）

TCP_CHECK {
    connect_timeout <INTEGER>    #客户端请求的超时时长, 相当于haproxy的timeout server，多久连接不上就报错
    nb_get_retry <INT>           #重试次数
    delay_before_retry <INT>     #重试之前的延迟时长
    connect_ip <IP ADDRESS>      #向当前RS哪个IP地址发起健康状态检测请求，多网卡情况下
    connect_port <PORT>          #向当前RS的哪个PORT发起健康状态检测请求
    bindto <IP ADDRESS>          #向当前RS发出健康状态检测请求时使用的源地址，多网卡情况下
    bind_port <PORT>             #向当前RS发出健康状态检测请求时使用的源端口
}

配置举例

virtual_server 10.0.0.100 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind DR
    persistence_timeout 120
    protocol TCP
    sorry_server 10.0.0.101 80
 
    real_server 10.0.0.11 80 {
        weight 1
        
        TCP_CHECK { 
            connect_timeout 5
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
 
    }
 
    real_server 10.0.0.12 80 {
        weight 1
        
        TCP_CHECK {
            connect_timeout 5
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
 
    }
}