Geplante Tasks automatisch ausführen

Orlando Rosu, 123RF, 123RF

Die Uhr tickt

Regelmäßige Jobs auf Servern zu verwalten kann schnell in viel Arbeit ausufern, vor allem wenn sie auf mehreren Rechnern ablaufen sollen. Einfacher geht's mit dem Open Source Job Scheduler.
High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Zum Tagesgeschäft von IT-Administratoren gehört es, regelmäßig ablaufende Wartungsjobs und andere Skripte einzurichten. In der Unix-Welt ist dafür klassischerweise Cron zuständig, ein im Hintergrund laufender Prozess, der Textdateien einliest, in denen der Admin mit Zeitangaben die auszuführenden Jobs konfiguriert.

Auch wenn im Lauf der Jahrzehnte das Cron-System einige Erweiterungen und Verbesserungen erfahren hat, eignen sich selbst neuere Versionen nur für sehr einfache Job-Terminpläne. Wer kompliziertere Ablaufpläne realisieren will, muss deren Logik in die Skripte auslagern, die Cron ausführt. Viel einfacher wäre es, wenn er keine Wrapper-Skripte bräuchte und sich nicht um die Fehlerbehandlung kümmern müsste.

Einige kommerzielle Produkte bieten solchen Komfort, gehen aber schnell ins Geld. Aber auch die Open-Source-Welt hat hier etwas zu bieten. Dieser Artikel stellt den Open Source Job Scheduler [1] vor und erklärt, wie Sie Gebrauch von seinen besten Features machen.

Bei jeder Scheduling-Software ist die grundlegende administrative Einheit der Job, typischerweise ein Programm oder Skript, das dann abläuft. Meist reicht dafür auch Cron, wenn es um ganz einfache Anforderungen geht, um zum Beispiel jeden Tag zur gleichen Zeit ein Backup zu starten. Auch Jobs, die in kleineren Intervallen ablaufen müssen oder an einem spezifischen Datum, stellen für Cron kein Problem dar.

Cron am Limit

Schwieriger wird es, wenn Abhängigkeiten irgendwelcher Art dazukommen. Dann stößt der Admin schnell an die Grenzen des Cron-Systems, etwa wenn ein Programm beim Eintritt eines bestimmten Ereignisses starten soll. Im Berufsalltag gibt es einige Job-Abläufe, die aus einem Dutzend einzelner Aufgaben bestehen, die in einer bestimmten Reihenfolge abgearbeitet werden müssen. Außerdem darf jeder nachfolgende Schritt nur dann beginnen, wenn der vorherige erfolgreich absolviert ist. Liefe ein späterer Job trotzdem, würde das zu schwerwiegenden Problemen führen. Nicht einmal die neuesten Cron-Versionen sind dazu imstande, das zu leisten, ganz zu schweigen davon, einen solchen abgebrochenen Ablauf irgendwo in der Mitte fortzusetzen.

Ereignisse, die den Start eines Jobs auslösen, können nicht nur das Erreichen eines Zeitpunkts oder das erfolgreiche Beenden eines anderen Jobs sein, sondern beispielsweise auch das Erzeugen einer bestimmten Datei oder überhaupt von Dateien in einem Verzeichnis.

Gerade in verteilten Umgebungen müssen viele Jobs auf mehreren Maschinen gesteuert werden. Es wäre also wünschenswert, wenn der Administrator alle diese Aufgaben von zentraler Stelle aus steuern könnte. Crontab-Dateien lassen sich zum Beispiel per Rsync verteilen, aber das kann schnell in einen administrativen Alptraum ausufern, wenn die Konfiguration der einzelnen Server sich unterscheidet. Auch wenn es Cron-Varianten für Windows gibt, ist die Verwaltung von Jobs über verschiedene Betriebssysteme hinweg nicht so einfach.

Einen Ansatz zur Lösung bietet der Open Source Job Scheduler der Software- und Organisations-Server (SOS) GmbH Berlin [2], der für Linux, Solaris, HP-UX, AIX und Windows erhältlich ist. Er unterstützt mehrere Datenbanken, darunter DB2, Oracle, Microsoft SQL Server, PostgresQL und MySQL. Der Open Source Job Scheduler ist wahlweise unter der GPL-Lizenz oder einer kommerziellen Lizenz erhältlich, die Support und automatisierte Updates einschließt. Abgesehen davon erhält der Anwender in beiden Fällen das gleiche Produkt mit der gleichen Funktionalität.

Die zentrale Komponente der Software ist die Job Scheduler Engine, die auf dem Rechner läuft, der regelmäßige Jobs starten soll. Dieser Schritt unterscheidet sich von der eigentlichen Ausführung des Jobs. Die Dokumentation führt auch einige Methoden auf, Jobs auf einem anderen Rechner auszuführen. Zum Beispiel kann auf diesem auch ein Scheduler laufen, der gegenüber dem ersten als Slave auftritt. Er kann aber ebenso als eigenständiger Scheduler arbeiten. So lassen sich recht einfach verteilte Szenarien mit Load Balancing über mehrere Rechner hinweg realisieren: Eine Aufgabenliste läuft auf einem Hauptrechner ab, der sie dann auf andere Scheduler verteilt.

Staffellauf

Ein Schlüsselkonzept dabei ist die so genannte Order, die wie ein Token funktioniert, das zwischen den Jobs herumgereicht wird. Je nach Konfiguration kann ein Job nicht starten, bevor er nicht seine Order bekommen hat. Im einfachsten Fall funktionieren die Orders wie die Stäbe in einem Staffellauf, die von einem Job zum nächsten wandern. Sie können aber auch Variablen enthalten, zum Beispiel den Namen der gerade bearbeiteten Datei. Der Administrator kann auch Orders mit bestimmten Startzeiten konfigurieren, die das System dann selbst erzeugt und somit den Job startet.

Damit das funktioniert, muss ein Job so konfiguriert sein, dass er überhaupt Orders akzeptiert. Eine Order ist immer mit einer Ablaufkette verknüpft, nicht nur mit einem einzelnen Auftrag. Das heißt, sie wird von einem Job der Kette zum nächsten weitergegeben, startet aber den kompletten Ablauf. Wer einrichten will, dass ein einzelner Job zu gegebener Zeit startet, kann das auch direkt im Job einrichten.

Der Administrator kann Aufgaben über das Job-Scheduler-Editor-GUI (Abbildung 1) konfigurieren oder XML-Dateien direkt editieren. Der Job Editor ist ein Java-GUI, in dem sich Jobs, Ablaufketten und andere Einstellungen editieren lassen. Die ganze Konfiguration ist in XML-Dateien gespeichert, daher genügt es, die entsprechende Datei im Job Editor zu öffnen, um Einstellungen zu verändern. Wer viele Dateien ändern muss, kann auch einen beliebigen Editor dafür verwenden – das geht oft einfach schneller.

Abbildung 1: Die Benutzeroberfläche des Job Editors.

Die XML-Dateien kann der Administrator entweder von Hand auf andere Rechner kopieren oder direkt mit dem Job Editor per FTP speichern. Wenn sie in einem der so genannten Hot Folder landen, sind sie sofort in der Scheduler Engine des anderen Computers verfügbar. Diese Hot Folder überprüft der Scheduler permanent auf Veränderungen hin, zum Beispiel auf neue oder modifizierte Jobs.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite