glusterfs in KVM Umgebungen

[Marcus Schopen]

Grüß Dich Georg,

Am Freitag, den 28.06.2019, 00:25 +0200 schrieb Georg Gottleuber:
> Hallo.
> 
> Am 27.06.19 um 16:26 schrieb Maximilian Wilhelm:
> > Ich habe so ein Setup selbst nie in der Hand gehabt, durfte jüngst
> > aber lernen, dass Menschen viele Schmerzen mit der in-VM disk
> > performance
> > hatte und deshalb jetzt Container statt VMs nutzen :)
> 
> Die Performance ist bei uns kein wirkliches Problem. Aber wir
> benutzen
> KVM mit LVM, also Logical Volumes statt qcow2s (dadurch müssen
> Dateisystemzugriffe in der VM durch zwei Abstraktionsschichten
> weniger).
> 
> Die LVs könnte man auch im Betrieb via Snapshot + rsync auf einen
> anderen Host übertragen (der automatische Delta-Transfer-Algorithmus
> sorgt dafür, dass nur die Änderungen übertragen werden; evtl mit
> --block-size verschiedene Werte probieren). Damit habe ich aber keine
> Erfahrung.
> 
> Außerdem hat das Vorgehen (LVM-Snapshots) einen Nachteil: Bei einem
> Hardwarefehler hat man nur den Image-Inhalt, nicht den RAM-Inhalt,
> dass
> heißt das Backup hat die Qualität von einer Platte, die man im
> Betrieb
> aus einem Rechner zieht (hartes Ausschalten eben). In der Praxis
> hatte
> ich damit aber noch nie Probleme. Es ist nicht schön, aber die
> Ext-Dateisysteme überleben das (dank Journaling).
> 
> Zu glusterfs kann ich leider nichts sagen.

Backups fahre ich bereits mit LVM snaps und bup. Ich lege die Gäste
kurze schlafen (snapshot-create-as), erstelle dann einen LVM snap,
wecke die Gäste wieder auf und ziehe dann per bup das Backup. Für bup
habe ich mir ein paar Skripten[1] gebastelt, die das ganze
automatisieren. Das funktioniert zuverlässig und man damit jede Nacht
ein Vollbackup inkl. RAM der Gäste. Durch die Deduplizierung hält sich
der Datenverbrauch im Backup in Grenzen.

Wenn gluster keine gute Idee für qcow2 images ist, hat jemand schon
einmal mit DRDB in diesem Bereich gearbeitet?

Ciao!
Marcus



[1] https://github.com/localguru/bupmonkey