WebSphere Extended Deployment Compute Grid, Version 6.1
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Planning your Compute Grid environment

This topic describes different Compute Grid environments, factors to consider when making decisions for those environments, and considerations that will help you design your environment to best suit your needs.

Before you build your Compute Grid environment, you must carefully consider what it is you want to build in order to make the best decisions. For example, you can build a Compute Grid in an existing WebSphere cell or build a new WebSphere cell to host your Compute Grid environment. Additionally, your Compute Grid environment can be built to run WebSphere 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 Compute Grid 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

There is no fundamental reason to build a new cell, or to use an existing one. Your choice depends on whether you want a new environment isolated from any existing WebSphere environment, or whether you want to add the Compute Grid capabilities to an existing WebSphere environment you already have. If you choose to add Compute Grid to an existing WebSphere cell, realize that WebSphere Extended Deployment Compute Grid V6.1 requires WebSphere Application Server V6.1 Therefore, it might be necessary to migrate an existing cell to V6.1 before adding Compute Grid. See the WebSphere Extended Deployment detailed system requirements for the prerequisites for each component.

You only need to install Compute Grid on those WebSphere nodes where you want to activate the job scheduler or batch container functionality. Only those nodes must be at the WebSphere V6.1 level.

The following steps are required to add Compute Grid to an existing cell:
  1. Ensure that the WebSphere nodes that will have Compute Grid function are upgraded to WebSphere V6.1, including the necessary fix pack level.
  2. Install WebSphere Extended Deployment Compute Grid on the target nodes.
  3. Augment target WebSphere profiles with WebSphere Extended Deployment Compute Grid.

The steps for building a Compute Grid environment in a new WebSphere cell are nearly the same. The only difference is that the WebSphere nodes that comprise the WebSphere cell must first be built. Do this by installing WebSphere and creating the necessary profiles to create the WebSphere cell.

Job types

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

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

    The transactional batch programming model provides a container-managed checkpoint/restart mechanism that enablesCompute Grid job 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 programming model. They are packaged as Enterprise Archive (EAR) files and are deployed to the batch container hosted in a WebSphere 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 administrative control.

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

All Compute Grid environments require you to deploy the job scheduler on a WebSphere server or cluster. An environment to host transactional batch or compute-intensive job types requires that you deploy the batch container to at least one WebSphere server or cluster. The transactional batch and/or compute-intensive applications are installed on the same WebSphere server or cluster. If you want to host native execution job types, do it on the WebSphere nodes in your target cell through the nodeagent on each node. However, if you want to provide additional nodes on which to run native execution jobs, and do not require WebSphere on those nodes, you must install and configure the middleware agent on those target nodes.

Relational database

The Compute Grid 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 auto-configures a simple file-based Derby database by default to help you quickly get a functioning Compute Grid 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 Compute Grid environment includes both a clustered job scheduler, as well as 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 job scheduler's Web, command line, and programmatic interfaces.
  2. Role-based security for permission rights to job. Authenticated users must be assigned to the appropriate roles in order to perform actions against jobs. There are two roles:
    • 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 their own or anyone else's jobs.

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

High availability considerations

Use clustering for high availability of Compute Grid components. Both the job scheduler and the batch container should be deployed to, and operated on, clusters to provide high availability.

Typical application clustering techniques should be used with the job scheduler to ensure it is highly available. The job scheduler supports multiple methods of access to its APIs: Web application, command line, Web service, and Enterprise JavaBean (EJB). Ensuring 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 from the WebSphere Extended Deployment Operations Optimization feature. The batch container is made highly available simply 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 launched by the external workload scheduler.



Related information
Setting up the external scheduler interface
Installing the product
Securing the job scheduler
Compute Grid applications, jobs, and job definitions
Concept topic    

Terms of Use | Feedback

Last updated: Oct 30, 2009 6:22:31 PM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/scheduler/ccgplan.html