为什么解决文件协议 OP 放大的问题,对分布式文件存储特别重要?
![为什么解决文件协议 OP 放大的问题,对分布式文件存储特别重要?](https://static001.geekbang.org/infoq/a9/a98fb6a0a2f65d11b1f4202e4dd58d68.jpeg)
解决 OP 放大问题对于分布式文件系统的性能进一步提升十分关键,可以用更少的系统资源(CPU、IO、网络)实现同等的客户端 IOPS 结果。
XGFS 自从 2021 年发布 V5.0 开始第一个正式版本,到 6.4 版本发布已经完成 7 个主要版本的迭代,伴随着完善的 NAS 企业级功能,XGFS 在性能方面一直追求极致。在新发布的 6.4 版本里,XGFS 进一步提升了 NFS/SMB 协议下的小文件性能,特别在延迟降低方面取得了较大进展。
在探讨 6.4 版本的性能提升前,先回顾下过去 XGFS 版本的性能相关架构更新:
文件元数据集群支持海量小文件,提供高性能低延迟的文件元数据服务;
基于通用服务器,提供多副本冗余保护的数据写缓存,提供低延迟的单流写入,比肩使用电池保护的传统 NAS 阵列内存缓存性能。
随着集群元数据和缓存性能的提升,文件协议网关的瓶颈逐步成为制约,特别是 NFS/SMB 协议自 20 世纪 90 年代以来,始终基于集中式架构的演进,对于协议操作的设计实现都基于本地假设,而不是分布式文件系统的跨网络调用。比如,在集中式 NAS 中,文件协议基于本地文件系统承载,不会带来在单个文件请求里出现额外的网络调用,且可以使用系统本地内存(有掉电保护和镜像机制)做数据和元数据缓存,在亿级别以下数据量能够发挥很好的性能。
在分布式文件系统架构中,通过横向扩展和元数据和数据分离的架构设计,很好解决了亿级别以上的文件容量扩展和性能问题,但是这也带来了单一文件请求出现多次网络调用的性能影响,我们将这个问题描述为文件协议网关的 OP 放大问题。
![](https://static001.geekbang.org/infoq/7c/7cd75236297b203469b82130caf1af8f.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
随着 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 性能。
实验室性能混闪硬件测试结果如下:
![](https://static001.geekbang.org/infoq/86/86496cb3114a26bcaedab41b155e3b7b.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
通过协议 OP 优化,IOPS 性能全面提升,特别是读性能。写性能应该已经达到混闪池的瓶颈,因此效果没有这么明显。但如果以后换成星飞全闪数据池,相信这次 OP 优化的效果也可以体现出来了。
SMB 协议 OP 放大减少到 1.3 倍
SMB 协议也是 NAS 存储最重要的协议之一,多应用于 Windows 操作系统,适用 PACS、仿真、基因测序、文件网盘,制造业数据采集等场景。
SMB 协议由于元数据操作是串行方式,如典型的 CREATE/GETINFO/CLOSE 等等,都是以单线程,同步的方式执行,导致时延很高,同时并发也上不去。需要性能提升,协议 OP 放大优化就变得极为重要。
![](https://static001.geekbang.org/infoq/37/378fdd998d9e4b3166354e94c9c95559.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
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 路径长问题,提升单流写性能),性能进一步提升。
内部实测单流拷贝性能如下:
![](https://static001.geekbang.org/infoq/5f/5f0a28a7c6c33321ab1f0b47f19328a0.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
(注:PACS 场景之一, 57K 是图片切片大小)
同时,我们也和业界著名的 NAS 厂商 NetApp 的全闪 NAS 进行了性能对比, 测试了 SMB 协议 57KB 小文件拷贝性能。发现如果存储节点采用老的 CPU 平台,性能可达到 NetApp 75%以上,如果采用新的 CPU 平台,性能接近 NetApp 的 93%,几乎可以媲美 NetApp。
![](https://static001.geekbang.org/infoq/dd/ddc80117088991bc7f1e0633a5695d13.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
(注:XGFS v6.4 虽然采用混闪配置,但元数据是保存在 NVMe SSD 上的,这个场景混闪和全闪应该差距不大)
信创 NAS 存储 性能提升同样明显
在信创 CPU 上,文件网关协议 OP 放大的降低带来了更大的性能收益。XGFS 文件系统由于实现了用户态架构,可快速支持国产 CPU 架构平台和操作系统兼容。在最新 6.4 版本协议 OP 放大优化后,信创硬件平台性能相应提升,内部实验室测试机性能如下:
![](https://static001.geekbang.org/infoq/4c/4c89c61f56f34e1582cd1c51ec01b314.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/8a/8ae6992f6e6b3cf8f26f2e864fdb9fa1.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
相同硬件条件下对海光和鲲鹏平台,OP 优化后性能提升巨大,性能可以媲美同档次的国外主流 NAS,如 NetApp,是 NetApp 国产化替换的理想选择。
XSKY 文件存储已经有很多的信创案例,包括珠海华润银行、北京银行、贵州农信、安信证券、东风财务等。这次 XSKY SDS V6.4 版本的文件性能优化,将会大大加速信创文件存储的推进。
小结
分布式文件存储系统的性能与 NFS 和 SMB 协议操作密切相关。协议的设计、网络条件、并发处理能力和缓存机制等因素都会影响整体性能。通过优化协议实现和采用合适的架构设计,分布式文件存储系统能够在提供高性能的同时,保持数据的高可用性和一致性。
XGFS 6.4 版本通过对 NAS 核心协议(NFSv3、SMB)OP 放大优化,极大提升了集群的 IOPS 性能。在某项目 POC 中,对比国内 S 友商,发现该厂商的 NFS 协议放大 3 倍,SMB 协议放大 3 倍,XGFS 协议性能大幅领先。
同时,XGFS 企业级文件存储不仅支持企业级高级特性,还支持文件双活、多协议互通等高级功能,全方位满足客户业务需求。
在信创生态中,XSKY 将持续针对信创硬件和操作系统适配,为客户信创转型提供完善的解决方案。
版权声明: 本文为 InfoQ 作者【XSKY星辰天合】的原创文章。
原文链接:【http://xie.infoq.cn/article/b6aff9e690782ae8d3346e29b】。文章转载请联系作者。
评论