概述

CubeFS(储宝文件系统)是为大规模容器平台设计的分布式文件系统。

整体架构

Architecture

CubeFS由 元数据子系统数据子系统资源管理节点 组成,可以通过 客户端 访问不同文件系统实例,

元数据子系统由元数据节点组成,每个节点可以管理一组 元数据分片

数据子系统分为副本子系统和纠删码子系统,两种子系统可同时存在,也都可单独存在

  • 副本子系统由数据节点组成,每个节点管理一组 数据分片,多个节点的 数据分片 构成副本组

  • 纠删码子系统由多个blobNode节点组成,每个节点管理一组 数据块,多个节点的 数据块 构成一组纠删码条带

在CubeFS中,卷是一个逻辑概念,由多个元数据和数据分片组成。 从客户端的角度看,卷可以被看作是可被容器访问的文件系统实例。 一个卷可以在多个容器中挂载,使得文件可以被不同客户端同时访问。 根据底层存储方式不同,卷分为副本卷和纠删码卷,如无特殊强调,卷就是副本卷的类型。 一个CubeFS集群可以有上百个卷,大小从几GB至几TB不等。

概括来说,资源管理节点定期获取元数据和数据子系统信息,客户端则定期从资源管理器拉取元数据和数据分片信息,并且进行缓存。通常来讲,文件操作由客户端发起,直接与数据和元数据节点通信,无需资源管理节点介入。

系统特性

可扩展元数据管理

元数据操作有时候会成为文件系统的性能瓶颈。在我们的平台中,由于可能会有成百上千的客户端同时访问文件,这个问题变得非常突出。单独节点存储元数据很容易成为性能瓶颈。所以,CubeFS中使用了分布式元数据子系统,以便提供高可扩展性。 元数据子系统可以认为是内存元数据存储。我们使用了两个B-Tree,inodeTree和dentryTree,来加快索引速度。每个元数据分片根据inode id范围进行划分。

通用存储引擎

为了降低存储成本,很多应用和服务都使用了共享的存储基础设施。不同负载交织在一起,文件大小可以从几KB至几百GB,读写模型从顺序到随机。一个成熟的文件系统应该可以高性能地服务于这些负载。CubeFS的存储引擎同时提供了对大文件和小文件的随机/顺序读写的支持。

强一致性的复制协议

出于性能考虑,CubeFS根据文件写入的方式的不同采用不同的复制协议来保障副本之间的一致性。

POSIX兼容

兼容POSIX接口,可以使得上层应用的开发变得简单,并且大大降低新用户的学习难度。同时,CubeFS在实现时放松了对POSIX语义的一致性要求来兼顾文件和元文件操作的性能。

对象存储

对象存储系统提供兼容S3的对象存储接口,可以使用户使用原生的Amazon S3 SDK操作CubeFS中的文件。它使得CubeFS成为一个可以将两种通用类型接口进行融合的存储(POSIX和S3兼容接口)。

纠删码存储

支持纠删码的数据存储方式,纠删码子系统具备高可靠、高可用、低成本、支持超大规模(EB)的特性(纠删码卷暂不支持修改写和覆盖写操作)

多级缓存加速

纠删码卷支持多级缓存加速能力,针对热点数据,提供更高数据访问性能

  • 本地缓存:可以在Client机器上同机部署BlockCache组件,管理本地磁盘作为本地缓存. 可以不经过网络读取本地Cache当中的数据, 容量受本地磁盘限制

  • 全局缓存:使用副本组件DataNode搭建的分布式全局Cache, 比如可以通过部署客户端同机房的SSD磁盘的DataNode作为全局cache, 相对于本地cache, 需要经过网络, 但是容量更大, 可动态扩缩容, 副本数可调

Architecture