Keepalived一开始就是为lvs设计的，解决了单点服务器的故障问题，能保证服务不中断、稳定运行。
LVS是一种集群(Cluster)技术：采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。工作在四层，在内核空间工作，基于ipvs模块，不占用流量。
一、 LVS概念
LVS（Linux Virtual Server），也就是Linux虚拟服务器, 是一个自由软件项目。使用LVS技术要达到的目标是：通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。
LVS主要用来做四层负载均衡。
二、 Keepalived概念
Keepalived是分布式部署系统解决系统高可用的软件，结合LVS（Linux Virtual Server）使用，其功能类似于heartbeat，解决单机宕机的问题。
Keepalived是以VRRP协议为实现基础的，VRRP全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议。通过VRRP协议结合LVS，对组群服务器监控情况，若master出现宕机情况，则将VIP漂移到backup机上。实现了分布式系统高可用。可以理解为：keepalived是LVS的管理软件，根据监控情况，将宕机服务器从ipvsadm移除掉。
Keepalived的诞生最初是为LVS ipvs（director）提供高可用性的，后来发展一个多功能、通用的轻量级高可用组件，可以为ipvs、nginx、haproxy等诸多服务提供高可用功能，主要应用在负载均衡调度器上，同时也可以检查后端各realserver的健康状态。
三、负载均衡
四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。
七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、dns等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器，七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。
四、搭建过程及测试
2.1 主机配置
主机名
ip
操作系统
软件
端口
lvs01
10.1.28.253
CentOS 7.0
lvs keepalived
8080
lvs02
10.1.28.70
CentOS 7.0
lvs keepalived
8080
Nginxsever01
10.1.28.30
CentOS 7.0
nginx
8080
Nginxsever01
10.1.28.40 CentOS 7.0 nginx 8080
2.3 搭建准备
2.3.1 关闭所有机器防火墙
[root@lvs01 ~]#systemctl stop firewalld.service
2.3.2 关闭防selinux
关闭所有服务器selinux，修改/etc/selinux/config，将SELINUX由enforcing设置为disabled，重启服务器。
2.4 ipvs安装
LVS无需安装，安装的是管理工具，第一种叫ipvsadm，第二种叫keepalive。ipvsadm是通过命令行管理，而keepalive读取配置文件管理。
分别在lvs01和lvs02执行如下操作：
[root@lvs01 ~]# yum -y install ipvsadm
2.4.1 把模块加载进系统
[root@lvs01 ~]#ipvsadm
2.5 keepalived安装
分别在lvs01和lvs02执行如下操作：
[root@lvs01 ~]# yum -y install keepalived
2.6 keepalived配置
! Configuration File for keepalived
global_defs {
router_id MASTER ## keepalived 服务器标识符，可以随意设定（ 貌似也是全局唯一 ）
}
vrrp_instance VI_1 { ## 定义一个名为 VI_1 的 VRRP 实例
state MASTER ## Keepalived 服务器角色，MASTER 为主、BACKUP 为备
interface eth0 ## 指定 HA 监测网络接口
virtual_router_id 51 ## 虚拟路由标识，同一个 VRRP 实例使用唯一的标识，主备必须一样
priority 100 ## 节点优先级，同一 VRRP 实例中 MASTER 的优先级必须大于 BACKUP
advert_int 1 ## MASTER / BACKUP 之间同步检查间隔时间，单位 秒
authentication { ## 节点之间通信验证类型、密码 ，同一 VRRP 实例中，MASTER / BACKUP 必须使用相同的密码才可以通信
auth_type PASS
auth_pass 123456
}
virtual_ipaddress { ## 虚拟 IP 地址，又称漂移 IP 。可以通过 ip add 在 MASTER 上查看是否绑定
10.1.28.123
}
}
virtual_server 10.1.28.123 8080 { ## 定义虚拟服务器
delay_loop 6 ## 定义健康检查时间间隔，单位 秒
lb_algo rr ## 负载均衡调度算法，支持 rr 、wrr 、lc 、wlc 、lblc 、sh 、dh 等
lb_kind DR ## LVS 负载均衡机制，支持 NAT 、TUN 、DR
persistence_timeout 120 ## 会话保持时间，单位 秒。提供动态页面 session 保持功能，同一 IP 该值时间内被持续分配到同一台节点服务器上
protocol TCP ## 转发协议类型，支持 TCP 、UDP
real_server 10.1.28.30 8080 { ## 定义节点服务器
weight 1 ## 节点权重值，数字越大权重越高，分配到的连接越多。主要用于后端节点服务器性能不统一
notify_down /etc/keepalived/real_down.sh ## 该节点服务器处于 DOWN 状态后执行的脚本
TCP_CHECK { ## 健康检测方式，支持 HTTP_GET 、SSL_GET 、TCP_CHECK 、SMTP_CHECK 、MISC_CHECK
connect_port 8080 ## 检测端口，不指定时默认为 real_server 指定的端口
connect_timeout 3 ## 无响应超时时间，单位 秒
nb_get_retry 3 ## 重试次数
delay_before_retry 3 ## 重试间隔，单位 秒
}
}
real_server 10.1.28.40 8080 { ## 第二台节点服务器
weight 1
notify_down /etc/keepalived/real_down.sh
TCP_CHECK {
connect_port 8080
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
lvs02配置
! Configuration File for keepalived
global_defs {
router_id lvs02
}
vrrp_instance VI_1 {
state BACKUP
interface ens160
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.1.28.123
}
}
virtual_server 10.1.28.123 8080 {
delay_loop 6
lb_algo rr
lb_kind DR
# persistence_timeout 50
protocol TCP
real_server 10.1.28.30 8080 {
weight 1
TCP_CHECK{
connetct_timeout 10
retry 3
delay_before_retry 3
connetct_port 8080
}
}
real_server 10.1.28.40 8080 {
weight 2
TCP_CHECK{
connetct_timeout 10
retry 3
delay_before_retry 3
connetct_port 8080
}
}
}
2.7 参数说明
IPVS三种IP负载均衡技术：
VS/NAT： 即（Virtual Server via Network Address Translation）
也就是网络地址翻译技术实现虚拟服务器，当用户请求到达调度器时，调度器将请求报文的目标地址（即虚拟IP地址）改写成选定的Real Server地址，同时报文的目标端口也改成选定的Real Server的相应端口，最后将报文请求发送到选定的Real Server。在服务器端得到数据后，Real Server返回数据给用户时，需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口，然后把数据发送给用户，完成整个负载调度过程。可以看出，在NAT方式下，用户请求和响应报文都必须经过Director Server地址重写，当用户请求越来越多时，调度器的处理能力将称为瓶颈。
VS/TUN：即（Virtual Server via IP Tunneling）
也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样，只是它的报文转发方法不同，VS/TUN方式中，调度器采用IP隧道技术将用户请求转发到某个Real Server，而这个Real Server将直接响应用户的请求，不再经过前端调度器，此外，对Real Server的地域位置没有要求，可以和Director Server位于同一个网段，也可以是独立的一个网络。因此，在TUN方式中，调度器将只处理用户的报文请求，集群系统的吞吐量大大提高。
VS/DR： 即（Virtual Server via Direct Routing）
也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样，但它的报文转发方法又有不同，VS/DR通过改写请求报文的MAC地址，将请求发送到Real Server，而Real Server将响应直接返回给客户，免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的，但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上，且真实服务器网络设备或设备别名不作 ARP 响应。
IPVS调度器实现了如下八种负载调度算法：
轮叫（Round Robin）
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
加权轮叫（Weighted Round Robin）
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
最少链接（Least Connections）
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
加权最少链接（Weighted Least Connections）
在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
基于局部性的最少链接（Locality-Based Least Connections）
"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
目标地址散列（Destination Hashing）
"目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
源地址散列（Source Hashing）
"源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
本例中采用DR负载均衡和wrr负载调度算法
3. 负载均衡及高可用测试
3.1 启动Keepalived
lvs01和lvs02分别执行：
[root@lvs01 ~]# service keepalived start
执行ip a，lvs01上有vip10.1.28.123，lvs02没有
3.2 页面访问
通过不同浏览器访问http://10.1.28.30:8080
3.3 Master上检查连接情况
lvs01上执行ipvsadm -ln:
3.4 ipvsadm参数说明
ipvsadm:
-L|-l（–list）：显示内核虚拟服务器表
-n（–numeric）：输出IP 地址和端口的数字形式
输出参数说明：
Forward 转发方式，当前是路由转发
Weight 权重
ActiveConn 当前活跃的连接数
InActConn 当前不活跃的连接数
3.5 修改keepalived参数
通过ipvsadm命令发现访问请求都被分配到92（nginx02）这台服务器，没有实现负载均衡。这个和keepalived参数配置persistence_timeout有关，这个参数的意义是保持客户端的请求在这个时间段内全部发到同一个真实服务器。
分别注释lvs01和lvs02的persistence_timeout：
[root@lvs01 keepalived]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak
[root@lvs01 keepalived]# view /etc/keepalived/keepalived.conf #persistence_timeout 50
重启两台lvs服务器keepalived服务：
[root@lvs01 keepalived]# service keepalived restart
再次测试：
发现连接均匀的分配到后台两台nginx服务器。
3.5.5 lvs高可用测试
恢复keepalived配置并重启服务。
lvs01宕机前访问页面：
停止lvs01的keepalived服务，模拟lvs01宕机：
systemctl stop keepalived
查看lvs02情况：
发现vip已飘至lvs02。
http://10.1.28.123:8080，访问正常：
恢复lvs01的keepalived服务：
发现vip飘回至lvs01，vip页面访问正常
五、 lvs故障排错思路
5.1 导致负载不均衡的原因
q LVS自身的会话保持参数设置（-p 300），优化：大公司常用cookies代替session
q LVS调度算法设置，如rr、wrr、wlc、lc
q 后端RS节点的会话保持参数，如apache的keepalived参数
q 用户发送请求时间短，请求资源的大小
5.2 排错思路
q 调度器上LVS调度规则及IP的正确性
q RS节点上VIP绑定和arp的抑制检查
vip绑定处理方案：
对RS绑定的VIP做实时监控
把RS绑定的VIP 做成配置文件，/etc/sysconfig/network-scripts/ifcfg-lo:0
arp抑制处理方案：
如果是单个VIP，则可以用stop传参设置0
若果RS有多个VIP绑定，即使stop也一定不要设置为0
q RS节点上自身提供服务的检查（DR不能进行端口转换）
q 利用辅助工具tcpdump、ping等进行排查
总结：
当 MASTER 服务器无法提供服务时，VIP 会在 MASTER 上自动移除，BACKUP 服务器会提升为 MASTER 状态，绑定 VIP 、接管服务。
当 MASTER 修复加入网络后，会自动抢回 VIP ，成为 MASTER 身份。
文章摘自网络，有数据吧整理发布