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

admin

当mon节点全部出现问题的时候或者单独一个节点出现问题时恢复过程
& N; w2 c* I7 z" D' c  R5 A. K
3 C+ l( ~. H1 {8 k( [3 o! {
& o* T( ~. J4 Lceph一直无法正常的执行ceph -s命令；
, W4 p2 L4 [: m& e! W  E9 s) |
" @  S1 Y3 G2 K. i! ]
  C* c2 ^* J$ u" V& }5 _
/ S# z5 u" ~0 w. N# P4 j' Cceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]

2024-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' D6 j% M- F. K
5 N9 J1 K" W$ r4 x$ x: y4 v) [

0 L5 o) n. j5 C, s6 {* T1 M4 u$ `环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。

结果过程：
* t  q( e0 g) _3 ?0 O0 X$ E
1、在gm268-3节点上导出monmap文件：

( c. A* T- `3 S" l
$ 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
4 Q5 @0 r9 f: [' m4 s6 tmonmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
8 g0 ^* `2 W0 L9 u$ f  Cmonmaptool: writing epoch 0 to /tmp/monmap (3 monitors)
8 b$ x, j; b; ~1 g
" ]( z5 b9 e4 _5 B+ z1 u
导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。

查看下导出的文件信息：

, U: C1 \6 K: ]  g$ monmaptool --print /tmp/monmap
monmaptool: monmap file /tmp/monmap
epoch 0
# r' [. P0 t' Y: k" G1 w; rfsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
! ?6 ~. A7 T" v9 J4 l0 e  E6 ^last_changed 2024-10-18T13:17:03.645872+0800
( _% E. Y9 ?; N% c2 u3 Pcreated 2024-10-18T13:17:03.645872+0800
; I- s# T- F, Lmin_mon_release 0 (unknown)
5 L# M, J- h* t4 T9 m8 K* _0: v1:10.12.1.2:6789/0 mon.gm268-1
: h! m' [5 _6 N2 k/ V1: v1:10.12.2.2:6789/0 mon.gm268-2
2: v1:10.12.3.2:6789/0 mon.gm268-3
) s  l/ L4 T8 \1 J# T6 }3 r8 {
0 i; J, I; e) @/ n
: l! z( [* c6 t7 [; S
8 C% Y- y& p3 ^2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。
% T0 I% o% K$ F3 X

3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：
7 q2 O3 C# T0 g
0 X( [& u3 m/ H scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
7 V6 K4 z( i" B: Z3 xscp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/
" m0 t  A& _. X9 F: G8 H, H
& Z/ W# ]6 @3 x$ }* n4 j/ A! _scp /tmp/monmap  gm268-1:/tmp/
  b: z8 F1 Y( T2 H( yscp /tmp/monmap  gm268-1:/tmp/
) D4 f' N  y8 S- a, H
6 P5 T9 [, _$ ?9 R. V
( f6 Z4 K  L% W4 Q& G% Z& l, y4、重做gm268-1和gm268-2 节点mon  
ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf

5 L' @3 p% Q# U1 @. L" p& X  c切换到/var/lib/ceph/mon目录下
执行：
- D' Z# B( l+ _! Q( U- {1 u& H3 ochown -R ceph:ceph mon/
; D8 L5 ?( `  X2 F
启动mon服务：
systemctl start ceph-mon@gm268-1.service

! L( `0 D4 e1 `7 P/ I查看服务：
1 C  [6 N  u# Y
$ systemctl status ceph-mon@gm268-1.service
; X- O7 ]& M3 {6 [! {, v" k● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
# X( {+ G4 m: ]2 |* u   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
8 B- f) P: W- @) k) Z( Y Main PID: 664542 (ceph-mon)
    Tasks: 27
3 {1 h) g' C" {' R4 z; C. S9 F) `   Memory: 286.0M
' _& _% ~  x2 v: q8 ^9 ~& M   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
( C  l4 h" `+ [& O           └─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph
+ P4 ~$ o# y$ H2 s3 Z5 Q0 X; I
Oct 18 13:21:24 gm268-1 systemd[1]: Started Ceph cluster monitor daemon.
$ g6 Z7 `8 J) c$ T3 _9 A! eOct 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
% r3 C4 {: n) m! I  \( P6 T1 A8 OOct 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
: x. H  l5 z) L6 f4 @

节点修复完成。
节点二上
* C% O) V7 g# l; {7 U
7 R: o  R- h3 S5 |ceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
, H; ]8 q/ {  \$ R3 j1 {( _
  y* s) Q/ E" k% G切换到/var/lib/ceph/mon目录下
. ?( u. e' |* {执行：
$ H+ N1 `& }* Z% N! O% i% Kchown -R ceph:ceph mon/
/ K  {6 L2 H) i9 }, l$ g
启动mon服务：
1 x2 F2 M  T& u) b$ a2 Esystemctl start ceph-mon@gm268-2.service



7 D/ x1 v9 E) x5 h! z  U$ 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)
1 I* m3 g- y8 c   Active: active (running) since Fri 2024-10-18 13:09:42 CST; 51min ago
Main PID: 157382 (ceph-mon)
, p5 \( J# b7 E+ W, M' x    Tasks: 27
   Memory: 587.1M
- v; L5 }- r7 k   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 b. j+ s& k1 n" ]
7 i* H( X  c* Z4 U

admin

检查集群状态：
4 k7 s5 l' Q' S1 s) b5 l4 D, a$ ceph -s
  cluster:
: A$ j6 `& e) |1 M    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
* I$ b) z4 Q/ L9 l# m& \; f    health: HEALTH_ERR
            3 failed cephadm daemon(s)
            failed to probe daemons or devices
9 S2 `+ m- _( v: {- b            2 mgr modules have failed
0 |) }0 @7 g1 s. C* j            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
3 l) N' @' _8 }0 _
  services:
    mon: 3 daemons, quorum gm268-2,gm268-3,gm268-1 (age 39m)
! i; G$ Q& x/ k) V8 j    mgr: gm268-2.zttohs(active, since 51m), standbys: gm268-3.sjagqo, gm268-1.jgdvxs
! r+ g4 J$ t4 t$ B- _    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
* Q! s# G. T. G2 Y9 Z+ d! U7 F
5 a% d2 ?) N: G$ F  data:
. q" u* w3 H1 H' L    pools:   5 pools, 11265 pgs
    objects: 42.48M objects, 115 TiB
