nginx Keepalived高可用集群

一、Keepalived高可用

1、简介

Keepalived软件起初是专为LvS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了可以实现高可用的VRRP功能。因此,Keepalived除了能够管理LvS软件外,还可以作为其他服务(例如: Nginx、 Haproxy、MySQL等)的高可用解决方案软件。

Keepalived软件主要是通过VRRP协议实现高可用功能的。VRRP是 Virtual router Redundancy Protocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题的,它能够保证当个别节点宕机时,整个网络可以不间断地运行。所以, Keepalived一方面具有配置管理LvS的功能,同时还具

有对LVS下面节点进行健康检査的功能,另一方面也可实现系统网络服务的高可用功能。Keepalived软件的官方站点是http://www.keepalived.org

2、Keepalived服务的三个总要功能

1).管理LVS负载均衡软件
早期的Lvs软件,需要通过命令行或脚本实现管理,并且没有针对LVS节点的健康检查功能。为了解决LVS的这些使用不便的问题, Keepalived就诞生了,可以说,Keepalived软件起初是专为解决Lvs的问题而诞生的。因此, Keepalived和Lvs的感情很深,它们的关系如同夫妻一样,可以紧密地结合,愉快地工作。 Keepalived可以通过读取自身的配置文件,实现通过更底层的接口直接管理LVS的配置以及控制服务的启动、停止等功能,这使得LVS的应用更加简单方便了。

2).实现对LVS集群节点健康检查功能( healthcheck)
Keepalived可以通过在自身的 keepalived.conf文件里配置Lvs的节点IP和相关参数实现对LVS的直接管理;除此之外,当LVS集群中的某一个甚至是几个节点服务器同时发生故障无法提供服务时, Keepalived服务会自动将失效的节点服务器从LVS的正常转发队列中清除出去,并将请求调度到别的正常节点服务器上,从而保证最终用户的访问不受影响;当故障的节点服务器被修复以后, Keepalived服务又会自动地把它们加入到正常转发队列中,对客户提供服务。

3).作为系统网络服务的高可用功能( failover)
Keepalived可以实现任意两台主机之间,例如 Master和 Backup主机之间的故障转移和自动切换,这个主机可以是普通的不能停机的业务服务器,也可以是LVS负载均衡、 Nginx反向代理这样的服务器。
Keepalived高可用功能实现的简单原理为,两台主机同时安装好 Keepalived软件并启动服务,开始正常工作时,由角色为 Master的主机获得所有资源并对用户提供服务,角色为 Backup的主机作为 Master主机的热备;当角色为 Master的主机失效或出现故障时,角色为 Backup的主机将自动接管 Master主机的所有工作,包括接管vIP资源及相应资源服务;而当角色为 Master的主机故障修复后,又会自动接管回它原来处理的工作,角色为 Backup的主机则同时释放 Master主机失效时它接管的工作,此时,两台主机将恢复到最初启动时各自的原始角色及工作状态。

3、Keepalived高可用故障切换转移原理
Keepalived高可用服务对之间的故障切换转移,是通过RRP( Virtual router Redundancy Protocol,虚拟路由器冗余协议)来实现的。
在 Keepalived服务正常工作时,主 Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备 Backup节点自己还活着,当主 Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主 Master节点的心跳了,于是调用自身的接管程序,接管主 Master节点的I资源及服务。而当主 Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的P资源及服务,恢复到原来的备用角色。

