HA/DR 选项和注意事项 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

HA/DR 选项和注意事项

尽管 AWS 可用区或区域完全脱机的可能性极为罕见,但我们建议在发生灾难时采用多管齐下的备份和恢复方法,以实现冗余并最大限度地减少数据丢失。备份和恢复过程应包括适当的粒度级别,以达到工作负载的恢复时间目标(RTO)和恢复点目标(RPO)并支持业务流程,且通常取决于应用程序。就数据库而言, AWS 还支持 Microsoft 为实现高可用性和灾难恢复而提出的所有 SQL Server 设置和配置建议(HA/DR). Different editions of SQL Server support various HA/DR options, and you should consider special cases such as very large databases (VLDBs) on a case-by-case basis. As with any DR configuration, testing is essential to ensure that each application meets its service-level agreements (SLAs) for HA/DR. For your test/development环境,请考虑使用 SQL Server 开发者版,该版本是免费的,但有一些限制。

对于需要 15 分钟的 RPO 和 4 小时的 RTO 的用例,您可以考虑将以下 HA/DR 选项结合使用:

  • 带热备用模式的 SQL Server 本机 HA/DR 选项(数据库级别):有关其中一些架构的插图,请参阅本指南后面的 亚马逊上的 SQL Server EC2 架构图 章节。

    • 位于单个区域(同步提交模式)或多个区域(异步提交模式、基本可用性组)中的双节点、多可用区

    • 三节点(或更多)、多个区域中的多可用区(同步提交和异步提交模式)

    • 双节点、多可用区和多个区域的日志传送(每 5 分钟备份一次日志)

  • SQL Server 原生备份到 Amazon S3(数据库级别,仅限灾难恢复):完整备份(每天一次)

    • 差异备份(每 2-4 小时一次)。

    • 日志备份(每 5-10 分钟)。

    • 需要使用自定义脚本或诸如文件网关之类的选项进行备份并将其复制到 Amazon Simple Storage Service (Amazon S3),以实现高效的备份和传输。

    • 如果您有数百个数据库,则可以继续使用现有的备份工具(例如 Commvault 或 Litespeed)来高效管理备份并将其直接存储在 Amazon S3 中。

    • 使用带有 S3 复制时间控制 (RTC)Amazon S3 跨区域复制 (CRR),在 15 分钟的 SLA 内控制和监控对象复制。

    • 为了合规和节省成本,您还可以使用 S3 生命周期管理来移动和存储较旧的备份以进行长期存储。

    • 如果您获取 SQL Server 原生备份并定期将其移至 Amazon S3,则在发生灾难时,目标区域将随时提供备份。这样就无需传输备份或恢复快照。

    • 我们建议使用 SQL 本机备份压缩来减小文件大小。

  • AWS 快照(实例和卷级别,仅限 DR)

    • 亚马逊弹性计算云 (Amazon EC2) Amazon 系统映像 (AMI) 备份可从头开始重建数据库

    • 用于将 EBS 卷附加到亚马逊的亚马逊 Elastic Block Store (Amazon EBS) 卷快照 EC2

在中管理 HA/DR 资源 AWS Backup

AWS Backup是一项完全托管的服务,它能够创建备份计划和计划,并将高可用性/灾难恢复配置中涉及的 AWS 资源(例如用于创建快照的 Amazon EBS 卷和 Amazon)分配给这些备份计划。 EC2 AMIs您还可以使用 AWS Backup 安排这些 EBS 快照的多区域副本。为了获得最佳使用效果, AWS Backup 需要有效的资源标记机制才能到位。 AWS Backup 还支持通过 Windows 卷影复制服务 (VSS) 实现应用程序一致性备份,您可以将其用于 SQL Server。对于存储级别的保护,我们建议使用 EBS 快照。初始 EBS 快照已满,后续快照为增量快照。尽管 EBS 快照提供了存储级别的保护,但它们并不能取代提供恢复功能的基于 SQL Server 文件的本机备份。 point-in-time

用 AWS DMS 于 HA/DR

如果您正在寻找 SQL Server Always On 复制选项的替代方案,或者您有异构的源数据库和目标数据库,无论是在混合设置中还是在中 AWS,都可以通过以下方式使用 AWS Database Migration Service (AWS DMS)。

如果您在自我管理的环境中使用 AWS DMS SQL Server(托管在 Amazon EC2 或本地),则它支持两种模式的一次性和持续复制:使用 MS-REPLICATION(捕获对具有主键的表的更改)和 MS-CDC(捕获对没有主键的表的更改)。但是,如果您使用亚马逊关系数据库服务 (Amazon RDS) 作为来源 AWS DMS,则仅支持 MS-CDC。 AWS DMS 提供一系列源端点和目标端点,支持异构数据库引擎,并提供对复制过程的精细控制。也可以使用 AWS Schema Conversion Tool (AWS SCT) with AWS DMS 进行异构数据库迁移。 AWS SCT 自动执行架构级别的更改,并生成迁移准备情况和规划报告。

