通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在 Azure 上规划和实施 SAP 部署

  • 项目

在 Azure 中，组织无需完成漫长的采购周期即可获取所需的云资源和服务。 但是，在 Azure 中运行 SAP 工作负载需要了解可用的选项，并在选择 Azure 组件和体系结构方面进行仔细规划，以便为解决方案提供支持。

Azure 提供用于运行 SAP 应用程序的综合平台。 Azure 基础结构即服务 (IaaS) 和平台即服务 (PaaS) 产品/服务相结合，为成功部署整个 SAP 企业布局提供了最佳选择。

本文对 SAP 文档和 SAP 说明（提供有关如何在 Azure 及其他平台上安装和部署 SAP 软件的信息的主要资源）作了补充。

定义

在本文中，我们使用以下术语：

  • SAP 组件：单个 SAP 应用程序，例如 SAP S/4HANA、SAP ECC、SAP BW 或 SAP Solution Manager。 SAP 组件可以基于传统的高级商业应用程序编程 (ABAP) 或 Java 技术，也可以是不基于 SAP NetWeaver 的应用程序，例如 SAP BusinessObjects。
  • SAP 环境：以逻辑方式组合在一起，用于执行开发、质量保证、培训、灾难恢复或生产等业务功能的多个 SAP 组件。
  • SAP 布局：组织 IT 布局中的整套 SAP 资产。 SAP 布局包括所有生产和非生产环境。
  • SAP 系统：数据库管理系统 (DBMS) 层与应用层的组合。 两个示例是 SAP ERP 开发系统和 SAP BW 测试系统。 在 Azure 部署中，无法在本地与 Azure 之间分布这两个层。 某个 SAP 系统要么部署在本地，要么部署在 Azure 中。 但是，可以在 Azure 中或本地操作 SAP 布局中的不同系统。

资源

介绍如何在 Azure 上托管和运行 SAP 工作负载的文档入口点是 Azure 虚拟机上的 SAP 入门。 在本文中，可以找到指向涵盖以下内容的其他文章的链接：

  • 用于存储、网络的 SAP 工作负载具体信息以及支持的选项。
  • Azure 上各种 DBMS 系统的 SAP DBMS 指南。
  • SAP 部署指南（人工和自动化）。
  • Azure 上 SAP 工作负载的高可用性和灾难恢复详细信息。
  • 使用其他服务和第三方应用程序与 Azure 上的 SAP 集成。

重要

如需了解先决条件、安装过程和有关特定 SAP 功能的详细信息，请务必仔细阅读 SAP 文档和指南。 本文仅介绍在 Azure 虚拟机 (VM) 上运行和安装的 SAP 软件的特定任务。

以下 SAP 说明构成了用于 SAP 部署的 Azure 指南的基础：

说明文档编号 标题
1928533 Azure 上的 SAP 应用程序：支持的产品和大小
2015553 Azure 上的 SAP：支持先决条件
2039619 Azure 上使用 Oracle Database 的 SAP 应用程序
2233094 DB6：Azure 上使用 IBM Db2 for Linux、UNIX 和 Windows 的 SAP 应用程序
1999351 适用于 SAP 的增强型 Azure 监视故障排除
1409604 Windows 上的虚拟化：增强型监视
2191498 Azure 的 Linux 上的 SAP：增强型监视
2731110 支持对 Azure 上的 SAP 使用网络虚拟设备 (NVA)

如需了解 Azure 订阅和资源的常规默认值和最大限制，请参阅 Azure 订阅和服务限制、配额和约束。

方案

SAP 服务通常被视为企业中最关键的应用程序之一。 这些应用程序的体系结构和操作非常复杂，因此，必须确保符合可用性与性能方面的要求。 企业通常会认真考虑选择哪个云提供商来运行此类业务关键业务流程。

Azure 是适用于关键业务 SAP 应用程序和业务流程的理想公共云平台。 如今，大多数当前 SAP 软件（包括 SAP NetWeaver 和 S/4HANA 系统）都可以托管在 Azure 基础结构中。 Azure 提供超过 800 种 CPU 类型和具有数 TB 内存的 VM。

有关支持的方案和不支持的某些方案的说明，请参阅 Azure 上的 SAP 支持的方案。 在规划想要部署到 Azure 的体系结构时，请检查这些方案以及指示为不受支持的条件。

要成功地将 SAP 系统部署到 Azure IaaS 或者一般的 IaaS，必须了解传统外购商或托管商的产品与 IaaS 产品之间的明显差异。 传统主机或外包商会根据客户想要托管的工作负载改造其基础结构（网络、存储和服务器类型）。 在 IaaS 部署中，客户或合作伙伴负责评估其可能的工作负载并选择适用于 VM、存储和网络的正确 Azure 组件。

为了收集用于规划部署到 Azure 的数据，请务必执行以下操作：

  • 确定 Azure 支持哪些 SAP 产品和版本。
  • 评估为 SAP 产品选择的 Azure VM 是否支持计划使用的操作系统版本。
  • 确定特定 VM 上的哪些 DBMS 版本支持用于 SAP 产品。
  • 评估是否需要升级或更新 SAP 布局，以便与所需的操作系统和 DBMS 版本保持一致，进而实现支持的配置。
  • 评估是否需要迁移到其他操作系统才能在 Azure 中部署。

有关 Azure 上支持的 SAP 组件、Azure 基础结构单元以及相关操作系统版本和 DBMS 版本的详细信息，请参阅 Azure 部署支持的 SAP 软件。 你从评估 SAP 版本、操作系统版本和 DBMS 版本之间的支持和依赖项中得到的信息对于将 SAP 系统迁移到 Azure 这一工作影响重大。 你了解是否涉及重大准备工作，例如，是否需要升级 SAP 版本或切换到其他操作系统。

规划部署的第一步

部署规划的第一步不是查找可用于运行 SAP 应用程序的 VM。

部署规划的第一步是与组织中的合规性和安全团队合作，确定在公有云中部署相应类型的 SAP 工作负载或业务流程的边界条件。 该过程可能非常耗时，但完成这一过程至关重要。

如果组织已在 Azure 中部署了软件，则该过程可能很简单。 如果贵公司更多地处于起步阶段，则可能需要进行更大的讨论才能确定边界条件、安全条件和企业体系结构，以允许将特定 SAP 数据和 SAP 业务流程托管在公有云中。

规划合规性

有关可帮助你针对合规性需求进行规划的 Microsoft 合规性产品的列表，请参阅 Microsoft 合规性产品。

规划安全性

有关 SAP 特定安全注意事项的信息，如静态数据的数据加密或 Azure 服务的其他加密，请参阅 Azure 加密概述和 SAP 布局的安全性。

组织 Azure 资源

如果此任务尚未完成，请结合安全性和合规性评审来规划如何组织 Azure 资源。 该过程包括做出有关以下事项的决策：

  • 用于每个 Azure 资源的命名约定，例如用于 VM 和资源组。
  • SAP 工作负载的订阅和管理组设计，例如，是否应为每个工作负载、每个部署层或每个业务单位创建多个订阅。
  • 针对订阅和管理组的 Azure Policy 企业范围使用。

为了帮助你做出正确的决策，Azure 云采用框架中介绍了许多企业体系结构的详细信息。

