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

使用 SAP 应用程序实现最佳网络延迟的配置选项

  • 项目

重要

2021 年 11 月，我们对在区域部署中将邻近放置组与 SAP 工作负载一起使用的方式进行了重大更改。

基于 SAP NetWeaver 或 SAP S/4HANA 体系结构的 SAP 应用程序对 SAP 应用层与 SAP 数据库层之间的网络延迟很敏感。 这种敏感性是大多数业务逻辑在应用层运行的结果。 因为 SAP 应用层运行业务逻辑，所以它以每秒数千或数万次的高频率向数据库层发出查询。 在大多数情况下，这些查询的性质很简单。 它们通常可以在 500 毫秒或更短的时间内在数据库层上运行。

以下过程花费的时间对运行业务流程所需的时间有重大影响：在网络上将此类查询从应用程序层发送到数据库层并接收返回的结果。 对网络延迟的这种敏感性是你可能想要在 SAP 部署项目中实现特定的最小网络延迟的原因。 有关如何对网络延迟进行分类的准则，请参阅 SAP Note #1100926 - FAQ: Network performance（SAP 说明 #1100926 - 常见问题解答：网络性能）。

在许多 Azure 区域，数据中心的数量不断增加。 同时，客户（特别是高端 SAP 系统的客户）会使用更特殊的 VM 系列，例如 Mv2 或 Mv3 系列以及更新的系列。 这些 Azure 虚拟机类型并不总是在收集到 Azure 区域的每个数据中心都可用。 这些事实可以为优化 SAP 应用层与 SAP DBMS 层之间的网络延迟创造机会。

Azure 提供不同的 SAP 工作负荷部署选项。 对于所选的部署类型，你可以选择优化网络延迟（如果需要）。 本文的以下部分透彻介绍了每个选项的详细信息：

邻近放置组

邻近放置组支持在单个网络脊下对不同 VM 类型进行分组，确保它们之间的最佳低网络延迟。 在邻近放置组中部署第一个 VM 时，该 VM 会绑定到一个特定的网络脊。 由于所有其他 VM 都将部署到同一邻近放置组中，因此这些 VM 将分组到同一网络脊下。 这项功能听起来很吸引人，但此构造的使用也引入了一些限制和缺陷：

  • 你不能假设所有 Azure VM 类型在每一个 Azure 数据中心或每一个网络脊下都可用。 因此，在一个邻近放置组中，不同 VM 类型的组合可能会受到严格限制。 之所以会出现这些限制，是因为运行特定 VM 类型所需的主机硬件可能不在数据中心或分配邻近放置组的网络脊下
  • 在对一个邻近放置组中的部分 VM 重设大小时，不能自动假设在所有情况下，新的 VM 类型在同一数据中心或在邻近放置组分配到的网络脊下可用
  • 当 Azure 解除硬件授权时，可能会将邻近放置组的某些 VM 强制放入另一个 Azure 数据中心或网络脊。 有关此情况的详细信息，请阅读文档邻近放置组

重要

由于存在潜在限制，只有在以下情况下才应使用邻近放置组：

  • 在某些情况下需要时（见后面）
  • 当应用程序层与 DBMS 层之间的网络延迟过高并影响工作负载时
  • 用于单个 SAP 系统的粒度，而非整个系统环境或完整的 SAP 环境
  • 使用邻近放置组时，应将邻近放置组内的不同 VM 类型和 VM 数量保持在最低水平

可以使用邻近放置组来优化网络延迟的场景：

  • 你想要在不同的可用性区域中部署 SAP 工作负荷的关键资源，另一方面，你需要通过使用每个区域中的可用性集将应用程序层的 VM 分布在不同的容错域中。 在这种情况下，如本文档稍后所述，邻近放置组是所需的粘附资源。
  • 使用可用性集部署 SAP 工作负荷。 其中 SAP 数据库层、SAP 应用程序层和 ASCS/SCS VM 已分组到三个不同的可用性集。 在这种情况下，需要确保可用性集不会分散在整个 Azure 区域，因为这可能导致网络延迟，从而对 SAP 工作负荷产生负面影响（具体取决于 Azure 区域）。
  • 使用邻近放置组将 VM 组合在一起，以在 VM 中托管的服务之间实现尽可能最低的网络延迟。 例如，仅优化可用性区域内的延迟并不能满足应用程序要求。

对于部署场景 2，在许多区域（尤其是没有可用性区域的区域和有可用性区域的大多数的区域），与 VM 所在位置无关的网络延迟是可以接受的。 不过 Azure 的某些区域在不使用邻近放置组的情况下，如果不配置三种不同的可用性集，就无法提供足够好的体验。

什么是邻近放置组？

Azure 邻近放置组是一种逻辑构造。 定义邻近放置组后，它会绑定到 Azure 区域和 Azure 资源组。 部署 VM 时，以下 VM 将引用邻近放置组：

  • 部署在网络脊下的第一个 Azure VM 具有许多 Azure 计算单元和较低的网络延迟。 此类网络脊通常与单个 Azure 数据中心匹配。 可以将第一个虚拟机视为“范围 VM”，它根据最终与部署参数结合的 Azure 分配算法部署到计算缩放单元。
  • 部署的所有引用邻近放置组的后续 VM 都将部署在与第一个虚拟机相同的网络脊下。

注意

如果未在放置第一个 VM 的网络脊下部署可以运行特定 VM 类型的主机硬件，所请求的 VM 类型的部署将失败。 你收到一条分配失败消息，表明 VM 在邻近放置组的外围内不受支持。

为了降低上述风险，建议在创建邻近放置组时使用意向选项。 通过意向选项，可列出要包含在邻近放置组中的 VM 类型。 此 VM 类型列表将用于查找托管这些 VM 类型的最佳数据中心。 如果找到此类数据中心，则将创建 PPG，并将其范围限定为满足 VM SKU 要求的数据中心。 如果未找到此类数据中心，则邻近放置组的创建将失败。 有关详细信息，请参阅 PPG - 使用意向指定 VM 大小这一文档。 请注意，意向选项触发的检查不会考虑实际容量情况。 因此，仍然可能存在源于可用容量不足的分配错误。

单个 Azure 资源组可以分配有多个邻近放置组。 但是，一个邻近放置组只能分配给一个 Azure 资源组。

有关邻近放置组的详细信息和部署示例，请参阅可用文档。

具有区域部署的邻近放置组

必须在 SAP 应用程序层和 DBMS 层之间提供合理的低网络延迟。 大多数情况下，仅区域部署就可以满足此要求。 对于一组有限的场景，仅靠区域部署可能无法满足应用程序延迟要求。 在这种情况下，需要尽可能近地放置 VM 并实现合理的低网络延迟，可以为这样的 SAP 系统定义 Azure 邻近放置组。

避免将多个 SAP 生产或非生产系统捆绑到单个邻近放置组中。 避免捆绑 SAP 系统，因为在邻近放置组中分组的系统越多，出现以下情况的几率就越大：

  • 需要一个 VM 类型，该 VM 类型在分配了邻近放置组的网络脊下不可用。
  • 当你随着时间推移，需要将 VM 数量扩展到邻近放置组时，非主流 VM（例如 M 系列 VM）的资源最终可能无法满足你的需求。

根据 Microsoft 部署到 Azure 区域以减少 Azure 可用性区域中网络延迟的许多改进，使用邻近放置组进行区域部署时的部署指南如下所示：

具有区域的新邻近放置组

与目前给出的建议不同的是，两个区域中的数据库 VM 不再是邻近放置组的一部分。 每个区域的邻近置放群组现在都在运行 SAP ASCS/SCS 实例的 VM 部署的范围内。 这也意味着，对于可用性区域由多个数据中心收集的区域，ASCS/SCS 实例和应用程序层可以在一个网络脊下运行，并且数据库 VM 可以在另一个网络脊下运行。 尽管进行了网络改进，但 SAP 应用程序层与 DBMS 层之间的网络延迟仍足以提供足够良好的性能和吞吐量。 此新配置的优点是，使用 SAP 系统的 DBMS 层或/和应用程序层，可以更灵活地调整 VM 大小或迁移到新的 VM 类型。

有关对 DBMS 环境使用 Azure NetApp 文件 (ANF) 的特殊情况，以及适用于 SAP HANA 的 Azure NetApp 文件应用程序卷组的 ANF 相关新功能及其邻近放置组的需要，请查看 Azure NetApp 文件上适用于 SAP HANA 的 NFS v4.1 卷文档。

具有可用性集部署的邻近放置组

在这种情况下，目的是使用邻近放置组来并置通过不同可用性集部署的 VM。 在此使用场景中，不会跨区域的不同可用性区域使用受控部署。 而是希望使用可用性集部署 SAP 系统。 因此，至少为 DBMS VM、ASCS/SCS VM 和应用程序层 VM 设置了可用性集。 由于无法在 VM 的部署时指定可用性集和可用性区域，因此无法控制将不同可用性集中的 VM 分配到何处。 这可能会导致某些 Azure 区域不同 VM 之间的网络延迟仍然过高，无法提供足够良好的性能体验。 因此，最终的体系结构如下所示：

