Keepalive 基础概要及简单示例

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 {     
   [e-mail]  
   [e-mail]    ##故障发生时给谁发邮件通知
  }   
 notification_email_from [e-mail]   ##通知邮件从哪个地址发出
 smtp_server 172.18.14.168        ##通知邮件的smtp地址
 smtp_connect_timeout 30          ## 连接smtp服务器的超时时间
 router_id LVS_DEVEL          ##标识本节点的字条串，故障发生时，邮件通知会用到
}

• vrrp_script区域主要用来做健康检查的，当时检查失败时会将vrrp_instance的priority减少相应的值。（自定义脚本）

vrrp_script chk_http_port {   
 script "path to scirpts " :检测脚本
 interval 1    ：检测周期
 weight -10  :当发生检测失败事件，权重较低多少
}

• VRRP实例定义块主要用来定义对外提供服务的VIP区域及其相关属性：

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地址，配置在哪个网卡/网卡别名
    <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL>
       172.18.14.1
    }  

track_script {     #调用自定义脚本 即vrrp_script区域的脚本
 chk_http_port    #要调用的自定义名称
}    

track_interface {  #跟踪监视机制一旦接口出现故障，则转为FAULT状态
                            eth0
                            eth1
                }

nopreempt：#定义工作模式为非抢占模式；（如果不加，就默认抢占模式）
preempt_delay 300：#抢占式模式下，节点上线后触发新选举操作的             

notify_master <STRING>|<QUOTED-STRING>：当前节点成为主节点时(master状态)触发的通知脚本；

  notify_backup <STRING>|<QUOTED-STRING> #切换为备用（backup）时的通知脚本

  notify_fault <STRING>|<QUOTED-STRING> #出错时（faulty状态）的通知脚本

  notify <STRING>|<QUOTED-STRING> 
   #表示任何状态都会触发的通知脚本，并且该脚本在以上三个脚本执行完成之后进行调用，keepalived会自动传递三个参数：（$1 = "GROUP"|"INSTANCE"，$2 = name of group or instance，$3 = target state of transition(MASTER/BACKUP/FAULT)）
1

}
}

• 虚拟服务器定义块

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 <INT>：#服务轮询的时间间隔；
                 lb_algo rr|wrr|lc|wlc|lblc|sh|dh：#定义调度方法；
                 lb_kind NAT|DR|TUN：#集群的类型；
                 persistence_timeout <INT>：#持久连接时长；
                 protocol TCP：#服务协议，仅支持TCP；
                sorry_server <IPADDR> <PORT> ##备用服务器地址；
                real_server <IPADDR> <PORT>
                {
                     weight <INT>
                     notify_up <STRING>|<QUOTED-STRING>
                     notify_down <STRING>|<QUOTED-STRING>
                     HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }：##定义当前主机的健康状态检测方法；
                }

                HTTP_GET|SSL_GET：#应用层检测

                HTTP_GET|SSL_GET {
                    url {
                        path <URL_PATH>：#定义要监控的URL；
                        status_code <INT>：#判断上述检测机制为健康状态的响应码；
                        digest <STRING>：#判断上述检测机制为健康状态的响应的内容的校验码；
                    }
                    nb_get_retry <INT>：#重试次数；
                    delay_before_retry <INT>：#重试之前的延迟时长；
                    connect_ip <IP ADDRESS>：#向当前RS的哪个IP地址发起健康状态检测请求
                    connect_port <PORT>：#向当前RS的哪个PORT发起健康状态检测请求
                    bindto <IP ADDRESS>：#发出健康状态检测请求时使用的源地址；
                    bind_port <PORT>：#发出健康状态检测请求时使用的源端口；
                    connect_timeout <INTEGER>：#连接请求的超时时长；
                }

                 TCP_CHECK {
                    connect_ip <IP ADDRESS>：#向当前RS的哪个IP地址发起健康状态检测请求
                    connect_port <PORT>：#向当前RS的哪个PORT发起健康状态检测请求
                    bindto <IP ADDRESS>：#发出健康状态检测请求时使用的源地址；
                    bind_port <PORT>：#发出健康状态检测请求时使用的源端口；
                    connect_timeout <INTEGER>：#连接请求的超时时长；
                }

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 地址。

