☰

GlusterFS ボリューム作成の提案

tag-icon • tag-icon kubernetes glusterfs openshift-origin
GlusterFS ボリューム作成の提案

3 ノードから 10 ノードまでの複数の Openshift クラスターをデプロイする必要があります。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 に使用し、各サーバーには 300 GB のディスクがあり、300 GB のうち 250 GB のサイズのボリュームを MYSQL 用に作成します。

OpenShift 3.11 version

# gluster --version
glusterfs 6.1

追記: 私はストレージに関する知識がないので、明らかな点を見逃していたらごめんなさい。Google で検索してみましたが、必要な情報を抽出できませんでした。

答え1

すべてのノードをストレージ ノードとして使用する予定ですか、それともノードのサブセットのみをストレージ ノードとして使用する予定ですか? ご質問によると、MySQL は 250 GiB を使用しますが、他にどのようなアプリケーションでストレージが必要ですか?

複製ボリューム: 利用可能な有効なストレージスペースは

volume_size = sum of storage available from three nodes / 3

あなたの場合、ボリューム サイズは 3 つのストレージ ノードを使用して 300 GiB になります。

分散容量: 利用可能な有効なストレージスペースは

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/#分散ボリュームの作成 分散ボリュームは、レプリカ ボリュームに比べてスペースを節約できるため、アーカイブ目的に適しています。ただし、すべての IO 中に計算が行われるため、レプリカに比べて遅くなる可能性があります。

カダル（https://kadalu.io) プロジェクトは、Kubernetes でボリュームをプロビジョニングするための異なるアプローチを提供します。ストレージから単一の Gluster ボリュームを作成し、PV が要求されたときにそのボリュームからサブボリュームを提供します (この場合は、Mysql 用のストレージ)。

Kadalu は現在、レプリカ 1 ボリュームとレプリカ 3 ボリュームをサポートしています。レプリカ 1 は、ストレージ デバイスが AWS/Azure などの他のストレージ プロバイダーから要求される場合に便利です。レプリカ 3 は、3 つのノードのうち 1 つがダウンした場合でも、アプリケーションに高可用性のストレージを提供します。最近のブログ投稿(https://kadalu.io/blog/kadalu-kubernetes-storage) では、Kadalu で利用可能な複数の構成と、それを既存のストレージで使用する方法について説明します。

Kadalu は GlusterFS を使用し、Gluster 管理デーモン (glusterd) を使用せずに Kubernetes とネイティブに統合されています。

アップデート: 分散体積の計算を追加しました

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 つがダウンしてもボリュームは使用できます。

関連情報