阿里云上的SAP高可用集群维护指南

2.1 crm_mon 命令详解

crm_mon 是查看集群实时状态的核心命令，常用参数如下：

常用命令示例：

# 实时监控集群状态（交互模式，按 Ctrl+C 退出）
crm_mon

# 单次输出集群概要
crm_mon -1

# 查看资源故障计数
crm_mon -1f

# 完整输出（含故障信息和无效资源）
crm_mon -1rf

正常状态输出示例（ASCS/ERS集群）：

Cluster Summary:
  * Stack: corosync
  * Current DC: node1 (version 2.1.5+20230509.git63b431033-3.21.1-2.1.5) - partition with quorum
  * Last updated: Thu May 14 10:00:00 2026
  * Last change:  Thu May 14 09:30:00 2026 by hacluster via crmd on node1
  * 2 nodes configured
  * 8 resource instances configured

Node List:
  * Online: [ node1 node2 ]

Active Resources:
  * res_ALIYUN_STONITH_1  (stonith:fence_aliyun):     Started node1
  * res_ALIYUN_STONITH_2  (stonith:fence_aliyun):     Started node2
  * Resource Group: grp_EN2_ASCS00:
    * rsc_ip_EN2_ASCS00   (ocf::heartbeat:aliyun-vpc-move-ip):  Started node1
    * rsc_sap_EN2_ASCS00  (ocf::heartbeat:SAPInstance):         Started node1
    * rsc_SAPStartSrv_EN2_ASCS00 (ocf::heartbeat:SAPStartSrv):  Started node1
  * Resource Group: grp_EN2_ERS10:
    * rsc_ip_EN2_ERS10    (ocf::heartbeat:aliyun-vpc-move-ip):  Started node2
    * rsc_sap_EN2_ERS10   (ocf::heartbeat:SAPInstance):         Started node2
    * rsc_SAPStartSrv_EN2_ERS10  (ocf::heartbeat:SAPStartSrv):  Started node2

2.2 crm status 命令

crm status 提供与 crm_mon -1 类似的概要输出，是快速查看集群状态的便捷命令：

# 查看集群整体状态
crm status

# 查看指定资源的状态
crm status resource rsc_sap_EN2_ASCS00

2.3 查看节点状态

# 查看所有节点状态
crm node status

# 查看节点是否在线/standby
crm node show

节点状态说明：

2.4 查看资源故障计数

# 查看所有资源的故障计数
crm_mon -1f

# 查看指定资源在指定节点上的故障计数
crm resource failcount rsc_sap_EN2_ASCS00 show node1

# 查询特定资源的故障计数（使用 crm_attribute）
crm_attribute --type status --node node1 --attr-name fail-count-rsc_sap_EN2_ASCS00 --query-xml

2.5 查看集群属性

# 查看所有集群属性
crm_attribute --list

# 查看特定集群属性
crm_attribute --attr-name stonith-enabled --query
crm_attribute --attr-name maintenance-mode --query
crm_attribute --attr-name no-quorum-policy --query

# 查看资源默认属性
crm_resource --list-attrs

# 查看节点属性
crm_attribute --type nodes --node node1 --list

关键集群默认属性参考：

ASCS资源特殊属性：

2.6 HANA集群特有属性查看

使用 SAPHanaSR-showAttr 查看 HANA System Replication 状态和集群属性：

# 查看HANA集群的SR状态概览
SAPHanaSR-showAttr

# 示例输出：
# Name             Site        LPA        LPT        LPTsys   SRA
# node1            SITE1       1715644800 1715644800 1        S_OK
# node2            SITE2       1715644800 0          0        S_OK

# 查看HANA特定SID的属性
SAPHanaSR-showAttr --sid=HA1 --inst=10

# 查看HANA SR Hook状态
python /usr/share/SAPHanaSR-angi/susHanaSR.py --check --sid=HA1 --instnum=10

HANA关键属性说明：

# 查看HANA多目标属性
crm_attribute --type rsc_defaults --meta --attr-name AUTOMATED_REGISTER --query

# 查看特定HANA资源的属性
crm_resource --resource mst_SAPHanaCon_HA1_HDB10 --list-attrs

2.7 日志查看

集群和Pacemaker的日志是排查问题的重要依据：

# 实时查看Pacemaker日志
tail -f /var/log/pacemaker/pacemaker.log

