SAP on Amazon部署必知必会

一．前言

您是否计划将SAP应用程序迁移到SAP HANA平台或使用SAP HANA进行新项目的实施？如果是这样，您可能会想知道Amazon Web Services（亚马逊云科技）提供什么选项来运行SAP HANA工作负载。在这篇博文中，我想讨论SAP HANA所需的核心基础架构组件以及亚马逊云科技提供的构建模块，以帮助您构建运营在亚马逊云科技上的以SAP HANA数据库为核心的SAP系统。通过此文，可以帮助您了解概念层面的部署选项。

通常，内存、计算、存储、网络是SAP HANA所需的四个关键基础架构组件，也是SAP on Amazon 实例选型考虑的必要因素。其中，内存是对HANA实例进行选型考虑的最重要的因素，CPU、存储和网络的需求根据内存大小预设或派生。例如，根据内存大小，亚马逊云科技会提供相应的经SAP认证的实例类型，其CPU核数按照内存大小进行匹配。关于存储，无论内存大小如何，您需要根据SAP HANA硬件配置检查工具（HWCCT）指南（也可以参考SAP note 1943937 – Hardware Configuration Check Tool – Central Note提及的内容）中的要求去计算满足HANA对于存储大小和性能的要求。最后，对于网络，特别是对于横向扩展情况，不论内存大小，您都需要能够在SAP HANA节点之间至少支持9.5 Gbps的网络吞吐量。

在过去的几年中，Amazon与SAP紧密合作，以验证在Amazon平台上运行SAP HANA工作负载的计算和存储配置。我们如何实现这个目标的呢？答案是，Amazon已经设计了具有不同内存大小经过SAP认证的Amazon Elastic Compute Cloud（Amazon EC2）实例，以满足SAP对SAP HANA的所有严格的性能要求。此外，Amazon Elastic Block Store（Amazon EBS）提供高性能的存储，满足HANA对读写I/O的性能要求。

下面我们来详细介绍SAP on Amazon云平台的配置选项，高可用及灾备，备份与恢复，系统部署和迁移，以及监控方面的话题。

二．部署选项

1. CPU和内存

亚马逊云科技提供了多种种EC2实例类型来支持不同类型的工作负载。有多种EC2实例系列非常适合SAP HANA工作负载。例如，内存优化的M4、R3、R4、R5和R6实例以及高内存X1、X2以及U系列实例。这些实例系列是针对HANA工作负载专门打造的。这些实例系列为您提供了运行SAP HANA工作负载的各种选项。对于在线分析处理（OLAP）系统的工作负载（例如，HANA上的SAP Business Warehouse，SAP BW/4 HANA，数据集市等），实例垂直扩展能力从244 GiB到2 TB、4TB以及24TB，而水平扩展能力可以一直到扩展到100 TB，并被SAP完全支持，我们已经在Amazon实验室中成功测试了多达25个节点的部署或总共100 TB的内存。对于在线交易处理（OLTP）系统的工作负载（例如，HANA上的SAP Business Suite，SAP S4/HANA，SAP CRM等），您现在可以从244 GiB垂直扩展到4TB以及24TB。

随着Amazon不断推出最新CPU的新实例类型，我们将与SAP密切合作，为这些SAP HANA新一代实例进行认证。通过SAP认证和支持的SAP HANA硬件“认证IaaS平台”目录页面，您可以根据项目需要选择用于SAP HANA工作负载所需的Amazon实例类型。在非生产工作负载的给定实例系列中，您可以随时使用较小的实例，例如R3.8xlarge，R4.8xlarge、R5.4xlarge、R6i.12xlarge等，以降低总体拥有成本（TCO）。请记住，这些是云原生实例，使您可以灵活地将SAP HANA系统的内存空间从64GB无缝更改为2TB。反之亦然，几分钟内即可实现SAP HANA实施的前所未有的灵活性。

以下图表展示了SAP HANA从纵向和横项两个维度展示的的HANA实例类型。

其次，我们也对新一代Amazon EC2 HANA实例X2与上一代实例类型X1进行了相关的性能比较。我们可以看到，在CPU、内存配置基本一致的情况下，X2实例较X1实例类型的SAPs值有了将近一倍的提升，同时我们的成本还较X1实例有所下降，如下图表所示。相关的比较说明请参考SAP的官方文档之描述备注2提及的内容。

