、工具介绍Keepalived 是一个运行在 Linux 上的高可用HA与负载均衡辅助服务最初主要是为 Linux Virtual ServerLVS设计的但现在也常被用来搭建服务的高可用以防止业务核心设备出现单点故障。虽然说它也间接具备负载均衡的能力但在配置和使用上个人觉得它比 HAProxy 更为复杂不好用。故本文的重点只关注其高可用的能力不对其负载均衡的能力做过多探讨。注为什么上面说 Keepalived 是间接具备负载均衡的能力呢是因为 Keepalived 与 LVS 是高度集成的组合LVS 才是实际具备负载均衡能力的服务而 Keepalived 仅是支持配置负载均衡的规则然后调用 LVS 实现。具体过程如下你编写配置在/etc/keepalived/keepalived.conf中写好virtual_server相关的所有规则IP、端口、算法、后端服务器列表等。Keepalived 启动Keepalived 服务启动后会读取自己的配置文件。自动调用 IPVSKeepalived 内部包含了操作 LVS 的代码。它会直接调用 Linux 内核的 IPVS 接口把你配置文件里的规则自动转换成ipvsadm命令才能创建的规则。验证结果你可以随时运行ipvsadm -L -n来查看。你会看到只要 Keepalived 在运行这里就已经有规则了而你完全没有动过ipvsadm命令。Keepalived 可以与 HAProxy/LVS/Nginx 组合以实现业务的高可用负载均衡的功能以下是关于 Keepalived HAProxy 组合的架构图2、协议介绍Keepalived 底层主要依赖 VRRP 协议Virtual Router Redundancy Protocol 虚拟路由冗余协议而协议的主要作用就是在多个节点之间选举出一个 MASTER 角色等协议选举出 MASTER 之后再由 Keepalived 到 MASTER 所处的服务器上去实现 VIP虚拟 IP 的功能就是在指定的物理网卡上再制作出一个虚拟的网络适配器。注VIP 即虚拟 IP就是一个未分配给真实主机的 IP也就是说对外提供服务的主机除了有一个真实 IP 外还有一个虚 IP使用这两个 IP 中的任意一个都可以连接到这台主机。注意这个 VIP 一般都是取的和服务器 IP 同网段的地址这样它虚拟出来之后客户端在原有基础不变动的情况下便可直接访问而若是使用其它网段的 IP客户端要想访问到这个虚拟 IP网络管理员还需要对路由器交换机这些网络设备进行路由调整待调整之后客户端才能够顺利访问。VRRP 协议选举 MASTER 的工作过程所有服务器在开启 VRRP 功能后都会根据优先级确定自己在服务器池中的角色。优先级高的服务器成为 Master优先级低的成为 Backup。【全部成员都在进行选举】成为 Master 的服务器会定期发送 VRRP 通告报文即心跳/广播包 通知服务器池内的其他服务器自己工作正常而成为 Backup 的服务器则会启动定时器等待通告报文的到来。同时 MASTER 也会通过 ARP 协议对外VIP 所在网段之内的所有机器通告该 VIP 的虚拟 IP 以及 MAC 地址以让客户端能够及时了解当前 VIP 对应的 MAC 地址其实就是让客户端知道 VIP 当前所在的具体服务器是哪个。如果 Backup 们的定时器在超时之后仍未收到 Master 发送来的 VRRP 通告报文此时 Backup 们便会认为 Master 已经无法正常工作于是 Backup 们就会认为自己才是 Master并纷纷对外发送 VRRP 通告报文。于是新一轮的选举便再次展开此时 Backup 们就又会根据优先级再次选举出 Master让其承担报文的转发功能。【除了故障机器之外的剩余成员都在进行选举】【在默认的抢占模式下】如果不久之后原来故障的 MASER 又恢复了正常此时它便会将自己的优先级数值与当前 MASTER 通告报文中的优先级数值进行比较如果自己大则直接抢夺 MASTER并恢复自己原来的转发功能。【仅恢复机器与当前 MASTER 成员在进行选举】【在非抢占模式下】如果不久之后原来故障的 MASER 又恢复了正常此时即便它的优先级大于当前 MASTER 的优先级它也不会去抢夺 MASTER而是等当前的 MASTER 故障之后它才会在下一轮的选举中进行 MASTER 的抢夺。注1VRRP 协议的实现有 VRRPv2 和 VRRPv3 两个版本。其中VRRPv2 基于 IPv4VRRPv3 基于 IPv6。 VRRPv2 和 VRRPv3 在功能实现上并没有区别仅仅只是应用的网络环境不同而已。2Keepalived 允许服务器池中只有个别机器开启了非抢占模式而其它机器仍旧是抢占模式这样的用法。但建议均保持一致。3、配置结构Keepalived 默认的配置文件是/etc/keepalived/keepalived.conf它整体的语法结构如下# 全局参数 global_defs { # 定义 router_id、邮箱通知等参数 } # VIP 绑定组 vrrp_sync_group VG1 { group { # 配置 VIP 漂移实例名称 } } # 健康检查脚本 vrrp_script chk_mt { # 定义检查脚本的位置、定时间隔、权重变化值等参数 } # VIP 漂移实例1 vrrp_instance VI_1 { # 定义状态、优先级、接口等参数 track_script { chk_mt } virtual_ipaddress { # 指定 VIP 的 IP 地址 } } # VIP 漂移实例2 vrrp_instance VI_2 { # 定义状态、优先级、接口等参数 virtual_ipaddress { # 指定 VIP 的 IP 地址 } } # LVS 负载均衡 virtual_server 192.168.200.12 443 { # 定义负载均衡的模式、算法、协议等参数 real_server 192.168.100.2 443 { # 指定后台实际提供服务的地址 } real_server 192.168.100.3 443 { # 指定后台实际提供服务的地址 } }注以上功能块都不是必须要出现的例如我们只使用 keepalived 的高可用功能那么只需要 vrrp_instance 块存在即可其它块可有可无。4、应用场景以下实验的环境状况如下实验环境总共两台服务器 A 和 B均未开启 SELinux、iptables 安全设置 A 网卡 ens33IP 地址 192.168.98.120B 网卡 ens33IP 地址 192.168.98.130定义的 VIP 地址 192.168.98.200、192.168.98.250。4.1、VIP 漂移实验目的聚合两台服务器形成一个虚拟 ip使得只要服务器池中还有一台机器存活那么这个虚拟 ip 便仍旧可以正常访问。# 服务器 A 的 keepalived 配置 #global_defs { # router_id test-name # 本机名称可随便自定义 # vrrp_strict # 对 VRRP 配置进行严格校验。建议关闭否则可能会出现一些奇怪的问题。 # enable_script_security # 开启脚本执行环境的安全模式此时脚本相关的文件权限、内容规范、所属人都会被严格检查检查通过脚本才会被执行。所以一般还是把它关闭掉否则疑点会很多。 # script_user root # 指定执行脚本的用户不指定的话默认是 keepalived_script 用户而该用户默认不存在还需要手动去创建。 #} vrrp_instance VI_1 { state MASTER # 设置起始状态为 MASTER 角色但片刻之后这个角色能否保持还是取决于 priority。 interface ens33 # 指定 VIP 绑定的网卡接口 virtual_router_id 50 # 类似群组的功能要求同一个服务器池的机器的此值都保持一致否则会出现脑裂现象即同时出现多个 MASTER 角色。 priority 150 # 指定优先级值越大优先级越高。取值范围0~255 advert_int 1 # 心跳发包间隔时间1秒 # nopreempt # 开启非抢占模式 virtual_ipaddress { 192.168.98.200 # 定义虚拟 IP } }# 服务器 B 的 keepalived 配置 vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 50 priority 100 advert_int 1 virtual_ipaddress { 192.168.98.200 } }注1如果 AB 服务器只有一方开启了非抢占模式那么仅为服务器 A 开启非抢占模式的选举仅对 A 有效B 若没有开启此功能的话B 是会进行抢占的。2router_id是“节点名字”可随便指定virtual_router_id是“VRRP 组编号”服务器池中的所有主机必须保持一致。4.2、VIP 绑定实验目的让多个虚拟 ip 捆绑在一台服务器上而不是让他们各自选举随机分布在不同的服务器上。# 服务器 A 的 keepalived 配置 global_defs { router_id LVS_MASTER } ############################ # 第一个 VRRP 实例 ############################ vrrp_instance VI_WEB { state MASTER interface ens33 virtual_router_id 51 # 关注点 priority 150 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.200/24 # 关注点 } } ############################ # 第二个 VRRP 实例 ############################ vrrp_instance VI_DB { state MASTER interface ens33 virtual_router_id 52 # 关注点 priority 50 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.250/24 # 关注点 } } ############################ # 同步组 ############################ vrrp_sync_group VG_1 { group { VI_WEB VI_DB } }# 服务器 B 的 keepalived 配置 global_defs { router_id LVS_MASTER } ############################ # 第一个 VRRP 实例 ############################ vrrp_instance VI_WEB { state BACKUP interface ens33 virtual_router_id 51 # 关注点 priority 100 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.200/24 # 关注点 } } ############################ # 第二个 VRRP 实例 ############################ vrrp_instance VI_DB { state BACKUP interface ens33 virtual_router_id 52 # 关注点 priority 100 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.250/24 # 关注点 } } ############################ # 同步组 ############################ vrrp_sync_group VG_1 { group { VI_WEB VI_DB } }注服务器 A 的 VI_WEB 的优先级大于 服务器 B 的 VI_WEBA 的 VI_DB 的优先级又小于 B 的 VI_DB在不绑定 VIP 组的情况下A 服务器上存在一个 VIPB 服务器存在一个 VIP当绑定 VIP 组之后这两个 VIP 要么都在 A 服务器上要么都在 B 服务器上此时优先级似乎没有什么作用了 VIP 在哪个服务器上完全取决于服务启动的先后顺序了。4.3、健康检查实验目的让服务器的优先级可以随着外部环境的一些可变因素而发生变化而不是一成不变或者只能在 keepalived 服务挂掉或服务器宕机的情况下优先级才会改变伴随着 MASTER 角色才能发生改变。# 服务器 A 的 keepalived 配置 vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 50 priority 150 advert_int 1 virtual_ipaddress { 192.168.98.200 } }# 服务器 B 的 keepalived 配置 #global_defs { # vrrp_strict # 对 VRRP 配置进行严格校验。建议关闭否则可能会出现一些奇怪的问题。 # enable_script_security # 开启脚本执行环境的安全模式此时脚本相关的文件权限、内容规范、所属人都会被严格检查检查通过脚本才会被执行。所以一般还是把它关闭掉否则疑点会很多。 # script_user root # 指定执行脚本的用户不指定的话默认是 keepalived_script 用户而该用户默认不存在还需要手动去创建。 #} vrrp_script chk_mt { script /etc/keepalived/chk_mt.sh # 当脚本返回 0 时priority160 priority100 weight60此时 B 的优先级会大于 AB 会切换为 MASTER。 interval 10 # 脚本每 10 秒执行一次 weight 60 } vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 50 priority 100 advert_int 1 virtual_ipaddress { 192.168.98.200 } track_script { chk_mt } }测试脚本如下#!/bin/bash #touch /tmp/test.txt echo test /tmp/test2.txt touch /tmp/test.txt #exit 1注关于健康脚本的实验在测试的时候坑有点多现将注意事项整理如下。1安全选项 enable_script_security 开启的状态下被执行脚本的权限最好是 750脚本所有者和 script_user 指定的要保持一致。2keepalived 的脚本执行环境不是简单的 bash脚本内容不能有类似echo 123 /tmp/test.txt这种写法出现特殊符号会导致脚本解析错误的问题。若是要进行判断可在脚本中写入/usr/bin/touch /tmp/test.txt然后在 shell 中不断执行stat /tmp/test.txt去查看文件的修改时间是否发生变化若有变化则说明脚本是被执行了。3脚本在被执行时systemctl ststus keepalived.service日志中并不会显示脚本每次被定时执行的事件只会显示初次被执行时的状态。但即便显示初始化失败也并不意味着该脚本就没有被执行它的判断标准似乎只是根据脚本的最后一条命令的返回值进行的判断若最后一条命令执行失败或错误日志显示的初始化状态便也是 failed 状态但这个状态下脚本依旧被定时执行着。4脚本在每次被执行之后它的优先级的计算并非每次都是priority priority weight 而是只有在“状态发生变化”时才会调整优先级。例如假设 weight 等于 20脚本被定时执行 5 次之后 优先级的状态如下时间返回值状态priorityT10OK90T21FAIL70T31FAIL仍失败70不变T41FAIL持续失败70不变T50OK90可见weight 值不是让 priority 一直递减它只是在 90 和 70 这两个值之间来回跳。4.4、切换通知实验目的让服务器的角色在发生变化时可以通过邮箱或一些其它的手段来通知管理员或是让其可以执行一些其它什么脚本任务啥的。#通知脚本 #!/bin/bash # 这里是我们的vip 地址 vip172.16.100.104 contactrootlocalhost notify() { mailsubjecthostname to be $1: $vip floating mailbodydate %F %H:%M:%S: vrrp transition, hostname changed to be $1 echo $mailbody | mail -s $mailsubject $contact # 发送 } case $1 in master) notify master exit 0 ;; backup) notify backup exit 0 ;; fault) notify fault exit 0 ;; *) echo Usage: basename $0 {master|backup|fault} exit 1 ;; esac# ... 其他配置 vrrp_instance VI_1 { # ... 其他配置 notify_master /etc/keepalived/notify.sh master # 当当前服务器的角色切换为 MASTER 时向 root 用户发送 mail通知 notify_backup /etc/keepalived/notify.sh backup # 当当前服务器的角色切换为 BACKUP 时向 root 用户发送 mail通知 notify_fault /etc/keepalived/notify.sh fault # 当当前服务器的角色切换为 FAULT 时向 root 用户发送 mail通知 }4.5、负载均衡实验目的让访问 VIP 的请求任务可以被均匀的分发给不同的后端服务器进行处理。vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 50 priority 150 advert_int 1 virtual_ipaddress { 192.168.98.200 } } virtual_server 192.168.98.200 8080 { delay_loop 20 lb_algo rr # 负载均衡调度算法 lb_kind NAT # 负载实现的 NAT 模式 persistence_timeout 360 protocol TCP # 实际处理任务的后端服务器 real_server 192.168.98.120 8080 { weight 1 TCP_CHECK { # TCP 健康检查 connect_timeout 3 } } real_server 192.168.98.130 8080 { weight 1 TCP_CHECK { connect_timeout 3 } } }注以上仅为配置上的示例实际上还需要在机器上进行一些系统级的功能开启具体参考 这篇文章。仅凭以上配置在浏览器访问 web 服务 http://192.168.98.200:8080 并不能够成功。5、杂七杂八1参考文档中文手册、木西笔记、CSDN2服务器之间的心跳包的防火墙放行规则如下# 放行广播包 iptables -A INPUT -i eth1 -d 224.0.0.0/8 -j ACCEPT # 放行协议号 112。心跳包是一个基于 ip 协议之上的 vrrp 协议包协议号是 112。【这条似乎可以省略有前面一条就够了】 iptables -A INPUT -i eth1 -p 112 -j ACCEPT
Keepalived 学习总结
、工具介绍Keepalived 是一个运行在 Linux 上的高可用HA与负载均衡辅助服务最初主要是为 Linux Virtual ServerLVS设计的但现在也常被用来搭建服务的高可用以防止业务核心设备出现单点故障。虽然说它也间接具备负载均衡的能力但在配置和使用上个人觉得它比 HAProxy 更为复杂不好用。故本文的重点只关注其高可用的能力不对其负载均衡的能力做过多探讨。注为什么上面说 Keepalived 是间接具备负载均衡的能力呢是因为 Keepalived 与 LVS 是高度集成的组合LVS 才是实际具备负载均衡能力的服务而 Keepalived 仅是支持配置负载均衡的规则然后调用 LVS 实现。具体过程如下你编写配置在/etc/keepalived/keepalived.conf中写好virtual_server相关的所有规则IP、端口、算法、后端服务器列表等。Keepalived 启动Keepalived 服务启动后会读取自己的配置文件。自动调用 IPVSKeepalived 内部包含了操作 LVS 的代码。它会直接调用 Linux 内核的 IPVS 接口把你配置文件里的规则自动转换成ipvsadm命令才能创建的规则。验证结果你可以随时运行ipvsadm -L -n来查看。你会看到只要 Keepalived 在运行这里就已经有规则了而你完全没有动过ipvsadm命令。Keepalived 可以与 HAProxy/LVS/Nginx 组合以实现业务的高可用负载均衡的功能以下是关于 Keepalived HAProxy 组合的架构图2、协议介绍Keepalived 底层主要依赖 VRRP 协议Virtual Router Redundancy Protocol 虚拟路由冗余协议而协议的主要作用就是在多个节点之间选举出一个 MASTER 角色等协议选举出 MASTER 之后再由 Keepalived 到 MASTER 所处的服务器上去实现 VIP虚拟 IP 的功能就是在指定的物理网卡上再制作出一个虚拟的网络适配器。注VIP 即虚拟 IP就是一个未分配给真实主机的 IP也就是说对外提供服务的主机除了有一个真实 IP 外还有一个虚 IP使用这两个 IP 中的任意一个都可以连接到这台主机。注意这个 VIP 一般都是取的和服务器 IP 同网段的地址这样它虚拟出来之后客户端在原有基础不变动的情况下便可直接访问而若是使用其它网段的 IP客户端要想访问到这个虚拟 IP网络管理员还需要对路由器交换机这些网络设备进行路由调整待调整之后客户端才能够顺利访问。VRRP 协议选举 MASTER 的工作过程所有服务器在开启 VRRP 功能后都会根据优先级确定自己在服务器池中的角色。优先级高的服务器成为 Master优先级低的成为 Backup。【全部成员都在进行选举】成为 Master 的服务器会定期发送 VRRP 通告报文即心跳/广播包 通知服务器池内的其他服务器自己工作正常而成为 Backup 的服务器则会启动定时器等待通告报文的到来。同时 MASTER 也会通过 ARP 协议对外VIP 所在网段之内的所有机器通告该 VIP 的虚拟 IP 以及 MAC 地址以让客户端能够及时了解当前 VIP 对应的 MAC 地址其实就是让客户端知道 VIP 当前所在的具体服务器是哪个。如果 Backup 们的定时器在超时之后仍未收到 Master 发送来的 VRRP 通告报文此时 Backup 们便会认为 Master 已经无法正常工作于是 Backup 们就会认为自己才是 Master并纷纷对外发送 VRRP 通告报文。于是新一轮的选举便再次展开此时 Backup 们就又会根据优先级再次选举出 Master让其承担报文的转发功能。【除了故障机器之外的剩余成员都在进行选举】【在默认的抢占模式下】如果不久之后原来故障的 MASER 又恢复了正常此时它便会将自己的优先级数值与当前 MASTER 通告报文中的优先级数值进行比较如果自己大则直接抢夺 MASTER并恢复自己原来的转发功能。【仅恢复机器与当前 MASTER 成员在进行选举】【在非抢占模式下】如果不久之后原来故障的 MASER 又恢复了正常此时即便它的优先级大于当前 MASTER 的优先级它也不会去抢夺 MASTER而是等当前的 MASTER 故障之后它才会在下一轮的选举中进行 MASTER 的抢夺。注1VRRP 协议的实现有 VRRPv2 和 VRRPv3 两个版本。其中VRRPv2 基于 IPv4VRRPv3 基于 IPv6。 VRRPv2 和 VRRPv3 在功能实现上并没有区别仅仅只是应用的网络环境不同而已。2Keepalived 允许服务器池中只有个别机器开启了非抢占模式而其它机器仍旧是抢占模式这样的用法。但建议均保持一致。3、配置结构Keepalived 默认的配置文件是/etc/keepalived/keepalived.conf它整体的语法结构如下# 全局参数 global_defs { # 定义 router_id、邮箱通知等参数 } # VIP 绑定组 vrrp_sync_group VG1 { group { # 配置 VIP 漂移实例名称 } } # 健康检查脚本 vrrp_script chk_mt { # 定义检查脚本的位置、定时间隔、权重变化值等参数 } # VIP 漂移实例1 vrrp_instance VI_1 { # 定义状态、优先级、接口等参数 track_script { chk_mt } virtual_ipaddress { # 指定 VIP 的 IP 地址 } } # VIP 漂移实例2 vrrp_instance VI_2 { # 定义状态、优先级、接口等参数 virtual_ipaddress { # 指定 VIP 的 IP 地址 } } # LVS 负载均衡 virtual_server 192.168.200.12 443 { # 定义负载均衡的模式、算法、协议等参数 real_server 192.168.100.2 443 { # 指定后台实际提供服务的地址 } real_server 192.168.100.3 443 { # 指定后台实际提供服务的地址 } }注以上功能块都不是必须要出现的例如我们只使用 keepalived 的高可用功能那么只需要 vrrp_instance 块存在即可其它块可有可无。4、应用场景以下实验的环境状况如下实验环境总共两台服务器 A 和 B均未开启 SELinux、iptables 安全设置 A 网卡 ens33IP 地址 192.168.98.120B 网卡 ens33IP 地址 192.168.98.130定义的 VIP 地址 192.168.98.200、192.168.98.250。4.1、VIP 漂移实验目的聚合两台服务器形成一个虚拟 ip使得只要服务器池中还有一台机器存活那么这个虚拟 ip 便仍旧可以正常访问。# 服务器 A 的 keepalived 配置 #global_defs { # router_id test-name # 本机名称可随便自定义 # vrrp_strict # 对 VRRP 配置进行严格校验。建议关闭否则可能会出现一些奇怪的问题。 # enable_script_security # 开启脚本执行环境的安全模式此时脚本相关的文件权限、内容规范、所属人都会被严格检查检查通过脚本才会被执行。所以一般还是把它关闭掉否则疑点会很多。 # script_user root # 指定执行脚本的用户不指定的话默认是 keepalived_script 用户而该用户默认不存在还需要手动去创建。 #} vrrp_instance VI_1 { state MASTER # 设置起始状态为 MASTER 角色但片刻之后这个角色能否保持还是取决于 priority。 interface ens33 # 指定 VIP 绑定的网卡接口 virtual_router_id 50 # 类似群组的功能要求同一个服务器池的机器的此值都保持一致否则会出现脑裂现象即同时出现多个 MASTER 角色。 priority 150 # 指定优先级值越大优先级越高。取值范围0~255 advert_int 1 # 心跳发包间隔时间1秒 # nopreempt # 开启非抢占模式 virtual_ipaddress { 192.168.98.200 # 定义虚拟 IP } }# 服务器 B 的 keepalived 配置 vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 50 priority 100 advert_int 1 virtual_ipaddress { 192.168.98.200 } }注1如果 AB 服务器只有一方开启了非抢占模式那么仅为服务器 A 开启非抢占模式的选举仅对 A 有效B 若没有开启此功能的话B 是会进行抢占的。2router_id是“节点名字”可随便指定virtual_router_id是“VRRP 组编号”服务器池中的所有主机必须保持一致。4.2、VIP 绑定实验目的让多个虚拟 ip 捆绑在一台服务器上而不是让他们各自选举随机分布在不同的服务器上。# 服务器 A 的 keepalived 配置 global_defs { router_id LVS_MASTER } ############################ # 第一个 VRRP 实例 ############################ vrrp_instance VI_WEB { state MASTER interface ens33 virtual_router_id 51 # 关注点 priority 150 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.200/24 # 关注点 } } ############################ # 第二个 VRRP 实例 ############################ vrrp_instance VI_DB { state MASTER interface ens33 virtual_router_id 52 # 关注点 priority 50 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.250/24 # 关注点 } } ############################ # 同步组 ############################ vrrp_sync_group VG_1 { group { VI_WEB VI_DB } }# 服务器 B 的 keepalived 配置 global_defs { router_id LVS_MASTER } ############################ # 第一个 VRRP 实例 ############################ vrrp_instance VI_WEB { state BACKUP interface ens33 virtual_router_id 51 # 关注点 priority 100 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.200/24 # 关注点 } } ############################ # 第二个 VRRP 实例 ############################ vrrp_instance VI_DB { state BACKUP interface ens33 virtual_router_id 52 # 关注点 priority 100 # 关注点 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.98.250/24 # 关注点 } } ############################ # 同步组 ############################ vrrp_sync_group VG_1 { group { VI_WEB VI_DB } }注服务器 A 的 VI_WEB 的优先级大于 服务器 B 的 VI_WEBA 的 VI_DB 的优先级又小于 B 的 VI_DB在不绑定 VIP 组的情况下A 服务器上存在一个 VIPB 服务器存在一个 VIP当绑定 VIP 组之后这两个 VIP 要么都在 A 服务器上要么都在 B 服务器上此时优先级似乎没有什么作用了 VIP 在哪个服务器上完全取决于服务启动的先后顺序了。4.3、健康检查实验目的让服务器的优先级可以随着外部环境的一些可变因素而发生变化而不是一成不变或者只能在 keepalived 服务挂掉或服务器宕机的情况下优先级才会改变伴随着 MASTER 角色才能发生改变。# 服务器 A 的 keepalived 配置 vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 50 priority 150 advert_int 1 virtual_ipaddress { 192.168.98.200 } }# 服务器 B 的 keepalived 配置 #global_defs { # vrrp_strict # 对 VRRP 配置进行严格校验。建议关闭否则可能会出现一些奇怪的问题。 # enable_script_security # 开启脚本执行环境的安全模式此时脚本相关的文件权限、内容规范、所属人都会被严格检查检查通过脚本才会被执行。所以一般还是把它关闭掉否则疑点会很多。 # script_user root # 指定执行脚本的用户不指定的话默认是 keepalived_script 用户而该用户默认不存在还需要手动去创建。 #} vrrp_script chk_mt { script /etc/keepalived/chk_mt.sh # 当脚本返回 0 时priority160 priority100 weight60此时 B 的优先级会大于 AB 会切换为 MASTER。 interval 10 # 脚本每 10 秒执行一次 weight 60 } vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 50 priority 100 advert_int 1 virtual_ipaddress { 192.168.98.200 } track_script { chk_mt } }测试脚本如下#!/bin/bash #touch /tmp/test.txt echo test /tmp/test2.txt touch /tmp/test.txt #exit 1注关于健康脚本的实验在测试的时候坑有点多现将注意事项整理如下。1安全选项 enable_script_security 开启的状态下被执行脚本的权限最好是 750脚本所有者和 script_user 指定的要保持一致。2keepalived 的脚本执行环境不是简单的 bash脚本内容不能有类似echo 123 /tmp/test.txt这种写法出现特殊符号会导致脚本解析错误的问题。若是要进行判断可在脚本中写入/usr/bin/touch /tmp/test.txt然后在 shell 中不断执行stat /tmp/test.txt去查看文件的修改时间是否发生变化若有变化则说明脚本是被执行了。3脚本在被执行时systemctl ststus keepalived.service日志中并不会显示脚本每次被定时执行的事件只会显示初次被执行时的状态。但即便显示初始化失败也并不意味着该脚本就没有被执行它的判断标准似乎只是根据脚本的最后一条命令的返回值进行的判断若最后一条命令执行失败或错误日志显示的初始化状态便也是 failed 状态但这个状态下脚本依旧被定时执行着。4脚本在每次被执行之后它的优先级的计算并非每次都是priority priority weight 而是只有在“状态发生变化”时才会调整优先级。例如假设 weight 等于 20脚本被定时执行 5 次之后 优先级的状态如下时间返回值状态priorityT10OK90T21FAIL70T31FAIL仍失败70不变T41FAIL持续失败70不变T50OK90可见weight 值不是让 priority 一直递减它只是在 90 和 70 这两个值之间来回跳。4.4、切换通知实验目的让服务器的角色在发生变化时可以通过邮箱或一些其它的手段来通知管理员或是让其可以执行一些其它什么脚本任务啥的。#通知脚本 #!/bin/bash # 这里是我们的vip 地址 vip172.16.100.104 contactrootlocalhost notify() { mailsubjecthostname to be $1: $vip floating mailbodydate %F %H:%M:%S: vrrp transition, hostname changed to be $1 echo $mailbody | mail -s $mailsubject $contact # 发送 } case $1 in master) notify master exit 0 ;; backup) notify backup exit 0 ;; fault) notify fault exit 0 ;; *) echo Usage: basename $0 {master|backup|fault} exit 1 ;; esac# ... 其他配置 vrrp_instance VI_1 { # ... 其他配置 notify_master /etc/keepalived/notify.sh master # 当当前服务器的角色切换为 MASTER 时向 root 用户发送 mail通知 notify_backup /etc/keepalived/notify.sh backup # 当当前服务器的角色切换为 BACKUP 时向 root 用户发送 mail通知 notify_fault /etc/keepalived/notify.sh fault # 当当前服务器的角色切换为 FAULT 时向 root 用户发送 mail通知 }4.5、负载均衡实验目的让访问 VIP 的请求任务可以被均匀的分发给不同的后端服务器进行处理。vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 50 priority 150 advert_int 1 virtual_ipaddress { 192.168.98.200 } } virtual_server 192.168.98.200 8080 { delay_loop 20 lb_algo rr # 负载均衡调度算法 lb_kind NAT # 负载实现的 NAT 模式 persistence_timeout 360 protocol TCP # 实际处理任务的后端服务器 real_server 192.168.98.120 8080 { weight 1 TCP_CHECK { # TCP 健康检查 connect_timeout 3 } } real_server 192.168.98.130 8080 { weight 1 TCP_CHECK { connect_timeout 3 } } }注以上仅为配置上的示例实际上还需要在机器上进行一些系统级的功能开启具体参考 这篇文章。仅凭以上配置在浏览器访问 web 服务 http://192.168.98.200:8080 并不能够成功。5、杂七杂八1参考文档中文手册、木西笔记、CSDN2服务器之间的心跳包的防火墙放行规则如下# 放行广播包 iptables -A INPUT -i eth1 -d 224.0.0.0/8 -j ACCEPT # 放行协议号 112。心跳包是一个基于 ip 协议之上的 vrrp 协议包协议号是 112。【这条似乎可以省略有前面一条就够了】 iptables -A INPUT -i eth1 -p 112 -j ACCEPT
