Der Image-Automat Glance

Keine Wolke ohne Images von Betriebssystemen: Damit Benutzer schnell und ohne großes Vorwissen virtuelle Maschinen starten können, haben Admins ihnen entsprechende Images zur Verfügung zu stellen – sonst wird es nichts mit der Wolke. Glance übernimmt in OpenStack genau diese Aufgabe. De facto besteht der Dienst aus zwei einzelnen Komponenten: Der API ( »glance-api« ) sowie der Registry ( »glance-registry« ). Erstere bietet ein Interface für alle anderen OpenStack-Dienste, zweitere kümmert sich um die Pflege der Datenbank von Glance selbst.

Den Anfang macht die Konfigurationsdatei von »glance-api« . Die liegt in »/etc/glance/glance-api.conf« . An ihrem Ende findet sich ein Eintrag namens »[keystone_authtoken]« . Ein solcher oder ähnlicher Eintrag begegnet OpenStack-Admins häufig – jeder Dienst muss sich, bevor er mit Keystone sprechen darf, selbst erstmal bei ihm anmelden. Die zitierte Stelle in »glance-api.conf« ist der richtige Ort, um dafür die Credentials zu definieren. Der Vorteil: Die Konfiguration ist für fast alle OpenStack-Dienste ähnlich aus oder sogar identisch.

Für den weiteren Verlauf des Artikels gilt deshalb: »auth_host« ist stets »192.168.122.111 « , »admin_tenant_name« ist stets »service« und »admin_password« ist stets »geheim« . »admin_user« ist stets der Name des OpenStack-Dienstes, der sich an Keystone anmelden soll, also »glance« im vorliegenden Fall, » nova« für OpenStack Nova, »quantum« für OpenStack Quantum und so weiter. Einige Dienste fragen nach einer »auth_url« – diese ist im Rahmen dieses Artikels stets »http://192.168.122.111:5000/v2.0/« . Wenn im lokalen Setup andere IPs zum Einsatz kommen, so sind diese freilich für »auth_host« und »auth_url« zu nutzen. Damit steht fest, was in »glance-api.conf« für die jeweiligen Werte bei »[keystone_authtoken]« einzusetzen ist.

Wie zuvor »keystone.conf« findet sich auch in »glance-api.conf« die SQL-Anweisung in einer Zeile, die mit »sql_connection« beginnt. Nach der Glance-Installation steht dort eine SQLite-Datenbank, im konkreten Beispiel ist die SQL-Verbindung diese:

sql_connection = mysql://glancedbadmin:ohC3teiv@192.168.122.111/glance

Weiter unten im File findet sich eine Sektion namens »[paste_deploy]« . Hier möchte Glance wissen, welche Authentifizierungs-Methode es verwenden soll und wo es nähere Einstellungen dazu findet. Für »glance-api.conf« lautet der korrekte Eintrag bei »config_file =« in dem Abschnitt folglich »/etc/glance/glance-api-paste.ini« und bei »flavor=« führt der Wert » keystone« zum gewünschten Resultat. Nach diesen Änderungen ist die Datei für den Einsatz bereit. Analog zu ihr ist »/etc/glance/glance-registry.conf« zu bearbeiten: Die Werte für die verschiedenen »auth_« -Variablen sind dieselben wie für »glance-api« , auch die Datenbankverbindung sowie der Text bei »flavor=« sind identisch. Lediglich bei »config_file« unterscheidet sich der Eintrag, denn für »glance-registry.conf« ist dieser entsprechend »/etc/glance/glance-registry-paste.ini« . Damit ist die Konfiguration der Glance-Komponenten fertig.

Höchste Zeit also, die Tabellen in den Glance-Datenbanken anzulegen. Dabei hilft »glance-manage« :

glance-manage version_control 0
glance-manage db_sync

Es folgt ein Neustart der beiden Glance-Dienste mittels »service glance-api restart && service glance-registry restart« .

Nun ist der Image-Store bereit für das erste Test-Image. Glücklicherweise unterstützt der Glance-Client den direkten Download von Images aus dem Netz. Um ein Ubuntu-12.04-Cloud-Image in den Image-Store aufzunehmen, genügt daher der folgende Befehl aus Listing 3 .

Im Anschluss sollte »glance image-list« das entsprechende Image auch anzeigen – sobald im Feld »Status« der Wert »ACTIVE« aufscheint, ist das Image bereit für die Nutzung.

Quantum: Die Netzwerk-Hydra

