Azure Batch 中的可靠性

Azure Batch在Azure中运行大规模并行和高性能计算（HPC）批处理作业。 Batch 创建和管理计算节点池、安装要运行的应用程序，并计划要在节点上运行的作业。

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

本文介绍如何使Azure Batch对暂时性故障、计算节点故障、可用性区域故障、区域范围的故障和服务维护具有复原能力。 它还介绍了生产部署建议、Batch 可靠性体系结构、备份和还原，以及有关Azure Batch服务级别协议（SLA）的关键信息。

生产部署建议

对于生产工作负荷，请遵循Azure Batch的最佳做法，包括以下可靠性建议：

可靠性体系结构概述

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

逻辑体系结构

Azure Batch使用多种资源类型来运行批处理工作负荷。 这些资源的配置决定了工作负荷如何响应故障。

所有批处理和资源都与 Batch 帐户相关联。 Batch 解决方案使用以下逻辑组件：

• Batch 帐户： 与池、作业、任务和其他 Batch 资源关联的区域资源。 创建帐户并选择其区域、池分配模式和身份验证设置。

• 池： 运行任务的计算节点的集合。 池的配置定义其 VM 映像和大小、目标节点计数、缩放行为、网络和区域放置。 配置每个池以提供工作负荷所需的容量、放置和操作环境。 目标节点计数是请求的容量，但由于配额限制、容量约束或分配失败，分配的节点数可能较低。

• 作业和任务：作业管理任务的集合，并与池相关联。 任务会使应用程序或脚本在计算节点上运行。 您定义作业、任务、约束、依赖项、重试行为以及每个作业运行所在的池。

• 关联的存储帐户：可以选择链接到 Batch 帐户的Azure 存储帐户。 大多数 Batch 解决方案对应用程序文件、任务资源文件、输入数据和输出数据使用关联的存储帐户。

  将存储帐户链接到 Batch 帐户后，Batch 将它称为 自动存储帐户。 应用程序包需要 autostorage 帐户，还可以存储任务资源文件。

  Batch 解决方案的可靠性取决于其存储资源。 你负责在创建存储帐户时选择满足恢复要求的存储冗余配置。 将任务输出和其他持久数据从计算节点移到存储中。 有关Azure 存储可靠性选项的信息，请参阅Azure Blob 存储中的可靠性。

有关详细信息，请参阅 Batch 服务工作流和资源以及 Batch 帐户以及Azure 存储帐户。

物理体系结构

Azure Batch具有一个区域控制平面，它针对 Batch 帐户和其他 Batch 资源（例如池、作业和任务）处理管理操作。 它独立于运行任务的计算节点。

Azure Batch池使用Azure 虚拟机和虚拟机规模集。 计算节点是用于处理 Batch 工作负荷一部分的 VM。 每个节点都属于池，并执行 Batch 服务向其分配的任务。 Batch 节点代理在每个节点上运行，并在节点与 Batch 服务之间提供命令和控制接口。 计算节点及其本地存储是非持久性的。 节点离开池时，其操作系统和文件的更改将丢失。

Batch 帐户的池分配模式确定 Batch 在何处创建与计算和 VM 相关的资源：

• Batch 批处理池分配模式：Batch 在 Batch 服务管理的 Azure 订阅中分配资源。
• 用户订阅池分配模式： Batch 直接在包含 Batch 帐户的订阅中创建资源。

物理体系结构的责任划分如下：

• Microsoft：Microsoft运行区域 Batch 控制平面和服务基础结构。 Batch 根据池配置和可用容量预配计算节点、调度任务、监视节点运行状况，并在基础结构故障后尝试恢复节点。 Batch 可以重新排队中断的任务，以便在另一个可用节点上执行。

• 你： 选择 VM 映像和大小、节点类型、目标节点计数、缩放配置、网络和可用性区域放置。

  你还负责维护足够的容量来容忍节点故障、监视节点和任务状态、使来宾操作系统和节点代理保持最新状态、设计任务以容忍重新执行以及将持久数据移出计算节点。

