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

Azure 虚拟机支持的方案中的 SAP 工作负载

  • 项目

在 Azure 中设计 SAP NetWeaver、Business One、Hybris 或 S/4HANA 系统体系结构为使用各种体系结构和工具实现可缩放、高效且高度可用的部署创造了各种不同的机会。 不过，这存在一些限制，具体取决于所用的操作系统或 DBMS。 此外，在本地受支持的方案不一定在 Azure 中受到同等的支持。 本文档介绍受支持的非高可用性和高可用性配置，以及仅使用 Azure VM 的体系结构。

注意

HANA 大型实例服务处于日落模式，不再接受新客户。 仍然可以为现有的 HANA 大型实例客户提供单元。 有关替代方案，请查看 HANA 硬件目录中介绍的 HANA 认证 Azure VM 产品/服务。 对于拥有 HANA 大型实例的现有 HANA 大型实例客户过去和现在都支持的方案，请查看支持的 HANA 大型实例方案一文。

一般平台限制

除了作为第一方服务提供的所谓本机 Azure VM 之外，Azure 还具有各种平台。 其中一个平台是处于日落模式的 HANA 大型实例。 再如，其中的另一个第一方服务是Azure VMware 服务。 SAP 通常不支持将 Azure VMware 服务用于托管 SAP 工作负载。 有关不同平台上 VMware 支持情况的更多详细信息，请参阅 SAP 支持说明 #2138865 - VMware Cloud 上的 SAP 应用程序：支持的产品和 VM 配置。

除了本地 Active Directory，Azure 还提供 Microsoft Entra 域服务（由 Microsoft 管理的传统 AD）和 Microsoft Entra ID 的托管 Active Directory SaaS 服务。 托管在 Windows OS 上的 SAP 组件通常依赖于 Windows Active Directory 的使用。 在这种情况下，传统 Active Directory 由你或 Microsoft Entra 域服务（仍在测试中）托管在本地。 但这些 SAP 组件不能使用本机 Microsoft Entra ID 运行。 原因是，Active Directory 在本地窗体或其 SaaS 窗体（Microsoft Entra 域服务）和本机 Microsoft Entra ID 之间的功能差距仍然较大。 此依赖项是基于 Windows OS 上的 SAP NetWeaver 和 S/4 HANA 的应用程序不支持 Microsoft Entra 帐户的原因。 在这种情况下需要使用传统的 Active Directory 帐户。

AD 服务 Windows OS 上基于 SAP NetWeaver 和 S/4 HANA 的受支持应用程序
本地 Windows Active Directory 支持
Microsoft Entra 域服务 支持
Microsoft Entra ID 不支持

上述不会影响使用 SAP 应用程序的单一登录（SSO）方案的 Microsoft Entra 帐户。

2 层配置

SAP 2 层配置被认为建立在由同一服务器或 VM 单元上运行的 SAP DBMS 和应用程序层组合而成的层的基础之上。 第二层被视为用户界面层。 对于 2 层配置，DBMS 和 SAP 应用程序层共享 Azure VM 的资源。 因此，需要以一种避免让不同的组件争用资源的方式来配置这些组件。 此外，还需要小心不要过度订阅 VM 的资源。 此类配置不提供比各种相关 Azure 组件的 Azure 服务级别协议更高的高可用性。

此类配置的图形表示形式如下所示：

Simple 2-Tier configuration

用于生产和非生产案例的 Windows、Red Hat、SUSE、适用于 SQL Server DBMS 系统的 Oracle Linux、Oracle、DB2、maxDB 和 SAP ASE 支持此类配置。 对于用作 DBMS 的 SAP HANA，SAP 支持 SAP 说明 #1953429 中所述的场景。 目前，没有任何 Linux 发行版提供足够的 HA 文档以在此类配置中设置和操作 Pacemaker 群集。 因此，只有在不需要高可用性故障转移群集的非生产情况下，Azure 才支持此类配置。

对于 Azure 上支持的所有 OS/DBMS 组合，支持此类配置。 但是，必须以一种可避免 DBMS 和 SAP 组件争用内存和 CPU 资源，从而避免超出可用物理资源的方式，来设置 DBMS 和 SAP 组件的配置。 需要通过限制允许 DBMS 分配的内存来实现此目的。 还需要限制应用程序实例上的 SAP 扩展内存。 此外，还需要监视 VM 的总体 CPU 消耗量，确保组件不会尽其最大限度消耗 CPU 资源。

