本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
测试 SAP HANA 高可用性部署
本节涵盖备份失败情景、高可用性和灾难恢复解决方案的测试指南和注意事项,以及灾难恢复模拟练习。
备份失败情景和建议
下表概述了 SAP HANA 系统的不同故障场景、发生的风险、潜在的数据丢失和最大中断时间。确定哪种故障情况需要从备份中恢复,这一点很重要。请注意,场景的粒度、分类和影响将因您的需求和架构而异。
数据保护/灾难恢复 | 故障场景 | 比较发生风险 | 潜在的数据丢失 | 最大中断次数 | Impact |
没有高可用性 | 资源耗尽或受损(CPU 过高utilization/file system full/out of memory/storage问题) | 中 | ~o(未提交的交易) | 可避免 | 区域 |
高可用性 | 单点故障(数据库) | 中 | ~o(未提交的交易) | 是时候检测故障和故障转移了(自动) | 区域 |
可用区/网络故障 | 低 | ~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 卷可以作为操作root
data
或log
卷的主存储。可能存在不同的故障场景,例如 Amazon EBS 卷故障、磁盘损坏、数据意外删除、恶意攻击、代码部署错误等。我们建议使用以下选项来保护您的数据。
-
使用 SAP HANA 备份和还原使用适用于 SAP HANA 的 Backint Agen AWS t 将你的 SAP HANA 数据库备份到亚马逊 S3。
-
定期拍摄服务器的 Amazon Machine Images/Amazon EBS 快照。
应将 Amazon S3 单区域复制配置为防止同一区域的数据丢失。对于灾难恢复,我们建议使用 Amazon S3 跨区域复制进行保存backups/snapshots in the secondary Region, in the event of a failure in the primary Region. You can restore the SAP HANA system in the secondary Region from the last set of backups/snapshots。此处的恢复点目标取决于故障发生前的最后一个一致还原点。
测试指南和注意事项
Pacemaker 集群可以通过自动执行集群成员的故障转移和故障恢复,来帮助您执行计划内停机任务,例如修补 SAP HANA 数据库。在 SAP HANA 数据库操作期间,可能会出现各种计划外情况或故障情况。这些可以包括但不限于以下内容。
-
硬件故障,例如裸机实例上的内存模块故障
-
软件故障,例如由于 out-of-memory问题导致的进程崩溃
-
网络中断
这些故障场景中的大多数都可以使用 SAP HANA 数据库和 Linux 操作系统命令进行模拟。也可以使用 AWS Management Console 或使用来模拟 AWS 基础设施的场景 AWS APIs。有关更多信息,请参阅 AWS APIs。
高可用性集群解决方案会持续监控已配置的资源,以根据预定义的阈值、依赖关系和目标状态进行检测和响应。SAP HANA pacemaker 集群配置可能会有所不同,具体取决于数据库大小、应用程序可用性等因素。以下是测试基于 pacemaker 集群的 SAP HANA 高可用性部署的一些注意事项。
-
基于 pacemaker 集群的 SAP HANA 高可用性安装必须经历计划内和计划外停机情况,以验证稳定性。
-
无需将业务数据加载到 SAP HANA 数据库即可执行初始集群测试。测试的第一次迭代验证集群在各种故障情况下是否按预期运行。在此迭代中,您还可以执行测试用例的初始周期,并找出任何产品或配置问题。
-
第二次测试迭代可以通过将生产规模数据加载到 SAP HANA 数据库中来执行。主要目标是调整集群监视器的有效超时。
大型 SAP HANA 数据库需要更多时间才能启动和停止。如果它们托管在 AWS 裸机实例上,则重启所需的时间可能会更长。由于这些因素会影响集群行为,因此必须相应地调整集群超时值。
-
一个 SAP 应用程序可能有许多单点故障,而 SAP HANA 数据库就是其中之一。SAP 应用程序的可用性取决于所有单点故障能否适应故障情况。在整体测试中包括单点故障。例如,验证 AWS 可用区故障,其中 SAP 应用程序/ NetWeaver 堆栈组件 (ASCS) 和 SAP HANA 数据库都部署在同一个可用区中。群集解决方案必须能够对预先配置的资源进行故障转移,并且必须在目标可用区上恢复 SAP 应用程序。
-
包含计划内和计划外停机的测试用例应作为最低限度的验证进行测试。您还可以包括过去观察到单点故障的场景。例如,年终整合作业会测试实例的内存限制,从而导致数据库崩溃。
有关在 AWS 测试用例中使用 S LES 上的 pacemaker 集群进行的 S AP HANA 高可用性部署,请参阅测试集群。
有关在 AWS 测试用例中使用 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 多目标复制。
在对原始主站点执行故障恢复后,必须执行一些手动步骤才能在第三站点上重新启用复制。在发布系统用于生产性使用之前,必须验证这些步骤的流程以及每个测试场景中服务启动所花费的时间。
-
可以在中配置 SAP HANA 系统复制Active/Active configuration. This configuration utilizes the secondary hardware for read-only purpose. The supported products include SAP S/4 HANA, BW on HANA, and BW4/HANA。
SLES 和 RHEL 支持使用起搏Active/Active SAP HANA system replication setup using pacemaker cluster. Depending on the operating system version, additional steps may be required to set up an Active/Active器集群进行配置。
测试方案将有所不同,包括对只读虚拟 IP 的故障切换和故障恢复行为以及故障切换和故障恢复后能够连接的相应客户机连接的额外验证。
灾难恢复模拟演习指导
必须通过执行手动模拟练习来验证您的灾难恢复设置。通过模拟灾难恢复练习,您可以验证恢复点和时间目标以及调用灾难恢复的步骤。您还可以确定所涉及的各个团队的所有权和任务,并制定详细的计划来路由客户端连接以及建立与中心系统和第三方连接的连接。
调用灾难恢复系统需要其他团队的详细规划和支持,例如专门的网络运营团队。在灾难恢复区域启动这些系统后,还需要就性能要求达成协议。
灾难恢复模拟练习还包括验证 Amazon EFS、Amazon S3 和作为整体灾难恢复计划一部分的其他 AWS 服务的跨区域复制。任何计划用于跨区域复制这些服务(例如 Amazon EFS)的同步任务都必须进行调整或暂停。它们往往会覆盖灾难恢复网站上创建的任何新内容。您可能还必须在网络层执行任务,以便 SAP 和第三方系统在灾难恢复区域内相互通信,以及客户端连接。还必须执行恢复后的任务,例如申请新许可证。还必须考虑最终用户的通信要求以及如何在灾难恢复站点上连接到 SAP HANA 系统的指导。
深入的灾难恢复模拟练习还包括测试在原始站点(主区域或可用区)上恢复 SAP HANA 系统的步骤。必须仔细计划此任务,以避免任何数据丢失。复制步骤因两层和多层 SAP HANA 系统复制设置而异。它需要异步复制模式。
在调用灾难恢复并故障恢复到原始站点之前,职能和技术团队必须验证 SAP HANA 系统是否存在潜在的数据丢失。通过模拟灾难恢复练习,您还可以为业务连续性准备标准操作程序,从而在实际灾难期间节省时间并最大限度地减少可能的数据丢失。