你当前正在访问 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 解决方案管理器。 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 使用 Oracle 数据库在 Azure 上的 SAP 应用程序
2233094 DB6：使用 IBM Db2 for Linux、UNIX 和 Windows 的 Azure 上的 SAP 应用程序
1999351 适用于 SAP 的增强型 Azure 监视故障排除
1409604 Windows 上的虚拟化：增强型监视
2191498 Azure 的 Linux 上的 SAP：增强型监视
2731110 支持 Azure 上的 SAP 的网络虚拟设备（NVA）

有关 Azure 订阅和资源的默认和最大限制，请参阅 Azure 订阅和服务限制、配额和约束。

方案

SAP 服务通常被视为企业中最关键的应用程序之一。 应用程序的体系结构和操作很复杂，必须确保满足可用性和性能的所有要求。 企业通常会仔细考虑选择哪个云提供商来运行此类业务关键型业务流程。

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

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

若要成功将 SAP 系统部署到 Azure IaaS 或 IaaS，请务必了解传统私有云和 IaaS 产品/服务之间的重大差异。 传统的主机或外包商将基础结构（网络、存储和服务器类型）适应客户想要托管的工作负荷。 在 IaaS 部署中，客户或合作伙伴负责评估其潜在工作负荷，并选择 VM、存储和网络的正确 Azure 组件。

若要收集数据来规划到 Azure 的部署，请务必：

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

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

规划部署的第一步

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

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

如果组织已在 Azure 中部署了软件，则此过程可能很简单。 如果你的公司在旅程开始时更多，则可能需要进行更大的讨论来找出边界条件、安全条件和企业体系结构，这些条件允许某些 SAP 数据和 SAP 业务流程托管在公有云中。

规划合规性

有关可帮助规划合规性需求的 Microsoft 合规性产品/服务列表，请参阅 Microsoft 合规性产品/服务。

规划安全性

有关 SAP 特定安全问题的信息，例如静态数据的数据加密或其他 Azure 服务中的加密，请参阅适用于 SAP 环境的 Azure 加密概述和安全性。

组织 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 配对区域中，默认在两个区域之间启用某些数据副本 (replica)。 有关详细信息，请参阅 Azure 中的跨区域复制：业务连续性和灾难恢复。

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

支持配对区域数据的存储类型副本 (replica)是不适合 SAP 组件和 DBMS 工作负荷的存储类型。 Azure 存储副本 (replica)的可用性仅限于Azure Blob 存储（出于备份目的）、文件共享和卷以及其他高延迟存储方案。

为配对区域和要在主要或次要区域中使用的服务检查时，你打算在主要区域中使用的 Azure 服务或 VM 类型在要用作次要区域的配对区域中不可用。 或者，你可能会确定由于数据符合性原因，无法接受 Azure 配对区域。 对于这些方案，需要将非对区域用作次要区域或灾难恢复区域，并且需要自行设置一些数据副本 (replica)。

可用性区域

许多 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，需要在部署时将 Azure 可用性集分配给 VM。 有关详细信息，请参阅 可用性集。

更新域

更新域表示一个逻辑单元，用于设置 SAP 系统中由多个 VM 组成的 VM 的更新方式。 发生平台更新时，Azure 会逐个更新这些更新域。 通过在部署时将 VM 分散到不同的更新域，可以保护 SAP 系统免受潜在的停机。 与容错域类似，Azure 缩放单元分为多个更新域。 若要通过不同的更新域操纵 Azure 构造控制器来部署一组 VM，需要在部署时将 Azure 可用性集分配给 VM。 有关详细信息，请参阅 可用性集。

Diagram that depicts update domains and failure domains.

可用性集

一个 Azure 可用性集中的 Azure VM 通过不同的容错域由 Azure 构造控制器分发。 在不同容错域中的分发是防止 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 工作负荷的高可用性部署选项。

提示

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

邻近放置组