# 查看Pacemaker日志中的错误信息
grep -i "error\|warning\|crit" /var/log/pacemaker/pacemaker.log | tail -50

# 查看系统日志中的集群相关信息
tail -f /var/log/messages | grep -i "pacemaker\|corosync\|lrmd\|crmd"

# 查看Corosync日志
tail -f /var/log/messages | grep corosync

# 查看fence_aliyun操作日志
grep "fence_aliyun" /var/log/messages | tail -20

# 查看HANA SR相关日志
grep "SAPHanaSR\|susHanaSR\|susTkOver\|susChkSrv" /var/log/messages | tail -30

说明：在SLES 15中，Pacemaker日志同时写入 /var/log/pacemaker/pacemaker.log 和 /var/log/messages。优先查看 pacemaker.log，信息更为集中和完整。

3.1 全局维护模式

全局维护模式会暂停所有资源监控和STONITH操作，适用于需要对集群进行全面升级或大规模变更的场景。

# 将集群置于维护模式
crm configure property maintenance-mode=true

# 确认维护模式已生效
crm_attribute --attr-name maintenance-mode --query
# 应返回：name=maintenance-mode value=true

# 退出维护模式
crm configure property maintenance-mode=false

# 确认已退出维护模式
crm_attribute --attr-name maintenance-mode --query
# 应返回：name=maintenance-mode value=false

重要：维护模式下，STONITH和所有资源监控均暂停。集群不会自动响应任何故障，务必在完成维护后及时退出维护模式。

3.2 单个资源维护

当只需对特定资源进行维护时，建议使用单资源维护模式，其他资源仍受集群正常监控保护：

# 将单个资源置于维护模式
crm resource maintenance rsc_sap_EN2_ASCS00 on

# 退出单个资源的维护模式
crm resource maintenance rsc_sap_EN2_ASCS00 off

# 查看资源是否在维护模式
crm_resource --resource rsc_sap_EN2_ASCS00 --is-maintenance

3.3 节点Standby操作

将节点置于standby状态，使该节点不再运行任何资源：

# 将节点置于standby
crm node standby node2

# 取消节点standby（使节点重新上线）
crm node online node2

# 查看节点状态
crm node show

3.4 典型维护场景操作流程

1. 确认当前集群状态正常                        → crm_mon -1
2. 将待升级节点置于standby                      → crm node standby <node>
3. 确认资源已迁移至另一节点                      → crm_mon -1
4. 在standby节点上执行OS补丁升级
5. 升级完成后重启节点（如需要）
6. 节点启动后确认集群状态                        → crm_mon -1
7. 将节点重新上线                                → crm node online <node>
8. 确认集群状态正常                              → crm_mon -1
9. 对另一节点重复步骤2-8

1. 确认当前集群状态正常                          → crm_mon -1
2. 将集群置于维护模式                            → crm configure property maintenance-mode=true
3. 在两节点上分别执行Kernel升级
4. 升级完成后退出维护模式                        → crm configure property maintenance-mode=false
5. 确认集群状态正常                              → crm_mon -1
6. 验证SAP实例启动正常                           → sapcontrol -nr 00 -function GetSystemInstanceList

1. 确认当前HANA SR状态正常                       → SAPHanaSR-showAttr
2. 将HANA集群置于维护模式                        → crm configure property maintenance-mode=true
3. 先升级Secondary节点的HANA
4. 执行HANA takeover，将原Primary切换为Secondary
5. 升级新Secondary（原Primary）的HANA
6. 退出维护模式                                  → crm configure property maintenance-mode=false
7. 确认HANA集群状态正常                          → crm_mon -1 && SAPHanaSR-showAttr

4.1 启动/停止资源

# 启动资源
crm resource start rsc_sap_EN2_ASCS00

# 停止资源（集群将资源标记为stopped，但仍在集群配置中）
crm resource stop rsc_sap_EN2_ASCS00

# 启动整个资源组
crm resource start grp_EN2_ASCS00

# 停止整个资源组
crm resource stop grp_EN2_ASCS00

说明：crm resource stop 停止资源后，集群不会自动重启该资源。需要使用 crm resource start 手动启动。

4.2 资源清理（清除故障计数）

当资源发生故障后，故障计数会累积。即使故障已恢复，残留的故障计数也可能导致资源意外迁移。因此，在确认故障已解决后，应及时清理故障计数：

# 清理指定资源的故障计数
crm resource cleanup rsc_sap_EN2_ASCS00

