Openstack: Viele brauchen es, keiner versteht es - wir erklären es
Cloud Computing hat sich in der IT-Landschaft gegen alle Erwartungen bis heute als Hype erhalten. Und mittlerweile gelten zumindest im Umfeld freier Software Cloud Computing und Openstack(öffnet im neuen Fenster) fast schon als Synonyme: Tatsächlich ist kein anderes Floss-Projekt im Cloud-Dunstkreis auch nur annähernd so gefragt wie Openstack. Wer sich mit der Umsetzung einer privaten Cloud für sein Unternehmen beschäftigt, kommt um die Software praktisch nicht herum.
Das ist insbesondere bemerkenswert, als Openstack noch vor drei Jahren kaum mehr als ein Bastlerprojekt einiger Wissenschaftler war. Mittlerweile besteht die Umgebung aus etlichen Komponenten, die ineinandergreifen und Administratoren die eierlegende Wollmilchsau versprechen. Doch wer sich mit Openstack etwas näher beschäftigt, merkt schnell: Es ist aufgrund seiner Größe mittlerweile äußerst komplex. Und wer sich nicht schon tiefgreifend mit Clouds beschäftigt hat, kann kaum nachvollziehen, worum es bei der inzwischen sehr populären und riesigen Softwaresammlung eigentlich geht.
Für das Verständnis von Openstack hat es sich bewährt, sich in mehreren Schritten zu nähern. Von großer Bedeutung ist, die Idee hinter dem Begriff "Cloud Computing" überhaupt zu verstehen - was im ersten Moment offensichtlich klingt, ist nämlich schon gar nicht so einfach. Der zweite Schritt besteht dann darin, sich die Komponenten von Openstack genauer anzusehen und sich klarzumachen, welche davon welche Funktionen bieten. Der folgende Artikel soll Administratoren also folgende Frage beantworten: Was soll eigentlich mit Openstack erreicht werden?
Die Cloud an und für sich
Jeder Administrator kennt konventionelle IT-Einrichtungen, wie sie über Jahre hinweg beinahe überall zum Einsatz kamen. Klassische IT-Setups haben hinsichtlich ihrer Architektur eines gemeinsam: Es gibt Server mit festgelegten Funktionen, und die einmal bestimmten Funktionen verändern sich im Laufe des Lebens eines Servers auch nicht mehr.
Ein typisches Beispiel ist ein Monitoring-Server: Ein Stück Hardware ist dazu da, um einen einzigen Zweck zu erfüllen, und bekommt höchstens noch einen Zwilling als HA-Cluster. Datenbanken, Webserver, Applikationsserver, Archivserver - all diese Rollen sind typisch in alltäglichen Installationen. Fällt der Monitoring-Server aus, übernimmt im besten Falle dessen Cluster-Partner, und der Administrator hat die Möglichkeit, den ausgefallenen Rechner zu reparieren. Außerdem ist die gesamte Architektur einer Plattform auf diese spezifischen Eigenschaften der Systeme ausgerichtet: Auf den beteiligten Switches findet sich eine starre, im Switch abgelegte Zuordnung von VLANs. Neue Rechner kommen selten hinzu. Kurzum: Die ganze Infrastruktur ist in ihrer Anlage bereits sehr festgelegt.
Schlecht genutzte Ressourcen
Die Herausforderung klassischer IT-Umgebungen besteht daher oft darin: Wenn das Unternehmen wächst, das das Setup betreibt, muss auch die IT-Plattform mit ihm wachsen. Die konventionelle Methode macht das aber äußerst schwierig, denn neue Funktionen im Setup setzen neue Rechner voraus, und an der Installation neuer Rechner hängt eine ganze Reihe weiterer Abhängigkeiten wie die korrekte Einrichtung von Switches und die spezifische Installation der benötigten Softwarekomponenten.
All das erfordert Zeit und Arbeitskraft. Administratoren sind regelmäßig dieser eher eintönigen Arbeit ausgesetzt, statt sich um Innovation und höheren Komfort zu kümmern. Außerdem nutzen konventionelle Installationen ihre Ressourcen häufig schlecht: Ein moderner Server mit etlichen CPUs und viel Arbeitsspeicher ist mit einem einzelnen Webserverprozess kaum auszulasten, wenn das Setup nicht Java oder ähnlich rechenintensive Software nutzt.
Mehr als nur virtuelle Maschinen
Virtualisierung von Computing-Leistungen war der erste Schritt auf dem Weg von spezifischen Rechnern zu universell einsetzbaren. Sie verfolgt dabei einen einfachen Zweck - die Entkoppelung von Hardware - und sorgt dafür, dass eine IT-Infrastruktur deutlich flexibler wird. Ein Server dient nicht mehr nur einer Aufgabe, sondern erfüllt verschiedene Funktionen - abhängig davon, wie viele virtuelle Maschinen (VMs) auf jenem System beheimatet sind.
Typische Virtualisierungen mittels KVM oder VMware lösen aber nur einen Teil der typischen Probleme. Denn auch bei ihnen ist der Grad an Automatisierung eher gering: Zwar müssen Administratoren nicht mehr für jedes neue System auch neue Server in Racks schrauben, aber neue virtuelle Maschinen legen sie noch immer per Hand an. Ebenfalls manuell werden Netzwerke eingerichtet und persistenter Speicher kommissioniert, denn wer will schon seinen Kunden etwa den Zugriff auf vorhandene, zentrale SAN-Speicher erlauben?
Nicht wenige Administratoren unterstellen auch deshalb, dass sich Virtualisierung bis vor rund zwei Jahren ausschließlich auf die Computing-Dienstleistung bezogen habe, während klassische Elemente eines Setups wie Speicher und Storage gar nicht virtualisiert gewesen seien. Das hat sich inzwischen durch eine Erweiterung der Virtualisierung deutlich geändert.
Software-defined Everything
Jetzt verhält es sich in Cloud-Computing-Installationen so: Jeder Rechner ist eine Computing-Maschine und jede angebotene Dienstleistung ist virtualisiert. Das erstreckt sich sowohl auf den Computing-Teil als auch auf das Thema Storage und inzwischen auch auf die Netzwerkverwaltung. Anwender bedienen sich selbst, indem sie etwa nach Bedarf (on demand) neue, virtuelle Systeme selbst starten. Dazu stellt der Anbieter ihnen ein entsprechendes Portal zur Verfügung.
Damit das alles so funktioniert, müssen im Hintergrund etliche Programme arbeiten. Diese steuern die Virtualisierung des Computings, legen dynamische Netzwerke an, die ohnehin nur noch virtuell existieren und hängen an Kunden-VMs Speicher an, wenn sie benötigt werden. Braucht ein Kunde schnell neue Webserver, weil etwa sein Onlineshop im Fernsehen erwähnt worden ist, startet er die neuen virtuellen Maschinen einfach so, wie er sie gerade benötigt. Der Internetanbieter wird gewissermaßen degradiert: In einer typischen Cloud ist er nur noch derjenige, der die Infrastruktur zur Verfügung stellt.
In einer Cloud ist alles durch Software bestimmt (Software-defined), die entlang der vom Administrator festgelegten Richtlinien automatisch Dinge erledigt - willkommen bei Openstack!
Aus der Not geboren
Openstack war ursprünglich eine Kooperation des US-Webhosters Rackspace(öffnet im neuen Fenster) und der US-Raumfahrtbehörde Nasa. Die Nasa wollte durch die Komponente, die damals noch Nebula hieß, ein simples Problem lösen: Wissenschaftler benötigten regelmäßig Rechenkapazität und schafften dafür eigene Hardware an. Hatten sie jedoch ihre Experimente beendet, lag die Hardware brach und war für andere nicht direkt zu gebrauchen. Nebula sollte Abhilfe schaffen, indem es die Rechenkapazität an zentraler Stelle bündelte und den einzelnen Abteilungen die Möglichkeit gab, die benötigten Ressourcen bei Bedarf einfach abzurufen.
Seither hat das Projekt einen langen Weg hinter sich. Die Nasa ist heute nicht mehr involviert, dafür aber IT-Branchengrößen wie HP, IBM oder Intel. Die erste Version der Cloud-Umgebung mit dem Namen Openstack erschien 2010; Canonicals Gründer Mark Shuttleworth gab der Openstack-Entwicklung mächtig Auftrieb, indem er es zum Standard für Cloud Computing in Ubuntu(öffnet im neuen Fenster) 12.04 machte und damit erstmals kommerziellen Support für das Projekt anbot. Heute hat sich die Lösung fest etabliert, und alle großen Linux-Anbieter haben Openstack-Anwendungen im Portfolio.
Die vielen Komponenten von Openstack
Wenn sich Administratoren zum ersten Mal mit Openstack beschäftigen, fällt ihnen oft die große Anzahl verschiedener Komponenten auf. Tatsächlich ist der Umfang des Projekts in den vergangenen Jahren kontinuierlich gewachsen.
Noch immer lassen sich aber zwei Kategorien von Tools trennen: Auf der einen Seite stehen die Komponenten, die für den Betrieb einer Openstack-Cloud von elementarer Bedeutung sind. Hinzu kommt das schmückende Beiwerk, das Administratoren einsetzen, wenn sie einen konkreten Bedarf für eine Funktion haben. Eine Sonderrolle spielt die Komponente Swift(öffnet im neuen Fenster) : Sie stellt den Teil von Openstack dar, der von Rackspace stammt. In Openstack-Clouds bietet sie Object Storage an und ergänzt das "Computing on demand" so um "Storage on demand".
Keystone, Glance und Nova
Praktisch jede Openstack-Komponente hat ein eigenes Handbuch oder findet im Handbuch für Openstack-Administratoren(öffnet im neuen Fenster) ausführlich Erwähnung. Im Folgenden gibt der Artikel einen Überblick über die wichtigsten Komponenten und die Funktion, die sie in Openstack erfüllen.
Den Anfang macht zwangsläufig Keystone(öffnet im neuen Fenster) , denn es gilt als Wurzelkomponente. Keystone ist zuständig für Authentifizierung, damit sich Benutzer in der Cloud anmelden und dort beispielsweise VMs starten und beenden können. Keystone setzt auf Grundlage der Einstellungen des Administrators auch Richtlinien um: So entscheidet es darüber, welcher Nutzer in der Cloud welche Berechtigungen hat. Dabei lässt sich Keystone mit einer eigenen Datenbank sowie mit LDAP als Backend betreiben.
Glance(öffnet im neuen Fenster) liefert in Openstack-Clouds fertige Images von virtuellen Festplatten aus, die Kunden für ihre VMs verwenden können. Damit lösen Unternehmen gleich zwei Probleme: Einerseits kann nicht von jedem Kunden erwartet werden, dass er eine Linux-Installation selbst abwickeln kann oder die Zeit dafür aufbringen möchte. Andererseits muss der Anbieter so keine Administratoren abstellen, die für Kunden in neuen VMs regelmäßig Betriebssysteme installieren. Nicht mal fertige Images muss der Anbieter bereitstellen, denn die können sich Kunden auch selbst in Openstack hochladen.
Nova(öffnet im neuen Fenster) ist die Komponente, die sich um die Verwaltung der verfügbaren Computing-Ressourcen kümmert. Sie startet und stoppt virtuelle Maschinen und unterstützt heute eine Vielzahl verschiedener Hypervisor-Varianten: Neben den Klassikern wie KVM und Xen lässt sich etwa auch VMware problemlos anbinden. HyperV ist ebenfalls eine Option, falls Windows-Virtualisierung im Full-Stack-Prinzip notwendig ist.
Neutron konfiguriert SDN
Bei Openstack Neutron(öffnet im neuen Fenster) geht es um den Teil von Openstack, der das Software-defined Networking (SDN) konfiguriert. De facto setzt Openstack voraus, dass alle Hypervisoren in einer flachen Hierarchie an einen Switch angeschlossen sind, so dass VLANs und ähnliche Techniken keine Rolle mehr spielen. Die Trennung von Paketen und das Einrichten von virtuellen Netzen erledigt Neutron automatisch.
Dazu kann es im Hintergrund auf viele verschiedene SDN-Technologien zurückgreifen, etwa Open vSwitch oder das von Juniper angebotene Opencontrail. Ein richtig konfiguriertes Neutron lässt den Kunden einer Cloud-Umgebung seine virtuelle Netzwerkumgebung nach Gutdünken gestalten. Im Hintergrund stellt Neutron sicher, dass die unterschiedlichen Kundennetze nicht in Konflikt geraten und per automatisch konfiguriertem Gateway eine Internetverbindung haben. Auch die externe Erreichbarkeit von VMs wird durch Neutron gewährleistet.
Insgesamt ist Neutron die mit Abstand komplexeste Komponente innerhalb der Openstack-Infrastruktur, die Einsteiger regelmäßig zur Verzweiflung treiben kann.
Cinder, Ceilometer und Horizon
Persistenten Speicher für virtuelle Systeme besorgt in Openstack Cinder(öffnet im neuen Fenster) . Der Dienst hat seine Daseinsberechtigung: Ab Werk hat jede virtuelle Maschine nämlich nur flüchtigen Speicher, der nach dem Löschen einer VM wieder verschwindet. Cinder stellt Speicher bereit, der sich notfalls auch von einer VM trennen und in eine andere virtuelle Maschine einbinden lässt. Dazu schleift Cinder vorhandenen Speicher beispielsweise von Ceph oder einem existierenden SAN zu den VMs durch.
Ceilometer(öffnet im neuen Fenster) schreibt im Hintergrund mit, wer welche Dienstleistungen innerhalb der Cloud in Anspruch nimmt. So ermöglicht der Dienst eine reibungslose Kostenabrechnung. Horizon ist für Endanwender die wichtigste Komponente: Das Webinterface ermöglicht Kunden, sich VMs in Openstack schnell und per Mausklick zusammenzustellen.
Openstack ist längst nicht perfekt
Zusammen greifen die Openstack-Komponenten so ineinander, dass sich für Administratoren wie Nutzer eine umfassende Virtualisierungs- und Speicherlösung ergibt. Dabei sollte die schiere Summe der einzelnen Dienste allerdings nicht darüber hinwegtäuschen, dass auch in Openstack nicht alles perfekt ist.
Einerseits sind die einzelnen Openstack-Komponenten sehr unterschiedlich ausgereift: Die Kernkomponenten wie Nova und Neutron werden üblicherweise gut gewartet, jüngere Komponenten wie Sahara erfüllen hingegen die Erwartungen oft nur zum Teil.
Andererseits kann Openstack seinem universellen Anspruch nicht immer so gerecht werden, wie die Entwickler es vielleicht gerne wollen. Die große Zahl möglicher Kombinationen macht es schlicht unmöglich, Designentscheidungen so zu treffen, dass sie für jeden möglichen Anwender funktionieren. Open vSwitch und Openflow sind etwa der Standard für SDN in Openstack, funktionieren für größere Netze aber nicht zuverlässig. Unternehmen sehen sich deshalb regelmäßig mit der Notwendigkeit konfrontiert, einzelne Komponenten im Openstack-System durch andere, zum Teil auch kommerzielle Lösungen zu ersetzen. Die Zeit wird zeigen, ob dieses Modell funktioniert.
Die Community ist wichtig
Die Community ist für Openstack traditionell sehr wichtig. Zwar spielt mittlerweile auch eine Reihe von großen Unternehmen eine Rolle, die ihre Interessen durchsetzen wollen. Im Kern ist Openstack aber ein von der Floss-Community getragenes Projekt. Das wird schon dadurch deutlich, dass die Openstack Foundation die Schirmherrschaft über die Wartung der Software übernommen hat und tatsächlich eine Stiftung nach US-Recht ist.
Die einzelnen Openstack-Teile sind in ihrer Entwicklung in eigene Projekte aufgeteilt; jedem Projekt steht ein gewählter Project Technical Lead (PTL) vor. Die wichtigen Entscheidungen werden öffentlich diskutiert, zum Beispiel bei den Openstack-Entwicklertreffen ("Openstack Developers Summit"), die halbjährlich stattfinden. Auch die Dokumentation kommt ausschließlich aus der Community und ist mittlerweile qualitativ sehr hochwertig.
Fazit: Big Business
Openstack gibt Admins all die Werkzeuge an die Hand, die sie für den Betrieb einer Cloud-Computing-Umgebung benötigen. Im Hintergrund stützen namhafte Unternehmen die Bestrebungen des Projekts, das nicht zuletzt deshalb heute als sehr komplexes Gebilde daherkommt. Fakt ist, dass das Einarbeiten in die Openstack-Toolsuite viel Zeit kostet - die Investition lohnt sich für Administratoren am Ende aber durchaus.
Openstack und die meisten seiner Komponenten stehen unter der Apache-Lizenz 2.0. Aktuell ist Version 2014.2 alias Juno vom 14. Oktober 2014. Die nächste Version 2015.1 alias Kilo soll am 30. April 2015 veröffentlicht werden.
Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Syseleven(öffnet im neuen Fenster) . Er beschäftigt sich dort intensiv mit den Themen Openstack, Distributed Storage und Puppet und hat kürzlich das iX-Seminar zu Ceph gehalten, das gern zusammen mit OpenStack genutzt wird. Er schreibt regelmäßig für verschiedene Publikationen. In seiner Freizeit pflegt er Pacemaker für Debian.