Job-Steuerung ist so alt wie die Informationsverarbeitung. In den ersten Jahren wurden Computer ausschließlich im Batch-Mode betrieben. Die Zeiten haben sich zwar geändert, doch obwohl Unternehmen in den letzten Jahren ihr Augenmerk vor allem auf dialogorientierte Prozesse gelegt haben, läuft noch immer ein Großteil der Vorgänge im Hintergrund ab - laut dem Beratungshaus Gartner sind es etwa 70 Prozent. Mehr noch: Dialogsysteme machen immer mehr Batch-Läufe erforderlich. "Auf jede Online-Transaktion kommen zehn Batch-Jobs", schätzt Gartner-Analyst Milind Govekar. Doch so offensichtlich scheint dies nicht zu sein: "Die Kunden unterschätzen oft, wie abhängig sie von der Hintergrundverarbeitung sind", hat Matthias Frank, Business Technologist für Enterprise Management bei Computer Associates aus Darmstadt, festgestellt.

Immer weniger Batch-Zeit

Ein großer Teil der Batch-Jobs läuft nachts, während tagsüber die IT-Systeme für Dialog- und Online-Anwendungen zur Verfügung stehen. Zumindest war das bisher so, doch nach Auffassung der auf Job-Steuerung spezialisierten französischen Firma Orsyp verschiebt sich das Zeitfenster zunehmend in Richtung Transaktionsverarbeitung: Web-Anwendungen beanspruchten die Rechnerkapazität mittlerweile rund um die Uhr, und auch Dialogsysteme seien nicht mehr nur von 8 bis 18 Uhr, sondern zwischen 7 und 22 Uhr in Betrieb. So bleibe für unternehmenskritische Batches immer weniger Zeit, was zu Störungen und Abbrüchen führe.

Batch-Jobs, auch Stapelverarbeitung oder Batch-Prozesse genannt, sind Programmroutinen, die zeit- oder ereignisgesteuert ohne Interaktion mit dem Benutzer ablaufen. Die Hintergrundprogramme lesen Daten ein und liefern Rückgabewerte sowie Statusinformationen wie Laufzeit, Störungen und Fehlerbeschreibungen zurück. Ein Job-Scheduler startet und überwacht die Batch-Läufe. Praktisch alle Computersysteme verfügen über solche Mechanismen. Selbst Windows-Desktops verwenden Jobs, beispielsweise zur Datensicherung oder zum Ausdrucken von Dokumenten. Firmen verwenden die Batch-Steuerung unter anderem dazu, Massendaten wie Lohnabrechnungen zu verarbeiten, Vertriebszahlen auszuwerten oder Geschäftsinformationen in ein Data Warehouse zu laden. Neben den Betriebssystemen verfügen auch Enterprise-Resource-Planning-(ERP-)Programme über solche Scheduler, um so neben Dialog- auch Hintergrundprozesse anzustoßen.

Allerdings verfügen die integrierten Scheduler meist nur über rudimentäre Steuerungskonzepte. Mit dem Unix-Werkzeug "Cron" etwa ist der Systemverwalter in der Lage, Jobs zu definieren, jedoch sind die Skript-Kommandos nicht gerade benutzerfreundlich, und die Pflege dieser Steuerroutinen gestaltet sich aufwändig. Ferner besitzt Cron kaum Funktionen, um mehrere Batches nebeneinander und in Abhängigkeit von einander ablaufen zu lassen, erst recht nicht bei plattformübergreifenden Batch-Prozessen.

Plattformübergreifende Jobs

Die heterogenen IT-Landschaften bringen es jedoch mit sich, dass Jobs nicht nur auf einzelnen Rechnern mit gleicher Systemsoftware verwaltet werden müssen. Häufig sind mehrere, verschiedene Computersysteme an einem Hintergrundprozess beteiligt. So müssen Unternehmen beispielsweise Batch-Jobs auf dem Mainframe mit denen auf Unix-Servern synchronisieren.

