Die hier vorgestellte OpenStack-Installation ist das grundlegende Setup, das aus drei Knoten eine Wolke konstruiert. Themen wie die Hochverfügbarkeit einzelner Dienste oder das Zuweisen von "öffentlichen" IP-Adressen an die VMs behandelt dann der dritte Teil der Serie im kommenden Admin-Magazin 02/2013 ausführlich.
Benötigte Pakete
Der Artikel geht davon aus, dass Ubuntu 12.04 zum Einsatz kommt. Um in den Genuss von OpenStack Folsom zu gelangen, reichen die Paketlisten von Ubuntu 12.04 allerdings nicht aus, denn diese enthalten nur Pakete für die Vorgängerversion Essex. Glücklicherweise stellt das Ubuntu-Cloud-Team für Precise Pangolin aber in einem eigenen Repository Pakete von Essex bereit, die sich wie gehabt installieren lassen. Damit die Installation klappt, ist das Paket
»ubuntu-cloud-keyring
«
notwendig, das den GPG-Schlüssel des Cloud-Teams enthält. In
»/etc/apt/sources.list.d/cloud.list
«
sorgt im Anschluss der Eintrag
»deb http://ubuntu-cloud.archive. canonical.com/ubuntu precise-updates/folsom main
«
dafür, dass die benötigten Paketlisten tatsächlich auch in die Verwaltung des Systems gelangen. Die Installation einzelner Pakete erfolgt danach wie gewohnt über Werkzeuge wie
»apt-get
«
oder
»aptitude
«
.
Der Host
»alice
«
spielt im Beispiel den Cloud Controller; damit der Host diese Aufgabe erfüllen kann, benötigt er den Basis-Satz an Paketen für OpenStack. Die folgenden Pakete samt Abhängigkeiten sind also Voraussetzung:
Auf dem Compute-Host sind ebenfalls ein paar Pakete notwendig, jedoch deutlich weniger als auf dem Cloud Controller:
Schließlich gibt es noch den Netzwerk-Knoten, der auch ein Basisset an Paketen braucht. Damit er tut wie ihm verheißen, dürfen die folgenden Pakete also nicht fehlen:
Das Netzwerk der Wolke
Das Netzwerk der Wolke
OpenStack Folsom bringt Quantum als zentrale Komponente für das Netzwerk. Die Komponente hilft dabei, Netzwerke zu virtualisieren – damit sie diese Rolle wahrnehmen kann, muss der Admin allerdings verstehen, wie Quantum im Ansatz funktioniert und welche Voraussetzungen auf den einzelnen Knoten zu erfüllen sind, damit das Quantum-Prinzip funktioniert.
Grundsätzlich gilt: In Quantum bekommt der Admin es mit einer Reihe von Netzwerken zu tun, die die Kommunikation der Knoten untereinander und der virtuellen Maschinen ermöglichen. Die Quantum-Entwickler unterscheiden in diesem Falle zwischen vier verschiedenen Netzwerken ( Abbildung 1 )
Das Management-Network ist das Netzwerk, das die physikalischen Server der OpenStack-Installation nutzen, um miteinander zu kommunizieren. Über dieses Netzwerk laufen beispielsweise interne Anfragen an den Keystone-Dienst, der für die Autentifizierung innerhalb des Setups verantwortlich ist. In diesem Beispiel ist das Management-Netz 192.168.122.0/24, und alle drei Knoten haben eine direkte Verbindung in dieses Netz über die Netzwerkschnittstelle eth0.
»alice
«
hat dabei die IP-Adresse 192.168.122.111,
»Bob
«
hat die IP 192.168.122.112 und
»Charlie
«
hat die IP-Adresse 192.168.122.113. Zudem geht das Beispiel davon aus, dass die Default-Route aller drei Rechner zur Außenwelt ebenfalls in diesem Netzwerk liegt und dass das Default-Gateway in allen Fällen 192.168.122.1 ist (
Abbildung 2
). Hinzu kommt das Data Network: Dieses nutzen die virtuellen Maschinen auf dem Comute-Host (Bob), um mit dem Netzwerk-Dienst auf Charlie zu sprechen. Das Data-Netz ist im Beispiel 192.168.133.0/24, Bob hat als IP-Adresse in diesem Netz 192.168.133.112 und Charlie hat 192.168.133.113 – auf beiden Hosts liegt das Netz auf dem Interface
»eth1
«
an, das seinerseits auch als Bridge für die virtuellen Maschinen dient (diese werden IP-Adressen im privaten Netzwerk 10.5.5.0/24 haben, um miteinander zu sprechen).
Weiterhin existiert das
»External Network
«
: Aus diesem beziehen die virtuellen Maschinen später öffentliche IP-Adressen. In Ermangelung echter öffentlicher IPs nutzt das Beispiel für dieses Netz
»192.168.144.0/25
«
. Weil in Quantum die einzelnen VMs die öffentlichen IP-Adressen nicht direkt zugewiesen bekommen, sondern der Zugriff hierauf über den Netzknoten und dort gesetzte iptables-DNAT-Regeln funktioniert, benötigt nur der Host für Quantum, also Charlie, ein Interface in diesem Netz.
Die Zuteilung einer IP erfolgt durch Quantum automatisch, sodass auf Charlie nur das Interface
»eth2
«
vorhanden sein muss – aus der Konfiguration erfährt Quantum im weiteren Verlauf, dass es dieses Interface für das öffentliche Netz nutzen soll.
Schließlich existiert das
»API
«
-Netzwerk: Dieses ist nicht zwingend vorgeschrieben, erlaubt es aber, die APIs der OpenStack-Dienste über ein öffentliches Interface der Außenwelt zur Verfügung zu stellen. Das Netz kann im gleichen Segment liegen, wie das External Network (beispielsweise könnte das gesamte zur Verfügung stehende Netz 192.168.144.0/24 sein, auf Quantum-Ebene ist das definierte öffentliche Netz dann 192.168.144.0/25, und das Netz 192.168.144.129/25 steht als API-Netz zur Verfügung). Falls die APIs von OpenStack von außen erreichbar sein wollen, muss auf Alice dafür ein Interface existieren, das eine entsprechende IP enthält.
Eine überaus lästige Default-Einstellung in Ubuntu 12.04 führt bisweilen zu Problemen, gerade in Setups mit OpenStack Quantum. Ubuntu setzt ab Werk den Wert für die
»rp_filter
«
-Syscontrol-Variable auf 1. Das bedeutet, dass ein Antwortpaket für einen Netzwerkrequest nur über genau das Interface den Weg in das System nehmen darf, über das die ursprüngliche Anfrage das System zuvor verlassen hat. In Quantum-Setups kann es allerdings durchaus vorkommen, dass Pakete über andere Interfaces rausgehen, als deren Antworten den Weg zurück in das System finden. Es empfiehlt sich daher, das asynchrone Routing auf Ubuntu großflächig zu erlauben. In
»/etc/sysctl.conf
«
erledigen das die folgenden beiden Einträge:
net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0
Selbstverständlich muss auch das Packetforwarding aktiviert sein:
net.ipv4.ip_forward=1
Ein Reboot im Anschluss sorgt dafür, dass die neue Konfiguration aktiv ist.
Last but not least ist freilich auch die Firewall-Konfiguration der Hosts zu beachten. Grundsätzlich gilt, dass iptables-Regeln nicht den Traffic der einzelnen Interfaces behindern sollten. Kommt wie im Beispiel zudem ein Gateway für das externe Netzwerk zum Einsatz, das kein vom Provider separat gesteuerter Router ist, sondern ein lokaler Rechner, so sind auf diesem die Regeln für DNAT und SNAT so zu setzen, dass sie zum Setup passen.
Infos