注意

对于生产 SAP 系统，我们建议根据本文档稍后所述，采用额外的高可用性和最终灾难恢复配置

3 层配置

在此类配置中，需要将 SAP 应用程序层和 DBMS 层隔离到不同的 VM 中。 通常，对于较大的系统，以及出于更灵活地分配 SAP 应用程序层的资源的原因，你会采取这种做法。 在最简单的设置中，不会提供比各种相关 Azure 组件的 Azure 服务级别协议更高的高可用性。

图形表示形式如下所示：

Diagram that shows a simple 3-Tier configuration.

用于生产和非生产案例的 Windows、Red Hat、SUSE、适用于 SQL Server DBMS 系统的 Oracle Linux、Oracle、DB2、SAP HANA、maxDB 和 SAP ASE 支持此类配置。 为方便起见，我们未区分 SAP 应用程序层中的 SAP Central Services 和 SAP 对话实例。 在此简单的 3 层配置中，不为 SAP Central Services 提供高可用性保护。

注意

对于生产 SAP 系统，我们建议根据本文档稍后所述，采用额外的高可用性和最终灾难恢复配置

每个 VM 多个 DBMS 实例

在此配置类型中，将为每个 Azure VM 托管多个 DBMS 实例。 这种方案的动机可能是减少要维护的操作系统，并凭此降低成本。 其他动机是通过在多个 DBMS 实例之间共享较大 VM 或 HANA 大型实例单元的资源，来提高灵活性和效率。 到目前为止，主要是非生产系统采用这些配置。

此类配置如下所示：

Multiple DBMS instances in one unit

以下系统支持此类 DBMS 部署：

在一台主机上运行多个数据库实例时，需要确保不同的实例不会争用资源，从而导致超出 VM 的物理资源限制。 需要限制任一共享 VM 的实例可分配的内存时，尤其需要在内存方面做到这一点。 对于不同数据库实例可以使用的 CPU 资源，可能也是如此。 提到的所有数据库系统均采用允许在实例级别限制内存分配和 CPU 资源的配置。 若要使 Azure VM 支持此类配置，不同实例管理的数据库的数据文件和日志/重做日志文件所用的磁盘或卷应该是独立的。 换言之，不同 DBMS 实例管理的数据库的数据文件或日志/重做日志文件不应共享相同的磁盘或卷。

注意

对于生产 SAP 系统，我们建议根据本文档稍后所述，采用额外的高可用性和最终灾难恢复配置。 此文档稍后将介绍不支持高可用性配置的包含多个 DBMS 实例的 VM。

一个 VM 中的多个 SAP 对话实例

在许多情况下，会在裸机服务器甚至是私有云中运行的 VM 上部署多个对话实例。 采用此类配置的原因是，根据特定的工作负载、业务功能或工作负载类型定制特定的 SAP 对话实例。 不将这些实例隔离到不同 VM 的原因是避免增加操作系统维护和操作的工作量。 或者，在很多情况下，VM 的托管商或运营商要求按照操作和管理的每个 VM 支付每月费用。 在 Azure 中，在单个 VM 上托管多个 SAP 对话实例的方案支持用于 Windows、Red Hat、SUSE 和 Oracle Linux 操作系统上的生产和非生产目的。 如果多个 SAP Application Server 实例在单个 VM 上运行，则应设置在 Windows 和现代 Linux 内核上可用的 SAP 内核参数 PHYS_MEMSIZE。还建议在操作系统上限制 SAP 扩展内存的扩展，例如实现 SAP 扩展内存自动增长的 Windows。 可以使用 SAP 配置文件参数 em/max_size_MB 中做出这种限制。

在 Azure VM 中运行多个 SAP 对话实例的 3 层配置如下所示：

Diagram that shows a 3-Tier configuration where multiple SAP dialog instances are run within Azure VMs.

为方便起见，我们未区分 SAP 应用程序层中的 SAP Central Services 和 SAP 对话实例。 在此简单的 3 层配置中，不为 SAP Central Services 提供高可用性保护。 对于生产系统，不建议使 SAP Central Services 保持不受保护状态。 有关适用于 SAP 中心实例的所谓多 SID 配置以及此类多 SID 配置的高可用性的具体信息，请参阅本文档稍后的部分。

SAP DBMS 层的高可用性保护

