☰

GlusterFS 卷創建建議

tag-icon • tag-icon kubernetes glusterfs openshift-origin
GlusterFS 卷創建建議

我必須部署多個 Openshift 集群，從 3 個節點到 10 個節點。對於 3 個節點，我正在建立複製卷。

但對於 4 及以上，建立複製卷看起來不太好，因此每個節點都有 300GB 磁碟，將其複製到 10 個節點並不是最佳選擇。我正在尋找使用的公式

For 4 nodes create volume as disperse:2:1
For 5 nodes create volume as disperse:?:?
For 6 nodes create volume as disperse:?:?
For 7 nodes create volume as disperse:?:?
For 8 nodes create volume as disperse:?:?
For 9 nodes create volume as disperse:?:?
For 10 nodes create volume as disperse:?:?

環境： 我將使用這些磁碟區用於 MYSQL 5.7.28，每個伺服器都有 300GB 磁碟，在 300GB 中，我將為 MYSQL 建立大小為 250GB 的磁碟區。

OpenShift 3.11 version

# gluster --version
glusterfs 6.1

PS：我沒有儲存背景，所以如果我遺漏了一些我嘗試在谷歌上搜尋但無法提取所需資訊的明顯點，請原諒。

答案1

您計劃使用所有節點作為儲存節點還是僅使用部分節點作為儲存節點？根據你的問題，MySQL使用250GiB，還有哪些應用程式需要儲存？

複製磁碟區：可用的有效儲存空間將是

volume_size = sum of storage available from three nodes / 3

在您的情況下，使用三個儲存節點的磁碟區大小將為 300GiB。

分散磁碟區：可用的有效儲存空間將是

volume_size = storage in single node * (number of bricks - redundancy count)

在您的情況下，磁碟區大小將為300 * (3-1) = 600GiB。更多詳細資訊請參閱此處https://docs.gluster.org/en/v3/Administrator%20Guide/Setting%20Up%20Volumes/#creating-分散-卷 分散卷非常適合歸檔目的，因為與副本卷相比，它可以節省空間。但與副本相比，它可能會慢，因為每次 IO 期間都會涉及計算。

卡達魯(https://kadalu.io）專案提供了一種不同的方法來在 Kubernetes 中配置磁碟區。它從儲存空間建立單一 Gluster 卷，並在請求 PV 時提供該磁碟區之外的子磁碟區（在您的情況下是 Storage for Mysql）。

Kadalu 目前支援副本 1 和副本 3 卷。當從其他儲存提供者（例如 AWS/Azure）聲明儲存裝置時，副本 1 非常有用。即使三分之一的節點發生故障，副本 3 仍可為應用程式提供高可用性的儲存。最近的部落格文章（https://kadalu.io/blog/kadalu-kubernetes-storage）解釋了 Kadalu 可用的多種配置以及將其與現有儲存一起使用。

Kadalu 使用 GlusterFS 並與 Kubernetes 原生集成，無需使用 Gluster 管理守護程序 - glusterd。

更新：新增了分散體積的計算

number of disperse bricks = data bricks + redundancy count

如果有3個儲存設備可用，

2 data bricks + 1 redundancy bricks

如果有 6 個儲存設備，

4 data bricks + 2 redundancy bricks

如果冗餘區塊的數量增加，則可用磁碟區大小將減少。即使相當於冗餘磚塊的磚塊數量減少，該卷仍可供應用程式使用。例如，在4+2配置中，即使 6 塊磚中有 2 塊損壞，磁碟區也將可用。

相關內容