Azure Data Explorer的可靠性

Azure Data Explorer是一种分析服务，可用于引入、存储和查询大量数据，且延迟较低。 它通常用于需要快速查询大型数据集的日志分析、遥测和时序工作负荷。

使用 Azure 时，可靠性是共同的责任。 Azure提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。

本文介绍如何使Azure Data Explorer应对各种潜在中断和问题，包括暂时性故障、可用性区域故障和区域范围的故障。 它还介绍了备份和还原选项以及服务维护的复原能力，并重点介绍了有关Azure Data Explorer服务级别协议（SLA）的关键信息。

提高可靠性的生产部署建议

对于生产工作负荷，建议执行以下步骤来提高Azure Data Explorer群集的可靠性：

  • 部署完整的群集。 Azure Data Explorer提供免费群集以供试用。 对于生产工作负荷，请部署完整的群集。
  • 启用可用性区域支持。 Azure Data Explorer支持可用性区域。 启用可用性区域支持后，计算节点分布在多个可用性区域，并使用区域冗余存储来存储数据。 此配置可提高可用性区域故障的复原能力。

可靠性体系结构概述

本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。

逻辑体系结构

部署的主要资源是 一个群集，表示引入、存储和查询数据所需的基础结构。 使用群集，可以创建数据库，而 数据库又包含 表。

显示包含两个数据库的群集的关系图，每个数据库都有一组表。

群集执行 引入 以从其他数据源检索数据，并将其加载到群集中的表中。 然后，可以使用 Kusto 查询语言 （KQL） 语法 查询 数据。 集群还有一组管理操作可以执行。

物理体系结构

Azure Data Explorer群集有两个主要层，适用于其可靠性配置：

  • Compute layer： Azure Data Explorer 是分布式计算平台，可以根据规模和节点角色类型，具有两到多个节点虚拟机（VM）。 节点处理数据引入和查询处理工作。 你看不到也无法直接管理节点虚拟机。 平台会自动管理实例创建、运行状况监视和替换不正常的节点。 将群集 配置为使用可用性区域时，节点分布在不同的数据中心之间。

  • Storage 层： Azure Data Explorer使用Azure Storage作为持久持久性层。 Azure Storage自动提供容错，默认设置在数据中心内提供本地冗余存储（LRS）。 保留三个副本。 如果一个副本在使用过程中丢失，则在不中断的情况下部署另一个副本。 将群集 配置为使用多个可用性区域时，副本分布在不同的数据中心之间。

显示一个包含计算节点和多份数据的群集图。

有关详细信息，请参阅 Azure Data Explorer工作原理。

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。

与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。

若要在使用Azure Data Explorer时构建暂时性故障的复原能力，请遵循以下做法：

应对可用区故障的弹性

可用性区域 是 Azure 区域内在物理上独立的若干数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。

Azure Data Explorer支持两种类型的可用性区域配置：

  • 区域冗余（建议）： 在群集上启用可用性区域时，群集的节点分布在多个区域。 Azure管理跨所选可用性区域的节点分布，并处理对可用性区域故障的检测和响应。 区域冗余群集能够抵御可用性区域的故障。

    将群集配置为区域冗余时，将使用Azure Storage区域冗余存储（ZRS）存储数据，该存储跨多个可用性区域同步复制数据至少三个副本。

    Diagram 显示Azure Data Explorer群集的区域冗余部署，计算节点和存储分布在多个区域。

  • 区域： 在群集上启用可用性区域时，可以选择一个单独的区域。 Azure将所有计算笔记放入该区域。 这是一个 区域 （单区域）群集。 如果工作负荷异常延迟敏感，此配置有时可能会有所帮助，但不会为区域中断提供复原能力。

    重要

    仅当跨区域延迟太高而无法满足需求时，才建议固定到单个可用性区域，并且验证延迟是否不符合要求。 区域资源本身不能提供对可用区中断的复原能力。 若要提高区域资源的复原能力，需要将单独的资源显式部署到多个可用性区域，并配置流量路由和故障转移。 有关详细信息，请参阅 区域资源和区域复原能力。

    区域选择仅适用于计算节点。 对于区域群集，存储数据继续使用 LRS，并且可能存储在计算节点的不同区域中。

    图示显示 Azure Data Explorer 群集的分区部署，所有计算节点均位于单个区域，并具有区域冗余存储。

如果未启用可用性区域，该群集为“非区域性”（nonzonal），这意味着 Azure 会为每个节点和数据选择可用性区域。 如果区域中的任何可用性区域发生中断，则可能会影响群集的节点、数据或两者。 不建议使用非区域配置，因为它不提供针对可用性区域中断的保护。

