Nachdem ich jetzt den Cluster einige Tage / Wochen beobachten konnte, musste ich mich nun endgültig vom Gluster verabschieden. Wichtig zu wissen, dies gilt jetzt erstmal nur für den Raspberry Pi, da dieser einfach nicht über genug Leistung verfügt wie andere x86 Systeme. Wie man jetzt schon erahnen kann, lief mein Docker Swarm oder ehr die persistenten Daten auf einem GlusterFS.
Also zunächst kurz erklärt, wofür man die persistenten Daten überhaupt benötigt. Container sind in erster Linie flüchtig, heißt soviel wie, jetzt sind se da und wenn diese wieder offline gehen, gehen auch die Daten sofort mit ins Nirvana. Wenn dann doch mal ein Container wichtige Daten produziert, welche aufgehoben werden möchten, dann müssen diese eben gespeichert werden und dann zwar in den persistenten Speicher. Dieser ist dann nach einen Neustart eines Containers wieder für diesen da. Zum Beispiel hier diese Website, der Webserver wird als Container betrieben und die Daten liegen im persistenten Bereich. Wäre das nicht so, dann würden nach jedem Neustart des Containers alle meine Inhalte gelöscht. Das wollen wir natürlich nicht.
Dafür brauchen wir GlusterFS
Also brauchen wir jetzt GlusterFS um einen persistenten Datenbereich zu schaffen. Wie dem Bild unten zu entnehmen ist, wollen wir auch das unsere Daten repliziert werden, denn in einem Ausfallszenario müssen wir ja trotzdem an die Daten kommen, bzw. der Container muss dran kommen um weiterhin die Webseite anzeigen zu lassen. Wieso weshalb warum replicated Volume werde ich jetzt hier nicht erklären, das wäre ein ganz eigener Post. Also was passiert jetzt wenn wir etwas in das Volume schreiben im Gluster? Bevor wir ein Commit bekommen, das diese Datei geschrieben worden ist, werden die Daten an alle Beteiligten Clusterknoten gesendet und erst wenn diese alle ihr OK geben, bekommen wir das OK vom Schreibprozess. Klingt erstmal alles super, unsere Daten werden wenigstens sicher abgelegt und sind im Ausfall auch wieder direkt da. Bei einem Datenverlust auf einem oder mehrerer der Knoten, können diese ohne weiteres zurück repliziert werden. Toll 🙂 🙂
Kommen wir nun zum ursprünglichen Problem. Genau dieses hin und her schieben und abwarten auf die Commits von den anderen Clusterknoten, geht volle Kanne auf die CPU und die Leistung des Raspberry Pi’s. Wie dem Bild zu entnehmen ist, sieht man einige Prozesse für den GlusterFS, welche im Hintergrund laufen und die CPU zum glühen bringt. Nicht nur das dass System ausgelastet ist, sondern auch die Schreib-/Leseprozesse im Volume waren dadurch “*rschlangsam”. Ich habe teilweise darauf gewartet das Gluster endlich fertig wird, bevor ein Container überhaupt starten konnte. Besonders wenn kleine Daten und in hoher Anzahl gelesen und/oder geschrieben werden, rastet das Gluster total aus. Naja, wie gesagt, dies kann auch nur der Fall sein auf dem Raspberry Pi, auf anderen System oder Umgebungen wird es sicher besser laufen.
Fazit:
GlusterFS auf einem Raspberry Pi Cluster mit Docker Swarm ist keine gute Idee. Jedenfalls war meine Erfahrung keine Gute. Ich habe jetzt wieder auf einen normalen NFSv4 mount umgestellt und sofort keine Probleme mehr. Na klar, ich habe jetzt meine Replication über alle Clusterknoten verloren, aber ein “Backup” kann man auch anders machen. Von der Funktionalität her ist Gluster absolut zu empfehlen, allerdings sollten die Rahmenparameter wie Netzwerk und CPU Power nicht außer acht gelassen werden.
10. Juli 2021 um 21:11 Uhr
Hallo Dennis,
Danke für den Beitrag. Ich arbeite an einem ähnlichen Projekt. Ich habe ein PI Docker Swarm Cluster und ein separates Pi für den Storage und den haProxy. NFS speichert alle Dateien als nobody/nogroup. Ich bekomme dort aber immer wieder rechte Probleme, wie bei NGINX etc. Wie hasst du das Problem gelöst?
Gruss
15. Oktober 2021 um 12:42 Uhr
Hallo Dennis,
hast du mal ceph probiert und damit Erfahrung gesammelt?
Gruß
9. Mai 2022 um 09:15 Uhr
Danke für den Bericht. Toll wäre noch die Abgabe der Specs der Pi’s sowie die Anzahl der Swarm und Gluster Nodes sowie das verwendete Dateisystem.
9. Mai 2022 um 09:18 Uhr
War Standard ext4 und 4 PI Knoten im Gluster. Für den PI einfach zu viel.
27. Februar 2023 um 08:15 Uhr
Was für Pi Nodes? Die interscheiden sich signifikant hinsichtlich Rechenpower und Netzwerkdurchsatz, insbesondere der Pi 4 hat dort wesentlich mehr Dampf unter der Haube als die Vorgängermodelle.