亚马逊AWS官方博客

SAP on AWS 的端到端可观测性:第 2 部分 – SAP 网络延迟监控

简介

这是 AWS 端到端 SAP 可观测性系列博客文章的第 2 部分。第 1 部分见此处

网络性能对于 SAP 等企业应用程序至关重要,这些应用程序通常运行的是公司业务流程。在 SAP 博客 Network Performance Analysis for SAP Netweaver ABAP 中,解释了 SAP 三层软件架构(即表示层、应用层和数据库层)如何使用各种协议和 API 的组合来相互通信。

网络速度缓慢会导致数据处理的严重延迟,并导致更长的用户响应时间。网络流量拥塞将导致数据包丢失,甚至各层间的通信完全失败,这会造成数据丢失或损坏,并给 SAP 应用程序及其用户带来严重后果。快速数据库语句的执行时间通常在 100 微秒范围内,而典型的往返网络时间约为 300 微秒,因此网络时间很容易就占到数据库总响应时间的 75%。

考虑到网络性能的重要性,我们将讨论如何在 AWS 云中优化和监控 SAP 网络性能。我们首先从 SAP 服务器之间的网络性能开始(在图 1 中以红框突出显示)。

SAP 服务器之间的网络性能

SAP 是一款包含客户端和服务器的企业应用程序,由多个组件组成,例如 SAP 应用程序服务器,用户登录该服务器以执行日常活动,以及用于存储 SAP 数据的数据库。下图重点介绍了客户网络(本地)上的 SAP 用户,如何通过 WAN(Wide Area Network,广域网)连接(例如 Site-to-Site VPN 或称为 AWS Direct Connect 的专用链接),来访问在 AWS 云上运行的 SAP 应用程序。

架构图显示了与在 AWS 云端运行的 SAP 应用程序的本地连接图 1:示例架构图显示了与在 AWS 云端运行的 SAP 应用程序的本地连接

面向任务关键型工作负载的 AWS 全球基础设施

在深入分析之前,让我们先了解一下 AWS 全球基础设施。AWS 使用“区域”概念,这是一个用于部署我们数据中心集群的物理位置,遍布全球。我们将每一组逻辑数据中心称为一个可用区(AZ)。每个 AWS 区域由一个地理区域内的至少三个可用区组成,这些可用区彼此隔离,在物理上相互独立。

其他云提供商通常将单个数据中心定义为一个区域,而每个 AWS 区域均采用多可用区设计,为客户提供诸多优势。每个可用区都有独立的电源、冷却和物理安全措施,并通过冗余的超低延迟网络来连接。如果将工作负载分布在多个可用区中,则在面对停电、雷击、龙卷风、地震等问题时,可以更好地隔离问题并保护客户免受影响。可用区彼此之间间隔有相当公里数的距离,不过通常在 100 公里之内。AWS 客户在需要高可用性时,可以将应用程序设计为在多个可用区中运行,以实现更高的容错能力。最重要的是,AWS 基础设施区域还可以满足极高级别的安全性、合规性和数据保护要求。

对于运行需要高可用性的企业应用程序,Gartner 推荐使用 AWS 区域和可用区模型方法。

SAP 网络延迟要求

为了获得出色的性能,SAP 概述了建议的网络要求:

  • 根据 SAP Note 1100926,SAP 应用程序服务器和数据库服务器之间的网络延迟应小于 0.7 毫秒(ms)
  • 使用同步数据复制(实现零数据丢失所必需)时,HANA 系统复制的网络延迟应小于 1 毫秒

SAP 提供了 NIPING 工具来测量本地 SAP 系统所用网络基础设施的运行状况。NIPING 以客户端/服务器工具的形式运行,用于测量网络延迟和吞吐量。

基于以上内容,我们以包含 6 个可用区的 AWS 北弗吉尼亚区域(us-east-1)为例,来看看在可用区之间以及同一可用区内部的网络延迟。我们创建了 6 个 EC2 实例,每个可用区中一个,然后使用 NIPING 执行测试,以 AZ1 为基准。

使用 NIPING 来测量网络延迟的 EC2 实例

图 2:使用 NIPING 来测量网络延迟的 EC2 实例

NIPING 结果显示了 AZ1 与 AZ2 到 AZ6 之间的可用区网络延迟与 0.7 毫秒阈值的对比。AZ1 内部的可用区网络延迟同样低于 0.7 毫秒的阈值。

图 3:2023 年 7 月,使用 NIPING 在 AWS 北弗吉尼亚(us-east-1)区域测量的网络延迟

如上所述,NIPING 工具可用于监控和测量可用区之间和可用区内部的网络延迟。但是,它需要多个 EC2 实例才能运行,您也可以使用 AWS Network Manager 作为替代测量方案。

AWS Network Manager – Infrastructure Performance

AWS Network Manager 提供了工具和功能,帮助您在 AWS 上管理和监控网络。使用 Network Manager,您可以更轻松地执行连接管理、网络监控和故障排除、IP 管理以及网络安全和治理。我们在此处要重点介绍的是 AWS Network Manager – Infrastructure Performance

