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)

Storage-Pool für Libvirt

Wenn Sie nun zwei KVM-Hosts vorbereiten, definieren Sie dort jeweils einen Libvirt-Storage-Pool mit NFS. Die Libvirt übernimmt selbständig das Mounten des Share, wenn sie entsprechend konfiguriert ist. Dazu ist es zunächst nötig, einen Storage-Pool zu definieren, beispielsweise mit dem Commandline-Tool "virsh". Das wiederum benötigt eine XML-Datei, die Ort und Format des Storage bestimmt. Ein Beispiel dafür sieht so aus wie Listing 1.

Listing 1: Storage-Pool mit NFS



<pool type='netfs'>
   <name>virtstore </name>
    <source>
       <host name='192.168.1.1'/>
       <dir path='/virtstore'/>
       <format type='nfs'/>
    </source>
    <target>
       <path>/virtstore</path>
       <permissions>
          <mode>0755</mode>
          <owner>-1</owner>
          <group>-1</group>
       </permissions>
    </target>
</pool>

Mit dieser XML-Datei, als »virtstore.xml« gespeichert, lässt sich ein Storage-Pool mit dem Namen "virtstore" definieren:

virsh pool-define virtstore.xml

Der folgende Befehl legt fest, dass der Storage-Pool automatisch startet:

virsh pool-autostart virtstore

Je nach Linux-Distribution sind noch die Eigentümer und Rechte der Dateien anzupassen. Nutzen Sie SELinux mit Red-Hat und Co, können Sie auf eine spezielle SEBool-Einstellung zurückgreifen, die den Zugriff ermöglicht:

setsebool virt_use_nfs 1

Zur Kommunikation verwenden die beteiligten VM-Hosts die Secure-Shell SSH, die Sie also dementsprechend konfigurieren müssen. Am einfachsten ist es, mit »ssh-keygen« neue Schlüssel zu erzeugen und dabei auf die Passphrase zu verzichten, was selbstverständlich nur in einem gut abgesicherten Netz sinnvoll ist. Dann kopieren Sie die Schlüssel mit »ssh-copy-id« jeweils auf den anderen Host. Jetzt können Sie testen, ob ein SSH-Login ohne Passwort funktioniert.

Wenn Sie nun auf einem der beiden VM-Hosts eine neue virtuelle Maschine anlegen, achten Sie darauf, dass der vorher erzeugte NFS-Storage-Pool verwendet wird. Außerdem müssen Sie den Cache des virtuellen Block Device abschalten, weil "virsh" sonst bei der Migration meldet:

error: Unsafe migration: Migration may lead to data corruption if disks use cache != none

Das Abschalten des Cache empfiehlt sich ohnehin, da ja der VM-Host selbst über einen Buffer-Cache verfügt, der zum Einsatz kommt, bevor die Daten einer VM über die simulierte Disk auf einer echten Festplatte landen. Dazu können Sie entweder ein grafisches Frontend wie "virt-manager" verwenden oder weiterhin alles auf der Konsole erledigen, indem Sie die Konfiguration mit »virsh edit VM« bearbeiten. In der XML-Datei, die die Konfiguration einer VM bestimmt, suchen Sie die Zeilen für die Disk-Einstellungen und fügen den Attributen des "driver" die Option "cache='none'" hinzu:

<devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
       <driver name='qemu' type='raw' cache='none'/>
       ...

Nun lässt sich die Migration einer VM manuell wie folgt starten:

virsh migrate --live fedora-22 qemu+ssh://node2/system

Das Ergebnis ist in Bild 1 zu sehen: In knapp drei Sekunden wurde die virtuelle Maschine "fedora-22" vom Rechner node2 auf node1 übertragen.

Management-Tools für KVM

Für produktive Setups sollten Sie statt virsh eher komplexere Management-Tools verwenden wie etwa oVirt, das Open Source-Projekt, das dem Red Hat Enterprise Virtualization Manager (RHEV-M) zugrunde liegt.

In Produktivumgebungen sollte die Management-Instanz von oVirt respektive RHEV-M auf einem eigenen Rechner mit mindestens 4 GByte Speicher und 20 GByte Plattenplatz laufen. Dazu kommen ein bis mehrere Virtualisierungshosts, auf denen neben den VMs eine Software-Komponente namens VDSM (Virtual Desktop and Server Manager) läuft, die mit dem zentralen Server kommuniziert.

Am einfachsten ist die Installation auf CentOS oder Red Hat Enterprise Linux, aber die oVirt-Website gibt auch einige Tipps zur Installation auf Ubuntu und Debian. Bei CentOS und RHEL lässt sich die Software nach dem Einbinden der Paketquellen durch

yum localinstall http://resources. ovirt.org/pub/yum-repo/ovirt-release35.rpm

mit dem Befehl »yum -y install ovirt-engine« installieren. Danach konfigurieren Sie die Software mit »engine-setup« , wobei Sie in den meisten Fällen die Vorgaben übernehmen können.

Auch bei oVirt müssen Sie an die Firewall-Konfiguration denken und zahlreiche Ports öffnen, die Sie am einfachsten in den oVirt-FAQ [2] finden. Alternativ bietet oVirt bei der Installation an, das Management der Firewall zu übernehmen, dies allerdings nur auf dem Management-Rechner.

