Nodes zur Umgebung hinzufügen

 Der letzte Schritt des OpenStack-Deployments mit Fuel besteht nun darin, die "Unallocated Hosts" in Fuel mit der eben angelegten OpenStack-Umgebung zu verbinden. Bis dato handelt es sich nämlich um separate Einträge, die miteinander nichts zu tun haben. Das muss sich ändern: Indem Sie die Hosts einerseits zur OpenStack-Umgebung hinzufügen und ihnen andererseits in jener Umgebung Rollen zuweisen, setzen Sie das OpenStack-Deployment in Gang. Freilich bietet das Fuel-Interface auch dafür die passenden Knöpfe. Falls die angelegte Umgebung vom letzten Schritt nicht eh noch auf dem Schirm ist, öffnet sie ein Klick im "Environments"-Teil von Fuel.

Jede OpenStack-Umgebung in Fuel hat mehrere Registerreiter: Nodes, Networks, Settings und so weiter. Im ersten Schritt ist der "Nodes"-Eintrag das Ziel des Admins: Mittels des "Add Nodes"-Buttons lassen sich neue Knoten zu der OpenStack-Umgebung hinzufügen. Der Dialog hinter "Add Nodes" ist allerdings etwas verwirrend. Im oberen Teil des Fensters erscheint eine Liste der Rollen, die Mirantis in Fuel vorgegeben hat. "Controller" vereint praktisch alle zentralen Open­Stack-Dienste. "Compute" installiert einen Knoten mit Hypervisor-Fähigkeiten für den Betrieb in OpenStack. "Storage - Cinder" macht einen Server zum Lieferanten von persistentem Speicher.

Unten stehen die verfügbaren Knoten, sortiert nach ihren Möglichkeiten auf Basis ihrer Hardware. Um einem Host eine Rolle zuzuweisen, wählen Sie in diesem Dialog oben die entsprechende Rolle und unten den passenden Host. Verschiedene Rollen lassen sich auch miteinander kombinieren, zum Beispiel die Compute-Rolle und die Controller-Rolle. Damit OpenStack sinnvoll funktioniert, sollten mindestens die Controller-, Storage-Node- und Compute-Node-Rollen den vorhandenen physischen Hosts zugewiesen sein. Ein Klick auf "Apply Changes" trägt die Änderung in die Fuel-Konfiguration ein. Der Button ist nicht mit dem "Deploy Changes"-Button oben rechts zu verwechseln – dieser kommt erst ganz am Ende zum Einsatz.

In der Knoten-Liste von Fuel haben die einzelnen Knoten übrigens noch keinen Namen. Das lässt sich durch einen Klick auf den "Untitled"-Eintrag in der Knotenliste ändern (Bild 3).

Platten und Netzwerk bestimmen

Wenn einem Knoten eine Rolle zugewiesen ist und er dann erneut per Haken vor dem Eintrag in der Knotenliste ausgewählt wird, tauchen oben rechts zwei neue Buttons auf: "Configure Disks" und "Configure Interfaces". Über die beiden Buttons lassen sich pro Knoten das erwartete Disk-Layout und das Layout der Netzwerkkarten im Host definieren. Beim Partitionslayout sind im Grunde lediglich die persönlichen Vorlieben des Admins von Bedeutung; eine Ausnahme davon bilden die Storage-Knoten, bei denen genug Speicherplatz für Cinder zur Verfügung stehen sollte.

Die Netzwerkeinstellungen sind tatsächlich hakelig: Hier unterscheidet Fuel zwischen den Netzwerken "Public", "Management" und "Storage". Hinzu kommt das "L3-Netzwerk", das für VMs später eine externe Verbindung herstellt. Fuel ist ganz gut darin, die einzelnen Netzwerkschnittstellen automatisch zu erkennen. Admins sollten im "Network Settings"-Dialog pro Maschine trotzdem nachschauen, ob die Interfaces wie gewünscht eingestellt sind. Im Dialog "L3 Configuration" geben Admins außerdem das externe Netzwerk an, aus dem Kunden-VMs sich später dynamische externe IPs ("Floating IPs") zuweisen können (Bild 4).

Bild 4: Die L3-Konfiguration von Neutron legt fest, welche IP-Adressen Neutron für die Verbindung nach draußen nutzt und aus welcher Range Floating-IPs kommen.

Schließlich sorgt ein Klick auf "Deploy Changes" oben rechts dafür, dass Fuel das Deployment der Software auf den einzelnen Knoten in Gang setzt. Das kann eine ganze Weile dauern, doch der Mühe Lohn kann sich sehen lassen: Am Ende begrüßt den Admin eine fertige OpenStack-Installation aus mehreren Knoten, die als Proof of Concept gute Dienste leistet.

Unübersehbar gibt es in Fuel den Registerreiter "Settings", der die Details der jeweiligen OpenStack-Umgebung in Fuel festlegt. Hier finden Admins gleich mehrere Stellschrauben, an denen sich das Verhalten der Cloud verändern lässt. Quotas sind hier genauso festzulegen wie die Antwort auf die Frage, ob das OpenStack-Setup in seinen Logfiles Debug-Output enthalten soll oder nicht. Der Compute-Scheduler, der in Nova die Ziel-Hosts für spezifische VMs auswählt, ist ebenfalls an dieser Stelle anzugeben.