keepalived实现高可用

1.高可用介绍

1.1）什么是高可用
	简单理解：出现故障，自动恢复，对于用户而言无感知。
	专业理解：减少系统不能对外提供服务的时间。4个9 5个9。

1.2）为什么要设计高可用?

2.高可用实现手段?

2.1）硬件
2.2）软件 keepalived     基于VRRP协议来实现。VRRP虚拟路由冗余协议，主要用来解决单点故障问题。

3.vrrp虚拟路由冗余协议

3.1）vrrp诞生过程
3.2）vrrp实现原理

VRRP 协议，全称 Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP 的出现就是为了解决静态路由的单点故障问题，VRRP 协议是通过一种竞选机制来将路由的任务交给某台 VRRP 路由器的。VRRP 协议早期是用来解决交换机、路由器等设备单点故障的。

1）VRRP 原理描述（同样适用于 Keepalived 的工作原理）
在一组 VRRP 路由器集群中，有多台物理 VRRP 路由器，但是这多台物理的机器并不是同时工作的，而是由一台称为 MASTER 的机器负责路由工作，其他的机器都是 BACKUP。MASTER 角色并非一成不变，VRRP 协议会让每个 VRRP 路由参与竞选，最终获胜的就是 MASTER。MASTER 拥有虚拟路由器的 IP 地址，我们把这个 IP 地址称为 VIP，MASTER 负责转发发送给网关地址的数据包和响应 ARP 请求。

2）VRRP 是如何工作的？
VRRP 协议通过竞选机制来实现虚拟路由器的功能，所有的协议报文都是通过 IP 多播（默认的多播地址：224.0.0.18）形式进行发送。虚拟路由器由 VRID （范围0-255）和一组 IP 地址组成，对外表现为一个周知的 MAC 地址：00-00-5E-00-01-{VRID}。所以，在一个虚拟路由器中，不管谁是 MASTER，对外都是相同的 MAC 地址和 IP 地址，如果其中一台虚拟路由器宕机，角色发生切换，那么客户端并不需要因为 MASTER 的变化修改自己的路由设置，可以做到透明的切换。这样就实现了如果一台机器宕机，那么备用的机器会拥有 MASTER 上的 IP 地址，实现高可用功能。

3）VRRP 是如何通信的？
在一组虚拟路由器中，只有作为 MASTER 的 VRRP 路由器会一直发送 VRRP 广播包，此时 BACKUP 不会抢占 MASTER 。当 MASTER 不可用时，这个时候 BACKUP 就收不到来自 MASTER 的广播包了，此时多台 BACKUP 中优先级最高的路由器会去抢占为 MASTER。这种抢占是非常快速的（可能只有1秒甚至更少），以保证服务的连续性。出于安全性考虑，VRRP 数据包使用了加密协议进行了加密。
5.keepalived高可用使用场景?

6.keepalived高可用核心概念总结?

1.如何确认谁是主谁是备节点？   优先级。 谁的优先级高谁就是master。
2.master故障，然后恢复？     抢占式、非抢占式。

业务不重要，需不需要高可用keepalived？

配置操作:

7.keepalived高可用安装与配置?

安装：
	yum install keepalived -y
配置
	master （优先级）   lb01  150

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {
    router_id lb01			#标识身份
}

vrrp_instance VI_1 {
    state MASTER			#master身份
    interface eth0			#vip绑定在那个网卡上
    virtual_router_id 50	#组名称必须一致
    priority 150			#优先级
    advert_int 1			#检查间隔时间
    authentication {
        auth_type PASS		#明文认证
        auth_pass 1111		必须一致		
}
    virtual_ipaddress {		#虚拟ip地址是10.0.0.3
        10.0.0.3
    }
}

backup （优先级）	  lb02   120

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

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.3
    }
}

	启动
systemctl enable keepalived
systemctl start keepalived

8.keepalived高可用地址漂移测试?

[root@lb01 ~]# ip addr | grep 10.0.0.3

尝试停止master的keeplaived
[root@lb01 ~]# systemctl stop keepalived

在slave上查看是否有对应的VIP
[root@lb02 ~]# ip addr|grep 10.0.0.3
    inet 10.0.0.3/32 scope global eth0

像 vrrp 224.0.0.18 发送组播数据报文?
广播：比如我讲课，说一句话，所有人 都收到了。
组播：是 一种特定的广播，只有特定的人群才可以收到。

9.keepalived高可用抢占式与非抢占式?

抢占：		master故障，backup接管，master恢复后会抢占VIP。   （发生2次切换）  默认就是抢占式。
	对于并发访问非常高的 站点，不建议配置抢占，因为会发生至少2次VIP地址漂移。
	什么情况用：  master 和 backup 的 配置 不对等。  （ master性能高，backup性能弱。 ）

非抢占：		master故障，backup接管，master恢复了不会抢占VIP，除非backup故障，master会再次接管VIP。