要求

  • 区域支持：可用性区域支持在支持可用性区域的 Azure 区域中可用。

    但是，某些计算节点类型和大小仅在特定区域或区域中的特定区域可用。

  • 完整群集： 完整群集提供可用性区域支持。 它不适用于 免费群集。

注意事项

区域选择： 对于计算节点，可以选择要使用的可用性区域。 存储区域的分配由Microsoft管理，存储副本可能会被置于与计算节点不同的区域中。

Cost

启用可用性区域支持会产生区域冗余存储的额外成本，该存储的计费速率高于本地冗余存储。 有关详细信息，请参阅 Azure Storage 定价。

无论是否使用可用性区域支持，计算节点都按相同的费率收费。 有关详细信息，请参阅 Azure Data Explorer 定价。

配置可用性区域支持

  • 创建具有可用性区域支持的新群集：创建新的Azure Data Explorer群集时，可以启用可用性区域支持。 有关详细信息，请参阅创建群集和数据库。

    使用 Azure 门户创建启用了可用性区域的群集时，会自动进行区域冗余设计，Azure 选择区域。

    若要自行选择区域或创建区域群集，请使用其他部署方法，例如Azure Resource Manager API 或Bicep。 在大多数情况下，我们建议创建区域冗余群集，并使用该区域中的所有区域。

    注释

    选择要使用的可用性区域时，实际上是在选择逻辑可用性区域。 如果在不同的Azure订阅中部署其他工作负荷组件，他们可能会使用不同的逻辑可用性区域编号来访问相同的物理可用性区域。 有关详细信息，请参阅 物理和逻辑可用性区域。

  • 在现有群集上启用可用性区域（预览）： 可以迁移现有非区域群集以使用可用性区域。 此功能以预览版提供。 有关详细信息，请参阅 迁移群集以支持多个可用性区域。

  • 重新配置现有群集上的可用性区域（预览版）： 可以更改用于群集的区域。 此功能以预览版提供。 有关详细信息，请参阅 迁移群集以支持多个可用性区域。

  • 在现有群集上禁用可用性区域支持： 使用可用性区域配置群集后，无法将群集更改为不使用可用性区域。

  • 验证群集的可用性区域配置： 可以使用群集 的区域状态 属性（ zoneStatus REST API 中的属性）来验证群集的可用性区域配置。

    如果值为此值 Zonal，则表示群集已配置为使用可用性区域。 但是，群集可能是区域化或区域冗余的。 若要确定哪一项，请使用 zone 属性。 如果区域列表中只列出一个区域，则群集是区域性（单区域）。 如果列出了多个区域，则表示实现了区域冗余。

容量计划和管理

当可用性区域不可用时，该区域中的任何节点可能暂时不可用，这会减少群集的计算容量，直到区域恢复为止。

如果群集无法容忍容量丢失，请考虑 超额配置 群集。 此方法允许解决方案容许某些容量丢失并继续正常运行，而不会降低性能。 但是，在过度预配群集时，群集可能跨区域具有不均衡的节点数。

跨区域的实例分布

群集的计算层使用最佳方法将实例均匀分布到所选区域。

所有区域正常时的行为

本节介绍为支持可用性区域而配置群集时可以预期的情况，并确保所有区域都正常运行。

  • 跨区操作：正常操作期间，Azure Data Explorer 使用所有可用的计算节点进行数据摄入、查询处理和其他操作。 无论其可用性区域如何，工作都分布在节点之间。

  • 跨区域数据复制： 跨区域数据复制行为取决于群集使用的可用性区域配置。

    • Zone-redundant： 数据通过使用 Azure Storage区域冗余存储跨可用性区域同步复制。 这提供高级别的数据一致性，并最大限度地减少区域故障期间数据丢失的风险。

    • Zonal： 数据存储使用本地冗余存储Azure Storage，这意味着这三个副本可能位于单个可用性区域中。

区域故障期间的行为

