如文章《幻方力量 | 高速读写文件系列 3FS》中所介绍的，幻方AI设计了一套非常适合深度学习训练的样本读取文件系统，3FS，其采用Direct IO和RDMA Read的读取方式，让模型训练在样本读取部分只用极小的CPU和内存开销，就可以获得超高的读取带宽，从而无需再训练过程中等待加载数据，更充分地利用起GPU的计算性能。
为了实现训练性能的最优化，幻方AI采用InfinBand技术来构建整个萤火二号集群的网络。本文将介绍我们针对InfinBand在我们实际场景的应用中所遇到的问题，介绍我们的探索和优化思路。
我们知道，幻方AI的深度学习平台是计算与存储分离的，计算服务只负责计算，而所有的数据读取、模型保存、中间数据保存等，都需要通过计算服务与存储服务之间的网络进行通讯交互，这里面会不可避免地发生一些不同应用的流量相互影响、从而导致整体性能（波动/下降）的问题。
流量分类
计算服务与存储服务之间通过网络交换着各种各样不同类型的数据。如何在这样复杂的网络应用场景中保持优异的性能呢？InfinBand提供了一种叫做虚拟通道（Virtual Lane）的机制，可以将单个物理链路划分成多个逻辑的流，每个通道都有自己的流量控制机制，而不会互相影响。
如上图所示，一开始我们设计的解决方案，是把计算侧的流量（例如：模型保存、梯度reduce等）分到了单独的虚拟通道（Virtual Lane） 上，与3FS的流量隔离，避免两者互相影响。这个改动在初期取得了一定成效。但是之后我们把3FS的读取从 RDMA Send/Recv 改成了用 RDMA Read 之后，我们又发现3FS自己的不同流量之间也会互相影响。
我们把 RDMA Read 的流量放到单独的虚拟通道上测试，并没有彻底解决问题。后来我们意识到，虽然从存储侧读取到的数据走的是 RDMA Read，但是发起读取这个行为的请求走的还是在计算侧（Send/Recv），在老的虚拟通道里会受到其他流量的影响。因此，我们再次把流量进行进一步细分之后，才把3FS的带宽完全打满。
Infiniband 路由算法
Infiniband 的路由算法对于带宽的影响也很大。
我们集群目前用迈络斯的800口大交换机，其内部是由60台小交换机组成的两层FatTree结构（如上图所示），但在我们的场景中，800 口的交换机并不能完全满足我们的需求，我们实际还在上面挂了若干个 40 口的交换机。所以我们实际的网络结构并不是标准的FatTree。在迈络斯技术人员的建议下，我们最初选用的是UpDown的路由算法。但在这种情况下。我们发现3FS的表现并不稳定，有的时候表现尚可，但是有些时候则非常糟糕。
我们尝试了很多方案来排查这个问题。最初我们怀疑是3FS软件实现的问题，我们多次调整小交换机的连接方式、修改网络协议和通信方式等，又多次回滚，都没有达到理想的效果。直到在某次升级时，我们断开了一台40口小交换机的连接，惊人地发现网络状况立刻变好了。
我们分析后发现，插小交换机本身不应该造成如此严重的影响。我们的集群中有两个OpenSM实例，原来的主OpenSM接在这个被断开的小交换机下面。当断开小交换机的时候，800 口交换机自带的 OpenSM 实例就成为了唯一的实例，接管了网络，这时启用了默认的 FatTree 算法，网络状况就瞬间变好了。如果让原来的 Up-Down 算法生效的话，带宽一开始可以跑满，但是很快就会掉下来。不过也不是说多挂 40 口交换机就没有影响，在某些情况下，40 口和 800 口之间的连线上拥塞会很高，同样会影响整个集群的性能。
Adaptive Routing
除了上面说的问题，我们发现 Adaptive Routing 也是一个值得深究的问题。
早期我们发现集群中流量不均匀的时候，在 Up-Down 算法的基础上打开了 Adaptive Routing，带宽立刻就提升了。但是后来我们发现，在网络负载较低的时候，Adaptive Routing 的确能通过把流量均分到集群中各个节点，提升整个网络的总带宽；但当有比较高的拥塞出现的时候，Adaptive Routing 也会把一个节点的拥塞传播到了集群所有的节点上，流量虽然均匀了，但是总带宽反而下降了。因此，目前Adaptive Routing算法已不适用于我们的场景。
小结
本文介绍了幻方AI在设计3FS文件系统时，针对网络配置优化的一些实践和思考。我们采用更精细化的虚拟网路配置，更合理的路由算法，让网络带宽充分利用，最大的发挥出集群的硬件性能。
幻方AI在长期实践中对3FS不断优化，遇到了不少挑战。本系列文章将陆续为大家分享一些有关3FS性能优化的小故事，作为抛砖引玉，其中还不乏我们踩过的坑。欢迎业界的学者专家们一起探讨。