© Sergey Gavrilichev, 123RF

Großrechnern, Unix und Linux ist gemein, dass sie einen Teil ihrer Aufgaben nicht auf Benutzeranforderung hin erledigen, sondern automatisiert. Cron ist der simpelste Job-Scheduler. In der Enterprise-Klasse, die sich durch ausgefeilte Ablauf- und Überwachungsfunktionen abhebt, spielt das hier vorgestellte Schedulix.

Job-Scheduling war und ist auf Mainframes und auf Midrange-Systemen unverzichtbar. Aber auch sonst sind auf Servern automatisch gesteuerte Abläufe gängig. Mehr als die Hälfte aller geschäftskritischen Operationen – angefangen bei der Archivierung über Backups und Reports bis zur Verwaltung des Warenbestands in Unternehmen aller Branchen – sollen als Batchprozesse ablaufen. Laut einer Studie von BMC, Hersteller einer Agenten-losen Schedulinglösung, liegen beispielsweise jeder Webtransaktion durchschnittlich mehr als zehn Batchprozesse zugrunde.

Weitverbreitetes Scripting

Viele kleine und mittlere Unternehmen lösen Aufgaben der Ablaufsteuerung von Prozessen mit Skripten (Bash, Perl, Python et cetera). Die so realisierte Ablaufsteuerung sorgt dafür, dass das System jeden Prozess koordiniert, synchronisiert und in der richtigen Reihenfolge abarbeitet. Sollen zwei Prozesse A und B nacheinander laufen, könnte der Admin sie hintereinander in ein Shellskript packen. Muss er zudem sicherstellen, dass Prozess B mit gültigen Daten arbeitet, muss er dafür sorgen, dass B nicht startet, wenn A einen Fehler meldet. Die Fehlerbehandlung macht das Skript natürlich komplexer, aufwändiger zu testen und schwerer les- und wartbar.

Zudem müsste der Admin das Skript dahingehend erweitern, dass es sich merkt, welche Teile schon abgearbeitet sind. Ohne ein solches Gedächtnis müsste der Job-Verantwortliche per Hand das Skript neu starten, wenn etwa Programm B mit einem Fehler abbricht, nachdem Programm A schon vier Stunden gelaufen ist. Er kann sich nun aussuchen, ob er mit den vier verlorenen Stunden leben kann oder ob er temporär schon abgearbeitet Teile im Skript auskommentiert, was aber das Fehlerrisiko erhöht.

Ein Skript-Gedächtnis ließe sich mit Hilfe eines Step-File implementieren. Ein solches müsste vor dem ersten Aufruf und nach einem Abbruch initialisiert werden. Zudem bedürfte auch das Lesen und Schreiben des Fortschritts einer eigenen Fehlerbehandlung.

Das Beispiel macht deutlich, dass sich eine per Scripting realisierte Ablaufsteuerung bereits bei sehr einfachen Aufgaben schnell zu einem veritablen Programmierprojekt entwickelt und zudem schlecht zu warten ist. Die Praxis zeigt, dass eine Skript-gesteuerte Ablaufsteuerung bei einer Handvoll Jobs noch handhabbar bleibt, bei einigen Tausend Prozessen aber zu einer komplexen Entwicklungsaufgabe anschwillt. Genau hier entsteht der Raum für das Enterprise Job Scheduling,

Darunter versteht man in der IT eine Software zum Planen, Steuern, Überwachen und Automatisieren der Ausführung voneinander abhängiger Programme oder Prozesse. Ein Job-Scheduling-System vermag mehr als ein Cron-Dienst, der Prozesse zeitgesteuert startet. Um einen stabilen Betrieb abhängiger Jobs zu gewährleisten, bedarf es weiterer Funktionen, etwa einer Übergabemöglichkeit von Steuerinformationen, einer Überwachungsoption oder einer Gelegenheit für den Operator einzugreifen. Auch eine Ressourcenkontrolle, das Ermöglichen von Parallelität und eine verteilte Ausführung sind wünschenswert.

