VM-Failover mit OpenStack

Besondere Erwähnung sollen außerdem die drei »p_nova-compute« -Instanzen finden, denn sie ermöglichen den Neustart virtueller Maschinen auf anderen Hosts, nachdem der ursprüngliche Host, auf dem die VMs gelaufen sind, nicht mehr zur Verfügung steht. Bisher war das in OpenStack ein heikles Thema, denn die Umgebung selbst merkt – zumindest in Folsom – vom Ausfall eines Knotens zunächst einmal nichts. Über das im Beispiel genutzte Hintertürchen lässt sich eine ähnliche Funktion allerdings nachrüsten. Jede Instanz von »nova-compute« erlaubt es, zusätzliche Konfigurationsdateien anzugeben. Deren Werte d überschreiben dabei jeweils schon vorhandene Werte – der letzte gewinnt. Mittels »host=« erfährt eine Compute-Instanz, wie sie heißen soll; ist der Wert nicht gesetzt, nimmt Nova üblicherweise den Hostnamen des Systems. Der Trick besteht darin, die Kopplung von Hostname und hierauf laufenden VMs aufzuheben. Ob die Nova-Compute-Instanz namens »host1« auf Knoten 1, Knoten 2 oder Knoten 3 läuft, ist dann erstmal nicht relevant, und VMs, die auf »host1« gelaufen sind, lassen sich auf jedem Server starten, solange es dort eine Nova-Compute-Instanz gibt, die sich für »host1« hält.

Die in Teil 2 des Workshops genutzte »nova.conf« enthält außerdem die Option »resume_guests_state_on_host_boot=true« , die dazu führt, dass VMs auf einem Host nach dem Start von »nova-compute« in den Zustand versetzt werden, in dem Nova sie zum letzten Mal gesehen hat. Im Klartext: Läuft auf Server 1 ein »nova-compute« , das »host=host1« gesetzt hat, merkt Nova sich, welche VMs auf diesem »host1« laufen. Stürzt Server 1 ab, startet im Beispiel Pacemaker die »nova-compute« -Instanz »host1« auf einem anderen Server neu – und Nova bootet die VMs, die zuvor auf Server 1 gelaufen sind, dort ebenfalls. Damit das Prinzip sinnvoll funktioniert, ist es notwendig, dass alle »nova-compute« -Instanzen Zugriff auf das gleiche »instances« -Verzeichnis von Nova haben. Das Beispiel löst das Problem, indem es auf allen Servern »/var/lib/nova/instances« als Mount auf ein CephFS nutzt, über das allen Hosts die gleichen Dateien zur Verfügung stehen.

Darüber hinaus gilt für OpenStack-Pacemaker-Setups das, was für sämtliche Pacemaker-Installationen gilt: Die Versionen der Programme sind zwischen den Rechnern identisch zu halten. Eventuell benötigte Config-Files der Dienste müssen ebenfalls zwischen den Hosts synchron bleiben. Sind diese Voraussetzungen erfüllt, steht dem hochverfügbaren OpenStack-Setup nichts im Weg.

Abbildung 4: Das Verzeichnis /var/lib/nova/instances ist auf allen Hosts ein CephFS-Mount – so stehen allen Servern die gleichen VM-Daten zur Verfügung.

Zukunftsmusik

Der vorgestellte Mechanismus für VM-HA kommt mit einem nicht ganz kleinen Pferdefuß, denn er ermöglicht lediglich das kollektive Neustarten sämtlicher VMs eines ausgefallenen Hosts auf einem anderen. Sinnvoller wäre es, würde sich OpenStack selbst um die Problematik kümmern und ausgefallene VMs über seinen eigenen Scheduler auf mehrere Hosts mit freien Ressourcen verteilen. Folsom wird diese Funktion vermutlich nicht mehr erhalten. In Grizzly ist ein entsprechendes Feature aber schon implementiert: Die »evacuate« -Funktion soll genau diese Feature-Lücke füllen. Noch ist es zu früh, um deren Alltagstauglichkeit zu untersuchen. Wer sich mit OpenStack in Zukunft näher beschäftigen möchte, darf aber gespannt sein.

Abbildung 5: Mittels Pacemaker lässt sich ein Open-Stack-Setup gegen Ausfälle abhärten. Das Beispiel zeigt einen Drei-Knoten-Cluster, bei dem ein Knoten nicht zur Verfügung steht.