Linux-Admin: VM-Cluster des Otto-Diels-Instituts

Wozu ist das gut?

Diese Anleitung erklärt die Organisation, Wartung und Troubleshooting der Server-Virtualisierung im Otto-Diels-Institut.

Grundsätzlicher Aufbau

Der Virtual Machine (VM)-Cluster wird mit QEMU-KVM (Kernel-based Virtual Machine) auf Ubuntu LTS Server betrieben. Derzeit (Juli 2015) gibt es vier Host-Server:

vmhost1: 134.245.135.180
vmhost2: 134.245.135.181
vmhost3: 134.245.135.182
vmhost4: 134.245.135.183

Diese benutzen einen gemeinsamen Netzwerkspeicher, um auf die VM-Platten-Images zuzugreifen. Der Speicher (Oracle Cluster File System) wird von einem iSCSI-RAID über das Storage Network (internes Netzwerk) bereitgestellt:

192.168.0.10 (vmstorage OCFS2 cluster)
192.168.0.11 (datengrab OCFS2 cluster, wird für VMs nicht benötigt)

Der vmstorage-Cluster wird von den vmhost-Servern als /vmstorage gemountet. Dies ermöglicht die freizügige Migration der VMs zwischen den vmhost-Servern je nach Auslastung oder bei Server-Wartungsarbeiten.

Installation

Zum Setup der VM-Hosts und Einrichtung des Oracle Cluster File System siehe folgende Anleitungen:

• Linux-Admin: Installationsanleitungen für Server (Sektion: VM-Host-Maschine)
• Linux-Admin: Netzwerkbrücke auf Ubuntu für VM-Hosts
• Linux-Admin: Geräte über serielle Schnittstelle steuern mit minicom
• Linux-Admin: Oracle Cluster File System (OCFS)

VM-Verwaltung mit virsh

Man kann fast alle Manipulationen mit VMs auf der Kommandozeile der vmhost-Server mit dem Werkzeug virsh erledigen. Die wichtigsten Befehle sind folgende:

virsh list (Auflisten aller laufenden VMs)
virsh list --all (Auflisten aller definierten VMs, auch der gerade nicht laufenden)
virsh start <VM-Name> (Starten einer VM)
virsh shutdown <VM-Name> (kontrolliertes Herunterfahren)
virsh destroy <VM-Name> (sofortiges Ausschalten, quasi "Stecker raus", kann für abgestürzte VMs nötig sein)
virsh define <XML-Dateiname> (VM aus XML-Datei neu definieren)
virsh undefine <VM-Name> (VM-Definition löschen)
virsh dumpxml <VM-Name> > <XML-Dateiname> (VM-Definition neu schreiben)

VM-Verwaltung mit virt-manager

virt-manager ist ein grafisches Programm für Linux, mit dem man VMs auch auf entfernten vmhost-Servern administrieren kann (vorausgesetzt man hat root-Zugriff und den SSH-Key getauscht). Auf Ubuntu installiert man wie folgt:

sudo apt-get install virt-manager virt-viewer

In virt-manager kann man dann "file --> add connection" wählen, dort Haken bei "connect to remote host" setzen, Method: SSH, Username: root, Hostname: z.B. vmhost1 (oder die IP-Adresse). "Connect", und fertig. Man sieht alle laufenden und nicht-laufenden VMs und kann durch Doppelklick auch eine Konsole öffnen (wichtig bei fälligen Tastatur-Eingaben während des Boots), Einstellungen verändern, Systemlast sehen etc.).

VM-Autostart nach Reboot des Host-Servers

Auf den vmhost-Servern werden nach einem Reboot die zuvor laufenden VMs automatisch wieder angefahren. Dazu enthält die crontab von root folgenden Eintrag:

@reboot /usr/local/bin/restart_running_vms

Damit wird nach dem Neustart dieses Skript getriggert, das nach einer Wartezeit von 30 sec. die VMs wieder startet, die in der Datei /root/running_vms gelistet sind:

sleep 30

echo "restarting VMs on `hostname` after reboot at `date`" >> /vmstorage/restart_running_vms.log
while read line; do virsh start $line >> /vmstorage/restart_running_vms.log; sleep 5; done < /root/running_vms

Die Datei /root/running_vms muss manuell gepflegt werden, damit dort jederzeit die richtigen VMs gelistet sind, z.B.:

virsh list --name > /root/running_vms

VM-Migration zwischen Hosts

Grundsätzlich ist jede VM auf allen Hosts lauffähig, da die Images allen Hosts zur Verfügung stehen. Es kann nötig sein, VMs zwischen Hosts zu verschieben (Server-Wartung am Host, Auslastungsprobleme), dazu geht man wie folgt vor:

