分布式文件系统Ceph

分布式文件系统Ceph

原论文链接：File Systems Unfit as Distributed Storage Backends:
Lessons from 10 Years of Ceph Evolution

1. 摘要

在过去10年，Ceph分布式文件系统基于机器本地的文件系统之上实现。由于用于机器本地使用的文件系统(比如NTFS、ext、Fat)技术相对比较成熟，因此在这些文件系统的基础之上实现分布式的文件系统更加方便。但是这可能会带来如下三个问题：

• 开发一个零负担(zero-overhead)的事务机制(transaction mechanism)是困难的；
• 本地操作元数据(metadata)的性能会极大地影响分布式环境下的性能；
• 对新的存储硬件的支持较为缓慢

Ceph 使用BlueStore解决这些问题，与常规的方式不同，BlueStore是直接操作硬件的，而不是建立在机器的本地文件系统之上的。BlueStore具有如下的优势：

• 空间占用较低的元数据(metadata，元数据包含文件的访问权限、文件块等信息)；
• 数据校验(data checksums)；
• 纠删码(erasure code，一种数据冗余保护技术，能够提供近似三个副本的可靠性)保护的数据的快速覆盖写(overwrite)；
• 内联压缩(inline compression，相比于数据的原始格式占用更少的存储空间，是数据库中数据压缩的一种方式)；
• 避免了本地文件系统的一些缺陷；
• 使得支持后向不兼容的存储硬件成为可能；

2. 简介

分布式文件系统运行在一个机器集群上，每个机器都负责一个或者多个功能，包括集群状态监测服务器、元数据(metadata)服务器、存储服务器。传统的分布式文件系统使用机器的本地文件系统，如ext4、XFS作为存储后端(storage backend)。采用这种方式的好处是技术比较成熟，并且可以兼容本地的linux工具操作文件。但是采用这种方式，包含本地文件系统以及操作系统，有较大的运行开销。此外，本地文件系统元数据的操作性能会极大地影响分布式文件系统的性能。一个较为具体的问题就是，如何快速地遍历目录下上百万的文件条目并返回有序的结果。

Ceph项目在2015年开始设计实现BlueStore，直接操作底层硬件，并且将文件的元数据(metadata)存储在K-V数据库中。
BlueStore有如下特征：

• 存储文件系统底层的元数据，比如扩展的位示图(bitmap)，元数据存储在K-V数据库中，避免了存放在存储设备上格式的改变；
• 优化的clone操作(copy on write，写时复制技术，即只有当要写目标的时候才会复制)以及扩展的引用技术的优化；
• BlueFS使得RocksDB能够在存储设备上运行的更快；
• 一个存储空间分配器，管理1TB的磁盘占用35MB的内存

存储后端程序支持事务(transaction)机制能够简化分布式文件系统中保证强一致性的实现。但是，目前按照POSIX标准的文件系统尚不支持事务机制。因此，目前分布式文件系统的典型做法是在文件系统之上使用Write-Ahead Log(WAL)或者使用文件系统内部的事务机制。但是这种方式不是十分高效，并且比较复杂。

文件元数据的管理是分布式文件系统中另外一个比较难处理的问题。本地文件系统处理目录中包含大量文件以及小文件的性能会影响分布式文件系统整体的性能。为了解决这个问题，分布式文件系统使用元数据缓存(metadata caching)、由数据哈希组织的深层层级目录、个性化的数据库以及对本地文件系统打补丁。

3. Ceph分布式文件系统架构

上图是Ceph上层架构，处于核心部位的是RADOS(Reliable Autonomic Distributed Object Store)服务，包含数千个对象存储服务(Object Storage Devices, OSDs)，提供自组织、自修复的对象存储，并且提供强一致性。librados库提供操作对象以及RAD