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

使用 Azure 可用性区域的 SAP 工作负荷配置

  • 项目

除了可以在 Azure 可用性集中部署不同的 SAP 体系结构层以外，还可以使用 Azure 可用性区域部署 SAP 工作负载。 Azure 可用性区域 (zone) 定义为：“某个地理区域 (region) 中的独特物理位置。 每个局部区域 (zone) 由一个或多个数据中心组成，这些数据中心配置了独立电源、散热设备和网络”。 Azure 可用性区域并未覆盖所有地理区域。 有关提供可用性区域的 Azure 区域，请查看 Azure 区域地图。 此地图显示了哪些区域提供或已宣布提供可用性区域。

需要保护三个不同的典型 SAP NetWeaver 或 S/4HANA 体系结构层：

  • SAP 应用程序层，可以是一到几十个 VM。 需要尽可能地避免在同一台主机服务器上部署多个 VM。 此外，这些 VM 与 DBMS 层之间应保持可接受的邻近距离，使网络延迟保持在可接受的范围内
  • SAP ASCS/SCS 层，代表 SAP NetWeaver 和 S/4HANA 体系结构中的单一故障点。 你通常会看到要在故障转移框架中涵盖的两个 VM。 因此，应将这些 VM 分配到不同的基础结构容错域中
  • SAP DBMS 层，也代表单一故障点。 在一般情况下，它由故障转移框架涵盖的两个 VM 组成。 因此，应将这些 VM 分配到不同的基础结构容错域中。 例外的情况是可以使用两个以上 VM 的 SAP HANA 横向扩展部署

通过可用性集或通过可用性区域部署关键 VM 的主要差别在于：

  • 使用可用性集进行部署时，将在单个局部区域或数据中心（以适用于特定地理区域的情况为准）的集内排布 VM。 那么在发生影响整个局部区域中数据中心的电源、散热或网络问题时，通过可用性集进行的部署是不受保护的。 但从另一方面看，VM 与该局部区域或数据中心内的更新域和容错域相对应。 具体而言，对于每个可用性集保护两个 VM 的 SAP ASCS 或 DBMS 层，与容错域的对齐可防止这两个 VM 最终位于同一主机硬件上。
  • 通过 Azure 可用性区域部署 VM 并选择不同区域（最多三个可能）时，将跨不同的物理位置部署 VM，并增加对整个区域的电源、冷却或网络问题的保护。 但在将同一 VM 系列的多个 VM 部署到同一个可用性区域时，最终部署在同一台主机或同一容错域中的这些 VM 不会受到保护。 因此，通过可用性区域进行部署非常适合 SAP ASCS 和 DBMS 层，在其中的每个层我们通常会看到两个 VM。 对于可能远远超过两个 VM 的 SAP 应用程序层，可能需要回退到不同的部署模型（参阅后文）

跨 Azure 可用性区域进行部署的动机应该是，在能够应对单个关键 VM 发生故障，或者减少在关键 VM 中修补软件所造成的停机时间的基础上，在发生可能影响一个或多个 Azure 数据中心可用性的重大基础结构问题时提供保护。

作为另一种复原部署功能，Azure 引入了 具有灵活业务流程 的虚拟机规模集，用于 SAP 工作负荷。 虚拟机规模集提供平台托管虚拟机的逻辑分组。 虚拟机规模集的灵活业务流程提供了在区域中创建规模集或跨可用性区域的选项。 创建时，使用 platformFaultDomainCount>1（FD>1）在区域中灵活规模集，规模集中部署的 VM 将分布在同一区域中的指定数量的容错域。 另一方面，使用 platformFaultDomainCount=1（FD=1）跨可用性区域创建灵活的规模集会跨不同区域分配虚拟机，规模集还会尽力在每个区域中的不同容错域中分发 VM。 对于 SAP 工作负荷，仅支持具有 FD=1 的灵活规模集。 将灵活规模集与 FD=1 一起使用进行跨区域部署的优点是，使用规模集部署的 VM 会以最佳方式分布在区域中的不同容错域中。 有关详细信息，请参阅 SAP 工作负荷灵活规模集的部署指南。

