Jobwarteschlangen und Absicherung bei Serverausfall

Batch-Jobs werden in so genannten Jobwarteschlangen gesammelt und abgearbeitet. Handelt es sich bei den Jobs um Aufgaben, die in einer bestimmten Reihenfolge abgearbeitet werden müssen, darf es nur genau eine Jobwarteschlange für diese Jobs geben. Da diese Jobwarteschlange genau einem Server zugeordnet ist bzw. genau ein Application Server für die Abarbeitung der Warteschlange zuständig ist, würde ein Ausfall dieses Servers bedeuten, dass so lange keine Jobs mehr abgearbeitet werden würden, bis der Server wieder verfügbar ist.
Um diesem Fall vorzubeugen, ist ein so genanntes „Failover" (Ausfallsicherung) für diese Warteschlangen bereitzustellen. D.h. ein Verbund von mindestens zwei Application Servern, in dem bei einem Ausfall eines Servers ein zweiter Server dessen Aufgaben übernimmt. Diese Übernahme muss dynamisch im laufenden Betrieb erfolgen können, um eine unterbrechungsfreie Abarbeitung der Jobs zu gewährleisten.

Failover-Konfiguration für Jobwarteschlangen

Seit oxaion open 5.0 können für Jobwarteschlangen bis zu drei Server als Failover-System zusammengeschaltet werden. Dies ist für jede Jobwarteschlange individuell konfigurierbar. Die Konfiguration wird über die drei Felder „Möglicher ausführender Server" in der Jobwarteschlangeverwaltung (US00300) vorgenommen.
 
In diesen Feldern können bis zu drei ausführende Server für eine Jobwarteschlange hinterlegt werden. Fällt der aktive Server aus, übernimmt einer der anderen Server die Jobwarteschlange. Damit der ursprüngliche Application-Server die Jobwarteschlange auch wieder zurück übernehmen kann, sollte er auch mit bei den ausführenden Servern eingetragen sein. Die Reihenfolge der Einträge spielt keine Rolle. Bleiben die drei Einträge leer, wird die Jobwarteschlange weiterhin nur auf dem Application-Server (Feld darüber) ausgeführt.

Technische Detailbeschreibung

Auf jedem Applikation Server läuft ein interner Job der regelmäßig alle die Jobwarteschlagen prüft, in der der aktuelle Applikation Server als „Möglicher ausführender Server“ eingetragen ist und „Application Server“ nicht der aktuelle Applikation Server ist. Bei der Prüfung wird geschaut, ob der in der Jobwarteschlage angegebene „Application Server“ in der aktuellen Liste der Server im Serververbund enthalten ist.

Für diese Jobwarteschlageneinträge wird jeweils versucht, genau den bisherigen „Application Server“ auf den aktuellen Applikation Server umzustellen.

Bei Erfolg, also wenn kein anderer „Möglicher ausführender Server“ zuvorkommt, werden folgende Aktionen ausgeführt:

• Jobs für den bisherigen „Application Server“ im Status INIT für diese Jobwarteschlage werden auf den aktuellen Applikation Server umgestellt.
• Die Jobs mit Status „RUNNING“ für diese Jobwarteschlage für den bisherigen „Application Server“ werden aus der Jobliste entfernt.
• Ein Ereignis STARTUP wird für genau die umgestellte Jobwarteschlage ausgelöst, so dass entsprechend konfigurierte Einträge aus „Jobs planen“ gestartet werden.