Die Einschränkungen der Betriebssystemwerkzeuge haben zahlreiche Hersteller dazu veranlasst, ausgefeilte Job-Scheduling-Software auf den Markt zu bringen. Laut Gartner sind es etwa 60 Firmen weltweit, darunter finden sich Spezialisten wie die bereits erwähnte Orsyp, die in Wolfsgraben bei Wien beheimatete SBB Software oder die amerikanische Firma Redwood. Sie haben komplette Job-Control-Programme oder Ergänzungen zu den in ERP-Produkten oder Betriebssystemen integrierten Schedulers entwickelt. Mitbewerber wie IBM, BMC Software und Computer Associates positionieren sich als Generalisten und preisen Job-Scheduler als Teil ihrer System-Management-Umgebung an.

IBM, BMC Software, Beta Systems und Computer Associates (CA) stammen aus der Mainframe-Welt und haben sich zum Teil über Zukäufe oder Kooperationen Technik zum Job-Scheduling in Windows, Linux und Unix erworben. Andere Firmen starteten gleich als Anbieter von Batch-Verwaltungswerkzeugen für offene Systeme, bieten für Hosts aber nur einen eingeschränkten Funktionsumfang.

Doch die IT-Strategie ihrer Kunden zwingt Anbieter zum Umdenken. Beta Systems beispielsweise adressiert mit dem Produkt "Beta 48" Mainframe-Anwender. Das Tool stützt sich auf einen Host-basierenden Job-Scheduler von IBM oder CA, es bietet aber gleichzeitig Methoden, um Batches in Windows- und Unix-Servern zu steuern. Softwareagenten binden die Batch-Scheduler dieser Plattformen ein, so dass sie vom Host aus zentral gesteuert werden können. Um Kunden nicht an Konkurrenten zu verlieren, die den Mainframe lediglich als einen von vielen Servern betreiben, betätigt sich das Unternehmen als Wiederverkäufer des Schedulers "UC4" von SBB Software. Die Kontrolle erfolgt hier über ein plattformneutrales Java-Frontend. Mit UC4 lassen sich Batches sowohl in den Business-Applikationen von Peoplesoft, Oracle und SAP als auch den Betriebssystemen Unix, Windows, Open VMS, BS 2000, OS/400 und z/OS beziehungsweise OS/390 starten.

Mainframe-Konzepte übertragen

An der Architektur vieler Job-Scheduler hat sich seit Jahren wenig geändert: Sie arbeiten nach dem Master/Agent-Konzept der Mainframe-Tools. Dabei initiiert der Master die Batches, reiht sie je nach Priorität in Warteschlangen ein und kontrolliert deren Ablauf. Die Agenten führen die Jobs aus und senden Statusinformationen an die Steuerungskomponente beziehungsweise fertigen Laufzeitberichte an. Einen anderen Weg beschreitet Orsyp mit dem Produkt "Dollar Universe", das für die Job-Verwaltung in Unix, Linux, Windows, Open VMS und HP Nonstop Kernel entwickelt wurde. Die etwas hochtrabend "Automation Power Grid" getaufte Infrastruktur des Batch-Steuerungsprogramms basiert auf der Idee von Peer-to-Peer-Netzen: Jedes mit Dollar Universe ausgestattete System hält eine Kopie der kompletten Job-Scheduler-Konfiguration vor und fungiert quasi als Master und Agent gleichzeitig. Ein dedizierter Master-Rechner ist nicht erforderlich, stattdessen tauschen die Job-Server Steuer- und Statusinformationen untereinander aus. Nach Überzeugung des Herstellers führt dieses Konzept zu einer höheren Fehlertoleranz, da im Gegensatz zum Master/Agent-Ansatz keine zentrale Steuerinstanz erforderlich ist und damit ein Single-Point-of-Failure vermieden wird. Selbst bei Netzzusammenbrüchen oder dem Ausfall eines Rechners im Verbund könnten die nicht betroffenen Job-Computer weiterlaufen.

Skalierbare Job-Steuerung

