week17-Keepalive

作者: 刘Huai | 来源:发表于2019-08-24 17:11 被阅读0次

1. 什么是高可用，为什么要设计高可用?

两台业务系统启动着相同的服务,如果有一台故障,另一台自动接管,称为高可用.
高可用的目的: 保证系统实时不间断的可用性. (每一层都要考虑高可用)
系统可靠性评估

2. 高可用使用什么工具来实现? 是硬件还是软件?

软件 Keepalived

3. keepalived如何实现高可用?

keepalived是通过vrrp来实现的高可用. vrrp,虚拟路由冗余协议.

4. vrrp诞生的过程以及vrrp的原理?

虚拟路由冗余协议

客户端 -----> 网关 (10.0.0.254)

pc1  >>>>

pc2  >>>>    路由器/网关设备  （10.0.0.254）（master 主设备） 例: 出现故障
             路由器/网关设备  （10.0.0.253）（backup 主设备） 
pc3  >>>>
# 用户正常将请求发送给 主设备，当主设备出现问题，情况会如下：
             解决方法1：
             加一台备设备 10.0.0.253
             解决方法2:
             将备改为主的地址，但是此操作无法解决问题；
             因为在第一次网络包通讯的时候，pc会记录一个mac地址，在第一次网络包通讯的时候，pc会记录一个mac地址(硬件地址，假设是主设备的mac地址) 
             如果将备地址改为主地址，但是pc还是会将请求发送给记录的mac(主设备，但是主设备已经故障)
             如果修改mac地址表
             1. mac 表会定时刷新(不到时间，不会自动刷新)，但是调整过期时间
             此处就用到了vrrp协议
             vrrp
pc1  >>>>            
             
pc2  >>>>       v ip                   路由器/网关设备  （10.0.0.254）（master 主设备） 例: 出现故障            
                v mac                  路由器/网关设备  （10.0.0.253）（backup 主设备） 
pc3  >>>>

             vrrp会在客户端与网管设备中间加一个 vip  （虚拟ip） vmac （虚拟mac地址），pc就会将请求发给vip， vip会将请求发送给 备设备，这个时候keepalive会通知pc arp更新了，这样就做到了无缝连接

VRRP 使用原理

5. keepalived高可用使用场景?

通常业务系统需要保证7X24小时不down机。比如公司内部OA系统，每天公司人员都需要使用，则不允许down机。作为业务系统来说随时随地地都要求可用。

应用场景

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

1.如何确定谁是主节点谁是备节点。(投票选举？优先级？)
2.如果Master故障，Backup自动接管，那Master恢复后会夺权吗？(抢占式、非抢占式)
3.如果两台服务器都认为自己是Master会出现什么问题？(脑裂)

7. keepalived高可用安装与配置

7.1 安装

yum install -y keepalived 
在 lb01 和 lb02 上安装

7.2 配置

rpm -qc keepalived

查看配置文件
/etc/keepalived/keepalived.conf
/etc/sysconfig/keepalived

'【主】 配置文件'
global_defs {     
    router_id lb01   标识信息，随意指定
}

vrrp_instance VI_1 {
    state MASTER                             表示此设备为主
    priority 150                             优先级 
    interface eth0                           绑定到eth0 网卡
    virtual_router_id 50 
    advert_int 1                             心跳间隔时间，秒；检测【主】是否存在（正常/故障）
    authentication {                         发送心跳，主机之间的认证
        auth_type PASS  
        auth_pass 1111                       认证密码
}
    virtual_ipaddress {
        10.0.0.99                             虚拟ip地址，可以写多个，都可以
    }
}

'【备】 配置文件 '

global_defs {
    router_id lb02     标识信息，随意指定
}

vrrp_instance VI_1 {
    state BACKUP                             表示此设备为备
    priority 100                             优先级 
    interface eth0
    virtual_router_id 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.99                             虚拟ip地址，可以写多个，都可以
    }
}

7.3 启动

systemc  start keepalived

服务启动

7.4 测试

查看主设备，虚拟IP 是否绑定成功（主设备工作正常）

绑定正常

ping 虚拟IP

ping虚拟IP 正常

查看 arp地址表

arp地址表

可以看出虚拟IP 的物理地址和【主设备】的MAC地址相同，MAC 使用的是【主设备】
因为改过【主设备】eth0 网卡的IP ，所以跟上图的【主设备】IP不同，MAC地址相同

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

提供一个 VIP 和 VMAC 模拟 master停止keeplaived 看是否会发生地址漂移至Backup

主IP 10.0.0.21 备IP 10.0.0.201

抓包过程

发包内容，与配置文件配置的符合

在ping 虚拟IP 的时候，将Master停掉，可以看到，VMAC 和VIP 自动切换到 BACKUP 上

arp地址表

