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

SAP 迁移的业务连续性和灾难恢复

本文基于 BCDR 的 Azure 登陆区域设计区域中的注意事项和建议。 本文介绍支持 SAP 平台的登陆区域的唯一约束。 SAP 是一个任务关键型平台，因此还应将其他 任务关键型指南 纳入设计。

方案和范围

将原则合并到体系结构中，以解决本地业务连续性和灾难恢复（BCDR）方案。 这些原则也适用于 Azure。 但 Azure 可能比本地环境具有更多的硬件容量来补偿主机故障。 若要自动恢复甚至最大的 Azure 虚拟机（VM），可以将它们配置为在另一台服务器上重启。 将 Azure 部署设置为使用与本地部署相同的条件。 如果使用自动故障转移群集配置来部署本地系统或裸机硬件，请在 Azure 上以相同的方式部署它们。 运行组织最关键业务流程的 SAP 应用程序需要：

• 服务和业务流程可用性。

• 故障方案或灾难方案的恢复时间目标（RTO）。

• 故障方案的恢复点目标（RPO）。

• 运行和生命周期管理任务，以及在故障方案中运行的技术。 这些管理任务包括修补来宾操作系统和数据库管理系统、克隆和刷新 SAP 系统。

提示

提前确定 SAP 布局中每个原型的高可用性和灾难恢复（HADR）解决方案。 确保解决方案涵盖所有 SAP 组件。

尽早在 Azure 上配置 HADR 解决方案，至少在一个布局中，并使其保持活动状态。 然后，你的团队可以获得解决方案技术的经验，这可能与现有技术不同。 提前配置 HADR 以帮助开发和改进标准操作过程（SOP）。

计划在系统运行后立即为生产工作负荷提供完整的高可用性、灾难恢复和备份保护。

本文介绍适用于企业级 SAP 方案的 BCDR 的以下方面：

• Azure 区域中的高可用性

• 备份和还原注意事项

• 在跨区域和区域灾难恢复之间决定的条件

Azure 区域中的高可用性

对于 SAP 企业方案，以下部分提供了有关 Azure 区域中高可用性的设计注意事项和建议。

高可用性的设计注意事项

实现高可用性时，目标是为 SAP 软件的单一故障点提供可用性，例如：

• 数据库管理系统。

• 应用程序中的单一故障点，例如 SAP 高级业务应用程序编程（ABAP）、ABAP SAP Central Services （ASCS）和 SAP Central Services （SCS）。 高可用性示例包括 SAP NetWeaver 和 SAP S/4HANA 体系结构。

• 其他工具，如 SAP Web 调度程序。

对于其他方案，请勿将可用性限制为基础结构故障或软件故障。 将可用性应用于所有必要的生命周期管理任务。 例如，可以在 VM、数据库管理系统（DBMS）和 SAP 软件中修补 OS。 若要最大程度地减少在计划内停机和生命周期管理操作期间可能发生的中断，请使用有助于保护系统免受计划外服务中断的常见工具。

SAP 和 SAP 数据库支持自动故障转移群集。 在 Windows 中，Windows Server 2022 故障转移群集功能支持故障转移。 在 Linux 中，Linux Pacemaker 或 SIOS 保护套件和 Veritas InfoScale 等合作伙伴工具支持故障转移。 在 Azure 中，只能在自己的数据中心部署子集高可用性配置。

有关详细信息，请参阅 Azure VM 上的 SAP 工作负荷支持方案，以及 SAP HANA 大型实例支持的方案。

对于 DBMS 层，常见的体系结构模式是同时复制数据库，其存储堆栈不同于主 VM 和辅助 VM 使用的存储堆栈。 Azure 不支持主要 VM 和辅助 VM 共享 DBMS 数据的存储的体系结构。 Azure 也不支持事务日志或重做日志。 指导原则是使用两个独立的存储堆栈，即使它们基于网络文件系统（NFS）共享也是如此。 这些限制仅适用于 Azure 解决方案，而不是本地解决方案。