# 清理指定资源在指定节点上的故障计数
crm resource cleanup rsc_sap_EN2_ASCS00 node1

# 清理HANA资源的故障计数
crm resource cleanup mst_SAPHanaCon_HA1_HDB10

# 清理所有资源的故障计数
crm resource cleanup

重要：在排查和解决资源故障后，务必执行 cleanup 操作清除故障计数，否则可能因累计达到 migration-threshold 而导致资源无法回到原节点。

4.3 资源迁移

# 将ASCS资源组迁移到node2
crm resource move grp_EN2_ASCS00 node2

# 将HANA资源迁移（触发takeover）
crm resource move mst_SAPHanaCon_HA1_HDB10 node2

警告：crm resource move 命令会创建一个位置约束（colocation constraint），使资源倾向于运行在目标节点。操作完成后务必执行 crm resource clear 移除该约束，否则资源将被固定在目标节点，无法在后续故障时正常切换。

4.4 取消迁移约束

# 取消ASCS资源组的迁移约束
crm resource clear grp_EN2_ASCS00

# 取消HANA资源的迁移约束
crm resource clear mst_SAPHanaCon_HA1_HDB10

4.5 资源刷新

# 刷新资源状态（使集群重新检测资源的实际运行状态）
crm resource refresh rsc_sap_EN2_ASCS00

# 刷新所有资源状态
crm resource refresh

4.6 操作流程示例：手动切换ASCS到另一节点

# 步骤1：确认当前集群状态
crm_mon -1

# 步骤2：迁移ASCS资源组到目标节点
crm resource move grp_EN2_ASCS00 node2

# 步骤3：确认迁移完成
crm_mon -1

# 步骤4：清除迁移约束（关键步骤！）
crm resource clear grp_EN2_ASCS00

# 步骤5：最终确认集群状态
crm_mon -1

5.1 ASCS/ERS服务

# 通过 sapcontrol 停止ASCS（自动触发集群维护模式）
sapcontrol -nr 00 -function StopSystem

# 通过 sapcontrol 启动ASCS
sapcontrol -nr 00 -function StartSystem

# 通过 sapcontrol 停止ERS
sapcontrol -nr 10 -function StopSystem

# 通过 sapcontrol 启动ERS
sapcontrol -nr 10 -function StartSystem

# 验证 sap-suse-cluster-connector 版本
rpm -q sap-suse-cluster-connector

# 验证 <sid>adm 用户组
id en2adm | grep haclient

# 验证集群 record-pending 配置
crm configure show op_defaults | grep record-pending

# 通过集群命令停止ASCS
crm resource stop grp_EN2_ASCS00

# 通过集群命令启动ASCS
crm resource start grp_EN2_ASCS00

# 通过集群命令停止ERS
crm resource stop grp_EN2_ERS10

# 通过集群命令启动ERS
crm resource start grp_EN2_ERS10

# 步骤1：确认当前ASCS运行节点
crm_mon -1 | grep -A5 grp_EN2_ASCS00

# 步骤2：迁移ASCS资源组到目标节点
crm resource move grp_EN2_ASCS00 node2

# 步骤3：等待迁移完成，确认ASCS已在目标节点运行
crm_mon -1

# 步骤4：清除迁移约束
crm resource clear grp_EN2_ASCS00

# 步骤5：确认ERS是否仍在原节点运行
# 注意：由于ASCS和ERS的colocation约束score=-5000，ASCS切换后ERS不会自动迁移
crm_mon -1 | grep -A5 grp_EN2_ERS10

# 步骤6：如果需要，可手动迁移ERS
crm resource move grp_EN2_ERS10 node1
crm resource clear grp_EN2_ERS10

# 查看ASCS实例状态
sapcontrol -nr 00 -function GetSystemInstanceList

# 查看ERS实例状态
sapcontrol -nr 10 -function GetSystemInstanceList

# 查看实例进程列表
sapcontrol -nr 00 -function GetProcessList

5.2 HANA数据库服务

# ===== 停止HANA集群资源 =====
# 停止HANA资源（Primary和Secondary均停止）
crm resource stop mst_SAPHanaCon_HA1_HDB10

# 停止HANA拓扑资源
crm resource stop cln_SAPHanaTop_HA1_HDB10

# ===== 启动HANA集群资源 =====
# 先启动拓扑资源
crm resource start cln_SAPHanaTop_HA1_HDB10

