Seite wählen

KVM-Cluster: Hochverfügbarkeit und zuverlässiges Locking

von | Sep 8, 2011 | Linux, Virtualisierung

Im Internet, in Büchern und einer Reihe von Fachartikeln findet sich umfangreiche Unterstützung für das Einrichten unterschiedlichster hochverfügbarer Linux-Cluster. Zur Zeit hoch im Kurs ist die Clusterlösung Pacemaker in Kombination mit Corosync/OpenAIS. Als Virtualisierungslösung mausert sich KVM (neben LXC) zum Produkt der Wahl. Und beides zusammen ergibt einen richtig schönen Cluster mit VMs, die „nach Belieben“ von einem Rechner zum anderen wandern können. Oder auf Neudeutsch: eine „Private Cloud“.
Soweit nichts Neues, allerdings sind die meisten der vorgestellten Lösungen, die sich so finden, höchst riskant. Wer nämlich auf die Live-Migration nicht verzichten will, muss auf „Shared Storage“ zurückgreifen. Dabei hat man die Wahl zwischen einer Lösung wie NFS (was man für VMs nicht unbedingt haben möchte), oder aber einem gemeinsamen Blockdevice (SAN, DRBD, iSCSI) mit einem Cluster-Filesystem wie GFS2 oder OCFS2. Bei vielen Knoten bieten sich Lustre, GlusterFS oder für wagemutige auch Ceph an – diese Lösungen lassen wir jetzt aber mal außen vor.

Soweit, so gut. Aber: QEMU/KVM betreibt keinerlei Locking für seine Disk Images. Das bedeutet, dass man sehr leicht versehentlich dasselbe Image zweimal gleichzeitig booten kann. So etwas hat katastrophale Auswirkungen, das Filesystem der VM wird schneller als einem lieb ist korrupt und ist zudem sehr bald kaum noch wiederherstellbar. Zwar kann man eine VM mit libvirt nicht zweimal gleichzeitig starten, wohl aber z.B. beim Clonen einer VM versehentlich dasselbe Image im XML-File stehen lassen. Genauso „tödlich“ ist es, wenn in einem Cluster dieselbe VM auf zwei unterschiedlichen Knoten startet. Und spätestens in einer Split-Brain-Situation wird das früher oder später passieren.
Kürzlich konnte ich bei einem Kunden eine interessante Lösung hierfür implementieren. Libvirt bietet nämlich mittlerweile eine Schnittstelle für Lock-Manager an, und „sanlock“ ist ein solcher. Damit gelang es nicht nur, auf einem GFS2 in Kombination mit mit einem Dual-Primary DRBD ein funktionierendes Locking für die VM-Images umzusetzen, sondern sogar in Kombination mit cLVM und GFS2-basiertem Sanlock auf dem DRBD sitzende einzelne Logical Volumes als virtuelle Disks den einzelnen VMs zuzuweisen.
Mit dem üblichen Minimal-Tuning für GFS2 bedeutete dies für die LVM-basierten VMs verglichen mit dem was wir in den GFS2-basierten messen konnten immer noch fast doppelten Durchsatz bei sequentiellem Schreiben und ein Fünftel der Latenzzeit!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

6 Kommentare

  1. Dennis

    Warum will man denn kein NFS als Shared Storage? Das in der Realität neben iscsi und FC Gang und Gebe.
    Aber ansonsten sehr interessanter Artikel!
    Gruß

    Antworten
  2. Thomas Gelf

    Besten Dank! Zum NFS: das war vielleicht etwas unglücklich formuliert. Klar kann man NFS „wollen“, es ist zudem äußerst bequem. Und auch in einem solchen Setup ist Sanlock übrigens definitiv einen Blick wert. NFS „will“ man meiner Meinung nach aber nur dann, wenn keine besonders hohen Anforderungen an die I/O-Performance der VMs stellt. KVM soll in dieser Disziplin zwar wesentlich performanter als XEN sein, verglichen mit dem was ein Bare-Metal Server liefert ist das aber immer noch sehr traurig.
    NFS impliziert ja schon per Design, dass man (wie auch bei GFS) Image-Files für seine VMs nutzen muss. Und schon allein dadurch verliert man enorm im Vergleich zu einem „direkt durchgereichten“ Block-Device. Hinzu kommen dann noch die protokollbedingten Latenzen, die (wie auch bei iSCSI) durchaus schmerzen können.
    Lieben Gruß
    Tom

    Antworten
  3. Peter Hinse

    Wichtig zu erwähnen ist, daß man eine aktuelle libvirt braucht. Dank spec File lässt sich das aktuelle tar.gz (momentan 0.9.4) von libvirt.org nach Auflösen weniger Abhängigkeiten unter RHEL-6.1 basierten Distributionen als RPM bauen. Unter CentOS 6.0 ging das leider wegen eines zu alten systemtap Pakets nicht.

    Antworten
  4. Oskar

    Hi, bin gerade auf den Post gestossen… Das mit dem GFS finde ich recht interesant. Kann man Glusterfs als interesante alternative sehen? Mitlerweile sind 2 Jahre vergangen und es hat sich einiges getan… Grüsse aus der Heimat…

    Antworten
  5. Thomas Gelf

    @Florian: wir mittlerweile auch, intensiv 🙂 Ceph ist wirklich herrlich. Der Artikel ist von 2011, Ceph hatte ich darin eh erwähnt und auch schon damals erste Tests damit gefahren. Zu dem Zeitpunkt wollte man das aber nicht unbedingt in Produktionsumgebungen einsetzen. Heute sieht es schon anders aus, wir sind mit Ceph jedenfalls sehr zufrieden.
    DRBD würd ich aber dennoch nicht so schnell abschreiben, ich nutze es noch immer sehr gerne. Zwar kann ich nicht so elegant den Durchsatz steigern wie bei Ceph und natürlich auch nicht so herrlich flexibel skalieren. Anders sieht es hingegen bei den Latenzen aus, gerade beim Lesen.
    @Oskar: sorry, deinen Kommentar hatte ich gar nicht bemerkt. GlusterFS ist durchaus interessant, und wir haben auch in Produktionsumgebungen eine Menge Erfahrung damit gesammelt. Kurz: solange alles läuft ist es super. Aber wehe wenn dir mal ein wenig Hardware um die Ohren fliegt. Ceph spielt da meiner Meinung nach einfach in einer anderen Liga. Bei GlusterFS zahlst viel schneller teures Lehrgeld. Gluster will halt einfach manchmal nicht wie du dir das so vorstellst 😀 Auch wenn das Problem dann vielleicht am Ende rein wissenschaftlich betrachtet eher auf Layer 8 anzusiedeln war – warum soll man sich quälen, wenn es auch einfacher geht.
    Kann Florian deshalb nur zustimmen: heute ist Ceph (die Rados block devices, NICHT CephFS) für ein Setup wie das hier beschriebene erste Wahl. Sonst würden wir’s ja nicht so intensiv nutzen 😉
    Lieben Gruß
    Thomas

    Antworten

Trackbacks/Pingbacks

  1. Weekly Snap: From Python, KVM locking & Clonezilla tips, to OpenSUSE rwx³ & Helping Kids in Uganda « NETWAYS Blog - [...] followed with his most recent solution for high availability and reliable locking in KVM clusters. With Libvirt’s Sanlock coupled…

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Linux | Virtualisierung

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: "Welches Linux ist das Beste?". Also für mich ganz persönlich. Nicht...

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation. If used in complex or...