Azure 提供其他选项，因为它支持 NFS 和服务器消息块共享。 可以在 Windows 中将 Azure 共享磁盘 用于 ASCS 和 SCS 组件以及特定的高可用性方案。 为 SAP 应用程序层组件和 DBMS 层单独设置故障转移群集。 Azure 不支持将 SAP 应用程序层组件和 DBMS 层合并到一个故障转移群集的高可用性体系结构。

SAP 应用程序层组件和 DBMS 层的大多数故障转移群集都需要故障转移群集的虚拟 IP 地址。 常见的例外情况是，使用 Oracle Data Guard 时不需要虚拟 IP 地址。 Azure 负载均衡器应处理所有其他情况的虚拟 IP 地址。 可以对每个群集配置使用一个负载均衡器。 建议使用负载均衡器的标准版本。 有关详细信息，请参阅 SAP 高可用性方案中使用标准Azure 负载均衡器为 VM 建立公共终结点连接。

有关详细信息，请参阅 SAP NetWeaver 的高可用性体系结构和方案。

下表显示了各种高可用性部署选项的平台级服务级别协议（SLA）。 提供托管服务的合作伙伴还提供应用程序级 SLA。

层	高可用性方案	平台 SLA
1	Availability zone	99.99%
2	可用性集	99.95%
3	单个 VM （自我修复）	99.90%

Azure 可用性集与可用性区域

在部署高可用性基础结构之前，请根据所选区域确定是使用 Azure 可用性集还是可用性区域 进行部署。 使用可用性集部署的 VM 的主要区别包括：

• VM 不会分布在不同的可用性区域。

• 可以通过单个可用性集部署的 VM 类型受到限制，因为在集中部署的第一个 VM 定义主机。 例如，不能将 M 系列 VM 和 E 系列 VM 合并到一个可用性集中。

跨不同可用性区域部署高可用性体系结构时，可以为 VM 提供更高的 SLA。 有关详细信息，请参阅 Azure VM SLA。 根据 Azure 区域的不同，你可能会发现 VM 之间的网络流量存在不同的网络延迟情况。 有关详细信息，请参阅 使用 Azure 可用性区域的 SAP 工作负荷配置。

如果选择区域部署方法，请考虑所选 Azure 区域的跨区域延迟如何影响性能和体系结构设计选择。 考虑应用程序服务器与数据库之间的延迟，以及两个数据库节点之间的延迟。

如果对应用程序服务器层使用主动/被动区域部署，应用程序服务器必须连接到同一可用性区域中的数据库，请配置自动化并创建 SOP，以便在发生数据库故障转移时实现快速和自动化恢复。

如果在 SAP 解决方案中使用可用性区域，请在 SAP 布局中设计所有其他 Azure 服务和基础结构组件以实现区域冗余，以便实现真正的区域冗余。 要考虑的服务和组件示例包括 Azure ExpressRoute 网关、负载均衡器、Azure 文件存储、Azure NetApp 文档、反向代理、防火墙、防病毒服务和备份基础结构。

高可用性设计建议

• Azure 提供了多个选项来帮助满足应用程序的基础结构 SLA。 应为所有三个 SAP 组件选择相同的选项：中央服务、应用程序服务器和数据库。 有关 VM、可用性集和可用性区域的 SLA 的详细信息，请参阅用于联机服务的 SLA。

• 在可用性集中部署 VM 时，与容错域和更新域的对齐可防止 VM 位于同一主机硬件上，从而防止硬件故障。 通过可用性区域部署 VM 并使用不同的区域时，可以在不同的物理位置创建 VM。 此配置可针对影响整个区域的数据中心的电源、冷却或网络问题提供额外的保护。 但是，除非使用 邻近放置组，否则无法在 Azure 可用性区域中部署 Azure 可用性集。

  如果选择区域部署方法，SAP DBMS、中心服务和应用程序层在不同的可用性区域中运行。 但每个可用性区域很可能有多个应用程序服务器。 在此方案中，每个区域中的应用程序服务器不会自动受益于容错域和更新域。 可以使用可用性集来获取这些优势。 有关详细信息，请参阅 Azure 邻近放置组，了解 SAP 的最佳网络延迟。