想要部署 SAP 生产系统时，需要考虑热备用类型的高可用性配置。 尤其是对于需要先将数据载入内存才能全面恢复性能和可伸缩性的 SAP HANA，Azure 服务修复并非理想的高可用性措施。

通常，Microsoft 仅支持 SAP 工作负载方案中所述的高可用性配置和软件包。 可以在 SAP 说明 #1928533 中阅读相同的陈述。 对于与 SAP 工作负载结合使用的、未在 Microsoft 文档中阐述的其他高可用性第三方软件框架，Microsoft 不会提供支持。 在这种情况下，高可用性框架的第三方供应商即是高可用性配置的支持方，而作为客户，你需要在支持过程中与该供应商接洽。 本文稍后会提到例外情况。

一般而言，Microsoft 支持 Azure VM 或 HANA 大型实例单元上有限的一组高可用性配置。

对于 Azure VM，在 DBMS 级别支持以下高可用性配置：

重要

对于上述任何方案，我们都不支持在一个 VM 中配置多个 DBMS 实例。 也就是说，对于每个案例，在每个 VM 上只能部署一个数据库实例，并使用所述的高可用性方法对其进行保护。 目前不支持在同一 Windows 或 Pacemaker 故障转移群集下保护多个 DBMS 实例。 此外，只有每个 VM 部署包含单个实例的案例才支持 Oracle Data Guard。

有多种数据库系统允许在一个 DBMS 实例下托管多个数据库。 与使用 SAP HANA 时一样，可以在多个数据库容器 (MDC) 中托管多个数据库。 如果这些多数据库配置在一个故障转移群集资源中运行，则支持这些配置。 不支持的配置是需要多个群集资源的配置。 例如，要在一个 SQL Server 实例下定义多个 SQL Server 可用性组的配置。

DBMS HA configuration

根据所用的 DBMS 和/或操作系统，不一定需要将 Azure 负载均衡器等组件配置为解决方案体系结构的一部分。

具体而言，对于 maxDB，存储配置需是不同的。 使用 maxDB，数据文件和日志文件需要位于用于高可用性配置的共享存储中。 仅对于 maxDB 而言，支持共享存储以实现高可用性。 对于所有其他 DBMS，在每个节点上使用单独的存储堆栈是唯一支持的磁盘配置。

已知存在并且也可以在 Microsoft Azure 上运行的其他高可用性框架。 但是，Microsoft 未测试这些框架。 如果你要使用这些框架构建高可用性配置，需要与该软件的提供商协作来处理以下事宜：

  • 开发部署体系结构
  • 部署体系结构
  • 为体系结构提供支持

重要

Microsoft Azure 市场提供各种软设备，它们在 Azure 原生存储的顶层提供存储解决方案。 这些软设备还可用于创建 NFS 共享，从理论上讲，在需要备用节点的 SAP HANA 扩展部署中可以使用这些共享。 出于各种原因，Microsoft 以及 Azure 上的 SAP 提供的任何 DBMS 部署都不支持这些存储软设备。 目前完全不支持 SMB 共享上的 DBMS 部署。 NFS 共享上的 DBMS 部署仅限于 Azure NetApp 文件中的 NFS 4.1 共享。

SAP Central Services 的高可用性

SAP Central Services 是 SAP 配置的另一个单一故障点。 因此，也需要保护这些 Central Services 进程。 SAP 工作负载支持的并在文档中阐述的产品/服务如下所述：

对于列出的解决方案，你需要与 SIOS 建立支持关系，以便为 Datakeeper 产品提供支持，并在遇到问题时直接与 SIOS 接洽。 根据 Windows、Red Hat 和/或 SUSE 操作系统的授权方式，还可能需要与 OS 提供商签订支持合同，以获得所列高可用性配置的全面支持。

配置还可能如下所示：

DBMS and ASCS HA configuration

图的右侧显示了高可用性 SAP Central Services。 除了使用故障转移群集框架（在出现故障的情况下可实现故障转移）保护 SAP Central Services 以外， 还有必要部署高可用性 NFS 或 SMB 共享或者 Windows 共享磁盘，以确保不管是否存在单个 VM，sapmnt 和全局传输目录都可供使用。 其他一些解决方案（例如 Windows 故障转移群集服务器和 Pacemaker）今后会要求 Azure 负载均衡器将流量定向或重定向到正常的节点。

