Ceph /ˈsɛf/ 是一个新兴的开源分布式存储系统,现在支持块存储、文件存储、对象存储。本文尝试从high level总结它的一些设计特性。只是初学者,描述可能有很多地方错误、不完善,欢迎指出。
部件
Ceph有几个基础的部件:
- Object Storage Device (OSD): OSD指的就是存储设备,负责数据存储。不同于传统的块存储设备,OSD是以对象为单位(更高层)的存储设备。一个OSD有自己的CPU, NIC, disk, cache。后面也会提及如何使用OSD的计算能力。OSD以集群的形式存在。
- Metadata Server (MDS): MDS负责元数据的存储。不同于GFS、HDFS的元数据管理,因为管理的是对象数据,MDS只管理命名空间,不管理allocation list。数据的访问靠计算来获得位置。另外MDS也以集群的形式存在,没有单点故障问题。MDS集群上都是无缓存的同步操作。
- Monitor: Moniter是一个轻量的集群,用来对OSD的状态进行监控和管理。
- Clients: 就是Ceph的实例,访问的发起者。然后向外提供一个类POSIX接口。
Decoupled Data and Metadata 数据与元数据解耦
如上图所示,Ceph通过图中所示的访问方式来组织数据。每个文件被切分成小对象,每个对象通过简单的哈希来对应到一个PG (placement groups)上,每个PG通过CRUSH操作来映射到具体的OSDs上。
这部分核心的就是CRUSH[5],Controlled, scalable, decentralized placement of replicated data。CRUSH本质上就是一个伪随机的哈希函数,可以把PG对应到OSD上。这样就可以通过计算来获得数据的位置。CRUSH除了一些placement rules以外,通过只输入PG和OSD cluster map就可以输出OSD。通过rules可以指定选择OSD的一些策略,如副本数量、放置位置、特定OSD的权重等。
OSD cluster map指的是OSD在物理上的结构分层,如机柜列、rack、服务器、OSD,需要手动设定。比如新加入一个OSD,那么map就会迎来一次更新。
Dynamic Distributed Metadata Management 动态分布式元数据管理
Ceph的MDS只管理目录项和inode,负载相对传统的元数据管理要轻很多。传统系统上元数据访问负载超过50%。
元数据管理的核心部分是Dynamic Subtree Partitioning[6],MDS集群基于此进行组织,能在节点之间自适应地按层级,来组织目录层级的元数据。
每个MDS,维护一个指数衰退的计数器,当被访问时,自己包括对应的所有上级结点进行自增。这计数值就代表了MDS的热度权重。
热点的元数据会被分割到不同的MDS上,突发读访问的数据会被复制多份,从而实现负载均衡(牺牲了locality)。
另外有一些有关safety的细节,不赘述了。
Reliable Autonomic Distributed Object Storage 可靠自治的分布式对象存储
RADOS即OSDs与Monitor组成的系统。OSD自己负责对数据进行复制、迁移、错误探测和故障恢复等的工作。
Ceph是一个强一致性的系统,在每次写入来临时,向CRUSH映射得到的OSDs中的Primary进行写入,Primary向Replicas转发数据。Primary获得replicas的落盘ack后,再返回ack。落盘的commit也等待replicas后,primary自己落盘,再向client返回。 为保证一致性,每个读请求则落在primary上。
每个OSD通过维护一个版本号和对于每一个PG的最近操作的日志(更新或删除的对象的名与版本)。
primary OSD如果不响应,会先被置为down状态,请求全部转到第二个OSD上。如果还不恢复,就说明原来的primary挂了,一个新的OSD将替换加入到这个PG对应的OSDs中。受到影响的OSD,将更新自己的map,并分发map给其他OSD。【中间等待的方法可以过滤掉一些短时的问题,避免老是转移数据】
当某一个OSD收到一个新的OSD cluster map时,说明有新OSD加入或退出了。它会迭代每一个PG,再通过CRUSH算法计算出自己在这PG对应的OSDs中是不是primary。如果是,则开始接管primary的工作,收集副本的信息,进行更新。等到primary确定了正确状态,才开始响应请求。并行恢复,提高效率。
类似Raft的appendEnrties,OSDs利用心跳包互相检测如掉电等无法自检测的错误。Monitor集群用来统一提交错误信息。
OSD backend
前文提到,Ceph把存储抽象到对象层面。在对象背后,也就是OSD的存储后端上,这几年有很大的变化。
一开始用的是EBOFS[1]等文件系统,绕过了传统文件系统的一些缺点,能够直接和块设备交互。文件系统在元数据设计上和对象存储有类似的对应之处,同时也可以直接利用文件系统带来的缓存设计的便利。
但直接使用文件系统作为对象存储后端,也存在了很多缺点。如缺乏事务、check sum等能力,元数据的管理效率低。为了实现事务等支持,需要在用户态上实现WAL,进而又会引发读后写、写放大等问题。类似的,后来也使用了BTRFS、XFS等文件系统,但仍然受到文件系统这些弊端带来的影响。同时单一的文件系统也无法很好的兼容新型的存储器件。
接下来的NewStore使用了键值存储数据库(如LevelDB)来管理保存元数据。再通过多步映射的方法来找到在文件系统中保存的数据的位置。这样做减轻了元数据管理的压力,但因为保存数据的仍然是文件系统,仍然没有避免写放大等问题,然后LSM Tree的键值存储也有自己的写放大问题等。
目前使用率最高的BlueStore,不再使用文件系统来保存数据,将键值数据库下面的文件系统换为自己一个轻量的BlueFS。BlueFS为键值数据库提供Env相关接口。而在数据的保存上,则直接操作裸的块设备。
下图为BlueStore的数据流示意图。SST指LSM的SSTable。 BlueStore并不完美,抛弃了文件系统,就抛弃了前文提到的便利的缓存系统,在用户态上构建出一个类似效果的缓存系统存在很大挑战。然后就是键值数据库自身的一些问题。
Reference
[1] Weil, Sage A., et al. “Ceph: A scalable, high-performance distributed file system.” Proceedings of the 7th symposium on Operating systems design and implementation. 2006. (OSDI 2006)
[2] Aghayev, Abutalib, et al. “File systems unfit as distributed storage backends: lessons from 10 years of Ceph evolution.” Proceedings of the 27th ACM Symposium on Operating Systems Principles. 2019. (SOSP 2019)
[3] 李翔. Ceph分布式文件系统的研究及性能测试. Diss. 西安电子科技大学.
[5] Weil, Sage A., et al. “CRUSH: Controlled, scalable, decentralized placement of replicated data.” SC’06: Proceedings of the 2006 ACM/IEEE Conference on Supercomputing. IEEE, 2006. (SC 2006)
[6] Weil, Sage A., et al. “Dynamic metadata management for petabyte-scale file systems.” SC’04: Proceedings of the 2004 ACM/IEEE conference on Supercomputing. IEEE, 2004.(SC 2004)
注
看完File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution再来更新。 更新完毕
最近很久没更新文章,之前一直在学习MIT 6.824……