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

admin

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

7 ~$ S! N5 v" ?
$ L6 g: K) ]1 P+ O7 fceph一直无法正常的执行ceph -s命令；



5 K5 h' a2 D+ |4 j: Q$ q: o. bceph分部署存储告警monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
7 d% E% p% f, j5 U
2024-10-17T22:33:47.295+0800 7f20fe7fc700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]
+ N2 l  ?& T4 ]3 ?2024-10-17T22:33:47.297+0800 7f20ff7fe700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2]

% @: f1 W9 o+ h0 O% I6 f

环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。

结果过程：

* K1 P) h3 E3 }8 l1、在gm268-3节点上导出monmap文件：

: X! @; `' p8 S. x
( L+ O' G* h9 P4 A; m* M$ 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
- t' {- G1 v3 i9 i1 amonmaptool: monmap file /tmp/monmap
monmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
( n2 F2 \) ~) Y5 u( ]' d  I3 smonmaptool: writing epoch 0 to /tmp/monmap (3 monitors)
% n. y5 z' U. n: R( z) \
% U2 _4 |; i, B. m( q! w! c  r
导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。
$ u1 d+ R- h& I' I
1 F' H& n3 t/ f) u/ @查看下导出的文件信息：

$ monmaptool --print /tmp/monmap
: \$ v9 z  Y6 r0 `/ H  [monmaptool: monmap file /tmp/monmap
" E4 k# |) X. ]$ c% t" I/ Pepoch 0
fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
last_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
min_mon_release 0 (unknown)
0: v1:10.12.1.2:6789/0 mon.gm268-1
, u; H! N  Z6 p# [5 y% L1: v1:10.12.2.2:6789/0 mon.gm268-2
" E. u: Y0 m9 [  ?/ }2 a2: v1:10.12.3.2:6789/0 mon.gm268-3

4 [6 M' d4 g' o9 l5 x0 a

6 S# e) J  _  |% w; I7 a) O6 ?& N2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。
& ~* d8 H9 I) o+ V9 p2 \! m
; Z9 \* z. ^1 O: t$ `* l9 M
* h% C5 P0 Z6 D9 X' d& a3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：

scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
: o. {3 P6 {9 g: g1 Jscp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/

scp /tmp/monmap  gm268-1:/tmp/
scp /tmp/monmap  gm268-1:/tmp/


+ v1 H9 {  f- r# _( f, W) |! @4、重做gm268-1和gm268-2 节点mon  
' y4 e9 f4 e. w' q' a% m7 ~ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf

" [8 K9 r( P0 C/ P# Q1 H9 i/ x切换到/var/lib/ceph/mon目录下
, y6 l. D* U; h执行：
chown -R ceph:ceph mon/

5 Y8 C: l2 V4 }8 ?; \启动mon服务：
: C# z- O# x# j& n. E- Tsystemctl start ceph-mon@gm268-1.service
$ N8 f$ k. _, l* {* w3 F- d5 ~
: H' T4 P; j! ?0 J查看服务：

$ systemctl status ceph-mon@gm268-1.service
● ceph-mon@gm268-1.service - Ceph cluster monitor daemon
   Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
3 X# Y% N# F8 Y& a6 i   Active: active (running) since Fri 2024-10-18 13:21:24 CST; 38min ago
) T. F, I/ }$ ~3 c" I7 @ Main PID: 664542 (ceph-mon)
    Tasks: 27
! M7 z5 D; Q3 ^8 t2 _. a. L8 h   Memory: 286.0M
' F( N. t8 }+ B: B& S, G   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
% t, a3 Z7 H$ _2 m( o           └─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph
. n" C- O3 n% R
Oct 18 13:21:24 gm268-1 systemd[1]: Started Ceph cluster monitor daemon.
9 i# a9 e3 p5 hOct 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
. f1 [  t  ]- h* ^1 V8 J- I8 UOct 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


' z$ h9 ^% \- o. L) ?$ D. |1 r# S节点修复完成。
8 x8 Y) `* Z! t  u6 w节点二上
" O7 t3 k3 G5 v, f
5 R& \) O, C1 H: P1 U2 Bceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
# e# |' y7 S1 L: f1 K
% Q) r( v. T9 R: V切换到/var/lib/ceph/mon目录下
9 G; l' |0 g" t' h执行：
, I% j9 n2 V0 echown -R ceph:ceph mon/
8 I" j" B( A! W1 M+ ]) Q
' ?% X$ L8 |+ g  L2 _- g启动mon服务：
systemctl start ceph-mon@gm268-2.service