本部分介绍为可用区支持配置群集时可以预期的情况，以及当其中一个区域发生中断时会遇到的问题。

  • 检测和响应： 检测和响应的责任取决于群集使用的可用性区域配置。

    • Zone-redundant： Azure检测可用性区域故障并管理Azure Data Explorer的响应。 无需执行任何操作即可启动区域故障转移。

    • 区域性： 你负责检测影响你的群集所使用的可用区的故障。 你还负责任何你决定启动的响应，例如切换到之前在不同可用区中创建的第二个集群。

  • Notification： Azure不会在区域关闭时自动通知你。 但是，可以使用 Azure Service Health 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。

  • 活动请求： 依赖于失败区域中计算或存储资源的活动请求可能会终止，客户端应重试。 按照 暂时性故障处理指南确保应用程序已准备好。

  • 预期数据丢失： 预期的数据丢失取决于群集使用的可用性区域配置。

    • 区域冗余： 可用性区域中断期间不会发生数据丢失，因为数据跨区域同步复制。

    • 纬 向： 数据在区域恢复之前不可用。 在包含所有存储副本的区域永久丢失的可能性不大的情况下，数据可能会永久丢失。

  • 预期的停机时间： 预期的停机时间取决于群集使用的可用性区域配置。

    • 区域冗余： 将流量重定向到正常的可用性区域时，可能会出现短暂的服务中断。 按照 暂时性故障处理指南确保应用程序已准备好。

    • 纬 向： 在可用性区域恢复之前，群集的计算节点不可用。 在发生区域故障期间，可能无法访问群集的数据。

  • 分配： 流量重新路由行为取决于群集使用的可用性区域配置。

    • Zone-redundant： Azure Data Explorer将新请求路由到剩余正常区域中的计算和存储资源。

    • 纬 向： 在可用性区域恢复之前，群集不可用。

区域恢复

当发生故障的可用性区域恢复时，Azure重新创建该区域中的群集节点和存储副本，并还原所有区域中的正常流量分布。 无需客户采取任何操作。

测试区域故障

用于测试区域故障的选项取决于群集使用的可用性区域配置。

  • 区域冗余：Azure 数据资源管理器的可用区故障转移与恢复完全由 Azure 管理。 无需启动或验证可用性区域故障进程。

  • 纬 向： 若要部分模拟区域中断期间所有计算节点丢失的情况，可以停止群集。 可以使用此方法来验证您自身的区域宕机监测和故障转移流程的各个环节。

对区域范围的故障的复原能力

Azure Data Explorer群集部署到单个Azure区域中。 如果该区域变得不可用，群集及其数据将不可用。

用于复原的自定义多区域解决方案

为了最大程度地减少区域中断的业务影响，可以在多个区域中部署单独的Azure Data Explorer群集。 每个群集都是独立的，你负责管理每个群集，以及协调区域之间的数据复制、流量路由和故障转移。

可以在不同类型的多区域群集配置之间进行决定，每个配置都支持不同级别的恢复时间、潜在的数据丢失、工作量和成本。 可以为支持延迟和数据驻留要求的每个群集选择Azure区域。 有关可以遵循的多区域群集配置和模式的详细信息，请参阅Azure区域的输出。

备份和还原

对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。

Azure Data Explorer不提供本机备份和还原功能。 如果需要执行数据备份，可以考虑以下方法：

  • 连续导出，该导出会定期将数据导出到外部存储，并且仅支持导出受支持的数据 一次 。
  • 数据导出到云存储，使你能够手动将数据导出到外部存储。
  • 从上游源（如数据湖）将原始数据引入到 Azure Data Explorer，并且可以单独备份。

对意外删除的抵抗力

Azure Data Explorer包括多种机制来帮助防止意外删除群集、数据库、表和外部表：

  • 意外删除群集或数据库： 意外的群集或数据库删除是不可恢复的操作。 可以通过在群集或数据库资源上启用 删除锁 来防止数据丢失。

  • 意外删除表： 允许具有表管理员权限或更高权限的用户 删除表。 如果其中一个用户意外地删除了某个表，你可以使用 .undo drop table 命令恢复该表。 若要使此命令成功，必须先在 保留策略 中启用 恢复性 属性。

  • 意外的外部表删除：外部表 是引用存储在数据库外部的数据的 Kusto 查询架构实体。 删除外部表只会删除表元数据。 可以通过重新执行表创建命令来恢复它。

    对于 Azure Blob Storage 和 Azure Data Lake 外部表，可以使用 软删除 功能，在用户配置的时间内防止 blob 被意外删除或覆盖。

服务维护期间的系统弹性能力

Azure Data Explorer定期应用服务更新并执行例行维护。 Azure平台会在 SLA 中指定的可用性级别内自动处理这些活动。 遵循暂时性故障处理指南，确保您的应用程序在服务维护期间已经准备好应对偶尔的连接中断。

若要了解即将进行的维护，请使用 Azure Service Health。

服务级别协议

Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for online services。

若要符合Azure Data Explorer可用性 SLA 的条件，应用程序需要通过重试失败的请求来处理暂时性故障。

相关内容

  • Last updated on