njör.de

Start > Texte > Hochverfügbarkeit unter Unix mit den daemontools

Hochverfügbarkeit unter Unix mit den daemontools

Mit den daemontools von Daniel J. Bernstein (djb) ist es möglich, Serverdienste zu verwalten und hoch verfügbar zu machen. Durch die Steuerung der Dienste mittels der Kommandos aus den daemontools ist man nicht mehr von den Eigenarten des jeweiligen Betriebssystems abhängig. Dadurch ergeben sich einheitliche IT-Prozesse bei der Wartung bzw. Migration. Wenn die Konfigurationsdateien unserer Dienste konsequent in /service/dienst/etc abgelegt werden, lässt sich mit einem einzigen rsync-Kommando die Konfiguration unserer Maschine sichern.

Vorteile der daemontools

Bei der Verwaltung verschiedener Server ergeben sich in der Administration häufig Probleme durch die vielen verschiedenen Startmechanismen. Ob es die rc.d-Skripte der BSD's sind, das alte inittab von Linux oder die neuere Variante init.d, alle müssen mit unterschiedlichen Kommandos eingerichtet und gewartet werden. Es wäre doch schön, egal für welches Betriebssystem, immer die gleichen Mechanismen benutzen zu können, um Serverdienste zu installieren, bzw. zu verwalten.

Hier kommen die daemontools ins Spiel. Auf fast allen unixoiden Systemen können die daemontools relativ einfach installiert werden. Damit steht plattformübergreifend ein Mechanismus zur Verfügung, mit dem die Prozesse für die Verwaltung und Installation von Serverdiensten vereinheitlicht werden können.

Alle Serverdienste die mittels den daemontools gestartet werden, unterliegen einer ständigen Kontrolle. Sollte sich ein Dienst - aus welchem Grund auch immer - beenden, wird dieser durch die daemontools sofort wieder neu gestartet.

Die Syslog-Alternative multilog soll hier nicht unerwähnt bleiben. Sie ist ebenfalls Bestandteil der daemontools und kann Nano-Sekunden genaue Logeinträge erstellen. Auf die Einrichtung von multilog wird hier jedoch nicht weiter eingegangen.

Einrichtung der daemontools

Installation

Die daemontools können nur auf unixioden Betriebssystemen installiert werden. Dazu wird ein C-Kompiler benötigt.

Die Abfolge der Installation gestaltet sich ziemlich kurz, Sourcen von http://cr.yp.to/daemontools/install.html herunterladen, Sourcen entpacken und den build-Prozess starten:

mkdir -p /package
chmod 1755 /package
cd /package
# Achtung: Versionsnummer anpassen
wget http://cr.yp.to/daemontools/daemontools-xxx.tar.gz
gunzip daemontools-0.76.tar
tar -xpf daemontools-0.76.tar
rm -f daemontools-0.76.tar
cd admin/daemontools-0.76

Linux Patch

Unter Linux muss nun noch in die Datei /package/admin/daemontools-xxx/src/error.h wie folgt bearbeitet werden. Die Zeile

extern int errno;

muss gelöscht und direkt danach die Zeile

#include <errno.h>

eingefügt werden.

Nun kann der Kompilerlauf gestartet werden:

package/install

Sollte der Bau fehlerfrei durchgelaufen sein, sind unter Linux die daemontools bereits gestartet (erkennbar an dem Prozess svscan), BSD-Systeme müssen neu gestartet werden.

Serverdienst hinzufügen

Der Dienst svscan arbeitet - gemäß der Unix-Tradition "Alles ist eine Datei" - mit einem Verzeichnis, in dem für jeden Dienst ein Unterverzeichnis angelegt werden muss. In unserem Beispiel wollen wir den sshd über daemontools starten lassen. Dazu legen wir ein Verzeichnis /service/sshd an.

Um zu verhindern, dass daemontools nun bereits diesen Dienst zu starten versucht, legen wir eine Datei an die daemontools sagt, dass der Dienst nicht gestartet werden soll:

touch /service/sshd/down

Der Start des Dienstes erfolgt über die Datei /service/sshd/run, welche aus einem shell-Skript besteht:

touch /service/sshd/run
chmod +x /service/sshd/run
chown root:root /service/sshd/run

Diese Datei muss ausführbar sein und ein exec-Kommando enthalten, damit der aktuelle Prozess durch den des Dienstes überlagert wird.

#!/bin/sh
exec 2>&1
exec /usr/local/sbin/sshd -D

Wichtig ist, keine &-Zeichen (für Hintergrunddienst) oder Pipes (|) in dem run-Skript zu benutzen und den entsprechenden Dienst so zu starten, dass er nicht in den Hintergrund verschwindet.

