High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Ressourcen-Manager

Sind diese ganzen Vorarbeiten abgeschlossen, sind nur noch die einzelnen virtuellen Maschinen über den Clustermanager zu aktivieren. Das Tool »clusvcadm« erweckt sie zum Leben:

# clusvcadm -e vm:vm1 -m host1.example.com
# clusvcadm -e vm:vm2 -m host2.example.com

Die Ausgabe von »clustat« sollte nun zusätzlich zu den physischen auch die beiden virtuellen Systeme anzeigen (Zeilen 11 und 12, Listing 11 ).

Listing 11

clustat

 

Fällt ein System aus, dann starten alle darauf laufenden virtuellen Systeme auf dem anderen Host. Außerdem ist auch eine Online-Migration möglich. Hierfür ist »clusvcadm« wie folgt aufzurufen:

# clusvcadm -M vm:vm1 -m host2.example.com

Zu Demonstrationszwecken eignet sich folgendes Szenario: Auf der »vm1« läuft die Kompilierung des Linux-Kernels. Während des Kompiliervorgangs stößt der oben aufgeführte Befehl die Migration der virtuellen Maschine auf den anderen Host an. Für den Benutzer ist die Migration komplett transparent.

Natürlich lässt sich das bestehende Setup auch noch um einen zweiten Cluster innerhalb der virtuellen Maschinen ergänzen. Dieser könnte sich dann beispielsweise um einzelne Netzwerkdienste innerhalb der virtuellen Maschine selbst kümmern. Das Setup ist nahezu identisch, lediglich bei der Konfiguration der (virtuellen) Fence-Devices ist darauf zu achten, den speziellen Agent »fence_virt« zu verwenden. Dieser versorgt den »fence_virtd« mit entsprechenden Anweisungen, sollte eine virtuelle Maschine nicht mehr reagieren.

Fazit

Ein Cluster-Setup mit virtuellen Maschinen als Cluster-Ressourcen ist schnell aufgebaut. Im Vergleich zur nativen Live-Migration auf Basis von Libvirt kümmert sich der Clustermanager auch um die Migration von Maschinen, wenn das Hostsystem ausgefallen ist. Für den Benutzer ist eine solche Migration komplett transparent und erfolgt ohne jeden manuellen Eingriff.

Auch wenn in diesem Artikel und seinen Beispielen lediglich von Linux-basierten virtuellen Maschinen die Rede war, so ist doch auch der Einsatz anderer Betriebssysteme innerhalb eines virtuellen Systems möglich.

Infos

  1. Xen-Hypervisor: http://www.xen.org
  2. KVM-Hypervisor: http://www.linux-kvm.org
  3. Red Hat Enterprise Virtualizsation (RHEV): http://www.redhat.com/virtualization/rhev/server
  4. Unterstützte KVM-Gastsysteme: http://www.linux-kvm.org/page/Guest_Support_Status
  5. Bonding-Treiber-Dokumentation im Linux-Kernel-Baum: http:///usr/share/doc/kernel-doc/Documentation/networking/bonbding.txt
  6. Unterstützte Fence-Devices der Red Hat Cluster Suite: http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/fence/agents/?cvsroot=cluster

Der Autor

Thorsten Scherf arbeitet als Senior Consultant für Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn ihm noch Zeit bleibt, nimmt er gerne an Marathonläufen teil.

comments powered by Disqus
Mehr zum Thema

Cluster-Dateisystem GFS2

Viele Köche verderben bekanntlich den Brei. Ähnlich würde es Daten ergehen, wenn viele Maschinen gleichzeitig auf ein und derselben Festplatte herumrühren. Abhilfe schafft ein Cluster-Dateisystem wie GFS2. Das arbeitet auf gesharten SAN-Platten oder DRBD-Spiegeln. Wir erklären die Basis des Filesystems und beschreiben dessen Installation auf RHEL-Basis.
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 /2023