Azure Batch 中的可靠性

本文介绍 Azure Batch 中的可靠性支持，还介绍了可用性区域的区域内部复原能力，以及关于跨区域恢复和业务连续性信息的链接。

可用性区域支持

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

有关 Azure 中可用性区域的详细信息，请参阅什么是可用性区域？。

Batch 可在支持可用性区域时维护与 Azure 的奇偶校验。

先决条件

• 对于用户订阅模式 Batch 帐户，请确保你在其中创建池的订阅在请求的 VM SKU 上没有区域产品/服务限制。 要查看订阅是否不存在任何限制，请调用资源 SKU 列表 API 并检查 ResourceSkuRestrictions。 如果存在区域限制，可以提交支持票证来删除区域限制。

• 由于 InfiniBand 不支持区域间通信，因此如果池已启用节点间通信，并且使用支持 InfiniBand 的 VM SKU，则无法创建具有区域性策略的池。

• Batch 可在支持可用性区域时维护与 Azure 的奇偶校验。 要使用区域选项，必须在 支持可用性区域的 Azure 区域中创建池。

• 要跨可用性区域分配 Batch 池，创建池的 Azure 区域必须在多个区域中支持请求的 VM SKU。 要验证该区域是否在多个区域中支持请求的 VM SKU，可调用资源 SKU 列表 API 并检查 resourceSku 的 locationInfo 字段。 确保请求的 VM SKU 支持多个区域。 还可以使用 Azure CLI 通过以下命令列出所有可用的资源 SKU：

  az vm list-skus
  

跨可用性区域创建 Azure Batch 池

有关如何跨可用性区域创建 Batch 池的示例，请查看跨可用性区域创建 Azure Batch 池。

详细了解如何通过 Azure 门户、Azure CLI、PowerShell 或 Batch 管理 API 创建 Batch 帐户。

区域故障体验

在区域关闭服务中断期间，该区域中的节点将不可用。 来自其他区域的同一节点池中的任何节点则不受影响，并将继续可用。

Azure Batch 帐户不会重新分配或创建新节点来补偿因中断而关闭的节点。 用户需要将更多节点添加到节点池，然后从其他正常区域分配这些节点。

容错

要为可能的可用性区域故障做好准备，应过度预配服务容量，以确保解决方案可以容忍 1/3 的容量损失，并在区域范围的中断期间继续正常运行，而不会降低性能。 由于平台将 VM 分散到三个区域，并且你至少需要考虑一个区域的故障，因此将峰值工作负载实例计数乘以“区域/(区域-1)”或 3/2。 例如，如果你的典型峰值工作负载需要四个实例，则应预配六个实例：（2/3 * 6 个实例）= 4 个实例。

可用性区域迁移

无法将现有 Batch 池迁移到可用性区域支持。 若要跨可用性区域重新创建 Batch 池，请查看跨可用性区域创建 Azure Batch 池。

跨区域灾难恢复和业务连续性

Azure Batch 在所有 Azure 区域中可用。 但在创建 Batch 帐户时，必须将其与特定区域相关联。 面向该 Batch 帐户的所有后续操作仅适用于该区域。 例如，池和关联的虚拟机 (VM) 在 Batch 帐户所在的区域中创建。

设计使用 Batch 的应用程序时，必须考虑到 Batch 在某个区域中不可用的可能性。 可能会遇到罕见的情况，即：整个区域遇到问题、区域中的整个 Batch 服务遇到问题，或特定 Batch 帐户出现问题。

如果使用 Batch 的应用程序或解决方案必须始终可用，则应将其设计为可以故障转移到另一区域，或始终在两个或更多区域之间拆分工作负载。 两种方法都需要至少两个 Batch 帐户，每个帐户位于不同的区域中。

你负责使用 Azure Batch 设置跨区域灾难恢复。 如果跨特定区域运行多个 Batch 帐户并利用可用性区域，则当其中一个 Batch 帐户不可用时，应用程序可以满足灾难恢复目标。

当提供故障转移到备用区域的功能时，必须考虑到解决方案中的所有组件；仅仅设置另一个 Batch 帐户是不够的。 例如，在大多数 Batch 应用程序中，需要使用 Azure 存储帐户。 存储帐户和 Batch 帐户必须位于同一区域，才能实现可接受的性能。

设计可以故障转移的解决方案时，请注意以下几点：

• 在每个区域中预先创建所有必需的服务，例如 Batch 帐户和存储帐户。 创建帐户通常不收取任何费用，而且只有使用帐户或存储数据时才会产生费用。

• 提前确保为所有用户订阅 Batch 帐户设置适当的配额，以便使用 Batch 帐户分配所需的核心数。

• 使用模板和/或脚本在区域中自动部署应用程序。