# 再启动HANA控制资源
crm resource start mst_SAPHanaCon_HA1_HDB10

# ===== 错误：不要直接使用以下命令 =====
# HDB stop
# systemctl stop saphana_HA1_HDB10

# 步骤1：确认当前HANA SR状态
SAPHanaSR-showAttr

# 步骤2：确认集群状态
crm_mon -1

# 步骤3：确认目标Secondary节点的SR同步状态为SYNC
# 在Secondary节点执行：
su - ha1adm -c "hdbnsutil -sr_state"
# 确认 mode: SYNC 和 site mode: SYNC

# 步骤4：通过集群命令执行takeover
crm resource move mst_SAPHanaCon_HA1_HDB10 node2

# 步骤5：等待takeover完成，确认状态
crm_mon -1
SAPHanaSR-showAttr

# 步骤6：清除迁移约束
crm resource clear mst_SAPHanaCon_HA1_HDB10

# 步骤7：确认原Primary已重新注册为Secondary
# 如果 AUTOMATED_REGISTER=true，集群会自动完成注册
# 如果 AUTOMATED_REGISTER=false，需要手动注册（见5.2.3）

# 在原Primary节点（现在是未注册状态）执行：

# 步骤1：确认HANA已停止
su - ha1adm -c "HDB info"

# 步骤2：以recovery模式注册为Secondary
su - ha1adm -c "hdbnsutil -sr_register --remoteHost=node2 --remoteInstance=10 --replicationMode=sync --operationMode=logreplay_readaccess --name=SITE1"

# 步骤3：启动HANA（由集群管理）
# 集群将自动检测到新注册的Secondary并启动HANA
crm resource cleanup mst_SAPHanaCon_HA1_HDB10
crm resource cleanup cln_SAPHanaTop_HA1_HDB10

# 步骤4：确认SR状态
su - ha1adm -c "hdbnsutil -sr_state"
SAPHanaSR-showAttr

# 查看当前AUTOMATED_REGISTER设置
crm_resource --resource mst_SAPHanaCon_HA1_HDB10 --get-parameter AUTOMATED_REGISTER

# 修改AUTOMATED_REGISTER设置
crm_resource --resource mst_SAPHanaCon_HA1_HDB10 --set-parameter AUTOMATED_REGISTER --parameter-value true

6.1 查看STONITH资源状态

# 查看STONITH资源状态
crm_mon -1 | grep -i stonith

# 查看所有STONITH资源
crm_resource --list | grep -i stonith

# 查看特定STONITH资源配置
crm configure show res_ALIYUN_STONITH_1
crm configure show res_ALIYUN_STONITH_2

6.2 测试STONITH是否正常工作

# 列出所有可用的STONITH设备
stonith_admin -L

# 查看指定STONITH设备的元数据
stonith_admin --metadata -a fence_aliyun

# 测试fence_aliyun连接（仅验证，不执行fencing）
# 需要替换为实际的ECS实例ID
fence_aliyun --action=list --region=cn-shanghai plug=<ECS instance id> ram_role=SAP-HA-ROLE

# 验证STONITH设备是否可以fencing指定节点
stonith_admin --validate --env-host=node2

警告：请勿在业务运行期间执行实际的fencing测试（fence_aliyun --action=off 或 --action=reboot），这将强制重启目标ECS实例，导致业务中断。

6.3 临时禁用STONITH

警告：临时禁用STONITH会显著降低集群的可靠性。在禁用STONITH期间，如果发生节点故障，集群无法隔离故障节点，可能导致脑裂（split-brain）或数据损坏。仅在紧急排障时短暂使用，并尽快恢复。

# 临时禁用STONITH（不推荐）
crm configure property stonith-enabled=false

# 恢复STONITH
crm configure property stonith-enabled=true

7.1 查看当前CIB配置

# 查看完整集群配置
crm configure show

# 导出完整CIB XML（用于深度排查）
cibadmin --query > /tmp/cib_backup.xml

# 查看特定资源配置
crm configure show res_ALIYUN_STONITH_1
crm configure show rsc_sap_EN2_ASCS00
crm configure show mst_SAPHanaCon_HA1_HDB10

7.2 查看资源组和约束

# 查看资源组配置
crm configure show grp_EN2_ASCS00
crm configure show grp_EN2_ERS10

# 查看colocation约束
crm configure show | grep -A2 colocation

# 查看ordering约束
crm configure show | grep -A2 order