• 创建可用性集时，请使用可用的容错域和更新域的最大数量。 例如，如果在一个可用性集中部署了两个以上的 VM，请使用容错域的最大数目（3 个）。 除了 Azure 计划内维护之外，还使用足够的更新域来限制潜在的物理硬件故障、网络中断或电源中断的影响。 容错域的默认数目为 2，以后无法联机更改。

• 在可用性集部署中，SAP 系统的每个组件都需要位于其自己的可用性集中。 SAP 中心服务、数据库和应用程序 VM 应位于其自己的可用性集中。

• 在可用性集部署中使用 Azure 邻近放置组时，请确保所有三个 SAP 组件（中央服务、应用程序服务器和数据库）都位于同一邻近放置组中。

• 如果使用邻近放置组，请对每个 SAP 系统标识（SID）使用一个。 组不跨可用性区域或 Azure 区域。

• 在可用性区域部署中使用 Azure 邻近放置组时，请确保两个 SAP 组件（中央服务和应用程序服务器）位于同一邻近放置组中。 两个区域中的数据库 VM 不再是邻近放置组的一部分。 每个区域的邻近放置组的范围是运行 SAP ASCS 和 SCS 实例的 VM 的部署。 此配置的优点是可以更灵活地调整 VM 的大小。 还可以在 DBMS 层或 SAP 系统的应用程序层中轻松切换到新的 VM 类型。

• Azure 不支持在单个 Linux Pacemaker 群集中合并 ASCS 和数据库高可用性。 将它们分成单独的群集。 可以将多达五 个中央服务群集 组合在一对 VM 中。

• 在 ASCS 和数据库群集前面使用标准负载均衡器。

• 在 Azure 高级 SSD 上运行所有生产系统，并使用 Azure NetApp 文档 或 Azure 超级磁盘存储。 至少请确保 OS 磁盘位于高级层上，以便提高性能并获得最佳 SLA。

• 在可用性集或可用性区域中的高可用性对中部署这两个 VM。 确保这些 VM 的大小相同，并且具有相同的存储配置。

• 使用本机数据库复制技术在高可用性对中同步数据库。

• 根据 OS，使用以下服务之一来运行 SAP 中心服务群集：

  • SUSE Linux Enterprise Server Pacemaker 群集支持 Azure 隔离代理和多达三个节点隔离设备。

  • Red Hat Enterprise Linux Pacemaker 群集支持 Azure 隔离代理，不支持节点隔离设备。

  • Windows 群集。

  • SAP 认证的非Microsoft群集软件。

• 按照中央服务和数据库群集文档中的建议设置群集超时参数。

SAP 工作负荷的存储

• 设计 SAP 工作负荷中的复原能力时，请选择正确的存储选项。 适用于 SAP 工作负荷的适当 Azure 存储设计可以最大程度地减少延迟并最大程度地提高吞吐量。 请考虑你的实现，以及以下指南如何帮助你为 Azure 上的 SAP 实现做出体系结构决策。 有关详细信息，请参阅 适用于 SAP 工作负荷的 Azure 存储类型。

• 应仅在 SAP 认证的存储类型上运行 Azure 上的 SAP HANA。 必须在某些磁盘配置上运行某些卷。 例如，配置可能启用写入加速器或使用高级 SSD 存储。 还需要确保在存储上运行的文件系统与计算机上运行的 DBMS 兼容。 有关详细信息，请参阅 SAP HANA 的存储配置。

