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)

Fazit

Kickstack ist eine willkommene Abwechslung für alle, die OpenStack gerne ausprobieren möchten, aber die aufwendige und sehr komplexe Installation scheuen. Denn die weicht bei Kickstack der Installation von Puppet sowie der benötigten Kickstack-Module. Tatsächlich lässt sich ein grundlegendes Puppet-Setup bestehend aus einem Master sowie mehreren Puppet-Clients verhältnismäßig schnell aufziehen. Obendrein ist die Konfiguration der einzelnen Knoten zu OpenStack-Maschinen über das in Puppet integrierte Dashboard deutlich komfortabler als das manuelle Einrichten der Dienste. Und wer seine OpenStack-Installation später um zusätzliche Rechner erweitern möchte, tut das ebenfalls im GUI per Mausklick ( Abbildung 6 ).

Abbildung 6: Gut zu erkennen sind die OpenStack-Dienste, deren Konfiguration von Kickstack stammt.

Wer OpenStack übrigens unter Nutzung von Kickstack ausprobieren und testen möchte, kann das auch auf Grundlage fertiger VM-Abbilder tun, die für VirtualBox unter [8] zur Verfügung stehen. In diesen ist die Puppet-Master-Client-Installation bereits fertig, sodass direkt nach dem Starten der VMs alle Kickstack-Funktionen zur Verfügung stehen. Vom Importieren der Abbilder bis zur fertigen kleinen OpenStack-Cloud sind es auf aktuellen Rechnern so gerade ein paar Minuten.

Allerdings ist für Kickstack das Ende der Fahnenstange noch nicht erreicht, was wünschenswerte Features angeht: Insbesondere das Thema Hochverfügbarkeit kommt bei der Lösung derzeit noch zu kurz; das ist einerseits dem Umstand geschuldet, dass das OpenStack-Projekt selbst erst eine Vorstellung entwickeln musste, wie es Hochverfügbarkeit denn umsetzen wollte, und andererseits auch dadurch zu erklären, dass die typischen HA-Werkzeuge wie Pacemaker derzeit eher schlecht als recht in Puppet integriert sind.

Abbildung 5: Nach der Installation von OpenStack per Kickstack ist es nötig, für den admin-Tenant ein Netzwerk anzulegen.

Design-Entscheidung: Puppet oder Chef?

Die Frage, ob Setups lieber auf Puppet oder auf Chef setzen sollten, hat mittlerweile die Qualität eines Glaubenskrieges erreicht. Ãhnlich hitzige Debatten sind sonst nur mit den Ur-Admin-Themen zu erreichen – also Vi versus Emacs, Ubuntu versus Debian und Java oder kein Java. Im Falle von Kickstack hat Florian Haas Puppet gewählt. Auch Packstack, das Red-Hat-Gegenstück zu Kickstack, setzt auf Puppet. Warum setzen die OpenStack-Entwickler und mit OpenStack arbeitende Firmen offensichtlich auf Puppet und vernachlässigen Chef?

Am grundsätzlichen Design beider Lösungen kann es kaum liegen, denn zwar arbeiten Chef und Puppet unter der Haube anders, erreichen aber letztlich das gleiche Ziel. Beide Systeme setzen auf eine Architektur aus Servern und Clients, beide setzen auf eine eigene Syntax, wenn es darum geht, Befehle zu definieren.

Die Arbeitsabläufe unter der Haube unterscheiden sich freilich dahingehend, dass Puppet sich selbst um die Abhängigkeiten einzelner Arbeitsschritte kümmern kann, während Chef diese Funktion nicht beherrscht. Bei Puppet ist es also möglich, durch einen entsprechenden Eintrag im Manifest festzulegen, dass Schritt A vor Schritt B zu erfolgen hat – in Chef müssen Schritt A und Schritt B in der richtigen Reihenfolge im Cookbook stehen, sonst steigt Chef aus.

Dieses System der »Eventual Consistency« hat Befürworter sowie erbitterte Gegner – im OpenStack-Kontext fallen die Unterschiede aber kaum auf, können also nicht der ausschlaggebende Punkt dafür sein, dass Auto-Deployment-Umgebungen für OpenStack derzeit nur in Form von Puppet-Lösungen bestehen. Der Grund ist letztlich viel banaler: Puppet ist insgesamt deutlich besser an OpenStack gekoppelt, als Chef es ist. Ein Blick auf die für Puppet zur Verfügung stehenden Module macht das sehr deutlich: Für alle Core-Komponenten finden sich im Internet Module auf dem neuesten Stand, die regelmäßig gepflegt werden und so letztlich den größten Teil der benötigten Funktionen bereits selbst umfassen.

Chef ist im Vergleich dazu deutlich im Hintertreffen, denn zwar sind Module für einige der Kernkomponenten vorhanden, aber offiziell ist von diesem Code nichts, außerdem fehlen Module für wichtige Teile wie den Netzwerkdienst Neutron. Dass Erweiterungen wie Packstack und Kickstack auf Puppet setzen, hat also maßgeblich damit zu tun, dass hier einfach deutlich mehr Vorarbeit bereits geschehen ist, als bei Chef. Aber keine Panik: Wer sich mit Puppet partout nicht anfreunden möchte und eher auf Chef setzt, dürfte in absehbarer Zeit Abhilfe durch Suse erhalten.

Denn zusammen mit einigen Entwicklern von Dell arbeitet Suse gerade massiv an Crowbar, das auf Chef aufbaut und ebenfalls eine Lösung werden soll, die automatische OpenStack-Deployments ermöglicht. Im Vergleich zu Kickstack und Packstack kommt Crowbar sogar mit einigen Zusatzteilen wie einem vorkonfigurierten Nagios daher. Nähere Details zu Crowbar finden sich auf [7] .

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei hastexo. Er beschäftigt sich dort intensiv mit den Themen HA, Distributed Storage und OpenStack. In seiner Freizeit pflegt er Pacemaker für Debian.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Mirantis gibt Deployment-Tools für OpenStack frei

Die Tool-Sammlung mit dem Namen "Fuel" ermöglicht die Bereitstellung einer Cloud-Infrastruktur auf der Basis von OpenStack.

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