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!
