高可用服务-Keepalived

高可用服务-Keepalived

1. 什么是Keepalived

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

Keepalived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障问题的，他能够保证当个别节点宕机时，整个网络可以不间断地运行。所以，Keepalived一方面具有配置管理LVS的功能，同时还具有对LVS下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用功能。

2. Keepalived服务的三个应用场景

2.1 管理LVS负载均衡软件

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

2.2 实现对LVS集群节点健康检查功能

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

2.3 作为系统网络服务的高可用功能

Keepalived可以实现任意两台主机之间，例如Master和Backup主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是LVS负载均衡，Nginx反向代理这样的服务器。

Keepalived高可用功能实现的简单原理为，两台主机同时安装好Keepalived软件并启动服务，开始正常工作时，由角色为Master的主机获得所有资源并对用户提供服务，角色为Backup的主机作为Master主机的热备；当角色为Master的主机失效或出现故障时，角色为Backup的主机将自动接管Master主机的所有工作，包括接管VIP资源及相应资源服务；而当角色为Master的主机故障修复后，又会自动接管回它原来处理的工作，角色为Backup的主机则同时释放Master主机失效时它接管的工作，此时，两台主机将恢复到最初启动时各自的原始角色及工作状态。

3. 了解VRRP虚拟路由器冗余协议

3.1 VRRP的出现背景

局域网中的用户终端通常采用配置一个默认网关的形式访问外部网络，如果默认网关设备发生故障，那么所有用户终端访问外部网络的流量将会中断。可以通过部署多个网关的方式来解决单点故障，但是需要解决多个网关之间的冲突问题。VRRP的出现既能够实现网关的备份，又能解决多个网关之间互相冲突的问题，从而提高网络可靠性。

3.2 VRRP的工作原理

VRRP为每一个组抽象出一台虚拟“路由器”（Virtual Router），该路由器并非真实存在的物理设备，而是由VRRP虚拟出来的逻辑设备。一个VRRP组只会产生一台虚拟路由器，虚拟路由器拥有自己的IP地址以及MAC地址。

“Master路由器” 在一个VRRP组中承担报文转发任务。在每一个VRRP组中，只有Master路由器才会响应针对虚拟IP地址的ARP Request。Master路由器会以一定的时间间隔周期性地发送VRRP报文，以便通知同一个VRRP组中的Backup路由器关于自己的存活情况。

Backup路由器将会实时侦听Master路由器发送出来的VRRP报文，它随时准备接替Master路由器的工作。选举Master路由器和Backup路由器的依据是靠优先级。

4. Keepalived高可用故障切换转移原理

1. Keepalived高可用服务之间的故障切换转移，是通过VRRP（虚拟路由器冗余协议）来实现的。
2. 在Keepalived服务正常工作时，主Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着。
3. 当主Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的IP资源及服务，保证业务的连续性，接管速度最快可以小于1秒。
4. 而当主Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

5. 配置Keepalived实现单实例VIP自动漂移

5.1 环境准备

主机	IP	角色
lb01	10.0.0.5	Master（Nginx主负载均衡器）
lb02	10.0.0.6	Backup（Nginx备负载均衡器）
web01	10.0.0.7
web01	10.0.0.8

5.2 安装服务

#lb01、lb02
yum install nginx keepalived -y

#web01、web02
yum install nginx -y

5.3 配置负载均衡

先在web01、web02修改配置，创建测试文件

#web01
[root@web01 ~]# mkdir -p /app/code/test
[root@web01 ~]# echo web01 www.yinjay.com > /app/code/test/index.html
[root@web01 ~]# cat /etc/nginx/conf.d/www.yinjay.com.conf
server {
    listen 80;
    server_name www.yinjay.com;
    root /app/code/test;

    location / {
        index index.html;
    }

}
[root@web01 ~]# systemctl start nginx
[root@web01 ~]# systemctl enabled nginx


#web02
[root@web02 ~]# mkdir -p /app/code/test
[root@web02 ~]# echo web02 www.yinjay.com > /app/code/test/index.html
[root@web02 ~]# cat /etc/nginx/conf.d/www.yinjay.com.conf
server {
    listen 80;
    server_name www.yinjay.com;
    root /app/code/test;

    location / {
        index index.html;
    }

}
[root@web02 ~]# systemctl start nginx
[root@web02 ~]# systemctl enabled nginx

