记一次机房搬迁引发的ceph改动

2018-11-12

字数统计: 2.2k字 | 阅读时长≈ 9分

因为业务需要，我们机房中的大多数设备需要迁移到另外的机房，其中ceph集群也在搬迁计划中，其中涉及了一些配置的更改并遇到了一些问题，这里权当记录

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

因为业务需要，我们机房中的大多数设备需要迁移到另外的机房，其中ceph集群也在搬迁计划中，其中涉及了一些配置的更改并遇到了一些问题

搬迁前准备

搬迁会涉及到的改动有这么一些：

1、节点ib网卡的ip修改，包括集群公网和集群私网
2、节点hosts文件的修改，ip变了hosts文件的内容也要改变
3、ceph配置文件ceph.conf中的mon相关内容，要根据新的ip进行修改
4、monmap的导出修改
5、针对ceph服务，禁用所有ceph相关进程开机启动，避免开机启动时引发各种问题
6、可能的磁盘盘符漂移问题

于是，我们在节点关机前，禁用了所有ceph服务的开机启动，一方面是因为系统识别磁盘柜的大量硬盘需要比较长的时间，在全部识别完成之前，很多来不及识别的磁盘盘符是不存在的，另一方面是防止ceph服务器自行启动带来其他问题

[tanweijie@ceph-52-201 ~]$ cat handle_ceph_process_auto_start.sh
#!/bin/bash

if [ x"$1" == x"enable" ]; then
    sudo systemctl enable ceph.target
    sudo systemctl enable ceph-osd.target
    sudo systemctl enable ceph-radosgw.target
    sudo systemctl enable ceph-mon.target
    sudo systemctl enable ceph-mgr.target
    sudo systemctl enable ceph-radosgw.target
    sudo systemctl enable ceph-volume@.service
    sudo systemctl enable ceph-radosgw@rgw.`hostname -s`.service
    sudo systemctl enable ceph-mon@`hostname -s`.service
elif [ x"$1" == x"disable" ]; then
    sudo systemctl disable ceph.target
    sudo systemctl disable ceph-osd.target
    sudo systemctl disable ceph-radosgw.target
    sudo systemctl disable ceph-mon.target
    sudo systemctl disable ceph-mgr.target
    sudo systemctl disable ceph-radosgw.target
    sudo systemctl disable ceph-volume@.service
    sudo systemctl disable ceph-radosgw@rgw.`hostname -s`.service
    sudo systemctl disable ceph-mon@`hostname -s`.service
fi

然后，修改了每个节点的集群公网、集群私网的ip地址，并修改了hosts文件中主机名和节点的ip映射关系，这里我们没有修改节点的主机名，因为修改主机名会涉及到osd、mon等服务的路径的修改问题，牵扯比较多，并且即使不修改主机名，也不会有太多的问题(就是看起来比较别扭)

首先导出集群的monmap

[tanweijie@ceph-52-201 ~]$ monmaptool --create --generate -c /etc/ceph/ceph.conf ./monmap.map
monmaptool: monmap file ./monmap.map
monmaptool: set fsid to 63c24cf3-8b6b-4be4-b1b9-defb05821564
monmaptool: writing epoch 0 to ./monmap.map (3 monitors)

然后，查看monmap的相关信息

[tanweijie@ceph-52-201 ~]$ monmaptool --print ./monmap.map
monmaptool: monmap file ./monmap.map
epoch 0
fsid 63c24cf3-8b6b-4be4-b1b9-defb05821564
last_changed 2018-11-08 17:01:42.064962
created 2018-11-08 17:01:42.064962
0: 192.25.52.201:6789/0 mon.noname-a
1: 192.25.52.202:6789/0 mon.noname-b
2: 192.25.52.203:6789/0 mon.noname-c

编辑monmap，实际上就是删掉monmap中的注册的mon