# q& D4 M0 V' O7 j" S. P
/ K+ l; `8 i  h& R, F
$ systemctl status ceph-mon@gm268-2.service
● ceph-mon@gm268-2.service - Ceph cluster monitor daemon
; B& b* |; G4 o   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
5 B3 l1 A) m/ X$ p Main PID: 157382 (ceph-mon)
    Tasks: 27
   Memory: 587.1M
- F0 u4 I7 k/ S   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

检查集群状态：
  f! V# ]8 H" o; W9 K$ ceph -s
  cluster:
    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
# |& r: ^7 i+ t- V+ S( V9 A    health: HEALTH_ERR
            3 failed cephadm daemon(s)
/ d: b# D( G/ @+ j            failed to probe daemons or devices
. Z9 i9 i. J( F& D, e6 c            2 mgr modules have failed
            mon gm268-1 is low on available space
+ i4 [. t- _3 f            22 pgs not deep-scrubbed in time
- a! c2 m; R: C            1 slow ops, oldest one blocked for 2805 sec, mon.gm268-3 has slow ops
4 P; e+ T+ Y* N3 _  l1 i' E* N
" N* U1 }9 S: _# m  services:
    mon: 3 daemons, quorum gm268-2,gm268-3,gm268-1 (age 39m)
  M" g* l2 i# s    mgr: gm268-2.zttohs(active, since 51m), standbys: gm268-3.sjagqo, gm268-1.jgdvxs
* c% c2 T7 h- l4 W5 f    mds: cephfs:1 {0=cephfs.gm268-3.ppyjrl=up:active} 1 up:standby
& O$ H! }! U+ D0 G- p  U. F: u    osd: 41 osds: 41 up (since 46m), 41 in (since 20h); 185 remapped pgs
/ y6 A; v! S- w4 Y! J/ p6 Z6 u( [* z! Z
9 k* I* T9 L  K/ d  ~  data:
    pools:   5 pools, 11265 pgs
    objects: 42.48M objects, 115 TiB
# Z$ I. U' J- E. |, J2 f    usage:   232 TiB used, 365 TiB / 597 TiB avail
5 ]0 Y% k( h$ k+ U8 W, H4 Q, J    pgs:     800589/84967110 objects misplaced (0.942%)
( y- a3 H% s# \6 w* O+ R( T             11080 active+clean
             184   active+remapped+backfill_wait
             1     active+remapped+backfilling
- q# s7 l+ y, m
  io:
    recovery: 22 MiB/s, 6 objects/s
" o0 x& [) I% l, n- y; v

admin

以下是其他的地方处理过程：
  K! i2 J# \- E- {0 c" J- X: gceph mon节点迁移
3 s* e! Y5 W' K+ c1 ?+ c& u. a有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。
8 c8 e# e0 |4 G; X
6 G. k" k, n; [$ @* k离线迁移主要涉及到的就是mon节点的改变。
; D! f3 T# G0 r2 O3 Y$ j: \7 D* _* K解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon
9 ^1 y; M. N: Q; z7 Y* {" u2 [1 ?
5 j: K* i. z; m# ~获取集群当前monmap(搬迁前进行)
获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。

如果剩余的 Ceph mon能够形成仲裁(多数存活)，请使用 ceph mon getmap 命令获取 Ceph monitor map：
0 q- t* O8 r( L) ]  t8 _9 V
ceph mon getmap -o /tmp/monmap
/ K( [) `) u" Q/ b" D2 |; M) P3 a如果此时ceph的mon已经不能够形成仲裁了(多数mon挂了)，那么在健康的正确的mon机器上通过如下步骤获取monmap

