选择高可用性和灾难恢复解决方案

概览

我们建议您为 AWS 上的 SQL Server 部署设计一种架构，既要满足您的业务需求，又能满足灾难恢复（DR）目标，包括恢复时间目标（RTO）和恢复点目标（RPO）。以下这些解决方案能够帮助您为在 Amazon Elastic Compute Cloud（Amazon EC2）上运行的 SQL Server 设计合适的架构，同时优化您的 SQL Server 工作负载的成本。

SQL Server Always On 可用性组

如果您将 SQL Server 企业版仅用于高可用性的 Always On 可用性组，则可以利用基本可用性组降级到 SQL Server 标准版。通过使用基本的可用性组而非 Always On 可用性组，您可以将成本降低 65% 至 75%。

设施特点：

限制

下图显示了 Windows Server 失效转移群集解决方案的示例架构。

SQL Server Always On 失效转移群集实例

您可以使用失效转移群集实例（FCI）来确保数据库的持续运行，同时最大限度地减少停机时间并降低数据丢失的风险。如果您希望您的 SQL Server 数据库具有高可用性，但又不想采用只读副本配置，那么 FCI 将为您提供一个可靠的解决方案。

与可用性组不同，FCI 无需使用 SQL Server 企业版即可提供可靠的失效转移解决方案。相反，FCI 只需要 SQL Server 标准版许可。您可以使用 FCI 将 SQL Server 的许可成本降低 65-75%。

请考虑以下事项：

以下图表显示了利用适用于 Windows File Server 的 FSx 的 SQL Server FCI 的示例架构。

SIOS DataKeeper

如果您计划在 AWS 上部署 SQL Server FCI，我们建议您考虑共享存储需求。传统的本地安装通常使用存储区域网络（SAN）来满足共享存储需求，但这在 AWS 上不是一个可行的选项。适用于 Windows File Server 的 Amazon FSx 是 AWS 上的 SQL Server FCI 的推荐存储解决方案，但它存在一些限制，致使无法在不同的 AWS 区域中添加集群服务器。

您可以使用 SIOS DataKeeper 创建涵盖可用区和区域的 SQL Server FCI，同时将成本降低 58-71%。SIOS DataKeeper 可以帮助您实现 FCI 的高可用性优势。这使得 SIOS DataKeeeper 成为了适用于各类组织的经济实惠且可靠的解决方案。

以下列举了使用 SIOS DataKeeper 的一些额外优势，请予以考虑：

以下图表展示了使用集群式虚拟 SAN 解决方案的 SQL Server FCI 的一个示例架构。

Always On 可用性组

您可以使用 Always On 可用性组来实现高可用性和灾难恢复的目的。您可以通过跨一个区域内的两个可用区部署 SQL Server 来实现高可用性。您可以通过跨区域扩展可用性组来实现灾难恢复。

以下图表展示了基于 Always On 可用性组的解决方案的示例架构。图中区域 1 中的副本采用了同步提交方式，这种方式能够实现可用性组的自动失效转移。区域 2 中的副本采用的是异步提交方式，这将需要对可用性组进行手动失效转移。

分布式可用性组

对于那些对可靠性或灾难恢复有着极高标准要求的任务关键型 SQL Server 部署而言，我们建议采用跨区域部署的方式。将您的可用性组分布到多个区域，是确保业务连续性、最大限度减少停机时间的最可靠解决方案。

该架构充分利用了适用于 Windows File Server 的 Amazon FSx 的各项功能，包括共享存储、同步块级复制以及 SQL Server FCI。这些功能使您能够创建一个跨多个可用区的高可用性 SQL Server 环境。通过在另一个区域复制这一设置，您将能够获得一个完全冗余的系统，该系统能够应对任何最严重的中断情况。该解决方案的与众不同之处在于其提供的灵活性和安全性。分布式可用性组独立于域的架构使得底层的 Windows 集群服务器能够加入不同的 Active Directory 域，而基于证书的身份验证则能为您的 SQL Server 环境提供最大程度的保护，并满足多区域 DR 策略的高 RTO 和 RPO 要求。有关构建多区域架构的信息，请参阅 AWS 架构博客》中的实地记录：利用 FCI 和分布式可用性组构建适用于 SQL Server 的多区域架构。