lb01、lb02配置

#lb01
[root@lb01 ~]# cat /etc/nginx/conf.d/lb01.conf
upstream lb_pools {
   server 172.16.1.7:80;
   server 172.16.1.8:80;

}

server {
   listen 80;
   server_name www.yinjay.com;

   location / {
       proxy_pass http://lb_pools;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $http_host;
   }

}
[root@lb01 ~]# systemctl start nginx
[root@lb01 ~]# systemctl enable nginx
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.



#lb02
[root@lb02 ~]# cat /etc/nginx/conf.d/lb02.conf
upstream lb_pools {
   server 172.16.1.7:80;
   server 172.16.1.8:80;

}

server {
   listen 80;
   server_name www.yinjay.com;

   location / {
       proxy_pass http://lb_pools;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $http_host;
   }

}
[root@lb02 ~]# systemctl start nginx
[root@lb02 ~]# systemctl enable nginx
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

5.4 Keeplived配置文件详解

/etc/keepalived/keepalived.conf 配置文件，主要分为三部分：全局定义部分、VRRP实例部分、LVS管理部分。

全局定义部分

这部分主要用来设置Keepalived的故障通知机制和Router ID标识。

• 第1行是注释，！开头和#号开发一样，都是注释。
• 第2行是空行。
• 第4~8行是定义服务故障报警的Email地址。作用是当服务发生切换或RS节点等有故障时，发报警邮件。这几行是可选配置，notification_email指定在Keepalived发生事件时，需要发送的Email地址，可以有多个，每行一个。
• 第9行是指定发送邮件的发送人，即发件人地址，也是可选的配置。
• 第10行smtp_server指定发送邮件的smtp服务器，如果本机开启了sendmail或postfix，就可以使用上面默认配置实现邮件发送，也是可选配置。
• 第11行smtp_connect_timeout是连接smtp的超时时间，也是可选配置。
• 第12行是Keepalived服务器的路由标识（router_id）.在一个局域网内，这个标识（router_id）应该是唯一的。

  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 192.168.200.1
 11    smtp_connect_timeout 30
 12    router_id LVS_DEVEL
 }

VRRP实例部分

• 第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，th1。当前主流的服务器都有2~4个网络接口，在选择服务接口时，要搞清楚了。
• 第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（not recommended））两种，官方推荐使用的类型为PASS。验证密码为明文方式，最好长度不要超过8个字符，建议用4位数字，同一vrrp实例的MASTER与BACKUP使用相同的密码才能正常通信。
• 第25 ~ 29 行virtual_ipaddress为虚拟IP地址。可以配置多个IP地址，每个地址占一行，配置时最好明确指定子网掩码以及虚拟IP绑定的网络接口。否则，子网掩码默认是32位，绑定的接口和前面的interface参数配置的一致。注意，这里的虚拟IP就是在工作中需要和域名绑定的IP，即和配置的高可用服务监听的IP要保持一致！

 15 vrrp_instance VI_1 {
 16     state MASTER
 17     interface eth0
 18     virtual_router_id 51
 19     priority 100
 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.18
 29     }

Tips：大括号“{}”。用来分隔区块，要成对出现。如果漏写了半个大括号，Keepalived运行时，不会报错，但也不会得到预期的结果。另外，由于区块间存在多层嵌套关系，因此很容易遗漏区块结尾处的大括号，要特别注意。

5.5 修改Keepalived配置文件

下面是示例

#全局定义部分
global_defs {
     router_id xxx    #每个keepalived软件都有一个独立的名字，名字不要冲突。
}

#VRRP实例部分
vrrp_instance lb_test { #lb_01为vrrp实例名字，要在一对主备之间保持一致。
     state MASTER     #主（MASTER）、备（BACKUP）
     interface eth0   #指定网卡，虚拟IP（VIP）在哪张网卡上创建
     virtual_router_id 10  #VRRP组ID，在同一主备之间要一致
     priority 100     #优先级
     advert_int 1     #心跳间隔，多久发送存活状态
     
     authentication {         #认证部分使用默认即可
           auth_type PASS     #使用简单认证
           auth_pass 123456   #设置密码
     }
     
     virtual_ipaddress {      #vip虚拟IP
           10.0.0.10/24 dev eth0 label eth0:1
     }
}

lb01修改

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-01

}

