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

# 测试
<a name="sap-hana-pacemaker-sles-testing"></a>

我们建议至少每年定期安排一次故障场景恢复测试，并在可能会影响到运营的操作系统或 HANA 升级过程中进行故障场景恢复测试。有关定期测试最佳实践的更多详细信息，请参阅 SAP Lens：[最佳实践 4.3 – 定期测试业务连续性计划和故障恢复](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-3.html)。

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

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

**Topics**
+ [测试 1：使用 `HDB kill-9` 在主节点上停止 HANA](#_test_1_stop_hana_on_the_primary_node_using_hdb_kill_9)
+ [测试 2：模拟硬件故障](#_test_2_simulate_a_hardware_failure)
+ [测试 3：模拟内核崩溃](#_test_3_simulate_a_kernel_panic)
+ [测试 4：模拟网络故障](#_test_4_simulate_a_network_failure)
+ [测试 5：意外关机](#_test_5_accidental_shutdown)
+ [其他测试](#_other_tests)

## 测试 1：使用 `HDB kill-9` 在主节点上停止 HANA
<a name="_test_1_stop_hana_on_the_primary_node_using_hdb_kill_9"></a>

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

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

```
hdbadm> HDB kill-9
```

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

 **恢复操作**：

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

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

1. 如果 AUTOMATED\$1REGISTER 为“false”，请手动重新注册以前的主节点：
   + 有关如何注册辅助节点的更多详细信息，请参阅 [HSR 设置](sap-hana-pacemaker-sles-hana-setup-hsr.md)：

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

## 测试 2：模拟硬件故障
<a name="_test_2_simulate_a_hardware_failure"></a>

 **原因**：测试集群对整个节点故障的响应，验证在节点完全无响应时的隔离行为和资源失效转移是否正确。

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

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

```
# poweroff --force --force
```

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

 **恢复操作**：

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

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

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

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

1. 如果 AUTOMATED\$1REGISTER 为“false”，请手动注册为辅助实例

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

## 测试 3：模拟内核崩溃
<a name="_test_3_simulate_a_kernel_panic"></a>

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

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

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

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

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

 **恢复操作**：

1. 内核崩溃后重启节点

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

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

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

1. 如果 AUTOMATED\$1REGISTER 为“false”，请手动注册为辅助实例

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

## 测试 4：模拟网络故障
<a name="_test_4_simulate_a_network_failure"></a>

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

 **注意**:
+ 必须安装 Iptables
+ 由于有辅助环路，因此在此命令中使用子网
+ 检查是否存在任何现有的 iptables 规则，因为 iptables -F 将刷新所有规则
+ 如果您看到两个节点在隔离竞赛中都未能存活，请查看 pcmk\$1delay 和 priority 参数

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

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

 **预期行为**：集群检测到网络故障并隔离其中一个节点，以避免出现脑裂情况。正常运行的节点将接管集群资源的控制。

 **恢复操作**：

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

1. 启动 EC2 节点和 pacemaker 服务

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

## 测试 5：意外关机
<a name="_test_5_accidental_shutdown"></a>

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

 **注意**:
+ 避免在没有集群感知能力的情况下停机
+ 建议使用 systemd 来确保行为可预测
+ 确保正确处理了资源依赖关系

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

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

 **恢复操作**：

1. 启动 EC2 节点和 pacemaker 服务

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

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

## 其他测试
<a name="_other_tests"></a>

根据您的环境和项目要求，请考虑执行以下额外的测试：
+  **辅助节点测试** 
  + 在辅助节点上执行上述测试，以确保辅助节点的中断不会影响主节点的服务可用性
  + 使用相反的角色对节点执行上述测试，以验证任一配置中的全部运营能力
+  **横向扩展测试**（适用于横向扩展部署）
  + 测试协调器和 Worker 节点上的故障
  + 测试多个 Worker 节点的并发故障以验证失效转移顺序
  + 测试阻止了对存储的访问权限（包括 /hana/shared）时的故障
+  **组件级测试** 
  + 测试索引服务器故障并测量恢复时间
  + 验证快速启动选项行为和钩子脚本执行
+  **集群配置测试** 
  + 使用 `stonith_admin -F <node_name>` 直接执行隔离操作 
  + 资源移动和约束条件验证

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