Live-Migration von VMs mit KVM

Wandertag

Mit dem KVM-Hypervisor gibt es in der Linux-Welt seit einigen Jahren eine leistungsfähige Alternative zu Xen und VMware. Um die Virtualisierungslösung tauglich für den Firmeneinsatz zu machen, integrieren die Entwickler immer wieder neue nützliche Features. Ein Beispiel dafür ist die Live-Migration virtueller Maschinen, die dieser Artikel näher betrachtet.
Musste ein Admin vor Jahren pro Anwender noch genau einen Arbeitsplatz-PC verwalten, hat die mobile Datenwelt mittlerweile zu einem rasanten Zuwachs bei den ... (mehr)

Auf Linux-Systemen hat der im Kernel integrierte Hypervisor KVM (Kernel-based Virtual Machine) seit langem die Oberhand gewonnen. Der Grund dafür ist, dass KVM in allen gängigen Linux-Distributionen ohne zusätzliche Konfiguration zur Verfügung steht und die großen Distributoren wie Red Hat und Suse kontinuierlich an der Verbesserung von KVM arbeiten. Dabei sind für die meisten Anwender die oberen Leistungsgrenzen hinsichtlich Speichernutzung und Anzahl an VMs wohl weniger interessant als Brot- und Butter-Features, die etwa der Konkurrent VMware schon anbot, als KVM noch in den Kinderschuhen steckte.

Mittlerweile hat KVM aufgeholt und bietet schon seit einigen Jahren die Live-Migration virtueller Maschinen [1], die eine Voraussetzung dafür ist, Dienste zuverlässig zu virtualisieren. Denn damit lassen sich VMs samt Diensten von einem Server zum anderen migrieren, was etwa für Lastverteilung oder Hardware-Updates nützlich ist. Auch die Hochverfügbarkeit von Services kann mit Hilfe von Live-Migration einfacher realisiert werden. Live-Migration bedeutet dabei, dass die virtuellen Maschinen, abgesehen von einer möglichst kurzen Zeitspanne, weiterlaufen. Im Idealfall merken Client-Rechner, die eine VM als Server verwenden, von einer Migration nichts.

Die Live-Migration wird durch einige ausgeklügelte Technologien umgesetzt, die sicherstellen sollen, dass einerseits die Unterbrechung des Diensts möglichst kurz ist, und andererseits der Zustand der migrierten Maschine genau demjenigen der Ursprungsmaschine entspricht. Dazu starten die beteiligten Hypervisoren die Übertragung des RAM-Speichers und beginnen gleichzeitig damit, die Aktivitäten der Ausgangsmaschine zu überwachen. Sind die verbliebenen Änderungen klein genug, um sie in der vorgesehenen Zeit zu übertragen, wird die Ursprungs-VM pausiert, der noch nicht übertragene Speicher an das Ziel kopiert und dort die neue Maschine gestartet.

Shared Storage notwendig

Eine Voraussetzung für die Live-Migration von KVM-Maschinen ist, dass die beteiligten Disks auf einem Shared Storage liegen, also einem Datenspeicher, der zwischen Ursprungs- und Ziel-Host geteilt wird. Dies lässt sich beispielsweise mit NFS, iSCSI, Fibre Channel, aber auch mit verteilten oder Cluster-Dateisystemen wie GlusterFS und GFS2 erreichen. Libvirt, die Abstraktionsschicht zum Management unterschiedlicher Hypervisor-Systeme in Linux, verwaltet Datenspeicher in sogenannten Storage Pools. Dies können neben den erwähnten Technologien beispielsweise auch konventionelle Disks sowie ZFS-Pools oder Sheepdog-Cluster sein.

