本文主要介绍关于管理的知识点，对【Keepalive 基础概要及简单示例】和【keepalive管理页面】有兴趣的朋友可以看下由【勐泐游侠】投稿的技术文章，希望该技术和经验能帮到你解决你所遇的【linux学习,原创+摘抄】相关技术问题。
##keepalive简介
keepalive的目标是为Linux系统和基于Linux的基础设施提供简单而强大的负载平衡和高可用性保障。负载平衡框架依赖于众所周知的广泛使用的Linux虚拟服务器（IPVS） 内核模块，提供Layer4负载平衡。Keealived动态的管理负债均衡的服务器群，实现服务器的健康检测。而了解keepalive，就不得不了解VRRP协议，keepalived正是以vrrp的工作逻辑来工作的，那么我们就先了解VRRP协议是什么样的协议，再了解keepalived。
keepalived是lvs的扩展项目，因此它们之间具备良好的兼容性。通过对服务器池对象的健康检查，实现对失效机器/服务的故障隔离。负载均衡器之间的失败切换failover，是通过VRRPv2（Virtual Router Redundancy Protocol）stack实现的 。
##VRRP 协议
####VRRP协议概述
随着Internet的发展，人们对网络的可靠性的要求越来越高。对于局域网用户来说，能够时刻与外部网络保持联系是非常重要的。
通常情况下，内部网络中的所有主机都设置一条相同的缺省路由，指向出口网关（即图1中的路由器RouterA），实现主机与外部网络的通信。当出口网关发生故障时，主机与外部网络的通信就会中断。
IETF（Internet Engineering Task Force，因特网工程任务组）推出了VRRP（Virtual Router Redundancy Protocol）虚拟路由冗余协议，来解决局域网主机访问外部网络的可靠性问题。
VRRP是一种容错协议，它通过把几台路由设备联合组成一台虚拟的路由设备，并通过一定的机制来保证当主机的下一跳设备出现故障时，可以及时将业务切换到其它设备，从而保持通讯的连续性和可靠性。
使用VRRP的优势在于：既不需要改变组网情况，也不需要在主机上配置任何动态路由或者路由发现协议，就可以获得更高可靠性的缺省路由。
####VRRP的基本概念
关键词解释VRRP路由器（VRRP Router）运行VRRP的设备，它可能属于一个或多个虚拟路由器。（实体路由器）虚拟路由器（Virtual Router）由VRRP管理的抽象设备，又称为VRRP备份组，被当作一个共享局域网内主机的缺省网关。 它包括了一个虚拟路由器标识符和一组虚拟IP地址。(实体路由器组)虚拟IP地址(Virtual IP Address)s虚拟路由器的IP地址，一个虚拟路由器可以有一个或多个IP地址，由用户配置IP地址拥有者（IP Address Owner）如果一个VRRP路由器将虚拟路由器的IP地址作为真实的接口地址，则该设备是IP地址拥有者。 当这台设备正常工作时，它会响应目的地址是虚拟IP地址的报文，如ping、TCP连接等虚拟MAC地址是虚拟路由器根据虚拟路由器ID生成的MAC地址。 一个虚拟路由器拥有一个虚拟MAC地址，格式为：00-00-5E-00-01-{VRID}。 当虚拟路由器回应ARP请求时，使用虚拟MAC地址，而不是接口的真实MAC地址。主IP地址（Primary IP Address）从接口的真实IP地址中选出来的一个主用IP地址，通常选择配置的第一个IP地址。 VRRP广播报文使用主IP地址作为IP报文的源地址。Master路由器（Virtual Router Master）是承担转发报文或者应答ARP请求的VRRP路由器，转发报文都是发送到虚拟IP地址的。 如果IP地址拥有者是可用的，通常它将成为Master。Backup路由器（Virtual Router Backup）一组没有承担转发任务的VRRP路由器，当Master设备出现故障时，它们将通过竞选成为新的Master抢占模式在抢占模式下，如果Backup的优先级比当前Master的优先级高，将主动将自己升级成Master非抢占模式只要master路由器没有出现故障，即使backup路由器的优先路由器高于master路由器，也不会成为master路由器####VRRP的工作原理
VRRP将局域网的一组路由器构成一个备份组，相当于一台虚拟路由器。局域网内的主机只需要知道这个虚拟路由器的IP地址，并不需知道具体某台设备的IP地址，将网络内主机的缺省网关设置为该虚拟路由器的IP地址，主机就可以利用该虚拟网关与外部网络进行通信。
VRRP将该虚拟路由器动态关联到承担传输业务的物理路由器上，当该物理路由器出现故障时，再次选择新路由器来接替业务传输工作，整个过程对用户完全透明，实现了内部网络和外部网络不间断通信。
如上图所示，虚拟路由器的组网环境如下：
RouterA、RouterB和RouterC属于同一个VRRP组，组成一个虚拟路由器，这个虚拟路由器有自己的IP地址172.18.14.1。虚拟IP地址可以直接指定，也可以借用该VRRP组所包含的路由器上某接口地址。
物理路由器RouterA、RouterB和RouterC的实际IP地址分别是172.18.14.10、172.18.14.11、172.18.14.12
局域网内的主机只需要将缺省路由设为172.18.14.1即可，无需知道具体路由器上的接口地址。
主机利用该虚拟网关与外部网络通信。路由器工作机制如下：
根据优先级的大小挑选Master设备。Master的选举有两种方法： 比较优先级的大小，优先级高者当选为Master。当两台优先级相同的路由器同时竞争Master时，比较接口IP地址大小。接口地址大者当选为Master。 其它路由器作为备份路由器，随时监听Master的状态。 当主路由器正常工作时，它会每隔一段时间（Advertisement_Interval）发送一个VRRP组播报文，以通知组内的备份路由器，主路由器处于正常工作状态。当组内的备份路由器一段时间（Master_Down_Interval）内没有接收到来自主路由器的报文，则将自己转为主路由器。一个VRRP组里有多台备份路由器时，短时间内可能产生多个Master，此时，路由器将会将收到的VRRP报文中的优先级与本地优先级做比较。从而选取优先级高的设备做Master。####VRRP的状态机
VRRP协议中定义了三种状态机：初始状态（Initialize）、活动状态（Master）、备份状态（Backup）。其中，只有处于活动状态的设备才可以转发那些发送到虚拟IP地址的报文。
Initialize
设备启动时进入此状态，当收到接口Startup的消息，将转入Backup或Master状态（IP地址拥有者的接口优先级为255，直接转为Master）。在此状态时，不会对VRRP报文做任何处理。Master 当路由器处于Master状态时，它将会做下列工作：
定期发送VRRP报文。以虚拟MAC地址响应对虚拟IP地址的ARP请求。转发目的MAC地址为虚拟MAC地址的IP报文。如果它是这个虚拟IP地址的拥有者，则接收目的IP地址为这个虚拟IP地址的IP报文。否则，丢弃这个IP报文。如果收到比自己优先级大的报文则转为Backup状态。如果收到优先级和自己相同的报文，并且发送端的主IP地址比自己的主IP地址大，则转为Backup状态。当接收到接口的Shutdown事件时，转为Initialize。Backup 当路由器处于Backup状态时，它将会做下列工作:
接收Master发送的VRRP报文，判断Master的状态是否正常。对虚拟IP地址的ARP请求，不做响应。丢弃目的MAC地址为虚拟MAC地址的IP报文。丢弃目的IP地址为虚拟IP地址的IP报文。Backup状态下如果收到比自己优先级小的报文时，丢弃报文，不重置定时器；如果收到优先级和自己相同的报文，则重置定时器，不进一步比较IP地址。当Backup接收到MASTER_DOWN_TIMER定时器超时的事件时，才会转为Master。当接收到接口的Shutdown事件时，转为Initialize。####负载分担
现在允许一台路由器为多个作备份。通过多虚拟路由器设置可以实现负载分担。
负载分担方式是指多台路由器同时承担业务，因此需要建立两个或更多的备份组。
负载分担方式具有以下特点:
每个备份组都包括一个Master设备和若干Backup设备。
各备份组的Master可以不同。
同一台路由器可以加入多个备份组，在不同备份组中有不同的优先级。
!
配置两个备份组：组1和组2；
RouterB在备份组1中作为Master，在备份组2中作为Backup；
RouterC在备份组1和2中都作为Backup；
RouterA在备份组2中作为Master，在备份组1中作为Backup。
一部分主机使用备份组1作网关，另一部分主机使用备份组2作为网关。
这样，以达到分担数据流，而又相互备份的目的。
##Kepalive基础
Keepalive体系结构
Keepalived 大致分两层结构：用户空间 user space和内核空间 kernel space
在这个结构图里，处于下端的是内核空间，它包括IPVS和NETLINK两个部分。netlink提供高级路由及其他相关的网络功能，如果在负载均衡器上启用netfilter/iptable，将会直接影响它的性能。处于图形上方的组件为用户空间，由它来实现具体的功能，下面选取几个重要的来做说明：
WatchDog 负责监控checkers和VRRP进程的状况；Checkers 负责真实服务器的健康检查healthchecking，是keepalived最主要的功能；VRRP Stack负责负载均衡器之间的失败切换FailOver；IPVS wrapper 用来发送设定的规则到内核ipvs代码；Netlink Reflector 用来设定 vrrp 的vip地址等。在Linux主机上，以daemon（守护进程）方式实现了vrrp协议，并提供了完成配置ipvs规则及实现相应real server状态检测能力。能调用外部脚本轻量灵活，不能解决脑裂问题（需要依靠其他措施来解决）Keepalived正常运行时，会启动3个进程，分别是core、check和vrrp：
vrrp模块是来实现VRRP协议的；check负责健康检查，包括常见的各种检查方式；core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。注意：
keepalived的启动过程并不会对配置文件进行语法检查，就算没有配置文件，keepalived的守护进程照样能够被运行起来。在不指定配置文件位置的状态下—keepalived默认先查找文件/etc/keepalived/keepalived.conf ，可以手动创建这个文件，然后在这个文件里书写规则，来达到控制keepalived运行的目的。keepalived特性:
vrrp协议的软件实现，原生设计的目的为了高可用ipvs服务：
vrrp协议完成地址流动；
为vip地址所在的节点生成ipvs规则（在配置文件中预先定义）；
为ipvs集群的各RS做健康状态检测；
基于脚本调用接口通过执行脚本完成脚本中定义的功能，进而影响集群事务；
KeepAlive的配置文件解释：
全局定义块，必须存在：global_defs {
notification_email {
a@abc.com
b@abc.com ##故障发生时给谁发邮件通知
}
notification_email_from c@abc.com ##通知邮件从哪个地址发出
smtp_server 172.18.14.168 ##通知邮件的smtp地址
smtp_connect_timeout 30 ## 连接smtp服务器的超时时间
router_id LVS_DEVEL ##标识本节点的字条串，故障发生时，邮件通知会用到
}
vrrp_script chk_http_port {
script "path to scirpts " :检测脚本
interval 1 ：检测周期
weight -10 :当发生检测失败事件，权重较低多少
}
vrrp_instance VI_1 {
state MASTER ##可以是MASTER或BACKUP，不过当其他节点keepalived启动时会将priority比较大的节点选举为MASTER
interface IFACE_NAME ##绑定为当前虚拟路由器使用的物理接口；
priority 100 ## 当前主机在此虚拟路径器中的优先级；范围1-254；
virtual_router_id 1 ## 取值在0-255之间，用来区分多个instance的VRRP组播， 同一网段中该值不能重复，并且同一个vrrp实例使用唯一的标识，即虚拟路由器id
advert_int 1 ##发VRRP包的时间间隔，即多久进行一次master选举，可以认为是健康查检时间间隔，单位为秒
authentication {
auth_type PASS ##认证类型有PASS和AH（IPSEC），通常使用的类型为PASS，同一vrrp实例MASTER与BACKUP 使用相同的密码才能正常通信
auth_pass 12345678
virtual_ipaddress { ##可以有多个VIP(虚拟路由器)地址，每个地址占一行，不需要指定子网掩码，必须与RealServer上设定的VIP相一致
#指明虚拟ip地址，配置在哪个网卡/网卡别名
/
brd
dev
scope
label
virtual_server 172.18.14.1 80 { ##定义RealServer对应的VIP及服务端口,必须与RealServer上设定的VIP相一致
delay_loop 6 ##延迟轮询时间（单位秒）
lb_algo rr ## 后端调试算法（load balancing algorithm ）
lb_kind NAT ##LVS调度类型NAT/DR/TUN
nat_mask 255.255.0.0
persistence_timeout 50 ##持久连接超时时间
protocol TCP ##转发协议protocol.一般有TCP和UDP两种
sorry_server ##当所有RealServer宕机时，sorry server顶替
real_server 192.168.200.100 80 { ##RealServer的IP和端口号，改组可在下面定义多个
weight 1
HTTP_GET {
url {
path / ##请求Real Serserver上的路径
digest ff20ad2481f97b1754ef3e12ecd3a9cc
status_code 200 ##用genhash算出的结果和http状态码
}
connect_timeout 3 ##超时时长
nb_get_retry 3 ##重试次数
delay_before_retry 3 ##下次重试的时间延迟
}
}
}
虚拟服务器的常用参数：
delay_loop
：#服务轮询的时间间隔； lb_algo rr|wrr|lc|wlc|lblc|sh|dh：#定义调度方法； lb_kind NAT|DR|TUN：#集群的类型； persistence_timeout
：#持久连接时长； protocol TCP：#服务协议，仅支持TCP； sorry_server
##备用服务器地址； real_server
{ weight
notify_up
|
notify_down
|
HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }：##定义当前主机的健康状态检测方法； } HTTP_GET|SSL_GET：#应用层检测 HTTP_GET|SSL_GET { url { path
：#定义要监控的URL； status_code
：#判断上述检测机制为健康状态的响应码； digest
：#判断上述检测机制为健康状态的响应的内容的校验码； } nb_get_retry
：#重试次数； delay_before_retry
：#重试之前的延迟时长； connect_ip
：#向当前RS的哪个IP地址发起健康状态检测请求 connect_port
：#向当前RS的哪个PORT发起健康状态检测请求 bindto
：#发出健康状态检测请求时使用的源地址； bind_port
：#发出健康状态检测请求时使用的源端口； connect_timeout
：#连接请求的超时时长； } TCP_CHECK { connect_ip
：#向当前RS的哪个IP地址发起健康状态检测请求 connect_port
：#向当前RS的哪个PORT发起健康状态检测请求 bindto
：#发出健康状态检测请求时使用的源地址； bind_port
：#发出健康状态检测请求时使用的源端口； connect_timeout
：#连接请求的超时时长； }
##Keepalive示例
####简易keepalive
node1配置：/etc/keepalived/keepalived.conf
node2配置：/etc/keepalived/keepalived.conf
接着在两台节点都重启keepalived服务（节点1为master,节点2为backup），节点1，注意观察标记部分，进入了master 模式， 并获取的虚拟路由器ip.
节点2，注意标记部分，收到了高优先级虚拟路由器通告，进入backup模式，主动释放虚拟路由器iP(VIP)
接着人为的把节点1keepalived模式关闭，然后观察节点2 keepalived 状态，可以发现节点2收不到master的通告，由backup模式转入master模式，并获取VIP 地址。
####双主模型
下面请看配置示例：
节点A：
节点2配置：
之后再重启，验证方法不再复述，自行回去复习哦。
探测网卡，查看arp广播发送情况 。
[root@localhost ~]# tcpdump -i eno16777736 -nn host 224.0.14.14
1、编写通知脚本，节点A,B都一样：由于截图关系导致截图补全（最上面是shell脚本的shellbang,#!/bin/bash）
2、修改/etc/keepalived/keepalived.conf配置文件：
高可用LVS 集群：
一、单主配置模式（一主一备），采用lvs-dir模型，采用五台主机，两个DS，两台RS，一台client测试机
1、对2台RS主机分别安装httpd服务，编辑配置文件，以示区分。
RS1
RS2
2、分别对2台RS，配置vip,开启 arp_ignore,arp_announce选项，配置主机路由，这里采用脚本的形式：
对RS1进行lvs-dir相关操作：
编写脚本，再执行脚本
[root@localhost scripts]# cat rs.sh
#!/bin/bash
#
iface=eth0
case $1 in
start)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/${iface}/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/${iface}/arp_announce
;;
stop)
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/${iface}/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/${iface}/arp_announce
;;
*)
echo "usage $(basename $0) start|stop"
exit 1
;;
esac
RS1添加vip ,添加主机路由:
RS2：操作方式和RS1一样，不在复述。
对DS1 keepalive的配置文件进行修改：
对DS2 keepalive的配置文件进行修改：
重启各个DS的keepalive ，在客户机测试结果：
测试keepalive健康状态检测：（蓄意关闭RS1的httpd）
[root@localhost scripts]# service httpd stop
Stopping httpd: [ OK ]
在DS1进行lvs集群信息查看：（已有一台RS自动被移除。）
测试DS的sorry server功能：
再将另一台RS关闭（模拟故障）
[root@bnpanda script]#systemctl stop httpd
在DS1查看集群信息：已成功转入DS1的错误server
在客户端进行验证：（错误页正常显示）
再将DS1认为关闭，模拟故障：
到DS2查看ip信息，虚拟ip（172.18.14.1）已转到DS2：
客户端测试：（DS2 sorry server发挥作用）
####双主模型
基本原则和单主模型一致，需要注意的是，双主模式，存在两个VIP，RS1,RS2需要配置两个VIP，都需要配置两个主机路由，DS1，DS2，keepalive 的/etc/keepalived/keepalived.conf配置文件需要配置两个虚拟路由器，两个虚拟服务器:
DS1配置文件：
[root@localhost keepalived]# cat keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.0.14.14
}
vrrp_instance myr1 {
state MASTER
interface eno16777736
virtual_router_id 78
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.1/16 dev eno16777736
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
}
vrrp_instance myr2 {
state BACKUP
interface eno16777736
virtual_router_id 79
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.2/16 dev eno16777736
}
}
virtual_server 172.18.14.1 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 172.18.14.2 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
DS2配置文件：
[root@localhost keepalived]# cat keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.0.14.14
}
vrrp_instance myr1 {
state BACKUP
interface eno16777736
virtual_router_id 78
priority 96
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.1/16 dev eno16777736
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_default "/etc/keepalived/notify.sh default"
}
vrrp_instance myr2{
state MASTER
interface eno16777736
virtual_router_id 79
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.2/16 dev eno16777736
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_default "/etc/keepalived/notify.sh default"
}
virtual_server 172.18.14.1 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 172.18.14.2 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
RS1添加VIP：(基于单主模型环境做的修改，额外添加一个vip)
#ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2
#route add -host 172.18.14.2 dev lo:1
RS2添加VIP：(基于单主模型环境做的修改，额外添加一个vip)
#ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2
#route add -host 172.18.14.2 dev lo:1
最后重启DS1，DS2，的keepalive
客户机测试：两个地址均能正常访问。
####双主模型的高可用nginx proxy服务
采用DIR的模式，在两台RS上分别取消arp应答与通告
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore;
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore;
echo 2 >/proc/sys/net/ipv4/conf/all/arp_anonouce;
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce;
两台主机添加两个VIP，启用两个主机路由（VIP的主机路由）
RS1: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0
RS1: ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2 up
route add -host 172.18.14.2 dev lo:1
RS2: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0
RS2: ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2 up
route add -host 172.18.14.1 dev lo:1
1、在两台代理上安装好nginx :
DS 1:
配置/etc/nginx/nginx.conf:
在http上下文内部定义一个 upstream:
[root@localhost keepalived]# vim /etc/nginx/conf.d/default.conf
在默认的location内部直接添加 proxy_pass http://websrv
DS2的nginx配置和DS1基本一致
2配置keepalived
DS1:
[root@localhost keepalived]# vim keepalived.conf
(/etc/keepalived/keepalived.conf)
解释一下：
vrrp_script ngxstatus { #此处为ngx状态检测脚本：
script 'killall -0 nginx && exit 0 || exit 1'
interval 1 #探测间隔
weight -5 #如果探测到nginx未启动，权重下降度5
}
track_script {#调用自定义脚本
ngxstatus #(调用之前定义的status脚本)
}
注意：自定义脚本请先定义，再调用，且在虚拟路由器实体中调用
此处自定义脚本的作用：当探测到本机nginx服务没有启动，就自动的把权重减5.使其从master变为backup,实现了主nginx故障的时候，业务能更换到备nginx上。即实现了nginx的双机备份。
DS2方式和DS1 类似 注意vrrp master,priority即可
3、重启nginx和keealive 两台都要操作（建议systemctl stop keepalive和systemctl startt keepalive）:避免操作失效
4到客户端测试：
5、人为关闭DNS1的keepalive，到DNS2观察 VIP是否已经获取到了。
附加测试：问：ipvs使用持久连接时，故障切换后，同一个客户端是否依然能关联至此前绑定的RS？
DS两台，RS两台，client一台
1、ipvs使用持久连接：
采用DIR模式：
RS1，RS2
采用DIR的模式，在两台RS上分别取消arp应答和通告：
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore;
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore;
echo 2 >/proc/sys/net/ipv4/conf/all/arp_anonouce;
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce;
两台主机添加两个VIP，启用两个主机路由（VIP的主机路由）
RS1: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0
RS2: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0
DS1 keepalived 配置 /etc/keepalived/keepalived.conf
DS2:配置 /etc/keepalived/keepalived.conf
在客户端测试：（因为持久连接的缘故，所以都是同一个页面）
现在，把RS1的 httpd关闭：
再次测试：业务成功转移到RS2
再次回复RS1 的httpd
关闭DS1 的keepalived
再次测试：访问的依旧是原来的页面
附加测试：问：ipvs使用sh算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的RS？
基础配置和上述的基本一致，主要就是设定算法的地方有所区别：
DS1
DS2
经过测试：
第一次访问
关闭DS1 的keepalive
再次测试：（业务成功迁移）
保证DS1 和DS2 的keepalived服务开启，将RS1的httpd关闭，即使在SH算法下，业务也能够正常迁移
问：nginx使用ip_hash算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的upstream server？
本次实验采用的单主模式：（双主模式请到前文去找了啦）
IP_hash 算法：
1、准备nginx的负载均衡配置：
DS1：
安装nginx：
修改/etc/nginx/nginx.conf,在http上下文中增加 upstram
修改/etc/nginx/conf.d/default.conf，直接在location内添加代理语句：（proxy_pass http://websrv）
DS2：
安装方法，和配置方式和DS1基本一致哦，除了sorry sever需要写自己本机的地址（或者写其他sorry server的ip地址也没问题啦。看个人想法）
2、准备 keepalived 配置 (编辑自定义脚本，使用killall时，确保系统安装了 psmisc 程序包 啊！)
DS1配置文件：
DS2配置文件：
测试：在所有业务都正常开启的时候 ，由于ip_hash算法，都被定位到RS2 上
故障测试：将RS2 web服务（httpd)关闭，再从客户端浏览访问：，此次业务并未终端，成功迁移到RS1上。
问：nginx使用hash $request_uri 算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的upstream server？
hash $request_uri 算法 配置和ip_hash 基本一致，除了nginx的配置所有差异：
DS1：
/etc/nginx/nginx.conf
DS2 nginx配置文件:
所有服务均正常的情况（keepalive ,nginx,httpd开启）：
将RS2 web服务关闭：
将所有服务恢复：访问测试
A、关闭 DS1 的nginx：再进行访问测试：
B、 启动 DS1 的nginx：再进行访问测试：
本文《Keepalive 基础概要及简单示例》版权归勐泐游侠所有，引用Keepalive 基础概要及简单示例需遵循CC 4.0 BY-SA版权协议。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有