使用 Azure SQL 数据库弹性池的应用程序的灾难恢复策略

适用于：Azure SQL 数据库

Azure SQL 数据库具备许多功能，可在发生灾难性事件时保证应用程序的业务连续性。 弹性池和单一数据库支持相同类型的灾难恢复 (DR) 功能。 本文介绍了针对使用这些 Azure SQL 数据库 业务连续性功能的弹性池的几种灾难恢复策略。

本文使用以下规范 SaaS 独立软件供应商（ISV）应用程序模式：

基于现代云的 Web 应用程序为每位最终用户都预配了一个数据库。 ISV 拥有大量客户，因此会使用多个数据库，称为租户数据库。 由于租户数据库的活动模式通常不可预测，因此 ISV 通常使用弹性池，以使数据库成本在很长时间段内具有高度可预测性。 弹性池还简化了用户活动达到高峰时的性能管理。 除了租户数据库外，应用程序还使用多个数据库管理用户配置文件、安全性、收集使用模式等。单个租户的可用性不会影响整个应用的可用性。 但是，管理数据库的可用性和性能对应用程序的功能至关重要，如果管理数据库处于脱机状态，则整个应用程序也同样处于脱机状态。

本文探讨了涵盖多种场景的 DR 策略，从成本敏感型初创应用到具有严格可用性要求的应用。

方案 1. 关注成本的创业公司

我们是一家创业公司，非常关注成本问题。 我希望简化应用程序的部署和管理，并可为各个客户提供有限的 SLA。 但是我希望确保应用程序整体不会脱机。

为满足简单性要求，请将所有租户数据库部署到所选的 Azure 区域中的一个弹性池中，同时将管理数据库部署为异地复制的单一数据库。 对于租户的灾难恢复，请使用异地还原，无需额外付费。 为确保管理数据库的可用性，请使用故障转移组将数据库异地复制到另一区域（步骤 1）。 此方案中的灾难恢复配置持续成本等于辅助数据库的总成本。 下图说明了此配置。

如果主要区域发生中断，可以使用下图中的恢复步骤恢复应用程序的在线状态。

• 故障转移组启动管理数据库向 DR 区域的自动故障转移。 应用程序将自动重新连接到新的主要区域，将在 DR 区域中创建所有新帐户和租户数据库。 现有客户的数据将暂时不可用。
• 创建与原始池具有相同配置的弹性池 (2)。
• 使用异地还原创建租户数据库副本 (3)。 可以考虑通过最终用户连接或使用其他应用程序的特定优先级方案来触发单个还原。

此时，应用程序便已在 DR 区域中恢复在线状态，但某些客户会在访问数据时遇到延迟。

如果中断是暂时的，Azure 可能会在 DR 区域中先恢复主要区域，然后再完成所有数据库还原。 在这种情况下，请安排将应用程序移回主要区域。 此过程会采用下图所示的步骤。

• 取消所有未完成的异地还原请求。
• 将管理数据库故障转移到主要区域 (5)。 区域恢复后，旧的主数据库便已自动成为辅助数据库。 现在他们又互换了角色。
• 更改应用程序的连接字符串，使其重新指向主要区域。 现在会在主要区域中创建所有新帐户和租户数据库。 某些现有客户的数据将暂时不可用。
• 将 DR 池中的所有数据库设置为只读，确保无法在 DR 区域中对其进行修改 (6)。
• 对于自恢复以来已更改的 DR 池中的每个数据库，重命名或删除主池中的相应数据库 (7)。
• 将 DR 池中已更新的数据库复制到主池 (8)。
• 删除 DR 池 (9)

此时，主要区域中的应用程序将处于在线状态，且主池中的所有租户数据库都可用。

益处

此策略的主要优点在于数据层冗余的持续低成本。 Azure SQL 数据库会自动备份数据库，且无需支付任何额外成本、无需应用程序重写。 仅在还原弹性数据库时才产生成本。

权衡

权衡是指所有租户数据库的完全恢复将花费很长时间。 具体时间长短取决于在 DR 区域中启动还原的总数和租户数据库的总体大小。 即使您优先恢复某些租户而不是其他租户，您仍会与在同一区域内发起的所有其他恢复操作竞争，因为该服务会进行仲裁和限流，以尽量降低对现有客户数据库的整体影响。 此外，在 DR 区域中创建新的弹性池之前，无法启动租户数据库恢复。

方案 2. 具有分层服务的成熟应用程序

我是一个成熟的 SaaS 应用程序，其中包含分层服务产品/服务和不同的 SLA，适用于试用客户和付费客户。 对于试用客户，我不得不尽可能降低成本。 试用用户可能会遇到停机，但我希望尽量降低这种情况发生的可能性。 对于付费客户来说，任何停机都可能导致客户流失。 因此，我希望确保付费客户始终能够访问其数据。

