本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 简介
<a name="arch-guide-introduction"></a>

几十年来，为了保护本地部署中的 SAP 工作负载，SAP 客户采用了两种常见模式：高可用性和灾难恢复。云计算的出现带来了全新的机遇，促使客户开始思考使用现代化架构和技术来重塑 SAP 的 HADR 功能。

我们先回顾一下 SAP 的系统设计，以及在 SAP 的 n 层架构中包含的单点故障。

## SAP NetWeaver 架构单点故障  
<a name="arch-guide-sap-netweaver-architecture-single-points-of-failure"></a>

 **图 1：SAP 单点故障** 

![\[SAP 单点故障\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-1.png)


图 1 显示了典型的 SAP NetWeaver 架构，它有几个单点故障，如下所示：
+ SAP 中央服务（消息服务器和入队流程）
+ SAP 应用程序服务器
+ NFS（共享存储）
+ 数据库
+ SAP Web Dispatcher

对于 SAP 中央服务和数据库，可以通过部署更多的主机来增加保护。例如，添加另一台主机来运行 SAP 复制入队，可以防止应用程序级锁（入队锁）丢失，而添加另一台主机来运行辅助数据库实例可以防止数据丢失。

但是，这些设计中存在固有的单点故障，限制了轻松利用云原生功能来提供高可用性和可靠性的能力。

Amazon 弹性文件服务 (Amazon EFS) 是一项高度可用且持久的托管 NFS 服务，可在多个物理位置（AWS可用区）主动运行。此服务有助于防御 SAP 单点故障之一。

## 高可用性和灾难恢复
<a name="arch-guide-high-availability-and-disaster-recovery"></a>

高可用性（HA）是系统的属性，用于在定义的时间段内以可接受或商定的水平提供服务，并让最终用户不会察觉到计划外中断。此功能通常通过使用集群服务器来实现。这些服务器提供自动化的故障检测和恢复，或者提供具有高韧性的硬件、可靠测试以及问题和变更管理。

灾难恢复 (DR) 通过在不同的硬件 and/or 物理位置进行可靠且可预测的恢复，防止计划外重大中断（例如站点灾难）。由于损坏或恶意软件导致的数据丢失被视为逻辑灾难事件。这种问题通常采用单独的解决方案来解决，例如从最新的备份或存储快照中恢复。逻辑灾难恢复并不一定意味着失效转移到另一个设施。

从有记录和可衡量的数据点的角度来看，HADR 要求通常按以下方式定义：
+  **正常运行时间**是给定时段（每月或每年）内正常运行时间的百分比。
+  **平均恢复时间（MTTR）**是从故障中恢复所需的平均时间。
+  **恢复服务（RTS）**是指为用户恢复系统服务所花费的时间。
+  **恢复时间目标（RTO）**是系统或服务出现停机、解决方案进行恢复，然后服务重新可供使用的可以接受的最大总时间长度。
+  **恢复点目标（RPO）**是指企业能够接受的数据丢失量，用时间表示。这是出现故障的时间与恢复点之间的最长时间间隔。

 **图 1：SAP 单点故障** 

![\[从破坏性事件中恢复\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-2.png)


≈

## 本地部署模式与云部署模式
<a name="arch-guide-on-premises-vs.-cloud-deployment-patterns"></a>

传统上，如果客户具有高可用性要求，就会将其主要计算容量部署在单个数据中心或托管设施中，通常是在数据中心的两个独立的计算机室或机房中，这些位置具有不同的冷却和电源系统并具备高速网络连接。一些客户会运行两个近距离的托管设施，这些设施具备独立的计算容量，但又足够近，不会受到网络延迟的影响。

为了满足灾难恢复需求（前面的情景意味着不可预见的场所故障风险更高），许多客户会扩展其架构，在备用位置存储数据副本，并提供额外的闲置计算容量。主位置与备用位置之间的距离通常会导致需要异步传输数据，这会影响恢复点目标。对于运行 SAP 的许多行业和公司而言，这是用于实现高可用性和灾难恢复的标准且普遍接受的架构模式。

 **图 3：本地部署灾难恢复** 

![\[本地部署灾难恢复\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-3.png)


图 3 举例说明了客户在本地部署中通常采用的方法。在**地点 1** 中，客户有两个托管设施，通常分隔在相同数据中心内的不同计算机室或机房内，客户在其中为 SAP 单点故障部署高可用性架构。**地点 2** 是用于灾难恢复的地点，在**地点 1** 的两个托管设施都出现严重故障时，SAP 系统将在其中恢复。

将 SAP 工作负载迁移到云提供商的客户仍会恢复到该架构，并将其映射到AWS区域和可用区 (AZs)，如图 4 所示。虽然这种架构可以用于您的环境，但没有遵循 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)，该框架可帮助云架构师为应用程序构建安全、高性能、高韧性和高效的基础设施。

 **图 4：本地到AWS区域的映射方法** 

![\[本地部署数据中心映射到区域的示例\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-4.png)


AWS在区域和可用区中按地理位置隔离设施。对于主计算容量，多可用区方法在确保间隔一定距离的同时维护性能。这种方法（图 5）大幅降低了某个地点出现故障的风险。

 **图 5：本地与AWS区域映射的替代方法** 

![\[本地数据中心映射到区域的替代方法\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-5.png)


在显著降低了主计算容量的地点故障风险后，可以根据业务需求评估是否需要第二个区域。您可以使用在相同或不同的区域快速部署所需的容量AWS。不会再出现空闲硬件的问题。利用跨区域复制，数据备份可以存储在亚马逊简单存储服务 (Amazon S3) 的AWS单个区域或AWS多个区域中。这种架构可以实现简化并且现成可用（图 6）。

 **图 6：单AWS区域方法** 

![\[单区域方法\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/arch-guidance-6.png)


除了考虑基础设施或托管设施故障的影响外，还需要考虑的另一种情况是由于意外或恶意的技术活动所导致的业务数据丢失。

意外或恶意技术活动导致的业务数据丢失称为*逻辑灾难恢复*。出现这种情况时，需要有相关决策来从正常的本地副本恢复业务数据。为此需要制定决策，确定数据的存储位置，以及发生*逻辑灾难恢复*事件时如何使用数据。

本指南的下文中将详细介绍关键架构指南、架构模式以及为满足可用性和可靠性要求而需要考虑的决策。