跨可用性区域部署的注意事项

使用可用性区域时需要考虑以下事项：

  • Azure 可用性区域之间的最大网络往返延迟在文档区域和可用性区域中进行了说明。
  • 你所遇到的网络往返延迟不一定表示构成不同区域的数据中心的实际地理距离。 网络往返延迟还受到这些不同数据中心之间的电缆连接和电缆路由的影响。
  • 可用性区域不是理想的灾难恢复 (DR) 解决方案。 在全球某些区域，自然灾害可能造成广泛破坏，其中包括对电力基础设施的严重破坏。 不同区域之间的距离可能不足以用作确定合适 DR 解决方案的标准。
  • 可用性区域之间的网络延迟并非在所有 Azure 区域中都相同。 有时，可以跨不同区域部署并运行 SAP 应用层，因为从一个区域到活动 DBMS VM 的网络延迟是可接受的。 但在某些 Azure 区域中，部署在不同区域中的活动 DBMS VM 与 SAP 应用程序实例之间的延迟对于 SAP 业务流程而言不可接受。 在这种情况下，部署体系结构需要有所不同，要么对应用程序采用主动/主动体系结构，要么采用主动/被动体系结构（如果跨局部区域网络的延迟过高）。
  • 根据在不同区域之间测得的网络延迟，确定在何处使用可用性区域。 网络延迟在两个方面起着重要作用：
    • 需要进行同步复制的两个 DBMS 实例之间的延迟。 网络延迟越高，它就越有可能影响工作负载的可伸缩性。
    • 在活动 DBMS 实例所在区域中运行 SAP 对话实例的 VM 与另一区域中的类似 VM 之间的网络延迟差。 此差越大，业务进程和批处理作业运行时受到的影响就越大，具体取决于它们是在 DBMS 所在区域中运行，还是在其他区域中运行。

跨可用性区域部署 Azure VM 并在同一 Azure 区域内建立故障转移解决方案存在一些限制：

理想的可用性区域组合

如果你要跨局部区域部署 SAP NetWeaver 或 S/4HANA 系统，那么有以下两种体系结构模式可以部署：

  • 主动/主动：运行 ASCS/SCS 的 VM 对以及运行 DBMS 层的 VM 对分布在两个局部区域中。 运行 SAP 应用程序层的 VM 会平均部署到相同的两个局部区域中。 如果 DBMS 或 ASCS/SCS VM 正在故障转移，某些未完成的和处于活动状态的事务可能会回滚。 但用户仍保持登录状态。 主动 DBMS VM 和应用程序实例在哪个局部区域中运行实际上并不重要。 此体系结构是用于跨局部区域部署的首选体系结构。
  • 主动/被动：运行 ASCS/SCS 的 VM 对以及运行 DBMS 层的 VM 对分布在两个局部区域中。 运行 SAP 应用程序层的 VM 部署到一个可用性区域中。 在主动 ASCS/SCS 和 DBMS 实例所在的同一局部区域中运行应用程序层。 如果跨不同局部区域的网络延迟太高，以致无法运行跨局部区域分布的应用程序层，请使用此部署体系结构。 SAP 应用程序层需要在主动 ASCS/SCS 和/或 DBMS 实例所在的同一局部区域中运行。 如果某个 ASCS/SCS 或 DBMS VM 故障转移到次要区域，则你可能会遇到更高的网络延迟，吞吐量也随之下降。 另外，需要尽快故障回复先前已故障转移的 VM，才能恢复到先前的吞吐量级别。 如果发生局部区域性服务中断，需要将应用程序层故障转移到次要区域。 用户遇到的系统完全关闭的活动。 在某些 Azure 区域中，当你想要使用可用性区域时，此体系结构是唯一可行的体系结构。 如果你无法接受 ASCS/SCS 或 DBMS VM 故障转移到次要区域所造成的潜在影响，坚持使用可用性集部署可能更好

