LVS+Keepalived 高可用负载均衡集群

一. 高可用集群的相关知识

1.1 高可用（HA）集群和普通集群的比较

① 普通集群

���通的群集的部署是通过一台度器控制调配多台节点服务器进行业务请求的处理，但是仅仅是一台调度器，就会存在极大的单点故障风险，当该调度器的链路或则调度器本身出现故障时，就会导致整个业务的无法正常进行。

② 高可用集群

高可用集群是由一台主调度器和一台或多台备用调度器。在主调度器能够正常运转时，由主调度器进行节点服务器业务的分配处理，其余备用调度器处于待机状态，不参与当前的集群运转。当主调度器出现故障无法运转时，此时备用调度器会由优先级最高的调度承担主调度器的工作，而出现故障的主调调度器便会退出当前工作，由人工维修后返回集群。

两者比较后：高可用集群只需要在调度器上多进行一台或两台（服务器本身的价格比较昂贵，一般备用的服务器的数量会和当前业务创造的价值对等）的设置，就可避免因调度器瘫痪业务中断的风险，所以实现了真正的高可用的效果。

1.2 Keepalive 高可用方案

Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案，可以解决静态路由出现的单点故障问题。

在一个LVS服务集群中通常有主服务器（MASTER）和备份服务器（BACKUP）两种角色的服务器，但是对外表现为一个虚拟IP（VIP），主服务器会发送VRRP通告信息给备份服务器，当备份服务器收不到VRRP消息的时候，即主服务器异常的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。（主备服务器之间由优先级决定，优先级更高的充当主服务器，优先级低的成为备份服务器。）

1.3 Keepalive 基础

1.3.1 vrrp 技术

VRRP 相关术语

• 虚拟路由器：Virtual Router 不是真实存在 ，虚构出来的

• 虚拟路由器标识：VRID(0-255)，唯一标识虚拟路由器

• VIP：Virtual IP   

• VMAC：Virutal MAC (00-00-5e-00-01-VRID)

• 物理路由器：

• master：主设备

• backup：备用设备

