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

Autor: Thomas Stiefel <Tom_at_vTux.de>
Datum: Mon, 20 Dec 2010 13:00:11 +0100
Hallo Raphael,

ich wollte nie deine Fähigkeiten anzweifeln und hätte auch nicht 
gedacht, dass es sich um ein so komplexes Setup für eine eigentlich 
relativ einfache Aufgabe handelt.

Aber wie auch immer die Umgebung aussieht, Probleme sind dazu da, dass 
sie gelöst werden und hier ist die Herausforderung eben etwas größer, 
aber damit auch interessanter ;)

Raphael Eiselstein schrieb am 18.12.2010 00:16:
>> Ist halt die Frage ob der nfs-Server dafür ausgerüstet 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 hochverfügbar NFS-Server die Rede war, bin ich von 
UNIX-/Linux-Systemen ausgegangen.

Daher bietet sich für mich an ein schon hochverfügbar aufgebautes System 
auch für andere Zwecken zu nutzen und die Hochverfügbarkeit nicht 
nochmal zu implementieren. Da hier aber wohl "nur" das NFS über BRBD 
hochverfgübar ist, dann ist die Ausgangsposition eine andere.

> Es gibt im konkreten Setup mehrere hochverfügbare NFS-Quellen, die
> allesamt auf mehreren unabhängigen Servern gemountet sind. Diese Server
> bieten irgendwelche Dienste an, hier zB im Rahmen eines Datawarehouses
> den Import und Export von Daten (in Dateiform) durchführen.
>
> Da Daten (Dateien) kontinuierlich beschafft und verarbeitet werden müssen,
> sollte unter keinen Umständen die Beschaffung (Import) von Daten
> unterbrochen werden. Um das zu gewährleisten betreibe ich mehrere Rechner,
> die bestimmte Copy-Jobs ausführen. Ich nehme dafür mehrere Server nicht,
> weil es zuviel Last wäre für nur einen, sondern weil ich damit eine
> Ausfallsicherheit bekomme und zusätzlich 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
> über 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  für bestimmte Mandanten zur Abholung
> angeboten, auch hier per IPVS-Loadbalancer, auf dem ein ldirectord
> regelmäßig prüft, 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
> ausschließlich auf nur einem Server verfügbar ist.
>
Das von dir beschriebene Setup ganz klar nach einem Enterprise-Szenario 
an, das bestimmt auch Workflows enthält bei dem Daten von einem System 
über ein zweites in ein drrittes System wandern.
Hier würde sicher nicht nur ein Job-Scheduler für die angesprochenen 
Copy-Jobs Sinn machen, sondern der durchgehende Einsatz eines solchen.
So kann man bestimmte Abläufe effizienter gestalten, da man nicht nur in 
Abhängigkeit eines Jobs seinen direkten Nachfolger starten lassen kann, 
sondern auch bei Abbrüchen innerhalb einer größeren Job-Kete problemlos 
an genau diesem Punkt die Verarbeitung wieder aufsetzten.

Dienstlich arbeite ich hier mit UC4, aber das ist nicht gerade günstig 
was die Lizenzen angeht. Auch die anderen mir bekannten 
Automatisierungs- bzw. Scheduler-Tools sind meist nicht unbedingt 
günstig. Ein Ausnahme bildet hier der "Open Source Job Scheduler" 
(OSJS): http://jobscheduler.sourceforge.net/
> Ich suche also nach einer Möglichkeit in diesem vorne und hinten und in
> der Mitte redundant ausgelegten System wiederkehrende Jobs verteilt auf
> mehreren Systemen auszuführen und dabei sicherstellen, dass identische
> Jobs sowohl pro System aber auch im gesamten Verbund nie parallel
> ausgeführt werden.
>
Dies kann der OSJS auf jeden Fall, aber er kann - wenn dies gewünscht 
ist - auch Jobs auf einer bestimmten Anzahl an an Systemen parallel 
ausführen.
DER OSJS kann darüber 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 könnten da
> helfen, aber wenn ein CopyJob einmal abstürzt, hinterlässt er dann
> PID-Files mit nicht mehr gültigen PIDs oder Lockfiles, die ihren Lock
> nicht verlieren. Also suche ich nach einer Möglichkeit zweifelsfrei
> und mit geringem technischen Aufwand herauszufinden, ob PID/Lockfiles
> noch "gültig" sind.
>
> Oder, weil cron hier eher das Problem darstellt: Einen verteilten
> Job-Scheduler, der ohne zentrale Instanz auskommt und trotzdem dafür
> sorgt, dass konkrete Jobs nie mehr als einmal parallel ausgeführt werden
> *und* eine Fehlerbehandlung ermöglicht, wenn ein Job einmal unsauber
> abgebrochen ist, etwa weil Quelle oder Ziel plötzlich nicht mehr
> verfügbar sind (Timeout).
DER OSJS sorgt nicht nur über eigene Routinen dafür, dass Jobs nur 
einmal parallel laufen, sondern überwacht die Jobs auch und kann auf 
Abbrüche sogar selbst reagieren. So könnten man beispielsweise einen auf 
ServerA abgebrochenen Copy-Job gleich auf ServerB nochmal anstarten lassen.

> Ich könnte 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. Für 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 ausgeführt. Das ganze wird dann über einen Loadbalancer
> angesprochen, der einen eingehenden Request zB für 4714/tcp auf
> ServerB:4714 durchreicht, während er zufällig einen parallel eingehenden
> Request auf :4712 auf ServerC:4712 durchreicht.
>
> Jetzt bräuchte ich "nur" noch einen zentralen Dienst, der via LoadBalancer
> für 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 hierfür eine
> singuläre Instanz, die selbst wieder hochverfügbar aufgebaut sein muss.
> Aber genau das erwarte ich von einem Jobscheduler, dass er konfigurierte
> Jobs sicher zur Ausführung bringt (und überwacht), auch wenn das Blech
> auf dem der Scheduler installiert ist mal wackelt.
DER OSJS bietet auch die Möglichkeit an Jobs als Webservices zu 
konfigurieren und anzusprechen. Wie genau das deinen Anforderungen 
entspricht kann ich dir allerdings nicht sagen.
Der OSJS bietet die Möglichkeit ein  Job Scheduler Backup Cluster ein 
ausfallsicheres System aufzubauen, das aus einem primären Job Scheduler 
und mindestens einem Backup Job Scheduler besteht, die sich über 
Heartbeats überwachen.
Ob OSJS auch mit Loadbalancer wie von dir gewünscht umgehen kann, kann 
ich nicht wirklich beurteilen, aber er bringt für 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
> Lösung ("KISS Prinzip"). Das wäre dann auch nicht beschränkt auf cronjobs,
> sondern könnte auch aus anderen Konstrukten her in einer Form verwendet
> werden, dass bestimmte Prozesse sich über 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. Außerdem könnte in 
größeren Netzwerken die Infrastruktur Probleme machen, da 
Multicast-Kommunikationen in den meisten Systemen nicht "von Haus aus" 
über Switch-Grenzen hinweg funktioniert.

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

Gruß 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/
Empfangen am 20.12.2010

Dieses Archiv wurde generiert von hypermail 2.2.0 : 20.12.2010 CET