Als weiteren Vorteil nennt der Anbieter die vergleichsweise geringe Netzbelastung, da die Batch-Steuerung jeweils lokal erfolgt und die Kommunikation mit dem Master entfällt. Zudem lasse sich die Orsyp-Technik leichter skalieren, da der Anwender neue Rechner ohne viel Aufwand in das "Automation Power Grid" einbinden könne. Abstriche machen müssen Orsyp-Nutzer jedoch, wenn sie auch Mainframes einsetzen: Dollar Universe wurde noch nicht auf das Betriebssystem z/OS portiert. Für die Host-Kopplung haben die Franzosen einen Agenten entwickelt, der den Scheduler des Rechnerboliden mit der kooperativen Job-Steuerung von Dollar Universe vernetzt. Ähnlich verfahren die Franzosen bei der Anbindung von SAP R/3: Hier koppelt ein Softwareagent den Scheduler der ERP-Umgebung an.

Während Orsyp seine Software auf mehrere Betriebssysteme portiert hat, verwendet beispielsweise Konkurrent CA unterschiedliche Job-Scheduler für Mainframes, Unix, Windows und Linux. Sowohl die Master als auch die Agenten wurden plattformspezifisch implementiert. Ein Manko sieht der Hersteller darin nicht, schließlich ließen sich die Batch-Systeme über eine zentrale Job-Administration verwalten und überwachen. Gleichwohl arbeitet CA an der Harmonisierung seiner Technik. So soll es künftig statt spezieller Agenten für jeden Scheduler nur noch universelle Module für alle Betriebssysteme und Applikationen geben, die dann alle Batch-Steuerkomponenten im CA-Portfolio verwenden. Die Integration in die Zielsysteme übernehmen spezielle Adapter, hier setzt der Softwarekonzern verstärkt auf Web-Services-Schnittstellen beziehungsweise XML.

Web-Services binden Batch-Jobs ein

Dass Job-Scheduling und Web-Services koexistieren müssen, glaubt auch Gartner-Mann Govekar. So könnten geschäftskritische Anwendungen über Web-Services-Schnittstellen auf Job-Scheduler zugreifen. Solche Interfaces reduzieren nach Ansicht des Analysten die Komplexität bei der Verknüpfung von Programmen und Job-Steuerung. Als Beispiel nennt Govekar das Zusammenspiel zwischen einer Internet-Bank und einem Batch-Prozess, der die Kreditwürdigkeit des Kunden prüft. Letzterer könnte im IT-System eines externen Dienstleisters laufen. Die Bank benötigt lediglich die Schnittstellen-Beschreibung sowie das Format der Rückgabewerte, um den Service an die Online-Applikation anzubinden. Die Web-Service-Technik eignet sich außerdem dazu, verschiedene Job-Scheduler mit weit weniger Aufwand als bisher zu verknüpfen.

Integrationsfähigkeit steht bei Kunden ohnehin hoch im Kurs, denn trotz der Verlockungen der Anbieter wollen viele Unternehmen ihre bestehenden Job-Scheduler lieber koppeln, statt sie durch neue Produkte abzulösen. Oft verrichten diese Systeme seit Jahren ihren Dienst zuverlässig, und ein Umstieg käme den Anwender teuer zu stehen. Dies gilt insbesondere für Mainframe-Werkzeuge. Gleichwohl sind sie bestrebt, ihre Job-Steuerungssoftware zu konsolidieren, um so die Verwaltungskosten zu senken und den Integrationsaufwand auf einige wenige Produkte zu reduzieren.

