Gluster - Distributed 模式

Distributed 在 Gluster 中是預設的模式，也就是說在不指定任何的模式之下 distributed 就是其預設項目。本篇文件探討 Distributed 模式的運作與其設定方式。

下圖說明了當有 File1 與 File2 寫入 Distributed Volume 時，其實是分別存放在不同的 Brick 中。

特徵討論

資料分配

Distributed 就是將資料分散的存入可用的 brick 中，與其它分散式檔案系統不同的地方是 Gluster 不需要集中管理的 Metadata Server，而是使用 Elastic Hashing Algorithm 演算法取得定址位置，在 Distributed 模式中絕非以隨機的方式存放檔案，在使用 Elastic Hashing Algorithm 會將檔案路徑、Brick 數量與容量做總合計算而決定檔案的實際位置。這個方法不需要 Metadata Server 記錄檔案實際位置，如此可以增加效率與橫向擴展的簡易性。

因為 Distributed 會將檔案分散至不同的 Brick 中，所以在當您複製 100 個檔案中，實際上會被分散至多個不同的 Brick 上，而再度存取時會將檔案從不同的 Brick 中還原給 Client 的請求。

效能

多個節點可以提供更快的存取速度，若一個節點在 1GiB 的網路環境下其理論傳輸值可以達到 100MB 的傳輸量；此時再新增一個節點的話就會提一倍的效能為 200MB 傳輸量。所以越多的節點在其傳速度可以大符提升。

Gluster 在使用 Gluster Native Client 存取小型檔案（如 PHP、JS、CSS ... 等網頁小檔案）時其效能較不如預期，因為小型檔案在傳送時會耗費較多的網路初始化連線，這一來一往之間有很多時間與頻寬就會被耗用了，而小檔案在寫入磁碟時通常較不連續也會增加磁碟寫入的延遲時間。所幸 Gluster 也提供了 NFS 與 CIFS 的存取方式，NFS 允許 Client 在連線時使用非同步（async）存取的機制進而提升小檔案的傳送效率。

在設計 NFS 的情況之下，為了保護 Gluster Storage 不讓真正的使用者直接存取，比較建議使用一個 NFS Server 在後端使用 Native Client 連接 Gluster Storage，而前端提供 NFS 服務讓真正的使用者直接存取，這樣可以讓環境單純化且容易管理。

檔案存取流程

當 Client 在存取 Gluster Storage 時，使用 Native Client 與 NFS 有不同的存取流程：

• Native Client：

  因為 Native Client 可以直接與 Gluster Storage 連接，所以使用 Native Client 掛載時其檔案在寫入時會直接存放於合適的節點 Brick，而在讀取時則直接到 Brick 取得檔案，如此一來可以真正的達到存取平行化，快速的讀寫效率以減少時間消耗。

• NFS：

  每個 Volume 預設都可以使用 NFS 掛載（也可以設定停用），當檔案在寫入的時候會將檔案傳送至掛載的節點，再由該節點計算合適的 Brick 存放；而讀取時也是由該節點取得檔案再回傳給 NFS Client。

節點 / Brick 損毀

如果您的 100 個檔案放在 Distributed Volume 上，經由上述的討論可以得知它們會分散在不同的節點 Brick 上，假設一個 Volume 的 Brick 成員為 brick_01 與 brick_02。檔案分別被分散於 brick_01 有 49 個檔案、brick_02 有 51 個檔案，當 brick_01 損毀時則會損失 49 個檔案，其它的 51 個檔案仍可以被存取。

因此當一個 Volume 的成員越多，那麼檔案損失的數量會減少。

容量

Distributed Volume 的容量大小為所有成員 Brick 的總合，比如 brick_01 與 brick_02 各為 10GB，那麼整個 volume 的可用空間為 20GB。

雖然整個可用的空間為 20GB，但是因為是由兩個 10GB 組合而成，所以當有超過 10GB 的單一大型檔案試圖寫入時就會發生錯誤，因此不應該將個別 Brick 設定過小。

個別 Brick 容量大小的問題可以在節點上使用 LVM 的方法解決，LVM 可以跨越多個不同的硬碟將它們組合成大型的硬碟空間，這也就是為什麼在設定 Brick 之前最好將其設定在 LVM 的原因之一。

開始設定 volume

Gluster Volume 設定

在設定 Volume 時只需要在任何一個節點（必須在同一個 Storage Pool 中）設定即可，而不用在每一台節點設定。

延續著先前的環境條件，我們試著建立一個 volume 名稱為 dist_vol，而其 Brick 成員為 S1 - brick_01 與 S2 - brick_01。因為每個 brick 已經被分配了 10GB 的空間，所以在 dist_vol 完成被 Client 掛載之後應該會有 20GB 的可用容量。