在规划中，请勿低估项目的初始阶段。 只有当你为合规性、安全性和 Azure 资源组织制定了协议和规则时，才应推进部署规划。

后续步骤是规划在 Azure 中部署的地理位置和网络体系结构。

Azure 地域和区域

Azure 服务在单独的 Azure 区域中提供。 Azure 区域是数据中心的集合。 数据中心包含托管和运行区域中提供的 Azure 服务的硬件和基础结构。 该基础结构中包括的大量节点充当计算节点或存储节点，或者运行网络功能。

有关 Azure 区域的列表，请参阅 Azure 地理位置。 有关交互式地图，请参阅 Azure 全球基础结构。

并非所有 Azure 区域都提供相同的服务。 根据要运行的 SAP 产品、调整大小要求以及所需的操作系统和 DBMS，特定区域可能并不提供方案所需的 VM 类型。 例如，如果运行的是 SAP HANA，则通常需要各种 M 系列 VM 系列的 VM。 这些 VM 系列仅部署在 Azure 区域的一个子集中。

在开始规划并考虑选择哪些区域作为主要区域以及最终的次要区域时，需要先调查考虑的区域中是否提供方案所需的服务。 可以在各区域的产品可用性中了解每个区域中提供的确切 VM 类型、Azure 存储类型或其他 Azure 服务。

Azure 配对区域

在 Azure 配对区域中，默认在两个区域之间启用特定数据的复制。 有关详细信息，请参阅 Azure 中的跨区域复制：业务连续性和灾难恢复。

区域对中的数据复制绑定到可以配置为复制到配对区域的 Azure 存储类型。 有关详细信息，请参阅次要区域中的存储冗余。

支持配对区域数据复制的存储类型不适用于 SAP 组件和 DBMS 工作负载。 Azure 存储复制的可用性仅限于 Azure Blob 存储（如用于备份目的）、文件共享和卷以及其他高延迟存储场景。

当你检查配对区域以及你要用于主要或次要区域的服务时，你计划在主要区域中使用的 Azure 服务或 VM 类型可能在要用作次要区域的配对区域中不可用。 或者，你可能会确定由于数据合规性原因，你的方案不接受 Azure 配对区域。 对于这些方案，需要将非配对区域用作次要或灾难恢复区域，并且需要自行设置一些数据复制。

可用性区域

许多 Azure 区域都使用可用性区域以物理方式分隔 Azure 区域内的位置。 每个可用性区域都由一个或多个数据中心组成，这些数据中心都配置了独立电源、冷却和网络。 使用可用性区域增强复原能力的示例是在 Azure 的两个单独的可用性区域中部署两个 VM。 另一个示例是为一个可用性区域中的 SAP DBMS 系统实施高可用性框架，并在另一个可用性区域中部署 SAP (A)SCS，以便在 Azure 中获得最佳 SLA。

有关 Azure 中的 VM SLA 的详细信息，请查看最新版本的虚拟机 SLA。 由于 Azure 区域快速发展和扩展，因此 Azure 区域的拓扑结构、物理数据中心的数量、这些数据中心之间的距离以及 Azure 可用性区域之间的距离也会不断变化。 基础结构更改时，网络延迟也会随之更改。

选择具有可用性区域的某个区域时，请遵循使用 Azure 可用性区域的 SAP 工作负载配置中的指南。 此外，确定哪个区域部署模型最适合你的要求、所选区域和工作负载。

容错域

容错域表示物理故障单元。 容错域与数据中心中包含的物理基础结构密切相关。 虽然物理刀片服务器或机架可被视为一个容错域，但物理计算元件和容错域之间不存在直接的一对一映射。

在将多个 VM 部署为 SAP 系统的一部分时，可以间接操控 Azure 结构控制器，以将 VM 部署到不同的容错域中，从而达到可用性 SLA 的要求。 但是，你无法直接控制在 Azure 缩放单元（数百个计算节点或存储节点和网络的集合）中分布容错域，或向特定容错域分配 VM。 若要操纵 Azure 结构控制器跨不同容错域部署一组 VM，需要在部署时向 VM 分配一个 Azure 可用性集。 有关详细信息，请参阅可用性集。

更新域

更新域代表一个逻辑单元，可设置如何更新包含多个 VM 的 SAP 系统中的某个 VM。 在进行平台更新时，Azure 会经历逐个更新这些更新域的整个过程。 通过在部署时跨不同的更新域分布 VM，可以防止 SAP 系统产生潜在的停机。 与容错域类似，Azure 缩放单元已分割到多个更新域中。 若要操纵 Azure 结构控制器跨不同更新域部署一组 VM，需要在部署时向 VM 分配一个 Azure 可用性集。 有关详细信息，请参阅可用性集。

描述更新域和容错域的示意图。

可用性集

Azure 结构控制器跨不同的容错域分布一个 Azure 可用性集中的 Azure VM。 跨不同容错域分布是为了防止在进行基础结构维护或者在一个容错域中发生故障时关闭 SAP 系统的所有 VM。 默认情况下，VM 并不属于某个可用性集。 只能在部署时或在重新部署 VM 时在可用性集中添加 VM。

若要详细了解 Azure 可用性集以及可用性集与容错域的关系，请参阅 Azure 可用性集。

重要

Azure 中的可用性区域和可用性集是互斥的。 可以将多个 VM 部署到特定的可用性区域或可用性集中。 但是，不可以将可用性区域和可用性集同时分配给 VM。

如果使用邻近放置组，则可以将可用性集和可用性区域结合使用。

在定义可用性集并尝试在一个可用性集中混合使用不同 VM 系列的各种 VM 时，可能会遇到问题，导致无法将特定 VM 类型包含在可用性集中。 原因是可用性集绑定到包含特定类型的计算主机的缩放单元。 特定类型的计算主机只能运行特定类型的 VM 系列。

例如，创建一个可用性集，并在该可用性集中部署第一个 VM。 添加到可用性集的第一个 VM 位于 Edsv5 VM 系列中。 尝试部署第二个 VM（M 系列中的 VM）时，此部署将失败。 原因是 Edsv5 系列的 VM 与 M 系列的 VM 不在同一主机硬件上运行。

如果要调整 VM 大小，则会出现相同的问题。 如果尝试将 VM 移出 Edsv5 系列并移入 M 系列的 VM 类型中，部署将失败。 如果将大小调整为无法在同一主机硬件上托管的 VM 系列，则必须关闭可用性集中的所有 VM，并调整它们全部的大小以使其能够在其他主机类型上运行。 有关在可用性集中部署的 VM 的 SLA 信息，请参阅虚拟机 SLA。

具有灵活的业务流程的虚拟机规模集

具有灵活的业务流程的虚拟机规模集提供平台管理的虚拟机的逻辑分组。 可以选择在区域内创建规模集，也可以跨可用性区域扩展规模集。 在 platformFaultDomainCount>1 (FD>1) 的区域内创建灵活规模集时，规模集中部署的 VM 将分布在同一区域中指定数量的容错域中。 另一方面，跨可用性区域创建 platformFaultDomainCount=1 (FD=1) 的灵活规模集将跨指定区域分布 VM，并且该规模集还将尽量使 VM 分布在区域内的不同容错域中。

