|
|
1、 处理故障的pg0 c: ~- K% d; A& ^! u( q* g& A
从ceph的状态中，可以看到，有一部分的pg处于stale/down/peering等状态，这部分异常的pg不能提供对外提供服务，影响了业务的可用性，通过ceph health detail找到这部分异常的pg，发现其中有一些pg的upset中都没有映射到osd，或者三副本只选出来2个osd，没有选出来第3个osd，下面是当时故障的pg的状态：! S# z" q" o- d# f- s" `8 Q
) D0 _! I9 o1 y! J7 N1 _& C B( T9 t& c q/ d
/ R& R; [! h. S$ r% n
这个现象很有可能是权重不平衡导致的，关于权重在0.94.7版本的ceph中，有两个参数，一个是weight，一个是reweight，weight会参与crush算法，计算出要落位osd，然后reweight是在此基础上再去决定是否选择此osd，但是reweight不会参与crush算法，crush算法本质上是一个概率算法，因此当权重相差悬殊的时候，很有可能选不出来osd，客户环境中部分osd的reweight设置成了0.09，有将近一半的osd都将reweight设置成了小于1的值，这就有可能导致pg出现异常，从而选不出osd。因此尝试将故障pg对应的osd的reweight重置为1：* `7 R# P7 e1 a$ x' D( S0 R# n$ p) R
0 B4 l& l6 X& a& Z1 m
* c# {2 `3 c; a6 ^ceph health detail | grep stale; k, H5 O( G) V
ceph pg <pgid> query8 u6 Y. U0 u- N! ~; K$ l
ceph osd reweight <id> 1% m! v) F6 K4 B2 V I
置为1之后，观察到该pg重新映射出了osd，并且消除了stale状态，恢复了服务。因为reweight的不确定性，我们调整权重，一般不调整reweight，让它始终保持为1，在L版之前的ceph中，需要通过调整weight值进行数据平衡，L版之后新增了weight-set功能，可以更有效的去平衡数据。2 W& ^ y* ~* I9 d0 r3 i H& k
9 L H" C7 z! }7 L' U/ t: P* m' s此时，可以将所有reweight不为1的osd重置为1:- R: P# f: }( i2 n G
! z& J9 W' @ Y1 S& \/ O$ F
/ J" K9 N7 I( M- q% X) r3 Ifor i in `cat reweight_osds.txt`; do setsid ceph osd reweight $i 1; done; H4 |* E$ @ Q B" v3 l& v
重置为1之后，stale的pg全部恢复了正常，业务也恢复了正常。, D* C4 R: c8 Y! a9 R7 C# h
! Q7 F w, x4 |% `
2. 数据重平衡! a( h! n9 j# T
后续需要做的操作就是继续平衡数据，但是要保持各个osd-domain的权重值大小一致，然后可以微调osd的weight值，将一个osd-domain中高使用率的调低，同时也要将另一个osd-domain中低使用率的调高，平衡数据，直到各个osd的使用率趋于均衡。% A$ k. e+ J% O5 P
i4 {3 y4 @& k3. 恢复mon服务
9 J5 X3 l: p( A, e等待数据平衡完成之后，压缩61 62的mon服务，然后启动，再将63加进集群。/ j) K' h( E4 E7 O5 h1 l9 [4 z% w2 i
4 d% ^8 e$ i1 H# Q& x: G
至此故障处理完成，所以最终总结一下，引起该故障的本质原因，在于调整数据均衡的方式不对，权重调整的幅度过于大，不同osd之间的权重相差悬殊，导致pg出现了问题，进而引发了后续的一系列问题。因此，关于权重值需要关注以下几点：+ _% q! s: F, K! Y
6 z0 X/ `5 \, [% Q
保持各个bucket的故障域的权重是相等的，bucket里面的osd权重值可以不一致，但是osd上的权重值得保持相等，扩容/缩容，都需要考虑这个问题7 a8 F$ h$ y6 A, m. U( m
weight不要设置过大与过小，需要跟它的实际容量保持一致0 C, p2 @- K. ? I! T W5 }
尽量不调整reweight值，即使调整，也是微调
6 |6 d$ O; i8 j1 F$ I+ P, j, F1 d( M& _' c
|
|
发表于 2023-3-16 13:00:24