The Batch Architecture for the Oracle Utilities Application Framework is both flexible and powerful. To simplify the configuration and prevent common mistakes the Oracle Utilities Application Framework includes a capability called Batch Edit. This is a command line utility, named bedit.sh, that provides a wizard style capability to build and maintain your configuration. By default the capability is disabled and can be enabled by setting the Enable Batch Edit Functionality to true in the Advanced Configuration settings using the configureEnv.sh script:
$ configureEnv.sh -a ************************************************* * Environment Configuration demo * ************************************************* 50. Advanced Environment Miscellaneous Configuration ... Enable Batch Edit Functionality: true ...
Once enabled the capability can be used to build and maintain your batch architecture.
The Batch Edit capability is an interactive utility to build the environment. The capability is easy to use with the following recommendations:
Here is an example of an edit session:
$ bedit.sh -w
Editing file /u01/ugtbk/splapp/standalone/config/threadpoolworker.properties using template /u01/ugtbk/etc/threadpoolworker.be
Includes the following push destinations:
Batch Configuration Editor 220.127.116.11.0_1 [threadpoolworker.properties]
Pushing file threadpoolworker.properties to /u01/ugtbk/etc/conf/tpw ...
The first step in the process is to design your batch cluster. This is the group of servers that will execute batch processes. The Oracle Utilities Application Framework uses a Restricted Use License of Oracle Coherence to cluster batch processes and resources. The use of Oracle Coherence allows you to implement different architectures from simple to complex. Using Batch Edit there are three cluster types supported (you must choose one type per environment).
|Cluster Type (template code)||Use Cases||Comments|
|Single Server (ss)||Cluster is restricted to a single host||This is useful for non-production environments such as demonstration, development and testing as it is most simple to implement|
|Uni-Cast (wka)||The cluster uses unicast protocol with the hosts explicitly named within the cluster that are part of the cluster.||This is recommended for sites wanting to lock down a cluster to specific hosts and does not want to use multi-cast protocols. Administrators will have to name the list of hosts, known as Well Known Addresses, that are part of the cluster as part of this configuration|
|Multi-Cast (mc)||The cluster uses the multi-cast protocol with a valid multi-cast IP address and port.||This is recommended for sites who want a dynamic configuration where threadpools and submitters are accepted on demand. This is the lowest amount of configuration for product clusters as the threadpools can join a cluster from any server with the right configuration dynamically. It is not recommended for sites that do not use the multi-cast protocol.|
This is the simplest configuration with the cluster restricted to a single host. The cluster configuration is restricted networking wise within the configuration. To use this cluster type simply use the following command and follow the configuration generated for you from the template.
bedit.sh -c -t ss
This is a multi-host cluster where the hosts in the configuration are defined explicitly in host and port number combinations. The port number is used for communication to that host in the cluster. This style is useful where the site does not want to use the multi-cast protocol or wants to micro-manage their configuration. To use this cluster type simply use the following command and follow the configuration generated for you from the template.
bedit.sh -c -t wka
You then add each host as a socket using the command:
This will add a new socket collection in the format socket.<socketnumber>. To set the values use the command:
set socket.<socketnumber> <parameter> <value>
|The host number to edit|
|Either wkaaddress (host or IP address of server) and wkaport (port number on that host to use)|
|the value for the parameter.|
set socket.1 wkaaddress host1
To use this cluster style ensure the following:
This is the most common multi-host configuration. The idea with this cluster type is that a multi-cast port and IP Address are broadcast across your network per cluster. It requires very little configuration and the threadpools can dynamically connect to that cluster with little configuration. It uses the multi-cast protocol which network administrators either love or hate. The configuration is similar to the Single Server but the cluster settings are actually managed in the installation configuration (ENVIRON.INI) using the COHERENCE_CLUSTER_ADDRESS and COHERENCE_CLUSTER_PORT settings. Refer to the Server Administrator Guide for additional configuration advice.
When setting up the cluster there are a few guidelines to follow:
The cluster configuration generates a tangosol-coherence-override.xml configuration file used by Oracle Coherence to manage the cluster.
Now we have the cluster configured, the next step is to design your threadpools to be housed in the cluster. That will be discussed in Part 2 (coming soon).