所以我有一台Ubuntu 14.04服务器(1千兆位)和一台NAS(Synology DS1815,4千兆位网卡).我正在定期通过Ubuntu 14.04服务器和我的网络之间的千兆线路.大部分但并非全部流量都来自NAS. NAS作为NFS共享安装在Ubuntu 14.04服务器上.
我刚购买了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将跨NIC传播TCP会话,您所描述的是单个会话. LACP不像bond-rr那样对流量进行条带化(这有很大的原因).
LACP是否可以从单个NFS共享中同时进行多个文件传输,从而提供任何性能优势？
不,因为这仍然通过单个会话发送.
LACP是否会从多个NFS共享的多个同时文件传输中提供任何性能优势？ (好像它会)
如果您的NFS客户端配置为在mount上生成多个会话,则可以.大多数是(通常默认大约八).但是,根据您的LACP算法,情况可能并非如此.一些算法基于MAC地址(意味着来自客户端的单个NIC永远不会连接到服务器上的多个NIC)或通过会话来扩展连接,这将允许此类流量在服务器端的NIC上传播,因为多个会话已创建.
NAS没有正式支持balance-rr,那么这比LACP更好吗？
几乎在所有情况下都绝对不会更好. balance-rr适用于服务器之间的点对点连接.当涉及交换机或任何其他中间设备时,它会引入极大量的抖动,因为流量在无序接收端进入.但是,它可以很好地用于节点间点对点同步网络.但是,这种情况非常严重,因此我从未在三个节点集群(顶部)之外看到它.
另一种债券模式会更合适吗？ (它看起来不像我读过但只是确定)
LACP是您现在可以使用的最智能的绑定模式.正确管理后,它运行良好,并且非常优雅地处理故障转移.
如果您希望通过单个“会话”跨网络链接进行数据条带化,则使用iSCSI进行多路径处理非常有效. GlusterFS还能够以LACP需要良好运行的方式传播流量,并且其行为与NFS类似.但是你真的无法击败NFS的简单性.