以下图表展示了采用分布式可用性组的多区域解决方案的示例架构。

日志传送

日志传送是一种经过验证、可靠且经济高效的解决方案，可在出现意外停机情况时保障您在不同区域中的数据库安全。几十年来，各组织一直采用日志传送的方式来保护其数据。

如果您在 AWS 上实施日志传送，则可以在几分钟内实现 RPO 和 RTO，具体取决于事务和日志传送作业的频率。在极不可能出现的极端情况下，如果某个区域突然无法访问，则日志传送能确保您的数据安全且可恢复。

以下列举了使用日志传送的一些额外优势，请予以考虑：

有关更多信息，请参阅 AWS 架构博客中的通过适用于 Windows 的 Amazon FSx 配置使用 SQL Server FCI 的日志传送功能扩展 SQL Server DR。

以下图表展示了日志传送解决方案的一个示例架构。

AWS Database Migration Service

您可以使用 AWS Database Migration Service（AWS DMS）根据您的应用程序需求设计 HA/DR 解决方案。AWS DMS 使您能够轻松地将数据复制到同一区域（HA）或不同区域（DR）的另一个 SQL Server 数据库中。这种方法在技术上是可行的，它能让您在 AWS 基础设施方面最大化您的投资，同时还能优化资源的利用效率。

AWS DMS 是一项经济高效的服务。您只需为传输过程中所使用的 CPU 资源以及任何额外的日志存储付费。这意味着，您可以从该解决方案中获益，同时无需承担过多额外费用。您可以使用 AWS DMS 来确保您的数据可用且可访问，同时还能将与许可及资源使用相关的成本降至最低。

以下图表展示了基于 AWS DMS 的解决方案的一个示例架构。

AWS Elastic Disaster Recovery

一些组织必须确保所有关键业务应用程序都已实施灾难恢复计划。过去，这些组织中有许多都大量投入资金用于传统的灾难恢复解决方案。这类方案要求您预先构建并维护一个完整的复制基础设施。这种方法成本高昂、耗时长且难以扩展。

现在，您可以使用 AWS Elastic Disaster Recovery 来省去预先构建灾难恢复基础设施的步骤。在 Elastic Disaster Recovery 中，灾难恢复设备仅在必要时才会启动。因此，您只需按实际使用量在您需要它时付费。这意味着您能够显著降低软件许可费用和高性能计算成本。

此外，灾难恢复解决方案的暂存区域还包含低成本的 Amazon Elastic Block Store（Amazon EBS）卷。EBS 卷进一步降低了预调配重复资源的成本。这使您能够降低总体的灾难恢复成本，同时仍能维护一个强大且可靠的灾难恢复方案，满足您的业务需求。您可以使用 Elastic Disaster Recovery 来专注于核心业务活动，与此同时，AWS 为您的灾难恢复解决方案处理底层基础设施。

对于 SQL Server，您可以将 Elastic Disaster Recovery 用作经济高效的灾难恢复选项。如果您使用主动式软件保障服务，那么在具有容错能力且高度可用的 SQL Server 架构中，被动节点的许可费用将包含在内。然而，您仍需支付计算费用才能让该被动服务器保持在线状态。借助 Elastic Disaster Recovery，主服务器可以复制到灾难恢复环境中，而无需保持软件保障的活跃状态，也无需支付灾难恢复的计算费用。这种节省组合可以将您的 SQL Server 灾难恢复成本降低 50% 或更多。

以下图表展示了基于 Elastic Disaster Recovery 的解决方案的一个示例架构。

有关更多信息，请参阅 AWS 博客上的如何在 Microsoft 工作负载上为使用 AWS Elastic Disaster Recovery 恢复的 DR 站点中的 SQL Server 设置高可用性。

成本比较

以下表格对本部分所介绍的 HA/DR 解决方案的成本进行了比较。为进行此次比较，我们做出了以下假设：

成本优化建议

我们建议您接下来采取以下步骤，以选择符合您组织需求的 HA/DR 解决方案：

其他资源