Ceph分布式存储 OSD从filestore 转换到 bluestore的方法

admin

获取代码并安装git clone https://github.com/ceph/ceph.gitcd cephgit submodule update --init --recursive./make-distrpm -bb ceph.spec

生成rpm安装包后进行安装,这个过程就不讲太多，根据各种文档安装上最新的版本即可，这个代码合进去时间并不久，大概是上个月才合进去的

配置集群

首先配置一个filestore的集群，这个也是很简单的，我的环境配置一个单主机三个OSD的集群

[root@lab8106 ceph]# ceph -s    cluster 3daaf51a-eeba-43a6-9f58-c26c5796f928     health HEALTH_WARN            mon.lab8106 low disk space     monmap e2: 1 mons at {lab8106=192.168.8.106:6789/0}            election epoch 4, quorum 0 lab8106        mgr active: lab8106      osdmap e16: 3 osds: 3 up, 3 in      pgmap v34: 64 pgs, 1 pools, 0 bytes data, 0 objects            323 MB used, 822 GB / 822 GB avail                  64 active+clean[root@lab8106 ceph]# ceph osd treeID WEIGHT  TYPE NAME        UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.80338 root default                                       -2 0.80338     host lab8106                                    0 0.26779         osd.0         up  1.00000          1.00000  1 0.26779         osd.1         up  1.00000          1.00000  2 0.26779         osd.2         up  1.00000          1.00000

" X6 W- z# g% }写入少量数据[root@lab8106 ~]# rados -p rbd bench 10 write --no-cleanup

设置noout[root@lab8106 ~]# ceph osd set nooutnoout is set

停止OSD.0[root@lab8106 ~]# systemctl stop ceph-osd@0[root@lab8106 ~]# ceph osd down 0osd.0 is already down.
+ _# m* ]" [) h* v" ^; y
" f' g4 _: e' [* A

将数据换个目录挂载，换个新盘挂载到原路径

[root@lab8106 ~]# mkdir /var/lib/ceph/osd/ceph-0.old/[root@lab8106 ~]# umount /var/lib/ceph/osd/ceph-0[root@lab8106 ~]# mount /dev/sdb1 /var/lib/ceph/osd/ceph-0.old/[root@lab8106 ~]# mount /dev/sde1 /var/lib/ceph/osd/ceph-0/[root@lab8106 ~]# df -h|grep osd/dev/sdc1       275G  833M  274G   1% /var/lib/ceph/osd/ceph-1/dev/sdd1       275G  833M  274G   1% /var/lib/ceph/osd/ceph-2/dev/sdb1       275G  759M  274G   1% /var/lib/ceph/osd/ceph-0.old/dev/sde1       280G   33M  280G   1% /var/lib/ceph/osd/ceph-0

) {; N( C$ c: ^) x; o

在配置文件/etc/ceph/ceph.conf中添加

enable_experimental_unrecoverable_data_corrupting_features = bluestore

/ O) c4 R/ @. V0 S' P& s

如果需要指定osd的block的路径需要写配置文件

在做 ceph-objectstore-tool --type bluestore --data-path --op mkfs 这个操作之前，在配置文件的全局里面添加上

bluestore_block_path = /dev/sde2

然后再创建的时候就可以是链接到设备了，这个地方写全局变量，然后创建完了后就删除掉这项配置文件，写单独的配置文件的时候发现没读取成功,生成后应该是这样的

[root@lab8106 ceph]# ll /var/lib/ceph/osd/ceph-0total 20lrwxrwxrwx 1 root root  9 May  3 17:40 block -> /dev/sde2-rw-r--r-- 1 root root  2 May  3 17:40 bluefs-rw-r--r-- 1 root root 37 May  3 17:40 fsid-rw-r--r-- 1 root root  8 May  3 17:40 kv_backend-rw-r--r-- 1 root root  4 May  3 17:40 mkfs_done-rw-r--r-- 1 root root 10 May  3 17:40 type

, x5 v" c4 O9 E9 c6 c

如果不增加这个就是以文件形式的存在

获取osd.0的fsid[root@lab8106 ~]# cat /var/lib/ceph/osd/ceph-0.old/fsid b2f73450-5c4a-45fb-9c24-8218a5803434

