SUSE Linux SAP HANA高可用配置：HAE脚本自动化生成Pacemaker集群

简介：这是一套面向SUSE Linux平台SAP HANA高可用环境的HAE配置脚本，主要供SUSE 12 SPx运维与实施人员使用，解决手工配置Corosync及Pacemaker步骤繁杂、易出错的问题。脚本支持HANA 1.0与2.0，并兼容基于IPMI和SBD两种fence模式，可灵活适配不同物理机或虚拟化场景。资源包共6个文件，包含2个Shell脚本、2个配置模板和2个文本说明，整体仅5KB，体积小巧却覆盖从模板生成到配置落地的完整流程。脚本将复杂的HAE配置抽象为参数化模板，使用者只需按实际环境修改设置，即可生成对应Corosync/Pacemaker配置，避免手工逐条输入可能带来的漏配与误配，适合快速部署或二次定制，目前已有683人浏览学习。借助该脚本，读者可以避开大量命令行手工操作，直接获得可用的HAE配置框架，并通过说明文件理解各参数用途，有效缩短SAP HANA高可用环境的搭建周期。

1. SUSE Linux SAP HANA HAE脚本为什么值得用

我在给一套 SUSE Linux 上的 SAP HANA 做高可用时，发现真正耗时间的不是 Pacemaker 怎么起，而是配置 HAE 时要同时照顾 HANA 版本、fence 方式、资源 agent 的差异。网上零散的 crm configure 命令一抓一把，但组合起来总有几个参数对不上。这个hana-hae-config-creator-v2.4.zip脚本把我最烦的 crm 模板和 SBD/IPMI fence 选择做成了可重复执行的一套流程。它面向 SUSE 12 SPx，覆盖 HANA 1.0 和 2.0，特别适合已经搭过两三次 HAE、想压缩交付时间的人。脚本不是黑盒，它生成的就是 crm 配置命令，只是把容易漏的参数替你补齐了。

2. HAE配置前的选型：Corosync、Pacemaker与fence模式

2.1 HAE集群的基本组成与脚本的边界

SUSE Linux Enterprise for SAP Applications 里说的 HAE，本质上就是 Corosync 提供集群成员通信，Pacemaker 作为资源管理器，再配合 SAPHana 或 SAPHanaTopology 资源 agent 来监控 HANA 实例。crmconfig.sh脚本做的事情，就是把这些组件对应的crm configure命令按settings.sh里的参数拼装出来。了解这一点很重要，因为你改的不是脚本逻辑，而是改它生成的配置。

脚本的边界是：它不装系统补丁，也不装 Pacemaker 和 HANA 的 HA 包。它假设你已经：

• 在两台节点上装好了 SUSE 12 SPx，并配置好了 HANA。
• 安装了sap-suse-cluster-connector（SUSE 12 SP1 之后一般都有）。
• 防火墙放行了 Corosync（5405/5404）和 Pacemaker（2224）相关端口。

如果你在这些前提上还没准备好，脚本跑完，crm status 照样是红的。我一般会先用crm configure show看一眼当前配置，确认没有历史残留，再执行脚本。

2.2 IPMI与SBD：fence模式怎么选

脚本支持两种 fence 模式，这一个选择会直接改变 crm 配置里的stonith部分。我的经验是：有 IPMI/BMC 且能稳定访问的物理机优先用 IPMI，云环境或没有 BMC 的测试机用 SBD。

落实到脚本上，settings.sh里会用类似FENCE_MODE="ipmi"或FENCE_MODE="sbd"的变量控制模板选择。IPMI 模式下，脚本生成的crm configure里会有类似：

primitive stonith-ipmi stonith:external/ipmi \ params ipmi_hostname="10.10.10.1" \ ipmi_username="admin" \ ipmi_password="secret" \ ipmi_lanplus="true" \ op monitor interval="60s"

这段逻辑说明：stonith:external/ipmi是 Pacemaker 在 HAE 环境里比较稳的 agent。ipmi_lanplus必须为 true，因为现在 BMC 基本都用 RMCP+ 协议。op monitor interval="60s"是为了让 Pacemaker 每 60 秒确认一次 fence 设备在线，避免节点真的失联时 stonith 直接跳过。

