BlueStore 介绍

ceph 目前是开源社区比较流行的分布式块存储系统,其以良好的架构,稳定性和完善的数据服务功能,获得的了广泛的部署和应用。

目前ceph 最大的问题是其性能相对较差,特别是无法发挥SSD等高速设备的硬件的性能。 Ceph 开源社区一直在优化ceph的性能问题。 目前的结果就是引入了新的object store,这就是最进合并入ceph master的BlueStore.

Bluestore的架构

这里写图片描述

如上图所示 :

BlueStore整体架构分为四个部分:

  • BlockDevice为最底层的块设备,BlueStore直接操作块设备,抛弃了XFS等本地文件系统。BlockDevice在用户态直接以linux系统实现的AIO直接操作块设备文件。
  • BlueFS是一个小的文件系统,其文件系统的文件和目录的元数据都保存在全部缓存在内存中,持久化保存在文件系统的日志文件中, 当文件系统重新mount时,重新replay该直接,就可以加载所有的元数据到内存中。其数据和日志文件都直接保存在依赖低层的BlockDevice中
  • RocksDB 是Facebook在leveldb上开发并优化的KV存储系统。BlueFS的主要的目的,就是支持RocksDB
  • BlueStore是最终基于RocksDB和BlockDevice实现的ceph的对象存储,其所有的元数据都保存在RocksDB这个KV存储系统中,包括collection,对象,omap,磁盘空间分配记录等都保存RocksDB里, 其对象的数据直接保存在BlockDevice

BlockDevice

BlockDevice 块设备,其对于一个物理块设备(目前也支持用XFS的一个大文件里实现),用来存储实际的数据。其实现在bluestore/BlockDevice.cc 和 bluestore/BlockDevice.h

其主要实现了异步写操作,写操作是通过 操作系统提供的异步io调用。 由于操作系统支持的aio操作只支持directIO,所以对BlockDevice的写操作直接写入磁盘,并且需要按照page对齐。其内部有一个aio_thread 线程,用来检查aio是否完成。其完成后,调用 aio_callback_t aio_callback; 回调函数通知调用方。 
目前BlocekDevice的读操作是同步读操作。 有待继续实现异步的读操作。

BlueFS

BlueFs 既然是一个文件系统,就要解决的是元数据的分配管理,其次解决文件空间的分配和管理,以及磁盘空间的分配和管理。

由于BlueFS用来支持RocksDB,所以就不是一个通用的文件系统,它的功能足以支持RocksDB 就可以了。所以它只支持以下功能:

  • 文件只支持顺序写
  • 只支持两层目录

BlueFS的元数据

BlueFS中,文件的元数据由 bluefs_fnode_t 保存

struct bluefs_fnode_t {
  uint64_t ino;  //文件的ino
  uint64_t size;  //文件大小
  utime_t mtime;  // 修改时间
  uint8_t prefer_bdev; //优先在该设备上分配空间
  vector extents; //文件在磁盘上分配的空间
  ......
}

bluefs_extents_t 代表在磁盘上的分配的extents
struct bluefs_extent_t {
  uint64_t offset;  //块设备上的 extent偏移量
  uint32_t length;  // extent的长度
  uint16_t bdev;   //对于的块设备
  ......
}

目录对应的结构 Dir

struct Dir {
    map file_map;
  };

对于BlueFS

  • 所有的元数据(文件和目录)都需要缓存在内存中
  • 所有的元数据的修改都记录在BlueFS的日志中,也就是对于BlueFS,元数据的持久化保存在日志中,当重新mount文件系统时,只需要replay日志,就可以获取所有元数据
//BlueFS的元数据cache
map dir_map;                      ///< dirname -> Dir
ceph::unordered_map file_map;  ///< ino -> File

BlueFS的读写

