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

Azure 数据平台的 DR - 体系结构

Azure Synapse Analytics

Azure 机器学习

Azure Cosmos DB

Azure Data Lake

Azure 事件中心

用例定义

为了支持此有效示例，虚构公司“Contoso”将与基于 Microsoft 参考体系结构的 Azure 数据平台一起使用。

数据服务 - 组件视图

Contoso 实现了以下基础 Azure 体系结构，这是企业登陆区域设计的子集。

以下说明中的数字对应于上图。

Contoso 的 Azure 基础 - 工作流

企业注册 - Contoso 的 Azure 中顶级父企业注册，反映其与Microsoft的商业协议、其组织结构和可用的 Azure 订阅。它为订阅以及如何管理数字资产提供计费基础。
标识和访问管理 – 在 Contoso 的 Azure 资产中提供标识、身份验证、资源访问和授权服务所需的组件。
管理组和订阅组织 - 一个可缩放的组层次结构，与数据平台的核心功能保持一致，允许使用集中管理的安全性和治理大规模实施，其中工作负荷具有明确的分离。管理组提供了订阅上方的治理范围。
管理订阅 - 支持数据平台所需的各种管理级别功能的专用订阅。
连接订阅 - 数据平台的连接功能的专用订阅，可用于标识命名服务、确定内部和外部服务之间的安全路由和通信。
登陆区域订阅 - 适用于 Azure 本机、联机应用程序、内部和外部面向工作负荷和资源的一对多订阅
DevOps 平台 - 支持整个 Azure 资产的 DevOps 平台。此平台包含代码基源代码管理存储库和 CI/CD 管道，用于自动部署基础结构即代码（IaC）。

注意

许多客户仍保留大型基础结构即代码 (IaaS) 占用空间。要提供跨 IaaS 的恢复功能，要添加的关键组件是 Azure Site Recovery。 Site Recovery 将在区域之间协调 Azure VM、本地虚拟机和物理服务器并将其将自动复制到 Azure，以及将本地计算机复制到辅助数据中心。

在此基础结构中，Contoso 实现了以下元素来支持其企业商业智能需求，这些元素与使用 Azure Synapse 进行端到端分析中的指南保持一致。

Contoso 的数据平台

Contoso 的数据平台 - 工作流

工作流按照数据流从左到右进行读取：

数据源 - 数据平台可以使用的源或数据类型。
引入 - 用于从不同结构和速度的各种源引入数据的平台功能。此设计反映了 Lambda 体系结构。
存储 - 能够大规模安全地存储已引入到平台上的数据。
流程 - 用于处理数据的平台功能，使其“适合”下游流程，如清理、标准化和建模。数据的预处理通常确保数据处于“位置和条件，可供使用”。
扩充 - 通过统计、机器学习或其他建模技术或预生成的 Azure AI 服务增强平台上处理的数据的功能。
服务 - 平台为下游使用塑造和呈现数据的功能。
数据使用者 - 使用来自平台的各种服务触摸点的数据的个人、应用程序或下游进程。
发现和管理 - 平台管理其包含的数据的功能，并确保其已编制索引、可发现/可搜索、经过充分描述，并且对最终用户和使用过程是透明的。
平台 - 构建平台的基础，即 Contoso 的 Azure 基础，如上所述。

注意

对于许多客户而言，使用的数据平台参考体系结构的概念级别将保持一致，但物理实现可能会有所不同。例如，可通过 Azure 数据工厂执行 ELT（提取、加载、转换）过程，并通过 Azure SQL 服务器执行数据建模。为了解决此问题，下面的有状态组件与无状态组件部分将提供指导。

对于数据平台，Contoso 已为所有组件选择了建议的最低生产服务层级，并已选择根据运营成本最小化方法采用“在灾难时重新部署”灾难恢复（DR）策略。

以下各部分将提供对 DR 流程的基线了解，以及客户可用来改善这一状况的方法。

Azure 服务和组件视图

下表列出了跨 Contoso 数据平台使用的每个 Azure 服务和组件的明细，以及用于 DR 提升的选项。

