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


Compute-Grid-Umgebung planen

In diesem Artikel werden verschiedene Compute-Grid-Umgebungen, Faktoren, die bei den zu treffenden Entscheidungen für diese Umgebungen berücksichtigt werden müssen, und Aspekte beschrieben, die Ihnen helfen, Ihre Umgebungen optimal für Ihre Anforderungen zu entwerfen.

Bevor Sie Ihre Compute-Grid-Umgebung erstellen, müssen Sie sich sorgfältig darüber Gedanken machen, was Sie erstellen möchten, um die richtigen Entscheidungen treffen zu können. Sie können beispielsweise eine Compute-Grid-Umgebung in einer vorhandenen WebSphere-Zelle oder eine neue WebSphere-Zelle für Ihre Compute-Grid-Umgebung erstellen. Außerdem kann die Compute-Grid-Umgebung so erstellt werden, dass WebSphere-Stapeljobs und/oder Jobs für native Ausführung ausgeführt werden können. Außerdem müssen Sie entscheiden, welche relationale Datenbank verwendet werden soll, welche Sicherheit Sie benötigen und welche Verfügbarkeitsanforderungen Sie haben. Wenn Sie Ihre Compute-Grid-Workload über einen externen Workload-Scheduler wie Tivoli Workload Scheduler (TWS) steuern möchten, müssen Sie Ihre JMS- und WSGridNotification-SPI-Konfiguration planen. In den folgenden Abschnitten wird jeder dieser Aspekte beschrieben.

Neue oder vorhandene Zelle

Es gibt keinen wesentlichen Grund für die Erstellung einer neuen Zelle oder die Verwendung einer vorhandenen Zelle. Ihre Entscheidung richtet sich danach, ob Sie eine neue Umgebung verwenden möchten, die von der vorhandenen WebSphere-Umgebung isoliert ist, oder ob Sie die Compute-Grid-Funktionalität einer bereits vorhandenen WebSphere-Umgebung hinzufügen möchten. Wenn Sie sich dafür entscheiden, Compute Grid einer vorhandenen WebSphere-Zelle hinzuzufügen, müssen Sie beachten, dass WebSphere Extended Deployment Compute Grid Version 6.1 WebSphere Application Server Version 6.1 erfordert. Deshalb kann es erforderlich sein, eine vorhandene Zelle auf Version 6.1 zu migrieren, bevor Compute Grid hinzugefügt wird. Die Voraussetzungen für jede Komponente sind auf der Webseite WebSphere Extended Deployment detailed system requirements beschrieben.

Sie müssen Compute Grid nur auf den WebSphere-Knoten installieren, auf denen Sie die Funktionen des Job-Schedulers oder Stapelcontainers aktivieren möchten. Nur diese Knoten müssen den Stand der WebSphere Version 6.1 haben.

Sie müssen die folgenden Schritte ausführen, um Compute Grid einer vorhandenen Zelle hinzuzufügen:
  1. Stellen Sie sicher, dass die WebSphere-Knoten, auf denen Compute Grid ausgeführt werden soll, auf WebSphere Version 6.1 (inklusive des erforderlichen Fix-Pack-Stands) aktualisiert wurde.
  2. Installieren Sie WebSphere Extended Deployment Compute Grid auf den Zielknoten.
  3. Erweitern Sie die WebSphere-Zielprofile mit WebSphere Extended Deployment Compute Grid.

Die Schritte für das Erstellen einer Compute-Grid-Umgebung in einer neuen WebSphere-Zelle sind nahezu identisch. Der einzige Unterschied ist der, dass die WebSphere-Knoten, aus denen sich die WebSphere-Zelle zusammensetzt, zuerst erstellt werden muss. Dazu installieren Sie WebSphere und erstellen die erforderlichen Profile, um die WebSphere-Zelle zu erstellen.

Jobtypen