X2idn实例系列	X1实例

X2iedn实例系列	X1e实例系列

下表展示了针对SAP生产系统，HANA可以选择的X2、X1、r6、r5部分实例：

下表展示了针对SAP开发、测试系统，HANA可以选择的r6、r5、r4部分实例：

备注1：- 关于SAP ON Amazon的认证的实例类型请参考以下链接。

经SAP认证的实例详细信息链接，在Amazon官网的访问链接如下：

https://thinkwithwp.com/cn/sap/instance-types/

经SAP官网认证的Amazon实例列表，在SAP官网的访问链接如下：

https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23

备注2：X2与X1性能介绍

https://www.sap.com/about/benchmark/measuring.html

https://launchpad.support.sap.com/#/notes/1656099

2. 存储

提供6种不同的存储类型供SAP EC2实例选择，这六种不同的存储包括：GP2, GP3, IO1, IO2, ST1, SC1 。其中GP2, GP3, IO1, IO2这四类以固态驱动器（SSD）为基础的存储服务，他们属于EBS块存储，为SAP EC2实例提供持久的、可靠的存储卷，作为原始块设备呈现给EC2实例。EBS卷的功能类似于存储区域网络（SAN）设备，与EBS卷的所有通信都通过Amaon提供给Amazon EC2实例的存储网络进行。另外，Amazon还提供对象存储S3、Glacier来实现SAP的系统的备份恢复；对于SAP应用服务器所需的网络文件共享，通过使用EFS与FSx来实现。

EBS卷存储的特性如下：

gp3 卷可以在任何卷大小下提供 3000 IOPS free和 125 MB/s free 的基准性能。追求更高性能的客户可在另外付费后扩展到高达Max IOPS/Volume 16,000 和 Max IOPS/Volume 1,000 MB/s的最佳性能。gp3 卷可达到个位数毫秒级的延迟，同时获得预置性能水平的时间可达到 99%。
通用SSD（gp2）卷类型，您可以使用高达每卷250 MB/s的吞吐量。
IOPS SSD（io1）io1 旨在实现从最高 50 IOPS/GB 的稳定基准性能到 64000 IOPS 的极限性能，每个卷的吞吐量最高可达1000MB/s，为了最大限度地利用 io1 的优势，我们推荐使用EBS优化型 EC2 实例。
io2 是新一代预置 IOPS SSD卷，在与上一代卷 (io1) 价格相同的情况下，可为预置的每GB提供高达100倍的持久性 (99.999％)，以及高10 倍的IOPS存储比 (500 IOPS)。io2是一个高性能的 EBS 存储选项，旨在用于具有较高持久性要求的业务关键型、I/O 密集型数据库应用程序，例如 SAP HANA。

针对SAP on Amazon,EBS卷存储的选择如下：

Amazon建议针对SAP EC2实例选择存储时，如果对I/O要求不高时，可以选择使用GP2/GP3卷类型，但优先选择GP3存储；
如果使用GP2/GP3无法达到I/O性能要求或可用性级别时，建议选择使用IO1或IO2；
为了满足SAP生产系统的高I/O要求，建议对HANA数据库使用EBS优化的EC2实例。为了进一步增加一个文件系统可以提供的IOPS总数，可以使用软件RAID（如逻辑卷管理器）将多个EBS卷分条到单个文件系统中。每个EBS卷都通过Amazon底层基础架构中的镜像来防止物理驱动器故障。因此，不建议使用高于RAID-0的软件RAID级别。

HDD卷类型特性及部署选项如下：

st1 卷由普通硬盘 (HDD) 提供支持，非常适用于频繁访问且拥有大型数据集I/O 的吞吐量密集型工作负载，例如SAP BW/4 HANA数据仓库以及 ETL工作负载。这些卷提供吞吐量方面的性能（以 MB/s 为单位），能够突增至每TB 250MB/s，其中基准吞吐量为每TB 40MB/s，最大吞吐量为每卷500MB/s
sc1 由普通硬盘 (HDD) 提供支持，它非常适用于非频繁访问且拥有大型冷数据集的工作负载。与st1 类似，sc1也提供突增模型。这些卷能突增至每 TB 80MB/s，其中基准吞吐量为每 TB 12MB/s，最大吞吐量为每卷 250MB/s。

对象存储S3 和Glacier特性及使用选择：

