Prozess-Steuerung im Netzwerk

I

Indi

Member of Honour
Ich hoffe der Thread-Titel war einigermaßen passend.

Folgendes Szenario:
Ein lokales Linux-Netzwerk von variabler Größe. Auf den meisten läuft eine MySQL-Datenbank. Ich führe auf den einzelnen Rechnern eine Menge verschiedener PHP- und Perl-Scripts aus. Das Problem dabei ist, dass ich das ganze nicht über Cron-Jobs regeln kann, da die Resultate des einen Scripts auf andere Scripts enorme Auswirkungen hat. Läuft bei Script A alles ok, soll auf einem anderen PC Script B ausgeführt werden, läuft etwas schief, auf einem anderen PC wieder Script C, usw.

Ich könnte natürlich wenn Script A ausgeführt wurde zb. über SSH auf dem entsprechenden remote Computer das nächste Script auführen, dabei kommt aber so wie ich das sehe eventuell ein ziemliches Chaos hinaus, außerdem hab ich dadurch auch keinen schönen überblick über die jeweiligen Rück- bzw. Ausgabewerte. Außerdem wäre das auch nicht transparent genug, wenn ich zb. zwei Computer für eine Aufgabe zur Verfügung stelle, wobei einer einfach nur zur Verfügung steht, falls der andere down ist.

Da ich ohnehin sehr intensiv mit SQL-Zugriffen arbeite, dachte ich mir, ich verwende einen Computer als Job-Control, sozusagen, von dem aus alle Aufgaben verteilt und geregelt werden. Dadurch könnte ich auch auf dem Job-Control-PC eine SQL-DB laufen lassen, die mir eine Prozess-History bzw. die Rückgabewerte der einzelnen Scripts speichert.

Meine Frage dazu ist ob jemand eine bessere Lösung für sowas weiß.

Mir geht's vor allem um die Transparent. Wenn ich fünf neue PCs mit bestimmten Aufgabenbereiche ins Netzwerk integriere, will ich dafür nicht alle anderen PCs dementsprechend umkonfigurieren müssen. Desweiteren sollte die Job-Control höchst effizent laufen.

Ich hoffe ich hab meine Sorgen einigermaßen gut erklärt. Für jede Hilfe bzw. Gedankenanregung bin ich im voraus schon dankbar.
 
ich habe zwar keine Ahnung von solchen Problemstellungen aber ich versuche es trotzdem.

Wenn du einen JOB-Control-PC einsetzt mit ner DB drauf könnterst du die skripte ja direkt in der DB abspeichern und kannst diese schon mal zentral verwalten. Um diese Skripte auszuführen müsstest du dir ein kleines tool basteln das auf den verschiedenen "slaves" läuft und nach einem Broadcast der DB seine "Jobs" abholt, ausführt und das Ergebniss anschließend auf dem Job-Control-PC ablegt. Welches Skript auf welchem Slave läuft kannst du ja dann zentral in der DB steuern. Ist aber recht ineffizient :-)

Normalerweise übernimmt solche aufgaben ein Cluster BS soder die entsprechende MiddleWare
 
hört sich interessant an.
die MPI Leute und die Beowulf Leute haben sich da bestimmt schon viele Gedanken zu gemacht. Dito diejenigen, die an Verteilten Systemen und an Verläßlichen Systemen forschen.
http://www-unix.mcs.anl.gov/mpi/ MPI
FAI
http://www.informatik.uni-koeln.de/fai/
sind vielleicht auch interessant für Dich. Die haben als Ziel eine CDROM, mit der man einen PC bootet, und er konfiguriert sich komplett selbst, holt sich eine IP Nummer, meldet sich als einer von ganz vielen gleichen an und holt sich eine Aufgabe (und außerdem ein komplettes Linux, aber das ist nur ein Seiteneffekt)
Gnutella bzw P2P
hat auch nette Ideen. nämlich wie man Knoten so designed, daß sie sich automatisch zu einem Netz zusammenfügen und auch nicht von einzelnen ausfallenden Knoten irritiert werden. Gnutella ist mW open source und du könntest es als Bibliothek bei deiner Software einbinden :-)
Oder du mißbrauchst deine mysql RDBMS als zentrale Ablage, bei sich neu hinzukommende PCs anmelden, sich eintragen, ihre jobs abholen.
Vorsicht aber bei load balancing bzw fail over. Da solltest du dann schon etwas genauer Buch führen, welcher Knoten in Produktion ist und welcher hot standby. Sonst kannst du das fail over nicht wirklich testen. Außerdem fällt da ein Versagen oder ein Lastwechsel auch nnach Aussen auf :-)

nur so ein paar unsortierte Ideen..
 
Wenn ich auchmal noch meinen Senf dazu geben darf:

Wie wäre es wenn ein (PHP, mit Perl weiss ichs nicht) - Skript über HTTP ein nächstes auslöst? Rein von dem her gesehen ohne Probleme Realisierbar, vielleicht sogar in Form einer Art Webservice.

