背景信息：
所以我有一个Ubuntu 14.04服务器（1千兆网卡）和一个NAS（Synology DS1815 +，4千兆网卡）。 我正在定期通过Ubuntu 14.04服务器和我的networking之间的千兆线路。 大部分但不是全部的stream量都是NAS。 NAS在Ubuntu 14.04服务器上作为NFS共享装入。
我刚刚购买了一个USB 3.0双千兆网卡适配器（尚未到货）。 我的计划是将适配器连接到服务器，并将两个nics连接到NAS。 这将作为NAS和服务器之间的直接连接。 NAS正式支持LACP，USB nic适配器也是如此。
问题：
我想了解LACP及其与NFS的关系。 我知道LACP不会简单地将带宽加倍，但我不确定我是否掌握了如何使用NFS进行平衡。 关于通过专用连接在NAS和服务器之间的传输，这里是我的问题：
LACP是否能够从单个NFS共享中为单个文件传输提供任何性能优势？ （这看起来不像我读过的，但只是确保）
LACP是否能够为单个NFS共享的多个同时文件传输提供任何性能优势？
LACP是否会为多个NFS共享的多个同时文件传输提供任何性能优势？ （这似乎是）
NAS并没有正式支持balance-rr，但是如果它起作用，那么这会比LACP更好吗？
另一种债券模式会更合适吗？ （这看起来不像我读的东西，只是确保）
感谢您的帮助！
回答你的问题：
LACP是否能够从单个NFS共享中为单个文件传输提供任何性能优势？ （这看起来不像我读过的，但只是确保）
不，不会的 LACP将跨网卡传播TCP会话，并且描述的是单个会话。 LACP不会像bond-rr那样对stream量进行条带化处理（这是有很大的理由的）。
LACP是否能够为单个NFS共享的多个同时文件传输提供任何性能优势？
不，因为这仍然通过一个会议发送。
LACP是否会为多个NFS共享的多个同时文件传输提供任何性能优势？ （这似乎是）
它可以，如果你的NFS客户端被configuration为在装载上产生多个会话。 大多数是（通常默认约八）。 但是，根据你的LACPalgorithm，这可能不是这种情况。 一些algorithm基于MAC地址（意味着客户端的单个NIC永远不会连接到服务器上的多个NIC）或会话来传播连接，这将允许这种types的stream量跨越服务器端的NIC，由于多个会议创build。
NAS并没有正式支持balance-rr，但是如果它起作用，那么这会比LACP更好吗？
几乎在所有情况下，这绝对不会更好。 balance-rr适用于服务器之间的点对点连接。 当涉及到交换机或任何其他中间设备时，由于stream量在接收方不按顺序进入，会引入极大的抖动。 但是，对于节点间的点对点同步networking来说，它可以工作的很好。 尽pipe如此，这个比例非常大，所以我从来没有在三个节点集群（顶部）之外看到它。
另一种债券模式会更合适吗？ （这看起来不像我读的东西，只是确保）
LACP是您现在可以使用的最智能的债券模式。 如果pipe理得当，它运行得非常好，它可以很好地处理故障转移。
如果您想通过单个“会话”跨networking链接进行数据分割，使用iSCSI进行多path处理的效果非常好。 GlusterFS还能够以LACP需要performance良好的方式传播stream量，而且其行为与NFS类似。 不过，你真的无法打败NFS的简单性。