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

Aus Hergipedia
Zur Navigation springen Zur Suche springen

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 2021) gibt es vier Host-Server, davon sind zwei aktiv und zwei Reserve: 

vmhost1: 134.245.135.180 (aktiv)
vmhost2: 134.245.135.181 (Reserve)
vmhost3: 134.245.135.182 (Reserve)
vmhost4: 134.245.135.183 (aktiv)

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:

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

zur Zeit (Juli 2021) nicht funktional!!

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.

Datenbackups und MySQL-Backups auf dem NAS

Von diversen VMs wird täglich ein Datenbackup sowie ein MySQL-Autobackup erstellt und aufs Nas übertragen: 

nasigoreng (134.245.135.26)
Die Backup-Daten liegen dort unter /home/datenbackups

Diese Backups können genutzt werden, um ein ggf. veraltetes VM-Image auf den neuesten Stand zu bringen.

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

Abgerufen von „http:///mediawiki/index.php?title=Linux-Admin:_VM-Cluster_des_Otto-Diels-Instituts&oldid=22848“