手册

为生产环境的 SAP HANA 数据库选择虚拟机 (VM)。

→对于大型数据库（>4TB），使用 Mv2 系列或 M 系列 VM。对于较小的生产 HANA 数据库（<4TB），使用 SAP 认证的 Edsv5 系列 VM。

原因: M 系列/Mv2 系列已通过 SAP 认证，适用于大型内存工作负载。Edsv5 系列为较小的 HANA 实例提供了经济高效的认证选项。其他系列（D、F、L）未经生产 HANA 数据库认证。

参考↗

为 SAP NetWeaver 应用服务器选择虚拟机 (VM)。

→使用 Edsv5 系列或 Ddsv5 系列 VM。根据 SAP EarlyWatch Alert 报告或 SAP Quick Sizer 中的 SAPS 要求进行大小调整。

原因: E 系列和 D 系列 VM 提供平衡的 CPU 与内存比，适用于 SAP 应用服务器工作负载，并已通过 SAP NetWeaver 认证。

确保 SAP 应用服务器和数据库服务器之间的网络延迟最小。

→将所有相关 VM（应用服务器、ASCS/ERS、数据库）部署在单个邻近放置组 (PPG) 中。

原因: PPG 将 VM 物理上并置在同一数据中心，从而最大限度地缩短网络往返时间，以满足 SAP 对应用和数据库层之间亚毫秒级延迟的要求。

在 SAP HANA 横向扩展部署中，为 /hana/shared 卷提供共享文件系统。

→使用支持 NFS 协议的 Azure NetApp Files (ANF)。

原因: ANF 是 SAP 认证的高性能共享 NFS 存储解决方案，是 HANA 横向扩展配置所必需的。不能将像 Managed Disks 这样的块存储用于此目的。

为 /sapmnt 和全局传输目录 (/usr/sap/trans) 提供高度可用的共享文件系统。

→使用 Azure NetApp Files (NFS) 或 Azure Files Premium (NFS)。对于 Windows，使用 Azure Files Premium (SMB) 或 SOFS 群集。

原因: 这些服务提供托管的、高度可用的文件共享，具有所需的性能和协议支持（Linux 为 NFS，Windows 为 SMB），无需构建和管理单独的文件服务器群集。

为生产环境的 SAP HANA /hana/data 和 /hana/log 卷设计存储，这些卷要求高 IOPS 和亚毫秒级延迟。

→使用 Azure 超级磁盘或高级 SSD v2 托管磁盘。对于 M 系列 VM 上的 /hana/log，带有写入加速器 (Write Accelerator) 的高级 SSD 也是一个有效选项。

原因: 超级磁盘和高级 SSD v2 满足 SAP 为生产 HANA 工作负载定义的严格 IOPS、吞吐量和亚毫秒级延迟 KPI。不支持标准存储层。

为 SAP 工作负载设计安全的网络架构，将生产环境与非生产环境隔离。

→使用中心辐射型拓扑。为每个环境（生产、QA、开发）在专用辐射型 VNet 中部署 SAP 系统。使用网络安全组 (NSG) 在子网之间强制执行严格的流量规则。

原因: 这在 VNet 级别提供了强大的网络隔离，并使用 NSG 实现了细粒度流量控制，遵循了安全最佳实践和 Azure Landing Zone 概念。

使用基础设施即代码 (IaC) 方法在 Azure 上部署 SAP 环境，以实现一致性和自动化。

→使用官方的 SAP on Azure 部署自动化框架，该框架利用 Terraform 和 Ansible。或者，构建自定义的 Bicep 或 Terraform 模块。

原因: 该框架提供了预构建的、经过 SAP 验证的模板，用于部署整个环境（控制平面、工作负载区域、SAP 系统），减少了手动工作并确保遵循最佳实践。

通过互联网将 SAP Fiori 或其他基于 Web 的 SAP 应用程序安全地发布给外部用户。

→使用启用 Web 应用程序防火墙 (WAF) 的 Azure Application Gateway。

原因: 应用网关提供第 7 层负载均衡、SSL 卸载和针对常见 Web 漏洞的 WAF 保护，使其成为基于 Web 的 SAP 应用程序的理想且安全的入口点。

部署超大型 SAP HANA 数据库（>12 TB 内存），其容量超出 Azure VM 限制。

→使用 Azure 大型实例上的 SAP HANA (HLI)。连接需要通过 ExpressRoute 网关将 HLI 戳连接到 Azure VNet 的 ExpressRoute 线路。