So wundert es nicht, dass der Markt entsprechend optimierte Produkte vorhält: IBM Tivoli Workload Scheduler [1], Entire Operations [2] der Software AG oder BMCs Control-M-Suite [3]. Insgesamt ist die Auswahl verfügbarer Lösungen mit und ohne ERP-Support nicht gerade klein [4]. Die genannten Programme arbeiten in der Regel betriebssystemunabhängig und können das Ausführen von Programmen unter Windows, Unix, Linux überwachen und steuern.

Schedulix und BIC Suite

In dieselbe Kategorie gehören das kostenlose und unter Open-Source-Lizenz stehende Enterprise-Ressource-Scheduling-System Schedulix [5] und dessen kommerzielle Variante BIC Suite [6]. Beide sind anhand der Anforderungsprofile zahlreicher Kunden des seit 1997 als Dienstleister für Consultingprojekte im Datenbankumfeld aktiven Herstellers Independ IT Integrative Technologies GmbH [7] entstanden. Seit 2001 widmet sich Independ IT ausschließlich BIC Suite und Schedulix.

Die aktuelle Software ist laut Hersteller jedoch kein Abfallprodukt aus dem Projektgeschäft, sondern eine (rein unter Linux entstandene) Neuentwicklung von Grund auf, wobei “neu” bei einem Entwicklungszeitraum von einem Jahrzehnt natürlich relativ ist. Zu den großen Kunden des Unternehmens gehören ein internationaler Telekommunikationskonzern und ein soziales Netzwerk im deutschsprachigen Raum.

Schedulix adressiert vorrangig kleine und mittlere Unternehmen. Die Software ist für Linux-Umgebungen konzipiert und wird nur im Quellcode ausgeliefert. Wer einen Schedulix-Server und -Agenten dagegen auf einem Windows-System einsetzen will, kann bei Independ IT einen 3- bis 4-tägigen Workshop buchen. Teilnehmern installiert das Unternehmen dabei eine Lizenzkosten-freie Version der Basic-Edition von BIC Suite in der Umgebung ihrer Wahl, beispielsweise Windows oder Solaris.

Die Arbeitsweise

Schedulix arbeitet im Gegensatz zu traditionellen Job-Scheduling-Systemen dynamisch und errechnet unter Berücksichtigung von Randbedingungen wie Prioritäten oder Ressourcenverfügbarkeit laufend, welche Prozesse es zur Ausführung bringen könnte. Konkret arbeitet Schedulix mit einem benutzerdefinierten Exit-Status-Modell. Neben den frei definierbaren Exit-Status berücksichtigen definierte Jobs Abhängigkeiten zu anderen Jobs, was die Ausführungsreihenfolge in Teilschritten steuerbar macht.

Anwender können beim Modellieren der Abläufe Variablen und Parameter, Sequenzen, Verzweigungen in alternative Teilabläufe oder Schleifen verwenden. Als Schleifen- oder Verzweigungsbedingungen kommen der Exit-Status oder konfigurierbare Trigger in Betracht. Batches oder Jobs lassen sich beim Submit sowohl statisch als auch dynamisch parametrisieren. Benutzer bekommen außerdem Unterstützung bei der Synchronisation und bei der Ausnahmebehandlung. Zwei Besonderheiten der Software sind die Möglichkeit zur hierarchischen Ablauf-Modellierung sowie zum Zerlegen von Programmen oder Skripten in kleinere Einheiten mit klar abgegrenzter Funktionalität (siehe Kasten “Process Decomposition”).

Hinsichtlich paralleler Prozesse zeigt sich Schedulix gerüstet. Die Funktion »Dynamic Submit« submittet (Teil-)Abläufe von Jobs dynamisch und parallelisiert sie so. Ferner ist es möglich, dynamische Submits von Batches und Jobs mittels Exit-Status abhängiger Trigger zu automatisieren. So lassen sich zum Beispiel Benachrichtigungen oder ähnliche automatisierte Reaktionen auf Ablauf-Ereignisse implementieren. Darüber hinaus können Nutzer mit Hilfe von »System-Ressourcen« abhängig von der Ausführungsumgebung deren Ressourcen in »Einheiten« teilen und zuteilen. Mit einem »Ressource Requirement« lässt sich zudem für jeden Job die Auslastung einer Ressource begrenzen (Load Control).

