Jobs nach Wartungstermin nachholen

[nafetS]

Hi,

mich würde mal interessieren, wie ihr mit eurer Jobsteuerung zu einem Wartungstermin umgeht?

Bei uns sieht es momentan wie folgt aus:

Applikations- und Datenbankserver werden einmal heruntergefahren (liegt nicht in meiner Hand). Davor stoppe ich die Verarbeitung in Automic.

Jetzt sind die Server auf Grund der Wartungsarbeiten mehrere Stunden offline. Nachdem sie wieder hochgefahren werden, wird auch die Verarbeitung in Automic wieder gestartet.

Nun sind aber in den Schedules alle Objekte, die eigentlich in diesem Zeitraum starten sollten, mit einem TIMEOUT beendet, da die Startzeit überschritten ist. Wir gehen sämtliche Schedules durch und setzen die betroffenen Aufgaben zurück., damit diese nachgeholt werden.

Ich finde dieses Vorgehen sehr mühsam.....

Habt ihr vielleicht Tipps für mich, wie man das besser machen kann bzw. wie macht ihr das?

Danke und Grüße
Stefan

[marco_lucarelli_automic]

Hallo Stefan

Wir haben für Wartungsarbeiten und Release Termine einen separaten Workflow der täglich gestartet wird und nur leere Scripte (mit Ihnalt ":wait 0") für jede Verarbeitung enthält. Jede Verarbeitung, welche unser Wartungsfenster kreuzen könnte hat eine externe Bedingung zu einem dieser leeren Scripte. Bei Wartung setzen wir in den betroffenen Scripten einen Haltepunkt und so startet keine der betroffenen Verarbeitungen.
Die Workflows müssen natürlich vor dieser Wartung schon generiert werden damit dies funktioniert. Alle Tagesendverarbeitungen werden bei uns am morgen früh aktiviert und duch externe Bedingungen wird gesteuert wann der jeweilige Worklfow gestartet werden soll.
Ist wirklich nicht "ideal" umgesetzt, aber wir haben zur Zeit auch noch ein weiteres Scheduler System (EOR) im Einsatz und nur durch externe Bedingungen und Datei-Steuerungen können wir beide Systeme optimal zusammen nutzen.

Wenn man schnell prüfen möchte welche Worklfow nicht durch ein Scheduler aktiviert wurde könnte man etwas in der Art nutzen:

SQLI.TEST:
select EH_Name,EH_AH_Idnr,EJPP_Object,EJPP_OType,EJPP_TaskIdnr,EJPP_Status,EJPP_JobStatus from EH
inner join EJPP
on EH_AH_Idnr=EJPP_AH_Idnr
where EH_Client = '&$CLIENT#'
and EH_Otype = 'JSCH'
and ( EJPP_Status = '1941' or (EJPP_Status between '1560' and '1564') or (EJPP_Status between '1800' and '1899') )

[Legacy User]

Hallo Stefan,
in welcher Version bist Du den unterwegs? Hast Du schon die Queues ?
Ich habe mir für jede größere Entität, Produkt etc. eine Queue angelegt, dort hast Du jetzt die Möglichkeit die Slots auf 0 zu setzen, somit wird alles geplant aber nicht gestartet. (Warten auf Queue-Slot) Im Anschluss an die Wartungsarbeiten/Downtime dann die Slots wieder erhöht und alles wird nun abgearbeitet. Funktioniert prima.
Für Deploy's etc. habe ich das Ganze automaisiert so dass ich gar nicht mehr eingreifen muss.
Vielen Dank
Christian

[Manfred Mauermann]

Hallo Stefan,
wir haben vermutlich auch noch eine eher rustikale Methode im Einsatz, die wohl historisch bedingt ist.
Für jeden Mandanten haben wir ein VARA-Objekt, in dem alle Events und Schedules aufgelistet sind, in einer weiteren Spalte sogar noch, für welche Umgebung sie gültig sind, also z.B. Integ, QSU und PROD.
Mittels Start- und Stop-Skripten wird nun dieses VARA ausgelesen und umgebungsabhängig gestartet bzw. gestoppt.
Es muss natürlich geprüft werden, ob das Aktivitätenfenster leer ist, bevor für ein Wartungsfenster beendet wird. Nachdem wir lediglich vier kurze planmäßige Wartungstermine für Updates vorgesehen haben, klappt das ganz gut.

