Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Perspektiven

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« .

Pakete auf dem Cloud Controller

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:

  • ntp
  • tgt / open-iscsi / open-iscsi-utils
  • rabbitmq-server
  • mysql-server / python-mysqldb
  • keystone / python-keystone / python-keystoneclient
  • glance / glance-api / glance-common / glance-registry / python-glance
  • nova-api-metadata / nova-api-os-compute / nova-api-os-volume / nova-api-ec2
  • nova-cert / nova-common / nova-doc / nova-objectstore / nova-scheduler
  • nova-consoleauth / nova-novncproxy / python-nova / python-novaclient
  • openvswitch-switch
  • quantum-server / python-cliff / python-pyparsing
  • cinder-api / cinder-scheduler
  • cinder-volume / iscsitarget / open-iscsi / python-cinderclient
  • libapache2-mod-wsgi / openstack-dashboard / python-memcache

Auf dem Compute-Host sind ebenfalls ein paar Pakete notwendig, jedoch deutlich weniger als auf dem Cloud Controller:

  • kvm / libvirt-bin / pm-utils
  • nova-compute-kvm
  • quantum-plugin-openvswitch-agent / bridge-utils

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:

  • bridge-utils
  • quantum-plugin-openvswitch-agent / quantum-l3-agent / quantum-dhcp-agent
  • python-keystone / python-keystoneclient

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 )

Abbildung 1: Ein OpenStack-Standardsetup sieht mindestens vier Netzwerke vor, die jeweils eine eigene Rolle spielen.

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).

Abbildung 2: Nach dem Anlegen der Netzwerke in Quantum stehen zwei Netzwerke sowie ein Router zur Verfügung.

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.

Asynchrones Routing aktivieren

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.

IPTables und Masquerading

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.

Abbildung 6: Ist das Dashboard installiert, erlaubt es das bequeme Starten und Stoppen neuer virtueller Maschinen über die grafische Oberfläche.

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei hastexo. Er beschäftigt sich dort intensiv mit Hochverfügbarkeitslösungen und pflegt in seiner Freizeit den Linux-Cluster-Stack für Debian GNU/Linux.

comments powered by Disqus
Mehr zum Thema

OpenStack-Workshop, Teil 3: Gimmicks, Erweiterung und Hochverfügbarkeit

Nach der knochentrockenen Installations-Anleitung in Episode 2 beschäftigt sich nun der dritte Teil des Workshops mit nützlichen Erweiterungen von OpenStack und verrät Admins, wie sie ihre Wolke am besten gegen Ausfälle absichern.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023