HA双机架构的核心概念与设计思路拆解1. 主流HA模式共享存储 vs. 存储复制HANA HA主要有两种实现模式选择哪一种取决于你的基础设施策略和成本考量。共享存储架构Shared Storage 这是较为传统和经典的方案。两台HANA服务器通常称为节点通过光纤通道FC或iSCSI连接到一个共享的SAN存储阵列。HANA的数据卷如 /hana/data , /hana/log 都存放在这个共享存储上。正常情况下只有一个节点主节点挂载这些卷并运行HANA数据库服务。备用节点虽然能访问存储但不会挂载数据卷。当主节点故障时集群软件如SUSE HAE 或RHEL HA会触发故障转移流程首先在存储层面确保数据一致性例如使用SCSI-3 Persistent Reservation防止脑裂然后将数据卷挂载到备用节点最后启动HANA服务。注意 共享存储架构本身不解决存储单点故障。存储阵列的可靠性需要通过其自身的RAID、多控制器、快照等技术来保障。此外网络路径也需要冗余多路径IO避免因一条光纤线或HBA卡故障导致存储失联。存储复制架构Storage Replication 这种模式在近些年尤其是云和分布式存储场景下越来越流行。两个节点拥有各自独立的本地存储或存储设备。通过存储层级的同步复制技术如NetApp SnapMirror同步模式、IBM Spectrum Virtualize Metro Mirror将主节点存储上的数据块实时复制到备用节点的存储上。在这种架构下备用节点的存储是主节点存储的一个实时镜像。故障转移时备用节点直接使用其本地已同步的存储副本来启动HANA省去了挂载远程存储的步骤理论上速度可能更快。两种模式的抉择点 • 成本与复杂性 共享存储通常需要昂贵的SAN设备和专门的存储网络总体拥有成本高但架构清晰被广泛验证。存储复制可能利用现有存储设备的功能但在跨站点如同城双活部署时对网络延迟和带宽要求极为苛刻。• 故障域隔离 共享存储架构中存储是一个关键的共享故障点。存储复制架构将故障域更好地隔离在了两个节点但复制链路本身成为了新的潜在故障点。• 运维操作 共享存储下做存储快照、备份相对集中。存储复制下可能需要协调两端的存储操作。2 .关键组件解析-共享存储架构Shared Storage2.1 硬件与基础架构层这一层是HA的物理承载任何不稳定都会直接传导至上层的数据库服务。2.1.1. 服务器节点至少需要两台独立的服务器Node A和Node B。它们应具有相同或兼容的CPU架构、相近的内存和CPU配置。这里有一个关键点虽然内存大小最好一致但如果备节点内存略小于主节点在切换后HANA会进行内存的重新调整但这可能影响切换后的瞬时性能。最佳实践是配置完全相同。2.1.2. 共享存储这是HA架构的“数据心脏”。HANA的数据卷 /hana/data 和日志卷 /hana/log 必须位于共享存储上例如SAN存储区域网络、高性能NAS或分布式存储如vSAN。这样两个节点才能访问同一份数据。 绝对要避免 使用本地磁盘作为数据/日志卷否则无法实现故障切换。共享存储本身也需要是高可用的否则它就成了新的单点故障。2.1.3. 网络网络配置复杂且关键。关键网段如下业务网用于应用程序如SAP应用服务器连接HANA数据库。通常需要浮动虚拟IPVirtual IP在发生故障切换时这个IP会从故障节点“漂移”到健康节点实现应用连接的无感重定向需要应用层配置连接重试。心跳网 用于两个节点间持续相互监控判断对方是否存活。 强烈建议 使用独立的、物理隔离的网络如专用的万兆网卡直连与业务网络分离。如果心跳网络丢包或延迟可能导致“脑裂”——两个节点都认为对方挂了都试图接管资源造成数据损坏。IMM网IMM 网 服务器的带外管理网BMC/IPMI 网走的是独立于 OS 的 BMC 网口,在 HANA 高可用集群里它唯一且不可替代的作用就是承载 STONITH/fencing 指令把疑似故障的节点真正踢下线。SR网络 可选但重要用于HANA系统复制System Replication时将数据变更从主节点同步到备节点。对带宽和延迟要求极高建议使用高速网络如Infiniband或高速以太网并独立部署。2.2 集群软件层故障检测与资源调度的“大脑”这是HA的“智能中枢”负责监控、决策和行动。在SUSE Linux Enterprise Server上通常使用 Pacemaker Corosync 集群栈在Red Hat Enterprise Linux上则是 Pacemaker Corosync RHEL HA Add-On。它们的作用是• Corosync 提供集群成员关系和消息传递服务确保所有节点对集群状态有一致的认知。它是神经系统负责在集群节点间传递心跳Heartbeat和集群事务消息。通过心跳节点能相互确认对方是否存活。通常需要配置至少两个冗余的心跳网络例如一个通过业务网卡一个通过专用的交叉线直连或管理网卡以防止网络分区导致误判。它是运行在用户态的守护进程开启命令如下systemctl start corosync.service• Pacemaker 集群资源管理器。它不关心具体应用是什么只管理“资源”Resource。在HANA场景下一个HANA数据库实例例如 PRD 被Pacemaker定义为一组相互关联的资源集合包括◦ 文件系统资源 挂载共享存储上的 /hana/data 和 /hana/log 。◦ 资源代理Resource Agent, RA它是Pacemaker与HANA数据库交互的“手”和“眼”。SAP提供了专门的 SAPHana 和 SAPHanaTopology 资源代理。 SAPHanaTopology RA运行在每个节点上负责收集本节点HANA实例的状态信息如是否安装、运行模式等。 SAPHana RA是主资源负责控制HANA实例的启动、停止、状态监控和故障转移。它通过HANA的 hdbsql 命令或本地接口与数据库通信。◦ 虚拟IP资源 管理业务网络的浮动IP地址。Pacemaker通过定义资源之间的“约束”Constraints例如“虚拟IP必须在HANA主资源所在的节点上运行”来保证所有资源协同工作。◦ STONITH (Shoot The Other Node In The Head) 这是防止“脑裂”Split-Brain的终极武器。当集群无法确定哪个节点应该存活时例如心跳网络完全中断但两个节点自身都运行良好脑裂会导致两个节点都试图接管资源从而造成数据损坏。STONITH机制会强制关闭或重启被认定为“失败”的节点通常通过IPMI、iLO、iDRAC等带外管理接口发送关机指令。 没有正确配置和测试过的STONITH你的HA集群就是在裸奔。Pacemaker 是运行在用户态的守护进程开启命令如下systemctl start pacemaker.service 可通过以下命令监控集群状态# 查看集群整体状态 crm status # 或更详细的视图 crm_mon -1 # 查看所有资源状态 crm resource status┌─────────────────────────────────────────┐│ 资源代理层 Resource Agents │ ← 具体干活的手执行层│ ocf:suse:SAPHana、IPaddr2、fence_ipmilan │ 启动/停止/监控/提升├─────────────────────────────────────────┤│ Pacemaker ── 决策大脑 │ ← 决策层│ 判断谁该当主、要不要切换、先 fence 还是先切 │├─────────────────────────────────────────┤│ Corosync ── 心跳/成员/仲裁 │ ← 底层通信管道│ 谁在线、谁掉了、有没有 quorum │└─────────────────────────────────────────┘2.3 SAP HANA数据库层数据同步与状态管理这是HA的“血肉”承载着实际的数据和服务。• HANA系统复制 这是HANA原生提供的数据同步机制是大多数HA方案的数据基础。主节点Primary将重做日志Redo Log实时或异步地传输到备节点Secondary。备节点持续应用这些日志使其数据状态与主节点保持高度一致。根据数据同步模式可分为◦ 同步模式 主节点的事务提交必须等待备节点确认日志落盘后才返回成功。这保证了数据的零丢失RPO0但会略微增加事务延迟。◦ 异步模式 主节点提交事务无需等待备节点确认性能更好但存在极小的数据丢失窗口期RPO0。• HANA实例状态 一个HANA实例在HA环境中会有明确的状态标识如 PRIMARY , SECONDARY , SYNCHRONIZED , ACTIVE , STANDBY 等。 SAPHanaController 资源正是根据这些状态来决定是否触发故障转移。这三层架构环环相扣。硬件层提供稳定平台集群层负责故障感知和资源调度数据库层确保数据一致性。任何运维操作都必须清楚自己正在影响哪一层以及可能对其它层产生什么连锁反应。3.操作系统层面维护集群资源组件原理说明3.1 依赖的systyemd服务清单服务层进程本体说明sbd.serviceL2 隔离sbd用户态靠内核 watchdog 完成自杀corosync.serviceL1 消息corosync主进程fork 出 totem/votequorum 等线程corosync-qdevice.serviceL1 仲裁corosync-qdevice第三仲裁方可选pacemaker.serviceL3 决策pacemakerd主守护再fork 出 cib/crmd/pengine/lrmd/attrd/stonithdhawk.service旁路Hawk2Web 管理界面TCP 7630pacemaker_remote.service扩展pacemaker-remoted远程节点用双节点不涉及3.2 单节点服务启动顺序systemctl start sbd # 无 SBD 则跳过 systemctl start corosync systemctl start pacemaker # 它会因 Requirescorosync 自动带起 corosync停止顺序必须反过来pacemaker → corosync → sbd。3.3依赖的内核设施1. watchdog最关键也是你环境的缺口内核模块类型说明softdog软件看门狗纯内核模拟硬死机时救不了仅测试用hpwdt/iTCO_wdt硬件看门狗HP / Intel 平台生产推荐ipmi_watchdogBMC 看门狗借 IMM/BMC 实现SR950 可用ls -l /dev/watchdog # 你的 have-watchdogfalse → 大概率不存在 lsmod | grep -E softdog|hpwdt|iTCO|ipmi|wdt # 若无临时加载生产请用硬件 watchdog modprobe softdog echo softdog /etc/modules-load.d/watchdog.conf # 持久化SBD 的工作原理正是用户态sbd进程持续往/dev/watchdog写喂狗一旦进程卡死或节点被判定要自杀停止喂狗 →内核 watchdog 超时 → 硬件强制重启。所以 SBD 是用户态进程 内核机制的组合体。2. 网络协议栈与端口通道协议/端口内核层Corosync totemUDP5405组播/ 5404内核网络栈依赖组播或 udpu 单播qdeviceTCP 5403同上IPMI lanplusUDP623RMCP走 IMM 网无内核驱动依赖Hawk2TCP 7630—ss -lnup | grep -E 5404|5405|623 # 确认端口监听3. IPMI 内核驱动仅本地模式需要模块用途ipmi_msghandler/ipmi_si/ipmi_devintf让本机 OS 访问自己的 BMC/dev/ipmi0⚠️ 你的 fence 走interfacelanplus即网络模式02 的 ipmitool 通过 UDP 623 打 01 的 BMC不需要在 01 上加载 ipmi 驱动。这也是带外的优势——跟被隔离节点的 OS 完全无关。4. 建议调整的 sysctl配合 watchdog# /etc/sysctl.d/99-ha.conf kernel.panic 0 # 交给 watchdog 重启而非内核自己停住 kernel.panic_on_oops 1 # kernel oops 立即 panic → watchdog 接管 kernel.hung_task_panic 1 # 可选任务长时间 D 状态触发 panic sysctl -p /etc/sysctl.d/99-ha.conf这套参数的目的是任何内核级卡死都要变成重启而不是挂着等 fence。没有 watchdog 时它们意义有限。