使用keepalived实现redis的故障切换

线上的redis环境一直是单点，确实挺危险的。刚开始想用redis的Sentinel来做，可看了半天发现这东西也不靠谱，还挺麻烦的样子，只能暂时抛弃，换成自己熟悉的keepalived来做。 有了方案后剩下的就是查询相关资料了，google了一堆的资料，发现大家的做法普遍是

线上的redis环境一直是单点，确实挺危险的。刚开始想用redis的Sentinel来做，可看了半天发现这东西也不靠谱，还挺麻烦的样子，只能暂时抛弃，换成自己熟悉的keepalived来做。

有了方案后剩下的就是查询相关资料了，google了一堆的资料，发现大家的做法普遍是：

场景：CentOS A —>Keepalived Master && Redis Master
     CentOS B—>Keepalived Backup && Redis Backup
1.正常情况CentOS A 提供服务， CentOS B 备份
2.如果CentOS A 挂了，CentOS B 升级为Master;
     CentOS A 恢复正常后，CentOS A 抢占为 Master，CentOS B 降级为 Slave.
3.如果CentOS A 挂，重复上述过程；如果 CentOS B 挂，请自行修复CentOS B.
  可以看到上述步骤2中，一个是当CentOS A 挂了再起来后再次抢占为Master，会照成业务的再次切换,影响线上业务的稳定性；另一个就是可以看到网上大家的做法一般是当CentOS A恢复抢占为Master后，为了保持Redis 主从数据的一致性，会让CentOS A 的 Redis 变成从先跟 CentOS B的Redis 同步数据，同步了一个固定时间后，然后把CentOS A的Redis 变为主，同样CentOS B的Redis 也是先sleep了某一个固定时间等待CentOS A 同步完成后，再变为从，其他状态变化参考这个过程，不多讲。看完后，我深深的震撼了，我靠，这些哥们确信自己真的能精确的控制这些过程吗？脚本中sleep的时间真的可以定下来吗？最简单的Redis 主从复制，主挂了，立即切换到从，都不能保证数据完整（主的数据还没来得及进行持久化，保存到硬盘），加了个keepalived就行了吗？

我的观点是搞运维的要尽量把架构搞的简单点，不要给自己挖坑，过于复杂的架构不仅难维护，而且容易出问题,出了问题还要背黑锅。所以简单的梳理了下我的需求和我想要得到的效果:

场景：
        CentOS A —>Keepalived Master && Redis Master
        CentOS B—>Keepalived Backup && Redis Backup
1.正常情况CentOS A 提供服务，CentOS B  备份
2.如果CentOS A 挂了，CentOS B 升级为Master;
  CentOS A 恢复正常后， 不抢占，变为slave.
3.如果CentOS B挂了，CentOS A 再升级为主

大家知道keepalived会有四种状态的变化，每种状态变化时，都可以调用一个脚本,如下:

当进入Master状态时会呼叫notify_master
当进入Backup状态时会呼叫notify_backup
当发现异常情况时进入Fault状态呼叫notify_fault
当Keepalived程序终止时则呼叫notify_stop
    进入Master和Backup这两种状态很容易理解了，就是分别变为主和从；进入Fault这个稍微要注意下，这个是什么意思呢，简单的说就是keepalived发现自己有问题了，既然有问题那他就不可能再去参与Master竞选了，你得修好他才行，进入这种状态一般是keepalived自身出问题了，或者keepalived检测的网卡出问题不通了，再或者就是我们自己写的检测业务的脚本返回错误；进入Stop 这个就容易理解了，执行/etc/init.d/keepalived stop 就会进入这个状态。
    我想要的是上诉步骤2中，当CentOS A 挂了后（Keepalived检测的网卡出问题或者Redis挂了），CentOS A 上的Keepalived也立即stop了，这样一个是流程清晰，另一个是可以避免“脑裂”情况的发生，当然了事后要手动把CentOS A 上的Redis 和 Keepalived 起来；同理上诉步骤3中CentOS B挂了后，也是立即停止Keepalived进程，事后手动启动CentOS B的Redis 和 Keepalived。