Die nahtlose Integration von Job-Schedulern ist eine wichtige Vorausetzung, um Geschäftsprozesse zu automatisieren (Business Process Automation). Während die Enterprise-Application-Integration-(EAI-)Spezialisten Lösungen vor allem für die synchrone Anwendungskopplung anbieten, also für Antwortzeiten von wenigen Sekunden, benötigen Firmen zusätzlich Werkzeuge, um auch die unverzichtbaren, asynchronen Batch-Läufe in die Geschäftsprozesse einzuflechten. Aus diesem Grund haben sich nahezu alle Job-Scheduling-Hersteller Business Process Automation auf die Fahnen geschrieben. Allerdings klaffen Anspruch und Wirklichkeit mitunter noch weit auseinander. Zwar beherrschen alle Anbieter die zeitgesteuerte Job-Kontrolle, einige weisen jedoch noch Schwächen in puncto Ereignissteuerung auf (Event-driven Job-Scheduling). "Vor allem solche Hersteller, die in erster Linie Mainframe-Produkte anbieten, tun sich hier schwer", meint Gartner-Analyst Govekar. Beta Systems arbeitet daher emsig daran, die Mainframe-Software Beta 48 mit Event-Steuerung auszustatten. Ein auf Unix und Windows laufender Trigger-Agent soll künftig auf Events reagieren und Jobs auf dem Host starten können. Weil er durch Ereignisse ausgelöst oder getriggert wird, heißen diese Agenten Trigger-Agenten.

Ein Event ist beispielsweise das Unterschreiten des minimalen Lagerbestands. In diesem Fall müssen eine Reihe Jobs automatisch starten und koordiniert werden, und zwar sowohl in den internen IT-Systemen als auch in denen der Lieferanten. Ereignisse können jedoch auch technischer Natur sein, zum Beispiel Systemausfälle. In zunehmendem Maße führen auch Entscheidungen aus dem Management zu Ereignissen, dazu zählen die bei Administratoren ungeliebten Ad-hoc-Auswertungen von Vertriebszahlen, die der Geschäftsführer oder Vorstand lieber heute als morgen hätte.

Die Systemverwalter sind dann gezwungen, nicht planbare Anforderung zusätzlich in ihre Jobplanung hineinzuquetschen. Doch damit ist es nicht getan: Job-Scheduler müssen in der Lage sein, die Batch-Planung so anzupassen, dass der zusätzliche Ressourcenbedarf weder die übrigen Jobs noch die Dialogprozesse beeinträchtigt. Dies zu gewährleisten, erfordert neben einer ausgefeilten Planungskomponente und Simulationswerkzeugen mitunter auch Funktionen zur Lastverteilung. Ein dynamisches Workload-Management ermittelt selbständig freie IT-Ressourcen und weist sie den Batches zu. Hier sehen sich Hersteller im Vorteil, die Job-Scheduling als Teil ihrer System-Management-Plattform vermarkten.

Workload-Balancing entsteht erst noch

Ihr Argument: Die Verwaltungsumgebungen sammeln Statusinformationen über die CPU- und Speicherauslastung, Nutzerzahl sowie Festplattenkapazität der einzelnen Server und liefern so die Grundlage für ein Load-Balancing. Doch dieses Alleinstellungsmerkmal relativiert die Konkurrenz, denn viele Scheduler-Hersteller haben ihre Produkte in Management-Lösungen wie "CA Unicenter", "HP Openview", "BMC Patrol" und "Tivoli Enterprise" eingebunden. Allerdings kann dies nicht darüber hinwegtäuschen, dass die Entwicklung von Workload-Balancing, das Mainframes schon lange beherrschen, für heterogene Systemumgebungen erst begonnen hat. Dieses Austarieren der Arbeitslast über unterschiedliche Plattformen hinweg ist Teil der in die Zukunft gerichteten On-Demand-Computing-Strategien der IT-Konzerne.

Job-Scheduling

- Betriebssysteme und Business-Applikationen wie SAP R/3 verfügen meist nur über rudimentäre Job-Scheduling-Funktionen.

- Firmen wollen Batch-Läufe plattformübergreifend steuern, also unter Unix, Linux, Windows und Mainframe-Betriebssystemen.

- Anbieter statten Job-Scheduler mit Web-Services-Schnittstellen aus, um die Integration zu erleichtern.

- Scheduler müssen nicht nur zeit-, sondern auch ereignisgesteuert Batch-Jobs verwalten.

Abb: Job-Scheduler in einer typischen IT-Umgebung

Unternehmen wollen Batch-Jobs plattform- und anwendungsübergreifend steuern. Die Bordmittel der Betriebssysteme reichen hier oft nicht. Quelle: Bloor Research 2003