Gluster: Entscheidung über Redundanz fällen

[Rüdiger Kupper]

Bevor wir ein GlusterFS aufsetzen können, müssen wir über die Art der Redundanz entscheiden, die wir haben wollen.

• derzeit vorbereitet ist eine komplette Redundanz jeder Festplatte auf Basis von RAID1.
• GlusterFS selbst bietet das selbe Feature, sogar über Maschinen hinweg (die Spiegelung einer Platte von gluster1 könnte also auf gluster3 liegen.)
• GlusterFS bietet zudem das Feature „Erasure Coding“, bei dem Dateien stückweise über die Knoten verteilt werden, so dass eine festgelegte Anzahl von Knoten ausfallen können.

Eine Änderung des Verfahrens zu einem späteren Zeitpunkt ist nicht ganz einfach und erfordert, dass zunächst das komplette GlusterFS auf neue Knoten verlegt wird, um die alten umstellen zu können.
Es ist also wichtig, dass wir uns hier klar werden, *bevor* ich den Gluster-Pool einrichte.

[bau]

Meine Erfahrung ist, dass ein Raid 1 auf Plattenebene sehr viel Sicherheit bietet, vor allem, da die Platten per SMART vorher melden, wenn was schiefzulaufen droht. Ich habe aktuell immer zwei Platten zu einem Raid 1 zusammengeschlossen.

GlusterFS soll möglichst viel Geschwindigkeit bieten, wenn die Dateien also (wie in Punkt 3) auf alle vier Knoten und zudem noch redundant verteilt werden, wäre das mE die beste Lösung (also so eine Art Netzwerk-Raid 5, bei dem die Daten von mehreren Servern gleichzeitig kommen können).

[lehm]

Als absoluter Laie hätte ich mir das irgendwie so vorgestellt (Zahlen fiktiv, nur als Beispiel):

Die Datengrundmenge wird in vier disjunkte Teilmengen 1-4 aufgeteilt. Jeder Gluster hat vier HDDs A-D. Teilmenge 1 liegt gespiegelt auf allen HDD A, Teilmenge 2 auf allen Bs etc. So sind alle Daten auf allen Maschinen verfügbar und bei drei Maschinen hat man doppelte Redundanz jeder Teilmenge.

Wenn das kompletter Schwachsinn ist, dann ignoriert den Kommentar einfach. Wie gesagt, ist die naive Sicht eines Laien.

[Rüdiger Kupper]

Genau, das ist eins der Szenarien, wie man Gluster konfigurieren kann. In der Gluster-Terminologie nennt sich das „vollständige Replikation“: jeder Knoten hat eine komplette Kopie aller Daten. Bei unserem Cluster aus vier Knoten wäre also jede Datei vierfach vorhanden.

Das bedeutet hohe Robustheit gegen Ausfälle (es können bis zu drei Knoten ausfallen) und voraussichtlich ein gewisser Performancegewinn beim Lesen (denn es reicht, wenn ein Knoten die Datei auslefert, die anderen können sich derweil schon um die nächsten Dateien kümmern). Wie groß der Performancegewinn ist, lässt sich aber schwer abschätzen. Kommt wohl v.a. bei hoher Auslastung zum Tragen. Das ist auch das, was Jens meinte.

[Rüdiger Kupper]

Das gegenteilige Extremum (darf man das so sagen?) wäre „vollständiges Verteilen“: jede Datei liegt nur auf einem einzigen Knoten.

Daa bedeutet minimale Robustheit (sobald ein Knoten ausfällt, sind alle Dateien, die dort lagen, nicht mehr vorhanden). Dafür hätten wir mit unseren vier Knoten den vierfachen Speicherplatz verfügbar.

[Rüdiger Kupper]

Die inreressanten Fälle liegen dazwischen, denn Gluster bietet „Verteilen und Replizieren“ in frei wählbarem Verhältnis:

Bei unseren vier Knoten könnten wir uns also für Szenario „2/4“ entscheiden: Jede Datei liegt auf zwei Knoten vor. Das wäre dann ein Kompromiss zwischen Robustheut gegen Ausfälle (ein beliebiger Knoten könnte ausfallen, ohne dass Dateien verschwinden) und Performancegewinn (jede Datei kann von zwei verschiedenen Knoten ausgeliefert werden). Speicherplatz wäre doppelt so groß wir auf einem Knoten.

