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

0次阅读

共计 4435 个字符，预计需要花费 12 分钟才能阅读完成。

恰逢公司的存储服务 (Ceph\&Curve) 要迁徙到新的机房，因而对 Ceph 的集群迁徙进行了一些学习与整顿，从 ceph 的集群迁徙中学习一些教训，避免踩坑。

Ceph 的迁徙能够分为离线迁徙以及在线迁徙(业务不中断), 这里会别离进行介绍。

有时可能须要将 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 个必要条件就是两个机房的机房须要网络互通，并且网段要基本一致(当然也能够放宽掩码范畴)。

因为网络是互通的，所以能够通过以下步骤进行迁徙：

先增加加 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

正文完

云计算

发表至：云计算

2023-07-07

0

关于云计算:PolarDB-并行查询的前世今生

关于云计算:JavaCV的摄像头实战之四抓图

The-Overview-of-KubeSphere-30

关于云计算:云原生周刊Docker-推出-Docker-Build-Cloud

关于前端:Angular-项目引入纯-H5-直播流播放器-Jessibuca已被官方收录

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

背景

离线迁徙[服务器搬迁]

ceph mon 节点迁徙

对于下层服务

在线迁徙

mon 的迁徙

数据的迁徙

一些要点

参考文献

站内搜索