测试 - SAP HANA on AWS
测试 1：使用 HDB kill-9 在主节点上停止 HANA测试 2：模拟硬件故障测试 3：模拟内核崩溃测试 4：模拟网络故障测试 5：意外关机其他测试

测试

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

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

除了检查集群资源的状态之外，还要确保您尝试保护的服务处于所需状态。客户端连接是否仍可用？ 定义恢复时间，确保其符合业务目标。在运行手册中记录恢复操作。

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

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

模拟故障：在 hanahost01 上，以 hdbadm 身份执行以下命令：

hdbadm> HDB kill-9

预期行为：集群检测到 HANA 进程故障，并触发立即失效转移到辅助节点。辅助节点提升为主节点，接管工作负载而不尝试本地恢复。

恢复操作：

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

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

  3. 如果 AUTOMATED_REGISTER 为“false”，请手动重新注册以前的主节点：

    • 有关如何注册辅助节点的更多详细信息，请参阅 HSR 设置：

      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. 使用 crm resource refresh 清理 STONITH 历史记录

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

  5. 如果 AUTOMATED_REGISTER 为“false”，请手动注册为辅助实例

  6. 验证应用程序是否连接到新的主实例

测试 3：模拟内核崩溃

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

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

模拟故障：在 hanahost01 上，以 root 身份执行以下命令：

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

预期行为：集群通过检测信号丢失来发现节点故障。正常运行的节点通过隔离代理启动隔离，然后将辅助 HANA 实例提升为主实例。

恢复操作：

  1. 内核崩溃后重启节点

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

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

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

  5. 如果 AUTOMATED_REGISTER 为“false”，请手动注册为辅助实例

  6. 验证所有集群资源是否清洁

测试 4：模拟网络故障

原因：测试网络分区场景中的集群行为，确保脑裂防范机制发挥作用，并在节点无法通信时正确进行隔离。

注意:

  • 必须安装 Iptables

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

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

  • 如果您看到两个节点在隔离竞赛中都未能存活，请查看 pcmk_delay 和 priority 参数

模拟故障：在任一节点上以根用户身份执行以下命令：

# 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 节点和 pacemaker 服务

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

测试 5：意外关机

原因：测试系统能否正确处理停机场景，确保集群在计划内和计划外停机期间都能正确地管理资源。

注意:

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

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

  • 确保正确处理了资源依赖关系

模拟故障：登录 AWS 管理控制台，停止实例或发布关机命令。

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

恢复操作：

  1. 启动 EC2 节点和 pacemaker 服务

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

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

其他测试

根据您的环境和项目要求，请考虑执行以下额外的测试：

  • 辅助节点测试

    • 在辅助节点上执行上述测试，以确保辅助节点的中断不会影响主节点的服务可用性

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

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

    • 测试协调器和 Worker 节点上的故障

    • 测试多个 Worker 节点的并发故障以验证失效转移顺序

    • 测试阻止了对存储的访问权限（包括 /hana/shared）时的故障

  • 组件级测试

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

    • 验证快速启动选项行为和钩子脚本执行

  • 集群配置测试

    • 使用 stonith_admin -F <node_name> 直接执行隔离操作

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

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