存储架构模式之复制架构:主备、主从、双机切换、集群选举

存储类问题处理框架图

存储架构模式之复制架构:主备、主从、双机切换、集群选举

高可用存储几个核心指标

【RPO】

Recovery Point Objective,恢复点目标,指”最大可接受的数据损失“,因为数据备份和复制都是有时间限制的,不可能做到绝对实时。

【RTO】

Recovery Time Objective,恢复时间目标,指“最大可接受的系统恢复所需时间”,因为定位、处理、恢复需要时间。

【WRT】

Work Recovery Time,工作恢复时间,指“系统恢复正常后,恢复业务所需的时间”,因为要进行各种业务检查、校验、修复。

【MTD】

Maximum Tolerable Downtime ,最大可容忍宕机时间,等于 RTO + WRT。

主备复制 & 主从复制

存储架构模式之复制架构:主备、主从、双机切换、集群选举

本质:通过冗余来提升可用性,通过叠加来提升读性能。

变化:备机是否提供复制功能,备机部署地点,主从主备混合部署。

存储架构模式之复制架构:主备、主从、双机切换、集群选举

优点:实现简单,只需要数据复制,无状态检测和角色切换。

缺点:需要人工干预,RTO 比较大。

主备级联复制

存储架构模式之复制架构:主备、主从、双机切换、集群选举

变化:

备机作为复制源,例如图中备机1是备机2的复制源。

优点:

主机故障后,切换备机1为主机,方便快捷,直接修改配置即可(图中虚线部分),无需修改备机2的配置,无需判断备机1和备机2的数据覆盖问题。

缺点:

备机1对备份非常关键,备机1宕机会导致两台备份机都备份失败。

应用:

MySQLRedis 支持这种模式。

主备架构的灾备部署

存储架构模式之复制架构:主备、主从、双机切换、集群选举

【场景1】

IDC-1 和 IDC-2 在同一个城市,可以应对机房级别的灾难。

【场景2】

IDC-1 和 IDC-2 不在同一个城市,可以应对城市级别的灾难。

主从架构的灾备部署

存储架构模式之复制架构:主备、主从、双机切换、集群选举

【场景1】

IDC-1 和 IDC-2 在同一个城市,可以应对机房级别的灾难。

【场景2】

IDC-1 和 IDC-2 不在同一个城市,可以应对城市级别的灾难。

双机切换 – 主备切换

存储架构模式之复制架构:主备、主从、双机切换、集群选举

优点:可以自动实现故障恢复,RTO 短。

缺点:实现复杂,需要实现数据复制、状态检测、故障切换 数据冲突处理。

应用:内部系统、管理系统。

双机切换 – 主从切换

存储架构模式之复制架构:主备、主从、双机切换、集群选举

整体和主备切换类似,差异点在于“切换阶段”,只有主机提供读写服务,主机性能有风险。

集群选举

存储架构模式之复制架构:主备、主从、双机切换、集群选举

优点:可以自动实现故障恢复,RTO 短,可用性更高。

缺点:实现复杂,需要实现数据复制、状态检测、选举算法、故障切换、数据冲突处理。

应用:通用,例如 Redis、MongoDB 等。

集群选举案例 – Redis

存储架构模式之复制架构:主备、主从、双机切换、集群选举

Redis:使用 sentinel 集群来解决“决策者”单点问题,sentinel 又是通过Raft 算法进行选举的。

最佳实践 – 基于 ZooKeeper 实现

存储架构模式之复制架构:主备、主从、双机切换、集群选举

基于 ZooKeeper 来实现双机切换或者集群选举,能够大大降低复杂度,优势有几点:

1. ZooKeeper 已经保证了自我的高可用。

2. 基于 ZooKeeper,切换或者选举过程实现比较简单。

3. ZooKeeper 可以有多用途

原文始发于微信公众号(二进制跳动):存储架构模式之复制架构:主备、主从、双机切换、集群选举

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/167100.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!