Jobs sind mit Prioritäten belegbar, um bei Ressourcenmangel Vor- oder Nachrangigkeit zu anderen Jobs zu organisieren. Die Dokumentation beschreibt, dass es im Zusammenspiel von statischen und Systemressourcen möglich ist, Jobs in Abhängigkeit der aktuellen Ressourcen-Verfügbarkeit automatisch auf mehrere Ausführungsumgebungen zu verteilten, also ein Load Balancing der Jobs zu realisieren.

Ferner kennt Schedulix so genannte Synchronizing Ressources. Diese fordern unterschiedliche Lock Modes (Nolock, Shared, Exclusive) an, die ehemals voneinander unabhängig gestartete Abläufe nachträglich synchronisieren. Einer Synchronizing Ressource kann der Admin zudem ein Status-Modell zuordnen und damit das Ressource-Requirement Status-abhängig definieren. So lassen sich abhängig vom Exit-Status eines Jobs automatische Statusänderungen einrichten.

API und Architektur

Schedulix besitzt ein offenes und gut dokumentiertes API, über das alle Komponenten mit dem Job-Scheduling-Server kommunizieren. Die Bedienung ist daher im Prinzip aus beliebigen Nutzerprogrammen möglich. So können Jobs beispielsweise per API beliebige Result-Variablen setzen. Die kann anschließend ein Monitoringprogramm gezielt auswerten, was dort zu besseren Resultaten und mehr Übersichtlichkeit führt. Mit dem relationalen Repository, dem API und dem Verwenden offener Standards wie Java, JDBC und SQL ist Schedulix für eine Integration in viele Systemumgebungen gut gerüstet.

Schedulix besteht im Wesentlichen aus dem in Java geschriebenen Schedulix Job Scheduling Server im Zentrum der Architektur, der für sämtliche logischen Funktionen des Job-Scheduling zuständig ist. Der Server legt die Daten für seine Konfiguration, die Modellierung, Prozesszustände, Protokollierung und so weiter kontinuierlich und ausschließlich in einer relationalen Datenbank ab. Schedulix unterstützt mit dem zugehörigen JDBC-Treiber PostgreSQL, MySQL oder Maria DB und Ingres. Die kommerzielle Variante BIC Suite versteht sich zusätzlich mit Oracle, IBM Informix, IBM DB2 und Microsoft SQL Server. Schedulix setzt mindestens Oracle (Sun) Java 1.7 SE JRE voraus.

Selbst installieren

Das Aufsetzen einer Schedulix-Umgebung an sich, also das Übersetzen und Installieren aller benötigten Komponenten, ist zwar nicht per Klick zu haben, mit Hilfe der umfangreichen Dokumentation aber für jeden Admin beherrschbar. Das gesamte System benötigt weder für die Installation noch für den Betrieb Rootrechte auf den beteiligten Systemen. Sind Jobserver und Datenbank installiert, das entsprechende Environment passend eingerichtet und die Datenbank gestartet, läuft der Job-Scheduling-Server mit »server-start« los.

Sind auch das Zope-basierte Webinterface installiert und der Applikationsserver gestartet, gelingt der Zugriff auf das Webinterface über die URL »http://localhost:8080/SDMS« (alternativ via SSL). Für erste Gehversuche empfiehlt es sich, die umfangreiche Beispielsammlung zu installieren, wie in der Installationsbeschreibung erläutert. Die Beispiele sind anschließend im Navigator anwählbar (Abbildung 1).

Der Schedulix Job Server lässt sich auch einer Client-Server-Architektur folgend installieren, welche die Client-Installationen auf mehrere Hosts verteilt. Die Clients brauchen die Programmbibliothek Java Native Access (JNA). Diese erlaubt den Zugriff auf plattformspezifische dynamische Programmbibliotheken (Shared Libraries, bei Windows DLLs), ohne dass plattformspezifischer Code zu schreiben wäre wie bei JNI.

Abbildung 1: Schedulix-Einsteigern erschließt sich die Arbeitsweise am besten anhand der Beispiele.

An der Oberfläche

