Es gibt viele Ansätze für hochverfügbare Dateien zu realisieren. Gerade viele hochverfügbaren Serverlösungen setzen auf hochverfügbare Dateien. Eine Lösung, dies bei einem Serverausfall abzufangen, betsteht darin, einfach einen externen Dateiserver, also ein NAS oder SAN zu verwenden.

Das bleibt bestehen, wenn der Server einmal weg ist. Aber wie regelt man, wer darauf zugriff haben darf und wie? Und was passiert, wenn just dieses zentrale Speichmedium ausfällt?

Eine Lösung besteht darin, einfach die Daten auf zwei Servern lokal vorzuhalten und die irgendwie zu synchronisieren. Eine beliebte und Open Source Lösung war hier DRBD.

Die hatte allerdings einen Nachteil: Man konnte die Daten immer nur auf einem System nutzen, das zweite war nur ein Backup. Mit neueren Versionen ist diese Einschränkung wegefallen, es können nun beide Systeme aktiv genutzt werden.

Allerdings hat das noch immer ein Problem: Wer darf auf welche Daten zugreifen? Da muss es dann locking-Mechanismen geben, um sicherzustellen, dass nicht zwei Prozesse die gleiche Datei zeitgleich auf verschiedenen Systemen (nodes) verändern. Da kommt dann oft der Distributed Lock Manager zum Einsatz oder man setzt ein Dateisystem auf dem DRDB ein, dass diese Funktion ebenfalls bereit hält, wie zum Beispiel GlusterFS

Wenn aber GlusterFS dieses Locking bereits bietet und obendrein ein verteiltes Dateisystem darstellt: Geht es dann nicht auch ohne DRBD?

Einsatzzwecke von HA-Dateien im aktiv-aktiv-Modus

Es gibt viele Fälle, bei denen beide Systeme aktiv genutzt werden sollten:

• Live-Migration von VMs

• schnelle Verfügbarkeit bei Ausfall

• höhere Performance durch Lastverteilung

Bei einer Live-Migration zum Beispiel mit QEMU wird dasselbe VM-Image auf einem zweiten Server gestartet und wartet auf den Abgleich der Daten wie die akutelle Hauptspeicherbelegung und welche Verbindungen aktiv sind. Dazu muss dann auch das zweite System auf das Image zugreifen können.

Beim Ausfall im aktiv-passiv-Modus fällt gleich alles aus und muss warten, bis das passive System aktiv ist. Bei aktiv-aktiv ist mitunter nur eine Hälfte betroffen und der Wechsel auf den anderen Server könnte schneller gehen.

Und die Geschwindigkeit ist eventuell auch höher, sofern sich die aktiven Nodes schnell synchronisieren können. Dazu beitet sich eine eigene Verbindung an. Dann kann ein Teil mit dem einen Node, der andere Teil mit den zweiten Node arbeiten.

Probleme bei aktiv-aktiv

Ein Problem wurde bereits erwähnt: Das locking muss geklärt werden. Sonst können zwei Prozesse auf verschiedenen Nodes dieselben Dateien verändern. Wer wird dann gewinnen? Mitunter werden dann Daten verloren oder noch schlimmer, die Datei ist anschließend korrupt und unnutzbar.

Ein weiteres Problem besteht aber im sogenannten split-brain-Fall. Die Server synchronisieren sich und stellen durch ein locking sicher, dass die Dateien nicht gleichzeitig mehrfach editiert werden. Die Änderungen werden dann in der Regel über eine eigene Netzwerkverbindung abgeglichen.

Was aber passiert, wenn diese Synchronisation unterbrochen ist? Wenn die zwei Nodes sich nicht mehr sehen? Wer ist denn dann der aktive Knoten? Die Lösung ist einfach: Es wird geprüft, ob der andere Node erreichbar und funktional ist. Nur wenn das nicht geht, die Node sich nicht sehen, wohl aber beide von den Clients angesprochen werden können?

Das ist ein Problem, jeder der beiden Nodes denkt dann, er wäre der alleinige aktive Knoten und nimmt Datenänderungen gemäß den Clientanforderungen vor. Das kann nur im Chaos enden und ist der größte Alptraum in diesem Umfeld

Der Schiedsrichter

Bei GlusterFS gibt es die Möglichkeit drei Server zu verwenden und über ein Quorum zu definieren, welche noch die alleinigen aktiven Nodes sind. Wenn dann einer ausfällt oder von einem anderen Node nicht mehr gesehen wird, so sind noch die Nodes aktiv, die sich sehen.

Sieht ein Node die zwei anderen Nodes nicht, so ist er der isolierte und verweigert daraufhin die weitere Arbeit bis alle Systeme wieder sichtbar sind und ein Abgleich der Daten stattgefunden hat.

Das ist eine schöne Lösung, hat aber einen Haken: Dann sind die Daten nicht zweimal sondern dreimal vorhanden, es wird dann der dreifache Speicherplatz benötigt, statt dem doppelten.

Hier hat GlusterFS eine elegante Lösung gefunden. Es gibt einen Node der nur Schiedsrichter (arbiter) spielt. Der muss nicht den vollen Datensatz zur Verfügung haben, sondern lediglich nur die Metadaten der Dateien um zu sehen, wie der Status ist, also zum Beispiel der Zeitpunkt der letzten Änderung, Zugriffsrechte, Größe, etc. Das belegt dann nur noch einen Bruchteil des Speicherplatzes und ist dann wieder in einem vertretbarem Rahmen.

Die Daten liegen dann lokal in einem Verzeichnis auf dem Node, dieses wird brick genannt. Allerdings werden Daten, die dahin geschrieben werden, nicht synchronisiert. Dafür muss das GlusterFS auch auf dem Server gemountet werden. Das kann per NFS erfolgen, besser ist aber das Userland per fuse eingebunden. Dabei findet auch eine Art der Lastverteilung auf die Nodes statt.

Fazit

Mit GlusterFS sind auch andere Szenarien realisierbar wie ein verteiltes Speichern von Daten oder auch etwas was sich Geo-Replikation nennt, da liegen die Dateien mitunter auf verschiedenen Kontinenten.

Aber eine der schönsten Anwendungen sind die hochverfügbaren Dateien in Verbindung mit einem arbiter. Gerade wenn Live-Migrationen von virtuellen Maschinen interessant sind oder die Daten möglichst immer da sein müssen, weil es zum Beispiel ein Home-Verzeichnis ist, so ist das eine schöne Lösung.

Es gibt auch andere Lösungen wie Ceph oder BeeGFS, aber meines Wissens haben diese alle nicht diese arbiter Funktion.