通过

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

SAP NetWeaver 的高可用性体系结构和方案

  • 项目

术语定义

高可用性：指的是一系列技术，这些技术通过相同数据中心内受冗余、容错或故障转移保护的组件，为 IT 服务提供业务连续性，以最大程度减少 IT 中断的情况。 在本例中，数据中心驻留在一个 Azure 区域内。

灾难恢复：也是指最大程度减少 IT 服务中断及其恢复，但可在彼此相距数百英里的不同数据中心内执行操作。 在我们的示例中，数据中心可能位于同一地理位置的多个 Azure 区域，也可能位于你以客户身份创建的位置。

高可用性概述

Azure 中的 SAP 高可用性可以分为三种类型：

  • Azure 基础结构高可用性：

    例如，高可用性可以包括计算 (VM)、网络或存储，以及提高 SAP 应用程序可用性的优点。

  • 利用 Azure 基础结构 VM 重启来保护 SAP 应用程序：

    如果你决定不在 Linux 上使用 Windows Server 故障转移群集 (WSFC) 或 Pacemaker 等功能，则可利用 Azure VM 重启。 如果 Azure 物理服务器基础结构和整个基础 Azure 平台出现计划内和计划外停机的情况，它会还原 SAP 系统中的功能。

  • SAP 应用程序高可用性：

    要实现完整的 SAP 系统高可用性，必须保护所有关键的 SAP 系统组件。 例如：

    • 冗余 SAP 应用程序服务器。
    • 唯一的组件。 一个示例可能是单点故障 (SPOF) 组件，如 SAP ASCS/SCS 实例或数据库管理系统 (DBMS)。

Azure 中的 SAP 高可用性与本地物理或虚拟环境中的 SAP 高可用性不同。

不同于 Windows，Linux 没有集成 sapinst 的 SAP 高可用性配置。 有关 Linux 的本地 SAP 高可用性的详细信息，请参阅高可用性合作伙伴信息。

Azure 基础结构高可用性

单实例虚拟机的 SLA

目前存在一个使用高级存储的 99.9% 的单一 VM SLA。 若要大致了解单一 VM 可用性的情形，请计算可用的不同 Azure 服务级别协议的乘积。

计算的基数是每月 30 天，即 43,200 分钟。 例如，0.05% 停机时间就相当于 21.6 分钟。 像往常一样，不同服务的可用性按以下方式计算：