S3 存储类包括：S3 Intelligent-Tiering，可自动为具有未知或不断变化的访问模式的数据节省成本；
S3 Standard，适用于频繁访问的数据；S3 Standard-Infrequent Access (S3 Standard-IA)
S3 One Zone-Infrequent Access (S3 One Zone-IA)，适用于访问频率较低的数据；
S3 Glacier Instant Retrieval，适用于需要即时访问的归档数据；
S3 Glacier Flexible Retrieval（前称为 S3 Glacier），适用于很少访问且不需要即时访问的长期数据；
Amazon S3 Glacier Deep Archive (S3 Glacier Deep Archive)，适用于以最低的云存储成本进行长期归档和数字保存。

如果您具有现有 Amazon 区域无法满足的数据驻留要求，您可以使用 S3 Outposts 存储类将您的 S3 数据存储在本地。Amazon S3 还提供了在整个数据生命周期内管理数据的功能。设置 S3 生命周期策略之后，无需更改您的应用程序，您的数据将自动传输到其他存储类。

通常，我们推荐使用S3来定期存放备份周期内的HANA备份、SAP应用服务器的备份，使用S3的生命周期管理策略把过期的备份转移到成本更低的Glacier。

弹性文件系统（EFS）作为NFS服务：

基于Linux的SAP系统可以将EFS用作所有区域（至少有3个可用性区域）中/sapmnt、/usr/SAP/trans和ASCS实例目录的高可用性共享文件系统
Amazon FSx for Windows File Server使您能够轻松地为应用程序和最终用户启动和扩展可靠、高性能和安全的共享文件存储。使用Amazon FSx，您可以启动可跨多个可用性区域（AZ）的高持久性和可用性文件系统，并且可以使用行业标准服务器消息块（SMB）来访问/sapmnt、/usr/SAP/trans和ASCS实例目录。

3. 网络

网络性能是SAP HANA的另一个关键因素，尤其是针对OLAP横向扩展系统。每个EC2实例都有自己特定的网络带宽，而像X2、X1这样的一些实例系列可为您的SAP HANA需求提供高达100 Gbps的网络带宽。

此外，许多实例为Amazon EBS存储提供专用网络带宽。例如，X2实例（x2iedn.32xlarge）提供100 Gbps的网络带宽和80 Gbps的专用存储带宽。 R6（r6i.32xlarge）除了专用的40 Gbps存储带宽外还提供50 Gbps的网络带宽。

下表简要列举了经SAP认证的几个有代表性的实例的网络功能。

4. 操作系统

SAP目前支持在SUSE Linux Enterprise Server（SLES）或Red Hat Enterprise Linux（RHEL）上运行SAP HANA，AMAZON都支持这两种操作系统版本。此外，您可以在Amazon Marketplace中选择SAP HANA特定的SUSE和Red Hat AMI来快速开始部署您需要的操作系统版本。您还可以选择携带自己的操作系统许可证在Amazon上部署您的操作系统。

5. 高可用性

HA和DR是在SAP HANA上运行的关键业务应用程序的关键。Amazon提供了几个构建模块，包括全球各个Amazon区域和每个Amazon区域内的多个可用区域，您可以根据RTO和RPO的要求设置HA和DR解决方案。无论您是寻求基于成本优化的解决方案还是基于停机时间优化的解决方案，SAP HANA HA/DR架构都有一些独特的选择，请查看SAP HANA HA/DR 指南，以了解有关这些更多信息。通常我们推荐使用SUSE Linux或者RedHat Linux的最佳实践来部署SAP on Amazon的相关产品。下面是SUSE Linux推荐的SAP ON Amazon的高可用的部署方案示例介绍。

高可用方案建设方案介绍：ASCS使用SUSE Linux pacemaker集群技术实现ASCS与ERS的高可用；HANA通过SUSE Linux pacemaker集群技术结合HANA的System Replicate数据复制技术实现HANA数据库可靠性、一致性、业务的可持续性运营。在这个高可用解决方案中，通过SAP认证的Amazon EC2实例，Amazon高性能网络，高性能EBS存储，为SAP量身定制优化的EFS存储，实现了ASCS与HANA无单点故障运行（SPOF）。

6. 灾备系统