Viele Serverprogramme bieten entsprechende Optionen an, um dies zu verhindern. Sollte ein Dienst keine entsprechende Option bieten, kann mit dem Zusatzprogramm aus den daemontools fghack der fork() in den Hintergrund verhindert werden. Sauberer ist es jedoch, den Dienst entsprechend über den Sourcecode anzupassen.

Nun können wir die Funktionalität testen, indem wir das run-Skript manuell ausführen. Sollte nun ein Fehler auftreten, können wir die Ausgabe in der Shell sehen und den Fehler abstellen. Wenn der Dienst fehlerfrei startet, können wir in den Produktivbetrieb gehen. Dazu muss die Datei /service/sshd/down gelöscht werden und der Dienst dauerhaft mittels

svc -u /service/sshd

gestartet werden.

Standardisierte Umgebung

Mit den daemontools ist es möglich, einen Serverdienst in einer genau definierten Umgebung zu starten. Umgebungsvariablen, ulimit-Einschränkungen, uid, gid oder globale Lock's werden über die Hilfsprogramme envdir, setuidgid, softlimit und setlock festgelegt.

Auch Abhängigkeiten der Dienste untereinander können berücksichtigt werden. Benötigt der www-Dienst bspw. den php-Dienst zum Laufen, können wir beim Start auf die Verfügbarkeit entsprechend warten:

#!/bin/sh
exec 2>&1
until svok /service/php
do
sleep 1
done
exec /bin/nice -+15 \
/src/apache/bin/httpd -F -f /service/www/etc/lists.conf

Damit ist sichergestellt, dass die einmal eingerichtete Konfiguration auf jedem anderen Betriebssystem unter denselben Einstellungen laufen wird. Der Administrationsaufwand wird somit minimiert, da durch die daemontools ein Layer zwischen Serverdienst und Betriebssystem steht, welches die immer gleichen Schnittstellen zur Verfügung stellt.

Verwaltung von Serverdiensten

Die Verwaltung der Dienste erfolgt über die Programme svc, svok und svstat. Die Programme sind generell so angelegt, dass sie auch mittels shell-Skripte arbeiten können.

Als Argument benötigen alle Programme immer das jeweilige Arbeitsverzeichnis des Serverdienstes, in unserem Beispiel ist das /service/sshd.

# gibt den aktuellen Status des Dienstes aus
svstat /service/sshd

Mittels svc kann ein Dienst gestartet oder gestoppt werden, oder es können Signale zu dem Dienst gesendet werden. Eine komplette Beschreibung der Funktionen gibt es auf der Webseite zu den daemontools.

# startet den Dienst neu
svc -du /service/sshd

Wildcards

Es ist auch möglich, Dienste selektiv neu zu starten oder zu stoppen. Darüber sollte man sich vor der Installation der Dienste Gedanken machen, um dafür geeignete Namen festzulegen. Laufen bspw. auf der Maschine mehrere php-Instanzen, wäre es möglich, sie wie folgt zu benennen:

/service/php-seite1
/service/php-seite2

Mittels

svc -d /service/php*

können nun alle php-Instanzen heruntergefahren werden.

PID Hack

Dadurch, dass wir den aktuellen Status und die Prozess-ID über eine standardisierte Ausgabe herausbekommen können, ist es nicht mehr notwendig, PID-Dateien anzulegen oder die Ausgabe von ps zu verarbeiten. Wir können auf jedem Betriebssystem, auf dem die daemontools laufen, über denselben Weg feststellen, ob ein Dienst gestartet ist, wie lange er bereits läuft und welche Prozess-ID der Dienst hat.

Sicherung

Wenn man nun ein komplettes System auf eine neue Maschine umziehen muss, und wir keinen Einfluss auf das Betriebssystem nehmen können, entfallen beim Einsatz umständliche Anpassungen der Pfade, PID-Dateien und Konfigurationsdateien. Wir brauchen lediglich - nach der Installation von daemontools und unserer Serverdienste - den Ordner /service auf die neue Maschine kopieren, und können die Dienste sofort in Betrieb nehmen.

Dadurch ist man nicht mehr auf ein bestimmtes Betriebssystem angewiesen, kann bei der Ressourcenbeschaffung aus einer größeren Auswahl wählen, die sich letzten Endes auch im Preis niederschlägt.

Auch braucht nicht ständig die Dokumentation und Konfiguration angepasst zu werden, wenn wiedermal ein System meint, bestimmte Standards anders umsetzen zu müssen. Man gewinnt durch den Einsatz der daemontools eine gewisse Zukunftssicherheit des einmal eingerichteten Systems und der damit investierten Arbeitszeit.

Kommentar schreiben

Name

Kommentar