(可用性服务 #1/100) x (可用性服务 #2/100) x (可用性服务 #3/100) *…

例如：

(99.95/100) x (99.9/100) x (99.9/100) = 0.9975，即总体可用性为 99.75%。

同一个可用性集中虚拟机的多个实例

对于在同一可用性集中部署两个或更多实例的所有虚拟机，我们保证你至少在 99.95% 的时间内有至少一个实例的虚拟机连接。

当两个或多个 VM 同属一个可用性集时，基础 Azure 平台将为可用性集中的每个虚拟机分配一个更新域和一个容错域。

  • 更新域保证在计划内的 Azure 基础结构维护期间，不会同时重新启动多个 VM。 一次只重新启动一个 VM。
  • 容错域保证 VM 部署在不共享通用电源和网络交换机的硬件组件上。 当服务器、网络交换机或电源发生计划外故障时，只会有一个 VM 受到影响。

有关详细信息，请参阅使用可用性集在 Azure 中管理虚拟机的可用性。

Azure 可用性区域

Azure 正在各个不同的 Azure 区域中推出 Azure 可用性区域的概念。 提供可用性区域的 Azure 区域具有多个数据中心，这些数据中心独立提供电源、冷却和网络设备。 在单个 Azure 区域中提供不同区域的原因是为了能够跨越提供的两个或三个可用性区域部署应用程序。 假设电源和/或网络问题只会影响一个可用性区域基础结构，则 Azure 区域中的应用程序部署仍可完全正常运行。 最终会减少一些容量，因为一个区域中的某些 VM 可能会丢失。 但是，另外两个区域中的 VM 仍可保持正常运行。 Azure 可用性区域中列出了提供局部区域的 Azure 区域。

使用可用性区域时需要注意一些事项。 注意事项列表如下：

  • 不能在可用性区域中部署 Azure 可用性集。 结合可用性集和可用性区域的唯一可能性是使用邻近放置组。 有关详细信息，请参阅将可用性集和可用性区域与邻近放置组结合使用一文。
  • 不能使用基本负载均衡器基于 Windows 故障转移群集服务或 Linux Pacemaker 创建故障转移群集解决方案。 需要改用 Azure 标准负载均衡器 SKU。
  • Azure 可用性区域不能保证一个区域中的不同局部区域之间保持特定的距离。
  • 不同 Azure 区域中不同 Azure 可用性区域之间的网络延迟可能根据 Azure 区域的不同而异。 有时，客户可以合理运行部署在不同局部区域中的 SAP 应用层，因为从业务流程影响度来看，从一个局部区域到活动 DBMS VM 的网络延迟仍可接受。 但在某些客户场景中，一个局部区域中的活动 DBMS VM 与另一个局部区域中的 VM 上的 SAP 应用程序实例之间的延迟可能过高，不能被 SAP 业务流程所接受。 因此，如果延迟过高，则部署体系结构需要与应用程序的主动/主动体系结构或者与主动/被动体系结构不同。
  • 部署到 Azure 可用性区域时必须使用 Azure 托管磁盘。

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

在 Azure 中，具有灵活业务流程的虚拟机规模集提供了一种实现 SAP 工作负荷高可用性的方法，这与可用性集和可用性区域等其他部署框架非常类似。 使用灵活的规模集，VM 可以分布在各个可用性区域和容错域中，使之成为部署高可用性 SAP 工作负荷的合适选项。

具有灵活业务流程的虚拟机规模集让用户可以灵活地在区域内创建规模集或让规模集跨越可用性区域。 在 platformFaultDomainCount>1 (FD>1) 的区域内创建灵活规模集时，规模集中部署的 VM 将分布在同一区域中指定数量的容错域中。 另一方面，跨可用性区域创建 platformFaultDomainCount=1 (FD=1) 的灵活规模集将跨不同区域分布 VM，并且该规模集还会尽量使 VM 分布在区域内的不同容错域中。 对于 SAP 工作负荷，仅支持 FD=1 的灵活规模集。

与传统可用性区域部署相比，使用 FD=1 的灵活规模集进行跨区域部署的优点是，使用该规模集部署的 VM 将尽量分布在区域内的不同容错域中。 为避免与利用邻近放置组来确保 VM 在所有 Azure 数据中心或每个网络脊中可用相关联的限制，建议使用 FD=1 的灵活规模集跨可用性区域部署 SAP 工作负荷。 这种部署策略可确保部署在每个区域的 VM 不局限于单个数据中心或网络脊，而且所有 SAP 系统组件（如数据库、ASCS/ERS 和应用层）都局限于区域级别。

因此，对于跨可用性区域的新 SAP 工作负荷部署，我们建议使用 FD=1 的灵活规模集。 有关详细信息，请参阅 SAP 工作负载的虚拟机规模集文档。

虚拟机计划内和计划外的维护

两种类型的 Azure 平台事件都可能会影响虚拟机的可用性：

  • 计划内维护事件是由 Microsoft 对基础 Azure 平台进行的定期更新。 这些更新将提高虚拟机在其上运行的平台基础结构的总体可靠性、性能与安全性。
  • 计划外维护事件发生于虚拟机所在硬件或物理基础结构出现某类故障的情况。 此类故障可能包括：本地网络故障、本地磁盘故障，或者其他机架级别的故障。 检测到此类故障时，Azure 平台会自动将虚拟机从所在的不健康物理服务器迁移到健康的物理服务器。 此类事件很少见，但也会导致虚拟机重启。

有关详细信息，请参阅在 Azure 中维护虚拟机。

Azure 存储冗余

始终复制存储帐户中的数据以确保持久性和高可用性，并且即使遇到临时硬件故障也可满足 Azure 存储 SLA 的要求。

因为 Azure 存储默认保留数据的三个映像，所以没有必要在多个 Azure 磁盘上使用 RAID 5 或 RAID 1。

有关详细信息，请参阅 Azure 存储复制。

Azure 托管磁盘

托管磁盘是 Azure 资源管理器中的一种资源类型，是一项建议的存储选项，用于替代 Azure 存储帐户中存储的虚拟硬盘 (VHD)。 托管磁盘将与其所附加到的虚拟机的 Azure 可用性集自动保持一致。 它们会提高虚拟机以及在其中运行的服务的可用性。

有关详细信息，请参阅 Azure 托管磁盘概述。

建议使用托管磁盘，因为托管磁盘可简化虚拟机的部署和管理。

SAP 工作负荷的不同部署类型的比较

下面是适用于 SAP 工作负荷的各种部署类型的快速摘要。

功能 具有灵活业务流程的虚拟机规模集 (FD=1) 可用性区域 可用性集
部署行为 实例跨 1 个、2 个或 3 个可用性区域，尽量分布在每个区域内的不同机架上 实例跨 1 个、2 个或 3 个可用性区域 实例位于区域内，分布在不同的容错/更新域中
将 VM 和托管磁盘分配到特定的可用性区域 是 是 否
容错域 - 最大分散（Azure 会最大程度地分散实例） 是 否 是的，基于创建时定义的容错域数量。
计算到存储容错域对齐方式 否 No 是
容量预留 是（在 VM 级别分配产能预留） 是 否

注意

SAP 工作负荷的高可用性部署选项

在 Azure 上部署高可用性 SAP 工作负载时，请务必考虑可用的各种部署类型，以及如何跨不同的 Azure 区域（例如跨区域、在单个区域中或在没有区域的地区中）应用这些部署类型。 下表说明了 Azure 区域中 SAP 系统的多个高可用性选项。

系统类型 跨区域中的不同局部区域 在区域的单个局部区域中 在无局部区域的区域中
高可用性 SAP 系统 FD=1 的灵活规模集 具有邻近放置组的可用性集 可用性集
具有邻近放置组的可用性集和可用性区域 FD=1 的灵活规模集（仅选择一个区域） FD=1 的灵活规模集（未定义区域）
可用性区域 可用性集
  • 跨区域中的不同局部区域进行部署：为了获得最高可用性，SAP 系统应跨区域中的不同局部区域进行部署。 这确保了在一个区域不可用的情况下，SAP 系统仍可在另一个区域继续使用。 如果要跨可用性区域部署新的 SAP 工作负荷，建议使用带有 FD=1 部署选项的灵活虚拟机规模集。 这样就可以跨一个区域的不同局部区域部署多个 VM，而不必担心容量约束或放置组。 规模集框架可确保使用规模集部署的 VM 尽量分布在区域内的不同容错域中。 所有高可用性 SAP 组件（例如 SAP ASCS/ERS、SAP 数据库）都分布在不同的区域中，而每个区域中的多个应用程序服务器则尽量分布在不同的容错域中。
  • 在某个区域的单个局部区域中部署：若要按区域将高可用性 SAP 系统部署到具有多个可用性局部区域的位置，在系统的所有组件都必须位于单个局部区域中的情况下，建议使用具有邻近放置组部署选项的可用性集。 使用这种方法，你可以将所有 SAP 系统组件分组到单个可用性区域中，确保可用性集内的虚拟机分布在不同的容错域和更新域中。 虽然此部署会将计算与存储容错域对齐，但无法保证邻近度。 但是，由于此部署选项是区域性的，因此它不支持 Azure Site Recovery 进行区域到区域的灾难恢复。 另外，此选项将整个 SAP 部署限制在一个数据中心，在需要更改 SKU 大小或横向扩展应用程序实例的情况下，这可能会导致容量限制。
  • 在没有局部区域的区域部署：如果在没有任何局部区域的区域部署 SAP 系统，建议使用可用性集。 此选项通过将 VM 放置在不同的容错域和更新域中来提供冗余和容错能力。

重要

需要注意的是，Azure 区域的部署选项仅供参考。 最适合你的 SAP 系统的部署策略取决于你的特定要求和环境。

利用 Azure 基础结构高可用性来保护 SAP 应用程序

如果你决定不在 Linux（支持 SUSE Linux Enterprise Server 12 和更高版本，以及 Red Hat Enterprise Linux 7 和更高版本）上使用 WSFC 或 Pacemaker 等功能，则可利用 Azure 虚拟机重启。 如果 Azure 物理服务器基础结构和整个基础 Azure 平台出现计划内和计划外停机的情况，它会还原 SAP 系统中的功能。

有关此方法的详细信息，请参阅利用 Azure 基础结构 VM 重启来实现 SAP 系统的更高可用性。

Azure IaaS 上的 SAP 应用程序的高可用性

要实现完整的 SAP 系统高可用性，必须保护所有关键的 SAP 系统组件。 例如：

  • 冗余 SAP 应用程序服务器。
  • 唯一的组件。 一个示例可能是单点故障 (SPOF) 组件，如 SAP ASCS/SCS 实例或数据库管理系统 (DBMS)。

以下各部分将讨论如何实现这三个关键 SAP 系统组件的高可用性。

SAP 应用程序服务器的高可用性体系结构

Windows 徽标。 Windows 和 Linux 徽标。 Linux

对于 SAP 应用程序服务器和对话实例，通常不需要特定的高可用性解决方案。 通过冗余实现高可用性，并且可在 Azure 虚拟机的不同实例中配置多个对话实例。 应该至少有两个 SAP 应用程序实例安装在两个 Azure 虚拟机实例中。

根据部署类型（FD=1 的灵活规模集、可用性区域或可用性集），你必须相应地分配 SAP 应用程序服务器实例以实现冗余。

  • platformFaultDomainCount=1 (FD=1) 的灵活规模集：使用灵活规模集 (FD=1) 部署的 SAP 应用程序服务器会跨不同的可用性区域分布虚拟机，且该规模集还会尽量使 VM 分布在区域内的不同容错域中。 这确保了在一个区域不可用的情况下，部署在另一个区域的 SAP 应用程序服务器仍然可用。
  • 可用性区域：跨可用性区部署的 SAP 应用程序服务器可确保 VM 跨不同的区域来实现冗余。 这确保了在一个区域不可用的情况下，部署在另一个区域的 SAP 应用程序服务器仍然可用。 有关详细信息，请参阅使用 Azure 可用性区域的 SAP 工作负荷配置
  • 可用性集：部署在可用性集中的 SAP 应用程序服务器可确保 VM 分布在不同的容错域和更新域中。 跨不同的更新域放置 VM 时，请确保多个 VM 在计划内维护停机期间不会同时进行更新。 而将 VM 放置在不同的容错域中则可确保 VM 不受数据中心内硬件故障或电源中断的影响。 但是，可以在 Azure 缩放单元内的 Azure 可用性集中使用的容错域和更新域的数量是有限的。 如果你不断将 VM 添加到单个可用性集，则会两个或多个 VM 最终将在同一个容错或更新域中。 有关详细信息，请参阅“适用于 SAP NetWeaver 的 Azure 虚拟机计划和实现”文档中的 Azure 可用性集部分。

仅限非托管磁盘：在使用具有可用性集的非托管磁盘时，重要的是要认识到 Azure 存储帐户会成为单一故障点。 因此，必须至少拥有两个 Azure 存储帐户，并在其中至少分配两个虚拟机。 在理想的设置中，运行 SAP 对话实例的每个虚拟机的磁盘都应部署在不同的存储帐户中。

重要

强烈建议使用 Azure 托管磁盘用于 SAP 高可用性安装。 由于托管磁盘会与其所附加到的虚拟机可用性集自动保持一致，因此可增加虚拟机及运行于其上的服务的可用性。

Windows 上 SAP ASCS/SCS 实例的高可用性体系结构

Windows logo. Windows

WSFC 解决方案可用于保护 SAP ASCS/SCS 实例。 可以根据存储类型参考适当的解决方案，具体取决于群集共享配置的类型（文件共享或共享磁盘）。

Linux 上 SAP ASCS/SCS 实例的高可用性体系结构

Linux logo. Linux

在 Linux 上，SAP ASCS/SCS 实例群集的配置取决于操作系统发行版和所使用的存储类型。 建议根据具体 OS 群集框架实施合适的解决方案。

群集 SAP ASCS/SCS 实例的 SAP NetWeaver 多 SID 配置

Windows logo.窗口

使用文件共享和共享磁盘，WSFC 支持多 SID。 有关 Windows 上多 SID 高可用性体系结构的详细信息，请参阅：

Linux logo. Linux

在适用于 SAP ASCS/ERS 的 Linux Pacemaker 群集上支持多 SID 群集，限制为同一群集上五 个 SAP SID。 有关 Linux 上多 SID 高可用性体系结构的详细信息，请参阅：

DBMS 实例的高可用性

在 SAP 系统中，DBMS 服务器也是单一故障点。 因此，通过实施高可用性解决方案来保护数据库非常重要。 DBMS 的高可用性解决方案因 SAP 系统所使用的数据库而异。 请根据数据库按指南操作来实现数据库的高可用性。

数据库 DR 建议
SAP HANA HANA 系统复制 (HSR)
Oracle Oracle 数据防护
IBM DB2 高可用性和灾难恢复 (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE ASE HADR Always On