[tanweijie@ceph-52-201 ~]$ monmaptool --rm noname-a ./monmap.map
monmaptool: monmap file ./monmap.map
monmaptool: removing noname-a
monmaptool: writing epoch 0 to ./monmap.map (2 monitors)
[tanweijie@ceph-52-201 ~]$ monmaptool --rm noname-b ./monmap.map
monmaptool: monmap file ./monmap.map
monmaptool: removing noname-b
monmaptool: writing epoch 0 to ./monmap.map (1 monitors)
[tanweijie@ceph-52-201 ~]$ monmaptool --rm noname-c ./monmap.map
monmaptool: monmap file ./monmap.map
monmaptool: removing noname-c
monmaptool: writing epoch 0 to ./monmap.map (0 monitors)
[tanweijie@ceph-52-201 ~]$ monmaptool --print ./monmap.map
monmaptool: monmap file ./monmap.map
epoch 0
fsid 63c24cf3-8b6b-4be4-b1b9-defb05821564
last_changed 2018-11-08 17:01:42.064962
created 2018-11-08 17:01:42.064962

此时monmap已经删掉了mon的注册信息，可以拷到所有mon节点，另外ceph.conf的对应字段也要修改：

[global]
fsid = 63c24cf3-8b6b-4be4-b1b9-defb05821564
mon_initial_members = ceph-52-201, ceph-52-202, ceph-52-203
mon_host = 192.26.25.56,192.26.25.57,192.26.25.58
......
public_network = 192.26.0.0/16
cluster_network = 192.30.0.0/16

配置文件也要推送到所有节点

先关闭服务器，再关闭磁盘柜，然后拔线，运输，到达新机房后，重新接上线，磁盘柜子先开机，确保磁盘全部正常后，服务器再开机

搬迁后恢复

服务器开机后，ceph服务没有自动启动，所以在此之前，需要进行monmap的修改，首先要让mon先起来

在每一个mon节点，先注入monmap，将自己注册为mon节点

1
2
3

[tanweijie@ceph-52-201 ~]$ ceph-mon -i noname-a --mon-data /var/lib/ceph/mon/ceph-`hostname -s` --inject-monmap ./monmap.map
[tanweijie@ceph-52-202 ~]$ ceph-mon -i noname-b --mon-data /var/lib/ceph/mon/ceph-`hostname -s` --inject-monmap ./monmap.map
[tanweijie@ceph-52-203 ~]$ ceph-mon -i noname-c --mon-data /var/lib/ceph/mon/ceph-`hostname -s` --inject-monmap ./monmap.map

这样就完成了monmap的修改，先将mon启动起来，确认mon无问题后，再启动mgr，最后启动osd，然后使用之前的脚本将ceph服务的开机启动恢复，即可

遇到的问题

过程本身不是很复杂，但是还是遇到了一些问题

osd起不来

确实有部分osd一直起不来，重启了不少10次，仍然起不来，看日志输出基本是在pg的同步时候，一直在等待，直到超时也没有成功，所以osd就挂了，出现这个问题时，现象比较有规律，起不来的osd仅集中在某个节点或者某两个节点，排查发现是集群私网的ip修改有问题，使得osd之间无法正常同步

另外一个osd起不来的问题非常罕见，就是osd的wal分区不见了！对，就是不见了，我们在设计的时候，将osd的wal分到了一个ssd磁盘，通过调查起不来的osd的配置，发现起不来的那部分osd的wal分区恰好都在同一个ssd上，而一看该ssd的分区情况，居然消失了！！消失了！！失了！！是的，原本它应该有很多个分区，而现在看来只有一个分区，这就导致相关的osd找不到他们的wal，从而一直出堆栈；关于这个问题，我们查了一下能查到的资料，都没有说到，经过一个通宵的折腾，我们决定重建这部分osd草草了事-.-

osd可能的盘符漂移问题

