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

admin

当mon节点全部出现问题的时候或者单独一个节点出现问题时恢复过程
0 ^+ H& _: G$ F/ U
6 K' a) D( |+ E4 v1 Q; P
ceph一直无法正常的执行ceph -s命令；
$ P$ P3 y& T0 J0 h. R


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

2 R5 d" D; |( t/ B, Q8 {1 K2024-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]
1 ^# l$ e. k0 Y, g, K2 y5 w* l9 e
+ y; B3 g) I5 r* j+ N
+ s) R! s7 e/ M7 b/ _" A( j
环境中也就只有gm268-3节点因重启失败夯住是好的，gm268-1和gm268-2都已经被损坏。只能想办法从3上入手解决。

结果过程：
& o( @, W: I5 q, u
* T& ]' [2 @$ z9 C, e6 n2 }1、在gm268-3节点上导出monmap文件：
- S  V6 n5 w" h/ A$ o. h# 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
monmaptool: set fsid to ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
" O8 p, m: Q# j& \  g8 ?monmaptool: writing epoch 0 to /tmp/monmap (3 monitors)
4 v9 j6 R% X. U5 i2 F
, C7 t! E2 O" B9 o- }2 P
导出monmap，好的节点写在前面，后面把所有的坏节点加上就可以了。

+ ?, W6 \$ a. G1 x查看下导出的文件信息：
9 d, G% r' F1 @2 ?4 B; Q+ O. S
$ monmaptool --print /tmp/monmap
monmaptool: monmap file /tmp/monmap
5 `$ A8 M5 X& p3 {# h5 W* ]epoch 0
fsid ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
: `, }+ n2 n% a; v# ?last_changed 2024-10-18T13:17:03.645872+0800
created 2024-10-18T13:17:03.645872+0800
: f  M+ i+ F6 ~6 N( {% umin_mon_release 0 (unknown)
' e# g4 d  G) P& ?. j2 I0: v1:10.12.1.2:6789/0 mon.gm268-1
! L+ X3 W: m+ O2 F1: v1:10.12.2.2:6789/0 mon.gm268-2
2: v1:10.12.3.2:6789/0 mon.gm268-3

' ~2 v! H* l! ]/ d8 |4 g  e
) Q3 T* u8 R- p+ p8 |& d
2、去gm268-1和gm268-2的节点上找到/var/lib/ceph/mon 目录，备份下。删除掉。因为文件被修改了，导致文件有异常，没有导致认证出问题。原有的/etc/ceph/目录不能删除。

6 k% Y% W5 K* q4 Z. i8 L/ ?
2 l: _; A5 I, P0 J* H; \1 D5 ?3、将正常节点上keyring和导出的monmap文件传送到其他两个节点上：

scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-2:/tmp/
scp /var/lib/ceph/mon/ceph-gm268-3/keyring  gm268-1:/tmp/

; S) h. P8 \' X- O" w% nscp /tmp/monmap  gm268-1:/tmp/
" B( G5 m2 ]2 ]  Y/ c& rscp /tmp/monmap  gm268-1:/tmp/
8 d. f4 G1 t" D( u% [* O" `

4、重做gm268-1和gm268-2 节点mon  
ceph-mon --cluster ceph -i gm268-1 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
2 t7 S8 ~% X7 C; X
切换到/var/lib/ceph/mon目录下
. j9 O# K8 o9 l% H/ A2 m执行：
chown -R ceph:ceph mon/

) J7 T6 U* l9 I2 y启动mon服务：
9 G" h$ S3 R& j+ lsystemctl start ceph-mon@gm268-1.service
/ M+ ~. d7 w" {; e
' y/ T3 H/ V( ~$ D% y$ O8 g查看服务：

$ 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)
   Active: active (running) since Fri 2024-10-18 13:21:24 CST; 38min ago
! L2 q2 l! r' D8 v3 x Main PID: 664542 (ceph-mon)
    Tasks: 27
   Memory: 286.0M
   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@gm268-1.service
           └─664542 /usr/bin/ceph-mon -f --cluster ceph --id gm268-1 --setuser ceph --setgroup ceph

4 {) j0 V8 u8 V& o1 qOct 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
) o- P% r: t& \/ h2 t2 r% }! H6 ^
! V+ _+ S* O% i& ~; `3 y; A6 {
节点修复完成。
节点二上

ceph-mon --cluster ceph -i gm268-2 --mkfs --monmap /tmp/monmap --keyring /tmp/keyring -c /etc/ceph/ceph.conf
" {1 D- d4 q) c8 R4 k
切换到/var/lib/ceph/mon目录下
! t+ U) Z. z; K+ A1 ^6 h执行：
chown -R ceph:ceph mon/
) [, o9 P' T& a  S0 G' e9 p4 C- j
5 l" R3 X, m6 R8 E8 p9 i  b$ D2 M5 M. |启动mon服务：
systemctl start ceph-mon@gm268-2.service
& |+ I+ [& c- `1 x1 d
( R5 y( y, R5 I0 A$ z
) \3 V6 ~! {- j4 M4 S. F4 V
' _& O9 n& X" G$ systemctl status ceph-mon@gm268-2.service
- g: A8 |/ C1 `: q9 |2 a) v● ceph-mon@gm268-2.service - Ceph cluster monitor daemon
   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
6 D$ u7 Q' z1 P% @: k" { Main PID: 157382 (ceph-mon)
* f- @) M# C7 K  i& N3 L    Tasks: 27
8 b# U. |" N/ F% o' {6 _' }- h" g   Memory: 587.1M
- F9 j* r/ o% H+ w3 Z   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
  cluster:
