ceph存储当mon节点全部出现问题的时候或者单独一个节点出现问题时恢复过程
当mon节点全部出现问题的时候或者单独一个节点出现问题时恢复过程ceph一直无法正常的执行ceph -s命令；
ceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods but i only support
2024-10-17T22:33:47.295+0800 7f20fe7fc700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods but i only support
2024-10-17T22:33:47.297+0800 7f20ff7fe700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods but i only support
环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。
结果过程：
1、在gm268-3节点上导出monmap文件：
$ monmaptool --create --clobber --fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9 --add gm268-3 10.12.3.2:6789 --add gm268-2 10.12.2.2:6789 --add gm268-1 10.12.1.2:6789 /tmp/monmap
monmaptool: monmap file /tmp/monmap
monmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
monmaptool: writing epoch 0 to /tmp/monmap (3 monitors)
导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。
查看下导出的文件信息：
$ monmaptool --print /tmp/monmap
monmaptool: monmap file /tmp/monmap
epoch 0
fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
last_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
min_mon_release 0 (unknown)
0: v1:10.12.1.2:6789/0 mon.gm268-1
1: v1:10.12.2.2:6789/0 mon.gm268-2
2: v1:10.12.3.2:6789/0 mon.gm268-3
2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。
3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：
scp /var/lib/ceph/mon/ceph-gm268-3/keyringgm268-2:/tmp/
scp /var/lib/ceph/mon/ceph-gm268-3/keyringgm268-1:/tmp/
scp /tmp/monmapgm268-1:/tmp/
scp /tmp/monmapgm268-1:/tmp/
4、重做gm268-1和gm268-2 节点mon
ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
切换到/var/lib/ceph/mon目录下
执行：
chown -R ceph:ceph mon/
启动mon服务：
systemctl start ceph-mon@gm268-1.service
查看服务：
$ systemctl status ceph-mon@gm268-1.service
● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2024-10-18 13:21:24 CST; 38min ago
Main PID: 664542 (ceph-mon)
Tasks: 27
Memory: 286.0M
CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
└─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph
Oct 18 13:21:24 gm268-1 systemd: Started Ceph cluster monitor daemon.
Oct 18 13:21:24 gm268-1 ceph-mon: 2024-10-18T13:21:24.793+0800 7fcc5f804700 -1 mon.gm268-1@0(probing) e11stashing newest monmap 11 for next startup
Oct 18 13:21:24 gm268-1 ceph-mon: ignoring --setuser ceph since I am not root
Oct 18 13:21:24 gm268-1 ceph-mon: ignoring --setgroup ceph since I am not root
节点修复完成。
节点二上
ceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
切换到/var/lib/ceph/mon目录下
执行：
chown -R ceph:ceph mon/
启动mon服务：
systemctl start ceph-mon@gm268-2.service
$ systemctl status ceph-mon@gm268-2.service
● ceph-mon@gm268-2.service - Ceph cluster monitor daemon
Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2024-10-18 13:09:42 CST; 51min ago
Main PID: 157382 (ceph-mon)
Tasks: 27
Memory: 587.1M
CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-2.service
└─157382 /usr/bin/ceph-mon -f --cluster ceph --id gm268-2 --setuser ceph --setgroup ceph
检查集群状态：
$ ceph -s
cluster:
id: ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
health: HEALTH_ERR
3 failed cephadm daemon(s)
failed to probe daemons or devices
2 mgr modules have failed
mon gm268-1 is low on available space
22 pgs not deep-scrubbed in time
1 slow ops, oldest one blocked for 2805 sec, mon.gm268-3 has slow ops
services:
mon: 3 daemons, quorum gm268-2,gm268-3,gm268-1 (age 39m)
mgr: gm268-2.zttohs(active, since 51m), standbys: gm268-3.sjagqo, gm268-1.jgdvxs
mds: cephfs:1 {0=cephfs.gm268-3.ppyjrl=up:active} 1 up:standby
osd: 41 osds: 41 up (since 46m), 41 in (since 20h); 185 remapped pgs
data:
pools: 5 pools, 11265 pgs
objects: 42.48M objects, 115 TiB
usage: 232 TiB used, 365 TiB / 597 TiB avail
pgs: 800589/84967110 objects misplaced (0.942%)
11080 active+clean
184 active+remapped+backfill_wait
1 active+remapped+backfilling
io:
recovery: 22 MiB/s, 6 objects/s
以下是其他的地方处理过程：
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 监控器
# systemctl stop ceph-mon@<host-name>
// 获得ceph monmap
# 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节点就可以
其他文献解决办法：
1 问题
一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢？
如果ceph的monitor节点超过半数挂掉，paxos算法就无法正常进行仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。
If there are not enough monitors to form a quorum, the ceph command will block trying to reach the cluster. In this situation, you need to get enough ceph-mon daemons running to form a quorum before doing anything else with the cluster.
所以，
（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。
（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？
2 恢复
其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。
添加monitor的步骤：
$ ceph mon getmap -o /tmp/monmap # provides fsid and existing monitor addrs
$ ceph auth export mon. -o /tmp/monkey # mon. auth key
$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey
所以，只要得到monmap，就可以恢复monitor了。
为了模拟，考虑2个monitor节点，挂掉一个，此时通过网络访问ceph的所有操作都会被阻塞，但monitor的本地socket还是可以通信的。
NewImage
但是，让人蛋疼的是通过socket不能进行monmap的导出。不过，幸好有monmaptool工具，通过它，我们可以手动生成(注意fsid)：
# monmaptool--create--add vm2 172.16.213.134:6789 --add vm3 172.16.213.135:6789 --fsid eb295a51-ec22-4971-86ef-58f6d2bea3bf --clobber monmap
monmaptool: monmap file monmap
monmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
monmaptool: writing epoch 0 to monmap (2 monitors)
将正常monitor节点的mon key拷贝过来：
# cat /var/lib/ceph/mon/cluster1-vm2/keyring
key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==
caps mon = "allow *"
然后初始化：
# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
ceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3
最后，启动故障节点：
# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789
NewImage
一切OK! 最近还发现一个问题就是一个节点上存在磁盘空间超过80%之后，mon的服务也会停止。这个很隐形的问题。需要注意。
页:
[1]