第1步 - 至少有三個節點
-
名爲“server1”，“server2”和“server3”的3個節點上的Fedora 26（或更高版本）
-
一個有效的網絡連接
-
每個虛擬機上至少有兩個虛擬磁盤，一個用於操作系統安裝，另一個用於服務GlusterFS存儲（sdb）。這將模擬真實世界的部署，您可能希望將GlusterFS存儲與操作系統安裝分開。
-
在每個服務器上設置NTP，以便在文件系統之上正常運行許多應用程序。
注意：GlusterFS將其動態生成的配置文件存儲在/var/lib/glusterd。如果在任何時間點GlusterFS無法寫入這些文件（例如，當後備文件系統已滿時），它將至少導致系統出現不穩定行爲; 或者更糟糕的是，讓您的系統完全脫機。建議爲目錄創建單獨的分區，/var/log以減少發生這種情況的可能性。
第2步 - 格式化並安裝磚塊
在所有節點上執行此步驟，“server {1,2,3}”
注意：我們將使用XFS文件系統作爲後端塊。但Gluster旨在處理任何支持擴展屬性的文件系統。
以下示例假定brick將駐留在/ dev / sdb1上。
mkfs.xfs -i size=512 /dev/sdb1
mkdir -p /data/brick1
echo '/dev/sdb1 /data/brick1 xfs defaults 1 2' >> /etc/fstab
mount -a && mount
您現在應該看到sdb1掛載在/ data / brick1
第3步 - 安裝GlusterFS
安裝軟件
yum install glusterfs-server
啓動GlusterFS管理守護程序：
service glusterd start
service glusterd status
glusterd.service - LSB: glusterfs server
Loaded: loaded (/etc/rc.d/init.d/glusterd)
Active: active (running) since Mon, 13 Aug 2012 13:02:11 -0700; 2s ago
Process: 19254 ExecStart=/etc/rc.d/init.d/glusterd start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/glusterd.service
├ 19260 /usr/sbin/glusterd -p /run/glusterd.pid
├ 19304 /usr/sbin/glusterfsd --xlator-option georep-server.listen-port=24009 -s localhost...
└ 19309 /usr/sbin/glusterfs -f /var/lib/glusterd/nfs/nfs-server.vol -p /var/lib/glusterd/...
步驟4 - 配置防火牆
節點上的gluster進程需要能夠相互通信。要簡化此設置，請在每個節點上配置防火牆以接受來自其他節點的所有流量。
iptables -I INPUT -p all -s <ip-address> -j ACCEPT
防火牆前期直接關了就行先不管它 chkconfig iptables off # 永久關閉，重啓生效 reboot
其中ip-address是另一個節點的地址。
步驟5 - 配置信任池
來自“server1”
gluster peer probe server2
gluster peer probe server3
注意：使用主機名時，需要從另一臺服務器探測第一 臺服務器以設置其主機名。
來自“server2”
gluster peer probe server1
注意：建立此池後，只有受信任的成員才能將新服務器探測到池中。新服務器無法探測池，必須從池中進行探測。
檢查server1上的對等體狀態
gluster peer status
你應該看到這樣的東西（UUID會有所不同）
Number of Peers: 2
Hostname: server2
Uuid: f0e7b138-4874-4bc0-ab91-54f20c7068b4
State: Peer in Cluster (Connected)
Hostname: server3
Uuid: f0e7b138-4532-4bc0-ab91-54f20c701241
State: Peer in Cluster (Connected)
步驟6 - 設置GlusterFS卷
在所有服務器上：
mkdir -p /data/brick1/gv0
從任何一臺服務器：
gluster volume create gv0 replica 3 server1:/data/brick1/gv0 server2:/data/brick1/gv0 server3:/data/brick1/gv0
gluster volume start gv0
確認卷顯示“已啓動”：
gluster volume info
您應該看到類似的內容（卷ID會有所不同）：
Volume Name: gv0
Type: Replicate
Volume ID: f25cc3d8-631f-41bd-96e1-3e22a4c6f71f
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: server1:/data/brick1/gv0
Brick2: server2:/data/brick1/gv0
Brick3: server3:/data/brick1/gv0
Options Reconfigured:
transport.address-family: inet
注意：如果卷未顯示“已啓動”，/var/log/glusterfs/glusterd.log則應檢查下面的文件 以便調試和診斷情況。可以在配置的一個或所有服務器上查看這些日誌。
第7步 - 測試GlusterFS卷
對於此步驟，我們將使用其中一個服務器來裝入卷。通常，您可以從外部計算機（稱爲“客戶端”）執行此操作。由於使用此方法需要在客戶端計算機上安裝其他軟件包，因此我們將使用其中一個服務器作爲首先進行測試的簡單位置，就像它是“客戶端”一樣。
mount -t glusterfs server1:/gv0 /mnt
for i in `seq -w 1 100`; do cp -rp /var/log/messages /mnt/copy-test-$i; done
首先，檢查客戶端掛載點：
ls -lA /mnt/copy* | wc -l
您應該看到返回100個文件。接下來，檢查每臺服務器上的GlusterFS磚安裝點：
ls -lA /data/brick1/gv0/copy*
您應該使用我們在此處列出的方法在每臺服務器上看到100個文件。如果沒有複製，在僅分發卷（此處未詳述）中，您應該在每個捲上看到大約33個文件。
一些可能用到的命令
man glusterfs 查看全部的使用命令
service gluster start 啓動glusterfs服務
service glusterd status 查看服務的啓動狀態
mount 檢查掛載點 服務能起來說明掛載沒問題
systemctl stop firewalld 關閉防火牆
systemctl start glusterfsd 啓動守護進程
systemctl enable glusterfsd 設置開機自啓
systemctl restart glusterfsd 關閉進程
fdisk -l 查看磁盤設備特別直觀
tar -xzvf filename 解壓.tar文件
unzip filename linux自帶的一個解壓.zip文件命令
netstat -an 查看開啓了那些端口 以及端口的網絡連接情況
常見術語
Xlator=translator:glusterfs 模塊的代名詞
Brick :存儲目錄是Glusterfs的基本存儲單元，由可信存儲池中服務器上對外
輸出的目錄表示。存儲目錄的格式由服務器和目錄的絕對路徑構成，具體如下：
SERVER:EXPORT.例如：myhostname:/exports/myexportdir/
Volume :卷是存儲目錄的邏輯組合。大部分gluster 管理操作是在捲上進行的。
Metadata:元數據關於數據的數據，用於描述文件、目錄等的相關信息。
FUSE=Filesystem inUserspace: 是一個內核模塊，允許用戶創建自己的文件系
統無需修改內核代碼。
Glusterd : Glusterfs 後臺進程，運行在所有Glusterfs 節點上。
DistributeVolume: 分佈式卷
ReplicateVolume: 副本卷
StripeVolume: 條帶卷
DistributeReplicate Volume: 分佈式副本卷
DHT=Distribute HashTable
AFR=Automatic FileReplication
SAN = Storage AreaNetwork： 存儲區域網絡是一種高速網絡或子網絡，提供在計算機與存儲之間的數據傳輸。
NAS = Network-attachedstorage：網絡附屬存儲是一種將分佈、獨立的數據整合爲大型、集中化管理的數據中心，
以便於對不同主機和應用服務器進行訪問的技術。
RPC =Remote ProcedureCall: 遠程過程調用
XDR =eXtern DataRepresentation: RPC 傳遞數據的格式
CLI=Command LineInterface 控制檯
argp=Argument Parser
UUID=University UnqiueIdentifier
SVC =service
CLNT =client
MGMT=management
cbks = Call Backs
ctx = context
lk = lock
attr = attribute
txn = transaction
rb = replace brick
worm = write once , readmany
Glusterfs .glusterfs目錄
.glusterfs目錄大小基本是等於當前brick中的所有文件大小，原因是裏面主要存放的是brick中文件的硬鏈接。
一、什麼是分佈式文件系統
簡單的說，
分佈式文件系統就是將固定於某個點的某個文件系統，
擴展到任意多個地點/多個文件系統，
衆多的節點組成一個文件系統網絡。
通過網絡進行節點間的通信和數據傳輸。
你無需關心數據是存儲在哪個節點，
或是從哪個節點讀取數據。
分佈式存儲按其存儲接口分爲三種：文件存儲、塊存儲和對象存儲。
glusterfs堆棧式結構
Glusterfs是根據fuse提供的接口實現的一個用戶態的文件系統，主要包括gluster、glusterd、glusterfs和glusterfsd四大模塊組成。
二、Gluster是什麼？
GlusterFS（GNU ClusterFile System）.
一個開源的分佈式文件系統
與Lustre、MooseFS、CEPH並列成爲四大開源分佈式文件系統
2011年Red hat以1.36億美元現金的價格收購Gluster
GlusterFS目前在開源社區活躍度非常之高
分佈式存儲已經研究很多年，但直到近年來，伴隨着谷歌、亞馬遜和阿里等互聯網公司雲計算和大數據應用的興起，它才大規模應用到工程實踐中。如谷歌的分佈式文件系統GFS、分佈式表格系統google Bigtable，亞馬遜的對象存儲AWS，阿里的TFS等都是很好的代表，同時也催生了一大批優秀的開源分佈式存儲系統，包括ceph、swift、Lustre和glusterfs等。
三、Gluster的優缺點
優點：
1.無元數據服務設計，彈性HASH
2.高性能：PB級容量、GB級吞吐量、數百集羣規模
3.用戶空間模塊化堆棧式設計
4.高可用性，支持複製和自修復
5.適合大文件存儲
缺點：
1.小文件性能表現差
2.系統OPS表現差
3.複製存儲利用率低（HA和糾刪碼方案）
4.元數據性能
GlusterFS優點分析：
GlusterFS（GNU ClusterFile System）是一個開源的分佈式文件系統，它的歷史可以追溯到2006年，最初的目標是代替Lustre和GPFS分佈式文件系統。經過八年左右的蓬勃發展，GlusterFS目前在開源社區活躍度非常之高，這個後起之秀已經儼然與Lustre、MooseFS、CEPH並列成爲四大開源分佈式文件系統。由於GlusterFS新穎和KISS（KeepIt as Stupid and Simple）的系統架構，使其在擴展性、可靠性、性能、維護性等方面具有獨特的優勢，目前開源社區風頭有壓倒之勢，國內外有大量用戶在研究、測試和部署應用。
無元數據節點性能瓶頸
採用無中心對稱式架構，沒有專用的元數據服務器，也就不存在元數據服務器瓶頸。元數據存在於文件的屬性和擴展屬性中。當需要訪問某文件時，客戶端使用DHT算法，根據文件的路徑和文件名計算出文件所在brick，然後由客戶端從此brick獲取數據，省去了同元數據服務器通信的過程。
良好的可擴展性
良好的可擴展性
使用彈性hash算法代替傳統的有元數據節點服務，獲得了接近線性的高擴展性。
高可用
採用副本、EC等冗餘設計，保證在冗餘範圍內的節點掉線時，仍然可以從其它服務節點獲取數據，保證高可用性。採用弱一致性的設計，當向副本中文件寫入數據時，客戶端計算出文件所在brick，然後通過網絡把數據傳給所在brick，當其中有一個成功返回，就認爲數據成功寫入，不必等待其它brick返回，就會避免當某個節點網絡異常或磁盤損壞時因爲一個brick沒有成功寫入而導致寫操作等待。
服務器端還會隨着存儲池的啓動，而開啓一個glustershd進程，這個進程會定期檢查副本和EC卷中各個brick之間數據的一致性，並恢復。
存儲池類型豐富
包括粗粒度、條帶、副本、條帶副本和EC，可以根據用戶的需求，滿足不同程度的冗餘。粗粒度卷不帶任何冗餘，文件不進行切片，是完整的存放在某個brick上。
條帶卷不帶任何冗餘，文件會切片存儲（默認大小爲128kB）在不同的brick上。這些切片可以併發讀寫（併發粒度是條帶塊），可以明顯提高讀寫性能。該模式一般只適合用於處理超大型文件和多節點性能要求高的情況。
副本卷冗餘度高，副本數量可以靈活配置，可以保證數據的安全性。
條帶副本卷是條帶卷和副本卷的結合。
EC卷使用EC校驗算法，提供了低於副本卷的冗餘度，冗餘度小於100%，滿足比較低的數據安全性，例如可以使2+1（冗餘度爲50%）、5+3（冗餘度爲60%）等。這個可以滿足安全性要求不高的數據。
高性能
採用弱一致性的設計，向副本中寫數據時，只要有一個brick成功返回，就認爲寫入成功，不必等待其它brick返回，這樣的方式比強一致性要快。
還提供了I/O併發、write-behind、read-ahead、io-cache、條帶等提高讀寫性能的技術。並且這些都還可以根據實際需求進行開啓/關閉，i/o併發數量，cache大小都可以調整。
GlusterFS缺點分析：
GlusterFS不是一個完美的分佈式文件系統，這個系統自身也有許多不足之處，包括衆所周知的元數據性能和小文件問題。沒有普遍適用各種應用場景的分佈式文件系統，通用的意思就是通通不能用，四大開源系統不例外，所有商業產品也不例外。每個分佈式文件系統都有它適用的應用場景，適合的纔是最好的。這一次我們反其道而行之，不再談GlusterFS的各種優點，而是深入談談GlusterFS當下的問題和不足，從而更加深入地理解GlusterFS系統，期望幫助大家進行正確的系統選型決策和規避應用中的問題。同時，這些問題也是GlusterFS研究和研發的很好切入點。
1、元數據性能
GlusterFS使用彈性哈希算法代替傳統分佈式文件系統中的集中或分佈式元數據服務，這個是GlusterFS最核心的思想，從而獲得了接近線性的高擴展性，同時也提高了系統性能和可靠性。GlusterFS使用算法進行數據定位，集羣中的任何服務器和客戶端只需根據路徑和文件名就可以對數據進行定位和讀寫訪問，文件定位可獨立並行化進行。
這種算法的特點是，給定確定的文件名，查找和定位會非常快。但是，如果事先不知道文件名，要列出文件目錄（ls或ls -l），性能就會大幅下降。對於Distributed哈希卷，文件通過HASH算法分散到集羣節點上，每個節點上的命名空間均不重疊，所有集羣共同構成完整的命名空間，訪問時使用HASH算法進行查找定位。列文件目錄時，需要查詢所有節點，並對文件目錄信息及屬性進行聚合。這時，哈希算法根本發揮不上作用，相對於有中心的元數據服務，查詢效率要差很多。
從我接觸的一些用戶和實踐來看，當集羣規模變大以及文件數量達到百萬級別時，ls文件目錄和rm刪除文件目錄這兩個典型元數據操作就會變得非常慢，創建和刪除100萬個空文件可能會花上15分鐘。如何解決這個問題呢？我們建議合理組織文件目錄，目錄層次不要太深，單個目錄下文件數量不要過多；增大服務器內存配置，並且增大GlusterFS目錄緩存參數；網絡配置方面，建議採用萬兆或者InfiniBand。從研發角度看，可以考慮優化方法提升元數據性能。比如，可以構建全局統一的分佈式元數據緩存系統；也可以將元數據與數據重新分離，每個節點上的元數據採用全內存或數據庫設計，並採用SSD進行元數據持久化。
2、小文件問題
理論和實踐上分析，GlusterFS目前主要適用大文件存儲場景，對於小文件尤其是海量小文件，存儲效率和訪問性能都表現不佳。海量小文件LOSF問題是工業界和學術界公認的難題，GlusterFS作爲通用的分佈式文件系統，並沒有對小文件作額外的優化措施，性能不好也是可以理解的。
對於LOSF而言，IOPS/OPS是關鍵性能衡量指標，造成性能和存儲效率低下的主要原因包括元數據管理、數據佈局和I/O管理、Cache管理、網絡開銷等方面。從理論分析以及LOSF優化實踐來看，優化應該從元數據管理、緩存機制、合併小文件等方面展開，而且優化是一個系統工程，結合硬件、軟件，從多個層面同時着手，優化效果會更顯著。GlusterFS小文件優化可以考慮這些方法，這裏不再贅述，關於小文件問題請參考“海量小文件問題綜述”一文。
3、集羣管理模式
GlusterFS集羣採用全對等式架構，每個節點在集羣中的地位是完全對等的，集羣配置信息和卷配置信息在所有節點之間實時同步。這種架構的優點是，每個節點都擁有整個集羣的配置信息，具有高度的獨立自治性，信息可以本地查詢。但同時帶來的問題的，一旦配置信息發生變化，信息需要實時同步到其他所有節點，保證配置信息一致性，否則GlusterFS就無法正常工作。在集羣規模較大時，不同節點併發修改配置時，這個問題表現尤爲突出。因爲這個配置信息同步模型是網狀的，大規模集羣不僅信息同步效率差，而且出現數據不一致的概率會增加。
實際上，大規模集羣管理應該是採用集中式管理更好，不僅管理簡單，效率也高。可能有人會認爲集中式集羣管理與GlusterFS的無中心架構不協調，其實不然。GlusterFS 2.0以前，主要通過靜態配置文件來對集羣進行配置管理，沒有Glusterd集羣管理服務，這說明glusterd並不是GlusterFS不可或缺的組成部分，它們之間是鬆耦合關係，可以用其他的方式來替換。從其他分佈式系統管理實踐來看，也都是採用集羣式管理居多，這也算一個佐證，GlusterFS 4.0開發計劃也表現有向集中式管理轉變的趨勢。
4、容量負載均衡
GlusterFS的哈希分佈是以目錄爲基本單位的，文件的父目錄利用擴展屬性記錄了子卷映射信息，子文件在父目錄所屬存儲服務器中進行分佈。由於文件目錄事先保存了分佈信息，因此新增節點不會影響現有文件存儲分佈，它將從此後的新創建目錄開始參與存儲分佈調度。這種設計，新增節點不需要移動任何文件，但是負載均衡沒有平滑處理，老節點負載較重。GlusterFS實現了容量負載均衡功能，可以對已經存在的目錄文件進行Rebalance，使得早先創建的老目錄可以在新增存儲節點上分佈，並可對現有文件數據進行遷移實現容量負載均衡。
GlusterFS目前的容量負載均衡存在一些問題。由於採用Hash算法進行數據分佈，容量負載均衡需要對所有數據重新進行計算並分配存儲節點，對於那些不需要遷移的數據來說，這個計算是多餘的。Hash分佈具有隨機性和均勻性的特點，數據重新分佈之後，老節點會有大量數據遷入和遷出，這個多出了很多數據遷移量。相對於有中心的架構，可謂節點一變而動全身，增加和刪除節點增加了大量數據遷移工作。GlusterFS應該優化數據分佈，最小化容量負載均衡數據遷移。此外，GlusterFS容量負載均衡也沒有很好考慮執行的自動化、智能化和並行化。目前，GlusterFS在增加和刪除節點上，需要手工執行負載均衡，也沒有考慮當前系統的負載情況，可能影響正常的業務訪問。GlusterFS的容量負載均衡是通過在當前執行節點上掛載卷，然後進行文件複製、刪除和改名操作實現的，沒有在所有集羣節點上併發進行，負載均衡性能差。
5、數據分佈問題
Glusterfs主要有三種基本的集羣模式，即分佈式集羣(Distributed cluster)、條帶集羣(Stripe cluster)、複製集羣(Replica cluster)。這三種基本集羣還可以採用類似堆積木的方式，構成更加複雜的複合集羣。三種基本集羣各由一個translator來實現，分別由自己獨立的命名空間。對於分佈式集羣，文件通過HASH算法分散到集羣節點上，訪問時使用HASH算法進行查找定位。複製集羣類似RAID1，所有節點數據完全相同，訪問時可以選擇任意個節點。條帶集羣與RAID0相似，文件被分成數據塊以Round Robin方式分佈到所有節點上，訪問時根據位置信息確定節點。
哈希分佈可以保證數據分佈式的均衡性，但前提是文件數量要足夠多，當文件數量較少時，難以保證分佈的均衡性，導致節點之間負載不均衡。這個對有中心的分佈式系統是很容易做到的，但GlusteFS缺乏集中式的調度，實現起來比較複雜。複製捲包含多個副本，對於讀請求可以實現負載均衡，但實際上負載大多集中在第一個副本上，其他副本負載很輕，這個是實現上問題，與理論不太相符。條帶卷原本是實現更高性能和超大文件，但在性能方面的表現太差強人意，遠遠不如哈希卷和複製卷，沒有被好好實現，連官方都不推薦應用。
6、數據可用性問題
副本（Replication）就是對原始數據的完全拷貝。通過爲系統中的文件增加各種不同形式的副本，保存冗餘的文件數據，可以十分有效地提高文件的可用性，避免在地理上廣泛分佈的系統節點由網絡斷開或機器故障等動態不可測因素而引起的數據丟失或不可獲取。GlusterFS主要使用複製來提供數據的高可用性，通過的集羣模式有複製卷和哈希複製卷兩種模式。複製卷是文件級RAID1，具有容錯能力，數據同步寫到多個brick上，每個副本都可以響應讀請求。當有副本節點發生故障，其他副本節點仍然正常提供讀寫服務，故障節點恢復後通過自修復服務或同步訪問時自動進行數據同步。
一般而言，副本數量越多，文件的可靠性就越高，但是如果爲所有文件都保存較多的副本數量，存儲利用率低（爲副本數量分之一），並增加文件管理的複雜度。目前GlusterFS社區正在研發糾刪碼功能，通過冗餘編碼提高存儲可用性，並且具備較低的空間複雜度和數據冗餘度，存儲利用率高。
GlusterFS的複製卷以brick爲單位進行鏡像，這個模式不太靈活，文件的複製關係不能動態調整，在已經有副本發生故障的情況下會一定程度上降低系統的可用性。對於有元數據服務的分佈式系統，複製關係可以是以文件爲單位的，文件的不同副本動態分佈在多個存儲節點上；當有副本發生故障，可以重新選擇一個存儲節點生成一個新副本，從而保證副本數量，保證可用性。另外，還可以實現不同文件目錄配置不同的副本數量，熱點文件的動態遷移。對於無中心的GlusterFS系統來說，這些看起來理所當然的功能，實現起來都是要大費周折的。不過值得一提的是，4.0開發計劃已經在考慮這方面的副本特性。
7、數據安全問題
GlusterFS以原始數據格式（如EXT4、XFS、ZFS）存儲數據，並實現多種數據自動修復機制。因此，系統極具彈性，即使離線情形下文件也可以通過其他標準工具進行訪問。如果用戶需要從GlusterFS中遷移數據，不需要作任何修改仍然可以完全使用這些數據。
然而，數據安全成了問題，因爲數據是以平凡的方式保存的，接觸數據的人可以直接複製和查看。這對很多應用顯然是不能接受的，比如雲存儲系統，用戶特別關心數據安全。私有存儲格式可以保證數據的安全性，即使泄露也是不可知的。GlusterFS要實現自己的私有格式，在設計實現和數據管理上相對複雜一些，也會對性能產生一定影響。
GlusterFS在訪問文件目錄時根據擴展屬性判斷副本是否一致，這個進行數據自動修復的前提條件。節點發生正常的故障，以及從掛載點進行正常的操作，這些情況下發生的數據不一致，都是可以判斷和自動修復的。但是，如果直接從節點系統底層對原始數據進行修改或者破壞，GlusterFS大多情況下是無法判斷的，因爲數據本身也沒有校驗，數據一致性無法保證。
8、Cache一致性
爲了簡化Cache一致性，GlusterFS沒有引入客戶端寫Cache，而採用了客戶端只讀Cache。GlusterFS採用簡單的弱一致性，數據緩存的更新規則是根據設置的失效時間進行重置的。對於緩存的數據，客戶端週期性詢問服務器，查詢文件最後被修改的時間，如果本地緩存的數據早於該時間，則讓緩存數據失效，下次讀取數據時就去服務器獲取最新的數據。
GlusterFS客戶端讀Cache刷新的時間缺省是1秒，可以通過重新設置卷參數Performance.cache-refresh-timeout進行調整。這意味着，如果同時有多個用戶在讀寫一個文件，一個用戶更新了數據，另一個用戶在Cache刷新週期到來前可能讀到非最新的數據，即無法保證數據的強一致性。因此實際應用時需要在性能和數據一致性之間進行折中，如果需要更高的數據一致性，就得調小緩存刷新週期，甚至禁用讀緩存；反之，是可以把緩存週期調大一點，以提升讀性能。