vrrp_instance lb_test {

     state MASTER
     interface eth0
     virtual_router_id 10
     priority 100
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }

}

lb02修改

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-02

}

vrrp_instance lb_test {

     state BACKUP
     interface eth0
     virtual_router_id 10
     priority 50
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }

}

lb01、lb02启动服务

systemctl start keepalived

5.6 抓包以及测试功能

首先进行抓包，能看到主为10.0.0.5在向组播进行通告自己还存活，报文中携带配置中的信息。

在宿主机进行添加一条host记录 10.0.0.10 www.yinjay.com，然后进行浏览器访问

此时lb01是主，所以VIP在lb01上，查看网卡详细信息与抓包内容相对应

5.7 模拟故障

此时模拟lb01服务挂掉，看lb02是否自动接管，现在进行抓包，然后停止lb01的keepalived服务。一秒切换，同时能看出发包的源MAC已改变。

在lb02上进行查看网卡详细信息，VIP已经漂移过来了。

现在在lb01上重新启动keepalived看看报文情况和网卡详细信息，lb01会广播免费ARP来刷新ARP表项，也就是告诉后端节点说我的VIP已经在lb01上啦，查看lb01上网卡详细信息，VIP也重新漂移了过来。

6. Keepalived高的“脑裂”问题

6.1 什么是脑裂

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

6.2 什么情况会出现脑裂

脑裂的发生，一般有以下几种原因：

• 高可用服务器对之间心跳线链路发生故障，导致无法正常通信。
• 心跳线坏了（包括断了，老化）
• 网卡及相关驱动坏了，IP配置及冲突问题（网卡直连）。
• 心跳线间连接的设备故障（网卡及交换机）
• 仲裁的机器出问题（采用仲裁的方案）
• 高可用服务器上开启了iptables防火墙阻挡了心跳消息传输
• 高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败。
• 其他服务配置不当等原因，如心跳方式不同，心跳广播冲突，软件BUG等。

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

6.3 解决Keepalived裂脑的常见方案

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

• 如果开启防火墙，一定要让心跳消息通过，一般通过允许IP段的形式解决。
• 可以拉多一条以太网网线作为主背节点心跳线路的冗余。
• 开发检测程序通过监控软件（例如Nagios）检测裂脑。

生产场景检测裂脑故障的一些思路

• 简单判断的思想：只要备节点出现VIP就报警，这个报警有两种情况，一是主机宕机了备机接管了；二是主机没宕，裂脑了。不管属于哪个情况，都进行报警，然后由人工查看判断及解决。
• 比较严谨的判断：备节点出现对应VIP，并且主节点及对应服务（如果能远程连接主节点看是否有VIP就更好了）还活着，就说明发生裂脑了。

7.案例：keepalived监控nginx

需要书写脚本，监控nginx端口/进程，如果端口或进程不存在，nginx挂了（lb01）同时关闭keepalived即可，最好再写一个告警功能，让运维人员能最快发现问题所在。

编写脚本

[root@lb01 ~]# cat /server/scripts/check_nginx.sh
#!/bin/bash

#检查端口是否存在，通过个数判断
count=`ss -lntup | grep nginx | wc -l`

#如果端口数量为0，则关闭Keepalived
if [ $count -eq 0 ];then
    systemctl stop keepalived
fi

#赋予权限
[root@lb01 ~]# chmod +x /server/scripts/check_nginx.sh

修改keepalived配置文件

示例

#放在vrrp_instance 实例上面
vrrp_script check_nginx {                  #check_nginx名字给脚本起个命令(keepalived使用)
   script /server/scripts/check_nginx.sh   #指定脚本路径,要有执行权限。
   interval 1                              #执行脚本的间隔,默认1秒
   timeout 30                              #脚本执行的超时时间，一般用于curl/wget等操作
   weight 1                                #权重(优先级) 如果仅仅1个脚本，可以忽略。一般用于keepalived中有多个监控脚本。
} 

#放在与在vrrp_instance实例里面并列
track_script {
   check_nginx
}

lb01上修改keepalived的配置文件

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-01

}

vrrp_script check_nginx {
     script /server/scripts/check_nginx.sh
     interval 1
     timeout 30
     weight 1

}

vrrp_instance lb_test {

     state MASTER
     interface eth0
     virtual_router_id 10
     priority 100
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }

     track_script {
           check_nginx
     }
}

