Amazon Redshift跨区域灾难恢复策略解析

现代企业信任Amazon Redshift来驱动他们最严苛的分析工作负载，并且日益需要跨区域灾难恢复来保护这些工作负载免受区域性中断的影响。从实时欺诈检测和监管报告到处理每日数百万笔交易的面向客户的仪表板，组织从第一天起就设计弹性。例如，在金融服务领域，监管框架日益要求数据基础设施具备地理冗余，使跨区域灾难恢复（DR）不仅是技术考量，更是合规要求。精心设计的灾难恢复策略可确保您的分析基础设施在区域中断时保持可用和响应迅速，从而保护收入流、维持监管地位并保持客户信任。

在我们之前的博客文章中，使用 Amazon Redshift 实施灾难恢复，我们涵盖了节点级恢复、可用区（AZ）恢复、多可用区部署、跨区域备份设置、CNAME实施、Amazon Redshift Spectrum和Redshift 数据共享的考量。

在本文中，我们将详细介绍跨区域灾难恢复的核心概念，介绍评估需求的框架，然后深入探讨 Amazon Redshift 的三种主要灾难恢复策略：主动-被动、主动-主动和混合方法。对于每种策略，我们都会介绍架构、权衡、实施指南和成本考量，以便您为工作负载做出明智的决策。

什么是灾难恢复？

灾难恢复包括一套策略、工具和程序，使组织能够在事件发生后恢复关键系统和数据。它有助于在 AWS 区域中断、意外数据删除、基础设施故障或安全事件等事件期间维持业务连续性。

任何灾难恢复策略都依赖于两个关键指标：

• 恢复点目标（RPO）：可接受的最大数据丢失量，以时间衡量。RPO 为 30 分钟意味着您可以容忍从源系统可复现的最多 30 分钟的数据丢失。
• 恢复时间目标（RTO）：在宣布灾难后恢复业务运营之前对停机时间的最大容忍度。RTO 为 30 分钟意味着您的系统必须在故障发生后 30 分钟内完全运行。

这两个数字驱动所有灾难恢复架构决策，理解它们有助于澄清各种灾难恢复策略之间的权衡。

评估您的灾难恢复需求

在选择策略之前，您需要评估工作负载的关键性以及组织对数据丢失和停机的容忍度。问问自己：

• 停机对业务有何影响？如果您的 Amazon Redshift 集群支持面向客户的应用程序、监管报告或实时风险计算，即使一小时的停机也可能不可接受。如果支持每日刷新的内部仪表板，2 小时的 RTO 可能是可以接受的。
• 数据能否从上游源回填？如果您的数据管道来自 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 或 Amazon Simple Storage Service (Amazon S3)，您也许可以在故障转移后重放事件，从而放宽 RPO 要求。如果数据是就地生成的或无法重放，您需要更紧密的复制。
• 您的监管义务是什么？金融服务、医疗保健和政府工作负载通常有监管机构规定的明确 RPO/RTO 要求。这些是不可谈判的底线。
• 您的成本容忍度是多少？主动-主动架构会使基础设施支出翻倍。主动-被动方法可显著节省成本，但恢复时间略长。

下表可作为快速参考，将您的需求与灾难恢复策略匹配：

以下决策树帮助您根据工作负载的 RPO 和 RTO 要求选择正确的灾难恢复策略。

跨区域最佳实践

无论您选择哪种策略，以下实践普遍适用于 Amazon Redshift 灾难恢复实施。

使用多区域 AWS KMS 密钥：使用多区域 AWS Key Management Service (AWS KMS) 密钥加密您的 Amazon Redshift 集群和 S3 数据。这避免了在故障转移期间重新加密数据的需要，这可能会显著增加 RTO。请注意，AWS KMS 在同一分区内的每个 AWS 区域仅允许一个多区域密钥的副本。这是一个服务级约束。在大多数灾难恢复场景中，每个区域一个多区域密钥就足够了，因为该区域中的所有资源可以共享同一个密钥。

使用基础设施即代码实现自动化：使用基础设施即代码（IaC）定义所有灾难恢复区域基础设施，例如 Terraform、AWS CloudFormation或AWS Cloud Development Kit (AWS CDK)。IaC 支持区域间的一致性，消除手动配置错误，并在故障转移期间实现快速预置。对于使用 Terraform Enterprise 的组织，请验证您的工作区配置支持多区域部署。

实施全面监控。尽可能使用 Amazon CloudWatch 警报：