• priority：优先级  0-255

  状态机    心跳线 1s

  1.3.2 VRRP 相关技术

  通告：心跳，优先级等；周期性

  工作方式：抢占式，非抢占式，延迟抢占模式，

  安全认证：

  • 无认证

  • 简单字符认证：预共享密钥

  • MD5

    工作模式：

    • 主/备：单虚拟路径器

    • 主/主：主/备（虚拟路由器1），备/主（虚拟路由器2）

      #通告：是宣告自己的主权，不要妄想抢班夺权，不停的向外#抢占式：主服务器宕机，过了一段时间修好了，再把主权抢过来#非抢占式：主服务器宕机，过了一段时间修好了，原来的主就作为备了#延迟抢占：主修好后，等待一定的时间（300s）后再次成为主#主/主：主/备（虚拟路由器1），备/主（虚拟路由器2）见下图：环境：有两台服务器虚拟出两台虚拟路由器第一台虚拟路由器中服务器1为主，服务器2为备，那么虚拟IP1就飘在服务器1上，真正工作的只有服务器1第二台虚拟路由器中服务器2为主，服务器1为备，那么虚拟IP2就飘在服务器2上，真正工作的只有服务器2优点：#提高了资源利用率：这样主，备服务器同时干活，可以同时运行两个项目#同样有备份功能：如果服务器1坏了，服务器2 将同时拥有虚拟IP1和虚拟IP2缺点：虽然有备份冗余功能但是对机器的性能要求非常高，当其中一台出现故障，本来一台运行一个任务，现在所有的业务全部压在了一台上，有十分大的风险

      1.4 Keepalived 的体系模块

      功能：

      • 基于vrrp协议完成地址流动

      • 为vip地址所在的节点生成ipvs规则(在配置文件中预先定义)

      • 为ipvs集群的各RS做健康状态检测

      • 基于脚本调用接口完成脚本中定义的功能，进而影响集群事务，以此支持nginx、haproxy等服务

        core模块：为 keepalived 的核心，负责主进程的启动、维护及全局配置文件的加载和解析。

        
        vrrp模块：是来实现VRRP协议的。（调度器之间的健康检查和主备切换）

        
        check模块：负责健康检查，常见的方式有端口检查及URL检查。（节点服务器的健康检查） 

        1.5 Keepalived 架构

        用户空间核心组件：

        1. vrrp stack：VIP消息通告 虚拟ip

        2. checkers：监测 real server（简单来说 就是监控后端真实服务器的服务）是否存活

        3. system call：实现 vrrp 协议状态转换时调用脚本的功能

        4. SMTP：邮件组件（报警邮件）

        5. IPVS wrapper：生成IPVS规则（直接生成 ipvsadm）

        6. Netlink Reflector：网络接口（将虚拟地址ip（vip）地址飘动）

        WatchDog：监控进程（整个架构是否有问题）

        • 控制组件：提供keepalived.conf 的解析器，完成Keepalived配置

        • IO复用器：针对网络目的而优化的自己的线程抽象

        • 内存管理组件：为某些通用的内存管理功能（例如分配，重新分配，发布等）提供访问权限

          1.6 Keepalived 实现原理

          由多台路由器组成一个热备组，通过共用的虚拟IP地址对外提供服务。

          每个热备组内同时只有一台主路由器提供服务，其他路由器处于冗余状态。

          若当前在线的路由器失效，则其他路由器会根据设置的优先级自动接替虚拟IP地址，继续提供服务。

          在配置时设置优先级，优先级高的那一方为 master。master节点承载着VIP地址。

          在一个LVS服务集群中通常有主服务器（MASTER）和备份服务器（BACKUP）两种角色的服务器，但是对外表现为一个虚拟IP，主服务器会发送VRRP通告信息给备份服务器，当备份服务器收不到VRRP消息的时候，即主服务器异常的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。

          主服务器作用：转发数据；发送报文告诉备服务器自己在线。

          备服务器作用：监听主服务器发来的数据；收不到消息的时候就接替主服务器。

          1.7 Keepalived 相关文件

          • 软件包名：keepalived

          • 主程序文件：/usr/sbin/keepalived

          • 主配置文件：/etc/keepalived/keepalived.conf

          • 配置文件示例：/usr/share/doc/keepalived/

          • Unit File：/lib/systemd/system/keepalived.service

          • Unit File的环境配置文件：/etc/sysconfig/keepalived CentOS

            1.7.1 配置组成

            /etc/keepalived/keepalived.conf 配置组成

            • GLOBAL CONFIGURATION

              Global definitions（全局配置）：定义邮件配置，route_id，vrrp配置，组播地址 等

              • VRRP CONFIGURATION

                VRRP instance(s)：定义 vrrp 协议中的每个 vrrp 虚拟路由器的规则，基本信息

                • LVS CONFIGURATION（lvs调度服务器的规则设置）

                  Virtual server group(s)

                  Virtual server(s)：LVS集群的VS和RS

                  1.7.2 全局配置

                  先安装软件

                  # /etc/keepalived/keepalived.conf global_defs { notification_email { root@localhost #keepalived 发生故障切换时邮件发送的目标邮箱，可以按行区分写多个 root@localhost  2860596835@qq.com  } notification_email_from keepalived@localhost   #发邮件的地址 smtp_server 127.0.0.1      #邮件服务器地址 smtp_connect_timeout 30    #邮件服务器连接timeout router_id R1 #每个keepalived主机唯一标识，建议使用当前主机名，但多节点重名不影响 vrrp_skip_check_adv_addr   #对所有通告报文都检查，会比较消耗性能，启用此配置后，如果收到的通告报文和上一个报文是同一个路由器，则跳过检查，默认值为全检查vrrp_strict #严格遵守VRRP协议,启用此项后以下状况将无法启动服务:1.无VIP地址 2.配置了单播邻居 3.在VRRP版本2中有IPv6地址，开启动此项并且没有配置 vrrp_iptables 时会自动开启iptables防火墙规则，默认导致VIP无法访问,建议不加此项配置。 vrrp_garp_interval 0  #gratuitous ARP messages 免费ARP报文发送延迟，0表示不延迟 vrrp_gna_interval 0  #unsolicited NA messages （不请自来）消息发送延迟 vrrp_mcast_group4 224.0.0.18  #指定组播IP地址范围：224.0.0.0到239.255.255.255,默认值：224.0.0.18  vrrp_iptables         #此项和vrrp_strict同时开启时，则不会添加防火墙规则,如果无配置vrrp_strict项,则无需启用此项配置}

                  地址分类：

                  自定义组播，一般都有规划，不能瞎配主和备要一样D类   224-239#修改组播默认keepalived主机之间利用多播相互通告消息，会造成网络拥塞，可以替换成单播，减少网络流量注意：启用 vrrp_strict 时，不能启用单播#在所有节点vrrp_instance语句块中设置对方主机的IP，建议设置为专用于对应心跳线网络的地址，而非使用业务网络

                  全局配置细讲

                  [root@localhost keepalived]#vim keepalived.confglobal_defs {   router_id HA_TEST_R2                  ####本路由器的服务器名称 HA_TEST_R2}vrrp_instance VI_1 {                     ####定义VRRP热备实列   state BACKUP                          ####热备状态，backup表示辅服务器   interface ens33                       ####表示承载VIP地址的物理接口   virtual_router_id 1                   ####虚拟路由器的ID号，每个热备组保持一致   priority 99                           ####优先级，优先级越大优先级越高   advert_int 1                          ####通告间隔秒数（心跳频率）   authentication {                      ####认证信息，每个热备组保持一致      auth_type PASS                     ####认证类型      auth_pass 123456                   ####认证密码   }   virtual_ipaddress {                   ####漂移地址（VIP），可以是多个      192.168.100.10   }}#需要修改项global_defs {   notification_email {     acassen@firewall.loc     failover@firewall.loc     sysadmin@firewall.loc   }   notification_email_from Alexandre.Cassen@firewall.loc   smtp_server 127.0.0.1   #修改邮箱指向自己（10行）   smtp_connect_timeout 30   router_id LVS_01   #指定服务器名称主备需要不一样（12行）   vrrp_skip_check_adv_addr   #vrrp_strict   #14行需要注释否则服务启动有问题   vrrp_garp_interval 0   vrrp_gna_interval 0}vrrp_instance VI_1 {    state MASTER    #指定服务器类型MASTER为主 BACKUP为备（20行）    interface ens33    #修改网卡名称为ens33（21）    virtual_router_id 10    #指定虚拟路由器的ID号主备需要一致    #nopreempt     #非抢占模式两个节点都需要配置去掉注释    priority 100    #设定优先级数字越大优先级越高，准备需要不一样    advert_int 1    #通告间隔（查看是否存活）    authentication {        auth_type PASS        #认证类型        auth_pass 123456        #修改验证密码，主备需要一样（27行）    }    virtual_ipaddress {        192.168.44.188        #指定群集vip地址    }}virtual_server 192.168.44.188 80 {    delay_loop 6    #健康间隔时间6秒    lb_algo rr    #调度算法轮询    lb_kind DR    #lvs模式为DR     persistence_timeout 0    #连接保持时间改为0 否则 无法体现效果    protocol TCP    #采用协议     real_server 192.168.44.10 80 { #43行修改地址为真实主机地址        weight 1        #45行删除        #节点权重        TCP_CHECK{            connect_port 80            #检查目标端口            connect_timeout 3            #连接超时             nb_get_retry 3            #重试次数            delay_before_retry 3            #重试间隔时间        }    } real_server 192.168.44.20 80 { #第二个        weight 1        TCP_CHECK{            connect_port 80            connect_timeout 3            nb_get_retry 3            delay_before_retry 3        }    }

                  1.7.3 配置虚拟路由器

                  vrrp_instance  {#为vrrp的实例名,一般为业务名称 配置参数 ...... }#配置参数：state MASTER|BACKUP#当前节点在此虚拟路由器上的初始状态，状态为MASTER或者BACKUPinterface IFACE_NAME #绑定为当前虚拟路由器使用的物理接口，如：eth0,bond0,br0,可以和VIP不在一个网卡virtual_router_id VRID #每个虚拟路由器惟一标识，范围：0-255，每个虚拟路由器此值必须唯一，否则服务无法启动，同属一个虚拟路由器的多个keepalived节点必须相同,务必要确认在同一网络中此值必须唯一priority 100 #当前物理节点在此虚拟路由器的优先级，范围：1-254，值越大优先级越高,每个keepalived主机节点此值不同advert_int 1#vrrp通告的时间间隔，默认1sauthentication { #认证机制 auth_type AH|PASS    #AH为IPSEC认证(不推荐),PASS为简单密码(建议使用) auth_pass   #预共享密钥，仅前8位有效，同一个虚拟路由器的多个keepalived节点必须一样}include    /etc/keealived/conf.d/*.confvirtual_ipaddress { #虚拟IP,生产环境可能指定上百个IP地址 / brd  dev  scope  label  192.168.200.100  #指定VIP，不指定网卡，默认为,注意：不指定/prefix,默认为/32 192.168.200.101/24 dev eth1    #指定VIP的网卡，建议和interface指令指定的岗卡不在一个网卡 192.168.200.102/24 dev eth2 label eth2:1  #指定VIP的网卡label }track_interface { #配置监控网络接口，一旦出现故障，则转为FAULT状态实现地址转移 eth0 eth1 …}

                  二. LVS + Keepalived 高可用群集

                  7-2 主服务器设置

                  做以下配置：

                  cd /etc/keepalived/cp keepalived.conf keepalived.conf.bakvim keepalived.conf......global_defs {#定义全局参数--10行--修改，邮件服务指向本地smtp_server 127.0.0.1--12行--修改，指定服务器（路由器）的名称，主备服务器名称须不同，主为LVS_01，备为LVS_02router_id LVS_01--14行--注释掉，取消严格遵守VRRP协议功能，否则VIP无法被连接#vrrp_strict} vrrp_instance VI_1 {#定义VRRP热备实例参数--20行--修改，指定热备状态，主为MASTER，备为BACKUP    state MASTER--21行--修改，指定承载vip地址的物理接口    interface ens33--23行--修改，指定优先级，数值越大优先级越高，这里设置主为100，备为80    priority 100    advert_int 1#通告间隔秒数(心跳频率)    authentication {#定义认证信息,每个热备组保持一致auth_type PASS#认证类型--27行--修改，指定验证密码（可以自定义），主备服务器保持一致        auth_pass 123123     }    virtual_ipaddress {#指定群集vip地址        192.168.44.188    }}--36行--修改，指定虚拟服务器地址(VIP)、端口，定义虚拟服务器和Web服务器池参数virtual_server 192.168.44.188 80 {    delay_loop 6#健康检查的间隔时间(秒)    lb_algo rr#指定调度算法，轮询(rr)--39行--修改，指定群集工作模式，直接路由(DR)    lb_kind DR    persistence_timeout 0#连接保持时间(秒)    protocol TCP#应用服务采用的是 TCP协议--43行--修改，指定第一个Web节点的地址、端口    real_server 192.168.44.30 80 {        weight 1#节点的权重--45行--删除，添加以下健康检查方式        TCP_CHECK {connect_port 80#添加检查的目标端口connect_timeout 3#添加连接超时(秒)nb_get_retry 3#添加重试次数delay_before_retry 3#添加重试间隔}} real_server 192.168.44.40 80 {#添加第二个 Web节点的地址、端口        weight 1        TCP_CHECK {connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}##删除后面多余的配置##}  systemctl start keepalivedip a#查看虚拟网卡vip

                  启动 ipvsadm 服务

                  7-1 从服务器配置

                  修改以下配置：

                  开启 ipvsadm

                  调整proc响应参数，关闭linux内核的重定向参数响应

                  7-3 节点服务器配置

                  添加测试页

                  设置回环虚拟网卡（VIP），添加静态路由

                  设置内核参数，响应参数以阻止更新VIP的MAC地址，避免发生冲突

                  关闭长连接

                  7-4 节点服务器配置

                  关闭长连接

                  客户机访问测试：

                  ① 客户机直接访问VIP地址，刷新网页观察是否存在负载均衡

                  ② 关闭DR主调度器 Keepalive服务，测试备调度器是否顶替

                  服务依旧存在，说明调度服务器已经顶替主调度服务器，服务并未中断

                  ③ 重新开启DR主调度服务，测试主调度是否抢占VIP

                  三.其他配置

                  1. 各种模式实验

                  抢占模式   非抢占模式   延时抢占模式

                  ① 默认抢占模式

                  ② 非抢占模式：

                  注意：要关闭 VIP抢占，必须将各 keepalived 服务器state配置为BACKUP

                  主 重启之后就变成了 备 不再抢回来

                  ③ 延时抢占

                  preempt_delay     指定抢占延迟时间为#s，默认延迟300s

                  注意：需要各keepalived服务器state为BACKUP,并且不要启用 vrrp_strict 

                  主

                  备

                  2.单播多播地址

                  修改多播

                  vrrp_mcast_group4 234.6.6.6

                  修改单播

                  主

                  备

                  抓包

                  3. 通知脚本

                  当前节点成为主节点时触发的脚本

                  notify_master |

                  当前节点转为备节点时触发的脚本

                  notify_backup |

                  当前节点转为“失败”状态时触发的脚本

                  notify_fault |

                  通用格式的通知触发机制，一个脚本可完成以上三种状态的转换时的通知

                  notify |

                  当停止VRRP时触发的脚本

                  notify_stop |

                  告警机制，出现意外自动运行脚本，发邮件提醒你

                     notify_master "/opt/keepalive.sh master"   notify_backup "/opt/keepalive.sh backup"   notify_fault "/opt/keepalive.sh fault"

                  #!/bin/bash#contact='940132245@qq.com'notify() { mailsubject="$(hostname) to be , vip floating" mailbody="$(date +'%F %T'): vrrp transition, $(hostname) changed to be " echo "$mailbody" | mail -s "$mailsubject" $contact}case  inmaster) notify master ;;backup) notify backup ;;fault) notify fault ;;*) echo "Usage: $(basename 
                  4. 日志功能
                  ) {master|backup|fault}" exit 1 ;;esac

                  可以模拟 master 故障

                  四.高可用群集的脑裂现象和预防措施

                  在配置文件添加以下内容

                  自定义日志位置

                  重启服务

                  查看日志

                  4.1 现象和原因

                  4.2 脑裂预防

                  现象：

                  在"双机热备"高可用（HA）系统中，当联系两个节点的"心跳线"断开时(即两个节点断开联系时)，本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点(即两个独立的个体)。由于相互失去了联系，都以为是对方出了故障，此时备用调度器会运转起来争做主调度器的工作，而主调度器依然保持着调度工作，两个调度的同时运转导致整个系统的紊乱。就会发生严重后果：（1）共享资源被瓜分、两边"服务"都起不来了.(2）或者两边"服务"都起来了，但同时读写"共享存储"，导致数据损坏（常见如数据库轮询着的联机日志出错）。

                  原因：

                  硬件原因： 

                  1. 高可用服务器各节点之间心跳线链路发生故障，导致无法正常通信。

                  2. 因心跳线坏了（包括断了，老化）。

                  3. 因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。

                  4. 因心跳线间连接的设备故障（网卡及交换机）。

                  5. 因仲裁的机器出问题（采用仲裁的方案）。

                  运用配置原因：

                  6. 高可用服务器上开启了 iptables 防火墙阻挡了心跳消息传输。

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

                  8. 其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等 

                  9. Keepalived 配置里同一VRRP实例如果 virtual_router_id 两端参数配置不一致也会导致裂脑问题发生。 

                  方式一：添加冗余的心跳线

                  针对脑裂现象的产生，运维人员第一时间要做的不是处理发生故障的调度器或则故障线路，而是首先确保业务不会因此中断，进行脑裂的预防尤为重要。出现问题，先保证业务的进行，再进行排障。

                  方式二：脚本配合周期任务计划检测，调度器自我裁决

                  添加冗余的心跳线支持HA多线路的进行，在多线路的加持下，一条线路故障后，也会有其余的线路也可传输心跳信息，让主备调度器继续保持正常运转。此方案可减少脑裂产生的概率。 

                  方式三：第三方工具，监控软件 

                  脑裂分析：产生脑裂的最主要最常见的原因是备调度器接收不到主调度器的的心跳信息。首先调度器大多数情况下都会是在统一局域网中，是通过网络来进行心跳信息的传送。所以心跳信息的检测可以基于icmp协议来进行检测

                  脚本思路：

                   如下图：若产生脑裂时我们需要探究的是通过脚本预测是1号线路的问题还是2号线路的问题 。所以本次脚本的编写只要能判断出哪条线路产生问题后，进行相应的裁决就可以在脑裂产生的第一时间免除其带来的影响

                  （1） 主调度器本身使用ping命令进行周期计划ping备用调度器，保证时刻畅通。

                  （2）采用条件判断语句，若主调调度器ping不通备调度器时，主调度器启用ssh服务远程借用节点服务器对备用调度器进行ping命令（可以多设置几台节点服务器ping，确保准确性）。若节点服务能ping通则说明问题出现在1号线路，主调度器进行自我裁决，让备调度器进行主调调度器的工作。若节点服务器也ping不通备调度器，说明问题出在了2号线路。

                  （3）可以在备调度器中也添加一个该方式的脚本，时刻ping主调度器。保证2号线出现问题时进行自我裁决。

                  （4）将主备调度器的脚本均添加周期计划任务中（crontab -e），进行合理的时间段检测。

                  方式四：启用磁盘锁 

                   

                  利用主流的监控软件，例如 zabbix。当两个节点出现分歧时，由第3方的仲裁者决定听谁的。这个仲裁者，可能是一个锁服务，一个共享盘或者其它什么东西。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。

                  五. 实现其它应用的高可用性 VRRP Script

                  正在服务一方锁住共享磁盘，"裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁"，另一方就永远得不到共享磁盘。现实中假如服务节点突然***机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即：正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。 

                  #!/bin/bashng=$(ps -elf |grep nginx |egrep -cv "grep|$$")if [ $ng -eq 0 ]thensystemctl stop keealivedfi直接用  killall -0 nginx  显示效果

                  keepalived 利用 VRRP Script 技术，可以调用外部的辅助脚本进行资源监控，并根据监控的结果实现优先动态调整，从而实现其它应用的高可用性功能。

                  5.1 VRRP Script 配置

                  vrrp_script  { script |   #此脚本返回值为非0时，会触发下面OPTIONS执行 OPTIONS }

                  定义脚本

                  vrrp_script：自定义资源监控脚本，vrrp实例根据脚本返回值，公共定义，可被多个实例调用，定义在vrrp实例之外的独立配置块，一般放在global_defs设置块之后。通常此脚本用于监控指定应用的状态。一旦发现应用的状态异常，则触发对MASTER节点的权重减至低于SLAVE节点，从而实现 VIP 切换到 SLAVE 节点

                  track_script { SCRIPT_NAME_1 SCRIPT_NAME_2}

                  调用脚本

                  track_script：调用vrrp_script定义的脚本去监控资源，定义在VRRP实例之内，调用事先定义的vrrp_script

                  5.2 定义VRRP Script

                  vrrp_script  { #定义一个检测脚本，在global_defs 之外配置     script | #shell命令或脚本路径(注意执行权限)     interval  #间隔时间，单位为秒，默认1秒     timeout  #超时时间     weight   #默认为0,如果设置此值为负数，当上面脚本返回值为非0时，会将此值与本节点权重相加可以降低本节点权重，即表示fall. 如果是正数，当脚本返回值为0，会将此值与本节点权重相加可以提高本节点权重，即表示 rise.通常使用负值     fall        #执行脚本连续几次都失败,则转换为失败，建议设为2以上     rise        #执行脚本连续几次都成功，把服务器从失败标记为成功     user USERNAME [GROUPNAME] #执行监测脚本的用户或组           init_fail         #设置默认标记为失败状态，监测成功之后再转换为成功状态}

                  操作：

                  nginx + keepalive

                  nginx 配置：

                  测试一下是否实现负载均衡和反向代理：

                  将 keepalive 和 nginx 使用

                  编写脚本

                  编写配置文件：

                  配置备服务器

                  重新启动服务

                  测试：

                  将主停掉

                  备顶上

                  测试：