OpenStack richtig nutzen: Tipps für den Betrieb ohne Abhängigkeiten

Wirft man einen Blick auf die OpenStack-Architektur, so erkennt man bekannte Elemente, wie man sie von Cloud-Anbietern und Virtualisierungslösungen kennt. Diese sind allerdings bewusst allgemeiner gehalten. So gibt es beispielsweise nicht die Bezeichnung “virtuelle Festplatte”, “iSCSI Lun” oder “Elastic Block Store”, sondern einfach nur Volume.

Mit einem Volume wird Block-Speicher bereitgestellt. Ob es sich dabei um Speicher aus einem SAN, eine Disk-Image-Datei oder sogar um eine physische Festplatte handelt, ist aus der Sicht des OpenStack-API zunächst nicht relevant. Die Technologie dahinter ist transparent. Auf diese Weise erreicht man, dass die eigentlichen Ressourcen sowohl in der privaten oder in der öffentlichen Cloud liegen können.

Solche Anwendungsfälle lassen sich zum Beispiel durch Einsatz eines globalen Namespace aus der Lösung Red Hat Storage lösen. So lassen sich Storage Systeme unabhängig von dedizierter Storage Hardware skalieren. Hintergrund der heutigen OpenStack Implementation ist der Focus auf Software-Basierte Dienste wie Netzwerk Dienste und Storage Dienste.

Natürlich muss im Endeffekt ein Durchgriff möglich sein. So muss der Anwender die Kontrolle darüber haben, welche I/O-Leistung und welche Ausfallsicherheit ein Volume bieten kann. Wichtig ist aber zunächst, dass der Nutzer mit ein und demselben API Ressourcen wie ein Volume sowohl in seinem Inhouse-Virtualisierungssystem als auch bei einem öffentlichen Cloud-Anbieter anfordern kann.

Wer bisher nur mit Virtualisierungslösungen wie VMware vertraut ist, findet als neues Element den Object Store vor. Dabei handelt es sich um einen globalen Speicher, der von allen Nutzern der Hybrid Cloud verwendet werden kann. Die Nutzung ist nur durch Zugangsberechtigungen eingeschränkt. Angesprochen wird dieser Speicher über ein HTTP- oder HTTPS-API, das den REST-Prinzipien folgt. Um einen schnellen Zugang zu gewährleisten, kann der Object Store redundant an mehreren Standorten gehalten werden, was gleichzeitig eine Ausfallsicherheit gewährleistet.

Ein Volume unterscheidet sich davon, dass es immer in unmittelbarer Nähe der Computing Hardware betrieben wird, damit die Geschwindigkeit der von lokalen Festplatte entspricht. Meist wird ein Volume auch nur von einer Recheninstanz benutzt, während auf Dateien im Object Store viele Nutzer gleichzeitig zugreifen können.

Ein Image schließlich ist ein bootbares Betriebssystem, das auf einer Computing-Ressource gestartet werden kann, ohne dass dabei bereits fixe Computing-Ressourcen wie Anzahl CPUs oder Hauptspeichermenge festgelegt sind. Die Boot-Festplatte existiert nicht, wie man vermuten könnte als Volume, sondern im Object Store. Erst wenn es einer Instanz zugeordnet wird, wird es vor dem Start auf ein Volume kopiert. Auf diese Weise ist ein Image für alle Nutzer verfügbar, sofern die Zugangsberechtigung das zulässt.

Der Schlüssel für eine erfolgreiche Implementierung von OpenStack ist das richtige Anlegen von Images und die Konfiguration der Applikation die auf der Cloud laufen soll. Die Philosophie von OpenStack ist, dass Anwendungen horizontal skalieren.. Das heißt dass sich Anwendungen physischer und virtueller Hardware und zwischen privater Cloud und öffentlichen Cloud-Anbietern bewegen lassen ohne dabei Abhängigkeiten zu spezieller Hardware zu schaffen. Zum Beispiel ist die Hochverfügbarkeit direkt in der Applikation und in den Services der Applikation zu lösen, anstatt sich auf spezielle Infrastruktur Dienste wie Cluster Lösungen zu verlassen. Als Mehrwert erhält man dafür leicht skalierende Anwendungen, die sich mit den Anforderungen der Nutzer herauf und herunter skalieren lassen.

Das richtige Betriebssystem wählen

Die Lösung für dieses Problem beginnt bei der Auswahl des Betriebssystems. So sollte man unter keinen Umständen ein OS verwenden, das von einem bestimmten Cloud-Anbieter angeboten wird, etwa Amazon-Linux. Stattdessen sollte man ein Betriebssystem suchen, das vollwertige OpenStack-Unterstützung bietet und dessen Images bei verschiedenen Cloud-Anbietern lauffähig sind. Red Hat Linux (RHEL) ist von Grund auf so gestaltet, dass sich OpenStack-Images erstellen lassen, die notwendige Treiber für virtuelle oder physische Hardware nach dem Booten laden und universell lauffähig sind.

Ein weiterer Faktor ist die Wartbarkeit der Betriebssysteme. In Closed-Cloud-Systemen findet man Anwendungen häufig als Appliance-Images realisiert. Das ist praktisch, weil die Images sofort nach dem Booten das tun, was man von Ihnen erwartet. Allerdings muss sich der Betreiber der Anwendung auch selbst um die Wartung des Betriebssystems kümmern.

Mit OpenStack gibt es bessere Möglichkeiten. Es empfiehlt sich nur wenige Basis-Images zu konfigurieren, die zentral immer mit Sicherheitsaktualisierungen auf dem aktuellen Stand gehalten werden. Die eigentliche Anwendung sollte nach Möglichkeit immer aus dem Object Store geholt werden. Ein Skript kann dann notwendige Anpassungen in den Konfigurationsdateien des Betriebssystems vornehmen und erforderliche Komponenten nachladen. So lässt sich automatisches Release-Management einer Anwendung am einfachsten realisieren.

Wer vor allem proprietäre Virtualisierungssysteme kennt, ist es gewohnt, für die Datenspeicherung vor allem virtuelle Festplattendateien zu nutzen. In einer OpenStack-Implementierung sollte man davon nach Möglichkeit absehen. Skalierung sollte nach Möglichkeit immer durch weitere Computingressourcen (virtuelle oder reale Server) erreicht werden und nicht durch Hinzufügen weiterer virtueller CPUs oder virtuellem Hauptspeicher. Das heißt, dass Volumes so weit wie möglich als temporärer oder instanzlokaler Speicher betrachtet werden sollten. Alles was persistent gespeichert werden soll, gehört in den Object Store, wo es allen Instanzen zur Verfügung steht.

Fazit

Wer die Möglichkeit hat, sollte beim Design seiner Anwendungen darauf achten, dass diese auf eine moderne offene Hybrid-Cloud ausgelegt sind. Dazu sollte man sich eingehend mit der Architektur OpenStack vertraut machen und die Chancen nutzen, sich unabhängig von einer bestimmten Virtualisierungslösung oder einem bestimmten Cloud-Anbieter machen.

Wer zunächst noch Legacy-Anwendungen zu betreiben hat, braucht sich deswegen jedoch keine Sorgen machen. Durch Einsatz einer Cloud Management Platform wie CloudForms lassen sich Migrationen zeitlich flexibel gestalten, und der Spagat zwischen älteren Anwendungen und neuen häufig aktualisierten Anwendungen kann gehalten werden.