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:
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.
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:
nova-api
«
und macht einen Host, dem diese Puppet-Rolle zugewiesen ist, zum Computing-Knoten, der virtuelle Maschinen betreiben kann.cinder-volume
«
.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.