通过

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

优化业务连续性和灾难恢复

  • 项目

将 Oracle 资源迁移到 Azure 时，请考虑数据库的可靠性，以及虚拟机 (VM) 、虚拟网络子网和存储组件上层的可靠性。

Azure 上的 Oracle 基础结构即服务 (IaaS) 可以实现最苛刻的 Oracle 工作负载所需的复原目标。 若要有效地使用本文中的指南，请首先定义复原能力关键绩效指标， (KPI) 基于业务需求。 使用恢复时间目标 (RTO) 和恢复点目标 (RPO) 要求作为基线 KPI 来确定 Azure 上 Oracle 工作负载的最佳体系结构。

RTO 是发生灾难、故障或类似事件后应用程序保持不可用的最长时间。

RPO 是发生灾难、故障或类似事件后的最大数据丢失量。

数据保护的备份方法

Azure IaaS 上 Oracle 工作负载的三种 Oracle 数据库备份方法包括：

  • 流式备份。 对此方法使用 Oracle 恢复管理器 (RMAN) 。 RMAN 将备份流式传输到顺序磁带介质。

    Azure 上的备份目标包括：

    • 可在 Azure 市场 中找到的非 Microsoft 虚拟磁带库。
    • 本地和远程文件共享，例如使用网络文件系统协议Azure Blob 存储、Azure 文件存储和Azure NetApp 文件。

  • 存储级快照。 对此方法使用 Azure 备份。 此方法依赖于用于数据库文件的存储类型。 例如，如果使用 Azure 托管磁盘（例如 Azure 高级 SSD），Azure 备份与 Oracle 数据库集成。 如果使用 Azure NetApp 文件，则可以使用Azure NetApp 文件数据保护功能，例如Azure NetApp 文件备份和跨区域复制。

  • VM 级备份。 对此方法使用 Azure 备份。

流式传输大型数据库的备份时，将数据复制到然后还原所需的时间可能会超过 RTO 要求。 存储级快照是该方案的最佳选择。

建议

  • 仔细考虑是实现基于流式处理、基于存储级快照还是基于这两种策略的备份策略。

  • 评估备份策略对 RTO 和 RPO 要求的影响。

  • 根据每个选项的记录吞吐量限制，分析 RMAN 备份的可用存储目标。 选择符合要求的选项。

  • 请考虑对存储级快照使用 Azure 备份，并考虑将快照放置在配对区域或可用性区域中，以便获得额外的保护。

  • 请考虑使用各种存储选项来存储恢复数据库所需的存档日志备份。 请考虑每个选项的性能、复制和成本注意事项。

  • 制定并定期测试备份和还原计划，以防止生产环境中出现不必要的意外情况。

服务保护和业务连续性

本部分介绍如何通过实施服务保护和业务连续性 (BC) 注意事项， (Azure IaaS 上的 Oracle 工作负载的 DR) 提高总体高可用性 (HA) 和灾难恢复。

合并以下建议，以提高体系结构冗余，并最终最大限度地延长服务可用时间。 旨在最大程度地减少因计划内中断（例如修补程序、更新和升级）以及计划外中断（如故障）而导致的服务停机时间。 使用 Azure 和 Oracle 功能改进从地理位置范围的故障中恢复。

Azure 为 Oracle on IaaS 体系结构中的单个组件的高可用性提供了许多选项。 例如，你能够：

  • 在可用性集中部署 VM，以确保单独的容错域和更新域。
  • Create可用性区域，以防止数据中心故障。
  • 将部署放置在不同的区域中，以防止发生全区域故障。

各种 Azure 存储功能提供不同的存储冗余级别，例如本地冗余存储、区域冗余存储和异地冗余存储。 在 Azure IaaS 上规划 Oracle 工作负载部署时，请考虑每个选项。

还可以使用 Oracle Data Guard，它是用于 Oracle 数据库服务保护设置的工具。 Data Guard 转发并将事务日志应用于一个或多个备用数据库。 此过程维护主数据库的确切副本，如果发生计划内维护或故障情况，则可以故障转移到这些副本。

Data Guard 有三种数据复制模式：最大保护、最大可用性和最佳性能。 每种复制模式为辅助数据库上的应用程序提供不同的日志传输模式组合和不同的事务保证。

根据策略（例如零延迟或零数据丢失策略），可以选择同步或异步配置。 还可以根据最大停机时间要求实现快速启动故障转移。 提供参考体系结构，可在不到一分钟或五分钟且最多四小时内提供恢复。 Oracle 数据库的Enterprise Edition包括 Data Guard。

Oracle GoldenGate 是另一种工具，可用于在两个数据库之间复制数据并启用多主方案。 必须单独购买 GoldenGate。

建议

  • 请考虑 Azure 为 Azure IaaS 上的 Oracle 实现中各种基础结构组件的高可用性提供的功能。

  • 使用 Data Guard for HA 和 DR 时，请仔细选择满足要求的数据库保护模式。 例如，最大性能模式可将对源的影响降至最低，但数据丢失的可能性最大。 有关详细信息，请参阅适用于 Azure 上的 Oracle 的 BCDR 虚拟机登陆区域加速器和 Oracle Data Guard 保护模式。

  • 请考虑自动执行故障转移过程。 例如，可以使用快速启动故障转移。

  • 为故障转移过程建立测试过程，并定期执行测试以避免任何问题。

  • 使用 Azure 本机功能（如可用性区域）和 Oracle 本机工具（如 Data Guard）来整体构建解决方案，以满足 HA 和 DR 要求。 以下两个示例使用 Azure 本机组件和 Oracle 原生组件。

使用被动待机Create故障转移

本部分介绍在具有被动备用状态的双可用性区域部署中业务关键型 Oracle 应用程序的故障转移方案示例。

业务关键型 Oracle 应用程序（如 Oracle 电子商务套件）需要故障防护，因此需要整体体系结构。

本示例：

  • 具有双可用性区域部署。 应用层将 Azure Site Recovery 与被动辅助 VM 配合使用。

  • 利用 Data Guard 快速启动故障转移功能。 若要获得最高可用性，建议安装两个观察程序。 主要观察程序位于可用性区域 1 中，辅助观察程序位于可用性区域 2 中。 观察者监视和定向流量。 当主数据库不可用时，观察程序会自动故障转移到辅助数据库。 Data Guard 执行重做同步。恢复同步的时间范围取决于重做配置。

  • 已将 Data Guard 配置为 数据保护模式，例如最大可用性、最大性能或最大保护。 有关为工作负载要求选择模式的详细信息，请参阅 Oracle Data Guard 保护模式。

以下体系结构的停机时间阈值小于 5 分钟。

显示具有被动待机的故障转移的体系结构的关系图。

使用活动待机Create故障转移

本部分介绍具有活动备用状态的双可用性区域部署中业务关键型 Oracle 应用程序的故障转移方案示例。

在本示例中：

  • Web 服务器层、应用程序层和数据库层驻留在其自己的虚拟网络子网中。

  • 主数据库驻留在可用性区域 1 中。

  • 使用 Active Data Guard 将主数据库复制到活动备用数据库的数据库驻留在可用性区域 3 中。

注意

此设置需要 Active Data Guard 许可证。

以下体系结构的停机时间阈值小于一分钟。 此故障转移方案具有活动备用配置，但具有只读功能。

显示具有活动备用状态的故障转移的体系结构的关系图。

后续步骤

优化安全性