Azure 数据资源管理器的可靠性

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

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

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

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

对于生产工作负荷，建议执行以下步骤来提高Azure 数据资源管理器群集的可靠性：

  • 部署完整的群集。 对于生产工作负荷，请部署完整的群集。

  • 启用可用性区域支持。 Azure 数据资源管理器支持可用性区域。 启用可用性区域支持时，服务会跨多个可用性区域分配计算节点，并使用区域冗余存储（ZRS）存储数据。 此配置可提高可用性区域故障的复原能力。

可靠性体系结构概述

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

逻辑体系结构

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

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

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

物理体系结构

Azure 数据资源管理器群集有两个主要层，适用于其可靠性配置：

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

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

Diagram，显示具有两层逻辑体系结构的 Azure 数据资源管理器 群集。

有关详细信息，请参阅 Azure 数据资源管理器工作原理。

暂时性故障的复原能力

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

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

若要在使用Azure 数据资源管理器时构建暂时性故障的复原能力，请遵循以下做法：

应对可用区故障的弹性

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

Azure 数据资源管理器支持两种类型的可用性区域配置：

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

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

    Azure 数据资源管理器群集的Diagram，计算节点和存储分布在多个区域。

  • 区域： 在群集上启用可用性区域时，可以选择一个单独的区域。 Azure将所有计算节点放入该区域。 此配置是区域性（单区域）集群。 区域群集可以减少异常延迟敏感工作负荷的延迟，因为所有计算节点在同一区域中运行，但它不提供对区域中断的复原能力。

    重要

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

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

    显示使用单个可用区的 Azure 数据资源管理器 群集的示意图。

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

要求

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

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

  • 完整群集： 完整群集提供可用性区域支持。

注意事项

区域选择： 对于计算节点，可以选择要使用的可用性区域。 Azure管理存储区域放置，并且存储副本可能位于与计算节点不同的区域中。

Cost

启用可用性区域支持会产生 ZRS 的额外成本，其费率高于 LRS。 有关详细信息，请参阅 Azure 存储 定价。

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

配置可用性区域支持

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

    使用 Azure 门户创建启用可用性区域的群集时，该群集会自动实现区域冗余，并由 Azure 选择可用性区域。

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

    注释

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

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

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

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

  • 验证群集的可用性区域配置。 使用群集 的区域状态 属性（ zoneStatus REST API 中的属性）验证群集的可用性区域配置。 Zonal值表示群集使用可用性区域，但这并不意味着群集在单个区域中运行。

    若要确定群集是区域性还是区域冗余，请使用 zones 属性。 如果区域列表中只列出一个区域，则群集是区域性（单区域）。 如果列出了多个区域，则表示具有区域冗余。

容量计划和管理

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

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

跨区域的实例分布

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

所有区域正常时的行为

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

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

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

    • 区域冗余： 使用存储 ZRS 在可用性区域中同步复制数据，该存储提供高级别的数据一致性，并最大限度地减少区域故障期间数据丢失的风险。

    • 区域性： 数据采用存储 LRS 进行存储，这意味着三个副本都可能位于同一个可用区中。

区域故障期间的行为

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

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

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

    • 分区级： 你负责检测群集所使用的可用区中的故障。 你还需对你决定发起的响应负责，例如切换到你之前在另一个可用区创建的第二个集群。

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

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

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

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

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

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

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

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

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

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

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

区域恢复

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

测试区域故障

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

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

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

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

Azure 数据资源管理器群集部署到单个Azure区域中。 如果该区域变得不可用，群集及其数据将不可用。

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

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

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

备份和还原

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

Azure 数据资源管理器不提供本机备份和还原功能。 如果需要备份数据，请考虑以下方法：

  • 连续导出 会定期将数据导出到外部存储，并为支持的数据类型提供 一次性 导出。

  • 将数据导出到云存储 支持手动将数据导出到外部存储。

  • 从上游源（如数据湖）将原始数据引入到 Azure 数据资源管理器，并且可以单独备份。

对意外删除的抵抗力

Azure 数据资源管理器包括多种机制来帮助防止意外删除群集、数据库、表和外部表：

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

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

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

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

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

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

若要了解即将到来的计划内维护，请使用 Azure 服务运行状况。

服务级别协议

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

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

相关内容

  • Last updated on