Neben einem Shared-File-Verzeichnis beherrscht Ganeti auch GlusterFS und die RDB-Schnittstelle des verteilten Dateisystems Ceph. Diese Disk-Templates aktivieren sie wie im Shared-File-Beispiel. Besonders interessant für den Enterprise-Einsatz sind die ExtStorage-Provider, die eine Anbindung von Storage-Appliances erlauben. Derzeit gibt es Ext-Storage-Provider für IBM Storwize, HP EVA sowie das ZFS-Dateisystem.
Ein weiterer ExtStorage-Provider bietet eine Integration von Clustered LVM (cLVM), und für RDB gibt es ebenfalls noch einen ExtStorage-Provider, der aber eigentlich nur zu Demo-Zwecken dient. Wer wirklich RDB/Ceph verwenden möchte, sollte das erwähnte native Disk-Template nutzen. Einen ExtStorage-Provider zu schreiben, ist zwar nicht trivial, aber auch nicht unendlich komplex, denn er muss nur die grundlegenden Operationen bereitstellen, die Ganeti verwendet. Eine Liste ist unter [3] zu finden.
Beim Anlegen einer neuen VM-Instanz geben Sie das Disk-Template mit dem Schalter "-t" an. Als Beispiel hier der Aufruf für das Shared-File-Directory:
# gnt-instance add -n node1:node3 -o debootstrap+default -t sharedfile -s 2G instance
Bereits angelegte Instanzen lassen sich hinsichtlich des Storage-Typs auch umwandeln. Dafür verwenden Sie den Befehl
»gnt-instance modify
«
gefolgt vom neuen Storage-Typ. Die VM muss dazu heruntergefahren sein. Beispielsweise wandelt der folgende Aufruf eine DRBD-basierte Instanz in eine VM mit einem gewöhnlichen Disk-Image um:
gnt-instance modify -t plain
Von einem Node zum anderen migrieren Sie die Instanzen mit dem Befehl
»gnt-instance migrate instance
«
. Damit das funktioniert, müssen die beiden VMs aber hinsichtlich ihrer virtuellen Hardware identisch ausgestattet sein, insbesondere was die CPU betrifft. Hier müssen Sie also bei der Cluster-Konfiguration den kleinsten gemeinsamen Nenner für alle VMs sicherstellen.
Um einen Node zum Beispiel bei Hardware-Ausfall oder Migration von allen laufenden VMs zu befreien, gibt es einige spezielle Befehle. Hierbei setzen Sie zuerst den Status eines Host auf "drained" (ausgetrocknet), um zu verhindern, dass er neue VMs erhält, und danach auf "offline", um ihn aus dem aktiven Cluster herauszunehmen:
# gnt-node modify --drained=yes node2
# hbal -L -X
# gnt-node modify --offline=yes node2
Analog verfahren Sie, um einen Node wieder zu aktivieren und in den Cluster aufzunehmen:
# gnt-node modify --online=yes node2
# hbal -L -X
Denken Sie immer daran, in solchen Fällen die von Ganeti bereitgestellten Kommandos zu verwenden und nicht etwa von Hand Änderungen vorzunehmen. Nur auf diese Weise ist die Konsistenz des Clusters gewährleistet.
Sollte der Cluster nicht arbeiten wie gewünscht, können Sie die meisten Befehle mit dem Schalter "-d" gesprächiger werden lassen. Weitere Informationen finden sich in den Logfiles in "/var/log/ganeti", etwa "/var/log/ganeti/node-daemon.log".
Bei Backups virtueller Maschinen hilft Ganeti mit dem Befehl "gnt-backup". Das Tool exportiert VMs samt Konfiguration in ein Verzeichnis auf einem der Nodes, das natürlich auch ein Netzlaufwerk sein kann. Auf dem gleichen Weg lässt sich ein exportiertes Verzeichnis auch wiederherstellen. Allerdings hält Ganeti per Default eine VM an, was nicht unbedingt wünschenswert ist, wenn der Dienst laufen soll und er nur auf dieser VM vorhanden ist. Alternativ bietet "gnt-backup" den Schalter "--noshutdown", der allerdings als "unsafe" gekennzeichnet ist:
gnt-backup export -n g1 --noshutdown instance0