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

© Steven Frame, 123RF

Überbreite

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.
Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

Der vergangene zweite Teil dieses Workshops bot wenig Grund zur Gaudi – bis eine vollständige OpenStack-Installation das Licht der Welt erblickt hat, muss der ausführende Admin sich um gefühlte 1000 Dinge gleichzeitig kümmern. Der Lohn ist eine Cloud-Plattform, die nahtlos in die Breite skaliert und die durch den Einsatz moderner Technik wie Openvswitch viele technische Probleme umschifft, mit denen konservative Virtualisierungs-Umgebungen kämpfen. Steht die Basisinstallation, geht es ans Verfeinern: Wie schaffen Cloud-Betreiber Mehrwert durch ihre Software, wie machen sie ihre Installation zukunftssicher, und wie lässt sich ein Infrastrukturausfall in OpenStack bestmöglich abfedern? Diese dritte Folge des OpenStack-Workshops geht jenen Fragen auf den Grund und beginnt mit einer Reparatur, die Cloud-Kunden ein Jauchzen entlocken dürfte.

Quantum, Horizon und Floating-IPs

Eine elementare Funktion in OpenStack sind die Floating-IPs. Sie erlauben es, virtuelle Maschinen bei Bedarf mit öffentlichen IP-Adressen auszurüsten, um diese aus dem Internet erreichbar zu machen. Öffentliche IPs lassen sich dynamisch bestehenden Instanzen zuweisen. Ihren Ursprung hat die Funktion in der Tatsache, dass längst nicht jede VM aus dem Internet erreichbar sein soll: Einerseits sind oft gar nicht genug IPv4-Adressen vorhanden, um dieses Ziel zu erreichen; andererseits gibt es auch keinen Grund beispielsweise einer Datenbank, eine öffentliche IP zuzuweisen. Webserver hingegen (oder wenigstens ihnen vorgeschaltete Loadbalancer) sind idealerweise aus dem Netz erreichbar.

In der vorangegangenen OpenStack-Version Essex war die Welt quasi noch in Ordnung: Um das Netzwerk kümmerte sich Nova Network als Komponente der Computing-Umgebung von OpenStack und von Quantum war noch nichts zu sehen. Das Zuweisen von Floating-IPs war eine Nova-interne Angelegenheit, und genau darauf ist beispielsweise auch das Webinterface Horizon ausgelegt: Will ein Kunde im Dashboard einer VM eine Floating-IP zuweisen, so sendet Horizon den Befehl an Nova und verlässt sich darauf, dass das Richtige geschieht.

Abbildung 1: Wenn der Patch für Floating-IPs mit Quantum per Dashboard auf dem System eingespielt ist …

Probleme mit Quantum

In Folsom hat diese Eintracht durch Quantum etwas gelitten. Denn nun ist nicht mehr Nova für Floating-IP-Adressen zuständig, sondern eben Quantum. Das macht sich an mehreren Stellen bemerkbar: In der ursprünglichen Version von Folsom, also 2012.2, funktioniert das Zuweisen von Floating-IPs nur per Kommandozeile und einem »quantum« -Befehl. Kostprobe gefällig? Listing 1 zeigt die einzelnen Schritte, die dafür notwendig sind.

Listing 1

Floating-IPs mit quantum zuweisen

 

Was im Beispiel kryptisch aussieht, ist es auch: Zunächst findet der Admin die ID seines externen Netzwerks (im Beispiel »ext_net« ) heraus, um dann per »quantum floatingip-create« eine Floating-IP in diesem Netz anzulegen. dann muss er wissen, mit welchem Port des virtuellen Quantum-Switches die VM verbunden ist, die die Floating-IP erhalten soll, im Beispiel die VM mit der IP-Adresse »10.5.5.3« . Schließlich kriegt die VM ihre IP. Bedingt durch die Tatsache, dass Quantum durchgehend auf UUIDs setzt, gestaltet sich der gesamte Vorgang offensichtlich überaus intuitiv.

Scherz beiseite: Dass diese Arbeitsschritte für Nicht-Geeks praktisch nicht zu meistern sind, liegt auf der Hand. An genau diese Nicht-Geeks richten sich Cloud-Plattformen aber, es muss also eine Lösung her. Das Dashboard, das den Benutzern das einfache Zuweisen von IPs erlaubt, ist leider noch nicht fit für den Quantum-Einsatz und versucht auch bei Quantum-Setups stur, das Zuweisen der IPs über Nova abzuwickeln. Quantum-Kompatibilität haben die Entwickler erst für die Grizzly-Version des Dashboards vorgesehen. Trotzdem kein Grund zum Verzweifeln, denn mit etwas Bastelei lässt sich die fehlende Funktion einfach nachrüsten. Die Nova-Komponente im ersten Folsom-Maintenance-Release (2012.2.1) kommt mit einem Patch, der Floating-IP-Requests direkt an Quantum weiterleitet, wenn Quantum zum Einsatz kommt. Wer Floating-IPs mit Quantum will, sollte also zunächst diese Version installieren (für Ubuntu 12.04 liegt sie mittlerweile in Form von Paketen im Ubuntu-Cloud-Repository vor). Das ist die halbe Miete – die andere Hälfte kommt in Form eines Patches.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019