那么,什么是VRRP呢?
VRRP,全称 Virtual Router Redundancy Protocol,中文名为虚拟路由冗余协议,VRRP的出现就是为了解决静态路由的单点故障问题,VRRP是通过一种竞选机制来将路由的任务交给某台VRRP路由器的。
VRRP早期是用来解决交换机、路由器等设备单点故障的,下面是交换、路由的Master和 Backup切换原理描述,同样适用于 Keepalived的工作原理。在一组VRRP路由器集群中,有多台物理VRRP路由器,但是这多台物理的机器并不是同时工作的,而是由一台称为 Master的机器负责路由工作,其他的机器都是Backup。 Master角色并非一成不变的,VRRP会让每个VRRP路由参与竞选,最终获胜的就是 Master。获胜的 Master有一些特权,比如拥有虚拟路由器的IP地址等,拥有系统资源的 Master负责转发发送给网关地址的包和响应ARP请求。
VRRP通过竞选机制来实现虚拟路由器的功能,所有的协议报文都是通过IP多播( Multicast)包(默认的多播地址224.0.0.18)形式发送的。虚拟路由器由VRID(范围0-255)和一组IP地址组成,对外表现为一个周知的MAC地址:00-00-5E-00-01-VRID}。所以,在一个虚拟路由器中,不管谁是 Master,对外都是相同的MAC和IP(称之为VIP)。客户端主机并不需要因 Master的改变而修改自己的路由配置。对它们来说,这种切换是透明的。

在一组虚拟路由器中,只有作为 Master的RRP路由器会一直发送VRRP广播包( VRRP Advertisement messages),此时 Backup不会抢占 Master当 Master不可用时,Backup就收不到来自 Master的广播包了,此时多台 Backup中优先级最高的路由器会抢占为 Master。这种抢占是非常快速的(可能只有1秒甚至更少),以保证服务的连续性。出于安全性考虑,VRRP数据包使用了加密协议进行了加密。

总结如下：
Keepalived高可用对之间是通过VRRP通信的。

1)VRRP,全称 Virtual Router Redundancy Protocol,中文名为虚拟路由冗余协议,VRRP的出现是为了解决静态路由的单点故障。

2)VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。

3)VRRP用IP多播的方式(默认多播地址(224.0.0.18))实现高可用对之间通信。

4)工作时主节点发包,备节点接包,当备节点接收不到主节点发的数据包的时候,就启动接管程序接管主节点的资源。备节点可以有多个,通过优先级竟选,但一般 Keepalived系统运维工作中都是一对。

5)VRRP使用了加密协议加密数据,但 Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。

Keepalived服务的工作原理:

Keepalived高可用对之间是通过VRRP进行通信的,ⅤRRP是通过竟选机制来确定主备的,主的优先级高于备,因此,工作时主会优先获得所有的资源,备节点处于等待状态,当主挂了的时候,备节点就会接管主节点的资源,然后顶替主节点对外提供服务。

在 Keepalived服务对之间,只有作为主的服务器会一直发送VRRP广播包,告诉备它还活着,此时备不会抢占主,当主不可用时,即备监听不到主发送的广播包时,就会启动相关服务接管资源,保证业务的连续性。接管速度最快可以小于1秒。

二、Keepalived高可用服务搭建准备

1、安装keepalived环境说明

2、安装Keepalived软件（在LB01和LB02上分别安装）

yum install ipvsadm keepalived -y

[root@lb01 ~]# rpm -qa keepalived
keepalived-1.3.5-6.el7.x86_64

3、启动Keepalived服务并检查

[root@lb01 ~]# systemctl enable keepalived.service

[root@lb01 ~]# systemctl start keepalived.service

[root@lb01 ~]# ps aux| grep keepalived |grep -v grep
root       1541  0.0  0.1 118676  1396 ?        Ss   22:06   0:00 /usr/sbin/keepalived -D
root       1542  0.0  0.3 122876  3120 ?        S    22:06   0:00 /usr/sbin/keepalived -D
root       1543  0.0  0.2 122876  2412 ?        S    22:06   0:00 /usr/sbin/keepalived -D
启动后有3个keepalived进程表示安装正确

4、keepalived配置文件说明

配置文件路径为：

[root@lb01 ~]# ls -l /etc/keepalived/keepalived.conf
-rw-r--r-- 1 root root 509 9月  19 22:04 /etc/keepalived/keepalived.conf

keepalived软件有3个主要功能，其中高可用部分的功能如下：
具备高可用功能的keepalived.conf配置文件包含了2个重要区块：
1）全局(Global Definitions)部分
这部分主要用来设置keepalived的故障通知机制和Route ID标识。示例代码如下：

[root@lb01 keepalived]# cat -n  /etc/keepalived/keepalived.conf
     1    ! Configuration File for keepalived
     2
     3    global_defs {
     4       notification_email {
     5         acassen@firewall.loc
     6         failover@firewall.loc
     7         sysadmin@firewall.loc
     8       }
     9       notification_email_from Alexandre.Cassen@firewall.loc
     10       smtp_server 127.0.0.1
     11       smtp_connect_timeout 30
     12       router_id lb01
     13     }

参数说明：
第1行是注释，！开头和#号开头一样，都是注释。
第3~8行是定义服务故障报警的Email地址，作用是当服务发生切换或RS节点等有故障时，发报警邮件。这几行时可选配置，notification_email指定在keepalived发生事件时需要发送的Email地址，可以有多个，每行一个。
第9行是指定发送邮件的发送人，即发件人地址，也是可选的配置。
第10行smtp_server指定发送邮件的smtp服务器，如果本机开启了sendmail和postfix，既可以使用上面默认配置实现邮件发送，也是可选配置。
第11行smtp_connect_timeout是连接smtp的超时时间，也是可选配置。
第12行是keepalived服务器的路由标识(route_id)。在同一个局域网内，这个标识是唯一的。
    大括号"{}",用来分隔区块，要成对出现。如果漏写了半个大括号，keepalived运行时不会报错，但也不会得到预期的结果，另外，由于区块间存在多层嵌套关系，因此很容易遗漏区块结尾处的大括号。
更多参数信息请执行man keepalived.conf获得。

2）VRRP实例定义区块(VRRP instance(s))部分
这部分主要用来定义具体服务的实例配置，包括keepalived准备状态、接口、优先级、认证方式和IP信息等，示例代码如下：

    15    vrrp_instance VI_1 {
    16        state MASTER
    17        interface eth0
    18        virtual_router_id 55
    19        priority 150
    20        advert_int 1
    21        authentication {
    22            auth_type PASS
    23            auth_pass 1111
    24        }
    25        virtual_ipaddress {
    26                    192.168.200.16
    27                    192.168.200.17
    28                    192.168.200.13
    29        }
    30    }

参数说明：
第15行表示定义一个vrrp_instance实例，名字是VI_1，每个vrrp_instance实例可以认为是keepalived服务的一个实例或者作为一个业务服务，在keepalived服务配置中，这样的vrrp_instance实例可以有多个。注意存在于主节点中的vrrp_instance实例在备节点中也要存在，这样才能实现故障切换接管。
第16行state MASTER表示当前实例VI_1的角色状态，当前角色为MASTER，这个状态只能有MASTER和BACKUP两种状态，并且需要大写这些字符，其中MASTER为正式工作的状态，BACKUP为备用的状态。当MASTER所在的服务器故障失效时，BACKUP所在的服务器会接管故障的MASTER继续提供服务。
第17行interface为网络通信接口，对外提供服务的网络接口，如eth0、eth1。
第18行virtual_router_id为虚拟路由ID标识，这个标识最好是一个数字并且要在一个keepalived.conf配置中是唯一的。但是MASTER和BACKUP配置中相同实例的virtual_router_id又必须是一致的，否则将出现脑裂问题。
第19行priority为优先级，其后面的数值也是一个数字，数字越大标识实例优先级越高。在同一个vrrp_instance实例里，MASTER的优先级配置要高于BACKUP的。若MASTER的priority值为150，那么BACKUP的priority必须小于150，一般建议隔50以上为佳，例如设置BACKUP的priority为100或更小的数值。
第20行advert_int为同步通知间隔，MASTER与backup之间通信检查的时间间隔，单位为秒，默认为1。
第21~24行authentication
为权限认证配置，包含认证类型(auth_type)和认证密码(auth_pass)。认证类型有PASS(Simple Passwd(suggested)、AH(IPSEC)(notrecommended))两种，官方推荐使用的类型为PASS。验证密码为明文方式，做好长度不要超过8个字符，建议用4位的数字，同一vrrp实例的MASTER与BACKUP使用相同的密码才能正常通信。
第25~29行virtual_ipaddress为虚拟IP地址。可以配置多个IP地址，每个地址占一行，配置时最好明确指定子网掩码以及虚拟IP绑定的网路接口。否则，子网掩码默认是32位，绑定的接口和前面的interface参数配置的一致。注意，这里的虚拟IP就是在工作中需要和域名绑定的IP，即和配置的高可用服务监听的IP要保持一致。

