UVMM Live Migration mit FibreChannel SAN Storage?

uvmm
kvm
san

#1

Hallöchen!

In einer UCS 4.2 Domäne habe ich 2 funktionierende Virtualisierungsserver. Nun würde ich gerne das Feature Live Migration in Betrieb bringen. Zur Verfügung habe ich ein HP EVA SAN Storage mit FibreChannel. Im standalone Betrieb habe ich bisher einfach eine große SAN Disk erzeugt, dem Host zugewiesen, libvirt Storage Pool angelegt und dort mehrere VMs in .qcow2 Dateien gespeichert, welche auf einer großen ext4 Partition liegen.

Versuchsweise habe ich eine neue SAN Disk angelegt und damit nur eine einzige VM drauf laufen lassen. Diese SAN Disk habe ich dann zusätzlich dem 2. KVM Host zugewiesen. Netzwerk und libvirt Storage Pool gleich konfiguriert - erfreulicherweise konnte ich nun schon die eine VM zwischen den Hosts hin- und her migrieren :slight_smile:

Die Frage die mich beschäftigt ist jetzt: Was muss ich bezüglich Speicher (Festplatte) beachten, um mehrere virtuelle Maschinen mit Live Migration nutzen können?

Bei Windows hatte ich bereits die Erfahrung gemacht, wenn mehrere Hosts gleichzeitig auf die selbe SAN Disk mit NTFS schreiben, ist das Dateisystem nach wenigen Minuten kaputt. Da ist in irgendeiner Form ein Clusterdienst nötig.
Sorgt hier auf dem Linux Server der libvirt Storage Pool für ein konsitentes Dateisystem? Brauche ich etwas anderes als ext4? Kann ich den vorhandenen libvirt Storage Pool mit 5 VMs einfach dem zweiten KVM Host zuweisen und gut ist? Oder benötigt man für jede VM eine eigene SAN Disk? Das würde wohl technisch funktionieren - wäre aber weit weg von benutzerfreundlich.

Das Dokument “Extended virtualization documentation” habe ich bereits gelesen, das behandelt nur ISCSI shared Storage und hilft mir nicht wirklich weiter.
Hat jemand einen Hinweis für mich?

sonnige Grüße,
Dirk


#2

Moin,

sicher, dass Du das Feature “Live Migration” richtig durchdrungen hast?

Es bedeuted, dass EINE virtuelle Maschine im laufenden Betrieb (also “angeschaltet”) von einem Virtualisierungs-Server auf den anderen Server “umziehen” kann.

Es bedeuted NICHT, dass ZWEI virtuelle Maschinen auf die gleichen (virtuellen) Festplatten zugreifen können! Denn da gilt das Gleiche wie für Win: Nach wenigen Minuten ist das Dateisystem Schrott!

LiveMigration dient dazu, dass man eine virtuelleMaschine im laufenden Betrieb auf einen anderene Host bringen kann, um den ursprünglichen Host z.B. zu aktualisieren. Es ist keine Hochverfügbarkeitslösung!

Solltest Du Platten bzw. Dateissysteme zwischen zwei VMs teilen wollen, benötigen diese definitiv ein Cluster-Dateisystem.

Hoffe das hilft.


#3

Hallo Knebb, danke schon mal für die Antwort.

Ja

Das ist mir bewusst, es geht nur darum an dem Host Wartungsarbeiten durchführen zu können. Da beschäftigt mich noch eine Frage. In meinem Testaufbau, mit einer VM auf einem Shared Storage mit zwei Hosts, hatte ich einen Defekt simuliert und den einen Host mit der VM drauf einfach ausgeschaltet. Bei einem Windows Hyper-V Cluster würde diese VM automatisch auf dem nächstbesten Cluster Node neugestartet werden und nach wenigen Minuten wäre alles wieder ok, ohne Admin Eingriff.

