文档章节

解析Ceph: 存储引擎实现之一–FileStore

shadowalker911
 shadowalker911
发布于 2015/02/13 16:26
字数 1267
阅读 110
收藏 0

#程序员薪资揭榜#你做程序员几年了?月薪多少?发量还在么?>>>

解析Ceph: 存储引擎实现之一–FileStore

2014 年 01 月 11 日 上公布 作者为 麦子迈 文章分类 Ceph

Ceph作为一个高可用和强一致性的软件定义存储实现,去使用它非常重要的就是了解其内部的IO路径和存储实现。这篇文章主要介绍在IO路径中最底层的ObjectStore的实现之一FileStore。

Snip20140111_1

ObjectStore

ObjectStore是Ceph OSD中最重要的概念之一,它封装了所有对底层存储的IO操作。从上图中可以看到所有IO请求在Clieng端发出,在Message层统一解析后会被OSD层分发到各个PG,每个PG都拥有一个队列,一个线程池会对每个队列进行处理。

当一个在PG队列里的IO被提出后,该IO请求会被根据类型和相关附带参数进行处理。如果是读请求会通过ObjectStore提供的API获得相应的内容,如果是写请求也会利用ObjectStore提供的事务API将所有写操作组合成一个原子事务提交给ObjectStore。ObjectStore通过接口对上层提供不同的隔离级别,目前PG层只采用了Serializable级别,保证读写的顺序性。

ObjectStore主要接口分为三部分,第一部分是Object的读写操作,类似于POSIX的部分接口,第二部分是Object的属性(xattr)读写操作,这类操作的特征是kv对并且与某一个Object关联。第三部分是关联Object的kv操作(在Ceph中称为omap),这个其实与第二部分非常类似,但是在实现上可能会有所变化。

目前ObjectStore的主要实现是FileStore,也就是利用文件系统的POSIX接口实现ObjectStore API。每个Object在FileStore层会被看成是一个文件,Object的属性(xattr)会利用文件的xattr属性存取,因为有些文件系统(如Ext4)对xattr的长度有限制,因此超出长度的Metadata会被存储在DBObjectMap里。而Object的omap则直接利用DBObjectMap实现。因此,可以看出xattr和omap操作是互通的,在用户角度来说,前者可以看作是受限的长度,后者更宽泛(API没有对这些做出硬性要求)。

FileJournal

Snip20140111_3

为了缩小写事务的处理时间,提高写事务的处理能力并且实现事务的原子性,FileStore引入了FileJournal,所有写事务在被FileJournal处理以后都会立即返回(上图中的第二步)。FileJournal类似于数据库的writeahead日志,使用O_DIRECT和O_DSYNC每次同步写入到journal文件,完成后该事务会被塞到FileStore的op queue。事务通常有若干个写操作组成,当在中间过程进程crash时,journal会OSD recover提供了完备的输入。FileStore会存在多个thread从op queue里获取op,然后真正apply到文件系统上对应的Object(Buffer IO)。当FileStore将事务落到disk上之后,后续的该Object的读请求才会继续(上图中的第五步)。当FileStore完成一个op后,对应的Journal可以丢弃这部分日志。

实际上并不是所有的文件系统都按照这个顺序,一般来说如Ceph推荐的Ext4和XFS文件系统会先写入Journal,然后再写入Filesystem,而COW(Copy on Write)文件系统如Btrfs和ZFS会同时写入Journal和FileSystem。

DBObjectMap

Snip20140111_4

DBObjectMap是FileStore的一部分,利用KeyValue数据库实现了ObjectStore的第三部分API,DBObjectMap主要复杂在其实现了clone操作的no-copy。因为ObjectStore提供了clone API,提供对一个Object的完全clone(包括Object的属性和omap)。DBObjectMap对每一个Object有一个Header,每个Object联系的omap(kv pairs)对会与该Header联系,当clone时,会产生两个新的Header,原来的Header作为这两个新Header的parent,这时候无论是原来的Object还是cloned Object在查询或者写操作时都会查询parent的情况,并且实现copy-on-write。那么Header如何与omap(kv pairs)联系呢,首先每个Header有一个唯一的seq,然后所有属于该Header的omap的key里面都会包含该seq,因此,利用KeyValueDB的提供的有序prefix检索来实现对omap的遍历。

