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 🙂 🙂

Quelle: http://www.gluster.org
Eine einfache Replizierung mit GlusterFS.

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.

Ansichten: 5.934