Ich muss mehrere Openshift-Cluster von 3 bis 10 Knoten bereitstellen. Für 3 Knoten erstelle ich replizierte Volumes.
Aber für 4 und höher sieht es nicht gut aus, replizierte Volumes zu erstellen, sodass jeder Knoten eine 300 GB-Festplatte hat und die Replikation auf 10 Knoten nicht optimal ist. Ich suche nach einer Formel, die ich verwenden kann, wie
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:?:?
Umfeld: Ich werde diese Volumes für MySQL 5.7.28 verwenden und jeder Server hat eine 300 GB große Festplatte. Von den 300 GB werde ich ein Volume mit einer Größe von 250 GB für MySQL erstellen.
OpenShift 3.11 version
# gluster --version
glusterfs 6.1
PS: Ich habe keine Erfahrung mit der Speicherung, also entschuldigen Sie, wenn ich einen offensichtlichen Punkt übersehe. Ich habe versucht, bei Google zu suchen, konnte aber die erforderlichen Informationen nicht extrahieren.
Antwort1
Planen Sie, alle Knoten als Speicherknoten zu verwenden oder nur eine Teilmenge der Knoten als Speicherknoten? Basierend auf Ihrer Frage verwendet MySQL 250 GiB. Welche anderen Anwendungen benötigen Speicher?
Repliziertes Volumen: Der tatsächlich verfügbare Speicherplatz beträgt
volume_size = sum of storage available from three nodes / 3
In Ihrem Fall beträgt die Datenträgergröße bei Verwendung von drei Speicherknoten 300 GiB.
Disperses Volumen: Der effektiv verfügbare Speicherplatz wird
volume_size = storage in single node * (number of bricks - redundancy count)
In Ihrem Fall beträgt die Volumengröße 300 * (3-1) = 600GiB. Weitere Einzelheiten finden Sie hierhttps://docs.gluster.org/en/v3/Administrator%20Guide/Setting%20Up%20Volumes/#creating-dispersed-volumes
Verteilte Volumes eignen sich gut für Archivierungszwecke, da sie im Vergleich zu Replikat-Volumes Platz sparen. Im Vergleich zu Replikaten können sie jedoch aufgrund der bei jedem IO erforderlichen Berechnungen langsam sein.
Kadalu(https://kadalu.io)-Projekt bietet einen anderen Ansatz zur Bereitstellung von Volumes in Kubernetes. Es erstellt ein einzelnes Gluster-Volume aus dem Speicher und stellt Untervolumes aus diesem Volume bereit, wenn PV angefordert wird (in Ihrem Fall Speicher für Mysql).
Kadalu unterstützt derzeit Replikat 1- und Replikat 3-Volumes. Replikat 1 ist nützlich, wenn das Speichergerät von anderen Speicheranbietern beansprucht wird, z. B. AWS/Azure. Replikat 3 bietet eine hohe Speicherverfügbarkeit für Anwendungen, selbst wenn einer von drei Knoten ausfällt. Der aktuelle Blogbeitrag (https://kadalu.io/blog/kadalu-kubernetes-storage) erläutert mehrere mit Kadalu verfügbare Konfigurationen und die Verwendung mit dem vorhandenen Speicher.
Kadalu verwendet GlusterFS und ist nativ in Kubernetes integriert, ohne den Gluster-Verwaltungsdaemon glusterd zu verwenden.
Aktualisieren: Berechnungen für Dispersionsvolumen hinzugefügt
number of disperse bricks = data bricks + redundancy count
Wenn 3 Speichergeräte verfügbar sind,
2 data bricks + 1 redundancy bricks
Bei 6 Speichergeräten
4 data bricks + 2 redundancy bricks
Wenn die Anzahl der Redundanz-Bricks zunimmt, verringert sich die nutzbare Volume-Größe. Das Volume bleibt für Anwendungen verfügbar, auch wenn die Anzahl der Bricks, die den Redundanz-Bricks entsprechen, sinkt. Beispielsweise 4+2bleibt das Volume in der Konfiguration verfügbar, auch wenn 2 von 6 Bricks ausfallen.