Hängt sicherlich auch davon ab, wieviele Jobpläne in Betrieb sind und natürlich von der Komplexität des ganzen Konstrukts. Die Methode von Christian wäre mein persönlicher Favorit, wenn wir hier mal was umstellen sollten.

Viele Grüße
Manfred

[nafetS]

Wir haben die V10 im Einsatz, also Queues wären möglich.
Klingt auch schon mal ganz interessant, muss ich mir mal mehr Gedanken zu machen  ;)

Aber die Jobs/Jobpläne die ihre Startzeit in der Downtime haben, werden doch dann trotzdem nicht generiert!?

Angenommen Downtime ist von 17:00 bis 20:00 Uhr und der Job soll um 18:00 über einen Scheduler gestartet werden, dann bleibt doch auch weiterhin nur die Möglichkeit die Aufgabe im Scheduler zurückzusetzen, da sie ja mit einem TIMEOUT beendet wurde. Oder?

Grüße
Stefan

[Legacy User]

Hallo Stefan,
nein, das ist ja der Vorteil der Queue's, die werden dann gestartet mit warten auf Queue Slot und wenn Du die Queue dann wieder frei gibst werden diese ausgeführt. Funktioniert super.
Vielen Grüße
Christian

[marco_lucarelli_automic]

Stefan Rieger said:

Wir haben die V10 im Einsatz, also Queues wären möglich.
Klingt auch schon mal ganz interessant, muss ich mir mal mehr Gedanken zu machen  ;)

Aber die Jobs/Jobpläne die ihre Startzeit in der Downtime haben, werden doch dann trotzdem nicht generiert!?

Angenommen Downtime ist von 17:00 bis 20:00 Uhr und der Job soll um 18:00 über einen Scheduler gestartet werden, dann bleibt doch auch weiterhin nur die Möglichkeit die Aufgabe im Scheduler zurückzusetzen, da sie ja mit einem TIMEOUT beendet wurde. Oder?

Grüße
Stefan

Bezieht sich die Downtime auf die Automic AutomationEngine?

Gruss,

Marco L.

[nafetS]

Christian Böck said:

Hallo Stefan,
nein, das ist ja der Vorteil der Queue's, die werden dann gestartet mit warten auf Queue Slot und wenn Du die Queue dann wieder frei gibst werden diese ausgeführt. Funktioniert super.
Vielen Grüße
Christian

Aber im betroffenen Zeitraum wird doch nicht gestartet, wenn die AE down ist.

Marco Lucarelli said:

Bezieht sich die Downtime auf die Automic AutomationEngine?

Gruss,

Marco L.

Ja. AE und Datenbank.

[Legacy User]

in dem Fall habt Ihr alle Recht, die Posts bis jetzt stellen die Möglichkeiten dar die man hat wenn die Wartungsarbeiten nicht soweit gehen dass die Automation Engine (oder die DB, oder beides) heruntergefahren werden. In dem Fall macht es absolut Sinn die Queues zu stoppen die Aufgaben da rein starten zu lassen, und danach wieder freizugeben.

Stefan Rieger Sie haben auch recht, wenn die DB oder die Automation Engine (oder beides) "weg" ist, dann werden auch keine Aufgaben in die Queues eingeplant, und damit gibt es für das System nichts nachzustarten.

Dafür gibt es einen kleinen "Lifehack", wenn es eine geplante Downtime ist, kann man für die Zeit einen Autoforecast laufen lassen, und sich damit die eingeplanten Aufgaben anzeigen. Basierend darauf kann man entscheiden welche der Aufgaben nach dem wieder Hochfahren eventuell nachgestartet werden müssen.

[Legacy User]

Hi Stefan,
sorry, ich dachte es geht hier um Wartungsarbeiten derer Systeme die Du bedienst und nicht um Automic selbst.
Wenn Automic natürlich down ist funktioniert das natürlich nicht. Dann kenne ich auch keine andere Möglichkeit
wie, dass Du dann die Sachen händisch nachtriggern musst, allerdings habe wir hier z. B. für Automic eigentlich
keine Downtime mehr. Upgrade von Automic selbst geht ja mittlerweile mit Zero Downtime und Wartung an
Server und DB beinhaltet eigentlich wenn überhaupt nur noch einen Reboot wenn überhaupt.
Da sollte Deine Lösung dann eher dahingehend sich ändern, dass Du den Downtime Zeitraum auf ein minimum reduzierst, ansonsten fällt mir aktuell keine andere Möglichkeit ein.
Viele Grüße
Christian

