通过

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

Azure 虚拟机登陆区域加速器上 Oracle 的业务连续性和灾难恢复

本文基于 业务连续性和灾难恢复 （BCDR） 的 Azure 登陆区域设计领域中定义的注意事项和建议。 本文遵循该指南，并介绍有关 Azure 基础结构虚拟机 （VM） 上 Oracle 工作负载部署的 BCDR 选项的设计注意事项和最佳做法。

Azure 提供的服务可用于设计高度可用且可复原的体系结构。 本指南概述了各种选项和最佳做法，可帮助你为 Azure 虚拟机登陆区域加速器上的 Oracle 数据库设计高可用性和灾难恢复。 它还介绍了如何配置随附的 Azure 服务，以帮助您实现解决方案的高端到端到端可用性。

开始吧

要为您的工作负载环境构建弹性架构，请根据不同故障级别的恢复时间目标 （RTO） 和恢复点目标 （RPO） 确定解决方案的可用性要求。 RTO 是应用程序在事件发生后保持不可用的最长时间。 RPO 是灾难期间的最大数据丢失量。 确定解决方案的要求后，设计体系结构以提供已建立的弹性和可用性级别。

Azure 上的 Oracle 工作负载主要使用 Oracle Data Guard，这是使用复制技术的内置 Oracle Database Enterprise Edition 功能。 您可以使用 Data Guard 来满足高可用性和灾难恢复需求。 Data Guard 提供三种保护模式：最高性能、最高可用性和最高保护。 根据您的架构设计以及特定的 RPO 和 RTO 要求选择您的保护模式。

配置工作负载以实现高可用性

运行 Oracle 工作负载的 Azure 虚拟机实例受益于 Azure 虚拟机规模集体系结构，特别是灵活的业务流程模式。 高可用性配置提供近乎实时的数据复制，并可能具有快速故障转移功能。 高可用性配置不为 Azure 数据中心级别或区域级别的故障提供保护。

选择正确的高可用性选项

使用以程图为您的 Oracle 数据库选择最佳高可用性选项。

显示 Oracle on Virtual Machines 登录区域加速器的服务设计保护流程图的图表。

在最高可用性模式下使用 Data Guard 实现高可用性

处于最高可用性模式的 Data Guard 提供最高可用性，并承诺零数据丢失 （RPO=0） 用于正常作。 对于在虚拟机规模集灵活业务流程中创建的两个 Oracle 数据库服务器的高可用性配置，Azure 为跨容错域的实例的服务级别协议 （SLA） 提供 99.95% 服务可用性。 Azure 为分布在 多个可用区的实例提供 99.99% 服务可用性。 有关详细信息，请参阅 虚拟机规模集的高可用性。

显示虚拟机登陆区域加速器上使用 Data Guard for Oracle 的高可用性配置的图表。

有关 Azure 上 Data Guard 的分步配置，请参阅 在基于 Linux 的 Azure VM 上实施 Oracle Data Guard。

在最大保护模式下使用 Data Guard 以实现高可用性

如果您需要数据库的事务一致性副本，请考虑在最高保护模式下使用 Data Guard。 但是，最大保护模式不允许在备用数据库不可用时继续事务。 因此，尽管使用虚拟机规模集灵活业务流程，但在使用最大保护模式时，SLA 会降低到 99.9% x 99.9% = 99.8%。 此配置可确保数据的一致副本，但不一定会提高可用性。

此体系结构的其他属性与最大可用性模式相同。 例如，RPO 为零，RTO 小于或等于 2 分钟。

考虑其他实现高可用性的方法

以下各节介绍了高可用性的特殊注意事项。

使用可用区提高高可用性

Azure 可用性区域 是位于同一 Azure 区域内的 Azure 数据中心。 可用区的往返延迟小于 2 毫秒。 您通常将可用区用于灾难恢复目的，但您可以使用它们来提高高可用性。 如果这样做，则必须确保您的解决方案可以以可用区提供的延迟和吞吐量运行。

具有虚拟机规模集灵活编排的可用性区域的一个优势是，VM 可用性 SLA 增加到 99.99%。

使用共享存储集群实现高可用性

共享存储集群技术提供了独特的属性，可以帮助您实现业务目标。 例如，您可以实施具有共享存储的 Pacemaker 和 Corosync （PCS） 集群。 您可以使用托管磁盘或 Azure NetApp 文件作为 PCS 群集实例的共享存储。 PCS 群集不会复制数据。 它为虚拟 IP 服务提供静态 IP 地址或 IP 网络名称，该地址或 IP 网络名称在故障转移之间不会更改。

注释

PCS 群集不是 Oracle 认证的解决方案。 在选择高可用性架构时，请记住此因素。

显示 Pacemaker for Oracle on Virtual Machines 登陆区域加速器的高可用性配置的图表。