# 查看location约束
crm configure show | grep -A2 location

7.3 修改资源参数

# 方法一：使用 crm configure edit（交互式编辑器）
crm configure edit

# 方法二：使用 crm_resource 修改特定参数
# 查看当前参数值
crm_resource --resource mst_SAPHanaCon_HA1_HDB10 --get-parameter AUTOMATED_REGISTER

# 修改参数值
crm_resource --resource mst_SAPHanaCon_HA1_HDB10 --set-parameter AUTOMATED_REGISTER --parameter-value true

# 方法三：使用 crm configure 命令行修改
crm configure property stonith-timeout=200
crm configure rsc_defaults resource-stickiness=10

7.4 导出/备份集群配置

# 导出集群配置到文件
crm configure save /tmp/cluster_config_$(date +%Y%m%d).txt

# 备份CIB XML
cibadmin --query > /tmp/cib_backup_$(date +%Y%m%d).xml

# 从备份恢复集群配置
crm configure load update /tmp/cluster_config_20260514.txt

# 从CIB XML恢复
cibadmin --replace --xml-file /tmp/cib_backup_20260514.xml

重要：在进行任何集群配置变更前，务必备份当前配置。变更操作不可逆，备份可确保在变更失败时快速恢复。

7.5 Hook脚本路径和配置查看

HANA高可用集群依赖以下Hook脚本，由SAPHanaSR-angi软件包提供：

# 查看ha_dr_provider配置
su - ha1adm -c "hdbuserstore list"
su - ha1adm -c "python /usr/share/SAPHanaSR-angi/susHanaSR.py --check --sid=HA1 --instnum=10"

# 查看HANA的ha_dr_provider配置
su - ha1adm -c "hdbsql -i 10 -d SYSTEMDB -u SYSTEM -p <password> \"SELECT * FROM M_INIFILE_CONTENTS WHERE FILE_NAME='global.ini' AND SECTION='ha_dr_provider'\""

# 或者直接查看global.ini文件
cat /hana/shared/HA1/global/hdb/custom/config/global.ini | grep -A20 ha_dr_provider

[ha_dr_provider_susHanaSR]
provider = susHanaSR
path = /usr/share/SAPHanaSR-angi
execution_order = 1

[ha_dr_provider_susTkOver]
provider = susTkOver
path = /usr/share/SAPHanaSR-angi
execution_order = 2