三、keepalived高可用配置

1、配置keepalived实现单实例单IP自动漂移接管
LB01 MASTER的keepalived.conf配置文件配置如下：

[root@lb01 keepalived]# cd /etc/keepalived/
[root@lb01 keepalived]# vim keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id lb01            #id为lb01，不同的keepalived.conf此ID要唯一;
}

vrrp_instance VI_1 {        #实例名为VI_1，相同实例的备节点名字要和这个相同;
    state MASTER            #状态为MASTER，备节点状态需要为BACKUP;
    interface ens33            #通信接口为ens33，此参数备节点设置和主节点相同;
    virtual_router_id 55    #实例ID为55，keepalived.conf里唯一;
    priority 150            #优先级为150，备节点的优先级必须比此数字低;
    advert_int 1            #通信检查间隔时间，默认为1秒;
    authentication {
        auth_type PASS        #PASS认证类型，此参数备节点设置和主节点相同;
        auth_pass 1111        #密码是1111，此参数备节点设置和主节点相同;
    }
    virtual_ipaddress {
        192.168.200.16/24 dev ens33 lable ens33:1
        #虚拟IP，即VIP为192.168.200.16，子网掩码为24位，绑定接口为ens33，别名为ens33:1，此参数备节点设置和主节点相同;
    }
    }
}

重启并查看是否有虚拟IP192.168.200.16

[root@lb01 keepalived]# systemctl restart keepalived.service
[root@lb01 ~]# ip add | grep 192.168.200.16
    inet 192.168.200.16/24 scope global ens33

LB02 BACKUP的keepalived.conf配置文件配置如下：

[root@lb02 ~]# cd /etc/keepalived/
[root@lb02 keepalived]# vim keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id lb02                #id为lb02;
}

vrrp_instance VI_1 {
    state BACKUP                #状态为BACKUP;
    interface ens33
    virtual_router_id 55
    priority 100                #优先级为100;
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16/24 dev ens33 lable ens33:1
    }
}

重启并查看是否有虚拟IP192.168.200.16

[root@lb02 keepalived]# systemctl restart keepalived.service
[root@lb02 keepalived]# ip add | grep 192.168.200.16
[root@lb02 keepalived]#

说明：因为主节点lb01活着的时候，lb02不会接管VIP192.168.200.16，如果lb02有VIP信息，说明高可用裂脑了，裂脑是2台服务器争抢同一资源导致的。
当2台服务器争抢同一IP资源时，一般要先考虑排查两个地方：
主备2台服务器之间是否通信正常，如果不正常是否有防火墙阻挡？
主备2台服务器对应的keepalived.conf配置文件是否有错误？例如，是否同一实例的virtual_route_id配置不一致。

进行高可用主备服务器切换
停掉主服务器上的keepalived服务或关闭主服务器，操作及检查步骤如下：
[root@lb01 ~]# systemctl stop keepalived.service
[root@lb01 ~]# ip add | grep 192.168.200.16
[root@lb01 ~]#
可以看到VIP192.168.200.16消失了，此时查看BACKUP备服务器，看是否会有VIP 192.168.200.16出现：
[root@lb02 keepalived]# ip add | grep 192.168.200.16
    inet 192.168.200.16/24 scope global ens33
可以看到备节点lb02已经接管绑定了192.168.200.16这个VIP，这期间备节点还会发送ARP广播，让所有的客户端更新本地的ARP表，以便客户端访问新接管VIP服务的节点。
此时如果再启动主服务器的keepalived服务，主服务器就会接管回VIP 192.168.200.16，启动后可以观察下主备的IP漂移情况，备服务器是否释放了IP？主服务器是否又接管了IP？
主节点启动keepalived服务后，发现很快就又接管了VIP 192.168.200.16，结果如下：
[root@lb01 ~]# systemctl start keepalived.service
[root@lb01 ~]# ip add | grep 192.168.200.16
    inet 192.168.200.16/24 scope global ens33
