Prozessablaufsteuerung mit Shell-Skripten
Dieser Artikel ist eine kritische Auseinandersetzung mit dem Einsatz der UNIX-Shell (sh, ksh, bash, . . .) im Rahmen der Prozessablaufsteuerung. Das Auftreten und die Probleme, die in diesem Dokument beschrieben werden, sind konzeptioneller Natur und gelten auch für die Verwendung anderer Skriptsprachen (perl, python, . . .). Es ist keineswegs unsere Absicht, diese Sprachen in ihrer Gesamtheit zu kritisieren. Jede der genannten Sprachen hat ihre Vorteile, und der Autor hat im Laufe seiner Karriere viele erfolgreiche Projekte unter Verwendung solcher Sprachen entwickelt.
Prozessablaufsteuerung
In jeder IT-Abteilung gibt es Aufgaben, die durch die Ausführung von mehreren Einzelprozessen erfüllt werden müssen. Solche Programmabläufe bestehen aus wenigen bis hin zu mehreren hundert Prozessen. Um solche Prozessabläufe durchführen zu können, muss sichergestellt werden, dass jeder einzelne Prozess koordiniert, synchronisiert und in der richtigen Reihenfolge ausgeführt wird. Hierfür wird eine Prozessablaufsteuerung benötigt. In der Praxis werden UNIX-Shells oder andere Skriptsprachen zur Umsetzung solcher Aufgaben verwendet.
Am Anfang ist alles einfach
In der Anfangsphase eines Projekts ist immer alles ganz einfach. Die Anzahl der Prozesse ist gering, sie sind von geringer Komplexität, die Datenmengen sind überschaubar und die Ablaufsteuerung ist (noch) kein Thema. Mit ein paar Zeilen Shell-Skript ist so ziemlich jeder Prozess verwaltet, schnell, pragmatisch und kostengünstig. Genau dieser Umstand birgt ein großes Risiko.
Da diese Lösungen aufgrund steigender Komplexität und erhöhter Anforderungen an Leistung und Zuverlässigkeit erhebliche Entwicklungsressourcen binden werden, werden sie mittelfristig einen zuverlässigen und stabilen Betrieb zu vertretbaren Kosten unmöglich machen.
Aus Sicht des Managements ist es fatal, dass die Kosten für die Prozessablaufsteuerung und -überwachung anfangs so gering sind, dass sie nicht gesondert budgetiert werden. Der kontinuierliche und schleichende Kostenanstieg wird für das Management lange Zeit unsichtbar sein (Blindleistung!). Zu dem Zeitpunkt, zu dem dieses Problem erkannt wird, sind bereits enorme Summen für die Entwicklung von Kontrollskripten und die erforderlichen unterstützenden Funktionen und Frameworks ausgegeben worden.
Um diese Investitionen zu schützen und aus Angst vor einer Migration dieser Prozessleitsysteme auf ein geeignetes Scheduling-System, wird oft versucht, an dieser Betriebsweise festzuhalten. Die Kosten werden weiter steigen und es werden zunehmend Mitarbeiterressourcen gebunden. Die Abkehr von dieser ineffizienten Betriebsweise wird immer teurer.
In diesem Dokument wollen wir für diese Problematik sensibilisieren und aufzeigen, dass der frühzeitige Einsatz eines geeigneten Dispositionssystems das Auftreten dieses Dilemmas verhindert und gleichzeitig Kosten reduziert und Ressourcen für die Lösung der eigentlichen Aufgaben freisetzt.
Ein einfaches Beispiel
Anhand eines einfachen Beispiels wollen wir die Entwicklung eines einfachen Prozessablaufs exemplarisch darstellen. Wir nehmen an, dass für eine einfache Verarbeitung zwei Programme (P1 und P2) nacheinander ausgeführt werden müssen. Dies kann mit folgendem Shell-Skript realisiert werden:
#!/bin/sh P1 P2
Das ist doch ganz einfach, oder?
Fehlerbehandlung
Fehler werden in dem obigen Skript nicht behandelt. Um zu verhindern, dass P2 die falschen Daten verarbeitet, muss verhindert werden, dass P2 startet, wenn P1 einen Fehler meldet. Nachdem dies ein wiederkehrendes Ärgernis war, müssen wir eine Fehlerbehandlung in das Skript programmieren. Es wird etwa so aussehen:
#!/bin/sh
P1
RET=$?
if [ $RET -ne 0 ]
then
echo "Fehler $RET in P1 !"
exit $RET
fi
P2
RET=$?
if [ $RET -ne 0 ]
then
echo "Fehler $RET in P2 !"
exit $RET
fi
Wie wir sehen können, wurden einige Codezeilen hinzugefügt. Diese Codezeilen müssen getestet werden, da ein nicht verarbeiteter Fehler fatale Folgen haben kann. Diese Art der Fehlerbehandlung wird von verschiedenen Entwicklern unterschiedlich umgesetzt werden. Die Nachvollziehbarkeit und Wartbarkeit sinkt und die Kosten steigen.
Neustart
In unserem Beispiel hat P1 eine Laufzeit von etwa drei Stunden und P2 gibt häufig einen Fehler zurück, weil die Ressourcen im Zwischenspeicher knapp sind. Ein Neustart des Skripts würde auch überflüssigerweise P1 erneut ausführen, was zu einer Reparaturzeit von drei Stunden führt. In vielen Umgebungen würde ein Entwickler das Skript kopieren, den Aufruf von P1 auskommentieren und die Kopie dieses Skripts starten. Dies verursacht eine Menge Arbeit und birgt ein hohes Fehlerrisiko. Da dies keine akzeptable Situation ist, benötigt das Skript etwas globalen Speicher und sieht etwa so aus:
#!/bin/sh
#
# STEP denotes the last step which has been successfully executed
#
STEP=‘cat stepfile‘
if [ $STEP -eq "0" ]
then
P1
RET=$?
if [ $RET -ne 0 ]
then
echo "Fehler $RET in P1 !"
exit $RET
fi echo "1"
stepfile
fi
if [ $STEP -eq "1" ]
then
P2
RET=$?
if [ $RET -ne 0 ]
then
echo "Fehler $RET in P2 !"
exit $RET
fi echo "2"
stepfile
fi
echo "0"
Dies scheint eine schnelle Lösung zu sein, die der Entwickler vielleicht implementieren möchte. Aber diese Lösung ist in Wirklichkeit gar keine Lösung und birgt viele Probleme. Die 'stepfile' muss vor der ersten Ausführung initialisiert werden und muss möglicherweise nach dem Abbruch des Skripts erneut initialisiert werden. Eine Fehlerbehandlung für das Lesen und Schreiben der Stepfile fehlt völlig. Außerdem ist es unmöglich, zwei Instanzen dieses Skripts gleichzeitig laufen zu lassen.
Um dieses Skript geschäftsfähig zu machen, muss viel Entwicklungsaufwand betrieben werden. Wir verzichten ab jetzt auf weitere Codebeispiele für unser Miniprojekt, da es sich leicht zu einem Skript mit mehreren hundert Zeilen Code entwickeln wird. Und diesen Entwicklungsaufwand wollen wir uns natürlich ersparen.
Was noch?
Das obige Beispiel hat nur die ersten einfachen Probleme der Ablaufsteuerung durch Skripting gezeigt. Um einen stabilen und reibungslosen Betrieb zu gewährleisten, müssen unter anderem mindestens die folgenden Funktionen zur Verfügung stehen:
- Überwachung und Bedieneraktion
- Weitergabe von Steuerungsinformationen
- Möglichkeit der parallelen Ausführung
- Verteilte Ausführung
- Kontrolle der Ressourcen
Die Implementierung der genannten und weiterer Funktionen in das Prozessleitsystem erfordert einen erheblichen Entwicklungs- und Wartungsaufwand. Fehlen diese Funktionen jedoch, so wird dies durch (weitgehend) erhöhte Kosten für den Betrieb bezahlt.
Überwachung und Bedieneraktion
Um einen stabilen Betrieb zu gewährleisten, müssen alle Prozesse überwacht werden können. Das bedeutet, dass alle Prozesse ihren Fortschritt protokollieren müssen (in unserem Beispiel "stepfile"). Diese Protokolle müssen gesammelt und verarbeitet werden, um einen Überblick über die aktuell laufenden Prozesse zu erhalten. Dies erfordert ein Repository, das Statusinformationen über laufende Prozesse speichert.
Um eine schnelle Fehlerreaktion zu ermöglichen, ist es notwendig, im Falle eines Fehlers benachrichtigt zu werden. Das dafür benötigte Benachrichtigungssystem muss entwickelt werden und allein dies stellt ein kleines Projekt dar, das leicht zweistellige Manntage kosten kann. Im Falle von Problemen oder Fehlern muss der Bediener in laufende Prozessabläufe eingreifen können. Er muss in der Lage sein, Prozesse oder ganze Prozessabläufe neu zu starten, anzuhalten, fortzusetzen, abzubrechen, zu überspringen usw. Dies muss einigermaßen komfortabel sein, was auch einen erheblichen Entwicklungsaufwand bedeutet.
Übertragung von Kontrollinformationen
Oft ist es notwendig, Informationen (Zeitstempel, Dateinamen, ...) von einem Prozess zu einem nachfolgenden Prozess zu übertragen. In einer skriptbasierten Ablaufsteuerung wird dies typischerweise mit Hilfe von Dateien realisiert, die von einem Prozess geschrieben und von seinem Nachfolger gelesen werden. Diese Lösung birgt wiederum eine Reihe von Nachteilen. Spätestens dann, wenn einer der beteiligten Prozesse auf einem anderen Rechner im Netz ausgeführt werden soll, muss ein erheblicher Entwicklungsaufwand betrieben werden, um den Informationstransfer zu realisieren.
Möglichkeit der parallelen Ausführung
Die Skriptentwicklung erhält eine ganz neue Dimension, wenn Teile eines Prozessablaufs parallel ausgeführt werden können. Prozesse müssen als Hintergrundprozesse gestartet werden und an bestimmten Stellen im Prozessablauf muss das Warten auf die Beendigung dieser parallel laufenden Prozesse implementiert werden. Dies erfordert eine hohe technische Kompetenz des Entwicklers und ist zusammen mit Fehlerbehandlung, Neustart, Überwachung und Betrieb wahrlich keine triviale Aufgabe.
Verteilte Ausführung
Wenn einige Teile eines Prozesses auf verschiedenen Computern ausgeführt werden müssen, müssen die Skripte, die den Prozess steuern, Prozesse auf entfernten Computern starten. Dies führt zu einer weiteren Komplexitätsebene, da die Tücken von Remote-Befehlen (ssh, rsh, scp, . . .) hinsichtlich Überwachung und Fehlererkennung umgangen werden müssen. Von möglichen Sicherheitsrisiken, z.B. durch die Speicherung von Passwörtern, ist hier noch gar nicht die Rede.
Kontrolle der Ressourcen
Die verfügbaren Systemressourcen sind immer begrenzt. Werden zu irgendeinem Zeitpunkt zu viele Ressourcen benötigt, so führt dies zu einem verringerten Durchsatz und zu einer Häufung von Fehlern aufgrund von Ressourcenknappheit. Deshalb ist es wichtig, neue Prozesse nur dann zu starten, wenn ausreichend Ressourcen zur Verfügung stehen. Dies mit vertretbarem Aufwand in einer skriptbasierten Prozesssteuerung zu realisieren, ist kaum möglich.
Bisher haben wir nur einige der wichtigsten Aspekte der Ablaufsteuerung sowie den daraus resultierenden Aufwand beim Einsatz einer Skriptlösung beleuchtet. Ohne den Einsatz eines geeigneten Dispositionssystems werden im Betrieb erhebliche Kosten entstehen. Der Versuch, diese Kosten durch eine Verbesserung der Skripting-Infrastruktur in den Griff zu bekommen, bedeutet, dass ein enormer Entwicklungs- und damit verbundener Wartungsaufwand betrieben werden muss.
schedulix und BICsuite als Alternative und Ausweg
independIT bietet mit seinem BICsuite Scheduling System eine Alternative und einen Ausweg aus der Skriptfalle. Das BICsuite Scheduling System bietet alle notwendigen Funktionen, um große und komplexe Prozessabläufe zu modellieren, ohne dass Teile der Ablaufsteuerung in den Teilprozessen selbst implementiert werden müssen. Der Aufwand für Entwicklung, Wartung und Betrieb wird durch den Einsatz des BICsuite Scheduling Systems drastisch reduziert.
Zusätzlich wird der Betrieb stabiler, weniger fehleranfällig und sicherer. Wiederherstellungszeiten können spürbar verkürzt werden. Schlussbemerkung Die skriptbasierte Prozessablaufsteuerung erfordert einen unverhältnismäßig hohen Aufwand in Entwicklung, Wartung und Betrieb. Ein optimaler, transparenter und effizienter Betrieb ist mit einer skriptbasierten Ablaufsteuerung ein unerreichbares Ziel. Wir empfehlen daher den Einsatz eines geeigneten Scheduling-Systems in einem sehr frühen Stadium.
Je früher eine Umstellung auf ein solches System erfolgt, desto weniger Investitionen gehen verloren und desto geringer ist der Migrationsaufwand. Wenn Sie derzeit Skripting für die Prozessablaufsteuerung verwenden, ist ein zeitnaher Umstieg auf den Einsatz eines Scheduling-Systems sehr empfehlenswert. Das independIT BICsuite Scheduling System bietet alle Funktionen für die Entwicklung, Überwachung und den Betrieb komplexer Prozessabläufe und minimiert die Kosten für deren Entwicklung und Wartung. Zu einem Bruchteil der Kosten einer Scripting-Lösung unterstützt das BICsuite Scheduling System den Aufbau und Betrieb eines dauerhaft stabilen und zuverlässigen IT-Systems. Handeln Sie jetzt!
BICsuite Höhepunkte
Mehr erfahren
Stöbern Sie in unserer wachsenden Sammlung von Artikeln, Erklärvideos und Tutorials, um praktische Einblicke und Best Practices für die Workload-Automatisierung mit Schedulix und BICsuite zu entdecken.
Mehr erfahrenHaben Sie noch Fragen?
Bitte zögern Sie nicht, sich mit uns in Verbindung zu setzen, wenn Sie irgendwelche Fragen haben oder weitere Informationen benötigen. Unser Team steht Ihnen gerne zur Verfügung.
Kontaktieren Sie uns↑ Nach oben