设为首页 收藏本站
查看: 1766|回复: 0

[经验分享] Redis的冗余方案(keepalived, HAProxy, Redis Sentinel)

[复制链接]

尚未签到

发表于 2015-11-20 03:25:37 | 显示全部楼层 |阅读模式
Redis的冗余方案(keepalived, HAProxy, Redis Sentinel)
  如果你在寻找Redis的冗余方案,我找到了下面的方案,我想可以来尝试一下这个方案。

「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的健康检查。

DSC0000.jpg

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。

DSC0001.jpg

这个方案是我参考下面的这篇文章「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/

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-141296-1-1.html 上篇帖子: keepalived指定日志文件 下篇帖子: CentOS 5.8布署nginx+keepalived实现负载均衡
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表