ceph

bluestore

直接管理裸设备,实现在用户态下使用linux aio直接对裸设备进行I/O操作


image.png

写IO流程:
一个I/O在bluestore里经历了多个线程和队列才最终完成,对于非WAL的写,比如对齐写、写到新的blob里等,I/O先写到块设备上,然后元数据提交到rocksdb并sync了,才返回客户端写完成(在STATE_KV_QUEUED状态的处理);对于WAL(即覆盖写),没有先把数据写块设备,而是将数据和元数据作为wal一起提交到rocksdb并sync后,这样就可以返回客户端写成功了,然后在后面的动作就是将wal里的数据再写到块设备的过程,对这个object的读请求要等到把数据写到块设备完成整个wal写I/O的流程后才行,代码里对应的是_do_read里先o->flush()的操作,所以bluestore里的wal就类似filestore里的journal的作用

bluestore 元数据

Bluestore的 所有的元数据都以KV对的形式写入RocksDB中,主要有以下的元数据:

// 保存BlueStore的超级块信息,在KV中, 以PREFIX_SUPER为Key的前缀 
const string PREFIX_SUPER = “S”; // field -> value
// 保存Collection的元数据信息bluestore_cnode_t 
const string PREFIX_COLL = “C”; // collection name -> cnode_t
// 保存对象的元数据信息 
const string PREFIX_OBJ = “O”; // object name -> onode_t

//需要主要的是,onode 和 enode的信息 都 以PREFIX_OBJ 为前缀,只是同一个对象的onode和 enode的信息的key不同来区分。

// 保存 overly 信息 
const string PREFIX_OVERLAY = “V”; // u64 + offset -> data

// 保存对象的omap 信息 
const string PREFIX_OMAP = “M”; // u64 + keyname -> value

// 保存 write ahead log 信息 
const string PREFIX_WAL = “L”; // id -> wal_transaction_t

// 保存块设备的空闲extent信息 
const string PREFIX_ALLOC = “B”; // u64 offset -> u64 length (freelist)
ceph bluefs

内存文件系统,mount的时候,通过扫码日志,在内存中还原出整个文件系统的状况

ceph 高级工具
  • ceph-bluestore-tool
ceph-bluestore-tool bluefs-export --path /var/lib/ceph/osd/ceph-0 --out-dir ./osd0
  • ceph-kvstore-tool
ceph-kvstore-tool bluestore-kv /var/lib/ceph/osd/ceph-0/ list > ceph.osd0.kvstore
ceph-kvstore-tool rocksdb /var/lib/ceph/mon/ceph-storage46/store.db/ list > mon.list
ceph-kvstore-tool bluestore-kv /var/lib/ceph/osd/ceph-0/ get C 1.11_head out tmp
  • ceph-objectstore-tool
ceph-objectstore-tool --op list-pgs --data-path /var/lib/ceph/osd/ceph-8/ --type bluestore
ceph-objectstore-tool --pgid 7.0 --op log --data-path /var/lib/ceph/osd/ceph-8/ --type bluestore > pglog.txt
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-8/ --type bluestore --pgid 17.3 hello.txt get-bytes
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-8/ --type bluestore hello.txt get-attr -
ceph crush算法
image.png
osd crush weight和 osd reweight区别

OSD上面数据相对不平衡时,我们应该使用ceph osd reweight 命令修改reweight值,而不应该使用ceph osd crush reweight 命令修改weight值。原因在于,修改reweight值将不会改变bucket的weight,而如果修改weight值就会改变整个bucket的weight。bucket weight 一旦改变,就会导致数据在bucket之间进行迁移,而不是在bucket内部进行迁移,这能最小化数据的转移量

ceph pg平衡工具
  • reweight
  • balancer
  • upmap+osdmap
    http://www.strugglesquirrel.com/2019/05/22/超实用的pg均衡工具upmap/
操作rados
import rados
import sys

cluster = rados.Rados(conffile='/etc/ceph/ceph.conf')
print "\nlibrados version: " + str(cluster.version())
print "Will attempt to connect to: " + str(cluster.conf_get('mon initial members'))

cluster.connect()

print "\nCluster ID: " + cluster.get_fsid()

print "\n\nCluster Statistics"
print "=================="
cluster_stats = cluster.get_cluster_stats()

for key, value in cluster_stats.iteritems():
    print key, value

ioctx = cluster.open_ioctx('mypool')
ioctx.aio_write("name","liu",offset=0)
ioctx.aio_write("name","liu",offset=1024)
ioctx.aio_flush()
参考

ceph bluestore非对齐写入策略
https://blog.csdn.net/Z_Stand/article/details/99654729

ceph 读流程

从Primary OSD中读取(offset,length)指定部分的内容即可,不牵扯到多个OSD之间的交互


image.png

ceph 写流程

写流程之所以比读流程复杂源于多个方面

  • 牵扯多个OSD的写入,如何确保多副本之间一致性 (PGLog)
  • 对于单个OSD的写入,如何确保最终的一致性 (Journal and FileStore)
  • 多个副本所在的OSD,状态可能不是active + clean


    image.png

Filestore

FileStore包含FileJournal和DBObjectMap两个模块,FileStore为了提高ObjectStore写事务处理能力和原子性引入了FileJournal。它相当于数据库的WAL(write ahead log),为了保证每个写事务的完整性。它会使用direct io方式写到journal日志里,完成后再将事务提交到FileStore的队列中继续完成写操作,如果中途有发生crash,OSD在做recovery的时候会将日志恢复出来。

FileStore写数据顺序是,先写journal然后再写盘上。Journal写完后会返回给上层,但是要能read ready还是要等到数据落盘后才行,不过在大量小io随机写场景性能还是不错。FileStore由于先写日志再写盘,所以有个写放大的问题。

DBObjectMap是专门用来管理对象的属性的模块,有两种实现xattr和omap。xattr是用文件系统的扩展属性实现的,受限于文件系统扩展属性的长度限制,适合小量数据存放。omap是采用leveldb k-v键值存储实现,如果属性大小超过xattr的限制,则可以存放到omap中

你可能感兴趣的:(ceph)