通过

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

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

  • 项目

跨 Azure 可用性区域部署不同的 SAP 体系结构是 Azure 上 SAP 工作负载部署的推荐体系结构。 Azure 可用性区域 (zone) 定义为：“某个地理区域 (region) 中的独特物理位置。 每个局部区域 (zone) 由一个或多个数据中心组成，这些数据中心配置了独立电源、散热设备和网络”。 Azure 可用性区域并未覆盖所有地理区域。 有关提供可用性区域的 Azure 区域，请查看 Azure 区域地图。 本文列出了哪些区域提供可用性区域。 大多数能够承载更大 SAP 工作负载的 Azure 区域都提供了可用性区域。 新的 Azure 区域从一开始就提供可用性区域。 一些较旧的区域已经或正在进行可用性区域改造。

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

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

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

  • 使用可用性集进行部署时，将在单个局部区域或数据中心（以适用于特定地理区域的情况为准）的集内排布 VM。 那么在发生影响整个局部区域中数据中心的电源、散热或网络问题时，通过可用性集进行的部署是不受保护的。 使用可用性集时，VM 与其磁盘之间也没有强制对齐方式。 这意味着，磁盘可以位于 Azure 区域的任何数据中心，独立于区域的区域性结构。 但从另一方面看，VM 与该局部区域或数据中心内的更新域和容错域相对应。 具体对于可为每个可用性集内的两个 VM 提供保护的 SAP ASCS 或数据库层而言，与容错域相对应可以防止这两个 VM 最终部署在相同的主机硬件上。
  • 通过 Azure 可用性区域部署 VM 并选择不同的局部区域（目前最多可选择三个）会将 VM 部署到不同的物理位置，因此，在发生影响整个局部区域中数据中心的电源、散热或网络问题时，可以提供保护。 VM 及其相关磁盘也位于同一可用性区域中。 但在将同一 VM 系列的多个 VM 部署到同一个可用性区域时，最终部署在同一台主机或同一容错域中的这些 VM 不会受到保护。 因此，通过可用性区域进行部署非常适合 SAP ASCS 和数据库层，在其中的每个层我们通常会看到两个 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 可用性区域的详细信息。
  • 你所遇到的网络往返延迟不一定表示构成不同区域的数据中心的实际地理距离。 网络往返延迟还受到这些不同数据中心之间的电缆连接和电缆路由的影响。
  • 如果你将可用性区域用作小距离灾难恢复解决方案，请记住，我们经历过在世界不同区域造成广泛破坏的自然灾害，包括对电力基础设施的严重和广泛破坏。 不同区域之间的距离可能并不总是足够大，无法弥补如此大的自然灾害。
  • 可用性区域之间的网络延迟并非在所有 Azure 区域中都相同。 即使在一个 Azure 地区内，不同区域之间的网络延迟也可能不同。 即使在最坏的情况下，基于 HANA 系统复制或 SQL Server Always On 的数据库级的同步复制也能正常工作，而不会影响工作负载的可扩展性。
  • 根据在不同区域之间测得的网络延迟，确定在何处使用可用性区域。 网络延迟在两个方面发挥重要作用：
    • 需要进行同步复制的两个数据库实例之间的延迟。 因为最大的 NetWeaver 和 S/4HANA 系统在具有较高网络延迟（小于 1.5 毫秒）的区域之间运行非常成功，因此可以忽略这一考虑事项
    • 在活动数据库实例所在区域中运行 SAP 对话实例的 VM 与另一区域中的类似 VM 之间的网络延迟差。 此差越大，业务进程和批处理作业运行时受到的影响就越大，具体取决于它们是在数据库所在区域中运行，还是在其他区域中运行（参阅本文中的下文）。
  • 即使在最大的区域中，Azure 可用性区域的网络延迟也足够低，可以运行 SAP 业务流程。 到目前为止，我们只看到了少数特殊情况，在这些情况下客户需要将 SAP 应用程序层和数据库层托管在单个数据中心网络主干下。

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

理想的可用性区域组合