开头说到，磁盘柜子在重启后，由于磁盘非常多(84*1TB)，服务器节点在识别磁盘的时候是按顺序识别，扫描到硬盘后会自动按顺序进行盘分配，即使我们在搬迁过程中没有拔下磁盘，而是整个磁盘柜子一起抬(一个柜子差不多300斤我的天！)，但是在磁盘柜重新开起来后，我们还是发现磁盘全部盘符都发生了变化！是的，只要有一个盘符变了，识别顺序就会改变从而使得其他盘符也会改变，但是，我们在启动osd 的时候，在解决了上述的两个osd起不来的问题后，osd是可以正常启动并恢复健康的，个中缘由，应该是在osd创建的时候，osd对应的lvm卷中写入了osd的相关信息，其中最重要的是lv、pv、vg这些信息，这些信息是依赖磁盘本身的wwn的，虽然lv、pv和vg本身与盘符是有映射关系的，但wwn对于一个磁盘来说是不会变化的，所以在创建lvm卷的时候，在lvm卷的tags中写入了这些信息，在实际的lvm卷管理中，并不依赖当前的盘符，盘符产生的映射关系是在lvm使用之前，所以即使盘符发生变化，只要lvm的tags中存在关联关系，lvm本身会根据这些信息去修改实际的盘符映射，实际情况也是这样的：

在集群建好之后，我们对节点中所有的osd及其他重要信息进行了备份，其中部分osd 的信息如下

[osd.0]
lv = /dev/ceph-f689ffba-f050-4375-8a9e-1b49c9c017ae/osd-block-9c0480a8-8504-46aa-ac53-0e1fe94c5362
vg = ceph-f689ffba-f050-4375-8a9e-1b49c9c017ae
pv = sdcf
data = sdcf
db = /dev/sdm1
wal = /dev/sdc1

[osd.1]
lv = /dev/ceph-07c7effd-bf4e-449e-8b3d-c28d65f3398c/osd-block-ac9baafe-cb77-4ade-a4a5-aad6d8e3e68c
vg = ceph-07c7effd-bf4e-449e-8b3d-c28d65f3398c
pv = sdda
data = sdda
db = /dev/sdm2
wal = /dev/sdc2

[osd.2]
lv = /dev/ceph-4d5f95f2-16f5-4d94-beff-71c8b7327e13/osd-block-02adf6b6-6bab-4217-b6d7-4e7b261f3d3b
vg = ceph-4d5f95f2-16f5-4d94-beff-71c8b7327e13
pv = sdcp
data = sdcp
db = /dev/sdm3
wal = /dev/sdc3

在集群搬迁并重启启动后，查看相同的osd信息，发现信息变更为：

[osd.0]
lv = /dev/ceph-f689ffba-f050-4375-8a9e-1b49c9c017ae/osd-block-9c0480a8-8504-46aa-ac53-0e1fe94c5362
vg = ceph-f689ffba-f050-4375-8a9e-1b49c9c017ae
pv = sdcd
data = sdcd
db = /dev/sdk1
wal = /dev/sdc1

[osd.1]
lv = /dev/ceph-07c7effd-bf4e-449e-8b3d-c28d65f3398c/osd-block-ac9baafe-cb77-4ade-a4a5-aad6d8e3e68c
vg = ceph-07c7effd-bf4e-449e-8b3d-c28d65f3398c
pv = sdcy
data = sdcy
db = /dev/sdk2
wal = /dev/sdc2

[osd.2]
lv = /dev/ceph-4d5f95f2-16f5-4d94-beff-71c8b7327e13/osd-block-02adf6b6-6bab-4217-b6d7-4e7b261f3d3b
vg = ceph-4d5f95f2-16f5-4d94-beff-71c8b7327e13
pv = sdcn
data = sdcn
db = /dev/sdk3
wal = /dev/sdc3

从而可以得出结论：盘符漂移可能发生，但是在特定场景下，lvm本身的机制也可以保证漂移后osd的正确性

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2018/11/12/记一次机房搬迁引发的ceph改动/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！