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

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

本文基于 BCDR 的 Azure 登陆区域设计区域中定义的注意事项和建议。 按照指导，本文提供了有关 Azure 基础结构虚拟机上 Oracle 工作负荷部署的业务连续性和灾难恢复（BCDR）选项的设计注意事项和最佳做法。

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

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

Azure 上的 Oracle 工作负载主要使用 Data Guard（作为 企业版 功能）的 Oracle 数据库的内置副本 (replica)技术来满足高可用性和灾难恢复需求。 Data Guard 提供三种保护模式：最大性能、最大可用性和最大保护。 保护模式的选择取决于体系结构设计和特定的 RPO 和 RTO 要求。

Azure 虚拟机登陆区域加速器上的 Oracle 工作负荷的高可用性

运行 Oracle 工作负荷的 Azure 虚拟机实例受益于可用性集体系结构。 高可用性配置提供准实时数据副本 (replica)具有潜在快速故障转移功能，但不为 Azure 数据中心级别或区域级别故障提供保护。

选择正确的高可用性选项

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

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

最大可用性模式下的 Data Guard 为正常操作提供零数据丢失承诺（RPO=0）的最高可用性。 对于在可用性集中创建的两台 Oracle 数据库服务器的高度可用配置，Azure 为服务可用性提供 99.95% SLA。

有关 Azure 上的 Data Guard 的分步配置，请参阅 在 Azure Linux 虚拟机 上实现 Oracle Data Guard。

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

如果始终需要数据库的事务一致性副本，则可以考虑在最大保护模式下使用 Data Guard。 但是，当备用数据库不可用时，最大保护模式不允许事务继续。 因此，尽管使用可用性集，但使用最大保护模式时，SLA 将减少到 99.9%x99.9%=99.8%。 此配置更用于确保数据副本的一致性，而不是提高可用性。

此体系结构的其他属性与最大可用性模式相同（即 RPO=0、RTO<=2 分钟）。

高可用性的特殊使用注意事项

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

将可用性区域与可用性集用于高可用性

Azure 可用性区域是同一 Azure 区域中的 Azure 数据中心，保证 <有 2 毫秒往返延迟。 尽管通常用于灾难恢复目的，但可以将其用于高可用性，而不是可用性集。 但是，必须确保解决方案可以使用所用可用性区域之间提供的延迟和吞吐量运行。

使用可用性区域比可用性集的优点之一是 SLA 将从 99.95% 增加到 99.99%。

共享存储聚类分析以实现高可用性

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

注意： PCS 群集不是 Oracle 认证的解决方案。 确定高可用性体系结构时，请考虑这一点。

使用邻近放置组

请考虑使用 邻近放置组 来确保同一可用性集中的数据库服务器与数据库服务器与应用程序服务器之间的最小延迟，以最大程度地降低网络延迟。

Azure 工作负载上的 Oracle 灾难恢复

灾难恢复体系结构提供针对影响 Azure 数据中心或区域的故障的复原能力，或者阻碍整个区域的应用程序功能。 在任何情况下，你都希望将整个工作负荷移动到另一个数据中心或区域。

如前所述，灾难恢复体系结构应基于 RTO 和 RPO 指示的解决方案要求。 由于灾难恢复体系结构是为异常故障情况构建的，因此故障转移过程是手动的，而不是高可用性设计。 通常，你应对 RTO 和 RPO 有更宽松的要求，这可以实现更具成本效益的设计。

本文档重点介绍主服务器和辅助服务器都在 Azure 上的场景。 还可以在 Azure 上创建主服务器和辅助服务器，以实现灾难恢复。 在 Azure 环境中 Oracle 数据库 12c 数据库的灾难恢复中详细了解此方案。

选择正确的灾难恢复选项

使用以下流程图确定 Oracle 数据库的最佳灾难恢复选项。

使用 Data Guard 进行灾难恢复

Data Guard 可用于将数据副本 (replica)到灾难恢复站点。 该站点可以是同一区域中的另一个可用性区域，也可以是不同的区域，具体取决于数据保护的要求。 它还依赖于生产站点上提供的可用性区域结构。 在灾难恢复方案中使用 Oracle Data Guard 与前面讨论的高可用性方案类似，但存在一些重要差异。

• 在高可用性方案中故障转移到辅助副本 (replica)时，会发送Azure 负载均衡器以将请求重定向到新的主数据库。
• 故障转移到灾难恢复站点时，可将整个解决方案故障转移到新站点。

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

Azure 数据中心之间的延迟彼此分离，区域或数据中心之间的延迟高于同一数据中心内的延迟。 因此，最复杂且成本最低的建议是出于灾难恢复目的，在最高性能模式下使用 Data Guard。 如果最大性能模式太有风险，则可以将最大可用性模式与 FarSync 机制一起使用。 但是，使用 FarSync 实例可在主环境和备用环境中触发 Active Data Guard 许可。 有关更多详细信息，请查看 许可证详细信息。

