Re: Job Scheduler (was: Re: File-Locking in Shellscripten auf NFS)

[Thomas Stiefel <Tom@xxxxxxx>]

Hallo Raphael,

ich wollte nie deine Faehigkeiten anzweifeln und haette auch nicht gedacht, dass
es sich um ein so komplexes Setup fuer eine eigentlich relativ einfache Aufgabe
handelt.

Aber wie auch immer die Umgebung aussieht, Probleme sind dazu da, dass sie
geloest werden und hier ist die Herausforderung eben etwas groesser, aber damit
auch interessanter ;)

Raphael Eiselstein schrieb am 18.12.2010 00:16:
> > Ist halt die Frage ob der nfs-Server dafuer ausgeruestet ist diese Aufgabe zu
> > erledigen? Evtl. gab es ja einen Grund dieses Script auf andere Server
> > auszulagern?
> Man kann auch NFS aus Kisten heraus anbieten, die kein (extern
> erreichbares) unixoides Betriebssystem im innern haben.
Klar, man kann auch mit irgendwelchen NAS-Systemen NFS-Dienste anbieten, aber
da von einem hochverfuegbar NFS-Server die Rede war, bin ich von
UNIX-/Linux-Systemen ausgegangen.

Daher bietet sich fuer mich an ein schon hochverfuegbar aufgebautes System auch
fuer andere Zwecken zu nutzen und die Hochverfuegbarkeit nicht nochmal zu
implementieren. Da hier aber wohl "nur" das NFS ueber BRBD hochverfguebar ist,
dann ist die Ausgangsposition eine andere.

> Es gibt im konkreten Setup mehrere hochverfuegbare NFS-Quellen, die
> allesamt auf mehreren unabhaengigen Servern gemountet sind. Diese Server
> bieten irgendwelche Dienste an, hier zB im Rahmen eines Datawarehouses
> den Import und Export von Daten (in Dateiform) durchfuehren.
> 
> Da Daten (Dateien) kontinuierlich beschafft und verarbeitet werden muessen,
> sollte unter keinen Umstaenden die Beschaffung (Import) von Daten
> unterbrochen werden. Um das zu gewaehrleisten betreibe ich mehrere Rechner,
> die bestimmte Copy-Jobs ausfuehren. Ich nehme dafuer mehrere Server nicht,
> weil es zuviel Last waere fuer nur einen, sondern weil ich damit eine
> Ausfallsicherheit bekomme und zusaetzlich im Normalbetrieb keine Bottlenecks
> habe.
> 
> Ausserdem laufen auf diesen "Beschaffungsservern" nicht nur Copy-Jobs, die
> aktiv Daten abholen sondern auch plain rsync-daemons, die Daten annehmen,
> also per "Push" von extern bekommen (oder zur Abholung anbieten). Da die
> Quellen sich schlecht syncronisieren lassen und es teilweise zu sehr
> vielen parallelen Transfers kommt, werden eingehende rsync-Verbindungen
> ueber einen LoadBalancer (IPVS, direct routing) auf mehrere rsync-daemons
> verteilt, die alle die gleiche rsyncd.conf haben und zudem jeweils alle
> NFS-Quellen und -Senken gemountet haben.
> 
> Datenexporte laufen ebenfalls als Copy-Job (per rsync, cron) oder werden
> per rsyncd, httpd und sftp  fuer bestimmte Mandanten zur Abholung
> angeboten, auch hier per IPVS-Loadbalancer, auf dem ein ldirectord
> regelmaessig prueft, dass die dahinter liegenden Dienste auch wirklich
> erreichbar sind und Zugriffe nur an "lebende Dienste" durchleitet.
> 
> Es gibt in diesem Spiel also keine Funktion und keinen Dienst, der
> ausschliesslich auf nur einem Server verfuegbar ist.
> 
Das von dir beschriebene Setup ganz klar nach einem Enterprise-Szenario an,
das bestimmt auch Workflows enthaelt bei dem Daten von einem System ueber ein
zweites in ein drrittes System wandern.
Hier wuerde sicher nicht nur ein Job-Scheduler fuer die angesprochenen Copy-Jobs
Sinn machen, sondern der durchgehende Einsatz eines solchen.
So kann man bestimmte Ablaeufe effizienter gestalten, da man nicht nur in
Abhaengigkeit eines Jobs seinen direkten Nachfolger starten lassen kann,
sondern auch bei Abbruechen innerhalb einer groesseren Job-Kete problemlos an
genau diesem Punkt die Verarbeitung wieder aufsetzten.

Dienstlich arbeite ich hier mit UC4, aber das ist nicht gerade guenstig was die
Lizenzen angeht. Auch die anderen mir bekannten Automatisierungs- bzw.
Scheduler-Tools sind meist nicht unbedingt guenstig. Ein Ausnahme bildet hier
der "Open Source Job Scheduler" (OSJS): http://jobscheduler.sourceforge.net/
> Ich suche also nach einer Moeglichkeit in diesem vorne und hinten und in
> der Mitte redundant ausgelegten System wiederkehrende Jobs verteilt auf
> mehreren Systemen auszufuehren und dabei sicherstellen, dass identische
> Jobs sowohl pro System aber auch im gesamten Verbund nie parallel
> ausgefuehrt werden.
> 
Dies kann der OSJS auf jeden Fall, aber er kann - wenn dies gewuenscht ist -
auch Jobs auf einer bestimmten Anzahl an an Systemen parallel ausfuehren.
DER OSJS kann darueber hinaus auch verhindern, dass zwei Jobs parallel auf die
gleiche Ressource zugreifen (z. B. eine Datenbank oder eine Datei).

