Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

Ein Storage-Device für eine virtuelle Maschine

Im Grunde könnte es nun mit der ersten virtuellen Maschine losgehen, aber dafür fehlt noch eine wichtige Zutat: Ein Storage-Device, auf dem die Daten der virtuellen Maschine lagern. Es bieten sich zwei Ansätze an: Qemu kann einerseits mit Image-Dateien umgehen. Das sind Files im Dateisystem, die Qemu dann quasi als Festplatte betrachtet. Solche Images haben manchen Vorteil, zum Beispiel den, dass das Qcow2-Format, in dem Images meistens vorliegen, komprimieren kann und ein Gast-Betriebssystem so weniger Plattenplatz vom Host abzwackt, als es in der Innenansicht benötigt. Gerade im Cluster-Kontext bietet eine Image-basierte Lösung aber auch einige Nachteile.

Denn zunächst erhöht die Variante, virtuelle Maschinen in Form von Images zu verwenden, den Cluster-Aufwand beträchtlich. So müssen in Pacemaker für jedes Image, das zur Verfügung stehen soll, entsprechende Ressourcen in die Cluster-Konfiguration eingetragen werden. Wird stattdessen nur ein Device mit allen Image-Files benutzt, müsste dieses wiederum mit NFS exportiert und auf beiden Clusterknoten gemountet werden – sonst könnten nur alle VMs zu einem Zeitpunkt auf dem gleichen Host laufen. Beide Varianten nagen außerdem an der Performance einer virtuellen Maschine: Das Dateisystem mit seinem Page Cache drosselt die maximale Leistung genauso, wie es NFS nochmals täte.

Es hat sich deshalb eingebürgert, Block-Devices direkt als Storage-Device für virtuelle Maschinen einzusetzen. Qemu unterstützt diese Funktion und in einem Zwei-Knoten-Cluster steht auch das passende Werkzeug zur Verfügung, um die Daten auf beiden Knoten aktuell zu haben: DRBD. Der erste Schritt auf dem Weg zu einer privaten Cloud mit Libvirt und Pacemaker besteht also darin, ein DRBD-Laufwerk anzulegen, das die Daten der virtuellen Maschine aufzunehmen vermag. Das geschieht analog zum DRBD-Artikel im letzten Admin-Magazin. Der Artikel geht im weiteren Verlauf davon aus, dass ein DRBD-Laufwerk vorhanden ist, das im System über den Device-Knoten »/dev/drbd/by-res/kvm-alice/0« anzusprechen ist. Übrigens: Nachdem die DRBD-Ressource angelegt ist, ist es nicht ratsam, ein Dateisystem auf dem DRBD anzulegen – dieses würde ohnehin von der Installationsroutine des Betriebssystems später überschrieben.

Ist die DRBD-Ressource angelegt, empfiehlt es sich, sie vorerst noch nicht in den Cluster-Manager zu integrieren, wie in Teil 2 des Workshops erklärt. Der nächste logische Schritt ist stattdessen, eine virtuelle Maschine mit KVM einzurichten, sodass die virtuelle Maschine grundsätzlich lauffähig ist.

Eine virtuelle Maschine in die Libvirt einpflegen

Libvirt sucht im Verzeichnis »/etc/libvirt/qemu« nach Dateien, die auf ».xml« enden – aus diesen liest es die Definitionen für VMs. Die meisten Einträge dieser Maschinendefinitionen sind generisch und ändern sich nicht und lassen sich so für neue VMs recyclen. Das Listing 1 zeigt ein vollständiges Konfigurationsfile für eine virtuelle Maschine namens »debian-i386-alice« .

Listing 1

Konfigurationsdatei für VM

 

Im Kasten sind die zu adaptierenden Teile besonders hervorgehoben. Der erste Eintrag ist »name« – er legt fest, wie die virtuelle Maschine in Libvirt intern heißt. »uuid« ist freilich eine UUID; jede UUID darf innerhalb einer Libvirt-Installation bloß einmal vorkommen. Am leichtesten generieren Admins eine UUID mit dem Werkzeug »uuidgen« auf der Kommandozeile. »memory« legt den Speicher fest, der der virtuellen Maschine zur Verfügung steht. Im Beispiel sind das 512MB. Der Eintrag »vcpu« legt fest, wie viele virtuelle CPUs den virtuellen Maschinen zur Verfügung stehen.

»source dev=...« legt das Storage-Device fest, das Libvirt als Festplatte für die virtuelle Maschine verwendet. Im Beispiel zeigt der Eintrag auf die zuvor angelegte DRBD-Resource. Übrigens: Die Domänen-Definition hat auch ein virtuelles CD-Laufwerk, das auf eine ».iso« -Datei in »/tmp« verweist. Der Eintrag ist nicht verpflichtend und kann, wenn als Installationsquelle für die VM ein anderes Medium zur Verfügung steht, entfallen. Soll aber die CD zum Einsatz kommen, ist der Wert »dev« beim Parameter »boot« oben noch von »hd« auf »cdrom« zu ändern.

Häufig stellt sich die Frage, welche Architektur ein Gastsystem nutzen soll. Nachdem die VM im Beispiel insgesamt bloß 512 MByte RAM hat, ist die Frage hier irrelevant. Soll aber eine 64bit-VM mit mehr RAM zum Einsatz kommen, genügt es, die Zeile »<type arch='i686' machine='pc-0.12'>hvm</type>« so zu ändern: »<type arch='x86_64' machine='pc-0.12'>hvm</type>« .

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019