HTW Dresden > GaFrame
 

Verteilte Verarbeitung

In einigen vorstellbaren Szenarien kann auch die im vorherigen Abschnitt vorgestellte Möglichkeit der Parallelisierung die benötigte Rechenzeit nicht in "erträgliche" Dimensionen rücken. Wenn in einem solchen Fall dann (z.B. in einer Hochschulumgebung) außerdem noch eine große Anzahl an Rechnern zur Verfügung steht, kommt der Wunsch auf, den Genetischen Algorithmus nicht nur auf mehrere Prozessoren sondern gleich auf mehrere Rechner zu verteilen.

Auch diese Möglichkeit, die verteilte Verarbeitung (oder Clusterbetrieb), ist in GaFrame umgesetzt und kann direkt genutzt werden.

Verteilte Verarbeitung in GaFrame

Aus den bereits erläuterten Gründen wird auch im Falle der verteilten Verarbeitung nur die Berechnung der Fitnessfunktion parallelisiert. Das angewendete Verfahren basiert auf der bereits vorgestellten Parallelisierung und erweitert diese, wobei die Möglichkeiten der Remote Method Invocation (RMI) genutzt werden.

Dabei tritt der Rechner, auf dem der Genetische Algorithmus gestartet wurde, als Koordinator auf und führt sämtliche Berechnungen bis auf Fitnessberechnungen selbst durch. Auf beliebig vielen anderen Rechnern laufen währenddessen RMI-Server, die bei Programmstart mit der zu nutzenden Fitnessfunktion initialisiert wurden.

Als zusätzliches Feature sind auch die Serverprozesse weiter parallelisiert: Pro Server werden so viele Fitnessberechnungsthreads erzeugt, wie Prozessoren/Kerne vorhanden sind. Dadurch werden auch die entfernten Rechner optimal ausgelastet.

Im Verteilungsdiagramm wird die Situation deutlich: Eine Instanz von GeneticAlgorithm kann auf beliebig viele Server zugreifen, die wiederum mehrere Objekte vom Typ RemoteFitness zur Verfügung stellen.

Verteilungsdiagramm für den Clusterbetrieb

Sobald Fitnesswerte zu berechnen sind, werden (wie bei der Parallelisierung) die entsprechenden Individuen in eine Warteschlange gefüllt. Die Fitness wird jetzt aber nicht lokal berechnet, sondern auf den entfernten Rechnern. Die Chromosomen der Individuen, deren Fitness zu berechnen ist, werden hierzu serialisiert und an die entsprechenden Server weitergegeben. Die Server führen dann die Berechnung durch und geben die Fitnesswerte an den Koordinator zurück.

Durch die Nutzung von RMI ist die Umsetzung der verteilten Verarbeitung transparent. Die entfernten Objekte (RemoteInterfaces) müssen lediglich beim Start des Genetischen Algorithmus initialisiert werden, im weiteren Programmverlauf ändert sich (gegenüber dem Betrieb in Parallelisierung) nichts. Das folgende Objektdiagram verdeutlicht dies nochmals:

Objektdiagramm Clusterbetrieb

Mehraufwand entsteht allerdings dadurch, dass der Quellcode der Fitnesfunktion sowie die GaFrame-Bibliothek auf die Server verteilt und die Serverprozesse dort gestartet werden müssen. Hinweise hierfür finden sich unter Verteilte Verarbeitung.

Sollte im Verlauf des Genetischen Algorithmus einer der entfernten Server ausfallen, läuft der Genetische Algorithmus trotzdem weiter (solange noch mindestens 1 Server zur Verfügung steht), der ausgefallene Server wird einfach ignoriert.