亚马逊AWS官方博客
量入为出,借助 headless 集群构建 Amazon Aurora 全球数据库,实现高性价比的跨区域容灾
前言
许多企业在部署关键应用时,为了保障业务连续性,需要预防区域级别中断的风险,因此需要制定跨区域的灾难恢复(DR)策略。在设计跨区域 DR 策略时,需要在数据恢复点目标(RPO)、恢复时间目标(RTO)和成本之间衡量。在企业降本增效的大环境下,具有高性价比的灾难恢复(DR)策略,是诸多企业在选择合适的业务连续性容灾方案时的重要考量因素。
恢复时间目标(RTO)和恢复点目标(RPO)是容灾规划中的两个关键指标。RTO(Recovery Time Objective)指在发生灾难后,将中断的业务流程恢复到可接受服务级别所需的最长时间。例如,如果某业务在下午 2 点遭受中断,且 RTO 为 2 小时,那么必须在下午 4 点前将业务恢复到可接受水平。 RPO(Recovery Point Objective)指在发生灾难时,业务可以容忍的最大数据损失量,通常以时间来衡量。例如,如果某业务在下午 2 点遭受灾难,且 RPO 为 2 小时,那么可以接受在中午 12 点至下午 2 点这 2 小时内的数据损失。企业通常根据业务中断对运营的影响程度,来制定适当的 RTO 和 RPO 目标,并据此规划相应的容灾策略和解决方案,以最大限度降低业务中断带来的风险和损失。 总的来说,RTO 关注的是将业务恢复到可运行状态所需的时间,而 RPO 则侧重于在容灾发生时可以容忍的数据损失量。两者是容灾规划中不可或缺的重要指标。
在本博客中,我们将探讨使用 Amazon Aurora Global Database Headless(全球数据库 headless 集群)作为数据库跨区域方案的一部分所带来的好处,以及如何实现跨区域灾难恢复。
Amazon Aurora Global Database Headless(全球数据库无头集群)是指没有数据库实例的从集群。这种配置可以降低 Aurora 全球数据库的费用。在 Aurora 数据库集群中,计算和存储是分离的。如果没有数据库实例,不需要收取计算费用。同时可以按需在从区域添加数据库实例到 Aurora 集群,以供用户和应用所使用。
借助 headless 集群构建 Amazon Aurora 全球数据库实现跨区域容灾的特点:
- 降低成本,提供高性价比容灾方案 – 从区域 Aurora 全球数据库从集群,不需要配置数据库实例 ,节省了数据库实例成本;同时可以按需增加数据库实例到 headless 集群,由于 Aurora 采用计算和存储分离架构,可快速分钟级(通常小于 10 分钟)扩展数据库实例。
- 保持跨区域低延迟复制,跨区域复制通常低于 1 秒 – Aurora 利用物理复制、跨区域的骨干网络和存储层实现跨区域复制,即使是 headless 配置,依然可以保持通常低于 1 秒的跨区域复制延迟。
- 满足低 RPO/RTO 满足构建容灾系统的需求,可实现数据库容灾切换时保障 RPO 通常小于 1 秒和 RTO 通常小于 10 分钟。
我们将在本博客后续章节,部署和测试 headless 集群,来验证以上特点。
Aurora 全球数据库 headless 集群架构
Aurora 全球数据库集群采用 headless 集群配置,跨越至少两个区域。主区域由一个读写 Aurora 数据库实例(兼容 MySQL 或 PostgreSQL)、一个或多个相同或不同可用区中的只读副本,以及存储集群数据的集群卷组成的 Aurora 数据库集群。从区域包含存储从集群数据的集群卷。Aurora 利用 AWS 骨干网络的专用基础设施跨区域复制数据,网络延迟通常低于一秒。最多可以为 Aurora 全球数据库创建五个从区域。下图是 Aurora 全球数据库 headless 集群架构图:
Aurora 全球数据库使用 Aurora 专门构建的存储层来处理跨区域的复制,headless 从集群使用的存储复制与主区域 Aurora 集群保持同步。
可以通过以下方式之一创建具有 headless 配置的 Aurora 全球数据库:
- 将 Aurora 集群转换为采用 headless 配置的全球数据库 — 可以通过添加没有 Aurora 数据库实例的从集群,来创建具有 headless 配置的 Aurora 全球数据库。
- 修改现有 Aurora 全局集群以创建 headless 配置 — 要将从集群转换为 headless 配置,可以在 Aurora 全球数据库从集群中删除 Aurora 数据库实例,从而将从集群将转换为 headless 集群。
部署和测试
将 Aurora 集群转换为 headless 配置的 Aurora 全球数据库
可以将已有的区域数据库转换成全球数据库(例如已有区域在美东一 添加美东二为从区域):
在控制台上查看已经创建好的全球数据库的配置:
将已经创建好的全球数据库转换成 headless 配置(切换到从区域,选择从区域数据库实例,实施删除):
在控制台上查看全球数据库 headless 配置(0 instances):
在 CloudWatch 定义 Dashboard 监控 headless 从区域复制延迟
因为在从区域没有数据库实例,所以无法查看 CloudWatch 监控指标,需要在 CloudWatch Dashboard 中定义全球数据库 headless 配置,所要监控的主从区域复制延迟指标:AuroraGlobalDBReplicationLag。
在 CloudWatch 控制台创建 Cloudwatch Dashboard aurora-global-db-headless:
在 us-east-2 区域查找 CloudWatch 指标,选择 RDS->DBClusterIdentifier->aurora-global-db-headless-cluster-1->选择 AuroraGlobalDBReplicationLag->Create Widget:
查看创建好的 widget,点击 save(保存到 Dashboard):
在主区域进行密集写操作 查看 headless 从区域复制延迟
安装和通过 sysbench 对主区域集群进行密集写压测:
链接到 Aurora 主集群,创建 demo 数据库:
准备 sysbench 测试数据:
执行 sysbench 只写测试,并发线程=300,执行 10 分钟:
观测 CloudWatch 指标 AuroraGlobalDBReplicationLag,可以看到 300 并发只写测试,headless 部署主从区域复制延迟非常稳定,大致在 120 毫秒,可验证数据库跨区域复制通常小于 1 秒,数据库容灾切换时 RPO 通常也会小于 1 秒:
主区域发生故障 如何将 headless 从集群 Failover 变成主集群
方式 1:通过 AWS Cli 和控制台操作 – 实现将 headless 从集群 Failover 变成主集群
在从区域通过 AWS Cli 增加 DB instance 到从集群:
记录创建 DB instance 创建时间:15:29 开始,15:37 结束 – 大致 8 分钟。
在 RDS 控制台上将从集群提升为独立集群,完成 failover:
记录从集群提升时间:15:41 开始,15:43 结束 – 大致从 console 上观察是 1-2 分钟。
方式 2:通过示例的自动化脚本 – 一键式实现将 headless 从集群 Failover 变成主集群
克隆 github 资料库:
执行自动化脚本 – 一键式实现将 headless 从集群 Failover 变成主集群:
参数说明:
- -g –> Global database identifer
- -R –> Secondary cluster region
- -r –> Secondary cluster identifer
- -s –> Added DB instance size
- -n –> Added DB instance AZ
在此示例中添加一个数据库实例类型为 db.r6g.large 到 us-east-2 区域的 Aurora 全球数据库从集群:aurora-global-db-headess-cluster-1 数据库实例所在的 AZ 为:us-east-2b。
在添加数据库实例节点到 headless 集群和提升从集群为独立集群时,需要人工输入两次 y 确认执行。
自动化脚本输出如下:
可以看到执行一键式自动化脚本,实现将 headless 从集群 Failover 变成主集群:执行时间为 316秒,大致在 5 分钟,可验证 Aurora 全球数据库,容灾切换时 RTO 通常小于 10 分钟。
在 RDS 控制台上查看已经提升为独立集群的从集群: