1. 为什么企业需要NFS高可用集群

想象一下这样的场景：公司财务部门正在通过共享目录处理季度报表，研发团队在同步代码库，市场部在更新宣传素材——突然NFS服务器宕机了。所有工作瞬间中断，数据可能丢失，业务停滞带来的损失难以估量。这就是为什么我们需要构建高可用的NFS集群。

传统单点NFS架构存在致命缺陷：

• 服务中断风险：硬件故障、网络问题都会导致服务不可用
• 数据同步滞后：备机数据往往不是最新状态
• 切换不透明：故障转移需要人工干预，客户端需要重新挂载

我在金融行业实施的一个案例中，通过Keepalived+Sersync方案将系统可用性从99%提升到99.99%，年故障时间从87小时降至不足1小时。这套方案的核心优势在于：

• 自动故障转移：VIP漂移过程对客户端完全透明
• 数据实时同步：Sersync基于inotify机制，触发式同步延迟在秒级
• 资源利用率高：备节点可承担只读负载

2. 架构设计与核心组件选型

2.1 典型拓扑结构

我们采用主备双活架构，关键组件包括：

[客户端] | [VIP: 192.168.100.100] | +-----+-----+ | | [NFS主节点] [NFS备节点] | | [Rsync] [Rsync] \ / [共享存储]

2.2 组件功能详解

NFS服务：

• 采用v4.2版本，支持文件锁迁移
• 配置no_root_squash需谨慎，生产环境建议使用all_squash
• 重要参数：sync（数据安全） vsasync（性能）

Keepalived：

• 实现VRRP协议，默认组播地址224.0.0.18
• 健康检查脚本需要检测三个关键服务：

  #!/bin/bash systemctl is-active nfs-server || exit 1 systemctl is-active rpcbind || exit 1 pgrep rsync || exit 1

Sersync：

• 对比inotify-tools的优势：
  • 多线程同步（默认10线程）
  • 内置重试机制
  • 失败日志记录
• 关键监控事件：

  <inotify> <delete start="true"/> <createFolder start="true"/> <closeWrite start="true"/> </inotify>

3. 实战部署步骤

3.1 基础环境准备

所有节点执行：

# 关闭防火墙 systemctl stop firewalld && systemctl disable firewalld # 安装依赖 yum install -y nfs-utils keepalived rsync # 创建共享目录 mkdir -p /data/nfs_share chmod 777 /data/nfs_share

3.2 NFS服务配置

主节点配置：

# /etc/exports /data/nfs_share 192.168.100.0/24(rw,sync,no_root_squash) # 启动服务 systemctl enable --now nfs-server exportfs -v # 验证共享

3.3 Keepalived配置

主节点/etc/keepalived/keepalived.conf：

vrrp_script chk_nfs { script "/usr/local/bin/chk_nfs.sh" interval 3 weight -5 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass nfs@123 } virtual_ipaddress { 192.168.100.100/24 } track_script { chk_nfs } }

备节点只需修改：

state BACKUP priority 90

3.4 Sersync实时同步

主节点配置：

<!-- /usr/local/sersync/confxml.xml --> <localpath watch="/data/nfs_share"> <remote ip="192.168.100.11" name="nfs_share"/> </localpath> <rsync> <commonParams params="-azR"/> <auth start="true" users="rsync_user" passwordfile="/etc/rsync.pass"/> </rsync>

启动命令：

/usr/local/sersync/sersync2 -d -o /usr/local/sersync/confxml.xml

4. 关键调优参数

4.1 NFS性能优化

/etc/nfs.conf关键参数：

[nfsd] threads=16 # 工作线程数，建议=CPU核心数*2 tcp=y # 使用TCP协议 vers=4.2 # 使用NFSv4.2 [exportfs] async=y # 生产环境慎用

客户端挂载优化：

mount -t nfs4 -o \ rw,hard,intr,noatime,nodiratime,rsize=65536,wsize=65536 \ 192.168.100.100:/data/nfs_share /mnt/nfs

4.2 Sersync调优

confxml.xml关键参数：

<inotify> <modify start="false"/> <!-- 避免重复触发 --> </inotify> <sersync> <localpath watch="/data/nfs_share"> <remote ip="192.168.100.11" name="nfs_share"/> <remote ip="192.168.100.12" name="nfs_share"/> <!-- 多目标同步 --> </localpath> <failLog path="/var/log/sersync_fail.log"/> <!-- 失败重试日志 --> </sersync>

5. 故障模拟与切换演练

5.1 测试场景设计

5.2 实际测试记录

# 在主节点模拟NFS故障 systemctl stop nfs-server # 观察VIP切换（约3秒完成） [root@client ~]# time while ! ping -c1 192.168.100.100; do sleep 1; done # 验证数据一致性 diff -r /mnt/nfs /backup/nfs_share | wc -l

6. 生产环境注意事项

1. 脑裂预防：

   • 配置多播改单播（keepalived.conf）：

     unicast_src_ip 192.168.100.10 unicast_peer { 192.168.100.11 }

   • 使用串口线或独立心跳网卡

2. 监控指标：

   • NFS：nfsstat -c查看客户端统计
   • Sersync：监控/var/log/sersync_fail.log
   • Keepalived：ipvsadm -Ln查看VIP状态

3. 常见问题处理：

   • 同步延迟：调整Sersync的<failLog timeToExecute="60">
   • 挂载卡死：客户端添加soft,intr参数
   • 权限混乱：确保所有节点nfsnobody用户UID一致

这套方案在某电商平台支撑了"双11"期间每秒上万次的文件访问请求。关键是要根据业务特点调整参数，比如：

• 小文件密集场景：增加nfsd.threads
• 大文件传输场景：调大rsize/wsize
• 高安全要求：启用NFS Kerberos认证