可以看到，在MASTER设备停掉之后，虚拟IP 会漂移绑定到 BACKUP 上 10.0.0.201 就是BACKUP的IP地址，keepalived 也通知系统，arp地址表更新了

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

在访问量高的网站上，不能频繁切换的，不配置非抢占式，当Master设备出现故障，转换到BACKUP 上进行访问时，如果没有配置非抢占式，主Master设备会抢回资源，这样就会出现抢占式，导致不稳定，如何配置非抢占式??

Master
    vrrp_instance VI_1 {
        state BACKUP
        priority 150
        nopreempt 非抢占式配置
    }

Backup
    vrrp_instance VI_1 {
        state BACKUP
        priority 100
        nopreempt 非抢占式配置
    }
注： 两台设备都要配置 'state 全部改成 BACKUP'，根据优先级判断，如果不改Master 还是会抢占

测试
主 10.0.0.21
备 10.0.0.201

正常访问

停掉优先级高的设备

停止主设备keepalived 服务

切换到备

VIP 已切换

如果没有配置抢占式，优先级高的设备在启动/恢复的时候，会将VIP抢占，配置了非抢占式之后，启动优先级高的设备之后，不会抢占,如下：

服务已启动

未抢占

可以看出，在配置了非抢占式之后，优先级高的设备故障之后恢复并没有抢占走VIP
注：两台设备都要配置 'state 全部改成 BACKUP'，根据优先级判断，如果不改Master 还是会抢占

10. keepalived高可用与Nginx集成

PS: 有 Nginx 负载均衡，并不一定要用Keepalived
Nginx 单独就可以实现流量分发和调度
多用在硬件环境上
云服务器无法使用Keepalived （云产品有一个叫做SLB,代替负载均衡，前提不要部署Nginx）

10.1 准备环境

lb01        10.0.0.5  负载1 
lb02        10.0.0.6  负载2 
web01       10.0.0.7 
web02       10.0.0.8
web03       10.0.0.9

在保证Nginx负载可用的情况下打开Keepalived ，将host文件的解析地址改问 VIP （vrrp 协议的VIP ），Nginx其实就是借用了 Keepalive 的地址漂移功能，因为Nginx 在做负载的时候，如果负载一故障，需要手动指定另一个负载的IP 到hosts文件，而借助了Keepalived 有了地址漂移功能，在Keepalived功能故障的时候，会自动漂移到另一台keepalvied 服务器

11. keepalived高可用脑裂与故障解决

出现原因

**主备keepalived服务器都开启了防火墙，互相都无法通信，导致各种都认为自己是MASTER **
网卡故障
网线松动

测试防火墙开启

ping vip

ping vip是可以通的，但是网站无法打开，因为两台Keepalived 在抢占资源；

网站故障

解决方法1 ：杀掉其中一台Keepalived 进程，另一台恢复正常

解决方法2 ： (待补充)

10.1 keepalived 与 Nginx 建立连接

如果Nginx宕机, 会导致用户请求失败, 但Keepalived并不会进行地址漂移
所以需要编写一个脚本检测Nginx的存活状态, 如果不存活则kill nginx和keepalived

# 检测Nginx 状态脚本如下
vim   /server/scripts/check_www.sh
#!/bin/sh
nginxpid=$(ps -C nginx --no-header|wc -l)
#1.判断Nginx是否存活,如果不存活则尝试启动Nginx
if [ $nginxpid -eq 0 ];then
    systemctl start nginx
    sleep 3
    #2.等待3秒后再次获取一次Nginx状态
    nginxpid=$(ps -C nginx --no-header|wc -l) 
    #3.再次进行判断, 如Nginx还不存活则停止Keepalived,让地址进行漂移,并退出脚本  
    if [ $nginxpid -eq 0 ];then
        systemctl stop keepalived
   fi
fi
#  注意要给脚本加上执行权限： chmod +x /server/scripts/check_www.sh

配置keepalived使用 (keepalived支持内置运行shell脚本)
vim  /etc/keepalived/keepalived.conf
global_defs {     
    router_id lb01   
}

#定义脚本所在的位置,以及执行时间
vrrp_script  check_www {
    script "/server/scripts/check_www.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_www
    }
}

示例操作

运行脚本

测试停止Nginx 服务之后脚本状态

将Nginx 配置文件做了一些错误的改动，导致无法Nginx 服务无法启动，当脚本检测到Nginx 无法启动之后，就会停止Keepalived 服务，Keepalived 服务检测到异常，就会进行地址漂移，将资源分配到另一台 keepalived 服务器，继续工作

测试Nginx 无法启动之后是否停止keepalived

停止 Nginx之后没有地址漂移，因为没有运行脚本

此时的请求还在负载1 上边

运行了脚本之后，服务停止

keepalived 也跳转到了另一台负载服务器上

网站也可以正常访问