解决文件协议 OP 放大，XSKY 文件存储 XGFS性能再突破-DOIT-数据产业媒体与服务平台

XGFS 自从 2021 年发布 V5.0 开始第一个正式版本，到 6.4 版本发布已经完成 7 个主要版本的迭代，伴随着完善的 NAS 企业级功能，XGFS 在性能方面一直追求极致。在新发布的 6.4 版本里，XGFS 进一步提升了 NFS/SMB 协议下的小文件性能，特别在延迟降低方面取得了较大进展。

在探讨 6.4 版本的性能提升前，先回顾下过去 XGFS 版本的性能相关架构更新：

文件元数据集群支持海量小文件，提供高性能低延迟的文件元数据服务；
基于通用服务器，提供多副本冗余保护的数据写缓存，提供低延迟的单流写入，比肩使用电池保护的传统 NAS 阵列内存缓存性能。

随着集群元数据和缓存性能的提升，文件协议网关的瓶颈逐步成为制约，特别是 NFS/SMB 协议自 20 世纪 90 年代以来，始终基于集中式架构的演进，对于协议操作的设计实现都基于本地假设，而不是分布式文件系统的跨网络调用。比如，在集中式 NAS 中，文件协议基于本地文件系统承载，不会带来在单个文件请求里出现额外的网络调用，且可以使用系统本地内存（有掉电保护和镜像机制）做数据和元数据缓存，在亿级别以下数据量能够发挥很好的性能。

在分布式文件系统架构中，通过横向扩展和元数据和数据分离的架构设计，很好解决了亿级别以上的文件容量扩展和性能问题，但是这也带来了单一文件请求出现多次网络调用的性能影响，我们将这个问题描述为文件协议网关的 OP 放大问题。

随着 AI/GPU 场景的爆发，对于存储性能的要求一下子提升一大截，硬件性能本身已经暴露出了瓶颈，更不用说软件还带来额外的 OP 放大浪费。基于分布式文件架构设计的产品很多，但市面上大部分产品都还没涉及到这个问题，或者说仍然存在严重的 OP 放大问题。在很多时候，仍然通过更多的系统资源来掩盖问题，比如更高的 CPU、更好的 SSD 等。因此，面向未来的 AI/GPU 文件需求，文件协议网关的 OP 放大问题的解决决定了文件存储系统的性能竞争力。

文件协议 OP 放大问题

文件协议网关的 OP 放大问题（Operation Amplification Problem）是指在文件存储系统中，由于文件协议（如 NFS、SMB）的设计和实现，每个用户请求的操作（如创建、读取、写入、删除文件等）需要在底层存储系统中执行多次额外的操作。这会导致实际执行的操作数量远多于用户请求的操作数量，从而引起性能问题。以下是 OP 放大问题的具体描述：

协议复杂性：文件协议（如 NFS、SMB）通常包含多个步骤来完成一个操作。例如，一个写操作可能需要包括创建文件、设置文件信息、写入数据、再次设置文件信息、获取文件信息、关闭文件等多个步骤；
元数据操作：每次文件操作（如读写）往往伴随着多次元数据操作，例如鉴权、属性检查和更新元数据（如文件长度、修改时间等）；
分布式系统特性：在分布式文件系统中，操作需要在多个节点间协调完成，导致额外的网络通信和同步操作。这进一步增加了操作放大的程度。

这些 OP 放大会带来显著的性能影响，不仅增加了 I/O 路径的长度，还增加了网络传输的延迟和处理时间。另一方面，额外的操作也会消耗更多的计算资源和网络带宽，导致系统效率降低。

因此解决 OP 放大问题对于分布式文件系统的性能进一步提升十分关键，可以用更少的系统资源（CPU、IO、网络）实现同等的客户端 IOPS 结果。

为什么文件协议 OP 放大问题，难以解决？

首先 OP 放大需要面临文件协议的复杂性：

复杂的协议规范：文件协议如 NFS 和 SMB 经过多年的发展，功能丰富，协议规范复杂。理解并优化这些复杂协议需要深入的专业知识；
版本差异：不同版本的协议（如 NFSv3、NFSv4.1，SMB1.0、SMB2.0、SMB3.0 等）存在显著差异。优化时需要针对不同版本进行适配和测试；
平台差异：不同操作系统和内核版本对协议的实现也不同。例如，Linux 和 Windows 在 NFS 和 SMB 协议的实现上有不同的优化和特性，这增加了优化的难度。

