☰

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

附言：我没有存储背景，所以如果我遗漏了一些明显的要点，请原谅，我尝试在谷歌上搜索，但无法提取所需的信息。

答案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-dispersed-volumes 分散卷适合用于存档目的，因为与副本卷相比，它可以节省空间。但由于每次 IO 期间都涉及计算，因此与副本卷相比，分散卷的速度可能较慢。

卡達魯(https://kadalu.io) 项目提供了一种在 Kubernetes 中配置卷的不同方法。它从存储中创建一个 Gluster 卷，并在请求 PV 时从该卷中提供子卷（在您的情况下为 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 个发生故障，卷仍可用。

相关内容