Es geht aber auch Szenario „3/4“. Jede Datei liegt als Kopie auf drei unserer vier Knoten. Der verbleibende Knoten wird für Performancegewinn genutzt. Speicherplatz wäre immerhin noch das 1,33-fache eines einzelnen Knotens. Dafür mehr Ausfallsicherheit. Dieses ist eins der am meisten empfohlenen Szenarien: mindestens dreifache Replikation. Die Idee dahinter ist, dass früher oder später ein Knoten gewartet werden muss und geplabt von Netzt genommen wird. Dann soll es aber noch immer Robustheit gegen unerwartete Ausfälle geben, daher muss jede Datei mindestens dreifach vorliegen.

[Rüdiger Kupper]

Und jetzt wird'däs etwas kompliziert, denn wir haben in jedem Knoten zwei Platten stecken. Derzeit sind die zu einem RAID1 verbunden, alle Daten liegen auf beiden Platten. Dadurch ist schon eine Robustheit gegeben — allerdings nur gegen Plattendefekte, nicht gegen Ausfall des ganzen Rechners (z.B. Netzteil fällt aus).

Wir könnten dieses RAID-Setup mit „vollständigem Verteilen“ nutzen und hätten den vierfachen Speicherplatz einer Platte bei guter Ausfallsicherheit (aber eben nur gegen Ausfälle von Platten, nicht von ganzen Rechnern).

Oder wir lösen die RAIDs auf und verwenden die Pkatten einzeln. Damit hätten wir 8 „Bricks“ (Gluster-Terminologie für die Speicherorte, die zusammengeschaltet werden). Mit diesen könnten wir dann jedes beliebige Szenario zwischen 1:8 (nur Verteilen) und 8:1 (nur Replizieren) wählen.

Beispiel: 2:6. Das wäre von der Ausfallsicherheit genau so wie RAID mit kompletten Verteilen (jede Datei liegt auf zwei Platten vor). Würde aber Robustheit sowohl gegen Platten-, als auch Rechnerausfall bieten. Und ebenfalls den vierfachen Speicherplatz einer einzelnen Platte.

Oder 4:4: Hier hätten wir vierfache Redundanz mit entsprechendem Performancegewinn, aber immerhin noch das Doppelte des Speicherplatzes einer einzelnen Platte (wenn ich richtig rechne).

[Rüdiger Kupper]

Ihr seht, warum ich mir da gerade den Kopf zerbreche. Ich stimme bau zu, dass wir mit den Software-RAIDs gute Erfahrungen haben und es wäre daher der „konventionelle“ Ansatz.
Aus Sicht von Gluster können wir aber bessere Ausfallsicherheit (auch gegen Komplettausfall ganzer Rechner) erzielen, bei gleicher Speichermenge, wenn wir die Platten einzeln nutzen.
Gluster bietet die RAID-Funktionalität über Rechner hinweg.

Dafür haben wir mit dieser Technologie noch keine Erfahrungen und es könnten Tücken lauern, die ich jetzt noch nicht absehe.

[bau]

No risk - no fun :-)

Es ist aber sicher so, dass wir die neue Technik der Glusters mal probieren wollen - oder?
Wenn Gluster zu der Redundanz noch die Performance steigert, würde ich das doch mal nutzen wollen.
Mein FAZIT wäre: RAID 1 auflösen: auf den 4 Gluster-Servern stehen dann jeweils 2x1TB = 2TB SSD (Samsung) und 2x4TB = 8TB SATA (WD blue) als insgesamt 4x10TB = 40TB zur Verfügung. (Mit Raid 1 waren es noch 20TB, angestrebt war nicht, dass jede einzelne Datei von jedem Gluster kommen würde = 5TB (das wäre übertrieben wenig) sondern, dass verschiedene Dateien von verschiedenen Gluster-Servern quasi gleichzeitig ausgeliefert werden = 20TB (unsere Clients fordern oft und viele Dateien an). Daran können wir uns ja orientieren, was dann ein 2/8 -> Beim Ausfall einer Platte oder eines Knotens würde das System noch funktionieren, der Defekt könnte behoben werden und das System wäre wieder stabil. Bislang sind wir zur Sicherheit immer so vorgegangen, dass wir das System gestoppt hatten, um den Defekt zu beheben. Das ist zwar für den User nicht mehr transparent aber nachvollziehbar.

[bau]

ToDo: Wir steigen aktuell von einem quotierten System auf ein unquotiertes um. Das hatten wir schon besprochen. Damit ist dann aber auch ein Automatismus zu implementieren, der den User informiert, sobald dieser an die Grenze des vorgesehenen Speicherplatzes kommt und letztlich auch zwangsweise aufräumt, wenn er dauerhaft drüber ist. Die Dateien sind ja alle im Backup noch vorhanden, so dass wir auch mal nach belieben löschen können :-)