对于 SAP 工作负载，仅支持 FD=1 的灵活规模集。 与传统可用性区域部署相比，使用 FD=1 的灵活规模集进行跨区域部署的优点是，使用该规模集部署的 VM 将尽量分布在区域内的不同容错域中。 若要详细了解使用规模集进行 SAP 工作负载部署，请参阅灵活的虚拟机规模部署指南。

在 Azure 上部署高可用性 SAP 工作负载时，请务必考虑可用的各种部署类型，以及如何跨不同的 Azure 区域（例如跨区域、在单个区域中或在没有区域的地区中）应用这些部署类型。 有关详细信息，请参阅 SAP 工作负载的高可用性部署选项。

提示

目前，无法直接将可用性集或可用性区域中部署的 SAP 工作负载迁移到 FD=1 的灵活规模集。 若要进行切换，需要从现有资源重新创建具有区域约束的 VM 和磁盘。 开源项目包含可用作将可用性集或可用性区域中部署的 VM 更改为 FD=1 的灵活规模集示例的 PowerShell 函数。 博客文章介绍了如何将可用性集或可用性区域中部署的 HA 或非 HA SAP 系统修改为 FD=1 的灵活规模集。

邻近放置组

各个 SAP VM 之间的网络延迟可能会对性能产生重大影响。 SAP 应用程序服务器与 DBMS 之间的网络往返时间对商务应用程序的影响尤其重大。 最佳情况是，运行 SAP VM 的所有计算元件都尽可能靠近。 这种选择不可能在每种组合中都实现，Azure 可能不知道要将哪些 VM 放在一起。 在大多数情况下和大多数区域中，默认放置能够满足网络往返延迟要求。

当默认放置不符合 SAP 系统中的网络往返要求时，邻近放置组可满足此需求。 可以将邻近放置组与 Azure 区域、可用性区域和可用性集的位置约束结合使用，以提高复原能力。 有了邻近放置组，可以在设置不同的更新域和容错域时结合使用可用性区域与可用性集。 邻近放置组应仅包含单个 SAP 系统。

尽管采用邻近放置组的部署可能会使放置的延迟优化效果最佳，但使用邻近放置组进行部署也有缺点。 某些 VM 系列不能合并到一个邻近放置组中，或者如果在 VM 系列之间调整大小，可能会遇到问题。 VM 系列、区域和可用性区域的约束可能不支持并置。 有关详细信息以及若要了解使用邻近放置组的优势和潜在挑战，请参阅邻近放置组方案。

大多数情况下，不使用邻近放置组的 VM 应该是 SAP 系统的默认部署方法。 对于 SAP 系统的区域（单个可用性区域）部署和跨区域（在两个可用性区域之间分布 VM）部署，此默认方法尤其适用。 仅出于性能原因需要使用邻近放置组时，才对 SAP 系统和 Azure 区域使用邻近放置组。

Azure 网络

Azure 有一个网络基础结构，其映射到你可能希望在 SAP 部署中实现的所有方案。 Azure 提供以下功能：

  • 访问 Azure 服务并访问应用程序使用的 VM 中的特定端口。
  • 通过安全外壳 (SSH) 或 Windows 远程桌面 (RDP) 直接访问 VM，以便进行管理。
  • 在 VM 之间以及通过 Azure 服务进行内部通信和名称解析。
  • 本地网络和 Azure 虚拟网络之间的本地连接。
  • 不同 Azure 区域中部署的服务之间的通信。

有关网络的详细信息，请参阅 Azure 虚拟网络。

设计网络通常是部署到 Azure 时进行的第一个技术活动。 支持像 SAP 这样的中央企业体系结构常常是总体网络要求的一部分。 在规划阶段，应尽可能详细地记录建议的网络体系结构。 如果在以后进行更改，例如更改子网网络地址，则可能需要移动或删除已部署的资源。

Azure 虚拟网络

虚拟网络是 Azure 中专用网络的基本构建基块。 可以定义网络的地址范围，并将该范围分成多个网络子网。 网络子网可供 SAP VM 使用，也可以专用于特定服务或用途。 某些 Azure 服务（如 Azure 虚拟网络和 Azure 应用程序网关）需要专用子网。

虚拟网络充当网络边界。 规划部署时所需的一部分设计是定义虚拟网络、子网和专用网络地址范围。 部署 VM 后，无法更改 VM 的网络接口卡 (NIC) 等资源的虚拟网络分配。 对虚拟网络或子网地址范围进行更改可能需要将所有已部署的资源移到其他子网。

网络设计应满足 SAP 部署的多个要求：

  • 不通过 SAP 内核（例如 S/4HANA 或 SAP NetWeaver）将防火墙等网络虚拟设备放置在 SAP 应用程序与 SAP 产品的 DBMS 层之间的通信路径中。
  • 网络路由限制由子网级别上的网络安全组 (NSG) 强制实施。 将 VM 的 IP 分组到 NSG 规则中维护的应用程序安全组 (ASG)，并提供权限的角色、层和 SID 分组。
  • SAP 应用程序和数据库 VM 在同一虚拟网络、单个虚拟网络的相同或不同子网中运行。 对应用程序和数据库 VM 使用不同的子网。 或者，使用专用应用程序和 DBMS ASG 对适用于同一子网中每个工作负载类型的规则进行分组。
  • 在所有 SAP 工作负载 VM 的所有网卡上启用加速网络（若技术上可行）。
  • 确保安全访问包括名称解析 (DNS)、标识管理（Windows Server Active Directory 域/Microsoft Entra ID）在内的中心服务的依赖项并具有管理访问权限。
  • 根据需要提供对公共终结点的访问以及通过公共终结点进行访问。 示例包括针对高可用性中的 ClusterLabs Pacemaker 操作或者 Azure 备份之类的 Azure 服务进行 Azure 管理。
  • 仅当需要创建具有自己的路由和 NSG 规则的指定子网时，才使用多个 NIC。

有关 SAP 部署的网络体系结构的示例，请参阅以下文章：

虚拟网络注意事项

某些虚拟网络配置有一些需要注意的具体事项。

  • 不支持使用 SAP 内核（例如 S/4HANA 或 SAP NetWeaver）在 SAP 应用层与 SAP 组件的 DBMS 层之间的通信路径中配置网络虚拟设备。

    通信路径中的网络虚拟设备很容易导致两个通信伙伴之间的网络延迟加倍。 它们还可能限制 SAP 应用程序层和 DBMS 层之间关键路径的吞吐量。 在某些方案下，网络虚拟设备可能导致 Pacemaker Linux 群集失败。

    SAP 应用层与 DBMS 层之间的通信路径必须为直接路径。 如果 ASG 和 NSG 规则允许直接通信路径，该限制就不包括 ASG 和 NSG 规则。

    不支持网络虚拟设备的其他方案包括：

  • 不支持将 SAP 应用层和 DBMS 层分到不同的 Azure 虚拟网络中。 建议使用相同 Azure 虚拟网络中的子网（而不是使用其他 Azure 虚拟网络）将 SAP 应用层与 DBMS 层隔离开来。

    如果设置将两个 SAP 系统层分到不同虚拟网络的不受支持的应用场景，则这两个虚拟网络必须对等互连。

    两个对等互连的 Azure 虚拟网络之间的网络流量会产生传输费用。 每一天，SAP 应用层和 DBMS 层之间交换的数据量都非常巨大，可达到许多太字节 (TB)。 如果 SAP 应用层和 DBMS 层的分隔处位于两个对等互连的 Azure 虚拟网络之间，产生的费用可能会很高。

