编辑

通过

你当前正在访问 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 灾难恢复提供的自动恢复，以及使用持续集成和持续交付 (CI/CD) 进行的用户管理的恢复。

体系结构

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

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

工作流

  1. 数据工厂和 Azure Synapse 管道通过使用 Azure 区域和 Azure 可用性区域来实现复原。

    • 每个 Azure 区域都有一组数据中心，这些数据中心部署在延迟定义的范围内。
    • Azure 可用性区域是每个 Azure 区域中具有本地容错性的物理上独立的位置。
    • 所有 Azure 区域和可用性区域都通过专用的区域低延迟网络采用高性能网络进行连接。
    • 所有已启用可用性区域的区域都至少有三个单独的可用性区域，以确保复原能力。

  2. 当区域中的数据中心、数据中心的一部分或可用性区域出现故障时，可在区域内复原的数据工厂和 Azure Synapse 管道将发生故障转移，停机时间为零。

组件

方案详细信息

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

Metadata

  • 管道
  • 数据集
  • 链接服务
  • 集成运行时
  • 触发器

监视数据

  • 管道
  • 触发器
  • 活动运行

灾难可能以不同的方式发生，例如硬件故障、自然灾害或人为错误或网络攻击导致的软件故障。 根据故障类型，其地理影响可以是区域性的，也可以是全局性的。 规划灾难恢复策略时，请考虑灾难的性质及其地理影响。

Azure 中的 BCDR 采用共担责任模型。 许多 Azure 服务要求客户明确设置其 DR 策略，而 Azure 则根据需要提供基线基础结构和平台服务。

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

使用 Azure 灾难恢复进行自动恢复

使用自动恢复提供的 Azure 备份和灾难恢复，当具有配对区域的 Azure 区域发生完全区域性中断时，数据工厂或 Azure Synapse 管道会在设置了自动恢复的情况下自动故障转移到配对区域。 东南亚和巴西地区除外，这些区域的数据驻留要求将数据保留在这些区域。

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

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

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

若要在整个区域发生故障时实现 BCDR，需要在次要区域中具有数据工厂或 Azure Synapse 工作区。 如果数据工厂或 Azure Synapse 管道意外删除、中断或发生内部维护事件，你可以使用 Git 和 CI/CD 手动恢复管道。

或者，可以使用主动/被动实现。 主要区域处理正常操作并保持活动状态，而次要 DR 区域需要预先计划的步骤（具体取决于具体实现）才能提升为主要区域。 在这种情况下，基础结构的所有必要配置都在次要区域中可用，但未预配。

可能的用例

用户管理的冗余在以下情况下很有用：

  • 因人为错误意外删除管道工件。
  • 由于没有灾难报告而未触发 BCDR 的长时间中断或维护事件。

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

注意事项

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

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。

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

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

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

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

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

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。

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

部署此方案

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

设置自动恢复

在数据工厂中，可以在“集成运行时设置”中为活动执行或调度设置 Azure 集成运行时 (IR) 区域。 若要在发生完全区域性中断的情况下启用自动故障转移，请将“区域”设置为“自动解决”。

显示在“集成运行时设置”中选择“自动解析”以启用自动故障转移的屏幕截图。

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

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

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

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

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

禁用触发器

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

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

处理重复写入

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

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

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

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

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

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

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

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

    • 如果参数匹配，则此管道在主要区域上运行。 继续进行实际操作。
    • 如果参数不匹配，则此管道在次要区域上运行。 只返回结果。

注意

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

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

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

后续步骤