Redis的冗余方案(keepalived, HAProxy, Redis Sentinel)

女爷i 2022-08-08 05:09 231阅读 0赞

# Redis的冗余方案(keepalived, HAProxy, Redis Sentinel) #

如果你在寻找Redis的冗余方案，我找到了下面的方案，我想可以来尝试一下这个方案。  
[「Highly Available Redis Cluster | Simplicity is the keynote of all true elegance」][Highly Available Redis Cluster _ Simplicity is the keynote of all true elegance]  
最初曾考虑使用Pacemaker 来构建，因为Redis作者推出Sentinel的方案，因此本文使用Sentinel方案。

软件列表及版本:  
OS: CentOS 6.6  
Redis: 2.8.19  
HAProxy: 1.5.11  
Keepalived: 1.2.13

Sentinel控制Redis的 Master / Slave之间的自动故障转移。  
Sentinel对Master / Slave的监控管理的效果非常好，但因为Master的转移无法使得客户端始终连接同一个IP地址。下面需要使用HAProxy提供VIP的方案来实现。  
HAProxy把所有的Redis服务器（在我们的例子中Master和Slave两台）作为LB的成员，并确保Master的健康检查。  
![这里写图片描述][20150502202046532]  
Slave服务器在这里是作为Master的Standby，并不能做分布式的访问。  
Client可以提供Sentinel查询Master的IP地址，Master IP地址的变化不能由Sentinel直接通知到Client。  
在Slave晋升为Master之后，如果旧的Master突然启动，这时旧Master可以直接通过HAProxy分配到访问。如果希望Sentinel立即把旧Master转为Slave，而不是临时的，取消Server的自动启动是一个好主意。  
在HAProxy的方案中，Client使用keepalived中VRRP协议提供一个虚拟IP来访问Redis。  
让我们一一来设置。

## Redis Sentinel ##

> redis-sentinel.conf

port 2379
    logfile /var/log/redis/sentinel.log
    dir /tmp
    sentinel monitor mymaster 192.168.1.20 6379 2
    sentinel auth-pass mymaster my-redis-password
    sentinel down-after-milliseconds mymaster 30000
    sentinel parallel-syncs mymaster 1
    sentinel failover-timeout mymaster 180000
    # sentinel notification-script mymaster /var/redis/notify.sh
    # sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

Master的名字mymaster，你可以用任何字符串指定。此外，您还可以设置多个Master名字，如mymaster1和mymaster2。这样你可以用一组Sentinel管理多个Redis的集群。  
只需要指定Master，Sentinel会依次从Master中获得Slave的信息。

## HAProxy ##

> haproxy.conf

global
        log 127.0.0.1 local2 notice
        maxconn 4096
        chroot /var/lib/haproxy
        user nobody
        group nobody
        daemon
    
    defaults
        log global
        mode tcp
        retries 3
        option redispatch
        maxconn 2000
        timeout connect 2s
        timeout client 120s
        timeout server 120s
    
    frontend redis
        bind :6379
        default_backend redis_backend
    
    backend redis_backend
        option tcp-check
        tcp-check send AUTH\ my-redis-password\r\n
        tcp-check expect string +OK
        tcp-check send PING\r\n
        tcp-check expect string +PONG
        tcp-check send INFO\ REPLICATION\r\n
        tcp-check expect string role:master
        tcp-check send QUIT\r\n
        tcp-check expect string +OK
        server redis1 192.168.1.21:6379 check inter 1s
        server redis2 192.168.1.22:6379 check inter 1s

tcp-check发送一个字符串，期望一个匹配的字符串应答。上面的配置是在一个TCP会话中顺序执行，反斜杠需要在空格的前面。AUTH命令发送密码，一旦正确会应答一个OK，发送包含PING的字符串，会应答PONG， 发送INFO REPLICATION会应答包含OK字符串的Master，你可以看到一个活着的Master。如果不需要认证及PING，也可以不发送它们。

## keepalived ##

由于多播(multicast)的packet 数据流问题，这里设置单播(unicast)。

> keepalived.conf

