通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 数据工厂和 Azure Synapse Analytics 管道的 BCDR

Azure 数据工厂
Azure Repos
Azure Synapse Analytics
GitHub

灾难可以是硬件故障、自然灾害或软件故障。 从灾难中恢复的准备和实施过程称为灾难恢复 (DR)。 本文介绍了实现 Azure 数据工厂和 Azure Synapse Analytics 管道的业务连续性和灾难恢复（BCDR）的建议做法。

BCDR 策略包括可用性区域冗余、Azure DR 提供的自动恢复，以及使用持续集成和持续交付（CI/CD）进行用户管理的恢复。

Architecture

显示 Azure Synapse Analytics 和 Azure 数据工厂管道 BCDR 的可用性区域和区域的关系图。

下载此体系结构的 Visio 文件 。

Workflow

  • Azure 数据工厂和 Azure Synapse Analytics 管道使用 Azure 区域和 Azure 可用性区域实现复原能力。

    • 每个 Azure 区域都有一组数据中心，这些数据中心部署在延迟定义的范围内。

    • “Azure 可用性区域”是每个 Azure 区域中的物理上独立的位置。 区域可以容忍本地故障。

    • 所有 Azure 区域和可用性区域都通过专用区域低延迟网络和高性能网络进行连接。

    • 所有已启用可用性区域的区域都至少有三个单独的可用性区域，以确保复原能力。

  • 当数据中心、数据中心的一部分或区域中的可用性区域发生故障时，区域可复原的 Azure 数据工厂和 Azure Synapse Analytics 管道会故障转移，且不会停机。

Components

  • Azure 数据工厂 是一项基于云的数据集成服务，旨在帮助你大规模管理和自动化数据工作流。 在此体系结构中，它协调数据移动和转换工作流，并支持通过区域配对的自动故障转移和基于 CI/CD 的用户托管恢复实现复原能力。

  • Azure Synapse Analytics 是大数据和数据仓库的统一平台，旨在帮助快速高效地分析大量数据。

    • Azure Synapse Analytics 管道是 Azure Synapse Analytics 中的数据集成和业务流程功能，可用于生成、管理和自动执行用于移动和转换数据的工作流。 在此体系结构中，Azure Synapse Analytics 管道通过启用区域冗余、与 Git 存储库集成以及自动化或用户管理的恢复方法来管理数据工作流并支持 BCDR。

  • GitHub 是一个基于云的平台，可帮助开发人员使用 Git 协作、管理代码和跟踪软件项目中的更改。 在此体系结构中，GitHub 存储管道项目，并作为用户管理的恢复策略的一部分自动部署到次要区域。

  • Azure Repos 是一组可用于管理代码的版本控制工具。 在此体系结构中，它通过为 Azure 数据工厂和 Azure Synapse Analytics 管道提供源代码管理和 CI/CD 集成来支持手动 DR 和故障转移准备，从而与 GitHub 类似。

Scenario details

Azure 数据工厂和 Azure Synapse Analytics 管道存储包含以下类型的数据的项目：

  • 管道、数据集、链接服务、集成运行时（IR）和触发器等元数据

  • 监视管道运行、触发器运行和活动运行等数据

灾难可能以各种形式发生，例如硬件故障、自然事件或人为错误或网络攻击造成的软件故障。 根据故障类型，地理影响可能是区域或全球影响。 规划灾难恢复策略时，请考虑灾难的性质及其潜在的地理范围。

Azure 中的 BCDR 在共同责任模型中运行。 Azure 提供了基础基础结构和平台服务，但许多 Azure 产品/服务要求你主动配置 DR 策略。

可以使用以下建议的做法在各种故障方案中实现适用于 Azure 数据工厂和 Azure Synapse Analytics 管道的 BCDR。 有关实现，请参阅 部署此方案。

使用 Azure DR 自动恢复

使用备份和 DR 配置自动恢复 时，具有配对区域的 Azure 区域中的完全中断会触发 Azure 数据工厂或 Azure Synapse Analytics 管道，以自动故障转移到配对区域。 例外包括东南亚和巴西区域，其中数据驻留要求数据保留在这些区域。

在 DR 故障转移中，Azure 数据工厂恢复生产管道。 如果需要验证恢复的管道，可以在机密存储中备份生产管道的 Azure 资源管理器模板，并将恢复的管道与备份进行比较。

Azure 全球团队定期执行 BCDR 演练，Azure 数据工厂和 Azure Synapse Analytics 会参与这些演练。 BCDR 演练模拟区域故障，并将 Azure 服务故障转移到配对区域，而无需任何客户参与。 有关 BCDR 演练的详细信息，请参阅 服务测试。

使用 CI/CD 处理用户管理的冗余

若要在发生完整的区域故障时实现 BCDR，必须在次要区域中预配 Azure 数据工厂或 Azure Synapse 工作区。 如果意外删除、服务中断或影响 Azure 数据工厂或 Azure Synapse Analytics 管道的内部维护事件，可以使用 Git 集成和 CI/CD 工作流手动恢复管道。