在显示的列表中未提到 Oracle Linux 操作系统。 Oracle Linux 不支持将 Pacemaker 用作群集框架。 如果你想要在 Oracle Linux 上部署 SAP 系统并需要为 Oracle Linux 使用高可用性框架，则需要与第三方供应商协作。 其中一家供应商是 SIOS，他们的 Protection Suite for Linux 受 Azure 上的 SAP 支持。 有关详细信息，请参阅 SAP 说明 #1662610 - SIOS Protection Suite for Linux 的支持详细信息。

上面列出的 SAP Central Services 方案支持的存储

由于只有一部分 Azure 存储类型提供质量符合要求的、适合在 SAP Central Services 群集方案中使用的高可用性 NFS 或 SMB 共享，因此下面列出了支持的存储类型

  • 可以在除 Azure NetApp 文件以外的所有原生 Azure 存储类型上部署 Windows 故障转移群集服务器和 Windows 横向扩展文件服务器。 但是，我们建议使用高级存储，因为它在吞吐量和 IOPS 方面提供优越的服务级别协议。
  • 支持在 Azure NetApp 文件上部署 Windows 故障转移群集服务器和 Azure NetApp 文件上的 SMB。 此方案也支持托管在 Azure 高级文件服务上的 SMB 共享。 不支持 Azure 标准文件
  • 可以在除 Azure NetApp 文件以外的所有原生 Azure 存储类型上部署 Windows 故障转移群集服务器和基于 SIOS Datakeeper 的 Windows 共享磁盘。 但是，我们建议使用高级存储，因为它在吞吐量和 IOPS 方面提供优越的服务级别协议。
  • 在 Azure NetApp 文件上，支持使用 NFS 共享的 SUSE 或 Red Hat Pacemaker。
  • 在使用 LRS 或 ZRS 的 Azure NetApp 文件上，支持使用 NFS 共享的 SUSE 或 Red Hat Pacemaker。 不支持 Azure 标准文件
  • 支持使用原生 Azure 存储类型（Azure NetApp 文件除外）在两个 VM 之间部署使用 drdb 配置的 SUSE Pacemaker。 但是，我们建议将第一方服务之一与 Azure 高级文件或 Azure NetApp 文件一起使用。
  • 支持使用原生 Azure 存储类型（Azure NetApp 文件除外）部署使用 glusterfs 提供 NFS 共享的 Red Hat Pacemaker。 但是，我们建议将第一方服务之一与 Azure 高级文件或 Azure NetApp 文件一起使用。

重要

Microsoft Azure 市场提供各种软设备，它们在 Azure 原生存储的顶层提供存储解决方案。 这些存储软设备也可用于创建 NFS 或 SMB 共享，从理论上讲，还可以在已组建故障转移群集的 SAP Central Services 中使用这些共享。 Microsoft 不直接支持对 SAP 工作负载使用这些解决方案。 如果你决定使用此类解决方案创建 NFS 或 SMB 共享，则对 SAP Central Services 配置的支持需要由拥有存储软设备中的软件的第三方来提供。

多 SID SAP Central Services 故障转移群集

为了减少大型 SAP 环境中所需的 VM 数量，SAP 允许在故障转移群集配置中运行多个不同 SAP 系统的 SAP Central Services 实例。 假设你有 30 个或者更多个 NetWeaver 或 S/4HANA 生产系统。 在未组建多 SID 群集的情况下，这些配置需要 30 个或者更多个 Windows 或 Pacemaker 故障转移群集配置中，提供 60 个或者更多个 VM。 跨故障转移群集配置中的两个节点部署多个 SAP Central Services 实例可以显著减少 VM 数量。 但是，在单个双节点群集配置中部署多个 SAP Central Services 实例也会带来一些劣势。 群集配置中单个 VM 相关的问题同样适用于多个 SAP 系统。 对群集配置中运行的来宾 OS 的维护需要经过更多的协调，因为多个生产 SAP 系统会受到影响。 诸如 SAP LaMa 的工具不支持在其系统克隆过程中组建多 SID 群集。

在 Azure 上，使用 ENSA1 和 ENSA2 的 Windows 操作系统支持多 SID 群集配置。 建议不要在一个多 SID 群集上结合使用旧式排队复制服务体系结构 (ENSA1) 与新式体系结构 (ENSA2)。 以下文章中提供了有关此类体系结构的详细信息

对于 SUSE，还支持基于 Pacemaker 的多 SID 群集。 到目前为止，该配置受以下方案的支持：

  • 最多五个 SAP ASCS/SCS 实例
  • 旧式排队复制服务体系结构 (ENSA1)
  • 双节点 Pacemaker 群集配置

