第一部分 SAP on AWS EC2 Auto Recovery

当在AWS平台上进行SAP架构设计时，高可用往往伴随着DR统一考虑，我将SAP on AWS在云端部署的常见架构汇总成以下的四个专题。

本文我将介绍 SAP on AWS在云端部署的常见架构第一种方式

AWS EC2 Auto Recovery

Auto Recovery是Amazon EC2的一项功能，旨在提高实例可用性。当云端物理主机底层硬件发生故障时，通过事先创建CloudWatch的StatusCheckFailed_System（状态检查失败（系统））警报监控EC2实例，在实例运行的物理主机发生底层硬件故障的时候能够自动触发警报，完成相关内容的邮件通知，并以最快时间将实例迁移到健康的物理硬件上，同时保持实例ID、私有IP 、EIP地址以及所有实例元数据不变，整个过程为自动执行，降低对人工干预的需求[2]。整个恢复过程如下图所示：

图2 – Auto Recovery 实现过程

此部署架构优势如下：

1) 架构成本低廉，使用Auto Recovery功能不会产生额外的EC2费用，只要缴纳 CloudWatch一般费用（请参阅CloudWatch 定价页面）。

2) Auto Recovery的实施和维护比较容易。参见配置示例。

3) 切换过程无需人工干预，配合SAP实例参数Autostart=1，将应用在操作系统重启后实现自动拉起。

4) 架构整体RPO = 0，由于Auto Recovery的特性，原有SAP虚拟机会在健康物理硬件上完成启动，所以原有实例的数据不会产生丢失。

5) RTO = Auto Recovery时间+操作系统启动时间+DB和APP的启动和预热时间。

虽然此架构拥有上述优势，但也存在以下劣势：

1) Auto Recovery为硬件层面检测，无法检测应用级的状态。如需进行应用级状态检测，需通过自开发脚本实现。

2) Auto Recovery发生切换后，主机内存中所执行的数据是无法在另外一台主机上完成状态的复制。当前只能完成已有EBS磁盘的重新映射，从而达到数据盘的重新加载。

3) Auto Recovery不支持多可用区，无法通过此功能实现跨可用区的数据容灾。

4) 此功能没有SLA保证，当可用区有空闲同样类型的EC2资源时，才可完成EC2的拉起。

为了能够获取SAP的支持服务且能够成功配置Auto Recovery功能，在系统进行初始化配置时需明确以下内容：

1) 所选实例是否为SAP认证实例。参见：SAP Note 1656099 – SAP Applications on AWS: Supported DB/OS and AWS EC2 products

2) 当前实例是否支持Auto Recovery功能。目前，支持如下主机类型：A1、C3、C4、C5、C5n、M3、M4、M5、M5a、P3、R3、R4、R5、R5a、T2、T3、X1 和 X1e 实例类型。

3) 为了避免由于应用和数据库（SAP分布式部署模式）或两个应用服务器在一台主机硬件上，建议通过配置AWS置放群组来避免[3]。

为了实现EC2触发Auto Recovery后将SAP应用自动拉起，可通过SAP参数AutoStart = 1配置SAP服务自启动（此参数对于SAP Instance 实例同样起作用）。当APP和DB在一台主机时，则需通过编写启动脚本实现数据库和应用的顺序启动。参见：SAP Note 2531906 – Database coming up without restarting。下面通过示例说明SAP和Auto Recovery功能的配置：

假设场景：

1) EC2 机型为X1.16xlarge自带Instance Storage SSD硬盘。

2) 实例上部署SAP HANA database应用。

3) 高可用通过Auto Recovery实现。

以下分别从EC2资源创建、Auto Recovery功能配置、SAP AutoStart功能配置三个方面进行具体操作过程的说明：

1） EC2 资源创建

由于X1.16xlarge自带Instance Storage，此实例如果想启用Auto Recovery功能，需在创建实例时删除自带的Instance Storage。如果当前EC2实例已创建完成，则需将原有EC2进行AMI快照后重新使用此快照进行EC2资源创建。