• 除了附加到 VM 的 Azure 托管数据磁盘外，各种 Azure 本机共享存储解决方案还会在 Azure 上运行 SAP 应用程序。 高可用性配置可能有所不同，因为 Azure Site Recovery 不支持 Azure 上提供的某些存储服务。 对 SAP 工作负荷使用以下存储类型。

  存储类型	高可用性配置支持
  Azure 共享磁盘（本地冗余存储（LRS）或区域冗余存储（ZRS））	Windows Server 2022 故障转移群集。 有关配置详细信息，请参阅 使用 Windows Server 2022 故障转移群集设计 SAP 高可用性。
  Azure 文件存储上的 NFS （LRS 或 ZRS）	基于 Pacemaker 的 Linux 环境群集。 请务必检查 各种区域中 NFS 的可用性。
  Azure NetApp 文件上的 NFS	基于 Pacemaker 的 Linux 环境群集。 有关详细信息，请参阅 SAP VM Azure NetApp 文档。
  Azure 文件存储上的 SMB （LRS 或 ZRS）	Windows Server 2022 故障转移群集。 有关配置详细信息，请参阅使用 Azure 文件存储 SMB 安装高可用性 SAP NetWeaver。
  Azure NetApp 文件上的 SMB	Windows Server 2022 故障转移群集。 有关配置详细信息，请参阅 SAP NetWeaver 的高可用性，以及 SAP 应用程序的 Azure NetApp 文档 （SMB）。

• 可以使用传统的 NFS 群集（基于分布式复制块设备复制）、GlusterFS 或群集共享卷（存储空间直通作为替代的共享存储解决方案在 Azure 上运行 SAP 工作负荷），而不是 Azure 本机共享存储服务。 当 Azure 本机共享存储服务在目标 Azure 区域中不可用或不支持目标体系结构时，这些选择特别有用。 有关存储服务可用性的详细信息，请参阅 Azure 产品（按区域）。

• 有关可用于 Azure 上的 SAP 工作负荷的存储选项的信息，请参阅 存储建议和设置灾难恢复指南。

备份和还原

以下部分介绍 SAP 方案中备份和还原的设计注意事项和建议。

尽管备份和还原通常不被视为生产 SAP 工作负荷的足够高可用性解决方案，但该技术提供了其他优势。 使用 SAP 应用程序的大多数公司都需要遵循需要长期存储备份的合规性法规。 在其他方案中，还需要具有可从中还原的备份。 本指南假定你已建立备份和还原，并遵循 SAP 应用程序的最佳做法，这意味着你可以：

• 在任何时间点（满足 RTO 的时间范围内）为生产数据库执行时间点恢复。 时间点恢复通常提供保护，防止操作员错误，例如在 DBMS 层上或通过 SAP 删除数据。

• 维护存储以保留长期备份，以满足合规性法规。

• 使用数据库备份克隆 SAP 系统，并针对其他服务器或 VM 还原备份。

• 使用数据库备份中的生产数据库数据刷新非生产系统。

• 备份 SAP 应用程序服务器和 VM、磁盘或 VM 快照。

• 备份启用了复制的 SAP HANA 系统。

• 备份 SAP HANA 数据库实例快照。

如果备份和还原本地，则需要将这些功能引入 Azure 中的 SAP 系统。 如果你喜欢当前解决方案，请检查备份供应商是否支持 Azure 部署，或者它是否具有适用于 Azure 的软件即服务（SaaS）解决方案。

Azure 提供名为 Azure 备份 的备份 SaaS 服务，该服务拍摄 VM 快照并管理流式处理 SQL Server 和 SAP HANA 备份。 如果使用Azure NetApp 文档来存储 SAP HANA 数据库，则可以基于 HANA 一致的存储快照运行备份。

还可以使用Azure 备份备份启用了 SAP HANA 系统复制（HSR）的数据库。 Azure 备份在发生故障转移时自动管理备份，并且无需手动干预。 备份还提供：

• 无需修正完整备份的即时保护，因此可以将 HANA 实例或 HSR 设置节点作为单个 HSR 容器进行保护。

• 即时备份和即时还原的好处。