global_defs {
        notification_email {
            admin@example.com
        }
        notification_email_from keepalived@example.com
        smtp_server 127.0.0.1
        smtp_connect_timeout 30
        router_id 主机名
    }
    
    vrrp_script check_haproxy {
        script "pkill -0 -x haproxy" # haproxy的过程中存在确认
        interval 1  # 每隔1秒运行
        fall 2      # 连续判断2次失败
        raise 2     # 成功判断2次为正常
    }
    
    vrrp_instance REDIS {
        state BACKUP   # nopreempt 2台作为BACKUP
        interface eth0
        smtp_alert
        virtualrouter_id 51     # 在同一子网内的唯一号码
        priority  101           # 数字较大的为Master
        advert_int 1            # VRRP报文的发送间隔
        nopreermpt              # 不要自动故障恢复
        unicast_peer {          # 配置unicast而不是multicast
            192.168.1.32        # 指定伙伴的IP地址
        }
        authentication {
            auth_type PASS
            auth_pass hogehoge  # 最多8个字符的字符串
        }
        virtual_ipaddress {
            192.168.1.30        # VIP
        }
        track_script {
            check_haproxy
        }
        # 在晋升Master时执行的脚本 (当然这里不需要设置任何东西)
        # notify_master /some/where/notify_master.sh

## 是不是有点夸张 ##

虽然可以提供 Ansible playbook来构造配置，是不是感觉有点夸张？我想这仅仅是个Active / Standby配置而已。  
有效利用Sentinel，通过增加Redis复制数来分布负载。由一对HAProxy来管理多个Redis集群（Sentinel可以是一组），尽管这是个不错的配置，但对于简单的Active / Standby来说过于复杂。  
另外，对于高速的Redis，相比HAProxy的长的等待时间来说确实会产生额外的负担。  
通过redis-benchmark简单地测试结果，性能只有原来的一半。（原来很快，希望达到相近性能）  
可以考虑去掉HAProxy，但keepalived非常有必要，通过keepalived返回的VIP总是可用Redis的Master，由Redis Sentinel 管理Redis的Failover。  
当Redis的Master切换后，由keepalived 切换Redis的主机为新的Master。  
![这里写图片描述][20150504215049814]  
这个方案是我参考下面的这篇文章[「Redis推荐的使用Keepalived的HA方案 」][Redis_Keepalived_HA_]。  
fujiwara写到keepalived 现在仍不支持 VRRP unicast，但我可以在云服务中使用，如EC2，因为单播可以使用。  
在keepalived的notify\_master中，调用 redis-cli的slaveof NO ONE命令，把一个Redis晋升为Master，并把变更写到redis.conf中以反映这种变化。  
CONFIG REWRITE是在2.8版本中增加的命令，在fujiwara 写这篇文章时还不支持。  
当切换到BACKUP时，你也可以使用notify\_backup，把Redis切换到slave。

> keepalived.conf

global_defs {
        notification_email {
            admin@example.com
        }
        notification_email_from keepalived@example.com
        smtp_server 127.0.0.1
        smtp_connect_timeout 30
        router_id 主机名
    }
    
    vrrp_script check_redis {
        script "/some/where/check_redis.sh" # 检查redis
        interval 2  # 每隔2秒运行
        fall 2      # 连续判断2次失败
        raise 2     # 成功判断2次为正常 
    }
    
    vrrp_instance REDIS {
        state BACKUP   # nopreempt 2台作为BACKUP
        interface eth0
        smtp_alert
        virtualrouter_id 51     # 在同一子网内的唯一号码
        priority  101           # 数字较大的为Master
        advert_int 1            # VRRP报文的发送间隔
        nopreermpt              # 不要自动故障恢复
        unicast_peer {          # 配置unicast而不是multicast
            192.168.1.32        # 指定伙伴的IP地址
        }    
        authentication {
            auth_type PASS
            auth_pass hogehoge  # 最多8个字符的字符串
        }
        virtual_ipaddress {
            192.168.1.30        # VIP
        }
        track_script {
            check_redis
        }
        # Master 在晋升Master时执行的脚本
        notify_master /some/where/notify_master.sh
        # notify_backup /some/where/notify_backup.sh 
    }

这很简单，如果主/备方式，你可以参考这些配置。

*原文：*  
[http://blog.1q77.com/2015/02/redis-ha/][http_blog.1q77.com_2015_02_redis-ha]

[Highly Available Redis Cluster _ Simplicity is the keynote of all true elegance]: http://www.101tech.net/2014/08/08/highly-available-redis-cluster/
[20150502202046532]: /images/20220805/f2e980b63c6845bead78e8ded9a83223.png
[20150504215049814]: /images/20220805/1bdcbc69f41744658ab4a111ee731166.png
[Redis_Keepalived_HA_]: http://sfujiwara.hatenablog.com/entry/20120802/1343880266
[http_blog.1q77.com_2015_02_redis-ha]: http://blog.1q77.com/2015/02/redis-ha/