• S3 跨区域复制的状态和延迟。
• AWS Glue 目录复制状态。
• Amazon DynamoDB 全局表复制延迟。

早期检测复制失败至关重要。在灾难期间发现的静默复制失败远比主动发现的糟糕得多。有关详细的指标监控配置，请参阅Amazon CloudWatch 警报用户指南。

每季度测试。未定期测试的灾难恢复计划在实际灾难中更有可能失败。每季度进行故障转移测试，将实际 RTO 和 RPO 与目标进行比较。验证故障转移后的数据一致性。记录经验教训，并相应更新运行手册。

使用 Amazon Redshift Spectrum。对于冷数据和温数据层，您可以直接在 Amazon S3 中查询数据，而无需将其加载到 Amazon Redshift 中。这可以减少故障转移期间的数据恢复需求。请记住，您的集群和 S3 存储桶必须位于同一区域。在灾难恢复区域中重新创建指向已复制 S3 数据的外部 schema。对于不使用 Spectrum 的 Amazon Redshift Serverless 端点和 Redshift 预置集群，灾难恢复策略依赖于快照复制和跨区域恢复。无论您使用 RA3 还是 RG（Graviton）节点类型，这些原则都适用。

策略 1：使用快照复制的主-被动

在主-被动配置中，您的主要 AWS 区域运行端到端工作负载，包括数据摄取、处理以及通过 Amazon Redshift 提供数据。Amazon Redshift 使用其内置的跨区域快照功能将数据复制到灾难恢复区域。在灾难期间，您可以从灾难恢复区域中复制的快照恢复集群。

RPO：15 分钟加上数据复制时间 | RTO：1–2 小时 | 成本：低

Amazon Redshift 预置集群中的快照

默认情况下，Amazon Redshift 预置集群每 8 小时拍摄一次新快照，或者在任何单个节点上检测到 5 GB 数据变化时（以先到者为准）拍摄新快照。5 GB 阈值是针对每个节点独立评估的。

Amazon Redshift 在您的主区域和灾难恢复区域提供集群的自动快照，无需额外存储成本。当 Amazon Redshift 跨区域复制快照时，您将承担数据传输费用。初始跨区域复制是全量快照传输。后续复制是增量的，仅传输自上次快照以来更改的块，这大大减少了传输时间和成本。

何时自定义自动快照计划

您可以覆盖默认设置并设置自定义计划，最低频率为每小时一次。然而，这仅在一种情况下有用：

何时使用手动快照

如果您需要保证RPO 小于 1 小时（例如，每 15 分钟），或需要将备份保留超过 35 天，请使用手动快照，并按您想要的频率进行计划。手动快照会产生额外存储费用，但会一直保留到显式删除。

自动快照与手动快照的比较

架构

下图说明了主-被动灾难恢复架构。

主-被动策略使灾难恢复区域中的计算资源保持就绪，以便在需要时从快照启动。在复制数据时，请考虑作为端到端数据管道一部分的其他服务。在 Amazon Redshift 数据共享模型中，生产者集群创建并拥有数据，而消费者集群通过数据共享从生产者读取数据。在灾难恢复场景中，首先在灾难恢复区域恢复生产者，然后恢复消费者集群以提供读取工作负载。

• Amazon S3 经常与 Amazon Redshift 一起使用。为了完整的数据弹性，使用 Amazon S3 跨区域复制（S3 CRR）在 Amazon S3 中也复制数据。它将您的 S3 数据湖持续复制到灾难恢复区域，延迟几乎为零。对于 Apache Iceberg 表，我们建议使用 Amazon S3 Tables 的复制功能（Amazon S3 的一项能力），以确保数据和相关元数据（清单、快照）一致地复制到灾难恢复区域。
• 客户使用 AWS Glue Data Catalog 和 AWS Lake Formation 来编目和维护权限。阅读这篇关于如何使用 AWS Glue 和 AWS Lake Formation 构建多区域弹性数据架构的文章。
• 客户经常在数据管道架构中将 Amazon DynamoDB 与 Amazon Redshift 结合使用，以跟踪管道编排状态，例如作业 ID、处理时间戳、批处理完成标志和摄取检查点，这些检查点告诉您的管道哪些数据已处理。Amazon DynamoDB 全局表将此状态复制到两个区域，因此管道状态在灾难恢复区域中可用，并且您确切知道故障转移后从何处恢复处理。

灾难恢复区域（被动）组件：