通过 Infrastructure Performance,您可以近实时地监控 AWS 全球网络的性能,包括 AWS 区域之间以及可用区之间/内部的网络延迟,还可以查看指定时段的历史记录。您可以最多以 5 分钟的间隔监控网络延迟,并查看 45 天的历史趋势。此外,您还可以将这些延迟指标发布到 Amazon CloudWatch,以进行进一步的监控、分析和发送提醒。这样您就可以轻松地评估网络性能是否会影响 SAP 或其他正在运行的应用程序。使用 Infrastructure Performance 没有任何费用,也无需预置 EC2 实例!

我们使用 AWS 北弗吉尼亚区域(us-east-1),来看看可用区之间和同一可用区内部的网络延迟分析。

在 AWS 管理控制台中,导航到 Network Manager,然后选择“Infrastructure Performance”:

AWS Network Manager – Infrastructure Performance 服务

图 4:AWS Network Manager – Infrastructure Performance 服务

设置网络延迟监控非常简单快捷。选择“可用区间”,在下例中,使用 AZ1 作为基准,选择其他 5 个可用区:

选择“可用区间”,以及 us-east-1 中要监控的相应可用区图 5:选择“可用区间”,以及 us-east-1 中要监控的相应可用区

接下来,选择相应的时段(在本示例中为 1 周)和监控频率(5 分钟):选择监控时段

图 6:选择监控时段

从 AZ1(use1-az1)到另外 5 个可用区的可用区之间延迟与上述 NIPING 结果一致:

可用区之间网络延迟监控图 7:可用区之间网络延迟监控

同样,我们在所有 6 个可用区内重复可用区内部网络延迟测试,结果显示平均网络延迟低于 0.3 毫秒,远低于 0.7 毫秒阈值:

可用区内部网络延迟监控图 8:可用区内部网络延迟监控

在上面的示例中,我们使用 AZ1 作为基准。先使用 AZ2 作为基准,然后使用 AZ3,以此类推,在其他可用区两两之间重复上述延迟测试,以确定哪个可用区符合建议。

区域之间的网络延迟会是什么情况呢? 我们将 AWS 北弗吉尼亚区域(us-east-1)与美国的另外几个 AWS 区域进行比较,包括俄亥俄(us-east-2)、北加利福尼亚(us-west-1)和俄勒冈(us-west-2)。

区域之间的网络延迟监控图 9:区域之间的网络延迟监控

在本例中,我们观察到 us-east-1(北弗吉尼亚)和 us-east-2(俄亥俄)之间的网络延迟最低,这是因为它们之间的地理距离较短。

通过 Amazon CloudWatch 监控可用区延迟

按照 AWS 文档:创建 CloudWatch 控制面板中的步骤操作,订阅 CloudWatch 指标 “AggregateAWSNetworkPerformance”,来创建用于监控可用区之间延迟的控制面板。您还可以在网络延迟超过特定阈值时创建和发送警报。请注意,尽管 AWS Network Manager – Infrastructure Performance 可以免费使用,但本例中会产生与 CloudWatch 相关的费用;请参阅 Amazon CloudWatch 定价

用于可用区之间监控的 CloudWatch 控制面板图 10:用于可用区之间监控的 CloudWatch 控制面板

请注意,Infrastructure Performance 未纳入使用 VPC 联网资源路径的性能指标,例如 Transit Gateway、NAT 网关、VPC 端点、弹性负载均衡或 Amazon EC2 网络接口。Infrastructure Performance 也没有考虑 SAP 应用程序所观察到的网络延迟,因为在此之上还会有 SAP 应用程序/操作系统/数据库开销。有关更多详细信息,请参阅 Infrastructure Performance AWS 文档

设计 SAP 架构以实现高可靠性和可用性

如果您有多个服务器(即多个 SAP 应用程序服务器、SAP Web Dispatcher),我们建议将这些服务器分布在多个可用区来提高可靠性和可用性,因为这样带来的好处要大于增加网络延迟的影响。如果您在设计具有高可用性的 SAP 架构(即数据库复制),请选择网络延迟低于其他可用区的一对可用区,以确保获得出色的性能。请注意,网络延迟可能会随时间而变化,具体因区域和可用区对而异。

如果您的批处理作业具有极高的性能要求,那么我们建议从数据库服务器所在可用区的 SAP 应用程序服务器中调度这些批处理作业。

如果您有跨区域灾难恢复(DR)要求,请考虑 AWS 区域之间的网络延迟以及对应的地理距离,以确定用于灾难恢复的辅助区域。

有关更多详细信息,请参阅 SAP 详解 – AWS Well-Architected Framework 文档

对于 RISE with SAP,AWS 是首家支持在所有 AWS 区域都提供短程灾难恢复和远程灾难恢复的云提供商。短程灾难恢复在单个区域的 2 个可用区之间提供灾难恢复,恢复点目标(RPO)为零,即不丢失数据,这证明了 SAP 对 AWS 多可用区基础设施的信心;以及对在地理位置相互分离的多可用区之间,用于支持同步数据复制的高速、低延迟的网络链接的信心。