原因: HLI 是专用的裸机服务器，为最大的 HANA 工作负载提供所需的巨大内存和性能，这些工作负载超出了当前虚拟化基础架构的规模。

在可用性区域之间部署 SAP 系统，同时仍最大限度地减少每个区域内的延迟。

→为每个可用性区域中的资源创建单独的邻近放置组 (PPG)。将每个 PPG 固定到其各自的区域。

原因: 单个 PPG 不能跨区域。这种方法确保了资源在区域内低延迟的共置，同时仍在区域之间实现了高可用性。

创建并分发标准化、已打补丁和预配置的 VM 映像，以用于跨多个区域的 SAP 部署。

→使用 Azure Image Builder 定义可重复的映像创建过程。使用 Azure Compute Gallery 存储和复制生成的托管映像。

原因: 这提供了一个版本控制的自动化“黄金映像”工厂，与手动配置每个新 VM 相比，可确保一致性并减少部署时间。

为 SAP VM 提供安全的 RDP/SSH 管理访问，而无需将其暴露给公共互联网。

→将 Azure Bastion（标准 SKU）部署到 SAP 虚拟网络中的专用子网。使用 Bastion 通过 Azure 门户或原生客户端连接到 VM。

原因: Bastion 作为安全的托管跳转盒，消除了 SAP VM 上公共 IP 地址的需求或用于管理访问的复杂 VPN 设置，从而减少了攻击面。

使用客户管理的加密密钥加密 SAP 数据卷。

→使用 Azure 磁盘加密和存储在 Azure Key Vault 中的客户管理密钥 (CMK)。这可以与 SAP HANA 原生加密结合使用，以实现纵深防御。

原因: 此配置使客户可以完全控制数据加密密钥，满足密钥生命周期管理的严格合规性和安全要求。

将包含非 HANA 数据库（例如 Oracle、Db2）的本地 SAP 系统迁移到 Azure 上的 SAP HANA。

→使用带有数据库迁移选项 (DMO) 的 SAP Software Update Manager (SUM)。为实现最短停机时间，请使用“带系统移动的 DMO”或近零停机时间 (nZDT) 选项。

原因: DMO 将数据库转换、系统升级和数据迁移组合到一个优化的流程中。它是完成此任务的标准 SAP 工具，与传统的导出/导入方法相比，最大限度地减少了停机时间。

以尽可能最短的停机时间将本地 SAP HANA 系统迁移到 Azure。

→使用 SAP HANA 系统复制 (HSR) 持续将数据复制到目标 Azure VM。在维护窗口期间执行最终的简短切换（接管）。

原因: HSR 将停机窗口缩短到几分钟，因为只需要最终同步和接管。对于大型数据库，备份/恢复或导出/导入方法会导致数小时的停机时间。

当网络带宽不足时，将大量 SAP 数据（>10 TB）从本地传输到 Azure 以进行初始迁移加载。

→使用 Azure Data Box 进行初始大容量数据传输。使用 ExpressRoute 或 VPN 进行后续增量同步。

原因: Data Box 提供了一种比通过有限带宽进行网络传输更快的离线传输方法，显著减少了初始加载时间。

使用简化的引导式体验在 Azure 上部署和管理 SAP S/4HANA 系统。

→使用 Azure Center for SAP Solutions (ACSS)。先决条件包括注册 `Microsoft.Workloads` 提供程序并创建具有所需权限的用户分配的托管标识。

原因: ACSS 通过捆绑最佳实践简化了部署，并在 Azure 门户中提供了一个单一的窗格，用于基本管理（启动/停止、监控）和质量检查。

确定新部署或迁移的 SAP 系统的正确 Azure VM 大小。

→对于新实施，使用 SAP Quick Sizer 工具。对于迁移，分析现有系统的 SAP EarlyWatch Alert 报告以获取当前的 SAPS 和内存使用情况。将这些映射到 SAP 认证的 Azure VM。

原因: 这些 SAP 原生工具提供最准确的工作负载特征（SAPS、内存、I/O），这对于正确选择 Azure 资源并确保性能和可支持性至关重要。

将客户管理的 Azure 环境与通过 RISE with SAP 部署的 SAP S/4HANA 系统集成。

→SAP 在单独的订阅中管理底层 Azure 基础架构。使用 VNet Peering 建立从您的 Azure VNet 到 SAP 管理的 VNet 的连接。

原因: RISE 是 SAP 提供的一项托管服务。VNet Peering 提供了 RISE 环境与 Azure 中其他客户工作负载之间标准、安全和私有的网络集成路径。

