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