" c5 r: w5 N3 ~9 S: ]    id:     ce68aab8-8f46-11ed-88c0-ac1f6b3a30b9
9 t. u- i+ a4 v8 L7 o5 v2 _    health: HEALTH_ERR
3 ^8 Q0 v9 V5 g# t9 C            3 failed cephadm daemon(s)
            failed to probe daemons or devices
            2 mgr modules have failed
            mon gm268-1 is low on available space
6 Z( b* {; y" e4 O            22 pgs not deep-scrubbed in time
. Z# p4 }: w* k! K            1 slow ops, oldest one blocked for 2805 sec, mon.gm268-3 has slow ops

, ^1 G- s/ k( X0 z, r  services:
3 d( q2 Z. @5 z. i# ?    mon: 3 daemons, quorum gm268-2,gm268-3,gm268-1 (age 39m)
0 B; {2 J& _! x; ^$ M2 ]0 @' F% D    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
! J4 T; S+ P6 x+ S; g
  data:
    pools:   5 pools, 11265 pgs
    objects: 42.48M objects, 115 TiB
    usage:   232 TiB used, 365 TiB / 597 TiB avail
) |, V/ `* D! u4 r$ H! I  V" t$ z    pgs:     800589/84967110 objects misplaced (0.942%)
/ m2 X1 L- v# Q3 G& Y$ e             11080 active+clean
             184   active+remapped+backfill_wait
2 o2 p6 `0 @* U3 \5 J1 y3 O' k& b             1     active+remapped+backfilling

  io:
) \9 O! R8 ~) B$ R% {    recovery: 22 MiB/s, 6 objects/s

admin

以下是其他的地方处理过程：
2 L3 F8 B+ M. E8 Z4 t! f; o' E* [ceph mon节点迁移
有时可能需要将ceph存储整机移动到不同的网络、数据中心的不同部分或完全不同的数据中心，甚至于新机房和老机房的网络都不是互通的，那么就需要使用离线迁移了。

. `, v1 s/ l* ^! D离线迁移主要涉及到的就是mon节点的改变。
解决方案是为集群中的所有mon生成具有新IP地址的新 monmap，并将新映射注入每个单独的mon

获取集群当前monmap(搬迁前进行)
获取集群monmap这里又分为三种情况：Ceph mon能够形成仲裁；Ceph mon不能形成仲裁待至少有一个存活；所有的Ceph mon都已经损坏了。

如果剩余的 Ceph mon能够形成仲裁(多数存活)，请使用 ceph mon getmap 命令获取 Ceph monitor map：

% j% ]: f1 H: S" z) R4 mceph mon getmap -o /tmp/monmap
/ F1 K8 r5 G. I5 V5 c9 ?如果此时ceph的mon已经不能够形成仲裁了(多数mon挂了)，那么在健康的正确的mon机器上通过如下步骤获取monmap

// 停止您要复制 Ceph monitor map 的 Ceph 监控器
[root@mon ~]# systemctl stop ceph-mon@<host-name>
// 获得ceph monmap
" C7 G5 z8 x& S+ m0 _[root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap
如果很不走运，所有的mon都损坏了，那么还有没有什么办法获取到集群的monmap，以至于恢复整个集群呢？

7 G4 a+ z* w! m# s! r) {6 B当然，也是有的，可以借助ceph-monstore-tool和 ceph- objectstore-tool 这两个实用程序，通过 OSD 节点上存储的信息来恢复它，具体详情请参考: 使用 BlueStore 时恢复 Ceph monitor 存储
0 g3 l& L# a( l4 m( O. x
: }0 @! t' h$ W- y: a删除临时monmap中的老的mon
* F& [$ k4 t) d0 ~# monmaptool --rm node1 --rm node2 --rm node3 /tmp/monmap
monmaptool: monmap file /tmp/monmap
monmaptool: removing node1
monmaptool: removing node2
monmaptool: removing node3
& |& O( m6 B2 u1 }& d; Vmonmaptool: writing epoch 1 to  /tmp/monmap (0 monitors)
* r0 o$ Y. ~5 r6 @1 t& [0 ~3 M向临时monmap中添加新的mon
- U2 F% H+ {1 z6 a% [; g% Z5 x: Z# i# monmaptool --add node1 192.168.244.44 --add node2 192.168.244.45  --add node3 192.168.244.46 /tmp/monmap
) t8 B$ H2 d# c  H7 a: lmonmaptool: monmap file  /tmp/monmap
monmaptool: writing epoch 1 to  /tmp/monmap (3 monitors)
停止所有mon服务并注入monmap
9 G! J0 t' A- v2 M首先要先确保新的mon已经在新的服务器上安装起来了，然后stop掉mon进程，每个mon新节点都要执行

+ B' m! c8 M2 V& L% d" V: mceph-mon -i {mon-id} --inject-monmap /tmp/monmap
更新所有服务(mon,mds,client,mgr,osd等)的ceph.conf
- U0 v0 O- D% F' b这里需要注意的是如果新ip的网段也有变化的话，那么除了要更新ceph.conf文件中mon\_host信息，还要更新public network/cluster network的网段信息
' G- C7 A/ D( V
; y8 e7 ]7 a1 X% r! u% U' Q同步的话可以通过ceph-deploy命令
' P, A/ q, S1 {! e5 Z1 h+ ^1 I
ceph-deploy --overwrite-conf config push node{1..3}
9 `; \* D3 e! x6 x# Z关于上层服务
' J$ r! g6 V4 j% h使用ceph底层存储的服务可能有虚拟机，k8s集群，如果ceph存储搬迁机房了，还需要服务之前的老的客户端，那么他们也需要做相应的变更

0 g: `0 x& G  dceph文件系统直接挂载+rbd挂载
2 d+ O. X& i7 N直接把新的ceph.conf同步到client节点就可以

admin

其他文献解决办法：

: u! B" k0 e$ w  s/ ?) K1 问题
- M% t/ h* {* Y+ r
4 U% B, ?+ \+ |9 Y一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢？

* `- P7 E6 i  E4 a- w2 v, A如果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.
8 Z# V3 U: b7 D! u0 Z
# e% a& }+ {* ~! b0 B
. D$ i2 Q" G/ v5 Q. X; |' \! @
- m' E8 q. p. X" O; N所以，
! \* F4 ^: g9 p
（1）如果挂掉的2个节点至少有一个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。所以，对于monitor，最好运行在RAID的机器上。这样，即使机器出现故障，恢复也比较容易。

（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明人品不行，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌工资太低，把机器砸了。如何恢复呢？
8 A# N" A( s4 t
( Z* _1 i( u! c+ A2 U2 恢复
其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。幸好还有一个元数据正常的节点，通过它可以恢复。
* U$ h4 _9 {4 d( e3 K; g6 E
( e5 b6 Q% W% Z' V
. Q1 K3 d3 _, e& k
添加monitor的步骤：
2 v1 u2 t  B' P5 O
$ ceph mon getmap -o /tmp/monmap           # provides fsid and existing monitor addrs
: M& h1 z- I$ `4 @: u1 {
0 ~1 K$ c: @" U8 _5 v$ ceph auth export mon. -o /tmp/monkey     # mon. auth key
2 M- M" F( W, R! u% K; S
$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey

# j- ]9 {0 N" Q, v# `! J- q所以，只要得到monmap，就可以恢复monitor了。
; f* e+ G' w9 c+ Z  Z
为了模拟，考虑2个monitor节点，挂掉一个，此时通过网络访问ceph的所有操作都会被阻塞，但monitor的本地socket还是可以通信的。
, W+ w; C& u' d" k
NewImage

5 h, R$ I+ }# \3 R! J6 V1 {7 m; p

但是，让人蛋疼的是通过socket不能进行monmap的导出。不过，幸好有monmaptool工具，通过它，我们可以手动生成(注意fsid)：
" F' M' X  a  w) ^  v
# 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

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

" Z2 N$ S  n0 `8 I/ v- }& r- Lmonmaptool: writing epoch 0 to monmap (2 monitors)

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

# cat /var/lib/ceph/mon/cluster1-vm2/keyring
% H, Z3 `" t! {& F- B
[mon.]

( m: I. D4 I3 \% U+ x5 a4 }$ R        key = AQDZQ8VTAAAAABAAX9HqE0NITrUt7j1w0YadvA==
0 W- @. `  _8 F8 l' p
        caps mon = "allow *"



然后初始化：

# ceph-mon --cluster cluster1 -i vm3 --mkfs --monmap /root/monmap --keyring /tmp/keyring
* G4 j5 L% v) c5 w' t! b0 g
ceph-mon: set fsid to eb295a51-ec22-4971-86ef-58f6d2bea3bf

- Y% }. h9 u, Jceph-mon: created monfs at /var/lib/ceph/mon/cluster1-vm3 for mon.vm3

最后，启动故障节点：
+ Q- A: `! |/ C5 y# s
# ceph-mon --cluster cluster1 -i vm3 --public-addr 172.16.213.135:6789


" `) }* a; t: |3 h8 S3 [( g  Y, M
NewImage
* i: |1 d/ P3 ~: x1 u# Y' l( z
3 T8 k' V1 v( h/ U& m; p/ @; x$ e一切OK!

admin

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