In diesem Artikel werden die Komponenten beschrieben, aus denen sich eine typische Compute-Grid-Umgebung zusammensetzt.
Der Job-Scheduler ist die Compute-Grid-Komponente, die alle Funktionen für die Jobverwaltung, z. B. Übergeben, Abbrechen und Neustart von Jobs usw., bereitstellt. Er verwaltet ein Verlaufsprotokoll aller Jobs, einschließlich der Jobs, die auf ihre Ausführung warten, bereits aktiv sind oder bereits ausgeführt wurden. Außerdem verwaltet er Nutzungsdaten für bereits ausgeführte Jobs. Der Job-Scheduler befindet sich in einem WebSphere Application Server (oder Cluster) in einer Umgebung mit WebSphere Network Deployment. Eine WebSphere-Zelle kann nur einen einzigen Job-Scheduler enthalten.
Der Stapelcontainer ist die Compute-Grid-Komponente, die die Ausführungsumgebung für die Stapeljobs bereitstellt. Stapelanwendungen, die auf Java 2 Platform Enterprise Edition (J2EE) basieren, werden im WebSphere-Stapelcontainer ausgeführt. Anwendungen für native Ausführung werden in einem gesonderten Container ausgeführt, der im folgenden Abschnitt beschrieben wird. Der Stapelcontainer befindet sich in einem WebSphere Application Server (oder Cluster) in einer Umgebung mit WebSphere Network Deployment. Eine WebSphere-Zelle kann eine beliebige Anzahl von Stapelcontainern enthalten.
J2EE-Stapelanwendungen sind reguläre WebSphere-J2EE-Anwendungen, die als EAR-Datei implementiert werden und Implementierungen einer oder mehrerer Java-Stapelanwendungen enthalten. Diese Java-Stapelanwendungen folgen dem Programmiermodell für transaktionsorientierte Stapeljobs oder dem Programmiermodell für rechenintensive Jobs.
Jobs werden mit einer Jobsteuersprache (JCL, Job Control Language) beschrieben. Compute-Grid-Jobs verwenden eine XML-basierte Jobsteuersprache. In der Jobbeschreibung werden die auszuführende Anwendung, die zugehörigen Eingaben und Ausgaben beschrieben.
Der Job-Scheduler stellt drei Typen von Anwendungsprogrammierschnittstellen (API, Application Programming Language) für den Zugriff auf seine Verwaltungsfunktionen bereit: eine Webschnittstelle (die so genannte Jobverwaltungskonsole), eine Shell-Befehlszeile (lrcmd) und Anwendungsprogrammierschnittstellen, die entweder als Web-Services oder EJBs verfügbar sind.
Der Job-Scheduler verwendet eine relationale Datenbank, um Jobinformationen zu speichern. Es kann jede relationale Datenbank verwendet werden, die von WebSphere Application Server unterstützt wird. Wenn der Job-Scheduler in einem Cluster eingesetzt wird, muss die Datenbank eine Netzdatenbank, wie z. B. DB2, sein.
Stapelcontainer verwendet eine relationale Datenbank, um Prüfpunktinformationen für transaktionsorientierte Stapelanwendungen zu speichern. Es kann jede relationale Datenbank verwendet werden, die von WebSphere Application Server unterstützt wird. Wenn der Stapelcontainer in einem Cluster eingesetzt wird, muss die Datenbank eine Netzdatenbank, wie z. B. DB2, sein.
Dies ist die JDBC-Konnektivität zum Scheduler und den Containertabellen, die vom Verbindungsmanager von WebSphere Application Server unterstützt wird.
Der Job-Scheduler von Compute Grid kann auch Jobs für native Ausführung verwalten. Ein Job für native Ausführung ist ein Job, der den Aufruf einer nativen Anwendung beschreibt. Eine native Anwendung ist eine Anwendung, die über einen nicht interaktiven Hintergrundbefehl ausgeführt werden kann. Dazu gehören Java-Hauptprogramme, kompilierte Anwendungen, die in Sprachen wie COBOL oder C++ geschrieben sind, und praktisch jede Art von Script.
In der folgenden Abbildung sind die zusätzlichen Elemente der Umgebung für Jobs für native Ausführung dargestellt:
Ein Endpunkt für native Ausführung ist ein Knoten in der WebSphere-Zelle, auf dem Jobs für native Ausführung ausgeführt werden können. Für Jobs für native Ausführung können Knoten mit und ohne WebSphere Application Server verwendet werden. Auf Knoten mit WebSphere Application Server verwendet der Job-Scheduler den Node Agent für die Steuerung der Jobs für native Ausführung. Auf Knoten ohne WebSphere Application Server steuert der Middleware-Agent die Jobs für native Ausführung.
Ein Knoten mit WebSphere Application Server kann als Ausführungsendpunkt für Jobs für native Ausführung verwendet werden. Der Job-Scheduler sendet einen Job für native Ausführung an den Node Agent. Der Node Agent erstellt daraufhin einen nativen Betriebssystemprozess, in dem die angegebene native Anwendung aufgerufen wird.
Die native Anwendung wird in einem eigenen Prozess ausgeführt, und die in der Jobbeschreibung (xJCL) angegebenen Eingabeparameter werden an die Anwendung übergeben. Der Prozess wird über Umgebungsvariablen, die in der xJCL angegeben sind, konfiguriert.
Jobs für native Ausführung können auch auf Knoten ohne WebSphere Application Server ausgeführt werden. Ein Knoten ohne WebSphere Application Server wird auch als Middleware-Knoten bezeichnet. Ein Middleware-Knoten erfordert einen kompakten Steuerungsagenten, einen so genannten Middleware-Agenten, um Jobs für native Ausführung auszuführen. Der Middleware-Agent ist ein Steuerpunkt für den Job-Scheduler. Über den Middleware-Agenten sendet der Job-Scheduler einen Job für native Ausführung an den Middleware-Knoten. Der Middleware-Agent führt wie der Node Agent jede Anwendung für native Ausführung in einem eigenen Prozess aus.