|
|
cephfs扩容方案' K2 N- M1 c4 S% i& f3 x% G
8 g2 M' z2 P0 ?2 P/ B8 G/ o! f
需求描述
9 v2 x" z9 n8 D5 [* y6 B! N! e2 x9 T' [
建立完善的cephfs的扩容方案,满足cephfs用户数据存储空间在各种场景下的扩容需求。目前扩容只涉及到用户的数据存储,元数据部分因为空间使用率较低所以不需要考虑扩容。0 v# O, S+ Q6 V
" D! z, i9 y& _8 K
现有cephfs用户存储模型
. d8 m* D" n5 ^( Y- {+ o0 Q, m! G" S9 a' @
目前单个用户会对应一个ceph集群里面的多个Dir目录,每个Dir目录底层会关联到两个pool,其中metadata_pool用来存储元数据,data_pool用来存储数据。7 o4 Z0 }7 m" Z. T" [8 M
0 M& E# a$ o- u( @3 W A1 M" b+ ^! X3 N7 |3 A. G$ V& i
H! x" m% }6 C }( J单集群扩容方案( i0 G- V: D9 Z7 f! M
/ H i z7 d) U; b& v$ T* M4 k通过filelayout进行扩容3 M/ ?- ?0 W# R* k
( ^3 M7 U' B# I$ f* j, ]; L基本原理
* G9 Z' G4 _3 q, G* t4 q% W, o b7 W- K4 ^% C" {
每个文件都有filelayout的xattr属性,其中包含一个关键的pool字段,用来指定存储文件底层用到哪个pool,因此利用该特性可以实现基于目录基本的扩容。7 V$ f. ]5 f, z; s% L9 N
1 |2 b: u* m" ]' ~: R& R6 G# A7 K5 w
参考 https://docs.ceph.com/docs/maste ... ata-pool-to-the-mds
a- x" q2 r4 `& E5 W
' Y# h- d* O$ K- J# v A操作流程
5 A Q( A3 H% Z1 @1 _5 q: _) X5 h t9 ~
root@host1:/mnt/cephfs1# ceph df RAW STORAGE: CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 952 TiB 861 TiB 89 TiB 91 TiB 9.52 TOTAL 952 TiB 861 TiB 89 TiB 91 TiB 9.52 POOLS: POOL ID STORED OBJECTS USED %USED MAX AVAIL rbdtest-site1-ssd-img 1 8.7 TiB 2.34M 26 TiB 24.58 27 TiB rbdtest-site1-sas-img 2 8.8 TiB 2.31M 26 TiB 3.63 233 TiB cephfs_metadata 3 85 GiB 116.05k 86 GiB 0.10 27 TiB cephfs_data 4 12 TiB 198.68M 36 TiB 30.65 27 TiB cephfs_pool1 5 121 GiB 31.04k 364 GiB 0.44 27 TiB sym_cephfs_data 6 656 KiB 13 3.6 MiB 0 233 TiB sym_cephfs_metadata 7 0 B 0 0 B 0 233 TiB kubernetes 20 152 B 6 192 KiB 0 233 TiB root@host1:/mnt/cephfs1# setfattr -n ceph.dir.layout.pool -v cephfs_pool1 /mnt/cephfs1/extest1/ root@host1:/mnt/cephfs1# getfattr -n ceph.dir.layout /mnt/cephfs1/extest1 getfattr: Removing leading '/' from absolute path names # file: mnt/cephfs1/extest1 ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 pool=cephfs_pool1" root@host1:/mnt/cephfs1/extest1# touch file2 root@host1:/mnt/cephfs1/extest1# getfattr -n ceph.file.layout /mnt/cephfs1/extest1/file2 getfattr: Removing leading '/' from absolute path names # file: mnt/cephfs1/extest1/file2 ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 pool=cephfs_pool1"
5 F4 W2 k* X. D$ o2 ]6 `. C0 u9 X# F! P! c, @
方案1. 同级目录扩容
/ w3 l% u. @* d/ ~# P M9 x1 \
* e& D# s! ]" M* ?& c7 K: R如果业务侧能够按新增主目录方式进行扩容,则可以通过新增一个用户主目录,将新目录指向新的data_pool来实现扩容。
. j# I6 a. F" {" b0 S; M
: J' E6 [6 P" W5 d0 U优点:新扩容的pool不会对现有存储服务造成影响。3 J% E2 y( [+ t: B* I
: R8 x$ D, @7 T8 {/ R
缺点:业务需要能够适配这种新增子目录的扩容方式。" ^4 m5 E( K0 i1 s, D
5 Y/ ?9 z, }" r2 z, G" v1 V( d y+ A, z O, y2 F5 M$ F
/ F0 ~; }$ |$ C8 T1 X! _% V方案2. 子目录扩容
7 t- \( Y5 x; S+ w0 D% X! Q& P
8 h8 N; k! s! ~/ e( Q( a% k如果业务侧只能在原有主目录中进行操作,则可以通过在原有主目录下新增一个用户子目录,将新生成的子目录指向新的data_pool来实现扩容。
" N. Z W) ^2 R" z/ `5 c) h/ v& B. r
优点:新扩容的pool不会对现有存储服务造成影响。6 A$ R* a0 ` A8 x2 k0 {$ M
; m1 n- q+ U+ ], v# [' a$ Y缺点:业务需要能够适配这种新增子目录的扩容方式。7 d) T. e: Q$ ~
/ k8 I& m& H! p0 [
1 S! }; O% N! N) I5 M2 _2 E7 ]4 _4 A* x7 I$ Y5 s2 K
通过新增OSD进行扩容
' _# g. t$ \2 t$ ]" B
/ w- r- K& D& ?基本原理8 }6 B- d, ~$ S- ?
, @# P8 s/ P& x) N9 d基于原生底层分布式存储的基本特性,可以在原有的pool里面新增OSD进行扩容,但是新增OSD会导致旧有数据重新平衡,造成性能波动,影响服务质量。0 h4 _3 b0 [0 T" x
( e5 C3 Y, Z2 w: N7 |& K) V方案3. 原有data_pool扩容
/ B% A6 |1 U! L. }5 G1 A: O
" c2 G! @, [) g! w* y' r8 p L: H通过在原有data_pool中新增OSD来实现扩容。+ K, x' J% y# o( l
3 k5 L0 [# x% q' N
优点:业务和k8s层面不需要做任何变动,完全对上层透明。- D5 [: r/ u2 l+ z# x
( A' G6 [1 ]/ i& M% B
缺点:旧集群在新增OSD的时候会发生性能抖动,同时为了兼顾扩容速率和减少业务影响,相对扩容周期会比较长。受限与机房机柜和网络设备环境,有物理层面的上限。
5 w& i2 e$ F& M2 u8 h" W, I% S6 l/ A
# A4 x$ Q" w6 K! C
/ J- r6 k0 {/ @) {多集群扩容方案
4 S! g8 s, X) C1 _
6 j) q% ~! S# |: t方案4. 新增ceph集群
; f0 [/ \: I1 H- t* L2 Q+ |. e1 U0 {: O. x2 X
受限于单集群规模存储集群的规模有限(受限机柜、网络等),单机房多集群、多机房多集群都会可能存在,因此这一块的存储扩容方案也会纳入设计范围。- g0 r8 y- d2 k3 X4 V" f0 S4 ^( K9 b) ^
; Z, H+ f+ I2 x5 f M7 o
优点:适配现有的单集群部署方案(1个集群跨3个机柜),相对来讲容易做故障域隔离(鸡蛋不放一个篮子里).扩容新集群不会对现有存储服务造成影响。4 L# j+ T% i2 M% J" v, ~
0 ~0 q8 u/ s, ^: u缺点:需要业务能够适配这种跨集群模型(跨集群的目录数据不能互通),单个docker里面最好不要同时挂载两个以上集群的目录。k8s的存储资源调度复杂度上升,需要支持多集群。
5 ^' U' p# C) _7 a+ y
6 H$ p* S+ E, U) ?9 {3 g- h9 T" k
) a7 C4 j& o ^& x# Y/ g# @ |
|