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

admin

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


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


5 W0 q8 s0 `! K1 O
! u: x. A: i/ Q+ zceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]

( I; b$ |6 P7 t) J. ~" S2024-10-17T22:33:47.295+0800 7f20fe7fc700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
2024-10-17T22:33:47.297+0800 7f20ff7fe700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
  X, |0 Z: J5 S1 f2 W# h& ^! x


环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。
# f! ~$ A! m, H5 G) u: y! j0 w
" p1 f* X. `% _; x5 x+ P3 O& ^, c结果过程：

1、在gm268-3节点上导出monmap文件：

1 d. h; D6 D" `) z  u/ U4 a% g! O5 [
$ 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
- z- o- @7 E, L  W$ umonmaptool: monmap file /tmp/monmap
, `! E7 X& @% P7 {3 ymonmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
% e5 r, [: j" @  l+ l8 N, Fmonmaptool: writing epoch 0 to /tmp/monmap (3 monitors)

( R' H0 L* A$ E7 p) o' n1 t
导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。
5 `5 J0 n6 G! e
! O6 Z5 F" l7 M  U3 @查看下导出的文件信息：

$ monmaptool --print /tmp/monmap
; ]' A! w) p1 F! M# }monmaptool: monmap file /tmp/monmap
% T; ]: a$ ~$ C/ ^( V! O3 pepoch 0
$ E# X1 I) m% [3 M7 R! C. @fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
5 n) ~) U9 {1 H( y( J" Vlast_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
min_mon_release 0 (unknown)
9 D8 e) d3 ]- [( \7 a0: v1:10.12.1.2:6789/0 mon.gm268-1
% V9 V+ g3 P, w" o1: v1:10.12.2.2:6789/0 mon.gm268-2
2: v1:10.12.3.2:6789/0 mon.gm268-3



5 r+ T; }, v: P. S; W$ c/ z) s; p2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。

: e7 @5 I+ {) J
3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：

) l1 A6 D# I& x6 h3 O6 a- l scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/
8 u8 F! }- i. q" r4 `
scp /tmp/monmap  gm268-1:/tmp/
9 w" W: p+ C8 G( B# Pscp /tmp/monmap  gm268-1:/tmp/


' S- K7 `8 a  T2 l3 F9 d+ B4、重做gm268-1和gm268-2 节点mon  
ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
/ I* a1 `, T0 T7 T( y
+ S1 j+ N) z/ f) z切换到/var/lib/ceph/mon目录下
执行：
chown -R ceph:ceph mon/

' I- X( u1 e) O$ C8 f# E% m2 K% k启动mon服务：
! B$ V9 ]* S5 y+ qsystemctl start ceph-mon@gm268-1.service
" [5 s4 N* F( p1 ^7 E' P. r
9 P+ l/ R( J# o4 v8 V1 a$ o: m9 w查看服务：
0 o, c+ L: V. q" V+ S; e
$ systemctl status ceph-mon@gm268-1.service
● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
1 O" a& {* I) Q9 S  r4 X' K3 Q" D   Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
& a5 Z: D2 _! @3 w( k) u3 U; n   Active: active (running) since Fri 2024-10-18 13:21:24 CST; 38min ago
- p* m& u4 e) o5 J" f8 j Main PID: 664542 (ceph-mon)
% `+ ^' H% y2 T% X8 |    Tasks: 27
" M8 ]8 d( C9 s: `& o   Memory: 286.0M
   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
; K* A/ k  c6 |+ r           └─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph

' B' u# `' F" R' Z1 J0 I( F2 mOct 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
" p% H. {5 b$ u7 [" JOct 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