> PID-Files oder Lock-Files auf der gemeinsamen NFS-Ressource koennten da
> helfen, aber wenn ein CopyJob einmal abstuerzt, hinterlaesst er dann
> PID-Files mit nicht mehr gueltigen PIDs oder Lockfiles, die ihren Lock
> nicht verlieren. Also suche ich nach einer Moeglichkeit zweifelsfrei
> und mit geringem technischen Aufwand herauszufinden, ob PID/Lockfiles
> noch "gueltig" sind.
> 
> Oder, weil cron hier eher das Problem darstellt: Einen verteilten
> Job-Scheduler, der ohne zentrale Instanz auskommt und trotzdem dafuer
> sorgt, dass konkrete Jobs nie mehr als einmal parallel ausgefuehrt werden
> *und* eine Fehlerbehandlung ermoeglicht, wenn ein Job einmal unsauber
> abgebrochen ist, etwa weil Quelle oder Ziel ploetzlich nicht mehr
> verfuegbar sind (Timeout).
DER OSJS sorgt nicht nur ueber eigene Routinen dafuer, dass Jobs nur einmal
parallel laufen, sondern ueberwacht die Jobs auch und kann auf Abbrueche sogar
selbst reagieren. So koennten man beispielsweise einen auf ServerA
abgebrochenen Copy-Job gleich auf ServerB nochmal anstarten lassen.

> Ich koennte mir vorstellen, dass ich anstelle von cron einen Dienst
> verwende (nehmen wir einfach mal sshd, aber das ist nur ein Beispiel),
> der von aussen angesprochen wird. Das Ganze ist verteilt auf sagen wir 3
> Systeme. Fuer jeden "Job" gibt es beispielsweise einen eigenen TCP-Port,
> also zB 4711, 4712, 4713, 4714, ... auf allen 3 Systemen jeweils alle
> oder eine beliebige Teilmenge der "Ports".
> 
> Durch einen authentifizierten Connect auf diesen Port wird der damit
> assoziierte Job ausgefuehrt. Das ganze wird dann ueber einen Loadbalancer
> angesprochen, der einen eingehenden Request zB fuer 4714/tcp auf
> ServerB:4714 durchreicht, waehrend er zufaellig einen parallel eingehenden
> Request auf :4712 auf ServerC:4712 durchreicht.
> 
> Jetzt braeuchte ich "nur" noch einen zentralen Dienst, der via LoadBalancer
> fuer die verschiedenen konfigurierten Jobs die jeweiligen Zugriffe
> startet und somit auf einem der Server{A,B,C} den entsprechenden Job
> dann triggert.
> 
> Aber hier ist genau wieder der Knackpunkt: Ich brauche hierfuer eine
> singulaere Instanz, die selbst wieder hochverfuegbar aufgebaut sein muss.
> Aber genau das erwarte ich von einem Jobscheduler, dass er konfigurierte
> Jobs sicher zur Ausfuehrung bringt (und ueberwacht), auch wenn das Blech
> auf dem der Scheduler installiert ist mal wackelt.
DER OSJS bietet auch die Moeglichkeit an Jobs als Webservices zu konfigurieren
und anzusprechen. Wie genau das deinen Anforderungen entspricht kann ich dir
allerdings nicht sagen.
Der OSJS bietet die Moeglichkeit ein  Job Scheduler Backup Cluster ein
ausfallsicheres System aufzubauen, das aus einem primaeren Job Scheduler und
mindestens einem Backup Job Scheduler besteht, die sich ueber Heartbeats
ueberwachen.
Ob OSJS auch mit Loadbalancer wie von dir gewuenscht umgehen kann, kann ich
nicht wirklich beurteilen, aber er bringt fuer ein Cluster eine eigene
Loadbalancer-Funktion mit.

> Die Idee eines einfachen runjob-Wrappers, der sich per multicast mit
> seinen (allen) Nachbarn synct, noch mit die beste weil einfachste
> Loesung ("KISS Prinzip"). Das waere dann auch nicht beschraenkt auf cronjobs,
> sondern koennte auch aus anderen Konstrukten her in einer Form verwendet
> werden, dass bestimmte Prozesse sich ueber Systemgrenzen hinweg "abstimmen".
> 
> Einzig: Ich kenne so ein Tool bisher nicht und kann mir sowas auch nicht
> mal eben selbst programmieren. Ideen anyone?
> 
Die Idee des runjob-Wrappers mit Multicast-Synchronisation ist sicher sehr
interessant, aber auch nicht ganz trivial. Ausserdem koennte in groeÃ?eren
Netzwerken die Infrastruktur Probleme machen, da Multicast-Kommunikationen in
den meisten Systemen nicht "von Haus aus" ueber Switch-Grenzen hinweg
funktioniert.

Bevor Du selber was programmierst, solltest Du dir vielleicht mal den OSJS
ansehen ;-)

Gruss Tom



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/