freiesMagazin

an einem wählbaren Platz im Dateisystem gesichert.
Damit das Festplattenimage auch konsistent
ist, wird die Snapshot-Funktionalität des
Proxmox VE zugrundeliegenden Dateisystems
(Logical Volume Manager) genutzt. Bei der Installation
wird die Festplattenaufteilung automatisch
vorgenommen und einfach 4 GB in der Volumegroup
pve freigehalten, um die Shapshots beim
Backup zu ermöglichen. Das ist bewährte Technik
und der Nutzer braucht sich darum nicht zu
kümmern.
Der Proxmox VE-Cluster
Richtig nett wird es, wenn man mit Proxmox VE
einen Cluster aufbaut. Hierbei ist allerdings kein
Cluster im Sinne von Ausfallsicherheit gemeint,
sondern eine gemeinsame Verwaltung der Clusterknoten
bzw. hauptsächlich der virtuellen Maschinen
auf den jeweiligen Knoten. Ein Cluster ist
schell eingerichtet. Bei der Installation des zweiten
Servers ist darauf zu achten, dass sich die
Rechnernamen unterscheiden. Auf dem Master
wird im Terminal ein
# pveca -c
und beim zweiten Server ein
# pveca -a -h IP-ADRESS -MASTER
ausgeführt. (Das IP-ADRESS-MASTER ersetzt
man z. B. mit 192.168.200.100.) Schon steht
der Cluster und wird synchronisiert. Wichtig ist
hierbei noch, dass die virtuellen Netzwerkbridges
(vmbr0-9) auf allen Clusterrechnern gleich defi-
niert sind. Sonst führt ein Verschieben einer VM
nicht zu dem erwünschten Ergebnis.
Zur Auswahl stehende Templates.
Nun können die Gastsysteme von einem Rechner
zum anderen transferiert werden – auch im
laufenden Betrieb. Dies dauert zwar seine Zeit,
weil sämtliche Dateien der VM, also auch Diskima-ges,
per rsync transferiert werden. Erst ganz
zum Schluss wird das Gastsystem kurz eingefroren
und dann auf dem neuen Host fortgesetzt.
Dies dauert je nach System und Last zwischen
wenigen Sekunden bis in den Minutenbereich.
Im Testfall wurde ein Windows-Rechner, der per
Netzwerkstream ein PDF aus einer Postscriptdatei
generiert, unter Vollast umgezogen. Dies dauerte
zwar recht lange, aber trotz eines Stillstandes
von knapp über zwei Minuten kam es zu
keinerlei Timeout und das PDF wurde ordnungsgemäß
erstellt. Im echten Leben würde man sicherlich
einen Zeitpunkt wählen, an dem der
VIRTUALISIERUNG
Umzugskandidat nicht besonders stark gefordert
ist. Es ist aber ein beruhigendes Gefühl, wenn
man weiß, dass es auch sonst funktioniert. Eine
Online-Migration funktioniert nur, wenn auf beiden
Knoten der gleiche CPU-Typ werkelt. Proxmox
VE warnt leider nicht, wenn von AMD zu Intel
oder andersherum migriert wird, was der virtuelle
Gast mit einem Crash und anschließendem
Neustart dankt!
Installierte Templates (ISO-Files der CDs) werden
automatisch auf alle Clusterknoten repliziert.
Dadurch ist es z. B. auch problemlos möglich, die
im Beispiel beschriebene Firewall, die von CD-
Isoimage bootet, im Betrieb umzuziehen. Dies
ist noch nicht einmal mit VMware Infrastructure
möglich – hier ist es kein Problem, Festplatten im
Betrieb zu migrieren, aber Maschinen mit Boot-
CDs lassen sich nur abgeschaltet umziehen.
Proxmox VE im Vergleich zu VMware
Infrastructure
Warum also noch Geld für proprietäre Produkte
wie VMware Infrastructure [10] ausgeben, wenn
es Proxmox VE gibt? Dafür gibt es natürlich nach
wie vor viele Gründe – auch wenn es inzwischen
ein paar weniger sind. Die Lösungen haben
einen unterschiedlichen Ansatz und entsprechend
auch unterschiedliche Einsatzgebiete. So
setzt VMware beim Festplattenspeicher auf ein
Speichernetzwerk (SAN) während bei Proxmox
VE jede Clusternode ihren eigenen Festplattenspeicher
benötigt, der natürlich auch im SAN liegen
kann. Ebenso wird die Konfiguration der ein-
© freiesMagazin GNU FDL Ausgabe 05/2009 28