远程灾难恢复包括在 2 个 AWS 区域之间的灾难恢复,RPO 为 30 分钟。客户可以选择任一灾难恢复选项,或将短程和远程灾难恢复结合用于 SAP RISE 构造中。

用户(本地)与 AWS 云之间的网络性能

本地与 AWS 之间的 WAN 连接

图 11:本地与 AWS 之间的 WAN 连接

本地与 AWS 云之间的 WAN 连接,对于确保客户能够访问 SAP 系统至关重要。监控是维护 WAN 连接的可靠性、可用性和性能的重要组成部分。

Amazon CloudWatch 提供了监控 Site-to-Site VPN 连接和 AWS Direct Connect 的功能。对于 Site-to-Site VPN,我们建议至少监控 VPN 隧道的状态以及传输的入站和出站数据。有关可用监控指标的详细信息,请参阅 AWS 文档:Monitoring your Site-to-Site VPN connectionMonitoring Direct Connect with CloudWatch

RISE with SAP

如果您在运行 SAP RISE on AWS,则仍需要 WAN 连接才能将用户连接到 AWS 云。

在这种情况下,您可以使用 AWS Transit Gateway,将您的 AWS 账户连接到 SAP RISE 管理的 AWS 账户,如下图所示。有关更多详细信息和连接选项,请参阅 AWS 文档:SAP RISE on AWS Connectivity

SAP RISE on AWS 客户的示例 WAN 连接

图 12:SAP RISE on AWS 客户的示例 WAN 连接

借助 AWS Global Accelerator 减少网络延迟

如果您的远程用户分散于不同的地理位置,在尝试访问 SAP 系统时应该怎么办? 例如,欧洲用户通过互联网访问 AWS 新加坡区域中的 SAP 系统,可能会遇到不可预测的网络性能,从而导致用户体验不佳。

一种选择是使用 AWS Global Accelerator,它通过 AWS 全球网络骨干网来传输流量,从而提高应用程序的可用性和性能。当用户连接到 AWS Global Accelerator 时,流量会根据最低的网络延迟,自动路由到最佳 AWS 端点。此外,您还可以通过 Accelerated Site-to-Site VPN(也是使用 AWS Global Accelerator)来加密传输中数据,为您的用户提供出色的安全性和网络性能。

远程用户通过 AWS Accelerated Site-to-Site VPN 访问 SAP 图 13:远程用户通过 AWS Accelerated Site-to-Site VPN 访问 SAP

要确定您的远程 SAP 用户是否可以获益于 AWS Global Accelerator,您可以使用 AWS Global Accelerator Speed Comparison 工具,该工具提供各个 AWS 区域的网络延迟测量值。您可以从 SAP 用户的位置运行此延迟测试,因为 AWS Global Accelerator 会将网络流量路由到最近的 AWS 端点,并将其与现有的互联网连接进行比较。请注意,当您多次运行测试时,结果可能会发生变化。下载时间会受到 Global Accelerator 外部的多种因素影响,例如您使用的最后一段网络的质量、容量和连接距离等。

图 14:使用和不使用 AWS Global Accelerator 的网络延迟比较

使用 Amazon CloudFront 提高 SAP Fiori 性能

Amazon CloudFront 是内容分发网络服务,通过在全球网络的边缘站点中缓存内容,以低延迟和高传输速度交付 SAP Fiori 等 Web 内容。当用户请求 CloudFront 缓存的 SAP Fiori 内容时,CloudFront 会将请求路由到能够提供服务的最近的边缘站点。如果内容已经缓存在边缘站点,CloudFront 从边缘站点将内容直接传输给用户,这样可以减少延迟并改善用户体验。

如果您运行带有 SAP Fiori 的全球 SAP 系统,并且有分散在不同地理位置的用户使用该系统,那么您可能会从使用 Amazon CloudFront 中获益。

有关 AWS Global Accelerator 与 Amazon CloudFront 的详细比较,请参阅此 AWS 博客

总结

网络性能优化和监控可能会非常耗时。使用 AWS Network Manager – Infrastructure Performance,您可以轻松地监控 AWS 全球基础设施的网络延迟,包括区域之间以及可用区之间/内部的延迟。利用这些信息,您可以优化 SAP 应用程序的放置位置,以充分利用 AWS 云端的出色网络性能,持续监控任务关键型 SAP 工作负载,并在出现问题时进行故障排除。

借助 Amazon CloudWatch,您可以通过单一面板来监控对 SAP 至关重要的网络组件。通过将 AWS Network Manager 与 Amazon CloudWatch 结合使用,您可以监控可用区之间、可用区内部的网络延迟,以及客户网络与 AWS 云之间的 WAN 连接。

要改善终端用户与 AWS 云的连接,您可以考虑使用 AWS Global Accelerator 或 Amazon CloudFront,这两项服务分别通过路由和缓存机制来提高应用程序的可用性和性能。

AWS 产品文档中,您可以找到有关 SAP on AWSNetwork Manager – Infrastructure PerformanceAmazon CloudWatchAWS Global AcceleratorAmazon CloudFront 的更多信息。

创作人员

在此,我们要感谢 Derek Ewell 和 Spencer Martenson 对本博文的贡献。