若要支持此方案，请通过将试用租户和付费租户放入不同的弹性池以将二者分开。 试用客户每个租户的 eDTU 或 vCore 更少，SLA 更低，恢复时间更长。 付费客户会被分入具有较高的每租户 eDTU 或 vCore 的池中并且 SLA 较高。 为了保证最低恢复时间，付费客户的租户数据库会进行异地复制。 下图说明了此配置。

如方案一所示，管理数据库将会非常活跃，因此应该为其使用异地复制的单一数据库 (1)。 这可以确保新的客户订阅、配置文件更新和其他管理操作具有可预测的性能。 管理数据库的主数据库所在的区域将会成为主要区域，而管理数据库的辅助数据库所在的区域则会成为 DR 区域。

付费客户的租户数据库在主区域中预配的 付费 池中拥有处于活动状态的数据库。 在 DR 区域中预配一个同名的辅助池。 每个租户都会被地理复制到辅助池 (2)。 这使得能够通过故障转移快速恢复所有租户数据库。

如果主要区域发生中断，可以使用下图中的恢复步骤恢复应用程序的在线状态：

• 立即将管理数据库故障转移到灾难恢复区域 (3)。
• 更改应用程序的连接字符串，使其指向 DR 区域。 现在会在 DR 区域中创建所有新帐户和租户数据库。 现有试用客户的数据将暂时不可用。
• 将付费租户的数据库故障转移到 DR 区域的池中以立即还原其可用性 (4)。 由于故障转移只是快速的元数据级更改，因此可以考虑一种优化方案：由终端用户连接按需触发各个故障转移。
• 如果辅助池的 eDTU 大小或 vCore 值之所以低于主池的相应值，是因为辅助数据库在处于辅助角色期间仅需具备处理更改日志的容量，那么现在请立即提高池容量，以承载所有租户的全部工作负载 (5)。
• 在 DR 区域中，为试用客户的数据库创建一个与现有弹性池名称和配置相同的新弹性池 (6)。
• 创建试用客户池后，请使用异地还原将各个试用租户数据库还原到新池 (7)。 考虑通过最终用户连接或使用其他应用程序的特定优先级方案来触发单个还原。

此时，应用程序在 DR 区域中重新联机。 所有付费客户均可访问其数据，而试用客户则会在访问数据时遇到延迟。

在 DR 区域中还原了应用程序 之后 ，如果 Azure 恢复了主要区域，则可以决定在该区域继续运行应用程序或故障回复到主要区域。 如果在故障转移过程完成之前主区域已恢复，请考虑立即进行故障回切。 此故障回复采用下图所示的步骤：

• 取消所有未完成的异地还原请求。
• 故障转移管理数据库 (8)。 区域恢复后，原主数据库会自动变为辅助数据库。 现在，它再次成为主数据库。
• 故障转移付费租户数据库 (9)。 同样，区域恢复后，旧的主数据库便会自动成为辅助数据库。 现在它们再次成为主节点。
• 将 DR 区域中已更改的还原试用数据库设置为只读 (10)。
• 对于自恢复以来已更改的试用客户 DR 池中的每个数据库，重命名或删除试用客户主池中的相应数据库 (11)。
• 将 DR 池中已更新的数据库复制到主池 (12)。
• 删除DR池 (13)。

益处

该策略的主要优点在于它为付费客户提供了最高的 SLA。 它还确保在试用 DR 池创建后，新的试用即可解除阻塞。

权衡

代价在于，这种设置会使租户数据库的总成本增加，增幅相当于付费客户辅助灾难恢复池的成本。 此外，如果辅助池大小不同，付费客户会在故障转移后体验较低性能，直到完成 DR 区域的池升级才能恢复往常性能。

方案 3. 具有分层服务的地理分布式应用程序

我在使用一款具有分层服务功能的成熟 SaaS 应用程序。 我希望为付费客户提供非常严格的 SLA，并尽可能降低发生服务中断时造成影响的风险，因为即使是短暂的中断也会引起客户不满。 付费客户始终可以访问其数据，这一点至关重要。 试用都是免费的，试用期间不会提供 SLA。

若要支持此方案，请使用三个单独的弹性池。 在两个不同区域预配两个相同大小的池，使其中的每个数据库都具有较高的 eDTU 或 vCore，以容纳付费客户的租户数据库。 包含试用租户的第三个池可以为每个数据库分配较低的 eDTU 或 vCore，并可在两个区域中的任意一个区域预配。

为了确保在发生中断时实现最短的恢复时间，付费客户的租户数据库会进行异地复制，并分布在这两个区域中，且每个区域承载 50% 的主数据库。 同样，每个区域会占用辅助数据库的 50%。 这样，如果某个地区离线，只有50% 付费客户的数据库受到影响，需要切换。 其他数据库将保持不变。 下图说明了此配置：

