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

admin

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

- A. g8 H; [) U" o, ?
ceph一直无法正常的执行ceph -s命令；

9 Z3 w2 X$ |7 L0 _' y6 z
8 I0 U, W+ z3 @3 V
ceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
8 a* B# z3 e* R
* l" v% y# F) G- w3 q  V/ |7 ^2024-10-17T22:33:47.295+0800 7f20fe7fc700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
+ b0 y) a8 \/ A4 H0 x2024-10-17T22:33:47.297+0800 7f20ff7fe700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
) B+ A" z3 V* B& Y2 l1 \, d
) W7 h9 v+ I8 e" \6 l
; M5 d, E9 i* Y6 E9 p0 A
) f3 p, x4 M5 V环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。
* v" h" H# ?: I& P3 x1 y+ u
结果过程：

1、在gm268-3节点上导出monmap文件：
9 S0 L5 _: J+ q8 ?9 Z7 B$ l
$ ~+ _. s7 \8 G3 E/ ]
$ 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
& N6 Z0 t( S0 V  b" \5 fmonmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
& ~* Z) {+ V' N1 x5 Lmonmaptool: writing epoch 0 to /tmp/monmap (3 monitors)

' c1 Y" J* l& K" K
+ N) i' A& A% {3 Q. F( N导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。

查看下导出的文件信息：

3 d; s% e5 ?; L/ m$ T/ x, u0 a" M6 V$ monmaptool --print /tmp/monmap
monmaptool: monmap file /tmp/monmap
4 _& @. \! s; S* Lepoch 0
fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
* Z2 d8 W6 `# F# C$ B& i9 Y5 Xlast_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
) U- x7 M! j# m- K# mmin_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



4 Z, e3 v# b' b: @+ R2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。
) Q6 Y3 g/ h# |% q! l" z
' n; K. m* K6 s+ ?& `
4 ]7 }# [! s/ H3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：
  B1 x1 B+ d6 w  ~/ o5 `8 u
scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
' ]6 v' U' M6 {! ~scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/

) T* @5 \6 ?* s  q" fscp /tmp/monmap  gm268-1:/tmp/
scp /tmp/monmap  gm268-1:/tmp/


4、重做gm268-1和gm268-2 节点mon  
* V( @9 G0 W7 k$ P) ]; c9 i" [" zceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
7 l  A, ~. o/ T+ G/ \* A6 D
切换到/var/lib/ceph/mon目录下
1 \* U0 |" N" k: ~执行：
chown -R ceph:ceph mon/
" K1 B* }1 f9 [# k! c5 t
' G% Q, p. u% x% ?启动mon服务：
systemctl start ceph-mon@gm268-1.service
( k1 o$ A+ L  I6 l' G
6 I/ C& z+ l( S6 T; r% X" T3 }查看服务：
% D% A# r/ y9 U* d7 n( D$ j
2 q, H, G2 f( j* X% `6 y$ systemctl status ceph-mon@gm268-1.service
$ }" @4 H  V5 r6 y3 x4 P' e0 Q● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
   Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
) d! H  @% {5 L   Active: active (running) since Fri 2024-10-18 13:21:24 CST; 38min ago
Main PID: 664542 (ceph-mon)
0 [  J$ \& F6 w8 i    Tasks: 27
1 p- s& v7 F" c, {   Memory: 286.0M
   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
4 W  D; }) c" g  N5 R. q; g+ O, @           └─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph
# i' h2 Q$ {4 \
Oct 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
Oct 18 13:21:24 gm268-1 ceph-mon[664542]: ignoring --setuser ceph since I am not root
Oct 18 13:21:24 gm268-1 ceph-mon[664542]: ignoring --setgroup ceph since I am not root

7 s* p! Q9 w- {; g" n& x0 D. A# M3 i4 s
节点修复完成。
节点二上
7 |* {9 L' o% F0 h
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服务：
+ Y4 l1 ]7 r+ u, Esystemctl start ceph-mon@gm268-2.service
' y/ \8 k7 t/ ?. L
) q  t! ^3 s' _% `

$ systemctl status ceph-mon@gm268-2.service
● ceph-mon@gm268-2.service - Ceph cluster monitor daemon
, k: |/ y% H* f& J& l# t  ^& d; Q   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)
, n* H) }+ ~5 K    Tasks: 27
   Memory: 587.1M
