Hochverfügbarkeit für OpenStack

Die gute Nachricht ist: Folsom ist in Sachen HA lange nicht so unbedarft, wie es frühere OpenStack-Versionen waren. Nicht zuletzt durch die vom Autor dieses Artikels mit vorangetriebene Integration der OpenStack-Dienste in Pacemaker-Cluster lässt sich der größte Teil einer OpenStack-Installation mittlerweile hochverfügbar auslegen. Dabei findet sich übrigens ein zweiter Grund, auf Object-Storage-Lösungen wie Ceph zu setzen: Jene kommen mit HA ab Werk, sodass Admins sich hier keine Gedanken um Redundanz zu machen brauchen.

Sehr wohl als Problemfeld erhalten bleibt dem Administrator sowohl die Ausfallsicherheit der OpenStack-Infrastruktur wie auch die der eigentlichen VMs. Hinsichtlich der Infrastruktur-Komponente bietet sich Pacemaker quasi an: Es bietet einen umfassenden Werkzeugkoffer, mit dem sich Dienste redundant auf mehreren Rechnern konfigurieren lassen. Fast alle OpenStack-Dienste lassen sich so hochverfügbar machen, das umfasst Keystone genauso wie Glance, Nova, Quantum oder Cinder. Wer ein OpenStack-HA-Setup plant, sollte allerdings zwei andere Komponenten nicht vergessen: die Datenbank, typischerweise MySQL, sowie den Message-Queue, also RabbitmQ oder Qpid.

HA für MySQL und RabbitMQ

Für MySQL bieten sich gleich mehrere HA-Optionen an. Die klassische Methode besteht darin, dass MySQL seine Daten auf einem Shared Storage wie DRBD liegen hat und der eigentliche »mysqld« dann zwischen zwei Rechnern hin- und herschwenkt. Je nach Größe des Datenbank-Journals kann ein Failover in solchen Szenarien allerdings einige Zeit dauern, überdies skaliert die Lösung nicht in die Breite. Sinnvoller sind nativ in MySQL integrierte Lösungen wie Galera, die dafür sorgen, dass sich die Datenbank selbst um die Replikation kümmert. Einen ausführlichen Artikel zum Thema Galera finden Interessierte in [2] .

Ganz ähnlich verhält es sich mit dem Messaging-Queue RabbitMQ: Auch dieser wäre über ein Shared-Storage als Fail-Over-Lösung leicht zu realisieren – hier ist diese Variante sogar die bessere Option als das HA-Konzept, welches RabbitMQ ab Werk mitbringt. Denn die sogenannten »Mirrored Queues« haben sich in der Vergangenheit immer wieder als fehleranfällig herausgestellt. Wer RabbitMQ im Rahmen eines Pacemaker-Setups hochverfügbar machen will, greift also lieber zu einer Lösung, bei der »rabbitmq-server« selbst zwischen den Hosts hin- und herschwenkt und »/var/lib/rabbitmq« auf einem gemeinsamen Speicher liegt. Wer mit mehr als zwei Knoten arbeitet und Ceph einsetzt, kann die RabbitMQ-Daten per CephFS nach »/var/lib/rabbitmq« mounten und schafft sich so nicht-skalierende Storages im Handstreich vom Hals.

Der restliche Aufwand eines HA-Setups besteht nahezu ausschließlich darin, die vorhandenen OpenStack-Komponenten in ein klassisches Pacemaker-Setup zu integrieren. Es würde an dieser Stelle den Rahmen sprengen, eine Konfiugration von Pacemaker von Grund auf zu erläutern – ein früherer Artikel des Autors dieses Textes steht unter [3] zur Verfügung und gibt Einblick.

Besonders hervorzuheben ist im Grunde nur die Tatsache, dass für nahezu alle OpenStack-Komponenten mittlerweile Ressource-Agents nach OCF-Standard zur Verfügung stehen. Diese lassen sich auf einem System wie folgt in den Ordner »/usr/lib/ocf/resource./openstack« entpacken:

cd /usr/lib/ocf/resource.d
mkdir openstack
cd openstack
wget -O- https://github.com/madkiss/openstack-resource-agents/archive/master.tar.gz |tar -xzv --strip-components=2 openstack-resource-agents-master/ocf
chmod -R a+rx *

Danach fördert ein »crm ra info ocf:openstack:nova-compute« exemplarisch den Hilfstext zum Resource-Agent für »nova-compute« zu Tage. Der Rest ist Schema F: Für die einzelnen OpenStack-Dienste sind jeweils Resourcen in die Pacemaker-Konfiguration zu integrieren, wobei Dienste, die zusammengehören, in Gruppen funktionieren. Damit alle wichtigen Dienste auf dem gleichen Host laufen, legen Colocation- und Order-Constraints der Verhältnis der Ressourcen zueinander fest. Erwähnenswert ist die Tatsache, dass es sich bei der Resource für den Quantum-Plugin-Openvswitch-Agent um eine Klon-Ressource handelt: Jener Dienst sollte auf allen OpenStack-Knoten laufen, auf denen grundsätzlich auch virtuelle Maschinen startbar sein sollen.