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

Azure 数据资源管理器中的业务连续性和灾难恢复使企业能够在发生中断时继续运营。 本文详细介绍了多个灾难恢复配置，具体取决于可恢复性要求（RPO 和 RTO）、所需的工作量和成本。

有关适用于 Azure 数据资源管理器 的可靠性选项的更多信息，包括可用性区域支持、备份和防止某些类型的人为错误，请参阅 Azure 数据资源管理器 中的可靠性。

灾难恢复配置

恢复时间目标 (RTO) 是指发生中断后恢复所用的时间。 例如，RTO 为 2 小时意味着应用程序必须在中断后两小时内恢复正常运行。 恢复点目标 (RPO) 是指在发生中断后，在中断期间丢失的数据量超过允许的阈值之前可经过的时间间隔。 例如，如果 RPO 是 24 小时，而应用程序的数据是从 15 年前开始的，则它们仍处于商定的 RPO 参数范围内。

在规划灾难恢复时，引入、处理和特选过程需要预先进行精心设计。 引入是指从各种源集成到Azure 数据资源管理器中的数据;处理是指转换和类似活动;策展是指具体化视图、导出到数据湖等。

以下是常用的灾难恢复配置：

• 主动-主动-主动（始终在线）配置
• 主动-主动配置
• 主-热备份配置
• 按需数据恢复群集配置

主动-主动-主动配置

此配置也称为始终在线。 对于无法容忍中断的关键应用程序部署，应跨Azure配对区域使用多个Azure 数据资源管理器群集。 在所有集群中并行设置数据摄取、处理和管理。 不同区域的群集 SKU 必须相同。 Azure确保在Azure配对区域内更新能够有序推出和分批部署。 Azure区域中断不会导致应用程序中断。 可能会遇到一些延迟或性能下降的情况。

主动-主动配置

此配置与 active-active-active 配置相同，但仅涉及两个 Azure 配对区域。 配置双重数据引入、处理和整理。 将用户路由到最近的区域。 不同区域的群集 SKU 必须相同。

主动-热备用配置

主动-热配置与主动-主动配置在双重导入、处理和管理方面相似。 当备用集群在线进行数据引入、处理和管护时，它无法被查询。 备用群集不需要与主群集位于同一 SKU 中。 它可以是较小的 SKU 和规模，这可能会导致其性能较低。 在灾难场景中，用户会被重定向到备用群集，你可以选择纵向扩展该群集以提高性能。

按需数据恢复配置

此解决方案提供最低的可恢复性（最高 RPO 和 RTO），是成本最低且工作量最高的解决方案。 在此配置中，没有数据恢复群集。 配置特选数据（除非还需要原始数据和中间数据）的连续导出，将其导出到配置了 GRS（异地冗余存储）的存储帐户。 如果发生灾难恢复情况，则会启动群集数据恢复。 此时将应用 DDL、配置、策略和流程。 使用引入属性 kustoCreationTime 从存储引入数据，以替代默认为系统时间的引入时间。

灾难恢复配置选项摘要

最佳做法

无论选择哪种灾难恢复配置，请遵循以下最佳做法：

• 锁定群集：将 Delete ARM 管理锁应用于群集。 这可以防止意外删除并防止基础结构即代码工具（如 Terraform）在修改只读属性时尝试删除和重新创建群集。 有关实现指南 ，请参阅“管理群集锁 ”。
• 所有数据库对象、策略和配置都应该保存在源代码管理中，这样就可以从发布自动化工具中将其发布到群集。 有关详细信息，请参阅 Azure DevOps对 Azure 数据资源管理器 的支持。
• 设计、开发和实现验证例程，以确保从数据角度来看所有群集都是同步的。 Azure 数据资源管理器支持 跨群集联接。 对不同表格进行简单的行数统计可以帮助验证。
• 发布过程应该包括可确保实现群集镜像的治理检查和均衡操作。
• 充分了解从头开始构建群集所需完成的所有操作。
• 创建部署单元清单。 你的列表符合你的需求，但应包括：部署脚本、引入连接、BI 工具和其他重要配置。

下一步