通过

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

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

  • 项目

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

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

开始使用

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

Azure 上的 Oracle 工作负荷主要使用 Oracle Data Guard，这是使用复制技术的内置 Oracle 数据库企业版功能。 可以使用 Data Guard 来满足高可用性和灾难恢复需求。 Data Guard 提供三种保护模式：最佳性能、最大可用性和最大保护。 根据体系结构设计和特定的 RPO 和 RTO 要求选择保护模式。

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

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

选择正确的高可用性选项

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

此图显示了虚拟机登陆区域加速器上 Oracle 的服务设计保护过程映射。

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

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

此图显示了在 虚拟机 登陆区域加速器上使用适用于 Oracle 的 Data Guard 的高可用性配置。

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

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

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

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

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

以下部分介绍高可用性的特殊注意事项。

使用可用性区域提高高可用性

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

具有虚拟机规模集灵活业务流程的可用性区域的优点是 VM 可用性 SLA 增加到 99.99%。

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

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

注意

PCS 群集不是 Oracle 认证的解决方案。 选择高可用性体系结构时，请记住这一因素。

此图显示了在 虚拟机 登陆区域加速器上使用适用于 Oracle 的 Pacemaker 的高可用性配置。

使用邻近放置组

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

为灾难恢复配置工作负荷

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

根据解决方案要求选择灾难恢复体系结构。 根据 RTO 和 RPO 确定要求。 灾难恢复体系结构适用于异常故障情况，因此需要手动执行故障转移过程。 在高可用性设计中，故障转移过程是自动的。 在灾难恢复体系结构中，RTO 和 RPO 的要求应该更加宽松，从而节省资金。

本文重点介绍主服务器和辅助服务器都位于 Azure 上的场景。 还可以在本地拥有主服务器和 Azure 上的辅助服务器，以便进行灾难恢复。 有关详细信息，请参阅 Azure 上的主站点和灾难恢复站点。

选择正确的灾难恢复选项

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

此图显示了 虚拟机 登陆区域加速器上 Oracle 的数据保护设计过程映射。

使用 Data Guard 进行灾难恢复

可以使用 Data Guard 将数据复制到灾难恢复站点。 根据数据保护的要求，将站点用作同一区域或不同区域中的另一个可用性区域。 配置还取决于生产站点上的可用性区域结构。 灾难恢复方案中的 Data Guard 实现类似于前面讨论的高可用性方案，但存在一些重要的差异。 例如：

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

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

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

单个数据中心内的延迟小于数据中心之间的延迟，这些数据中心之间彼此隔开的延迟远小于不同区域之间的延迟。 因此，最不复杂且成本最低的选项是出于灾难恢复目的，在最佳性能模式下使用 Data Guard。 如果最大性能模式下的潜在数据丢失过高，则可以将最大可用性模式与 Oracle Data Guard Far Sync 机制配合使用。 但是，Far Sync 实例在主要环境和备用环境中触发 Active Data Guard 许可。 有关详细信息，请参阅 Oracle 许可证详细信息。

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

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

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

使用 Golden Gate 进行灾难恢复

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

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

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

使用备份进行灾难恢复

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

  • 从数据库提取和移动数据的备份，以确保灾难恢复站点具有最新的数据。

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

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

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

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

重要

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

方法 2： 部署和维护生产环境的缩放版本。 具有一个版本，该版本可以正常用于小型工作负荷，并且可以在故障转移期间根据需要进行纵向扩展，以便用于生产负载。 此方法通常用于复杂部署，你不想冒险创建整个环境，或者想要快速故障转移以提供较低的 RTO。

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

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

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

使用远同步

远同步不会提高高可用性功能，但你可以使用它实现 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）系统上的工作负荷主要读取请求。 例如，90% 读取和 10% 写入操作或 95% 读取和 5% 写入操作在 OLTP 应用程序中很常见。 数据复制实质上复制在源数据库中写入请求的结果。 通过此设置，可以期望辅助数据库以 1/10（如果主数据库的容量为 90% 的读取率和 10% 的写入率）运行。

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

为服务保护和数据保护配置网络拓扑

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

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

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

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

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

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

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

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

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

针对各种故障类型的复原能力摘要

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

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

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

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

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

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

下一步

了解 Oracle 在企业规模方案中虚拟机登陆区域加速器安全性的设计注意事项。

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