Meine zwei Gedanken zu OpenStack Havana

In der vergangenen Woche konnte ich ein Test-Setup mit OpenStack Havana (für CentOS) von Grund auf einrichten. Wir haben uns erst einmal auf die Verwaltung der virtuellen Maschinene mittels KVM/libvirt konzentriert und weitere Komponenten wie Quantum erst einmal außen vor gelassen. Zusätzlich haben wir zur Verwaltung des Block Storage cinder aufgsetzt.

In der ersten Installation haben wir bewusst auf Hilfen wie DevStack verzichtet. Wir wollten auch etwas unter die Haube schauen. Ich finde es bemerkenswert, dass die Installation quasi nur aus Copy and Paste aus der OpenStack Dokumentation besteht.

Nachdem der Identity-Service keystone aufgesetzt, der Image-Service glance , der Block Storage cinder , das Dashboard horizon und die Compute-Nodes nova in relativen Standardkonfigurationen eingerichtet waren, haben wir uns an unsere Testfälle gesetzt. Zur Einrichtung der Compute-Nodes ist noch zu sagen, dass alle Zugriff auf die MySQL-Datenbank der Master-Node benötigen.

Das Anlegen und Verwalten der Images geht über die wirklich guten command line tools leicht von der Hand. Daraus Images zu starten ist ebenfalls einfach. Wenn man erst einmal vernünftige Images erstellt hat. Zu vergleichszwecken haben wir Gentoo-Images erzeugt, die so nah an unseren aktuellen VMs liegen wie möglich. Beim Erstellen der Images ist darauf zu achten, einen dhcp-client zu liefern und sich beim hochfahren eine dynamische IP zu holen. Um die Verwaltung kümmert sich OpenStack. Aus Images schreibbare Volumes zu erzeugen gelingt ähnlich einfach wie das Bereitstellen von Images.

Bis hier her hat alles exakt nach Dokumentation funktioniert. Hier noch einmal ein großes Lob für.

Wir spielten ein bisschen mit hoch und runter der VMs rum und waren ein bisschen vom JavaScript-VNC-Interface angetan. Das erste Problem auf das wir gestoßen sind, war die nicht funktionierende Migration. Doch auch hier gab war die Lösung durch Exceptions im Log einfach zu finden. Die Benutzer nova jeder Compute-Node müssen ohne Passwort (ssh-keys) auf die anderen Compute-Nodes zugreifen dürfen. Dies ist vor allem für das Kopieren der Daten nötig. Leider kann man bei der Migration einer VM keine Ziel-Node angeben. Die Auswahl obliegt OpenStack. Es gibt aber die (von uns ungetestete) Möglichkeit mittels Filter in die Auswahl der Ziel-Node einzugreifen. Ich verstehe hier ja durchaus den Sinn. Den Endanwender soll die zugrunde liegende Hardware nicht interessieren. Doch zurück zur Migration. Diese Erfolgt im Falle von laufenden Images immer einhergehend mit einem Neustart der VM. Die in libvirt unterstützte Live-Migration wird von OpenStack (noch) nicht unterstützt. Verwendet man an Stelle von Images aber Volumes, ist mit ein wenig Konfigurationsarbeit auch eine Live-Migration möglich. Wenn in beiden Migrationsfällen die Migration auf die Ziel-Node fehlschlägt, wird der nächste probiert.

OpenStack Havana fühlt sich erstaunlich fertig an und arbeitet an den meisten Stellen wie ich es erwartet habe. Kommt es mal zu Fehlern, lassen sich diese in den Logs finden. Wie das aber leider bei Exceptions im Log so oft der Fall ist, ist häufig nicht klar was genau passiert ist. Oft fehlen daher Quell- und Ziel-Node, was das Debugging erschwert. Schön finde ich die Möglichkeit an bestimmten Stellen eigenen Code einhängen zu können. Siehe Filter oder Driver.

Was mir persönlich ganz gut Gefällt ist die Art und Weise wie OpenStack arbeitet. Es dient als Verwaltungs-Layer und verwendet unter der Haube viele Komponenten die es schon lange gibt und die dementsprechend reif sind. z.B. dnsmasq als dhcp-Server, iSCSI mittels tgt für den Block Storage, u.a. libvirt als Hypervisor. Wenn man im OpenStack mal eine Instanz verloren hat, bedeutet das so keineswegs, dass man nicht mehr dran kommt.

Besonders positiv möchte ich die command line tools erwähnen. Sie kommen alle mit bash_completion daher und bedienen sich intuitiv.