本博文將介紹glusterfs集羣的創建過程；glusterfs的複製，條帶，哈希等基本卷類型及實際生產中使用率最高的哈希複製卷類型的基本原理，數據存儲方式及各種類型卷的創建和使用方法。
glusterfs的安裝方法見：
http://wangziyin.blog.51cto.com/6948950/1649838
1、測試環境
192.168.21.18 rhel6.5 vmserver server1
192.168.21.19 rhel6.5 vmserver server2
192.168.21.17 rhel6.5 vmserver client
請將主機名進行host解析，如果你使用主機名；NTP時間同步；iptables stop；selinux disable
服務啓動：
# /etc/init.d/glusterd start
# chkconfig glusterd on
2、創建gluster集羣
創建集羣是用gluster peer probe 命令
[root@lvs mnt]# gluster
gluster> peer help
peer probe <HOSTNAME> - probe peer specified by <HOSTNAME>
peer detach <HOSTNAME> [force] - detach peer specified by <HOSTNAME> #刪除集羣節點
peer status - list status of peers #list全部集羣節點，顯示除自己的其他全部節點
peer help - Help command for peer
pool list - list all the nodes in the pool (including localhost)
當前版本peer所具有的全部命令
在創建的時候使用ip和主機名都是可以的，但是host需要進行解析
gluster> peer probe 192.168.21.18
peer probe: success.
gluster> peer probe 192.168.21.19
peer probe: success. Probe on localhost not needed
使用peer查看當前集羣的節點的狀態
gluster> peer status
Number of Peers: 1 #看到只有一個節點，gluster默認是不顯示loaclhost的，如果去18上也就只能看到19
Hostname: 192.168.21.18
Uuid: 0d556480-b80b-4bff-b825-89bce6be1a3b
State: Peer in Cluster (Connected) #表示18節點已連接
3、創建glusterfs的卷
3.1 glusgerfs卷的類型
基本類型：條帶，複製，哈希。然後還有兩兩組合和三種類型同時使用，總共加起來共7種，新版的還有冗餘卷
3.2 創建數據分區
兩個節點分別創建/data0/gluster目錄，所謂brick的位置，用於存儲數據
3.3 創建volume
3.3.1 哈希卷：
哈希卷類似與負載均衡（實際上不是很均衡），他會將完整的數據分成幾個不分，分別存儲在每一個brick上。
gluster> volume create datavol1 transport tcp 192.168.21.18:/data0/gluster/data1 192.168.21.19:/data0/gluster/data1 force
因爲默認是哈希卷，所以卷的類型沒有指定，datavol1 這個volume擁有兩個brick，分佈在兩個peer節點；
gluster> volume start datavol1 #啓動volume
volume start: datavol1: success
gluster> volume info
Volume Name: datavol1 #卷名
Type: Distribute #哈希卷
Volume ID: e46b32f3-7490-4403-99db-d19ba8968a12
Status: Started #started已經啓動
Number of Bricks: 2 #brick數量
Transport-type: tcp
Bricks:
Brick1: 192.168.21.18:/data0/gluster/data1
Brick2: 192.168.21.19:/data0/gluster/data1
gluster> volume status datavol1
Status of volume: datavol1
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data1 49152 Y 2048
Brick 192.168.21.19:/data0/gluster/data1 49152 Y 16567
NFS Server on localhost 2049 Y 16588
NFS Server on 192.168.21.18 2049 Y 2075
以上是volume的狀態信息，可以看到在每一個節點上啓動一個volume後，gluster會自動的啓動相關的進程，Port機監聽的端口。
我們在使用ps去查看的時候此時會有3個進程：
glusterd #管理進程
glusterfsd #brick進程，因爲本機上只有一個brick
glusterfs #默認啓動的nfs的協議進程，是可以關閉的
在另外一個節點上會啓動相同的進程。
3.3.3 創建複製卷
複製卷和條帶卷必須要指定卷的類型，複製卷就是每一個brick中的數據都是一樣的，都是寫入數據的完整備份，相當raid1，所以容量會減少一半，當然性能上也會有所消耗，您想，同一個文件寫一次快還是寫兩次快。
gluster> volume create datavol2 replica 2 transport tcp 192.168.21.18:/data0/gluster/data2 192.168.21.19:/data0/gluster/data2 force
這裏需要指定複製卷的數量，目前支持比較好的是2或者3副本，事實上個人覺得3最好了，性能上還可以接受，安全上比2要好，因爲是無中心的，2個brick複製可能腦裂的機率會比較大。
爲了比較看起來比較爽一點，我們把datavol1 這個哈希卷停掉，然後把複製卷datavol2啓動：
gluster> volume stop datavol1
gluster> volume start datavol2
這裏仍然會啓動glusterd進程
glusterfsd進程，brick的服務進程
/usr/sbin/glusterfs -s localhost --volfile-id gluster/nfs #glusterfs的nfs進程
因爲是複製卷會啓動一個自修復的進程：
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd
volume status查看卷的狀態，如果不指定volume會將所有的volume的狀態顯示出來：
gluster> volume status
Volume datavol1 is not started
Status of volume: datavol2
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data2 49153 Y 2222
Brick 192.168.21.19:/data0/gluster/data2 49153 Y 16751
NFS Server on localhost 2049 Y 16767
Self-heal Daemon on localhost N/A Y 16773
NFS Server on 192.168.21.18 2049 Y 2237
Self-heal Daemon on 192.168.21.18 N/A Y 2243
可以看見vol1是sto的，vol2是我們剛創建的複製卷，並且左右的都是Online狀態，如果發現哪一個brick不是Online，那就得注意檢查這個brick節點了。
3.3.5 創建條待卷
條帶卷在處理大文件的時候會有一定的作用，它會將文件拆分幾個不分，分別存在兩個條帶上即兩個brick上。這個實際用的較少，個人沒有用過，所以理解上可能有誤。
gluster> volume create datavol3 stripe 2 192.168.21.18:/data0/gluster/data3 192.168.21.19:/data0/gluster/data3 force
volume create: datavol3: success: please start the volume to access data
gluster> volume status datavol3
Volume datavol3 is not started
gluster> volume start datavol3
volume start: datavol3: success
stripe和replica一樣指定了卷的類型，後邊的數字是條帶的數量
3.3.6 符合卷
符合卷就是哈希複製，哈希條帶，這兩個是比較常用的，向條帶複製卷，還有三種揉一塊兒的用的都比較少
之前單一類型的卷，複製、條帶和brick的數量是相同的，但是當我們的brick的數量是複製或條帶的倍數的時候就會自動的轉換爲哈希複製或者哈希條帶。
這裏我們用4個brick
哈希複製卷是一對一對組成複製卷，所以要選擇不同的節點上的brick組成複製卷，這樣一個數據的副本就會分佈在不同的節點上，不管那個節點宕機，另外一個節點都會數據的完整副本。
上圖的紅色標記是複製的數量，綠色的是兩個節點之間的brick構成複製關係，***的兩個brick構成複製關係，192.168.21.18上的data_rd_1和data_rd_2構成哈希關係，19節點同樣，所以兩個節點都具有數據的完成副本。這裏千萬不要同一節點的brick間構成複製，兩個節點間哈希，這樣每個節點上都只保存數據的一部分，任意掛一個節點，你就該哭了。
gluster> volume info data_rd
同樣應該start這個卷，
gluster> volume status data_rd
Status of volume: data_rd
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data_rd_1 49155 Y 2308
Brick 192.168.21.19:/data0/gluster/data_rd_1 49155 Y 16847
Brick 192.168.21.18:/data0/gluster/data_rd_2 49156 Y 2319
Brick 192.168.21.19:/data0/gluster/data_rd_2 49156 Y 16858
NFS Server on localhost 2049 Y 16870
Self-heal Daemon on localhost N/A Y 16879
NFS Server on 192.168.21.18 2049 Y 2331
Self-heal Daemon on 192.168.21.18 N/A Y 2341
上邊的status可以看出，只要存在複製卷，就會在每一個節點上啓動自恢復進程，用於自我修復數據。
3.4 卷的使用
這裏新加了一臺vmserver：192.168.21.17作爲測試的client 因爲一會兒需要將它擴展到之前的節點中去，所以全部安裝了server+client的包。
掛載類似與NFS，本地創建一個目錄，mount過來就OK了。
所以先創建本地掛載點：
# mkdir -p /data0/disperse #掛載哈希卷
# mkdir -p /data0/replica #掛載複製卷
# mkdir -p /data0/stripe #掛載條帶卷
# mount -t glusterfs 192.168.21.18:datavol1 /data0/disperse
# mount -t glusterfs 192.168.21.19:datavol2 /data0/replica
# mount -t glusterfs 192.168.21.19:datavol2 /data0/stripe
因爲兩個節點是完全對等的，所以你在掛哪一個ip地址都是一樣的。
寫到fstab：
192.168.21.18:datavol1 /data0/disperse glusterfs defaults 0 0
192.168.21.19:datavol2 /data0/replica glusterfs defaults 0 0
192.168.21.19:datavol3 /data0/stripe glusterfs defaults 0 0
mount -a測試沒有報錯就表明成功掛載，df看一下吧
192.168.21.18:datavol1 13G 2.2G 11G 18% /data0/disperse
192.168.21.19:datavol2 6.5G 1.3G 5.0G 20% /data0/replica
192.168.21.19:datavol3 6.5G 1.3G 5.0G 20% /data0/stripe
從容量可以看出，哈希卷和條帶卷是兩個brick容量之和，複製只有一個brick的大小。
3.5 測試：
我們在哈希卷的目錄/data0/disperse中寫入10個文件
[[email protected] disperse]# pwd
/data0/disperse
[[email protected] disperse]# touch testfile{1,2,3,4,5,6,7,8,9,10}
[[email protected] disperse]# ls
testfile1 testfile10 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9
我們去192.168.21.18和19的對應的brick上看分別存儲的數據。
19：
[root@lvs ~]# ls /data0/gluster/data1/
testfile1 testfile10 testfile2 testfile3 testfile4 testfile6 testfile8
18：
[root@lvs ~]# ls /data0/gluster/data1/
testfile5 testfile7 testfile9
可以看見哈希卷將完整的數據哈希成兩份，分別存在兩個brick上，相當於raid0，所以這種方式寫入的速度也是最快的。
條待卷：
[[email protected] stripe]# pwd
/data0/stripe
[[email protected] stripe]# du -sh /root/root.tar.gz
140M /root/root.tar.gz
[[email protected] stripe]# cp /root/root.tar.gz .
在192.168.21.17上有一個140M的文件，複製到掛載了條待卷的目錄下
18節點：
[root@lvs ~]# ls /data0/gluster/data3/
root.tar.gz
[root@lvs ~]# du -sh /data0/gluster/data3/root.tar.gz
70M /data0/gluster/data3/root.tar.gz
19節點：
[root@lvs ~]# du -sh /data0/gluster/data3/root.tar.gz
70M /data0/gluster/data3/root.tar.gz
可見條待卷將完成的一個文件分成兩個部分存儲在不同的brick上，同時拆分數據，與哈希卷不同的是，哈希卷是以文件爲單位的哈希分配。
複製卷比較簡單不再測試。
下來看一下哈希複製卷：
# mkdir -p /data0/data_rd
# mount -t glusterfs 192.168.21.18:data_rd /data0/data_rd/
我們將之前/data0/disperse下10個文件和root.tar.gz複製到/data0/data_rd/下：
18節點：
[root@lvs ~]# ls /data0/gluster/data_rd_1/
testfile5 testfile7 testfile9
[root@lvs ~]# ls /data0/gluster/data_rd_2
root.tar.gz testfile1 testfile10 testfile2 testfile3 testfile4 testfile6 testfile8
19節點：
[root@lvs ~]# ls /data0/gluster/data_rd_1/
testfile5 testfile7 testfile9
[root@lvs ~]# ls /data0/gluster/data_rd_2
root.tar.gz testfile1 testfile10 testfile2 testfile3 testfile4 testfile6 testfile8
可以看到同一個節點下的兩個brick構成哈希卷，文件哈希分配到兩個brick上，而兩個節點對應的brick上都是對方數據的完成副本，這個應該相當於raid10吧。
3.6 簡單的故障測試
以下我們模擬以下一個節點宕機的情況吧。這個應該是經常遇到的，不管是意外還是重啓還是調整，總之肯定是會出現的。
我們吧192.168.21.19這個節點網卡停掉。
[root@lvs ~]# /etc/init.d/network stop
gluster> peer status
Number of Peers: 1
Hostname: 192.168.21.19
Uuid: 2588fd9d-feb0-411e-aa5a-60821c78fddb
State: Peer in Cluster (Disconnected)
這是18這個節點上的peer狀態，19這個節點已經失聯了。
Status of volume: datavol1
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data1 49152 Y 2382
NFS Server on localhost 2049 Y 2403
volume的狀態也只有18的brick在線。
故障呢，就是這麼個情況，正常情況下應該是客戶端的對應掛載點下的文件完整可以正常訪問，文件數量完整，目錄可以創建刪除文件。這裏哈希卷除外啊，肯定是不完整的，哈希複製卷中如果您沒有按照要求構建複製卷的話，也可能是不完整的。
[[email protected] data0]# ls /data0/disperse/
testfile5 testfile7 testfile9
[[email protected] data0]# ls /data0/stripe/
[[email protected] data0]# ls /data0/data_rd/
root.tar.gz testfile1 testfile10 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9
在客戶端上可以看出，掛載點目錄都是可以正常訪問的。哈希卷只有18節點上文件正常，19上的brick中文件就飛了；條帶卷就更坑了，文件完全沒有了（條帶將文件內容拆分存放，只要一個節點故障，文件就沒法重新拼接）；哈希複製卷最給力了，完全沒有受到影響。當然如果之前測試了複製卷也是不會有影響的。
接下來我們在複製卷掛載點/data0/replica下創建一個文件，內容爲“you are the one”
# echo "you are the one" > /data0/replica/testfile_replica
18上：
[root@lvs ~]# cat /data0/gluster/data2/testfile_replica
you are the one
文件已經正常寫入，並在客戶端可以被正常讀取，所以掛掉一個節點，完全沒有問題的，雖然我們/data0/replica掛載的時候連接的是192.168.21.19（mount -t glusterfs 192.168.21.19:datavol2 /data0/replica），但目錄的操作還是絲毫沒有受到影響。
df看掛載信息，192.168.21.19雖然已經不通了，一樣不受影響。事實上，這裏掛載的都是192.168.21.18節點只是glusterfs在檢測到19節點掛了之後會將掛載路徑重定向到其他節點，所以如果你在19掛了之後第一時間來執行df命令，顯示的時候肯定會卡一會兒的。
故障恢復:
將19的網絡啓動，
gluster> peer status
Number of Peers: 1
Hostname: 192.168.21.19
Uuid: 2588fd9d-feb0-411e-aa5a-60821c78fddb
State: Peer in Cluster (Connected)
查看複製卷datavol2的19節點上brick：192.168.21.19:/data0/gluster/data2 的內容，因爲我們在它故障的時候寫入一個文件：testfile_replica 內容爲“you are the one”
19節點：
[root@lvs ~]# cat /data0/gluster/data2/testfile_replica
you are the one
故障節點在恢復之後會同步其他節點的配置信息，並將文件同步。
注意：
在實際使用當中，因爲網絡延遲，副本過多等諸多問題，出現過以下問題：
例如實際中我們在聯通和電信的機房內使用了複製卷，因爲存在跨運營商跨機房的複製，文件同步速度不是很理想，並且有多個不同的節點掛載了複製卷。就會有這樣一個問題，掛載點A vim修改了文件F1,比如數據首先寫入到V1節點，同時V2節點就會檢測自己的文件和V1文件是否一樣，當不一樣的時候就會啓動自我修復功能，將V1節點的文件同步過來。在這同步的過程中，在其他掛載點可能就出現文件無法訪問的情況。