测试 - SAP HANA 开启 Amazon
测试 1：使用在主节点上停止 HANA HDB kill-9测试 2：模拟硬件故障测试 3：模拟内核崩溃测试 4：模拟网络故障测试 5：意外关机其他测试
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

测试

我们建议至少每年定期安排一次故障场景恢复测试，并作为操作系统或 HANA 升级的一部分，这可能会影响运营。有关定期测试最佳实践的更多详细信息，请参阅 SAP Lens — 最佳实践 4.3 — 定期测试业务连续性计划和故障恢复。

此处描述的测试模拟故障。这些可以帮助您了解集群的行为和操作要求。

除了检查群集资源的状态外，还要确保您尝试保护的服务处于所需状态。还能连接客户端吗？ 定义恢复时间，确保恢复时间与您的业务目标保持一致。在运行手册中记录恢复操作。

测试 1：使用在主节点上停止 HANA HDB kill-9

原因 — 测试集群对 HANA 进程立即终止的响应。这可以验证集群检测和响应关键数据库进程故障的能力，并确保适当的故障转移机制正常运行。

模拟故障 — 开启hanahost01为hdbadm：

hdbadm> HDB kill-9

预期行为 — 集群检测到 HANA 进程故障并触发立即故障转移到辅助节点。辅助节点升级为主节点，无需尝试本地恢复即可接管工作负载。

恢复行动 —

  1. 使用监控集群状态 crm_mon -r

  2. 使用验证 HANA 系统复制状态 hdbnsutil -sr_state

  3. 如果 AUTOMATED_REGISTER 为 “假”，请手动重新注册以前的主服务器：

    • 在 HSR Setup 中查看有关如何注册辅助服务器的更多详细信息：

      hdbnsutil -sr_register --name=<site_name> --remoteHost=<primary_host> --remoteInstance=<instance_number> --mode=sync --operationMode=logreplay

测试 2：模拟硬件故障

原因 — 测试群集对完全节点故障的响应，验证节点完全无响应时的屏蔽行为和资源故障转移是否正确。

注意 — 双力选项 (--force --force) 用于在测试环境中尽可能接近地模拟硬件故障。此命令绕过系统管理器，在不进行任何清理的情况下强制立即关机，类似于断电或硬件故障。但是，值得注意的是，这仍然是一个模拟，可能仍会进行一些操作系统级别的清理，而这些清理在真正的硬件故障或断电情况下是不会发生的。

模拟故障 — 开启hanahost01为root：

# poweroff --force --force

预期行为 — Corosync 检测到节点通信中断，正常运行的节点上的 Pacemaker 通过屏蔽代理启动屏蔽，然后将辅助 HANA 实例提升为主实例。应用程序连接应自动重新连接到新的主服务器。

恢复行动 —

  1. 启动已关闭电源的 Amazon 实例 EC2

  2. 使用验证集群状态 crm_mon -r

  3. 使用清理 STONITH 历史记录 crm resource refresh

  4. 使用检查 HANA 复制状态 hdbnsutil -sr_state

  5. 如果 AUTOMATED_REGISTER 为 “假”，请手动注册为辅助系统

  6. 验证应用程序与新主服务器的连接

测试 3：模拟内核崩溃

原因 — 测试集群对灾难性内核故障的响应，确保节点系统完全崩溃时恢复机制能够正常运行。

注意-要模拟系统崩溃，必须首先确保将其设置/proc/sys/kernel/sysrq为 1。

模拟故障 — 开启hanahost01为root：

# echo 'c' > /proc/sysrq-trigger

预期行为-群集通过心跳丢失来检测节点故障。幸存的节点通过屏蔽代理启动屏蔽，然后将辅助 HANA 实例升级为主实例。

恢复行动 —

  1. 内核崩溃后重启节点

  2. 使用验证集群状态 crm_mon -r

  3. 使用清理 STONITH 历史记录 crm resource refresh

  4. 使用检查 HANA 复制状态 hdbnsutil -sr_state

  5. 如果 AUTOMATED_REGISTER 为 “假”，请手动注册为辅助系统

  6. 验证所有群集资源是否干净

测试 4：模拟网络故障

原因 — 测试网络分区场景中的群集行为，确保分裂防范机制起作用，并在节点无法通信时进行适当的屏蔽。

笔记 —

  • 必须安装 Iptables

  • 由于有辅助环路，因此在此命令中使用子网

  • 检查是否存在任何现有的 iptables 规则，因为 iptables-F 将刷新所有规则

  • 如果你看到两个节点都无法在围栏竞赛中幸存下来，请查看 pcmk_delay 和优先级参数

模拟故障 — 在任一节点上以 root 用户身份：

# iptables -A INPUT -s <CIDR_of_other_subnet> -j DROP; iptables -A OUTPUT -d <CIDR_of_other_subnet> -j DROP

预期行为 — 集群检测到网络故障并屏蔽其中一个节点，以避免出现大脑分裂的情况。正常运行的节点控制群集资源。

恢复行动 —

  1. 如果故障是在正常运行的节点上模拟的，则执行iptables -F以清除网络故障

  2. 启动 EC2 节点和起搏器服务

  3. 验证集群状态和资源放置

测试 5：意外关机

原因 — 测试是否正确处理停机情况，确保集群在计划内和计划外停机期间都能适当地管理资源。

笔记 —

  • 避免在没有集群感知的情况下停机

  • 我们建议使用 systemd 来确保行为可预测

  • 确保资源依赖关系到位

模拟故障-登录 Amazon 管理控制台，停止实例或发出关闭命令。

预期行为-已关闭的节点出现故障。群集会将故障节点上运行的资源移至正常运行的节点。如果 systemd 和资源依赖关系配置不正确，则群集可能会检测到群集服务不干净地停止并屏蔽关闭的实例。

恢复行动 —

  1. 启动 EC2 节点和起搏器服务

  2. 验证集群状态和资源放置

  3. 确保根据约束条件正确分配资源

其他测试

根据您的环境和项目要求考虑以下其他测试：

  • 辅助节点测试

    • 在辅助服务器上执行之前的测试，以确保二次中断不会影响主服务器的服务可用性

    • 使用角色相反的节点执行之前的测试，以验证任一配置中的全部运行能力

  • 横向扩展测试（适用于横向扩展部署）

    • 协调器和工作节点上的测试失败

    • 测试多个工作节点的并发故障以验证故障转移顺序

    • 测试无法访问存储访问权限（包括 /hana/shared）

  • 组件级测试

    • 测试索引服务器故障并测量恢复时间

    • 验证 Fast Start Option 行为和挂钩脚本执行

  • 集群配置测试

    • 使用直接进行围栏操作 stonith_admin -F <node_name>

    • 资源流动和约束条件验证

记得记录所有测试结果、恢复时间和任何意外行为，以备将来参考和运行手册更新。