5 d0 _: I  O. P( v* y- X. x0 F   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-2.service
: T8 R# j0 L4 v           └─157382 /usr/bin/ceph-mon -f --cluster ceph --id gm268-2 --setuser ceph --setgroup ceph
$ \1 ^- x2 b: e* M* s6 `

, c# k' c& r. m+ |0 h4 U3 N2 v( T4 G

admin

检查集群状态：
$ ceph -s
) e- d$ j/ J% S! u- P! U& f0 X  cluster:
2 y1 P9 }) [; [    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
3 ]5 |0 _. k6 u/ J3 L' m9 t' K    health: HEALTH_ERR
: _0 W) {# N- ~7 X. O            3 failed cephadm daemon(s)
$ i  ^6 X) }+ |4 X6 E9 C4 p! D            failed to probe daemons or devices
" _* U3 C  k( i' s3 o5 q            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
/ x7 a. I% y& r0 H# o  M/ T
  services:
' y: a" @/ ~$ n# O5 J    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
0 A+ p) P* K/ U1 K% i/ m& N    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:
' }& P2 N8 b; G+ y  x    pools:   5 pools, 11265 pgs
; {* G- {+ U+ b9 s! }6 {( {* ^    objects: 42.48M objects, 115 TiB
+ g4 w. M, g: W& X( M5 \8 Q    usage:   232 TiB used, 365 TiB / 597 TiB avail
) Z: o: q. x$ p$ s) w- W% P    pgs:     800589/84967110 objects misplaced (0.942%)
, W7 L: ^5 Y9 g3 J+ B& Z             11080 active+clean
             184   active+remapped+backfill_wait
             1     active+remapped+backfilling

  io:
    recovery: 22 MiB/s, 6 objects/s
. y$ n- h, O2 {* ^

admin

以下是其他的地方处理过程：
) V. J7 n6 _2 u! G0 c0 }ceph mon节点迁移
2 L$ ?( A2 p0 O$ _& W/ j& E: s8 s1 a7 [有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。

离线迁移主要涉及到的就是mon节点的改变。
解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon
( Y7 d! }8 \4 x, B
获取集群当前monmap(搬迁前进行)
获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。
* {% ^/ n6 L% r; S- U# J( f! l
: O8 m$ k' g5 C1 M  `2 @如果剩余的 Ceph mon能够形成仲裁(多数存活)，请使用 ceph mon getmap 命令获取 Ceph monitor map：
  h( z! l. J8 K: J
ceph mon getmap -o /tmp/monmap
" L1 h7 l: t  p8 s/ R如果此时ceph的mon已经不能够形成仲裁了(多数mon挂了)，那么在健康的正确的mon机器上通过如下步骤获取monmap
5 O+ R+ k& ]# a
// 停止您要复制 Ceph monitor map 的 Ceph 监控器
# z) `7 j( D. ^7 n0 T1 }  d[root@mon ~]# systemctl stop ceph-mon@<host-name>
# |' t: l' x$ _* ]/ N, p0 S/ u// 获得ceph monmap
) }" N& u" L3 S. _8 Z5 p[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？
( J  X' f- H# o; G+ @$ V
  k: |& g5 W- [5 N7 ]当然，也是有的，可以借助ceph-monstore-tool和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来恢复它，具体详情请参考: 使用 BlueStore 时恢复 Ceph monitor 存储
8 y% n  p9 J) r1 e- ]
) R) x4 D  F0 J. ^/ F0 N0 H' ]删除临时monmap中的老的mon
1 @- `' Z5 R  B# |; t" I# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
% C# d& k& w* }! @0 k4 T% y* ]monmaptool: monmap file /tmp/monmap
monmaptool: removing node1
. ?$ @- x+ O5 [3 V6 ]  X& vmonmaptool: removing node2
monmaptool: removing node3
% A3 I# R8 m7 X! `0 n3 M0 k$ O3 Imonmaptool: writing epoch 1 to  /tmp/monmap (0 monitors)
向临时monmap中添加新的mon
" d7 f. m1 r4 ~* a- O# 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
/ I; g7 g& k- Nmonmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
1 E$ G2 `& Z/ F3 E- V& @' X停止所有mon服务并注入monmap
7 k3 v: @/ w2 N8 m首先要先确保新的mon已经在新的服务器上安装起来了，然后stop掉mon进程，每个mon新节点都要执行
8 y7 q( A; I  B1 x5 f2 U
ceph-mon -i {mon-id} --inject-monmap /tmp/monmap
% n  l+ w: v. [8 c更新所有服务(mon,mds,client,mgr,osd等)的ceph.conf
这里需要注意的是如果新ip的网段也有变化的话，那么除了要更新ceph.conf文件中mon\_host信息，还要更新public network/cluster network的网段信息
* ^4 y" ^) Z3 z4 o9 ^- Y% d7 t
同步的话可以通过ceph-deploy命令

* b1 |# D9 J" b) ^% R" S" Rceph-deploy --overwrite-conf config push node{1..3}
关于上层服务
$ ]3 @: Y; h$ ]0 o, I: B使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更
* N* E+ j- j5 i1 a: w+ T& z/ g
2 H$ M$ F# g) J2 e: Z/ iceph文件系统直接挂载+rbd挂载
直接把新的ceph.conf同步到client节点就可以

admin

其他文献解决办法：

1 问题
% k' ~: w- Q" k; W+ ~( t
2 ]7 P* Y( K+ h3 }4 P) X: f7 s一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢？
! o" w6 ], @$ ?& g
3 {2 E+ K) ^$ F' p如果ceph的monitor节点超过半数挂掉，paxos算法就无法正常进行仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。

2 d4 \/ |% v) L1 f+ pIf 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.

% x8 v4 W: J6 d0 ?2 R" o0 Z
2 l! c7 m( E1 B% T! W5 h6 S
所以，
$ \$ \/ b* _+ h* m3 z
（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。

（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？
8 z8 W! d8 O* [
8 h  N- R6 e8 e8 {5 G% C: d2 恢复
9 L! q( _" U, U. T7 l# ?$ C其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。


, ^1 v, }* G' T9 S" l* D9 L4 ]
添加monitor的步骤：
7 X3 L5 {& f, e  }# |" p
, C/ w0 j# S( y1 A1 p$ ceph mon getmap -o /tmp/monmap           # provides fsid and existing monitor addrs

$ ceph auth export mon. -o /tmp/monkey     # mon. auth key
0 H" b. H3 i0 F6 ]8 s* A" T: s% y
6 F) d. b* T7 M! Q0 E& o3 o$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey
! @; E& l4 D+ \# u
9 r) v2 i, _1 o7 T& F所以，只要得到monmap，就可以恢复monitor了。

为了模拟，考虑2个monitor节点，挂掉一个，此时通过网络访问ceph的所有操作都会被阻塞，但monitor的本地socket还是可以通信的。
' L; O! X8 `: c
NewImage