使用邻近放置组

为了提供尽可能低的延迟，请将 VM 放置在尽可能近的位置。 您可以在 邻近置放群组中部署它们。 邻近放置组是一个逻辑分组，可确保 Azure 计算资源在物理上彼此靠近。 邻近置放群组对于需要低延迟的工作负载非常有用。

配置工作负载以进行灾难恢复

灾难恢复体系结构可针对影响 Azure 数据中心或区域的故障或阻碍整个区域中应用程序功能的故障提供复原能力。 在这种情况下，您应该将整个工作负载移动到不同的数据中心或区域。

根据您的解决方案要求选择灾难恢复架构。 您可以根据 RTO 和 RPO 确定您的要求。 灾难恢复架构适用于特殊故障情况，因此故障转移过程是手动的。 在高可用性设计中，故障转移过程是自动的。 在灾难恢复架构中，您应该对 RTO 和 RPO 有更宽松的要求，这样可以节省资金。

本文重点介绍主服务器和辅助服务器都位于 Azure 上的方案。 您还可以在本地拥有一台主服务器，在 Azure 上拥有一台辅助服务器，用于灾难恢复目的。 有关详细信息，请参阅 Azure 上的本地主站点和灾难恢复站点。

选择正确的灾难恢复选项

使用以程图为您的 Oracle 数据库选择最佳灾难恢复选项。

显示 Oracle on Virtual Machines 登录区域加速器的数据保护设计流程图的图表。

使用 Data Guard 进行灾难恢复

您可以使用 Data Guard 将数据复制到灾难恢复站点。 将该站点用作同一区域或不同区域中的另一个可用区，具体取决于您的数据保护要求。 您的配置还取决于生产站点上的可用区结构。 灾难恢复场景中的 Data Guard 实现与前面讨论的高可用性场景类似，但有一些重要区别。 例如：

  • 在高可用性方案中故障转移到次要副本时，将 Azure 负载均衡器配置为将请求重定向到新的主数据库实例。

  • 故障转移到灾难恢复站点时，会将 整个 解决方案故障转移到新站点。 为避免延迟挑战，您通常需要为应用程序服务配置故障转移。

如果灾难恢复站点位于另一个区域，则需要根据您的要求设计用于故障转移的站点。

单个数据中心内的延迟小于彼此相距较远的数据中心之间的延迟，也远小于不同区域之间的延迟。 因此，最简单、成本最低的选择是在最高性能模式下使用 Data Guard 进行灾难恢复。 如果最高性能模式下的潜在数据丢失过高，则可以将最大可用性模式与 Oracle Data Guard Far Sync 机制结合使用。 但是 Far Sync 实例会在主环境和备用环境中触发 Active Data Guard 许可。 有关更多信息，请参阅 Oracle 许可证详细信息。

此外，跨 Azure 区域或数据中心发送数据时，需要为发送到灾难恢复站点的数据（如重做日志）支付出口成本。 如果您不需要复制数据库中的所有数据，则可以使用基于 Oracle Golden Gateway 的复制根据需要仅复制部分数据，从而降低出口成本。

显示虚拟机登陆区域加速器上使用 Data Guard for Oracle 的灾难恢复配置的图表。

有关 Azure 上数据卫士的分步配置，请参阅 在基于 Linux 的 Azure Linux VM 上实现数据卫士。

使用 Golden Gate 进行灾难恢复

Golden Gate 是一种逻辑复制软件，可用于实时复制、筛选和转换数据，将数据从源数据库复制到目标数据库或在多个主数据库之间。 此功能可确保近乎实时地复制源数据库中的更改，以便目标数据库使用最新数据保持最新状态。

您可以使用 Golden Gate 将数据从主数据库复制到灾难恢复配置中的辅助数据库。 如果您只需要保护部分数据，Golden Gate 尤其实用。 为避免复制不必要的数据，请使用 Golden Gate 选择性地复制表，并在复制期间筛选出表行。

有关如何在 Azure 上实现 Golden Gate 的分步指南，请参阅 在基于 Linux 的 Azure VM 上实现 Golden Gate。

使用备份进行灾难恢复

备份和还原是灾难恢复体系结构的传统方法。 对于 Azure 上的 Oracle 数据库，备份作为灾难恢复方法有两个主要组件：

  • 从数据库中提取并移动数据备份，以确保灾难恢复站点具有 up-to-date 数据。

  • 确保在灾难恢复站点进行 up-to-date 部署。 要更新站点，请将所有网络组件、应用程序服务器和配置的相同部署复制到灾难恢复站点。

您可以使用多个备份选项来复制数据。 有关详细信息，请参阅 Azure 上的 Oracle Database 的备份策略。

