Benutzerverwaltung: Keystone

Da wäre zunächst die Benutzerverwaltung, die der Cloud zugrunde liegt. Der Punkt klingt banal, ist es aber nicht. Denn: Damit Kunden sich innerhalb einer Cloud-Computing-Umgebung ihre Dienste zurechtlegen können, muss jene zwingend über ein System zur Benutzerverwaltung verfügen. In OpenStack sorgt Keystone [1] dafür, dass Benutzer sich mit ihren Account-Daten einloggen können.

Keystone implementiert aber nicht nur ein simples System auf der Grundlage von Benutzern und Passwörtern, sondern es bietet ein feingranulares Schema zum Zuteilen von Berechtigungen: An oberster Stelle stehen die Tenants, die in der Cloud-Umgebung typischerweise die Ebene der Unternehmen darstellen, die Kunden des Cloud-Anbieters sind. Dann gibt es die Benutzer, die jeweils Mitglied eines Tenants sind und dort durchaus unterschiedliche Rechte haben können. Der Chef eines Unternehmens wird beispielsweise die Permissions haben, um VMs zu starten oder zu stoppen oder neue Admins zu ernennen, während der einfache Sysadmin nur virtuelle Systeme starten oder stoppen darf. Über Keystone lässt sich solch ein Benutzerschema nachbilden und zwar für beliebig viele Tenants.

Auch für die interne Kommunikation mit den anderen OpenStack-Diensten ist Keystone verantwortlich; damit ein OpenStack-Dienst mit einem anderen reden darf, muss er sich vorher ebenfalls über Keystone authentifizieren. Dafür gibt es die Keystone-Middleware, eine Art Python-Plugin, das jede interne oder externe Komponente nutzen kann, um die Keystone-Authentifizierung sicher abzuwickeln. Apropos Python: Keystone ist – wie alle anderen OpenStack-Dienste auch – zu 100 Prozent in Python verfasst.

Und dann wären da noch die Endpunkte: Damit die Cloud tut, was sie soll, findet zwischen den einzelnen Komponenten von OpenStack jede Menge Kommunikation statt. Weil Clouds aber skalieren sollen, wäre es sehr unpraktisch, für diese Kommunikation statische IPs zu nutzen. Keystone pflegt deshalb eine Art Telefonbuch innerhalb der OpenStack-Cloud: Das Endpunkte-Verzeichnis listet auf, welcher OpenStack-Dienst gerade wo zu erreichen ist. Will ein Dienst mit einem anderen reden, befragt er also ganz einfach nur Keystone und erhält im Handumdrehen die gewünschte Information. Ändert sich die Adresse eines Dienstes später, ändert der Admin einfach nur die Adresse in Keystone, nicht aber in allen Konfigurationsdateien für jeden Dienst auf jedem Host.

Image-Verwaltung: Glance

Cloud-Angebote, die Kunden per Web-Interface nutzen sollen, müssen eine zentrale Anforderung erfüllen: Sie müssen niederschwellig sein. Der Kunde muss per Mausklick eine neue VM starten können, sonst bringt ihm die ganze Umgebung nichts. Daraus ergibt sich zwangsläufig, dass es dem Kunden kaum zuzumuten ist, sich um die Installation eines Betriebssystems innerhalb der VM händisch zu kümmern – oft genug wird er gar nicht das notwendige Wissen mitbringen, das er braucht, um die VM zu installieren. Der Admin hat naturgemäß kein Interesse daran, dem Kunden die Aufgabe der manuellen VM-Installation abzunehmen, denn dann wäre der Automatisierungseffekt ja dahin.

Glance [2] schafft eine Lösung für das Problem: In Glance legt der Administrator einer Cloud-Umgebung fertige Images an, die der Benutzer dann bei Bedarf einfach für seine neue VM auswählt. Für den Admin fällt daher nur einmal Arbeit an, nämlich beim Einrichten des Images, und der Kunde hat mit dem Thema Betriebssystem überhaupt keine Scherereien mehr.

Unter der Haube besteht Glance aus zwei DashboardDiensten, einer API und einem Tool, das sich um die Verwaltung der Images kümmert ( Abbildung 1 ). Diese Einteilung findet sich in abgewandelter Form in OpenStack häufig. Auch Keystone ist ja im Grunde nichts anderes als eine HTTP-basierte API, die per ReSTful-Prinzip anzusprechen ist.

Abbildung 1: Über das Dashboard erhalten Nutzer Zugriff auf die Images, die in Glance gespeichert sind – per Mausklick wählen sie eines aus.

Glance gehört zu den eher unauffälligen OpenStack-Komponenten, und Admins werden nach der ersten Installation mit dem Dienst nur noch selten etwas zu tun haben. Er unterstützt diverse Image-Formate, darunter natürlich das KVM-eigene Format Qcow2, VMware-VMDK-Images, aber auch Microsofts VDI-Format aus Hyper-V. Außerdem lassen sich vorhandene Systeme relativ leicht in Glance-kompatible Images (Raw Images) verwandeln.

Seinen großen Auftritt hat Glance stets dann, wenn es gilt, eine neue VM zu starten: Dann kopiert der Dienst nämlich das Image für diese VM auf den Hypervisor-Host, auf dem die VM lokal laufen soll. Für Admins ergibt sich daraus freilich, dass in Glance abgelegte Images nicht zu groß sein sollten, sonst dauert es eine gefühlte Ewigkeit, bis das Image auf dem Hypervisor ankommt. Übrigens: Viele Distributionen bieten fertige Glance-Images an: Ubuntu kommt beispielsweise mit seinen UEC-Images [3] daher.