1. Herunterfahren der VM auf dem alten Host (virsh shutdown <VM-Name>)
2. warten, bis der Shutdown abgeschlossen ist (virsh list zeigt die VM nicht mehr)
3. falls die VM nicht erfolgreich runterfährt: VM abschießen (virsh destroy <VM-Name>)
4. Starten der VM auf dem neuen Host (virsh start <VM-Name>)

WICHTIG: Auf keinen Fall darf eine VM gleichzeitig auf zwei Hosts gestartet sein! Das führt meist zu Dateisystem-Fehlern am Image, bis hin zur völligen Unbrauchbarkeit!!!!!

VM klonen / duplizieren

Um eine bestehende VM zu duplizieren, geht man wie folgt vor:

1. Herunterfahren der VM (virsh shutdown <VM-Name>)
2. warten, bis der Shutdown abgeschlossen ist (virsh list zeigt die VM nicht mehr)
3. falls die VM nicht erfolgreich runterfährt: VM abschießen (virsh destroy <VM-Name>)

Danach muss das Disk Image und die XML-Definition kopiert werden:

cd /vmstorage
cp -r --sparse=always <old vm-dir> <new vm-dir> (sparse spart Speicherplatz) 
cp <old vm>.xml <new vm>.xml

In der Definition der neuen VM müssen vier Dinge editiert werden (z.B. mit vim):

• Name der VM ("name-Tag" im XML)
• UUID der VM ("uuid"-Tag im XML)
• Speicherort des neuen Disk Image ("source file"-Tag im XML)
• MAC-Adresse der virtuellen Netzwerkkarte ("mac address"-Tag im XML)

Für UUID und MAC-Adresse können willkürliche Werte eingegeben werden. Danach kann man die neue VM definieren und starten:

virsh define <XML-Dateiname>
virsh start <VM-Name>

In der neuen VM müssen dann noch IP-Adresse und Hostname geändert werden. Das geht entweder per SSH mit den Daten der "alten" VM, oder man benutzt virt-viewer für eine grafische Ansicht der VM (in Kombination mit virt-manager). Die neue VM sollte zum Schluss noch in der Datei /root/running_vms eingetragen werden, damit sie nach einem Host-Reboot auch wieder neu gestartet wird (s.o. "VM-Autostart nach Reboot des Host-Servers")

Wenn die duplizierte VM sauber läuft, kann auch die ursprüngliche VM wieder angefahren werden.

Troubleshooting

Ausfall einer VM

Wenn eine VM "hängt", kann das mehrere Ursachen haben.

Ursache innerhalb der VM

• fehlerhafte Konfigurationen
  • Lösung muss individuell gefunden werden.
• Dateisystemfehler (z.B. read-only, Lesefehler)
  • meist hilft ein VM-Neustart. Da nach einem abrupten Neustart meist ein Dateisystem-Check läuft, ist es sinnvoll, ggf. mit virt-viewer zuzugucken, um an der entscheidenden Stelle noch Eingaben machen zu können.

Ursache außerhalb der VM

• Dateisystemfehler auf einem vmhost
  • Wenn auf einem der Hosts der Bereich /vmstorage nur noch read-only gemountet ist, muss meist der Host neu gestartet werden.
  • Wenn noch möglich, sollten vorher ALLE noch laufenden VMs notiert und dann runtergefahren werden (virsh shutdown <VM-Name> bzw virsh destroy <VM-Name>.
  • Nach dem Neustart kann man überprüfen, ob alle VMs wieder hochkommen.
  • Sollte der Host nicht wieder starten, müssen wichtige VMs auf einem anderen Host gestartet werden.
  • WICHTIG: Es muss dann sichergestellt werden, dass die VMs nicht doppelt gestartet werden.
• Ausfall eines vmhost
  • In diesem Fall werden ebenso die wichtigsten VMs auf einem anderen Host gestartet.
  • WICHTIG: Es muss dann sichergestellt werden, dass die VMs nicht doppelt gestartet werden.
  • Danach kann das Problem behoben werden (Hardware-Tausch o.ä.)
  • Falls Neuinstallation fällig ist: Siehe Anleitungen oben unter "Installation".
• Ausfall des eonstor-iSCSI-RAID
  • vmhost2 hat noch einen zusätzlichen lokalen Bereich /vmstorage_local, wo einige wichtige VMs als Zweit-Image liegen.
  • Dazu werden die betroffenen VMs auf vmhost2 zuerst gestoppt (s.o.), gelöscht und dann die lokale Version neu definiert:

virsh undefine <VM-Name>
virsh define /vmstorage_local/<XML-Dateiname>
virsh start <VM-Name>

Danach kann ggf. innerhalb der VM das Datenbackup vom NAS-Server (HTML, MySQL) wieder eingespielt werden