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

[Raphael Eiselstein <rabe@xxxxxxxxx>]

On Fri, Dec 17, 2010 at 08:49:55PM +0100, Markus Hochholdinger wrote:
> Hi,
> 
> Am 17.12.2010 um 18:39 Uhr schrieb Thomas Stiefel <Tom@xxxxxxx>:
> > ich bin neu hier und wollte auch mal meinen Senf dazu geben ;-)
> 
> aber immer doch :-)
> 
> 
> > On Thu, Dec 09, 2010 at 10:23:03AM +0100, Alexander Holler wrote:
> > > > Gibt es eine *einfache* Loesung basierend auf NFS?
> > >  Ich wuerde das eigentliche Problem beseitigen. D.h. die offensichtlich
> > >  zentrale Aufgabe (sonst waere Mehrfachausfuehrung ja wohl kein
> > >  Problem), zentral erledigen lassen, oder die Problemstellung so
> > >  angehen, dass Mehrfachausfuehrung kein Problem ist.
> > Ich sehe das genauso. Wenn es schon einen zentralen Server gibt, der fuer
> 
> Ist die Frage ob es "EIN" zentraler NFS-Server ist oder ob einfach nur der 
> Dienst nfs "hochverfuegbar" ist!?

Ich gehe von einem hochverfuegbaren Dienst mit NFS aus, d.h. ein
NFS-Serverpaar, das mit zB Heartbeat und drbd hochverfuegbar NFS
anbietet, nur um mal eine Technologie zu nennen.
 
> 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. 
 
> > Mi rsync und SSH-Keys ist sowas total easy einzurichten und das benutze
> > ich eigentlich schon seit Jahren immer wieder in dieser Art.
> Ich denke das wuerde Raphael hinbekommen, wenn er das benoetigt ;-)

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. 

Da es wie erwaehnt eben diese CopyJobs gibt, die per cron aufgerufen
werden, ist es nicht weiter schlimm, wenn der gleiche Job auf 2 Servern
gleichzeitig ausgefuehrt wird, das erzeugt schlimmstenfalls einfach
sinnlosen Traffic oder I/O auf den Storages hinter den NFS-Servern.

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. 

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).

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.

Ein Scheduler bringt leider eine gewisse Komplexitaet mit, die ich durch
"kooperatives Multitasking" der verteilten Cronjobs gerne durch
"intelligente Lockfiles" an zentraler Stelle geloest haette, also 
Lockfiles, die von selbst verschwinden, wenn der assoziierte Prozess 
"weg" ist (egal ob regulaer beendet, durch kill -9 abgeschossen oder 
durch spontanen Stromausfall).

Alternatives Konzept: ein verteilter cron-daemon, der sich per multicast 
ueber mehrere Systeme hinweg synct und "abstimmt", sodass auf jedem System
immer bekannt ist, welche Jobs derzeit aktiv laufen und entsprechend
nicht neu ausgefuehrt werden sollen/duerfen. Das waere ausfallsicher und
kommt ohne zentrale Instanz ("Master") aus. 

Statt einer Alternative fuer cron koennte hier auch ein wrapper verwendet 
werden, der per multicast das Aequivalent eines PID/Lockfiles pro Job 
implementiert, sodass ein cronjob ganz traditionell ueber /etc/crontab 
oder /etc/cron.d/ so aussehen koennte:

-----------------------------
10 8-18 * * * jobuser runjob --jobname importABC --parallel=2 /opt/jobs/bin/importABC.sh
-----------------------------

... wobei "importABC" der symbolische Name fuer den Job ist, den es im
Netz als "laeuft derzeit bei mir" zu markieren gilt bzw. geprueft werden
kann, ob unter diesem Namen die maximale Anzahl der parallelen Jobs
(einer Klasse) bereits erreicht ist, zum Beispiel wenn man eine 2-aus-3
Ausfallsicherheit haben moechte. 

Dieser "runjob"-Wrapper wuerde also dafuer sorgen, dass beliebige Jobs
nicht kollidieren, obwohl sie potenziell zeitgleich auf verschiedenen
Systemen gestartet werden koennten.

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?

Gruss
Raphael

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyterægmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
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/