简介这份资源面向在 SUSE Linux 平台上部署 SAP HANA 高可用环境HAE的运维与实施人员提供一套可快速落地的自动化配置脚本解决手工搭建 Corosync、Pacemaker 集群时步骤繁琐、易出错的问题。资源包共 6 个文件以 sh 脚本、tpl 模板和 txt 说明为主压缩后约 5KB体积轻巧便于随项目分发其中脚本负责执行配置流程模板用于生成集群参数说明文档则交代使用前提与注意事项。脚本兼容 SUSE 12 SPx 系列同时支持 HANA 1.0 与 HANA 2.0并覆盖基于 IPMI 与 SBD 两种 fence 模式读者无需逐条敲命令执行脚本即可完成 HAE 基础配置。目前已有 683 人学习下载适合需要快速验证 HANA 高可用方案、或希望参考脚本化配置思路的中高级 Linux 运维人员。1. 从一次 HANA 集群上线翻车说起这套 HAE 配置脚本到底省了什么去年帮一家制造企业做 SUSE 上的 SAP HANA 高可用改造两台物理机、一套 HANA 2.0 主备按官方文档手撸 Corosync 加 Pacemaker光 resource agent 的参数就调了整整两天fence 设备还因为 IPMI 的 lanplus 参数写错导致测试时脑裂。后来同事丢给我一个hana-hae-config-creator-v2.4.zip说这是圈子里流传的 SUSE HANA HAE 快速配置脚本解压后只有crmconfig.sh、crmconfig.tpl、crmconfig-sbd.tpl、settings.sh和一份 README看着简陋但把 SUSE Linux 上 SAP HANA 的 HAE 集群搭建从「查文档拼参数」变成了「改一个 settings 文件然后跑脚本」。它支持 SUSE 12 SPx覆盖 HANA 1.0 和 2.0fence 模式同时给了 IPMI 和 SBD 两条路。如果你正在被 suse_saphana_hae、suse_corosync、suse_pacemaker 这些关键词绕得头大或者手上正好有一对要上 HAE 的 HANA 节点这篇就是我把这套脚本拆开、跑通、踩坑之后留下的实操记录。2. 拆开压缩包脚本结构、模板机制与 HANA 版本适配逻辑2.1 文件清单与各自职责解压hana-hae-config-creator-v2.4.zip之后目录里是这些东西文件作用settings.sh唯一需要你手工编辑的配置文件所有节点、SID、fence 参数都在这crmconfig.sh主执行脚本读取 settings 后生成并下发集群配置crmconfig.tplIPMI fence 模式下的 crm 配置模板crmconfig-sbd.tplSBD fence 模式下的 crm 配置模板README.txt作者写的使用说明和注意事项联系作者.txt反馈渠道这个结构的关键在于「模板 变量替换」。crmconfig.sh本身不硬编码任何集群参数它把settings.sh里的变量填进.tpl模板再通过crm命令把配置灌进 Pacemaker。所以你改错一个变量生成的集群配置就会整体偏掉这也是后面避坑章节要重点说的。2.2 为什么用模板而不是直接 crm configure手写过 HANA HAE 的人都知道一个完整的集群配置包含 primitive、group、clone、location、property 好几层HANA 的 resource agent 参数又有几十个。直接crm configure edit一条条敲不仅慢而且两台节点如果配置不一致Corosync 层就可能起不来。模板机制的好处是把「结构」和「值」分离结构由作者根据 SUSE 官方最佳实践固化在.tpl里你只负责填值。常见做法是先在测试环境用模板生成一遍crm configure show导出对比官方文档确认 resource agent 的op监控间隔、timeout这些没被改坏再上生产。2.3 HANA 1.0 与 2.0 的适配差异脚本声称同时支持 HANA 1.0 和 2.0差异主要体现在 resource agent 的调用方式上。HANA 2.0 的SAPHanaRA 在crmconfig.tpl里对应的参数名和 1.0 有细微不同比如SID、InstanceNumber的取值来源以及DUPLICATE_PRIMARY_TIMEOUT这类超时参数。脚本通过settings.sh里的HANA_VERSION变量做分支判断生成不同的 primitive 定义。如果你把 2.0 的环境按 1.0 的模板配最典型的翻车是集群能起来但 HANA 资源一直FAILED因为 RA 找不到对应的实例目录。2.4 跑之前先确认的三件事在动脚本之前有三件事必须先确认否则后面全是玄学问题第一两台节点的 hostname 必须和settings.sh里写的一致且/etc/hosts互相能解析。Corosync 对 hostname 极其敏感解析不一致直接导致节点无法加入集群。第二时间同步。SUSE 上一般用 chronychronyc sources确认两台节点都同步到同一个源。时间偏差过大会让 Pacemaker 的投票机制出问题。第三确认 HANA 已经安装完成且主备关系在 HANA 层面是干净的。HAE 管的是「进程和 VIP 的切换」不负责 HANA 本身的 system replication 配置。system replication 要先在 HANA studio 或 hdbnsutil 里配好HAE 才有意义。3. 改 settings.sh 到执行 crmconfig.sh一次完整的 HAE 配置流程3.1 settings.sh 里必须改的变量settings.sh是整套脚本的入口变量不多但每个都关键。下面是我实际用的一份脱敏配置# 节点定义顺序要和 Corosync 的 ring0 一致 NODE1_HOSTNAMEhana01 NODE2_HOSTNAMEhana02 NODE1_IP192.168.10.11 NODE2_IP192.168.10.12 # HANA 实例信息 HANA_SIDHDB HANA_INSTANCE00 HANA_VERSION2.0 # 1.0 或 2.0决定 RA 参数分支 # 虚拟 IP客户端连这个 VIP192.168.10.100 VIP_MASK24 # fence 模式ipmi 或 sbd FENCE_MODEipmi # IPMI 参数SBD 模式下这几行留空 IPMI_NODE1_IP192.168.20.11 IPMI_NODE2_IP192.168.20.12 IPMI_USERadmin IPMI_PASSyourpassword IPMI_LANPLUSlanplus # SBD 模式专用 SBD_DEVICE/dev/disk/by-id/your-sbd-disk逻辑说明NODE1_HOSTNAME和NODE2_HOSTNAME会被填进 Corosync 的nodelist顺序错了会导致 ring 绑定到错误的网卡。HANA_VERSION是分支开关脚本靠它决定用哪套 RA 参数。FENCE_MODE决定加载crmconfig.tpl还是crmconfig-sbd.tpl。IPMI 的lanplus参数是血泪经验很多 IPMI 设备只认 lanplus写成 lan 会连不上。参数说明VIP_MASK用 CIDR 写法别写成255.255.255.0脚本内部按 CIDR 拼ip addr。SBD_DEVICE建议用/dev/disk/by-id/路径而不是/dev/sdb因为设备名在重启后可能变by-id 更稳。3.2 执行脚本与生成集群改完 settings 后在两台节点上分别执行# 先给脚本执行权限 chmod x crmconfig.sh # 在节点1上执行脚本会读取 settings.sh 并生成配置 ./crmconfig.sh # 脚本执行完后检查集群状态 crm status crm configure show逻辑说明crmconfig.sh内部会先校验settings.sh里的变量是否为空然后根据FENCE_MODE选择模板用sed做变量替换生成临时配置文件最后通过crm configure load灌进 Pacemaker。执行过程中如果报crm: command not found说明 Pacemaker 没装或没在 PATH 里SUSE 上一般是/usr/sbin/crm。参数说明脚本没有交互式确认执行即生效。建议第一次在测试环境跑或者先备份当前crm configure show的输出。crm status里重点看Online的节点数和资源是否都Started如果有FAILED资源用crm resource status resource看具体原因。3.3 IPMI 与 SBD 两种 fence 模式的配置差异两种模式的配置路径完全不同选错了后面 fence 测试必挂。IPMI 模式依赖每台节点带外管理口的 IPMI 能力。crmconfig.tpl里会生成stonith:external/ipmi类型的 fence 设备参数包括hostname、ipaddr、userid、passwd、interface。配置完成后必须做 fence 测试stonith_admin --reboot hana02看节点2能不能被正常重启。如果 IPMI 密码里有特殊字符settings.sh里要用单引号包起来否则sed替换时会截断。SBD 模式依赖共享存储上的一个 SBD 分区通常配合 watchdog。crmconfig-sbd.tpl生成的是stonith:external/sbd设备参数主要是pcmk_delay_max和pcmk_action_limit。SBD 模式不需要 IPMI但要求两台节点都能看到同一个 SBD 设备且 watchdog 模块已加载。常见做法是modprobe softdog并在/etc/modules-load.d/里持久化。3.4 验证集群与 HANA 资源接管配置完成后验证分三层第一层Corosync 层。corosync-cfgtool -s看 ring 状态crm_mon -1看节点是否都online。第二层Pacemaker 资源层。crm resource status确认rsc_saphana_HDB_HDB00这类资源是StartedVIP 资源rsc_ip_HDB_HDB00也在运行节点上。第三层HANA 接管层。手动触发切换crm resource move rsc_saphana_HDB_HDB00 hana02观察 HANA 主备是否按预期切换VIP 是否漂移。切换完成后crm resource clear清除 move 约束否则资源会被钉死在节点2。4. 避坑与排查脚本跑不通时先看这几条4.1 现象crm status 显示节点 offlineCorosync 起不来原因最常见的是 hostname 解析不一致或者settings.sh里NODE1_HOSTNAME和实际hostname命令输出不匹配。Corosync 用 hostname 做节点标识对不上就拒绝加入。解决两台节点分别执行hostname和cat /etc/hosts确保settings.sh里的名字和hostname输出完全一致且/etc/hosts里两台节点互相能解析。改完重启corosync和pacemaker。4.2 现象fence 测试时节点没重启集群反而脑裂原因IPMI 的lanplus参数没写对或者 IPMI 用户权限不够。脚本生成的 fence 设备参数里interface如果写成lan很多服务器 IPMI 会拒绝连接fence 动作超时后 Pacemaker 认为 fence 失败触发保护机制。解决先在命令行手动测ipmitool -I lanplus -H IPMI_IP -U user -P pass power status确认能通再跑脚本。settings.sh里IPMI_LANPLUS保持lanplus。4.3 现象HANA 资源一直 FAILED日志报 RA 找不到实例原因HANA_VERSION填错或者HANA_SID、HANA_INSTANCE和实际安装不符。HANA 2.0 的 RA 会去/usr/sap/SID/HDBInstance找实例目录路径不对直接失败。解决su - sidadm确认实例能正常HDB info然后核对settings.sh里的 SID 和 InstanceNumber。改完重新执行crmconfig.sh前先crm configure erase清掉旧配置避免残留。4.4 现象SBD 模式下节点反复重启原因SBD 设备没配好或者 watchdog 没加载。SBD 依赖 watchdog 在失去心跳时强制重启节点watchdog 没起来 SBD 就认为节点不可信。解决lsmod | grep softdog确认 watchdog 模块加载sbd -d device dump看 SBD 设备状态。SUSE 上还要确认/etc/sysconfig/sbd里的SBD_DEVICE和脚本里一致。4.5 现象VIP 漂移了但客户端连不上原因VIP 漂移后 ARP 缓存没刷新或者防火墙没放行。客户端还指着旧节点的 MAC 地址发数据。解决客户端arp -d VIP清缓存或者交换机上检查 ARP 表。SUSE 上确认firewalld或SuSEfirewall2放行了 HANA 的 30013、30015 等端口。5. 进阶把脚本纳入版本管理以及我后来固定下来的验证习惯这套脚本最大的价值不是「一键」而是把集群配置变成了可版本管理的文本。我后来的做法是把settings.sh按环境拆成settings-prod.sh、settings-test.sh连同.tpl一起丢进 Git。每次改配置先改 settings跑脚本生成crm configure show导出对比 diff确认只改了预期的那几行再提交。这样即使半年后集群出问题也能回溯到当时到底改了什么。另一个固定习惯是 fence 测试必做两遍。第一遍在业务低峰期手动stonith_admin --reboot触发确认节点能正常重启且 HANA 能自动接管第二遍模拟真实故障直接echo c /proc/sysrq-trigger让节点内核崩溃看集群能不能在无人工干预下完成切换。第二遍才是真正验证 HAE 是否可靠的关键很多配置在第一遍能过第二遍就暴露 fence 超时或 SBD 没生效的问题。还有一个细节脚本生成的 resource agent 监控间隔默认值偏保守生产环境如果对切换时间敏感可以在crmconfig.tpl里把op monitor interval从 60s 调到 30s但别低于 20s否则 HANA 的hdbnsutil调用太频繁会拖慢实例。调完记得在测试环境压一遍确认监控本身不会成为负载。从那以后我每次上 HANA HAE都强制走一遍「改 settings → 跑脚本 → crm configure show 对比 → fence 双测」的流程再也没出现过上线当天才发现 fence 不通的情况。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源面向在 SUSE Linux 平台上部署 SAP HANA 高可用环境HAE的运维与实施人员提供一套可快速落地的自动化配置脚本解决手工搭建 Corosync、Pacemaker 集群时步骤繁琐、易出错的问题。资源包共 6 个文件以 sh 脚本、tpl 模板和 txt 说明为主压缩后约 5KB体积轻巧便于随项目分发其中脚本负责执行配置流程模板用于生成集群参数说明文档则交代使用前提与注意事项。脚本兼容 SUSE 12 SPx 系列同时支持 HANA 1.0 与 HANA 2.0并覆盖基于 IPMI 与 SBD 两种 fence 模式读者无需逐条敲命令执行脚本即可完成 HAE 基础配置。目前已有 683 人学习下载适合需要快速验证 HANA 高可用方案、或希望参考脚本化配置思路的中高级 Linux 运维人员。1. 从一次 HANA 集群上线翻车说起这套 HAE 配置脚本到底省了什么去年帮一家制造企业做 SUSE 上的 SAP HANA 高可用改造两台物理机、一套 HANA 2.0 主备按官方文档手撸 Corosync 加 Pacemaker光 resource agent 的参数就调了整整两天fence 设备还因为 IPMI 的 lanplus 参数写错导致测试时脑裂。后来同事丢给我一个hana-hae-config-creator-v2.4.zip说这是圈子里流传的 SUSE HANA HAE 快速配置脚本解压后只有crmconfig.sh、crmconfig.tpl、crmconfig-sbd.tpl、settings.sh和一份 README看着简陋但把 SUSE Linux 上 SAP HANA 的 HAE 集群搭建从「查文档拼参数」变成了「改一个 settings 文件然后跑脚本」。它支持 SUSE 12 SPx覆盖 HANA 1.0 和 2.0fence 模式同时给了 IPMI 和 SBD 两条路。如果你正在被 suse_saphana_hae、suse_corosync、suse_pacemaker 这些关键词绕得头大或者手上正好有一对要上 HAE 的 HANA 节点这篇就是我把这套脚本拆开、跑通、踩坑之后留下的实操记录。2. 拆开压缩包脚本结构、模板机制与 HANA 版本适配逻辑2.1 文件清单与各自职责解压hana-hae-config-creator-v2.4.zip之后目录里是这些东西文件作用settings.sh唯一需要你手工编辑的配置文件所有节点、SID、fence 参数都在这crmconfig.sh主执行脚本读取 settings 后生成并下发集群配置crmconfig.tplIPMI fence 模式下的 crm 配置模板crmconfig-sbd.tplSBD fence 模式下的 crm 配置模板README.txt作者写的使用说明和注意事项联系作者.txt反馈渠道这个结构的关键在于「模板 变量替换」。crmconfig.sh本身不硬编码任何集群参数它把settings.sh里的变量填进.tpl模板再通过crm命令把配置灌进 Pacemaker。所以你改错一个变量生成的集群配置就会整体偏掉这也是后面避坑章节要重点说的。2.2 为什么用模板而不是直接 crm configure手写过 HANA HAE 的人都知道一个完整的集群配置包含 primitive、group、clone、location、property 好几层HANA 的 resource agent 参数又有几十个。直接crm configure edit一条条敲不仅慢而且两台节点如果配置不一致Corosync 层就可能起不来。模板机制的好处是把「结构」和「值」分离结构由作者根据 SUSE 官方最佳实践固化在.tpl里你只负责填值。常见做法是先在测试环境用模板生成一遍crm configure show导出对比官方文档确认 resource agent 的op监控间隔、timeout这些没被改坏再上生产。2.3 HANA 1.0 与 2.0 的适配差异脚本声称同时支持 HANA 1.0 和 2.0差异主要体现在 resource agent 的调用方式上。HANA 2.0 的SAPHanaRA 在crmconfig.tpl里对应的参数名和 1.0 有细微不同比如SID、InstanceNumber的取值来源以及DUPLICATE_PRIMARY_TIMEOUT这类超时参数。脚本通过settings.sh里的HANA_VERSION变量做分支判断生成不同的 primitive 定义。如果你把 2.0 的环境按 1.0 的模板配最典型的翻车是集群能起来但 HANA 资源一直FAILED因为 RA 找不到对应的实例目录。2.4 跑之前先确认的三件事在动脚本之前有三件事必须先确认否则后面全是玄学问题第一两台节点的 hostname 必须和settings.sh里写的一致且/etc/hosts互相能解析。Corosync 对 hostname 极其敏感解析不一致直接导致节点无法加入集群。第二时间同步。SUSE 上一般用 chronychronyc sources确认两台节点都同步到同一个源。时间偏差过大会让 Pacemaker 的投票机制出问题。第三确认 HANA 已经安装完成且主备关系在 HANA 层面是干净的。HAE 管的是「进程和 VIP 的切换」不负责 HANA 本身的 system replication 配置。system replication 要先在 HANA studio 或 hdbnsutil 里配好HAE 才有意义。3. 改 settings.sh 到执行 crmconfig.sh一次完整的 HAE 配置流程3.1 settings.sh 里必须改的变量settings.sh是整套脚本的入口变量不多但每个都关键。下面是我实际用的一份脱敏配置# 节点定义顺序要和 Corosync 的 ring0 一致 NODE1_HOSTNAMEhana01 NODE2_HOSTNAMEhana02 NODE1_IP192.168.10.11 NODE2_IP192.168.10.12 # HANA 实例信息 HANA_SIDHDB HANA_INSTANCE00 HANA_VERSION2.0 # 1.0 或 2.0决定 RA 参数分支 # 虚拟 IP客户端连这个 VIP192.168.10.100 VIP_MASK24 # fence 模式ipmi 或 sbd FENCE_MODEipmi # IPMI 参数SBD 模式下这几行留空 IPMI_NODE1_IP192.168.20.11 IPMI_NODE2_IP192.168.20.12 IPMI_USERadmin IPMI_PASSyourpassword IPMI_LANPLUSlanplus # SBD 模式专用 SBD_DEVICE/dev/disk/by-id/your-sbd-disk逻辑说明NODE1_HOSTNAME和NODE2_HOSTNAME会被填进 Corosync 的nodelist顺序错了会导致 ring 绑定到错误的网卡。HANA_VERSION是分支开关脚本靠它决定用哪套 RA 参数。FENCE_MODE决定加载crmconfig.tpl还是crmconfig-sbd.tpl。IPMI 的lanplus参数是血泪经验很多 IPMI 设备只认 lanplus写成 lan 会连不上。参数说明VIP_MASK用 CIDR 写法别写成255.255.255.0脚本内部按 CIDR 拼ip addr。SBD_DEVICE建议用/dev/disk/by-id/路径而不是/dev/sdb因为设备名在重启后可能变by-id 更稳。3.2 执行脚本与生成集群改完 settings 后在两台节点上分别执行# 先给脚本执行权限 chmod x crmconfig.sh # 在节点1上执行脚本会读取 settings.sh 并生成配置 ./crmconfig.sh # 脚本执行完后检查集群状态 crm status crm configure show逻辑说明crmconfig.sh内部会先校验settings.sh里的变量是否为空然后根据FENCE_MODE选择模板用sed做变量替换生成临时配置文件最后通过crm configure load灌进 Pacemaker。执行过程中如果报crm: command not found说明 Pacemaker 没装或没在 PATH 里SUSE 上一般是/usr/sbin/crm。参数说明脚本没有交互式确认执行即生效。建议第一次在测试环境跑或者先备份当前crm configure show的输出。crm status里重点看Online的节点数和资源是否都Started如果有FAILED资源用crm resource status resource看具体原因。3.3 IPMI 与 SBD 两种 fence 模式的配置差异两种模式的配置路径完全不同选错了后面 fence 测试必挂。IPMI 模式依赖每台节点带外管理口的 IPMI 能力。crmconfig.tpl里会生成stonith:external/ipmi类型的 fence 设备参数包括hostname、ipaddr、userid、passwd、interface。配置完成后必须做 fence 测试stonith_admin --reboot hana02看节点2能不能被正常重启。如果 IPMI 密码里有特殊字符settings.sh里要用单引号包起来否则sed替换时会截断。SBD 模式依赖共享存储上的一个 SBD 分区通常配合 watchdog。crmconfig-sbd.tpl生成的是stonith:external/sbd设备参数主要是pcmk_delay_max和pcmk_action_limit。SBD 模式不需要 IPMI但要求两台节点都能看到同一个 SBD 设备且 watchdog 模块已加载。常见做法是modprobe softdog并在/etc/modules-load.d/里持久化。3.4 验证集群与 HANA 资源接管配置完成后验证分三层第一层Corosync 层。corosync-cfgtool -s看 ring 状态crm_mon -1看节点是否都online。第二层Pacemaker 资源层。crm resource status确认rsc_saphana_HDB_HDB00这类资源是StartedVIP 资源rsc_ip_HDB_HDB00也在运行节点上。第三层HANA 接管层。手动触发切换crm resource move rsc_saphana_HDB_HDB00 hana02观察 HANA 主备是否按预期切换VIP 是否漂移。切换完成后crm resource clear清除 move 约束否则资源会被钉死在节点2。4. 避坑与排查脚本跑不通时先看这几条4.1 现象crm status 显示节点 offlineCorosync 起不来原因最常见的是 hostname 解析不一致或者settings.sh里NODE1_HOSTNAME和实际hostname命令输出不匹配。Corosync 用 hostname 做节点标识对不上就拒绝加入。解决两台节点分别执行hostname和cat /etc/hosts确保settings.sh里的名字和hostname输出完全一致且/etc/hosts里两台节点互相能解析。改完重启corosync和pacemaker。4.2 现象fence 测试时节点没重启集群反而脑裂原因IPMI 的lanplus参数没写对或者 IPMI 用户权限不够。脚本生成的 fence 设备参数里interface如果写成lan很多服务器 IPMI 会拒绝连接fence 动作超时后 Pacemaker 认为 fence 失败触发保护机制。解决先在命令行手动测ipmitool -I lanplus -H IPMI_IP -U user -P pass power status确认能通再跑脚本。settings.sh里IPMI_LANPLUS保持lanplus。4.3 现象HANA 资源一直 FAILED日志报 RA 找不到实例原因HANA_VERSION填错或者HANA_SID、HANA_INSTANCE和实际安装不符。HANA 2.0 的 RA 会去/usr/sap/SID/HDBInstance找实例目录路径不对直接失败。解决su - sidadm确认实例能正常HDB info然后核对settings.sh里的 SID 和 InstanceNumber。改完重新执行crmconfig.sh前先crm configure erase清掉旧配置避免残留。4.4 现象SBD 模式下节点反复重启原因SBD 设备没配好或者 watchdog 没加载。SBD 依赖 watchdog 在失去心跳时强制重启节点watchdog 没起来 SBD 就认为节点不可信。解决lsmod | grep softdog确认 watchdog 模块加载sbd -d device dump看 SBD 设备状态。SUSE 上还要确认/etc/sysconfig/sbd里的SBD_DEVICE和脚本里一致。4.5 现象VIP 漂移了但客户端连不上原因VIP 漂移后 ARP 缓存没刷新或者防火墙没放行。客户端还指着旧节点的 MAC 地址发数据。解决客户端arp -d VIP清缓存或者交换机上检查 ARP 表。SUSE 上确认firewalld或SuSEfirewall2放行了 HANA 的 30013、30015 等端口。5. 进阶把脚本纳入版本管理以及我后来固定下来的验证习惯这套脚本最大的价值不是「一键」而是把集群配置变成了可版本管理的文本。我后来的做法是把settings.sh按环境拆成settings-prod.sh、settings-test.sh连同.tpl一起丢进 Git。每次改配置先改 settings跑脚本生成crm configure show导出对比 diff确认只改了预期的那几行再提交。这样即使半年后集群出问题也能回溯到当时到底改了什么。另一个固定习惯是 fence 测试必做两遍。第一遍在业务低峰期手动stonith_admin --reboot触发确认节点能正常重启且 HANA 能自动接管第二遍模拟真实故障直接echo c /proc/sysrq-trigger让节点内核崩溃看集群能不能在无人工干预下完成切换。第二遍才是真正验证 HAE 是否可靠的关键很多配置在第一遍能过第二遍就暴露 fence 超时或 SBD 没生效的问题。还有一个细节脚本生成的 resource agent 监控间隔默认值偏保守生产环境如果对切换时间敏感可以在crmconfig.tpl里把op monitor interval从 60s 调到 30s但别低于 20s否则 HANA 的hdbnsutil调用太频繁会拖慢实例。调完记得在测试环境压一遍确认监控本身不会成为负载。从那以后我每次上 HANA HAE都强制走一遍「改 settings → 跑脚本 → crm configure show 对比 → fence 双测」的流程再也没出现过上线当天才发现 fence 不通的情况。希望帮到你。本文还有配套的精品资源点击获取