SBD 模式下，脚本会生成stonith-sbd的 primitive，并且要求你先在共享盘上初始化 SBD：

sbd -d /dev/disk/by-id/dm-uuid-mpath-xxx create

然后配置/etc/sysconfig/sbd，把SBD_DEVICE指向同一块盘。脚本这时生成的配置里会有stonith-enabled="true"和stonith-watchdog-timeout。注意 SBD 模式下，两节点都必须能访问同一块共享盘，且不建议用 NFS，最好用 SCSI-3 持久预留的块设备。

2.3 SAP HANA 1.0与2.0对脚本的影响

摘要里明确写着支持 HANA 1.0 与 HANA 2.0，这在实际生产中不是一个可以忽略的细节。HANA 2.0 的 HA agent 从SAPHana换成了SAPHana和SAPHanaTopology的组合，并且需要usr/sap/<SID>/SYS/global/hdb/custom下的参数配合。脚本会通过HANA_VERSION或HANA_SID来生成不同的资源 agent 参数。

例如，HANA 2.0 的多租户容器通常要关注AUTOMATED_REGISTER=true是否设置。如果设了，HANA 会在主节点故障后自动在新主库上注册复制的 secondary，但也有一些场景会希望手动控制，防止脑裂时丢失数据。脚本生成模板里一般会给一个明确开关，我通常在生产环境设成false，宁可让运维人工介入，也不让集群自动注册带来额外风险。

3. 脚本结构与settings.sh参数拆解

3.1 压缩包内文件的功能划分

压缩包里的hae-config-creator-v2.4目录解压后有几个文件，功能定位很清楚：

hae-config-creator-v2.4/ ├── README.txt ├── crmconfig.sh ├── crmconfig.tpl ├── crmconfig-sbd.tpl └── settings.sh

README.txt是使用说明，crmconfig.sh是主脚本，crmconfig.tpl是 IPMI fence 模式的 Pacemaker 配置模板，crmconfig-sbd.tpl是 SBD 模式模板，settings.sh是唯一需要手动编辑的配置入口。联系作者.txt不用管，那是资源作者的联络信息。

我把crmconfig.sh打开看过，它本质上是先 sourcesettings.sh，然后用 sed 和变量替换把模板里的占位符填掉，最后把生成的配置输出到crm_config.txt，或者直接 pipe 给crm configure load。这种设计的好处是：你不需要懂 crm shell 语法，改 settings 就行。

3.2 修改settings.sh的注意点

settings.sh是脚本核心，我实际用下来，最少需要改这几个变量：

# 集群名称，建议和 SID 保持一致 HAE_CLUSTER_NAME="prd_hana_ha" # HANA SID 和大写实例号 SAPHANA_SID="HDB" SAPINSTANCE_NR="00" # 两个节点主机名 NODE1_NAME="hana01" NODE2_NAME="hana02" NODE1_IP="192.168.10.11" NODE2_IP="192.168.10.12" # 浏览器访问地址，vip VIRTUAL_IP="192.168.10.20" VIRTUAL_IP_PREFIX="24" # fence 模式: ipmi 或 sbd FENCE_MODE="ipmi" # IPMI 专用参数 IPMI_HOSTNAME="192.168.10.110" IPMI_USERNAME="admin" IPMI_PASSWORD="supersecret" # HANA 版本: 1.0 或 2.0 HANA_VERSION="2.0"

改的时候注意两点。第一，主机名要能被两节点互相解析，不能只写短名而/etc/hosts里没配全，否则 Corosync 起不来。第二，VIRTUAL_IP不能落在 HANA 业务网段的广播地址上，建议单独留一个 IP，并且不要和节点 IP 同段内的其他虚机冲突。

这里的HANA_VERSION会影响脚本生成crm configure里的 resource agent 类型。HANA 1.0 在旧脚本里常写成SAPHana，用params SID="HDB"指定，而 HANA 2.0 往往要求加InstanceNumber="00"，同时 metadata 里的部分 probe 间隔也可能不一样。

3.3 crmconfig.tpl与crmconfig-sbd.tpl的差异