重新加载keepalived配置文件，并停止nginx服务，看是否会自动关闭keepalived，VIP自动漂移。实验结束，已经自动VIP漂移。

8. 实现VIP非抢占式

VIP非抢占式：防止发生故障的时候与故障恢复的时候VIP飘来飘去。在keepalived监控nginx案例上进行下面配置，修改lb01、lb02的keepalived配置。

9.实现双实例双主模式

Keepalived还支持多实例多业务双向主备模式，即A业务在lb01上是主模式，在lb02上是备模式，而B业务在lb01上是备模式，在lb02上是主模式，具体实现就看下面lb01、lb02的配置。

lb01的keepalived配置

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-01

}

vrrp_instance lb_test {

     state MASTER
     interface eth0
     virtual_router_id 10
     priority 100
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }
     
}

vrrp_instance new_instance {

     state BACKUP
     interface eth0
     virtual_router_id 20
     priority 50
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 12345678
     }

     virtual_ipaddress {
           10.0.0.20/24 dev eth0 label eth0:1
     }
}

lb02的keepalived配置

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-02

}

vrrp_instance lb_test {

     state BACKUP
     interface eth0
     virtual_router_id 10
     priority 50
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }
     
}

vrrp_instance new_instance {

     state MASTER
     interface eth0
     virtual_router_id 20
     priority 100
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 12345678
     }

     virtual_ipaddress {
           10.0.0.20/24 dev eth0 label eth0:1
     }
}

实现效果

10.解决多组Keepalived在同一网络可能出现的问题

当在同一个局域网内部署了多组Keepalived服务器对，而又未使用专门的心跳线通信时，可能会发生高可用接管的严重故障问题。VRRP协议默认通过IP多播的形式实现高可用对之间的通信，如果同一个局域网内存在多组Keepalived服务器对，就会造成IP多播地址冲突问题，导致接管错乱，不同组的Keepalived都会使用默认的224.0.0.18作为多播地址。此时的解决办法是，在同组的Keepalived服务器所有的配置文件里指定独一无二的多播地址，配置如下：

global_defs {

router_id test
vrrp_mcast_group4 224.0.0.19    #这个就是指定多播地址的配置

}

#提示：不同实例的通信认证密码也最好不同，以确保接管正常。

11. 设置单播心跳检测

lb01的配置

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-01
}

vrrp_instance lb_test {

     state MASTER
     interface eth0
     virtual_router_id 10
     priority 100
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456

     }

     unicast_src_ip 10.0.0.5
     unicast_peer {
           10.0.0.6
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }

}


}

lb02的配置

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf
global_defs {

     router_id keepalived-02

}

vrrp_instance lb_test {

     state BACKUP
     interface eth0
     virtual_router_id 10
     priority 50
     advert_int 1

     authentication {
           auth_type PASS
           auth_pass 123456
     }

     unicast_src_ip 10.0.0.6
     unicast_peer {
           10.0.0.5
     }

     virtual_ipaddress {
           10.0.0.10/24 dev eth0 label eth0:1
     }



}

附录

keepalived配置文件其他参数详解

# 全局配置
global_defs {
   # 邮件通知信息
   notification_email {
     # 定义收件人
     acassen@firewall.loc
   }
   # 定义发件人
   notification_email_from Alexandre.Cassen@firewall.loc
   # SMTP服务器地址
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   # 路由器标识，一般不用改，也可以写成每个主机自己的主机名
   router_id LVS_DEVEL
   # VRRP的ipv4和ipv6的广播地址，配置了VIP的网卡向这个地址广播来宣告自己的配置信息，下面是默认值
   vrrp_mcast_group4 224.0.0.18
   vrrp_mcast_group6 ff02::12
}

# 定义用于实例执行的脚本内容，比如可以在线降低优先级，用于强制切换
vrrp_script SCRIPT_NAME {

}