因此，在决定如何使用可用性区域之前，需要确定：

  • Azure 区域的三个局部区域之间的网络延迟。 了解一个地理区域中各局部区域之间的网络延迟，这样，便可以选择在跨局部区域网络流量中网络延迟最低的局部区域。
  • 所选区域之一中的 VM 到 VM 延迟，与所选两个区域之间的网络延迟的差。
  • 确定需要部署的 VM 类型是否在所选的两个区域中可用的声明。 对于某些 VM SKU，可能会遇到这种情况：某些 SKU 只在两个（共三个）区域中可用。

区域之间和区域内部的网络延迟

若要确定不同区域之间的延迟，需要：

  • 部署用于所有三个区域中的 DBMS 实例的 VM SKU。 执行此测量时，请务必启用 Azure 加速网络。 加速网络是几年前的默认配置。 但请检查它是否已启用并正常工作
  • 找到网络延迟最低的两个区域后，部署该 VM SKU 的另外三个 VM，用作跨三个可用性区域的应用层 VM。 针对所选的两个 DBMS 区域中的两个 DBMS VM 测量网络延迟。
  • 使用 niping 作为测量工具。 SAP 支持说明 #500235 和 #1100926 中介绍了 SAP 提供的此工具。 请重点关注所述的延迟测量命令。 由于 ping 无法穿透 Azure 加速网络代码路径，因此我们不建议使用它。

无需手动执行这些测试。 可以找到一个 PowerShell 过程：可用性区域延迟测试，它能自动完成所述的延迟测试。

根据测量结果以及可用性区域中 VM SKU 的可用性，需要做出一些决策：

  • 定义 DBMS 层的理想区域。
  • 根据区域内部或区域之间的网络延迟差，确定是否要跨一个、两个或全部三个区域分布主动 SAP 应用层。
  • 从应用程序的角度确定是要部署主动/被动还是主动/主动配置。 （本文稍后会解释这些配置。）

在做出这些决策的同时，请考虑 SAP 在 SAP 说明 #1100926 中所述的网络延迟建议。

重要

所做的测量和决策对于测量时所用的 Azure 订阅有效。 如果使用另一个 Azure 订阅，枚举区域的映射可能因另一个 Azure 订阅而异。 因此，需要重复测量，或者通过工具 Avzone-Mapping 脚本找出新订阅与旧订阅之间的映射关系。

重要

按如上述执行的测量预期会在支持可用性区域的每个 Azure 区域中显示不同的结果。 即使网络延迟要求不变，也仍可能需要在不同 Azure 区域中采用不同的部署策略，因为区域之间的网络延迟可能不同。 在某些 Azure 区域中，三个不同区域之间的网络延迟可能会存在很大的差异。 在其他区域中，三个不同区域之间的网络延迟可能较为一致。 指出始终存在 1 毫秒到 2 毫秒网络延迟的声明是错误的。 Azure 区域中可用性区域之间的网络延迟不能一般化。

主动/主动部署

此部署体系结构之所以称为主动/主动部署，是因为要跨两个或三个局部区域部署主动的 SAP 应用程序服务器。 使用排队复制的 SAP Central Services 实例将部署在两个区域之间。 这同样适用于 DBMS 层，它将部署在 SAP Central Service 所在的相同区域中。 考虑此配置时，需要在区域中找到两个适当的两个可用性区域，它们的跨区域网络延迟可让工作负荷接受并满足同步 DBMS 复制的需求。 此外，请确保所选区域中的网络延迟与跨区域网络延迟的差不会过大。

SAP 体系结构的性质是，除非以不同的方式对它进行配置，否则用户作业和批处理作业可以在不同的应用程序实例中执行。 主动/主动部署的这一事实的副作用是，批处理作业可能会由任何 SAP 应用程序实例执行，与它们是否在包含主动 DBMS 的同一局部区域中运行无关。 如果不同局部区域之间的网络延迟相比某一个局部区域内部的网络延迟差异较小，则批处理作业运行时间的差异可能不明显。 但是，当某一个局部区域内部的网络延迟相比跨局部区域网络流量的网络延迟差异越大时，如果批处理作业在一个局部区域中执行且该局部区域中的 DBMS 实例并非主动实例，则批处理作业运行时间受到的影响可能就越大。 运行时间的可接受差异由客户确定。 工作负载的跨局部区域流量的可容忍网络延迟也由客户确定。

