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.
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 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.
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.
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
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.
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.
Compute Grid roles are assigned through the job scheduler configuration page in the WebSphere administrative console.
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.