nfs 、smb不要混用,推荐linux使用nfs ,windows使用smb

  知识点

遇到个case,挂nfs协议的cfs在win10上使用,业务每15分钟会remount一次

专门抓包看了下,如下面两张图,在12:51:35写操作之后就没有再发起write call,中间有尝试连接445端口,并且发起了remount export call ;从端口51646看,remount后,TCP连接没有断,而remount之前有smb请求被rst,rst后才remount的,remount后过10秒多业务就恢复正常写操作了(这里篇幅所限,只展示了一次remount,其实每次remount都是这个特征)

客户端机器是域成员机,业务不变的情况下,如果用smb协议的cfs,没有15分钟remount一次cfs的问题,用nfs协议的则会每15分钟remount一次cfs。微软论坛搜到1篇帖子,描述的问题好像一样,但是没有解决方案

https://social.technet.microsoft.com/Forums/en-US/eca1fa69-a9da-4908-81df-532f4e15e140/windows-server-as-nfs-client-remount-issue?forum=winserverfiles

nfs server没有445端口,结合抓包,发现客户端会请求445端口,这很奇怪。确认只用smb协议的cfs没问题。我查了资料,一般建议linux客户端用nfs协议的存储、windows客户端用smb协议的存储,混合协议可能会有问题。所以,我先关闭这台机器的smb client(即关闭 LanmanWorkstation 服务)或者参考https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3 关闭客户端的smb协议试试。

LanmanWorkstation这个服务默认是开机启动的,设置为开机禁止启动,重启机器后验证业务正常了。

 

后来想着既然是请求445造成的,那能不能在防火墙上阻止出向445端口的流量,试了下,不行,加不加这个防火墙规则,结果都是一样,看来出现问题并不是流量出去了,而是因为产生了445端口的出向请求,这才是关键。

 

添加防火墙规则的命令:

netsh advfirewall firewall add rule name=block445 protocol=TCP dir=out remoteport=445 action=block remoteip=cfsIP profile=any

例如:

netsh advfirewall firewall add rule name=block445 protocol=TCP dir=out remoteport=445 action=block remoteip=10.255.4.21 profile=any

netsh advfirewall set allprofiles state on

 

如此看来,只有一个办法,那就是禁止smb client,让它发不了455请求,即禁止LanmanWorkstation服务或禁止smb协议。得到这个方案,完全是从这里突破的:nfs server没有445端口,结合抓包,发现客户端会请求445端口,这很奇怪。所以关闭smb client (LanmanWorkstation服务)来验证nfs协议的cfs不夹杂445请求 是否能正常,验证正常。但为了nfs协议的cfs能在这个业务场景的使用,要禁掉smb client未免有点因噎废食了。最好的方案还是使用cifs/smb协议的cfs,毕竟smb是windows原生的,兼容性是最好的。

推荐linux 使用nfs ,windows 使用smb

NFS 和 SMB 都是经过实战考验的通过网络共享数据的解决方案。虽然 NFS 在基于 Linux 的环境中最容易使用,而 SMB 在 Windows 上最简单,但这两种协议都可以在任何主流操作系统上运行。尽管如此,重要的是要考虑与这两种协议相关的潜在配置和兼容性挑战,并评估商业文件共享平台是否是更好的选择。

 

NFS 与 SMB:网络文件共享速成课程

NFS vs. SMB: A Crash Course on Network File Sharing

 

网络共享:NFS 和 SMB 之间的性能差异

Network share: Performance differences between NFS & SMB