在 Azure 中的所有 SAP 部署中强制执行企业标准和安全最佳实践。

→使用 Azure Policy 强制执行规则，例如要求特定的 VM SKU、托管磁盘加密、NSG 关联或强制标记。使用 `DeployIfNotExists` 效果自动安装适用于 SAP 的 VM 扩展。

原因: Azure Policy 提供自动化的大规模治理，确保所有部署都符合要求，而无需依赖手动检查或单独的模板配置。

在上线前验证部署的 Azure 基础架构是否配置正确并符合 SAP 支持要求。

→安装并启用适用于 SAP 的 Azure VM 扩展（增强监控）。从 GitHub 运行 SAP on Azure 质量检查工具。

原因: VM 扩展是 SAP 支持的强制要求。质量检查工具主动根据已知最佳实践和要求列表验证配置（存储、网络、操作系统设置）。

为 Azure VM 上的 SAP HANA 数据库实施应用一致的自动化备份解决方案。

→使用 Azure Backup for SAP HANA，它通过 SAP 认证的 Backint 接口进行集成。配置包含完整/差异备份和频繁日志备份的策略以实现时间点恢复。

原因: Azure Backup 提供了一个原生、集成且经过认证的解决方案，可自动执行备份计划、保留和管理，无需自定义脚本或单独的备份基础架构。

为在 Azure 上运行的 SAP 环境实施全面、集中的监控。

→部署 Azure Monitor for SAP Solutions。为 SAP HANA、NetWeaver、操作系统 (Linux) 和高可用性集群遥测配置提供程序。

原因: 这是一项专为 SAP 设计的原生 Azure 服务。它提供丰富、SAP 感知的遥测和可视化，将整个 SAP 堆栈从基础架构到应用程序的监控集中化。

以最短停机时间将操作系统或 SAP 内核补丁应用于高可用性 SAP 集群。

→使用滚动更新方法。将辅助节点置于维护模式，打补丁，然后重新启动。执行受控集群故障转移，使打补丁的节点成为主节点。最后，对原主节点打补丁。

原因: 这种滚动方法确保在整个维护过程中 SAP 服务在一个节点上保持可用，最大限度地减少业务服务中断。

自动化创建副本或刷新 SAP 系统（例如，从 PRD 刷新 QAS 系统）的过程。

→使用带有 Azure 连接器的 SAP Landscape Management (LaMa)。

原因: LaMa 协调端到端流程，包括 Azure 基础架构任务（VM 停止/启动、磁盘快照）和 SAP 特定的复制后自动化 (BDLS)，显著减少了手动工作。

在不影响生产环境的情况下验证 SAP 灾难恢复计划。

→使用 Azure Site Recovery 的“测试故障转移”功能，该功能会在隔离的 VNet 中启动复制的 VM。对于 HSR，使用基于快照的恢复到隔离系统或专用的第三方复制目标。

原因: 在隔离网络中进行测试可防止 IP 冲突以及与生产系统或正在进行的复制的任何干扰，从而可以安全彻底地验证 DR 运行手册。

规划 Azure 上不断增长的 SAP 系统的未来资源需求（CPU、内存、存储）。

→使用 Azure Monitor 指标和 Log Analytics 分析历史使用趋势。使用这些数据进行预测。对于存储，利用在线动态调整 Azure 托管磁盘大小的能力。

原因: 基于历史数据的主动容量管理可防止性能下降，并允许即时预配，与大量前期过度预配相比，优化了成本。

最大程度地降低运行完整 SAP 环境的 Azure 成本。

→对于生产工作负载，使用 1 年或 3 年的 Azure 预留实例。对于非生产系统，通过 Azure Automation 实施自动化启动/停止计划。对于符合条件的许可证，使用 Azure 混合权益。

原因: 预留实例为可预测的 24/7 工作负载提供大幅折扣。自动关机消除了非生产环境在空闲期间的计算成本。这种组合解决了两个主要的成本驱动因素。

跟踪并将 SAP 工作负载的 Azure 成本分配给特定的业务部门、项目或 SAP 系统 (SID)。

→对所有 Azure 资源实施强制标记策略。使用 `CostCenter`、`Environment`、`SAP-SID` 和 `BusinessOwner` 等标记。使用 Azure 成本管理分析成本。

原因: 标记是 Azure 对资源进行分类的原生机制。一致的标记可以实现详细的成本分析和费用分摊，提供重要的财务可见性。