[nafetS]

Harald Heidinger said:

in dem Fall habt Ihr alle Recht, die Posts bis jetzt stellen die Möglichkeiten dar die man hat wenn die Wartungsarbeiten nicht soweit gehen dass die Automation Engine (oder die DB, oder beides) heruntergefahren werden. In dem Fall macht es absolut Sinn die Queues zu stoppen die Aufgaben da rein starten zu lassen, und danach wieder freizugeben.

Stefan Rieger Sie haben auch recht, wenn die DB oder die Automation Engine (oder beides) "weg" ist, dann werden auch keine Aufgaben in die Queues eingeplant, und damit gibt es für das System nichts nachzustarten.

Dafür gibt es einen kleinen "Lifehack", wenn es eine geplante Downtime ist, kann man für die Zeit einen Autoforecast laufen lassen, und sich damit die eingeplanten Aufgaben anzeigen. Basierend darauf kann man entscheiden welche der Aufgaben nach dem wieder Hochfahren eventuell nachgestartet werden müssen.

Die Downtime ist zwar geplant, aber das Ende der Downtime ist sehr variabel......

Christian Böck said:

Hi Stefan,
sorry, ich dachte es geht hier um Wartungsarbeiten derer Systeme die Du bedienst und nicht um Automic selbst.
Wenn Automic natürlich down ist funktioniert das natürlich nicht. Dann kenne ich auch keine andere Möglichkeit
wie, dass Du dann die Sachen händisch nachtriggern musst, allerdings habe wir hier z. B. für Automic eigentlich
keine Downtime mehr. Upgrade von Automic selbst geht ja mittlerweile mit Zero Downtime und Wartung an
Server und DB beinhaltet eigentlich wenn überhaupt nur noch einen Reboot wenn überhaupt.
Da sollte Deine Lösung dann eher dahingehend sich ändern, dass Du den Downtime Zeitraum auf ein minimum reduzierst, ansonsten fällt mir aktuell keine andere Möglichkeit ein.
Viele Grüße
Christian

An der AE wird auch selten etwas gewartet. Da aber die Server auf dem die virtuelle Maschine der AE und DB laufen heruntergefahren werden, geht es leider nicht anders. Die Wartung wird auch von einer anderen Abteilung durchgeführt, da kann ich leider nicht viel beeinflussen.....

Muss ich wohl mal mit den Kollegen sprechen, ob man das nicht ändern kann ;)

Solange werde ich wohl weiterhin die Jobs manuell nachholen müssen. Aber trotzdem vielen Dank für eure Antworten!

Grüße
Stefan

[Legacy User]

Hi Stefan,
okay alles klar, nur noch am Rande, den Forecast kannst Du wenn nötig auch über mehrere Tage fahren, so lange solltest Du ja nicht down sein, d. h. Du kriegst auf alle Fälle eine Liste derer Aufgaben die laufen hätten sollen und kannst während der Downtime schon entscheiden was Du nachstarten möchtest und was nicht. Kein großer Trost aber immerhin :-)
Viele Grüße
Christian

[Ralf-Peter Langer]

Hi,
für die täglich "wichtigen" Abläufe haben wir einen Jobplan der wir 0.05 Uhr täglich via Sheduler gestartet und alle weiteren Bedingungen (Kalender / früheste Startzeit) sind dann in den Subjobplänen verdrahtet.
Damit haben wir alles in dieser Kapsel und können somit auch mal in Stop gehen und es wird nichts vergessen.
Durch die Verschachtelung der Jobpläne und das generieren zur Laufzeit kann man dann sogar noch gut die Verarbeitung steuern.
Zyklische Aufgaben werden über Time-Events gestartet.
Grüße
RPL   

[nafetS]

Danke für deine Antwort Ralf-Peter.

Grüße aus Braunschweig nach Wolfenbüttel ;)