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

admin

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


: |  V/ o" |) b: @6 kceph一直无法正常的执行ceph -s命令；
6 K& z& _) x7 ~+ g8 ]3 I
/ z; p0 }# X( t, K! r; f; a

ceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]

, F4 G3 a3 j1 f' Z; p8 ^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]

  y5 {2 x$ {. J" `! k8 T
0 ^: \8 @3 m, \! }' j
1 f# b* I% n: y- |+ O3 g+ u5 [; H环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。

' P: ~1 M1 D! B$ B+ b6 t8 W结果过程：
, r7 H# g: m1 e1 X9 @2 @, j
* o& x' y+ H; l! L  \+ I3 ^1、在gm268-3节点上导出monmap文件：
0 H, w9 W& I' U
. @2 E2 {- l0 k' p4 W/ }0 a; 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
4 N0 N' w& o  l1 m* J9 E3 Zmonmaptool: monmap file /tmp/monmap
monmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
monmaptool: writing epoch 0 to /tmp/monmap (3 monitors)
+ @! n  E! \! d5 |5 J

5 t) x4 ]1 Z  U+ T( G, P9 J  g0 b+ `. D导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。

查看下导出的文件信息：

$ monmaptool --print /tmp/monmap
monmaptool: monmap file /tmp/monmap
7 B. ^$ G" q, z. B& J6 nepoch 0
fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
last_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
7 X( |- n8 q% q. S$ `9 R+ i! }' V8 ~min_mon_release 0 (unknown)
0: v1:10.12.1.2:6789/0 mon.gm268-1
/ X( M, ?! v* p, h" g1: v1:10.12.2.2:6789/0 mon.gm268-2
2: v1:10.12.3.2:6789/0 mon.gm268-3
8 s" r. n2 a! T' [" |) S


% d" j! y* a- H+ `! }% i# ]2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。

2 _4 C) k% L5 y3 U3 r
3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：

! l" _% n. P  F: w. b scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
) P2 z$ ?( z' u& V* pscp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/
; D( @& b2 y& g( |+ D
# b! }" }0 P" P* h. l  nscp /tmp/monmap  gm268-1:/tmp/
scp /tmp/monmap  gm268-1:/tmp/

3 i0 @5 V, F* u$ F& q
8 z6 K5 w" g! P# j6 u0 _, m% V4、重做gm268-1和gm268-2 节点mon  
ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
3 m7 }; z: @. L2 B' z0 \% r
切换到/var/lib/ceph/mon目录下
' _9 @$ b0 K( C1 V* ~执行：
. O( d& j) g' g9 Z( kchown -R ceph:ceph mon/

) D, O! `1 A( i启动mon服务：
systemctl start ceph-mon@gm268-1.service
- H$ S, N( R, I& Q5 T9 {
( {9 O" |7 }7 Q9 x1 m9 q3 h- O查看服务：
% O5 Y7 @9 t3 z' `6 M
4 Y" ?$ k) b! Y$ systemctl status ceph-mon@gm268-1.service
. ?; V. a4 M( m0 S" `● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
   Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
# }2 D) X& Q' o! ?; A   Active: active (running) since Fri 2024-10-18 13:21:24 CST; 38min ago
Main PID: 664542 (ceph-mon)
% _( p/ m) `4 ?( W# o/ b    Tasks: 27
# P! Y+ T7 T( T) }   Memory: 286.0M
   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
& o/ v+ V8 U' }$ s9 d           └─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph
( z0 q/ ^$ I0 z8 x, @: n& D' _
) J& t! E1 x7 b/ \. {Oct 18 13:21:24 gm268-1 systemd[1]: Started Ceph cluster monitor daemon.
# c7 `- T/ d  b( W2 D$ y, mOct 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
7 l# o! N  R: q2 O! ?5 HOct 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


) _$ N. ^! g3 z! z# C5 u节点修复完成。
. L5 B: E" m5 b" S/ I节点二上

ceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
, L, I; \; i/ e, A. ?# b$ z% z. I
2 H4 ]- s: V. i  o0 ]# [- ^切换到/var/lib/ceph/mon目录下
执行：
chown -R ceph:ceph mon/
& q( c1 V) C: Q
& P+ R% S) o+ R& K& h; \4 W启动mon服务：
+ x& s0 p5 ^1 a; bsystemctl start ceph-mon@gm268-2.service

7 `# n& j  {7 d4 S
' R: d# _: E# r; {* n
6 X( g" C& s2 S$ systemctl status ceph-mon@gm268-2.service
" J; a3 N: y% r, C! Z● ceph-mon@gm268-2.service - Ceph cluster monitor daemon
; p7 p7 t& K/ B8 t   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)
; [) Z; G+ H0 i9 Y    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

admin

检查集群状态：
$ ceph -s
$ |6 C/ V0 F% R/ Y# e) A' {  cluster:
    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
8 y* l1 l% l1 q$ W1 G5 H9 [8 Y1 i    health: HEALTH_ERR
            3 failed cephadm daemon(s)
            failed to probe daemons or devices
+ s5 a6 W3 Z4 @; U7 n' M. L: x) u            2 mgr modules have failed
3 `& L* G5 b" e/ O4 i* ~  _$ M            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
' S# R" O- n; i4 v6 @
  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
, L! G* m4 s- Q* x
5 Z+ q' S! T) B1 q  data:
    pools:   5 pools, 11265 pgs
    objects: 42.48M objects, 115 TiB
