简介这份资源是面向SUSE Linux平台SAP HANA高可用部署运维人员的HAE快速配置脚本适合已具备一定Linux与集群基础、需要简化HAE搭建流程的中高级工程师。它针对SUSE 12 SPx环境兼容HANA 1.0与2.0并同时支持基于IPMI与SBD两种fence模式可帮助读者跳过繁琐的手工配置通过执行脚本快速完成HAE集群搭建。压缩包共6个文件以sh脚本、tpl模板和txt说明文档为主脚本负责核心配置逻辑模板用于生成corosync与pacemaker相关配置说明文档则提供使用指引整体仅约5KB轻量易用。目前已有687人学习下载读者可借此获得一套可直接复用的HAE配置工具理解SUSE HAE在HANA场景下的参数组织方式并对照模板与脚本快速完成集群初始化与fence策略选择减少手工排错成本。1. SUSE Linux 上 SAP HANA HAE 配置脚本到底在解决什么问题生产环境里跑 SAP HANA 的 SUSE Linux 服务器最怕的不是数据库本身崩而是主节点挂了之后备节点没接上。SUSE Linux Enterprise Server for SAP Applications 自带一套 HAEHigh Availability Extension栈底层是 Pacemaker Corosync再叠上 SAPHanaSR 资源代理才能实现 HANA 系统的自动故障切换。但真正落地时你会发现光装完 HAE 软件包根本不够——集群资源怎么建、约束怎么加、STONITH 怎么配、HANA 的 hook 脚本怎么挂每一步都有坑。所谓“HAE 配置脚本”本质就是把这一整套集群资源配置动作脚本化、可重复化让每次部署或重建集群时不用靠手敲crm命令碰运气。这套东西适合谁适合正在 SUSE Linux 上部署或维护 SAP HANA 高可用架构的运维工程师、BASIS 顾问以及需要把集群搭建流程标准化的团队。下面我从原理到脚本一步步拆开讲。2. HAE 集群与 SAPHanaSR 资源代理先搞懂谁在管谁2.1 Pacemaker、Corosync 和 SAPHanaSR 的分工SUSE Linux 的 HAE 不是单一软件而是一组组件协同工作。Corosync 负责集群节点间的通信和成员管理它跑在底层决定哪些节点在线、哪些失联。Pacemaker 跑在 Corosync 之上负责资源调度和决策——谁该跑 HANA谁该待命什么时候切换。SAPHanaSR 则是一个 Pacemaker 资源代理Resource Agent专门用来管理 SAP HANA 实例的启动、停止和状态监控。三者关系可以这样理解Corosync 是“神经系统”Pacemaker 是“大脑”SAPHanaSR 是“手”。大脑通过神经系统感知节点状态再通过手去操作 HANA 实例。配置脚本要做的就是告诉 PacemakerHANA 主实例和备实例分别是什么资源、它们之间有什么依赖、什么条件下触发切换。SUSE 提供了两个资源代理SAPHana和SAPHanaTopology。前者管理 HANA 实例的启停和复制状态后者负责收集 HANA 的拓扑信息比如哪个节点是主、哪个是备、复制模式是什么。两个代理必须配合使用缺一不可。2.2 集群资源配置的脚本化思路手工配置 HAE 集群的典型流程是先crm configure进入交互模式然后逐条输入primitive、ms、clone、location、colocation、order等命令。问题是这些命令一旦敲错排查起来非常痛苦而且换一套环境就得重来一遍。脚本化的思路是把这些配置命令写成一个可执行的 shell 脚本用crm configure load或者直接管道输入的方式批量执行。好处有三个第一配置过程可版本控制第二重建集群时一键执行第三团队之间可以共享同一套标准配置。我一般会把脚本分成三段第一段定义变量节点名、HANA SID、实例编号、虚拟 IP 等第二段清理旧配置如果是重建场景第三段逐条创建资源、约束和属性。下面是一个最小可用的脚本骨架#!/bin/bash # hana-hae-setup.sh - SUSE HAE 集群资源配置脚本 # 用法: ./hana-hae-setup.sh SID InstanceNumber Node1 Node2 VirtualIP set -euo pipefail SID${1:?请传入 HANA SID如 HDB} INSTANCE${2:?请传入实例编号如 00} NODE1${3:?请传入主节点主机名} NODE2${4:?请传入备节点主机名} VIP${5:?请传入虚拟 IP} # 清理已有配置谨慎使用仅限重建场景 crm configure property maintenance-modetrue crm configure erase crm configure property maintenance-modefalse # 设置集群基础属性 crm configure property stonith-enabledtrue crm configure property no-quorum-policyignore # 创建 SAPHanaTopology 克隆资源 crm configure primitive rsc_SAPHanaTopology_${SID}_HDB${INSTANCE} ocf:suse:SAPHanaTopology \ params SID${SID} InstanceNumber${INSTANCE} \ op monitor interval10 timeout600 \ op start interval0 timeout600 \ op stop interval0 timeout300 crm configure clone cln_SAPHanaTopology_${SID}_HDB${INSTANCE} \ rsc_SAPHanaTopology_${SID}_HDB${INSTANCE} \ meta clone-node-max1 interleavetrue # 创建 SAPHana 主备资源 crm configure primitive rsc_SAPHana_${SID}_HDB${INSTANCE} ocf:suse:SAPHana \ params SID${SID} InstanceNumber${INSTANCE} \ PREFER_SITE_TAKEOVERtrue DUPLICATE_PRIMARY_TIMEOUT7200 AUTOMATED_REGISTERtrue \ op start interval0 timeout3600 \ op stop interval0 timeout3600 \ op monitor interval60 timeout700 \ op promote interval0 timeout3600 \ op demote interval0 timeout3200 crm configure ms msl_SAPHana_${SID}_HDB${INSTANCE} \ rsc_SAPHana_${SID}_HDB${INSTANCE} \ meta clone-node-max1 interleavetrue notifytrue # 创建虚拟 IP 资源 crm configure primitive rsc_ip_${SID}_HDB${INSTANCE} ocf:heartbeat:IPaddr2 \ params ip${VIP} cidr_netmask32 \ op monitor interval10 timeout20 # 创建约束IP 跟随主 HANA 实例 crm configure colocation col_ip_with_hana inf: rsc_ip_${SID}_HDB${INSTANCE} msl_SAPHana_${SID}_HDB${INSTANCE}:Master # 创建顺序约束Topology 先于 HANA 启动 crm configure order ord_topology_before_hana inf: cln_SAPHanaTopology_${SID}_HDB${INSTANCE} msl_SAPHana_${SID}_HDB${INSTANCE} # 设置节点偏好 crm configure location loc_hana_prefer_${NODE1} msl_SAPHana_${SID}_HDB${INSTANCE} 100: ${NODE1} crm configure location loc_hana_prefer_${NODE2} msl_SAPHana_${SID}_HDB${INSTANCE} 50: ${NODE2} echo HAE 集群资源配置完成请用 crm status 检查状态。这段脚本的核心逻辑是先清理旧配置再按依赖顺序创建资源。SAPHanaTopology是克隆资源跑在所有节点上SAPHana是主备资源用ms声明同一时间只有一个节点是 Master。虚拟 IP 通过colocation约束绑定到 Master 节点上确保客户端始终连到主实例。参数说明几个关键点PREFER_SITE_TAKEOVERtrue表示优先在备节点接管而不是尝试重启原主节点DUPLICATE_PRIMARY_TIMEOUT7200是防止双主脑裂的等待时间单位秒AUTOMATED_REGISTERtrue让备节点在切换后自动注册为新的备节点。这些参数直接决定故障切换的行为设错了要么切不过去要么切过去回不来。2.3 验证集群资源是否按预期运行脚本执行完不代表万事大吉必须验证。第一步看crm status输出确认所有资源都是Startedmsl_SAPHana显示一个Master一个Slave。第二步用crm_mon -1 -r查看资源详情和失败计数。第三步在 HANA 层面用hdbnsutil -sr_state确认复制状态是ACTIVE。如果crm status里看到资源在FAILED状态先别急着重启集群用crm resource failcount resource show node看失败原因。常见的是 HANA 实例没起来、监控超时、或者权限不对。SAPHanaSR 的资源代理需要sidadm用户能免密执行 HANA 的hdbnsutil和sapcontrol命令这个权限没配好资源永远起不来。3. STONITH 与节点隔离不配这个集群就是纸老虎3.1 为什么 STONITH 是 HAE 的必选项STONITHShoot The Other Node In The Head是 Pacemaker 的节点隔离机制。没有 STONITH集群在脑裂场景下无法确定哪个节点该继续服务可能导致两个节点同时挂载同一份 HANA 数据后果是数据损坏。SUSE HAE 默认stonith-enabledtrue如果你不配 STONITH 设备集群会拒绝启动任何资源。在物理机上STONITH 通常通过 IPMI、iLO、iDRAC 等带外管理接口实现。在虚拟化环境里可以用fence_azure_arm、fence_aws、fence_vmware_soap等代理。SUSE 也提供了external/sbd作为共享块设备隔离方案但 SBD 需要额外的共享存储配置复杂度更高。我一般推荐用 IPMI 方案因为最直接、最可靠。配置命令如下# 创建 STONITH 资源每个节点一个 crm configure primitive rsc_stonith_node1 stonith:fence_ipmilan \ params ipaddr192.168.1.101 loginadmin passwdxxxxx lanplus1 \ op monitor interval60 timeout60 crm configure primitive rsc_stonith_node2 stonith:fence_ipmilan \ params ipaddr192.168.1.102 loginadmin passwdxxxxx lanplus1 \ op monitor interval60 timeout60 # 设置 STONITH 资源的位置约束确保每个节点用对应的隔离设备 crm configure location loc_stonith_node1 rsc_stonith_node1 -inf: node1 crm configure location loc_stonith_node2 rsc_stonith_node2 -inf: node2注意-inf的含义是“永远不在该节点上运行”。rsc_stonith_node1是用来隔离 node1 的所以它不能跑在 node1 上否则 node1 挂了它也没了。这个逻辑反直觉但必须这样配。3.2 测试 STONITH 是否真的能隔离节点配完 STONITH 一定要测试。测试方法是手动触发隔离crm node fence node。如果配置正确目标节点会被强制重启集群日志里能看到 fence 成功的记录。如果失败检查 IPMI 地址是否可达、用户名密码是否正确、lanplus参数是否匹配你的 BMC 版本。注意在生产环境测试 STONITH 前确认业务已经切换到备节点否则强制重启主节点会导致服务中断。测试通过后用crm configure show导出完整配置保存到安全位置。这份配置就是你的“后悔药”集群彻底崩了可以快速恢复。3.3 资源约束的常见误配与修正约束是 HAE 配置里最容易出错的部分。colocation定义资源之间的位置关系order定义启动顺序location定义节点偏好。三者写错任何一个集群行为都会异常。一个典型误配是把colocation的分数设成了INFINITY以外的值。比如colocation col_ip_with_hana 100: rsc_ip msl_SAPHana:Master这个 100 分意味着 IP 资源“倾向于”跟 Master 在一起但不是强制。当 Master 切换时IP 可能不会跟着走。正确做法是用inf:表示强制约束。另一个常见问题是order约束的方向搞反。order ord_topology_before_hana inf: cln_SAPHanaTopology msl_SAPHana表示 Topology 先启动HANA 后启动。如果写成msl_SAPHana cln_SAPHanaTopologyHANA 会在 Topology 之前启动导致资源代理拿不到拓扑信息监控失败。修正方法是每次改完约束后用crm configure show检查一遍再用crm_simulate -sL模拟集群调度看资源是否会按预期分布。crm_simulate是验证约束逻辑的利器强烈建议在应用配置前跑一次。4. HANA Hook 脚本与集群的联动切换后自动注册怎么实现4.1 SAPHanaSR hook 脚本的作用与挂载位置SAPHanaSR 资源代理在检测到 HANA 主备切换后需要通知 HANA 层面更新复制关系。这个通知机制靠的是 HANA 的 hook 脚本。具体来说SUSE 提供了一个 Python 脚本SAPHanaSR.py需要挂到 HANA 的global.ini配置里让 HANA 在状态变化时回调它。挂载位置在/usr/sap/SID/SYS/global/hdb/custom/config/global.ini需要添加以下段落[ha_dr_provider_suschksrv] provider susChkSrv path /usr/share/SAPHanaSR execution_order 1 action_on_lost kill [ha_dr_provider_saphanasr] provider SAPHanaSR path /usr/share/SAPHanaSR execution_order 2 [trace] ha_dr_saphanasr infoha_dr_provider_saphanasr是主 hook负责在 HANA 状态变化时通知集群。ha_dr_provider_suschksrv是辅助 hook用于在 HANA 进程异常时触发隔离。action_on_lost kill表示如果 HANA 主进程丢失直接杀掉节点上的 HANA 进程让集群感知到故障。4.2 用脚本自动写入 hook 配置并校验手工编辑global.ini容易漏行或缩进错误我一般用脚本追加#!/bin/bash # setup-hana-hook.sh - 配置 HANA hook 脚本 SID${1:?请传入 HANA SID} GLOBAL_INI/usr/sap/${SID}/SYS/global/hdb/custom/config/global.ini if [ ! -f $GLOBAL_INI ]; then echo 错误$GLOBAL_INI 不存在请确认 HANA 已安装。 exit 1 fi # 备份原配置 cp $GLOBAL_INI ${GLOBAL_INI}.bak.$(date %Y%m%d%H%M%S) # 检查是否已存在 hook 配置避免重复写入 if grep -q ha_dr_provider_saphanasr $GLOBAL_INI; then echo hook 配置已存在跳过写入。 else cat $GLOBAL_INI EOF [ha_dr_provider_suschksrv] provider susChkSrv path /usr/share/SAPHanaSR execution_order 1 action_on_lost kill [ha_dr_provider_saphanasr] provider SAPHanaSR path /usr/share/SAPHanaSR execution_order 2 [trace] ha_dr_saphanasr info EOF echo hook 配置已写入 $GLOBAL_INI fi # 校验 Python 脚本是否存在 if [ ! -f /usr/share/SAPHanaSR/SAPHanaSR.py ]; then echo 警告/usr/share/SAPHanaSR/SAPHanaSR.py 不存在请确认 SAPHanaSR 包已安装。 fi写入后需要重启 HANA 实例才能生效。重启前用hdbnsutil -sr_state确认复制状态正常重启后用crm_mon -1 -r确认集群资源没有异常。4.3 切换后备节点自动注册的验证方法自动注册的核心参数是AUTOMATED_REGISTERtrue。当主节点故障、备节点接管后原主节点恢复时会自动注册为新的备节点。验证方法是手动触发一次切换crm resource move msl_SAPHana_SID_HDBINSTANCE 备节点然后观察crm status和hdbnsutil -sr_state的输出。如果自动注册失败检查三个地方第一AUTOMATED_REGISTER是否真的设成了true第二原主节点上的 HANA 实例是否被正确停止第三global.ini里的 hook 配置是否在重启后生效。常见错误是 hook 配置写入了但没重启 HANA导致资源代理拿不到状态更新。提示切换测试建议在业务低峰期做并且提前通知相关方。切换过程中 HANA 连接会短暂中断客户端需要重连。5. 避坑与排查HAE 配置脚本落地时最容易翻车的 5 个点5.1 现象集群资源全部 Stoppedcrm status 显示 “no quorum”原因Corosync 的 quorum 策略没设对。两节点集群默认需要两票才能形成 quorum一个节点挂了就失去 quorumPacemaker 会停止所有资源。解决crm configure property no-quorum-policyignore让集群在单节点时也能继续运行。这个属性必须在集群启动前设置已经失去 quorum 时可以用crm configure property maintenance-modetrue临时进入维护模式再改。5.2 现象SAPHana 资源启动超时日志显示 “hdbnsutil not found”原因资源代理执行hdbnsutil时用的 PATH 不对。Pacemaker 以 root 用户运行资源代理但hdbnsutil在sidadm的环境变量里。解决在/usr/sap/SID/SYS/global/hdb/custom/config/下确认hdbnsutil路径或者在资源代理参数里显式指定DIR_EXECUTABLE。SUSE 的 SAPHanaSR 代理通常会自动读取sidadm的环境但如果 HANA 安装不完整或环境变量被覆盖就会找不到命令。5.3 现象STONITH 资源创建成功但 fence 失败日志报 “Unable to connect to IPMI”原因BMC 的 IPMI 版本和lanplus参数不匹配。老版本 BMC 可能只支持 IPMI 1.5不支持 2.0 的lanplus。解决先手动测试ipmitool -I lanplus -H bmc_ip -U user -P pass power status如果失败就换成-I lan再试。确认能通之后把lanplus1改成lanplus0或者去掉这个参数。另外检查 BMC 的防火墙是否放行了 623 端口。5.4 现象HANA 切换后备节点没有自动注册hdbnsutil -sr_state 显示 “Not registered”原因AUTOMATED_REGISTER参数没生效或者 hook 脚本没执行。解决先确认crm configure show里AUTOMATED_REGISTERtrue确实存在。然后检查/usr/sap/SID/SYS/global/hdb/custom/config/global.ini里的 hook 配置确认ha_dr_provider_saphanasr段落存在且路径正确。最后看 HANA 的nameservertrace 日志搜索SAPHanaSR关键字看 hook 是否被调用。如果 hook 没被调用大概率是global.ini格式错误或者 HANA 没重启。5.5 现象集群正常运行但虚拟 IP 漂移到了备节点原因colocation约束的分数不够强制或者location约束的优先级冲突。解决检查colocation col_ip_with_hana是否用了inf:前缀。如果用了inf:还是漂移检查location约束里是否给备节点设了更高的分数。location的分数会覆盖colocation的约束所以备节点的location分数必须低于主节点。我一般把主节点设 100备节点设 50这样正常情况下 IP 永远在主节点上。6. 用 crm_simulate 做切换预演不碰生产环境也能验证配置6.1 crm_simulate 的基本用法和输出解读crm_simulate是 Pacemaker 自带的模拟工具可以在不实际改变集群状态的前提下模拟节点故障、资源故障、手动切换等场景看集群会怎么调度。基本命令是# 模拟 node1 故障看资源会怎么迁移 crm_simulate -sL -N node1 # 模拟手动切换 SAPHana 主资源到 node2 crm_simulate -sL -m msl_SAPHana_HDB_00 -M node2 # 输出完整的调度决策过程 crm_simulate -sL -vvv-s表示保存模拟结果-L表示输出详细日志-N指定故障节点-m指定要迁移的资源-M指定目标节点。输出里会显示每个资源的promote、start、stop、migrate动作以及决策原因。6.2 用模拟结果反推约束配置是否正确模拟输出里最关键的是Transition Summary段落它列出了集群将要执行的所有动作。如果模拟 node1 故障后msl_SAPHana的promote动作发生在 node2 上rsc_ip也跟着迁移到 node2说明约束配置正确。如果rsc_ip没跟着走或者msl_SAPHana没有promote动作说明colocation或order约束有问题。我一般会在应用任何约束变更前跑三次模拟一次模拟主节点故障一次模拟备节点故障一次模拟手动切换。三次都符合预期才把配置写入集群。这个习惯帮我省了很多次生产环境的“血泪排查”。6.3 把模拟验证写进配置脚本的收尾步骤好的配置脚本不应该只负责“配”还应该负责“验”。我习惯在脚本最后加一段模拟验证# 模拟验证检查约束是否按预期工作 echo 模拟 node1 故障 crm_simulate -sL -N ${NODE1} | grep -A 20 Transition Summary echo 模拟 node2 故障 crm_simulate -sL -N ${NODE2} | grep -A 20 Transition Summary echo 模拟手动切换 crm_simulate -sL -m msl_SAPHana_${SID}_HDB${INSTANCE} -M ${NODE2} | grep -A 20 Transition Summary这段代码不改变集群状态只是输出模拟结果。执行完脚本后人工看一眼输出确认资源迁移路径符合预期再正式启用集群。这个步骤花不了两分钟但能避免很多上线后的意外。6.4 一个我踩过的坑模拟通过但实际切换失败有一次模拟显示一切正常但实际切换时 HANA 备节点没起来。排查后发现是 HANA 的global.ini里ha_dr_provider_saphanasr的path写错了模拟工具只检查 Pacemaker 层面的资源调度不检查 HANA 层面的 hook 是否可用。所以模拟通过只是第一步实际切换测试才是最终验证。我的习惯是模拟验证通过后在业务低峰期做一次真实切换观察crm status、hdbnsutil -sr_state和 HANA trace 日志三处输出。三处都正常才算这套 HAE 配置脚本真正落地。希望帮到你。本文还有配套的精品资源点击获取