以之前的GlusterFS來說, 在容錯方面都是用replicate來做, 或是搭配stripe做成stripe replicate volume.
因為複製就是1:1(或更多), 所以實際可用容量會是底層容量的1/2或更少, 說起來相當浪費
而disperse volume目前看起來是一個很好的想法.
簡單來說, disperse volume就類似硬碟的RAID5或RAID6.
把資料分散到各個brick上, 但是同時利用erasure code處理
所以當其中有brick掛掉時, 只要不超過當初建立volume時設定的redundant brick數量, 就可以維持正常運作.
下面是一個簡單的POC.
我用CentOS 6.6架設, 搭配目前最新的GlusterFS 3.7.0 RPM.
gfs1:/export/brick1
gfs2:/export/brick2
gfs3:/export/brick3
這3個server都用8GB的disk做XFS當作brick, 掛載在/export底下.
最後有一個client VM來掛載.
這裡直接跳到建立volume的步驟:
gluster volime create gfs disperse 3 gfs1:/export/brick1 gfs2:/export/brick2 gfs3:/export/brick3
要注意的是, 如果只指定總共的brick數量, 則GlusterFS會自動幫你決定redundant brick數量.
你也可以自己用
disperse-data <COUNT> redundancy <COUNT>
來指定數量.
另外, 因為使用的erasure code的特性, disperse volume裡的data brick總數, 建議要是2的次方數.
例如上面的3+1就不是, 4+1或者4+2會是比較好的組合
這裡我們一共3個brick, 最後GlusterFS決定redundancy是1, 也就是同時間可以掛掉1個brick.
這等於手動用
disperse-data 2 redundancy 1
來建立volume.
然後啟動volume, 讓client去掛載, 這裡並不需要有什麼改變.
[root@client ~]# mount gfs1:/gfs /gfs -t glusterfs
[root@client ~]# df -h /gfs
Filesystem Size Used Avail Use% Mounted on
gfs1:/gfs 16G 65M 16G 1% /gfs
可以看到總容量是2個brick的容量, 這裡也跟RAID5類似.
再來又是玩弄的時間XD
跟上次的測試類似, 我在資料寫入volume的中途, 切斷其中一個server的網路
client寫入會暫停, 經過42秒的timeout之後繼續寫入, 連線恢復之後server會自動補上斷線期間的資料傳輸.
這功能大大提升了GlusterFS的彈性, 但是這裡還是有一些地方要注意.
例如如果我在一個server上放了2個brick, 那麼就要考慮這個server斷線導致同時掛掉2個brick的可能性.
3 comments:
補充:
目前disperse volume的brick數量是固定的, redundancy無法事後調整.
事後加入brick是可以的, 但以目前來說, 必須要一次加入disperse-data的數量
例如建立volume時是disperse-data 3 redundancy 1
那麼加入brick時就要一次加進去3個brick.
http://www.gluster.org/pipermail/gluster-users/2014-November/019443.html
Mike您好:
想請問您disperse-data這個參數目前還有嗎?
我參考了gluster.readthedocs.io好像找不到disperse-data,只看到disperse,不知道是否是新舊版本的差異?
我目前的版本是3.7,謝謝您~
Hi~
剛看了一下文件, 參數名子換了:) 所以你看到的狀況是正常的.
雖說我還不大敢在production環境用這功能 XD
Post a Comment