下面列出了当跨不同可用性区域部署的应用程序层中运行时间和吞吐量差异不是很大时，支持此类主动/主动部署的 Azure 区域：

  • 澳大利亚东部（三个局部区域中的两个）
  • 巴西南部（三个区域全部）
  • 印度中部（三个区域全部）
  • 美国中部（所有三个局部区域）
  • 亚太（三个区域全部）
  • 美国东部（三个局部区域中的两个）
  • 美国东部 2（所有三个局部区域）
  • 德国中西部（三个区域全部）
  • 以色列中部（所有三个区域）
  • 意大利北部（三个区域中的两个）
  • 韩国中部（三个区域全部）
  • 波兰中部（所有三个区域）
  • 卡塔尔中部（三个区域全部）
  • 北欧（所有三个局部区域）
  • 挪威东部（三个区域中的两个）
  • 南非北部（三分之二）
  • 美国中南部（三个区域全部）
  • 东南亚（三个区域全部）
  • 瑞典中部（三个区域全部）
  • 瑞士北部（三个区域全部）
  • 阿联酋北部（三个区域全部）
  • 英国南部（三个局部区域中的两个）
  • 西欧（三个局部区域中的两个）
  • 美国西部 2（所有三个局部区域）
  • 美国西部 3（三个区域全部）

即使我们提供了区域列表，客户也还是需要测试工作负载以确定主动/主动部署体系结构是否可行。

在部分 Azure 区域中，跨区域的主动/主动 SAP 部署体系结构是不可行的，例如：

  • 加拿大中部
  • 法国中部
  • 日本东部

但对于单个工作负载也许可用。 因此在决定体系结构之前，应先进行测试。 Azure 一直在努力改善其网络的质量和延迟。 几年前进行的测量也许并不能代表目前的状况。

其他未列出的地理区域可能也符合条件，具体取决于你对运行时间差异的容忍程度。

跨两个区域的主动/主动部署的简化架构如下所示：

Active/Active zone deployment

以下注意事项适用于此配置：

重要

在此主动/主动方案中，会产生跨区域流量的费用。 请查看文档带宽定价详细信息。 SAP 应用程序层与 SAP DBMS 层之间的数据传输活动非常密集。 因此主动/主动方案的费用可能较高。

主动/被动部署

如果发现一个区域中的网络延迟与跨区域网络流量的网络延迟差不可接受，可部署的体系结构从 SAP 应用层的角度来看应该具有主动/被动特征。 定义一个主动区域，在其中部署完整的应用层，并尝试运行主动 DBMS 实例和主动 SAP Central Services 实例。 使用此类配置时，需要根据作业是否在主动 DBMS 实例所在区域中运行，确保业务事务与批处理作业的运行时差异不会过大。

可能更适合使用这种跨不同局部区域的部署体系结构的 Azure 区域为：

  • 加拿大中部
  • 法国中部
  • 日本东部
  • 挪威东部
  • 南非北部

该体系结构的基本布局如下所示：

Active/Passive zone deployment

以下注意事项适用于此配置：

高可用性和灾难恢复组合配置

Microsoft 不会共享有关托管 Azure 区域中不同 Azure 可用性区域的设施之间的地理距离的任何信息。 尽管如此，一些客户正在使用相关区域进行 HA 和 DR 组合配置，此配置承诺恢复点目标 (RPO) 为零。 若 PRO 为零，则表示即使是在发生灾难恢复的情况下也不应丢失任何提交的数据库事务。

注意

建议仅在特定的场合采用此类配置。 例如，出于安全与合规原因，数据不能离开 Azure 区域，在这种情况下可以使用此配置。

下面是此类配置的示例：

Combined high-availability DR in zones

以下注意事项适用于此配置：

后续步骤

下面是跨 Azure 可用性区域进行部署的后续步骤：