在为 DFS 而烦恼之后，我脑子里突然冒出一个奇怪且具有潜在危险的想法，有可能，我可以使用 HA-Proxy 来平衡服务器之间的文件共享负载。
我进行了一些补救数据包跟踪，结果显示 TCP 端口 445 是使用 Windows 文件共享时唯一涉及的端口。多年来我一直认为 UDP 139、135 等也至少参与了建立连接 - 但显然不是！
因此我设置了一个基本测试：
listen SMBTest *:445
mode tcp
server Smb1 172.16.61.201:445
server Smb2 172.16.61.202:445
而且您绝对想不到...它有效吗？（！）
现在显然大家关心的是文件服务器之间的同步问题（当然）。只需使用一点 Robocopy 脚本就可以轻松解决。
并且考虑到我只需要一个 HA 只读文件共享，因此不会出现任何与文件锁定等相关的问题。
- 谁能告诉我我玩的东西是不是火？我真的没想到它会起作用，现在我有点震惊。
- 有什么缺点吗？
- 这在生产环境中可靠吗？
答案1
文件复制比您最初想象的要困难得多。
文件复制通常不能很好地扩展。当您处理的文件数量达到五十万或更多时，您就会开始看到问题，要么复制所花的时间比同步所花的时间长，因此您需要将会话保持更长时间并减少复制之间的间隔，要么复制更少的文件。
从我对您的具体工作量的了解来看，这对您来说可能还是可以的。您说文件共享是只读的，这让我相信您会大批量更新数据。在这种情况下，Robocopy 可能会很慢，但由于更改间隔很长，这可能是一个可以接受的风险。
鉴于 HAProxy 在此设置中提供与第 4 层负载均衡器相当的智能，使用第 4 层负载均衡器可能更有利，因为它们通常可以在高负载下处理更高的吞吐量和更低的延迟。这可能不适用于您的问题，但值得深思。
如果您需要功能和性能（例如需要紧密同步的读写共享），那么这将行不通。如果您认为将来需要此数据集，请仔细考虑您的解决方案，因为到那时您的数据集的大小可能会达到 TB 级，并且您不希望陷入必须将其废弃并重新上传到新解决方案的情况。