PARS-Mitteilungen 2007 - Parallel-Algorithmen, -Rechnerstrukturen ...

Behandlung offener Netzwerkverbindungen bei Prozessmigration
Andreas Bergmann
Jörg Schneider
Technische Universität Berlin
Hans-Ulrich Heiß
1 Einleitung
Verschiedene Ansätze sind bekannt, um verteilte Rechner
so zusammenzufassen, dass sie als ein Rechnerverbund
agieren. Für lose gekoppelte parallele Anwendungen eignen
sich besonders die sogenannten Networks of Workstations.
In einem solchem Netzwerk stehen die Rechner
nicht exklusiv für die Anwendung zur Verfügung und sind
nur über ein einfaches Verbindungsnetzwerk verbunden.
Ein solches Netzwerk kann nur effizient arbeiten, wenn
die Rechenlast gleichmäßig und unter Berücksichtigung
der sonstigen Nutzung verteilt wird. Eine gute Lastverteilung
muss auf wechselnde Rechnerauslastungen reagieren
und einzelne Komponenten einer parallelen Anwendung
auf andere Rechner verschieben können. Das Verschieben
einer laufenden Anwendung oder eines Anwendungsteils
von einem Rechner auf einen anderen wird Prozessmigration
genannt.
Bei der Migration wird der aktuelle Zustand eines Prozesses
gesichert, auf einen anderen Rechner übertragen
und dort ab dem gesicherten Zustand wieder weiter ausgeführt.
Falls der Zustand des Prozesses auch von seiner
Umgebung abhängig ist, wie zum Beispiel von einer
geöffneten Datei, kann er entweder nicht migriert werden
oder die alte Umgebung muss auf dem neuen Rechner
nachgestellt werden. Dazu wäre es nötig, die Umgebung
ebenfalls zu kopieren. Das ist bei Dateien möglich, funktioniert
aber bei Netzwerkverbindungen nicht.
Wir stellen ein Verfahren vor, um eine geöffnete Netzwerkverbindung
nach der Migration wiederherzustellen.
Die Wiederherstellung läuft vollständig auf Benutzerebene
und ist damit leicht in bestehende Netzwerke zu integrieren.
Im Folgenden beschreiben wir kurz die bisher verwendeten
Ansätze zur Migration von Prozessen und dem Umgang
mit offenen Netzwerkverbindungen dabei. Danach
stellen wir unser Verfahren und die Ergebnisse vor, die
wir durch Experimente mit einer prototypischen Implementierung
des Verfahren gewonnen haben.
2 Bekannte Verfahren
Die Umleitung bestehender Netzwerkverbindungen kann
auf verschiedenen Ebenen des Netzwerkprotokolls umgesetzt
werden. Auf einer niedrigen Protokollebene wäre
die Umlenkung der Netzwerkdaten, zum Beispiel mit
Hilfe einer Protokollerweiterung ähnlich der TCP Migrate
Option[4] oder durch Änderung des Routings[1]
denkbar. Die Umsetzung auf der höchsten Protokollebene
wäre innerhalb der Programmlogik der Anwendung
durchzuführen.
Die übliche Herangehensweise bei der Prozessmigration
liegt in der Mitte und soll am Beispiel zweier bekannten
Cluster-Verwaltungssysteme vorgestellt werden.
Beim MOSIX-Projekt[2] wird der Rechner, auf dem
das Programm zuerst gestartet wurde, zum Heimatknoten.
Auf dem Heimatknoten läuft ein Stellvertreter, welcher
die Dateisystemzugriffe und Netzwerkkommunikation
übernimmt. Nach der Migration eines Prozesses werden
alle ein- und ausgehenden Pakete über den Stellvertreter
weitergeleitet. Für die Anwendung ist diese Umleitung
unsichtbar und eher als Ausnahme gedacht. Prozesse
mit hohem Kommunikationsaufkommen werden deshalb
auf ihren Heimatknoten zurückmigriert.
Beim Condor-Framework[3] sind Migrationen von
Netzwerkverbindungen zwar möglich, allerdings wird ein
Prozess nicht migriert, solange eine Verbindung offen ist.
Solange ein Prozess nur kurze Nachrichten an einen bekannten
Partner schickt und dann die Verbindung beendet,
kann er von Condor migriert werden.
3 Automatisches Wiederverbinden
nach der Prozessmigration
Bei dem im Folgenden vorgeschlagenen Verfahren wird
eine Netzwerkverbindung vor der Migration beendet und
danach wieder direkt zwischen beiden Endpunkten aufgebaut.
Damit weder die Anwendung noch das zugrundeliegende
Betriebssystem dafür geändert werden muss, wird
eine Zwischenschicht im Benutzerbereich hinzugefügt.
Die Zwischenschicht wird als Bestandteil einer Anwendung
mit ihr zusammen auf den neuen Rechner migriert.
Allerdings erfährt sie genauso wenig wie die Anwendung
vom Ziel der Migration. Deshalb ist es nicht möglich, vor
der Migration mit der Gegenstelle die Adressen für eine
Wiederherstellung der Verbindung auszuhandeln. Aus
diesem Grund wird schon beim Verbindungsaufbau für jede
Seite ein Port für das Wiederverbinden ausgehandelt.
Nachdem einer der Partner migriert wurde, stellt er eine
48