Damit würde man die Cascade auslösen. Die "Abhängigkeiten" wäaren damit mal realisiert. Dann musst du auch nicht kompliziert auf die anderen Hosts zugreifen.

Für die Flexibilität könnte ein interner DNS Server sorgen. Wenn du neue Server hinzufügst, einfach im DNS eintragen. Mit Roundrobin (oder ähnlichem) hast du sogar Loadbalancing und verteilst die lasten auf mehrere Server, sofern mehrere für diesselbe aufgabe konfiguriert sind. Ausfallsicherheit ist damit auch gewährleistet.

Ich hoffe du siehst wie ich das machen würde. Aber nun dochmal noch die Frage: Wieso nich alles auf demselben Server? Würde mich nur interessieren :)

Viel Glück
 
Ich habe aehnliche Situationen.

Dafuer habe ich im internen Netz auf jedem Host einen Server laufen, der in Perl geschrieben ist. Jeder dieser Server ist in der Lage bestimmte jobs zu erledigen.
Die einzelnen jobs sind dann auch perl scripte, shell scripts oder eben programme.

Ueber eine zentrale Kiste kann ich diese Jobs steuern und rueckgaben auswerten.
Kommt eine neue Maschine ins Netz- bekommt die nen tarball mit nem shell script drin was das ganze installiert (services/inetd).

Neue jobs, die programmiert werden, koennen ebenfalls vom "master"host an die uebrigen kisten verteilt werden.

Was die Sicherheit angeht musste dir in solchem fall eben was ausdenken, zb alles ueber ssh tunneln..whatever. in meinem Fall habe ich dafuer nen VPN ueber ssh aufgebaut.
 
Zwischenbericht

Nachdem ich nun momentan mitten in der Lösung meiner oben beschriebenen Problemstellung arbeite, möchte ich nun auch kurz erklären, wie ich das bisher gelöst habe. Auf jeden Fall danke für die bisherigen Anregungen bzw. Links.

Nachdem der Aufgabenbereich für den dieses Netzwerk entsteht sehr eigen ist, hab ich mich dazu entschlossen den Job-Control-Prozess selbst zu gestalten. Es hätte mit Sicherheit schon verwendbare Software gegeben, mir war aber von Anfang an auch sehr wichtig, dass ich Änderungen schnell durchführen kann bzw. zu 100% weiß, was wie wo und wann in den Systemen abläuft. Zwar ist das auf diese Art und Weise extrem mühsam zu testen, da ich aber nicht unter Zeitdruck stehe und die Vorteile davon auf der Hand liegen, entschied ich mich nun für diesen Weg.

Zuerstmal hab ich die Grundidee umstrukturiert. Auf den einzelnen Clients läuft nun kein SQL-Server mehr, sondern nur noch einer zentral.

Der PC der als Job-Controller nun ins Netzwerk implementiert wurde, ist einerseits nun dafür da, die Jobs an die Clients zu verteilen bzw. die Abhängigkeiten davon zu regeln, andererseits verwalte ich dort auch ein Config-File für die jeweiligen Clients.

Auf den einzelnen Clients läuft nur eine minimale Linux-Installation. Die ist im Moment noch zu Testzwecken auf die hdd installiert, soll aber letztendlich dann auf CD gelangen. PXE ist leider nicht möglich, da ich nicht garantieren kann, dass es alle Clients unterstützen werden. Bootet nun ein Client, connectet er sich zum Job-Control und lädt vorerstmal alle benötigten Software-Pakete ins lokale Installations-Verzeichnis. Die Programme sind dann aber schon kompiliert, wodurch ich dann die jeweiligen Binaries und Libs nur noch dort hinsetze wo sie sein sollen. Das hat den Vorteil, dass ich die Software zentral verwalten kann und bei Bedarf auch Updates einspielen kann. Da es sich bei den Clients nahezu um die gleiche Hardware handelt, hab ich da auch kein Problem mit verschiedenen Kernel-Builds. Einziges kleines Problem war dass die Festplatten an den Clients unterschiedlich eingehängt sind. Kommt also ein neuer PC ins Netzwerk muss ich am Job-Controller nur ein Config-File mit den jeweiligen Einstellungen anlegen.

