Externe Netze anlegen

Eingangs sind wie gewohnt die Werte für die »auth_« -Variablen in die Konfiguration einzutragen. Weiter unten in der Datei findet sich überdies der Eintrag »# metadata_ip =« , der zu entkommentieren ist und im Beispiel den Wert »192.168.122.111« enthält – mehr zum Metadaten-Server später. Die Konfigurationsdatei bedarf weiterer Anpassungen, die derzeit allerdings noch nicht möglich sind. Denn dafür wären die IDs des externen Routers wie auch die ID des externen Netwerks nötig, die allerdings erst exisiteren, nachdem die Netzwerke entsprechend angelegt sind. Genau das ist daher der nächste Schritt: Das Anlegen der Netzwerke in Quantum. Dieser Schritt findet auf Alice statt.

Weil auch das Anlegen von Netzwerken einige Kommandos umfasst, stellt der Autor dieses Artikels ein Skript unter [3] zur Verfügung. Dieses legt die im Beispiel vorgesehenen Netzwerke an: Einerseits ein "privates" Netzwerk für die Kommunikation der virtuellen Maschinen untereinander, andererseits auch das pseudo-öffentliche Netzwerk »192.168.144.0/25« , aus dem die VMs dann im weiteren Verlauf dynamische IP-Adressen ("floating IPs") erhalten. Nach dem Download und dem Ausführen des Skriptes gilt es, die Quantum-interne ID des Routers für das Floating-Netz wie auch die ID des Floating-Netztes selbst in Erfahrung zu bringen. Den ersten Wert fördert »quantum router-list« auf den Bildschirm – der Wert bei »ID« in der Zeile für den Router »provider-router« ist von Interesse. Dieser wiederum landet in der eben bereits bearbeiteten »/etc/quantum/l3_agent.ini« auf Charlie. Die ID des Floating-Netzwerkes lässt sich mit »quantum net-list« erfragen – dabei ist der Wert des »ID« -Feldes beim Eintrag interessant, dessen Name » ext_net« ist. Der Wert landet in »/etc/quantum/l3_agent.ini« hinter dem Wert »gateway_external_net_id = « . Beide zu ändernden Werte sind auch zu entkommentieren, sodass die Quantum-Agents sie tatsächlich betrachten. Damit sind die Quantum-Konfigurationsdateien fertig.

Mit Quantum kann es nun fast losgehen: Auf Bob und Charlie fehlen nur noch die internen Bridges, die OpenVSwitch verwendet, um die Quantum-Interfaces an die lokale Netzwerk-Konfiguration anzuschließen. Auf Bob und Charlie legt »ovs-vsctl add-br br-int« die Bridge an, die für die VM-interne Kommunikation zuständig ist. Zusätzlich braucht Charlie auch die Bridge nach außen: » ovs-vsctl add-br br-ext« und »ovs-vsctl add-port br-ext eth2« erledigen die notwendige Konfiguration. Am Ende des Vorgangs steht ein Neustart aller Agents auf Bob und Charlie an: »restart quantum-plugin-openvswitch-agent« sind sowohl auf Bob als auch auf Charlie notwendig, auf Charlie sorgt zudem »restart quantum-l3-agent« und »restart quantum-dhcp-agent« dafür, dass die Agents ihre Konfiguration neu laden.

Direkt angenehm im Vergleich zu Quantum gestaltet sich die Konfiguration von Cinder. Die Komponente war in der letzten OpenStack-Version Essex noch unter dem Namen »nova-volume« Teil der Computing-Komponente, führt nun aber ein Eigenleben.

Block-Storage mit Cinder

Voraussetzung dafür, dass Cinder funktioniert, ist eine LVM-Volume-Gruppe namens »cinder-volumes« auf dem Host, auf dem Cinder läuft. Meistens wird Cinder auf dem Cloud-Controller beheimatet sein, auch in diesem Beispiel werkelt das Programm auf Alice. Welche Storage-Devices Teil der LVM-Volume-Gruppe sind, ist Cinder übrigens herzlich egal – wichtig ist nur, dass es in dieser Volume-Gruppe selbst Volumes anlegen kann. Auf Alice ist entsprechend eine Volume-Gruppe »cinder-volumes« für dieses Beispiel da.

Nach der Installation der Cinder-Dienste ist der wichtigste Teil, dass in »/etc/cinder/cinder.conf« das Programm über »sql_connection« erfährt, wie es an seine Datenbank kommt. Der korrekte Eintrag im Rahmen des Artikels ist »sql_connection = mysql://cinderdbadmin:ceeShi4O@192.168.122.111:3306/cinder« . Anschließend steht »/etc/cinder/api-paste.ini« auf dem Programm – die nötigen Anpassungen sind analog zu den Veränderungen von »api-paste.ini« der anderen Programme, wobei die »service_« -Einträge die gleichen Werte erhalten wie ihre »auth_« -Pendants. »admin_user« ist »cinder« .

Auch Cinder benötigt Tabellen in seiner MySQL-Datenbank, die das Kommando »cinder-manage db sync« anlegt. Es folgt ein Restart der Cinder-Dienste: »for i in api scheduler volume; do restart cinder-"$i"; done« . Zuletzt gilt es, einen lästigen Bug im »tgt« -iSCSI-Target zu umgehen, der sonst die korrekte Funktion von Cinder verhindert: Dazu ist der vorhandene Eintrag in »/etc/tgt/targets.conf« durch den Eintrag »include /etc/tgt/conf.d/cinder_tgt.conf« zu ersetzen. Danach ist Cinder bereits fertig – der Befehl »cinder list« sollte eine leere Liste ausgeben, es sind ja noch keine Volumes konfiguriert.