jewel

rbd-mirror是jewel版本新加入的一个特性，目的是在不同的ceph集群中同步rbd设备上的数据。 rbd-mirror的内部实现如下图所示： 在两个相互独立的ceph集群中分别多了一个守护进程rbd-mirror，该守护进程负责同步rbd设备上的数据。rbd-mirror的主要处理流程如下图所示： 用户操作块设备向块设备中写入数据时，librbd首先将写操作写入日志，当日志写入完毕后应答用户写操作完毕。之后日志向本地块设备写入数据，于此同时日志通过rbd-mirror守护进程将日志发送到对端ceph集群。对端ceph集群将日志内容写入到块设备中，由此完成块设备的同步功能。由此看到rbd-mirror的核心在于rbd-mirror守护进程和块设备写入的日志。 rbd-mirror动手实践部分如下： 1、集群环境。 rbd-mirror的测试环境采用手动编译ceph源代码的方式安装并配置ceph集群，具体操作过程请参考http://my.oschina.net/linuxhunter/blog/682013。集群名称分别是ceph和ceph2。测试rbd-mirror使用的用户是各自集群中的admin用户（当然可以自行创建一个专门为rbd-mirror的特定用户）。 2、rbd-mirror设置。 1）复制ceph配置文件和admin用户的keyring到对端ceph集群。

一、手动安装ceph。 根据http://my.oschina.net/linuxhunter/blog/682013，手动安装jewel版本ceph到硬件服务器。 二、测试ceph集群的方法。 使用ceph自带的rados bench命令简单测试手动搭建ceph集群的性能，查看系统性能的工具使用perf命令。由于默认安装的ubuntu环境没有安装perf工具及其依赖，所有要手动安装perf工具。#apt-get install perf linux-tools-4.4.0-21-generic。安装完成后启用两个终端分别运行#perf top命令和#rados banch -p test_rbd 60 write --no-cleanup命令。 三、发现的问题。 在运行#perf top命令的终端上发现ceph-osd在调用ceph_crc32_sctp这个函数上占用了35%的CPU时间，而此时集群的压力并不大，因此决定从源代码上找找ceph_crc32_sctp为什么占用那么多的CPU时间。 ceph_crc32_sctp这个函数位于src/common/sctp_crc32.c这个文件中，只有ceph_choose_crc32函数调用ceph_crc32_sctp函数。分析ceph_choose_crc32这个函数不难发现，该函数根据当前CPU的架构来选择计算crc32的方法

一、下载ceph源代码。 由于通过源代码编译、安装并部署ceph，所以通常从github上下载ceph源代码。 #git clone https://github.com/ceph/ceph.git 二、编译ceph源代码。 最好不要在git的master上编译ceph源代码，会有不少坑。最好使用最新发布的tag上编译，到目前为止ceph最新发布的版本号是v10.2.1，因此在该tag上编译。 #git checkout -b v10.2.1 v10.2.1 #git branch master *v10.2.1 由此可以看到，当前代码即是v10.2.1 tag处的源代码。 编译ceph请参考http://my.oschina.net/linuxhunter/blog/682013 三、安装ceph。 安装编译好的ceph请参考http://my.oschina.net/linuxhunter/blog/682013 四、部署测试环境。 ceph在源代码路径的src目录下有一个vstart.sh脚本，该脚本用来快速搭建由源代码编译出来的ceph集群。使用vstart.sh脚本创建快速ceph集群命令如下： #./vstart.sh -m 192.168.250.93 -n -d -r --mon_num 1 --osd_num 3 --mds_num 0 --bluestore

一、主OSD读处理流程 OSD::ms_fast_dispatch() |__OSD::dispatch_session_waiting() |__OSD::dispatch_op_fast() |__OSD::handle_op() |__OSD::get_pg_or_queue_for_pg() 找到OpRequest中对应的PG和Pool信息 |__OSD::enqueue_op() |__PG::queue_op() |__OSD::ShardedThreadPool::ShardedWQ::queue() 将PG和Op一起放入队列中 OSD::ShardedOpWQ::_process() 负责处理OSD::ShardedThreadPool::ShardedWQ队列中的Op |__PGQueueable::RunVis::operator()(const OpRequestRef &op) |__OSD::dequeue_op() |__ReplicatedPG::do_request() |__检查当前PG是否处于flush或peering状态，若是则将op放入waiting_for_peered队列中等待PG变成可用状态 |__检查当前PG是否处于Active状态，若不是则将op放入waiting_for_active队列中 |_

一、主OSD写处理流程 OSD::ms_fast_dispatch() |__OSD::dispatch_session_waiting() |__OSD::dispatch_op_fast() |__OSD::handle_op() |__OSD::get_pg_or_queue_for_pg() 找到OpRequest中对应的PG和Pool信息 |__OSD::enqueue_op() |__PG::queue_op() |__OSD::ShardedThreadPool::ShardedWQ::queue() 将PG和Op一起放入队列中 OSD::ShardedOpWQ::_process() 负责处理OSD::ShardedThreadPool::ShardedWQ队列中的Op |__PGQueueable::RunVis::operator()(const OpRequestRef &op) |__OSD::dequeue_op() |__ReplicatedPG::do_request() |__检查当前PG是否处于flush或peering状态，若是则将op放入waiting_for_peered队列中等待PG变成可用状态 |__检查当前PG是否处于Active状态，若不是则将op放入waiting_for_active队列中 |_