注意

以下部分按有状态服务与无状态服务进行组织。

有状态基础组件

Microsoft Entra ID，包括角色权利
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：Premium P1
- DR 提升选项：Microsoft Entra 复原能力是其软件即服务（SaaS）产品/服务的一部分。
- 注意
  - Microsoft Entra ID 中提升服务复原能力
Azure Key Vault
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
恢复服务保管库
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：默认（异地冗余存储 (GRS)）
- DR 提升选项：启用跨区域还原会在辅助配对区域中创建数据还原。
- 注意
  - 虽然本地冗余存储（LRS）和区域冗余存储（ZRS）可用，但它需要默认设置中的配置活动。
Azure DevOps
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：DevOps 服务
- DR 提升选项：DevOps 服务和数据复原是其 SaaS 产品/服务的一部分。
- 注意
  - DevOps Server 作为本地产品/服务仍将是客户对灾难恢复的责任。
  - 如果使用第三方服务（SonarCloud、Jfrog Artifactory、Jenkins 生成服务器），则它们仍将是客户从灾难中恢复的责任。
  - 如果在 DevOps 工具链中使用 IaaS VM，它们仍将是客户从灾难中恢复的责任。

无状态基础组件

订阅
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
管理组
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
Azure Monitor
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
成本管理
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
Microsoft Defender for Cloud
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
Azure DNS
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：单一区域 - 公共
- DR 提升选项：N/A、DNS 设计高度可用。
网络观察程序
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
虚拟网络，包括子网、用户定义路由 (UDR) 和网络安全组 (NSG)
- 组件恢复责任：Contoso
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：不适用
- DR 提升选项： VNET 可以复制到辅助配对区域。
Azure 防火墙
- 组件恢复责任：Contoso
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：标准
- DR 提升选项：Azure 防火墙设计高度可用，可通过可用性区域创建，以提高可用性。
Azure DDoS
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：DDoS 网络保护
- DR 提升选项：N/A，涵盖为 Azure 服务的一部分。
ExpressRoute 线路
- 组件恢复责任：Contoso、连接合作伙伴和Microsoft
- 工作负荷/配置恢复责任：连接合作伙伴和Microsoft
- Contoso SKU 选择：标准
- DR 提升选项：
  - 可以提升 ExpressRoute 以使用专用对等互连，从而提供异地冗余服务。
  - ExpressRoute 还提供高可用性（HA）设计。
  - 站点到站点 VPN 连接可用作 ExpressRoute 的备份。
- 注意
  - ExpressRoute 具有内置冗余，每个线路包含两个连接到来自连接提供商/客户端网络边缘的 ExpressRoute 位置的两个Microsoft企业边缘路由器（MSE）的连接。
  - ExpressRoute 高级线路将允许访问全球所有 Azure 区域。
VPN 网关
- 组件恢复责任：Contoso
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：单一区域 - VpnGw1
- DR 提升选项：可将 VPN 网关部署到具有 VpnGw#AZ SKU 的可用性区域中，以提供区域冗余服务。
Azure 负载均衡器
- 组件恢复责任：Contoso
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：标准
- DR 提升选项：
  - 可为可用性区域的区域内的区域冗余配置负载均衡器。如果是这样，只要区域中的一个区域保持正常，数据路径就会生存。
  - 根据主要区域，可以为高度可用的跨区域部署部署跨区域负载均衡器。
- 注意
  - Azure 流量管理器是基于 DNS 的流量负载均衡器。此服务支持在全球 Azure 区域中为面向公众的应用程序分配流量。此解决方案将针对高可用性设计中的区域性中断提供保护。

有状态数据平台特定的服务

存储帐户：Azure Data Lake Gen2
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：LRS
- DR 提升选项：存储帐户具有从主要区域冗余到次要区域冗余的广泛数据冗余选项。
- 注意
  - 建议使用 GRS 来提升冗余性，从而在配对区域中提供数据的副本。
