你用对了么？对象文件网关 VS 分布式文件存储

2022 年 9 月 26 日
北京
本文字数：2034 字
阅读完需：约 7 分钟

在近期的文章留言中，我们看到一个很好的提问可以作为话题一起探讨。有关基于对象的两类文件存储，一类是“对象文件网关型”文件存储，即在对象存储的基础上提供文件接口，支持用户业务以文件的方式去使用对象存储。另一类则是分布式文件存储，即对象存储的使用只是整个文件系统功能的一部分，这种文件系统本身的功能是完整的，且同时支持对象存储，来满足某些业务需求。针对这两类存储产品一些同学存有疑惑，比如：

疑惑一：产品架构的设计思路上到底有何不同？
疑惑二：对象文件网关 VS 分布式文件存储架构的优劣势体现在哪里？
疑惑三：这 2 种产品架构适合怎样的应用场景和业务？

如果恰巧你关注的也是以上这些问题，希望这篇技术科普文可以很好地帮助到你，也欢迎大家留言。

众所周知，存储系统一般分为块存储、对象存储和文件存储三种。其中文件存储的使用最为广泛，小到个人电脑、家用 NAS，大到传统 HPC、大数据平台、AI 等等，这些都是以使用文件接口为主。近几年，得益于存储空间大、成本低的优势，对象存储扮演着越来越重要的角色。但用户业务往往不能直接使用对象存储，于是市面上出现了一些实际使用的是对象存储但对外提供文件接口的号称文件存储的方案。

“对象文件网关型”文件存储，一般架构上可以划分为客户端、元数据服务和数据服务三大块：

1、客户端：一般都是基于 fuse 实现，优点是简单，缺点是会有一定性能损耗（可参考论文 FAST'17 To FUSE or Not to FUSE，点击阅读原文获取链接）。

2、元数据服务：基本都是使用第三方数据库，比如 mysql、redis、tikv 等。

mysql 没有强一致集群方案，性能较差，因此一般不会选用。
redis 以性能高著称，但内存占用极高，且有单点数据风险，不能支持较大数据规模。
tikv 是强一致的分布式 kv，相对而言是个不错的选择。但掌握和维护 tikv 颇有挑战。

3、数据服务：直接使用对象存储，比如 Amazon S3、阿里云 OSS 等。

可以看出，对象文件网关架构深度使用和依赖于第三方系统，它将复杂的 data io 交给对象存储，将更复杂的 meta io 交给第三方数据库，比较取巧，但也的确不失为一种有效的选择。对象网关文件存储天然获得了这些优势：

容量无限，用户可以在对象存储中存放海量数据。
成本相对较低，对象存储往往用价格更低的硬盘（如大容量机械硬盘），且使用 EC 等更节省空间的数据冗余算法。
一定的吞吐能力。

也正因为这种架构设计，为“对象文件网关型”文件存储带来一些功能上的限制，最为突出的是随机写性能差，究其原因一是对象不支持修改，二是用户业务往往需要写数据。因此不同的对象文件网关系统，采取了不同的应对方法：

方法一：规避需要写入，尤其是随机写较多的业务。拥抱只读为主、数据量很大的业务，比如视频备份等。
方法二：利用本地盘做数据缓存。不过这又引入了新的问题，主要是本地盘缺乏冗余，也不方便数据共享。

那么，分布式文件存储系统的表现又是怎样的呢？首先它是基于 x86 架构设计的一款分布式文件存储系统，支持主流对象存储，一般用户会使用两种典型功能：数据分层和跨云数据整合。接下来，我们逐一介绍下：

数据分层

定义热层在本地，冷层在对象存储。被读写的数据将自动落在热层，而未被访问的数据，根据策略被判定为冷数据后，将被自动放到冷层，冷热层数据流动完全对用户透明。

优势：

这种设计思路可以理解为热层为数据读写提供极高的性能。比如 GPU 计算集群对存储性能要求极高，则热层可以部署 RDMA、NVMe 等高性能硬件去满足业务需求。而冷层又可以存储海量的冷数据，用以节省存储成本。冷热层数据透明流动，做到业务无感知。用户既得到了热层高性能，同时又得到了冷层的大容量低成本。