Schedulix ist vollständig über eine Weboberfläche bedienbar, bringt aber auch eine CLI-Schnittstelle samt eigener Kommandosprache mit. Das durchgängige Verwenden von Authentifizierung aller Nutzer und Komponenten gewährleistet die Sicherheit. Das per HTTP oder HTTPS zugängige Interface für eine grafische Bedienung ist auf Basis des Zope-Applications-Servers implementiert.

Der Python-Quellcode für das Webfrontend ist komplett offen, auch bei der BIC Suite. Dass die Installationsanleitung der (noch) aktuellen Schedulix-Version 2.6.1 vom März 2015 [8] als Build-Voraussetzung auch einen C/C++-Compiler nennt, liegt am Java Jobexecutor (»obexecutor.c« ), einer kleinen Komponente des Jobservers.

Nach dem erfolgreichen Login präsentiert das System den Main-Desktop, das Hauptfenster der Weboberfläche. Deren Design ist von der Zope-Python-Architektur geprägt und entsprechend unmodern. Von aktiven Ajax-Funktionen, die das Look & Feel einer nativen Desktopapplikation imitieren, ist weit und breit nichts zu sehen. Auch ein explizit zu betätigender Refresh-Button zum Holen der Objekte-Liste vom Server ist sicher nicht State of the Art.

Ihre mehr als zehnjährige Geschichte hat der Funktionsvielfalt und -qualität der Software insgesamt zweifellos gut getan, beim Oberflächendesign erweist sich die Historie nach Ansicht der Tester als Ballast. Independ IT – der Misere offenbar schon länger bewusst – hat (kurz nach dem Linux-Magazin-Test) die Oberfläche einem Relaunch unterzogen. Die Abbildungen 2 und 3 zeigen einen Vorher-nachher-Vergleich.

Vom etwas altbackenen, der Zope-Python-Architektur geschuldeten Design mal abgesehen, fördert eine Matrix-ähnliche Ansammlung von 20 (gestrig designten) Icons nicht gerade die Übersichtlichkeit. Auch den Workflow spiegelt die Anordnung der Elemente nicht intuitiv wider. Bei genauerem Hinsehen hat das Ganze aber doch System. So finden sich im unteren Teil in der Hauptsache Module für das Festlegen von Templates und Definitionen wie Exit-State-Definitionen, Exit-State-Profile, Ressource-State-Definitionen, Ressource-State-Mapping und so weiter.

Im mittleren Teil zeigt das GUI die Module zum Anlegen von Ressourcen, Environments sowie Benutzer und Gruppen an, oben die jeweiligen Ausgangspunkte zum Submit oder Ausführen von Batches und Jobs. Für den produktiven Einsatz ist es trotzdem unerlässlich, sich anhand der umfangreichen Dokumentation und der mitgelieferten Beispiele in das Bedienkonzept und die Arbeitsweise von Schedulix einzuarbeiten. Gestandene Admins dürfte dies zwar nicht abschrecken, trotzdem sind die geschätzten Kosten von vier bis fünf Tagessätzen für einen Einführungsworkshop sicher gut investiert, zumal der Kunde dann BIC Suite Basic frei Haus geliefert und installiert bekommt.

Abbildung 2: Hier das altbackener Design der Weboberfläche, …

Abbildung 3: … und nun die kommende, komplett überarbeitete Version.

Ein praktisches Beispiel

Viele Unternehmen erzeugen täglich aus Datenbanken Reports für die Geschäftsleitung und sichern ihre Datenbanken. Die dabei involvierten Vorgänge wie das für jede Report erforderliche Aggregieren der Daten stehen mindestens im zeitlichen Zusammenhang, meist aber auch in sachlichem. Vorstellbar ist, dass aus den aggregierten Daten ein PDF entsteht, auf das die Geschäftsleitung über einen im Intranet veröffentlichten Link zugreifen darf. Zudem soll während der Sicherung der Datenbank keine Aktivität auf der Datenbank stattfinden.

