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

本文介绍了一种使用Redis Sentinel、HAProxy和Keepalived构建的Redis高可用方案。该方案通过Sentinel实现Redis Master/Slave自动故障转移,HAProxy提供VIP方案,而Keepalived则用于监控并切换Redis Master。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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的健康检查。
这里写图片描述
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。
这里写图片描述
这个方案是我参考下面的这篇文章「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/

<think>嗯,用户想了解企业级部署Nextcloud的高可用方案的最佳实践。首先,我需要回忆一下Nextcloud的高可用性涉及哪些方面。高可用性通常涉及到消除单点故障,确保各个组件都有冗余。Nextcloud的架构主要包括前端Web服务器、数据库、存储、缓存和会话管理等部分,所以每个部分都需要考虑冗余和负载均衡。 首先,Web服务器层。用户可能需要使用负载均衡器,比如HAProxy或Nginx,来分发流量到多个Nextcloud实例。这可以避免单台服务器故障导致服务中断。另外,负载均衡器本身也需要高可用,可以通过VRRP协议配合Keepalived实现双机热备,这样即使一个负载均衡器宕机,另一个可以接管。 接下来是数据库层。Nextcloud支持MySQL、PostgreSQL等关系型数据库。对于高可用数据库,常用的方案有主从复制配合故障转移,或者使用Galera Cluster实现多主同步。不过,Galera Cluster可能会增加复杂性,需要评估运维能力。另外,云托管的数据库服务如AWS RDS或阿里云RDS已经内置了高可用功能,可能更适合资源有限的企业。 存储层方面,Nextcloud默认使用本地存储,但企业级部署需要共享存储。可以考虑使用NFS服务器,但NFS本身可能成为单点故障,所以需要分布式文件系统如GlusterFS或Ceph,它们提供冗余和自动故障恢复。另外,对象存储集成也是一个选项,比如兼容S3的对象存储服务,这样可以利用对象存储的高可用特性,同时通过Nextcloud的External Storage插件挂载。 缓存和会话管理也很重要。Redis或Memcached可以用来缓存数据和会话,但单节点Redis有风险,所以需要Redis SentinelRedis Cluster来实现高可用。配置Nextcloud使用Redis集群时,需要修改config.php文件,确保会话数据在节点间同步。 然后是数据备份与恢复。即使有高可用架构,备份仍是必须的。需要定期全量备份和增量备份,验证备份的完整性,并且有灾难恢复演练。此外,Nextcloud的版本升级和插件兼容性测试也要在备份后进行,避免升级导致的问题。 监控和自动扩展方面,Prometheus和Grafana可以监控系统状态,设置阈值告警。在容器化部署时,Kubernetes能够自动扩展Pod,根据负载调整资源,但需要合理设置资源限制,避免资源争抢。 用户提供的引用中,引用[1]提到Nextcloud和LAMP堆栈的高度可配置性,三种典型场景的最佳实践,可能需要结合这些场景来推荐不同的高可用方案。引用[3]提到预览生成器插件的配置和系统性能监控,这也提醒我在高可用方案中需要考虑插件的影响和性能优化。 潜在的问题可能包括:如何选择适合企业规模的数据库集群方案,分布式存储的配置复杂度,以及容器化部署中的网络和存储管理。需要根据企业的具体需求和IT基础设施来权衡不同方案,比如中小型企业可能更适合使用托管数据库和对象存储,而大型企业可能自建Ceph集群和Kubernetes编排。 总结下来,高可用方案需要覆盖Web层、数据库、存储、缓存、会话管理、备份和监控等多个层面,每个层面都有不同的技术选型和配置要点。需要确保各组件冗余,避免单点故障,同时考虑运维复杂性和成本。</think>### 企业级 Nextcloud 高可用方案最佳实践 企业级部署 Nextcloud 的高可用方案需从 **架构冗余**、**负载均衡**、**数据同步** 和 **故障恢复** 四个核心维度设计,以下为分步实施方案: --- #### 一、Web 服务层高可用 1. **负载均衡与多实例部署** - 使用 $Nginx$ 或 $HAProxy$ 作为负载均衡器,将请求分发至多个 Nextcloud 应用服务器实例 - 配置会话保持(Session Persistence)确保用户请求连续性 - 示例架构: $$ \text{用户} \rightarrow [HAProxy_{主备}] \rightarrow [Nextcloud\_Server1 | Nextcloud\_Server2 | ...] $$ 2. **容器化部署(可选)** - 通过 $Kubernetes$ 部署 Nextcloud Pod,实现自动扩缩容和故障转移[^3] - 使用 $Helm Chart$ 快速编排,需配置持久化存储卷(PVC)绑定共享存储 --- #### 二、数据库层高可用 1. **数据库集群方案** - **MySQL/MariaDB**: 使用 $Galera\ Cluster$ 实现多主同步复制,确保数据一致性 - **PostgreSQL**: 配置 $Patroni + etcd$ 实现自动故障切换 - 云环境可选用托管服务(如 $AWS\ RDS$、$阿里云\ PolarDB$)[^1] 2. **Nextcloud 配置优化** - 修改 `config.php` 指定集群数据库节点: ```php 'dbcluster' => [ 'read' => ['db1.example.com', 'db2.example.com'], 'write' => ['db3.example.com'], ], ``` --- #### 三、存储层高可用 1. **分布式文件系统** - 使用 $GlusterFS$ 或 $Ceph$ 提供共享存储,避免单点故障 - 配置 Nextcloud 数据目录(`datadirectory`)挂载分布式存储卷 2. **对象存储集成** - 通过 `External Storage` 插件挂载 $Amazon\ S3$、$MinIO$ 等对象存储[^2] - 启用版本控制和跨区域复制(CRR)提升数据可靠性 --- #### 四、缓存与会话管理 1. **Redis 高可用集群** - 部署 $Redis\ Sentinel$ 或 $Redis\ Cluster$ 管理缓存和会话 - Nextcloud 配置示例: ```php 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'redis' => [ 'host' => 'redis-cluster.example.com', 'port' => 6379, ], ``` --- #### 五、备份与灾难恢复 1. **跨区域数据备份** - 使用 $BorgBackup$ 或 $Restic$ 执行增量备份至异地存储 - 定期验证备份可恢复性(建议每月一次) 2. **快速故障切换** - 通过 $DNS\ Failover$ 或 $浮动IP$ 实现入口层快速切换 - 预设应急预案,确保 RTO(恢复时间目标)<15 分钟 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值