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

使用 Azure 数据资源管理器创建业务连续性和灾难恢复解决方案

本文详细介绍了如何通过在不同的 Azure 区域中复制 Azure 数据资源管理器资源、管理活动和数据引入，为应对 Azure 区域性中断做准备。 提供使用 Azure 事件中心进行数据引入的示例。 此外还针对不同的体系结构配置讨论了成本优化。 有关体系结构注意事项和恢复解决方案的详细信息，请参阅业务连续性概述。

为应对 Azure 区域性中断做准备以保护你的数据

Azure 数据资源管理器不支持针对整个 Azure 区域的中断进行自动保护。 在自然灾害（如地震）期间，会发生这种中断。 如果你需要一个用于灾难恢复的解决方案，请执行以下步骤以确保业务连续性。 在这些步骤中，需在两个 Azure 配对区域中复制群集、管理活动和数据引入。

1. 在两个 Azure 配对区域中创建两个或更多个独立的群集。
2. 复制所有管理活动，例如，在每个群集上创建新表或管理用户角色。
3. 以并行方式将数据引入每个群集。

创建多个独立的群集

在多个区域中创建多个 Azure 数据资源管理器群集。 请确保在 Azure 配对区域中创建至少两个这样的群集。

下图显示的是副本，三个群集位于三个不同的区域中。

复制管理活动

复制管理活动，使每个副本中具有相同的群集配置。

1. 在每个副本上创建相同的项，如下所示：

   • 数据库：可以使用 Azure 门户或我们的 SDK 之一来创建新数据库。
   • 表
   • 映射
   • 策略

2. 在每个副本上管理身份验证和授权。

   

使用事件中心引入功能的灾难恢复解决方案

完成为应对 Azure 区域性中断做准备以保护你的数据后，你的数据和管理活动会分发到多个区域。 如果某个区域发生服务中断，则 Azure 数据资源管理器将能够使用其他副本。

使用事件中心设置引入

要将数据从 Azure 事件中心引入到每个区域的 Azure 数据资源管理器群集，请先复制每个区域中的 Azure 事件中心设置。 然后，将每个区域的 Azure 数据资源管理器副本配置为从相应的事件中心引入数据。

注意

通过 Azure 事件中心/IoT 中心/存储引入非常可靠。 如果某个群集在一段时间内不可用，则它稍后会追赶进度并插入任何挂起的消息或 blob。 此过程依赖于检查点设置。

如下图所示，数据源向所有区域的事件中心生成事件，每个 Azure 数据资源管理器副本都会使用这些事件。 数据可视化组件（如 Power BI、Grafana 或 SDK 支持的 WebApps）可以查询其中一个副本。

优化成本

现在，你可以使用下面的一些方法优化副本：

• 创建按需数据恢复配置
• 启动和停止副本
• 实施高度可用的应用程序服务
• 在主动-主动配置中优化成本

创建按需数据恢复配置

复制和更新 Azure 数据资源管理器设置会导致成本随副本数量线性增加。 为了优化成本，你可以实施体系结构变体来平衡时间、故障转移和成本。 在按需数据恢复配置中，通过引入被动 Azure 数据资源管理器副本实现了成本优化。 只有当主要区域（例如区域 A）中发生灾难时，才会启用这些副本。 区域 B 和 C 中的副本不需要全天候处于活动状态，因而大大降低了成本。 但在大多数情况下，这些副本的性能不如主要群集。 有关详细信息，请参阅按需数据恢复配置。

在下图中，只有一个群集从事件中心引入数据。 区域 A 中的主要群集执行连续数据导出来将所有数据导出到某个存储帐户。 次要副本有权使用外部表访问数据。

启动和停止副本

可以使用以下方法之一启动和停止次要副本：

• Power Automate 的 Azure 数据资源管理器连接器（预览版）

• Azure 门户中“概览”选项卡上的“停止”按钮。 有关详细信息，请参阅停止和重启群集。

• Azure CLI：

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>"

实施高度可用的应用程序服务

创建 Azure 应用程序服务 BCDR 客户端

本部分介绍了如何创建 Azure 应用程序服务，该服务支持与单个主要的和多个辅助的 Azure 数据资源管理器群集进行连接。 下图展示了 Azure 应用程序服务设置。

提示

在同一服务中的副本之间建立多个连接可以提高可用性。 此设置不仅仅在发生区域性中断的情况下有用。

1. 使用此应用程序服务样板代码。 为了实施多群集客户端，已经创建了 AdxBcdrClient 类。 使用此客户端执行的每个查询都将首先发送到主要群集。 如果出现故障，则查询将发送到次要副本。

2. 使用自定义应用程序见解指标来度量性能，并请求将内容分发到主要群集和辅助群集。

测试 Azure 应用程序服务 BCDR 客户端

我们使用多个 Azure 数据资源管理器副本运行了测试。 在模拟主要和辅助群集的服务中断后，可以看到应用程序服务 BCDR 客户端的行为符合预期。

Azure 数据资源管理器群集分布于西欧（2xD14v2 主要副本）、东南亚和美国东部 (2xD11v2)。

注意

响应时间较慢是由不同的 SKU 和全球查询导致的。

执行动态或静态路由

使用 Azure 流量管理器路由方法对请求进行动态或静态路由。 Azure 流量管理器是一个基于 DNS 的流量负载均衡器，可以用来分发应用程序服务流量。 此流量针对全球 Azure 区域中的服务进行了优化，同时提供高可用性和快速响应能力。

还可使用基于 Azure Front Door 的路由。 有关这两种方法的比较，请参阅使用 Azure 的应用程序交付套件进行负载均衡。

在主动-主动配置中优化成本

使用主动-主动配置进行灾难恢复会线性增加成本。 成本包括节点、存储、标记成本以及因带宽增加的网络成本。

使用优化的自动缩放来优化成本

使用优化的自动缩放功能为辅助群集配置水平缩放。 它们应进行维度设置，以便能够处理引入负载。 一旦无法访问主群集，辅助群集将获得更多流量，并根据配置进行缩放。

与在所有副本上使用相同的水平和垂直缩放相比，在此示例中使用优化的自动缩放节省了大约 50% 的成本。

相关内容

• 业务连续性和灾难恢复概述