• Amazon Redshift 集群准备好从快照恢复。
• AWS Lambda 函数及其数据转换管道代码已部署并准备就绪。
• Amazon MSK 基础设施以 IaC 定义但未预置。
• Amazon EMR 作业定义已准备好但未运行。

故障转移序列（20–60 分钟）：

1. 从最新的跨区域快照在灾难恢复区域恢复 Amazon Redshift 集群（这通常是耗时最长的步骤）。
2. 在灾难恢复区域预置并启动 Amazon MSK 集群。
3. 禁用 AWS Glue Catalog 的 S3 事件触发器（以防止分裂脑元数据更新）。
4. 启动 Amazon EMR 并恢复数据处理。
5. 恢复暂停的 Amazon Redshift 消费者集群。
6. 重新创建指向灾难恢复区域的 AWS Glue Catalog 的外部 schema。注意： Amazon Redshift 快照中包含的外部 schema、外部 schema 级权限以及对外部资源（例如 S3 路径、AWS Glue Catalog 数据库）的引用，包含对主区域资源的引用。请计划在故障转移手册中在您的灾难恢复区域重新创建这些内容。数据库用户、组及其内部权限随快照复制。请计划在故障转移手册中编写外部 schema 重新创建的脚本。
7. 将查询或应用程序服务端点更新到灾难恢复区域。
8. 更新 Lambda 数据转换管道，使其指向新的生产者端点。

何时选择主动-被动

• 您可以容忍 15 到 20 分钟的数据丢失。
• 1 到 2 小时的恢复时间目标对您的业务来说是可接受的。
• 成本优化是优先事项。
• 数据可以从上游来源（例如 Amazon MSK 主题保留）回填或重放。

策略 2：主动-主动多区域

在主动-主动配置中，您的主区域和灾难恢复区域同时运行完全可操作的数据管道。数据在两个区域中始终被摄取、处理和服务。故障转移变成了重定向流量而不是恢复基础设施的问题。这将恢复时间目标缩短到几分钟。

恢复点目标： 接近零 | 恢复时间目标： < 1 小时（通常为几分钟）| 成本： 高

架构

下图说明了主动-主动灾难恢复架构。主动-主动要求在两个区域中镜像您的整个管道，从摄取到服务。

实时复制层：

• Amazon MSK Replicator：实时将 Kafka 主题从主区域镜像到辅助区域。这是管道中最早的复制点，因此灾难恢复区域以最小的延迟处理相同的事件。
• Amazon DynamoDB Global Tables：在两个区域中进行活动状态跟踪，使管道控制和作业状态保持同步。
• 活动 Amazon EMR 处理：两个区域持续处理传入数据，在各自的 S3 数据湖和 AWS Glue Catalog 中保持最新状态。
• 活动 Amazon Redshift 生产者集群：两个区域持续摄取已处理的数据，保持几乎相同的仓库状态。
• 镜像数据转换管道：通过 DynamoDB 复制，在灾难恢复区域积极处理数据转换事件，保持派生数据的一致性。在主动-主动模型中，两个区域维护自己的 Amazon Redshift 集群，独立摄取相同的源数据，因此灾难恢复区域的 Amazon Redshift 已经拥有当前数据。镜像管道支持转换逻辑，派生数据集保持同步。

灾难恢复区域（活动）组件：

• Amazon Redshift 集群暂停但已准备就绪（可在几分钟内激活）。
• 任何 Amazon Redshift 数据共享在区域间定期同步。
• 外部 schema 处于活动状态并同步。
• 查询或应用程序服务端点已预先配置并测试。

故障转移序列（分钟）：

1. 将 Amazon MSK 消费者故障转移到灾难恢复区域的 Amazon MSK 集群。
2. 恢复灾难恢复区域中的 Amazon Redshift 消费者集群。
3. 更新查询或应用程序服务端点以指向灾难恢复区域。
4. 提升灾难恢复区域的 Lambda 数据转换管道函数作为主要函数。

因为灾难恢复区域的管道已经在运行，所以没有基础设施供应延迟。故障转移主要是配置更改。

成本考虑因素

主动-主动基本上使您的基础设施成本翻倍。您需要在两个区域同时运行完整的 Amazon MSK、Amazon EMR 和 Amazon Redshift 集群。对于大规模部署（1 PB 以上），这代表着一笔可观的持续投资。商业案例取决于停机成本是否超过重复基础设施的成本。对于面向客户或受监管的工作负载，这种计算通常有利于主动-主动。

何时选择主动-主动

