SAP on AWS 部署架构（引论）

本文是 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上的最佳实践以及客户实际使用场景。

亚马逊AWS官方博客