如前面的方案所示，管理数据库将会非常活跃，因此应该将其配置为异地复制的单一数据库 (1)。 这确保了新的客户订阅、配置文件更新和其他管理操作的可预测性能。 区域 A 将是管理数据库的主要区域，而区域 B 将用于恢复管理数据库。

同样会对付费客户的租户数据库进行异地复制，但将在区域 A 和区域 B 之间拆分主数据库和辅助数据库 (2)。 这样，受故障影响的租户主数据库可以切换到另一个区域并变得可用。 另一半的租户数据库完全没有受到影响。

下图说明了区域 A 发生中断时要采取的恢复步骤。

• 立即将管理数据库故障转移至区域 B (3)。
• 更改应用程序的连接字符串，使其指向区域 B 的管理数据库。修改管理数据库以确保将在区域 B 中创建新的帐户和租户数据库，同时确保可在此处找到现有租户数据库。 现有试用客户的数据将暂时不可用。
• 将付费租户的数据库故障转移到区域 B 的池 2 中以立即还原其可用性 (4)。 由于故障转移是一种快速的元数据级别更改，因此可以考虑一种优化方案，即由最终用户连接按需触发各个故障转移。
• 由于现在池 2 仅包含主数据库，池中的总工作负载会增加，因此可以立即增加其 eDTU 大小（5）或 vCore 数量。
• 在区域 B 中，为试用客户的数据库创建一个名称和配置均相同的新弹性池 (6)。
• 池创建完成后，使用异地还原将各个单独的试用租户数据库还原到该池中 (7)。 可以考虑通过最终用户连接或使用其他应用程序的特定优先级方案来触发单个还原。

此时，应用程序便已在区域 B 中恢复为在线状态。所有付费客户均可访问其数据，而试用客户则将在访问数据时遇到延迟。

恢复区域 A 后，需要确定是要为试用客户使用区域 B，还是故障回复到使用区域 A 中的试用客户池。一个条件可能是自恢复以来修改的试用租户数据库百分比。 无论做出何种决定，你都需要在两个池之间重新平衡付费租户。 下图展示了试用租户数据库故障切回到区域 A 时的流程。

• 取消所有未完成的异地还原请求以试用 DR 池。
• 故障转移管理数据库 (8)。 区域恢复后，旧的主数据库便已自动成为辅助数据库。 现在，它再次成为主数据库。
• 选择要故障回复到池 1 的付费租户数据库，并启动向其次要副本的故障转移 (9)。 区域恢复后，池 1 中的所有数据库便会自动成为辅助数据库。 现在，其中的 50 % 都再次成为主数据库。
• 将池 2 的大小缩减至原始 eDTU (10) 或原始 vCore 数量。
• 将区域 B 中的所有已还原试用数据库设置为只读 (11)。
• 对于自恢复以来已更改的试用 DR 池中的每个数据库，重命名或删除试用主池中的相应数据库 (12)。
• 将 DR 池中已更新的数据库复制到主池 (13)。
• 删除 DR 池 (14)。

益处

该策略的主要优点有：

• 它支持付费客户最严格的SLA，因为这确保停机不会影响超过50% 的租户数据库。
• 它确保在恢复期间一旦创建试用 DR 池，新的试用就会立即解除阻塞。
• 它实现了更有效地使用池容量，因为其已确保池 1 和池 2 中的 50% 辅助数据库活动量均少于主数据库的活动量。

权衡

主要权衡有：

• 对管理数据库执行的 CRUD 操作，对连接到区域 A 的最终用户而言，其延迟低于连接到区域 B 的最终用户，因为这些操作是在管理数据库的主副本上执行的。
• 它需要对管理数据库进行更复杂的设计。 例如，每条租户记录都有一个在故障转移和故障恢复期间需要更改的位置标签。
• 在区域 B 中的池升级完成之前，付费客户的性能可能低于平常。

总结

本文重点介绍了关于 SaaS ISV 多租户应用程序使用的数据库层的灾难恢复策略。 你选择的策略基于应用程序的需求，例如业务模型、要提供给客户的 SLA、预算约束等。每个描述的策略概述了优势和权衡，以便你可以做出明智的决策。 此外，特定应用程序可能包括其他 Azure 组件。 因此，请查看其业务连续性指南并根据指南安排数据库层的恢复。 若要深入了解如何管理 Azure 中的数据库应用程序恢复，请参阅设计灾难恢复云解决方案。

后续步骤

• 若要了解 Azure SQL 数据库的自动备份，请参阅 Azure SQL 数据库自动备份。
• 有关业务连续性概述和应用场景，请参阅业务连续性概述。
• 若要了解如何使用自动备份进行恢复，请参阅 从服务启动的备份中还原数据库。
• 若要了解更快的恢复选项，请参阅活动异地复制和故障转移组。
• 若要了解如何使用自动备份进行存档，请参阅 数据库复制。