Es gibt drei Jobtypen. Zwei Typen befinden sich in der WebSphere-Serverumgebung und einer außerhalb der WebSphere-Serverumgebung.
  1. Transaktionsorientierte Stapel

    Führt transaktionsorientierte Stapelanwendungen aus, die in Java geschrieben sind und ein WebSphere-Programmiermodell implementieren. Diese Anwendungen werden als EAR-Dateien (Enterprise Archive) gepackt und in dem Stapelcontainer in einem WebSphere Application Server oder Cluster implementiert.

    Das Programmiermodell für transaktionsorientierte Stapel enthält einen containergesteuerten Prüfpunkt-/Wiederanlaufmechanismus, der den Wiederanlauf von Compute-Grid-Jobs ab dem letzten Prüfpunkt ermöglicht, falls sie durch einen geplanten oder ungeplanten Ausfall unterbrochen wurden.

  2. Rechenintensiv

    Führt rechenintensive Anwendungen aus, die in Java geschrieben sind und ein WebSphere-Programmiermodell implementieren. Diese Anwendungen werden als EAR-Dateien (Enterprise Archive) gepackt und in dem Stapelcontainer in einem WebSphere Application Server oder Cluster implementiert.

    Das Programmiermodell für rechenintensive Anwendungen ist ein schlankes Ausführungsmodell, das auf dem allgemeinen Framework basiert.

  3. Native Ausführung

    Führt native Ausführungsanwendung aus, die in jeder Sprache und jedem Programmiermodell geschrieben sein kann, die bzw. das vom Zielknoten, auf dem diese Anwendungen implementiert werden, unterstützt wird. Die Pack- und Implementierungstechniken für solche Anwendungen befinden sich außerhalb der Steuerung der WebSphere-Verwaltung.

    Das native Ausführungsmodell ist eine Methode, bereits vorhandene, nicht interaktive Programme als Stapeljobs auszuführen und zu steuern.

Alle Compute-Grid-Umgebungen erfordern, dass Sie den Job-Scheduler in einem WebSphere-Server oder -Cluster implementieren. Eine Umgebung für transaktionsorientierte Stapeljobs oder rechenintensive Jobs erfordert, dass Sie den Stapelcontainer in mindestens einem WebSphere-Server oder -Cluster implementieren. Die transaktionsorientierten Stapelanwendungen und/oder rechenintensiven Anwendungen werden in demselben WebSphere-Server oder -Cluster installiert. Wenn Sie Jobs für native Ausführung verwenden möchten, installieren Sie sie auf den Knoten in Ihrer Zielzelle über den Node Agent auf jedem Knoten. Wenn Sie jedoch weitere Knoten bereitstellen möchten, auf denen Jobs für native Ausführung ausgeführt werden sollen, und WebSphere auf diesen Knoten nicht erforderlich ist, müssen Sie den Middleware-Agenten auf diesen Zielknoten installieren und konfigurieren.

Relationale Datenbank

Der Job-Scheduler und der Stapelcontainer von Compute Grid erfordern beide Zugriff auf eine relationale Datenbank. Die verwendete relationale Datenbank wird über JDBC verbunden. Compute Grid stützt sich bei dem Zugriff auf die zugrunde liegenden Verbindungsverwaltungsfunktionen von WebSphere Application Server. Die unterstützten relationalen Datenbanken sind dieselben, die auch von WebSphere Application Server unterstützt werden, z. B. DB2, Oracle usw.

Compute Grid konfiguriert standardmäßig automatisch eine einfache dateibasierte Derby-Datenbank, damit Sie schnell eine funktionierende Compute-Grid-Umgebung haben. Die Derby-Datenbank wird jedoch für die produktive Nutzung nicht empfohlen. Außerdem unterstützt die Derby-Standarddatenbank weder einen Job-Scheduler noch einen Stapelcontainer für Cluster.

Eine hoch verfügbare Compute-Grid-Umgebung enthält einen Job-Scheduler sowie einen oder mehrere Stapelcontainer für Cluster. Für das Clustering ist eine Netzdatenbank erforderlich. Für diesen Zweck werden in Produktionsumgebungen einsatzfähige Datenbanken wie DB2 usw. empfohlen. Network Derby und Cloudscape funktionieren auch, weisen aber nicht die erforderliche Leistungsfähigkeit für Produktionszwecke auf und werden deshalb nicht empfohlen.

