为了最大化运行时间，请提前规划以维持业务连续性并使用 Azure 机器学习为灾难恢复做好准备。
Azure 致力于确保 Azure 服务一直可用。 不过，可能会发生计划外服务中断。 制定灾难恢复计划来处理区域服务中断。 在本文中，你将了解如何：
- 规划Azure 机器学习和关联资源的多区域部署。
- 最大化恢复日志、笔记本、Docker 映像和其他元数据的机会。
- 针对解决方案的高可用性进行设计。
- 发起故障转移到另一个区域。
重要
Azure 机器学习本身不提供自动故障转移或灾难恢复。 工作区元数据（例如运行历史记录）无法进行备份和还原。
如果意外删除了工作区或相应的组件，本文还提供了当前支持的恢复选项。
了解适用于 Azure 机器学习的 Azure 服务
Azure 机器学习依赖于多项 Azure 服务。 其中一些服务已在订阅中预配。 你负责这些服务的高可用性配置。 其他服务将在 Azure 订阅中创建，并由 Azure 管理。
Azure 服务包括：
Azure 机器学习基础结构：适用于 Azure 机器学习工作区的 Azure 托管环境。
关联资源：Azure 机器学习工作区创建期间在订阅中预配的资源。 这些资源包括 Azure 存储、Azure 密钥保管库、Azure 容器注册表和 Application Insights。
- 默认存储包含模型、训练日志数据和数据资产引用等数据。
- 密钥保管库 具有 Azure 存储、容器注册表和数据存储的凭据。
- 容器注册表提供用于训练和推理环境的 Docker 映像。
- Application Insights 用于监视 Azure 机器学习。
计算资源：在部署工作区之后创建的资源。 例如，可能会创建一个计算实例或计算群集来训练机器学习模型。
- 计算实例和计算群集：Azure 托管模型开发环境。
- 其他资源：可附加到 Azure 机器学习的 Azure 计算资源，例如 Azure Kubernetes 服务 (AKS)、Azure Databricks、Azure 容器实例和 Azure HDInsight。 你负责配置这些资源的高可用性设置。
其他数据存储：Azure 机器学习可以装载其他数据存储（例如 Azure 存储和 Azure Data Lake Storage）来训练数据。 这些数据存储已在订阅中预配。 你负责配置它们的高可用性设置。 若要查看其他数据存储选项，请参阅创建数据存储。
下表显示了哪些Azure服务由Azure管理，哪些服务由你管理。 它还指示默认情况下高度可用的服务。
| 服务 | 管理者 | 默认具有高可用性 |
|---|---|---|
| Azure 机器学习基础结构 | 蔚蓝 | |
| 关联资源 | ||
| Azure 存储 | 你 | |
| 密钥保管库 | 你 | ✓ |
| 容器注册表 | 你 | |
| Application Insights | 你 | 暂无 |
| 计算资源 | ||
| 计算实例 | 蔚蓝 | |
| 计算群集 | 蔚蓝 | |
| 其他计算资源，例如 AKS、 Azure Databricks、容器实例、HDInsight |
你 | |
|
其他数据存储，例如 Azure 存储、SQL 数据库、 Azure Database for PostgreSQL、Azure Database for MySQL、 Azure Databricks 文件系统 |
你 |
本文的其余部分介绍如何使这些服务具有高可用性。
多区域部署计划
多区域部署依赖于在两个 Azure 区域中创建 Azure 机器学习和其他资源（基础结构）。 如果发生区域性服务中断，可以切换到另一个区域。 规划资源的部署位置时，请考虑：
区域可用性：如果可能，请使用同一地理区域中的某个区域，而不必是最近的区域。 若要检查 Azure 机器学习的区域可用性，请参阅 Azure 产品（按区域））。
Azure 配对区域：配对区域协调平台更新，并在需要时确定恢复工作的优先级。
服务可用性：确定解决方案使用的资源应该是热/热、热/暖还是热/冷。
- Hot/Hot：两个区域同时处于活动状态，其中一个区域已准备就绪，可立即投入使用。
- 热/温：主要区域处于活动状态，次要区域已具备可随时启动的关键资源（例如，已部署的模型）。 非关键资源需要手动部署在次要区域。
- 热/冷：主要区域处于活动状态，次要区域已部署 Azure 机器学习和其他资源，以及所需的数据。 需要手动部署模型、模型部署或管道等资源。
提示
根据业务需求，你可能会决定以不同的方式对待不同的 Azure 机器学习资源。 例如，对于已部署的模型（推理），您可能希望使用热/热，而对于实验（训练），则使用热/冷。
Azure 机器学习基于其他服务进行构建。 某些服务可以配置为复制到其他区域。 其他则必须在多个区域手动创建。 下表提供了负责复制的服务列表，以及配置概述：
| Azure 服务 | 异地复制 | 配置 |
|---|---|---|
| 机器学习工作区 | 你 | 在所选区域中创建工作区。 |
| 机器学习计算 | 你 | 在所选区域中创建计算资源。 对于可以动态缩放的计算资源，请确保这两个区域提供的计算配额足以满足你的需求。 |
| 机器学习注册表 | 你 | 在多个区域中创建注册表。 |
| 密钥保管库 | 蔚蓝 | 在两个区域中，将相同的 密钥保管库 实例与 Azure 机器学习工作区和资源一起使用。 密钥保管库 会自动故障转移至次要区域。 有关详细信息，请参阅 Azure 密钥保管库 可用性和冗余。 |
| 容器注册表 | 蔚蓝 | 将容器注册表实例配置为将注册表异地复制到 Azure 机器学习的配对区域。 对两个工作区实例使用相同的实例。 有关详细信息，请参阅 Azure 容器注册表中的异地复制。 |
| 存储帐户 | 你 | Azure 机器学习不支持对 默认存储帐户 使用异地冗余存储 (GRS)、异地区域冗余存储 (GZRS)、读取访问权限异地冗余存储 (RA-GRS) 或读取访问权限异地区域冗余存储 (RA-GZRS) 进行故障转移。 为每个工作区的默认存储创建一个单独的存储帐户。
为其他数据存储创建单独的存储帐户或服务。 有关详细信息，请参阅 Azure 存储冗余。 |
| Application Insights | 你 | 为两个区域中的工作区创建 Application Insights。 若要调整数据保留期和详细信息，请参阅 Application Insights 中的数据收集、保留和存储。 |
若要在次要区域中启用快速恢复和重启，建议使用以下开发实践：
- 使用 Azure 资源管理器模板。 模板是“基础结构即代码”，可让你快速地在这两个区域中部署服务。
- 若要避免两个区域之间发生偏差，请更新持续集成和部署管道，将其部署到这两个区域。
- 在自动化部署时，请将附加到工作区的计算资源（例如 Azure Kubernetes 服务）的配置纳入其中。
- 为两个区域的用户创建角色分配。
- 为两个区域创建网络资源，例如 Azure 虚拟网络和专用终结点。 确保用户有权访问这两个网络环境。 例如，这两个虚拟网络的 VPN 和 DNS 配置。
计算和数据服务
根据需求，你可能拥有更多由 Azure 机器学习使用的计算或数据服务。 例如，你可能使用 Azure Kubernetes 服务或 Azure SQL 数据库。 使用以下信息了解如何配置这些服务以实现高可用性。
计算资源
- Azure Kubernetes 服务：请参阅 Azure Kubernetes 服务 (AKS) 中实现业务连续性和灾难恢复的最佳做法和创建使用可用性区域的 Azure Kubernetes 服务 (AKS) 群集。 如果 AKS 群集是使用 Azure 机器学习工作室、SDK 或 CLI 创建的，则不支持跨区域高可用性。
- Azure Databricks：请参阅 Azure Databricks 群集的区域性灾难恢复。
- 容器实例：容器编排器负责处理故障转移。 请参阅 Azure 容器实例和容器业务流程协调程序。
- HDInsight：请参阅 Azure HDInsight 支持的高可用性服务。
数据服务
Azure Blob 容器/Azure 文件存储/Data Lake Storage Gen2：请参阅 Azure 存储冗余。
提示
如果你提供自己的客户管理的密钥来部署 Azure 机器学习工作区，则还会在订阅中预配 Azure Cosmos DB。 在这种情况下，你应负责配置其高可用性设置。 请参阅使用 Azure Cosmos DB 实现高可用性。
面向高可用性的设计
可用性区域
某些 Azure 服务支持可用性区域。 对于支持可用性区域的区域，如果某个区域出现故障，任何工作负载都会暂停，并且应保存数据。 但是，在区域重新联机之前，数据无法刷新。
有关详细信息，请参阅可用性区域服务支持。
将关键组件部署到多个区域
确定目标业务连续性级别。 解决方案的组件之间的级别可能有所不同。 例如，你可能希望为生产流水线或模型部署采用热/热配置，而为实验采用热/冷配置。
管理独立存储上的训练数据
通过将数据存储与工作区用于日志的默认存储分离，你可以：
- 将与数据存储相同的存储实例附加到主要工作区和次要工作区。
- 利用存储账户的异地复制功能，最大限度地延长正常运行时间。
将机器学习资产作为代码进行管理
注意
无法备份和还原运行历史记录、模型和环境等工作区元数据。 使用 YAML 规范将资产和配置指定为代码，有助于在发生灾难时跨工作区重新创建资产。
Azure 机器学习中的作业由作业规范定义。 此规范包括对在工作区实例级别管理的输入项目（包括环境和计算）的依赖项。 对于多区域作业提交和部署，建议采用以下做法：
借助 Git 存储库，在本地管理基本代码。
- 从 Azure 机器学习工作室中导出重要的笔记本。
- 导出在 Studio 中以代码形式创作的管道。
以代码的方式管理配置。
- 避免对工作区进行硬编码引用。 请改为使用配置文件配置对工作区实例的引用，并使用 MLClient.from_config() 初始化工作区。
- 如果您使用自定义 Docker 镜像，请使用 Dockerfile。
启动故障转移
在故障转移工作区中继续工作
当主要工作区不可用时，可以切换到次要工作区以继续试验和开发。 如果发生中断，Azure 机器学习不会自动将作业提交给次要工作区。 更新代码配置，使其指向新的工作区资源。 我们建议避免对工作区引用进行硬编码。 应使用工作区配置文件来最大程度地减少更改工作区时的手动用户步骤。 请确保还将所有自动化（例如持续集成和部署管道）更新到新工作区。
Azure 机器学习无法同步或恢复工作区实例之间的项目或元数据。 取决于应用程序部署策略，您可能必须将工件移至故障转移工作区，或在该工作区中重新创建实验输入（例如数据资产），才能继续提交作业。 如果您已将主工作区和辅助工作区资源配置为共享已启用异地复制的关联资源，则某些对象可能会直接在故障转移工作区中可用。 例如，两个工作区共享相同的 docker 映像、配置的数据存储和 Azure 密钥保管库 资源。 下图显示了一个配置，其中两个工作区共享相同的映像 (1) 、数据存储 (2) 和 密钥保管库 (3)。
注意
发生服务中断时运行的任何作业都不会自动转换为辅助工作区。 解决服务中断后，作业在主工作区中恢复并成功完成的可能性很小。 而是，这些作业必须重新提交，可以在次要工作区中提交，或在主要工作区中提交（待故障恢复后）。
在工作区之间移动工件
根据你采用的恢复方式，你可能需要在各个工作区之间复制工件，以继续开展工作。 目前，工作区之间的项目可移植性受到限制。 建议尽可能以代码形式管理工件，以便在故障转移实例中重新创建它们。
以下工件可通过使用适用于机器学习的 Azure CLI 扩展在工作区之间导出和导入：
提示
- 作业输出存储在与工作区关联的默认存储帐户中。 尽管在服务中断时可能无法从工作室 UI 访问作业输出，但你可以通过存储帐户直接访问数据。 有关处理存储在 blob 中的数据的详细信息，请参阅使用 Azure CLI 创建、下载和列出 blob。
恢复选项
工作区删除
如果您不小心删除了工作区，或许可以将其恢复。 有关恢复步骤，请参阅使用软删除恢复意外删除的工作区数据。
即使无法恢复工作区，也可以按照以下步骤从与工作区关联的 Azure 存储资源检索笔记本：
- 在 Azure 门户中，导航到已链接到删除的 Azure 机器学习工作区的存储帐户。
- 在左侧的“数据存储”部分中，选择“文件共享”。
- 你的笔记本位于名称中包含你的工作区 ID 的文件共享上。
后续步骤
若要了解使用 Azure 机器学习进行可重复的基础结构部署，请使用 Bicep 模板或 Terraform 模板。