Batch 节点恢复不保证工作负荷在不中断的情况下继续。 有关详细信息，请参阅 计算节点故障的复原能力。

暂时性故障的复原能力

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

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

在 Batch 解决方案中，暂时性故障可能会影响作为任务运行的应用程序和脚本，以及调用 Batch API 来管理 Batch 资源的任何应用程序。 Batch 在任务级别提供重试机制。 你负责配置任务约束、使任务 幂等 （可以安全运行多次），以及配置对 Batch 服务和其他依赖项的调用的重试行为。

任务重试和时间限制

配置 maxTaskRetryCount 以控制 Batch 在其进程以非零退出代码退出后重试任务的次数：

• 默认值 0表示 Batch 不会在非零退出代码后重试任务。
• 正整数设置初始尝试后的最大重试次数。
• 允许无限重试的值 -1 。 不建议使用此值，因为永久性故障可能导致任务无限期运行。

将每个任务设计为幂等任务，以便重试不会导致数据损坏或重复输出。 对于长时间运行的任务，请使用检查点，以便重试可以从已保存的进度继续。 有关详细信息，请参阅 重试和重新执行的设计。

对任务或作业设置 maxWallClockTime 约束，以终止在可接受时间内未取得进展的工作。 时间限制还限制了重复失败的影响。 选择与工作负荷的恢复目标一致的重试计数和时间限制。

任务依赖项中的暂时性故障

作为 Batch 任务运行的应用程序和脚本通常调用其他组件，例如Azure 存储、数据库或 API。 Batch 不会处理任务代码发送到这些依赖项的单个请求。 在任务代码中实现暂时性故障处理，或使用依赖项 SDK 提供的重试功能。 按照每个依赖项的指导来确定可重试的错误，选择适当的退避和超时设置，并遵循例如 Retry-After 标头中的重试指令。 仅重试可安全重复执行的操作。

如果依赖项失败导致任务进程使用非零退出代码退出，Batch 可以根据 maxTaskRetryCount 重试整个任务。 但是，Batch 不会重试正在运行的任务中的单个依赖项请求。

批处理 API 请求重试

在服务外部运行的应用程序可以调用 Batch API 来创建和管理池、作业、任务、计算节点和其他 Batch 资源。 使用 持续时间至少为 5 分钟的重试策略配置这些客户端，以处理暂时性 Batch 服务或网络故障。

当内置 SDK 重试支持可用时，请使用它。 例如，Azure.Compute.Batch client library for .NET通过Azure.Core重试选项提供重试行为。

如果直接从代码与 Batch 服务的 API 交互，请在重试前等待几秒钟，使用带随机化（抖动）的指数回退来避免同步重试请求，并遵循随限制响应（如 429 Too Many Requests 和 503 Service Unavailable）返回的 Retry-After 标头。

请求超时不一定意味着 Batch 未能处理请求。 超时后，请在安全执行此操作时重试该操作，或检索资源状态以确定原始操作是否成功。 有关详细信息，请参阅Azure Batch中的错误处理和检测。

计算节点故障的复原能力

由于基础结构故障、操作系统问题或配置问题，计算节点可能变得不可用。 批处理尝试恢复受基础结构故障影响的节点，但无法自动恢复与配置相关的每个故障。 例如，如果应用程序包或容器无法安装，则必须更正基础问题，并且可能需要删除并替换受影响的节点。

如果节点故障中断某个任务，Batch 可以在同一节点上重试该任务（如果可能），最多可重试至内部限制次数。 如果任务无法在该节点上继续执行，Batch 可以将其重新加入队列，以便在另一个可用节点上执行。 这些服务驱动的恢复重试独立于maxTaskRetryCount，即使其值为0，也可能发生。

Microsoft托管节点恢复过程