请考虑使用以下方法之一来维护灾难恢复站点：

方法 1： 为避免额外的维护工作和成本，请不要在灾难恢复站点维护任何物理部署。 您可以使用基础设施即代码和站点可靠性工程实践来开发和维护存储库。 此存储库可以在故障转移时将部署作为配置复制到灾难恢复站点。 此方法可优化成本，因为在故障转移发生之前，它不会使用任何物理资源。

重要

如果您在故障转移期间从头开始创建整个部署，则必须确保您的部署能够满足解决方案的 RTO 要求。 为了确保部署代码不会损坏，您必须定期模拟和测试灾难恢复方案。

方法 2： 部署和维护生产环境的扩展版本。 拥有一个可以正确处理小型工作负载的版本，并且您可以在故障转移期间根据需要进行扩展以服务于生产负载。 此方法很常用，尤其是对于您不想冒险创建整个环境的复杂部署，或者如果您想快速故障转移以提供较低的 RTO。

方法 3： 在灾难恢复站点中部署和维护您的整个解决方案，以实现最快的 RTO 和故障转移时间。 由于运行完全冗余的基础设施，此方法会增加成本。

考虑实施灾难恢复的其他方法

以下部分介绍了灾难恢复的特殊注意事项。

使用 Far Sync

Far Sync 不会提高高可用性功能，但您可以使用它来实现 Oracle 数据库的零数据丢失保护功能。 如果您的主数据库发生故障，您的工作负载可能需要零数据丢失。 有关详细信息，请参阅 Azure 上的 Oracle 参考体系结构。

选择正确的数据复制技术

除了本文中的技术之外，您还可以使用任何有助于跨两个 Oracle 数据库进行数据复制的技术，以维护 Azure 上 Oracle 数据库的高可用性副本和灾难恢复副本。 您选择的技术必须满足您在这些类别中的解决方案要求。

延迟： 将更新从主数据库复制到辅助数据库以实现高可用性和灾难恢复所需的时间应符合您的解决方案的要求。

带宽： 将数据复制到辅助数据库以实现高可用性和灾难恢复所需的带宽量和成本。 Azure 在可用性区域之间提供高速网络基础结构。 考虑复制到其他 Azure 区域以进行灾难恢复时，请考虑离开 Azure 数据中心的数据的带宽量和出口成本。

冲击： 复制对主数据库上的事务处理的影响级别应符合您的解决方案的要求。

数据丢失： 在主数据库突然发生故障期间，您预期的数据丢失量应符合您的解决方案的要求。

总拥有成本： 考虑非 Microsoft 复制解决方案的购置成本以及配置和维护复制解决方案所需的工作量。 验证这些因素是否符合解决方案的要求。

优化故障转移实例

在高可用性模式或高保护模式下使用 Data Guard 时，您可以配置自动故障转移，以便在主服务器发生故障时自动启动辅助服务器。 正确配置应用程序服务器后，可以确保在故障转移期间几乎没有应用程序停机时间。

在此实现中，数据库必须在故障转移后运行相同的作。 因此，您需要配置与主服务器具有相同 CPU、内存和输入/输出 （I/O） 容量的辅助服务器。 您需要使用辅助服务器保持高容量，这会增加 Azure 成本和 Oracle 数据库许可成本。 辅助服务器通常不处理用户请求。

Azure 为可用性区域中的 VM 提供 99.9% 的可用性。 有关详细信息，请参阅 VM 运行时间 SLA。 当您使用数据复制技术在同一可用区、不同可用区或不同区域中维护数据库的辅助副本时，您可以优化辅助容量。

使用此方法，辅助数据库配置了保持最新所需的容量。 发生故障时，辅助数据库的大小将调整为与主数据库相同的容量。 仅当出现故障时，才会执行此作。 因此，在正常作期间，您只需支付主服务器费用的一小部分。 主数据库在故障期间无法运行，因此您不需要其他 Oracle 数据库许可证。

将辅助数据库作为复制目标运行所需的容量取决于您使用的复制技术。 从本质上讲，事务性联机事务处理 （OLTP） 系统上的工作负载主要具有读取请求。 例如，在 OLTP 应用程序中，通常有 90% 个读取作和 10 个% 写入作，或者 95% 读取作和 5% 写入作。 数据复制实质上是复制在源数据库中写入请求的结果。 通过此设置，您可以预期辅助数据库将以主数据库容量的 1/10（如果您的读取比率为 90% 和 10% 写入比率）运行。

自动执行故障转移过程，以确保您在故障转移过程中符合企业标准。 您可以配置故障转移过程以包括简化端到端过程的服务器大小调整作。

配置网络拓扑以实现服务保护和数据保护