[ha_dr_provider_susChkSrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-angi
execution_order = 3

# 查看SAPHanaSR的sudoers配置
cat /etc/sudoers.d/SAPHanaSR

# 验证ha1adm用户的sudo权限
sudo -l -U ha1adm | grep -i "crm_\|cibadmin\|stonith_admin"

8.1 计划内维护（OS补丁/SAP升级）

┌─────────────────────────────────────────────────────────────────┐
│ 步骤1: 确认集群状态正常                                          │
│   crm_mon -1                                                    │
├─────────────────────────────────────────────────────────────────┤
│ 步骤2: 将待维护节点置于standby                                   │
│   crm node standby node2                                        │
├─────────────────────────────────────────────────────────────────┤
│ 步骤3: 确认资源已迁移至另一节点                                   │
│   crm_mon -1                                                    │
│   （ASCS和ERS应均运行在node1）                                    │
├─────────────────────────────────────────────────────────────────┤
│ 步骤4: 在node2上执行OS补丁升级并重启                              │
├─────────────────────────────────────────────────────────────────┤
│ 步骤5: node2重启后确认集群状态                                    │
│   crm_mon -1                                                    │
│   （node2应自动重新加入集群，但资源不会回迁）                      │
├─────────────────────────────────────────────────────────────────┤
│ 步骤6: 将node2重新上线                                           │
│   crm node online node2                                         │
├─────────────────────────────────────────────────────────────────┤
│ 步骤7: 如需恢复ASCS/ERS的原分布，手动迁移ERS回到node2             │
│   crm resource move grp_EN2_ERS10 node2                         │
│   crm resource clear grp_EN2_ERS10                              │
├─────────────────────────────────────────────────────────────────┤
│ 步骤8: 对node1重复步骤2-7                                       │
├─────────────────────────────────────────────────────────────────┤
│ 步骤9: 最终确认集群状态                                          │
│   crm_mon -1                                                    │
└─────────────────────────────────────────────────────────────────┘

# 步骤1：确认HANA SR状态
SAPHanaSR-showAttr
su - ha1adm -c "hdbnsutil -sr_state"

# 步骤2：将Secondary节点置于standby
crm node standby node2   # 假设node2为Secondary

# 步骤3：确认集群状态正常（Primary不受影响）
crm_mon -1

# 步骤4：在node2上执行OS补丁升级并重启

# 步骤5：node2重启后重新上线
crm node online node2

# 步骤6：确认HANA SR恢复
SAPHanaSR-showAttr
# 等待SR重新建立同步

# 步骤7：执行HANA takeover，使原Secondary成为新Primary
crm resource move mst_SAPHanaCon_HA1_HDB10 node2
crm resource clear mst_SAPHanaCon_HA1_HDB10

# 步骤8：确认takeover完成
SAPHanaSR-showAttr

# 步骤9：对原Primary节点（现为Secondary）重复步骤2-6

# 步骤10：最终确认集群状态
crm_mon -1 && SAPHanaSR-showAttr

8.2 节点故障后恢复

# 步骤1：确认故障节点的资源已自动迁移到健康节点
crm_mon -1

# 步骤2：恢复故障节点（修复ECS实例、启动实例等）

# 步骤3：确认节点自动重新加入集群
crm node show
# 节点应显示为 Online

# 步骤4：清理故障计数
crm resource cleanup

# 步骤5：确认资源分布
# ASCS和ERS应分布在不同节点（由于colocation score=-5000）
# 如果ERS未回到原节点，可手动迁移
crm resource move grp_EN2_ERS10 node2
crm resource clear grp_EN2_ERS10

# 步骤6：最终确认
crm_mon -1

# 步骤1：确认当前集群状态
crm_mon -1
SAPHanaSR-showAttr

# 步骤2：确认takeover已自动完成（如果PREFER_SITE_TAKEOVER=true）
# 健康节点应已成为新Primary

# 步骤3：恢复故障节点（修复ECS实例等）

# 步骤4：确认故障节点已重新加入集群
crm node show

# 步骤5：检查HANA SR注册状态
SAPHanaSR-showAttr

# 情况A：如果 AUTOMATED_REGISTER=true
# 集群会自动将恢复节点注册为Secondary并启动HANA
# 确认SR同步正常：
su - ha1adm -c "hdbnsutil -sr_state"

# 情况B：如果 AUTOMATED_REGISTER=false
# 需要手动注册（参见5.2.3节）

# 步骤6：清理资源故障计数
crm resource cleanup mst_SAPHanaCon_HA1_HDB10
crm resource cleanup cln_SAPHanaTop_HA1_HDB10

# 步骤7：最终确认
crm_mon -1 && SAPHanaSR-showAttr

8.3 集群资源持续报错

当集群资源持续报错时，按以下步骤排查：

# 步骤1：查看集群状态，定位报错资源
crm_mon -1rf

# 步骤2：查看资源的故障计数
crm resource failcount rsc_sap_EN2_ASCS00 show node1

# 步骤3：查看Pacemaker日志，定位错误原因
grep "rsc_sap_EN2_ASCS00" /var/log/pacemaker/pacemaker.log | tail -50

# 步骤4：查看资源操作日志（重点关注last-rc-change和rc-code）
crm_resource --resource rsc_sap_EN2_ASCS00 --force-demote --verbose

# 步骤5：查看资源代理的详细输出
# 手动执行资源代理的monitor操作
crm_resource --resource rsc_sap_EN2_ASCS00 --probe node1

# 步骤6：查看系统日志
grep "rsc_sap_EN2_ASCS00\|SAPInstance\|lrmd" /var/log/messages | tail -30

# 步骤7：根据错误原因修复问题后，清理故障计数
crm resource cleanup rsc_sap_EN2_ASCS00

# 步骤8：确认资源恢复
crm_mon -1

常见错误及处理：

8.4 虚拟IP未正确漂移

虚拟IP（Overlay IP）未正确漂移是常见问题，按以下步骤排查：

# 步骤1：检查aliyun-vpc-move-ip资源状态
crm_mon -1 | grep -i vpc-move-ip

# 步骤2：查看虚拟IP资源详情
crm configure show rsc_ip_EN2_ASCS00

# 步骤3：检查资源在哪个节点运行
crm_resource --resource rsc_ip_EN2_ASCS00 --locate

# 步骤4：如果资源状态与实际不符，手动刷新
crm resource refresh rsc_ip_EN2_ASCS00

# 如果自动漂移失败，可尝试手动操作
# 步骤1：停止当前节点的VIP资源
crm resource stop rsc_ip_EN2_ASCS00

# 步骤2：启动目标节点的VIP资源
crm resource start rsc_ip_EN2_ASCS00

# 步骤3：确认路由表条目已更新
# 在阿里云控制台检查VPC路由表

# 步骤4：清理故障计数
crm resource cleanup rsc_ip_EN2_ASCS00

9.1 操作系统与版本一致性

重要：同一集群内的两个节点，操作系统版本、内核版本、SAP相关软件包版本必须保持一致。版本不一致可能导致集群行为异常或资源代理执行结果不同。

# 检查两节点OS版本
cat /etc/os-release

# 检查内核版本
uname -r

# 检查SAPHanaSR-angi版本（HANA集群）
rpm -qa | grep SAPHanaSR

9.2 不要直接使用systemctl管理SAP服务

SAP服务由Pacemaker集群管理，直接使用systemctl启停会导致集群检测到资源状态异常，触发不必要的恢复动作。

# ===== 错误操作 =====
systemctl start SAPEN2_00
systemctl stop SAPEN2_00
systemctl restart SAPEN2_00

# ===== 正确操作 =====
crm resource start rsc_sap_EN2_ASCS00
crm resource stop rsc_sap_EN2_ASCS00

9.3 关闭SAP实例的autostart

为避免ECS实例重启时SAP实例先于集群启动，导致集群资源状态混乱，必须关闭SAP实例的autostart：

# 检查SAP实例的autostart状态
systemctl is-enabled SAPEN2_00
systemctl is-enabled SAPEN2_10
systemctl is-enabled SAPHA1_10

# 如果返回 enabled，需要禁用
systemctl disable SAPEN2_00
systemctl disable SAPEN2_10
systemctl disable SAPHA1_10

# 同时确认SAP profile中的autostart设置
# 检查以下profile文件中的 Autostart 参数：
grep -i autostart /usr/sap/EN2/SYS/profile/EN2_ASCS00_*
grep -i autostart /usr/sap/EN2/SYS/profile/EN2_ERS10_*
grep -i autostart /usr/sap/HA1/SYS/profile/HA1_HDB10_*

# Autostart值应为0或该行被注释
# 如不是，修改为：
# Autostart = 0

重要：如果在部署时遗漏了此步骤，ECS重启后SAP实例会自动启动，与集群管理产生冲突，可能导致fencing操作或资源反复启停。

9.4 定期检查集群状态和STONITH可用性

建议将以下检查纳入日常巡检：

# 1. 集群整体状态
crm_mon -1

# 2. STONITH资源状态
crm_mon -1 | grep -i stonith

# 3. HANA SR状态
SAPHanaSR-showAttr

# 4. 检查是否有未清理的故障计数
crm_mon -1f | grep -i "fail"

# 5. 检查Corosync通信
corosync-cfgtool -s

# 6. 检查集群节点成员
crm_node -l

9.5 变更前务必备份集群配置

# 在执行任何集群配置变更前，备份当前配置
crm configure save /root/cluster_config_backup_$(date +%Y%m%d%H%M).txt
cibadmin --query > /root/cib_backup_$(date +%Y%m%d%H%M).xml

9.6 升级操作前先将节点置于standby或集群进入维护模式

警告：在集群正常运行状态下直接对节点执行重启或升级操作，可能触发STONITH fencing，导致非预期的节点重启。

# 正确做法：先将节点置于standby
crm node standby <node>

# 或将整个集群置于维护模式
crm configure property maintenance-mode=true

# 执行升级操作...

# 完成后恢复
crm node online <node>
# 或
crm configure property maintenance-mode=false

9.7 资源迁移后务必清除约束

# 每次执行 crm resource move 后，必须执行：
crm resource clear <resource>

# 检查是否存在残留的位置约束
crm configure show | grep -A2 "location cli-"

9.8 关注集群通信

Corosync使用UCAST单播模式，两节点间需要稳定的网络通信：

# 检查Corosync环形状态
corosync-cfgtool -s

# 检查Corosync成员
corosync-cmapctl | grep -i member

# 检查Corosync配置
cat /etc/corosync/corosync.conf

说明：本文档中的命令示例基于 SLES for SAP 15 和 Pacemaker 2.x 环境。如使用其他版本，命令格式可能略有差异，请参考对应版本的官方文档。