Azure 事件中心
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：标准
- DR 提升选项：可以在启用可用性区域的情况下创建事件中心命名空间。可以扩展此复原能力，以涵盖异地灾难恢复的完整区域中断。
- 注意
  - 根据设计，事件中心异地灾难恢复不会复制数据，因此需要注意故障转移和回退的几个注意事项。
Azure IoT 中心
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：标准
- DR 提升选项：
  - IoT 中心跨区域 HA 实施可以提升复原能力。
  - Microsoft提供以下 HA/DR 选项指南。
- 注意
  - IoT 中心提供 Microsoft 发起的故障转移和手动故障转移功能，可将数据复制到每个 IoT 中心的配对区域。
  - IoT 中心提供区域内 HA，并在预定义的 Azure 区域集中创建时自动使用可用性区域。
Azure 流分析
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：标准
- DR 提升选项：虽然 Azure 流分析是一种完全托管的平台即服务（PaaS）产品/服务，但它不提供自动异地故障转移。可以通过在多个 Azure 区域中部署相同的流分析作业来实现异地冗余。
Azure 机器学习
- 组件恢复责任：Contoso 和 Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：常规用途、D 系列实例
- DR 提升选项：
  - Azure 机器学习依赖于多项 Azure 服务，其中一些服务是在客户的订阅中预配的。因此，客户仍负责这些服务的高可用性配置。
  - 可以通过多区域部署提升复原能力。
- 注释：
  - Azure 机器学习本身不提供自动故障转移或灾难恢复。
Power BI
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：Power BI Pro
- DR 提升选项：N/A、Power BI 的复原能力是其 SaaS 产品/服务的一部分。
- 注意
  - Power BI 驻留在 Office365 租赁中，而不是 Azure 的租户。
  - Power BI 使用 Azure 可用性区域来保护 Power BI 报表、应用程序和数据免受数据中心故障的影响。
  - 对于区域性故障，Power BI 将故障转移到新区域（通常位于同一地理位置），如Microsoft信任中心所述。
Azure Cosmos DB
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：具有定期备份的单区域写入
- DR 提升选项：
  - 发生区域性服务中断时，单区域帐户可能会失去可用性。复原能力可以提升到单个写入区域和至少一秒钟（读取）区域，并启用服务管理的故障转移。
  - 建议将 Azure Cosmos DB 帐户用于生产工作负载，以启用自动故障转移。如果没有此配置，则在写入区域服务中断的整个持续时间内，帐户将处于写入可用性缺失的状态，因为缺少区域连接时，手动故障转移将不会成功。
- 注意
  - 为了防止区域中的数据丢失，Azure Cosmos DB 提供了两种不同的备份模式定期 - 。
  - 区域故障转移在 Azure Cosmos DB 客户端中进行检测和处理。它们不需要在应用程序中进行任何更改。
  - 以下指南介绍了基于 Cosmos DB 配置的区域中断的影响。
Azure Data Share
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：不适用
- DR 提升选项：高可用性部署可将 Azure Data Share 复原能力提升到次要区域。
Microsoft Purview
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：不适用
- DR 提升选项：N/A
- 注意
  - 截至 2024 年 10 月，Microsoft Purview 不支持自动化业务连续性和灾难恢复（BCDR）。在添加该支持之前，客户负责所有备份和还原活动。

无状态数据平台特定服务

Azure Synapse：管道
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：计算优化 Gen2
- DR 提升选项：N/A、Synapse 复原能力是其使用自动故障转移功能的 SaaS 产品/服务的一部分。
- 注意
  - 如果使用自承载数据管道，它们仍将是客户从灾难中恢复的责任。
Azure Synapse：数据资源管理器池
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：计算优化，小型（4 核心）
- DR 提升选项：N/A、Synapse 复原能力是其 SaaS 产品/服务的一部分。
- 注意
  - 默认情况下为 Synapse 数据资源管理器启用可用性区域（如果可用）。
Azure Synapse：Spark 池
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：计算优化，小型（4 核心）
- DR 提升选项：N/A、Synapse 复原能力是其 SaaS 产品/服务的一部分。
- 注意
  - 目前，Azure Synapse Analytics 仅支持专用 SQL 池的灾难恢复，并且不支持 Apache Spark 池。