Die Sache mit dem Stromausfall hat sich nun auch selbst beseitigt. Hatte dazu auch einen Thread erstellt bzgl. Sicherung bei Datenbank-Servern. Bekommt ein Client einen Job wird der am Job-Controller als aktiv markiert. Nach erfolgreicher Erledigung wird er als abgeschlossen markiert, wodurch ich sofort sehe, falls auf irgendeinem Client etwas schief geht. Die einzelnen Berechnungen, die auf den verschiedenen Clients durchgeführt werden, können als gemeinsamer Durchlauf zusammengefasst werden. Jeder Durchlauf bekommt eine ID, läuft bei einem Durchlauf etwas schief, kann ich anhand der ID genau den Fehlerbereich feststellen und dementsprechend die Daten löschen und den entsprechenden Durchlauf neu starten. Dabei muss man nur darauf achten, dass man den Zeitrahmen eines solchen Durchlaufes entsprechend den eigenen Bedürfnissen anpasst. Ich hab zwar bei meinen Anforderungen den Vorteil, dass sich ein Durchlauf zeitmäßig relativ kurz haltet und es relativ egal ist, sollte ein Durchlauf einmal neu berechnet werden müssen. Allerdings dürfen dabei keinesfalls Daten ungewollt manipuliert werden. Notfalls kann man da aber auch einen Durchlauf in mehrere Teile zerteilen, mach ich aber vorerst nicht, weil ich momentan keine Notwendigkeit dafür sehe. Ein Stromausfall hat auch insofern den Vorteil, dass nach einem neuen Bootvorgang wieder ein reines System vorhanden ist. Auch wenn das System der Clients nie wirklich verschmutzt wird, werd ich da wohl in regelmäßigen Abständen das System neu booten lassen, kann man dann gleich für fsck und ähnliches verwenden.

Ein Problem dass sich mir allerdings schon noch stellt ist die Sache mit den Backups. Jemand ne Ahnung wie Datenbank-Backups bei großen Datenbanken realisiert werden? Ich weiß zwar noch nicht genau, wie ich das machen werde, aber ich möchte zumindest von bestimmten Tabellen der Datenbank ein tägliches Backup. Die Datenbank-Dateien einfach kopieren ist nicht drin, da die früher oder später zuviel Platz brauchen. Desweiteren muss ich das in einem normalen Größenbereich standardisieren, so dass ich die Backups, vom Backup-PC weiter auf DVDs brennen kann. Fehlt mir irgendwie noch die Idee dazu. Jemand ne Idee?

Ein zweiter Problempunkt ist, dass ich noch einen zweiten Job-Controller benötige, falls der erste ausfällt. Sollte die Auslastung des Backup-Servers nicht zu groß sein, werde ich dort wohl auch den zweiten Job-Controller laufen lassen. Die Datenbanken der Job-Controller kann man dann leicht synchronisieren, allerdings müssten dazu dann noch die Scripts angepasst werden und eine Routine eingebaut werden, die zwischen den beiden Job-Controllern läuft. Probleme über Probleme. ;)

Sieht vlt. jemand grobe Probleme beim bisherigen/geplanten Vorgehen? Hoffe diesbzgl. noch Denkanstösse zu bekommen.

Ich hoffe du siehst wie ich das machen würde. Aber nun dochmal noch die Frage: Wieso nich alles auf demselben Server? Würde mich nur interessieren
Zum Vergrößern anklicken....

Ich hab dafür keine tolle Hardware zur Verfügung. Daher würde die Verarbeitung zulange dauern. Aber auch wenn ich tolle PCs zur Verfügung habe, hätte ich es verteilt gemacht, da es dadurch völlig egal ist, wenn ein Computer mal nicht verfügbar ist.
 
Backups von einer SQL-Datenbank erstellst du am einfachsten durch Replikation, da das Dumping grosser Datenbanken meist mehrere Stunden in Anspruch nimmt und den Server extrem ausbremst. Willst du dann die Backups auch noch als Dateien haben, kannst du einfach Dumps vom Slave-Knoten ziehen ohne den laufenden Betrieb nachteilig zu beeinflussen. Wie das mit der Replikation z.B. bei MySQL funktioniert, kannst du unter http://www.hackerwiki.org/index.php/Datenbank-Replikation_mit_MySQL nachlesen. Zum ziehen von Dumps siehe die Manpage zu mysqldump.
 
Also die Backups koenntest du ja als cronjob machen, so wuerd ichs auf jedenfall umsetzen.
Ausserdem noch ne Frage: Wenn du das ganze aufgrund von Performance machst wieso dann mit LiveCds?
Ich haette in so einem Fall (wo viele schlechte PCs 1nen guten Server bilden sollen) ja zu Virtualisierung gegriffen. Sprich alle PCs zu 1nen virtuellen Server zusammenziehen. Zwecks ausfallsicherheit gilt hier nur, dass der Server auf dem das virtualisierungssystem laeuft laufen muss, da laesst sich aber sicher auch was machn, dass das 2 PCs uebernehmen zwecks ausfallsicherheit.
Aber da du dir die Arbeit schon angetan hast wirst du denk ich nicht mehr umsteigen wollen.
 
Wenn du das ganze aufgrund von Performance machst wieso dann mit LiveCds?
Zum Vergrößern anklicken....

Auf den LiveCds liegen dann ja nur der Kernel und die absolut elementaren Programme. Ich lad ja keinen X von CD. Also denke ich nicht, dass das einen Unterschied machen wird. Der Vorteil IMO ist, wie schon oben erwähnt, dasss ich dann immer ein 100% sauberes OS und Festplatte hab.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben