SAP on AWS 部署架构（引论）

SAP 作为企业核心应用系统，业务对于系统的 RTO/RPO 以及高可用支持的场景通常会有较高的要求。通常 SAP 系统在云上部署会使用 DX、VPC、EC2、EBS、S3 等相关 AWS 基础服务，详情清单如下所示：

图 1 – SAP on AWS 基础服务清单

一般在项目实施初期，进行 SAP 系统架构设计的时候，客户会存在以下疑问：“既然云上 AWS 都已经保证在一个区域内 Amazon EC2 和 Amazon EBS 的正常运行时间百分比至少达到 99.99%，那我们为什么还要部署要采用高可用?”

根据 AWS 推荐设计原则，搭建一个云端应用系统时，基础原则是“design for failure”。也就是设计系统架构的时候，需要考虑到应用系统的每一个层面，包括硬件和软件可能出现的故障，并据此在应用系统架构设计上消除单一故障点，从而实现系统架构的高可用性。

通常，AWS 平台在提到系统架构高可用时，会从以下三个方面进行说明：

1） 云上基础服务的高可用，即 AWS 厂商所提供的 SLA 标准[1]。

2） 企业应用架构高可用，即通过高可用软件，例如 SUSE HAE 实现应用层面的高可用。

3） 企业终端到云上应用访问的高可用，即云上 DX 到线下应用或客户终端的高可用。

AWS 云厂商对于 EC2、EBS 已提供高达 99.99%的 SLA，但如果业务有更高的高可用需求以及更多场景的支持，我们就需要从企业实际的应用架构来考虑，完成高可用架构的设计和实施，从而提升系统整体的高可用性。

在进行高可用架构设计时，首先需要从客户获得以下相关输入，作为未来整体系统架构设计的连续性要求。

1） 客户可以承受的系统不可用或数据丢失的时长，也就是我们片头所提到的 RTO/RPO，其中 RPO 是由于重大事件而可能导致 IT 服务丢失数据的最大目标期限，RTO 是在灾难或中断之后必须恢复业务流程的目标持续时间。

2） 未来架构对于故障场景支持的广度，例如地震、火灾，洪水，龙卷风等自然灾害或单可用区故障。

3） 架构复杂程度，例如使用各软件厂商的已封装好的 HA 解决方案，还是使用利用云原生服务通过脚本来实现。

4） 系统在业务部门的定位，有些企业 ERP 作为财务核心系统优先级会最高，单由于 BW 系统受众为管理层其优先级不低于 ERP 系统。

5） 整个架构所需额外的成本，例如高可用架构所需额外的 AWS 资源以及高可用软件订阅许可等。

因此，设计高可用架构时，需要从系统 RTO/RPO 需求、架构复杂度、优先级、以及成本等多方面统一考虑，最终选择最符合客户需求的架构。

当在 AWS 平台上进行 SAP 架构设计时，高可用往往伴随着 DR 统一考虑，SAP on AWS 在云端部署的常见架构可分为以下几种方式：

1） EC2 Auto Recovery

2） Pilot Light

3） Single AZ HA

4） Multiple AZ HA

为了更好的说明各个类型所适用的场景以及优缺点，后续将创建相关专题来分别说明以上这几种架构方式在 AWS 上的最佳实践以及客户实际使用场景。

（第一部分 SAP on AWS EC2 Auto Recovery)

（第二部分 SAP on AWS Pilot Light）

（第三部分 SAP on AWS 单可用区高可用）

（第四部分 SAP on AWS 跨可用区高可用）

作者介绍：崔新岩，AWS 中国专业服务团队 SAP 顾问，在 SAP 系统架构设计与迁移方面有着丰富的经验。主要为客户提供云上系统架构设计，SAP 上云迁移等咨询服务。

本文转载自 AWS 技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/sap-on-aws-deployment-architecture-intro/