Für das Modellieren etwa der Report-Zusammenstellung sind nach Analyse der Problemstellung drei voneinander abhängige Schritte erforderlich. Die bilden im hierarchischen Modellierungskonzept von Schedulix so genannte Parent-Child-Beziehungen zum Masterjob »REPORT« dar. Zum Abbilden in Schedulix ist zunächst eine Umsetzung der numerischen Exitcodes auf logische Zustände zwingend. Wer nicht selbst Hand anlegt, bekommt das in Schedulix vorinstallierte klassische Unix-Mapping, das den Exitcode 0 als Success und alle anderen Codes als Failure wertet.

Mit logischen Zuständen zu arbeiten hilft jedoch, den Ablauf zu dokumentieren. Im GUI zuständig sind die Module »Exit State Definition« und »Exit State Mapping« . Ferner muss der Bediener im Modul beziehungsweise Menü »Environments« festlegen, in welcher Umgebung die Prozesse auszuführen sind. So könnte etwa »Server_1« für das Reporting zuständig sein, während auf »Server_2« das Datenbanksystem läuft.

Vorteile des GUI sind die visuelle Darstellung von Abhängigkeiten als Pfeile und die Möglichkeit, Abhängigkeiten oder Verzweigungen in der Job-Hierarchie mit der Maus zu verändern (Abbildung 4). Für das GUI spricht drittens, dass es den Fortschritt eines Ablaufs sichtbar macht und außerdem schnell erfassbar ist, welcher Schritt gerade ausgeführt wird und wie lange und mit welchem Erfolg die vorherigen Schritte gelaufen sind.

Abbildung 4: Die visuelle Darstellung von Abhängigkeiten.

Meta-Ebenen

Zum Verständnis der Arbeitsweise mit Schedulix ist es wichtig, die Definitions von der Ausführungsebene zu unterscheiden (Abbildung 5). Auf der Definitionsebene gibt es so genannte Job Definitions, die ihrerseits Ressource Requirements besitzen beziehungsweise stellen. In Schedulix sind solche Requirements nicht an bestimmte Ressourcen gebunden, sondern an so genannte Named Ressources, die Anwender in den Ressource Definitions zuordnen.

Abbildung 5: Der Zusammenhang zwischen Definitions- und Ausführungsebene.

Durch eine Submit-Operation wird aus einer Job Definition ein Job, also eine Instanz der zugehörigen Job Definition. Durch Erzeugen von Instanzen einer Named Ressource in einer Ausführungsumgebung (Jobserver) entstehen Ressources. Erst wenn ein Job (eine Submitted Job Definition) durch das Scheduling-System zur Ausführung einer oder mehrerer möglicher Ausführungsumgebungen zugeordnet wird, entsteht die Verknüpfung (Ressource Allocation) von Jobs und Ressourcen (Instanzen von Named Ressources).

Fazit

Traditionelle Scheduling-Systeme orientieren sich an einem definierten Tagesablauf. Da das Job-System bei jeder Störung den Tagesablauf neu berechnen muss, ist diese Arbeitsweise nach Ansicht der Schedulix-Macher ineffektiv.

Deren System setzt dem eine dynamische Architektur entgegen, welche die Konsequenzen der aktuellen Rahmenbedingungen fortlaufend neu berechnet. So bietet Schedulix andere Möglichkeiten, das Systemverhalten sich ändernden Anforderungen anzupassen und vorhandene Ressourcen effizient zu nutzen. An einer Lösung für das etwas unzeitgemäße Design des Web-GUI arbeitet der Hersteller Independ IT augenscheinlich.

Schedulix und die kommerzielle Schwester BIC Suite erfordern wie alle Enterprise-Schuduling-Lösungen eine gründliche und damit aufwändige Einarbeitung in Konzept und Arbeitsweise. Kleine und mittelständische Firmen, die mit ihrer bislang per Skript und in Eigenregie realisierten Ablaufsteuerung einen Leidensdruck aufgebaut haben, werden selbst evaluieren müssen, ob der erreichbare Nutzen und der Aufwand für eine Schedulix-Einführung (Open Source und nur in reinen Linux-Umgebungen) oder für die BIC Suite (mit Kosten verbunden, aber Multiplattform) für sie in einem guten Verhältnis stehen. Die ökonomische Logik hängt eventuell davon ab, ob das eigene Unternehmen den Aufwand für Job Scheduling und Monitoring gesondert budgetiert oder nicht.