Flinkes System-Management aus den Puppet Labs

© jeancliclac, 123RF

Großes Orchester

Admins kennen das Problem: mal schnell ein Kommando auf einer Vielzahl von Systemen ausführen. Mit dem Marionette Collective Framework (MCollective) steht hierfür ein mächtiges Tool aus den Puppet Labs zur Verfügung. Dank modernster Technologie setzt es sich deutlich von der Konkurrenz ab.
Was das Backup wert war, erweist sich, sobald man es versucht ganz oder teilweise wiederherzustellen. Spätestens dann macht sich die Wahl des richtigen Tools ... (mehr)

Ähnlich wie das in ADMIN 02/2011 [1] vorgestellte Func bietet MCollective [2] die Möglichkeit, beliebige Job-Ketten auf einer Vielzahl von Systemen parallel zu starten. Im Unterschied zu Func oder beispielsweise Fabric [3] und Capistrano [4] benutzt MCollective eine Middleware auf Basis der Publish-/Subscribe-Methode, um Jobs auf den einzelnen Knoten zu starten. Als Middleware unterstützt das Framework dabei sämtliche auf STOMP (Apache Streaming Text Orientated Messaging Protocol) basierenden Server-Implementationen beispielsweise ActiveMQ [5] und RabbitMQ [6].

Die auf dem Management-System erzeugten Job-Ketten werden erst einmal nur an den Middleware-Rechner gerichtet. Von hier aus versendet dieser die Anfragen dann mittels Broadcast. Über entsprechende Filter kann der Admin dabei nur Subsets der vorhandenen Knoten ansprechen. Als Lowlevel-Protokoll zwischen den beteiligten Systemen kommt Simple-RPC zum Einsatz, das sich auch um die Authentifizierung, Autorisierung und das Auditing der einzelnen Requests (Abbildung 1) kümmert.

Abbildung 1: Eine Middleware sorgt für den schnellen Austausch von Nachrichten zwischen den einzelnen Knoten und einem Management-System.

Darauf setzt dann das Messaging-Protokoll der Middleware auf. Die eigentlichen Aktionen führt MCollective mithilfe von Agents auf den einzelnen Knoten aus. Das Framework bietet bereits eine Vielzahl fertiger Agents an, und mit etwas Ruby-Kenntnissen sollte es kein großes Problem sein, eigene Agents mit zusätzlichen Funktionen zu schreiben, Die MCollective-Website bietet hierfür ausführliche Beispiele [7] an. In Kombination mit einem Konfigurationsmanagement-Tool wie beispielsweise Puppet [8], stellt MCollective ein sehr mächtiges, aber dennoch leicht zu verwaltendes System-Management-Tool dar.

Dank der eingesetzten Middleware ist MCollective in der Lage, Jobs mit sehr hoher Geschwindigkeit auszuführen. Der Autor benutzt das Framework beispielsweise in einer Umgebung mit über 3000 Systemen, wobei die Ausführung eines Jobs auf sämtlichen Knoten selten länger als 30 Sekunden dauert.

Ein weiterer Vorteil sind die Yaml-basierten Facts-Dateien, die eine Möglichkeit darstellen, Systemen bestimmte Eigenschaften beispielsweise einem Rechenzentrum oder Land zuzuordnen. Die Eigenschaften können beim Generieren von Jobs als Filter-Kriterium dienen – somit entfällt die lästige Angabe von Rechner- oder Domänennamen. Kommt Puppet beim Konfigurationsmanagement zum Einsatz, hat der Admin die Möglichkeit, auch die Puppet-Classes als Filter-Kriterium zu verwenden.

Installation und Konfiguration

Unter [9] stellt Puppet Labs verschiedene Pakete für RPM- und Deb-basierte Systeme bereit. Um zu entscheiden, welches Paket auf welchem System zu installieren ist, hier noch einmal eine Auslistung der einzelnen Funktionalitäten. Die Beispiele basieren auf Red Hat Enterprise Linux 5, gelten aber genauso für alle anderen unterstützten Systeme, lediglich die Paket-Namen sind hier teilweise leicht anzupassen:

  • Management-System (Workstation): Dieses System dient als Client-System für den Administrator, der hier Job-Ketten in Auftrag gibt. Benötigt die Pakete »mcollective-common« und »mcollective-client« .
  • Middleware: Hier läuft das Messaging-System. Benötigt neben der eigentlichen Middleware (beispielsweise ActiveMQ) ebenfalls das Paket »mcollective-common« . Um alle Ruby-Abhängigkeiten auflösen zu können, sollte auf diesem System ebenfalls der Zugriff auf das EPEL-Repository [10] möglich sein.
  • Nodes: Hierbei handelt es sich um die eigentlichen Systeme, die MCollective verwalten soll. Diese benötigen die Pakete »mcollective-common« und »mcollective« .

