测试 SAP HANA 高可用性部署
此部分介绍备份故障场景，高可用性和灾难恢复解决方案的测试指南及注意事项，以及灾难恢复模拟练习。
备份故障场景和建议
下表概述了 SAP HANA 系统的不同故障场景、发生的风险、可能会出现的数据丢失和最大中断时间。务必确认是哪种故障场景需要从备份中恢复。请注意，根据您的需求和架构，场景的粒度、分类和影响会有所不同。
|
数据保护/灾难恢复 |
故障场景 |
发生时的相对危险性 |
可能的数据丢失 |
最大中断时间 |
影响 |
|
无高可用性 |
资源耗尽或受损（CPU 利用率高/文件系统已满/内存不足/存储问题） |
中 |
约为 0（未提交的事务） |
可避免 |
区域 |
|
高可用性 |
单点故障（数据库） |
中 |
约为 0（未提交的事务） |
检测到故障和失效转移的时间（自动） |
区域 |
|
高可用性 |
可用区/网络故障 |
低 |
约为 0（未提交的事务） |
检测到故障和失效转移的时间（自动） |
区域 |
|
高可用性 |
核心服务失败 |
低 |
o |
视故障而定 |
区域 |
|
灾难恢复。 |
损坏/意外删除/恶意活动/错误的代码部署 |
低 |
故障前的最新一致性恢复点 |
检测到故障和失效转移的时间（手动） |
跨区域 |
|
灾难恢复。 |
区域故障 |
非常低 |
复制延迟 |
检测到故障并决定调用灾难恢复和进行接管的时间 |
跨区域 |
对于未实施高可用性的 SAP HANA 系统，在基础设施级别，某个实例的核心关键组件出现故障是指计算、内存和存储故障。对于与计算或内存相关的故障场景，可能是处理器、内存故障或资源耗尽，例如 CPU 利用率高、内存不足等。如果出现 CPU 或内存问题，我们建议使用以下方法恢复 SAP HANA 系统。
-
使用 Amazon EC2 自动恢复功能或主机恢复，在新主机上启动 SAP HANA 系统。有关更多信息，请参阅 Amazon EC2 恢复选项。
-
使用亚马逊机器映像以及各个 Amazon EBS 卷的快照，创建 Amazon EC2 实例的完整备份。出现任何故障时，请将此完整备份用作黄金映像来启动新实例。
-
实施 Amazon CloudWatch 等监控解决方案，以防止出现涉及 CPU 或内存资源耗尽的故障场景。
您可以调整或升级 Amazon EC2 实例，来支持更多的 CPU 核心数或实例内存大小。有关更多信息，请参阅更改实例类型。
对于 SAP HANA 系统，Amazon EBS 卷可以作为主存储来运行 root、data 或 log 卷。故障场景可能会有不同的情况，例如 Amazon EBS 卷故障、磁盘损坏、数据意外删除、恶意攻击、错误代码部署等。建议使用以下选项来保护您的数据。
-
使用 SAP HANA 备份和还原，通过 Amazon Backint Agent for SAP HANA 将 SAP HANA 数据库备份到 Amazon S3。
-
定期获取服务器的亚马逊机器映像/Amazon EBS 快照。
应配置 Amazon S3 单区域复制来防范同一个区域中的数据丢失。对于灾难恢复，我们建议使用 Amazon S3 跨区域复制，在辅助区域中保存备份/快照来防止主区域出现故障。您可以从最新的一组备份/快照在辅助区域中恢复 SAP HANA 系统。此时的恢复点目标取决于故障发生前的最后一个一致性还原点。
测试指南和注意事项
Pacemaker 集群可以自动对集群成员执行失效转移和失效自动恢复，来帮助您执行计划内停机任务，例如修补 SAP HANA 数据库。在 SAP HANA 数据库操作期间，可能会出现各种计划外停机或故障情况。这些情况包括但不限于以下内容。
-
硬件故障，例如裸机实例上的内存模块故障
-
软件故障，例如因内存不足问题而导致的进程崩溃
-
网络中断
这些故障场景中的大多数都可以使用 SAP HANA 数据库和 Linux 操作系统命令进行模拟。Amazon 基础设施的场景也可以在 Amazon 管理控制台上或使用 Amazon API 进行模拟。有关更多信息，请参阅 Amazon API。
高可用性集群解决方案会持续监控已配置的资源，根据预定义的阈值、依赖关系和目标状态进行检测和响应。SAP HANA Pacemaker 集群配置会有所不同，具体取决于数据库大小、应用程序可用性及其他因素。以下是测试基于 Pacemaker 集群的 SAP HANA 高可用性部署的一些注意事项。
-
基于 Pacemaker 集群的 SAP HANA 高可用性安装，必须在计划内和计划外停机场景中进行检验来验证稳定性。
-
您无需将业务数据加载到 SAP HANA 数据库即可执行初始集群测试。测试的第一次迭代验证集群在各种故障场景下是否按预期运行。在此迭代中，您还可以执行测试用例的初始周期，来查找任何可能的产品或配置问题。
-
第二次测试迭代可在将生产规模数据加载到 SAP HANA 数据库中时执行。主要目标是调整集群的监视程序，来有效地监控超时。
大型 SAP HANA 数据库需要更多时间来启动和停止。如果它们托管在 Amazon 裸机实例上，则重启所需的时间可能会更长。由于这些因素会影响集群行为，因此必须相应地调整集群超时值。
-
一个 SAP 应用程序可能会有多个单点故障，SAP HANA 数据库就是其中之一。SAP 应用程序的可用性取决于所有单点故障面对故障情况时的韧性。整体测试中需要包括单点故障。例如，验证 Amazon 可用区故障场景，其中 SAP 应用程序/NetWeaver 堆栈组件（ASCS）和 SAP HANA 数据库都部署在同一个可用区中。集群解决方案必须能够失效转移到预先配置的资源上，并且必须在目标可用区中恢复 SAP 应用程序。
-
作为最低验证要求，应对包含计划内和计划外停机时间的测试用例进行测试。您还可以包括过去观察到的单点故障场景。例如，年终整合作业会测试实例的内存限制，进而导致数据库崩溃。
有关 Amazon 测试用例中 SLES 上采用 Pacemaker 集群的 SAP HANA 高可用性部署的信息，请参阅测试集群。
有关 Amazon 测试用例中 RHEL 上采用 Pacemaker 集群的 SAP HANA 高可用性部署的信息，请参阅测试集群。
-
Pacemaker 集群解决方案需要虚拟 IP 地址配置用于客户端连接。使用虚拟 IP 地址，运行 SAP 工作负载的实际硬件对客户端应用程序保持透明。发生故障时，连接可实现无缝失效转移。失效转移之后，您必须验证所有预期的 SAP 或第三方接口都能够连接到目标 SAP 应用程序。
您可以先准备一份客户端连接或接口列表，其中包括与目标 SAP 系统的所有关键连接。确定连接配置中需要进行的修改，以指向虚拟 IP 地址或负载平衡机制。测试期间，必须验证在集群执行失效转移之前，每个连接的连接能力、检测新连接所花费的时间以及应用程序设置的锁定丢失情况。有关更多信息，请参阅客户端重定向选项。
-
如果您的 SAP HANA 工作负载具备高可用性和灾难恢复功能，则必须采取其他步骤来执行集群验证。Pacemaker 集群只能看到其集群成员（主和辅助）。集群软件不控制灾难恢复操作（第 3 层/第 3 级）。
在多层 SAP HANA 系统复制设置中触发失效转移并且辅助数据库接管主数据库的角色时，复制将在第 3 级系统上继续进行。但是，一旦原始主系统的故障得到纠正并且系统重新可用时，就需要手动干预才能完成从新的主 SAP HANA 数据库向原始主数据库的反向复制要求。对于不支持多目标复制的 SAP HANA 数据库（低于 SAP HANA 2.0），需要执行这些手动步骤。有关更多信息，请参阅 SAP HANA 多目标复制。
对原始主数据库执行失效自动恢复后，必须执行一些手动步骤才能在第三级站点上重新启用复制。在发布系统用于生产性使用之前，验证这些步骤流程以及每个测试场景中服务启动所花费的时间是非常重要的。