# E  P  P8 ]$ s2 B    usage:   232 TiB used, 365 TiB / 597 TiB avail
    pgs:     800589/84967110 objects misplaced (0.942%)
4 R" O' |/ T8 D) G0 H5 q3 E             11080 active+clean
9 a- C! [6 R! M6 W- T+ e/ q8 b+ |             184   active+remapped+backfill_wait
! K$ j8 U# |$ d3 q: B; @4 W             1     active+remapped+backfilling
/ W1 N* ^. i. r
8 a1 \( c5 w) |5 H( `  W' A  Z. g  io:
' ]) F( P. l7 N. W9 Q7 Z( M    recovery: 22 MiB/s, 6 objects/s
' h9 p- q+ d8 L: K6 U

admin

以下是其他的地方处理过程：
ceph mon节点迁移
1 V- F$ W; r2 h* B4 B8 M: V- _有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。
; c/ H6 q0 p7 A1 Z! m! K' J/ K
离线迁移主要涉及到的就是mon节点的改变。
解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon
; ?( _  D" o& i
& L  k9 `1 u7 A& U获取集群当前monmap(搬迁前进行)
$ U+ c! [4 @# [6 a0 }+ h获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。
# Y$ P; t* a, H- ?0 g  B
# f$ e/ y0 b( S* i! M如果剩余的 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>
! c# }, S) u( R) x5 h// 获得ceph monmap
[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？

当然，也是有的，可以借助ceph-monstore-tool和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来恢复它，具体详情请参考: 使用 BlueStore 时恢复 Ceph monitor 存储

9 e' i, W* R1 @5 i- Z  b" Y. _删除临时monmap中的老的mon
# S" _3 |- I1 H* z# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
/ ?, f# ?) n' D% T/ B% u' {8 Imonmaptool: monmap file /tmp/monmap
monmaptool: removing node1
monmaptool: removing node2
+ K7 o* q5 P$ a7 tmonmaptool: removing node3
monmaptool: writing epoch 1 to  /tmp/monmap (0 monitors)
向临时monmap中添加新的mon
2 t7 v' D1 S/ I# 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
0 O  ~. X; N' \; C% nmonmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
4 F( C4 S4 N- M* q停止所有mon服务并注入monmap
首先要先确保新的mon已经在新的服务器上安装起来了，然后stop掉mon进程，每个mon新节点都要执行
8 X9 o7 k4 q* `( X- u, y3 j- N
5 u5 H/ L6 W6 `2 bceph-mon -i {mon-id} --inject-monmap /tmp/monmap
' p3 \8 ^1 t4 l% L/ Q更新所有服务(mon,mds,client,mgr,osd等)的ceph.conf
这里需要注意的是如果新ip的网段也有变化的话，那么除了要更新ceph.conf文件中mon\_host信息，还要更新public network/cluster network的网段信息

同步的话可以通过ceph-deploy命令
* @3 k6 q2 o- e4 A$ H; L, ?
5 g# l8 S' j7 J- l+ M+ K3 K) Iceph-deploy --overwrite-conf config push node{1..3}
& E6 |2 j9 v% R) L关于上层服务
: }' }& k, ?4 l' ^1 D; X3 Z使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更
$ c8 [: L6 k5 S& k
- F& G8 o  p9 r9 kceph文件系统直接挂载+rbd挂载
直接把新的ceph.conf同步到client节点就可以

admin

其他文献解决办法：
. @" J( k- k% y/ G
1 问题

一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢？

1 @# f2 X, x) D3 p/ L7 [- o; o0 t7 ?如果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.
- ~) k% |% O  u+ I1 G


所以，

（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。
$ Y. k) Y9 g; L( M5 E
（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？

6 c! t: d; I2 \/ m2 恢复
- S6 \  Q" M) R- B其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。
5 |6 i0 }, z: F/ o
& W, P2 ^6 s- ]6 c. g3 R# J

添加monitor的步骤：
& ?# k+ _& B! h( k1 V0 y: b
$ 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了。

( j3 D; O+ s" n7 R为了模拟，考虑2个monitor节点，挂掉一个，此时通过网络访问ceph的所有操作都会被阻塞，但monitor的本地socket还是可以通信的。
2 o9 j" I0 n; \4 a% f3 S/ Y' D
NewImage
) c6 s  b! X3 F) u6 p  d0 @