9 ]) `  b7 c) X* ~% B    usage:   232 TiB used, 365 TiB / 597 TiB avail
, k. C$ {: k( E0 \    pgs:     800589/84967110 objects misplaced (0.942%)
             11080 active+clean
% C' B9 E  Y6 Z% H- V3 K             184   active+remapped+backfill_wait
! L* Z# p; l! C7 n, B) b             1     active+remapped+backfilling

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

admin

以下是其他的地方处理过程：
ceph mon节点迁移
" G( J9 W" d- \, x5 \. U5 k2 F有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。
8 \& ^" V6 o) ?6 @
离线迁移主要涉及到的就是mon节点的改变。
解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon

! m% ~2 \2 I' i* m# M: ?$ a6 F获取集群当前monmap(搬迁前进行)
' G+ C# J% S6 w: y$ G) M获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。

如果剩余的 Ceph mon能够形成仲裁(多数存活)，请使用 ceph mon getmap 命令获取 Ceph monitor map：
6 y- H& g( [: {9 p+ r3 i
- ~; L3 {2 a/ p7 y8 r7 xceph mon getmap -o /tmp/monmap
如果此时ceph的mon已经不能够形成仲裁了(多数mon挂了)，那么在健康的正确的mon机器上通过如下步骤获取monmap
- v" N7 i* j! y1 q
// 停止您要复制 Ceph monitor map 的 Ceph 监控器
[root@mon ~]# systemctl stop ceph-mon@<host-name>
// 获得ceph monmap
+ ?" e0 ~* x9 x[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？
8 j8 W7 O& f' k* h
当然，也是有的，可以借助ceph-monstore-tool和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来恢复它，具体详情请参考: 使用 BlueStore 时恢复 Ceph monitor 存储

删除临时monmap中的老的mon
. \* y( h3 i6 k9 H0 Y1 k. h# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
# d' K$ h$ h& r7 l4 v; B4 Wmonmaptool: monmap file /tmp/monmap
monmaptool: removing node1
monmaptool: removing node2
( v! k. J1 G9 vmonmaptool: removing node3
: r. `1 u! ~2 A' w; h1 x. V- D  D; cmonmaptool: writing epoch 1 to  /tmp/monmap (0 monitors)
向临时monmap中添加新的mon
' |1 _8 ?7 U, Y. A; \3 B# monmaptool --add node1 192.168.244.44 --add node2 192.168.244.45  --add node3 192.168.244.46 /tmp/monmap
% w1 Z" K" d+ r: tmonmaptool: monmap file  /tmp/monmap
monmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
停止所有mon服务并注入monmap
5 h+ D. f9 B. M) j* a& a* ]3 [首先要先确保新的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命令
' d2 a# G/ V  o* r# J; c5 \
ceph-deploy --overwrite-conf config push node{1..3}
关于上层服务
使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更
0 N. V' T' K' q; C7 I  k
  C1 z/ {/ I- d- kceph文件系统直接挂载+rbd挂载
! }; z5 D4 k+ J直接把新的ceph.conf同步到client节点就可以

admin

其他文献解决办法：

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

如果ceph的monitor节点超过半数挂掉，paxos算法就无法正常进行仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。
0 S( q% v" j6 W/ Z
0 o0 d7 @. K6 D* e! F) T/ ]2 uIf 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.

; A0 n+ k3 R. w, j* D8 L% ~

所以，

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

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

/ I: M4 Q  k8 q  [- Z
* s+ r! T9 ?& a; {& T, M) P' [
% F9 s/ ]: x. F5 f/ a添加monitor的步骤：
2 F0 n! L( R& |0 G
1 ?% R* m+ ~  A" c: L" W( |7 d$ ceph mon getmap -o /tmp/monmap           # provides fsid and existing monitor addrs
# E3 ?+ w; O+ v8 T$ }! S5 [
5 g! d; h# c" D/ j$ ceph auth export mon. -o /tmp/monkey     # mon. auth key

$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey
5 P& P, C7 K' v+ i! P, y$ i
- I8 D, {- U4 x: r* R所以，只要得到monmap，就可以恢复monitor了。

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

NewImage
( z7 C) o  ^; t# J


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

, B- t) i- h+ O& Z" J# G3 h# 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
) n7 e7 e- c" G
( c, C+ D8 r' q4 y& Smonmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

. e* G& ]8 v* h( I* e. amonmaptool: writing epoch 0 to monmap (2 monitors)
: |2 C9 O3 Y! s
+ |5 I' ~1 A- |7 N; t将正常monitor节点的mon key拷贝过来：
: |1 Z# r; |2 l. |
6 I! G5 ?& m" Q6 U4 P" l# cat /var/lib/ceph/mon/cluster1-vm2/keyring

[mon.]
+ W) S% p) f- @- f; Z
, l* z- ^5 G- H+ l+ E; S        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==

        caps mon = "allow *"

# T5 J& t7 p6 z+ c# q3 J& L" ~& O+ }
  L2 ^: x% p/ E* f4 p3 d( {) @; i
然后初始化：
; C8 Y6 L& F: Z1 Q
# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
8 m6 g% q* |1 T# N( i
ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

ceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3
) z% C$ p! \5 ~6 q
最后，启动故障节点：

( S" x# \+ }: G8 s( u/ e4 J, w# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789

- ^7 U7 \/ }; I0 X$ ?- K

NewImage

一切OK!

admin

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