具有 AvSet 的邻近放置组

在此图中，单个邻近放置组将分配给单个 SAP 系统。 此 PPG 将分配给三个可用性集。 然后，将第一个数据库层 VM 部署到 DBMS 可用性集，以确定邻近放置组的范围。 此体系结构建议将所有 VM 并置在同一网络脊下。 它将引入本文前面提到的限制。 因此，邻近放置组体系结构应该少用。

将可用性集和可用性区域与邻近放置组结合使用

使用可用性区域部署 SAP 系统的问题之一是，你无法使用特定可用性区域内的可用性集来部署 SAP 应用程序层。 你希望将 SAP 应用程序层与 SAP ASCS/SCS VM 部署在相同的区域中。 目前不支持在部署单个 VM 时引用可用性区域和可用性集。 但是，仅部署指示可用性区域的 VM，你无法确保应用程序层 VM 分布在不同的更新域和故障域中。

通过使用邻近放置组，你可以绕过此限制。 下面是部署顺序：

  • 创建邻近放置组。
  • 通过引用可用性区域部署定位点 VM（建议用作 ASCS/SCS VM）。
  • 创建一个引用 Azure 邻近放置组的可用性集。 （请参阅本文后面的命令。）
  • 通过引用可用性集和邻近放置组来部署应用层 VM。

重要

请务必了解，应用层 VM 的磁盘并不保证分配在 VM 使用邻近放置组定向到的同一可用性区域。 后续步骤中显示的部署结果可能是，VM 被分配在同一网络脊中，并与定位点 VM 分配在相同的可用性区域中。 但是，各自的磁盘（基本 VHD 和已装载的 Azure 块存储磁盘）可能不会分配到同一网络脊，甚至不会分配到同一可用性区域。 这些 VM 的磁盘可以分配到特定区域的任何数据中心。 但是，通过定义区域部署的定位点 VM 的磁盘将部署在部署 VM 的同一区域。

部署 VM 时，无需像上一部分演示的那样部署第一个 VM，你可以引用可用性区域和邻近放置组：

New-AzVm -ResourceGroupName "ppgexercise" -Name "centralserviceszone1" -Location "westus2" -OpenPorts 80,3389 -Zone "1" -ProximityPlacementGroup "collocate" -Size "Standard_E8s_v4"

成功部署此虚拟机后，SAP 系统的 ASCS/SCS 实例将托管在一个可用性区域中。 在这种情况下，VM 和 VM 的基本 VHD 以及可能已装载的 Azure 块存储磁盘分配在同一可用性区域内。 邻近放置组的范围固定为你定义的可用性区域的网络脊之一。

在下一步中，你需要创建要用于 SAP 系统的应用层的可用性集。

定义并创建邻近放置组。 用于创建可用性集的命令需要另外引用邻近放置组 ID（而不是名称）。 你可以使用以下命令获取邻近放置组的 ID：

Get-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate"

创建可用性集时，如果使用托管磁盘（除非另有说明，否则为默认设置）和邻近放置组，则需要考虑其他参数：

New-AzAvailabilitySet -ResourceGroupName "ppgexercise" -Name "ppgavset" -Location "westus2" -ProximityPlacementGroupId "/subscriptions/my very long ppg id string" -sku "aligned" -PlatformUpdateDomainCount 3 -PlatformFaultDomainCount 2

理想情况下，应使用三个容错域。 但是，受支持容错域的数量可能因地区而异。 在本例中，特定区域可能具有的最大容错域数量为 2 个。 若要部署应用层 VM，你需要添加对可用性集名称和邻近放置组名称的引用，如下所示：

New-AzVm -ResourceGroupName "ppgexercise" -Name "appinstance1" -Location "westus2" -OpenPorts 80,3389 -AvailabilitySetName "myppgavset" -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"

注意

部署到上述可用性集中的 VM 的磁盘不会被强制分配到 VM 所在的同一可用性区域。 虽然你实现了应用层 VM 分布在分配定位点 VM 所在的同一网络脊下的不同容错域，但磁盘也可在不同的容错域中分配在区域范围的不同位置。

此部署的结果为：

  • SAP 系统的中央服务位于特定的可用性区域中。
  • SAP 应用程序层通过可用性集位于与单个或多个 SAP 中央服务 (ASCS/SCS) VM 相同的网络脊中。

注意