上面提到FileStore会将每个Object作为一个文件,那么Object的一些属性会与Object Name一起作为文件名,Object 所属的PG会作为文件目录,当一个PG内所包含的文件超过一定程度时(在目录内文件太多会造成文件系统的lookup性能损耗),PG会被分裂成两个PG。

本文转载自:http://www.wzxue.com/ceph-filestore/

shadowalker911
粉丝 6
博文 28
码字总数 3041
作品 0
徐汇
私信 提问
加载中

评论(0)

Ceph存储后端ObjectStore架构和技术演进

Ceph是分布式和强一致性的软件定义存储产品,随着越来越多的企业和组织不断加入,Ceph存储系统稳定性、可靠性和易管理性得到了很大的提升,在版本演进和迭代中,Ceph存储的企业特性也得到了完...

架构师技术联盟
2018/08/16
0
0
[ Ceph ] 分布式存储系统 Ceph 后端存储引擎说明

前言 在知乎看到一篇介绍 Ceph 后端存储引擎的文章 【分布式存储系统Ceph的后端系统引擎研究】分析的非常到位,对理解Ceph 后端存储引擎有非常大的帮助。 本篇主要围绕这篇文章来学习,并写出...

hukey
04/07
0
0
Ceph BlueStore与FileStore:利用Micron NVMe SSD进行性能比较

https://www.micron.com/about/blog/2018/may/ceph-bluestore-vs-filestoreblock-performance-comparison-when-leveraging-micron-nvme-ssds BlueStore是Ceph的新存储引擎,是社区版的默认配......

osc_2o4gyq0o
2019/08/16
2
0
[ ceph ] BlueStore 存储引擎介绍

为什么需要 BlueStore 首先,Ceph原本的FileStore需要兼容Linux下的各种文件系统,如EXT4、BtrFS、XFS。理论上每种文件系统都实现了POSIX协议,但事实上,每个文件系统都有一点“不那么标准”...

hukey
2019/11/22
0
0
Ceph Luminous版本DashBoard预览

今天来聊一聊Ceph新版本功能,Ceph会在今年秋季发布一个长期支持稳定版本Luminous(12.x.x),现在已经出RC版了,Luminous版本新增了很多功能,比如新增一个内置的Dashboard、底层的存储引擎...

Devin
2017/06/28
0
0

没有更多内容

加载失败,请刷新页面

加载更多

垃圾收集器与内存分配策略

对象已死? 垃圾标记算法 1.引用计数算法 C++智能指针、Python 2.可达性分析算法 JavaGC Roots的根对象作为起始节点,通过引用链到某个对象不可达时,证明此对象不可能再被使用。 强引用:...

LoSingSang
昨天
27
0
Python--从集合中随机取出一个元素

Python--从集合中随机取出一个元素 博客说明 文章所涉及的资料来自互联网整理和个人总结,意在于个人学习和经验汇总,如有什么地方侵权,请联系本人删除,谢谢! 说明 有时候有一个这样的需求...

归子莫
昨天
27
0
iptables-F 后 SSH 连接断开

最近回收利用一台被征用做邮件服务的服务器,重新部署新的业务。 清理了所有的安装软件和目录文件后,调整了网络安全组规则,仅开放所需端口。 看了下防火墙的配置: # iptables -LChain I...

DEPAKIN
昨天
27
0
IDEA通过Maven打包JavaFX工程(OpenJFX11)

1 概述 最近研究JFX,写出来了但是打包不了,这。。。尴尬。。。 IDEA的文档说只支持Java8打成jar包: 尝试过直接使用Maven插件的package,不行,也尝试过Build Artifacts,也不行,各种奇奇...

氷泠
昨天
19
0
《一天一模式》— 命令模式

一、命令模式的概念 将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。 二、什么时候使用命令模式 调用者与实现者通常是一种紧耦合的...

XuePeng77
昨天
13
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部