Zweifellos die aufwendigste Konfiugurationsarbeit erwartet Admins, wenn es um den Netzwerkdienst Quantum geht. Denn damit dieser funktioniert, sind auf allen drei Hosts Dienste einzurichten. Den Anfang macht Alice: Hier muss der eigentliche Quantum-Server samt entsprechendem Plugin laufen. Dieses Beispiel nutzt als Plugin OpenVSwitch, sodass der Quantum-Server selbst wie auch das OpenVSwitch-Plugin zu konfigurieren sind ( Abbildung 3 ).

Abbildung 3: Auf der Kommandozeile verrät der Befehl ovs-vsctl show, was Quantum in der OpenVSwitch-Konfiguration verändert.

Nach der Installation ist zunächst »/etc/quantum/api-paste.ini« an der Reihe. Im Abschnitt »[filter:authtoken]« finden sich die schon von Glance her bekannten Einträge, die durch die Werte für dieses Beispielsetup zu ersetzen sind. Als »auth_port« muss zwingend »35357« in der Datei stehen. Dann folgt die Konfiguration des OVS-Plugins: Dessen Konfigurationsdatei ist » /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini« . Darin findet sich eine Zeile, die mit »sql_connection« anfängt und die Quantum verrät, wie es auf seine eigene MySQL-Datenbank zugreift. Hier lautet der korrekte Eintrag »sql_connection = mysql://quantumdbadmin:wozohB8g@192.168.122.111/quantum« . Weiter unten sind in der Datei hinter der Zeile »# Example: bridge_mappings = physnet1:br-eth1« folgende drei Zeilen einzutragen:

tenant_network_type = gre
tunnel_id_ranges = 1:1000
enable_tunneling = True

Der Einfachheit halber empfiehlt es sich, diese Datei nun zu speichern und an die gleiche Stelle auf »bob« zu kopieren (für die Hosts Bob und Charlie werden später allerdings noch Veränderungen notwendig). Auch »/etc/quantum/api-paste.ini« lässt sich eins zu eins auf den beiden Knoten übernehmen.

Auf Alice lässt sich der Quantum-Server ( Abbildung 4 ) samt OpenVSwitch-Plugin nun schon starten: »service quantum-server start« erledigt das.

Abbildung 4: Auf dem Cloud Controller läuft in einer Default-Installation nur der eigentliche Quantum-Server.

Auf Bob läuft kein Quantum-Server, nachdem es sich allerdings im Beispiel um den Computing-Knoten handelt, braucht Bob zwingend den » quantum-plugin-openvswitch-agent« , den Agent, der zum OpenVSwitch-Plugin gehört. Über ihn erhält Bob später sämtliche relevanten Netzwerkinfos von Alice ( »quantum-server« ) und Charlie ( »DHCP« - und »L3« -Plugin), um sein eigenes Netzwerk richtig zu konfigurieren. Das Paket für diesen Agent sollte bereits vorhanden sein, sodass jetzt noch die Agent-Konfiguration ansteht. Die findet sich in » /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini« . Hinter der Zeile »# Example: bridge_mappings = physnet1:br-eth1« sorgt der folgende Absatz für die korrekte Funktion des Agents auf Bob:

tenant_network_type = gre
tunnel_id_ranges = 1:1000
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 192.168.133.112
enable_tunneling = True

Mit diesen Zeilen startet der OpenVSwitch-Agent automatisch einen Tunnel zwischen Bob und dem Netzwerk-Knoten Charlie, über den die beiden Hosts dann Informationen austauschen.

Wenn die Änderungen an »ovs_quantum_plugin.ini« vollzogen sind, sollte ein Duplikat der Datei von Bob am gleichen Ort auf Charlie landen, wobei für Charlie die IP-Adresse »192.168.133.112« durch »192.168.133.113« zu ersetzen ist. Auf beiden Hosts – Bob und Charlie – ist zusätzlich in » /etc/quantum/quantum.conf« noch »# rabbit_host« zu entkommentieren und mit dem Wert »192.168.122.111« zu versehen – nur so wissen die Agents auf Bob und Charlie, wie sie den RabbitMQ-Server auf Alice erreichen.

Schließlich braucht Charlie noch spezifische Veränderungen, weil auf ihm auch der »quantum-l3-agent« und der »quantum-dhcp-agent« laufen. Die beiden Dienste versorgen VMs im Setup später einerseits mit DHCP-Adressen, und andererseits stellen sie per »iptables« die Möglichkeit her, die VMs über öffentliche IP-Adressen zu erreichen (im Beispiel 192.168.144.0/25). Die gute Nachricht ist: Der DHCP-Agent braucht überhaupt keine Veränderungen an der Konfiguration – der L3-Agent hingegen schon: Seine Konfigurationsdatei ist »/etc/quantum/l3_agent.ini« .