此外，在跨 Azure 区域或数据中心发送数据时，将面临发送到灾难恢复站点的数据（例如重做日志）的出口成本。 如果不需要副本 (replica)数据库中所有数据，则可以使用基于 Golden Gate 的副本 (replica)副本 (replica)仅根据需要对部分数据进行副本 (replica)，并节省出口成本。

有关 Azure 上的 Data Guard 的分步配置，请参阅 在 Azure Linux 虚拟机 上实现 Oracle Data Guard。

使用 Golden Gate 的灾难恢复

Golden Gate 是一种逻辑副本 (replica)软件，它支持将数据从源数据库实时副本 (replica)、筛选和转换到目标数据库，或在多个主数据库之间转换数据。 此功能可确保源数据库中的更改几乎实时副本 (replica)，使目标数据库能够与最新数据保持最新。

Golden Gate 可用于在灾难恢复配置中副本 (replica)将数据从主数据库副本 (replica)辅助数据库。 例如，如果数据需要保护，则 Golden Gate 可能更实用。 Golden Gate 允许选择性地副本 (replica)表，甚至可以在副本 (replica)期间筛选出表行，以避免副本 (replica)不必要的数据。

有关如何在 Azure 上实现 Golden Gate 的分步指南，请参阅 在 Azure Linux 虚拟机上实现 Oracle Golden Gate。

使用备份进行灾难恢复

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

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

• 确保在灾难恢复站点上部署最新。 通过将所有网络组件、应用程序服务器和配置的相同部署副本 (replica)到灾难恢复站点来更新站点。

在使用备份副本 (replica)数据时，可以使用多种不同的选项进行浏览，如 Azure 上的 Oracle 数据库的备份策略中所述。

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

• 一种方法是在灾难恢复站点上不维护任何物理部署，从而避免其维护工作和成本。 可以使用基础结构即代码（IaC）和站点可靠性工程做法来开发和维护存储库，该存储库可以在故障转移到灾难恢复站点时单击一键副本 (replica)部署作为配置。 此方法优化成本，因为它在故障转移前不使用任何物理资源。

重要

如果在故障转移期间从头开始创建整个部署，则必须确保满足解决方案的 RTO 要求。 需要对灾难恢复方案进行例行模拟和测试，以确保部署代码不会中断。

• 第二种方法是部署和维护生产环境的缩放版本。 一个版本，可为小型工作负荷准确运行，并且可以根据需要在故障转移期间进行纵向扩展，以便用于生产负载。 此选项是最常用的方法，尤其是对于不想冒险创建整个环境或想要快速故障转移以便提供较低 RTO 的复杂部署。

第三种方法是将整个解决方案部署到灾难恢复站点，以节省成本，从而缩短 RTO 和故障转移时间。

灾难恢复的特殊注意事项

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

使用 FarSync

Oracle Data Guard Far Sync 对高可用性功能无助于实现零数据丢失保护功能，副本 (replica) Oracle 数据库。 如果主要工作负荷失败时需要零数据丢失，请参阅 Azure 上的 Oracle 参考体系结构，详细了解如何在 Azure 上使用 Far Sync。

选择正确的数据副本 (replica)技术

除了本文档中所述的本机技术外，还可以使用任何技术来促进跨两个 Oracle 数据库的数据副本 (replica)，以保持高可用性副本 (replica)和 Azure 上的 Oracle 数据库的灾难恢复副本 (replica)。 你选择的技术必须满足这些支柱的解决方案要求。

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

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

影响：副本 (replica)对主数据库的事务施加的影响量应符合解决方案要求。

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

总拥有成本：购置成本（第三方副本 (replica)解决方案）以及配置和维护副本 (replica)解决方案所需的工作量，还应考虑并验证解决方案要求。

优化故障转移实例

在高可用性或高保护模式下使用数据防护时，还可以配置自动故障转移，以便在主服务器发生故障时自动启动辅助服务器。 通过相应地配置应用程序服务器，可以确保故障转移期间应用程序停机时间接近零。

在此实现中，由于数据库应在故障转移后以相同的方式提供服务，因此需要为辅助服务器配置与主服务器相同的 CPU、内存和 I/O 容量。 在这种情况下，需要使用辅助服务器保持较高的容量，以增加 Azure 成本和 Oracle 数据库许可证成本。 辅助服务器在大多数情况下不会处理用户请求。

Azure 已为可用性区域中的虚拟机提供 99.9% 的可用性，如虚拟机运行时间服务级别协议（SLA）中所述。 在同一可用性区域中维护数据库的辅助副本 (replica)、使用任何数据副本 (replica)技术的另一个可用性区域或其他区域时，可以优化辅助容量。

使用此方法时，辅助数据库（s）配置了它们需要保持最新状态的容量。 发生故障时，将调整辅助数据库的大小，使其达到与原始主数据库相同的容量。 此操作仅在失败时完成，因此在正常操作期间，只需支付原始服务器成本的一小部分。 由于主数据库目前无法运行，因此不需要其他 Oracle 数据库许可证。