Wie sieht es denn aktuell mit den Caches von Chrome & Co aus? Die sollten ja nicht im HomeVZ sondern auf der lokalen Platte liegen.

[Rüdiger Kupper]

@bau

Wie war noch die Überlegung? Welche Daten sollen auf die schnellen 1TB-SSDs und welche auf die „langsamen“ 4TB WD rotierend?

[Rüdiger Kupper]

Replying to bau:

No risk - no fun :-)

Naja, wir betreiben hier einen Produktivserver für mehr als 800 Nutzer. Ist das da der richtige Ansatz?

Mein FAZIT wäre: RAID 1 auflösen: auf den 4 Gluster-Servern stehen dann jeweils 2x1TB = 2TB SSD (Samsung) und 2x4TB = 8TB SATA (WD blue) als insgesamt 4x10TB = 40TB zur Verfügung. (Mit Raid 1 waren es noch 20TB, angestrebt war nicht, dass jede einzelne Datei von jedem Gluster kommen würde = 5TB (das wäre übertrieben wenig) sondern, dass verschiedene Dateien von verschiedenen Gluster-Servern quasi gleichzeitig ausgeliefert werden = 20TB (unsere Clients fordern oft und viele Dateien an). Daran können wir uns ja orientieren, was dann ein 2/8 -> Beim Ausfall einer Platte oder eines Knotens würde das System noch funktionieren, der Defekt könnte behoben werden und das System wäre wieder stabil. Bislang sind wir zur Sicherheit immer so vorgegangen, dass wir das System gestoppt hatten, um den Defekt zu beheben. Das ist zwar für den User nicht mehr transparent aber nachvollziehbar.

Ja, das wäre auch mein primäres Szenario.

[Rüdiger Kupper]

Also entschieden: RAIDs auflösen und einzeln für Gluster verwenden.
Leider ist damit noch immer nicht alles entschieden.

(Nebenbemerkung, nur zur Vollständigkeit: die offizielle Gluster-Doku legt nahe dass man, wenn man in einem Rechner mehrere Platten hat, diese per LVM zu einem gemeinsamen Logical Volume verbinden soll und dann diese als Bricks für Gluster verwenden.
Was da der konkrete Vorteil ist?

-> Die Bricks sind größer, kommen also nicht so schnell an die Speichergrenze. Und: LVM-Volumes haben kürzere Schreibzugriffe, da jeder Sshreibzugriff nur suf eine Platte erfolgen muss.
Beim Lesen kein Vorteil.)

[Rüdiger Kupper]

Anderererseits sehe ich beim Speicherzugriff nicht den Vorteil gegenüber Gluster-nativem „Verteilen“. Müsste ja den selben Vorteil bringen.

Dieses Szenario würde ich erst mal beiseite lassen.

[Rüdiger Kupper]

Dann müssen wir jetzt noch entscheiden, wie genau die 2/8-Replikation stattfinden soll. Bei der Gluster-Konfiguration geben wir explizit vor, welche Brick sich mit welcher Brick zwecks Replikation „paaren“ soll.

Zur Erinnerung:

• jeder der vier Rechner (nodes) 1—4 beherbergt 2 Bricks (zwei Platten)
• ganz sicher sollen die Kopien der Dateien nicht auf der zweiten Platte des selben Rechners liegen (sonst hätten wir das bisherige RAID-Szenario)
• gluster1 und gluster2 stehen gemeinsam im Serverraum
• gluster3 und gluster4 stehen gemeinsam im Heizungskeller neben dem Putzkräfteraum.

[Rüdiger Kupper]

Wenn wir uns dagegen absichern wollen, dass in einem der Räume der Strom ausfällt (im Serverraum wäre dann eh alles verloren, aber im Prinzip), dann sollten alle Kopien von gluster1 und gluster2 jedenfalls auf gluster3 und gluster4 liegen und umgekehrt.

[Rüdiger Kupper]

Erste Idee wäre:

• gluster1,brick1 <-> gluster3,brick1
• gluster1,brick2 <-> gluster3,brick2
• gluster2,brick1 <-> gluster4,brick1
• gluster2,brick2 <-> gluster4,brick2

(Das Zeichen „<->“ bedeutet „repliziet sich mit“)

[Rüdiger Kupper]

Das ist gut zu behalten, doch nicht optimal. Würden z.B. die Server gluster1 und gluster3 gemeinsam ausfallen, wäre die Hälfte aller Dateien nicht zugreifbar.

@bau

Du kennst das von den Portkopplungen der Switche, Ports am selben Modul sollten eher nicht gekoppelt sein, da die sich gemeinsame Hardware teilen müssen.

Das führt mich dann schließlich zu diesem Setup:

gluster1,brick1 <-> gluster3,brick1
gluster1,brick2 <-> gluster4,brick1
gluster2,brick1 <-> gluster3,brick2
gluster2,brick2 <-> gluster4,brick2

Würden jetzt gluster1 und gluster3 gleichzeitig ausfallen, so wäre nur ein Viertel der Dateien nicht erreichbar.
Das aber zum Preis erhöhter Unübersichtlichkeit und Fehleranfälligkeit. Und wir sind ein kleines, überlastetes Team, das grundsätzlich fehleranfällig ist.

[Rüdiger Kupper]

Ich würde das Setup in comment:16 favorisieren. Obwohl es nicht die volle Robustheit hat. Doch finden wir uns dann mal in einem Krisenfall, dann kommen wir damit sicher besser klar.

[Rüdiger Kupper]

Und Krisenfälle hatten wir ja schon mehrfach.

[bau]

Die Homes sollen auf die SSD, der Rest ist für die Tauschlaufwerke etc.

[Rüdiger Kupper]

Replying to bau:

ToDo: Wir steigen aktuell von einem quotierten System auf ein unquotiertes um. Das hatten wir schon besprochen. Damit ist dann aber auch ein Automatismus zu implementieren, der den User informiert, sobald dieser an die Grenze des vorgesehenen Speicherplatzes kommt und letztlich auch zwangsweise aufräumt, wenn er dauerhaft drüber ist. Die Dateien sind ja alle im Backup noch vorhanden, so dass wir auch mal nach belieben löschen können :-)