灾备系统建设方案：通常我们需要对生产系统的SAP应用服务器和HANA数据库服务器根据客户需求设计对应的灾备解决方案，满足系统在地震、洪水、战争或者火灾等不可抗外力因素发生的时候有一套对应的灾备解决方案，满足生产系统的可靠运营，保证业务的持续运营。Amazon通常有4种不同的灾备解决方案（包括备份恢复模式、守夜灯模式、温备模式、多站多活模式）。本博文简要介绍前两种常用的针对SAP生产系统的灾备方案选项。

对于选项一，通过Amazon Backint Agent进行生产系统的备份，然后定期把备份通过Amazon S3传输到灾备系统的S3，随后恢复备份数据到灾备系统HANA数据库,选项一对RPO和RTO要求不高。

选项二，通过HANA的异步复制技术，实现灾备系统与生产系统的数据一致性。选项二对于RTO和RPO要求比较高，比如RPO<=10分钟,RTO根据实际的网络切换、接口切换等时间来决定。

下图为两种不同灾备系统建设的架构示意图：

7. 快速部署SAP on Amazon

您可能会问：“Amazon为SAP HANA提供的这些构建模块非常好，但是如何将这些组件放在一起构建一个满足SAP on Amazon要求的系统？”Amazon客户几年前就问了这个问题，这就是为什么Amazon构建了Amazon SAP HANA快速启动。此快速启动使用Amazon CloudFormation模板（基础架构作为代码infrastructure as code）和自定义脚本来帮助配置Amazon基础架构组件，包括存储和网络。快速启动有助于设置SAP HANA安装的操作系统先决条件，并且可以在携带自己的软件和许可证时安装SAP HANA软件。快速启动是可以在全球许多Amazon地区使用的自助服务工具。在不到一小时的时间内，可以一致、可预测和可重复的方式为您的SAP HANA系统提供基础设施，无论是单节点还是多节点的横向扩展系统。

我们建议您使用Amazon快速启动为您的SAP HANA部署配置基础架构。但是，如果无法使用快速启动（例如，因为要使用自己的操作系统映像），则可以手动配置SAP HANA环境，您需要确保并遵循快速入门指南中有关存储和实例类型的建议。为此，我们也推荐您遵循“SAP HANA on Amazon 手动部署指南”中的建议去部署您的SAP系统。

8. 备份和恢复

备份存储选择：以可靠的方式备份和恢复SAP HANA数据库的能力对于保护业务数据至关重要。您可以使用SAP HANA原生工具将数据库备份到EBS卷，并最终将备份的文件移动到Amazon Simple Storage Service（Amazon S3），以提高其持久性。Amazon S3是高度可扩展和持久的对象存储服务，Amazon S3中的对象可以冗余地存储在一个区域内的多个设施中，并提供11个9的持久性。

备份方案选择：您还可以选择使用与Amazon S3集成的企业级备份解决方案，如Commvault，EMC NetWorker，Veritas NetBackup和IBM Spectrum Protect（Tivoli Storage Manager）这些合作伙伴解决方案可以帮助您将SAP HANA数据库直接备份到Amazon S3，并使用企业级软件管理备份和恢复。在Amazon上，我们也为SAP HANA量身定制打造了Amazon Backint Agent 。

Amazon Backint Agent备份及恢复工作原理示意图如下：

Amazon Backint Agent 是经过SAP认证的备份和恢复应用程序，适用于在 Amazon EC2实例上运行的 SAP HANA 工作负载。Amazon Backint Agent作为独立应用程序运行,该应用程序与现有工作流集成，将SAP HANA 数据库备份到Amazon S3,备份与恢复工具可以使用 SAP HANA Cockpit、SAP HANA Studio 和 SQL 命令等。Amazon Backint Agent支持 SAP HANA 数据库的完整、增量和差异备份。此外，您可以将日志文件和目录备份到Amazon S3。Amazon Backint Agent在SAP HANA数据库服务器上运行，日志备份和目录通过Amazon Backint Agent存放到S3。如果需要恢复 SAP HANA数据库，SAP HANA使用SAP HANA Cockpit、SAP HANA Studio 和 SQL 命令，通过Amazon Backint Agent 读取存储在S3存储桶中的目录和文件，发起请求以从S3恢复所需的文件。

9. 系统监控

使用Amazon CloudWatch Application Insights 来为 SAP HANA数据库设置监控，您可以使用 Amazon CloudWatch Application Insights 自动控制面板可视化展示问题详细信息、加快故障排除速度及缩短SAP HANA数据库的平均解决时间(MTTR)。