作为副本 (replica)目标运行辅助数据库所需的容量取决于所使用的副本 (replica)技术。 实质上，事务 OLTP 系统上的工作负荷主要由读取请求组成。 例如，90%-10% 或 95%-5% 的读写配给在 OLTP 应用程序中很常见。 数据副本 (replica)实质上副本 (replica)在源数据库中写入请求的结果。 通过此设置，可以合理地让辅助数据库以 1/10（如果 90%-10% 的读写比率）运行，甚至主数据库的容量为 1/10。

建议在故障转移过程中自动执行故障转移过程，以确保企业标准。 可以开发相同的过程来包括服务器大小调整操作，从而简化端到端过程。

用于服务保护和数据保护的网络拓扑

实现高可用性和灾难恢复需要财务和业务决策，将恢复时间（RTO）和潜在的数据丢失（RPO）与其他 Oracle 许可、虚拟机服务和数据传输成本相平衡来实现。 在单个 Azure 虚拟机上托管工作负荷可为常见硬件故障提供基本保护，并提供成本最低的解决方案。 但是，由于单个虚拟机上的故障可能会导致停机和数据丢失，生产环境应包括使用 Oracle Data Guard 在单独的虚拟机上托管的辅助 Oracle 数据库。 根据要求，使用以下一个或多个体系结构正确配置数据副本 (replica)保护数据。

• 最佳 RTO 和 RPO。 为了最大程度地减少延迟，请将辅助 Oracle 数据库合并到位于同一可用性区域和邻近放置组中的单独虚拟机上，作为主数据库。
• 数据中心故障的数据保护。 如果整个数据中心发生故障，将辅助虚拟机置于第二个数据库中会增加数据保护。 主数据库和辅助数据库之间的延迟可能高达 2 毫秒，这可能会影响性能、RTO 和 RPO。
• 发生区域性故障时的数据保护。 若要扩展保护以防止 Azure 区域故障数据丢失，可将辅助数据库置于另一个区域中。 由于区域之间的延迟可能介于 30 毫秒到 300 毫秒之间，因此对生产工作负荷和 RTO 和 RPO 的影响可能会增加。 提前估计此延迟。

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

• Oracle Data Guard 提供高可用性，（在大多数情况下）为常见故障提供足够的支持。 当虚拟机放置在可用性集中时，单个解决方案中的所有虚拟机和服务都应驻留在同一可用性区域中，以减少网络延迟。 此外，出于同样的原因，服务应共享相同的虚拟网络。
• 对于其他保护，虚拟机可以战略性地放置在单独的可用性区域中，而不是单个可用性区域。 此方法可以防止数据中心故障期间的停机。
• 为了获得极端保护，辅助数据库可以放置在另一个 Azure 区域中，并使用全局虚拟网络对等互连通过 Oracle Data Guard 应用持续更新。 通过此保护，数据更新可以通过 Microsoft 主干私下应用于次要区域。 资源直接通信，无需网关、额外跃点或通过公共 Internet 传输。 此网络选项允许跨不同区域中的对等互连虚拟网络建立高带宽、低延迟的连接。 可以使用全局虚拟网络对等互连通过高速网络将主站点连接到另一区域中的灾难恢复站点。

针对不同故障类型的复原能力摘要

失败方案	Azure HA/DR 上的 Oracle 方案	RPO/RTO
单组件故障（主机、机架、冷却、网络、电源）	在同一数据中心的同一可用性集中有两个节点的 Data Guard。 - 防止单个实例故障。 - 如果整个数据中心关闭，将导致停机。	RPO=0 RTO<=2 分钟 - 使用观察程序进行快速故障转移 - 使用 Data Guard 的MAX_AVAILABILITY或MAX_PROTECTION模式。
数据中心故障	数据防护在单独的可用性区域中有两个节点。 - 防止数据中心故障。 - 如果整个区域关闭，将导致停机。 - 需要应用服务器更多的故障转移配置来管理网络延迟。	RPO<=5 分钟 RTO<=5 分钟 - 使用 Data Guard MAX_PERFORMANCE 模式 RPO=0 RTO<=5 分钟 - 对 Data Guard 使用MAX_AVAILABILITY模式
区域故障	Data Guard 在单独的 Azure 区域中有两个节点： - 防范区域故障 - 需要应用服务器更多的故障转移配置来管理网络延迟。	RPO>=10 分钟 RTO>=15 分钟 - 对 Data Guard 使用 MAX_PERFORMANCE 模式。
	备份寄送到其他 Azure 区域： - 防范区域故障。 - 需要在故障转移期间在目标区域中设置整个 Azure 环境。	RPO>=24 小时 RTO>=4 小时

后续步骤

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

请参阅 Azure 上的 Oracle 虚拟机登陆区域加速器的安全指南。