配置非抢占式步骤如下
1、两个节点的state都必须配置为BACKUP(官方建议)
2、两个节点都在vrrp_instance中添加nopreempt参数
3、其中一个节点的优先级必须要高于另外一个节点的优先级。
两台服务器都角色状态启用nopreempt后，必须修改角色状态统一为BACKUP，唯一的区分就是优先级。

#Master
    vrrp_instance VI_1 {
        state BACKUP
        priority 150
        nopreempt
    }

#Backup
    vrrp_instance VI_1 {
        state BACKUP
        priority 100
        nopreempt
    }

10.keepalived高可用与Nginx集成

准备环境：
10.0.0.5 已经配置好的负载均衡 （ blog、zh ）
10.0.0.6
安装Nginx
拉取10.0.0.5 的配置
目的：确保10.0.0.5 与 10.0.0.6 配置一致，无论通过5 或者 6 都能正常访问 blog 和 zh

[root@lb02 ~]# scp root@172.16.1.5:/etc/yum.repos.d/nginx.repo /etc/yum.repos.d/
[root@lb02 ~]# yum install nginx -y
[root@lb02 ~]# scp -rp 172.16.1.5:/etc/nginx /etc/
[root@lb02 ~]# nginx -t
[root@lb02 ~]# systemctl enable nginx
[root@lb02 ~]# systemctl start nginx

配置高可用：
1.提供的VIP是10.0.0.3
2.将域名解析指向到10.0.0.3

	解析：10.0.0.3 blog.oldxu.com zh.oldxu.com

Nginx和Keepalived有什么关系？ keepalived是如何实现nginx高可用的呢？

没有关系。
Nginx仅借助了Keepalived的地址漂移技术，实现的高可用。

nginx停止了？那么VIP还会漂移吗？
不会。

1.停止nginx
[root@lb01 ~]# systemctl stop nginx

2.检查vip，发现没有漂移。
[root@lb01 ~]# ip addr |grep 10.0.0.3
inet 10.0.0.3/32 scope global eth0

VIP在什么时候会漂移？
	1.keepalived服务停止了，地址就会漂移。
	2.服务器直接关机、重启了，地址会漂移。

希望Nginx如果故障停止了，那么希望VIP漂移到另外一台节点。
写一个脚本：
1.判断Nginx是否存活，
如果存活则不处理。
如果不存活，尝试1~3次，强制杀掉keeplaived。

[root@lb01 ~]# mkdir /server/scripts -p
[root@lb01 ~]# vim /server/scripts/check_web.sh
#!/bin/sh
nginxpid=$(ps -C nginx --no-header|wc -l)
#1.判断Nginx是否存活,如果不存活则尝试启动Nginx
if [ KaTeX parse error: Expected 'EOF', got '#' at position 65: … sleep 3 #̲2.等待3秒后再次获取一次Ng…(ps -C nginx --no-header|wc -l)
#3.再次进行判断, 如Nginx还不存活则停止Keepalived,让地址进行漂移,并退出脚本
if [ $nginxpid -eq 0 ];then
systemctl stop keepalived
fi
fi

#给脚本增加执行权限
[root@lb01 ~]# chmod +x /server/scripts/check_web.sh

---

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

#定义脚本路径，定义脚本多久执行一次，定义名称check_web
vrrp_script check_web {
	script "/server/scripts/check_web.sh"
	interval 5
}

vrrp_instance VI_1 {
    state BACKUP
    priority 150
    nopreempt

    interface eth0
    virtual_router_id 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
}
    virtual_ipaddress {
        10.0.0.3
    }
	#调用脚本，并运行该脚本
	track_script {
		check_web
	}
}

---

keepalived如何投产?
虚拟的IP地址。是无法对外的，意味着 DNS 怎么解析到你的 VIP ？

NAT：
SNAT 源地址转换 （ 共享上网的 ）
DNAT 目标地址转换 （ 端口映射 ）

keepalived 脑裂？

1.什么是脑裂？
	当两个节点同时认为自己是唯一处于活动状态的时候，从而出现了资源抢占，双方都在抢占资源的情况下，及为脑裂。
2.脑裂的产生？
	1.网线松动
	2.开启了防火墙。
3.脑裂影响的范围？
	1.对于无状态的服务，比如Nginx，不care脑裂不脑裂。
	2.对于有状态的服务，比如MySQL，就必须严格防止脑裂现象。
	对于MySQL来说，可能出现多种情况，比如无法正常访问、或者得不到正确的返回结果，但大部分是无法正常访问，直接没有响应；
	如果出现了脑裂，有多种办法可以规避，比如我们可以写一些监控性的脚本，同时监控2台服务器的地址配置情况，如果检测同时存在2个IP，就可以认定为脑裂，这		时软件解决办法，生产中用这种比较多；也有硬件解决办法，但不常用。
4.网上很多解决keepalived脑裂的问题的文章。