Läuft oVirt, erreichen Sie das Webinterface unter der URL "https://oVirt-Server/ ovirt-engine", wo Sie sich am Administration Portal anmelden, um die Konfiguration des Datacenters fertigzustellen. Neben den VM-Hosts benötigen Sie auch noch eine Storage-Domain, etwa basierend auf NFS. Wenn Sie dazu einen Linux-Rechner verwenden, müssen Sie beim Export des Dateisystems spezielle Optionen einstellen, damit die Zusammenarbeit mit oVirt funktioniert:

/virtstore 192.168.100.0/24(rw,anonuid=36,anongid=36,all_squash)

Wenn die Installation eines VM-Hosts fehlschlägt, überprüfen Sie die Firewall-Einstellungen und stellen sicher, dass auch auf dem Host das oVirt-Repository eingetragen ist. Gelingt es dem oVirt-Manager, auf dem Host die nötige VDSM-Software zu installieren, schaltet er anschließend den Status auf "active". Zusammen mit der Storage-Domain haben Sie nun ein funktionierendes Datacenter.

Um eine virtuelle Maschine zu installieren, benötigen Sie ein Template, das Sie am einfachsten aus dem bereits vorhandenen Glance-Repository beziehen. Dazu klicken Sie in der linken Spalte erst Ihr "Datacenter (Default)" an und wählen im oberen Reiter "Storage" aus. Klicken Sie mit der rechten Maustaste auf die "ovirt-image-repository"-Domain, können Sie die verfügbaren Images als Template importieren.

Zwischen zwei Hosts migrieren Sie VMs nun bequem per Mausklick. Alternativ bietet oVirt auch eine Reihe von Möglichkeiten, VMs automatisch zu migrieren, zum Beispiel wenn ein Node in den Maintenance-Mode versetzt wird. Zum Loadbalancing kann der Administrator eine Migration Policy aufstellen. Bild 2 zeigt, wie eine erfolgreiche Migration im Eventlog von oVirt aussieht.

Bild 2: Die VM-Migration von node1 auf node2 mit oVirt hat zehn Sekunden gedauert.

oVirt ist wie RHEV-M eine umfangreiche Software, die einige Einarbeitungszeit erfordert. Für kleinere Setups gibt es eine Reihe von mehr oder weniger ausgereiften Alternativen, die das KVM-Projekt auf einer eigenen Seite [3] aufführt. Herauszuheben ist hierbei etwa Proxmox VE, über das wir bereits mehrfach berichtet haben. OpenQRM, das ein Artikel in IT-Administrator 07/2015 im Detail vorstellt, geht schon einen Schritt weiter in Richtung Cloud-Management.

Eine interessante und eher unbekannte, wenngleich populäre Alternative ist Ganeti, ein Projekt aus den Google Labs. Zwar bietet es nur eine Kommandozeilenschnittstelle, lässt sich aber mit nur wenigen Befehlen bedienen. Das einzige Hindernis ist die nicht ganz einfache Installation, die in der Dokumentation auf Ubuntu- und Debian-Rechnern beschrieben wird. Wir haben Ganeti allerdings im Test auch auf CentOS ohne größere Schwierigkeiten zum Laufen gebracht.

Die potenziell größte Hürde ist die uneinheitliche Verwendung von Hostnamen. Am besten sollten Sie ein funktionierendes DNS betreiben, in dem die Namen der beteiligten Rechner konfiguriert sind. Alternativ können Sie die Namen in den Hosts-Files eintragen, müssen sich aber dann selber um Konsistenz kümmern. Neben den IP-Adressen und Namen für die einzelnen Knoten benötigen Sie noch eine weitere IP/Namenskombination, die für den Cluster verwendet wird.

Für den Shared Storage sorgt bei Ganeti das Distributed Replicated Storage Device (DRBD), das Sie der Ganeti-Dokumentation entsprechend konfigurieren müssen. Alternativ unterstützt Ganeti auch GlusterFS und Ceph/RADOS, aber dieses Setup haben wir nicht getestet. Ab Version 2.7 kann Ganeti auch externen Shared Storage einbinden, was beispielsweise den Einsatz von NFS ermöglicht.

Link-Codes

[1] KVM Live-Migration: http://www.linux-kvm.org/page/Migration/

[2] oVirt FAQ: http://www.ovirt.org/Ovirt_faq

[3] KVM Management-Tools: http://www.linux-kvm.org/page/Management_Tools/

[4] Synnefo: https://www.synnefo.org/

Nach der Installation der Software initialisieren Sie den Cluster mit einem Aufruf von »gnt-cluster init« . Dabei geben Sie den verwendeten Hypervisor KVM an, denn alternativ arbeitet Ganeti auch mit Xen zusammen. Läuft der Cluster wie gewünscht, startet der folgende Aufruf die Migration einer virtuellen Maschine (Bild 3):

gnt-instance migration vm1
Bild 3: Migration einer virtuellen Maschine in einem Ganeti-Cluster.

Läuft wider Erwarten eine Migration schief, bietet das Management-Tool auch eine Cleanup-Option, um Überreste der alten VM zu beseitigen. Wer über die Kommandozeile hinaus etwas mehr Komfort haben möchte, kann einen Blick auf Synnefo [4] werfen, ein grafisches Frontend, das von der griechischen Regierung und der EU finanziert wurde. Ganeti selbst bietet Hochverfügbarkeit und Failover und ist für ein Setup mit bis zu 150 physischen Hosts gedacht.

Ähnliche Artikel

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

Ausgabe /2022