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

Das OpenStack-Dashboard

Dessen Konfiguration ist nicht weiter schwierig: Nach der Installation der benötigten Pakete auf Alice ist die Datei »/etc/openstack-dashboard/local_settings.py« für diese Aufgabe von Interesse. Am Ende dieser Datei fehlen ein paar Einträge für die korrekte Funktion des Dashboards:

OPENSTACK_HOST = '192.168.122.111'
QUANTUM_ENABLED = True
SWIFT_ENABLED = True

Danach sorgt ein Neustart des Apache2-Webservers mittels »restart apache2« dafür, dass das Dashboard seine Konfiguration neulädt. Direkt im Anschluss steht das Webinterface unter »http://192.168.122.111/horizon« zur Verfügung ( Abbildung 7 ) – der Login geschieht mit dem Benutzernamen »admin« , das Passwort ist »geheim« .

Abbildung 7: Das Dashboard zeigt zu gestarteten VMs diverse Informationen wie die zugewiesene IP-Adresse und auch die Hardware-Konfiguration an.

Die Sache mit dem Metadata-Server

Virtuelle Maschinen, die aus speziellen Images stammen – nämlich aus solchen Images, die offiziell für Cloud-Umgebungen vorbereitet sind – zeichnen sich durch eine Besonderheit aus: Sie versuchen nämlich während des Bootvorgangs per HTTP-Request Informationen über sich selbst von einem Cloud-Metadatenserver zu erhalten. Diese Technik stammt ursprünglich aus Amazons EC2-Umgebung – sie stellt sicher, dass eine virtuelle Maschine ihren Hostname kennt und diverse Parameter beim Systemstart zur Verfügung hat, beispielsweise die Konfiguration hinsichtlich des zu startenden SSH-Servers.

Die Ubuntu-UEC-Images sind ein gutes Beispiel für den Einsatz dieser Funktion: Eine Maschine, die aus einem Ubuntu-Image für UEC-Umgebungen stammt, führt eben jenes »cloud-init« genannt Tool beim Starten aus. Das Schema ist immer das gleiche: Ein HTTP-Request auf die URL »http://169.254.169.254:80« soll die entsprechenden Details beim Cloud-Controller abfragen. Damit diese Technik funktioniert, ist einerseits eine entsprechende IPTables-Regel notwendig, die jene IP-Adresse auf den Computing-Knoten auf den "richtigen" Cloud-Controller per DNAT-Regel weiterleitet.

Der "richtige" Controller ist in diesem Beispiel »nova-api-metadata« , der auf Alice am Port 8775 lauscht. Die gute Nachricht ist: Die DNAT-Regel setzt der L2-Agent auf den Compute-Knoten automatisch. Die schlechte: Damit auch der Rückkanal vom Cloud-Controller hin zu den VMs funktioniert, ist auf dem Cloud-Controller – also Alice – eine entsprechende Route zu setzen. Diese enthält als Netzwerk das private VM-Netzwerk (im Beispiel 10.5.5.0/24) und als Gateway die IP-Adresse, die auf dem Netzwerk-Host als Gateway-IP für virtuelle Maschinen dient. Je nach Konfiguration unterscheidet sie sich. Um sie herauszufinden, sind zwei Arbeitsschritte nötig:

Per »quantum router-list« ist zunächst die ID des Routers zu finden, die das externe Netzwerk nutzt. Danach fördert der Befehl »quantum port-list -- --device_id ID --device_owner network:router_gateway « das Gateway zu Tage, im Beispiel also 192.168.144.100. Die korrekte Route auf Alice setzt der Admin dann per »ip route add 10.5.5.0/24 via 192.168.144.100« . Danach klappt der Zugriff auf den Metadatenserver. Dieser doch etwas umständliche Prozess wird wohl in einer der kommenden OpenStack-Versionen durch eine neue und bequemere Prozedur ersetzt werden.

comments powered by Disqus
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