SAP HANA 的高可用
SAP HANA数据库的高可用通过HANA System Replication(HSR)+ Pacemaker集群实现。SUSE提供了专用的资源代理SAPHanaController(或旧版SAPHana)和SAPHanaTopology来自动化管理。
1. HSR方案选型
方案 | 适用场景 | 切换时间 | 二次节点利用 | 推荐度 |
Performance Optimized | 生产环境,要求快速切换 | 短(表预加载) | 支持Read-Enabled只读 | 首选 |
Cost Optimized | 开发/测试,预算有限 | 较长(需先停非复制实例) | 运行非复制实例(QAS/DEV) | 预算敏感场景 |
1.1 Performance Optimized方案
二次节点配置表预加载(preload),数据常驻内存,切换时间通常很短。支持logreplay_readaccess操作模式,允许在二次节点上进行只读查询。

1.2 Cost Optimized方案
二次节点在正常运行时同时运行一个非复制的SAP HANA实例(如QAS),通过Pacemaker的反亲和约束(anti-colocation)管理。当主库需要切换时,先自动停止非复制实例,再执行takeover。

2. ECS选型
SAP HANA对硬件有严格的认证要求。在阿里云上,HANA节点必须使用经过SAP HANA Hardware Directory认证的ECS实例类型。
HANA认证实例,参考支持SAP HANA部署的ECS机型
选型原则:
主节点和备节点必须使用相同规格(两个站点都需要能运行Primary)
内存大小根据SAP HANA Sizing报告确定
Cost Optimized方案中,备节点内存需同时满足Secondary(减少内存模式)+ 非复制实例的需求
操作系统的选型请参考 阿里云上的SAP高可用架构。SAP HANA数据库节点必须选择SUSE Linux Enterprise Server for SAP。
3. 存储选型
SAP HANA对存储性能有严格要求,需要满足SAP HANA TDI(Tailored DataCenter Integration)存储标准。
挂载点 | 用途 | 存储类型 | 容量建议 | 性能要求 |
| 数据卷 | ESSD PL1及以上 | 1.5x RAM | 高IOPS、高吞吐 |
| 日志卷 | ESSD PL1及以上 | 0.5x RAM (最小512GB) | 极低延迟、高IOPS |
| 共享卷 | ESSD PL0 或 NAS | 1x RAM (最小256GB) | 中等 |
| SAP二进制 | ESSD PL0 | 50GB | 低 |
存储设计要点:
/hana/data和/hana/log使用本地ESSD云盘,不在节点间共享/hana/shared对集群至关重要,可使用ESSD云盘(各节点独立)或NAS共享使用
SAPHanaFilesystem资源代理监控/hana/shared的可用性文件系统统一使用XFS格式
4. 组网设计
HANA集群的组网设计与应用层类似,但有额外的网络需求:
VPC网络规划:
├── 业务网络vSwitch (ring0): 用于SAP应用访问和集群心跳
│ ├── HANA Primary
│ └── HANA Secondary
├── 复制网络vSwitch(可选,与业务共用): 用于HANA System Replication数据传输
└── 管理网络vSwitch(可选): 用于运维管理
IP地址规划示例:
用途 | IP地址 | 主机名 |
HANA Primary物理IP | 10.0.1.20 | hana01 |
HANA Secondary物理IP | 10.0.1.21 | hana02 |
HANA Primary VIP | 10.0.100.20 | vhanadb |
HANA Read-Enabled VIP(可选) | 10.0.100.21 | vhanadbro |
HANA System Replication网络要求:
同步模式(sync/syncmem)对网络延迟敏感,主备节点之间的网络延迟应尽可能低
HANA默认使用端口
3<instance_number>01至3<instance_number>99进行通信
5. 文件系统设计
HANA Primary (hana01) HANA Secondary (hana02)
├── /hana/shared/<SID>/ (ESSD) ├── /hana/shared/<SID>/ (ESSD)
├── /hana/data/<SID>/ (ESSD) ├── /hana/data/<SID>/ (ESSD)
├── /hana/log/<SID>/ (ESSD) ├── /hana/log/<SID>/ (ESSD)
└── /usr/sap/<SID>/ (ESSD) └── /usr/sap/<SID>/ (ESSD)
注意:HANA数据和日志卷在主备节点上各自独立,数据通过HANA System Replication在数据库层面复制,无需共享存储。
6. SAPHanaSR资源代理包的选择
SUSE为SAP HANA System Replication集群提供了两代资源代理包,分别适用于不同场景。在配置集群前,需要明确当前系统安装的是哪个版本,并根据需要选择。
6.1 两代资源代理包对比
维度 | SAPHanaSR(经典版) | SAPHanaSR-angi(新版) |
定位 | 经典版本,长期稳定 | 新一代(a next generation interface),是未来方向 |
提供的核心RA |
|
|
拓扑采集RA |
|
|
额外RA | 无 |
|
HA/DR Provider Hook |
|
|
Scale-up支持 | 支持 | 支持 |
Scale-out支持 | 有限 | 完整支持 |
Multi-tenant支持 | 有限 | 完整支持 |
SLES版本要求 | SLES 12 SP2+ / SLES 15+ | SLES 15 SP4+(推荐SP5+) |
共存性 | 不能与angi共存 | 不能与经典版共存 |
6.2 如何检查当前安装的版本
# 查看已安装的包
rpm -qa | grep SAPHanaSR
# 可能的输出:
# SAPHanaSR-0.155.0-... → 经典版
# SAPHanaSR-doc-0.155.0-...
# 或
# SAPHanaSR-angi-1.2.1-... → 新版
# SAPHanaSR-angi-doc-1.2.1-...
根据安装的包确认使用对应的RA名称:
# 经典版 - 确认SAPHana RA存在
ls /usr/lib/ocf/resource.d/suse/SAPHana
# 新版 - 确认SAPHanaController RA存在
ls /usr/lib/ocf/resource.d/suse/SAPHanaController
6.3 选型建议
新部署且SLES >= 15 SP4:推荐使用
SAPHanaSR-angi,它是SUSE未来的主线方向,功能更完善已有集群运行经典版:无需强制迁移,经典版仍然受支持;升级到angi需要重新配置集群资源
SLES 15 SP3及更低版本:只能使用经典版
SAPHanaSR两个包不能共存,切换时需要先卸载旧包再安装新包:
# 从经典版切换到angi(需在集群维护模式下操作)
zypper remove SAPHanaSR SAPHanaSR-doc
zypper install SAPHanaSR-angi SAPHanaSR-angi-doc
6.4 对集群配置的影响
两个版本的集群资源配置差异主要在RA名称和hook脚本:
配置项 | SAPHanaSR(经典版) | SAPHanaSR-angi(新版) |
主资源 |
|
|
Hook脚本路径 |
|
|
Hook provider名 |
|
|
额外hook | 无 |
|
sudo配置 |
|
|
本文档后续章节中的集群配置示例基于新版 SAPHanaSR-angi(ocf:suse:SAPHanaController)。如使用 SAPHanaSR,请将RA名称替换为 ocf:suse:SAPHana,并参考SUSE官方的SAPHanaSR配置文档调整hook脚本配置。
7. Pacemaker集群配置
7.1 HANA System Replication配置
在配置集群之前,需先完成HANA System Replication的设置:
# 在Primary节点 (hana01) 上启用SR
hdbnsutil -sr_enable --name=SiteA
# 在Secondary节点 (hana02) 上注册
hdbnsutil -sr_register --remoteHost=hana01 --remoteInstance=<inst_nr> \
--replicationMode=sync --operationMode=logreplay --name=SiteB
7.2 HA/DR Provider Hook脚本配置
SUSE提供了三个关键的HA/DR provider hook脚本,需在HANA的global.ini中配置:
susHanaSR.py — 监控SR连接状态变化(必需):
[ha_dr_provider_sushanasr]
provider = susHanaSR
path = /usr/share/SAPHanaSR-angi/
execution_order = 1
[trace]
ha_dr_sushanasr = info
susTkOver.py — 在takeover前进行检查,阻止非预期的手动takeover:
[ha_dr_provider_sustkover]
provider = susTkOver
path = /usr/share/SAPHanaSR-angi/
execution_order = 2
[trace]
ha_dr_sustkover = info
susChkSrv.py — 监控服务状态变化,加速indexserver故障时的切换:
[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-angi/
execution_order = 3
action_on_lost = stop
[trace]
ha_dr_suschksrv = info
配置sudo权限:
创建/etc/sudoers.d/SAPHanaSR:
<sid>adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_<sid>_*
<sid>adm ALL=(ALL) NOPASSWD: /usr/bin/SAPHanaSR-hookHelper --sid=<SID> *
7.3 STONITH/Fencing配置
参考SAP应用服务器高可用架构规划的fence_aliyun方案(阿里云上的SAP高可用架构)。
7.4 HANA集群资源配置(Performance Optimized)
以下为完整的HANA Pacemaker集群资源配置示例(SID=HA1,实例号=10):
# === 集群全局属性 ===
property cib-bootstrap-options: \
stonith-enabled="true" \
stonith-action="reboot" \
stonith-timeout="150" \
priority-fencing-delay="30"
rsc_defaults rsc-options: \
resource-stickiness="1000" \
migration-threshold="5000"
op_defaults op-options: \
timeout="600" \
record-pending=true
# === STONITH ===
# 阿里云fence_aliyun(与应用层类似)
primitive res_ALIYUN_STONITH_1 stonith:fence_aliyun \
op monitor interval=120 timeout=60 \
params filter="InstanceIds=[\"<ECS Id1>\", \"<ECS Id2>\"]" plug=<ECS Id1> ram_role=SAP-HA-ROLE region=<region ID> \
meta target-role=Started
primitive res_ALIYUN_STONITH_2 stonith:fence_aliyun \
op monitor interval=120 timeout=60 \
params filter="InstanceIds=[\"<ECS Id1>\", \"<ECS Id2>\"]" plug=<ECS Id2> ram_role=SAP-HA-ROLE region=<region ID> \
meta target-role=Started
location loc_node1_stonith_not_on_node1 res_ALIYUN_STONITH_1 -inf: <node1>
location loc_node2_stonith_not_on_node2 res_ALIYUN_STONITH_2 -inf: <node2>
# === SAPHanaTopology ===
primitive rsc_SAPHanaTop_HA1_HDB10 ocf:suse:SAPHanaTopology \
op start interval=0 timeout=600 \
op stop interval=0 timeout=300 \
op monitor interval=50 timeout=600 \
params SID=HA1 InstanceNumber=10
clone cln_SAPHanaTop_HA1_HDB10 rsc_SAPHanaTop_HA1_HDB10 \
meta clone-node-max=1 interleave=true
# === SAPHanaController ===
primitive rsc_SAPHanaCon_HA1_HDB10 ocf:suse:SAPHanaController \
op start interval=0 timeout=3600 \
op stop interval=0 timeout=3600 \
op promote interval=0 timeout=900 \
op demote interval=0 timeout=320 \
op monitor interval=60 role=Promoted timeout=700 \
op monitor interval=61 role=Unpromoted timeout=700 \
params SID=HA1 InstanceNumber=10 \
PREFER_SITE_TAKEOVER=true \
DUPLICATE_PRIMARY_TIMEOUT=7200 \
AUTOMATED_REGISTER=false \
meta priority=100
clone mst_SAPHanaCon_HA1_HDB10 rsc_SAPHanaCon_HA1_HDB10 \
meta clone-node-max=1 promotable=true interleave=true maintenance=true
# === 虚拟IP ===
# Primary VIP
primitive rsc_ip_HA1_HDB10 ocf:aliyun:vpc-move-ip \
params address=10.0.100.20 routing_table=<rt-id> \
endpoint=vpc-vpc.<region-id>.aliyuncs.com interface=eth0
# === 约束 ===
# VIP跟随Promoted的HANA
colocation col_saphana_ip_HA1_HDB10 2000: \
rsc_ip_HA1_HDB10:Started mst_SAPHanaCon_HA1_HDB10:Promoted
# Topology先于Controller启动
order ord_saphana_HA1_HDB10 Optional: \
cln_SAPHanaTop_HA1_HDB10 mst_SAPHanaCon_HA1_HDB10
7.5 关键参数说明
参数 | Performance Optimized | Cost Optimized | 说明 |
PREFER_SITE_TAKEOVER | true | false | 是否优先切换到备站(而非本地重启) |
AUTOMATED_REGISTER | false (初始) / true (生产) | false / true | 是否自动注册故障Primary为新Secondary |
DUPLICATE_PRIMARY_TIMEOUT | 7200 | 7200 | 双主检测时间窗口(秒) |
7.6 Active/Active Read-Enabled(可选)
如果启用了logreplay_readaccess操作模式,可以为Secondary添加只读VIP:
primitive rsc_ip_HA1_HDB10_readenabled ocf:aliyun:vpc-move-ip \
params address=10.0.100.20 routing_table=<rt-id> \
endpoint=vpc-vpc.<region-id>.aliyuncs.com interface=eth0
colocation col_saphana_ip_HA1_HDB10_readenabled 2000: \
rsc_ip_HA1_HDB10_readenabled:Started mst_SAPHanaCon_HA1_HDB10:Unpromoted