1. 建立 Volume

    root # gluster volume create dist_vol \
    > S1:/bricks/brick_01/brick \
    > S2:/bricks/brick_01/brick
   

   如果在這個過程發生錯誤，請確認節點是否存在、目錄是確正確與節點是否已被加入 Storage Pool

2. 啟用 Volume

    root # gluster volume start dist_vol
   

3. 查看 Volume 狀態

    root # gluster volume info dist_vol
   

經過以上三個步驟就完成了 volume 的設定，非常簡短。

Client 存取設定

在 Red Hat Enterprise Linux 與 CentOS 下，可以使用 Native Client 直接與 Volume 連接，或是使用 NFS 掛載。

• Native Client：

  在使用 Native Client 之前要先確認已經安裝了 glusterfs-fuse 的 RPM 套件，而連接 Volume 的方法就跟掛載磁碟一樣簡單：

    root # mount -t glusterfs rw S1:/dist_vol /mnt/dist_vol
  

  上述指令會將 S1 的 Volume（dist_vol）掛載到 /mnt/dist_vol，在掛載的同時 S1 也會傳送相關的 brick 資訊給 Client。

  如果要在開機的時候就掛載該 volume，那麼就需要在 /etc/fstab 中設定（該設定會啟用 ACL 功能）：

    S1:/dist_vol    /mnt/dist_vol    glusterfs    _netdev,rw,acl    0    0
  

• NFS：

  NFS 掛載的方法就如同以往一樣沒有改變：

    root # mount -t nfs rw S1:/dist_vol /mnt/dist_vol
  

  若要在開機時啟用則設定 /etc/fstab

    S1:/dist_vol    /mnt/dist_vol    nfs    rw    0    0
  

更換 Brick

通常建置完成好之後就很少會再更動設備，除非遇到設備更新或是損毀後的修複。不管任何原因，Gluster 都允許你進行線上更換 Brick，也就是在更換 Brick 的時候不用讓你的服務停止，而且使用者可以繼續操作檔案。

只要 Brick 有所變動，基本上就會在更換的時候耗用較大的 CPU 與網路流量，因為 Gluster 要把資料從來源端複製到新的 Brick 上，但時間與資源消耗要看資料量的大小來決定。Brick 變更的時候雖然不會影響使用者的操作，但是會增加些許的延遲時間，感覺得來就會覺得像時存取效能變慢，但在 Brick 轉換完成之後一切就會恢複正常。

Brick 在更換的過程中，是由 Server 端的主機做資料移轉而不是 Client，所以在整個後端資料流與網路會較為忙碌。

更換 Brick 可以使用 replace-brick 完成，其整體的語法如下：

root # gluster volume replace-brick [VOL_NAME] [OLD_BRICK] [NEW_BRICK] [start | status | commit]

直接替換 Brick

更換 Brick 前請先確定所屬節點已被加入 Storage Pool。

假設在名稱為 dist_vol 的 Volume 我們使用 S3:/bricks/brick_01/brick 替換 S1:/bricks/brick_01/brick，那麼實做的方法如下：

1. 設定替換作業

    root # glsuter volume replace-brick dist_vol \
    S1:/bricks/brick_01/brick \
    S3:/bricks/brick_01/brick
    start
   

2. 查看 Brick 檔案移動狀態

    root # glsuter volume replace-brick dist_vol
    S1:/bricks/brick_01/brick \
    S3:/bricks/brick_01/brick
    status
    volume replace-brick: success: Number of files migrated = 1     Migration complete
   

3. 通知 Volume 確認移除舊的 Brick

    root # glsuter volume replace-brick dist_vol \
    S1:/bricks/brick_01/brick \
    S3:/bricks/brick_01/brick
    commit
   

   請使用 status 確認所有的檔案已經在完成（complete）狀態再進行 commit。

4. 確認 volume 成員

    root # gluster volume info dist_vol
   

新增 Brick

也許您的儲存空間使用量很大，很快的需要更大的空間，此時可以加入新的 Brick 讓你的整體容量增加，在新增 Brick 的時候也不用停用服務。

在新增 Brick 之前，也要先確認該節點已經加入 Storage Pool 而且完成好 Brick 的相關設定。

假設要將 S4:/bricks/brick_01/brick 加入到 dist_vol 的 Volume 中，其作法如下：

1. 新增 Brick

    root # gluster volume add-brick dist_vol S4:/birkcs/brick_01/brick
   

2. 重新分配檔案存放位置

   重新分配檔案位置的用意在於將既有的檔案移到合適的位置，這樣可以確認每一個空間都會被分配到而不會特別偏向特定的 Brick。

    root # gluster volume rebalance dist_vol start
   

   也可以查看 rebalance 的狀態

    root # gluster volume rebalance dist_vol status