单个 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 应用程序与 SAP 产品 DBMS 层之间的通信路径中没有 通过 SAP 内核（例如 S/4HANA 或 SAP NetWeaver）放置任何网络虚拟设备（如防火墙）。
  • 网络路由限制由 子网级别的网络安全组（NSG） 强制执行。 将 VM 的 IP 分组到 NSG 规则中维护的应用程序安全组（ASG）， 并提供权限的角色、层和 SID 分组。
  • SAP 应用程序和数据库 VM 在同一虚拟网络中、单个虚拟网络的相同或不同子网中运行。 对应用程序和数据库 VM 使用不同的子网。 或者，使用专用应用程序和 DBMS ASG 对适用于同一子网中每个工作负荷类型的规则进行分组。
  • 在技术上尽可能为 SAP 工作负荷启用所有 VM 的所有网络卡启用加速网络。
  • 确保安全访问中央服务（包括名称解析（DNS）、标识管理（Windows Server Active Directory 域/Microsoft Entra ID）和管理访问权限。
  • 根据需要提供对公共终结点的访问和访问。 示例包括用于在高可用性中或 Azure 服务（如 Azure 备份）的 ClusterLabs Pacemaker 操作的 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 虚拟网络之间的网络流量可能会产生传输成本。 每天，由许多 TB 组成的大量数据在 SAP 应用程序层和 DBMS 层之间交换。 如果 SAP 应用程序层和 DBMS 层在两个对等互连的 Azure 虚拟网络之间隔离，可能会 产生巨大的成本 。

名称解析和域服务

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

通常，企业有一个中央 DNS 解决方案，该解决方案是整个体系结构的一部分。 Azure 虚拟网络中资源的“名称解析”中介绍了几种在本地实现名称解析的选项，而不是通过设置自己的 DNS 服务器。

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

IP 地址分配

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

可以将固定 IP 地址分配给 Azure 虚拟网络中的 VM。 IP 地址通常为依赖于外部 DNS 服务器和静态条目的 SAP 系统重新分配。 IP 地址将保持分配状态，直到删除 VM 及其 NIC 或 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 可用于映射到 DNS A 记录或 DNS PTR 记录的 SAP 虚拟主机名。 必须将辅助 IP 地址分配给 Azure NIC 的 IP 配置。 辅助 IP 还必须以静态方式在操作系统中配置，因为辅助 IP 通常不是通过 DHCP 分配的。 每个辅助 IP 必须来自 NIC 绑定到的同一子网。 可以在不停止或解除分配 VM 的情况下从 Azure NIC 添加和删除辅助 IP。 若要添加或删除 NIC 的主 IP，必须解除分配 VM。

注意

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

运行 SAP 的 VM Azure 负载均衡器

负载均衡器通常用于高可用性体系结构，以提供主动和被动群集节点之间的浮动 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 门户向 VM 分配多个 IP 地址。

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

警告

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

加速网络

为了进一步降低 Azure VM 之间的网络延迟，建议确认 在运行 SAP 工作负荷的每个 VM 上都启用了 Azure 加速网络 。 尽管默认情况下为新 VM 启用了加速网络，但根据部署检查列表，应验证状态。 加速网络的好处是大大提高了网络性能和延迟。 在所有受支持的 VM 上（尤其是 SAP 应用程序层和 SAP DBMS 层）上部署 SAP 工作负荷的 Azure VM 时，请使用它。 链接的文档包含对操作系统版本和 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 工作负荷。 Azure 部署支持的 SAP 软件中介绍了查找正确的 VM 类型及其支持 SAP 工作负荷的功能。 此外，SAP 说明 1928533 列出了所有经认证的 Azure VM 及其性能功能，如 SAP 应用程序性能标准（SAPS）基准和限制（如果适用）。 为 SAP 工作负荷认证的 VM 类型不会对 CPU 和内存资源使用过度预配。

除了仅查看支持的 VM 类型的选择之外，还需要检查这些 VM 类型是否在特定区域中可用，具体取决于按区域可用的产品。 至少重要的是确定 VM 的以下功能是否适合你的方案：

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

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

Azure VM 的定价模型

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

  • 即用即付定价模型
  • 一年期保留或储蓄计划
  • 三年期保留或储蓄计划
  • 现成定价模型

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

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

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

相同 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 代的 Azure VM 系列。 本文还列出了 Azure 中第 1 代和第 2 代 VM 之间的功能差异。

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

注意

建议在 Azure 中的所有 SAP 部署中使用第 2 代 VM，而不考虑 VM 大小。 适用于 SAP 的所有最新 Azure VM 都支持第 2 代，或仅限制为第 2 代。 某些 VM 系列目前仅支持第 2 代 VM。 即将推出的某些 VM 系列可能仅支持第 2 代。

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

