通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

启用了 Azure Arc 的 SQL 托管实例的业务连续性和灾难恢复

  • 项目

启用了 Azure Arc 的 SQL 托管实例提供了业务连续性和灾难恢复 (BCDR) 功能，可帮助业务从中断中恢复并以最短的停机时间继续运营。

本文提供有关配置和管理业务连续性功能（如时间点还原、高可用性和灾难恢复）的关键设计注意事项和建议。

体系结构

以下体系结构图显示业务关键服务层中启用了 Arc 的 SQL 托管实例的高可用性功能，它支持停机时间几乎为零的故障转移。 如果主要实例发生故障，负载均衡器将停止向该实例发送流量。 然后，将某一个辅助实例提升为主实例，该新提升的实例开始接收来自负载均衡器的读写流量。 失败的实例重新联机后将被添加为辅助实例。

高度可用的业务关键实例的操作状态的示意图。

该示意图显示了主要副本中的故障以及将辅助副本提升为主要副本。

该示意图显示了主要副本故障。

该示意图显示了恢复的操作状态。

以下体系结构图显示如何将启用了 Arc 的 SQL 托管实例部署在两个不同站点中的两个独立 Kubernetes 群集上以进行灾难恢复。

该示意图显示跨两个群集在灾难恢复设置中部署的启用了 Azure Arc 的 SQL 托管实例。

以下体系结构图显示启用了 Arc 的 SQL 托管实例在启动灾难恢复故障转移时如何响应。

该示意图显示跨两个群集启动启用了 Azure Arc 的 SQL 托管实例灾难恢复故障转移。

设计注意事项

若要评估启用了 Azure Arc 的 SQL 托管实例对整体 BCDR 模型的影响，请查看业务连续性和灾难恢复中针对登陆区域的 BCDR 建议。 请注意，业务连续性和灾难恢复仅侧重业务连续性的设计建议，但实例的高可用性和复原能力还取决于底层 Kubernetes 基础结构的可用性。

时间点还原

  • 为恢复点目标 (RPO) 和恢复时间目标 (RTO) 定义目标。

  • 确定要在支持的保留期限制内保留和恢复备份多长时间。

  • 考虑对存储的影响以及增加备份保留期所产生的成本。 默认保持期为 7 天。 在此期间内，最多可以恢复 7 天，并且大约每五分钟会获得一个完整备份、一个每日差异备份和多个事务日志备份。

  • 考虑对备份的永久性卷使用哪个存储类。 有关指导，请参阅启用了 Azure Arc 的 SQL 托管实例的存储规程。

  • 考虑数据大小如预期和保留期按配置时备份的永久性卷的大小。

  • 有关存储的最佳做法，请参阅启用了 Azure Arc 的 SQL 托管实例的存储规程。

  • 备份始终在主要副本上执行。 确定分配给实例的资源时，请考虑备份和恢复过程对性能的影响。

  • 请将数据库的时间点还原不能覆盖现有数据库纳入考虑。 但数据库的时间点还原可将数据恢复到同一实例上的新数据库。

  • 如果应用程序在恢复过程中处于联机状态，请考虑完全恢复数据库所需的其他步骤。

  • 考虑将数据库恢复到多副本实例上所需的其他步骤，如将数据库恢复到多副本实例上中所述。

  • 确定数据库管理员用于配置和恢复备份的工具。 有关详细信息，请参阅连接到启用了 Azure Arc 的 SQL 托管实例。

