CubeFS混合云存储加速设计揭秘

岳鸿

以下文章来源于CubeFS官微，作者CubeFS官微



00
业务背景

前文CubeFS在OPPO机器学习平台的技术实践第三节介绍了CubeFS在机器学习平台混合云场景的背景和存储解决方案。接前文内容，本文将详细阐述CubeFS在混合云场景下，存储缓存加速原理及实践。


混合云-存储架构

简单回顾下混合云场景下机器学习存储痛点：

1）跨区域带来的存储性能问题：由于网络带宽时延（2ms),公有云GPU主机访问存储性能急剧下降，无论是元数据操作、还是数据IO，无论是对于延迟敏感的小文件训练集，还是lmdb格式的大文件训练集（fuse iosize为128k, 大文件也需要多次网络IO）。对比OPPO私有云的GPU主机访问存储，通过io瓶颈的AI训练模型观察到单GPU卡每epoch处理的samples相差2-4倍，io瓶颈导致GPU卡利用率低，这对于任务训练时间、GPU资源无疑是一种极大的浪费。


公有云和OPPO私有云AI模型训练对比

2）资源弹性及安全问题：初期阶段调度到公有云GPU的task pod会挂载公有云文件存储，但需要用户将OPPO云中的CubeFS数据迁移到公有云存储，用户使用成本高、体验不一致，部分数据面临安全合规问题，不能进行迁移。因此AI算力调度平台并不能实现真正的弹性。

除了以上业务痛点，AI训练自身的特点——每轮epoch训练都会重复读取同一训练集数据——也会给平台带来挑战。为了解决网络延迟带来的性能问题，CubeFS在客户端设计了一套缓存加速机制：实现本地缓存，拉取远端训练数据靠近到GPU计算节点，将CubeFS元数据延迟降低到us级别，数据延迟降低到百us级别。

在AI混合云架构下，缓存加速带来以下收益：

1）统一存储到CubeFS，对于GPU算力平台做到真正的弹性能力。

2）对于业务透明，使用方式和性能与OPPO私有云体验一致。

01
整体简介

架构


CubeFS-client 读加速架构图

文件系统包括文件元数据和数据。因此客户端的缓存包括元数据缓存meta-cache和数据缓存data-cache两部分。

metacache:  元数据缓存,缓存在CubeFS client内存中，主要缓存inode、dentry两类元数据。

datacache (blockcache):  数据缓存服务，基于uds(unix domain socket)实现 。

由blockcache client和service组成，主要是管理缓存数据的索引信息、缓存数据的读写入、缓存数据盘的空间管理。单独部署在公有云GPU宿主机上，同一台宿主机的pod共享缓存服务。缓存数据的读取：先通过blockcache获取文件在缓存盘的位置信息，然后直接通过标准的POSIX接口读取文件。

接下来，我将分别介绍缓存加速在元数据和数据两个场景下的具体方案。

02
元数据加速

通过分析训练过程中的CubeFS client端元数据操作，发现主要耗时的元数据操作如下图：

元数据访问	平均延迟	描述
Lookup	5.23ms	lookup操作是访问文件的dentry信息。dentry描述文件系统的层级关系。
Open	2.98ms	获取文件inode信息，包括文件基本信息、数据分片extent信息

文件系统中读写文件会访问inode属性和dentry两种元数据，虽然kernel fuse模块中已经支持dentry以及inode缓存, 在fuse挂载时候通过指定entry_timeout和attr_timeout来设置dentry以及inode属性的缓存时间。但依然面临两个问题：

1、缓存的时效性，挂载时设置缓存的过期时间，无法灵活适应不同类型训练任务。缓存过期时间设置过长，内存得不到及时释放，设置过短，则影响缓存命中率。

2、缓存的作用范围，开启元数据缓存是对整个客户端生效，在实际使用中，会影响有一致性要求的文件（如在notebook中编辑的代码文件）。因此在CubeFS-client实现基于指定目录的dentry和inode的cache，这样更灵活的管理缓存的范围和生命周期。

inodeCache

inodecache主要涉及两部分的缓存：inode的基本属性和inode对应的数据分片extent 信息。

对于inode基本属性通过在客户端的hashmap来缓存inode号和inodeinfo的对应关系，inodecache在客户端缓存inode号和inodeinfo的关系。当缓存的inode数量超过一定阈值，通过LRU来淘汰inode缓存数据。

CubeFS client 在open操作时，会调用getExtents接口获取分片信息，并更新本地extentcache。因为对于开启了缓存的文件，如果本地extentcache存在，则不需要从元数据节点更新文件的分片信息。同样的采用LRU来淘汰inode的extentcache。