除非你使用 SAP 功能（例如登录组、RFC 服务器组、批处理服务器组等）配置业务流程分配，否则业务流程可以在 SAP 应用程序层的不同应用程序实例中执行。 这一事实的副作用是，批处理作业可能会由任何 SAP 应用程序实例执行，与它们是否在包含主动数据库实例的同一局部区域中运行无关。 如果不同局部区域之间的网络延迟相比某一个局部区域内部的网络延迟差异较小，则批处理作业运行时间的差异可能不明显。 但是，当某一个局部区域内部的网络延迟相比跨局部区域网络流量的网络延迟差异越大时，如果批处理作业在一个局部区域中执行且该局部区域中的数据库实例并非主动实例，则批处理作业运行时间受到的影响可能就越大。 运行时间的可接受差异由客户确定。 工作负载的跨局部区域流量的可容忍网络延迟也由客户确定。 纯粹从技术角度来看，Azure 地区内 Azure 可用性区域之间的网络延迟适用于 NetWeaver、S/4HANA 或其他 SAP 应用程序的体系结构。 当你决定采用本文中介绍的部署概念之一时，你作为客户也有可能使用 SAP 的登录组、RFC 服务器组、批处理服务器组等概念来缓解这种差异。

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

  • 主动/主动：运行 ASCS/SCS 的 VM 对以及运行数据库层的 VM 对分布在两个局部区域中。 运行 SAP 应用程序层的 VM 会平均部署到相同的两个局部区域中。 如果数据库或 ASCS/SCS VM 正在故障转移，某些未完成的和处于活动状态的事务可能会回滚。 但用户仍保持登录状态。 主动数据库 VM 和应用程序实例在哪个局部区域中运行实际上并不重要。 此体系结构是用于跨局部区域部署的首选体系结构。 在执行业务流程时，如果区域之间的网络延迟导致更大的差异，你可以使用 SAP 登录组、RFC 服务器组、批处理服务器组等功能，将业务流程的执行路由到与活动数据库实例位于同一区域的特定对话实例
  • 主动/被动：运行 ASCS/SCS 的 VM 对以及运行数据库层的 VM 对分布在两个局部区域中。 运行 SAP 应用程序层的 VM 会部署到一个可用性区域中。 在主动 ASCS/SCS 和数据库实例所在的同一局部区域中运行应用程序层。 如果你认为不同区域之间的网络延迟过高，则可以使用此部署体系结构。 这会导致业务流程运行时出现无法忍受的差异。 或者，如果你想将可用性区域部署用作短距离灾难恢复部署。 区域。 如果某个 ASCS/SCS 或数据库故障转移到次要区域，则你可能会遇到更高的网络延迟，吞吐量也随之下降。 另外，需要尽快故障回复先前已故障转移的 VM，才能恢复到先前的吞吐量级别。 如果发生局部区域性服务中断，需要将应用程序层故障转移到次要区域。 用户遇到的系统完全关闭的活动。

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

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

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

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

  • 部署用于所有三个区域中的数据库实例的 VM SKU。 执行此测量时，请务必启用 Azure 加速网络。 加速网络是几年前的默认配置。 但请检查它是否已启用并正常工作
  • 找到网络延迟最低的两个区域后，部署该 VM SKU 的另外三个 VM，用作跨三个可用性区域的应用层 VM。 针对所选的两个区域中的两个数据库 VM 测量网络延迟。
  • 使用 niping 作为测量工具。 SAP 支持说明 #500235 和 #1100926 中介绍了 SAP 提供的此工具。 将 SAP 说明 #1100926 中的网络延迟分类作为粗略指南。 大于 0.7 毫秒的网络延迟并不意味着系统在技术上无法工作，也不意味着业务流程不能满足你的个人 SLA。 该说明并非用于说明 SAP 和/或 Microsoft 支持或不支持什么。 请重点关注所述的延迟测量命令。 由于 ping 无法穿透 Azure 加速网络代码路径，因此我们不建议使用它。

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

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

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

重要

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

重要

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

主动/主动部署

此部署体系结构之所以称为主动/主动部署，是因为要跨两个或三个局部区域部署主动的 SAP 应用程序服务器。 使用排队复制的 SAP Central Services 实例将部署在两个区域之间。 这同样适用于数据库层，它将部署在 SAP Central Service 所在的相同区域中。 考虑此配置时，你需要在你的地区中找到两个适当的两个可用性区域，这两个可用性区域的跨区域网络延迟必须是你的工作负载可接受的。 此外，请确保所选区域中的网络延迟与跨区域网络延迟之间的差值是你的工作负载可接受的。

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

主动/主动区域部署

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

重要

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

主动/被动部署

如果你找不到减轻 SAP 业务流程运行时潜在增量的配置，或者如果你想部署短距离灾难恢复配置，则可以从 SAP 应用程序层的角度部署具有主动/被动特性的体系结构。 定义一个主动区域，在其中部署完整的应用层，并尝试运行主动数据库实例和主动 SAP Central Services 实例。 使用此类配置时，需要根据作业是否在主动数据库实例所在区域中运行，确保业务事务与批处理作业的运行时差异不会过大。

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

主动/被动区域部署

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

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

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

注意

如果你将可用性区域用作小距离灾难恢复解决方案，请记住，我们经历过在世界不同区域造成广泛破坏的自然灾害，包括对电力基础设施的严重和广泛破坏。 不同区域之间的距离可能并不总是足够大，无法弥补如此大的自然灾害。

下面是此类配置的示例：

在区域中结合使用高可用性和灾难恢复

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

后续步骤

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