Microsoft管理服务驱动的节点恢复和任务重新排队。 如果 Batch 服务长时间收不到某个节点的心跳信号，以至于触发恢复，Batch 可以执行以下操作：

1. 隔离节点： Batch 将节点视为不正常，将其状态设置为 unusable，并停止在该节点上计划新任务。
2. 确定受影响的任务： Batch 将节点上运行的任务标识为重新安排的候选项。
3. 重新排队符合条件的任务： 如果受影响的任务仍处于 running 状态，Batch 可以将其重置为 active，以便计划程序可以将其分配给另一个节点。 Batch 不会重置或重新运行已保留在 completed 状态的任务。
4. 恢复节点： Batch 尝试将节点还原到正常状态或替换基础 VM。

恢复不是即时的。 当 Batch 检测到节点失败并尝试重新计划任务时，任务可以保持处于 running 状态。 如果没有其他可用的计算节点，任务可以保持该状态，直到 Batch 可以重新调度它。 有关详细信息，请参阅 Batch 任务的已知限制。

如果原始节点在替换开始前恢复正常的心跳信号，Batch 可以将其返回到稳定状态。 如果已开始替换，Batch 可以删除原始 VM 并预配一个替换 VM。

你的责任

服务驱动的恢复不能保证不间断的任务执行或足够的剩余容量。 你负责以下操作：

• 保持足够的容量： 如果工作负载在节点不可用时必须继续，请预配足够的节点，以便其余节点能够运行重新调度的任务。 在没有另一个可用节点的情况下，中断的任务必须等待。

• 监视可用容量： 跟踪聚合节点计数和状态，以便可以检测池何时不再有足够的可用节点用于工作负荷。 诸如startTaskFailed、unknown、preempted和unusable等状态表示容量减少。 有关详细信息，请参阅通过按状态对任务和节点进行计数来监视 Batch 解决方案。

• 调查问题节点： 如果任务重复失败、重新排队，或在其分配的节点变得不可用或离开池后仍处于 running 状态，请使用任务元数据来确定这些问题是否与特定节点相关联。

  删除问题节点之前，请上传其 Batch 节点代理日志并保留相关的任务日志，因为删除节点会删除其本地文件。 节点代理日志可以帮助Azure支持诊断 Batch 服务或节点问题，而 stdout 和 stderr 等任务日志可帮助识别应用程序和配置问题。 有关详细信息，请参阅 Node 代理日志文件。

• 保护任务进度和数据： 设计任务以容忍中断和重新执行。 将检查点、输出和其他持久数据移出计算节点，因为它们的本地存储是临时的。

有关详细信息，请参阅Azure Batch池和节点错误，以及Azure Batch中的错误处理和检测。

应对可用区故障的弹性

可用性区域 是 Azure 区域内物理上独立的数据中心组。 当一个区域发生故障时，服务可以故障转移到其余区域中的一个。

Batch 以两种主要方式支持可用性区域：

• 控制平面： Batch 控制平面在许多区域中可在区域间复原。 在这些区域中，对 Batch 帐户和其他 Batch 资源的管理操作可以在区域故障期间继续。 Microsoft不会发布哪些区域提供此控制平面复原能力。

• 池： 可以将 Batch 池配置为使用 可用区放置。 如果某个区域不可用，则正常区域中的计算节点仍可用于任务调度。

  对于计算节点放置，此支持模型类似于其他 Azure 服务中的可用区冗余，因为单个池可以包含多个可用性区域中的计算节点。 但是，Batch 会尽力跨可用区分配节点。 它尝试使用该区域中的所有可用区，但不能保证在每个可用区中放置或实现均匀分布。 不能选择特定区域或控制每个区域中放置的节点数。

下图显示了一个 Batch 帐户示例。 该帐户有一个池，其节点分布在三个可用性区域：