So ein ähnliches Skript haben wir ja bereits laufen. Das fragt derzeit ab, welche User über ihrer Quota sind (tut derzeit also wohl gar nichts) und löscht bei Bedarf Mülleimer u.s.w.
Aber was geben wir den Nutzern denn als "erlaubten Speicherplatz"? Oder soll das Skript greifen, wenn der Speicherplatz insgesamt knapp wird?

Wie sieht es denn aktuell mit den Caches von Chrome & Co aus? Die sollten ja nicht im HomeVZ sondern auf der lokalen Platte liegen.

Die Umgebungsvariable XDG_CACHE_HOME weist nach /var/cache/usercache, also lokal. Daran sollten sich alle Programme halten. Dennoch habe ich kürzlich bei bestimmten Nutzern in ~/.cache/ große Datenmengen gefunden. Ursache ist noch unklar. Und Programme, die als Snap-Paket installiert sind, halten sich daran ebenfalls nicht, sondern speichern alles unter ~/snap/. Ich versuche Snaps zu vermeiden, aber manche Sachen gibt es inzwschen nur noch so. Auch eine offene Baustelle.

[Rüdiger Kupper]

Replying to bau:

Die Homes sollen auf die SSD, der Rest ist für die Tauschlaufwerke etc.

Richtig. Ich baue also zwei Gluster-Volumes zusammen, eins für die schnellen Platten und eins für die langsamen. (Nach dem Schema in comment:16.) Dann kommen /home/teachers und /home/students(?) auf die schnellen Platten und alles andere auf die langsamen.

[Stephan Richter]

Sorry für den späten Einstieg:

Wie sieht es bei den Varianten mit der Erweiterbarkeit aus? Natürlich kann man immer noch weitere Server hinstellen, aber langfristig will man ja sicherlich eher die Platten in den vorhandenen Servern durch dann größere ersetzen. Wie geht das? Geht das im laufenden Betrieb?

• kann man einen Brick frei machen (wie im RAID5) und dann die Platte ersetzen? Müssen alle Bricks gleich groß sein?
• sollten wir evtl. doch ein LVM aus je einer Platte erstellen, und daraus jeweils einen Brick? Dann könnte man später eine zweite, größere Platte dem LVM hinzufügen und die Daten im Betrieb auf die neue große Platte umziehen. Wenn man das nacheinander mit jedem Brick macht, kann man das GlusterVolumen evtl. relativ einfach im laufenden Betrieb vergrößern. (bzw. auch altersschwache Platten ersetzen).

[Rüdiger Kupper]

Update: nach extensivem Lesen in Foren, Docs und Manuals bin ich jetzt sicher, welches Setup für uns geeignet ist. Dokumentation folgt. (Ist auch nötig, das Setup ist zwar Gluster-typisch aber dennoch genügend kompliziert.)