nfs-ganesha 本身不提供高可用，因其为用户态单实例服务，无内置集群或主备切换逻辑；高可用需依赖 pacemaker+corosync 编排 vip 漂移、配置同步、后端健康检查及导出 id 全局唯一等外部机制协同实现。
为什么 NFS-Ganesha 本身不提供高可用，得靠外部机制
NFS-Ganesha 是个用户态 NFS 服务器，它自己没有内置集群或主备切换逻辑。所谓“高可用”，实际是指 nfs-ganesha 进程挂了能自动拉起、VIP 能漂移、配置能同步、后端存储访问不中断——这些都得靠外部组件协作实现。直接跑单实例再加个 systemd restart，扛不住脑裂或状态不同步问题。
常见错误现象：showmount -e 突然返回空、客户端报 Stale file handle、failover 后导出路径消失。根本原因往往是 VIP 漂移了但 ganesha.conf 里没配 Export_Id 全局唯一，或后端（如 CephFS、Lustre）连接未做重试兜底。
- 必须用 Pacemaker + Corosync 做资源编排，不能只依赖 keepalived + script
-
ganesha.conf中每个EXPORT块必须显式指定Export_Id = N（N 为整数），否则 Pacemaker 切换节点后，客户端缓存的文件句柄会失效 - 后端存储建议走 DNS 名（如
cephfs.example.com）而非直连 IP，避免 failover 时要改配置
如何用 Pacemaker 配置 NFS-Ganesha 资源组
Pacemaker 把 nfs-ganesha 当成普通服务管理，但它依赖 VIP、配置同步、后端健康检查三类资源。漏掉任一环，failover 就会卡在 “Started” 状态或静默失败。
关键点：Pacemaker 不会自动同步 /etc/ganesha/ganesha.conf，你得自己加 fsync 或 rsync 资源，或者用分布式配置中心（如 etcd + confd），但生产环境更推荐前者——简单可控。
- 定义 VIP 资源：
pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.10.100 cidr_netmask=24 op monitor interval=10s - 定义 Ganesha 服务资源：
pcs resource create ganesha systemd:nfs-ganesha op monitor interval=15s timeout=30s - 强制绑定顺序：
pcs constraint colocation add ganesha with vip INFINITY和pcs constraint order vip then ganesha - 加一个配置同步资源（示例用 rsync）：
pcs resource create sync-conf ocf:pacemaker:FileSync directory=/etc/ganesha/ source_host=node1 dest_host=node2 op monitor interval=60s
客户端 mount 时必须加哪些参数才稳
默认 mount -t nfs 行为在 HA 场景下极易出问题：超时短、不重试、硬挂载却没设 retrans，导致 VIP 切换瞬间大量进程 hang 住。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
错误写法：mount -t nfs 192.168.10.100:/export /mnt —— 没指定协议版本、没设超时、没开 soft/hard 语义控制。
- 强制 v4.2：
mount -t nfs -o vers=4.2,minorversion=2,nfsvers=4.2（Ganesha 3.5+ 对 v4.2 的 layoutrecall 和 delegation 支持更稳） - 软挂载 + 可控重试：
soft,timeo=600,retrans=3（timeo单位是 1/10 秒，600 = 60 秒） - 禁用属性缓存（防 stale）：
noac或至少acregmin=1,acregmax=1,acdirmin=1,acdirmax=1 - 务必加
proto=tcp，UDP 在跨网段或丢包时不可靠
怎么验证 failover 真的不中断业务
别信 pcs status 显示 “Started” 就完事。真实业务中断往往发生在元数据操作（ls -l、stat）、小文件创建、或 close() 返回阶段。得模拟客户端侧真实行为。
典型漏测点：只测大文件读写，没测 open(O_CREAT) 或 rename()；只看服务端日志，没抓客户端 strace；failover 时没清内核 NFS 缓存（echo 2 > /proc/sys/vm/drop_caches 只清 pagecache，不碰 NFS inode cache）。
- 用
strace -e trace=open,close,stat,read,write,mkdir,rename -p $(pidof your-app)监控关键进程系统调用是否卡住 - 在客户端执行：
while true; do date; ls -l /mnt/testfile 2>/dev/null | head -1; sleep 0.5; done，手动触发 Pacemaker failover，观察输出是否连续 - failover 后立刻查服务端：
ganesha-admin -v --export-list，确认导出仍在且State = EXPORTED，不是UNAVAILABLE - 检查
/var/log/ganesha.log是否有CEPH: connection failed或FSAL: backend not ready类错误，这类错不会让进程退出，但会让 export 不可用
最易被忽略的是后端存储的连接复用：Ganesha 默认复用后端连接，failover 后旧连接可能还卡在 CLOSE_WAIT，得在 ganesha.conf 的 FSAL 块里加 reconnect_delay = 5 和 timeout = 30 才真正可靠。