您可以将源数据库和目标数据库添加为中的端点 AWS DMS,如下图所示。该服务使用 MS-REPLICATION 或 MS-CDC 实现逻辑复制过程。如果您采用混合设置,则可以配置 AWS DMS 为在本地和之间进行持续复制 AWS。在切换期间,可以停止 AWS DMS 迁移任务,应用程序将能够毫不延迟地连接到已经与本地数据库同步的数据库。将 AWS DMS SQL Server 用作源有一些限制,AWS DMS 文档中概述了这些限制。

用 AWS DMS 于 HA/DR

在以下情况下,可以考虑使用原生 HA/DR 方法 AWS DMS 代替原生 HA/DR 方法:

  • 当您想节省许可成本时。例如,如果您仅将 SQL Server Enterprise 版等高级版本用于其 Always On 选项,则可以考虑 AWS DMS 改为进行设置,因为它可以提供逻辑复制选项,而无需支付企业版许可证的费用。

  • 当您有异构的来源和目标时。主节点和灾难恢复节点上的 SQL Server 版本无需匹配(在 AWS DMS 限制范围内),这提供了极大的灵活性。

  • 为了避免 Windows、SQL Server 群集以及分布式可用性组设置和管理的开销。 AWS DMS 提供了简单的设置和复制任务的便捷管理。

  • 适用于业务用例,例如近乎实时的传输(取决于复制实例、网络配置和数据量)、数据掩蔽、选择性筛选、架构/表映射(同构和异构)、迁移前评测和 JSON 支持。

  • 根据日志序列号 (LSNs)、时间戳和类似选项,根据需要轻松复制、停止和启动任务。

下图显示了 AWS DMS 如何提供复制支持的替代方法。在此配置中,源是 SQL Server Always On 可用性组群集,并 AWS DMS 使用更改数据捕获 (CDC) 选项将数据持续复制到不同 AWS 区域的目标。要获得最佳性能,必须确保复制实例的大小合适,并保留在源区域。

AWS DMS 与 CDC 配合使用,将数据持续复制到另一个区域

源引擎和目标引擎不必匹配。在图中,标记为 (1) 的主节点和辅助节点可以是单可用区或多可用区配置中的 SQL Server 集群。或者源可以是支持 MS-CDC 或 MS-REPLICATION 的单个 SQL Server 节点。

图中标记为 (2) 的目标数据库实例可以是 Amazon RDS、Amazon 上的任何版本的 SQL Server EC2,也可以是任何其他异构目标。它不必匹配主实例和辅助实例,也不必支持 Always On 可用性组。例如,源可以是 SQL Server Always On 可用性组集群,目标可以是兼容 Amazon Aurora PostgreSQL 的版本。

AWS Application Migration Service 用于灾难恢复

我们建议使用 lift-and-shift迁移到 AWS。 AWS Application Migration Service Application Migration Service 会持续将您的计算机(包括操作系统、系统状态配置、数据库、应用程序和文件)复制到目标 AWS 账户和首选区域的低成本暂存区。发生灾难时,您可以使用 Application Migration Service 在几分钟内自动启动数千台处于完全配置状态的计算机。

额外注意事项

以下列表列出了在设计 HA/DR 策略时应考虑的可能瓶颈。

  • 多区域节点设置中的带宽、延迟、网络复杂性和连接性。

  • Amazon EBS 或 Amazon EC2 快照的大小,以及使用 AWS Backup复制它们所花费的时间。

    • 亚马逊 EBS 和亚马逊 EC2 快照通过使用 AWS Backup存储在 Amazon S3 中。

    • 在当前快照完成之前,EBS 快照不会复制到 Amazon S3 中的目标区域。复制的持续时间还取决于卷的大小。

    • 快照完成后,99.99% 的对象复制快照的持续时间可以短至 15 分钟。但是,对于特定的用例和关键的大批卷,需要进行全面的测试。

  • 在目标可用区和区域中恢复 EBS 卷所需的时间。

  • 在目标可用区和区域恢复 Amazon EC2 映像所需的时间。

  • 如果是从头开始构建,则需要时间在目标可用区和地区为 Amazon EC2 映像或恢复的 EBS 快照预置基础设施。

  • 如果从头开始恢复,则需要时间在目标可用区和区域中恢复 SQL Server 本机完整备份、差异备份和日志备份。

  • 需要跨区域可用的应用程序和外部依赖项。

  • 对卷和上传到 Amazon S3 的文件大小的限制。