WebSphere Extended Deployment Compute Grid, Version 6.1.1
             Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows,


Informationen zum Verständnis der Compute-Grid-Umgebung

In diesem Artikel werden die Komponenten beschrieben, aus denen sich eine typische Compute-Grid-Umgebung zusammensetzt.

Elemente in der Compute-Grid-Umgebung

Die Compute-Grid-Basisumgebung setzt sich aus Elementen zusammen, die im folgenden Diagramm angezeigt werden:
Abbildung 1. Compute-Grid-Elemente
Die Compute-Grid-Elemente werden in der folgenden Liste detailliert beschrieben. Dazu gehören: Job-Scheduler, Stapelcontainer, J2EE-Stapelanwendung, xJCL, APIs für den Zugriff auf Verwaltungsfunktionen, Scheduler-Tabellen und Containertabellen.
In der folgenden Liste werden die nummerierten Elemente aus der vorherigen Abbildung beschrieben:
  1. Job-Scheduler

    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.

  2. Stapelcontainer

    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.

  3. J2EE-Stapelanwendung

    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.

  4. xJCL

    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.

  5. Web, Shell, API

    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.

  6. Scheduler-Tabellen

    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.

  7. Containertabellen

    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.

  8. JDBC

    Dies ist die JDBC-Konnektivität zum Scheduler und den Containertabellen, die vom Verbindungsmanager von WebSphere Application Server unterstützt wird.

Basisumgebung für Jobs für native Ausführung

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:

Abbildung 2. Basisumgebung für Jobs für native Ausführung
In der folgenden Liste werden die einzelnen Bestandteile der Umgebung beschrieben. An jedem Endpunkt für native Ausführung werden ein Middleware- oder ein Knotenagent und die native Anwendung ausgeführt. Diese Endpunkte kommunizieren über den Agentenprozess mit dem Job-Scheduler. Der Job-Scheduler wird auf einem Anwendungsserver ausgeführt. Eingaben in den Job-Scheduler beinhalten xJCL und Scheduler-Tabellen, die JDBC verwenden.
  1. Endpunkt für native Ausführung

    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.

  2. Node Agent

    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.

  3. Native Anwendung

    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.

  4. Middleware-Agent

    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.




Zugehörige Konzepte
xJCL-Elemente
Middleware-Agent
Zugehörige Tasks
Anwendungen für Compute Grid entwickeln
Job-Scheduler konfigurieren
Zugehörige Informationen
Compute-Grid-Umgebung planen
Grid-Endpunkte konfigurieren
Konzeptartikel    

Nutzungsbedingungen | Feedback

Letzte Aktualisierung: 24.09.2009 16.45 Uhr EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/prodovr/ccgunder.html