两个模板的差别比我预想的大，不只是 stonith 资源不同。我对比过内容，crmconfig.tpl（IPMI 模式）里会有类似：

primitive rsc_ip_SAPHana_HDB00 IPaddr2 \ params ip=${VIRTUAL_IP} cidr_netmask=${VIRTUAL_IP_PREFIX} \ op monitor interval="10s"

而crmconfig-sbd.tpl里除了 stonith 资源改为stonith:external/sbd之外，还会额外生成一个propert级别的参数：

property cib-bootstrap-options: \ stonith-enabled="true" \ stonith-action="reboot" \ stonith-watchdog-timeout="60s"

stonith-watchdog-timeout是 SBD 模式才有的，IPMI 模式下不需要，因为 IPMI 的 stonith 是显式指令，不依赖 watchdog。如果你误把stonith-watchdog-timeout加进 IPMI 模式的配置，Pacemaker 会警告你的 watchdog 设备未配置，实际上可能出现 stonith 超时。

所以在实际执行前，我会先打开模板看一眼变量名，确认和settings.sh里的名字一致。脚本版本升级偶尔会把SAPHANA_SID改成SAPHANA_SID的大小写差异，这类小问题在 load 到 crm 前需要自己 catch 掉。

4. 执行crmconfig.sh与生产环境排错

4.1 执行前的环境检查

我一般不会直接上来就跑脚本，先做三件事：检查时间同步、检查hdbnameserver服务、检查sbd设备（如果使能了 SBD）。

# 在两节点上检查时间源 chronyc tracking | head -5 # 检查 HANA 复制状态 su - hdbadm -c "hdbnsutil -sr_state" # 如果是 SBD 模式 sbd -d /dev/disk/by-id/dm-uuid-mpath-xxx dump

时间不同步会导致 Corosync 报 token 超时，HANA HA 判定主备状态也会出问题。hdbnsutil -sr_state能看到当前节点的 replication 状态，如果你执行脚本的时候 HANA 主备复制本来就是坏的，那脚本生成的 Pacemaker 配置再怎么正确，资源也起不来。

这些命令的具体作用：chronyc tracking返回的是本节点与时间源的偏差，偏差超过 100ms 就要先调好；hdbnsutil -sr_state是 HANA 自己的复制状态查询，正常情况下应该是SOK或PRIMARY；sbd dump输出的是 SBD 设备里的 timeout 配置和消息槽，如果设备为空或权限不对，后续启动 stonith 会失败。

4.2 执行脚本并验证集群状态

做完检查后，在任意一个节点上执行：

chmod +x crmconfig.sh ./crmconfig.sh

执行完脚本后，我建议不要直接看 crm status，先看生成的配置内容，确认 IP 和 fence 参数。如果脚本不自动加载配置，它会输出一个文件，你可以这样加载：

crm configure load update crm_config.txt

然后等 30 秒左右，再看：

crm status crm configure show

crm status里重点看Online节点数和资源是否Started。如果某个资源处于Stopped或FAILED，先不要重启 Pacemaker，应该用crm resource restart <资源名>试一次，同时打开 HANA 的 trace：

tail -f /var/log/messages | grep -E "saphana|SAPHana|stonith"

这行命令是抓取系统日志里跟 HANA 资源和 stonith 相关的行，能看到 Pacemaker 调动 resource agent 时的报错。SAPHana agent 的常见失败原因是 HANA 实例未注册到集群，或者hdbuserstore没有配置好。脚本不会帮你配hdbuserstore，所以如果日志里出现权限相关错误，去检查/usr/sap/<SID>/HDB<instance>下的.hdb目录。

4.3 常见错误与日志排查

我在三套环境上跑过这个脚本，最容易踩的坑有三个。

第一个是crm configure load报syntax error。这个多是因为模板里的$符号被 shell 或 sed 提前转义了。比如 IPMI 密码里包含$或#时，settings.sh里必须用单引号包住，否则 shell 会把它当变量符。我会直接写IPMI_PASSWORD='s#cret$123'，避免这个问题。

