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


Manager für parallele Jobs (PJM)

Der Manager für parallele Jobs (Parallel Job Manager, PJM) stellt ein Tool und ein Framework für die Übergabe und Verwaltung transaktionsorientierter Stapeljobs bereit, die als koordinierte Sammlung unabhängiger paralleler Unterjobs ausgeführt werden.

PJM-Operation und Aufruf der SPIs

Die folgenden zwei Abbildungen beschreiben die PJM-Architektur und die Abfolge eines parallelen Jobs. Zuerst wird ein Job der Ausgangsebene an den Job-Scheduler übergeben, der bestimmt, dass es sich um einen parallelen Job handelt und ihn an an den PJM übergibt. Der PJM ruft die Parameterizer-SPI auf, die die Unterteilung des Jobs in untergeordnete Jobs unterstützt. Der PJM ruft dann die Synchronisierungs-SPI "LogicalTX" auf, um den Beginn der logischen Transaktion anzuzeigen. Der PJM verwendet dann die im Repository gespeicherte xJCL des Unterjobs, um die Unterjobs an den Job-Scheduler zu übergeben. Dann teilt der Job-Scheduler die Unterjobs den Endpunkten des Stapelcontainers zur Ausführung zu. Wenn der PJM feststellt, dass die Ausführung der Unterjobs begonnen hat, ruft er die Lebenszyklus-SPI auf. Im Rahmen dieses Aufrufs sind im Gegensatz zu anderen SPI-Aufrufen keine Kontextinformationen verfügbar. Dann führt der Stapelcontainer den Unterjob aus. Wenn ein Prüfpunkt abgerufen wird, wird die Collector-SPI des Unterjobs aufgerufen. Diese SPI erfasst relevante Statusinformationen zum Unterjob. Diese Daten werden zur Interpretation an die SPI der Analysefunktion des Unterjobs gesendet. Wenn alle Unterjobs einen Endstatus erreichen, werden die Synchronisierungs-SPIs beforeCompletion und afterCompletion aufgerufen. Die SPI der Analysefunktion wird ebenfalls aufgerufen, um den Rückkehrcode des Jobs zu berechnen.

PJM-Architektur und -Programmiermodell

Die folgende Abbildung ist eine Zusammenfassung der PJM-Architektur, die zeigt, wo die SPIs aufgerufen werden:


PJM-Architektur

Reihenfolge in einem parallelen Job

Die folgende Abbildung zeigt die Reihenfolge der Ereignisse in einem parallelen Job:


Reihenfolge in einem parallelen Job

PJM-Systemanwendung und parallele Jobs

Der PJM ist eine EJB-Anwendung (Enterprise JavaBeans), die parallele Unterjobs überwacht und verwaltet. Parallele Unterjobs sind J2EE-Stapelanwendungen. Der PJM ist ein aus einem Schritt bestehender J2EE-Job (Java 2 Platform, Enterprise Edition. Der PJM verarbeitet keine Stapeldatenströme, sondern dient der Übergabe und dem Neustart von Unterjobs im Rahmen der Steuerung der Abschnittseigenschaften, die den Unterjob im Job-Repository und die Anzahl der zu verarbeitenden Unterjobs festlegen.

Ein paralleler Job besteht aus einem Job auf der Ausgangsebene, der die ParallelJobManager-Anwendung ausführt, und aus einer Gruppe von Unterjobs, die die tatsächliche Geschäftslogik ausführt. Unterjobs führen zwar dieselbe Jobdefinition aus, haben jedoch potenziell unterschiedliche Eingaben. Alle Unterjobs werden zusammen als ein einziger logischer Job ausgeführt.

Separate xJCL-Definition sind sowohl für Jobs der Ausgangsebene als auch für Unterjobs erforderlich. Alle Unterjobs verwenden dieselbe xJCL-Definition, alle Unterjobinstanz können mit eigenen Ersetzungseigenschaften parametrisiert werden.

Eine logische Transaktion ist die Demarkation für eine Arbeitseinheit, die die Ausführung eines parallelen Jobs umfasst. Ihr Lebenszyklus entspricht dem kombinierten Lebenszyklus der Unterjobs des parallelen Jobs. Ein Erweiterungsmechanismus ermöglicht die Anpassung, damit anwendungsgesteuerte Ressourcen in diesem Bereich der Arbeitseinheit zwecks Festschreibung und Rollback gesteuert werden können.

Namenskonvention für Jobnamen

Der Jobname eines parallelen Jobs ist in der xJCL angegeben, die einen Job der Ausgangsebene definiert. Die xJCL des Jobs der Ausgangsebene kann aus dem Dateisystem oder aus dem Compute-Grid-Job-Repository stammen. Der Jobname kann mit der Standardnotation für die Ersetzungseigenschaft parametrisiert werden: <job name=”${jobname}” … >.

Eine Job-ID wird durch Verkettung eines Jobnamens mit einer vom System generierten Folgenummer gebildet. Ein Jobname und eine Folgenummer müssen durch einen Doppelpunkt voneinander getrennt werden. Der Jobname eines Unterjobs ist die Job-ID des parallelen Jobs. Die xJCL für einen Unterjob kann nur aus dem Compute-Grid-Job-Repository stammen. Die xJCL des Unterjobs muss die Eigenschaft für die Ersetzung des Jobnamens bereitstellen: <job name=”${jobname}” … >

Jobverwaltung durch Manager für parallele Jobs

Der Job der Ausgangsebene übergibt die Unterjobs und überwacht deren Ausführung. Der Status "Beendet" des Jobs der Ausgangsebene hängt folgendermaßen vom Ergebnis der Unterjobs ab:
  1. Wenn alle Unterjobs im Status "Beendet" abgeschlossen, d. h., erfolgreich ausgeführt werden, wird der Job der Ausgangsebene ebenfalls im Status "Beendet" abgeschlossen.
  2. Wenn ein Unterjob im Status "Wieder anlauffähig" abgeschlossen wird und kein Unterjob im Status "Fehlgeschlagen" beendet wurde, wird der Job der Ausgangsebene im Status "Wieder anlauffähig" abgeschlossen.
  3. Wenn ein Unterjob im Status "Fehlgeschlagen" abgeschlossen wird, wird auch der Job der Ausgangsebene im Status "Fehlgeschlagen" abgeschlossen.
  4. Wenn der Job der Ausgangsebene und die Unterjobs einen Status haben, der einen Neustart zulässt, sollte nur der Job der Ausgangsebene erneut gestartet werden. Wenn Unterjobs manuell gestartet werden, verarbeitet der Job der Ausgangsebene die logische Transaktion nicht ordnungsgemäß.



Zugehörige Konzepte
Compute-Grid-Jobs und ihre Umgebung verwalten
Weitere Hinweise zur Ausführung paralleler Jobs
Zugehörige Tasks
Manager für parallele Jobs (PJM) installieren und konfigurieren
Beispielanwendung für den Manager für parallele Jobs
Zugehörige Verweise
System Programming Interfaces (SPI) und Eigenschaften
Script parallelJobManager.py
Konzeptartikel    

Nutzungsbedingungen | Feedback

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