- o9 M5 @+ f5 M, a+ _" k创建一个bluestore的osd.0[root@lab8106 ~]# ceph-objectstore-tool --type bluestore --data-path /var/lib/ceph/osd/ceph-0 --fsid b2f73450-5c4a-45fb-9c24-8218a5803434 --op mkfs
: M: U4 n% v( {2 z" |' n/ T
转移数据[root@lab8106 ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0.old --target-data-path /var/lib/ceph/osd/ceph-0 --op dup[root@lab8106 ~]# chown -R ceph:ceph /var/lib/ceph/osd/ceph-0

这个操作是将之前的filestore的数据转移到新的bluestore上了

启动OSD.0[root@lab8106 osd]# systemctl restart ceph-osd@0

0 s& U4 Z) P/ w) J  [/ B4 k+ l" X

检查状态

[root@lab8106 osd]# ceph -s2017-05-03 17:05:13.119492 7f20a501b700 -1 WARNING: the following dangerous and experimental features are enabled: bluestore2017-05-03 17:05:13.150181 7f20a501b700 -1 WARNING: the following dangerous and experimental features are enabled: bluestore    cluster 3daaf51a-eeba-43a6-9f58-c26c5796f928     health HEALTH_WARN            noout flag(s) set            mon.lab8106 low disk space     monmap e2: 1 mons at {lab8106=192.168.8.106:6789/0}            election epoch 4, quorum 0 lab8106        mgr active: lab8106      osdmap e25: 3 osds: 3 up, 3 in            flags noout      pgmap v80: 64 pgs, 1 pools, 724 MB data, 182 objects            3431 MB used, 555 GB / 558 GB avail                  64 active+clean
& x6 `+ Y& H/ }/ a: S3 J" W

成功转移

不同的block方式[root@lab8106 ceph]# ll /var/lib/ceph/osd/ceph-0/ -al|grep block-rw-r--r--  1 ceph ceph 10737418240 May  3 17:32 block[root@lab8106 ceph]# ll /var/lib/ceph/osd/ceph-4/ -al|grep blocklrwxrwxrwx  1 ceph ceph  58 May  3 17:16 block -> /dev/disk/by-partuuid/846e93a2-0f6d-47d4-8a90-85ab3cf4ec4e-rw-r--r--  1 ceph ceph  37 May  3 17:16 block_uuid

可以看到直接创建的时候的block是以链接的方式链接到一个分区的，而不改配置文件的转移的方式里面是一个文件的形式，根据需要进行选择

5 t* H6 D2 a0 S$ g3 r$ i' ?( _

转移 工具 的出现方便了以后从filestore到bluestore的转移，可以采取一个个osd的转移方式将整个集群进行转移，而免去了剔除osd，再添加的方式，减少了迁移量，可以一个个的离线进行操作

ceph的工具集越来越完整了

( b" ~- N) h% i* R# n% o! {: [
0 I7 y0 x/ q; F$ C, i- Q' }

admin

迁移方式
数据清空——重建为Bluestore——回填均衡数据！
& h8 c# L8 f9 |3 {从Filestore到Bluestore的转换不能在转换节点上有数据且提供服务的情况下进行，因此我们的方法是先将存储节点的数据清空，销毁OSD，然后使用重新准备Bluestore类型的OSD，再从群集中重新填充数据。对群集中的每个存储节点进行数据清空并重复此操作。根据您的Ceph架构，您可以并行地操作几个存储节点，以减少总的迁移时间。我们将一次迁移2-3个存储节点，每个节点位于不同的机架中（我们的故障域单位为机架），并在删除以及填充数据过程中尽量保持在20%的“misplaced objects”以下。
, H  J' D8 y5 z5 |. G& ~2 P, e7 d为了使此操作成功，您必须确保集群有足够的可用空间，以应对当一个节点必须将其所有数据迁移到集群的其余节点时集群容量的可用以及安全。
节点数据清空
要清空节点，我们将该存储节点所有的OSD的crush weight修改为0。这将触发从该存储节点迁移出数据并将其分发到集群的其余节点（数据均衡）。
/ u7 j, y* p: \( z/ Z例如，要将OSD 720到OSD 755的数据清空，我们可以运行：
for i in $(seq 720 755); do ceph osd crush reweight osd.$i 0; done
清空完成后，您可以检查Ceph的运行状况（ceph -s）以确认是否已完成数据清空。您还可以使用“ ceph osd df tree”来查看磁盘仍然还需要传输多少数据。我们的存储节点平均每台服务器需要24小时才能完全清空。根据您的OSD磁盘类型和群集上的负载，此指标可能会有很大差异。
2 ~$ m! y, ~( a9 ^将OSD转换为Bluestore
请按照以下步骤操作，安全的清理回收磁盘，然后重新部署为Bluestore类型的OSD。
: R9 |: X( D2 b0 i8 W# Stop the OSD process
systemctl stop ceph-osd@<osd-id>.service
# Unmount the OSD
umount /dev/<block-device>
+ ?( |( h8 y% S& J8 i' W& ~# Zap the disk
ceph-disk zap <osd-id>
# Mark the OSD as destroyed
ceph osd destroy <osd-id> --yes-i-really-mean-it
# Prepare the disk as Bluestore
6 W& U( S) A/ B, L4 jceph-disk prepare --bluestore /dev/<block-device> --osd-id <osd-id>
我们注意到，在比较转换前后的“ ceph osd tree”的输出时，类列现在可以指示您的OSD类型（SSD或HDD），对我们而言，此类型之前为空白。这可能只是新添加到Luminous的，而不是Bluestore所特有的。本次只是简单说明一下。
( x/ c% r' B2 K% NFilestore ‘ceph osd tree’
: Q) A0 X6 g8 r) iID   CLASS WEIGHT     TYPE NAME               STATUS REWEIGHT PRI-AFF
7 \* U, W2 d" s) Z-1       8503.16504 root default
" y' Q( v- S9 v-84               0     rack 1
. S, J( L) D3 f" J" X-5       1306.07776     rack rack1
-83       388.79956         host storage1-r1                              
- J) L" z) L6 ]- ?+ H720         10.79999             osd.720         up 1.00000 1.00000
' P: f$ S: k; a2 F) S2 R5 P: ]% t721         10.79999             osd.721         up 1.00000 1.00000
8 K7 s) W# f+ M; i/ tBluestore ‘ceph osd tree’
/ `8 u" O, i4 {/ l) M! ^. R  kID   CLASS WEIGHT     TYPE NAME               STATUS REWEIGHT PRI-AFF
- s5 W+ I5 W9 [& @5 C. C" d# V$ w) P-1       8503.16504 root default
-84               0     rack 1
-5       1306.07776     rack rack1
-83       388.79956         host storage1-r1
720   hdd   10.79999             osd.720         up 1.00000 1.00000
; a9 X' n) U% ~/ N( n, w721   hdd   10.79999             osd.721         up 1.00000 1.00000
回填数据
现在是时候用数据填充Bluestore OSD了。就像清空OSD数据一样，我们将更改OSD 的crush weight值。
例如，要填充OSD 720至OSD 755（12TB磁盘），我们将运行：
for i in $(seq 720 755); do ceph osd crush reweight osd.$i 10.79999; done
根据磁盘的大小，您需要配置适合OSD的 crush weight。这通常是磁盘的大小（以TB为单位）。Ceph官方可以阅读更多关于“ceph osd reweight”和“ceph osd crush reweight”的区别。
& U2 A. C' m& U5 V1 q, J等待Ceph的运行状态恢复为HEALTH_OK。
跟踪与监控
我们使用各种工具来监控和报告我们的OpenStack和Ceph集群。对于本次迁移，我们能够监控Filestore的XFS数据分区，并查看将数据复制到集群的其余部分。

3 x3 Z) G& i: x* z7 k一旦将OSD转换为Bluestore，我们就不再需要在Zabbix中监视Ceph系统的posix文件系统，因此我们不得不依靠ceph-mgr的输出来获取OSD上有多少数据。Grafana和graphite与ceph-mgr可以很好的集成在一起，因此我们仍然能够看到每个存储节点上数据分布的情况。
0 a  ^' K) H7 ]& J0 l
随着37个存储节点的迁移，每个节点都需要数据清空，转换和数据回填，我们不得不以某种方式对其进行跟踪整个过程。我们是一个由两个人组成的团队，因此我们建立了一个共享的电子表格以此来跟踪进度。

花了多少时间？
. S' U; |1 K$ A$ g+ j: H我们于2018年7月底开始迁移，并于9月初完成迁移。在此迁移期间，群集仍在生产环境中正常运行，我们记录了以下统计数据：
/ H' M& f) K6 L480 TB的基因组数据上传到集群
增加了1 PB的新存储容量
  ]1 q. N/ P" p8 o为Collaboratory的各个研究人员提供了188 TB的基因组数据。
4 v$ i( E. L  T+ ?过程影响
每个存储节点的清空和回填会导致群集上出现大量复制流量，但Ceph群集的前端仍然能够为环境提供服务。研究人员仍然能够从对象存储中获取数据，并且openstack卷可以继续正常工作。我们还每小时对从对象存储中下载100GB基因组文件进行基准测试，并且在此迁移项目期间未发现偏离正常速度的情况。

问题
在项目后期，我们开始收到Ceph健康警告，发现monmap太大。我们的集群已经使用了几年，所以我们的monmap是leveldb。在迁移期间，monmap已增长到20GB（通常低于1GB）。在大型数据移动事件期间，Leveldb的性能可能会很差，并导致一切变慢。为了解决这个问题，我们必须在/etc/ceph/ceph.conf中启用mon压缩，然后重新启动ceph-mon，最后等待压缩发生。
/ ~" a$ S% k9 I. t, [% i[mon]
8 ^$ g: h2 w& U# G  f9 S! |, kmon compact on start = true
7 l  P, _% e+ F2 v这不是什么大问题，因为我们已经为存储monmap的分区分配了100GB的空间，但是确实导致我们考虑迁移到使用Luminous的默认值“ rocksdb”的monmap后端，该默认值显然可以更好的处理诸如失败之类的数据迁移事件。
, {  E3 F8 W+ m" g若要确定您的monmap是leveldb还是rocksdb，请执行以下操作
# cat /var/lib/ceph/mon/ceph-<mon-name>/kv_backend
leveldb
; b7 c9 W/ Q! ^& m$ g7 D, ]当前，从leveldb迁移到rockdb的唯一方法是删除/添加您的mons。例如，如果您有3个mon，则可以部署一个临时的第4个mon，然后删除/添加原始的3个mon，最后删除第4个mon。
未来的改进
% f: I# ~7 w( i5 M- K0 l. q# aCeph Monmap后端更改为Rocksdb
增加PG以解决我们在迁移过程中添加到集群中的新OSD