SAP on AWS 在云端部署的常见架构第一部分

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

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

（第二部分 SAP on AWS Pilot Light）

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

（第四部分 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 实现过程

此部署架构优势如下：

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

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

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

假设场景：

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

1） EC2 资源创建

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

2） Auto Recovery 功能配置

如在 EC2 创建过程中没有删除自带 Instance Storage，后续 Auto Recovery 将无法配置， Recovery 选项会产生置灰无法选择的情况，如下图所示：

3） SAP AutoStart 功能开启

更多信息请参考

[1] EC2 SLA 说明：https://aws.amazon.com/cn/ec2/faqs/

[2] AutoRecovery 说明：https://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingRecoverActions

[3]置放群组说明：https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/placement-groups.html

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

本文转载自 AWS 技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/sap-on-aws-ec2-auto-recovery/