uint64_t size = 1048476 * 128;
  string fn = get_temp_bdev(size);
  BlueFS fs;
  ASSERT_EQ(0, fs.add_block_device(0, fn));
  fs.add_block_extent(0, 1048576, size - 1048576);
  uuid_d fsid;
  ASSERT_EQ(0, fs.mkfs(fsid));
  ASSERT_EQ(0, fs.mount());
  {
    BlueFS::FileWriter *h;
    ASSERT_EQ(0, fs.mkdir("dir"));
    ASSERT_EQ(0, fs.open_for_write("dir", "file", &h, false));
    bufferlist bl;
    bl.append("foo");
    h->append(bl);
    bl.append("bar");
    h->append(bl);
    bl.append("baz");
    h->append(bl);
    fs.fsync(h);
    fs.close_writer(h);
  }
  {
    BlueFS::FileReader *h;
    ASSERT_EQ(0, fs.open_for_read("dir", "file", &h));
    bufferlist bl;
    BlueFS::FileReaderBuffer buf(4096);
    ASSERT_EQ(9, fs.read(h, &buf, 0, 1024, &bl, NULL));
    ASSERT_EQ(0, strncmp("foobarbaz", bl.c_str(), 9));
    delete h;
  }
  fs.umount();

上述代码来自test_bluefs.cc的BlueFS的测试代码,展示了 BlueFS文件系统的使用。

  1. 文件系统调用函数fs.add_block_device 来添加设备到BlueFS中。 
    • 创建了以新的BlockDevice
    • 把该设备添加到bdev列表中,并添加相应的IOContext 到ioc中
  2. 调用 fs.add_block_extent把设备的空间添加到bluefs中
  3. 调用函数fs.mkdir创建目录
  4. 调用函数 fs.open_for_write 打开一个文件,如果不存在,就创建
  5. 调用h->append 写数据,目前数据都只是Cache在内存zhong
  6. 最后调用 fs.fsync,本函数真正的把bluefs的 数据和元数据写入磁盘

RocksDB on BlueFS

如何在BlueFS上实现RocksDB? 对RocksDB, 只要实现 rocksdb::EnvWrapper接口即可。BlueRocksEnv.cc 和 BlueRocksEnv.h 实现了class BlueRocksEnv 来完成此工作。

Bluestore 实现

BlueStore的元数据

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

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

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

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

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

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

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

onode 
数据结构onode 保存了BlueStore中一个对象的数据结构,字段和Filestore差不多,这里就不详细介绍。 
Enode 
数据结构Enode定义了一个共享的extent,也就是这段数据被多个对象共享,一个对象的onode里保存一个enode数据结构,记录该对象被共享的extent.这个shared extent 用来对象基于extent的Copy-on-write 机制

struct Enode : public boost::intrusive::unordered_set_base_hook<> {
    atomic_t nref;    //< reference count
    uint32_t hash;
    string key;      //< key under PREFIX_OBJ where we are stored
    EnodeSet *enode_set;  //< reference to the containing set

    bluestore_extent_ref_map_t ref_map;
    boost::intrusive::unordered_set_member_hook<> map_item;

数据结构bluestore_extent_ref_map_t 定义了shared extent 被哪些对象引用

struct bluestore_extent_ref_map_t {
  struct record_t {
    uint32_t length;
    uint32_t refs;
    ...... 
  };
  ......
  map ref_map;
}

BlueStore的数据读写

Bluestore的数据写入分为两类:

  1. 数据是整块覆盖写,也就是min_alloc_size对齐的写入。对于这一类写入: 
    • 重新分配新的存储空间
    • 把数据写入新分配存储空间
    • 删除旧的存储空间
  2. partial write,在这种情况下,部分块的写入,在这种情况下: 
    • overly write
    • wal write 
      这种两种方式都是先把数据写入 KV 存储中,后续再apply到实际的存储空间中,不同之处在于触发条件不同。

总结

BlueStore 其实是实现了用户态的一个文件系统。为了实现简单,又使用了RocksDB来实现了BlueStore的 所有的元数据的管理,简化了实现。

优点在于:

  • 对于整块数据的写入,数据直接aio的方式写入磁盘,避免了filestore的先写日志,后apply到实际磁盘的两次写盘。
  • 对于随机IO,直接WAL的形式,直接写入RocksDB 高性能的KV存储中

目前BlueStore的思路还是比较不错的,但是笔者认为 实现还是比较复杂,笔者简单测试了一下,性能比FileStore 在SSD 上略好一些,但是效果不明显,由于BlueStore代码实现也比较新,还需要有待优化。


你可能感兴趣的:(ceph)