目录
lvs+keepalive 工作原理及搭建
nginx应用场景
在实际使用，单机版的Nginx就不能满足高可用的要求了，在这种情况下，我们使用Nginx+Keepalived(双机热备)搭建一套高可用的环境，这就是本文的核心内容。
首先我们先了解一下Keepalived是什么
keepalive介绍
Keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。
Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议）功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件
Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。
keepalived工作原理
Keepalived本质就是为ipvs服务的，它也不需要共享存储。IPVS其实就是一些规则，Keepalived主要的任务就是去调用ipvsadm命令，来生成规则，并自动实现将用户需要访问的地址转移到可用LVS节点实现。所以keepalive的高可用是属于具有很强针对性的高可用，它和corosync这种通用性HA方案不同。
Keepalived的主要目的就是它自身启动为一个服务，它工作在多个LVS主机节点上，当前活动的节点叫做Master备用节点叫做Backup，Master会不停的向Backup节点通告自己的心跳，这种通告是基于VRRP协议的。Backup节点一旦接收不到Master的通告信息，它就会把LVS的VIP拿过来，并且把ipvs的规则也拿过来，在自己身上生效，从而替代Master节点。
Keepalived除了可以监控和转移LVS资源之外，它还可以直接配置LVS而不需要直接使用ipvsadm命令，因为它可以调用，也就是说在LVS+KEEPALIVED模型中，你所有的工作在Keepalived中配置就可以了，而且它还有对后端应用服务器健康检查的功能。
直接一句话Keepalived就是VRRP协议的实现，该协议是虚拟冗余路由协议。
VRRP工作原理简述
那么这个VRRP协议是干嘛用呢？传统上来说我们通过一个路由器上网，如果故障那就不能用了，如果使用2个路由器，有一个故障你就需要手动的设置客户端切换到另外的路由器上，或者使用ARP客户端也可以实现，但总之部署比较麻烦不利于管理，就像下图
有没有一种办法可以自动转移而省去手动配置呢？我们就可以通过VRRP协议来实现路由器的故障转移。如下图
这里有个问题，VRRP提供一个VIP，它可以来设定那个路由器是活动节点，然后出现故障进行切换，VIP也随之对应到新的路由器上，但是内网是用过MAC地址来寻址的，虽然VIP对应到了新的路由器上，可是MAC变了，客户端的ARP表也没有更新，所以还是用不了，为了解决这个问题VRRP不但提供VIP还提供VMAC地址，这个VMAC地址是VRRP单独申请的，大家都可以正常使用。
故障切换的时候虽然改变了后端路由器，但是由于客户端使用的是VIP和VMAC地址，这样就不会有任何影响了。
所以Keepalived就是在Linux系统上提供了VRRP功能，当然还提供了服务监控功能，比如监控后端服务器的健康检查、LVS服务可用性检查。
VRRP的工作过程是这样的：
- 虚拟路由器中的路由器根据优先级选举出Master，Master路由器通过发送免费ARP报文，将自己的虚拟MAC地址通告给与它连接的设备。
- Master路由器周期性发送VRRP报文，以公布自己的配置信息（优先级等）和工作状态
- 如果Master故障，虚拟路由器中的Backup路由器将根据优先级重新选举新的Master
- 虚拟路由器状态切换时，Master路由器由一台设备切换会另外一台设备，新的Master路由器只是简单的发送一个携带虚拟MAC地址和虚拟IP的免费ARP报文，这样就可以更新其他设备中缓存的ARP信息
- Backup路由器的优先级高于Master时，由Backup的工作方式（抢占式或者非抢占式）决定是否重新选举Master。
VRRP还支持认证，就是为了防止随意一个VRRP设备加入到当前的虚拟路由组离来，它提供无认证、简单8位字符串认证和MD5认证（该认证方式Keepalive不支持）。
keepalive软件结构
Keepalived启动后以后会有一个主进程Master，它会生成还有2个子进程，一个是VRRP Stack负责VRRP（也就是VRRP协议的实现）、一个是Checkers负责IPVS的后端的应用服务器的健康检查，当检测失败就会调用IPVS规则删除后端服务器的IP地址，检测成功了再加回来。当检测后端有失败的情况可以使用SMTP通知管理员。另外VRRP如果检测到另外一个Keepalive失败也可以通过SMTP通知管理员。
Control Plane：这个就是主进程，主进程的功能是分析配置文件，读取、配置和生效配置文件，指挥那2个子进程工作。
WatchDog：看门狗，这个是Linux系统内核的一个模块，它的作用是帮助主进程盯着那2个子进程，因为主进程并不负责具体工作，具体工作都是子进程完成的。如果子进程挂了，那Keepalived就不完整了，所以那2个子进程会定期的向主进程打开的一个内部Unix Socket文件写心跳信息。如果有某个子进程不写信息了，它就会重启子进程，主进程就是让WatchDog来监控子进程的。
开始搭建环境
准备工作：
192.168.16.128
192.168.16.129
两台虚拟机，服务器也行。安装好Nginx
安装Nginx
更新yum源文件：
rpm -ivh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
安装Nginx:
yum -y install nginx
操作命令：
systemctl start nginx; #启动Nginx
systemctl stop nginx; #停止Nginx
什么是高可用？
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。如果一个系统能够一直提供服务，那么这个可用性则是百分之百，但是天有不测风云。所以我们只能尽可能的去减少服务的故障。
解决的问题？
在生产环境上很多时候是以Nginx做反向代理对外提供服务，但是一天Nginx难免遇见故障，如：服务器宕机。当Nginx宕机那么所有对外提供的接口都将导致无法访问。
虽然我们无法保证服务器百分之百可用，但是也得想办法避免这种悲剧，今天我们使用keepalived来实现Nginx的高可用。
双机热备方案
这种方案是国内企业中最为普遍的一种高可用方案，双机热备其实就是指一台服务器在提供服务，另一台为某服务的备用状态，当一台服务器不可用另外一台就会顶替上去。
故障转移机制
Keepalived高可用服务之间的故障切换转移，是通过VRRP 来实现的。
在 Keepalived服务正常工作时，主 Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主 Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的 IP资源及服务。而当主 Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。
实现过程
安装keepalived
yum方式直接安装即可，该方式会自动安装依赖：
yum -y install keepalived
修改主机（192.168.16.128）keepalived配置文件
yum方式安装的会生产配置文件在/etc/keepalived下：
vi keepalived.conf
#检测脚本
vrrp_script chk_http_port {
script "/usr/local/src/check_nginx_pid.sh" #心跳执行的脚本，检测nginx是否启动
interval 2 #（检测脚本执行的间隔，单位是秒）
weight 2 #权重
}
#vrrp 实例定义部分
vrrp_instance VI_1 {
state MASTER # 指定keepalived的角色，MASTER为主，BACKUP为备
interface ens33 # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) 用ifconfig查看你具体的网卡
virtual_router_id 66 # 虚拟路由编号，主从要一直
priority 100 # 优先级，数值越大，获取处理请求的优先级越高
advert_int 1 # 检查间隔，默认为1s(vrrp组播周期秒数)
#授权访问
authentication {
auth_type PASS #设置验证类型和密码，MASTER和BACKUP必须使用相同的密码才能正常通信
auth_pass 1111
}
track_script {
chk_http_port #（调用检测脚本）
}
virtual_ipaddress {
192.168.16.130 # 定义虚拟ip(VIP)，可多设，每行一个
}
}
- virtual_ipaddress 里面可以配置vip,在线上通过vip来访问服务。
- interface需要根据服务器网卡进行设置通常查看方式ip addr
- authentication配置授权访问后备机也需要相同配置
- 修改备机（192.168.16.129）keepalived配置文件
keepalived.conf:
#检测脚本
vrrp_script chk_http_port {
script "/usr/local/src/check_nginx_pid.sh" #心跳执行的脚本，检测nginx是否启动
interval 2 #（检测脚本执行的间隔）
weight 2 #权重
}
#vrrp 实例定义部分
vrrp_instance VI_1 {
state BACKUP # 指定keepalived的角色，MASTER为主，BACKUP为备
interface ens33 # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) 用ifconfig查看你具体的网卡
virtual_router_id 66 # 虚拟路由编号，主从要一直
priority 99 # 优先级，数值越大，获取处理请求的优先级越高
advert_int 1 # 检查间隔，默认为1s(vrrp组播周期秒数)
#授权访问
authentication {
auth_type PASS #设置验证类型和密码，MASTER和BACKUP必须使用相同的密码才能正常通信
auth_pass 1111
}
track_script {
chk_http_port #（调用检测脚本）
}
virtual_ipaddress {
192.168.16.130 # 定义虚拟ip(VIP)，可多设，每行一个
}
}
检测脚本：
#!/bin/bash
#检测nginx是否启动了
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then #如果nginx没有启动就启动nginx
systemctl start nginx #重启nginx
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then #nginx重启失败，则停掉keepalived服务，进行VIP转移
killall keepalived
fi
fi
脚本授权:chmod 775 check_nginx_pid.sh
说明：脚本必须通过授权，不然没权限访问啊，在这里我们两条服务器执行、VIP(virtual_ipaddress:192.168.16.130),我们在生产环境是直接通过vip来访问服务。
模拟nginx故障：
修改两个服务器默认访问的Nginx的html页面作为区别。
首先访问192.168.16.130,通过vip进行访问，页面显示192.168.16.128；说明当前是主服务器提供的服务。
这个时候192.168.16.128主服务器执行命令：
systemctl stop nginx; #停止nginx
再次访问vip(192.168.16.130)发现这个时候页面显示的还是：192.168.16.128，这是脚本里面自动重启。
现在直接将192.168.16.128服务器关闭，在此访问vip(192.168.16.130)现在发现页面显示192.168.16.129这个时候keepalived就自动故障转移了，一套企业级生产环境的高可用方案就搭建好了。
keepalived中还有许多功能比如：邮箱提醒啊等等，就不操作了，可以去官网看看文档。
标签：lvs,keepalived,Keepalived,路由器,nginx,VRRP,Master,keepalive,搭建 From： https://www.cnblogs.com/liwenchao1995/p/17125252.html