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.
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.
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.
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.
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.
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.
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.
Compute-Grid-Rollen werden über die Konfigurationsseite des Job-Schedulers in der WebSphere-Administrationskonsole zugeordnet werden.
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.