这么做有什么好处呢，那就是流程清晰，易于理解，便于维护。让我们梳理下这个流程，看看有多简单：

1.正常情况CentOS A 为Master提供服务，CentOS B 为 Slave 备份。
2.然后出问题了，那就是CentOS A上的 Redis  挂了，Keepalived检测到 Redis挂了后，就进入 Fault状态，调用redis_fault.sh脚本关闭Keepalived ,接着Keepalived进入stop状态了；此时CentOS B升级为Master,调用redis_master.sh脚本将Redis升级为主。
3.然后上去修复CentOS A,启动Redis、Keepalived,由于设置不抢占,这个时候CentOS A的状态就只能是Slave了，调用redis_backup.sh脚本把Redis变为从，跟CentOS B上的Redis同步数据；这个时候CentOS B 继续是主，当然Redis 也是主。
4.天有不测风云啊，CentOS A 刚修好，CentOS B的Redis 又挂了。这时只剩CentOS A 了，义不容辞的也就成为Master了，调用redis_master.sh脚本，将自己的Redis升级为主；CentOS B的 Redis挂的时候，同样会进入Fault状态，调用redis_fault.sh脚本关闭Keepalived ,接着Keepalived进入stop状态。
5.一把泪，只有登录CentOS B查看相关日志后，手动启动Redis、Keepalived。这个时候CentOS A 继续把持Master老大哥地位不放，所以状态不变；CentOS B就只能乖乖的进入Slave状态，调用redis_backup.sh脚本，把Redis搞成CentOS A 上Redis的从。
6.重复上述流程。

流程搞清楚了，剩下的就是Keepalived 配置 以及进入每种状态时呼叫的脚本了，不多说，这个就直接上配置吧.

主：

[root@puppet ~]# cat /etc/keepalived/keepalived.conf
#全局定义
global_defs {
   #运行keepalived的机器的一个标示
   router_id redis-ha
}
vrrp_script chk_redis {
    script "/etc/keepalived/scripts/redis_check.sh"
    interval 1
}
#vrrp实例配置
vrrp_instance VI_1 {
    state BACKUP
    nopreempt
    interface eth0
    virtual_router_id 58
    priority 180
    #检查间隔，默认1s
    advert_int 1
    #在切换到MASTER状态后，延迟进行gratuitous ARP 请求
    garp_master_delay 1
    authentication {
        auth_type PASS
        auth_pass KJj23576hYgu23IP
    }
    #设置额外的监控，里面的任意一个网卡出现问题，都会进入FAULT状态
    track_interface {
       eth0
    }
    track_script {
        chk_redis
    }
    virtual_ipaddress {
        192.168.188.132
    }
    notify_master /etc/keepalived/scripts/redis_master.sh
    notify_backup /etc/keepalived/scripts/redis_backup.sh
    notify_fault  /etc/keepalived/scripts/redis_fault.sh
    notify_stop   /etc/keepalived/scripts/redis_stop.sh
}
[root@puppet ~]# cat /etc/keepalived/scripts/redis_master.sh
#!/bin/bash
REDISCLI="/usr/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"
echo "[master]" >> $LOGFILE
date >> $LOGFILE
echo "Being master...." >> $LOGFILE 2>&1
echo "Run SLAVEOF NO ONE cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF NO ONE >> $LOGFILE 2>&1
[root@puppet ~]# cat /etc/keepalived/scripts/redis_backup.sh
#!/bin/bash
REDISCLI="/usr/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"
echo "[backup]" >> $LOGFILE
date >> $LOGFILE
echo "Being slave...." >> $LOGFILE 2>&1
echo "Run SLAVEOF cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF 192.168.188.131 6379 >> $LOGFILE  2>&1
[root@puppet ~]# cat /etc/keepalived/scripts/redis_fault.sh
#!/bin/bash
LOGFILE=/var/log/keepalived-redis-state.log
echo "[fault]" >> $LOGFILE
date >> $LOGFILE
/etc/init.d/keepalived stop
[root@puppet ~]# cat /etc/keepalived/scripts/redis_stop.sh
#!/bin/bash
LOGFILE=/var/log/keepalived-redis-state.log
echo "[stop]" >> $LOGFILE
date >> $LOGFILE