• 与适用于 SAP HANA 的 Backint 集成的基于 HANA 的基于快照的方法。 可以将备份用作整个 HANA 布局和任何数据库大小的单个产品。

有关详细信息，请参阅 启用了复制的 SAP HANA 数据库系统和 SAP HANA 实例快照备份。

备份和还原的设计建议

• 可以使用Azure 备份备份 SAP 应用程序服务器和中心服务 VM。

• 可以将 SAP HANA 备份用于最多 8 TB 的 HANA 部署。 有关详细信息，请参阅 Azure VM 上 SAP HANA 数据库的备份支持矩阵。

• 如果使用基础结构即服务备份解决方案，请调整备份基础结构的大小，以确保它可以同时备份所有生产大小的系统，或者在预期的时间段内备份所有生产大小的系统（如在实际方案中）。 将生产设置或类似的设置用于网络和安全性等区域。

• 测试备份和恢复时间，以验证它们是否满足 RTO 要求，以便在发生灾难后同时还原所有系统。

• 理想情况下，请避免将备份从 Azure 拉取到本地备份基础结构，尤其是对于大型数据库。 此方法可能会影响 ExpressRoute 线路使用的带宽量。

• 作为性能测试计划的一部分，负载测试备份和恢复工具。

灾难恢复

以下部分介绍 SAP 方案中灾难恢复的设计注意事项和建议。

灾难恢复的设计注意事项

Azure 区域映射包含 65 个以上的 Azure 区域，并非所有区域都运行相同的服务。 对于更大的 SAP 软件部署，尤其是那些使用 SAP HANA 的软件部署，请查找提供 Azure M 系列 VM 或 Mv2 系列 VM 的 Azure 区域。 Azure 存储还对不同的区域进行配对，将较小的存储类型子集复制到另一个区域。 有关详细信息，请参阅 Azure 配对区域概述。

对适用于 SAP 工作负荷的 Azure 区域进行配对的主要挑战如下：

• 区域对并不总是与 M 系列或 Mv2 系列 VM 服务一致。 部署 SAP 系统的许多组织不使用 Azure 配对区域。 而是根据所需 VM 类型的可用性选择区域。

• 可以在配对区域之间复制标准存储，但不能使用标准存储来存储数据库或虚拟硬盘。 只能在使用的配对区域之间复制备份。 对于所有其他数据，请使用 SQL Server Always On 或 SAP HANA 系统复制等本机 DBMS 功能运行复制。 对 SAP 应用程序层使用 Site Recovery、工具（如 rsync 或 robocopy）和其他非Microsoft软件的组合。

• 如果发生灾难，Azure 区域中的多个受影响的客户会故障转移到相应的配对灾难恢复区域。 这种情况会导致资源竞争，在灾难恢复区域中引发休眠 VM。 解决方法是在灾难恢复区域中运行非生产系统，并使用相同的资源托管生产系统的灾难恢复副本。 这种在灾难恢复区域中对 Azure 基础结构的双重用途使用有助于避免资源容量约束。

另一个重要考虑因素是确保灾区所需的操作容量。 如果发生灾难，可能需要以最小的 IT 容量和关键人力资源运行 SAP 应用程序，同时在主要区域中恢复正常运行时，才需要运行 SAP 应用程序。 此策略要求在灾难恢复区域中提供最少的 IT 基础结构。

定义 Azure 区域后，需要选择部署模式：

• 是否会将生产系统部署到主要区域？

• 是否会将非生产 SAP 系统部署到灾难恢复区域？

• 是否使用将所有 SAP 系统分组到主要区域的体系结构？ 此配置可确保灾难恢复区域仅用于灾难恢复。

大多数组织将这两个区域用于操作系统。 作为业务回归测试系统运行生产系统的完整副本的组织通常计划将 SAP 生产线的业务回归测试系统用作灾难恢复目标。