这些协议的历史演进都成为了解决 OP 放大的挑战，需要在不破坏协议原有语义和兼容性的前提下，进行语义扩展或合并操作。例如，将多个操作合并为一个操作，但仍需确保这些操作在协议层面上是合法的。

而减少 OP 放大的本质就是合并多个 OP 以及尽可能通过缓存技术实现本地命中，因此，不仅要求协议细节的掌握，还要求分布式文件系统的元数据服务和缓存机制紧密配合，这对于非自研的文件系统产品来说几乎做不到。

以元数据管理为例，文件系统中的许多操作涉及元数据（如文件创建、属性设置、权限检查等）。优化这些操作需要高效的元数据管理机制，而这些机制本身又复杂且难以优化。简单的元数据缓存无法解决跨节点的元数据一致性，需要精细的锁机制和一致性协议来确保数据的正确性。

历经 4 年的生产部署经验和广泛的企业级 NAS 场景适配，通过逐步优化现有系统的协议语义，减少对系统稳定性的影响，并验证每一步优化的效果。XSKY 终于在 XGFS 6.4 版本的文件协议 OP 放大问题实现了突破。

NFS/SMB OP 放大问题的解决效果

NFS 协议 OP 放大完全消除

NFS 协议广泛应用于 Linux 操作系统中，是目前主流的文件协议之一，XGFS 当前支持标准 NFSv3 协议。应用于云原生、AI、HPC、文件共享等场景。

针对 NFSv3 协议，每次读写 IO 都需要多次访问元数据，用于处理鉴权、属性检查等操作，同时完成 OP 后也需要给客户端返回新的长度、修改时间等元数据，也就带来在数据 IO 之外需要多次元数据操作；

优化前：一次 write/read，通过通过 NFS 协议后，OP 放大 4 倍，极大增加后端系统压力，IOPS 性能不如预期；
优化方法：XGFS 自研文件系统与 NFS 协议组合，实现富语义 OP，批量完成 IO 需要的所有 OP 操作，避免协议层和数据服务层的多次交互；
优化后：一次 write/read，协议只需要 1 次 OP 操作，消除 OP 放大后，完全释放了 NFS 协议 IOPS 性能。

实验室性能混闪硬件测试结果如下：

通过协议 OP 优化，IOPS 性能全面提升，特别是读性能。写性能应该已经达到混闪池的瓶颈，因此效果没有这么明显。但如果以后换成星飞全闪数据池，相信这次 OP 优化的效果也可以体现出来了。

SMB 协议 OP 放大减少到 1.3 倍

SMB 协议也是 NAS 存储最重要的协议之一，多应用于 Windows 操作系统，适用PACS、仿真、基因测序、文件网盘，制造业数据采集等场景。

SMB 协议由于元数据操作是串行方式，如典型的 CREATE/GETINFO/CLOSE 等等，都是以单线程，同步的方式执行，导致时延很高，同时并发也上不去。需要性能提升，协议 OP 放大优化就变得极为重要。

SMB 协议一次小文件写入，客户端需要 create/setinfo/write/setinfo/getinfo/close 6 次 OP 操作，

优化前：客户端下发的 6 次操作会在协议里放大到 20 次操作，放大 3.3 倍，SMB 小文件拷贝延迟高、性能差；
优化方法：XGFS 自研文件系统与 SMB 协议组合，实现协议富语义 OP，减少鉴权、属性获取等 OP 操作；
优化后：一次写入，客户端下发 6 个 OP，经过协议后减少到 8 个，减少到 1.3 倍，小文件拷贝性能提升明显。

SMB 协议配合 XDCache 写缓存（支持内存 3 副本和持久化存储，大大减少分布式带来的 IO 路径长问题，提升单流写性能），性能进一步提升。

内部实测单流拷贝性能如下：

（注：PACS 场景之一， 57K 是图片切片大小）

同时，我们也和业界著名的 NAS 厂商 NetApp 的全闪 NAS 进行了性能对比，测试了 SMB 协议 57KB 小文件拷贝性能。发现如果存储节点采用老的 CPU 平台，性能可达到 NetApp 75%以上，如果采用新的 CPU 平台，性能接近 NetApp 的 93%，几乎可以媲美 NetApp。