或者，可以使用主动/被动实现。 主要区域处理正常作并保持活动状态。 将次要 DR 区域提升到主要区域需要预先计划的步骤，这些步骤因具体实现而异。 这些步骤可确保发生区域性故障时的平稳过渡和最小的中断。 在这种情况下，基础结构的所有必要配置都在次要区域中可用，但未预配。

可能的用例

在以下方案中，用户管理的冗余非常有用：

  • 由于人为错误而意外删除管道项目
  • 未触发 BCDR 的扩展中断或维护事件，因为未报告任何灾难

可以快速将生产工作负载转移到其他区域而不会受到影响。

Considerations

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

Reliability

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性设计评审清单。

Azure 数据工厂和 Azure Synapse Analytics 管道是支持可用性区域的主流 Azure 服务。 它们旨在提供适当的复原能力和灵活性以及超低延迟。

用户管理的恢复方法允许在主要区域中发生任何维护事件、中断或人为错误时继续作。 通过使用 CI/CD，Azure 数据工厂和 Azure Synapse Analytics 管道可以集成到 Git 存储库并部署到次要区域，以便立即恢复。

Cost Optimization

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

用户管理的恢复使用 CI/CD 将 Azure 数据工厂与 Git 集成。 它可以选择使用具有所有必要基础结构配置的辅助 DR 区域作为备份。 此方案可能会产生额外的成本。 若要估算成本，请使用 Azure 定价计算器。

有关 Azure 数据工厂和 Azure Synapse Analytics 定价的示例，请参阅以下文章：

Operational Excellence

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅 针对卓越运营的设计评审清单。

通过使用用户管理的 CI/CD 恢复方法，可以集成到 Azure Repos 或 GitHub。 有关详细信息，请参阅 CI/CD 的最佳做法。

部署此方案

执行以下作，为 Azure 数据工厂和 Azure Synapse Analytics 管道设置自动化或用户管理的 DR。

设置自动恢复

在 Azure 数据工厂中，可以在 IR 设置中为活动运行或调度设置 Azure IR 区域。 若要在发生完整的区域中断时启用自动故障转移，请将 区域 设置为 自动解决。

显示如何选择“自动解析”以在 IR 设置中启用自动故障转移的屏幕截图。

选择“ 自动解析 ”作为 IR 区域时，IR 会自动故障转移到配对区域。 对于其他特定位置区域，可以在另一个区域中创建辅助数据工厂，并使用 CI/CD 从 Git 存储库预配数据工厂。

  • 对于托管虚拟网络，必须手动切换到次要区域。

  • Azure 托管的自动故障转移不适用于自承载集成运行时（SHIR），因为基础结构是客户管理的。 有关如何使用 SHIR 设置多个节点以实现更高的可用性的指导，请参阅 创建和配置 SHIR。

  • 若要为 Azure SQL Server Integration Services （Azure-SSIS） IR 配置 BCDR，请参阅 为 BCDR 配置 Azure-SSIS IR。

由于区域中较新的网络中挂起的专用终结点，故障转移后未完全启用链接服务。 你需要在恢复的区域中配置专用终结点。 可以使用 审批 API 自动创建专用终结点。

通过 CI/CD 设置用户管理的恢复

如果发生 Azure 数据工厂或 Azure Synapse 管道删除或中断，可以使用 Git 和 CI/CD 手动恢复管道。

使用 CI/CD 部署用户管理的冗余时，请执行下列作。

Disable triggers

在原始主数据工厂恢复联机后禁用触发器。 可以手动禁用触发器或实现自动化来定期检查原始主数据工厂的可用性。 工厂恢复后，立即禁用原始主数据工厂上的所有触发器。

若要使用 Azure PowerShell 关闭或打开 Azure 数据工厂触发器，请参阅与管道触发器部署相关的 示例预部署和部署后脚本 和 CI/CD 改进。

处理重复写入

大多数提取、转换和加载管道旨在处理重复的写入，因为回填和重述过程需要它们。 支持透明故障转移的数据接收器可以通过合并记录或删除和插入特定时间范围内的所有记录来处理重复写入。

对于在故障转移后更改终结点的数据接收器，主存储和辅助存储可能具有重复或部分数据。 你需要手动合并数据。

检查见证并控制管道流量（可选）

通常，需要设计管道以包含活动（例如失败和查找活动），以便从兴趣点重启失败的管道。

  1. 在数据工厂中添加全局参数以指示区域，例如 region='EastUS' 在主数据工厂和 region='CentralUS' 辅助数据工厂中。

  2. 在第三个区域创建见证。 见证可以是 REST 调用，也可以是任何类型的存储。 见证服务器默认返回当前主要区域，例如 'EastUS'。

  3. 发生灾难时，手动更新见证服务器以返回新的主要区域，例如 'CentralUS'。

  4. 在管道中添加一个活动，以查找见证并将当前主值与全局参数进行比较。

    • 如果参数匹配，此管道将在主要区域运行。 继续执行主处理任务。

    • 如果参数不匹配，则此管道在次要区域中运行。 仅返回结果。

Note

此方法在管道中引入了对见证查找的依赖项。 未能读取见证会停止所有管道运行。

Contributors

Microsoft维护本文。 以下参与者撰写了本文。

Principal authors:

Other contributors:

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

Next steps