; K/ U( G6 O" k' u3 J& _) d( P
但是，让人蛋疼的是通过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
' S. g" i9 I* \: V/ b5 M9 ^8 {
monmaptool: monmap file monmap
. _5 b' Q4 W! Z& \4 d
: j, {7 D$ E) g  H- F4 smonmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
  ?+ O' y( B) |: P: J& F6 {( x
. {4 t( n$ ?$ Q* \& C( Tmonmaptool: writing epoch 0 to monmap (2 monitors)

将正常monitor节点的mon key拷贝过来：

# cat /var/lib/ceph/mon/cluster1-vm2/keyring

[mon.]
4 X& Z5 V5 V8 F8 @- l% i
6 K& k! u8 q5 o% j: K0 s+ [4 |        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==

        caps mon = "allow *"


% v3 m8 _5 X& ?3 L+ }
- b# H# g" a1 d' P% t然后初始化：

- k' {1 ?8 R6 Y1 p* i# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring

ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf
: [5 q1 F; m" }/ ^3 A1 I
9 J3 E9 F. {+ e8 Rceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3

- N+ a3 {  N0 P6 r: ?$ r最后，启动故障节点：
3 b, ~) i3 K8 v6 s
# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789



NewImage
3 Z, v7 v  E7 Z- K6 Y4 L
一切OK!

admin

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