你负责使其他依赖资源（如存储帐户）具备区域复原能力。 查看每个服务的可靠性指南。 有关详细信息，请参阅Azure服务的可靠性指南。

Requirements

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

• VM SKU 可用性： 所选 VM SKU 必须在该区域的多个可用区中可用。 使用 资源 SKU 列表 API 检查 VM SKU 的 locationInfo 字段。

• 订阅访问权限：对于 用户订阅池分配模式，订阅对所选 VM SKU 不得具有可用区产品/优惠限制。 查看资源 SKU 列表 API 响应中的 ResourceSkuRestrictions。 如果存在限制， 请提交支持请求 以请求其删除。

• 节点间通信： 使用 支持 InfiniBand 的 VM SKU 启用节点间通信时，池无法使用可用性区域放置策略。

跨区域的实例分布

启用可用性区域放置时，Batch 会尝试跨所选区域中的所有可用性区域分配计算节点。 此分配是尽最大努力执行的。 Batch 控制分布，并且每个区域中的节点数可能不相等。

Cost

Batch 不会为启用可用区放置添加费用。 系统会为工作负荷使用的计算、存储、网络和其他Azure资源计费。 如果预配额外的节点以承受某个可用区发生故障，则这些节点会产生其正常费用。 有关详细信息，请参阅Azure Batch定价。

配置可用性区域支持

• 创建具有可用性区域放置的新池： 若要创建启用了可用性区域放置的池，请参阅 跨可用性区域创建 Batch 池。

• 更改现有池上的可用区放置： 创建池时，必须选择可用区放置。 无法更改现有池以使用可用性区域。

  可以使用以下步骤创建替换池并更新每个作业以使用它：

  1. 禁用作业： 使用 “禁用作业 ”操作，并选择 Batch 如何处理提交请求时正在运行的任务：

     • 等待： 批处理停止启动新任务，并允许正在运行的任务在现有池中完成。 作业一直处于 disabling 状态，直到正在运行的任务完成。
     • 重新排队： 批处理作业会中断正在运行的任务，并将其返回到队列。 启用作业后，任务可以再次运行。
     • 终止： Batch 中断正在运行的任务，并将它们标记为已完成，其中包含指示它们已终止的失败信息。 启用作业后，任务不会再次运行。

     状态已处于 active 状态的任务（这意味着它们已排队但未运行）无论选择哪个选项，仍保持排队状态。

     等待作业到达 disabled 状态，然后再继续。 此时，不会运行任何任务，Batch 不会调度新任务。

  2. 编辑作业的池： 使用 更新作业 操作将作业的池 poolInfo.poolId 设置为替换池。 Batch 仅允许在作业处于 disabled 状态时更改此属性。 在启用作业之前，请确保替换池存在并具有可用容量。 如果池不存在，Batch 接受更新，但在创建池之前无法计划任务。

  3. 启用作业： 使用 “启用作业” 操作。 作业通过 enabling 状态转换到 active 状态。 然后，Batch 在替换池上计划排队的任务，包括通过 “重新排队 ”选项返回到队列的任务。 Batch 应用 Wait 选项时完成的任务以及通过 Terminate 选项完成的任务不会再次运行。

容量计划和管理

Batch 的 正常节点恢复过程 尝试替换在区域故障期间不可用的节点，并将池还原到其配置的目标节点计数。 它不会增加该目标项。 若要在某个区域不可用时保留足够的容量，以便工作负载继续运行，请考虑使用自动缩放或手动 超额预配 池的容量：

• 如果使用自动缩放：在池的自动缩放公式中引用$UsableNodeCount服务定义的变量，以检测可用容量何时低于工作负荷所需的基线。 $UsableNodeCount是正在计算其公式的池的 Batch 自动缩放变量，而不是Azure Monitor指标。 Azure Monitor在 Batch 帐户范围内发布 Batch 节点计数指标，并且这些指标没有poolId维度。