Azure Synapse：无服务器和专用 SQL 池
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Contoso
- Contoso SKU 选择：计算优化 Gen2
- DR 提升选项：N/A、Synapse 复原能力是其 SaaS 产品/服务的一部分。
- 注意
  - Azure Synapse Analytics 全天自动拍摄快照，以创建七天的还原点。
  - Azure Synapse Analytics 每天对配对数据中心执行一次标准异地备份。异地还原的恢复点目标 (RPO) 为 24 小时。
  - 如果使用自承载数据管道，则客户仍负责从灾难中恢复。
Azure AI 服务
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：即用即付
- DR 提升选项：N/A，AI 服务的 API 由 Microsoft托管的数据中心托管。
- 注意
  - 如果 AI 服务已通过客户部署的 Docker 容器进行部署，恢复仍由客户负责。
Azure AI 搜索
- 组件恢复责任：Microsoft
- 工作负荷/配置恢复责任：Microsoft
- Contoso SKU 选择：标准 S1
- DR 提升选项：
  - 可以通过跨可用性区域和区域使用副本将 AI 搜索提升到 HA 设计。
  - 不同区域中的多个服务可以进一步扩展复原能力。
- 注意
  - 在 AI 搜索中，业务连续性（和灾难恢复）是通过多种 AI 服务实现的。
  - 没有内置的灾难恢复机制。如果在灾难性故障期间需要持续服务，建议在不同的区域中提供第二个服务，并实施异地复制策略，以确保索引在所有服务中完全冗余。

有状态组件与无状态组件

特别是 Microsoft 产品套件和 Azure 的创新速度，这意味着我们用于此工作示例的组件集将迅速发展。为了防止提供过时的指导并将此指导扩展到本文档未显式涵盖的组件，以下部分提供了一些基于粗粒度状态分类的说明。

如果组件/服务旨在记住前面的事件或用户交互，则可以将其描述为有状态。无状态意味着没有以前的交互记录，必须完全基于每个交互请求附带的信息对其进行处理。

对于需要重新部署的 DR 场景：

可以使用至少冒烟测试从源代码管理重新部署“无状态”的组件/服务（如 Azure Functions 和Azure 数据工厂管道），以验证可用性，然后再引入更广泛的系统。
具有“有状态”的组件/服务（如Azure SQL 数据库和存储帐户）需要更多关注。
- 在采购组件时，选择数据冗余功能将是一个关键的决策。此决策通常侧重于可用性与持久性之间的权衡，同时降低运营成本。
数据存储也需要数据备份策略。基础存储的数据冗余功能可缓解某些设计的这种风险，而其他设计（如 SQL 数据库）则需要单独的备份过程。
- 如有必要，可以通过冒烟测试通过验证的配置从源代码管理重新部署组件。
- 重新部署的数据存储必须将其数据集解除冻结。解除冻结可通过数据冗余（如果可用）或备份数据集来完成。解除冻结完成后，必须验证其准确性和完整性。
  - 根据备份过程的性质，备份数据集可能需要在应用之前进行验证。备份进程损坏或错误可能会导致使用较早的备份来代替可用的最新版本。
- 组件日期/时间戳与当前日期之间的任何增量都应通过重新执行或重播从该点向前的数据引入过程来解决。
- 组件数据集更新后，可以将其引入到更广泛的系统中。

其他关键服务

本部分包含其他关键 Azure 数据组件和服务的高可用性（HA）和 DR 指南。

Azure Databricks - DR 指南可在产品文档中找到。
Azure 分析服务 - 可以在产品文档中找到 HA 指南。
Azure Database for MySQL
- 可以在产品文档中找到灵活服务器 HA 指南。
- 可以在产品文档中找到单服务器 HA 指南。
SQL
- 可以在产品文档中找到 Azure VM 上的 SQL 指南。
- 可以在产品文档中找到 Azure SQL 和Azure SQL 托管实例指南。

后续步骤

了解方案体系结构后，可以了解方案详细信息。

通过