dentryCache

dentry描述目录和文件的关系的数据结构。访问一个文件，需要通过文件名和父目录的inode号来确定文件的inode编号。CubeFS client虽然之前已经支持文件的dentry cache,但是每个dir维护一个dentry map,定时来淘汰。类似于kernel-fuse中的dentry cache，同样存在缓存失效性的问题。因此dentry-cache使用全局的hash来记录，key为父目录的inode和文件的filename，value为文件的inode号。和inodechae一样，当缓存的dentry数量超过一定阈值，通过LRU来淘汰dentry缓存数据。

03
数据加速

数据加速的目的将文件的数据分片缓存到本地磁盘，前面提到数据缓存blockcache是需要单独部署的服务。为什么不单独为CubeFS client提供一块缓存磁盘，主要是基于几个原因：

资源限制：AI混合云场景，每台GPU主机提供的缓存盘（云盘）只有1TB的空间，因此需要运行在这台宿主机的task pod共享缓存空间。

通用性：CubeFS在大数据存算分离的解决方案中，blockcache同样为大数据作业提供缓存加速，需要为调度到同一计算节点的计算单元 container 共享缓存。

因此将数据缓存模块blockcache设计成轻量级的服务模块,主要提供三方面的功能：缓存读写功能、缓存数据索引管理和缓存盘的空间管理。

索引管理

CubeFS中一个文件由分片extent组成。为了方便管理文件的缓存数据，按照一个完整的extent进行缓存。在blockcache中，一个extent分片key命名规则：卷名称_inode号_extentId_在文件中的逻辑起始偏移（volname_inode_extentid_fileoffset）来唯一标识一个extent。extent存放在缓存盘（本地文件系统）的位置信息，则通过hash规则计算出来。这样的好处是不需要额外的元数据管理服务，在内存中简单维护一个map来管理缓存文件的空间，无需持久化。


blockcache缓存数据布局

当服务重启后，blockcache会遍历缓存盘的文件，来重建缓存数据的索引结构。

数据管理

blockcache按文件的数据分片extent作为缓存单元，非整个文件。文件会切分成多个数据块存储在远端datanode，只缓存访问过的数据块。

blockcache-service提供三个接口：查询extent索引接口、删除extent缓存接口、写入extent数据。CubeFS client开启缓存后，client先通过索引查询接口查询extent在缓存盘的位置信息，如果命中，则直接通过文件接口读取数据。未命中则从datanode读取完整的extent数据，加密后，通过blockcache写入接口异步缓存到磁盘，在下一次读取文件时，就直接从本地读取。为了降低小文件读取的整体延迟，blockcache-client和blocache-service采用unix domain socket进程间通信来进行数据传输。

部署方式



数据加速模块（blockcache）采用damonset 方式部署在公有云GPU主机。缓存盘以hostpath的方式挂载到task-pod，blockcache-pod。

04
实际效果

通过单卡GPU测试RESNET18、RESNET50（非IO瓶颈）、AlexNet 模型在OPPO私有云、公有云未开启加速、公有云开启加速后性能测试对比。如下图所示：



通过图中的数据看出：在公有云GPU启动CubeFS 客户端加速后，RESNET18在Dataloader worker=1,16 性能分布提升360%，114%；AlexNet 在worker=16,24分别提升130%，80%；效果非常明显。相对于OPPO私有云GPU访问，也有12%-27%的提升，收益显著。

缓存命中率对于整体的性能有着非常重要的影响，虽然单个GPU主机的缓存盘容量有限，但受限与单机GPU卡数及CPU资源，同时运行的训练task数不多，缓存命中率基本稳定地保持在较高的水平。

05
展望

目前blockcache是计算侧的本地缓存，对于AI训练数据起到加速的作用虽然明显，但是受限于客户端缓存盘资源、不同客户端存在重复缓存数据集和多客户端数据不一致等问题。后续会推出CubeFS分布式缓存，进一步丰富混合云场景下的存储解决方案。

CubeFS简介
CubeFS于2019年开源并在SIGMOD发表工业界论文，目前是云原生计算基金会(CNCF)托管的孵化阶段开源项目。作为新一代云原生分布式存储平台，兼容S3、POSIX、HDFS等协议，支持多副本和纠删码引擎，提供多租户，多AZ部署、跨区域复制等特性；适用于大数据、AI、容器平台、数据库及中间件存算分离，数据共享、数据保护等广泛场景。

GitHub：https://github.com/cubefs
微信群：搜索并添加微信号blkleaf或mervinkid联系，注明您的来意
公众号：微信搜索“CubeFS官微”