linux存储集群高可用需路径层（multipath）与集群层（pacemaker+corosync）协同：multipath保障单机多路径故障切换与i/o均衡，pacemaker实现跨节点服务接管与负载分发，再通过keepalived+haproxy/nginx提供前端vip与请求分发，三者缺一不可。

Linux 存储集群的自动故障切换与负载均衡，核心在于路径层和集群服务层的协同：底层靠多路径（Multipath）保障单主机到存储的冗余路径，上层靠集群软件（如 Pacemaker + Corosync）协调多节点间的资源接管与流量分发。两者分工明确——Multipath 管理的是“一条服务器到一个LUN的多条物理链路”，而 Pacemaker 管理的是“整个服务（如iSCSI target、GFS2文件系统或数据库）在多个节点间的可用性”。不依赖单一方案，组合使用才能真正落地。

多路径层：实现存储链路级故障切换与I/O均衡

这是存储高可用的第一道防线，确保单台服务器不会因某根光纤、某个HBA口或某台交换机故障而丢失LUN访问能力。

• 确认硬件与驱动就绪：HBA卡驱动已加载（lspci | grep -i fibre 和 lsmod | grep qla 或 lpfc），存储设备支持ALUA（Asymmetric Logical Unit Assignment），并已在存储侧启用。
• 安装并启用 multipathd：运行 yum install -y device-mapper-multipath（RHEL/CentOS）或 apt install multipath-tools（Debian/Ubuntu），然后执行 systemctl enable --now multipathd。
• 关键配置项需显式设置：编辑 /etc/multipath.conf，至少明确以下内容：
  • user_friendly_names yes（启用 mpatha、mpathb 等易读名）
  • path_grouping_policy multibus（允许多路径同时参与I/O，而非仅主备）
  • path_selector "service-time 0"（按响应时间动态选路，比 queue-length 更适合混合负载）
  • failback immediate（故障路径恢复后立即回归活跃组，避免长期失衡）
  • rr_min_io_rq 1（配合 service-time 使用，提升轮询粒度）
• 验证效果：运行 multipath -ll 查看路径状态（应显示 active / ready 多路径），用 iostat -x 1 观察各路径 %util 是否接近均衡；模拟拔掉一根光纤，确认 I/O 不中断且 multipath -ll 中对应路径状态变为 failed，恢复后自动 re-enable。

集群资源层：实现节点级服务自动接管与请求分发

当整台存储服务器或网络节点宕机时，仅靠 Multipath 无法解决——它不跨主机。此时需 Pacemaker 管理服务生命周期，并配合 LVS/Nginx/HAProxy 分流客户端请求。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 部署 Pacemaker + Corosync 基础集群：在所有参与节点安装 pacemaker corosync fence-agents-all，配置 Corosync 通信（推荐采用 qdevice 或仲裁盘防脑裂），启动 corosync 和 pacemaker 服务。
• 定义可迁移资源：例如，若共享存储挂载点为 /shared，对应 GFS2 文件系统，则需注册：
  • Filesystem 资源（指定设备、目录、fstype）
  • IPaddr2 资源（绑定 VIP，供客户端统一访问）
  • clvm 或 dlm 资源（若用 LVM 集群锁或 DLM 分布式锁管理器）
• 设置故障策略：通过 pcs resource defaults 设置 failure-timeout=60s，并通过 pcs constraint location 和 pcs constraint order 明确启动顺序（如先启 DLM，再启文件系统，最后启 VIP）。
• 集成 fencing（隔离机制）：必须配置 fence 设备（如 IPMI、AWS EC2 API、DRAC），确保故障节点被强制断电或网络隔离，防止脑裂写入损坏数据。

前端接入层：实现客户端请求的动态分发与无感切换

客户端不应直连某一台存储节点IP，而应通过虚拟入口访问。这个入口本身也需高可用，否则成为新单点。

• Keepalived 提供 VIP 高可用：在两台或以上存储网关节点部署 Keepalived，共用一个 VIP（如 192.168.10.100）。主节点持有 VIP 并响应 ARP；心跳失败后，备节点秒级抢占 VIP 并发送免费 ARP 刷新下游缓存。
• HAProxy/Nginx 实现七层/四层负载：
  • 对 NFS/GPFS 等协议，用 HAProxy 做 TCP 层转发（mode tcp），后端指向各存储节点的 NFS server IP。
  • 对 S3 或 REST 接口，用 Nginx 做 HTTP 反向代理（proxy_pass），启用 least_conn 或 ip_hash 算法，并配置 health_check 主动探测后端健康状态。
• 与 Pacemaker 协同控制：将 Keepalived 或 HAProxy 作为 Pacemaker 托管资源，使其启停受集群统一调度——例如 VIP 只在当前主节点上激活，HAProxy 进程也只在该节点运行，避免多点响应冲突。

验证与日常维护要点

配置完成不等于可靠，必须定期验证真实故障场景下的行为。

• 模拟链路中断：拔掉 HBA 光纤或禁用交换机端口，确认 multipath 自动切路径、I/O 无报错、dmesg 无 I/O timeout。
• 模拟节点宕机：强制 systemctl stop pacemaker 或直接断电，观察 VIP 是否 3–5 秒内漂移、Pacemaker 日志是否记录资源迁移、客户端 mount 是否保持可用（NFS soft mount 可设 timeo=10 缩短重试间隔）。
• 检查日志链路：重点关注 /var/log/messages（multipathd）、/var/log/cluster/corosync.log（Corosync 心跳）、/var/log/ha-log（Pacemaker 动作）三类日志，确认事件时间线连贯、无 fence 超时或资源 start failure。
• 避免常见陷阱：不要关闭 multipath 的 udev 规则（否则设备名会随路径变化）；不要在 Pacemaker 中遗漏 fence 配置；不要让 NFS 客户端使用 hard mount + infinite retry（导致 hang 死）。