Dass bei meiner rudimentären Testumgebung das nicht automatisch geschieht, hatte ich schon erwartet, aber ich war irritiert, dass die eine VM auf dem intakten Host auch nicht mehr manuell zu starten war. Der UVMM hatte noch die “Erinnerung”, dass da mal eine VM war, aber er konnte sie nicht starten, weil der Host auf dem sie zuletzt lief, ja down war. Und bei meiner Desktop Anwendung, dem Virt-Manager war die VM aus der Liste komplett verschwunden.

Die Frage wäre nun, was muss beim anlegen einer VM beachtet werden, dass sie nach Ausfall eines Hosts, woanders wieder gestartet werden kann?

In der Windows-Welt ist das recht überschaubar, da kommt praktisch nur NTFS auf einem ClusterSharedVolume in Frage. Bei Linux lassen sich allerdings mehrere Finden, z.B. GFS2 und OCFS2. Welches eignet sich gut auf UCS mit UVMM?
Auf der Produktseite https://www.univention.de/produkte/ucs/funktionen/virtualisierung/ zählt das Feature “Live Migration” zu den wichtigsten Funktionen. Auf der englischen Version steht sogar: “Simple expansion and central administration of virtualization server in a cluster”

Aber in den Dokus konnte ich zu einem Cluster-Dateisystem nichts finden, wird nur bei Dovecot kurz erwähnt. Bin ich der erste der das nutzen will? Wie machen das andere? Welches Knöpferl muss ich drücken? :slight_smile:

Ciao,
Dirk


#4

Aber Du simulierst doch genau eine Hochverfügbarkeitslösung, indem Du den Host, auf dem die Maschine läuft, einfach abschaltest!

LiveMigration bedeuted, dass die VM im laufenden Betrieb von einem aktiven Host auf einen anderen aktiven Host migriert werden kann. Netzwerkverbindungen zu Clients etc. bleiben dabei vorhanden. Es geht nicht um (hartes) Ausschalten und automatisches Wiederanfahren!

Dazu benötigt die VM selbst auch kein Shared Dateisystem, da sie sich dessen ja garnicht bewußt ist, dass sie jetzt auf einem andern Rechner läuft. Es wird ja auch keine zweite Instanz gestartet, die gleichzeitig auf die virtuelle Platte zugreift. Innerhalb der VM ist also auch kein Cluster-FS nötig.

Das Dateisystem, auf dem die virtuelle Platte liegt, muss allerdings geteilt werden können. Allerdings reicht hier z.B. NFS völlig aus- sofern keine besonderen Anforderungen existieren.

Du legst also die virtuelle Platte in einen Storage, der von beiden Hosts angesprochen werden kann. Die Zugriffe regeln die UCS/ UVMM-System dann selbstsändig, auch ohne ClusterFS. Willst Du jedoch kein NFS benutzen, wirst Du um z.B. iSCSI oder SAN in Verbindung mit einem ClusterFS nicht drumherum kommen. Finde das aber “mit Kanonen auf Spatzen geschossen”. Soweit ich weiss, ist GlusterFS in DEbian (und damit UCS) integriert und wäre das Mittel der Wahl. Aber wie gesagt…

[Edit] sorry, ganz übersehen, dass Du ja mittels FC-SAN teilst… ja, dann nimm GlusterFS.


#5

Es passiert mir manchmal, dass ich zu kompliziert denke, NFS habe ich bisher gar nicht in Betracht gezogen, weil ich bislang kaum Berührungspunkte damit hatte - danke für den Hinweis. Da stellt sich mir die nächste Frage. Wenn ich zwei KVM Host mit je 5 VMs, wegen Updates im wechsel neustarten möchte, benötige ich (in meiner Vorstellung) einen dritten Server, der die NFS Freigabe bereitstellt.
Aber wie sieht dann die Situation aus, wenn der dritte Server auch mal einen Neustart braucht? Dann muss ich vermutlich zunächst alle VMs herunterfahren/speichern und dann kann erst der NFS Server neugestartet werden?


#6

Ja, das ist dann der Nachteil dieser Lösung. Stellt sich die Frage, wie oft das vorkommen mag und welche Vor-/ Nachteile die jeweiligen Lösungen für Dich so haben. Abwägen musst Du dann selbst…