Planning your Compute Grid environment

When planning your Compute Grid environments, consider certain factors that can help you design your environment to best suit your needs.

Before you build your environment, you must carefully consider what it is you want to build to make the best decisions. For example, you can install the product in an existing cell or build a new cell. Additionally, you can build your environment to run batch jobs, native execution jobs, or both. Also, you must decide what relational database to use, the security you need, and what your availability requirements are. If you are planning to control your workload through an external workload scheduler, such as Tivoli® Workload Scheduler (TWS), you must plan for your JMS and WSGridNotification SPI configuration. The following sections discuss each of these considerations.

New or existing cell

You can install Compute Grid in an existing WebSphere® Application Server cell or you can build a new cell entirely. Your choice depends on whether you want a new environment isolated from any existing WebSphere Application Server environment, or whether you want to add the capabilities of Compute Gridto an existing environment. See the WebSphere Extended Deployment detailed system requirements for the prerequisites for each component.

Install Compute Grid on the WebSphere Application Server nodes where you want to activate the job scheduler or batch container functionality.

Job types

There are three jobs types. Two are hosted in the WebSphere Application Server environment, and one is hosted outside of the WebSphere Application Server environment.
  1. Transactional batch

    Runs transactional batch applications that are written in Java and implement a WebSphere Application Server programming model. They are packaged as Enterprise Archive (EAR) files and are deployed to the batch container hosted in an application server or cluster.

    The transactional batch programming model provides a container-managed checkpoint/restart mechanism that enables Compute Grid jobs to be restarted from the last checkpoint if interrupted by a planned or unplanned outage.

  2. Compute-intensive

    Runs compute-intensive applications that are written in Java and implement a WebSphere Application Server programming model. They are packaged as Enterprise Archive (EAR) files and are deployed to the batch container hosted in an application server or cluster.

    The compute-intensive programming model provides a lightweight execution model based on the common framework

  3. Native execution

    Runs native execution applications that can be written in any language and programming model supported by the target node on which these applications are deployed. The packaging and deployment technique for such applications are both outside of a WebSphere Application Server administrative control.

    The native execution model provides a way to run and control pre-existing, non-interactive programs as batch jobs.

For all Compute Grid environments, you must deploy the job scheduler on a WebSphere Application Server server or cluster. To set up an environment to host transactional batch or compute-intensive job types, you must deploy the batch container to at least one WebSphere Application Server server or cluster. The transactional batch applications, compute-intensive applications, or both types of applications are installed on the same WebSphere Application Server server or cluster. If you want to host native execution job types, do so on the nodes in your target cell through the node agent on each node. However, if you want to provide additional nodes on which to run native execution jobs, and do not require WebSphere Application Server on those nodes, you must install and configure the middleware agent on those target nodes.

Relational database

The job scheduler and batch container both require access to a relational database. The relational database used is JDBC connected. Compute Grid relies on the underlying WebSphere Application Server connection management facilities for access. The relational databases supported are the same as those supported by WebSphere Application Server, including DB2®, Oracle, and others.

Compute Grid automatically configures a simple file-based Derby database by default to help you quickly get a functioning environment up and running. However, the Derby database is not recommended for production use. Moreover, the default Derby database does not support a clustered job scheduler, nor a clustered batch container.

A highly available environment includes both a clustered job scheduler and one or more clustered batch containers. Clustering requires a network database. Production grade databases such as DB2 and others are recommended for this purpose. Network Derby or Cloudscape work also, but lack the robustness necessary for production purposes and are not recommended.

Limitation: All batch containers in the same cell must use the same relational database type.

Security considerations

Compute Grid security is based on two techniques:
  1. WebSphere authentication for access to job scheduler interfaces. Users defined to the active WebSphere security registry can authenticate and gain access to the Web, command line, and programmatic interfaces of the job scheduler.
  2. Role-based security for permission rights to jobs. Authenticated users must be assigned to the appropriate three roles in order to perform actions against jobs. There are three roles:
    • lrmonitor - Users in the lrmonitor role can view and download all job logs, but cannot submit or operate on jobs.
    • lrsubmitter - Users in the lrsubmitter role can submit and operate on their own jobs, but on no others.
    • lradmin - Users in the lradmin role can submit jobs and operate on any job including those that they did not submit.

Compute Grid roles are assigned through the job scheduler configuration page in the administrative console.

High availability considerations

Use clustering for high availability of Compute Grid components. The job scheduler and batch container can be used to deploy to clusters and operate on cluster to provide high availability.

Use typical application clustering techniques with the job scheduler to ensure that it is highly available. The job scheduler supports multiple methods of access to its APIs: Web application, command line, Web service, and Enterprise JavaBeans (EJB). Ensuring that highly available network access to a clustered job scheduler depends on which job scheduler API access method. These choices include using the WebSphere plug-in or the on-demand router in WebSphere Virtual Enterprise. The batch container is made highly available by deploying it to a cluster. The job scheduler automatically recognizes the batch container is clustered and takes advantage of it to ensure a highly available execution environment for the batch jobs that run there.

External scheduler considerations

Compute Grid jobs can optionally be controlled through an external workload scheduler, such as Tivoli Workload Scheduler (TWS). Prepare for this integration by following these required steps in the Compute Grid environment:
  1. Configure WebSphere Service Integration Bus and required JMS artifacts.
  2. Install JobSchedulerMDI application in the same server or cluster hosting the job scheduler.
  3. Configure bus and JMS security if security is enabled in your environment.
  4. Optionally implement and install WSGridNotification SPI.
  5. Use WSGrid utility as the executable program started by the external workload scheduler.