Azure Data Explorer中的业务连续性和灾难恢复使企业能够在发生中断时继续运营。 本文讨论可用性（区域内）和灾难恢复。 其中详细介绍了可靠Azure Data Explorer部署的本机功能和体系结构注意事项。 并详细说明了如何在发生人为错误时进行恢复，介绍了高可用性，以及多个灾难恢复配置。 这些配置取决于可恢复性要求，例如恢复点目标（RPO）和恢复时间目标（RTO）、所需的工作量和成本。
缓解中断性事件
人为错误
人为错误是不可避免的。 用户可能会意外删除群集、数据库或表。
意外删除群集或数据库
意外删除群集或数据库是无法恢复的操作。 作为Azure Data Explorer资源所有者，可以通过启用在Azure资源级别提供的删除 lock 功能来防止数据丢失。
意外删除表
允许具有表管理员权限或更高权限的用户删除表。 如果其中一个用户意外删除了一个表，则可以使用 .undo drop table 命令将其恢复。 若要使此命令成功，必须先在 保留策略 中启用 恢复性 属性。
意外删除外部表
外部表是 Kusto 查询架构中的实体，用来引用存储在数据库外部的数据。 删除外部表只会删除表元数据。 可以通过重新执行表创建命令来恢复它。 使用 软删除 功能以在用户配置的时间段内防止文件/blob被意外删除或覆盖。
Azure Data Explorer的高可用性
高可用性是指Azure Data Explorer、其组件和Azure区域内的基础依赖项的容错。 这种容错避免了实现中的单一故障点 (SPOF)。 在Azure Data Explorer中，高可用性包括持久性层、计算层和前导跟踪器配置。
持久性层
Azure Data Explorer使用Azure Storage作为持久持久性层。 Azure Storage自动实现容错，默认设置提供的是数据中心内的本地冗余存储（LRS）。 保留三个副本。 如果一个副本在使用过程中丢失，则在不中断的情况下部署另一个副本。 区域冗余存储（ZRS）能够进一步提高复原能力，它可智能地在 Azure 区域的可用性区域之间放置副本，以实现最大的容错能力，但需支付额外费用。 Azure Data Explorer 群集部署到可用区时，会自动配置启用 ZRS 的存储。
计算层
Azure Data Explorer是分布式计算平台，可以根据规模和节点角色类型具有两到多个节点。 在预配时，选择可用区在可用区间分布节点部署，以实现区域内的最大复原能力。 可用性区域故障不会导致完全中断，而是导致性能下降，直到恢复区域。
先导-后继群集配置
Azure Data Explorer提供可选的后随功能，使其他后随群集可以对领导者群集的数据和元数据进行只读访问。 先导群集中的更改，例如 create、append 和 drop 将自动与后继群集同步。 虽然领导者可以跨Azure区域，但后续群集应托管在与领导者相同的区域中。 如果主群集关闭或数据库或表意外删除，则从群集将失去访问权限，直到在主群集中恢复访问权限。
Azure可用性区域的中断
Azure 可用性区域是在同一 Azure 区域内的一组独特的物理位置。 它们可以保护Azure Data Explorer群集的计算和数据免受部分区域故障的影响。 区域故障是一种与可用性相关的情况，因为它发生在区域内。
将Azure Data Explorer群集固定到与其他已连接Azure资源相同的区域。 有关如何启用可用区的详细信息，请参阅 创建群集。
注意事项
创建群集时可以部署到可用区，或者可以以后进行迁移。
Azure数据中心中断
Azure 可用性区域附带成本，部分客户选择在没有区域冗余的情况下进行部署。 通过这种Azure Data Explorer部署，Azure数据中心中断会导致群集故障。 因此，处理Azure数据中心中断与Azure区域中断的情况相同。
Azure 区域故障
Azure Data Explorer不会针对整个Azure区域的中断提供自动保护。 为了最大程度地减少此类服务中断对业务的影响，Azure配对区域中部署了多个Azure Data Explorer群集。 根据恢复时间目标 (RTO)、恢复点目标 (RPO) 以及工作量和成本，有多种灾难恢复配置。 可以通过Azure Advisor建议和 autoscale 配置来优化成本和性能。
灾难恢复配置
本部分详细介绍了多个灾难恢复配置，具体取决于可恢复性要求（RPO 和 RTO）、所需的工作量和成本。
恢复时间目标 (RTO) 是指发生中断后恢复所用的时间。 例如，RTO 为 2 小时意味着应用程序必须在中断后两小时内恢复正常运行。 恢复点目标 (RPO) 是指在发生中断后，在中断期间丢失的数据量超过允许的阈值之前可经过的时间间隔。 例如，如果 RPO 是 24 小时，而应用程序的数据是从 15 年前开始的，则它们仍处于商定的 RPO 参数范围内。
在规划灾难恢复时，引入、处理和特选过程需要预先进行精心设计。 引入是指从各种源集成到Azure Data Explorer中的数据;处理是指转换和类似活动;策展是指具体化视图、导出到数据湖等。
以下是常用的灾难恢复配置：
主动-主动-主动配置
此配置也称为始终在线。 对于无法容忍中断的关键应用程序部署，应跨Azure配对区域使用多个Azure Data Explorer群集。 在所有群集中并行设置引入、处理和管理。 不同区域的群集 SKU 必须相同。 Azure确保在Azure配对区域中逐步推出和错开更新。 Azure区域中断不会导致应用程序中断。 可能会遇到一些延迟或性能下降的情况。
| 配置 | RPO | RTO | 工作量 | 成本 |
|---|---|---|---|---|
| 主动-主动-主动-n | 0 小时 | 0 小时 | 较低 | 最高 |
主动-主动配置
此配置与 active-active-active 配置 相同，但仅涉及两个 Azure 配对区域。 配置双重引入、处理和整理。 将用户路由到最近的区域。 不同区域的群集 SKU 必须相同。
| 配置 | RPO | RTO | 工作量 | 成本 |
|---|---|---|---|---|
| 主动-主动 | 0 小时 | 0 小时 | 较低 | 高 |
主动-热备用配置
活动-热点配置与活动-活动配置在双重引入、处理和数据整理方面相似。 当备用群集在线进行数据引入、处理和管理时，它无法执行查询。 备用群集不需要与主群集位于同一 SKU 中。 它可以是较小的 SKU 和规模，这可能会导致其性能较低。 在灾难场景中，用户会被重定向到备用群集，你可以选择纵向扩展该群集以提高性能。
| 配置 | RPO | RTO | 工作量 | 成本 |
|---|---|---|---|---|
| 主动-热备用 | 0 小时 | 低 | 中等 | 中等 |
按需数据恢复配置
此解决方案提供最低的可恢复性（最高 RPO 和 RTO），是成本最低且工作量最高的解决方案。 在此配置中，没有数据恢复群集。 配置将特选数据（除非也需要原始数据和中间数据）连续导出到配置了异地冗余存储 (GRS) 的存储帐户。 如果发生灾难恢复情况，则会启动群集数据恢复。 此时将应用 DDL、配置、策略和流程。 使用引入属性kustoCreationTime从存储中引入数据，以覆盖默认的系统时间作为引入时间。
| 配置 | RPO | RTO | 工作量 | 成本 |
|---|---|---|---|---|
| 按需数据恢复群集 | 最高 | 最高 | 最高 | 最低 |
灾难恢复配置选项摘要
| 配置 | 可恢复性 | RPO | RTO | 工作量 | 成本 |
|---|---|---|---|---|---|
| 主动-主动-主动-n | 最高 | 0 小时 | 0 小时 | 较低 | 最高 |
| 主动-主动 | 高 | 0 小时 | 0 小时 | 较低 | 高 |
| 主动-热备用 | 中等 | 0 小时 | 低 | 中等 | 中等 |
| 按需数据恢复群集 | 最低 | 最高 | 最高 | 最高 | 最低 |
最佳做法
无论选择哪种灾难恢复配置，请遵循以下最佳做法：
- 所有数据库对象、策略和配置都应该保存在源代码管理中，这样就可以从发布自动化工具中将其发布到群集。
- 设计、开发和实现验证例程，以确保从数据角度来看所有群集都是同步的。 Azure Data Explorer支持 跨群集连接。 在表之间进行简单的行数统计可以帮助验证。
- 发布过程应该包括可确保群集镜像实现的治理检查和制衡措施。
- 充分了解从头开始构建群集所需完成的所有操作。
- 创建部署单元清单。 你的列表符合你的需求，但应包括：部署脚本、引入连接、BI 工具和其他重要配置。