与此同时备节点上的VIP 192.168.200.16则被释放了，如下：
[root@lb02 keepalived]# ip add | grep 192.168.200.16
[root@lb02 keepalived]#
这样就实现了单实例keepalived服务IP自动漂移接管了，VIP漂移到了新机器新服务上，用户的访问请求自然就会找新机器新服务了。

四、keepalived高可用服务器的"裂脑"问题

1、什么是裂脑？

由于某些原因，导致两台高可用服务器对在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务器的所有权，而此时的两台高可用服务器都还活着并在正常运行，这样就会导致同一IP或服务在两端同时存在而发生冲突。最严重的是两台主机占用同一个VIP地址，当用户写入数据时可能会分别写入到两端，这可能会导致服务器两端的数据不一致或造成数据丢失，这种情况就被成为裂脑。

导致裂脑发生的原因
一般来说，裂脑的发生，有以下几种原因：
（1）高可用服务器对之间心跳线链路发生故障,导致无法正常通信。
    心跳线坏了(包括断了,老化)。
    网卡及相关驱动坏了,IP配置及冲突问题(网卡直连)。
    心跳线间连接的设备故障(网卡及交换机)。
    仲裁的机器出问题(采用仲裁的方案)。
（2）高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

（3）高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败。

（4）其他服务配置不当等原因,如心跳方式不同,心跳广播冲突、软件Bug等。
2、解决裂脑的常见方案
在实际生产环境中，我们可以从以下几个方面来防止裂脑问题的发生

1）同时使用串行电缆和以太网电缆连接，同时用2条心跳线路，这样一条线路坏了，另一条还是好的，依然能传送心跳消息。

2）当检测到裂脑时强行关闭一个心跳节点(这个功能需特殊设备支持,如 Stonith、fence)。相当于备节点接收不到心跳消息,通过单独的线路发送关机命令关闭主节点的电源。

3）做好对裂脑的监控报警(如邮件及手机短信等或值班),在问题发生时人为第一时间介入仲裁,降低损失。例如,百度的监控报警短信就有上行和下行的区别。报警信息发送到管理员手机上,管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器,让服务器根据指令自动处理相应故障,这样解决故障的时间更短。

当然,在实施高可用方案时,要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务,这个损失是可容忍的。

3、解决 Keepalived裂脑的常见方案
作为互联网应用服务器的高可用,特别是前端Web负载均衡器的高可用,裂脑的问题对普通业务的影响是可以忍受的,如果是数据库或者存储的业务,一般出现裂脑问题就非常严重了。因此,可以通过增加冗余心跳线路来避免裂脑问题的发生,同时加强对系统的监控,以便裂脑发生时人为快速介入解决问题。

如果开启防火墙,一定要让心跳消息通过,一般通过允许IP段的形式解决。

可以拉一条以太网网线或者串口线作为主被节点心跳线路的冗余。

开发监测程序通过监控软件(例如 Nagios)监测裂脑。

下面是生产场景检测裂脑故障的一些思路:

1)简单判断的思想:只要备节点出现VIP就报警,这个报警有两种情况,一是主机宕机了备机接管了;二是主机没宕,裂脑了。不管属于哪个情况,都进行报警,然后由人工查看判断及解决。

2)比较严谨的判断:备节点出现对应VIP,并且主节点及对应服务(如果能远程连接主节点看是否有VP就更好了)还活着,就说明发生裂脑了。

五、Keepalived双机双主模式配置

keepalived支持多实例多业务双向主备模式，即A业务在lb01上是主模式，在lb02上是备模式，而B业务在lb01上是备模式，在lb02上是主模式，具体配置如下：

在LB01上配置如下：

[root@lb01 keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id lb01
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 55
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16/24 dev ens33 lable ens33:1
    }
}