, G/ H" y7 u; W* s4 A( V( J; l3 E// 停止您要复制 Ceph monitor map 的 Ceph 监控器
[root@mon ~]# systemctl stop ceph-mon@<host-name>
// 获得ceph monmap
[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
7 A# u& W6 T0 |. j7 g, B3 \$ p5 b如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？

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

删除临时monmap中的老的mon
# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
) w0 i8 H* F4 Dmonmaptool: monmap file /tmp/monmap
' s! @. N4 ^, V5 L! C' Q6 _monmaptool: removing node1
0 d1 r5 A/ G$ Amonmaptool: removing node2
monmaptool: removing node3
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
1 P2 @- n3 x9 Q- L9 U& B2 vmonmaptool: monmap file  /tmp/monmap
3 ~, @0 N' C- F. R9 Mmonmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
. x- D9 A8 k% ]9 q! N8 X" O停止所有mon服务并注入monmap
- j. P' Y9 p+ N& \3 d* W* ?0 F4 Z$ K首先要先确保新的mon已经在新的服务器上安装起来了，然后stop掉mon进程，每个mon新节点都要执行
" p: w3 O7 \  U5 E1 _
/ @, G7 C1 b0 t- T3 ]% aceph-mon -i {mon-id} --inject-monmap /tmp/monmap
6 e, r" H" K4 U) z更新所有服务(mon,mds,client,mgr,osd等)的ceph.conf
这里需要注意的是如果新ip的网段也有变化的话，那么除了要更新ceph.conf文件中mon\_host信息，还要更新public network/cluster network的网段信息

" w7 C6 ]" ]- g同步的话可以通过ceph-deploy命令

ceph-deploy --overwrite-conf config push node{1..3}
关于上层服务
使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更
* T/ F* e! Z: C) j/ J- ]9 z
ceph文件系统直接挂载+rbd挂载
直接把新的ceph.conf同步到client节点就可以

admin

2 G9 B. C% n; R$ c5 |$ L; f其他文献解决办法：
+ z: d# A% P2 {$ w; k
: c, ]) ~4 S0 R& k5 A1 问题

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

9 x- q% x5 Q9 p2 L% i( z" G如果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.



所以，
1 C) `  ^1 B4 _) U6 }
$ x. i5 B" [! b  p8 F2 i& n（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。
& j% Z! w" |- d7 R+ K2 b: Q' P! q
（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？
# B) ~: L4 ^9 o* m
. x3 Q0 a  D+ {$ ~2 恢复
6 D; M, A, K( W4 t" v5 l其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。
5 u3 J$ @7 `% p! J: B" @: Z2 S

' e. r* ~, a  R
) k, H) U. @* `8 K添加monitor的步骤：
6 n% t9 b) ~# y9 c- R
. ~) u/ g- U2 ?$ ~7 Q$ L8 [$ ceph mon getmap -o /tmp/monmap           # provides fsid and existing monitor addrs
5 l% n: m! O. V/ W! [4 x8 a
$ ceph auth export mon. -o /tmp/monkey     # mon. auth key

$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey
6 c& K5 e9 w2 O
, H; c, F. ?) D; x% {所以，只要得到monmap，就可以恢复monitor了。
/ \$ s8 c1 ~* L5 l7 Z" z4 ]
/ I" I# |; J1 O" T  q/ Q3 O为了模拟，考虑2个monitor节点，挂掉一个，此时通过网络访问ceph的所有操作都会被阻塞，但monitor的本地socket还是可以通信的。
  ]! b# X; v9 M. G6 H4 I' I+ m8 K
NewImage

# d1 Z7 }+ _2 ~2 C1 ?2 }

$ x+ O# O0 g3 m- M' B6 @2 ~但是，让人蛋疼的是通过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, u; d, k- ^# Kmonmaptool: monmap file monmap

monmaptool: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

monmaptool: writing epoch 0 to monmap (2 monitors)
7 l7 t) c/ b$ {( s  f, j; p* W
将正常monitor节点的mon key拷贝过来：

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

[mon.]

        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==
6 R6 f$ \' H$ Z" j2 A' S, k  z
        caps mon = "allow *"
& K5 k5 \, ^9 {1 ]6 v+ ^+ J
; ?: I" Y# s3 \( `7 L3 b
4 W$ `" a( t7 x' E  p
然后初始化：

# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
- l  y0 g' z) G3 F( L; ?' N+ [) e0 [
+ K! K3 R$ E' v7 R: A! ]ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

ceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3

9 `: _( w& S- y  @最后，启动故障节点：
( j8 p0 L7 W! E7 l
# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789
: M/ A1 N+ r: |' Z, c+ r+ I" ]


: C# H8 X0 {# X; K8 G NewImage
$ A  r! Z4 L1 v# K3 d
$ I: _$ `% K8 J7 @一切OK!

admin

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