Im ersten Schritt geht es an die Installation des Middleware-Servers. In diesem Artikel kommt ActiveMQ als Middleware-Implementierung zum Einsatz. Am einfachsten ist es, für die unter [9] und [10] aufgeführten Installationsquellen ein Yum-Repository einzurichten. Die Installation des Messaging-Systems sollte dann mittels »yum install activemq« ohne Probleme funktionieren. Das RPM-Frontend Yum löst dabei sämtliche Abhängigkeiten auf und installiert die Pakete auf Nachfrage. Listing 1 zeigt ein Beispiel für die Konfigurationsdatei des ActiveMQ-Servers, der mindestens in Version 5.4 vorliegen sollte. Der Benutzer-Account, mit dem ein MCollective-Client auf den Server zugreift, ist entsprechend anzupassen. ActiveMQ kann auch gegen einen LDAP-Server authentifizieren, der Einfachheit halber kommt in diesem Artikel jedoch lediglich ein lokaler Account in der Konfigurationsdatei des Servers zum Einsatz. Um einen Single-Point-of-Failure (SPoF) zu vermeiden, bietet der Server auch eine High-Availability-Konfiguration an, die unter [11] näher dokumentiert ist. Ein abschließendes »service activemq start« erweckt den Server zum Leben.Auf dem Management-System sind die beiden Pakete »mcollective-client« und »mcollective-common« zu installieren. Ersteres enthält die Konfigurationsdatei »/etc/mcollective/client.cfg« (Listing 2) und ist für die Kommunikation mit der Middleware zuständig. Das zweite Paket stellt die Konfigurationsdatei »/etc/mcollective/server.cfg« (Listing 3) bereit, über die MCollective Zugriff auf die einzelnen Server-Facts (Listing 4) erhält, sofern sie definiert sind. Sicherheitsbewusste Admins entfernen sensible Informationen aus der globalen Client-Konfigurationsdatei und legen stattdessen eine zusätzliche Konfigurationsdatei »~/.mcollective« auf dem Management-System an. Diese muss jedoch sämtliche Einstellungen aus der globalen Konfiguration enthalten. Für die Server-Konfigurationsdatei bietet es sich an, die Rechte entsprechend zu ändern, für die Client-Konfigurationsdatei ist dies leider nicht möglich.

Listing 1

/etc/activemq/activemq.xml

 

Listing 2

/etc/mcollective/client.cfg

 

Listing 3

/etc/mcollective/server.cfg

 

Listing 4

/etc/mcollective/facts.yaml

 

Auf den mit MCollective verwalteten Systemen sind ebenfalls die Pakete »mcollective-common« (stellt sozusagen die Server-Komponente des Frameworks zur Verfügung) und »mcollective« zu installieren. Die Server-Konfiguration ist dabei identisch mit der des Management-Systems, die Facts-Datei ist entsprechend anzupassen. Der Server startet schließlich nach dem Aufruf von »service mcollective start« . Um die Konfigurationsdatei sowie angepasste Facts-Dateien auf die einzelnen Systeme zu verteilen, bietet es sich an, ein Tool wie Puppet oder Cfengine zu verwenden. Auch ein Red-Hat-Satellite- oder Spacewalk-Server lassen sich für diesen Zweck einsetzen.

Sind die ersten Systeme mit dem MCollective-Server installiert, kann der Admin erste Tests durchführen und überprüfen, ob die Kommunikation mit dem Messaging-System funktioniert (Listing 5). Die Tests finden dabei auf dem Management-System mithilfe des Tools »mco« statt, dem MCollective Controller.

Listing 5

Kommunikationstest

 

Durch das modulare Konzept von MCollective hat der Admin die Möglichkeit, auf den einzelnen Knoten diverse Agenten aufzurufen. Je nachdem, welche Aufgabe zu bewerkstelligen ist, kommen dabei unterschiedlichste Agenten zum Einsatz, die meistens eigene Client-Tools auf dem Management-System besitzen. MCollective bringt bereits einige Agenten mit, weitere stehen über die Community-Page [12] zum Download bereit.

Beispielsweise gibt es auf dieser Seite das Plugin »mc-service« , das einen in Ruby geschriebenen Agenten »services.rb« zur Verfügung stellt, der auf den Nodes im Verzeichnis »$libdir/mcollective/agent« liegen muss. Das Verzeichnis »$libdir« ist dabei in der Datei »server.cfg« definiert. Die passende Client-Anwendung »mc-service« findet sich auf dem Management-System im Verzeichnis »/usr/local/bin/« . Listing 6 zeigt einen Probelauf mit »mc-service« .

Listing 6

Plugin mc-service

 

Eigene Agenten in Ruby

Wer auf der Community-Seite von MCollective keinen passenden Agenten für seine Aufgaben findet, kann natürlich auch selbst neue Agenten mit passenden Clients entwickeln. Dafür sind nur paar rudimentäre Ruby-Kentnisse nötig, um alles Weitere kümmert sich das SimpleRPC-Framework, das die grundlegenden MCollective Client- und Server-Strukturen kapselt. Mit dem Tool »mc-call-agent« lassen sich selbst geschriebene Agenten testen, bevor man hierfür einen eigenen Client bereitstellt. Dies kann beim Entwickeln von komplexen Agenten sehr hilfreich sein. Unter [13] findet sich eine Anleitung zum Thema.

Natürlich bietet MCollective auch umfassendes Reporting. Das geht bei einfachen Knoten-Statisken los und endet bei sehr detaillierten Auflistungen bestimmter Eigenschaften der einzelnen Systeme. Das Tool »mc-facts« zeigt beispielsweise Statistiken, basierend auf den Eigenschaften von Systemen, die in der Facts-Datei definiert sind. Auch der MCollective Controller »mco« bietet einige interessante Funktionen zum Reporting.

Ä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