名称解析和域服务

通过 DNS 将主机名解析为 IP 地址通常是 SAP 网络的关键元素。 有许多选项可以在 Azure 中配置名称解析和 IP 解析。

通常，企业有一个中央 DNS 解决方案，该解决方案是整个体系结构的一部分。 有关在 Azure 中以本机方式而不是通过设置自己的 DNS 服务器实现名称解析的几个选项，请参阅 Azure 虚拟网络中资源的名称解析。

与 DNS 服务一样，可能需要通过 SAP VM 或服务访问 Windows Server Active Directory。

IP 地址分配

在 VM 的 NIC 的整个存在过程中，仍会声明和使用 NIC 的 IP 地址。 该规则适用于动态和静态 IP 分配。 无论 VM 是在运行中还是已关闭，情况均如此。 如果删除 NIC、更改子网或者分配方法变为静态，则会释放动态 IP 分配。

可以将固定的 IP 地址分配给 Azure 虚拟网络中的 VM。 IP 地址通常针对依赖于外部 DNS 服务器和静态条目的 SAP 系统进行重新分配。 在删除 VM 及其 NIC 之前，或者在 IP 地址取消分配之前，保持分配此 IP 地址。 当为虚拟网络定义 IP 地址范围时，必须考虑 VM（正在运行和已停止）总数。

有关详细信息，请参阅创建具有静态专用 IP 地址的 VM。

注意

应在 Azure VM 及其 NIC 的静态和动态 IP 地址分配之间做出抉择。 VM 的来宾操作系统将获取 VM 启动时分配给 NIC 的 IP。 不应将来宾操作系统中的静态 IP 地址分配给 NIC。 某些 Azure 服务（例如 Azure 备份）依赖于至少主虚拟 NIC 设置为 DHCP 而不是操作系统中的静态 IP 地址这一事实。 有关详细信息，请参阅对 Azure VM 备份进行故障排除。

SAP 主机名虚拟化的辅助 IP 地址

每个 Azure VM 的 NIC 都可以分配有多个 IP 地址。 辅助 IP 可用于 SAP 虚拟主机名，该主机名映射到 DNS A 记录或 DNS PTR 记录。 必须将辅助 IP 地址分配给 Azure NIC 的 IP 配置。 还必须以静态方式在操作系统中配置辅助 IP，因为辅助 IP 通常并不通过 DHCP 进行分配。 每个辅助 IP 必须来自 NIC 绑定到的同一子网。 可以在不停止或解除分配 VM 的情况下在 Azure NIC 中添加和删除辅助 IP。 若要添加或删除 NIC 的主 IP，必须解除分配 VM。

Azure 负载均衡器由 SAP 高可用性体系结构与 Pacemaker 群集一起使用。 在此方案中，负载均衡器启用 SAP 虚拟主机名。 有关使用虚拟主机名的一般指南，请参阅 SAP 说明 962955。

将 Azure 负载均衡器与运行 SAP 的 VM 配合使用

负载均衡器通常用于高可用性体系结构，以提供主动和被动群集节点之间的浮动 IP 地址。 还可以对单个 VM 使用负载均衡器来保存 SAP 虚拟主机名的虚拟 IP 地址。 对单个 VM 使用负载均衡器是在 NIC 上使用辅助 IP 地址或在同一子网中使用多个 NIC 的替代方法。

标准负载均衡器会修改默认出站访问路径，因为其体系结构默认情况下是安全的。 标准负载均衡器后面的 VM 可能无法再访问相同的公共终结点。 一些示例是操作系统更新存储库的终结点或 Azure 服务的公共终结点。 有关提供出站连接的选项，请参阅使用 Azure 标准负载均衡器的 VM 的公共终结点连接。

提示

基本负载均衡器不应与 Azure 中的任何 SAP 体系结构一起使用。 基本负载均衡器计划将停用。

每个 VM 可以有多个 vNIC

可以为 Azure VM 定义多个虚拟网络接口卡 (vNIC)，每个 vNIC 都分配给与主 vNIC 相同的虚拟网络中的任何子网。 拥有多个 vNIC 后，可以根据需要开始设置网络流量隔离。 例如，客户端流量通过主 vNIC 路由，某些管理员或后端流量通过另一个 vNIC 路由。 根据使用的操作系统和映像，可能需要为操作系统内的 NIC 设置流量路由，以便正确地进行路由。

VM 的类型和大小决定了 VM 可以分配有多少个 vNIC。 有关功能和限制的信息，请参阅使用 Azure 门户将多个 IP 地址分配给 VM。

将 vNIC 添加到 VM 不会增加可用的网络带宽。 所有虚拟网络都共享相同的带宽。 建议仅在 VM 需要访问专用子网时使用多个 NIC。 建议采用依赖于 NSG 功能并能简化网络和子网要求的设计模式。 设计应使用尽可能少的网络接口，最好只使用一个。 HANA 横向扩展例外，这种情况下，HANA 内部网络需要辅助 vNIC。

警告

如果在 VM 上使用多个 vNIC，建议使用主 NIC 的子网来处理用户网络流量。

加速网络

为了进一步降低 Azure VM 之间的网络延迟，建议确认已在运行 SAP 工作负载的每个 VM 上启用 Azure 加速网络。 尽管默认情况下会为新 VM 启用加速网络，但根据部署清单，应验证该状态。 加速网络的优势是可极大地改善网络性能和延迟。 在为所有支持的 VM 上的 SAP 工作负载部署 Azure VM 时使用它，尤其要为 SAP 应用层和 SAP DBMS 层使用。 链接的文档包含操作系统版本和 VM 实例的支持依赖项。

本地连接

Azure 中的 SAP 部署假设企业范围的中央网络体系结构和通信中心已就位，可启用本地连接。 本地网络连接对于允许用户和应用程序访问 Azure 中的 SAP 布局以访问其他中央组织服务（例如，中央 DNS、域以及安全修补程序管理基础结构）至关重要。

有许多选项可以为 Azure 上的 SAP 部署提供本地连接。 网络部署通常是中心辐射型拓扑或中心辐射型拓扑的扩展（即全局虚拟 WAN）。

对于本地 SAP 部署，建议通过 Azure ExpressRoute 使用专用连接。 对于较小的 SAP 工作负载、远程区域或较小的办公室，可以使用 VPN 本地连接。 将 ExpressRoute 与 VPN 站点到站点连接结合用作故障转移路径是这两种服务的可能组合。

入站和出站 Internet 访问

SAP 布局要求连接到 Internet，无论是接收操作系统存储库更新、与其公共终结点上的 SAP SaaS 应用程序建立连接，还是通过其公共终结点访问 Azure 服务。 同样，可能需要为客户端提供对 SAP Fiori 应用程序的访问权限，并让 Internet 用户访问 SAP 布局提供的服务。 SAP 网络体系结构要求你规划 Internet 的路径以及任何传入的请求。

