你当前正在访问 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 使用 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 上 支持的 SAP 组件、Azure 基础结构单元和相关操作系统版本和 DBMS 版本。 从评估 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，需要在部署时将 Azure 可用性集分配给 VM。 有关详细信息，请参阅 可用性集。

更新域

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

描述更新域和失败域的示意图。

可用性集

一个 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 工作负载的高可用性部署选项。

提示

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

邻近放置组

单个 SAP VM 之间的网络延迟可能会对性能产生重大影响。 SAP 应用程序服务器与 DBMS 之间的网络往返时间尤其会对业务应用程序产生重大影响。 以最佳方式，运行 SAP VM 的所有计算元素都尽可能靠近。 此选项并非在每个组合中都可行，Azure 可能不知道要保留哪些 VM。 在大多数情况下和区域中，默认放置满足网络往返延迟要求。

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

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

在大多数情况下，不使用邻近放置组的 VM 应是 SAP 系统的默认部署方法。 此默认值尤其适用于区域 (单个可用性区域) 和跨区域 (VM，这些 VM 分布在两个可用性区域) SAP 系统的部署之间。 仅出于性能原因需要时，应将邻近放置组限制为 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 后，无法更改网络接口卡 (NIC 等资源的虚拟网络分配，) VM。 若要更改虚拟网络或 子网地址范围 ，可能需要将所有已部署的资源移到其他子网。

网络设计应满足 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域/Azure Active Directory) 和管理访问。
  • 根据需要，通过公共终结点提供对 和 的访问权限。 示例包括针对高可用性中的 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 虚拟网络中资源的名称解析中介绍了用于在 Azure 中本机实现名称解析（而不是通过设置自己的 DNS 服务器）的多个选项。

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

IP 地址分配

在 VM 的 NIC 存在期间，NIC 的 IP 地址仍被声明和使用。 该规则适用于 动态和静态 IP 分配。 无论 VM 是否正在运行或已关闭，它都保持不变。 如果删除 NIC、子网更改或分配方法更改为静态，则会释放动态 IP 分配。

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

注意

在辅助 IP 配置中， 不支持 Azure 负载均衡器的浮动 IP 地址。 Azure 负载均衡器由具有 Pacemaker 群集的 SAP 高可用性体系结构使用。 在此方案中，负载均衡器启用 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 列出了 SAP Application Performance Standard (SAPS) 基准和限制（如果适用）衡量的所有经过认证的 Azure VM 及其性能。 经过 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 代的 Azure VM 系列。 本文还列出了 Azure 中第 1 代和第 2 代 VM 之间的功能差异。

部署 VM 时，所选的操作系统映像将确定 VM 是第 1 代 VM 还是第 2 代 VM。 Azure (Red Hat Enterprise Linux、SuSE 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 的基本 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 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 文件共享。 请参阅 SAP 说明 2015553 ，了解在 Azure 中的 SAP 系统中对存储层使用第三方服务时对 SAP 支持的限制。

由于网络共享通常具有关键性质，并且它们通常是设计 (中针对文件接口) 的高可用性) 或处理 (的单一故障点，因此建议依赖每个 Azure 本机服务来获取其自己的可用性、SLA 和复原能力。 在规划阶段，请务必考虑以下因素：

  • NFS 或 SMB 共享设计，包括每个 SAP 系统 ID (SID) 、每个布局和每个区域使用的共享。
  • 子网大小调整，包括专用终结点或Azure NetApp 文件等服务的专用子网的 IP 要求。
  • 到 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 (应用程序和 DBMS) 的所有 VM 创建另一个 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 服务可以选择性地包含该服务的成本。 此信息包含在服务的定价信息中。

Encryption

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

基础结构资源的加密

默认情况下，Azure 中的托管磁盘和 Blob 存储 使用平台管理的密钥 (PMK) 进行加密 。 此外， (BYOK 自带密钥) Azure 中的 SAP 工作负载支持对托管磁盘和 Blob 存储进行加密。 对于 托管磁盘加密，可以根据公司安全要求从不同的选项中进行选择。 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 网络共享，请仔细查看 SMB 版本的Azure 文件存储和操作系统依赖项，因为配置会影响对传输中加密的支持。

重要

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

SAP 组件的加密

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

  • DBMS 加密
  • 传输加密

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

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

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

重要

有一个谨慎的计划来存储和保护加密密钥是多么重要，这一点不容夸大。 如果没有加密密钥，数据库或 SAP 软件可能不可访问，并且可能会丢失数据。 仔细考虑如何保护密钥。 仅允许特权用户或服务访问密钥。

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

威胁监视和警报

若要部署和使用威胁监视和警报解决方案，请首先使用组织的体系结构。 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 () SCS 和 SAP ERS 实例
    • 数据库服务器

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

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

灾难恢复

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

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

Backup

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

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

  • VM 配置、操作系统和 SAP 应用层 (通过 VM Azure 备份) 托管磁盘上的数据调整大小。 查看 支持矩阵 ，验证体系结构是否可以使用此解决方案。
  • 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 迁移工具。

    与本地迁移相比，在 Azure 中部署而不是基本 VM 迁移更可取且更易于完成。 Azure Center for 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 建立连接和连接。 通常，如果通过 Internet 上的加密网络通道或通过专用 VPN 连接到 SAP，则连接采用 SAProuter 连接的形式。 有关最佳做法和 Azure 中 SAProuter 的示例实现，请参阅 Azure 上的 SAP 入站和出站 Internet 连接中的体系结构方案。

后续步骤