3 e8 v# Q. R3 ^( x9 c& C( O( K4 i
& E. ?: t* {0 P! `! ^. Z" a节点修复完成。
3 }1 C0 Z, w0 R6 D* {节点二上

8 J9 X' M; y. W6 C+ H9 Jceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf

切换到/var/lib/ceph/mon目录下
执行：
5 W% j* P7 v1 X0 J( l( lchown -R ceph:ceph mon/

启动mon服务：
% ^1 b. }0 b  `" K9 k7 Usystemctl start ceph-mon@gm268-2.service

8 ~, L. E- S1 Z% N- H6 g

$ systemctl status ceph-mon@gm268-2.service
! _# A$ e9 K$ s7 i& e● ceph-mon@gm268-2.service - Ceph cluster monitor daemon
   Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
  z( ^! L1 s* L: @: p; s   Active: active (running) since Fri 2024-10-18 13:09:42 CST; 51min ago
Main PID: 157382 (ceph-mon)
7 t+ n5 A+ Q- w5 H3 {7 b3 p- u5 J    Tasks: 27
   Memory: 587.1M
9 F( V9 e6 S; _. d   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-2.service
/ y4 C/ y1 `* L: T/ K           └─157382 /usr/bin/ceph-mon -f --cluster ceph --id gm268-2 --setuser ceph --setgroup ceph
3 W1 `2 A( ^) ^$ r- r) c3 R9 W2 g% a. B

9 k  w3 @+ }/ Q" f

admin

检查集群状态：
3 p0 L1 D! A0 r4 G; Z8 I7 m, [$ ceph -s
  cluster:
6 E- R3 _: ]- t7 y6 u& U; t    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
    health: HEALTH_ERR
            3 failed cephadm daemon(s)
# L1 G3 |" {! x. H' ^+ B. b            failed to probe daemons or devices
$ d4 x. ?# x# m5 j8 y            2 mgr modules have failed
            mon gm268-1 is low on available space
4 n3 L1 g3 O+ d% o  q            22 pgs not deep-scrubbed in time
            1 slow ops, oldest one blocked for 2805 sec, mon.gm268-3 has slow ops
! c5 k  s' a# L7 r& B- ]( k
# h. Q9 f( J/ e! r# }  services:
, A. k4 @! L* q3 ^" w8 N    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
7 w  e! N3 u0 {3 C7 I# U4 _
  data:
$ l( S0 {. z8 W+ W    pools:   5 pools, 11265 pgs
    objects: 42.48M objects, 115 TiB
    usage:   232 TiB used, 365 TiB / 597 TiB avail
" ?# k2 M9 ]; t2 a8 S/ i    pgs:     800589/84967110 objects misplaced (0.942%)
' J0 o# v7 o3 ^) G7 E$ L9 p             11080 active+clean
             184   active+remapped+backfill_wait
3 j5 W* J0 t3 ?) R             1     active+remapped+backfilling
9 ]2 Z3 l) \: F  l
4 ]2 ~, J  F! U5 R  io:
    recovery: 22 MiB/s, 6 objects/s

admin

以下是其他的地方处理过程：
ceph mon节点迁移
有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。
& C0 ]) y/ a2 b
; I! |* c& H9 b" ?. X8 R1 h( W% w离线迁移主要涉及到的就是mon节点的改变。
4 w" _9 O) Q2 B; r5 d8 n, m; j  f解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon

获取集群当前monmap(搬迁前进行)
获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。
1 i0 ~1 x3 m1 t) o! i( f
如果剩余的 Ceph mon能够形成仲裁(多数存活)，请使用 ceph mon getmap 命令获取 Ceph monitor map：

7 v9 i9 {) J+ e+ Mceph mon getmap -o /tmp/monmap
% {0 A9 D& q4 B5 X; N( H" U如果此时ceph的mon已经不能够形成仲裁了(多数mon挂了)，那么在健康的正确的mon机器上通过如下步骤获取monmap
( I) ~8 h$ u& O+ y8 k
// 停止您要复制 Ceph monitor map 的 Ceph 监控器
# z( k* G! _, |" }, `  h- B' p[root@mon ~]# systemctl stop ceph-mon@<host-name>
// 获得ceph monmap
. {# y; s8 ]# w# J( u" w/ }% `4 T+ W[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？
' C& i+ X9 G. J6 ]( u
( ?  y' \: [1 w8 |' p& i* p$ x1 B/ {当然，也是有的，可以借助ceph-monstore-tool和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来恢复它，具体详情请参考: 使用 BlueStore 时恢复 Ceph monitor 存储
  [( p& w7 }( \. f4 s$ ~
! l+ R; W5 J5 w: r9 \* Z删除临时monmap中的老的mon
# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
" x0 f2 z( p  v0 lmonmaptool: monmap file /tmp/monmap
monmaptool: removing node1
, Y+ z, `7 j4 H! wmonmaptool: removing node2
monmaptool: removing node3
monmaptool: writing epoch 1 to  /tmp/monmap (0 monitors)
3 O+ F* O' S( @( X" g& ~$ v  Y; R! t向临时monmap中添加新的mon
5 ~7 d; o! c% Q# H  ?# 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
" J- f$ r' _4 t% `  Dmonmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
停止所有mon服务并注入monmap
. T+ A5 U/ _- ~6 Q2 K. j8 H# t首先要先确保新的mon已经在新的服务器上安装起来了，然后stop掉mon进程，每个mon新节点都要执行
* D' [+ u/ I6 Q6 c+ Y* k5 Q
2 W8 J' D9 x) c& h+ b- kceph-mon -i {mon-id} --inject-monmap /tmp/monmap
( o5 M7 Z; R) K, g5 \, c2 ?5 v更新所有服务(mon,mds,client,mgr,osd等)的ceph.conf
8 D& B+ N/ f) w8 J4 H! a+ y( l这里需要注意的是如果新ip的网段也有变化的话，那么除了要更新ceph.conf文件中mon\_host信息，还要更新public network/cluster network的网段信息

3 o2 d+ k/ j+ d) K, B+ Q同步的话可以通过ceph-deploy命令
/ p$ I( }: N  }, K1 P1 ]( d/ p* X
ceph-deploy --overwrite-conf config push node{1..3}
关于上层服务
使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更

4 {/ d% d4 Z% K# }ceph文件系统直接挂载+rbd挂载
; @& L" i" P5 a5 I直接把新的ceph.conf同步到client节点就可以

admin

: y* w. f! |" t8 q. B: P其他文献解决办法：

1 问题
0 b# l9 V2 O1 I. A
一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢？
! R3 {+ f  _* b2 P
如果ceph的monitor节点超过半数挂掉，paxos算法就无法正常进行仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。

/ n, v* k% q" b6 sIf 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 [# e! ^& q7 g* D  {4 w所以，

（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。

（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？
3 A! J: A1 o* `/ I4 {* c- n: g+ v
/ x1 e; r, U+ [) s# o/ U8 v2 恢复
其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。
. ^8 a3 c" v- g2 z9 @
  T+ D$ `$ T6 o# k, p7 U* c
; ]6 G1 J+ ?/ B% n6 p# a
6 R$ F. C+ |, L添加monitor的步骤：

$ ceph mon getmap -o /tmp/monmap           # provides fsid and existing monitor addrs

$ ceph auth export mon. -o /tmp/monkey     # mon. auth key
$ F. W; e0 b2 k' [  }! l
$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey
6 z. z3 E/ w( t
% b: y9 H2 D& @, R所以，只要得到monmap，就可以恢复monitor了。

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

& _8 y) s( u8 y$ e3 UNewImage

% x. `* L# E" q) ?7 ?. p% N" B: q

但是，让人蛋疼的是通过socket不能进行monmap的导出。不过，幸好有monmaptool工具，通过它，我们可以手动生成(注意fsid)：
6 t, V/ {) Y) _6 ?! a
# monmaptool  --create  --add vm2 172.16.213.134:6789 --add vm3 172.16.213.135:6789 --fsid eb295a51-ec22-4971-86ef-58f6d2bea3bf --clobber monmap
) l" E' I2 \. o: _$ W
monmaptool: monmap file monmap

monmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
) P: C" K( O7 F
monmaptool: writing epoch 0 to monmap (2 monitors)
/ P6 F  J9 b' c# B& |6 V
$ H4 [6 p, G& p8 d  D8 E将正常monitor节点的mon key拷贝过来：

3 z, S- R: ^% p2 h3 v3 o  e8 ~/ m# cat /var/lib/ceph/mon/cluster1-vm2/keyring
/ o7 v* g1 Z+ n+ y( w5 ]6 U
[mon.]
5 J. K. z' n) H, ^( l* t
        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==
2 u6 r/ Q, h2 |+ \
' Y( O' b: R2 L' {& B        caps mon = "allow *"
1 `1 N: S. h' W' e; s

. d$ s4 @$ W! r1 @
然后初始化：
& X1 I: L1 X6 D7 G7 w
3 `' J/ \! ~% W/ o. z# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
& @4 y* G; U& D3 j# ]1 _
ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
+ n; L% s9 Y/ `- B, _# l
ceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3
0 e1 ?/ F0 j3 W1 r5 w
' V/ u0 C' p" k6 w最后，启动故障节点：

2 }0 l. N) T, p) Z! _7 v6 Z# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789
! W2 i* }) _1 ]! Y% `


NewImage
% b% \) q8 l! z2 U& o' c
一切OK!

admin

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