保护虚拟网络，方法是使用 NSG 规则、对已知服务使用网络服务标记，以及建立到防火墙或其他网络虚拟设备的路由和 IP 寻址。 所有这些任务或注意事项都是体系结构的一部分。 专用网络中的资源需要受到网络第 4 层和第 7 层防火墙的保护。

与 Internet 的通信路径是最佳做法体系结构的重点所在。

适用于 SAP 工作负载的 Azure VM

某些 Azure VM 系列尤其适用于 SAP 工作负载，某些则更确切地用于 SAP HANA 工作负载。 有关如何找到正确 VM 类型及其支持 SAP 工作负载的能力的信息，请参阅 Azure 部署支持的 SAP 软件。 此外，SAP 说明 1928533 列出了所有经认证的 Azure VM 及其性能功能，如 SAP 应用程序性能标准 (SAPS) 基准和限制（如适用）。 经认证可用于 SAP 工作负载的 VM 类型，不会超量预配 CPU 和内存资源。

除了查看受支持的 VM 类型选择外，还需要根据可用产品（按区域）检查这些 VM 类型在特定地区是否可用。 至少重要的是确定 VM 的以下功能是否适合你的应用场景：

  • CPU 和内存资源
  • 每秒输入/输出操作 (IOPS) 带宽
  • 网络功能
  • 可附加的磁盘数量
  • 能够使用某些 Azure 存储类型

若要获取特定 FM 系列和类型的此信息，请参阅 Azure 中虚拟机的大小。

Azure VM 的定价模型

对于 VM 定价模型，可以选择首选使用的选项：

  • 即用即付定价模型
  • 预留一年或节省计划
  • 预留三年或节省计划
  • 现成定价模型

若要获取有关不同 Azure 服务、操作系统和区域的 VM 定价的详细信息，请参阅虚拟机定价。

节省若要了解一年和三年期储蓄计划和预留实例的定价和灵活性，请参阅以下文章：

有关现成定价的详细信息，请参阅 Azure 现成虚拟机。

相同 VM 类型的定价可能因 Azure 区域而异。 一些客户从部署到成本较低的 Azure 区域受益，因此在规划时，有关按区域定价的信息会很有帮助。

Azure 还提供使用专用主机的选项。 使用专用主机可以更灵活地控制 Azure 服务的修补周期。 你可以计划修补以支持自己的日程安排和周期。 此产品/服务专门针对工作负载不遵循正常工作负载周期的客户。 有关详细信息，请参阅 Azure 专用主机。

SAP 工作负载支持使用 Azure 专用主机。 许多 SAP 客户希望更灵活地控制基础结构修补和维护计划，他们使用 Azure 专用主机。 有关 Microsoft 如何维护和修补托管 VM 的 Azure 基础结构的详细信息，请参阅 Azure 中虚拟机的维护。

VM 的操作系统

在 Azure 中为 SAP 布局部署新 VM 时，若要安装或迁移 SAP 系统，请务必为工作负载选择正确的操作系统。 Azure 为 Linux 和 Windows 提供了大量的操作系统映像选择，也为 SAP 系统提供了许多合适的选项。 你还可以从本地环境创建或上传自定义映像，也可以使用或通用化来自映像库的映像。

有关可用选项的详细信息和信息：

根据需要为 SAP 工作负载规划操作系统更新基础结构及其依赖项。 请考虑使用存储库过渡环境，通过在更新期间使用相同版本的修补程序和更新，使 SAP 布局（沙盒、开发、预生产和生产）的所有层保持同步。

第 1 代和第 2 代 VM

在 Azure 中，可以将 VM 部署为第 1 代或第 2 代。 Azure 中对第 2 代 VM 的支持列出了可以部署为第 2 代 VM 的 Azure VM 系列。 本文还列出了 Azure 中第 1 代和第 2 代 VM 之间的功能差异。

部署 VM 时，你选择的操作系统映像决定了 VM 是第 1 代还是第 2 代 VM。 Azure 中提供的所有 SAP 操作系统映像（Red Hat Enterprise Linux、SuSE Enterprise Linux 以及 Windows 或 Oracle Enterprise Linux）的最新版本均可在第 1 代和第 2 代 VM 中使用。 请务必根据映像说明仔细选择映像，以部署正确的 VM 生成。 同样，可以将自定义操作系统映像创建为第 1 代或第 2 代，并在部署 VM 时影响 VM 的代系。

注意

我们建议你在 Azure 中的所有 SAP 部署中使用第 2 代 VM，无论 VM 大小如何。 适用于 SAP 的所有最新 Azure VM 均支持第 2 代 VM，或仅支持第 2 代 VM。 某些 VM 系列目前仅支持第 2 代 VM。 即将推出的某些 VM 系列可能仅支持第 2 代 VM。

可以根据所选操作系统映像确定 VM 是第 1 代还是仅第 2 代。 无法将现有 VM 从一个代更改为另一代。

在 Azure 中，无法将部署的 VM 从第 1 代更改为第 2 代。 若要更改 VM 代系，必须部署你需要的新一代 VM，然后在新一代 VM 上重新安装软件。 这种更改只会影响 VM 的基本 VHD 映像，而不会影响数据磁盘或附加的网络文件系统 (NFS) 或服务器消息块 (SMB) 共享。 最初分配给第 1 代 VM 的数据磁盘、NFS 共享或 SMB 共享可以附加到第 2 代 VM。

某些 VM 系列（如 Mv2 系列）仅支持第 2 代 VM。 将来新的 VM 系列可能也会有同样的要求。 在这种情况下，无法调整现有第 1 代 VM 的大小，以适应新的 VM 系列。 除了 Azure 平台的第 2 代 VM 要求外，SAP 组件也可能具有与 VM 代系相关的要求。 若要了解所选 VM 系列的任何第 2 代 VM 要求，请参阅 SAP 说明 1928533。

Azure VM 的性能限制

作为公有云，Azure 依赖于以安全的方式在整个客户群中共享基础结构。 若要启用缩放和容量，需要为每个资源和服务定义性能限制。 在 Azure 基础结构的计算端，请务必考虑为每个 VM 大小定义的限制。

每个 VM 都具有不同的磁盘和网络吞吐量配额及可附加的磁盘数，无论它是否存在具有自己的吞吐量和 IOPS、内存大小以及可用的 vCPU 数量限制的本地临时存储。

注意

对 Azure 上的 SAP 解决方案的 VM 大小做出决策时，必须考虑每个 VM 大小的性能限制。 文档中介绍的配额代表理论上可达到的最大值。 每个磁盘的 IOPS 性能限制可能是使用较小输入/输出 (I/O) 值（例如 8 KB）实现的，但可能无法使用较大 I/O 值（例如 1 MB）来实现。

与 VM 一样，SAP 工作负载的每种存储类型以及所有其他 Azure 服务都存在相同的性能限制。