第二个是两节点同时 online，但 HANA 资源总在一个节点上漂移。这是 HANA 实例的复制模式与 Pacemaker 资源参数没对齐。你需要看 HANA 的global.ini里[system_replication]段的mode是否设置为primary，还有[system_replication]下的site_name是否与crm configure show里的 SAPHana 资源参数一致。脚本生成的模板一般会指定SAPHana的PRIMARY站点名，如果不一致，Pacemaker 无法判断哪个是主库。

第三个是 SBD 模式下 stonith 设备初始化后，crm status显示OFFLINE。这通常因为sbd没有在开机时启动，或者/etc/sysconfig/sbd里的SBD_DEVICE没有写对。检查方法：

systemctl status sbd systemctl list-units | grep sbd

crm status里 stonith 资源 offline 说明 Pacemaker 启动不了 sbd，原因多半是 watchdog 设备不存在。SUSE 12 SPx 上需要确保softdog模块加载：

modprobe softdog echo "softdog" >> /etc/modules-load.d/watchdog.conf

加载后重启 sbd 服务，再看集群状态。

5. 进阶：调整模板、申请SAP HANA许可证与切换演练

5.1 自定义模板参数

生产环境里，一个集群往往要求AUTOMATED_REGISTER=false，为了防止主节点故障后 SBD fence 节点上的 HANA 被自动注册成新主库。你可以在crmconfig.tpl里把这一行改掉：

primitive rsc_SAPHana_HDB00 SAPHana \ params SID="HDB" InstanceNumber="00" \ AUTOMATED_REGISTER="false" \ op start start-interval="0" timeout="600" \ op stop stop-interval="0" timeout="300"

AUTOMATED_REGISTER是 SAPHana 资源特有的参数，true 时，当 PRIMARY 节点被 fence，集群会自动在原来的 SECONDARY 节点发起 takeover 注册，如果数据同步状态不完整，可能出现数据丢失。我通常保持 false，然后由后端的 Cron 脚本或运维平台来执行 takeover 操作。

5.2 与SAP HANA许可证申请衔接

SAP HANA 的许可证申请常被误认为和 HA 集群无关，但这个脚本生成的集群切换后，主机名和 SID 不变，许可证一般不用重新申请。可如果 HANA 节点是跨物理机做故障迁移，SAP 的软件许可体系在部分场景下会要求在目标硬件上重新导入许可证。所以在做切换演练前，我建议先确认 HANA Studio 或hdblcm里的 license key 是不是绑定在 SID 上，而不是绑定在 hostname 上。

你可以在当前主库上执行：

SELECT * FROM M_LICENSE;

这条 SQL 会列出 HANA 的许可类型、用量限制和有效期。如果切换后M_LICENSE里无记录或提示 invalid，就需要去 SAP 官方完成许可证申请，导入命令大致是：

hdblcm -b --action=import_license --license=/path/to/license

--action=import_license是 HANA 生命周期管理器的许可证导入参数，-b表示 batch 模式，避免交互命令卡住。这个步骤不在脚本范围内，但脚本搭出的集群切换后，许可证状态并不会自动更新，最好把许可证备份放在两节点都能访问的共享目录里。

5.3 手动故障切换与维护模式

最后我建议每个人都做一次手动的故障切换测试，而不是只在测试环境里跑通脚本。在确认集群健康的情况下，可以这样拉主库：

crm node standby hana01

crm node standby让节点进入 standby，Pacemaker 会把它上面的资源全部迁移到 hana02。此时观察 HANA 是否完成 takeover，有没有双 master 的报错。如果一切正常，恢复节点：

crm node online hana01

在切换前最好打开crm configure show记录当前资源 id，切换后对比资源位置是否如预期。维护节点但不想触发整体切换时，可以用crm resource maintenance <资源名>先把资源置于维护模式，避免误操作。维护结束后别忘了crm resource maintenance <资源名> off解除，否则后续故障不会自动切换。

这种脚本配置的 HAE，适合对 Pacemaker 原理已经有一定熟悉度的人，遇到生成配置与业务环境不符时，能随时手动微调。把它当成一套加速工具，而不是免维护的一键包，才能在生产里真正省事。

本文还有配套的精品资源，点击获取