• 如果手动管理容量： 使用 列表池节点计数 操作检索每个池处于每个状态的专用节点计数和 Spot 节点计数。 该操作不返回单一的可用节点计数值。 评估支持任务的状态（如idle和running）与不可用或问题状态（如unusable、unknown、offline和startTaskFailed）进行比较。 返回的计数可能不是当前计数，因此需要确切计数时枚举池的计算节点。

Batch 会尽力跨可用区分配节点，因此实际分布可能不相等。 规划容量时，不要假定节点在区域之间均匀分布。 验证工作负荷在池容量减少的情况下是否可以满足其恢复目标。

所有区域正常时的行为

本部分介绍 Batch 池使用可用性区域放置和所有区域正常运行时会发生什么情况。

• 跨区域操作： 无论包含每个节点的区域如何，批处理都会将任务安排到整个池中可用的计算节点上。

• 跨区域数据复制： 批处理计算节点是临时的，Batch 不会在区域之间复制任务文件。 你负责将输入、输出、检查点和在节点丢失后仍需保留的诊断数据移至持久存储。 配置存储帐户冗余以满足可用性要求。

区域故障期间的行为

本部分介绍 Batch 池使用可用性区域放置和一个可用性区域不可用时会发生什么情况。

• 检测和响应：Microsoft监视 Batch 服务和计算节点运行状况。 在区域故障期间，Batch 检测到受影响节点的持续心跳丢失，并启动其 正常节点恢复过程。 正常区域中的节点仍然可用，Batch 可以继续在这些节点上计划任务。

  Batch 尝试通过正常的恢复过程将池还原到其配置的目标节点计数，但不会增加该目标。 如果目标端没有为工作负荷提供足够的容量，你负责请求额外的容量。

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

• 活动任务： 受影响节点上运行的任务会中断。 Batch 可能会在可用节点上重新计划任务，作为其内部恢复行为的一部分。 设计任务以容忍重试和重新执行，如 对暂时性故障的复原能力 和 计算节点故障的复原能力中所述。

• 预期数据丢失： 受影响的计算节点上的文件在服务中断期间不可用，如果节点已重置映像或从池中删除，则会丢失。 Batch 不会在区域之间复制这些文件。 根据存储资源的冗余配置，持久保存到持久存储的数据仍可用。

• 预期的停机时间： 正常节点上的任务将继续执行。 中断的任务会暂停运行，直到 Batch 可以将其重新安排到可用节点。 如果没有可用的节点，则任务可能会一直处于running状态，直到 Batch 可以重新计划它。 恢复时间取决于可用的池容量和排队的工作负荷。

  如果帐户位于控制平面是区域可复原的区域，则对 Batch 帐户和其他 Batch 资源的管理操作会继续。 在其他区域中，在受影响的可用区恢复之前，管理操作可能不可用。

• 重新分发： 在持续心跳信号丢失后，Batch 会将受影响的节点标记为 unusable，并通过其正常节点恢复过程提交它们进行替换。 Batch 尝试将池还原到其配置的目标节点数，但替代容量取决于正常区域中的配额和 VM 可用性。

  在此过程中，作业仍与池关联。 Batch 继续在正常区域中的可用节点上调度活动作业中的任务。 如果分配了替换节点并变得可用，Batch 还可以在这些节点上调度任务。

  此恢复过程不会增加配置的目标节点计数。 如果工作负荷需要超出该目标的容量，请手动增加容量或配置池的自动缩放公式以执行此操作。

区域恢复

Batch 管理当某个区域在故障后恢复时的恢复过程。 Batch 遵循 针对计算节点故障的弹性 中定义的相同过程。

Batch 不保证在恢复后节点会在各可用区之间得到均匀重新平衡。 区域放置仍按尽力原则进行。

测试区域故障

无法模拟实际 Azure 可用区中断用于测试。 相反，使用非生产池来中断典型任务，并将足够的计算节点从服务中取出，以近似预期容量损失。 请考虑使用以下 支持的节点操作：