规划并选择要在 SAP 部署中使用的 VM 时，请考虑以下因素：

  • 从内存和 CPU 要求开始。 将 SAPS 对 CPU 能力的要求分为 DBMS 部分和 SAP 应用程序部分。 对于现有系统，通常可以根据现有的 SAP 标准应用程序基准来确定或估测使用中的硬件的相关 SAPS。 对于新部署的 SAP 系统，请完成大小调整练习，以确定系统的 SAPS 要求。

  • 对于现有系统，应该度量 DBMS 服务器上的 I/O 吞吐量和 IOPS。 对于新系统，在针对新的系统完成选型活动后，应该也能给出 DBMS 端 I/O 要求的大致观点。 如果对这种结果没有把握，最终需要开展概念认证。

  • 将 DBMS 服务器的 SAPS 要求与 Azure 的不同 VM 类型可以提供的 SAPS 进行比较。 SAP 说明 1928533 中阐述了有关不同 Azure VM 类型的 SAPS 的信息。 首先应该将注意力集中在 DBMS VM 上，因为数据库层是 SAP NetWeaver 系统上的、不能在大多数部署中横向扩展的层。 相比之下，SAP 应用程序层可以横向扩展。各个 DBMS 指南介绍了建议的存储配置。

  • 汇总以下结果：

    • 要使用的 Azure VM 数。
    • 每个 SAP 层的各个 VM 系列和 VM SKU：DBMS、(A)SCS 和应用程序服务器。
    • I/O 吞吐量度量或计算的存储容量要求。

HANA 大型实例服务

Azure 提供计算功能，可在名为 Azure SAP HANA 大型实例的专用产品/服务上运行纵向扩展或横向扩展的大型 HANA 数据库。 此产品/服务扩展了 Azure 中可用的 VM。

注意

HANA 大型实例服务处于日落模式，不接受新客户。 仍然可以为现有的 HANA 大型实例客户提供单元。

Azure 上的 SAP 存储

Azure VM 使用各种存储选项进行暂留。 简单而言，VM 可以分为永久性存储类型和临时或非永久性存储类型。

可以从多种存储选项中选择适合 SAP 工作负载和特定 SAP 组件的存储选项。 有关详细信息，请参阅适用于 SAP 工作负载的 Azure 存储。 本文介绍了 SAP 每个部分的存储体系结构：操作系统、应用程序二进制文件、配置文件、数据库数据、日志和跟踪文件以及与其他应用程序的文件接口（无论是存储在磁盘上还是通过文件共享访问）。

VM 中的临时磁盘

大多数适用于 SAP 的 Azure VM 都提供临时磁盘，但这不是托管磁盘。 临时磁盘仅用于存储消耗性数据。 临时磁盘上的数据可能会在不可预见的维护事件或 VM 重新部署期间丢失。 临时磁盘的性能特征使其成为操作系统交换/页面文件的理想选择。

任何应用程序或非消耗性的操作系统数据都不应存储在临时磁盘上。 在 Windows 环境中，临时驱动器通常作为驱动器 D 进行访问。在 Linux 系统中，装入点通常是 /dev/sdb device、/mnt 或 /mnt/resource。

某些 VM 不提供临时驱动器。 如果计划将这些 VM 大小用于 SAP，则可能需要增加操作系统磁盘的大小。 有关详细信息，请参阅 SAP 说明 1928533。 对于具有临时磁盘的 VM，请在 Azure 中虚拟机的大小中获取有关临时磁盘大小以及每个 VM 系列的 IOPS 和吞吐量限制的信息。

不能直接调整具有临时磁盘的 VM 系列与没有临时磁盘的 VM 系列之间的大小。 目前，两个此类 VM 系列之间的重设大小会失败。 解决方法是使用操作系统磁盘快照重新创建没有新大小的临时磁盘的 VM。 保留所有其他数据磁盘和网络接口。 了解如何将具有本地临时磁盘的 VM 规格调整为无本地临时磁盘的 VM 规格。

SAP 的网络共享和卷

SAP 系统通常需要一个或多个网络文件共享。 文件共享通常是以下选项之一：

  • SAP 传输目录（/usr/sap/trans 或 TRANSDIR）。
  • SAP 卷或共享 sapmnt 或 saploc 卷，用于部署多个应用程序服务器。
  • SAP (A)SCS、SAP ERS ​​或数据库 (/hana/shared) 的高可用性体系结构卷。
  • 运行第三方应用程序进行文件导入和导出的文件接口。

在这些情况下，我们建议您使用 Azure 服务，例如 Azure 文件存储或 Azure NetApp 文件。 如果这些服务在你选择的区域中不可用，或者它们不适用于你的解决方案基础结构，则可以选择从自托管、基于 VM 的应用程序或第三方服务提供 NFS 或 SMB 文件共享。 如果在 Azure 中的 SAP 系统中使用第三方服务作为存储层，请参阅 SAP 说明 2015553，了解 SAP 支持的限制。

由于网络共享通常至关重要，并且它们通常是设计（对于高可用性）或流程（对于文件接口）中的单一故障点，我们建议你依赖每个 Azure 本机服务来实现其自身的可用性、SLA 和复原能力。 在规划阶段，请务必考虑以下因素：

  • NFS 或 SMB 共享设计，包括每个 SAP 系统 ID (SID)、每个部署和每个区域使用哪些共享。
  • 子网大小调整，包括专用终结点的 IP 要求或 Azure NetApp 文件等服务的专用子网。
  • 网络路由到 SAP 系统和连接的应用程序。
  • 为 Azure 文件存储使用公共或专用终结点。

有关要求以及如何在高可用性方案中使用 NFS 或 SMB 共享的信息，请参阅高可用性。

注意

如果将 Azure 文件存储用于网络共享，建议使用专用终结点。 如果发生区域性故障（不太可能发生此情况），NFS 客户端会自动重定向到运行正常的区域。 你不需要在 VM 上重新装载 NFS 或 SMB 共享。

SAP 布局的安全性

若要保护 Azure 上的 SAP 工作负荷，需要规划安全性的多个方面：

  • 网络分段以及每个子网和网络接口的安全性。
  • SAP 布局中每个层上的加密。
  • 针对最终用户和管理访问以及单一登录服务的标识解决方案。
  • 威胁和操作监视。

本章中的主题并非所有可用服务、选项和替代方法的详尽列表。 其中列出了 Azure 中所有 SAP 部署应考虑的几种最佳做法。 根据企业或工作负载要求，还需要涵盖其他方面。 有关安全设计的详细信息，请参阅以下关于 Azure 常规指南的资源：

使用安全组保护虚拟网络

在 Azure 中规划 SAP 布局应包括一定程度的网络分段，其中虚拟网络和子网仅专用于 SAP 工作负载。 网络和其他 Azure 体系结构指南中介绍了子网定义的最佳做法。 我们建议将 NSG 与 NSG 中的 ASG 配合使用，以允许入站和出站连接。 设计 ASG 时，VM 上的每个 NIC 都可以与多个 ASG 相关联，因此可以创建不同的组。 例如，为 DBMS VM 创建 ASG，其中包含布局的所有数据库服务器。 为单个 SAP SID 的所有 VM（应用程序和 DBMS）创建另一个 ASG。 这样，可以为整个数据库 ASG 定义一条 NSG 规则，并为仅适用于 SID 特定的 ASG 定义另一条更具体的规则。

NSG 不会使用为 NSG 定义的规则来限制性能。 若要监视流量，可以选择激活 NSG 流日志记录，使用所选信息事件管理 (SIEM) 或入侵检测系统 (IDS) 评估的日志来监控可疑的网络活动并采取行动。

提示

