Sicher verstaut - Deduplizierung spart Platz, Cloud-Backup für Windows, Areca sichert kostenlos. ADMIN 01/14 stellt Backups für Profis mit und ohne Cloud ... (mehr)

Schritt 2 und 3: Kickstack

Die jeweils aktuelle Version von Kickstack finden Admins direkt auf GitHub unter [5] oder in PuppetForge. Sobald das Modul samt Abhängigkeiten installiert ist, kann es losgehen.

Die vormals beschriebenen Node-Rollen sind sinnvoll auf die Knoten, die zur Verfügung stehen, zu verteilen. Das Beispiel folgt einer eher konservativen Aufteilung: Während Charlie der Netzwerk-Knoten wird, der alle Teile von Neutron außer der Neutron-API betreibt, stellt Bob den Computing-Knoten dar, der die entsprechende Rolle hat. Alle anderen Rollen landen auf Alice, die den Löwenanteil der Arbeit verrichtet.

Das folgende Beispiel geht davon aus, dass die einzelnen Knoten nach der Installation von Kickstack auf dem Puppet-Master bereits vom Admin zum Teil der Puppet-Installation gemacht worden sind. In diesem Falle tauchen sie nach dem Admin-Login in Puppet-Dashboard unter »Nodes« auf.

Ein Klick auf »Groups« oben führt zur einzigen angelegten Gruppe mit dem Namen »kickstack« – Knoten, die im Rahmen von Kickstack Aufgaben in der Cloud übernehmen, sollten Mitglied dieser Gruppe sein (Abbildung 3). Ein Klick auf »kickstack« gefolgt von einem weiteren Klick auf »Edit« bieten die Möglichkeit, Knoten zur Gruppe hinzuzufügen. Das Editier-Fenster für die Gruppe bietet zudem Zugriff auf die wichtigsten Einstellungen bezüglich der OpenStack-Cloud: Soll beispielsweise innerhalb von OpenStack vollvirtualisiert werden (also nur mit Qemu, aber ohne KVM), so ist der Eintrag im Feld » kickstack_nova_compute_libvirt_type« der richtige Ansatzpunkt hierfür. Von großer Bedeutung sind auch die Einträge für »kickstack_nic_external« , » kickstack_nic_management« und »kickstack_nic_data« : Sie legen fest, auf welchen Netzwerk-Interfaces welche Netzwerk-Typen liegen. OpenStack kennt

Abbildung 3: Das Puppet-Dashboard zeigt eine Übersicht über die Kickstack-Gruppe sowie deren wichtigste Konfigurationsparameter und die beteiligten Knoten.
  • das Management-Netzwerk, das die einzelnen Dienste auf den Knoten direkt miteinander verbindet,
  • das Data-Netzwerk, über das der Traffic zwischen VMs wandert, die in der Cloud laufen sowie
  • das externe Netzwerk, das eine Verbindung für die virtuellen Maschinen mit der Außenwelt herstellt.

Wer Kickstack und OpenStack in virtuellen Maschinen ausprobiert, legt die Netzwerk-Interfaces der VMs sinnvollerweise gleich so an, dass sie diesem Schema entsprechen; bei Blech sind die Parameter der Kickstack-Gruppe unter Umständen anzupassen. Falls sich die Werte nicht einheitlich für alle Knoten anpassen lassen, weil zum Beispiel der Netzwerkknoten eine andere NIC für das Management-Netzwerk als der API-Knoten nutzt, lassen sich die Parameter im nächsten Schritt übrigens auch pro Knoten anpassen. Besonders wichtig dabei ist der Parameter »kickstack_cinder_lvm_pv« für den Knoten, auf dem die »Storage« -Rolle landet – im Beispiel also Alice: Kickstack macht aus dem dort angegebenen Device automatisch ein Logical Volume in LVM, um es danach für Cinder zu nutzen. Passt die Konfiguration der Kickstack-Gruppe, geht es weiter mit den Rollen.

Schritt 4: Rollen zuweisen

Ein Klick auf »Nodes« im Puppet-Dashboard führt direkt zu den einzelnen Einträgen der Knoten, die Puppet kennt. Ein Klick auf einen Knotennamen sowie ein anschließender Klick auf »Edit« führen zum Konfigurationsdialog dieses Knotens.

Die vorletzte Checkbox unten markiert die Klassen, zu der ein Knoten sich zugehörig fühlt: Per Auto-Completion lassen sich hier die entsprechenden Rollen zuweisen. Für Charlie ist das »kickstack::node::network« und für Bob »kickstack::node::compute« ; alle anderen Rollen landen bei Alice. Am Ende steht eine Reihe von Aufrufen des Puppet-Agents auf Alice, Bob sowie Charlie an. Falls die Puppet-Agents dort nicht ohnehin im Daemon-Modus und dauerhaft laufen, müssen gegebenenfalls mehrere Puppet-Runs hintereinander folgen, um alle Rollen sinnvoll anzuwenden (zur Erinnerung: Puppet versteht Abhängigkeiten, führt also pro Puppet-Run nur die Aufgaben aus, die nicht von einer unerfüllten Abhängigkeit betroffen sind).

Das war's: Nach den abschließenden Puppet-Runs findet sich im Dashboard auf der linken Seite einerseits die Information, dass nun jede Rolle innerhalb der Kickstack-Klasse einmal vergeben ist (Abbildung 4). Und OpenStack selbst läuft bereits: Das OpenStack-Dashboard ist unter »http://IP-des-Dashboard-Knotens/horizon« zu finden, im konkreten Beispiel von Alice also unter »http://192.168.122.111/horizon« . Die für den Login benötigten Zugangsdaten finden sich im File »openstackrc« , das auf dem Knoten mit der Auth-Rolle in »/root« liegt. Eine Aufgabe nimmt Kickstack dem Admin allerdings nicht ab: Das Anlegen von Netzwerken in Neutron – das lässt sich entweder per Skript oder per Dashboard im Nachhinein manuell erledigen. Gleiches gilt für das Einspielen eines Images – zum Testen empfiehlt sich CirrOS [6].

Abbildung 4: Sind alle Node-Rollen zugewiesen, ist das über die Klassenübersicht links im Puppet-Dashboard erkenntlich.

Ä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 /2020