诊断 Azure 中 SAP VM 之间间歇性网络连接或延迟问题。

→使用 Azure Network Watcher 工具，特别是连接监视器 (Connection Monitor) 来测试路径和延迟，以及 NSG 流日志 (NSG Flow Logs) 来分析和识别被阻止的流量。

原因: Network Watcher 提供主动和被动工具来查明 Azure 平台级别的网络问题，这些问题通常很难仅从客户操作系统内部诊断。

自动化 SAP VM 的操作系统补丁管理，同时确保应用程序优雅地关闭。

→使用带有前置/后置脚本的 Azure Update Manager。前置脚本停止 SAP 应用程序和数据库，后置脚本在补丁完成后重新启动它们。

原因: 这结合了 Azure 补丁管理的自动化与 SAP 所需的应用程序感知，防止了因修补正在运行的系统而可能发生的数据不一致。

在 SUSE/RHEL Linux VM 上为 SAP Central Services (ASCS/ERS) 或 SAP HANA 实施高可用性。

→配置 Pacemaker 集群。使用 `fence_azure_arm` 代理进行 STONITH（隔离），以防止脑裂场景，并通过托管标识进行身份验证。

原因: Pacemaker 是 Linux 上 SAP 支持的集群解决方案。`fence_azure_arm` 是 Azure 原生机制，通过 Azure API 可靠地隔离故障节点，这对于稳定集群是强制性的。

在 Windows Server VM 上为 SAP Central Services (ASCS/ERS) 实施高可用性。

→配置 Windows Server 故障转移群集 (WSFC)。对于群集共享存储，使用 Azure 共享磁盘或第三方复制解决方案，如 SIOS DataKeeper。

原因: WSFC 是 Windows 集群的标准。Azure 共享磁盘提供原生共享块存储，而 SIOS 创建“无共享”集群，两者都取代了云中传统 SAN 的需求。

为 SAP HANA 设计高可用性 (HA) 和灾难恢复 (DR) 策略。

→对于 HA（区域内），在可用性区域中部署 VM 并使用同步 (SYNC) SAP HANA 系统复制 (HSR)。对于 DR（跨区域），使用异步 (ASYNC) HSR。

原因: 同步复制提供零 RPO 但需要低延迟（<2ms），使其成为跨区域 HA 的理想选择。异步复制可以容忍更高的跨区域延迟，使其成为 DR 的选择。

配置 Azure 负载均衡器以管理 SAP HA 集群（ASCS/ERS 或 HANA）的虚拟 IP 地址。

→使用 Azure 标准负载均衡器。在负载均衡规则上启用浮动 IP（Direct Server Return）。在集群监控的特定端口上配置运行状况探测（例如，ASCS 为 620xx）。

原因: 区域冗余需要标准 SKU。浮动 IP 对于集群的虚拟 IP 正常运行是必需的。特定的运行状况探测确保流量仅发送到活动节点。

了解 Enqueue Replication Server (ERS) 在 SAP ASCS 高可用性集群中的作用。

→ERS 实例维护活动 ASCS 实例的 SAP 锁定表的副本。

原因: 如果 ASCS 实例发生故障转移，新启动的 ASCS 实例会从 ERS 中检索复制的锁定表。这保留了事务锁定，并允许用户不间断地继续工作。

为多层 SAP 环境设计一个完整的灾难恢复解决方案。

→数据库层使用原生数据库复制（例如，HANA 的异步 HSR）。应用层（ASCS/ERS 和应用服务器）使用 Azure Site Recovery (ASR)。

原因: 这种“最佳组合”方法通过原生复制确保数据库的应用一致性，而 ASR 提供了一种经济高效且自动化的方法来复制和故障转移应用服务器 VM。

为在 Azure VM 中运行 Microsoft SQL Server 的 SAP 数据库实施高可用性。

→使用 SQL Server Always On 可用性组，通常在区域内使用同步提交模式实现 HA，并结合 WSFC。

原因: Always On AG 是 SQL Server 推荐且完全支持的 HA/DR 解决方案，提供数据库级复制和自动故障转移功能。

为双节点 Pacemaker 集群实施 SBD (STONITH Block Device) 作为仲裁机制。

→配置一个小型 Azure 共享磁盘并将其附加到两个集群节点。或者，在第三个 VM 上设置一个专用的 iSCSI 目标服务器。

原因: 虽然 `fence_azure_arm` 是主要的隔离代理，但 SBD 提供了一个额外的见证/仲裁机制来防止脑裂，尤其是在没有第三个投票节点的集群中。