Die verschiedenen Technologien für Shared Storage bieten unterschiedliche Vorteile und erfordern mehr oder weniger Konfigurationsaufwand. Verwenden Sie Storage-Appliances der bekannten Hersteller, können Sie deren Netzwerk-Storage-Protokolle verwenden, also iSCSI, Fibre Channel oder eben NFS. Beispielsweise bietet NetApp Clustered ONTAP auch Support für pNFS, das von neueren Linux-Distributionen wie Red Hat Enterprise Linux oder CentOS 6.4 unterstützt wird. iSCSI lässt sich dagegen dank Multipathing redundant betreiben, aber dafür muss wieder die entsprechende Netzwerkinfrastruktur vorhanden sein. Fibre Channel ist in dieser Hinsicht am aufwendigsten, denn es erfordert ein eigenes SAN (Storage Area Network). Dazu gibt es mit FCoE (Fibre Channel over Ethernet) noch eine kupferbasierte Alternative, die aber eigentlich nur von der Firma Mellanox angeboten wird. Eine noch exotischere Lösung ist SCSI RDMA über Infiniband oder iWARP.

Testumgebung mit NFS einrichten

Für die ersten Tests geht es auch eine Nummer kleiner, also mit NFS, denn ein solcher Storage lässt sich auch mit Hausmitteln realisieren. Beispielsweise mit einem Linux-Server auf Basis von CentOS 7 ist ein NFS-Server im Handumdrehen installiert. Weil der NFS-Server größtenteils im Linux-Kernel implementiert ist, fehlen nur noch der RPCBind-Daemon und die nötigen Tools zum Management von NFS, die sich über das Paket "nfs-utils" installieren lassen. Die vom Server zur Verfügung gestellten ("exportierten") Verzeichnisse listet die Datei "/etc/exports" auf. Den NFS-Dienst startet der folgende Aufruf:

systemctl start nfs

Über Erfolg oder Misserfolg gibt ein Aufruf von »journactl -xn« Auskunft. Die aktuell exportierten Verzeichnisse listet »showmount -e« auf. Im Prinzip ist die Syntax der Exports-Datei einfach: das exportierte Verzeichnis gefolgt von IP-Adresse oder Hostnamen derjenigen Rechner, die das Ver- zeichnis mounten dürfen, und dahinter noch die Optionen, die beispielsweise festlegen, ob die Shares nur zum Lesen oder auch zum Schreiben freigegeben sind. Von diesen Optionen gibt es freilich eine ganze Menge, wie ein Blick in die Manpage von "exports" zeigt. Um mit Root-Rechten von anderen Rechnern auf die Netzlaufwerke zu schreiben, müssen Sie das mit der Option "no_root_squash" erlauben. Eine entsprechende Zeile in "/etc/exports" sähe dann etwa so aus:

/nfs 192.168.1.0/ 24(rw,no_root_squash)

Damit dürfen alle Rechner aus dem Netz 192.168.1.0 mit Root-Rechten das Verzeichnis "/nfs" mounten und darauf schreiben. Den NFS-Server können Sie daraufhin neu starten oder ihn über die Änderungen einfach per »exportfs -r« unterrichten. Wenn Sie nun von einem Rechner versuchen, aus dem besagten Netz das Verzeichnis zu mounten, schlägt das unter Umständen fehl, weil Sie auf dem Server noch die Firewall anpassen müssen, also den TCP-Port 2049 öffnen.

Bild 1: In knapp drei Sekunden wurde die virtuelle Maschine "fedora-22" vom Rechner node2 auf node1 übertragen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Container-Anwendungen isolieren mit Aporeto Trireme

Beim Umstieg auf Container-basierte Anwendungen sind viele Klippen zu umschiffen, dies gilt insbesondere für das Thema Security. So lassen sich Anwendungen nur schwer voneinander kontrollierbar isolieren. Hier setzt Aporeto mit Trireme an. Die Software sorgt dank einer attributbasierten Zugriffskontrolle für mehr Sicherheit. Wir stellen das Konzept anhand eines Beispiels vor. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Linux-Backup

Welche Backup-Lösung setzen Sie für Linux im professionellen Umfeld ein?

  • keine
  • eigene Scripts
  • rsnapshot
  • rdiff-backup
  • Bacula
  • Bareos
  • Borg
  • Duplicity
  • Amanda
  • Burp
  • Clonezilla
  • Acronis
  • Arkeia
  • SEP sesam
  • Veeam
  • Redo Backup
  • Relax-and-Recover
  • andere kommerzielle Software
  • andere Open-Source-Software

Google+

Ausgabe /2017

Microsite