为了创建高可用性配置，你将一个 DBMS 和 ASCS/SCS VM 部署到一个区域，而将第二个 DBMS 和 ASCS/SCS VM 部署到另一个区域，因此，你需要为每个区域提供不同的邻近放置组。 对于你使用的任何可用性集，也是如此。

更改现有系统的邻近放置组配置

如果根据到目前为止给出的建议实现了邻近放置组，并且想要调整到新配置，可以使用以下文章中介绍的方法完成：

如果临近放置组中有一个现有 VM，无法移动到一个新的 VM 类型，则使用这些命令还会收到分配错误。

具有灵活的业务流程的虚拟机规模集

为避免与邻近放置组相关的限制，建议使用 FD=1 的灵活规模集跨可用性区域部署 SAP 工作负载。 这种部署策略可确保部署在每个区域的 VM 不局限于单个数据中心或网络脊，而且所有 SAP 系统组件（如数据库、ASCS/ERS 和应用层）都在一个区域内。 由于所有 SAP 系统组件都在区域级别范围内，因此单个 SAP 系统不同组件之间的网络延迟必须足以确保令人满意的性能和吞吐量。 这种具有 FD=1 的灵活规模集的新部署选项的主要优势在于，它为 SAP 系统所有层调整 VM 规模或切换到新的 VM 类型提供了更大的灵活性。 此外，规模集将在单个区域内的多个容错域中分配 VM，这非常适合在每个区域内运行多个应用层 VM。 有关详细信息，请参阅 SAP 工作负载的虚拟机规模集文档。

灵活规模集中的 SAP 工作负荷部署

在非生产环境或非高可用性环境中，可以使用 FD=1 的灵活规模集，在单个区域内部署所有 SAP 系统组件，包括数据库、ASCS 和应用层。

本部分详述之前建议的用于优化 SAP 网络延迟的部署选项。 随着时间的推移，新功能和 Azure 内容会不断增多，本部分的详细内容应该只会在极少数情况下适用。

适合整个 SAP 系统的、具有区域部署的邻近放置组

到目前为止，我们推荐的邻近置放群组用法如下图所示。

此图显示具有区域的旧邻近放置组。

你在将 SAP 系统部署到的两个可用性区域中分别创建一个邻近放置组 (PPG)。 特定区域的所有 VM 都是该特定区域的单个邻近放置组的一部分。 首先在每个区域部署 DBMS VM 来界定 PPG 的范围，然后将 ASCS VM 部署到同一个区域和 PPG 中。 在第三步中，请创建一个 Azure 可用性集，将可用性集分配给范围内的 PPG，并将 SAP 应用程序层部署到其中。 此配置的优点是，所有组件都在同一网络脊下很好地对齐。 最大的缺点是，调整虚拟机大小的灵活性可能会受到限制。

根据 Microsoft 部署到 Azure 区域以减少 Azure 可用性区域中网络延迟的许多改进，本文提供了最新的针对区域部署的部署指南。

邻近放置组和 HANA 大型实例

如果数据库层的某些 SAP 系统依赖于 HANA 大型实例，则在使用修订版 4 行或标记中部署的 HANA 大型实例单元时，HANA 大型实例单元和 Azure VM 之间的网络延迟将得到显著改进。 其中一项改进是，HANA 大型实例单元在部署时会与邻近放置组一起部署。 你可以使用该邻近放置组来部署应用层 VM。 因此，这些 VM 将部署在托管 HANA 大型实例单元的同一数据中心内。

若要确定 HANA 大型实例单元是否部署在修订版 4 标记或行中，请查看通过 Azure 门户控制 Azure HANA 大型实例一文。 在 HANA 大型实例单元的属性概述中，你还可以确定邻近放置组的名称，因为它是在部署 HANA 大型实例单元时创建的。 属性概述中显示的名称是应将应用层 VM 部署到的邻近放置组的名称。

与仅使用 Azure 虚拟机的 SAP 系统相比，当你使用 HANA 大型实例时，在决定要使用多少个 Azure 资源组方面的灵活性较差。 如此文章所述，HANA 大型实例租户的所有 HANA 大型实例单元都分组在一个资源组中。 除非为了分隔生产和非生产系统或其他系统，或因其他原因而部署到不同的租户中，否则，所有 HANA 大型实例单元都将部署在一个 HANA 大型实例租户中。 此租户与资源组具有一对一关系。 但是，将为每个单元定义单独的邻近放置组。

因此，单个租户的 Azure 资源组和邻近放置组之间的关系将如下所示：

此图显示邻近放置组和 HANA 大型实例。

后续步骤

查看文档：