此指南演示了在 Azure 上支持灾难恢复 (DR) 的高可用性环境中运行 S/4HANA 和 Suite on HANA 的一套行之有效的做法。 Fiori 信息仅适用于 S/4HANA 应用程序。
体系结构
下载此体系结构的 Visio 文件。
注意
部署此体系结构需要获取 SAP 产品和其他非 Microsoft 技术的相应许可。
本指南描述了同一生产系统。 此体系结构是使用可根据组织需求更改的虚拟机 (VM) 大小来部署的。 若要满足业务需求，可以将此配置减少到单个 VM。
此指南中，网络布局被大大简化，以展示体系结构原理。 其目的并非描述完整的企业网络。
该体系结构使用以下组件。 某些共享服务是可选的。
Azure 虚拟网络。 虚拟网络服务在 Azure 资源之间建立安全连接。 在此体系结构中，虚拟网络将通过中心-分支拓扑的中心内部署的网关连接到本地环境。 分支是用于 SAP 应用程序和数据库层的虚拟网络。
虚拟网络对等互连。 此体系结构使用多个对等互连连在一起的虚拟网络。 此拓扑为部署在 Azure 上的服务提供网络分段和隔离。 对等互连通过 Microsoft 骨干网透明地连接网络，并且在单个区域内实现时不会对性能产生负面影响。 单独的子网用于每个层应用程序 (SAP NetWeaver)、数据库和共享服务，例如 Jumpbox 和Windows Server Active Directory。
VM。 此体系结构对应用层和数据库层使用运行 Linux 的虚拟机。这些层按以下方式划分：
应用程序层。 此架构层包括 Fiori 前端服务器池、SAP Web 调度程序池、应用程序服务器池和 SAP Central Services 群集。 要在 Linux VM 中运行的 Azure 上实现 Central Services 的高可用性，需要高可用性网络文件共享服务，例如 Azure 存储文件中的 NFS 文件共享、Azure NetApp 文件、群集网络文件系统 (NFS) 服务器或 适用于 Linux 的 SIOS 保护套件。 要在 Red Hat Enterprise Linux (RHEL) 上为 Central Services 群集设置高可用性文件共享，可在运行 RHEL 的 Azure VM 上配置 GlusterFS。 在 SUSE Linux Enterprise Server (SLES) 15 SP1 和更高版本或 SLES for SAP Applications 上，可以在 Pacemaker 群集上使用 Azure 共享磁盘来实现高可用性。
SAP HANA。 数据库层使用群集中的两个或更多 Linux VM 在纵向扩展部署中实现高可用性。 HANA 系统复制 (HSR) 用于在主要和辅助 HANA 系统之间复制内容。 Linux 群集用于检测系统故障，以及方便自动故障转移。 必须使用基于存储或基于云的隔离机制来确保发生故障的系统处于隔离状态或关闭状态，以避免出现群集分区情况。 在 HANA 横向扩展部署中，可以使用以下选项之一实现数据库高可用性：
- 在没有 Linux 群集组件的情况下使用 Azure NetApp 文件配置 HANA 备用节点。
- 使用 Azure 高级存储在没有备用节点的情况下横向扩展。 使用 Linux 群集进行故障转移。
Azure Bastion。通过该服务，你可以使用浏览器和 Azure 门户或通过本地计算机上已安装的本机 SSH 或 RDP 客户端连接到虚拟机。 如果仅使用 RDP 和 SSH 来完成管理任务，Azure Bastion 是一个很好的解决方案。 如果使用其他管理工具，如 SQL Server Management Studio 或 SAP 前端，请使用传统的自部署跳转盒。
专用 DNS 服务。Azure 专用 DNS 为虚拟网络提供可靠且安全的 DNS 服务。 Azure 专用 DNS 可管理并解析虚拟网络中的域名，使你无需配置自定义 DNS 解决方案。
负载均衡器。 若要将流量分发到 SAP 应用程序层子网中的 VM 以实现高可用性，建议使用 Azure 标准负载均衡器。 请注意，标准负载均衡器会默认提供一个安全层。 标准负载均衡器后面的 VM 没有出站 Internet 连接。 要在 VM 中启用出站 Internet，你需要更新标准负载均衡器配置。 此外，还可以使用 Azure NAT 网关获取出站连接。 对于 SAP 基于 Web 的应用程序高可用性，请使用内置的 SAP Web Dispatcher 或其他商业可用的负载均衡器。 根据你的选择：
- 流量类型，例如 HTTP 或 SAP GUI。
- 所需的网络服务，例如安全套接字层 (SSL) 终止。
标准负载均衡器支持多个前端虚拟 IP。 此支持非常适合包括以下组件的群集实现：
- 高级商业应用程序编程 (ABAP) SAP Central Service (ASCS)
- 排队复制服务器 (ERS)
这两种服务可以共享负载均衡器来简化解决方案。
标准负载均衡器还支持多系统标识符（多 SID）SAP 群集。 即，SLES 或 RHEL 上的多个 SAP 系统可以共享通用的高可用性基础结构，以减少成本。 建议评估成本节省，避免在一个群集中放置过多系统。 Azure 支持每个群集不超过 5 个 SID。
应用程序网关。 Azure 应用程序网关是一种 Web 流量负载均衡器，可用于管理 Web 应用的流量。 传统负载均衡器在传输层（OSI 第 4 层 - TCP 和 UDP）运行。 它们根据源 IP 地址和端口将流量路由到目标 IP 地址和端口。 使用应用程序网关时，可以根据 HTTP 请求的其他属性（例如 URI 路径或主机标头）进行路由决策。 这种类型的路由称为应用程序层（OSI 层 7）负载均衡。 S/4HANA 通过 Fiori 提供 Web 应用程序服务。 可以使用应用程序网关对由 Web 应用组成的 Fiori 前端进行负载均衡。
网关。 网关的作用是连接不同的网络，以及将本地网络扩展到 Azure 虚拟网络。 建议使用 Azure ExpressRoute 这一 Azure 服务来创建不必经由公共 Internet 的专用连接，但也可以使用站点到站点连接。 为了减少延迟，可使用 ExpressRoute Global Reach 和 ExpressRoute FastPath 连接选项，本文稍后部分将进行介绍。
区域冗余网关。 可以跨区域部署 ExpressRoute 或虚拟专用网 (VPN) 网关，以防止区域故障。 此体系结构使用区域冗余虚拟网络网关来实现复原能力，而不是基于同一可用性区域的区域部署。
邻近放置组。 此逻辑组对可用性集或虚拟机规模集中部署的 VM 施加约束。 邻近放置组倾向于归置，使 VM 位于同一数据中心，可最大程度地减少应用程序延迟。
注意
通过 SAP 应用程序实现最佳网络延迟的配置选项一文中包含最新的配置策略。 请阅读此文章，尤其是在要部署具有最佳网络延迟的 SAP 系统时。
网络安全组。 若要限制虚拟网络中的传入、传出和子网内部流量，可以创建网络安全组。
应用程序安全组。 要基于工作负载并以应用程序为中心定义细致缜密的网络安全策略，请使用应用程序安全组而不是显式 IP 地址。 可以按名称对 VM 进行分组，并通过筛选来自网络可信任段的流量来保护应用程序的安全。
Azure 存储。 存储以虚拟硬盘的形式为VM 提供数据持久性。 建议使用 Azure 托管磁盘。
建议
此体系结构描述一个小型的生产级部署。 根据业务需求，部署将有所不同，因此请考虑将这些建议作为起点。
VM
在应用程序服务器池和群集中，根据要求调整 VM 数目。 有关在 VM 上运行 SAP NetWeaver 的详细信息，请参阅 Azure 虚拟机规划和实施指南。 本指南也适用于 SAP S/4HANA 部署。
有关 SAP 支持的 Azure VM 类型和吞吐量指标 (SAPS) 的详细信息，请参阅 SAP 说明 1928533。 要访问 SAP 说明，需要具有 SAP 服务市场帐户。 有关 HANA 数据库的认证 Azure VM 列表，请参阅 SAP 认证和支持的 SAP HANA 硬件目录。
SAP Web 调度程序
Web 调度程序组件用来实现 SAP 应用程序服务器之间 SAP 流量的负载均衡。 为了实现 SAP Web Dispatcher 的高可用性，Azure 负载均衡器实现了故障转移群集或并行 Web Dispatcher 设置。 对于面向 Internet 的通信，外围网络中的独立解决方案将是满足安全问题的推荐体系结构。 ASCS 上的嵌入式 Web 调度程序是一种特殊选项。 如果使用此选项，请考虑根据 ASCS 上的额外工作负荷来调整大小。
Fiori 前端服务器 (FES)
此体系结构满足许多要求，并假定使用嵌入式 Fiori FES 模型。 所有技术组件都安装在 S/4 系统本身上，这意味着每个 S/4 系统都有其自己的 Fiori 启动板。 此部署模型的高可用性设置为 S/4 系统的设置，不需要其他群集组件或 VM。 因此，体系结构示意图不显示 FES 组件。
请参阅 SAP Fiori 部署选项和系统布局建议中的说明，了解主要的部署选项（嵌入式或中心型），具体使用哪种选项取决于应用场景。 为了实现简单和高性能，Fiori 技术组件和 S/4 应用程序之间的软件版本是紧密耦合的。 此设置进行了仅适合少数用例的中心部署。
如果使用 FES 中心型部署，FES 则是经典 SAP NetWeaver ABAP 堆栈的附加组件。 提供高可用性的原理与通过群集或多主机功能保护三层 ABAP 应用程序堆栈的原理相同，即设置备用服务器数据库层、设置通过高可用性 NFS 实现共享存储的群集 ASCS 层以及设置至少两个应用程序服务器。 流量通过一对可群集或并行的 Web Dispatcher 实例进行负载均衡。 对于面向 Internet 的 Fiori 应用，我们建议在外围网络中部署 FES 中心。 将应用程序网关上的 Azure Web 应用程序防火墙用作转移威胁的关键组件。 将 Microsoft Entra ID 与 SAML 配合使用，以便进行 SAP Fiori 用户身份验证和 SSO。
有关面向 Internet 的入站/出站设计示例，请参阅 Azure 上 SAP 的入站和出站 Internet 连接。
应用程序服务器池
要管理 ABAP 应用程序服务器的登录组，通常使用 SMLG 事务来均衡登录用户的负载，例如对批处理服务器组使用 SM61、对远程函数调用 (RFC) 组使用 RZ12 等等。 这些事务使用 Central Services 消息服务器内的负载均衡功能，在 SAP GUI 和 RFC 流量的 SAP 应用程序服务器池之间分发传入会话或工作负载。
SAP Central Services 群集
当 Azure 单实例 VM 可用性服务级别协议 (SLA) 满足要求时，可以将 Central Services 部署到单个 VM。 但是，该 VM 会成为 SAP 环境中的潜在单一故障点 (SPOF)。 为实现高可用性 Central Services 部署，使用 Azure 文件存储上的 NFS 或 Azure NetApp 文件服务和 Central Services 群集。
另一种方法是使用 Azure 共享磁盘实现高可用性。 在 SLES 15 SP1 及更高版本或 SLES for SAP Applications 上，可以使用适用于 Linux 的 Azure 共享磁盘设置 Pacemaker 群集。
或者，可使用 NFS 文件共享提供 Linux 群集共享存储。
在 Azure 部署中，应用程序服务器通过 Central Services 或 ERS 服务的虚拟主机名连接到高可用性 Central Services。 这些主机名分配给负载均衡器的群集前端 IP 配置。 负载均衡器支持多个前端 IP，因此 Central Services 和 ERS 虚拟 IP (VIP) 可同时配置到一个负载均衡器。
现在普遍支持使用 Linux 群集在 Azure 上进行 ASCS 多 SID 安装。 在多个 SAP 系统中共享可用性群集可简化 SAP 环境。
网络
此体系结构使用中心辐射型拓扑，其中，中心虚拟网络充当与本地网络建立连接的中心点。 分支是与中心对等互连的虚拟网络。 可以使用分支来隔离工作负荷。 流量通过网关连接在本地数据中心与中心之间流动。
网络接口卡 (NIC)
传统的本地 SAP 部署为每个虚拟机实现多个 NIC，以便将管理流量与业务流量分开。 在 Azure 上，虚拟网络是软件定义的网络，它通过同一网络结构发送所有流量。 因此，没有必要出于性能考虑使用多个 NIC。 但是，如果组织需要分离流量，则可为每个 VM 部署多个 NIC，将每个 NIC 连接到不同的子网，然后使用网络安全组强制实施不同的访问控制策略。
Azure NIC 支持多个 IP。 此支持符合 SAP 推荐的使用虚拟主机名进行安装的做法，如 SAP 说明 962955 中所述。要访问 SAP 说明，需要具有 SAP Service Marketplace 帐户。
子网和网络安全组
此体系结构将虚拟网络地址空间划分为子网。 你可以将每个子网与定义子网访问策略的网络安全组相关联。 将应用程序服务器放在单独的子网上。 这样一来，就可以管理子网安全策略而不是单个服务器，从而更轻松地保护服务器。
网络安全组与子网关联时，适用于子网中的所有服务器，并提供对服务器的精细控制。 使用 Azure 门户、PowerShell 或 Azure CLI 设置网络安全组。
ExpressRoute Global Reach
如果网络环境中包含两个或更多 ExpressRoute 线路，ExpressRoute Global Reach 可帮助减少网络跃点和降低延迟。 此技术是在两个或更多 ExpressRoute 线路之间设置的边界网关协议 BGP 路由对等互连，用于桥接两个 ExpressRoute 路由域。 当网络流量遍历多个 ExpressRoute 连接时，Global Reach 可降低延迟。 它目前仅适用于 ExpressRoute 线路上的专用对等互连。
目前，Global Reach 中没有可以更改的网络访问控制列表或其他属性。 因此，给定 ExpressRoute 线路（从本地和 Azure）获知的所有路由都通过线路对等互连播发到其他 ExpressRoute 线路。 建议在本地建立网络流量筛选，以限制对资源的访问。
ExpressRoute FastPath
FastPath 在 Azure 网络的入口点实现 Microsoft Edge 交换。 FastPath 可减少大多数数据包的网络跃点。 结果，FastPath 可降低网络延迟，提高应用程序性能，并且与 Azure 的新 ExpressRoute 连接默认配置均使用此选项。
对于现有 ExpressRoute 线路，请联系 Azure 支持人员激活 FastPath。
FastPath 不支持虚拟网络对等互连。 如果有其他虚拟网络与连接到 ExpressRoute 的虚拟网络对等互连，则从本地网络发往其他分支虚拟网络的网络流量将发送到虚拟网络网关。 解决方法是将所有虚拟网络直接连接到 ExpressRoute 线路。
负载均衡器
SAP Web 调度程序处理对发往 SAP 应用程序服务器池的 HTTP(S) 流量的负载均衡。 此软件负载均衡器提供了应用程序层服务（在 ISO 网络模型中称为第 7 层），这些服务能够实现 SSL 终止和其他卸载功能。
负载均衡器是一种网络传输层服务（第 4 层），它使用来自数据流的 5 元组哈希来均衡流量。 该哈希基于源 IP、源端口、目标 IP、目标端口、和协议类型。 Azure 负载均衡器用于在群集设置中将流量定向到主服务实例或正常节点（如果有故障）。 无论哪种 SAP 方案，均建议使用 Azure 标准负载均衡器。 务必注意，标准负载均衡器在默认情况下是安全的，并且标准负载均衡器后面的任何 VM 都不会具有出站 Internet 连接。 要在 VM 中启用出站 Internet，必须调整标准负载均衡器配置。
对于通过 DIAG 协议或 RFC 连接 SAP 服务器的 SAP GUI 客户端发出的流量，Central Services 消息服务器会通过 SAP 应用程序服务器登录组进行负载均衡。 因此，不需要其他负载均衡器。
存储
一些客户对应用程序服务器使用标准存储。 由于标准托管磁盘不受支持（如 SAP 说明 1928533 中所述），因此建议在所有情况下使用高级 Azure 托管磁盘或 Azure NetApp 文件。 最新更新的 SAP 说明 2015553 表明，对于几个特定用例，不能使用标准 HDD 存储和标准 SSD 存储。
由于应用程序服务器不托管任何业务数据，因此你可以借助较小的 P4 和 P6 高级磁盘来帮助管理成本。 若要了解存储类型如何影响 VM 可用性 SLA，请参阅适用于虚拟机的 SLA。 对于高可用性方案，Azure 高级 SSD 和 Azure 超级磁盘存储上提供了 Azure 共享磁盘 功能。 有关详细信息，请参阅 Azure 托管磁盘。
可以将 Azure 共享磁盘与 Windows Server、SLES 15 SP 1 及更高版本或 SLES for SAP 配合使用。 在 Linux 群集中使用 Azure 共享磁盘时，Azure 共享磁盘充当 STONITH 块设备 (SBD)。 它在群集网络分区情况下提供仲裁投票。 此共享磁盘没有文件系统，并且不支持从多个群集成员 VM 同时写入。
Azure NetApp 文件内置有 NFS 和 SMB 的文件共享功能。
对于 NFS 共享方案，Azure NetApp 文件为 NFS 共享提供高可用性，可用于 /hana/shared、/hana/data 和 /hana/log 卷。 有关可用性保证，请参阅 Azure NetApp 文件的 SLA。 如果将基于 Azure NetApp 文件的 NFS 共享用于 /hana/data 和 /hana/log 卷，则需要使用 NFS v4.1 协议。 /hana/shared 卷支持 NFS v3 协议。
对于备份数据存储，建议使用 Azure 冷访问层和存档访问层。 这些存储层的性价比较高，适合用于存储不经常访问的长久留存数据。 还可考虑使用 Azure NetApp 文件标准层作为备份目标或 Azure NetApp 文件备份选项。 对于托管磁盘，建议的备份数据层是 Azure 冷访问层或存档访问层。
超级磁盘存储和 Azure NetApp 文件超级性能层都极大地减少了磁盘延迟，并有利于性能关键型应用程序和 SAP 数据库服务器。
Azure 高级 SSD v2 专为 SAP 等性能关键型工作负载而设计。 有关此存储解决方案的优势和当前限制的信息，请参阅部署高级 SSD v2。
性能注意事项
SAP 应用程序服务器经常与数据库服务器通信。 对于任何数据库平台上运行的性能关键型应用程序（包括 SAP HANA），如果你使用的是高级 SSD v1，请为日志卷启用写入加速器。 这样做可以减少日志写入延迟。 高级 SSD v2 不使用写入加速器。 写入加速器可用于 M 系列 VM。
若要优化服务器间的通信，请使用加速网络。 大多数具有两个或更多 vCPU 的常规用途和计算优化 VM 实例大小都支持加速网络。 在支持超线程的实例上，具有四个或更多 vCPU 的 VM 实例支持加速网络。
有关 SAP HANA 性能要求的详细信息，请参阅 SAP 说明 1943937 - 硬件配置检查工具。 要访问 SAP 说明，需要具有 SAP 服务市场帐户。
若要实现较高的 IOPS 和磁盘带宽吞吐量，可向存储布局应用优化存储卷性能时采用的常见做法。 例如，如果将多个磁盘合并在一起以创建条带化磁盘卷，可以提高 I/O 性能。 针对不经常更改的存储内容启用读取缓存可增强数据检索的速度。 有关运行 SAP HANA 时各种 VM 大小的存储配置的建议，请参阅 SAP HANA Azure 虚拟机存储配置。
Azure 高级 SSD v2 专为 SAP 等性能关键型工作负载而设计。 请参阅 Azure 托管磁盘类型，了解其优点和限制以及最佳使用方案。
超级磁盘存储是新一代存储，可满足密集型 IOPS 和应用程序（如 SAP HANA）的传输带宽需求。 可动态更改超磁盘的性能并独立配置 IOPS 和 MB/s 等指标，而无需重新启动 VM。 当超级磁盘存储可用时，建议使用超级磁盘存储，而不是写入加速器。
某些 SAP 应用程序需要频繁与数据库通信。 由于距离，应用程序和数据库层之间的网络延迟会对应用程序性能产生不利影响。 Azure 邻近放置组为可用性集中部署的 VM 设置放置约束。 在组的逻辑结构中，场地租用和性能要比可扩展性、可用性和成本更重要。 邻近放置组可以极大地改善大多数 SAP 应用程序的用户体验。
任何 SAP 应用程序堆栈都不支持在应用程序层和数据库层之间放置网络虚拟设备 (NVA)。 NVA 需要大量的时间来处理数据包。 因此，它极大降低应用程序性能。
还建议在为资源部署可用性区域时考虑性能，可用性区域有助于增强服务可用性，如本文稍后部分所述。 请考虑在目标区域的所有区域之间创建明确的网络延迟配置文件。 此方法有助于确定资源放置以实现区域之间的最小延迟。 要创建此配置文件，请在每个区域中部署小型 VM 来运行测试。 建议的测试工具包括 PsPing 和 Iperf。 测试后，请删除这些 VM。 有关可以改用的公共域网络延迟测试工具，请参阅可用性区域延迟测试。
Azure NetApp 文件具有独特的性能功能，支持实时优化以满足最苛刻的 SAP 环境的需求。 有关使用 Azure NetApp 文件时需牢记的性能注意事项，请参阅调整 Azure NetApp 文件上的 HANA 数据库的大小。
可伸缩性注意事项
在 SAP 应用层，Azure 提供多种 VM 大小供纵向扩展和横向扩展。有关详尽列表，请参阅 SAP 说明 1928533 中的“Azure 上的 SAP 应用程序：支持的产品和 Azure VM 类型”。 要访问 SAP 说明，需要具有 SAP 服务市场帐户。 随着更多 VM 类型不断得以认证，你可以在同一个云部署中纵向扩展或缩减。
在数据库层，此体系结构在 Azure 虚拟机上运行 SAP HANA S/4 应用程序，这些 VM 可在一个实例中纵向扩展至 24 TB。 如果工作负载超过最大 VM 大小，可使用多节点配置获得高达 96 TB (4 x 24) 的大小，用于联机事务处理 (OLTP) 应用程序。 有关详细信息，请参阅认证和支持的 SAP HANA 硬件目录。
可用性注意事项
资源冗余是高可用性基础结构解决方案中的常见话题。 有关各种存储类型的单实例 VM 可用性 SLA，请参阅虚拟机的 SLA。 若要提高 Azure 上的服务可用性，请使用具有灵活业务流程、可用性区域或可用性集的虚拟机规模集来部署 VM 资源。
在这种 SAP 应用程序分布式安装中，将会复制基本安装以实现高可用性。 对于体系结构的每个层，高可用性设计各不相同。
部署方法
在 Azure 上，SAP 工作负载部署可以是地区性部署，也可以是区域性部署，具体取决于 SAP 应用程序的可用性和复原能力要求。 Azure 提供了不同的部署选项，例如具有灵活业务流程 (FD=1)、可用性区域和可用性集的虚拟机规模集，以增强资源的可用性。 若要全面了解可用的部署选项及其在不同 Azure 地区（包括跨区域、单个区域内或在不含区域的地区中）的适用性，请参阅 SAP NetWeaver 的高可用性体系结构和方案。
应用程序服务器层中的 Web Dispatcher
可以使用冗余 Web Dispatcher 实例实现高可用性。 有关详细信息，请参阅 SAP 文档中的 SAP Web Dispatcher。 可用性级别取决于 Web Dispatcher 后面的应用程序的大小。 在具有少量可伸缩性问题的小型部署中，可以将 ASCS VM 与 Web Dispatcher 放在一起。 这样，就可以节省单独的 OS 维护费用，同时获得高可用性。
应用程序服务器层中的 Central Services
若要实现 Azure Linux VM 上 Central Services 的高可用性，可使用所选 Linux 分发版的相应高可用性扩展。 通常，使用 SUSE DRBD 或 Red Hat GlusterFS 将共享文件系统放置在高可用性 NFS 存储上。 若要提供高可用性 NFS 且无需 NFS 群集，也可以使用其他经济高效或可靠的解决方案（如 Azure 文件存储上的 NFS 或 Azure NetApp 文件）。 另请注意，Azure NetApp 文件共享可托管 SAP HANA 数据和日志文件。 此设置支持具有备用节点的 HANA 横向扩展部署模型，而 Azure 文件存储上的 NFS 非常适合高可用性非数据库文件共享。
Azure 文件存储上的 NFS 现在支持 SLES 和 RHEL 的高可用性文件共享。 此解决方案适用于高可用性文件共享，例如 SAP 安装中 /sapmnt 和 /saptrans 的高可用性文件共享。
Azure NetApp 文件支持 ASCS on SUSE 的高可用性。 有关 ASCS on RHEL 高可用性的详细信息，请参阅适用于 Linux 的 SIOS 保护套件。
改进后的 Azure 隔离代理可用于 SUSE 和 Red Hat，与以前版本的代理相比，该代理提供的服务故障转移速度更快。
另一种方法是使用 Azure 共享磁盘实现高可用性。 在 SLES 15 SP 1 及更高版本或 SLES for SAP 上，可以使用 Azure 共享磁盘来设置 Pacemaker 群集以实现高可用性。
通过 Azure 标准负载均衡器，可直接启用高可用性端口，而无需为许多 SAP 端口配置负载均衡规则。 通常，如果在设置负载均衡器时启用直接服务器返回 (DSR) 功能，则对客户端查询的服务器响应可以绕过负载均衡器。 此功能也称为浮动 IP。 负载均衡器可以位于本地或 Azure 上。 这种直接连接避免了负载均衡器成为数据传输路径上的瓶颈。 对于 ASCS 和 HANA DB 群集，建议启用 DSR。 如果后端池中的 VM 需要公共出站连接，则需要更多配置。
对于通过 DIAG 协议或 RFC 连接 SAP 服务器的 SAP GUI 客户端发出的流量，Central Services 消息服务器会使用 SAP 应用程序服务器登录组进行负载均衡。 因此，不需要其他负载均衡器。
应用程序服务器层中的应用程序服务器
可通过对应用程序服务器池中的流量进行负载均衡来实现高可用性。
ASCS 层
就像应用程序服务器层一样，为 Linux 部署的常见 HANA 高可用性解决方案是 Pacemaker。
数据库层
本指南中的此参考体系结构描述包括两个 Azure VM 的高可用性 SAP HANA 数据库系统。 数据库层的本机系统复制功能在复制的节点之间提供手动或自动故障转移：
- 若要手动故障转移，请部署多个 HANA 实例，并使用 HSR。
- 若要自动故障转移，请使用适用于 Linux 分发版的 HSR 和 Linux 高可用性扩展 (HAE)。 Linux HAE 为 HANA 资源提供群集服务、检测故障事件，并协调将出错服务故障转移到正常节点的过程。
跨可用性区域部署 VM
可用性区域有助于增强服务可用性。 区域是指特定 Azure 地区中的物理分隔位置。 它们提高了工作负载可用性，可保护应用程序服务和 VM 免受数据中心中断的影响。 单个区域中的 VM 被视为位于单个更新或容错域中。 选择区域部署后，同一区域中的 VM 会以最佳方式分发到容错域和升级域。
在支持此功能的 Azure 区域中，至少有三个区域可用。 但是，无法保证这些区域中的数据中心之间的最大距离。 要跨区域部署多层 SAP 系统，必须知道区域中和跨目标区域的网络延迟，以及部署的应用程序对网络延迟的敏感程度。
当你决定跨可用性区域部署资源时，请考虑以下注意事项：
- 同一个区域中虚拟机之间的延迟
- 所选区域中 VM 之间的延迟
- 所选区域中相同 Azure 服务（VM 类型）的可用性
注意
不建议将可用性区域用于灾难恢复。 灾难恢复站点应距离主站点至少 100 英里，以防发生自然灾害。 数据中心之间的距离没有确定性。
主动/被动部署示例
在此示例部署中，主动/被动状态是指区域中的应用程序服务状态。 在应用程序层中，SAP 系统的所有四个活动应用程序服务器都位于区域 1 中。 另一组四台被动应用程序服务器是在区域 2 中构建的，还处于关闭状态。 仅当需要时才会激活。
Central Services 和数据库的双节点群集跨两个区域延伸。 如果区域 1 失败，Central Services 和数据库服务将在区域 2 中运行。 区域 2 中的被动应用程序服务器已激活。 由于此 SAP 系统的所有组件都并置在同一区域中，因此网络延迟最小。
主动/主动部署示例
在主动/主动部署中，有两组应用程序服务器是跨两个区域构建的。 在每个区域中，每组服务器中有两台应用程序服务器处于非活动（关闭）状态。 因此，在正常操作中，这两个区域中都有活动应用程序服务器。
ASCS 和数据库服务在区域 1 中运行。 由于区域之间的物理距离，区域 2 中的应用程序服务器在连接到 ASCS 和数据库服务时网络延迟可能延长。
如果区域 1 脱机，ASCS 和数据库服务将故障转移到区域 2。 可将休眠的应用程序服务器联机，以提供完整容量来处理应用程序。
DR 注意事项
SAP 应用程序堆栈中的每个层都使用不同的方法来提供 DR 保护。 有关 DR 策略和实施详细信息，请参阅 SAP 工作负载的灾难恢复概述和基础结构指南和 SAP 应用程序的灾难恢复指南。
注意
如果区域灾难导致一个区域中的许多 Azure 客户发生大规模故障转移事件，则无法保证目标区域的资源容量。 与所有 Azure 服务一样，Site Recovery 会继续增添特性和功能。 有关 Azure 之间的复制的最新信息，请参阅支持矩阵。
成本注意事项
使用 Azure 定价计算器估算成本。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。
VM
此体系结构将运行 Linux 的虚拟机用于管理层、SAP 应用程序层和数据库层。
通常 VM 有多种支付选项：
对于没有可预测的完成时间或资源消耗的工作负载，请考虑即用即付选项。
如果可以承诺在一年或三年内使用 VM，请考虑使用 Azure 预留。 VM 预留可以显著降低成本。 你可能只需支付即用即付服务成本的 72%。
使用 Azure 现成 VM 运行可能中断且不需要在预定的时间范围或 SLA 内完成的工作负载。 Azure 会在有可用容量时部署现成 VM，在需要恢复容量时将其逐出。 与现成 VM 关联的成本低于其他 VM 的成本。 请考虑为以下工作负载使用现成 VM：
- 高性能计算方案、批处理作业或视觉渲染应用程序
- 测试环境，包括持续集成和持续交付工作负载
- 大规模无状态应用程序
Azure 虚拟机预留实例可以通过将 Azure 虚拟机预留实例费率与即用即付订阅相结合来降低总拥有成本，以便可以跨可预测和可变工作负载管理成本。 有关此产品/服务的详细信息，请参阅 Azure 虚拟机预留实例。
有关定价的概述，请参阅 Linux 虚拟机定价。
负载均衡器
在此示例中，Azure 负载均衡器用于将流量分配到应用层子网中的 VM。
你只需为配置的负载平衡和出站规则的数量付费。 入站网络地址转换 (NAT) 规则是免费的。 如果未配置规则，则标准负载均衡器不按小时收费。
ExpressRoute
在此体系结构中，ExpressRoute 是用于在本地网络和 Azure 虚拟网络之间创建专用连接的网络服务。
所有入站数据传输都是免费的。 所有出站数据传输都根据预先确定的费率收费。 有关详细信息，请参阅 Azure ExpressRoute 定价。
管理和操作注意事项
为让系统在生产环境中运行，请考虑以下几点。
Azure SAP 解决方案中心
Azure SAP 解决方案中心是一种端到端解决方案，可用于在 Azure 上作为统一的工作负载创建和运行 SAP 系统，并为创新提供更加无缝的基础。 此外，Azure SAP 解决方案中心的引导式部署体验可创建运行 SAP 系统所需的计算、存储和网络组件。 然后，它会根据 Microsoft 最佳做法帮助自动安装 SAP 软件。 可以同时利用新的和现有的基于 Azure 的 SAP 系统的管理功能。 有关详细信息，请参阅 Azure SAP 解决方案中心。
备份
可以通过多种方式备份 SAP HANA 数据。 迁移到 Azure 后，可继续使用已有的任何现有备份解决方案。 Azure 提供了两种用于备份的本机方法。 可在 VM 上备份 SAP HANA，或在文件级别使用 Azure 备份。 Azure 备份已获得 SAP BackInt 认证。 有关详细信息，请参阅 Azure 备份常见问题解答和在 Azure VM 上备份 SAP HANA 数据库的支持矩阵。
注意
目前，只有 HANA 单容器部署或纵向部署支持 Azure 存储快照。
身份管理
在所有级别上使用集中式标识管理系统来控制对资源的访问：
通过 Azure 基于角色的访问控制 (Azure RBAC)提供对资源的访问。
通过轻型目录访问协议 (LDAP)、Microsoft Entra ID、Kerberos 或其他系统授予对 Azure VM 的访问权限。
通过 SAP 提供的服务或使用 OAuth 2.0 和 Microsoft Entra ID，在应用本身内部支持访问。
监视
如需尽可能提高 Azure 上的应用程序和服务的可用性和性能，请使用 Azure Monitor，这是一种全面的解决方案，用于收集、分析和处理来自云和本地环境的遥测数据。 Monitor 有助于你了解应用程序的性能，并可主动识别影响应用程序及其所依赖资源的问题。 对于在 SAP HANA 和其他主要数据库解决方案上运行的 SAP 应用程序，请参阅适用于 SAP 的 Azure Monitor 解决方案，了解适用于 SAP 的 Azure Monitor 如何帮助你管理 SAP 服务的可用性和性能。
安全注意事项
SAP 具有自身的用户管理引擎 (UME)，可在 SAP 应用程序和数据库中控制基于角色的访问和授权。 有关详细信息，请参阅 SAP HANA 安全性 - 概述。
若要实现更高网络安全性，请考虑使用外围网络。外围网络使用 NVA 在 Web Dispatcher 子网和 Fiori 前端服务器池的前面创建防火墙。 由于数据传输成本考虑，将运行 Fiori 应用的活动前端服务器放置在与 S/4 系统相同的虚拟网络中。 另一种方法是将它们放置在外围网络中，并通过虚拟网络对等互连将其连接到 S/4。
在基础结构安全性方面，传输中数据和静态数据会加密。 Azure 虚拟机上的 SAP NetWeaver - 规划和实施指南的“安全注意事项”部分包含有关网络安全的信息，其内容也适用于 S/4HANA。 该指南还指定了为使应用程序能够通信，而需要在防火墙中打开的网络端口。
要加密 Linux VM 磁盘，可选择各种选项，如磁盘加密概述中所述。 对于 SAP HANA 静态数据加密，我们建议使用 SAP HANA 本机加密技术。 如需了解特定 Linux 发行版、版本和映像上对 Azure 磁盘加密的支持，请参阅适用于 Linux VM 的 Azure 磁盘加密一文。
对于 SAP HANA 静态数据加密，我们建议使用 SAP HANA 本机加密技术。
注意
请不要在同一存储卷上同时使用 HANA 静态数据加密和 Azure 磁盘加密。 对于 HANA，请仅使用 HANA 数据加密。 此外，使用客户管理的密钥可能会影响 I/O 吞吐量。
社区
社区可以解答问题，并帮助设置成功的部署。 考虑这些资源：
作者
本文由 Microsoft 维护， 最初由以下参与者撰写。
主要作者：
- Ben Trinh | 首席架构师
若要查看非公开领英个人资料，请登录领英。
后续步骤
有关使用某些与此体系结构相同技术的 SAP 工作负载的详细信息和示例，请参阅以下文章：