---

双主模型

双主模型：简单来说，就是在VRRP2中，Router A 是Master状态，router B 是Backup状态；而在VRRP1中，Router A 是 Backup状态，router B 是Master状态。

下面请看配置示例：
节点A：

节点2配置：

之后再重启，验证方法不再复述，自行回去复习哦。
探测网卡，查看arp广播发送情况 。
[[e-mail] ~]# tcpdump -i eno16777736 -nn host 224.0.14.14

---

通知脚本的使用方式（示例）：

1、编写通知脚本，节点A,B都一样：由于截图关系导致截图补全（最上面是shell脚本的shellbang,#!/bin/bash）

2、修改/etc/keepalived/keepalived.conf配置文件：

关闭、重启两个节点的keepalived服务，查看邮件是否发送

---

高可用LVS 集群：

一、单主配置模式（一主一备），采用lvs-dir模型，采用五台主机，两个DS，两台RS，一台client测试机

1、对2台RS主机分别安装httpd服务，编辑配置文件，以示区分。
RS1

RS2

2、分别对2台RS，配置vip,开启 arp_ignore,arp_announce选项，配置主机路由，这里采用脚本的形式：
对RS1进行lvs-dir相关操作：
编写脚本，再执行脚本

[[e-mail] 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关闭（模拟故障）
[[e-mail] 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配置文件：

[[e-mail] keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
    [e-mail]
   }
   notification_email_from [e-mail]
   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配置文件：

[[e-mail] keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
    [e-mail]
   }
   notification_email_from [e-mail]
   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:
[[e-mail] 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是否已经获取到了。


6、重启DNS1 的keepalive,观察是否获取

7、DS1 关闭nginx，保持keepalived开启，查看DNS2是否获取vip，是否实现了nginx的故障切换，实现nginx高可用集群。


8、DNS1，重新启动nginx，查看是否重新获取ip,

---

附加测试：问：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

注：server 172.18.14.197:80 表示的是RS1，server 172.18.14.33:80表示的RS2，可以根据实际修改配置，而127.0.0.1:8080是本机的sorry server(这里选用的是http，已更改监听端口为8080，可根据实际需要修改)

修改/etc/nginx/conf.d/default.conf，直接在location内添加代理语句：（proxy_pass http://websrv）

上图使用的是ip_hash算法

DS2：
安装方法，和配置方式和DS1基本一致哦，除了sorry sever需要写自己本机的地址（或者写其他sorry server的ip地址也没问题啦。看个人想法）

2、准备 keepalived 配置 (编辑自定义脚本，使用killall时，确保系统安装了 psmisc 程序包 啊！)
DS1配置文件：

DS2配置文件：


（改配置前文有类似的实验，具体验证方法前文也有说明，此处不再负叙述，已经过验证，当DS1 nginx服务down掉，ip是能够转移到DS2上的）

测试：在所有业务都正常开启的时候 ，由于ip_hash算法，都被定位到RS2 上

故障测试：将RS2 web服务（httpd)关闭，再从客户端浏览访问：，此次业务并未终端，成功迁移到RS1上。

---

问：nginx使用hash requesturi算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的upstreamserver？hashrequest_uri 算法 配置和ip_hash 基本一致，除了nginx的配置所有差异：
DS1：
/etc/nginx/nginx.conf

DS2 nginx配置文件:

所有服务均正常的情况（keepalive ,nginx,httpd开启）：

将RS2 web服务关闭：

将所有服务恢复：访问测试

A、关闭 DS1 的nginx：再进行访问测试：

B、 启动 DS1 的nginx：再进行访问测试：