我们目前有一台 Thecus N12000V，16 TB 的 RAID 10（目前已满一半）。从我在网上读到的信息来看，这台机器的网速大约是 50MB/s。由于连接的人太多，大多数人最多只能得到 3MB/s。（所有机器都使用 SMB，所有电脑都是 Win 7 Pro，不支持 NFS）。
让 3 个相同的 NAS 盒不断进行 RSyncing，将它们连接到 Server 2008 R2 服务器并让其使用 DFS 处理 3 个之间的负载平衡，这样效率高吗？有没有更好的负载平衡解决方案？我尽量不把这个问题变成“购物”问题；如果我需要更具体一点，请告诉我。
答案1
我不建议采用手动分布式文件系统安排，让不同的人访问文件的不同驱动器，因为当两个人在不同的地方修改同一个文件时，您会遇到严重的同步问题。
目前有许多分布式文件系统（以及可以构建文件系统的分布式块设备）（见https://stackoverflow.com/questions/269179/best-distributed-filesystem-for-commodity-linux-storage-farm以获得指向开源解决方案的指针）。这些面向容错、大小可扩展性和远程访问性能，但如果您有多个本地节点，它们也会自然地提高多客户端访问可扩展性。不幸的是，您将无法在非企业级的现成 NAS 盒中使用这些（至少在我见过的任何 NAS 盒中都无法使用）。
使用 gbit 网络适配器时，50 到 100Mb/s 之间的速度限制可能是由网络接口或管理 RAID 的 I/O 控制器施加的，但吞吐量的主要瓶颈可能是驱动器，而不是其中任何一个。当几个人从驱动器中拉出数据时，磁头会在各处弹跳，从这里获取客户端 1 的一点数据，然后从那里获取客户端 2 的一点数据，然后是客户端 3，然后……，然后返回为客户端 2 的请求提供服务，……，……，…… - 每次磁头移动时，驱动器都无法传输数据。IO 控制器可以使用一些技巧（每个驱动器的巧妙电梯算法（见http://en.wikipedia.org/wiki/Elevator_algorithm)、当请求的数据位于多个位置时对驱动器之间的请求进行巧妙的排序等等)，但这些方法所能提供的帮助是有限的。
如果 NAS 盒具有自己的 RAM 用于缓存，而不是依靠驱动器来完成所有这些操作，您可能会发现它在某处有控制读取头和读取顺序的选项，这可以通过进一步减少服务同一组并发请求所需的头部移动量来提供帮助（但要小心彻底测试任何更改，因为您可能会让事情变得更糟而不是更好，并且一种访问模式的最佳选项对其他访问模式来说可能是残酷的）。
另一个值得考虑的选择是 SSD，因为 SSD 可以消除在随机或多路访问情况下使旋转金属驱动器陷入停滞的大部分延迟。虽然用崭新的 SSD 技术替换所有空间可能过于昂贵，但还是有一些折衷的选择。混合驱动器是旋转金属，内置一块 SSD 存储，用作缓存（并且由于是非易失性的，因此可以使用它来缓冲写入操作以及加快读取速度）。一些 NAS 盒内置支持使用 SSD 驱动器作为大型传统驱动器的大型非易失性缓存，从而无需用混合驱动器替换所有驱动器，而且效率可能更高，尽管 IIRC 此功能目前仅在更昂贵的盒子上提供。
答案2
DFS 仅提供一定程度的负载平衡。它不考虑副本维护的客户端会话数/会话长度，并使用 DNS 样式的循环选择。
NAS 本身具有支持负载平衡和故障转移的链路聚合，在尝试“自主开发”的负载平衡解决方案之前，我肯定会对此进行更多研究。