适用于 SAP 应用程序的 SUSE Linux Enterprise Server 上 Azure VM 中的 SAP NetWeaver 的多 SID 高可用性指南中阐述了此配置

包含排队复制服务器的多 SID 群集示意图如下所示

Diagram that shows a multi-SID cluster with Enqueue Replication server.

SAP HANA 横向扩展方案

SAP HANA 硬件目录中列出的一部分已通过 HANA 认证的 Azure VM 支持 SAP HANA 横向扩展方案。 在“群集”列中标有“是”的所有 VM 均可用于 OLAP 或 S/4HANA 横向扩展。以下 Azure 存储类型支持无备用节点的配置：

适用于 OLAP 或 S/4HANA 的具有备用节点的 SAP HANA 横向扩展配置仅支持 Azure NetApp 文件上托管的 NFS 共享。

有关具有或没有备用节点的具体存储配置的更多信息，请查看以下文章：

灾难恢复方案

支持多种灾难恢复方案。 我们将灾难体系结构定义为应该为整个断网的 Azure 区域提供补偿的体系结构。 这意味着，我们需要将灾难恢复目标确定为另一个 Azure 区域，而不是运行 SAP 环境的目标。 我们在 DBMS 层和非 DBMS 层中区分方法和配置。

DBMS 层

对于 DBMS 层，支持使用 DBMS 本机复制机制（例如 Always On、Oracle Data Guard、Db2 HADR、SAP ASE Always-On 或 HANA 系统复制）的配置。 在这种情况下，复制流必须是异步的，而不像在单个 Azure 区域内部署的典型高可用性方案中那样是同步的。 跨 Azure 区域的 SAP HANA 可用性一文中介绍了此类受支持 DBMS 灾难恢复配置的典型示例。 该文章中的第二幅插图描绘了使用 HANA 的方案示例。 在此类方案中，SAP 应用程序支持的主要数据库都可以部署。

支持使用较小的 VM 作为灾难恢复区域中的目标实例，因为该 VM 不会遇到工作负载流量已满的情况。 为此需要注意以下事项：

  • 较小的 VM 类型不能附加太多的磁盘
  • 较小 VM 的网络和存储吞吐量较低
  • 如果在一个 Azure 可用性集中收集不同的 VM，或者应该在 VM 的 M 系列与 Mv2 系列之间进行大小调整，则跨 VM 系列调整大小可能会造成问题
  • 考虑数据库实例的 CPU 和内存消耗量，确保它能够以极短的延迟接收更改流，并有足够的 CPU 和内存资源，能够以极短的延迟对数据应用这些更改

可在 VM 大小页面找到有关不同 VM 大小限制的更多详细信息

部署 DR 目标的另一种受支持方法是，在运行非生产 SAP 实例的非生产 DBMS 实例的 VM 上安装另一个 DBMS 实例。 此方法可能有点难度，因为需要确定应在 DR 方案中充当主要实例的特定目标实例所需的内存、CPU 资源、网络带宽和存储带宽。 尤其是在 HANA 中，强烈建议在共享主机上配置充当 DR 目标的实例，使数据不会预先加载到 DR 目标实例中。

注意

尚未对 SAP 工作负载中的 DBMS 部署测试 Azure Site Recovery 的使用情况。 因此，目前不支持对 SAP 系统的 DBMS 层使用 Azure Site Recovery。 未列出的其他 Microsoft 和 SAP 复制方法不受支持。 使用第三方软件在不同 Azure 区域之间复制 SAP 系统的 DBMS 层的做法需由该软件的供应商提供支持，而不能通过 Microsoft 和 SAP 支持渠道接受支持。

非 DBMS 层

对于 SAP 应用程序层以及所需的最终共享或存储位置，客户可以使用以下两种主要方案：

  • 不要将第二个 Azure 区域中的灾难恢复目标用于任何生产或非生产目的。 在此方案中，最好是不要部署充当灾难恢复目标的 VM，并将映像以及对生产 SAP 应用程序层映像的更改复制到灾难恢复区域。 可执行此类任务的功能之一是 Azure Site Recovery。 Azure Site Recovery 支持这种 Azure 到 Azure 的复制方案。
  • 灾难恢复目标是非生产系统实际使用的 VM。 整个 SAP 环境分散在两个不同的 Azure 区域之间，通常其生产系统位于一个区域，非生产系统位于另一个区域。 在很多客户部署中，客户的非生产系统等同于生产系统。 客户在应用程序层的非生产系统中预先安装了生产应用程序实例。 在故障转移事件中，非生产实例将会关闭，生产 VM 的虚拟名称将转移到非生产 VM（在 DNS 中分配新 IP 地址后），预先安装的生产实例将会启动

