简介这是一份面向SUSE Linux平台SAP HANA高可用部署运维人员的HAE快速配置脚本适合已具备一定Linux与集群基础、需要简化HAE搭建流程的中高级工程师使用。资源以脚本化方式替代繁琐的手工配置帮助读者在SUSE 12 SPx环境下快速完成HANA HAE集群搭建兼容HANA 1.0与2.0并支持基于IPMI与SBD两种fence模式覆盖corosync、pacemaker等核心组件。压缩包共6个文件约5KB包含2个sh执行脚本、2个tpl配置模板与2个txt说明文档脚本负责自动化配置模板提供集群参数骨架说明文档辅助理解与调整。目前已有687人学习下载。读者可借助该脚本省去逐条命令调试的时间快速获得可复用的HAE配置框架并依据模板与说明按实际环境调整fence方式与集群参数降低部署出错概率。1. SUSE Linux 上 SAP HANA HAE 配置脚本为什么手工搭集群总在细节上翻车在 SUSE Linux 上给 SAP HANA 配 HAEHigh Availability Extension集群很多人第一次做都会觉得“不就是装个 pacemaker、加几个资源嘛”结果一到切换测试就各种玄学资源起不来、STONITH 报错、VIP 漂移后连不上、HANA 主备角色识别错。问题不在命令本身而在于 HANA 的 HA 集成有大量隐式约束——文件系统挂载顺序、SAP HANA 的 srHook、集群资源的依赖链、stonith 设备的超时参数任何一个没对齐集群就是“看起来正常一切换就翻车”。这篇笔记围绕“SUSE Linux SAP HANA HAE 配置脚本”这个主题把我在实际项目里反复用到的配置脚本拆开讲。目标读者是需要在 SUSE Linux Enterprise Server 上为 SAP HANA 搭建高可用集群的运维和 BASIS 人员尤其是那些不想每次手工敲几十条 crm 命令、希望用脚本固化流程的人。读完你应该能拿到一套可复现的脚本框架知道每个参数为什么这么设以及哪些坑必须提前避开。2. HAE 集群与 SAP HANA 集成的底层逻辑先搞清资源模型再写脚本2.1 SAP HANA 在 HAE 里到底被拆成哪些资源SUSE HAE 基于 Pacemaker CorosyncSAP HANA 的集成不是简单加一个“HANA 资源”就完事。实际集群里至少涉及这几类资源文件系统资源/hana/shared、/hana/data、/hana/log通常用 NFS 或共享块设备需要Filesystem资源或nfsserver相关资源来管理挂载点。虚拟 IP 资源客户端通过一个浮动 IP 访问 HANA切换时 IP 要跟着主节点走用IPaddr2或IPaddr。SAP HANA 资源由SAPHana和SAPHanaTopology两个 RAResource Agent组成。SAPHanaTopology负责探测节点上 HANA 的安装和运行状态SAPHana负责启动、停止、监控 HANA 实例并管理主备角色。STONITH 资源防止脑裂的隔离设备常见的是 SBDStorage-Based Death或外部电源管理SUSE 环境里 SBD 用得最多。脚本要做的就是按正确顺序创建这些资源并设置好约束。顺序错了比如先起SAPHana再挂文件系统HANA 启动时找不到数据目录资源直接失败。2.2 为什么用脚本而不是手工敲 crm 命令手工敲crm configure的问题不是不会而是不可重复。今天搭一套环境明天换一套参数稍微不一样就出问题。脚本的好处是把所有参数、资源名、约束关系固化下来版本可控出问题能 diff。我一般会把脚本分成三段环境预检、资源创建、约束与属性设置。每段都可以单独执行方便排查。下面是一个资源创建脚本的核心片段用 bash 调用crm命令。注意这里用的是crm configure的批处理模式不是交互式。#!/bin/bash # hana_hae_resources.sh # 创建 SAP HANA HAE 集群资源 # 假设集群已用 crm cluster init 初始化且 corosync 正常 set -euo pipefail # 节点名根据实际环境修改 NODE1hana-node1 NODE2hana-node2 # 虚拟 IP 和网卡 VIP192.168.10.100 VIP_MASK24 VIP_IFeth0 # HANA 实例信息 SIDHDB INSTANCE00 # 共享文件系统挂载点假设已配置 NFS FS_SHARED/hana/shared FS_DATA/hana/data FS_LOG/hana/log # SBD 设备 SBD_DEV/dev/disk/by-id/scsi-3600a09803830442f552b4a4a4a4a4a4a crm configure EOF property cib-bootstrap-options: \ have-watchdogtrue \ stonith-enabledtrue \ stonith-timeout300s \ stonith-actionreboot \ cluster-recheck-interval2min \ maintenance-modefalse # 全局属性HANA 相关超时 property cib-bootstrap-options: \ stonith-timeout300s # 节点属性设置 HANA 相关参数 node $NODE1 \ attributes hana_$SID\_sitesite1 \ hana_$SID\_vhost$NODE1 node $NODE2 \ attributes hana_$SID\_sitesite2 \ hana_$SID\_vhost$NODE2 # 文件系统资源 primitive fs_shared Filesystem \ params devicenfs-server:/export/hana/shared \ directory$FS_SHARED \ fstypenfs \ optionsvers4.1 \ op start timeout60s interval0 \ op stop timeout60s interval0 \ op monitor timeout40s interval20s primitive fs_data Filesystem \ params devicenfs-server:/export/hana/data \ directory$FS_DATA \ fstypenfs \ optionsvers4.1 \ op start timeout60s interval0 \ op stop timeout60s interval0 \ op monitor timeout40s interval20s primitive fs_log Filesystem \ params devicenfs-server:/export/hana/log \ directory$FS_LOG \ fstypenfs \ optionsvers4.1 \ op start timeout60s interval0 \ op stop timeout60s interval0 \ op monitor timeout40s interval20s # 虚拟 IP primitive vip IPaddr2 \ params ip$VIP cidr_netmask$VIP_MASK nic$VIP_IF \ op start timeout20s interval0 \ op stop timeout20s interval0 \ op monitor timeout20s interval10s # SAPHanaTopology 资源 primitive rsc_hana_topology SAPHanaTopology \ params SID$SID \ op start timeout600s interval0 \ op stop timeout300s interval0 \ op monitor timeout600s interval60s # SAPHana 资源 primitive rsc_hana SAPHana \ params SID$SID InstanceNumber$INSTANCE \ op start timeout3600s interval0 \ op stop timeout3600s interval0 \ op monitor timeout700s interval60s \ op promote timeout3600s interval0 \ op demote timeout3600s interval0 # 克隆资源SAPHanaTopology 需要在所有节点运行 clone cln_hana_topology rsc_hana_topology \ meta clone-max2 clone-node-max1 interleavetrue # 主备资源SAPHana 是 master/slave 类型 ms msl_hana rsc_hana \ meta master-max1 master-node-max1 clone-max2 clone-node-max1 \ notifytrue target-roleStarted # 组资源把文件系统、VIP 和 HANA 主资源绑在一起 group grp_hana fs_shared fs_data fs_log vip msl_hana EOF echo 资源创建完成请用 crm_mon -Af 检查状态这段脚本的关键点SAPHanaTopology必须是 clone因为每个节点都要探测本地 HANA 状态。SAPHana必须是 master/slavems因为 HANA 有主备角色。文件系统和 VIP 放在 group 里保证启动顺序先挂文件系统再起 VIP最后起 HANA。stonith-timeout设 300s因为 HANA 停止可能很慢隔离超时太短会导致误判。参数说明SID和InstanceNumber必须和实际 HANA 安装一致hana_$SID\_site和hana_$SID\_vhost是 SAPHana RA 依赖的节点属性不设的话资源代理无法正确判断站点和虚拟主机名。2.3 约束让资源知道谁先谁后资源创建完只是第一步约束才是决定切换行为的核心。最常见的约束包括order文件系统 → VIP → HANA保证启动顺序。colocationHANA 主资源必须和 VIP、文件系统在同一节点。location根据站点属性决定主节点偏好。脚本里可以用crm configure继续追加crm configure EOF # 顺序约束文件系统先于 VIPVIP 先于 HANA order ord_fs_vip inf: fs_shared fs_data fs_log vip order ord_vip_hana inf: vip msl_hana:promote # 同节点约束HANA 主资源与 VIP、文件系统在一起 colocation col_hana_vip inf: msl_hana:Master vip colocation col_hana_fs inf: msl_hana:Master fs_shared fs_data fs_log # 位置约束site1 优先 location loc_hana_site1 msl_hana 100: hana-node1 location loc_hana_site2 msl_hana 50: hana-node2 EOFinf表示无穷大意味着约束必须满足。msl_hana:Master表示只约束主资源。位置约束的分数决定优先级100 比 50 高所以 site1 优先。提示约束不要一次加太多每加一条用crm_mon -Af看状态确认没有资源进入 FAILED 再继续。3. 配置脚本的落地步骤从环境预检到切换验证3.1 环境预检脚本跑之前必须确认的 5 件事脚本不是万能药环境不对脚本跑完也是白搭。我一般在跑配置脚本前先手动确认这几项SUSE HAE 扩展已安装zypper se -i ha看pacemaker、corosync、saphanabootstrap-formula等包是否齐全。NFS 共享已挂载且权限正确showmount -e nfs-server确认导出mount确认挂载点chown确认 HANA 用户有权限。SBD 设备可用sbd -d /dev/disk/by-id/... dump能读出元数据fdisk -l确认设备存在。HANA 已安装且能手动启动在切换前先确保 HANA 本身能正常起停否则集群资源永远起不来。主机名和 hosts 解析正确hostname -f和ping确认节点间能互相解析Corosync 依赖这个。这些检查可以写进脚本开头用if判断不满足就退出。# 预检片段 check_hae_installed() { rpm -q pacemaker corosync /dev/null 21 || { echo HAE 包未安装请先 zypper install ha_sles exit 1 } } check_nfs_mounted() { mountpoint -q /hana/shared || { echo /hana/shared 未挂载 exit 1 } } check_sbd_device() { sbd -d $SBD_DEV dump /dev/null 21 || { echo SBD 设备 $SBD_DEV 不可用 exit 1 } }3.2 用脚本初始化集群并配置 SBD集群初始化本身也可以用脚本封装。SUSE 的crm cluster init是交互式的但可以用-y和参数跳过交互。#!/bin/bash # hana_hae_init.sh # 初始化 HAE 集群并配置 SBD set -euo pipefail NODE1hana-node1 NODE2hana-node2 SBD_DEV/dev/disk/by-id/scsi-3600a09803830442f552b4a4a4a4a4a4a # 在 node1 上执行 crm cluster init -y \ -n $NODE1 \ --interface eth0 \ --sbd-device $SBD_DEV \ --watchdog /dev/watchdog # 加入 node2 crm cluster join -y -c $NODE1crm cluster init会自动配置 Corosync、Pacemaker、SBD 和 watchdog。--sbd-device指定共享存储上的 SBD 分区--watchdog指定硬件看门狗设备。如果环境里没有独立 watchdog可以用softdog模块但生产环境建议用硬件 watchdog。初始化完成后用crm status确认两个节点都在线crm_mon -Af看资源状态。3.3 资源创建与约束的脚本化把 crm configure 批处理用对前面第 2 章已经给了资源创建脚本这里补充几个实操细节crm configure 批处理模式用crm configure EOF ... EOF可以一次提交多条配置比逐条敲快得多。但要注意如果中间有一条语法错误整个批处理会回滚所以建议分段提交。资源名不要用中文或特殊字符Pacemaker 对资源名有命名规范用字母、数字、下划线、连字符。op 参数要按实际环境调比如SAPHana的start timeout默认 3600s如果 HANA 启动慢可以加大monitor interval默认 60s太短会增加负载太长会延迟故障发现。一个常见的坑是SAPHanaTopology的monitor超时设得太短导致探测失败资源被误判为 FAILED。我一般设 600s因为 HANA 的拓扑探测可能涉及数据库查询。3.4 切换验证手动触发一次看脚本是否真的可靠配置完不验证等于没配。切换验证分两步手动迁移crm resource move msl_hana hana-node2观察资源是否正常停止、VIP 是否漂移、HANA 是否在 node2 上启动。模拟故障crm node standby hana-node1让 node1 进入待机集群自动把资源迁到 node2。验证时重点看crm_mon -Af里资源是否都Started有没有FAILED。SAPHana资源的主备角色是否正确切换。VIP 漂移后客户端能否通过 VIP 连上 HANA。/var/log/pacemaker/pacemaker.log里有没有 ERROR 或 WARN。如果切换失败先看crm_mon -Af的资源失败原因再用crm resource cleanup 资源名清理失败状态重新测试。注意切换测试前一定要确认 HANA 数据已同步否则主备切换后数据不一致后果很严重。4. 避坑与排查HAE 配置脚本最常见的 5 个翻车现场4.1 现象SAPHana 资源一直 FAILED日志报 “Failed to connect to HANA”原因SAPHanaTopology没有正确探测到 HANA 实例或者SID、InstanceNumber参数写错。另一个常见原因是 HANA 的srHook没启用导致 RA 无法获取主备角色。解决检查/usr/sap/$SID/HDB$INSTANCE/work/下的srHook脚本是否存在且可执行。在 HANA 里执行hdbnsutil -sr_enable和hdbnsutil -sr_register确保系统复制已配置。然后crm resource cleanup rsc_hana清理失败状态重启资源。4.2 现象VIP 漂移后客户端连不上但 ping 得通原因VIP 漂移了但 HANA 的global.ini里public_hostname还是旧节点的主机名客户端解析后连到旧节点。或者防火墙没放行新节点上的 HANA 端口。解决在 HANA 的global.ini里把public_hostname设为 VIP 对应的主机名而不是物理节点名。检查firewall-cmd --list-all确认 30013、30015 等端口已放行。4.3 现象STONITH 超时节点被误隔离原因stonith-timeout设得太短HANA 停止需要几分钟隔离设备等不及就把节点重启了。或者 SBD 设备延迟高sbd心跳超时。解决把stonith-timeout调到 300s 以上SAPHana的stop timeout也相应加大。用sbd -d $SBD_DEV dump看 SBD 的timeout和watchdog参数确保timeout大于 HANA 停止时间。4.4 现象集群启动后资源乱序HANA 先于文件系统启动原因没有配 order 约束或者约束的inf写成了0导致约束不生效。解决用crm configure show检查 order 约束是否存在且score为inf。如果资源已经乱序启动先crm resource stop停掉所有资源再加约束重新启动。4.5 现象脚本执行到一半报 “crm configure” 语法错误原因crm configure批处理里用了 shell 变量但变量没展开或者换行符不对。比如$SID在 heredoc 里被 shell 展开了但crm不认。解决在 heredoc 里用\$转义或者把变量提前拼成字符串再传给crm。更稳妥的做法是用crm configure load从文件加载文件里用实际值。5. 进阶技巧用 crm 脚本做参数化与版本管理5.1 把配置脚本参数化一套脚本适配多套环境实际项目里不可能只搭一套 HANA 集群SID、节点名、VIP、NFS 路径都可能不同。我一般把脚本拆成两部分一个env.conf存环境变量一个deploy.sh读配置并执行。# env.conf SIDHDB INSTANCE00 NODE1hana-node1 NODE2hana-node2 VIP192.168.10.100 VIP_MASK24 VIP_IFeth0 FS_SHARED_DEVnfs-server:/export/hana/shared FS_DATA_DEVnfs-server:/export/hana/data FS_LOG_DEVnfs-server:/export/hana/log SBD_DEV/dev/disk/by-id/scsi-3600a09803830442f552b4a4a4a4a4a4a# deploy.sh source ./env.conf crm configure EOF primitive rsc_hana SAPHana \ params SID$SID InstanceNumber$INSTANCE \ op start timeout3600s interval0 \ op stop timeout3600s interval0 \ op monitor timeout700s interval60s EOF这样换环境只需要改env.conf脚本本身不动。5.2 用 crm 的 load 和 diff 做版本管理crm configure save可以把当前配置导出到文件crm configure load可以从文件加载。我习惯每次变更前先crm configure save /tmp/cib-before.xml变更后crm configure save /tmp/cib-after.xml然后diff看改了什么。这样出问题能快速回滚。# 导出当前配置 crm configure save /tmp/cib-$(date %Y%m%d-%H%M).xml # 加载配置谨慎使用会覆盖当前配置 crm configure load replace /tmp/cib-20250101-1200.xmlreplace是覆盖update是合并。生产环境建议用update避免误覆盖。5.3 验证脚本可靠性的一个具体技巧用 crm_simulate 做预演crm_simulate可以在不实际执行的情况下模拟集群对某个操作的反应。比如你想知道某个节点故障后资源会迁到哪里可以crm_simulate -S -L -s -N hana-node1-N指定模拟节点故障-S显示模拟后的状态。这个工具在改约束前特别有用能提前发现约束冲突。我自己的习惯是每次改完约束先crm_simulate跑一遍确认资源迁移路径符合预期再实际执行。这个习惯帮我省了好几次半夜回滚的麻烦。希望帮到你。本文还有配套的精品资源点击获取