为了实现高可用性和灾难恢复，您需要做出财务和业务决策，以平衡恢复时间 （RTO） 和潜在数据丢失 （RPO） 与其他 Oracle 许可、VM 服务和数据传输成本。 在单个 Azure VM 上托管工作负载时，可以以较低的成本获得针对常见硬件故障的基本保护。 但是，单个 VM 上的故障可能会导致停机和数据丢失。 因此，在您的生产环境中，至少包括一个托管在具有 Data Guard 的单独 VM 上的辅助 Oracle 数据库。 根据您的要求，使用以下一个或多个 Data Guard 配置进行数据复制：

  • 最佳 RTO 和 RPO。 为了最大限度地减少延迟，请将辅助 Oracle 数据库合并到同一虚拟机规模集灵活业务流程中的单独 VM 上，并与主数据库位于同一可用区中。 此配置提供高可用性并防止单实例故障。

  • 数据中心故障的数据保护。 将辅助 Oracle 数据库放在第二个可用区中，以提供高可用性设置，并在整个可用区发生故障时提供保护。 此配置在主数据库和辅助数据库之间可能有长达 2 毫秒的延迟，这可能会影响性能、RTO 和 RPO。

  • 数据保护免受区域故障的影响。 为了帮助防止由于 Azure 区域故障而导致潜在的数据丢失，可以将辅助数据库放置在其他区域中。 此配置在区域之间可能具有 30 毫秒到 300 毫秒的延迟，因此您可能无法满足 RTO 和 RPO 目标。 此解决方案最适合区域灾难恢复，而不是高可用性。

业务连续性需要一种包含工作负载所有组件的集成方法。 网络基础结构是 Azure 上任何工作负载的主要组件。 您的网络基础设施需要与您的高可用性或灾难恢复架构保持一致。 请考虑以下网络基础设施因素：

  • Data Guard 提供高可用性，并且在大多数情况下为常见故障提供足够的支持。 可以将 VM 放置在虚拟机规模集灵活业务流程中。 为了减少网络延迟，单个解决方案中的所有服务都应位于同一可用区内，并且这些服务应共享同一虚拟网络。

    为了进一步保护，您可以战略性地将 VM 放置在单独的可用区中，而不是单个可用区中。 此方法可以防止数据中心故障期间停机。

  • 为了获得最大程度的保护，可以将辅助数据库放置在与主数据库区域不同的 Azure 区域中。 要应用持续更新，您可以使用 Data Guard 实现全局虚拟网络对等连接。 使用此方法可通过 Microsoft 主干网以私密方式将数据更新应用于次要区域。 资源直接通信，无需网关、额外跃点或通过公共互联网传输。

    此联网选项可跨不同区域中的对等虚拟网络提供高带宽、低延迟的连接。 可以使用全局虚拟网络对等互连，通过高速网络将主站点连接到不同区域中的灾难恢复站点。

针对各种故障类型的复原能力总结

失败方案 Azure 上的 Oracle 高可用性或灾难恢复方案 RPO/RTO
单个组件故障，如主机、机架、冷却、网络或电源故障 在同一虚拟机规模集中具有两个节点的 Data Guard，在同一数据中心内实现灵活的业务流程：

- 防止单个实例故障。
- 如果整个数据中心发生故障，则会导致停机。		 如果您使用 Observer 进行快速启动故障转移，并使用 Data Guard 的 MAX_AVAILABILITY 或 MAX_PROTECTION 模式：
- RPO 为零。
- RTO 小于或等于 2 分钟。
数据中心故障 具有两个节点位于不同可用区的 Data Guard：

- 防止数据中心故障。
- 如果整个区域发生故障，则会导致停机。
- 需要为应用程序服务器进行更多故障转移配置，以管理网络延迟。		 - RPO 小于或等于 5 分钟。
- RTO 小于或等于 5 分钟。

如果对 Data Guard 使用 MAX_PERFORMANCE 模式和 MAX_AVAILABILITY 模式：
- RPO 为零。
- RTO 小于或等于 5 分钟。
区域性故障 在单独的 Azure 区域中具有两个节点的 Data Guard：

- 防止区域性故障。
- 需要为应用程序服务器进行更多故障转移配置，以管理网络延迟。		 如果对 Data Guard 使用 MAX_PERFORMANCE 模式：
- RPO 大于或等于 10 分钟。
- RTO 大于或等于 15 分钟。
所有方案：单个组件、数据中心和区域故障 寄送到其他 Azure 区域的备份：

- 防止区域性故障。
- 要求在故障转移期间在目标区域中设置整个 Azure 环境。		 - RPO 大于或等于 24 小时。
- RTO 大于或等于 4 小时。

后续步骤

了解企业级方案中 Oracle on Virtual Machines 登陆区域加速器安全性的设计注意事项。

虚拟机登陆区域加速器上的 Oracle 安全准则