SAP Central Services 群集

使用共享磁盘 (Windows)、SMB 共享 (Windows) 或 NFS 共享的 SAP Central Services 群集要更难复制一些。 在 Windows 端，Windows 存储复制是可能的解决方案。 在 Linux 上，rsync 是可行的解决方案。 Azure NetApp 文件的跨区域复制也是一个可行的解决方案。

不支持的方案

Azure 体系结构上的 SAP 工作负载不支持一系列方案。 “不支持”指的是 SAP 和 Microsoft 无法传递对这些配置的支持，需要将支持事宜移交给提供用于建立此类体系结构的软件的最终相关第三方。 其中两个类别是：

  • 存储软设备：市场上有各种存储软设备。 某些供应商会提供自己的文档，介绍如何在 Azure 上使用他们自己的与 SAP 软件相关的存储软设备。 涉及此类存储软设备的配置或部署的支持需要由存储软设备的供应商来提供。 SAP 支持说明 #2015553 中也表述了这一事实
  • 高可用性框架：对于 Azure 上的 SAP 工作负载，仅支持使用 Pacemaker 和 Windows Server 故障转移群集作为高可用性框架。 如前所述，Microsoft 介绍了 SIOS Datakeeper 解决方案并制作了其文档。 尽管如此，SIOS Datakeeper 的组件需要通过 SIOS（作为提供这些组件的供应商）来提供支持。 SAP 还在不同的 SAP 说明中列出了其他已通过认证的高可用性框架。 其中的某些框架也通过了 Azure 第三方供应商的认证。 尽管如此，使用这些产品的配置需要由产品供应商提供支持。 不同的供应商集成到 SAP 支持流程的方式不同。 决定在将本产品与 Azure 上部署的 SAP 配置配合使用之前，应明确知道哪种支持流程最适合特定的供应商。
  • 数据库文件驻留在共享磁盘上的共享磁盘群集不受支持，maxDB 除外。 对于其他所有数据库，支持的解决方案是使用单独的存储位置，而不是使用 SMB、NFS 共享或共享磁盘来配置高可用性方案

不支持的其他方案如下所述：

  • 像在 NetWeaver、S/4HANA 和 Hybris 等系统中那样，会在 SAP 应用程序层和 SAP DBMS 层之间造成较高网络延迟的部署情况。 这包括：
    • 在本地部署一个层，并在 Azure 中部署另一个层
    • 在不同的 Azure 区域中部署系统的 SAP 应用层，而部署的层不是 DBMS 层
    • 在与 Azure 位于同一位置的数据中心内部署一个层，并在 Azure 中部署另一个层，只不过此类体系结构模式是由 Azure 原生服务提供的
    • 在 SAP 应用层与 DBMS 层之间部署网络虚拟设备
    • 将与 Azure 数据中心位于同一位置的数据中心内托管的存储用于 SAP DBMS 层或 SAP 全局传输目录
    • 在两家不同的云供应商处部署两个层。 例如，在 Oracle 云基础结构中部署 DBMS 层，并在 Azure 中部署应用层
  • 多实例 HANA Pacemaker 群集配置
  • Windows 支持通过适用于 SAP 数据库的 ANF 上的 SOFS 或 SMB 进行使用共享磁盘的 Windows 群集配置。 不过，我们建议使用特定数据库的本机高可用性复制，并使用单独的存储堆栈
  • 在 Linux 上，支持使用位于 ANF 顶层的 NFS 共享中的数据库文件部署 SAP 数据库，但 SAP HANA、Oracle Linux 上的 Oracle 以及 SUSE 和 RedHat 上的 Db2 除外
  • 在除 Windows 和 Oracle Linux 以外的任何其他来宾 OS 上部署 Oracle DBMS。 另请参阅 SAP 支持说明 #2039619

我们未进行测试，因此没有经验的方案包括：

  • 用于复制 DBMS 层 VM 的 Azure Site Recovery。 因此，我们建议使用数据库本机异步复制功能实现可能的灾难恢复配置

后续步骤

参阅 SAP NetWeaver 的 Azure 虚拟机规划和实施中的后续步骤