1. 配置告警阈值：CloudWatch Application Insights会自动创建由告警监控的Amazon CloudWatch指标，以及该指标的阈值。当该指标在指定数量的评估期内超出阈值，告警将变为 ALARM （告警）状态。

2. SAP HANA 的异常检测：对于特定的 SAP HANA 指标（例如线程数量），CloudWatch应用统计和机器学习算法来定义阈值。这些算法只需最少的用户干预，即可持续分析 SAP HANA 数据库的指标，确定正常基线和表面异常。算法会生成一个异常检测模型，该模型生成表示正常指标行为的预期值范围。异常检测算法将指标的季节性变化和趋势变化考虑在内。季节性变化可以是每小时、每天或每周，如下图为 SAP HANA CPU 使用率示例所示。

3. 查看和排查 CloudWatch Application Insights 检测到的问题

另外，我们也可以通过使用无服务器架构结合CloudWatch对SAP应用服务器进行监控。目前，sap-monitor application repository还没落地中国区域，一旦落地后，我们就可以参考博文里提到的过程进行配置。（SAP monitoring: A serverless approach using Amazon CloudWatch）。我们可以通过下面的操作步骤去检查sap-monitor有没有落地中国区域：

Go to Serverless Application Repository from AWS Console and then go to Available applications → Public Applications and search for sap-monitor

下图展示如何去Amazon控制台查找sap-monitor

10. 系统迁移

在实际迁移的时候，您可以使用SAP Software Provisioning Manager（SWPM）和Software Update Manager（SUM）的Database Migration Option（DMO）等标准SAP工具集，或第三方迁移工具来把在其他数据库上运行的SAP应用程序迁移到Amazon上的SAP HANA。SAP到Amazon迁移过程与典型的本地迁移方案没有太大的不同。在IDC环境中，通常源系统和目标系统驻留在同一IDC数据中心。当您迁移到Amazon时，唯一的区别是您的目标系统驻留在Amazon上，因此您可以将Amazon视为自己的数据中心的扩展。还有一些选项可用于在迁移过程中将导出的数据从本地数据中心传输到Amazon。

如下图为我们展示了实施SAP on Amazon同构或者异构系统迁移时，根据客户源系统的不同情况使用到的迁移工具与方法。

另外，Amazon也提供非SAP的工具比如Amazon CloudEndure来为SAP从IDC机房迁移到Amazon或者从Amazon的不同区域迁移到另一个区域，或者从不同的云迁移到Amazon，也支持Amazon不同账号间的迁移。当然，也可以通过CloudEndure实现灾备，请关注另一博文（SAP Disaster Recovery Solution Using CloudEndure）提及的内容介绍。

下面是一个在Amazon上不同账号间采用CloudEndure从源系统迁移到目标系统的一个示例，这个例子在博文（Automating SAP migrations using CloudEndure Migration）中提到如何实施的过程，请大家参阅。

通过CloudEndure迁移SAP系统的步骤如下：

注册CloudEndure的迁移帐户在CloudEndure官网上
设置项目并定义复制设置
在源系统的实例上安装CloudEndure代理
监控复制和更新蓝图
启动测试实例
执行迁移切换
执行SAP迁移后的相关步骤
执行清理工作

其他注意事项包括操作，调整EC2实例大小，如何缩放EC2，与其他Amazon服务（如Amazon CloudWatch）的集成，以及大数据解决方案。要了解有关在Amazon上运行SAP工作负载的更多信息，请参阅Amazon网站上列出的白皮书。

最后，如果您需要一个超出了目前可用规模的可扩展系统，请与我们联系。我们很乐意与您讨论您的要求，并与您一起实施。

三．总结

本博客从SAP on Amazon的部署选项，包括内存、CPU、存储、网络、操作系统的介绍，让您明白如何选择一套适合SAP系统所需要的EC2实例；通过对SAP高可用、灾备的介绍，帮助您打造出一个满足业务高可用、高可靠的，具备容灾能力的一个健全的SAP系统；通过对系统监控、备份恢复的介绍，让您明白Amazon如何帮助您实现安全、自动化的运维；通过Amazon的部署工具和和迁移工具，让您快速高效的把SAP系统部署、迁移到Amazon。

亚马逊AWS官方博客