亚马逊AWS官方博客
使用 Amazon CloudWatch Application Insights 提高 SAP 业务流程韧性
简介
越来越多的 SAP 客户选择在 RISE with SAP on AWS 来支持他们向 AWS 的转型。RISE with SAP on AWS 为客户的 S/4HANA Cloud 提供遍布全球的云基础设施，具备卓越的安全性和可靠性，以及极为全面的服务组合，来推动客户的业务转型。
但是，成千上万的客户仍然使用传统的许可证模式运行 SAP on AWS，并且急需指导来配置其 SAP 系统以实现高可用性，同时尽可能降低复杂性。
由于企业依赖 SAP 等任务关键型系统来驱动其核心业务流程，因此确保韧性和连续性变得至关重要。根据 IDC 报告，对于财富 1000 强公司，计划外应用程序停机每年造成的损失从 12.5 亿美元增加到 25 亿美元。此类成本包括生产力损失、收入损失和对公司声誉的潜在损害。为了降低这种风险，对于任务关键型 SAP 工作负载，您需要配置跨多个可用区（多 AZ）的高可用性（HA，High Availability）解决方案。
虽然引入 HA 和多 AZ 的目的是尽可能减少停机时间，但它也增加了部署和管理的复杂性。因此，对已部署的高可用性解决方案，客户必须对其运行状况具有适当水平的可观测性，这样他们才能确定解决方案已做好准备，能够应对系统故障或其他服务中断。
对 HA 的可观测性使得 IT 团队能够全面监控、调查和解决问题。这可以提供对整个分布式 SAP 环境的完整可见性，从而实现主动检测问题，简化根本原因分析过程，并优化解决流程以尽量减少对关键运营的干扰。
在这篇博文中，我们将介绍通过适用于 SAP 的 Amazon CloudWatch Application Insights，实现对采用高可用性（HA）架构模式的 AWS for SAP 的可观测性。
业务场景
在传统 SAP 环境中，HA 架构的配置、部署和管理可能很复杂。作为 SAP Basis 管理员，您需要能够监控系统可用性，进行问题排查，确定故障原因和实施可靠的可观测性功能。 为了改进 SAP 的高可用性，并与 AWS Well Architected Framework 和 AWS Well Architected Framework 之 SAP 详解保持一致，您需要为采用高可用性设计模式的 SAP 工作负载实施可观测性功能，以实现以下目标：
- 事件管理：快速识别可用性问题，确定发生故障的组件，设置警报并发送通知，以及恢复业务运营。
- 事后根本原因分析：使用 AWS 机器学习算法来处理系统，进行准确的根本原因分析，从而节省时间。
- 预防和纠正措施：从单一面板监控 SAP 可用性，为 HA 解决方案配置偏差检测，并设置自适应阈值和警报，以提供近乎实时的通知，从而在可用性问题发生之前主动识别异常情况。
SAP 构造块的高可用性
在实施 HA 时，您需要将以下关键绩效指标作为主要目标：
- 平均恢复时间（MTTR，Mean Time to Recover），衡量从故障中恢复并防止故障再次发生所需的平均时间。
- 恢复时间目标（RTO），是指您的 SAP 应用程序在中断后完成恢复所需的时间，它定义了等待服务恢复时所能接受的不可用时长。
- 恢复点目标（RPO），决定了应用程序恢复期间可接受的数据丢失水平。
要了解有关 RPO、RTO 和 MTTR 的更多信息，请参阅 AWS 文档指南《SAP on AWS 可用性和可靠性架构指南》中的高可用性（HA）和灾难恢复（DR）部分。
在业务部门就 RPO、RTO 和 MTTR 达成一致之后，很重要的一点是为 SAP 系统中的单点故障（SPOF）提供保护，以防出现可用性问题。这包括保护 SAP Central Services、SAP 应用程序服务器、NFS、数据库和 SAP Web Dispatcher。
我们还建议使用 AWS Backup 等工具定期备份 Amazon Elastic Block Storage（EBS）卷、Amazon EC2 映像、Amazon Elastic File System（EFS）和数据库备份，这些工具也可以支持 SAP HANA 数据库的数据库级备份。
让我们看看如何实现保护机制来实现 HA。
| SAP 单点故障 | 保护 | |
| 1 | SAP ABAP Central Services（ASCS）和 Enqueue Replication Server（ERS） | ASCS 包含 Message Server，用于管理用户登录和工作负载在应用程序服务器上的分发；以及 Enqueue Server，用于管理应用程序级表锁定（入队锁）。 您在主可用区（AZ）部署 ASCS 主机，并在辅助可用区部署 SAP Enqueue Replication Service（ERS）主机。 然后，使用操作系统集群软件保护这些主机。1) |
| 2 | SAP 数据库（包括 HANA） | 为了改善 MTTR 和 RPO，您可以在启用了 HANA System Replication（HSR）的辅助可用区中安装另一个主机，运行 HANA 数据库的备用副本，以防止数据丢失并最大限度地减少停机时间。 然后，使用操作系统集群软件保护这些主机。1) |
| 3 | SAP 主应用程序服务器（PAS） | 跨多个可用区部署额外的 SAP 应用程序服务器并进行流量均衡，方便用户重新连接并继续其业务流程。 |
| 4 | SAP Web dispatcher | 配置 AWS 应用程序负载均衡器（ALB）或网络负载均衡器（NLB），以此作为 Web Dispatcher 流量的前端，可以面向互联网，也可以面向内部。 负载均衡器作为 SAP Web Dispatcher 的单一联系点，具有高可用性，可根据传入的应用程序流量自动扩展请求处理容量。 |
| 5 | 共享文件系统（NFS/SMB） | 实施 Amazon Elastic File System（EFS）、适用于 Windows File Server 的 Amazon FSx 或适用于 NetApp ONTAP 的 Amazon FSx，作为具备高可用性、持久的托管式 NFS 服务，跨多个可用区主动运行。 |
注意：
1) 您可以通过实施开源 HA 集群资源管理器 Pacemaker，来改进 ASCS ERS 和 SAP 数据库的 RTO。Pacemaker 管理部署在多个可用区中的单个 Amazon Elastic Compute Cloud（EC2）主机（也称为节点），并检测故障和协调故障转移活动，将工作负载从主节点移至位于不同可用区的辅助节点来恢复工作负载。您还可以通过在辅助可用区部署 SAP 其他应用程序服务器（AAS，Additional Application Server）来提高 SAP 应用程序服务器的可用性，使得用户能够重新连接并继续其业务流程。
有关采用 HA 设置的 SAP 系统，请参阅图 1 的参考架构。
图 1：两个可用区（AZ）中的 SAP HA 部署
提高 HA 解决方案的可观测性
使用适用于 SAP 的 Amazon CloudWatch Application Insights（CWAI），您可以通过向导无缝载入 SAP 应用程序，这样就能即时访问预构建的控制面板、指标、日志、跟踪和警报。适用于 SAP 的 Amazon CWAI 在单一平台上，简化了不同部门角色监管 SAP 可用性的工作。在载入过程中，CWAI 会自动发现 SAP NetWeaver 系统的资源，例如 Amazon EC2 实例、Amazon EBS 卷和 Amazon EFS 文件系统。它还支持开箱即用的指标和控制面板。要了解如何将 SAP 应用程序载入到 CWAI，请参阅 AWS 博文 Monitor SAP Applications using Amazon CloudWatch Application Insights 来了解更多信息。
让我们来看看如何为面向 SAP 单点故障（SPOF）的 CWAI 配置可观测性，例如：SAP Central Services（Message Server 和入队进程）、SAP 应用程序服务器、NFS（共享存储）、数据库和 SAP Web Dispatcher。
步骤 1：事件管理
为 SAP Central Services 配置可观测性
适用于 SAP 的 CWAI 可以监控 SAP ASCS 和 ERS 集群节点。它在 ASCS 出现故障时提供指示，这会导致采取防护措施，将 ASCS 移至运行状况良好的节点（ERS）。您还可以发现 SAP ASCS 和 ERS 集群节点之间，导致脉动信号故障的网络中断。
图 2：SAP ASCS 和 ERS 集群的 SAP HA 指标控制面板
您可以查看 SAP HA 指标 sap_HA_get_failover_config_HAActive 和 sap_HA_check_failover_config_state，这些指标指示 HA 的配置状态，以确保在集群中检测到任何故障时可以随时进行失效转移。
图 3：SAP HA 指标控制面板，显示集群连接器指标
为 SAP 应用程序服务器配置可观测性
您可以配置 CWAI 来监控 SAP NetWeaver Application 的可用性（即 PAS 和 AAS 的状态）。它会突出显示影响 SAP 系统可用性的系统级错误、系统异常和进程状态（即 Message Server、Enqueue Server、igw、icman、gwrd、disp+work）。
图 4：SAP NetWeaver 可用性控制面板
为 SAP 数据库配置可观测性
适用于 SAP 的 CWAI 可以配置为监控 HANA 数据库的可用性（包括主数据库节点和备用数据库节点之间的 HSR）。它提供与数据库节点之间的网络中断相关的信息，这些中断可能导致失效转移事件和无法重新连接到辅助数据库节点。这些图形能够显示数据库事务中，导致 HSR 延迟日志传输的异常峰值。
图 5：SAP HANA 数据库集群的 SAP HA 指标控制面板
图 6：SAP HANA SYSTEMDB 和 HDB 的 SAP HSR 指标控制面板
为 SAP Web Dispatcher 配置可观测性
Amazon CloudWatch 支持监控应用程序负载均衡器（ALB）可用性和 EC2 实例可用性。详细了解 Amazon CloudWatch ALB 监控指标和用于监控 EC2 实例状态的指标。
步骤 2：事后根本原因分析
CWAI 自动从 SAP 服务器摄取日志和跟踪。通过分析集群日志、NetWeaver 日志和跟踪，CWAI 可以自动识别异常情况并启动自动响应。CWAI 使用来自 SAP 组件的日志数据来识别可能导致 SAP 可用性的中断并解决问题。这些功能可帮助您排查和解决 SAP 应用程序的问题，并改善 MTTR。
问题摘要控制面板在检测 AWS 基础设施的性能问题时非常有用，例如 EC2 服务器大小、EBS 存储 IOPS 和吞吐量、EFS 流量和网络吞吐量。其中还报告了与可用性相关的常见的 SAP 问题，例如 HSR 故障、数据库流量激增、应用程序服务器故障等。在下面的图 7 中，我们说明了 CWAI 针对采用 HA 部署的 SAP 系统，自动检测到的可用性和性能方面的问题。
图 7：问题摘要控制面板
在此示例场景中，适用于 SAP 的 CWAI 自动持续检测 SAP 的可用性问题。控制面板提供问题摘要，以及对如何解决问题的深入分析。为了确保 SAP 的可用性，建议激活基于机器学习的指标异常检测功能，并使用 CloudWatch Alarms 建立相关的 CloudWatch 警报。在下面的示例场景中，SAP PAS 报告为离线。
图 8：SAP 可用性问题
SAP 可用性指标 sap_alerts_availability 确认 SAP PAS 的状态已从在线更改为离线，并且问题持续，导致 SAP 系统出错。
图 9：SAP 可用性问题与 SAP PAS 状态相关
有关对 SAP 系统进行故障排除的更多信息，请参阅 Amazon CloudWatch 文档中有关 SAP NetWeaver、SAP HANA 和 SAP ASE 的部分。要了解有关异常检测的更多信息，请阅读 AWS 博文 Operationalizing CloudWatch Anomaly Detection。
步骤 3：纠正和预防措施
为了跟踪 SAP HA 的关键指标，我们建议激活异常检测以及自适应阈值，并通过 Amazon SNS 或 Amazon EventBridge 接收警报。要了解有关使用 AWS EventBridge 和 AWS CloudFormation 集中管理 CloudWatch 警报的更多信息，请参阅 AWS 博文 How to centralize CloudWatch Alarms with Amazon EventBridge and AWS CloudFormation。
SAP Basis 管理员为 sap_alerts_availability 指标启用异常检测。
图 10：为 SAP PAS 启用异常检测
适用于 SAP 的 CloudWatch Application Insights 的估算成本
CloudWatch Application Insights 在载入应用程序时，为 SAP 设置 CloudWatch 自定义指标、警报和日志。根据 Amazon CloudWatch 定价，会产生一些费用。我们来看一个示例场景，该 SAP 系统采用 HA 部署，包括 10 个其他应用程序服务器（AAS）、1 个主应用程序服务器（PAS）、1 个 SAP ASCS 和 ERS 集群，以及一个使用 HANA System Replication（HSR）的 HANA 数据库集群。在我们的示例系统中，总共有 15 台 EC2 服务器和关联的 EBS 卷和 EFS 存储，用于 SAP 文件共享。
| 单位成本 | 已启用功能 | 总成本 | |
| 每个自定义指标的成本 | 0.30 美元/月 | 10 个指标 | 3.00 美元/月 |
| 每个警报的成本 | 0.10 美元/月 | 10 个警报 | 1.00 美元/月 |
| 数据摄取成本 | 0.05 美元/GB | 10 GB/月 | 0.50 美元/月 |
| SAP 日志存储成本 | 0.03 美元/GB | 10 GB/月 | 0.30 美元/月 |
| 1 个 EC2 实例的总成本 | 4.80 美元/月 | ||
| 采用 HA 部署的 SAP 系统总成本（在 15 个 EC2 实例上运行） | 72.00 美元/月 | ||
有关 Amazon CloudWatch Application Insights 定价的更多信息，请参阅 CWAI 文档中的“定价”部分。
总结
为了尽可能减少对 SAP 系统的干扰，您应该确保采取了多种措施，包括针对系统关键组件的可观测性功能。借助适用于 SAP 的 Amazon CloudWatch Application Insights，您可以在几分钟内为 SAP HA 部署实现全栈可观测性，以及使用开箱即用的功能，例如预构建的控制面板、预配置的指标和警报、自动异常检测，以及主动管理 SAP 可用性。
CWAI 可以为 SAP 创建易于使用的“单一面板”类型的控制面板，这些控制面板可以在整个企业中共享，供整个团队跟踪 SAP HA 解决方案的运行状况。它包含多项指标，可对采用 HA 部署的 SAP 系统进行端到端监控。您的 AWS 账户以外的用户可以查看和访问 CloudWatch 控制面板。为确保 SAP 可用性，我们建议 SAP Basis 管理员与运维团队合作，在专用控制面板中维护一系列重要的 SAP HA 指标。
CWAI 可用于运行在 Red Hat Enterprise Linux 上的 SAP ASE、SAP NetWeaver 和 SAP HANA，以及 SUSE Linux Enterprise Server 操作系统。您可以在 Amazon CloudWatch Application Insights 文档中找到有关如何使用该解决方案的更多指导以及教程等，并可通过 Setup monitoring for SAP using Amazon CloudWatch Application Insights 讲习会来学习实施该解决方案的动手操作指南。要详细了解 AWS 上 SAP 工作负载的可观测性，请阅读 AWS Blog 系列“SAP on AWS 的端到端可观测性”的第 1 部分和第 2 部分。
加入 AWS for SAP 的讨论
在客户团队和 AWS Support 渠道之外，AWS 还在 re:Post 网站上提供公开问答论坛。我们的 AWS for SAP 团队会定期查看 AWS for SAP 主题的讨论情况，确保问题得到解答，从而为您提供协助。如果您的问题与支持无关，可以考虑加入 re:Post 的讨论，提出您自己的问题和解答，将内容添加到社区知识库中。