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

适用于：Azure SQL 数据库

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

本文使用以下规范 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. 具有分层服务的成熟应用程序

我在使用一款具有分层服务功能并针对试用客户和付费客户提供不同 SLA 的成熟 SaaS 应用程序。 对于试用客户，我不得不尽可能降低成本。 试用客户可能会遇到故障时间，但是我希望降低其发生的可能性。 对于付费客户，任何故障时间都可能导致客户不再续订。 因此，我希望确保付费客户始终能够访问其数据。

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

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

付费客户的租户数据库将具备主要区域所预配的“付费”池中的活动数据库。 预配与 DR 区域中的辅助池具有相同名称的辅助池。 将每位租户异地复制到辅助池 (2)。 这会使用故障转移来实现快速恢复所有租户数据库。

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

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

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

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

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

优势

该策略的主要优点在于它为付费客户提供了最高的 SLA。 它还确保一旦创建了试用 DR 池，系统会取消阻止新试用。

权衡

权衡是指此设置需对付费客户的辅助 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 数据库自动备份。
• 有关业务连续性概述和应用场景，请参阅业务连续性概述。
• 若要了解如何使用自动备份进行恢复，请参阅 从服务启动的备份中还原数据库。
• 若要了解更快的恢复选项，请参阅活动异地复制和故障转移组。
• 若要了解如何使用自动备份进行存档，请参阅 数据库复制。