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