• 您需要接近零的恢复点目标，并且不能容忍数据丢失。
• 恢复时间目标必须按分钟计算，而不是按小时。
• 您的分析基础设施直接影响面向客户的操作或监管合规性。
• 停机成本（财务、声誉、监管）超过重复基础设施的成本。
• 您有严格的服务水平协议。例如，零恢复点目标，并在 4 小时内提供全面的服务功能，包括数据摄取。

策略 3：混合 — 按数据关键性分层灾难恢复

仓库中的并非所有数据都同等重要。一些实时见解和监管报告要求接近零的恢复点目标，而历史趋势分析和归档的合规数据可以容忍数小时的恢复时间。混合方法对不同的数据层应用不同的灾难恢复策略，优化成本，同时保护最重要的内容。

恢复点目标： 因层而异 | 恢复时间目标： 30 分钟 – 2 小时 | 成本： 中

架构

下图说明了混合灾难恢复架构。

混合策略要求数据模型在 schema 或表级别支持清晰的分离，并为每一层应用不同的恢复目标。

第 1 层：热数据（主动-主动）：

• 实时仪表板、监管报告、面向客户的分析。
• 通过 Amazon MSK Replicator 和两个区域中的活动 Amazon Redshift 生产者实现接近零的恢复点目标。
• 恢复时间目标：分钟。

第 2 层：温数据（主动-被动）：

• 每日报告、历史趋势分析、内部运营数据。
• 恢复点目标：1 小时，通过每小时 Amazon Redshift 快照跨区域复制。
• 恢复时间目标：1 到 2 小时。

第 3 层：冷数据（仅 S3 复制）：

• 归档数据、长期合规存储、不常访问的历史数据。
• 恢复点目标：数小时（S3 CRR 使用标准复制延迟）。
• 恢复时间目标：2 小时以上（从 S3 恢复到 Amazon Redshift Spectrum 或新集群）。
• 对于此层，在灾难恢复区域没有活动的 Amazon Redshift 基础设施。

实施注意事项

• 您的数据模型必须支持在 schema 或表级别的清晰分离，以应用不同的恢复策略。为了实现每个数据层不同的恢复点目标/恢复时间目标，同时避免不必要的 表级维护复杂性，考虑为每个层级使用单独的集群或命名空间，或结合使用集群快照和基于S3的备份（UNLOAD）以实现更细粒度的表级恢复。
• 可能需要工作负载管理（WLM）队列或单独的集群来隔离热、温和冷工作负载。
• 监控必须分别跟踪每个层级的复制延迟。
• 故障转移运行手册必须感知层级。操作员需要知道首先恢复哪些系统。

何时选择混合架构

• 您具有明确定义的数据层级，且关键性差异显著。
• 您的数据模型已经支持或可以重构为支持热/冷分离。
• 您希望使用双活保护关键任务数据，同时为不太关键的工作负载管理成本。
• 您的组织具备管理分层故障转移流程的运营成熟度。

测试您的灾难恢复策略

安排季度性灾难恢复测试，包括：

1. 按照记录的运行手册执行故障转移。
2. 从灾难声明到完全运行状态的RTO测量。
3. RPO验证以确认数据一致性。
4. 应用程序测试以确认连接性。
5. 故障恢复程序文档。
6. 经验教训和运行手册更新。

结论

Amazon Redshift的灾难恢复并非一刀切的问题。正确的策略取决于您的RPO和RTO要求、数据的严重性、从上游源重放数据的能力以及成本承受能力。

• 主动-被动 为大多数分析工作负载提供了一种经济高效的途径，可实现10-20分钟的RPO和1-2小时的RTO。
• 主动-主动 为关键任务服务提供接近零的RPO和分钟级RTO，这些服务的停机成本超过基础设施成本。
• 混合 允许您对正确的数据应用正确的保护级别，优化成本而不会影响最重要的事情。

无论您选择哪种策略，基本原则都相同：在管道早期复制，自动化基础设施，持续监控复制健康状况，并定期测试故障转移流程。灾难恢复不是一次性的项目，而是需要持续维护的实践。

后续步骤

• 探索Amazon Redshift跨区域快照复制 以开始使用快照复制。
• 了解Amazon MSK Replicator 用于主动-主动的Kafka主题镜像。
• 查看AWS上的工作负载灾难恢复 以了解更广泛的灾难恢复模式。
• 使用AWS Resilience Hub 来评估和提高您的Amazon Redshift工作负载的韧性。

关于作者