从：

[root@agent ~]# cat /etc/keepalived/keepalived.conf
#全局定义
global_defs {
   #运行keepalived的机器的一个标示
   router_id redis-ha
}
vrrp_script chk_redis {
    script "/etc/keepalived/scripts/redis_check.sh"
    interval 1
}
#vrrp实例配置
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 58
    priority 120
    #检查间隔，默认1s
    advert_int 1
    #在切换到MASTER状态后，延迟进行gratuitous ARP 请求
    garp_master_delay 1
    authentication {
        auth_type PASS
        auth_pass KJj23576hYgu23IP
    }
    #设置额外的监控，里面的任意一个网卡出现问题，都会进入FAULT状态
    track_interface {
       eth0
    }
    track_script {
        chk_redis
    }
    virtual_ipaddress {
        192.168.188.132
    }
    notify_master /etc/keepalived/scripts/redis_master.sh
    notify_backup /etc/keepalived/scripts/redis_backup.sh
    notify_fault  /etc/keepalived/scripts/redis_fault.sh
    notify_stop   /etc/keepalived/scripts/redis_stop.sh
}
[root@agent ~]# cat /etc/keepalived/scripts/redis_master.sh
#!/bin/bash
REDISCLI="/usr/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"
echo "[master]" >> $LOGFILE
date >> $LOGFILE
echo "Being master...." >> $LOGFILE 2>&1
echo "Run SLAVEOF NO ONE cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF NO ONE >> $LOGFILE 2>&1
[root@agent ~]# cat /etc/keepalived/scripts/redis_backup.sh
#!/bin/bash
REDISCLI="/usr/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"
echo "[backup]" >> $LOGFILE
date >> $LOGFILE
echo "Being slave...." >> $LOGFILE 2>&1
echo "Run SLAVEOF cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF 192.168.188.130 6379 >> $LOGFILE  2>&1
[root@agent ~]# cat /etc/keepalived/scripts/redis_fault.sh
#!/bin/bash
LOGFILE=/var/log/keepalived-redis-state.log
echo "[fault]" >> $LOGFILE
date >> $LOGFILE
/etc/init.d/keepalived stop
[root@agent ~]# cat /etc/keepalived/scripts/redis_stop.sh
#!/bin/bash
LOGFILE=/var/log/keepalived-redis-state.log
echo "[stop]" >> $LOGFILE
date >> $LOGFILE

注意：

    从配置里可以看到这种方案有一个坑，就是 CentOS A 上的Keepalived刚启动的时候，状态切换会先切换到Backup，然后参加竞选后才会到Master。这样就会出现问题，当切换到Backup时，会执行redis_backup.sh，跟 CentOS B 的Redis 同步数据，如果这时CentOS B上的Redis数据不全或者为空，悲剧就发生了，这肯定不是我想要的结果了。
    所以正常的启动流程是:先启动CentOS  A 的 Redis，接着启动Keepalived；然后等个几秒，启动 CentOS B 的Redis,接着启动Redis。

说了这么多，不做测试，一切都是白搭，下面让我们跑下测试流程，看看日志结果：

1.分别启动CentOS A的Redis、Keepalived(注意顺序)
[root@puppet ~]# /etc/init.d/redis start
启动 ：                                                    [确定]
[root@puppet ~]# /etc/init.d/keepalived start
正在启动 keepalived：                                      [确定]
查看日志

自言自语：

Keepalived中可以玩的地方还是挺多的，例如心跳时间、自定义检测脚本等等，我这里为了维护的方便只写出最简单的配置，具体可以参见官网文档；同时Redis主从的切换过程也可以加入报警功能，例如我就在redis_master.sh中加入了短信报警的功能，这样可以及时知道那一台Redis出问题了。这次写博客没有大片大片的写安装文档、没有写配置流程，真是个奇迹，不过预计以后写博客的时间也是越来越少了，各种忙碌中...

参考资料：

郭东：http://heylinux.com/archives/1942.html

oschina: http://my.oschina.net/guol/blog/182491

其他：《Keepalived 权威指南》

原文地址：使用keepalived实现redis的故障切换, 感谢原作者分享。