【ceph】后端存储ObjectStore|BlueStore
目录
ObjectStore简介
CEPH OBJECTSTORE API介绍
ObjectStore API
操作
事务
日志
实现
ObjectStore 实现
FileStore
KeyValueStore
MemStore
怎样加入新的ObjectStore
一个粗略的指南告诉你从哪里開始:
Newstore(BlueStore)存储引擎的出现
ObjectStore简介
object store是Ceph OSD的一部分,它完毕实际的数据存储。当前有三种不同的object store可用:
- FileStore: 文件系统+日志后备的存储
- KeyValueStore: 基于KV数据库(如:RocksDB、 LevelDB、memdb等)
- MemStore: 以内存作为存储(译注:全部数据全部位于内存中的STL::Map或者bufferlist)
- BlueStore,或称NewStore
相关文档
- Ceph Performance: Interesting Things Going On
- Object Store Architecture Overview
代码
object store源代码位于Ceph源代码文件夹下的os子文件夹。为方便:ceph github repository。以下的描写叙述基于Ceph commit-ish 6f8b54c from 2015-01-13。
OSD存储引擎实现;Ceph基础组件RADOS是强一致、对象存储系统,其OSD底层支持的存储引擎如下图所示:
图:https://www.cnblogs.com/wuhuiyuan/p/ceph-newstore-intro.html
其中,ObjectStore层封装了下层存储引擎的所有IO操作,向上层提供对象(object)、事务(Transaction)语义的接口,MemStore为基于内存的实现;KeyValueStore主要基于KV数据库(如leveldb, rocksdb等)实现接口功能,事务实现也基于KV数据库自身;FileStore是Ceph目前默认的存储引擎(也是目前使用最多的存储引擎),其事务实现基于Journal机制(Journal文件或块设备);除了支持事务特性(consistency、atomic等)外,Journal还可将多个小IO写合并为顺序写Journal,以提升性能。
CEPH OBJECTSTORE API介绍
本文由 Ceph中国社区-Thomas翻译,陈晓熹校稿 。
英文出处:THE CEPH OBJECTSTORE API 欢迎加入 翻译小组
ObjectStore API
抽象类ObjectStore
是OSD实现存储訪问的主要API。
这是一套类文件系统API。可是囊括了将状态转化为事务的操作。存储的是对象,而不是文件。
一个对象包括:
- 字节数据 - 相似于文件系统中的文件内容
- 扩展属性 - 相似于文件系统中文件的扩展属性。是键值对集合。
- omap - 在概念上与扩展属性相似,但有着不同的地址空间大小及訪问模式。
一个对象由下述两个id标示:
- 集合id -
coll_t
cid(一个集合就是一组对象) - 对象id -
ghobject_t
oid
操作
以下不是一个完整的列表;仅仅是给你一个印象。注意:有些操作仅仅对事务可用。
事务操作:以事务作为參数
apply_transaction
queue_transactions
常规文件系统操作:
mount
umount
mkfs
mkjournal
statfs
need_journal
sync
flush
snapshot
对象操作:以coll_t cid
和ghobject_t oid
为參数
exists
stat
read
fiemap
getattr
getattrs
集合操作:以coll_t cid
为參数
collection_getattr
collection_empty
collection_list
list_collections
collection_exists
collections_getattrs
Omap操作:
omap_get
omap_get_header
omap_get_keys
omap_get_values
omap_check_keys
延伸阅读
- ObjectStore.h - 凝视部分
事务
定义:事务是原始的变更操作序列。类定义ObjectStore::Transaction。
支持的操作(摘自ObjectStore.h):
class Transaction {public:enum {OP_NOP = 0,OP_TOUCH = 9, // cid, oidOP_WRITE = 10, // cid, oid, offset, len, blOP_ZERO = 11, // cid, oid, offset, lenOP_TRUNCATE = 12, // cid, oid, lenOP_REMOVE = 13, // cid, oidOP_SETATTR = 14, // cid, oid, attrname, blOP_SETATTRS = 15, // cid, oid, attrsetOP_RMATTR = 16, // cid, oid, attrnameOP_CLONE = 17, // cid, oid, newoidOP_CLONERANGE = 18, // cid, oid, newoid, offset, lenOP_CLONERANGE2 = 30, // cid, oid, newoid, srcoff, len, dstoffOP_TRIMCACHE = 19, // cid, oid, offset, len **DEPRECATED**OP_MKCOLL = 20, // cidOP_RMCOLL = 21, // cidOP_COLL_ADD = 22, // cid, oldcid, oidOP_COLL_REMOVE = 23, // cid, oidOP_COLL_SETATTR = 24, // cid, attrname, blOP_COLL_RMATTR = 25, // cid, attrnameOP_COLL_SETATTRS = 26, // cid, attrsetOP_COLL_MOVE = 8, // newcid, oldcid, oidOP_STARTSYNC = 27, // start a syncOP_RMATTRS = 28, // cid, oidOP_COLL_RENAME = 29, // cid, newcidOP_OMAP_CLEAR = 31, // cidOP_OMAP_SETKEYS = 32, // cid, attrsetOP_OMAP_RMKEYS = 33, // cid, keysetOP_OMAP_SETHEADER = 34, // cid, headerOP_SPLIT_COLLECTION = 35, // cid, bits, destinationOP_SPLIT_COLLECTION2 = 36, /* cid, bits, destinationdoesn't create the destination */OP_OMAP_RMKEYRANGE = 37, // cid, oid, firstkey, lastkeyOP_COLL_MOVE_RENAME = 38, // oldcid, oldoid, newcid, newoidOP_SETALLOCHINT = 39, // cid, oid, object_size, write_sizeOP_COLL_HINT = 40, // cid, type, bl};// ...
}
每个操作都在事务类中有一个相应的函数实现(如 OP_ZERO:zero(cid, oid off, len)
)
一个事务能够有例如以下三个回调:
on_applied
on_commit
on_applied_sync
ObjectStore::Transaction
对象主要用来发送来自OSD的操作序列。比如,OSD:mkfs
运行下述操作来初始化meta集合:
ObjectStore::Transaction t;
t.create_collection(META_COLL);
t.write(META_COLL, OSD_SUPERBLOCK_POBJECT, 0, bl.length(), bl);
ret = store->apply_transaction(t);
ObjectStore::Transaction
类还能从Buffer中反序列出操作序列(注:即从字节流重建Transcation对象)。日志重做机制就是使用这样的方式来重做事务(注:从日志中读取字节流重建出Transcation对象,再Apply这个对象)。
日志
日志对故障恢复非常重要。
基类ObjectStore
没有实现日志功能。在子类JournalingObjectStore
中加入了日志能力。
JournalingObjectStore
中加入了例如以下方法:
- journal_start
- journal_stop
- journal_write_close
- journal_replay
更要的是:
- _op_journal_transactions - 加入事务到日志
- do_transactions - 应用日志的纯虚函数.
mount
过程中的replay_journal
中有一个调用样例。
实现
当前仅仅有一个Journal
实现:
ObjectStore 实现
FileStore
因为KeyValueStore
还处于实验阶段。而MemStore
很多其它的还是一种參考/demo实现,FileStore
成为眼下使用最广的一种实现。
FileStore
实现了JournalingObjectStore
类。相应地也就实现了ObjectStore
类。该类既实现了ObjectStore::Transaction
中的操作也实现了其它成员操作。
事务操作在_do_transaction
中实现并分发给_$OPERATION
方法完毕详细的工作。因为每个文件系统的特性不同,有些操作及特性检查方法被提取出来放到了抽象类FileStoreBackend
中。一个与文件系统代码相关的特殊操作是:fiemap
。
关于fiemap
fiemap同意你訪问文件的扩展数据。基本上,你请求Linux系统将指向文件数据区的索引返回给你。这对稀疏文件非常实用。Ceph FileStore在FileStore::_do_sparse_copy_range
中使用了它。
延伸阅读:
- LWN: Fiemap, an extend mapping ioctl
- GNU Coreutils copy implementation
FileStore后端
FileStore后端将大部分与文件系统相关的优化和生僻特性从FileStore的实现中抽象剥离。
假设底层的文件系统支持检查点,FileStore后备将使用文件系统的快照特性实现检查点。它还会运行特征检查,如检測是否支持fiemap。
全部的详细类都继承至共同的基类GenericFileStoreBackend
。
特定文件系统的支持情况:
- ZFS - 用ZFS快照实现检查点
- XFS - 通过
set_alloc_hint
设置XFS扩展大小 - Btrfs - 用Btrfs快照实现检查点。用COW实现高效的文件克隆
KeyValueStore
KeyValueStore
是ObjectStore
的一个适配类同一时候是KeyValueDB
的一个详细子类。
KeyValueDB
是KV数据库的一个通用接口类,在Ceph代码的其它地方也实用到它。适配器中最大的一部分操作是将使用集合id及对象id的类文件系统操作映射为扁平的KV接口。KV数据库中的键值不是通常的随意大小。因此。KV映射及键值的条带化都须要类StripObjectMap
来完毕。它是KeyValueStore
的一部分。
对象映射
GenericObjectMap
是ghobject_t
、coll_t
到KV映射器的公共基类。它有点相似于KeyValueDB
API,但并没有实现它。而是採用KeyValueDB
代理实现。
StripObjectMap
StripObjectMap
是KeyValueStore
源代码的一部分而且实现了GenericObjectMap
。它加入了条带和缓存功能。默认条带大小为4096字节(可配置)。
数据库后端
kinetic 希捷kinetic客户端github repository
leveldb Google LevelDB
rocksdb Facebook RocksDB
MemStore
MemStore将一切都存储在内存。在mount/umount时支持转储和恢复。为便于对象和组查找,它环绕着C++对象及哈希表来构建。
与它的实现相关的第一条提交记录是对ObjectStore 1的一种參数实现。该实现仍然是1,537 SLOC.
怎样加入新的ObjectStore
因为已经有处理文件系统和KV数据库的代码。写一个全新的ObjectStore不总是有必要。
一个粗略的指南告诉你从哪里開始:
想支持的是何种后端?
- KV数据库: 从
KeyValueDB
的一个实现開始(注:參考LevelDBStore.cc/h 和 RocksDBStore.cc/h) - 文件系统:
- 看下
FileStoreBackend
中的detect_features
方法。文件系统是否须要特殊处理? - 是否支持快照?假设是,參考
BtrfsFileStoreBackend
、ZFSFileStoreBackend
- 看下
- 全然不一样的实现?看看
MemStore
(注:以了解须要实现哪些方法,以及这些方法最简单的的原型实现)。
Newstore(BlueStore)存储引擎的出现
FileStore最初只是针对机械盘进行设计的,并没有对固态硬盘的情况进行优化,而且写数据之前先写journal也带来了一倍的写放大。为了解决FileStore存在的问题,Ceph推出了BlueStore。BlueStore去掉了journal,通过直接管理裸设备的方式来减少文件系统的部分开销,并且也对固态硬盘进行了单独的优化。BlueStore架构如下图所示。
原文链接:https://blog.csdn.net/cyq6239075/article/details/107429211
在社区使用过程中,FileStore也暴露了若干问题:
(1)Journal机制使一次写请求在OSD端变为两次写操作(同步写Journal,异步写入object);
(2)对前一个问题,社区通常做法是使用专门设备(如SSD)用作Journal以解耦Journal和object写操作的相互影响,但持续循环写入Journal会降低SSD设备的使用寿命;
(3)写入的每个object都一一对应OSD本地文件系统的一个物理文件,对于大量小object存储场景,OSD端无法缓存本地所有文件的inode等元数据,使读写操作可能需要多次本地IO,系统性能差;
(4)object对应的本地物理文件的文件名,包含了object name、rados namespaces、object name hash、snapshot等信息,可能会超过本地文件系统对文件名长度的限制。
面对上述问题,新的存储引擎NewStore(又被称为KeyFileStore)出现,其关键数据结构如下图所示:
其主要特点有:
(1)解耦object与本地物理文件间的一一对应关系,通过索引结构(上图中ONode)在object和本地物理文件建立映射关系,并使用KV数据库存储索引数据;
(2)在保证事务特性的同时,对于object的create/append/overwrite(fragement aligned)操作,无需Journal支持;(3)对于unaligned update操作,先同步写入write-ahead-log(简称为WAL,使用KV存储),再异步写入相应的fragement文件;
(4)在KV数据库上层建立Onode数据cache以加速读取操作;
(5)单个object可以有多个fragement文件,多个object也可共存于一个fragement文件;
FileStore的上述问题,在NewStore结构中已基本解决;
NewStore还采用以下策略来减小WAL的性能开销:
(1)在update写入fragement文件后,立即将相应WAL从KVdb中删除(WAL已完成使命,无需保存);
(2)增大KVdb的write buffer,尽量将WAL保留在buffer中,避免不必要的dump;
(3)在write buffer数据dump到磁盘前,强制合并多个buffer数据,以避免不必要的dump。在初步的随机读写测试中,NewStore相对于FileStore有60%的性能提升;
本博客的上篇博文《海量小文件存储与Ceph实践》从元数据管理、本地存储引擎两个方面对海量小文件存储问题进行了分析描述,并通过object class接口层对FileStore存储结构做了改进优化,虽不如NewStore彻底,但也在很大程度上优化了小文件存储性能;NewStore则直接在存储引擎层进行重新设计实现,解耦object与本地物理文件间的对应关系,并允许多个object共存于一个fragement文件;但二者对小文件本地存储引擎优化的本质思想是相通的,即合并存储+索引;不过目前NewStore还在密集开发阶段,到线上部署还需要一段时间;相信以后随着NewStore引擎的逐步部署与成熟,海量小文件存储难题也不再是难题。
另外,基于object class接口层的改进优化方案相关代码实现已放到github,欢迎测试使用及批评指正。
参考:
图片和相关内容摘自2015年6月份Beijing Ceph Day《Newstore》讲稿
http://thread.gmane.org/gmane.comp.file-systems.ceph.devel/23414/focus=23417
http://docs.ceph.com/docs/master/rados/configuration/journal-ref/
http://www.sebastien-han.fr/blog/2014/02/17/ceph-io-patterns-the-bad/
http://tracker.ceph.com/projects/ceph/wiki/Optimize_Newstore_for_massive_small_object_storage
http://www.cnblogs.com/wuhuiyuan/p/ceph-small-file-compound-storage.html
http://www.wzxue.com/ceph-filestore/
http://www.wzxue.com/ceph-keyvaluestore/
https://github.com/yxgup/ceph/tree/omap_indexed_compound
------------------------------------
http://www.cnblogs.com/wuhuiyuan/p/4907984.html
- https://github.com/ceph/ceph/commit/aa63d6730a638591b0699c4215ed5cce2917d1c9↩
《大咖带你揭秘CEPH对象存储底层对象分布》 https://www.talkwithtrend.com/Article/242647
【ceph】后端存储ObjectStore|BlueStore相关推荐
- ceph查看卷_基于CEPH后端存储搭建Harbor
上一篇文章基于NFS后端存储搭建Harbor ,这一节来聊聊K8s与CEPH的对接以及基于CEPH Harbor的构建. 因为资源的问题,测试环境仍然是K8s的ALL-IN-ONE环境,CEPH集群通 ...
- Ceph学习笔记2-在Kolla-Ansible中使用Ceph后端存储
环境说明 使用 Kolla-Ansible 请参考<使用 Kolla-Ansible 在 CentOS 7 单节点上部署 OpenStack Pike >: 部署 Ceph 服务请参考&l ...
- ceph存储引擎bluestore解析
原文链接:http://www.sysnote.org/2016/08/19/ceph-bluestore/ ceph后端支持多种存储引擎,以插件式的方式来进行管理使用,目前支持filestore,k ...
- ceph存储原理_Ceph存储引擎BlueStore简析
前文我们创建了一个单节点的Ceph集群,并且创建了2个基于BlueStore的OSD.同时,为了便于学习,这两个OSD分别基于不同的布局,也就是一个OSD是基于3中不同的存储介质(这里是模拟的,并非真 ...
- 【转载】ceph作为OpenStack的后端存储解决方案
Piston Cloud Computing公司介绍 Piston Cloud Computing,inc 是一间建立于2011年的软件公司.主要创始人原来都是OpenStack的创建者,包括前NAS ...
- cinder与ceph的区别_配置cinder-volume服务使用ceph作为后端存储
在ceph监视器上执行 CINDER_PASSWD='cinder1234!' controllerHost='controller' RABBIT_PASSWD='0penstackRMQ' 1.创 ...
- K8S使用Ceph RBD作为后端存储
一.准备工作 Ceph版本:v13.2.5 mimic稳定版 1.Ceph上准备存储池 [root@ceph-node1 ceph]# ceph osd pool create k8s 128 128 ...
- Ceph分层存储分析
最近弄Ceph集群考虑要不要加入分层存储 因此花了点时间研究了下 1,首先肯定要弄清Ceph分层存储的结构 ,结构图大概就是下图所示 缓存层(A cache tier)为Ceph客户端提供更好的I/O ...
- 后端存储课程笔记(大量实战经验)
课程内容: 极客时间-后端存储 第一章: 电商系统: 幂等性,工作中也多次见到其实现了.一个幂等操作的特点是,其任意多次执行所产生的影响均与一次执行的影响相同 在电商系统中,防止重复下单如何解决: 因 ...
最新文章
- R语言编写自定义函数基于ggsumarystats函数计算每个分组的统计值、自定义可视化分组分面条形图,并在X轴标签下方添加分组对应的统计值(样本数N、中位数median、四分位数的间距iqr)
- python中的__str__ __name__ 和__call__方法
- DevStack安装问题,git clone noVNC.git失败
- 教你简单理解分布式与传统单体架构的区别
- 开源软件free download manager在windows defender中报毒
- 图两点间的最短路径,所有路径算法C语言实现
- c swap方法在哪个库里面_覆膜条件下土壤水热动态与玉米种子生长的SWAP修正模型...
- CCF201512-5 矩阵【矩阵快速幂】(募集解题代码)
- 真深复制python_Python深复制浅复制or深拷贝浅拷贝
- Wingdings特殊字符及符号对照表
- 数据资产管理及数据管控体系建设思路
- 打开u盘显示参数错误
- 中文汉字转拼音首字母大写
- CIO谈:基于K2 BPM平台怎么做报销?
- 免费领百度网盘会员,12月31日截止
- Qt5.9/C++架构实例(一个简单的MCV架构应用实例)
- 【Elasticsearch】利用kibana调整索引mapping结构
- 20个经典的Java应用
- 方案系列--多个应用同时接入Google和Facebook三方登陆互联互通解决方案
- Office文档在线编辑和预览服务搭建