高可用性

  • 查看工作负载的可用性要求并确定最适合部署启用了 Arc 的 SQL 托管实例的服务层：

    • 在常规用途服务层级中，只有一个副本可用，高可用性是通过 Kubernetes 业务流程来实现。
    • 在“业务关键”服务层级中，除了 Kubernetes 业务流程以原生方式提供的内容外，启用了 Azure Arc 的 SQL 托管实例还提供了一个包含的可用性组。

  • 考虑常规用途服务层级中因仅存在一个副本而可能导致的停机对业务的潜在影响。

  • 考虑要在业务关键服务层级中部署多少副本（一到三个）。

  • 在具有两个或多个副本的业务关键服务层级中部署实例时，可以将辅助副本配置为可读。 确定要在业务关键服务层级中部署的辅助副本的数量。 有关更改数量的详细信息，请参阅配置可读辅助副本。

  • 通过使用可选参数 --sync-secondary-to-commit，决定通过提交业务关键服务层中事务所需的次要副本数优先于可用性。 如果副本之间存在连接问题，则主要副本可能不会提交任何事务：

    • 在双副本配置中，必须在两个副本上提交事务，以便主要副本接收成功消息。
    • 在三副本配置中，三个副本中至少有两个必须提交事务才能返回成功消息。

  • 决定是否要将特定副本指定为主要副本。 有关指定主要副本的详细信息，请参阅首选的主要副本。

  • 决定要使用哪种 Kubernetes 服务类型，LoadBalancer 或 NodePort。 如果使用负载均衡器，则应用程序可以重新连接到同一主终结点，Kubernetes 会将连接重定向到新的主终结点。 如果使用节点端口，则应用程序必须重新连接到新的 IP 地址。

灾难恢复

  • 在异地主站点和异地辅助站点中，启用了 Azure Arc 的 SQL 托管实例的实例在计算和容量方面必须相同，并部署到相同的服务层级中。

  • 创建可供托管实例的两个群集访问的灾难恢复配置时，请确定存储镜像证书的位置。

  • 考虑如何监视主要实例的停机时间以决定何时故障转移到辅助实例。

  • 每个实例都有自己的终结点。 考虑应用程序在故障转移时如何在中断最短的情况下访问主要终结点。

设计建议

以下部分列出了针对时间点还原、高可用性和灾难恢复的设计建议。

时间点还原

  • 部署启用了 Arc 的 SQL 托管实例的新实例时，请始终为备份定义存储类，避免默认为数据存储类。

  • 为备份卷使用支持 ReadWriteMany (RWX) 的存储类。 有关指导，请参阅启用了 Azure Arc 的 SQL 托管实例的存储规程。

  • 在开始还原操作之前，请使用 可选参数 --dry-run 首先验证操作是否成功。 有关详细信息，请参阅使用 az CLI 从某个时间点创建数据库。

  • 创建一个流程，将需要更长保留期的备份发送到 Azure 或其他本地冷存储。

  • 监视备份使用的存储，以确定是否可以适应更长的保留时间（如果需要）。

高可用性

  • 执行定期演练，以验证启用了 Arc 的 SQL 托管实例的实例的高可用性。 演练示例包括删除常规用途实例中的 pod 和业务关键实例中的副本发生故障。

  • 在业务关键层级中，按三副本配置而不是双副本配置部署实例，以实现几乎不丢失任何数据。

  • 为获得更好的可用性，在部署实例时使用 LoadBalancer 作为服务类型。

  • 查看启用了 Azure Arc 的 SQL 托管实例的高可用性限制。

  • 查看支持的可用性模式，根据高可用性需求决定要使用哪种模式。

  • 部署具有多个副本的业务关键实例时，将其中一个辅助副本用于“读取”工作负载。 应用程序连接字符串必须将辅助终结点指定为服务侦听器以重定向到辅助副本。 有关终结点的详细信息，请参阅获取主要和辅助终结点以及 AG 状态。

  • 若要了解监视实例可用性的最佳做法，请参阅管理和监视启用了 Azure Arc 的 SQL 托管实例。

灾难恢复

  • 确保启用了 Arc 的 SQL 托管实例的实例具有不同的主要站点和辅助站点名称，并且这些站点具有相同的共享名称值。

  • 执行定期灾难恢复演练，以验证故障转移过程。

  • 创建用于启动手动和强制故障转移的流程。

  • 若要了解监视群集运行状况的最佳做法以及何时需要进行故障转移，请参阅管理和监视启用了 Azure Arc 的 SQL 托管实例。

  • 在 DNS 服务器中为分布式可用性组的共享名称定义 DNS 记录，以避免在故障转移期间手动创建 DNS 记录。

后续步骤

有关混合和多云云旅程的详细信息，请参阅以下文章：