内容简介：Ceph从Luminous开始，默认使用了全新的存储引擎BlueStore，来替代之前提供存储服务的FileStore，与FileStore不一样的是，BlueStore直接管理裸盘，分配数据块来存储RADOS里的objects。Bluestore比较复杂，学习BlueStore的关键就是查看其实现的 ”object → block device“ 映射，所以本文先重点分析下该部分：一个Object写到Bluestore的处理过程。下面借用
Ceph从Luminous开始，默认使用了全新的存储引擎BlueStore，来替代之前提供存储服务的FileStore，与FileStore不一样的是，BlueStore直接管理裸盘，分配数据块来存储RADOS里的objects。
Bluestore比较复杂，学习BlueStore的关键就是查看其实现的 ”object → block device“ 映射，所以本文先重点分析下该部分：一个Object写到Bluestore的处理过程。
Bluestore整体架构
下面借用 Sage Weil 的图描述下BlueStore的整体架构：
里面的几个关键组件介绍：
- RocksDB：存储元数据信息
- BlueRocksEnv：提供RocksDB的访问接口
- BlueFS：实现BlueRocksEnv里的访问接口
- Allocator：磁盘分配器
针对BlueStore的整体架构不做展开，大家只需对其几大组件有些了解即可，本文继续介绍Object写操作到底层BlockDevice的过程。
BlueStore中Object到底层Device的映射关系
这里先从整体上给出在BlueStore中，一个Object的数据映射到底层BlockDevice的实现，如下图：
首先详细介绍下与上诉映射关系相关的数据结构。
Bluestore相关数据结构
BlueStore里与Object 数据映射相关的数据结构罗列如下：
Onode
任何RADOS里的一个Object都对应Bluestore里的一个Onode（内存结构），定义如下：
struct Onode {
Collection *c; // 对应的Collection，对应PG
ghobject_t oid; // Object信息
bluestore_onode_t onode; // Object存到kv DB的元数据信息
ExtentMap extent_map; // 映射lextents到blobs
};
通过Onode里的ExtentMap来查询Object数据到底层的映射。
ExtentMap
ExtentMap 是 Extent 的set集合，是有序的，定义如下：
struct ExtentMap {
Onode *onode; // 指向Onode指针
extent_map_t extent_map; // Extents到Blobs的map
blob_map_t spanning_blob_map; // 跨越shards的blobs
struct Shard {
bluestore_onode_t::shard_info *shard_info = nullptr;
unsigned extents = 0; ///< count extents in this shard
bool loaded = false; ///< true if shard is loaded
bool dirty = false; ///< true if shard is dirty and needs reencoding
};
mempool::bluestore_cache_other::vector<Shard> shards; ///< shards
};
ExtentMap还提供了分片功能，防止在文件碎片化严重，ExtentMap很大时，影响写RocksDB的性能。
ExtentMap 会随着写入数据的变化而变化；
ExtentMap 的连续小段会合并为大；
覆盖写也会导致 ExtentMap 分配新的Blob；
Extent
Extent是实现object的数据映射的关键数据结构，定义如下：
struct Extent : public ExtentBase {
uint32_t logical_offset = 0; // 对应Object的逻辑偏移
uint32_t blob_offset = 0; // 对应Blob上的偏移
uint32_t length = 0; // 数据段长度
BlobRef blob; // 指向对应Blob的指针
};
每个Extent都会映射到下一层的Blob上，Extent会依据 block_size 对齐，没写的地方填充全零。
Extent中的 length 值，最小：block_size，最大：max_blob_size
Blob
Blob是Bluestore里引入的处理块设备数据映射的中间层，定义如下：
struct Blob {
int16_t id = -1;
SharedBlobRef shared_blob; // 共享的blob状态
mutable bluestore_blob_t blob; // blob的元数据
};
struct bluestore_blob_t {
PExtentVector extents; // 对应磁盘上的一组数据段
uint32_t logical_length = 0; // blob的原始数据长度
uint32_t compressed_length = 0; // 压缩的数据长度
};
每个Blob会对应一组 PExtentVector，它就是 bluestore_pextent_t 的一个数组，指向从Disk中分配的物理空间。
Blob里可能对应一个磁盘pextent，也可能对应多个pextent；
Blob里的pextent个数最多为：max_blob_size / min_alloc_size；
Blob里的多个pextent映射的Blob offset可能不连续，中间有空洞；
AllocExtent
AllocExtent是管理物理磁盘上的数据段的，定义如下：
struct bluestore_pextent_t : public AllocExtent {
...
};
class AllocExtent {
public:
uint64_t offset; // 磁盘上的物理偏移
uint32_t length; // 数据段的长度
...
};
AllocExtent的 length 值，最小：min_alloc_size，最大：max_blob_size
BlueStore写数据流程
BlueStore里的写数据入口是 BlueStore::_do_write() ，它会根据 min_alloc_size 来切分 [offset, length] 的写，然后分别依据 small write 和 big write 来处理，如下：
// 按照min_alloc_size大小切分，把写数据映射到不同的块上
[offset, length]
|==p1==|=======p2=======|=p3=|
|----------------|----------------|----------------|
| min_alloc_size | min_alloc_size | min_alloc_size |
|----------------|----------------|----------------|
small write: p1, p3
big write: p2
BlueStore::_do_write()
|-- BlueStore::_do_write_data()
| // 依据`min_alloc_size`把写切分为`small/big`写
| | -- BlueStore::_do_write_small()
| | | -- BlueStore::ExtentMap::seek_lextent()
| | | -- BlueStore::Blob::can_reuse_blob()
| | reuse blob? or new blob?
| | | -- insert to struct WriteContext {};
| | -- BlueStore::_do_write_big()
| | | -- BlueStore::ExtentMap::punch_hole()
| | | -- BlueStore::Blob::can_reuse_blob()
| | reuse blob? or new blob?
| | | -- insert to struct WriteContext {};
|-- BlueStore::_do_alloc_write()
| | -- StupidAllocator::allocate()
| | -- BlueStore::ExtentMap::set_lextent()
| | -- BlueStore::_buffer_cache_write()
|-- BlueStore::_wctx_finish()
BlueStore Log分析
可以通过开启Ceph bluestore debug来抓取其写过程中对数据的映射，具体步骤如下。
下面通过在CephFS上测试为例：
1. 创建一个文件 # touch tstfile 2. 查看该文件的inode numer # ls -i 2199023255554 tstfile 3. 获取该文件的映射信息 上诉inode number转换为16进制：20000000002 查看文件的第一个默认4M Object的映射信息 # ceph osd map cephfs_data_ssd 20000000002.00000000 osdmap e2649 pool 'cephfs_data_ssd' (3) object '20000000002.00000000' -> pg 3.3ff3fe94 (3.94) -> up ([12,0], p12) acting ([12,0], p12) 4. 在osd 12上开启bluestroe debug信息 # ceph daemon /var/run/ceph/ceph-osd.12.asok config set debug_bluestore "30" // 开启debug # ceph daemon /var/run/ceph/ceph-osd.12.asok config set debug_bluestore "1/5" // 恢复默认 5. 对测试文件的前4M内进行dd操作，收集log # dd if=/dev/zero of=tstfile bs=4k count=1 oflag=direct # grep -v "trim shard target" /var/log/ceph/ceph-osd.12.log | grep -v "collection_list" > bluestore-write-0-4k.log
通过上述方式可以搜集到Bluestore在写入数据时，object的数据分配和映射过程，可以帮助理解其实现。
BlueStore dd write各种case
为了更好的理解BlueStore里一个write的过程，我们通过 dd 命令写一个Object，然后抓取log后分析不同情况下的Object数据块映射情况，最后结果如下图所示：
注释：上图的数据块映射关系是通过抓取log后获取的。
最后一图中，写[100k, 200)的区域，查看Object对应的ExtentMap并不是与 min_alloc_size（16k）对齐的，只是保证是block_size（4k）对齐而已。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Usability for the Web
Tom Brinck、Darren Gergle、Scott D. Wood / Morgan Kaufmann / 2001-10-15 / USD 65.95
Every stage in the design of a new web site is an opportunity to meet or miss deadlines and budgetary goals. Every stage is an opportunity to boost or undercut the site's usability. Thi......一起来看看 《Usability for the Web》 这本书的介绍吧!