仅在子网级别激活 NSG。 虽然 NSG 可以在子网级别和 NIC 级别激活，但在分析网络流量限制时，同时在两者上激活通常会对故障排除造成阻碍。 仅在特殊情况下和需要时，才使用 NIC 级别的 NSG。

服务的专用终结点

默认情况下，可以通过公共终结点访问许多 Azure PaaS 服务。 尽管通信终结点位于 Azure 后端网络上，但该终结点在公共 Internet 中公开。 专用终结点是你自己的专用虚拟网络中的网络接口。 通过 Azure 专用链接，专用终结点将服务投射到虚拟网络中。 然后，通过网络内的 IP 以非公开方式访问所选 PaaS 服务。 根据配置，可以将服务设置为仅通过专用终结点进行通信。

使用专用终结点可以增强对数据泄露的保护，并且通常可以简化从本地和对等网络进行访问。 在许多情况下，可以简化网络路由和打开防火墙端口的过程（通常对于公共终结点是必要的）。 资源已在网络中，因为它们可以通过专用终结点访问。

若要了解哪些 Azure 服务提供使用专用终结点的选项，请参阅专用链接可用的服务。 对于使用 Azure 文件存储的 NFS 或 SMB，我们建议始终对 SAP 工作负载使用专用终结点。 若要了解使用服务产生的费用，请参阅专用终结点定价。 某些 Azure 服务可能会选择将费用包含在服务中。 此信息包含在服务的定价信息中。

加密

根据公司策略，SAP 工作负载可能需要超出 Azure 中默认选项的加密。

基础结构资源的加密

默认情况下，Azure 中的托管磁盘和 Blob 存储使用平台管理的密钥 (PMK) 进行加密。 此外，Azure 中的 SAP 工作负载还支持对托管磁盘和 Blob 存储进行创建自己的密钥 (BYOK) 加密。 对于托管磁盘加密，可以根据公司安全要求从不同的选项中进行选择。 Azure 加密选项包括：

  • 存储端加密 (SSE) PMK (SSE-PMK)
  • SSE 客户管理的密钥 (SSE-CMK)
  • 静态双重加密
  • 基于主机的加密

有关详细信息，包括 Azure 磁盘加密的说明，请参阅 Azure 加密选项的比较。

注意

目前，由于潜在的性能限制，在运行 Linux 时不要在 M 系列 VM 系列中的 VM 上使用基于主机的加密。 对托管磁盘使用 SSE-CMK 加密不受此限制影响。

对于 Linux 系统上的 SAP 部署，请勿使用 Azure 磁盘加密。 Azure 磁盘加密需要使用 Azure 密钥保管库中的 CMK 在 SAP VM 内部运行加密。 对于 Linux，Azure 磁盘加密不支持用于 SAP 工作负载的操作系统映像。 Azure 磁盘加密可用于具有 SAP 工作负载的 Windows 系统，但不能将 Azure 磁盘加密与数据库本机加密结合使用。 我们建议使用数据库本机加密代替 Azure 磁盘加密。 有关详细信息，请参阅下一部分。

与托管磁盘加密类似，Azure 文件存储静态加密（SMB 和 NFS）可使用 PMK 或 CMK。

对于 SMB 网络共享，请仔细查看 Azure 文件存储和操作系统依赖项与 SMB 版本，因为该配置会影响对传输中加密的支持。

重要

如果使用客户管理的加密，则仔细计划存储和保护加密密钥至关重要。 如果没有加密密钥，加密的资源（如磁盘）将不可访问，并可能导致数据丢失。 请仔细考虑保护密钥并仅允许特权用户或服务访问密钥。

SAP 组件的加密

SAP 级别的加密可以分为两个层：

  • DBMS 加密
  • 传输加密

对于 DBMS 加密，SAP NetWeaver 或 SAP S/4HANA 部署支持的每个数据库都支持本机加密。 透明数据库加密完全独立于 Azure 中现有的任何基础结构加密。 可以同时使用 SSE 和数据库加密。 使用加密时，加密密钥的位置、存储和保护至关重要。 任何加密密钥丢失都会导致数据丢失，因为无法启动或恢复数据库。

某些数据库可能没有数据库加密方法，或者可能不需要启用专用设置。 对于其他数据库，激活数据库加密时，可能会隐式加密 DBMS 备份。 请参阅以下 SAP 文档，了解如何启用和使用透明数据库加密：

请联系 SAP 或 DBMS 供应商，获取有关如何启用、使用或排查软件加密问题的支持。

重要

制定周密的计划来存储和保护加密密钥极其重要。 如果没有加密密钥，可能无法访问数据库或 SAP 软件，并且可能会丢失数据。 仔细考虑如何保护密钥。 仅允许特权用户或服务访问密钥。

可以向 SAP 引擎和 DBMS 之间的 SQL Server 连接应用传输或通信加密。 同样，还可以加密从 SAP 表示层（SAPGui 安全网络连接或 SNC）的连接或到 Web 前端的 HTTPS 连接。 请参阅应用程序供应商的文档，了解如何启用和管理传输中的加密。

威胁监视和警报

若要部署和使用威胁监视和警报解决方案，请首先使用组织的体系结构。 Azure 服务提供威胁防护和安全视图，你可以将其纳入整个 SAP 部署计划中。 Microsoft Defender for Cloud 解决了威胁防护要求。 Defender for Cloud 通常属于整个 Azure 部署的总体治理模型，而不仅仅是 SAP 组件。

有关安全信息事件管理 (SIEM) 和安全业务流程自动响应 (SOAR) 解决方案的详细信息，请参阅适用于 SAP 集成的 Microsoft Sentinel 解决方案。

SAP VM 内部的安全软件

适用于 Linux 的 SAP 说明 2808515 和适用于 Windows 的 SAP 说明 106267 介绍了在 SAP 服务器上使用病毒扫描程序或安全软件时的要求和最佳做法。 我们建议在 Azure 中部署 SAP 组件时遵循 SAP 建议。

高可用性

Azure 中的 SAP 高可用性分为两个部分：

  • Azure 基础结构高可用性：Azure 计算 (VM),、网络和存储服务的高可用性，以及如何提高 SAP 应用程序可用性。

  • SAP 应用程序高可用性：如何通过使用服务修复将其与 Azure 基础结构高可用性相结合。 使用 SAP 软件组件中的高可用性的示例：

    • SAP (A)SCS 和 SAP ERS 实例
    • 数据库服务器

有关 Azure 中 SAP 的高可用性的详细信息，请参阅以下文章：

Linux 上的 Pacemaker 和 Windows Server 故障转移群集是 Microsoft 在 Azure 上直接支持的唯一 SAP 工作负载高可用性框架。 Microsoft 不持任何其他高可用性框架，并且需要供应商提供设计、实现详细信息和运营支持。 有关详细信息，请参阅 Azure 中 SAP 支持的方案。

灾难恢复

通常，SAP 应用程序是企业中最关键的业务流程之一。 根据其重要性以及意外中断后恢复运行所需的时间，应仔细规划业务连续性和灾难恢复 (BCDR) 方案。

若要了解如何满足此要求，请参阅 SAP 工作负载的灾难恢复概述和基础结构指导。

Backup

作为 BCDR 策略的一部分，SAP 工作负载的备份必须是任何计划部署的重要一环。 备份解决方案必须涵盖 SAP 解决方案堆栈的所有层：VM、操作系统、SAP 应用程序层、DBMS 层和任何共享存储解决方案。 SAP 工作负载所使用的 Azure 服务以及其他关键资源（例如加密和访问密钥）的备份也必须是备份和 BCDR 设计的一部分。

Azure 备份提供备份以下内容的 PaaS 解决方案：

  • 通过适用于 VM 的 Azure 备份进行 VM 配置、操作系统和 SAP 应用程序层（在托管磁盘上调整数据大小）备份。 查看支持矩阵，验证你的体系结构是否可以使用此解决方案。
  • SQL Server 和 SAP HANA 数据库数据和日志备份。 它包括对数据库复制技术的支持，例如 HANA 系统复制或 SQL Always On，以及对配对区域的跨区域支持。
  • 通过 Azure 文件存储进行文件共享备份。 验证对 NFS 或 SMB 和其他配置详细信息的支持。

或者，如果部署 Azure NetApp 文件，则可以在卷级别上使用备份选项，包括 SAP HANA 和 Oracle DBMS 与计划备份的集成。

Azure 备份解决方案提供软删除选项，以防止恶意或意外删除并防止数据丢失。 软删除还适用于使用 Azure 文件存储部署的文件共享。

如果你自行创建和管理解决方案，或者使用第三方软件，则可以使用备份选项。 一个选项是将服务与 Azure 存储配合使用，包括使用 Blob 数据的不可变存储。 对于某些数据库（例如 SAP ASE 或 IBM Db2），当前需要此自托管选项作为 DBMS 备份选项。

使用 Azure 最佳做法中的建议来防范和验证勒索软件攻击。

提示

确保备份策略包括保护部署自动化、Azure 资源的加密密钥以及透明数据库加密（如果使用）。

跨区域备份

对于任何跨区域备份要求，请确定解决方案提供的恢复时间目标 (RTO) 和恢复点目标 (RPO)，以及它是否符合 BCDR 设计和需求。

SAP 迁移到 Azure

由于 SAP 产品种类繁多，版本依赖项以及本机操作系统和 DBMS 技术种类众多，因此不可能描述所有的迁移方法和选项。 组织的项目团队和服务提供商方面的代表应该考虑几种技术，以便顺利将 SAP 迁移到 Azure。

  • 在迁移期间测试性能。 SAP 迁移规划的一个重要部分是技术性能测试。 迁移团队需要为关键人员留出足够的时间和可用性来运行迁移后的 SAP 系统的应用程序和技术测试，包括连接的接口和应用程序。 为了成功实现 SAP 迁移，在测试环境中比较迁移前和迁移后的运行时间以及关键业务流程的准确性至关重要。 在迁移生产环境之前，请使用这些信息来优化流程。

  • 使用 Azure 服务进行 SAP 迁移。 通过使用 Azure Migrate 或 Azure Site Recovery 等服务或第三方工具，某些基于 VM 的工作负载无需更改即可迁移到 Azure。 认真确认该服务是否支持操作系统版本及其运行的 SAP 工作负载。

    通常，任何数据库工作负载都不受支持，因为服务无法保证数据库一致性。 如果迁移服务支持 DBMS 类型，则数据库更改或变动率通常过高。 大多数忙碌的 SAP 系统都无法满足迁移工具允许的更改率。 在生产迁移之前，可能不会看到或发现问题。 在许多情况下，某些 Azure 服务不适合迁移 SAP 系统。 Azure Site Recovery 和 Azure Migrate 没有大规模 SAP 迁移的验证。 经过验证的 SAP 迁移方法是依赖于 DBMS 复制或 SAP 迁移工具。

    与基本 VM 迁移相比，在 Azure 中部署是更好的选择，而且比本地迁移更容易完成。 Azure SAP 解决方案和 Azure 部署自动化框架等自动化部署框架允许快速执行自动化任务。 若要使用 DBMS 本机复制技术（例如 HANA 系统复制、DBMS 备份和还原或 SAP 迁移工具）将 SAP 环境迁移到新部署的基础结构，需要使用 SAP 系统的既定技术知识。

  • 基础结构纵向扩展。 在 SAP 迁移期间，拥有更多基础结构容量可帮助你更快地部署。 项目团队应考虑纵向扩展 VM 大小，以提供更多的 CPU 和内存。 团队还应考虑纵向扩展 VM 聚合存储和网络吞吐量。 同样，在 VM 级别，考虑单个磁盘等存储元素，以通过按需突发和高级 SSD v1 的性能层来增加吞吐量。 如果使用高于配置值的高级 SSD v2，请增加 IOPS 和吞吐量值。 放大 NFS 和 SMB 文件共享以提高性能限制。 请记住，Azure 管理磁盘的大小不能减小，并且大小、性能层和吞吐量 KPI 的减小可能会有各种冷却时间。

  • 优化网络和数据复制。 将 SAP 系统迁移到 Azure 总是涉及移动大量数据。 这些数据可能是数据库和文件备份或复制、应用程序到应用程序的数据传输或 SAP 迁移导出。 根据使用的迁移过程，需要选择正确的网络路径来移动数据。 对于许多数据移动操作，使用 Internet 而不是专用网络是将数据安全地复制到 Azure 存储的最快速路径。

    使用 ExpressRoute 或 VPN 可能会导致瓶颈：

    • 迁移数据使用过多的带宽，并干扰用户访问 Azure 中运行的工作负载。
    • 本地网络瓶颈（如防火墙或吞吐量限制）通常仅在迁移期间发生。

    无论使用哪种网络连接，数据移动的单个流网络性能通常很低。 若要通过多个 TCP 流提高数据传输速度，请使用可支持多个流的工具。 应用 SAP 文档和有关此主题的许多博客文章中介绍的优化技术。

提示

在规划阶段，请务必考虑用于将大量数据传输到 Azure 的任何专用迁移网络。 例如备份或数据库复制，或使用公共终结点将数据传输到 Azure 存储。 应该预计并减轻迁移对用户和应用程序的网络路径造成的影响。 在网络规划过程中，请考虑迁移的所有阶段以及迁移期间 Azure 中部分高效工作负载的成本。

SAP 的支持和操作

在 Azure 中部署 SAP 之前和期间，需要考虑一些其他方面。

适用于 SAP 的 Azure VM 扩展

Azure 监视扩展、增强型监视和适用于 SAP 的 Azure 扩展均指需要部署的 VM 扩展，用于向 SAP 主机代理提供有关 Azure 基础结构的一些基本数据。 SAP 说明可能将此扩展称为“监视扩展”或“增强型监视”。 在 Azure 中，它称为适用于 SAP 的 Azure 扩展。 出于支持目的，必须在运行 SAP 工作负载的所有 Azure VM 上安装此扩展。 若要了解详细信息，请参阅适用于 SAP 的 Azure VM 扩展。

SAP 支持的 SAProuter

在 Azure 中操作 SAP 布局需要与 SAP 建立连接，以提供支持。 通常，连接采用 SAProuter 连接的形式，可以通过 Internet 上的加密网络通道或通过到 SAP 的专用 VPN 连接进行连接。 有关最佳做法以及 Azure 中 SAProuter 的实现示例，请参阅 Azure 上的 SAP 的入站和出站 Internet 连接中的体系结构应用场景。

后续步骤