|
|
1、 处理故障的pg
% l: J. ^5 g$ z' k+ }$ T从ceph的状态中,可以看到,有一部分的pg处于stale/down/peering等状态,这部分异常的pg不能提供对外提供服务,影响了业务的可用性,通过ceph health detail找到这部分异常的pg,发现其中有一些pg的upset中都没有映射到osd,或者三副本只选出来2个osd,没有选出来第3个osd,下面是当时故障的pg的状态:# F" m( ]( E: r5 @
* F, Y: ^& {: g, T+ s/ T
1 ~$ c; f0 R+ o: M- ^( A; V
' U2 w* M7 E" L这个现象很有可能是权重不平衡导致的,关于权重在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:+ K! [% S/ F2 U: x5 I9 p6 p
. t/ N% X6 K0 h0 n1 B: H; S4 j ]% u2 K- ~ j! \8 ]
ceph health detail | grep stale
# _: J* s. Q, o6 g" {6 X- H+ Uceph pg <pgid> query; m: A% q; t4 V5 {+ ]/ j- i1 j \
ceph osd reweight <id> 1: n; d4 M: i5 b; @4 N9 K; B/ @
置为1之后,观察到该pg重新映射出了osd,并且消除了stale状态,恢复了服务。因为reweight的不确定性,我们调整权重,一般不调整reweight,让它始终保持为1,在L版之前的ceph中,需要通过调整weight值进行数据平衡,L版之后新增了weight-set功能,可以更有效的去平衡数据。
_, h* g4 p( `9 U$ Q: T$ ~0 l: W, k& C! T
此时,可以将所有reweight不为1的osd重置为1:1 h5 j# U- b. x1 l/ E! k
9 ~( `" R2 S3 f
7 m$ b& K" V- W4 d1 k
for i in `cat reweight_osds.txt`; do setsid ceph osd reweight $i 1; done1 _. L, D( S( f2 i5 f+ m
重置为1之后,stale的pg全部恢复了正常,业务也恢复了正常。
1 c# x3 U1 V' [+ P. v
% e, ^, `' q* C& x2. 数据重平衡
4 w {( f% ]) t8 }# K后续需要做的操作就是继续平衡数据,但是要保持各个osd-domain的权重值大小一致,然后可以微调osd的weight值,将一个osd-domain中高使用率的调低,同时也要将另一个osd-domain中低使用率的调高,平衡数据,直到各个osd的使用率趋于均衡。/ d* ~ z T% s- ^
5 x4 f9 k8 q, q J3. 恢复mon服务8 N( |# R2 ~$ G6 M Q: V
等待数据平衡完成之后,压缩61 62的mon服务,然后启动,再将63加进集群。6 r7 l8 Q. N: k7 J/ \+ Z* l; {! c
8 `6 q% h) X; G. Z3 R, U8 Q# b* n
至此故障处理完成,所以最终总结一下,引起该故障的本质原因,在于调整数据均衡的方式不对,权重调整的幅度过于大,不同osd之间的权重相差悬殊,导致pg出现了问题,进而引发了后续的一系列问题。因此,关于权重值需要关注以下几点:
# O9 m/ @7 n- D N( i& G9 Q, E+ e0 B/ [7 K7 K% e
保持各个bucket的故障域的权重是相等的,bucket里面的osd权重值可以不一致,但是osd上的权重值得保持相等,扩容/缩容,都需要考虑这个问题
) V0 a/ P% X, i3 u) Zweight不要设置过大与过小,需要跟它的实际容量保持一致. M( n* B- K" \7 ]- m
尽量不调整reweight值,即使调整,也是微调
8 L1 a$ i( N) _; o6 ~
! ^3 u! n6 m0 g1 \7 Z3 h |
|