• 重新启动所选节点。
• 禁用所选节点上的任务计划。
• 从池中删除所选节点。

当操作允许你选择如何处理正在运行的任务时，请选择“Requeue”选项，以便 Batch 可以在剩余节点上安排中断的任务。

在测试期间，验证 Batch 是否重新计划中断的任务，并且重新执行不会生成重复或不一致的输出。 确认检查点和输出在持久存储中保持可用，监视可检测节点丢失和容量减少，并且工作负荷可以使用剩余容量完成。

这些操作验证任务中断和重新安排、幂等性、检查点和持久输出处理。 但是，它们无法复现区域范围故障的所有影响。

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

Batch 帐户及其池的范围限定为一个Azure区域。 如果区域遇到故障，Batch 作业和池可能会受到影响。

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

Batch 不会将帐户、池配置、作业、任务、应用程序包或任务数据复制到另一个区域，并且不提供内置跨区域故障转移。 当工作负荷必须容忍区域范围的故障时，您负责部署和操作多区域 Batch 解决方案。

用于弹性的自定义多区域解决方案

若要构建多区域解决方案，请在恢复设计使用的每个区域中部署至少一个 Batch 帐户。 Batch 帐户在各区域中独立运行。 你负责选择区域、部署和操作每个区域中的资源，以及协调配置、复制、故障转移和故障回复。

可以设计一种 主动-主动 方法，用于在正常操作期间提交多个区域中的工作，也可以设计一种 主动-被动 方法，使辅助部署准备好进行故障转移。 主动-主动设计可以减少恢复时间，因为两个部署在正常运行期间都处理工作负载，而主动-被动设计可以降低稳定状态下的计算成本。

以下列表提供了设计解决方案时你的职责示例：

• 部署： 预先创建 Batch 帐户、池或池部署定义、存储帐户、网络资源以及每个区域中的其他依赖项。 验证每个所选区域是否支持工作负荷所需的 Batch 功能、VM 大小和依赖服务。 尽可能将每个 Batch 帐户及其任务使用的存储资源保留在同一区域，以避免不必要的延迟。 使用基础设施即代码定义 Batch 帐户、池和支持资源，以便跨区域一致地重现配置。

• 配额和容量： 验证每个恢复区域中适用的 Batch 帐户、订阅和 VM 系列配额，并在需要时于发生中断之前申请增加。 配额是一种限制，不是容量保证。 VM 可用性因区域、VM 系列和时间而异。 有关详细信息，请参阅 Batch 帐户和核心配额。

• 数据复制： 确保应用程序包、容器映像、输入数据和引用数据在每个恢复区域都可用。 批处理不会为你复制这些项。

• 存储复制： 根据恢复点目标配置存储冗余和跨区域数据复制。 验证是否可从每个恢复区域访问复制的数据。 有关存储可靠性选项，请参阅Azure Blob 存储中的可靠性。

• 区域定位： 如果应用程序与 Batch 帐户配合使用，请对其进行设计，以便其能够选择另一个 Batch 帐户及其关联的存储资源，而无需代码部署。

• 故障转移： Batch 不会自动将工作负荷移动到另一个区域。 你负责检测服务中断、确定服务中断如何影响工作负荷、停止向受影响的 Batch 帐户提交、将新工作定向到正常区域中的 Batch 帐户，以及决定是否重新提交中断的作业。 未在受影响区域外部复制的工作或任务输出可能不可用或丢失。 恢复时间取决于部署模型、可用容量、数据复制和自动化。

• 区域恢复： 在受影响区域的服务可用性恢复后，请在将工作定向到该区域之前验证 Batch 帐户、池、存储依赖项和作业状态。 重新提交之前处理重复或部分完成的任务。 Batch 不会协调此过程，也不会统一区域账户之间的状态。

