Rollen und Dienste in OpenStack

Wer in den letzten Monaten regelmäßig die Berichterstattung dieser Zeitschrift zum Thema OpenStack verfolgt hat, der weiß: OpenStack ist nicht ein großes Programm sondern eine Sammlung, die aus verschiedenen Komponenten besteht. Dieser Umstand ist von elementarer Bedeutung, um die Funktionsweise von Kickstack oder Packstack zu verstehen. Denn um OpenStack sinnvoll zu deployen, ist es notwendig, in Rollen zu denken und nicht in einzelnen Komponenten.

Die folgende Gegenüberstellung macht das deutlich – aktuell setzt sich OpenStack aus neun Kernkomponenten zusammen:

• Keystone, der Autentifizierungsdienst, der die Benutzeranmeldung und auch die Anmeldung der Dienste untereinander ermöglicht.
• Horizon, das Dashboard, das erst in Kombination mit einem Webserver sinnvoll nutzbar ist.
• Nova, die Computing-Komponente, die sich um das Starten, Stoppen und das Steuern virtueller Maschinen kümmert.
• Cinder, der Block-Storage-Dienst, der virtuelle Maschinen innerhalb von OpenStack mit virtuellem, persistenten Block-Speicher versorgt.
• Glance, der Image-Dienst, der Abbilder von Betriebssystemen sowohl verwaltet als auch je nach Bedarf an die Hypervisor-Knoten ausliefern kann.
• Neutron, der Netzwerkdienst, der sämtliche Aufgaben rund um Software Defined Networking (SDN) in OpenStack erledigt.
• Ceilometer, die Metering-Komponente, die mit dem Release Havana Einzug gefunden hat und das detaillierte Aufzeichnen von Verkehrsdaten ermöglicht.
• Heat, das für Orchestrierung innerhalb einer OpenStack-Cloud sehr nützlich ist und Admins viel Arbeit abnimmt.
• Swift, die Object-Store-Komponente, die in OpenStack-Clouds einen mit Amazon S3 vergleichbaren Speicher-Dienst anbietet.

Der Haken an der Sache ist, dass selbst die genannten Komponenten keine einzelnen Programme sind, sondern sich wiederum in mehrere Module aufteilen. Praktisch jeder Dienst in OpenStack hat eine eigene API-Komponente, die eine Restful-API exponiert und so dafür sorgt, dass der Dienst überhaupt erst per HTTP-Protokoll steuerbar wird. Aus technischer Sicht kann es durchaus sinnvoll sein, diese APIs auch in das Internet zu exponieren. So macht es beispielsweise Rackspace mit der eigenen OpenStack-Cloud. Dann kommt es allerdings zu einem Setup, bei dem die einzelnen Module der Komponenten auf verschiedene Systeme aufgeteilt sind. Denn dort, wo die API-Komponenten laufen, laufen nicht zwangsläufig oder sinnvollerweise auch die anderen Komponenten.

Eine weitere Fraktionierung findet statt, wenn einzelne Teile einer OpenStack-Komponente zwangsläufig auf mehrere Systeme aufzuteilen sind. Der Dienst »cinder-volume« beispielsweise ist die Schnittstelle, die VMs auf Hypervisor-Systemen mit dem zugewiesenen persistenten Speicher verbindet. Der Dienst wird also auf den Hosts laufen, wo der Platz auf den Platten zur Verfügung steht. »cinder-scheduler« wird meist auf einem anderen Host laufen – die Komponente koordiniert den Zugriff auf mehrere Storage-Backends, wenn diese konfiguriert sind. Und dann gibt es noch die Dienste, die innerhalb einer OpenStack-Installation mehrere Male vorhanden sein müssen: »nova-compute« , das im Auftrag von Nova virtuelle Maschinen startet, ist dafür ein gutes Beispiel.

Rollen statt Programme

Offensichtlich wäre es nicht besonders sinnvoll, die Dienste, die zu OpenStack gehören, als einzelne Gruppen auf verschiedene Rechner zu verteilen. Kickstack nutzt deshalb einen anderen Ansatz und geht davon aus, dass sich innerhalb einer OpenStack-Installation quasi ab Werk eine Vielzahl verschiedener Rollen definieren lässt. Jede Rolle ist durch eine spezifische Kombination aus Diensten gekennzeichnet. Es empfiehlt sich, das Gruppenschema nachzuvollziehen, bevor die Arbeit mit Kickstack losgeht, denn das Rollensystem ist in Kickstack zentral. Die folgenden Rollen kennt Kickstack ab Werk:

• Infrastructure Node: Dieses System betreibt die Hilfsdienste für OpenStack: RabbitMQ sowie MySQL.
• API Node: Auf diesem Knoten laufen zentral die API-Dienste sämtlicher Komponenten.
• Network Node: Der Netzwerkknoten betreibt die Neutron-Teile, die für die DHCP- und L3-Verbindungen verantwortlich sind und VMs so den Zugriff auf die Außenwelt ermöglichen.
• Auth Node: Dieser Knoten betreibt Keystone, den ID-Dienst, der quasi so etwas wie der Wurzel-Service in OpenStack ist – ohne ihn sind die anderen Komponenten nicht sinnvoll einzusetzen.
• Compute Node: Enthält im Wesentlichen »nova-api« und macht einen Host, dem diese Puppet-Rolle zugewiesen ist, zum Computing-Knoten, der virtuelle Maschinen betreiben kann.
• Dashboard Node: Der Dashboard-Knoten betreibt einen Apache mit Dashboard. Er ist von den API-Diensten getrennt.
• Metering Node: Der Knoten betreibt jene Dienste, die direkt zur Metering-Applikation Cinder gehören (ausgenommen ist die API).
• Orchestration Node: Die Rolle enthält alle benötigten Dienste für OpenStack Heat mit Ausnahme der API.
• Controller Node: Diese Rolle umfasst verschiedene Dienste für den internen OpenStack-Gebrauch, die sich aus Teilen verschiedener Services zusammensetzen; sie ist üblicherweise auf dem gleichen Host beheimatet, wie die Infrastructure-Rolle.
• Storage Node: Enthält die Komponenten, die notwendig sind, damit ein Host seinen lokalen Speicher für Cinder zur Verfügung stellen kann, im Wesentlichen also »cinder-volume« .
• Client Node: Die Besonderheit dieser Rolle ist, dass sie sämtliche Kommandozeilen-Clients für die verschiedenen OpenStack-Dienste installiert, also die Binaries wie »glance« und »nova« . OpenStack selbst nutzt im Hintergrund ohnehin die Python-Bibliotheken. Die Client-Rolle lässt sich sinnvoll auf dem Knoten anwenden, der auch die API-Rolle inne hat.