Oracle® Retail Job Orchestration and Scheduler Implementation Guide Release 16.0.21 E88078-01 |
|
Previous |
Next |
This chapter provides information about high availability considerations.
Modern business application requirements are classified by the abilities that the system must provide. This list of abilities, such as availability, scalability, reliability, scalability, audit ability, recoverability, portability, manageability, and maintainability, determine the success or failure of a business.
With a clustered system many of these business requirement abilities are addressed without having to do much development work within the business application. Clustering directly addresses availability, scalability, and recoverability requirements, which are very attractive to a business. In reality though it is a trade off, as clustered systems increase complexity and are normally more difficult to manage and secure, and so one should evaluate the pros and cons before deciding to use clustering.
Oracle provides many clustering solutions and options; those relevant to JOS are Oracle database cluster (RAC) and WebLogic Server clusters.
A WebLogic Server cluster consists of multiple WebLogic Server managed server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
In an active-passive configuration, the passive components are only used when the active component fails. Active-passive solutions deploy an active instance that handles requests and a passive instance that is on standby. In addition, a heartbeat mechanism is usually set up between these two instances together with a hardware cluster (such as Sun Cluster, Veritas, RedHat Cluster Manager, and Oracle CRS) agent so that when the active instance fails, the agent shuts down the active instance completely, brings up the passive instance, and resumes application services.
In an active-active model all equivalent members are active and none are on standby. All instances handle requests concurrently.
An active-active system generally provides higher transparency to consumers and has a greater scalability than an active-passive system. On the other hand, the operational and licensing costs of an active-passive model are lower than that of an active-active deployment.
See the Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server documentation for more information: http://download.oracle.com/docs/cd/E15523_01/web.1111/e13709/toc.htm
JOS needs to be scaled horizontally to handle a large number of concurrent jobs. Single instances of Scheduler and Process Flow can be used since they are not resource intensive. JOS Admin can be very resource intensive. To handle large number of concurrent jobs, multiple instances of JOS Admin can be used to distribute jobs. WebLogic Server cluster that consists of multiple managed server instances provide horizontal scalability for JOS Admin.
As recommended above, for scaling JOS for large number of jobs, JOS components should be deployed to cluster. Following are some considerations to be taken into account when deploying JOS on a cluster.
Issue
The System Logs tab in Scheduler, Process Flow, and JOS Admin UIs show only logs from the server that UI is connected to.
Solution
Use a common log directory for each of the JOS components. JOS components use the following directory structure for creating log files.
$DOMAIN_HOME/logs/<server name>/<app name>
Example
$DOMAIN_HOME/logs/server1/com.oracle.retail.integration_jos-rms-job-admin_war_16.0.21 $DOMAIN_HOME/logs/server2/com.oracle.retail.integration_jos-rms-job-admin_war_16.0.21
Create a common log directory (for example; /home/logs/jobadmin) for each JOS application.
Create symbolic links to the common log directory for each server using the below command from $DOMAIN_HOME/logs directory.
ln -s /home/logs/jobadmin server1/com.oracle.retail.integration_jos-rms-job-admin_war_16.0.21ln -s /home/logs/jobadmin server2/com.oracle.retail.integration_jos-rms-job-admin_war_16.0.21
If the directory $DOMAIN_HOME/logs/<server>/<app> already exists, it must be deleted before symbolic link is created.
The application must be restarted after symbolic link is created. When WebLogic managed servers are in different machines a shared network disk has to be used.
Issue
When the log level is updated through UI or REST end point, it updates the log level only on the server it is connected to.
Solution
Log level must be updated through the URL of all the nodes in the cluster using UI or REST endpoint.
Example
http://server1:port1/jos-rms-batch-job-admin/system-setting/system-logs http://server2:port2/jos-rms-batch-job-admin/system-setting/system-logs
Issue
When system options are created/updated/deleted using UI or REST end point, the changes are reflected only on the server that client is connected to.
Solution
The reset-cache REST endpoint must be invoked on the other nodes in the cluster for that application in JOS.
Example
http://server1:port1/jos-rms-batch-job-admin/system-setting/reset-cache
Issue
When system credentials are created/updated/deleted using REST endpoint, the credentials are created/updated/deleted only on the server that client is connected to.
Solution
The REST endpoint that creates/updates/deletes credentials must be invoked on all the nodes in the cluster for that application in JOS.
Example
http://server1:port1/jos-rms-batch-job-admin/system-setting/system-credentials http://server2:port2/jos-rms-batch-job-admin/system-setting/system-credentials
Cluster Job Scheduler Data Source
Specify the data source for the schedule timers in the Admin Console
Login to the Admin Console
Click Environment > Clusters
Click on the cluster name
Click Scheduling
Click Lock & Edit (For Production Mode only)
Select BatchInfraDataSource for the Data Source For Job Scheduler field
Click Save
WebLogic EJB JAR XML
Update the weblogic-ejb-jar.xml in WEB-INF folder of the bdi-scheduler-ui-<version>.war in <jos-home>/dist folder with the contents shown (The entry in bold in the following instructions is the change from the existing contents of the file).
Instructions to update:
cd dist
jar xf bdi-scheduler-ui-<version>.war WEB-INF/weblogic-ejb-jar.xml
Update the WEB-INF/weblogic-ejb-jar.xml with the contents below
jar uf bdi-scheduler-ui-<version>.war WEB-INF/weblogic-ejb-jar.xml
Delete dist/WEB-INF folder
Deploy the scheduler application
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<security-role-assignment>
<role-name>AdminRole</role-name>
<principal-name>BdiSchedulerAdminGroup</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name>OperatorRole</role-name>
<principal-name>BdiSchedulerOperatorGroup</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name>MonitorRole</role-name>
<principal-name>BdiSchedulerMonitorGroup</principal-name>
</security-role-assignment>
<timer-implementation>Clustered</timer-implementation>
</weblogic-ejb-jar>