ceph存储当mon节点全部出现问题的时候或者单独一个节点出现问题时恢复过程

admin

当mon节点全部出现问题的时候或者单独一个节点出现问题时恢复过程


ceph一直无法正常的执行ceph -s命令；



ceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
' N+ H( @* v' [3 n1 l9 y7 o8 @' J
2024-10-17T22:33:47.295+0800 7f20fe7fc700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
! }$ U3 v1 o3 B# J4 t2024-10-17T22:33:47.297+0800 7f20ff7fe700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
# h9 [. \9 z/ w8 {9 v" k

4 h; I; L- D! a
+ y) s$ _. @. c# i0 G环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。

结果过程：
" K, v" }/ J: a! M+ {9 e6 f8 m
1、在gm268-3节点上导出monmap文件：
* l" \; T  B6 W; ?3 Q" n) i$ u

% B+ b  Z* E; p6 b( B0 [7 u$ 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
5 m+ B3 p6 x' f5 ?9 p5 @) Y# Imonmaptool: monmap file /tmp/monmap
* \3 [) \1 H* l% i: m# Qmonmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
monmaptool: writing epoch 0 to /tmp/monmap (3 monitors)
" T3 p  R5 t8 W

导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。
- ^0 ~- T, u# B0 K! {" h
查看下导出的文件信息：

$ monmaptool --print /tmp/monmap
) @' g3 C, t6 ?& W1 a1 P% p  s$ Vmonmaptool: monmap file /tmp/monmap
epoch 0
, |4 a3 ]( l/ }; n+ f' m6 afsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
1 }& r( s& [9 B; Olast_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
! j- M$ g# |! y9 r8 T1 S/ q  _min_mon_release 0 (unknown)
6 H# h8 Z! S$ Z$ Y0: v1:10.12.1.2:6789/0 mon.gm268-1
. ^( i: G) u9 ~# `: X( I1: v1:10.12.2.2:6789/0 mon.gm268-2
2: v1:10.12.3.2:6789/0 mon.gm268-3


' t, v6 ^$ D, g" x2 M/ A
6 Z' b% s& j$ u8 W2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。
  Z1 }* N* x9 f' o* X8 G, w% T; H

5 C6 [; X% g7 p4 u3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：

scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
( b& D8 Z4 X; k! I1 g; }) V( {; Oscp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/
3 R0 u# w+ S5 a
& o, l; W: h2 I4 H7 @scp /tmp/monmap  gm268-1:/tmp/
scp /tmp/monmap  gm268-1:/tmp/
- g5 }, R* H  i3 `5 a" a, M4 c% F

( [0 t  V* c' k$ r* O# M4、重做gm268-1和gm268-2 节点mon  
ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf

( ]4 c- I6 d! r切换到/var/lib/ceph/mon目录下
执行：
8 V9 `3 G* @$ F4 m  p4 S$ I2 s6 wchown -R ceph:ceph mon/

启动mon服务：
systemctl start ceph-mon@gm268-1.service
+ l1 y% w( K& W7 R
查看服务：
( F+ i! Z- S7 v9 p3 g. s
% \# b8 W4 q' S5 h( B$ systemctl status ceph-mon@gm268-1.service
● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
( d4 l7 V7 ?9 K7 B7 x1 [   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

; O# u) H* }8 E1 sOct 18 13:21:24 gm268-1 systemd[1]: Started Ceph cluster monitor daemon.
Oct 18 13:21:24 gm268-1 ceph-mon[664542]: 2024-10-18T13:21:24.793+0800 7fcc5f804700 -1 mon.gm268-1@0(probing) e11  stashing newest monmap 11 for next startup
& k$ D6 T/ q, GOct 18 13:21:24 gm268-1 ceph-mon[664542]: ignoring --setuser ceph since I am not root
# {0 N5 a' S) o6 O; ^9 B. p" QOct 18 13:21:24 gm268-1 ceph-mon[664542]: ignoring --setgroup ceph since I am not root
3 T& p0 d8 f3 Y. r7 L8 ?$ U0 T; v
$ @$ x, K/ w; f% U+ `
节点修复完成。
, N4 j7 `( W- v" q/ q. d4 |节点二上
- D3 }* P+ g/ f8 ?( x! f
ceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
+ T- V: h/ c/ |' m3 }5 Y* }0 |
; u$ ?0 ^6 j+ R  u( z切换到/var/lib/ceph/mon目录下
执行：
( Q/ g, Z6 C/ x7 K& N! Cchown -R ceph:ceph mon/
5 `2 F) |9 y  P3 N" i( Y
启动mon服务：
systemctl start ceph-mon@gm268-2.service
4 G8 [% ?, h5 a2 l7 O; W


$ 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
1 r4 m, u  Z8 { 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


$ {1 [: r& e+ h9 y$ }

admin

检查集群状态：
$ T# R! J+ a: M2 J+ M) z0 n8 h; u$ ceph -s
& t0 h+ [% X+ }* Z. Q  cluster:
  T% v& I9 F" y+ [$ V, Y' r# F8 S    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
    health: HEALTH_ERR
7 [2 ~+ A- K) {/ E% Y+ {+ j            3 failed cephadm daemon(s)
! Y6 o0 F) Y9 X2 N            failed to probe daemons or devices
            2 mgr modules have failed
) z0 h! P5 [  K, a$ [& H            mon gm268-1 is low on available space
            22 pgs not deep-scrubbed in time
! o! B6 T9 C9 K5 r; P7 q' M            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)
. p; F( u8 |! `    mgr: gm268-2.zttohs(active, since 51m), standbys: gm268-3.sjagqo, gm268-1.jgdvxs
. h- O9 Q) O; X  U+ q. u    mds: cephfs:1 {0=cephfs.gm268-3.ppyjrl=up:active} 1 up:standby
6 b: s# y8 i  F' B    osd: 41 osds: 41 up (since 46m), 41 in (since 20h); 185 remapped pgs
3 x' l( q9 [& t# M+ X- i2 k- m
  data:
    pools:   5 pools, 11265 pgs
6 X5 _/ N( Z* S. b5 [* \" ?* U9 K. W    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
: w5 X+ r! D  r" P0 P, d0 J% R- o             1     active+remapped+backfilling

  io:
    recovery: 22 MiB/s, 6 objects/s

admin

以下是其他的地方处理过程：
ceph mon节点迁移
& d5 d1 P6 g* B4 ~3 b/ ?! G2 n有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。

' I3 @# j. f2 O1 W" V& c- L3 \离线迁移主要涉及到的就是mon节点的改变。
8 @0 x+ I1 @; `4 ~  y, _) K解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon

. ~' n: `' c2 e' s! k$ K# M+ v1 I获取集群当前monmap(搬迁前进行)
+ w  w8 l, u" _' f4 F获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。

如果剩余的 Ceph mon能够形成仲裁(多数存活)，请使用 ceph mon getmap 命令获取 Ceph monitor map：

ceph mon getmap -o /tmp/monmap
" Q5 n  B' H4 k1 N, b& b  n2 ~$ V; f如果此时ceph的mon已经不能够形成仲裁了(多数mon挂了)，那么在健康的正确的mon机器上通过如下步骤获取monmap
( C7 ], U% H7 z" ^2 d
// 停止您要复制 Ceph monitor map 的 Ceph 监控器
/ S* {* f% t  ~  P% K& j[root@mon ~]# systemctl stop ceph-mon@<host-name>
// 获得ceph monmap
* x7 _* V3 l7 `9 ?( ~2 ^[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？

5 A: o- Q1 h; ]" W当然，也是有的，可以借助ceph-monstore-tool和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来恢复它，具体详情请参考: 使用 BlueStore 时恢复 Ceph monitor 存储
. j( M+ c, M$ m/ D$ M
删除临时monmap中的老的mon
" P" W/ f# o. k8 P5 ]: n: i+ q# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
) h* ^: O4 p3 ?9 Nmonmaptool: monmap file /tmp/monmap
monmaptool: removing node1
monmaptool: removing node2
, _* Q: x2 S# Q9 C0 x2 Hmonmaptool: removing node3
* r/ A8 y7 [3 {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
, x3 X, @+ L" u+ }' lmonmaptool: monmap file  /tmp/monmap
monmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
9 Y3 k# N8 a9 e( ?6 J停止所有mon服务并注入monmap
首先要先确保新的mon已经在新的服务器上安装起来了，然后stop掉mon进程，每个mon新节点都要执行
' I! p  u8 k3 o3 s* ]' |
% x' n% i8 K  i* ?ceph-mon -i {mon-id} --inject-monmap /tmp/monmap
5 D& q4 l, z; {8 f更新所有服务(mon,mds,client,mgr,osd等)的ceph.conf
! K, ?% D2 a' O9 C7 v这里需要注意的是如果新ip的网段也有变化的话，那么除了要更新ceph.conf文件中mon\_host信息，还要更新public network/cluster network的网段信息
, [( v& A  ^" N1 }
4 s/ ~: \6 h+ ^7 h! v" H5 O" t同步的话可以通过ceph-deploy命令
# i3 R& J4 U: J4 ^  \3 F
6 I8 E3 b' L4 D  k: ?9 Hceph-deploy --overwrite-conf config push node{1..3}
关于上层服务
使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更
- Z$ A# D4 s- `) w3 t
ceph文件系统直接挂载+rbd挂载
直接把新的ceph.conf同步到client节点就可以

admin

其他文献解决办法：
: L& p1 l  n! B& Z# l1 o% }! \
( q" L$ Y0 f9 y- P# c1 问题
5 r7 J6 A3 A  a- ?5 W
一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢？
) B6 m1 c. b6 ]6 k- L9 _8 W5 G5 ?
4 c* V' X7 W8 R. J- ^5 ^如果ceph的monitor节点超过半数挂掉，paxos算法就无法正常进行仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。

  ~6 H3 u! U( Z  n( f9 m& rIf 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.
6 |* |% ]% H# ?$ u
2 T+ y: N, Q8 X; M5 D
  w- \# y1 E3 A+ @1 k7 C0 p  l
所以，

2 z1 v$ ?  d) ^7 R- v（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。
  d' \* L! P0 P+ q9 Y! V: y8 T
（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？

2 恢复
其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。
8 r6 y5 k' Y8 J7 l7 k7 [

8 i$ o% u$ W3 Q: @% W
$ T- f# A& [) l. K0 t+ p添加monitor的步骤：
8 v- M: s2 [  q5 ^5 }' U' m
( I) }; S5 O# O- a$ ceph mon getmap -o /tmp/monmap           # provides fsid and existing monitor addrs
6 Q! ~/ n/ d' l, A# b3 I/ Z2 t5 C% q
3 E# N$ M" s4 L; R: X8 @+ U$ ceph auth export mon. -o /tmp/monkey     # mon. auth key
, W6 \  h( Z/ \, L9 u
$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey
% M1 U! H4 u/ X, B% L- v& s8 b
所以，只要得到monmap，就可以恢复monitor了。
6 o3 E$ a, k" @; z
为了模拟，考虑2个monitor节点，挂掉一个，此时通过网络访问ceph的所有操作都会被阻塞，但monitor的本地socket还是可以通信的。
5 \! G# T1 ]6 h3 j% G
NewImage



但是，让人蛋疼的是通过socket不能进行monmap的导出。不过，幸好有monmaptool工具，通过它，我们可以手动生成(注意fsid)：

* b2 x0 n7 B% j, {: T# 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
* \1 o7 \( c+ N8 F9 n! Y' ]7 j
1 F$ C- S% W% Z( L: ?1 L# kmonmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

% U# Y: o5 f; ]8 P+ n" Pmonmaptool: writing epoch 0 to monmap (2 monitors)

将正常monitor节点的mon key拷贝过来：
; e0 R; x  A$ f. c+ p7 F
8 `; z) W( ?4 C# U% d1 n# cat /var/lib/ceph/mon/cluster1-vm2/keyring

[mon.]

        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==

        caps mon = "allow *"



然后初始化：

# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
) r% g' r/ U; J- j; c3 j
ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
* ^6 N# x! A% J. y( R" m+ {8 ]
& ^) h2 Q4 `; N' ^5 ]ceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3
% c" W5 [3 o: y3 h
最后，启动故障节点：
6 X; M: X  d$ ]) z$ U5 R
1 v( `, {- {/ d# f( i# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789
; L8 D( B9 Y. W

) }% c2 _# X3 Q# q+ Z+ N
- }2 [, \5 x# M" P+ h NewImage
/ i4 N- B7 f7 N! v+ @% x
$ j# l1 R- O0 e7 d  }" T+ j. R3 j& }一切OK!

admin

最近还发现一个问题就是一个节点上存在磁盘空间超过80%之后，mon的服务也会停止。这个很隐形的问题。需要注意。