Das Thema 'Servervirtualisierung & Cloud' steht auf der Agenda des IT-Administrator im Mai. So lesen Sie unter anderem, wie einfach sich OpenStack mit Mirantis ... (mehr)

Den Fuel-Server einrichten

Schritt eins besteht darin, den Fuel-Server so einzurichten, dass er als Basis für das Bootstrapping aller anderen Hosts dienen kann. Mirantis bietet dazu ein ISO [2] an, das einen nackten Computer in einen Fuel-Server verwandelt. Mirantis beschreibt in der Dokumentation, dass sich das Image idealerweise per Remote-Management-Console (IPMI, iLO, DRAC) nutzen lässt. Selbstverständlich funktioniert es aber auch, wenn es eigens auf eine DVD gebrannt wird und dann im CD-ROM-Laufwerk des Servers landet.

 Der Boot von der DVD führt zu einem Bootprompt, wie ihn auch die gängigen Linux-Distributionen nutzen. Mit der Eingabe-Taste würde Fuel nun booten und den Rechner lokal automatisch zum Master-Knoten für Fuel machen. Dabei kämen die von Mirantis voreingestellten Defaults für Einstellungen wie die gewünschten IP-Netzwerke und das Root-Passwort zum Einsatz. Admins werden einige dieser Parameter allerdings eher selbst festlegen wollen. Wenn das der Fall ist, genügt es, einmal auf Tab zu drücken, während der Mirantis-Bootscreen zu sehen ist. Dann erscheint unten die komplette Kernel-Kommandozeile, die der Installer beim Booten verwendet. Der Parameter "showmenu" ist der wichtige: Indem das "no" hier zu einem "yes" wird, sorgen Admins dafür, dass Fuel bei der Installation einen Konfigurationsdialog anzeigt.

Der bietet Admins umfangreiche Einstellungsoptionen. Haben die genutzten Server etwa mehrere Netzwerkkarten, lässt sich im Setup für jede einzelne die gesamte IP-Konfiguration festlegen. Das "docker0"-Interface sorgt im ersten Augenblick für Verwirrung, sollte aber unter allen Umständen einfach so bleiben, wie Fuel es darstellt (Bild 1) – zu Docker bei Fuel später mehr.

Bild 1: Bei der Konfiguration der Netzwerkkarten lassen Admins das Interface namens "docker0" idealerweise in Ruhe – es dient nur internen Zwecken.

Wenigstens eins der physischen Interfaces sollte am Ende eine fixe IP besitzen. Dieses Interface wird im Fuel-Jargon zum "Admin Network", über das später PXE-Requests beantwortet werden. Alle anderen Knoten sollten also mindestens eine Verbindung zum gleichen Netzwerk haben, damit sie später mit dem Fuel-Master kommunizieren können.

NTP, DNS und Docker

Sind die physischen Netzwerkkarten passend eingerichtet und gespeichert, folgt im nächsten Schritt der Dialog "PXE Set-up". Hier will Fuel wissen, welches der physischen Interfaces PXE-Anfragen bearbeiten soll. Wichtig dabei: Unter keinen Umständen darf "docker0" das PXE-Interface sein, denn das würde nicht funktionieren. Angehende OpenStack-Administratoren legen hier außerdem zwei IP-Ranges fest: Einer dient als statischer Adressraum für Knoten, die Fuel bereits kennt. Der Begriff "statisch" ist dabei etwas irreführend, denn auch die IPs des statischen Pools werden später per DHCP zugewiesen – aber reproduzierbar.

Der "DHCP Pool" bezieht sich im Gegensatz dazu auf die tatsächlich dynamischen Adressen, die Hosts bekommen, wenn sie sich später zum ersten Mal im Netz anmelden und per PXE ihr Installationsimage herunterladen. Sobald sie fix installiert sind, kriegen jene Hosts eine IP aus dem statischen Pool. Dabei bleibt dem Admin überlassen, wie er die beiden Adressräume aufteilt. Wenn private IPs im Spiel sind, schlägt Fuel ab Werk die Aufteilung eines /24er-Netzes in zwei Blöcke vor, ein Block ist dann der DHCP-Block und der andere der statische. Wenn klar ist, dass das anfängliche Fuel-Setup nicht mehr als gute 250 Hosts umfassen wird, geht die Fuel-Empfehlung durchaus in Ordnung.

Damit der PXE-Workflow von Fuel funktioniert, startet der Fuel-Master selbst übrigens einen DHCP-Server. Damit ist auch klar, dass das "Admin"-Netzwerk ein Netzwerk sein sollte, in dem noch kein DHCP-Server vorhanden ist – also zum Beispiel nicht das firmenweite Netz mit Standard-DHCP.

Die übrigen Einstellungen im Fuel-Installer betreffen den verwendeten DNS-Server, den Hostnamen des Fuel-Masters, NTP sowie das Root-Password, das der Fuel-Master und alle anderen später installierten Knoten für das Login voraussetzen. Diese Werte können Sie nach Belieben festlegen.

Sind alle Werte gesetzt, macht sich die Installationsroutine an die Arbeit, wenn Sie auf "Save & Quit" klicken. Am Ende erhalten Sie ein fertig installiertes Linux-System mit Fuel. Aus eben dieser Keimzelle lässt sich im nächsten Schritt eine komplette OpenStack-Wolke entwickeln.

Ein »ps faux« auf der Kommandozeile des Fuel-Masters macht übrigens deutlich, warum während der Fuel-Installation zuvor von einem Interface namens "docker0" die Rede war: Mirantis nutzt für den Fuel-Master Docker. Das ist eine Container-Technologie für Linux, im Grunde also eine Virtualisierungstechnologie, bei der aber kein kompletter Computer emuliert wird. Stattdessen erhalten Programme innerhalb des vom Host bereitgestellten Dateisystems ein eigenes, virtuelles Dateisystem. Aus Admin-Sicht ist der Einsatz von Docker für den Fuel-Master sehr sinnvoll: Das Host-System des Fuel-Masters hat nur Basis-Funktionalität und alles andere kommt aus den Docker-Containern. Sollte es also notwendig oder wünschenswert sein, den Fuel-Master auf eine neue Version von Fuel zu aktualisieren, wäre das nur ein Update der einzelnen Docker-Container. Das ist deutlich robuster, als wenn jeder Dienst direkt auf dem Fuel-Master-Host beheimatet wäre.

Ähnliche Artikel

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