# 一个vrrp_instance就是定义一个虚拟路由器的，实例名称
vrrp_instance VI_1 {
    # 定义初始状态，可以是MASTER或者BACKUP
    state MASTER
    # 工作接口，通告选举使用哪个接口进行
    interface ens33
    # 虚拟路由ID，如果是一组虚拟路由就定义一个ID，如果是多组就要定义多个，而且这个虚拟
    # ID还是虚拟MAC最后一段地址的信息，取值范围0-255
    virtual_router_id 51
    # 使用哪个虚拟MAC地址
    use_vmac XX:XX:XX:XX:XX
    # 监控本机上的哪个网卡，网卡一旦故障则需要把VIP转移出去
    track_interface {
        eth0
        ens33
    }
    # 如果你上面定义了MASTER,这里的优先级就需要定义的比其他的高
    priority 100
    # 通告频率，单位为秒
    advert_int 1
    # 通信认证机制，这里是明文认证还有一种是加密认证
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 设置虚拟VIP地址，一般就设置一个，在LVS中这个就是为LVS主机设置VIP的，这样你就不用自己手动设置了
    virtual_ipaddress {
        # IP/掩码 dev 配置在哪个网卡
        192.168.200.16/24 dev eth1
        # IP/掩码 dev 配置在哪个网卡的哪个别名上
        192.168.200.17/24 dev label eth1:1
    }
    # 虚拟路由，在需要的情况下可以设置lvs主机 数据包在哪个网卡进来从哪个网卡出去
    virtual_routes {
        192.168.110.0/24 dev eth2
    }
    # 工作模式，nopreempt表示工作在非抢占模式，默认是抢占模式 preempt
    nopreempt|preempt
    # 如果是抢占默认则可以设置等多久再抢占，默认5分钟
    preempt delay 300
    # 追踪脚本，通常用于去执行上面的vrrp_script定义的脚本内容
    track_script {

    }
    # 三个指令，如果主机状态变成Master|Backup|Fault之后会去执行的通知脚本，脚本要自己写
    notify_master ""
    notify_backup ""
    notify_fault ""
}

# 定义LVS集群服务，可以是IP+PORT；也可以是fwmark 数字，也就是防火墙规则
# 所以通过这里就可以看出来keepalive天生就是为ipvs而设计的
virtual_server 10.10.10.2 1358 {
    delay_loop 6
    # 算法
    lb_algo rr|wrr|lc|wlc|lblc|sh|dh 
    # LVS的模式
    lb_kind NAT|DR|TUN
    # 子网掩码，这个掩码是VIP的掩码
    nat_mask 255.255.255.0
    # 持久连接超时时间
    persistence_timeout 50
    # 定义协议
    protocol TCP
    # 如果后端应用服务器都不可用，就会定向到那个服务器上
    sorry_server 192.168.200.200 1358

    # 后端应用服务器 IP PORT
    real_server 192.168.200.2 1358 {
        # 权重
        weight 1
        # MSIC_CHECK|SMTP_CHEKC|TCP_CHECK|SSL_GET|HTTP_GET这些都是
        # 针对应用服务器做健康检查的方法
        MISC_CHECK {}
        # 用于检查SMTP服务器的
        SMTP_CHEKC {}

        # 如果应用服务器不是WEB服务器，就用TCP_CHECK检查
        TCP_CHECK {
          # 向哪一个端口检查，如果不指定默认使用上面定义的端口
          connect_port <PORT>
          # 向哪一个IP检测，如果不指定默认使用上面定义的IP地址
          bindto <IP>
          # 连接超时时间
          connect_timeout 3
        }

        # 如果对方是HTTPS服务器就用SSL_GET方法去检查，里面配置的内容和HTTP_GET一样
        SSL_GET {}

        # 应用服务器UP或者DOWN，就执行那个脚本
        notify_up "这里写的是路径，如果脚本后有参数，整体路径+参数引起来"
        notify_down "/PATH/SCRIPTS.sh 参数"

        # 使用HTTP_GET方法去检查
        HTTP_GET {
            # 检测URL
            url { 
              # 具体检测哪一个URL
              path /testurl/test.jsp
              # 检测内容的哈希值
              digest 640205b7b0fc66c1ea91c463fac6334d
              # 除了检测哈希值还可以检测状态码，比如HTTP的200 表示正常，两种方法二选一即可
              status_code 200
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            # 向哪一个端口检查，如果不指定默认使用上面定义的端口
            connect_port <PORT>
            # 向哪一个IP检测，如果不指定默认使用上面定义的IP地址
            bindto <IP>
            # 连接超时时间
            connect_timeout 3
            # 尝试次数
            nb_get_retry 3
            # 每次尝试之间间隔几秒
            delay_before_retry 3
        }
    }

    real_server 192.168.200.3 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

Tips：其余详细案例可看 https://blog.csdn.net/xili2532/article/details/127067331