关于云计算:Ceph集群迁移ip变更那些事

背景

恰逢公司的存储服务(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

关于云计算:Ceph集群迁移ip变更那些事

背景

离线迁徙[服务器搬迁]

ceph mon节点迁徙

对于下层服务

在线迁徙

mon的迁徙

数据的迁徙

一些要点

参考文献

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于云计算:Ceph集群迁移ip变更那些事

背景

离线迁徙[服务器搬迁]

ceph mon节点迁徙

对于下层服务

在线迁徙

mon的迁徙

数据的迁徙

一些要点

参考文献

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复