• 测试： 在非生产环境中定期测试完整的区域恢复过程。 模拟一个区域部署变得不可用，直接提交到另一个区域 Batch 帐户，验证对应用程序包和输入数据的访问权限，运行代表性作业，收集输出，并练习让已恢复的部署重新投入使用。 根据恢复时间目标和恢复点目标衡量结果。

备份和还原

Azure Batch不是工作负荷输入和输出数据的持久存储。 Microsoft维护 Batch 服务，但你负责保留重新创建工作负荷所需的配置和数据：

• 批处理配置：使用基础结构（例如Bicep）和版本控制的作业定义来定义 Batch 帐户、池、作业和支持资源。 这些工件提供了一种可重复的方法，用于在同一区域或其他区域中重新创建配置。 定期测试定义是否可以部署池并运行具有代表性的作业。

• 批处理元数据： 批处理将保留作业和任务记录，直到删除关联的作业或任务，但这些记录不是备份。 如果需要保留此历史记录，请保留 Batch 外部所需的记录。

• 计算节点上的数据： 计算节点是临时的，其文件系统不是备份或持久存储。 当节点重新映像或离开池时，节点上的数据会丢失。 Batch 还可以在其保留期到期后删除任务文件。 在任务完成之前，将所需的输出和诊断日志保存到持久存储。 对于长时间运行的任务，在执行期间持久化检查点。 有关详细信息，请参阅持久化作业和任务输出和监视Azure Batch。

• 自动存储帐户中的数据： 关联的自动存储帐户可以保存应用程序包和任务资源文件。 除了配置满足恢复目标的冗余外，还应考虑是否需要保护此数据免受意外删除或损坏的影响。 有关详细信息，请参阅Azure Blob 存储中的备份和恢复。

还原与恢复测试

若要恢复，请部署 Batch 和支持的资源配置，还原或重新连接所需的输入数据和应用程序项目，并重新提交未完成的工作。 在独立或非生产恢复环境中定期测试资源重建和数据还原。 使用版本控制定义和备份数据、运行具有代表性的作业、验证生成的输出和对依赖项的访问权限，并对照您的目标衡量实际达到的恢复时间和恢复点。 验证任务是否幂等，以便重新提交不确定的工作不会损坏数据或创建重复的输出。

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

Microsoft为Azure Batch和其他服务执行平台维护和协调基础结构更新。 你负责配置池更新行为和设计任务以容忍中断。

• 主机维护：Azure尽可能使用维护技术，例如实时迁移。 如果维护需要计算节点重启或迁移，则正在运行的任务可能会被中断，Batch 可能会重新计划它们。 使任务幂等，并将检查点和输出保存到持久存储。

• 来宾操作系统： 你负责使来宾操作系统和 Batch 节点代理保持最新状态。 操作系统更新行为取决于映像和更新配置。 使用适当的配置， Batch 池的自动 OS 映像升级 可以更新池节点，而不会中断正在运行的任务。 自动 OS 映像升级不支持每个 Batch 操作系统映像。

• 节点代理更新： 自动 OS 映像升级不会自动更新 Batch 节点代理。 当池中有计算节点时，批处理节点代理不会自动升级。 若要接收较新的节点代理，请将池大小调整为零个节点，然后再次扩容或替换池。 在删除节点之前，请保留任何所需的任务输出和诊断日志。 有关详细信息，请参阅 Batch 节点代理更新。

遵循 生产部署建议 和 计算节点故障指南，以便在维护中断任务或导致计算节点不可用时，工作负载能够继续运行或恢复。

服务级别协议

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

Azure Batch可用性 SLA 适用于针对 Batch API 执行的操作。 有关包含的操作类型的详细信息，请查看 SLA 条款内容。 池大小、区域分发和依赖服务会影响工作负荷的端到端可用性，但不会更改 Batch SLA 的条款。

相关内容

• Azure Batch 文档
• Azure Batch最佳做法
• Azure 中的可靠性