Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer the batch environment > Administer the batch environment > Job scheduler and grid endpoint considerations


Batch environment planning for transactional batch applications and compute-intensive applications

When planning your batch environment, consider certain factors that can help you design the environment to best suit your needs.

New feature: Before you build the environment, carefully consider the goals to accomplish. For example, you can configure your batch environment in an existing cell or build a new cell. Also, decide what relational database to use, the security you need, and what your availability requirements are. The following sections contain information about each of these considerations.


New or existing cell New feature:

We can choose to configure your batch environment in an existing WAS cell or you can build a new cell entirely. Your choice depends on whether you want a new environment isolated from any existing WAS environment, or whether to add the capabilities of batch to an existing environment.

On the application server nodes where you want the job scheduler and batch container functions, use the admin console to activate the functions. No action is necessary on the dmgr node.


Job types

There are two job types. They are hosted in the WAS environment.

  1. Transactional batch

    Runs transactional batch applications that are written in Java and implement a WAS 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 batch 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 WAS 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

For all batch environments, deploy the job scheduler on a WAS server or cluster. To set up an environment to host transactional batch or compute-intensive job types, deploy the batch container to at least one WAS server or cluster. The transactional batch, compute-intensive applications, or both are installed on the same WAS server or cluster.


Relational database

The job scheduler and batch container both require access to a relational database. The relational database used is JDBC connected. Access to the relational database is through the underlying WAS connection management facilities. The relational databases supported are the same as those relational databases supported by WAS, including DB2, Oracle, and others.

The simple file-based Apache Derby database is automatically configured for you by default so that you can quickly get a functioning environment up and running. However, do not use the Derby database 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. Use production grade databases such as DB2for this purpose. Network Derby works also, but lacks the robustness necessary for production purposes. Do not use the network version in production. Application JPA settings always override the settings on this page.


Security considerations

Security for the batch environment is based on the following 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. New feature: 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 job or the jobs of anyone else.

    These roles are assigned through the job scheduler configuration page in the admin console.


High availability considerations

Use clustering for high availability of batch components. Deploy and operate on clusters using the job scheduler and batch container.

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 EJB. Ensuring that highly available network access to a clustered job scheduler depends on which job scheduler API access method. 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.
Secure the job scheduler using roles
Batch applications, jobs, and job definitions

+

Search Tips   |   Advanced Search