Configuring High Availability for Oracle Enterprise Scheduling Service

In order to enable a highly available environment, it is recommended to run Oracle Enterprise Scheduling Service in a cluster of at least two nodes.

Configuring High Availability for Oracle Enterprise Scheduling Service

High Availability for Oracle Enterprise Scheduling Service A-7 This section includes the following topics:

■ Oracle Enterprise Scheduling Service Configuration and Deployment Artifacts

■ Oracle Enterprise Scheduling Service Logging

■ Oracle Enterprise Scheduling Service Cluster Architecture

■ Failover Requirements

■ Scalability

■ Backup and Recovery

■ Load Balancing

6.10.1 Oracle Enterprise Scheduling Service Configuration and Deployment Artifacts

Configuration files are as follows:

■ ess.xml: This file is part of the Oracle Enterprise Scheduling Service EAR file deployed to the Oracle Enterprise Scheduling Service cluster.

■ MDS repository: The Oracle Metadata repository stores Oracle Enterprise Scheduling Service job metadata. Oracle Enterprise Scheduling Service supports both database and file-based MDS repositories.

Deployment artifacts are as follows:

■ J2EE application for core run-time and hosting applications.

■ Job metadata within Oracle MDS for core runtime and jobs loaded at startup.

The Oracle WebLogic Server deployment is non-staged.

6.10.2 Oracle Enterprise Scheduling Service Logging

Use standard Oracle WebLogic Server logging for an Oracle Enterprise Scheduling Service cluster. Use logs in Oracle WebCenter Content to examine Oracle Enterprise Scheduling Service behavior. Oracle Enterprise Scheduling Service logging is configured by default in Oracle WebLogic Server.

The default location for log files for Oracle Enterprise Scheduling Service process jobs on UNIX servers is /tmp/ess/requestFileDirectory. Oracle Enterprise

Scheduling Service operational log files can be found under <DOMAIN_

HOME>/servers/<SERVER_HOME>/logs/<server name>-diagnostic.log, and <MW_HOME>\user_projects\domains\<DOMAIN_

HOME>\servers\<SERVER_HOME>\logs\<server name>-diagnostic.log on Windows.

6.10.3 Oracle Enterprise Scheduling Service Cluster Architecture

Figure 6–5 is an architectural diagram of a two node Oracle Enterprise Scheduling Service cluster.

Configuring High Availability for Oracle Enterprise Scheduling Service

Figure 6–5 Oracle Enterprise Scheduling Service Two Node Cluster

This configuration includes the following components:

■ Hardware load balancer.

■ A cluster of Oracle WebLogic Servers running on two servers.

■ Two Oracle Fusion Middleware homes running on two servers.

■ A two node cluster of Oracle Enterprise Scheduling Service instances, each running on a different instance of Oracle Fusion Middleware.

■ A cluster of Oracle RAC databases with multi-DS configuration is required for availability of run-time and MDS schemas. Multi-DS and Oracle RAC provide for database failure.

■ Shared persistence storage

■ A Metadata Store

■ An HTTP load balancer is required for web service interactions.

For more information regarding high availability architectures, see "Configuring High Availability for Oracle Fusion Middleware SOA Suite" in the Oracle Fusion Middleware High Availability Guide.

6.10.4 Failover Requirements

An HTTP load balancer provides load balancing so as to re-route requests in the event of node failure. There are no time out requirements for the load balancer or firewalls, as long as components use persistent connections. Likewise, session state replication and failover are not required.

Load balancing is used for actions such as submitting a job and querying its status using the Oracle Enterprise Scheduling Service web service interface. This load balancing occurs independently of where the job is scheduled to execute.

Configuring High Availability for Oracle Enterprise Scheduling Service

High Availability for Oracle Enterprise Scheduling Service A-9 As Oracle Enterprise Scheduling Service does not use JMS, no JMS failover is needed.

Oracle Enterprise Scheduling Service uses stateless session beans and JCA RAR files rather than stateful session beans. Therefore, no EJB state failover is required.

This section contains the following topics:

■ Request Processor Failover

■ External Component Failover

6.10.4.1 Request Processor Failover

Oracle Enterprise Scheduling Service includes a request processor component, which represents a single Managed Server in the Oracle Enterprise Scheduling Service cluster. Request processors process job requests, such that job execution is connected to one or more request processors.

If all jobs are targeted at a number of request processors, jobs are not dependent on a particular request processor. If a job is targeted at a particular request processor, any jobs tied to that request processor execute only when the Managed Server is available and an active workshift exists for the job.

6.10.4.2 External Component Failover

Oracle Enterprise Scheduling Service interacts with Oracle Fusion Middleware and other components such as Oracle SOA Suite, Oracle ADF Business Components, and so on. If one of these external components fail, it is possible that any running jobs may fail.

You can prevent external component failure from affecting jobs using proper configuration. Table 6–9 lists the external components that may fail, along with the steps to take to prevent failed Oracle Enterprise Scheduling Service jobs.

6.10.5 Scalability

Horizontal scalability—adding Managed Servers on different machines—tends to enable better performance than vertical scalability—(adding Managed Servers on the same machine.

Use standard Oracle WebLogic Server cluster scaling methodologies for horizontal scaling. For more information about Oracle WebLogic Server clustering, see the "High Availability for WebLogic Server" chapter in the Oracle Fusion Middleware High

Availability Guide. You can increase the concurrent processing of jobs within a work assignment by increasing the thread allocation of the request processor (by editing the workshift for the request processor) or by binding the work assignment to more than one request processor. For more information, see Section 5.3.2.1 and Section 5.3.1.1.

6.10.6 Backup and Recovery

Following are the backup and recovery guidelines for various components:

Table 6–9 Oracle Enterprise Scheduling Service External Component Failover

External Component Steps to Prevent Failure

Oracle WebCenter Portal Integrate with a cluster of Oracle WebCenter Portal service through a load balancer.

RAC Database Use multi-DS for Oracle RAC database integration.

Oracle SOA Suite, Oracle ADF, and so on

Configure retries for jobs that depend on these components.

Managing an Oracle Enterprise Scheduling Service Cluster

■ Components stored on the file system: Product binaries, deployed application EAR files and standard Oracle WebLogic Server files in the domain root.

■ Changes to the file system: The file system artifacts change when new EAR files are deployed or when the product is patched.

■ Data stored in the database: The database stores all metadata and run-time data.

■ Changes to database artifacts: Metadata changes when metadata is created and deployed from Oracle JDeveloper or Fusion Middleware Control. Run time data changes when jobs are submitted, undergo state changes, and so on.

There is no consistency requirement between the artifacts stored on the file system and those in database. The file system stores EAR files and temporarily stores scheduled job output and log files.

6.10.7 Load Balancing

Per Oracle best practice, use any hardware load balancer to load balance two or more Oracle HTTP servers, which, in turn, load balance the Oracle WebLogic Server Managed Servers in the cluster.