本文提供有关在 Azure 中构建整个 SAP 布局的最佳做法。 SAP 布局包括跨中心、生产、非生产和灾难恢复环境的多个 SAP 系统。 我们提供的建议侧重于网络设计，而不是特定 SAP 系统。 目标是为构建安全、高性能、可复原的 SAP 布局提供建议。
体系结构
下载体系结构的 Visio 文件。
工作流
- 本地网络：从本地网络到连接的 Azure 区域的 ExpressRoute 连接。
- Azure 订阅区域中心：包含整个企业（而不仅仅是 SAP）的中心服务的 Azure 订阅。 中心订阅通过对等互连到包含 SAP 工作负载的分支虚拟网络来提供连接。
- 中心虚拟网络：主要区域或区域 A 中的中心虚拟网络分支。
- 中心灾难恢复 (DR) 虚拟网络：灾难恢复区域中的中心虚拟网络分支。 它镜像主要区域中生产虚拟网络的子网设计。
- Azure 订阅 SAP 非生产：适用于所有非生产 SAP 工作负载的 Azure 订阅。 它包括预生产、质量保证、开发和沙盒环境。
- SAP 非生产分支虚拟网络：主要区域中用于 SAP 非生产工作负载的单独虚拟网络。 每个 SAP 环境都有其自己的虚拟网络和子网。
- Azure 订阅 SAP 生产：适用于所有生产 SAP 工作负载的 Azure 订阅。
- SAP 生产分支虚拟网络：具有多个子网的 SAP 生产环境的虚拟网络。 此虚拟网络位于主要区域中。
- SAP 生产灾难恢复 (DR) 分支虚拟网络：次要灾难恢复区域中用于 SAP 生产工作负载的虚拟网络。 它镜像主要区域中生产虚拟网络的子网设计。
- Azure 服务：可连接到 SAP 布局的 Azure 服务示例。
- SAP 业务技术平台 (BTP)：SAP 环境通过 Azure 专用链接访问 SAP 业务技术平台。
Azure 订阅
建议使用中心辐射型网络设计。 使用中心辐射型设计，需要至少三个订阅来划分 SAP 环境。 你应该订阅 (1) 区域中心虚拟网络、(2) 非生产虚拟网络和 (3) 生产虚拟网络。 订阅提供计费、策略和安全边界。 订阅数不正确。 使用的订阅数取决于计费、策略和安全需求。 通常需要避免使用过多订阅。 订阅过多可能会增加不必要的管理开销和网络复杂性。 例如，不需要对每个 SAP 系统使用一个订阅。 我们的体系结构使用三个订阅：
区域中心：一个 Azure 虚拟中心订阅，其中存在主要和次要区域的中心虚拟网络。 此订阅适用于所有中心服务，而不仅仅是 SAP。
SAP 非生产：非生产系统（包括沙盒、开发、质量保证或预生产系统）驻留的 Azure SAP 非生产订阅。
SAP 生产：我们在其中配置了生产和灾难恢复系统的 Azure SAP 生产订阅。
有关详细信息，请参阅：
网络设计
中心辐射型拓扑是建议的 SAP 布局网络设计。 在此拓扑中，生产中心虚拟网络充当连接的中心点。 它连接到本地网络和各种分支虚拟网络，并使用户和应用程序能够访问 SAP 工作负载。 在此中心辐射型拓扑中，下面是我们对 SAP 网络设计的建议。
使用 ExpressRoute 进行本地连接。 对于 SAP 工作负载，建议使用 ExpressRoute 将本地网络连接到中心虚拟网络和中心 DR 虚拟网络。 如果有全局位置，则可以使用 Azure 虚拟 WAN 拓扑。 请考虑设置站点到站点 (S2S) VPN 作为 Azure ExpressRoute 或任何第三方路由要求的备用连接。
有关详细信息，请参阅：
每个环境使用一个虚拟网络。 建议每个环境使用一个虚拟网络（SAP 部署层）。 该体系结构对生产、开发、质量保证和沙盒使用不同的虚拟网络。 此网络设计非常适合大型企业体系结构。
使用中央防火墙。 流向分支虚拟网络（包括远程函数调用 (RFC) 连接）的所有网络流量都应通过中心虚拟网络中的中央防火墙。 分支虚拟网络之间的网络通信（分支到分支通信）通过中心虚拟网络的 Azure 防火墙子网中的中心虚拟网络防火墙。 同样，分支虚拟网络和本地网络之间的网络通信也会通过中心虚拟网络防火墙。 我们使用虚拟网络对等互连将各种分支虚拟网络连接到中心虚拟网络。 分支虚拟网络之间的所有通信都会通过中心虚拟网络防火墙。 还可以使用网络虚拟设备而不是防火墙。 有关详细信息，请参阅网络虚拟设备。
停留在虚拟网络中的网络流量不应通过防火墙。 例如，不要在 SAP 应用程序子网和 SAP 数据库子网之间放置防火墙。 不能在 SAP 应用程序与运行 SAP 内核的 SAP 系统的数据库管理系统 (DBMS) 层之间放置防火墙或网络虚拟设备 (NVA)。
避免对等互连分支虚拟网络。 如果可能，应避免分支虚拟网络之间的虚拟网络对等互连。 分支到分支虚拟网络对等互连可让分支到分支通信绕过中心虚拟网络防火墙。 仅当具有高带宽要求（例如，在 SAP 环境之间进行数据库复制）时，才应配置分支到分支虚拟网络对等互连。 所有其他网络流量都应通过中心虚拟网络和防火墙。 有关详细信息，请参阅 Azure 上的 SAP 的入站和出站 Internet 连接。
子网
最佳做法是将每个 SAP 环境（生产、预生产、开发、沙盒）划分到多个子网，并使用子网对相关服务进行分组。 下面是有关对 SAP 布局进行子网划分的建议。
子网数
体系结构中的生产虚拟网络有五个子网。 此设计非常适合大型企业解决方案。 子网数可以更少也可以更多。 虚拟网络中的子网数应由虚拟网络中的资源数决定。
子网大小调整
确保子网有足够的网络地址空间。 如果使用 SAP 虚拟主机名，则 SAP 子网中需要有更多地址空间。 通常，每个 SAP 实例需要 2-3 个 IP 地址，并包括一个用于虚拟机主机名的 IP 地址。 在 SAP 工作负载虚拟网络中部署时，其他 Azure 服务可能需要自己的专用子网。
应用程序子网
应用程序子网包含运行 SAP 应用程序服务器、SAP 中心服务 (ASCS)、SAP 排队复制服务 (ERS) 和 SAP Web 调度程序实例的虚拟机。 子网还包含 Azure 文件存储的专用终结点。 在示意图中，我们按角色对虚拟机进行了分组。 我们建议采用具有灵活编排、可用性区域或可用性集的虚拟机规模集进行弹性部署。 有关详细信息，请参阅后续步骤。
数据库子网
数据库子网包含运行数据库的虚拟机。 在图中，一对具有同步复制的虚拟机表示一个 SAP 环境的所有数据库虚拟机。
外围子网
外围子网面向 Internet，包括 SAP 外围子网和应用程序网关子网。 下面是有关设计这两个子网的建议。
SAP 外围子网：SAP 外围子网是一个外围网络，其中包含面向 Internet 的应用程序，例如 SAProuter、SAP Cloud Connector、SAP Analytics Cloud Agent 和应用程序网关。 这些服务依赖于 SAP 团队应部署、管理和配置的 SAP 系统。 中心 IT 团队不应管理 SAP 外围子网中的服务。 因此，应将这些服务放置在 SAP 分支虚拟网络中，而不是中心虚拟网络中。 体系结构关系图仅显示生产 SAP 外围网络。 它在非生产虚拟网络中没有 SAP 外围子网。 非生产 SAP 订阅中的工作负载使用 SAP 外围子网中的服务。
可以在非生产订阅中创建一组单独的 SAP 外围子网。 我们仅建议将此方法用于关键工作负载或频繁更改的工作负载。 专用的非生产 SAP 外围有助于进行测试和部署新功能。 不太关键的应用程序或随着时间的推移只会进行少量修改的应用程序不需要单独的非生产 SAP 外围子网。
应用程序网关子网：Azure 应用程序网关需要其自己的子网。 使用它可允许 SAP 服务（如 SAP Fiori）可以使用的来自 Internet 的流量。 推荐的体系结构将 Azure 应用程序网关及其前端公共 IP 地址放置在中心虚拟网络中。 Azure 应用程序网关至少需要 1 个 /29 大小的子网。 我们建议使用 /27 大小或更大的子网。 不能在同一子网中同时使用两个版本（v1 和 v2）的应用程序网关。 有关详细信息，请参阅 Azure 应用程序网关的子网。
将外围子网放置在单独的虚拟网络中以提高安全性：为了提高安全性，可以将 SAP 外围子网和应用程序网关子网放在 SAP 生产订阅中单独的虚拟网络内。 SAP 外围分支虚拟网络与中心虚拟网络对等互连，流向公用网络的所有网络流量都会流经外围虚拟网络。 该替代方法将 Azure 应用网关及其入站连接的公共 IP 地址放置在辐射型虚拟网络中，仅供 SAP 使用。
此网络设计提供更好的事件响应功能和精细的网络访问控制。 但是，它也会增加部署的管理复杂性、网络延迟和成本。 让我们来讨论每个要点。
更好的事件响应：如果检测到漏洞，可通过 SAP 外围分支虚拟网络快速隔离遭入侵的服务。 可以删除从 SAP 外围分支虚拟网络到中心的虚拟网络对等互连，并立即将 SAP 外围工作负载和 SAP 应用程序虚拟网络应用程序与 Internet 隔离开来。 无需依赖于网络安全组 (NSG) 规则更改来响应事件。 更改或删除 NSG 规则只会影响新连接，不会切断现有恶意连接。
精细的网络访问控制：SAP 外围虚拟网络为 SAP 生产分支虚拟网络提供更严格的网络访问控制。
增加复杂性、延迟和成本：体系结构增加了管理复杂性、成本和延迟。 来自 SAP 生产虚拟网络的 Internet 绑定通信进行了两次对等互连，一次连接到中心虚拟网络，另一次连接到 SAP 外围虚拟网络外部的 Internet。 中心虚拟网络中的防火墙对延迟的影响最大。 建议测量延迟，以查看你的用例是否可以支持它。
有关详细信息，请参阅外围网络最佳做法。
Azure NetApp 文件子网
如果使用 NetApp 文件，则应有一个委托子网来为不同的 Azure 上的 SAP 方案提供网络文件系统 (NFS) 或服务器消息块 (SMB) 文件共享。 /24 子网是 NetApp 文件子网的默认大小，但可以根据需要更改该大小。 根据自己的要求确定适当的大小。 有关详细信息，请参阅委托子网。
子网安全性
通过使用子网对具有相同安全规则要求的 SAP 资源进行分组，可以更轻松地管理安全性。
网络安全组 (NSG)：通过使用子网，可在子网级别实现网络安全组。 若要对同一子网中需要不同安全规则的资源进行分组，需要子网级别和网络接口级别的网络安全组。 使用这种两级设置，安全规则很容易发生冲突，并可能导致难以排查的意外通信问题。 NSG 规则也会影响子网中的流量。 有关 NSG 的详细信息，请参阅网络安全组。
应用程序安全组 (ASG)：建议使用应用程序安全组对虚拟机网络接口进行分组，并在网络安全组规则中引用应用程序安全组。 通过此配置，可以更轻松地为 SAP 部署创建规则和管理 SAP 部署。 每个网络接口可以属于具有不同网络安全组规则的多个应用程序安全组。 有关详细信息，请参阅应用程序安全组。
Azure 专用链接
建议使用 Azure 专用链接来提高网络通信的安全性。 Azure 专用链接使用具有专用 IP 地址的专用终结点来与 Azure 服务通信。 Azure 专用链接可避免通过 Internet 将网络通信发送到公共终结点。 有关详细信息，请参阅 Azure 服务上的专用终结点。
在应用程序子网中使用专用终结点：建议使用专用终结点将应用程序子网连接到支持的 Azure 服务。 在体系结构中，每个虚拟网络的应用程序子网中都有一个用于 Azure 文件存储的专用终结点。 可以将此概念扩展到任何受支持的 Azure 服务。
使用适用于 SAP 业务技术平台 (BTP) 的 Azure 专用链接：适用于 SAP 业务技术平台 (BTP) 的 Azure 专用链接现已正式发布。 SAP 专用链接服务支持来自 SAP BTP、Cloud Foundry 运行时和其他服务的连接。 示例方案包括在虚拟机上运行的 SAP S/4HANA 或 SAP ERP。 它们可以连接到 Azure 本机服务，例如 Azure Database for MariaDB 和 Azure Database for MySQL。
该体系结构描绘了来自 SAP BTP 环境的 SAP 专用链接 服务连接。 SAP 专用链接服务在特定 SAP BTP 服务与每个网络中的特定服务之间建立专用连接，作为服务提供商帐户。 专用链接允许 BTP 服务通过专用网络连接访问 SAP 环境。 它不使用公共 Internet 来进行通信，因此提高了安全性。
有关详细信息，请参阅：
网络文件系统 (NFS) 和服务器消息块 (SMB) 文件共享
SAP 系统通常依赖于网络文件系统卷或服务器消息块共享。 这些文件共享在虚拟机之间移动文件，或者充当与其他应用程序的文件接口。 建议使用本机 Azure 服务（例如 Azure 高级文件和 Azure NetApp 文件）作为网络文件系统 (NFS) 和服务器消息块 (SMB) 文件共享。 与基于操作系统的工具相比，Azure 服务具有更好的可用性、复原能力和服务级别协议 (SLA) 组合。
有关详细信息，请参阅：
构建 SAP 解决方案时，需要正确调整单个文件共享卷的大小，并知道连接到哪个 SAP 系统文件共享。 在计划期间，请牢记 Azure 服务的可伸缩性和性能目标。 下表概述了常见的 SAP 文件共享，并提供了简要说明和在整个 SAP 环境中的建议用法。
| 文件共享名 | 使用情况 | 建议 |
|---|---|---|
sapmnt |
分布式 SAP 系统、配置文件和全局目录 | 每个 SAP 系统的专用共享，不重复使用 |
cluster |
每个设计的 ASCS、ERS 和数据库的高可用性共享 | 每个 SAP 系统的专用共享，不重复使用 |
saptrans |
SAP 传输目录 | 一个或几个 SAP 布局（ERP、Business Warehouse）使用一个共享 |
interface |
与非 SAP 应用程序的文件交换 | 客户特定的要求，每个环境（生产、非生产）使用单独的文件共享 |
只能在不同的 SAP 环境之间共享 saptrans 因此应仔细考虑其位置。 出于可伸缩性和性能原因，避免将过多 SAP 系统合并到一个 saptrans 共享中。
公司安全策略将推动体系结构和环境之间的卷分离。 按环境或层隔离的传输目录需要 SAP 环境之间的 RFC 通信，以允许 SAP 传输组或传输域链接。 有关详细信息，请参阅：
数据服务
该体系结构包含 Azure 数据服务，可帮助扩展和改进 SAP 数据平台。 为了帮助解锁业务见解，我们建议使用 Azure Synapse Analytics、Azure 数据工厂和 Azure Data Lake Storage 等服务。 这些数据服务可帮助分析和直观呈现 SAP 数据和非 SAP 数据。
对于许多数据集成方案，需要集成运行时。 Azure 集成运行时是 Azure 数据工厂和 Azure Synapse Analytics 管道用于提供数据集成功能的计算基础结构。 我们建议为每个环境单独部署这些服务的运行时虚拟机。 有关详细信息，请参阅：
- Azure 集成运行时
- 设置要在 SAP CDC 解决方案中使用的自承载集成运行时
- 从 SAP HANA 复制数据
- 通过 Open Hub 从 SAP Business Warehouse 中复制数据
共享服务
SAP 解决方案依赖于共享服务。 负载均衡器和应用程序网关是多个 SAP 系统使用的服务示例。 构建共享服务的方式应由体系结构和组织需求决定。 下面是应遵循的一般指南。
负载均衡器：建议每个 SAP 系统使用一个负载均衡器。 此配置有助于最大程度降低复杂性。 需要避免对单个负载均衡器使用过多池和规则。 此配置还可确保命名和放置与 SAP 系统和资源组保持一致。 每个具有群集高可用性 (HA) 体系结构的 SAP 系统都应有至少一个负载均衡器。 该体系结构将一个负载均衡器用于 ASCS 虚拟机，将另一个负载均衡器用于数据库虚拟机。 某些数据库可能不需要负载均衡器即可创建高可用性部署。 SAP HANA 就是如此。 有关更多详细信息，请查看特定于数据库的文档。
应用程序网关：我们建议对每个 SAP 环境（生产、非生产和沙盒）使用至少一个应用程序网关，除非连接系统的复杂性和数量过高。 可以对多个 SAP 系统使用一个应用程序网关，以降低复杂性，因为并非环境中的所有 SAP 系统都需要公共访问。 单个应用程序网关可以为单个 SAP S/4HANA 系统的多个 Web 调度程序端口提供服务，也可以由不同的 SAP 系统使用。
SAP Web 调度程序虚拟机：体系结构显示包含两个或更多 SAP Web 调度程序 VM 的池。 建议不要在不同的 SAP 系统之间重复使用 SAP Web 调度程序虚拟机。 通过分隔它们，可以根据每个 SAP 系统的需求调整 Web 调度程序虚拟机的大小。 对于较小的 SAP 解决方案，建议在 ASCS 实例中嵌入 Web 调度程序服务。
SAP 服务：SAProuter、Cloud Connector 和 Analytics Cloud Agent 等 SAP 服务根据应用程序要求进行集中部署或拆分部署。 由于客户要求不同，不建议在 SAP 系统之间重复使用。 网络部分提到了要做出的主要决定，即是否应使用 SAP 非生产外围子网以及何时使用。 否则，如果只使用 SAP 的生产外围子网，则整个 SAP 布局都会使用 SAP 外围服务。
灾难恢复
灾难恢复 (DR) 可满足在主要 Azure 区域不可用或遭到入侵时的业务连续性要求。 从整体 SAP 布局的角度来看，如图中所示，下面是我们对灾难恢复设计的建议。
使用不同的 IP 地址范围：虚拟网络仅跨越单个 Azure 区域。 任何灾难恢复解决方案都应使用不同的区域。 需要在次要区域中创建不同的虚拟网络。 DR 环境中的虚拟网络需要不同的 IP 地址范围才能通过数据库本机技术实现数据库同步。
中心服务和与本地的连接：与本地和关键中心服务（DNS 或防火墙）的连接必须在灾难恢复区域中可用。 灾难恢复计划中需要包括中心 IT 服务的可用性和更改配置。 中心 IT 服务是正常运行的 SAP 环境的关键组件。
使用 Azure Site Recovery：Azure Site Recovery 将应用程序服务器的托管磁盘和虚拟机配置复制到 DR 区域并对其进行保护。
确保文件共享可用性：SAP 依赖于密钥文件共享的可用性。 在 DR 方案中，需要通过备份或连续文件共享复制来提供这些文件共享上的数据，并尽量减少数据丢失。
数据库复制：Azure Site Recovery 无法保护 SAP 数据库服务器，因为服务更改率高且缺少数据库支持。 需要配置到灾难恢复区域的连续和异步数据库复制。
有关详细信息，请参阅 SAP 工作负载的灾难恢复概述和基础结构指导。
较小的 SAP 体系结构
对于较小的 SAP 解决方案，简化网络设计可能会有所帮助。 然后，每个 SAP 环境的虚拟网络将成为此类组合虚拟网络中的子网。 网络和订阅设计需求的任何简化都可能会影响安全性。 应重新评估网络路由、与公用网络之间的双向访问、对共享服务（文件共享）的访问，以及访问其他 Azure 服务。 下面是用于收缩体系结构以更好地满足组织需求的一些选项。
将 SAP 应用程序和数据库子网合二为一。 可以合并应用程序和数据库子网来创建一个大型 SAP 网络。 此网络设计镜像多个本地 SAP 网络。 要合并这两个子网，需要更加关注子网安全性和网络安全组规则。 将单个子网用于 SAP 应用程序和数据库子网时，应用程序安全组非常重要。
合并 SAP 外围子网和应用程序子网。 可以合并外围子网和 SAP 应用程序子网。 必须更加注意网络安全组规则和应用程序安全组的使用。 我们仅建议对小型 SAP 资产采用这种简化方法。
合并不同 SAP 环境之间的 SAP 分支虚拟网络：体系结构为每个 SAP 环境（中心、生产、非生产和灾难恢复）使用不同的虚拟网络。 根据 SAP 布局的大小，可以将多个 SAP 分支虚拟网络合并为更少的甚至仅一个 SAP 分支。 仍需要区分生产环境和非生产环境。 每个 SAP 生产环境都将成为一个 SAP 生产虚拟网络中的子网。 每个 SAP 非生产环境都将成为一个 SAP 非生产虚拟网络中的子网。
作者
Microsoft 会维护本文。 最初由以下贡献者撰写。
主要作者：
- Robert Biro | 高级架构师
- Pankaj Meshram | 首席项目经理