共计 4435 个字符，预计需要花费 12 分钟才能阅读完成。
背景
恰逢公司的存储服务 (Ceph\&Curve) 要迁徙到新的机房，因而对 Ceph 的集群迁徙进行了一些学习与整顿，从 ceph 的集群迁徙中学习一些教训，避免踩坑。
Ceph 的迁徙能够分为离线迁徙以及在线迁徙(业务不中断), 这里会别离进行介绍。
离线迁徙[服务器搬迁]
ceph mon 节点迁徙
有时可能须要将 ceph 存储整机挪动到不同的网络、数据中心的不同局部或齐全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就须要应用离线迁徙了。
离线迁徙次要波及到的就是 mon 节点的扭转。
解决方案是为集群中的所有 mon 生成具备新 IP 地址的新 monmap，并将新映射注入每个独自的 mon
- 获取集群以后 monmap(搬迁前进行)
获取集群 monmap 这里又分为三种状况：Ceph mon 可能造成仲裁；Ceph mon 不能造成仲裁待至多有一个存活；所有的 Ceph mon 都曾经损坏了。
如果残余的 Ceph mon 可能造成仲裁(少数存活)，请应用 ceph mon getmap 命令获取 Ceph monitor map：
ceph mon getmap -o /tmp/monmap
如果此时 ceph 的 mon 曾经不可能造成仲裁了(少数 mon 挂了)，那么在衰弱的正确的 mon 机器上通过如下步骤获取 monmap
// 进行您要复制 Ceph monitor map 的 Ceph 监控器
[root@mon ~]# systemctl stop ceph-mon@<host-name>
// 取得 ceph monmap
[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不背运，所有的 mon 都损坏了，那么还有没有什么方法获取到集群的 monmap，以至于复原整个集群呢？
当然，也是有的，能够借助 ceph-monstore-tool 和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来复原它，具体详情请参考: 应用 BlueStore 时复原 Ceph monitor 存储
- 删除长期 monmap 中的老的 mon
# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
monmaptool: monmap file /tmp/monmap
monmaptool: removing node1
monmaptool: removing node2
monmaptool: removing node3
monmaptool: writing epoch 1 to /tmp/monmap (0 monitors)
- 向长期 monmap 中增加新的 mon
# monmaptool --add node1 192.168.244.44 --add node2 192.168.244.45 --add node3 192.168.244.46 /tmp/monmap
monmaptool: monmap file /tmp/monmap
monmaptool: writing epoch 1 to /tmp/monmap (3 monitors)
- 进行所有 mon 服务并注入 monmap
首先要先确保新的 mon 曾经在新的服务器上安装起来了，而后 stop 掉 mon 过程，每个 mon 新节点都要执行
ceph-mon -i {mon-id} --inject-monmap /tmp/monmap
- 更新所有服务 (mon,mds,client,mgr,osd 等) 的 ceph.conf
这里须要留神的是如果新 ip 的网段也有变动的话，那么除了要更新 ceph.conf 文件中 mon\_host 信息，还要更新 public network/cluster network 的网段信息
同步的话能够通过 ceph-deploy 命令
ceph-deploy --overwrite-conf config push node{1..3}
对于下层服务
应用 ceph 底层存储的服务可能有虚拟机，k8s 集群，如果 ceph 存储搬迁机房了，还须要服务之前的老的客户端，那么他们也须要做相应的变更
- ceph 文件系统间接挂载 +rbd 挂载
间接把新的 ceph.conf 同步到 client 节点就能够
- k8s 集群
对于 Kubenetes 集群，更新 rook-ceph-mon-endpoints 配置映射
kubectl -n rook-ceph create configmap rook-ceph-mon-endpoints \
--from-literal=data="mon.ceph-mon=172.25.65.17:6789" \
--from-literal=mapping="{}" \
--from-literal=maxMonId="2"
- openstack
Openstack 的三个组件：Nova/Cinder/Glance 均曾经对接到了 Ceph 集群中，也就是说虚机系统盘，云硬盘，镜像都保留在 Ceph 中。而这三个客户端调用 Ceph 的形式不太一样：
- Glance
上传下载镜像等时，须要新建一个调用 librbd 的 Client 来连贯 Ceph 集群。
- Cinder
创立删除云盘时，新建一个调用 librbd 的 Client 来连贯 Ceph 集群。
挂载卸载云盘时，由 Nova 调用 librbd 来实现该操作。
- Nova
虚机 (qemu-kvm 过程) 相当于一个始终在调用 librbd 的 Client，并且过程始终都在。
当虚机挂载一个云硬盘时，Nova 会将挂载这个云盘时所连贯的 MON IP 写入到数据库中，而在批改完 MON 的 IP 后，新的 MON IP 不会被更新到数据库中，而虚机启动时会加载 XML 文件，这个文件由数据库对应字段生成，因为没有更新 MON IP，所以 qemu-kvm 过程在启动时，会尝试向旧的 MON IP 发动连贯申请，当然，旧 MON 曾经删除，导致连贯不上而卡住，最终以致虚机过程启动了，然而虚机状态始终不能更新为 RUNNING。
咱们只能手动批改数据库中记录的 IP 地址来确保虚机重启后可能连贯上新的 MON，须要留神的是，仅仅批改虚机 XML 文件是无奈失效的，因为会被数据库内的字段笼罩而连上旧 MON：
### 具体字段为：mysql =>
nova => block_device_mapping => connection_info
*************************** 23. row ***************************
created_at: 2018-03-19 08:50:59
updated_at: 2018-03-26 06:32:06
deleted_at: 2018-03-26 09:20:02
id: 29
device_name: /dev/vdb
delete_on_termination: 0
snapshot_id: NULL
volume_id: 39c76d96-0f95-490c-b7db-b3da6d17331b
volume_size: NULL
no_device: NULL
connection_info: {"driver_volume_type": "rbd", "serial": "39c76d96-0f95-490c-b7db-b3da6d17331b", "data": {"secret_type": "ceph", "name": "volumes/volume-39c76d96-0f95-490c-b7db-b3da6d17331b", "secret_uuid": "0668cc5e-7145-4b27-8c83-6c28e1353e83", "qos_specs": null, "hosts": ["192.168.100.110", "192.168.100.111", "192.168.100.112"], "auth_enabled": true, "access_mode": "rw", "auth_username": "cinder", "ports": ["6789", "6789", "6789"]}}
instance_uuid: 4f52191f-9645-448f-977b-80ca515387f7
deleted: 29
source_type: volume
destination_type: volume
guest_format: NULL
device_type: disk
disk_bus: virtio
boot_index: NULL
image_id: NULL
Glance & Cinder & Nova 服务重启
另外，无需重启 Glance 服务。须要重启 所有计算节点的 nova-compute 和 管制节点的 Cinder 服务，否则会导致虚机无奈创立等问题。
在线迁徙
在线迁徙的话就是不停服的状况下切换存储集群，这其中有 2 个必要条件就是两个机房的机房须要网络互通，并且网段要基本一致(当然也能够放宽掩码范畴)。
mon 的迁徙
因为网络是互通的，所以能够通过以下步骤进行迁徙：
- 先增加加 3 个新 mon
- 更新 ceph.conf 并同步到相干服务
以后集群曾经有 6 个 mon，先确保集群曾经 health\_ok，再进行后续操作。
把 ceph.conf 中的 3 个老 mon 换成新的 mon，并把 ceph.conf 同步到相干服务(同上一节)。
- 删除老的 mon
肯定要在删除老的 mon 之前进行 ceph.conf 的批改以及同步，要不然删除了老的 mon 当前，因为老的服务分割的都是老 mon，所以会导致服务生效
数据的迁徙
存储数据的在线迁徙能够通过迁徙逻辑池来实现，步骤如下：
- 新的服务器上创立好 osd 以及 rule\_set(new\_rule\_set)
- 更改逻辑 pool 的 rule\_set 为上述步骤创立的 new\_rule\_set
sudo ceph osd pool set poolname crush_rule new_rule_set
一些要点
- Ceph 配置文件 ceph.conf 除了要批改 ip，还要查看对应的网段是否有变动，如有，也须要变更
- 若是服务器搬迁，节点 hosts 文件须要批改，ip 变了 hosts 文件的内容也要扭转；并且禁用所有 ceph 相干过程的开机启动
- 部署前要确认为新机房服务器的网络(时延，带宽，防火墙)，ntp 时钟以及硬盘等是否失常
- osd\_crush\_update\_on\_start 肯定要配置成 false
- 在线迁徙时须要在删除新 mon 之前更新并同步 ceph.conf
参考文献
ceph doc – change ip
应用 BlueStore 时复原 Ceph monitor 存储
从不衰弱的存储集群中移除 Ceph Monitor
Cephadm: Reusing OSDs on reinstalled server
Cephadm: Changing a Monitor’s IP address
Ceph 批改 mon ip 地址
Ceph Network Change
Ceph – How to update the IP address or Port of the Ceph-dashboard
记一次机房搬迁引发的 ceph 改变
Ceph 集群整体迁徙计划
如何更改基于 rbd 块设施的虚机的 monitor ip