! ^8 V  ]  }6 F' u9 U
* V$ t5 ^4 u2 G* k( z# i. C5 b但是，让人蛋疼的是通过socket不能进行monmap的导出。不过，幸好有monmaptool工具，通过它，我们可以手动生成(注意fsid)：

5 |* ]" a- W4 F% y/ s$ L1 Q# monmaptool  --create  --add vm2 172.16.213.134:6789 --add vm3 172.16.213.135:6789 --fsid eb295a51-ec22-4971-86ef-58f6d2bea3bf --clobber monmap
( m. X" V: ~. J' S4 T3 x6 ?$ }
8 ?, J3 @: X4 A0 z3 C3 Smonmaptool: monmap file monmap
1 i( ]5 M; b% o4 ?
monmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
% `( P( [: ?* l2 d
monmaptool: writing epoch 0 to monmap (2 monitors)
3 {, M) \; `9 w& X. H
将正常monitor节点的mon key拷贝过来：

# cat /var/lib/ceph/mon/cluster1-vm2/keyring
' ~" c! i. X( e/ v- p
[mon.]

        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==

        caps mon = "allow *"



8 I. v( Y+ E8 B% n; E2 Y然后初始化：
5 Z$ Q7 i" H4 Z9 D( F0 j
/ x6 u& K. j! G- }# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
# e5 u$ }, ^. V2 V) @& }
% N7 M6 V) u$ ~8 `5 Y$ vceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

  P3 E2 r1 y) wceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3
& v9 Q4 l& L, g9 P+ _: c
最后，启动故障节点：
: }; x, y+ p% z4 I9 F* b
# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789



9 p& W2 I3 S" u5 h* h! y NewImage
8 }+ m+ K0 }# t: b" a3 J
一切OK!

admin

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