Diese Arbeit beschäftigt sich mit dem Online-Steering von Gridjobs. Das Online-Steering wird in vier Teilaufgaben zerlegt: Die Kommunikation, die Datenkonsistenz, automatisierte Auswertungen und Optimierungen und der Datenzugriff.
Der Schwerpunkt dieser Arbeit liegt in der Teilaufgabe, die sich mit der Datenkonsistenz beschäftigt. Hierfür wird ein neues Konzept vorgestellt, das Online-Steering als Zugriffe auf Daten in einem virtuellen verteilten gemeinsamen Speicher betrachtet. Es werden die Intra-Prozess und die Inter-Prozess Bedingung identifiziert, die Regeln für den Datenaustausch definieren, die die Integrität der Daten sichern sollen. Je nach Anwendung müssen dafür beide Bedingungen erfüllt werden oder es reicht die Erfüllung der Intra-\Prozess Bedingung.
Ausgehend von den Integritätsbedingungen werden die Spezielle Schwache Konsistenz und die Verzögerte Schwache Konsistenz definiert, die die Intra-Prozess Bedingung erfüllen. Ferner wird, basierend auf einem CUMULVS-Algorithmus, die Zeitplan-Konsistenz definiert, die beide Bedingungen erfüllt. Zusätzlich kann es Daten geben, für die keine der beiden Bedingungen erfüllt sein muss. Bei der Speziellen Schwachen Konsistenz und der Verzögerten Schwachen Konsistenz müssen jeweils nur ein Steering-Prozess und ein Anwendungsprozess miteinander kommunizieren. Für beide Konsistenzmodelle wurde je ein Aktualisierungsprotokoll und ein Invalidierungsprotokoll entworfen und implementiert. Zusätzlich wurden auch ein Aktualisierungsprotokoll und ein Invalidierngsprotokoll für die PRAM-Konsistenz implementiert. Anhand dieser Implementierungen wurde das Laufzeitverhalten der Protokolle untersucht.
Bei der Evaluation wurde festgestellt, dass die Protokolle der Speziellen Schwachen Konsistenz, aufgrund der strengen Ordnung der Synchronisationspunkte, langsamer als die Protokolle der Verzögerten Schwachen Konsistenz sind. Dieser Unterschied verstärkt sich, wenn die Round-Trip-Zeit im Netzwerk wächst.
Um Online-Steering mit Gridjobs zu ermöglichen, muss mit dem Gridjob kommuniziert werden können. Es wurde in dieser Arbeit eine Kommunikationsschicht entwickelt, die eine sichere Kommunikation zum Gridjob aufbauen kann. Dabei sollte das Sicherheitskonzept der Site aufrecht erhalten werden können. Es wurden daher mehrere Szenarien entwickelt, die je nach Konfiguration der Site zum Einsatz kommen. Das zu verwendende Szenario kann dabei dynamisch ermittelt werden.
Der Durchsatz und die Round-Trip-Zeit der Kommunikationsschicht bei verschiedenen Szenarien und Sicherheitsstufen wird evaluiert.
Das Verhalten der Kommunikationsschicht kann mit einer Pipeline modelliert werden. Der Durchsatz wird von der Pipelinestufe mit dem geringsten Durchsatz bestimmt. Bei Netzwerken, wie sie zwischen den deutschen LCG-Sites bestehen, führt die Verwendung von Verschlüsselung zu einer Limitierung des Durchsatzes durch die Rechenzeit auf den sendenden und empfangenden Rechnern. Bei der Verwendung einer zweiten Sicherheitsschicht ohne Verschlüsselung, war bei eindirektionalem Datentransfer die Bandbreite limitierend. Wenn in beide Richtungen gleichzeitig gesendet wird, wird die Rechenzeit an den Endpunkten kritisch, da bei voll-duplex Netzwerken die Übermittlung von Daten mit maximaler Bandbreite in beiden Richtungen gleichzeitig erfolgen kann, während die Rechenzeit zum Ein- und Auspacken der Nachrichten sich addiert.
Zu der Round-Trip-Zeit fügt jede Komponente einen additiven Bestandteil bei. In Anbetracht der Round-Trip-Zeit zwischen zwei Sites sind die zusätzlichen Zeiten für einen Verbindungsdienst und die Sicherheitsschichten vernachlässigbar.
Die Optimierung und der Datenzugriff werden in wesentlich geringerem Umfang behandelt als die Datenkonsistenz und die Kommunikation. Die Optimierungsidee basierte auf der Annahme, dass die Netzwerkbandbreite den Durchsatz limitiert. Es soll zwischen dem Aktualisierungprotokoll und dem Invalidierungsprotokoll, dasjenige gewählt werden, dass die beste Perfromance bietet.
Bei dem Datenzugriff geht es darum, Datenzugriffe der Anwendung abzufangen und Methoden des Steering-Systems aufzurufen, so dass das Steering-System auf die Datenzugriffe reagieren kann. Hierbei werden zunächst einige Klassifizierungen vorgenommen, die sich darauf auswirken, wie das Steering-System auf diese Datenzugriffe reagieren kann oder soll.
Mit der Implementierung in RMOST können Jobs des ATLAS Experiments gesteuert werden.