在 Azure 中，无法将部署的 VM 从第 1 代更改为第 2 代。 若要更改 VM 代系，必须部署一个新的 VM，该 VM 是想要的一代，并在新一代 VM 上重新安装软件。 此更改仅影响 VM 的基本 VHD 映像，并且不会影响数据磁盘或附加的网络文件系统（NFS）或服务器消息块（SMB）共享。 最初分配给第 1 代 VM 的数据磁盘、NFS 共享或 SMB 共享可以附加到新一代 2 VM。

某些 VM 系列（如 Mv2 系列）仅支持第 2 代。 将来对于新的 VM 系列，相同的要求可能也是如此。 在这种情况下，无法调整现有第 1 代 VM 的大小，以使用新的 VM 系列。 除了 Azure 平台的第 2 代要求外，SAP 组件可能还具有与 VM 代系相关的要求。 若要了解所选 VM 系列的任何第 2 代要求，请参阅 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 要求开始。 将 CPU 电源的 SAPS 要求分离到 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 设备、 /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 定义的规则的性能。 对于监视流量流，可以选择使用所选信息事件管理（SIEM）或入侵检测系统（IDS）评估的日志来激活 NSG 流日志记录 ，以监视和处理可疑网络活动。

提示

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

服务的专用终结点

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

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

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

Encryption

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

基础结构资源的加密

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

  • 存储端加密 （S标准版） PMK （S标准版-PMK）
  • S标准版客户管理的密钥（S标准版-CMK）
  • 静态双重加密
  • 基于主机的加密

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

注意

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

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

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

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

重要

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

SAP 组件的加密

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

  • DBMS 加密
  • 传输加密

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

某些数据库可能没有数据库加密方法，或者可能不需要启用专用设置。 对于其他数据库，激活数据库加密时，可能会隐式加密 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 工作负荷的灾难恢复概述和基础结构指南。

备份

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

Azure 备份提供用于备份的 PaaS 解决方案：

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

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

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

备份选项可用于创建和管理自己的解决方案，或者使用第三方软件。 一个选项是将服务用于Azure 存储，包括对 blob 数据使用不可变存储。 对于某些数据库（例如 SAP A标准版 或 IBM Db2），此自管理选项当前需要作为 DBMS 备份选项。

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

提示

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

跨区域备份

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

SAP 迁移到 Azure

无法描述各种 SAP 产品、版本依赖项以及可用的本机操作系统和 DBMS 技术的所有迁移方法和选项。 组织的项目团队和服务提供商端的代表应考虑多种技术，以便顺利将 SAP 迁移到 Azure。

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

  • 使用 Azure 服务进行 SAP 迁移。 某些基于 VM 的工作负荷通过使用 Azure Migrate 或 Azure Site Recovery 或第三方工具等服务迁移到 Azure，而无需更改 Azure。 勤奋地确认操作系统版本及其运行的 SAP 工作负荷受服务支持。

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

    与本地迁移相比，Azure 中的部署而不是基本 VM 迁移更可取且更易于完成。 自动化部署框架（如 适用于 SAP 解决方案 的 Azure 中心）和 Azure 部署自动化框架 允许快速执行自动化任务。 若要使用 HANA 系统副本 (replica)、DBMS 备份和还原等 DBMS 本机副本 (replica)技术将 SAP 布局迁移到新的部署基础结构，或者 SAP 迁移工具使用 SAP 系统的已建立技术知识。

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

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

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

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

    无论使用的网络连接如何，数据移动的单流网络性能通常较低。 若要通过多个 TCP 流提高数据传输速度，请使用可支持多个流的工具。 应用 SAP 文档和本主题上许多博客文章中所述的优化技术。

提示

在规划阶段，请务必考虑将用于大型数据传输到 Azure 的任何专用迁移网络。 示例包括备份或数据库副本 (replica)或使用公共终结点将数据传输到 Azure 存储。 迁移对用户和应用程序的网络路径的影响应得到预期和缓解。 在网络规划过程中，请考虑迁移的所有阶段以及迁移期间 Azure 中部分高效工作负荷的成本。

SAP 的支持和操作

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

适用于 SAP 的 Azure VM 扩展

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

SAP 支持的 SAProuter

在 Azure 中操作 SAP 布局需要连接到 SAP 以及从 SAP 进行连接，以实现支持目的。 通常，如果连接是通过 Internet 加密网络通道或通过专用 VPN 连接到 SAP，则连接采用 SAProuter 连接的形式。 有关 Azure 中 SAProuter 的最佳做法和示例实现，请参阅 Azure 上的 SAP 入站和出站 Internet 连接的体系结构方案。

后续步骤