把头发拉过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只读文件共享,就文件锁定等问题不会有任何问题.
>谁能告诉我,我在这里玩的是什么火？我真的不认为它会起作用,现在我有点震惊.
>缺点是什么？
>这可以依赖于生产环境吗？
解决方法
文件复制比您最初想象的要困难得多.
文件复制通常无法很好地扩展.当您处理的文件数量达到50万或更多时,您将开始看到问题,要么副本花费的时间比执行同步要长,所以您需要将会话粘贴更长时间并减少复制间隔或复制较少的文件.
从我知道的关于你的具体工作量的一点点来看,这对你来说仍然可以.您说文件共享是只读的,这使我相信您以大批量更新数据.在这些情况下,Robocopy可能会很慢,因为更改之间的间隔时间太长,这可能是一个可接受的风险.
在此设置中,看到HAProxy为第4层负载均衡器提供了比较智能,因此使用第4层负载均衡器可能更为有利,因为它们通常可以在高负载下以更少的延迟处理更多吞吐量.这可能不适用于您的问题,但需要深思熟虑.
如果您需要功能和性能(例如需要密切同步的r / w共享),那么这将不起作用.如果您认为将来需要使用此数据集,请仔细考虑您的解决方案,因为到那时您的数据集大小可能是太字节数,并且您不希望处于必须废弃它并将其重新上载到新解决方案.