• 持续更新所有区域中的应用程序二进制文件和引用数据。 保持最新将确保可将区域快速联机，而无需等待上传和部署文件。 例如，考虑使用 Batch 应用程序包存储和引用要在池节点上安装的自定义应用程序的情况。 应用程序更新发布后，应将其上传到每个 Batch 帐户，并由池配置进行引用（或将最新版本设为默认版本）。

• 在调用 Batch、存储和任何其他服务的应用程序中，可以轻松地将客户端或负载切换到不同的区域。

• 在正常操作过程中，请考虑频繁切换到备用区域。 例如，如果两个部署位于不同的区域，则每月切换到备用区域一次。

灾难恢复的时长取决于你选择的设置。 Batch 本身与使用多个帐户还是单个帐户无关。 在主动-主动配置中，如果两个 Batch 实例同时接收流量，则灾难恢复比主动-被动配置更快。 选择哪种配置应基于业务需求（不同区域、延迟要求）和技术注意事项。

单区域灾难恢复

无论是在单区域还是多区域地理位置工作，在 Batch 中实现灾难恢复的方式是相同的。 唯一的区别在于用于存储的 SKU，以及是否打算在所有区域中使用相同或不同的存储帐户。

灾难恢复测试

应对已启用 Batch 的解决方案执行自己的灾难恢复测试。 最佳做法是支持跨不同区域在客户端和服务负载之间轻松切换。

测试 Batch 的灾难恢复计划可以像切换 Batch 帐户一样简单。 例如，可以在一个运营日内依赖于特定区域中的单个 Batch 帐户。 然后在第二天，可以切换到其他区域中的另一个 Batch 帐户。 灾难恢复主要在客户端进行管理。 这种多帐户灾难恢复方法可处理单区域或多区域地理位置中的 RTO 和 RPO 预期。

容量和主动灾难恢复复原能力

Azure 及其客户按共担责任模型运营。 Azure 负责平台和基础结构的复原能力。 你负责解决所部署和控制的任何特定服务的灾难恢复问题。 要确保恢复是主动进行的：

• 应始终预先部署辅助数据库。 预先部署辅助数据库是非常必要的，因为对于尚未预分配此类资源的用户，在发生影响时无法保证容量。

• 请在每个区域中预先创建所有必需的服务，例如 Batch 帐户和关联的存储帐户。 创建新帐户通常不收取任何费用，而且只有使用帐户或存储数据时才会产生费用。

• 确保提前在所有订阅上设置适当配额，以便可以使用 Batch 帐户分配必需的核心数。 与其他 Azure 服务一样，与 Batch 服务关联的某些资源存在限制。 其中的许多限制是 Azure 在订阅或帐户级别应用的默认配额。 设计和增加 Batch 工作负荷时，请记住这些配额。

存储

必须配置 Batch 存储以确保跨区域备份数据；这一点默认为客户责任。 大多数 Batch 解决方案使用 Azure 存储来存储资源文件和输出文件。 例如，Batch 任务（包括标准任务、启动任务、作业准备任务和作业释放任务）通常指定位于存储帐户中的资源文件。 存储帐户还会存储已处理的数据和所生成的任何输出数据。 了解跨服务操作区域可能发生数据丢失是一项重要考虑因素。 还必须确认数据是可重写的还是只读的。

Batch 支持以下类型的 Azure 存储帐户：

• 常规用途 v2 (GPv2) 帐户
• 常规用途 v1 (GPv1) 帐户
• Blob 存储帐户（目前支持虚拟机配置中的池）

有关存储帐户的详细信息，请参阅 Azure 存储帐户概述。

创建帐户时可以将存储帐户与 Batch 帐户关联，也可以稍后关联。

如果要为提供服务的每个区域设置单独的存储帐户，则必须使用区域冗余存储 (ZRS) 帐户。 如果跨多个配对区域使用同一存储帐户，请使用异地区域冗余存储 (GZRS) 帐户。 对于包含单个区域的地理位置，必须创建区域冗余存储 (ZRS) 帐户，因为 GZRS 不可用。

产能规划是存储的另一个重要考虑因素，应主动加以解决。 选择存储帐户时，请考虑成本和性能要求。 例如，与 GPv1 相比，GPv2 和 blob 存储帐户选项支持更大的容量和可伸缩性限制。 （请联系 Azure 支持以请求提高存储上限。）对于包含大量读取或写入存储帐户的并行任务的 Batch 解决方案，这些帐户选项可以提高其性能。

在将存储帐户链接到 Batch 帐户时，可将其视为自动存储帐户。 如果计划使用应用程序包功能，则自动存储帐户是必需的，因为它会用于存储应用程序包 .zip 文件。 自动存储帐户还可用于任务资源文件；由于已将自动存储帐户链接到 Batch 帐户，因此无需共享访问签名 (SAS) URL 即可访问该资源文件。

后续步骤

• Azure 中的可靠性