NFS高可用核心是VIP自动切换与主备数据实时同步，采用NFS+Keepalived+sersync（或rsync+inotify）组合方案，通过Keepalived提供虚拟IP并检测NFS进程健康状态实现秒级故障转移，sersync基于inotify触发rsync确保数据低延迟一致，客户端挂载VIP即可透明访问，无需感知后端节点变化。
要让 NFS 服务具备高可用性、避免单点故障，核心是解决两个问题：一是服务地址能自动切换，二是数据在主备节点间实时一致。最常用且落地性强的方案是 NFS + Keepalived + 实时同步工具（如 rsync+inotify 或 sersync） 的组合，不需要额外硬件或复杂集群文件系统。
用 Keepalived 提供虚拟 IP 和自动故障切换
Keepalived 基于 VRRP 协议，让主备 NFS 节点共用一个虚拟 IP（VIP）。客户端只认这个 VIP，不关心背后哪台机器在提供服务。
- 主节点正常时，VIP 绑定在它身上，所有 NFS 请求都由它响应
- 主节点宕机或 NFS 进程异常，Keepalived 检测失败后，几秒内将 VIP 自动漂移到备节点
- 需配置健康检查脚本（例如检测
rpcinfo -p localhost | grep nfs是否返回），不能只依赖网络连通性 - 注意避免脑裂：两台节点之间必须有稳定的心跳链路（建议走独立网卡或私有网络），并配置
priority和weight合理降级
确保主备节点数据实时同步
仅切换 IP 不够，如果备节点数据落后，切过去就会丢数据或读到旧文件。必须在写入主节点的同时，把变更推送到备节点。
- 推荐用 sersync：基于 inotify 监控目录事件，触发 rsync 推送，延迟低、资源占用小、支持过滤和多目标
- 也可用 rsync + inotify-tools 自建脚本，但需处理并发写、删除冲突、进程守护等问题
- 不要用定时 rsync：分钟级延迟无法满足业务连续性要求
- 同步路径要与 NFS 导出路径严格一致，比如主节点导出
/data/k8s_storage，备节点也必须同步到相同路径
容器云环境特别注意事项
Kubernetes 对 NFS 故障更敏感，挂载卡住会导致 Pod 长时间处于 ContainerCreating 或 Terminating 状态，恢复还需人工干预。
- PV 中的
nfs.server字段必须填 VIP，不是物理 IP；否则切换后 PVC 仍连老地址 - 所有 Kubernetes Node 节点都要安装
nfs-utils，并确认能通过 VIP 挂载测试成功 - 建议关闭 SELinux 和防火墙，或精确放行 NFS 相关端口（111、2049、以及 rpcbind 动态端口）
- 生产环境共享目录务必使用独立磁盘分区，避免因系统盘满导致 NFS 异常
替代方案对比（按适用场景）
如果业务规模扩大或对一致性要求极高，可考虑进阶选项：
- DRBD + Pacemaker/Heartbeat：块设备级同步，数据强一致，但配置复杂、维护成本高，适合传统关键业务
- NFS over CephFS 或 GlusterFS：分布式文件系统自带多副本和故障转移，但引入新组件，学习和排障门槛上升
-
纯对象存储 + CSI 插件（如 MinIO + csi-s3）：彻底规避 NFS 单点，但牺牲 POSIX 兼容性，不适合需要
flock或频繁小文件写的场景
