亚马逊AWS官方博客

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 中国专业服务团队SAP顾问,在SAP系统架构设计与迁移方面有着丰富的经验。主要为客户提供云上系统架构设计,SAP 上云迁移等咨询服务。