vrrp_instance VI_2 {
    state BACKUP
    interface ens33
    virtual_router_id 56
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.17/24 dev ens33 lable ens33:2
    }
}

在LB02上配置如下：

[root@lb02 keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id lb02
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 55
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16/24 dev ens33 lable ens33:1
    }
}

vrrp_instance VI_2 {
    state MASTER
    interface ens33
    virtual_router_id 56
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.17/24 dev ens33 lable ens33:2
    }
}

重启服务

systemctl restart keepalived.service

LB01重启keepalived服务后结果如下：
[root@lb01 keepalived]# ip add |egrep "192.168.200.16|192.168.200.17"
    inet 192.168.200.16/24 scope global ens33

LB02重启keepalived服务后结果如下：
[root@lb02 keepalived]# ip add |egrep "192.168.200.16|192.168.200.17"
    inet 192.168.200.17/24 scope global ens33

停掉任意一端服务器或者keepalived服务，查看VIP会不会漂移到另一端

停掉LB01上的keepalived服务结果如下：
[root@lb01 keepalived]# systemctl stop keepalived.service
[root@lb01 keepalived]# ip add |egrep "192.168.200.16|192.168.200.17"

查看LB02服务器上的VIP接管情况，结果如下：
[root@lb02 keepalived]# ip add |egrep "192.168.200.16|192.168.200.17"
    inet 192.168.200.17/24 scope global ens33
    inet 192.168.200.16/24 scope global secondary ens33

启动LB01上的keepalived服务后，很快就会接管回了自己的VIP。
[root@lb01 keepalived]# systemctl stop keepalived.service
[root@lb01 keepalived]# ip add |egrep "192.168.200.16|192.168.200.17"
    inet 192.168.200.16/24 scope global ens33

再次查看LB02上的VIP，结果如下：
[root@lb02 keepalived]# ip add |egrep "192.168.200.16|192.168.200.17"
    inet 192.168.200.17/24 scope global ens33

六、nginx负载均衡配合Keepalived服务案例实战

在LB01和LB02上分别安装nginx，并做如下配置：

nginx编译安装参考：https://www.cnblogs.com/Mr-Ding/p/9502529.html

[root@lb01 ~]# cat /application/nginx/conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream www_server_pools   {
        server 192.168.100.107:80   weight=1;
        server 192.168.100.108:80   weight=1;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
    }
    server {
        listen       192.168.200.16:80;
        server_name  www.dmtest.com;
        location / {
        proxy_pass http://www_server_pools;
	proxy_set_header Host $host;
    	proxy_set_header X-Forwarded-For $remote_addr;
        }

    location /status {
            check_status;

            access_log   off;
        }
    }
}

说明：上面的配置仅代理了www.dmtest.com域名。

keepalived单实例配置如下：

在LB01上配置如下：

[root@lb01 keepalived]# cd /etc/keepalived/
[root@lb01 keepalived]# vim keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id lb01            #id为lb01，不同的keepalived.conf此ID要唯一;
}

vrrp_instance VI_1 {        #实例名为VI_1，相同实例的备节点名字要和这个相同;
    state MASTER            #状态为MASTER，备节点状态需要为BACKUP;
    interface ens33            #通信接口为ens33，此参数备节点设置和主节点相同;
    virtual_router_id 55    #实例ID为55，keepalived.conf里唯一;
    priority 150            #优先级为150，备节点的优先级必须比此数字低;
    advert_int 1            #通信检查间隔时间，默认为1秒;
    authentication {
        auth_type PASS        #PASS认证类型，此参数备节点设置和主节点相同;
        auth_pass 1111        #密码是1111，此参数备节点设置和主节点相同;
    }
    virtual_ipaddress {
        192.168.200.16/24 dev ens33 lable ens33:1
        #虚拟IP，即VIP为192.168.200.16，子网掩码为24位，绑定接口为ens33，别名为ens33:1，此参数备节点设置和主节点相同;
    }
    }
}

在LB02上配置如下：

! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id lb02
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 55
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16/24 dev ens33 lable ens33:1
    }
}