选择灾难恢复区域时，请务必与该区域建立 ExpressRoute 连接。 如果有多个 ExpressRoute 线路连接到 Azure，则至少其中一条线路必须连接到主要 Azure 区域。 其他人应连接到灾难恢复区域。 这种类型的体系结构将连接到不同地理或地缘政治区域中的 Azure 网络，如果灾难影响 Azure 区域之一，有助于保护连接。

某些组织使用高可用性和灾难恢复体系结构的组合，该体系结构将高可用性与同一 Azure 区域中的灾难恢复组合在一起。 但是，将高可用性与灾难恢复分组并不理想。 Azure 可用性区域 支持此体系结构。 一个 Azure 区域中的可用性区域之间的距离不如两个 Azure 区域之间的距离大，因此自然灾害可能会危及发生该区域的应用程序服务。 还需要考虑 SAP 应用程序服务器和数据库服务器之间的延迟。 根据 SAP 说明1100926，往返时间小于或等于 0.3 毫秒是一个很好的值，小于或等于 0.7 毫秒的时间是中等值。 因此，对于延迟较高的区域，需要执行操作过程，以确保 SAP 应用程序服务器和数据库服务器始终在同一区域中运行。 组织出于以下原因选择此体系结构：

• 符合性足以满足支持生产部署和灾难恢复目标之间的较小距离的配置。

• 数据主权是一个因素。

• 地缘政治因素涉及。

• 这是一种低成本选项，支持区域性故障，有时与备份传输到次要区域，用于影响大半径的自然灾害。

选择灾难恢复区域时需要考虑的另一个因素是用于故障转移到灾难恢复站点的 RPO 和 RTO。 生产区域与灾难恢复区域之间的距离越大，网络延迟就越高。 在 Azure 区域之间异步复制，但网络延迟可能会影响可复制的吞吐量和 RPO 目标。 若要最大程度地减少 RPO，可以使用组合的高可用性和灾难恢复体系结构。 但是，这种配置可能会给大规模自然灾害带来更高的风险。

灾难恢复设计建议

• 确保主虚拟网络的无类域间路由（CIDR）不会与灾难恢复站点虚拟网络的 CIDR 冲突或重叠。

• 设置从本地到主要和辅助 Azure 灾难恢复区域的 ExpressRoute 连接。

• 请考虑设置从本地到主要和辅助 Azure 灾难恢复区域的 VPN 连接。 使用此方法作为使用 ExpressRoute 的替代方法。

• 使用 Site Recovery 将应用程序服务器复制到灾难恢复站点。 Site Recovery 还可以帮助你将中央服务群集 VM 复制到灾难恢复站点。 调用灾难恢复时，需要在灾难恢复站点上重新配置 Linux Pacemaker 群集。 例如，可能需要替换虚拟 IP 地址或 SBD 或运行 corosync.conf。

• 跨区域复制证书、机密或密钥等密钥保管库内容，以便解密灾难恢复区域中的数据。

• 使用Azure NetApp 文档中的跨区域复制在主要区域和灾难恢复区域之间同步文件卷。

• 使用本机数据库复制（而不是 Site Recovery）将数据同步到灾难恢复站点。

• 将主要虚拟网络和灾难恢复虚拟网络对等互连。 例如，对于 HANA 系统复制，需要将 SAP HANA DB 虚拟网络对等互连到灾难恢复站点的 SAP HANA DB 虚拟网络。

• 如果对 SAP 部署使用Azure NetApp 文档存储，则至少在高级层（两个区域）中创建两个Azure NetApp 文档帐户。

• 考虑根据系统的业务重要性和基于应用程序性能的邻近依赖关系对系统进行分组。 为了最大程度地减少区域中断的业务影响，请将每个组部署到配对区域构造中的单独区域。 例如，为了最大程度地减少区域中断的影响，可以部署两个关键 ERP 中央组件系统，这些系统为英国南部和英国西部的两个不同的业务部门提供服务。

下一步

Azure 中 SAP 的部署选项