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中