interessante Frage - Prozesse verlagern

Hallo,

mich würde mal interessieren, wie man vorgehen müsste, wenn man ein schon laufendes Programm, also einen
Prozess, von einem Rechner auf einen anderen verlagern/migrieren möchte?
Was sind die Voraussetzungen hierfür?
Wie kann man das anstellen?

Also jeder Prozess unter Linux hat ja seinen eigenen Speicherbereich. Und auf einem Single-Prozessor-System kann ja sowieso nur ein Task gleichzeitig am Prozessor hängen, alle anderen müssen ja schlafen.

Geht das? Wie?

Ciao it.

 

Auch wenn heute schon der 8 Februar ist, ...

Also ich habe das Zeug abgegeben und mein Dozent meinte, dass wir ja auch überlegen sollten, was dazu nötig wäre.

Dass es nicht reibungslos klappt, (Zitat) "kann man daran erkennen, dass es noch kein Feature einer aktuellen Software oder eines aktuellen Betriebssystem ist."


Also es geht nicht "ohne Weiteres".

Ciao it.

 

Meines wissens kannst du die betreffenden dateien/ordner mit rsync synchronisieren, damit wäre das problem auch vermieren.

buhi

 

# und seinen Speicherbereich kopiert (Pages), dann
# m"usste es doch gehen.
Der Speicher ist zwar in Pages unterteilt und jeder Prozess liegt "in" Pages, aber der einem Prozess zugeteilte Speicher heißt nicht Pages. Nur so als Anmerkung. (:

Deine eigentliche Frage ist (bis auf die theoretische Sache mit Process Checkpoints) ganz simpel mit Nein zu beantworten.

Ist die Frage vielleicht anders gemeint?

 

Mit Unix kenn ich mich nicht so doll aus; habe grad mal in Linux reingeschnuppert.

Aber das mit den Descriptoren... liegt mir im Magen.

Beispiel:
Proggy öffnet Datei
Proggy schreibt was rein
Proggy wird versetzt
Proggy liest was aus der Datei
Proggy stürtzt ab, weil die Datei nicht (bzw wo anders) existiert.

Man müsste eine komplette HAL basteln, durch die alle IO-Streams des Proggys durch müssen. Wenn die HAL (=VM) entsprechend gestaltet ist, dann kann sie natürlich sowas abfangen und den Zugriff auf den richtigen Rechner weiterleiten, der dann die Datei liest und die Daten zurückschiebt. Dadurch kommt ein immenser Verwaltungsaufwand dazu.

Andere Idee: was ist wenn man statt "lokalen" Namen URL's verwendet? Sowas wie file://<RechnerID>/Verz/Datei.abc oder
Screen://<RechnerID>/0

Das würde den Overhead vermindern, aber das Proggy wird dafür komplexer

 

Hallo sarkastic_one,

vielleicht kann man ein Unix als VM sehen.
Immerhin sind die genannten Operationen (Datei "offnen, lesen, schreiben) System Calls.
Also ein Programm sagt dem System, bitte eine Datei X "offnen, darauf hin gibt das System dem Programm einen Filedescriptor (einen Pointer).

Genauso beim Lesen und Schreiben.
zu finden in man read(2) und man write(2). read(3) und write(3) greifen schliesslich auch nur auf die System Calls zur"uck.

Ausserdem ist ja jeder Prozess unterbrechbar, da ja der Unix Scheduler jeweils einen Prozess eine gewisse Zeit auf dem Prozessor zuweist und auch unterbricht.

Wenn man den Scheduler beeinflussen kann und einen Prozess komplett unterbrechen kann und seinen Speicherbereich kopiert (Pages), dann m"usste es doch gehen.

Gibt es da irgendein Veto?

Ciao it.

 

Meines bescheidenen Wissens nach sollte es - unter Verränkungen - folgendermaßen gehen:

1) Der Prozess verwendet eine virtuelle Umgebung, also z.B. eine Java-VM (damit entgehst du blakcomb's Argumenten)

2) Die Programme dürfen nichts voraussetzen und jeder Zugriff auf Dateisysteme, Bildschirm, Hardware usw muß eine Transaktion sein. Also nix mit Handles; Datei öffnen, Datei lesen/schreiben, Datei schließen muß eine einzige Operation sein. Sonst kann es zu Daten-Inkonsistenzen kommen.

3) Die Programme müssen jederzeit unterbrechbar sein (nichts zeitkritisches)

4) Das Programm muß jederzeit seine Ausgaben neu schreiben können.

Hmmm....
Hört sich nichtmal sooo komplex an. Das meiste ließe sich durch anpassen der VM realisieren (das mit den Zugriffen und den gespeicherten Ausgaben). Wahrscheinlich läuft es darauf hinaus, dass nicht nur der Thread selber sondern der komplette Dateninhalt der VM übertragen werden muß (so eine Art Speicherabbild).
Schwierig wird es dann aber mit den Ein/Ausgaben. Die müssen natürlich immernoch zum richtigen Terminal geleitet werden - auch wenn das Proggy mehrmals den Rechner gewechselt hat.

 

Auf die Antwort des Dozenten bin ich gespannt.

Es wäre nett, wenn du dich nach dem 29.1. noch an diesen Thread erinnerst und uns einmal informierst.

 

Wozu ich das brauche?

Ganz einfach: ich mache gerade ein Unix-Praktikum. die letzten Aufgaben waren alle recht einfach. IPC und ein bisschen mit fork() rumgespielt.

Nun ist die eben oben gestellte Frage auf meinem Arbeitsblatt von gestern.
Ich habe bei google gesucht, alle Folien durchschaut, allen Links von Docenten verfolgt. Selbst nach seinen Arbeiten an der Uni und sonst gesucht. Ich habe dann diverse Unix-Dokus und Papers gesucht und überflogen, aber nichts gefunden.

Diese Aufgabe fällt total aus dem Schema des Kurses heraus und ich finde nichts zum Nachlesen, ob es geht. Wenn er aber so eine Frage stellt, vor allem so stellt, dann müsste es eine Lösung geben.

Glücklicherweise habe ich bis zum 29. Jan Zeit irgendetwas zu finden.

Ciao it.

 

Mit Process Checkpoints (Dragonfly hat sowas), kannst du Prozesse beispielsweise über einen Reboot hinaus retten und später wieder starten. Zuminde theoretisch sollte es damit möglich sein, den Prozess auch auf einen anderen Rechner zu hieven. Praktisch kann ich mir gut vorstellen, daß es sehr große Probleme geben könnte. Wozu brauchst du sowas?

 

Interessante frage, einfache antwort: es geht nicht.
Dazu müssten die 2 rechner zu 100% idente platten haben und gleiche hardware besitzen. Dann müsstest du nur noch das speicherabbild rüberschaufeln... das ist aber meines wissens nicht möglich. (vielleicht eventuell mit software-suspend, da wird der prozess jedoch auch unterbrochen)

gruß, buhi