Ceph BlueStore

March 7, 2018
Author:Eric
Source:http://blog.wjin.org/posts/ceph-bluestore.html
Declaration: this work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Creative Commons License

Introduction

在介绍了BlockDevice,BlueFS,FreelistManager和Allocator后,接下来重点分析BlueStore的实现。BlueStore继承于ObjectStore,它需要实现mkfs/mount/umount等初始化和退出时的操作,同时它也提供对象操作的基本接口,比如read/write,以及对象属性attr和omap相关的操作。虽然代码量巨大,但是除了写操作以外,其他只是代码繁琐,但是不难理解,所以将更多精力花在写操作的流程上,以及和写性能相关的各种监控指标上。对于写操作的请求,怎么从内存的object extent映射到磁盘的地址空间,可以参考网上的这篇文章。这里以simple write表示新写/对齐写(cow)等不需要wal的场景,以deferred write表示需要写wal的场景(rmw)。

首先从宏观上了解一下BlueStore的整体架构(借用Ceph作者的图):

img

因为主要还是用KernelDevice,所以仍然以KernelDevice作为介绍,BlueStore涉及到的线程如下:

AioContext

写设备都是通过libaio,首先需要了解回调函数的执行流程。AioContext派生了两种context,TransContext和DeferredBatch,前者对应simple write,简称为txc,后者对应deferred write,简称为dbh。创建块设备的时候,会设置好回调函数,由块设备的aio thread线程执行回调:

struct AioContext {
	virtual void aio_finish(BlueStore *store) = 0;
	virtual ~AioContext() {}
};

struct TransContext : public AioContext {
	......
	void aio_finish(BlueStore *store) override {
		store->txc_aio_finish(this); // txc的回调
	}
}

struct DeferredBatch : public AioContext {
	......
	void aio_finish(BlueStore *store) override {
		store->_deferred_aio_finish(osr); // dbh的回调
	}
}

回调函数在创建设备的时候,会提前设置好:

int BlueStore::_open_bdev(bool create)
{
	assert(bdev == NULL);
	string p = path + "/block";
	bdev = BlockDevice::create(cct, p, aio_cb, static_cast<void*>(this)); // 传入回调函数
	......
}

static void aio_cb(void *priv, void *priv2)
{
	BlueStore *store = static_cast<BlueStore*>(priv);
	BlueStore::AioContext *c = static_cast<BlueStore::AioContext*>(priv2);
	c->aio_finish(store); // 执行回调函数
}

Write Type

对于用户或osd层面的一次IO写请求,到BlueStore这一层,可能是simple write,也可能是deferred write,还有可能既有simple write的场景,也有deferred write的场景。

Simple Write

img

对于simple write场景,先把数据写入新的block,然后更新k/v元信息,txc状态转换图如下:

写新block:

STATE_PREPARE -> STATE_AIO_WAIT -> STATE_IO_DONE -> STATE_KV_QUEUED

写k/v元信息:

STATE_KV_QUEUED -> STATE_KV_SUBMITTED -> STATE_KV_DONE -> STATE_FINISHING -> STATE_DONE

步骤:

Deferred Write

img

对于deferred write场景,wal直接封装在k/v事务中,先写日志,即commit k/v操作,所以不会经过STATE_AIO_WAIT。日志写完成后,再封装一个dbh事务执行data的写操作。

写k/v日志:

STATE_PREPARE -> STATE_IO_DONE -> STATE_KV_QUEUED -> STATE_KV_SUBMITTED -> STATE_KV_DONE -> STATE_DEFERRED_QUEUE

写数据:

STATE_DEFERRED_QUEUE -> STATE_DEFERRED_CLEANUP -> STATE_FINISHING -> STATE_DONE

步骤:

Simple Write + Deferred Write

img

这种写操作最复杂,状态由前面两种的组合起来,步骤如下:

无论何种情况,当执行到STATE_KV_DONE后,就可以安全通知用户写操作完成,下面具体分析每个线程的工作。

Write Process

OSD::osd_op_tp

和FileStore类似,pg内部的修改操作,由线程池osd_op_tp封装成事务,通过函数queue_transactions提交请求:

int BlueStore::queue_transactions(Sequencer *posr, vector<Transaction>& tls, TrackedOpRef op,
		ThreadPool::TPHandle *handle)
{
	// 准备pg的OpSequencer,保证pg内部操作串行执行
	OpSequencer *osr;
	if (posr->p) {
		osr = static_cast<OpSequencer *>(posr->p.get());
	} else {
		osr = new OpSequencer(cct, this);
		osr->parent = posr;
		posr->p = osr;
	}

	// 创建txc并将其在OpSequencer内部排队
	TransContext *txc = _txc_create(osr); // txc初始状态为STATE_PREPARE

	// 准备回调函数
	txc->onreadable = onreadable;
	txc->onreadable_sync = onreadable_sync;
	txc->oncommit = ondisk;

	// 将osd层面的事务,转换为BlueStore层面的事务操作
	for (vector<Transaction>::iterator p = tls.begin(); p != tls.end(); ++p) {
		(*p).set_osr(osr);
		txc->bytes += (*p).get_num_bytes();
		_txc_add_transaction(txc, &(*p)); // 非常复杂
	}

	// 将deferred类型的日志加入k/v的事务中
	if (txc->deferred_txn) {
		txc->deferred_txn->seq = ++deferred_seq;
		bufferlist bl;
		::encode(*txc->deferred_txn, bl);
		string key;
		get_deferred_key(txc->deferred_txn->seq, &key);
		txc->t->set(PREFIX_DEFERRED, key, bl);
	}

	// 限流操作
	......

	// 执行状态机,会将io请求提交给块设备执行
	_txc_state_proc(txc);
}

// _txc_state_proc函数就是一个状态机,实现比较简单,后续不再列举
void BlueStore::_txc_state_proc(TransContext *txc)
{
	while (true) {
		switch (txc->state) {
			case TransContext::STATE_PREPARE:
				txc->log_state_latency(logger, l_bluestore_state_prepare_lat);
				if (txc->ioc.has_pending_aios()) { // 区分是否包含simple write,如果没有,直接执行后面的case
					txc->state = TransContext::STATE_AIO_WAIT;
					txc->had_ios = true;
					_txc_aio_submit(txc); // 提交io请求
					return; // 返回,等待io完成后的回调
				}
				// 注意没有break

			case TransContext::STATE_AIO_WAIT:
				txc->log_state_latency(logger, l_bluestore_state_aio_wait_lat);
				_txc_finish_io(txc);
				return;
			......
		}
	}
}

这个线程涉及的latency有:

BlockDevice::aio_thread

对于simple write,io执行完成后,会再次执行状态机函数_txc_state_proc,根据前面的状态STATE_AIO_WAIT,会执行函数_txc_finish_io,这个函数的主要目的是保证pg对应的OpSequencer中的txc按排队的先后顺序依次进入kv_sync_thread线程的队列(因为libaio可能乱序)。为什么必须保证先后顺序?原因是对pg中的同一个object可能连续提交多次写请求,每次对应一个txc,在osd层面通过pg lock保证顺序,依次提交到ObjectStore层面,ObjectStore也必须保证这样的顺序,不然可能发生数据错乱。

void BlueStore::_txc_finish_io(TransContext *txc)
{
	OpSequencer *osr = txc->osr.get();
	std::lock_guard<std::mutex> l(osr->qlock); // 获取OpSequencer中的锁,主要是保互斥访问txc队列
	txc->state = TransContext::STATE_IO_DONE; // 设置状态

	txc->ioc.running_aios.clear();

	OpSequencer::q_list_t::iterator p = osr->q.iterator_to(*txc); // 定位到当前txc在队列中的位置
	while (p != osr->q.begin()) {
		--p;
		if (p->state < TransContext::STATE_IO_DONE) { // 前面还有未完成io操作的txc,这个txc不能继续进行下去,等待前面的完成,所以直接return
			return;
		}
		if (p->state > TransContext::STATE_IO_DONE) { // 前面以及进入下一个状态了,递增p并退出循环,下面接着处理当前的txc
			++p;
			break;
		}
	}

	// 依次处理状态为STATE_IO_DONE的txc,会将txc放入kv_sync_thread的队列kv_queue和kv_queue_unsubmitted
	do {
		_txc_state_proc(&*p++);
	} while (p != osr->q.end() && p->state == TransContext::STATE_IO_DONE);

	......
}

对于deferred write,第一阶段将日志写入k/v中后,会继续准备写data的dbh然后提交写io请求,完成后由aio_thread回调,主要工作是设置状态STATE_DEFERRED_CLEANUP和将dbh入队列deferred_done_queue等待kv_sync_thread线程处理:

void BlueStore::_deferred_aio_finish(OpSequencer *osr)
{
	......
	std::lock_guard<std::mutex> l2(osr->qlock);
	for (auto& i : b->txcs) {
		TransContext *txc = &i;
		txc->state = TransContext::STATE_DEFERRED_CLEANUP; // 设置状态
		costs += txc->cost;
	}

	osr->qcond.notify_all();
	throttle_deferred_bytes.put(costs); // 释放throttle资源
	std::lock_guard<std::mutex> l(kv_lock);
	deferred_done_queue.emplace_back(b); // 入队列

	......
}

综上,可以看出,当IO执行完成后,要么是将txc放入队列,要么是将dbh放入队列,虽然对应不同队列,但是都是等待线程kv_sync_thread执行,这里sync的意思应该是同步,写完数据后,需要更新k/v,比如object的Onode信息,FreelistManager的磁盘空间信息等等,这些必须按顺序操作。

对于simple write情况,都是写新的磁盘block(如果是cow,也是写新的block,只是事务中k/v操作增加对旧的block的回收操作),所以先由aio_thread写block,再由kv_sync_thread同步元信息,无论什么时候挂掉,数据都不会损坏。

对于deferred write,kv_sync_thread第一次的commit操作中,将wal记录在了k/v系统中,然后进行后续的操作,异常的情况,可以通过回放wal,数据也不会损坏。

这个线程涉及的latency有:

BlueStore::kv_sync_thread

这个线程即为同步线程,处理三个队列,kv_queue表示需要执行commit的txc队列,deferred_done_queue表示已经完成wal操作的dbh队列,deferred_stable_queue表示已经落盘,等待清理日志。线程一直循环处理每个队列:

kv_queue: 将kv_queue中的txc存入kv_committing中,并提交给k/v系统执行,即执行操作db->submit_transaction,设置状态为STATE_KV_SUBMITTED,并将kv_committing中的txc放入kv_committing_to_finalize,等待线程kv_finalize_thread执行。

deferred_done_queue: 这个队列的dbh会有两种结果: 1) 如果没有做flush操作,会将其放入deferred_stable_queue待下次循环继续处理 2) 如果做了flush操作,说明数据已经落盘,即已经是stable的了,直接将其插入deferred_stable_queue队列,这里stable的意思就是数据已经写好了,前面k/v中记录的wal没用了,可以删除。

deferred_stable_queue: 依次操作dbh中的txc,将k/v中的wal日志删除,然后dbh入队列deferred_stable_to_finalize,等待线程kv_finalize_thread执行。

这个线程涉及的latency有:

BlueStore::kv_finalize_thread

这个线程即为清理线程,处理两个个队列kv_committing_to_finalize和deferred_stable_to_finalize。

kv_committing_to_finalize: 再次调用函数_txc_state_proc,设置状态为STATE_KV_DONE,并执行回调函数通知用户io操作完成。然后根据条件判读是否需要继续执行操作:

deferred_stable_to_finalize: 遍历dbh中包含的txc,再次调用函数_txc_state_proc,设置状态为STATE_FINISHING,继续调用_txc_finish,设置状态为STATE_DONE,完成。

latency指标:

deferred_finisher和finishers两个线程比较简单,只是执行一个回调,就不介绍了,其他每个线程基本上都是身兼数职,处理多个队列,功能分的不是很清楚,以至于阅读代码的时候稍显晦涩。这样做可能是出于性能考虑,避免跨度多个线程,中断IO的流水线,引入不必要的开销。

Deferred IO Order

还有一个问题需要注意,dbh执行的时候,通过libaio提交给BlockDevice执行写data的请求,这个时候的顺序怎么保证?实现的时候,BlueStore内部包含一个成员变量deferred_queue,这个队列包含需要执行deferred IO的OpSequencer,而每个OpSequencer包含两个成员变量,deferred_running和deferred_pending,类型为DeferredBatch,这个类包含一个txc的数组,如果pg有写请求,会在pg对应的OpSequencer中的deferred_pending中排队txc,待时机成熟的时候,一次性提交所有txc给libaio,执行完成后才会进行下一次提交,这样不会导致deferred IO写data的时候乱序。

void BlueStore::_deferred_queue(TransContext *txc)
{
	deferred_lock.lock();
	if (!txc->osr->deferred_pending && !txc->osr->deferred_running) {
		deferred_queue.push_back(*txc->osr); // 排队osr
	}
	if (!txc->osr->deferred_pending) {
		txc->osr->deferred_pending = new DeferredBatch(cct, txc->osr.get()); // 如果不存在,新建dbh
	}

	++deferred_queue_size;
	txc->osr->deferred_pending->txcs.push_back(*txc); // 将txc追加到末尾
	......
}

void BlueStore::_deferred_submit_unlock(OpSequencer *osr)
{
	......

	// 切换指针,保证每次操作完成后才会进行下一次提交
	// submit的相关函数都会判断deferred_running是否为空
	osr->deferred_running = osr->deferred_pending;
	osr->deferred_pending = nullptr;

	......

	while (true) {
		......
		int r = bdev->aio_write(start, bl, &b->ioc, false); // 准备所有txc的写buffer
	}

	......

	deferred_lock.unlock();
	bdev->aio_submit(&b->ioc); // 一次性提交所有txc
}

void BlueStore::_kv_finalize_thread()
{
	......
	for (auto b : deferred_stable) {
		auto p = b->txcs.begin();
		while (p != b->txcs.end()) {
			TransContext *txc = &*p;
			p = b->txcs.erase(p);
			_txc_state_proc(txc);
		}
		delete b; // 释放dbh
	}
	......
}

Summary

Newest 10 Posts