我当前的设置:2 个 NFS 服务器共享同一个目录,内容相同,1 个keepalived
服务器作为 SLB(或者在这种情况下用于故障转移),1 个 NFSv4 客户端通过 VIP 安装。所有系统都运行 CentOS 6(2.6.32-573.26.1.el6.x86_64)。由于这是一个测试环境,所有机器都位于同一个子网(192.168.66.xx)。作为参考,IP 如下。
99 VIP
100 nfs01
101 nfs02
102 client
103 keepalived01
NFS 服务器配置如下:
/root/share 192.168.66.0/24(ro,fsid=0,sync,no_root_squash
至于keepalived
,我在 DR 模式下运行它(NAT 模式根本无法工作)。
vrrp_instance nfs {
interface eth0
state MASTER
virtual_router_id 51
priority 103 # 103 on master, 101 on backup
authentication {
auth_type PASS
auth_pass hiServer
}
virtual_ipaddress {
192.168.66.99/24 dev eth0
}
}
virtual_server 192.168.66.99 2049 {
delay_loop 6
lb_algo wlc
lb_kind DR
protocol TCP
real_server 192.168.66.100 2049 {
weight 100
TCP_CHECK {
connect_timeout 6
connect_port 2049
}
}
real_server 192.168.66.101 2049 {
weight 102
TCP_CHECK {
connect_port 2049
connect_timeout 6
}
}
}
最后,客户端通过以下命令挂载:
mount -t nfs4 192.168.66.99:/ /nfsdata
NFSv4 挂载似乎可以正常工作,但我还没有对它进行压力测试。我注意到的一件事是,在故障转移期间的一段时间内,即我关闭了其中一个 NFS 服务器,强制keepalived
将服务移至另一个 NFS 服务器,客户端似乎会挂起一段时间后才响应。我相信这是由于 90 秒的宽限期造成的。
困扰我的问题是,在 NFS 服务器上,每隔几秒就会显示这行日志,导致日志泛滥。
kernel: nfsd: peername failed (err 107)!
我尝试tcpdump
查看是什么导致了流量,并发现 NFS 服务器和keepalived
服务器之间有重复的交换。起初我以为这iptables
可能是罪魁祸首,但在两台机器上刷新它们并不能阻止错误。
如果有办法抑制错误,我可能会就此打住(有吗?),但我的好奇心是:keepalived
在这种情况下,NFS 服务器是否有理由尝试与服务器通信?或者,即使以这种方式设置 NFS HA 似乎有效,也可能存在根本性错误?
答案1
进一步检查后发现,该错误kernel: nfsd: peername failed (err 107)!
大约每 6 秒出现一次。该数字似乎与connection_timeout
conf 文件中的选项相对应,并且确实通过停止keepalived
服务,该错误完全停止出现。
看来,通过TCP_CHECK
在端口 2049 上使用,NFS 服务器将记录“错误”的连接尝试,因为keepalived
没有根据协议发送 NFS 消息。
最后我用MISC_CHECK
它来检查 NFS 服务器的健康状况(使用自定义 shell 脚本调用rpcinfo
)。