Einschränkung: Alle Stapelcontainer in derselben Zelle müssen denselben Typ relationaler Datenbank verwenden.

Sicherheitsaspekte

Die Compute-Grid-Sicherheit basiert auf zwei Techniken:
  1. WebSphere-Authentifizierung für den Zugriff auf Job-Scheduler-Schnittstellen. Benutzer, die in der aktiven WebSphere-Sicherheits-Registry definiert sind, können sich authentifizieren und auf die Web-, Befehlszeilen- und Programmschnittstellen des Job-Schedulers zugreifen.
  2. Rollenbasierte Sicherheit für Jobberechtigungen. Authentifizierte Benutzer müssen den richtigen Rollen zugeordnet sein, um Aktionen für Jobs ausführen zu können. Es gibt zwei Rollen:
    • lrsubmitter - Benutzer in der Rolle "lrsubmitter" können eigene Jobs übergeben und bearbeiten, aber nicht die Jobs anderer Benutzer.
    • lradmin - Benutzer in der Rolle "lradmin" können eine Jobs und die Jobs jedes anderen Benutzers übergeben und bearbeiten.

Compute-Grid-Rollen werden über die Konfigurationsseite des Job-Schedulers in der WebSphere-Administrationskonsole zugeordnet werden.

Aspekte der hohen Verfügbarkeit

Verwenden Sie Clustering für die hohe Verfügbarkeit von Compute-Grid-Komponenten. Der Job-Scheduler und der Stapelcontainer müssen zur Unterstützung der hohen Verfügbarkeit in Clustern implementiert und betrieben werden.

Um die hohe Verfügbarkeit des Job-Schedulers sicherzustellen, müssen typische Anwendungsclustertechniken verwendet werden. Der Job-Scheduler unterstützt mehrere Methoden für den Zugriff auf seine Anwendungsprogrammierschnittstellen: Webanwendung, Befehlszeile, Web-Service und Enterprise JavaBean (EJB). Die Gewährleistung eines hoch verfügbaren Netzzugriffs auf einen Job-Scheduler für einen Cluster richtet sich nach der API-Zugriffsmethode des Job-Schedulers. Zu den Optionen gehören die Verwendung des WebSphere-Plug-ins oder des On Demand Router (ODR) aus dem Feature "WebSphere Extended Deployment Operations Optimization". Der Stapelcontainer wird hoch verfügbar gemacht, indem er einfach in einem Cluster implementiert wird. Der Job-Scheduler erkennt automatisch, dass der Stapelcontainer in einem Cluster implementiert ist, und nutzt ihn, um eine hoch verfügbare Ausführungsumgebung für die dort ausgeführten Stapeljobs zu gewährleisten.

Hinweise zu externen Schedulern

Compute-Grid-Jobs können optional über einen externen Workload-Scheduler wie Tivoli Workload Scheduler (TWS) gesteuert werden. Bereiten Sie diese Integration vor, indem Sie die folgenden erforderlichen Schritte in der Compute-Grid-Umgebung ausführen:
  1. Konfigurieren Sie den WebSphere-Service-Integration-Bus und die erforderlichen JMS-Artefakte.
  2. Installieren Sie die Anwendung "JobSchedulerMDI" in demselben Server oder Cluster, in dem sich auch der Job-Scheduler befindet.
  3. Konfigurieren Sie die Bus- und JMS-Sicherheit, wenn die Sicherheit in Ihrer Umgebung aktiviert ist.
  4. Implementieren und installieren Sie optional die Serviceprogrammierschnittstelle "WSGridNotification".
  5. Verwenden Sie das Dienstprogramm "WSGrid" als ausführbare Datei, die vom externen Workload-Scheduler gestartet wird.



Zugehörige Informationen
Schnittstelle für externe Scheduler konfigurieren
Das Produkt installieren
Job-Scheduler sichern
Compute-Grid-Anwendungen, Jobs und Jobdefinitionen
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/ccgplan.html