|
Oracle® Application Server High Availability Guide
10g Release 3 (10.1.3) B15977-02 |
|
 Previous |
 Next |
|
Oracle® Application Server High Availability Guide
10g Release 3 (10.1.3) B15977-02 |
|
|
Previous |
Next |
This chapter describes active-active topologies. It contains the following sections:
An active-active topology consists of redundant middle-tier instances that deliver greater scalability and availability than a single instance. Active-active topologies remove the single point of failure that a single instance poses. While a single Oracle Application Server instance leverages the resources of a single host, a cluster of middle-tier instances spans multiple hosts, distributing application execution over a greater number of CPUs. A single Oracle Application Server instance is vulnerable to the failure of its host and operating system, but an active-active topology continues to function despite the loss of an operating system or a host, hiding any such failure from clients.
In active-active topologies, all the instances are active at the same time. This is different from active-passive topologies, where only one instance is active at any time.
The nodes in the active-active topologies are not in a hardware cluster.
Load Balancer Requirements
Active-active topologies use a load balancer to direct requests to one of the Oracle Application Server instances in the topology. In other words, the Oracle Application Server instances are fronted by the load balancer.
You configure the load balancer with virtual server names for HTTP and HTTPS traffic. Clients use the virtual server names in their requests. The load balancer directs requests to an available Oracle Application Server instance.
See Section 2.5, "External Load Balancers" for a list of features that your load balancer should have.
Figures of Active-Active Topologies
The following figures show two active-active topologies. The difference in the topologies is whether you install Oracle HTTP Server and OC4J in the same Oracle home or in separate Oracle homes.
Figure 3-1 shows an active-active topology with Oracle HTTP Server and OC4J in the same Oracle home. Figure 3-2 shows an active-active topology with Oracle HTTP Server and OC4J in separate Oracle homes.
Figure 3-1 Active-Active Topology with Oracle HTTP Server and OC4J in the Same Oracle Home
Figure 3-2 Active-Active Topology with Oracle HTTP Server and OC4J in Separate Oracle Homes
All the Oracle Application Server instances in an active-active topology belong to the same cluster. Oracle HTTP Server forwards application requests only to OC4J instances that belong to the same cluster.
You can group instances in an cluster using one of the following ways:
All the instances use the same multicast IP address and port.
All the instances are chained to the same discovery server.
Each instance specifies all other instances in the opmn.xml configuration file.
If the instances run on nodes that are on different subnets, you have to designate a node to be the gateway server, which bridges the instances on the different subnets.
OracleAS Clusters also enable you to use the @cluster parameter in some opmnctl commands. Commands that use the @cluster parameter apply to all instances in the cluster. For example, you can use the @cluster parameter to start all components in all instances in the cluster.
OC4J instances in a cluster have the following features:
OC4J instances have cluster-wide properties as well as instance-specific properties. Cluster-wide properties are properties whose values should be similar for all OC4J instances in the cluster. Instance-specific properties are properties that have different values for each OC4J instance. For a list of cluster-wide properties, see the "Configuring and Managing Clusters" chapter in the Oracle Containers for J2EE Configuration and Administration Guide.
If you modify a cluster-wide property in one OC4J instance, you should propagate the change to all other OC4J instances in the cluster.
When you deploy an application to an OC4J instance, you also need to deploy it on all other OC4J instances in the cluster.
The number of OC4J processes is an instance-specific property: it can be different for each OC4J instance. This must be configured for each Oracle Application Server instance in the cluster. The OC4J process configuration provides flexibility to tune according to the specific hardware capabilities of the host. By default, each OC4J instance is instantiated with a single OC4J process.
For details, see the "Configuring and Managing Clusters" chapter in the Oracle Containers for J2EE Configuration and Administration Guide.
For stateful Web applications and stateful session EJBs running on OC4J, a client communicates with the same OC4J process over a series of HTTP requests and responses. However, if the OC4J process that is running the application terminates or hangs, or if the node fails, the state associated with a client request may be lost.
To protect against such software and hardware failures, you need to do these steps:
Run OC4J instances on multiple nodes.
Cluster the OC4J instances in the same OracleAS Cluster (OC4J).
Cluster the applications at the application-level.
In application-level clustering in an OracleAS Cluster (OC4J), OC4J processes replicate their session state among each other. This configuration provides failover and high availability by replicating state across multiple OC4J processes running on different Oracle Application Server instances. In the event of a failure, Oracle HTTP Server forwards requests to active (alive) OC4J process within the OracleAS Cluster (OC4J).
To protect against hardware failures such as node failures, cluster OC4J instances on different nodes in the same OracleAS Cluster (OC4J). OC4J processes that run on different nodes but within the same OracleAS Cluster (OC4J) can share session state information. When an OC4J instance fails or becomes unavailable, Oracle HTTP Server forwards requests to an available OC4J process. Oracle HTTP Server forwards requests only to active (alive) OC4J processes within the cluster.
Using an OracleAS Cluster (OC4J) together with mod_oc4j request routing provides stateful failover in the event of a software or hardware problem. For example, if an OC4J process that is part of an OracleAS Cluster (OC4J) fails, OPMN notifies mod_oc4j of the failure, and mod_oc4j routes requests to another OC4J process in the same cluster. The session state for the client is preserved and the client does not notice any loss of service.
Figure 3-3 shows an OracleAS Cluster (OC4J) configured across two Oracle Application Server instances, with OC4J processes running on each instance. If Oracle Application Server instance 1 fails, the OC4J process on instance 2 contains the session state information and can handle the requests. This configuration enables web application session state replication failover within an OracleAS Cluster (OC4J).
Figure 3-3 Web Application Session State Failover Within an OracleAS Cluster (OC4J)
Minimum Number of Instances and Processes Needed
To protect against software or hardware failure while maintaining state with the least number of OC4J processes, you need to configure at least two OC4J processes in the same cluster. For example, if you have two Oracle Application Server instances, instance 1 and instance 2, you can configure two OC4J processes on each instance. With this configuration, stateful session applications are protected against hardware and software failures, and the client maintains state if either of the following types of failures occurs:
If one of the OC4J processes fails, then the client request is redirected to the other OC4J process in the same Oracle Application Server instance. State is preserved and the client does not notice any irregularity.
If Oracle Application Server instance 1 terminates abnormally, then the client is redirected to an OC4J process on Oracle Application Server instance 2. The state is preserved and the client does not notice any irregularity.
|
Note: Use of EJB replication OracleAS Cluster (OC4J-EJB) for high availability is independent of OracleAS Cluster (OC4J) and can involve multiple Oracle Application Server instances installed across nodes that are or are not part of OracleAS Cluster (OC4J). |
OracleAS Cluster (OC4J-EJB)s provide high availability for stateful session EJBs. They allow for failover of these EJBs across multiple OC4J processes that communicate over the same multicast address. Thus, when stateful session EJBs use replication, this can protect against process and node failures and can provide for high availability of stateful session EJBs running on Oracle Application Server.
For more information, see chapter 24, "Configuring OC4J EJB Application Clustering Services", in the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide.
Because the load balancer can send a request to any Oracle Application Server instance in the topology, you need to ensure that the instances are configured in the same manner so that clients get the same response regardless of which instance handles the request. This includes the following:
Deploy the same applications on each OC4J instance in the topology.
Ensure that you replicate state and stateful session bean information across OC4J instances so that in the event that an OC4J instance fails, another OC4J instance contains the state information and can continue the session.
Ensure that configuration properties for all the OC4J instances in the topology are identical. These configuration properties are listed in chapter 8, "Configuring and Managing Clusters", in section "Replicating Changes Across a Cluster", in the Oracle Containers for J2EE Configuration and Administration Guide.
In an OracleAS Cluster (OC4J), OC4J instances with the same name are considered to be in a group. For example, if you have three Oracle Application Server instances, and each of these instances has an OC4J instance called "home", then these OC4J instances belong to the same group called "home". Figure 3-4 shows this example. The figure also shows an OC4J instance called "sales" on two of the Oracle Application Server instances.
Oracle Application Server creates groups automatically when it finds OC4J instances with the same name in an OracleAS Cluster (OC4J). The "home" instance is the default OC4J instance that is created during installation.
Note that a group does not need to have OC4J instances in all the Oracle Application Server instances in the cluster. For example, in Figure 3-4, the "sales" OC4J instance exists only in two of the Oracle Application Server instances. This is valid.
Oracle Application Server does not enforce that the instances in a group be configured identically. However, you should ensure that some configurations (such as data sources, JMS resources, and security provider settings) are identical so that your applications return the same response to the client regardless of which instance is processing the request.
You can create additional OC4J instances using the ORACLE_HOME/bin/createinstance command. The syntax is:
createinstance -instanceName name [-port httpPort]
name specifies the name of the OC4J instance you want to create.
The optional port parameter is useful if the Oracle Application Server instance does not contain Oracle HTTP Server. Setting the HTTP port enables you to access the home page of the new OC4J instance directly. For more information on the createinstance command, see chapter 8, "Configuring and Managing Clusters", in section "Creating and Managing Additional OC4J Instances", in the Oracle Containers for J2EE Configuration and Administration Guide.
For example, to create the "sales" OC4J instance, you can use the following command:
createinstance -instanceName sales
The command prompts you to set the oc4jadmin password for the "sales" instance. This password can be different from the oc4jadmin password for the "home" instance. When you access the "sales" instance, you will need to enter its password.
The command creates the instance but does not start it. You can start it from Application Server Control Console or from the opmnctl command.
After creating the instance, you should reload OPMN so that it is aware of the new instance:
opmnctl reload
For a group of OC4J instances, you can manage them collectively or you can still manage them individually. You can start and stop all the applications and instances in a group or individually, and you can also deploy / redeploy / undeploy applications on all the instances in a group or on only some instances.
Deploying applications only on some instances in a group is not recommended. You should deploy the same application on all instances in a group.
You can manage groups using Application Server Control Console or admin_client.jar. In Application Server Control Console, you can perform these operations on groups:
Table 3-1 Performing Operations on Groups using Application Server Control Console
| Operation | Steps |
|---|---|
|
Start, stop, deploy, undeploy, redeploy applications in a group |
|
|
Configure JDBC resources and JMS providers |
|
|
Manage OC4J instances individually |
|
|
Manage OC4J instances as a group |
|
You can use the admin_client.jar utility to deploy applications to a group. The syntax looks like the following:
> cd ORACLE_HOME/j2ee/home > java admin_client.jar deployer:cluster:opmn://<host>:<opmnPort>/<groupName> <adminID> <adminPassword> -deploy -file <pathToArchiveFile> -deploymentName <appName>
For <host>, you can specify any host in the group.
For <opmnPort>, you specify the port at which OPMN is listening. This port is listed in the opmn.xml file.
For <groupName>, you specify the name of the group. This is the name of the OC4J instance (for example, home).
For <adminID> and <adminPassword>, you specify the administrator's ID and password. Typically the adminID is oc4jadmin.
|
Note: For deployment to work across all instances in a group, the administrator's password must be the same for all instances in the group. |
For <pathToArchiveFile>, you specify the full path to the EAR, WAR, or JAR file that you want to deploy.
For <appName>, you specify the application name.
There are other options that you can specify on the command-line for deployment. For details, see the Oracle Containers for J2EE Deployment Guide.
When Oracle HTTP Server receives a request for a J2EE application, it forwards the request to the mod_oc4j module located within Oracle HTTP Server itself. Following a load balancing algorithm, mod_oc4j forwards the request to an OC4J instance in the same cluster. See Figure 3-5.
The default load balancing algorithm that mod_oc4j uses to distribute the requests is a simple round robin algorithm. You can use a different algorithm by setting a directive in the mod_oc4j.conf file. See Section 3.2.12, "Setting mod_oc4j Load Balancing Options" for details.
Note that requests that are part of a session are sent to the same OC4J instance. If the OC4J instance becomes unavailable after the first request, mod_oc4j locates another instance to process the request, and subsequent requests in the same session are also sent to that instance.
Figure 3-5 OracleAS Clusters and Load Balancing Directives
Oracle Application Server Release 3 (10.1.3) does not provide Oracle Identity Management, but you can use Oracle Application Server Release 3 (10.1.3) with Oracle Identity Management from Release 2 (10.1.2).
You can associate the active-active topology with Oracle Identity Management, if you need Oracle Identity Management services such as Oracle Internet Directory, OracleAS Single Sign-On, OracleAS Certificate Authority, and Oracle Directory Integration and Provisioning.
You install the Release 3 (10.1.3) active-active topology and the Oracle Identity Management instances separately. After installation, you use Application Server Control Console to associate the Release 3 (10.1.3) instances with the Oracle Internet Directory in the Oracle Identity Management.
For instructions on how to associate Oracle Identity Management with Release 3 (10.1.3) instances, see the section "Configuring Instances to Use 10.1.2 and 9.0.4 Oracle Identity Management" in the Oracle Application Server Administrator's Guide.
In high availability environments, you need both your Release 3 (10.1.3) instances and your Release 2 (10.1.2) Oracle Identity Management instances to be highly available. This guide describes high availability for the Release 3 (10.1.3) instances only. For Oracle Identity Management Release 2 (10.1.2), see the Oracle Application Server High Availability Guide for Release 2 (10.1.2).
Figure 3-6 shows Oracle Application Server Release 3 (10.1.3) instances in an active-active topology running with Oracle Identity Management from Release 2 (10.1.2).
Figure 3-6 Oracle Application Server Middle Tiers with Oracle Identity Management
Instead of using Oracle HTTP Server from Release 3 (10.1.3), you can use Oracle HTTP Server from Release 2 (10.1.2) in the active-active topology. You might want to do this for the following reasons:
You are already using Oracle HTTP Server from Release 2 (10.1.2) with Oracle Application Server middle tiers from Release 2 (10.1.2).
You want to use Application Server Control Console to manage Oracle HTTP Server. Application Server Control Console from Release 2 (10.1.2) provides more management capabilities for Oracle HTTP Server than Application Server Control Console from Release 3 (10.1.3).
You can use Oracle HTTP Server from Release 2 (10.1.2) only for the distributed active-active topology (Figure 3-2).
You can use OracleAS Web Cache from Release 2 (10.1.2) with Oracle Application Server Release 3 (10.1.3), as shown in Figure 3-6.
OracleAS Web Cache is used as a reverse proxy server. The reverse proxy server can consist of an instance of OracleAS Web Cache or multiple instances configured as a cluster (called OracleAS Web Cache cluster).
For information about configuring OracleAS Web Cache (single instance or cluster) as a reverse proxy server, see section "Configuring 10.1.2 or 9.0.4 OracleAS Web Cache as a Reverse Proxy" in the Oracle Application Server Administrator's Guide.
This section describes some common procedures that you may need to perform to maintain the active-active topology:
Section 3.2.6, "Specifying the Number of Nodes to Replicate To"
Section 3.2.8, "Starting / Stopping Components in the Topology"
Section 3.2.10, "Adding Instances to an Active-Active Topology"
Section 3.2.11, "Removing Instances from an Active-Active Topology"
Section 3.2.13, "Configuring Java Message Service (JMS) for High Availability"
There are different ways to create OracleAS Clusters. This section describes only two methods:
For additional methods, see the "Configuring and Managing Clusters" chapter in the Oracle Containers for J2EE Configuration and Administration Guide.
In this method, you define the same multicast address and port for each Oracle Application Server instance in the cluster. An advantage in using this method is that you do not have to specify the name of each Oracle Application Server instance in the cluster. You can add or remove instances from the cluster by editing the multicast address and port.
For each Oracle Application Server instance that you want to group in the same cluster, run the following command:
opmnctl config topology update discover="*<multicastAddress>:<multicastPort>"
multicastAddress specifies the multicast address that you want to use for this cluster. The multicast address must be within the valid address range, which is 224.0.0.1 to 239.255.255.255. Note that the multicast address is preceded by a * character in the command.
multicastPort can be any unused port number.
Example:
> ORACLE_HOME/opmn/bin/opmnctl config topology update discover="*225.0.0.20:8001"
In distributed installations (Oracle HTTP Server and OC4J on different Oracle homes), you need to cluster all the Oracle Application Server instances into the same cluster. You need to use the same multicast IP and port for all the instances.
For each Oracle Application Server instance where you ran the "opmnctl config topology update" command, run the "opmnctl reload" command to force OPMN to read the updated opmn.xml file.
> ORACLE_HOME/opmn/bin/opmnctl reload
If you do not want to use the multicast method, you can define a cluster by specifying the names of the nodes running the Oracle Application Server instances in the opmn.xml file of each instance.
Example: if you want to cluster four instances (inst1.node1.mycompany.com, inst2.node2.mycompany.com, inst3.node3.mycompany.com, inst4.node4.mycompany.com), you would perform these steps:
Designate at least one of the instances to serve as the "discovery server". The discovery server maintains the topology for the cluster.
This example assumes that inst1.node1.mycompany.com and inst2.node2.mycompany.com will be the discovery servers for the cluster.
In distributed installations (Oracle HTTP Server and OC4J on different Oracle homes), any instance, whether running Oracle HTTP Server or OC4J, can serve as the discovery server.
In the opmn.xml file for all instances in the cluster, specify the nodes that are running the discovery servers (node1.mycompany.com and node2.mycompany.com in the example).
In the example, the opmn.xml file is changed to include the following lines:
<notification-server> <topology> <discover list="node1.mycompany.com:6201,node2.mycompany.com:6201"/> </topology> ... </notification-server>
The 6201 specifies the port number at which the notification server is listening. You can find this value in the opmn.xml file of that instance.
If you have more than one discovery server, you separate them with the comma character.
On all the instances, run "opmnctl reload" to force OPMN to read the updated opmn.xml file.
> ORACLE_HOME/opmn/bin/opmnctl reload
Multicast replication is the default replication type. To set up an application to use multicast replication, you can just add the empty <cluster/> tag to the application's orion-application.xml file or to the global ORACLE_HOME/j2ee/home/config/application.xml file. For example:
<orion-application ... > ... <cluster/> </orion-application>
You need to add the <cluster/> tag on all nodes where the application is deployed.
By default, multicast replication uses multicast address 230.230.0.1 and port 45566. If you want to change these values, you specify the desired values in the ip and port attributes of the multicast element. For example, the following snippet shows the ip and port attributes set to customized values:
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <multicast ip="225.130.0.0" port="45577" bind-addr="226.83.24.10"/> </protocol> </cluster> </orion-application>
The multicast address must be between 224.0.0.1 and 239.255.255.255.
Description of other tags and attributes used in the snippet above:
allow-colocation: specifies whether or not application state is replicated to other Oracle Application Server instances running on the same host. The default is true.
trigger and scope: see Section 3.2.5, "Setting the Replication Policy".
bind-addr: specifies the IP of the network interface card (NIC) to bind to. This is useful if the host machine has multiple NICs, each with its own IP address.
Oracle Application Server supports two types of peer-to-peer replication: dynamic and static.
In dynamic peer-to-peer replication, OC4J discovers other OC4J instances through OPMN. You do not have to list the names of the instances in a configuration file.
In static peer-to-peer replication, you list the names of the instances that you want to be involved in the replication.
Dynamic Peer-to-Peer Replication
To specify dynamic peer-to-peer replication, you include an empty <opmn-discovery/> tag in the application's orion-application.xml file or in the global ORACLE_HOME/j2ee/home/config/application.xml file
<orion-application ... >
...
<cluster allow-colocation="false">
<replication-policy trigger="onShutdown" scope="allAttributes"/>
<protocol>
<peer>
<opmn-discovery/>
</peer>
</protocol>
</cluster>
</orion-application>
You defined how OPMN discovers instances in a cluster when you set up the OracleAS Clusters. See Section 3.2.1, "Setting up OracleAS Clusters" for details.
Static Peer-to-Peer Replication
To specify static peer-to-peer replication, you list the names of the hosts in the <node> element in the application's orion-application.xml file or in the global ORACLE_HOME/j2ee/home/config/application.xml file. For each node, you specify another node in the active-active topology such that all the nodes in the topology are connected in the chain. For example, if you have three Oracle Application Server instances in your topology, node 1 can specify node 2, node 2 can specify node 3, and node 3 can specify node 1.
Example:
On node 1, the <node> tag specifies node 2:
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node2.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
On node 2, the <node> tag specifies node 3:
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node3.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
On node 3, the <node> tag specifies node 1:
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node1.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
Another way of doing this is to have all the nodes specify the same node. In a three-node example, you could also have nodes 1 and 2 specify node 3, and node 3 can specify either node 1 or node 2.
Description of the tags and attributes used in the example above:
start-port: specifies the first port on the local node that Oracle Application Server tries to bind to for peer communication. If this port is already in use, Oracle Application Server increments the port number until it finds an available port. The default is 7800.
timeout: specifies the length of time in milliseconds to wait for a response from the specified peer node. The default is 3000 milliseconds.
host: specifies the name of the peer node.
port: specifies the port to use on the specified host (in the host attribute) for peer communication. The default is 7800.
range: specifies the number of times to increment the port specified on the port (not start-port) attribute. The default is 5.
Note the following:
In static peer-to-peer replication, the application's orion-application.xml file is different for each instance. When you deploy your application, you have to make sure that you update the orion-application.xml accordingly.
In this replication mechanism, the replicated data is saved to a database. You specify the database in the <database> tag in the application's orion-application.xml file or in the global ORACLE_HOME/j2ee/home/config/application.xml file. For example:
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <database data-source="jdbc/MyOracleDS"/> </protocol> </cluster> </orion-application>
The value for the data-source attribute must match the data source's jndi-name as specified in the data-sources.xml file. See the Oracle Containers for J2EE Services Guide for details on creating and using data sources.
Attributes in the <replication-policy> tag enable you to specify which data is to be replicated and how frequently the data is replicated.
The trigger attribute specifies when replication occurs. Table 3-2 describes supported values for this attribute:
Table 3-2 Values for the trigger Attribute
| Value | HttpSession | Stateful Session Bean |
|---|---|---|
|
|
Replicate each change made to an HTTP session attribute at the time the value is modified. From a programmatic standpoint, replication occurs each time This option can be resource intensive in cases where the session is being extensively modified. |
Not applicable. |
|
|
Queue all changes made to HTTP session attributes, then replicate all changes just before the HTTP response is sent. |
Replicate the current state of the bean after each EJB method call. The state is replicated frequently, but offers higher reliance. |
|
|
Replicate the current state of the HTTP session whenever the JVM is terminated gracefully, such as with Control-C. State is not replicated if the host is terminated unexpectedly, as in the case of a system crash. Because session state was not previously replicated, all session data is sent across the network at once upon JVM termination, which can impact network performance. This option can also significantly increase the amount of time needed for the JVM to shut down. |
Replicate the current state of the bean whenever the JVM is terminated gracefully. State is not replicated if the host is terminated unexpectedly, as in case of a system crash. Because bean state was not previously replicated, all state data is sent across the network at once upon JVM termination, which can impact network performance. This option may also significantly increase the amount of time needed for the JVM to shut down. |
The scope attribute
The scope attribute specifies which data is replicated. Table 3-3 describes supported values for the attribute:
Table 3-3 Values for the scope Attribute
| Value | HttpSession | Stateful Session Bean |
|---|---|---|
|
|
Replicate only the modified HTTP session attributes. This is the default replication setting for HttpSession. |
Not applicable. |
|
|
Replicate all attribute values set on the HTTP session. |
Replicate all member variable values set on the stateful session bean. This is the default replication setting for stateful session beans. |
To specify the number of nodes to replicate to, use the write-quota attribute of the <cluster> tag. For example, the following snippet specifies that the replicated data is replicated to two other nodes.
<orion-application ... > ... <cluster allow-colocation="false" write-quota="2"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer> <opmn-discovery/> </peer> </protocol> </cluster> </orion-application>
The default is 1.
Recommendations: For a two-node active-active topology, set write-quota to 1, so that the data is replicated to the other node.
For topologies with three or more nodes, set write-quota to at least 2 to ensure that the data is replicated to at least two other nodes.
To replicate data to all nodes in the topology, set write-quota to the total number of nodes in the topology. It is possible to write back to the same node if there is another instance running on that node.
The write-quota attribute is not used if you are replicating to database.
To check the status of instances in the active-active topology, run the following command from any instance in the topology:
> cd ORACLE_HOME/opmn/bin > opmnctl @cluster status
You can use the opmnctl command to start and stop components in the topology. To start and stop components on all Oracle Application Server instances in the topology, you need to use the @cluster parameter in opmnctl. You can run the opmnctl command from any instance in the topology.
For example, to start the Oracle HTTP Server component on all instances in the topology, run the following command from any instance in the topology:
> cd ORACLE_HOME/opmn/bin > opmnctl @cluster startproc ias-component=HTTP_Server
You can deploy applications using Application Server Control Console or using commands that you run from the command-line.
If you want to deploy your application to all instances within a cluster, you can do so using admin_client.jar, as follows:
> cd ORACLE_HOME/j2ee/home > java admin_client.jar deployer:cluster:opmn://<host>:<opmnPort>/<oc4jInstanceName> <adminID> <adminPassword> -deploy -file <pathToArchiveFile> -deploymentName <appName>
For <host>, you can specify any host in the cluster.
For <opmnPort>, you specify the port at which OPMN is listening. This port is listed in the opmn.xml file.
For <oc4jInstanceName>, you specify the OC4J instance to which you want to deploy your application. Example: to deploy on the "home" instance, you specify home.
For <adminID> and <adminPassword>, you specify the administrator's ID and password. Typically the adminID is oc4jadmin.
|
Note: For deployment to work across all instances in a cluster, the administrator's password must be the same for all instances in the cluster. |
For <pathToArchiveFile>, you specify the full path to the EAR, WAR, or JAR file that you want to deploy.
For <appName>, you specify the application name.
There are other options that you can specify on the command-line for deployment. For details, see the Oracle Containers for J2EE Deployment Guide.
To add instances to an existing topology:
Use the existing cluster method that the topology is using. For example, if the topology is using the dynamic discovery method, then you need to configure the new instance to use the same multicast IP and port.
To cluster the OC4J component, follow the existing model already in use by the topology.
Deploy the same applications on the new instances.
Configure your load balancer to direct requests to the new node.
To remove an instance from a topology:
Reconfigure your load balancer so that it no longer directs requests to the removed instance.
Remove the instance from OracleAS Clusters by removing the tags that you added to the instance. You added these tags when you set up the cluster. See Section 3.2.1, "Setting up OracleAS Clusters" for details.
Remove the instance from application-level clustering by removing these tags:
The <distributable/> tag from the web.xml file for all Web modules that are part of an application configured for clustering
The <cluster> tag that you added to the application's orion-application.xml file or to the global ORACLE_HOME/j2ee/home/config/application.xml file
The mod_oc4j module within Oracle HTTP Server delegates requests to OC4J processes. Whenever Oracle HTTP Server receives a request for a URL that is intended for OC4J, Oracle HTTP Server routes the request to the mod_oc4j module, which then routes the request to an OC4J process. If an OC4J process fails, OPMN detects the failure and mod_oc4j does not send requests to the failed OC4J process until the OC4J process is restarted.
You can configure mod_oc4j to load balance requests to OC4J processes. Oracle HTTP Server, through mod_oc4j, supports different load balancing policies. Load balancing policies provide performance benefits along with failover and high availability, depending on the network topology and host machine capabilities.
You can specify different load balancing routing algorithms for mod_oc4j depending on the type and complexity of routing you need. Stateless requests are routed to any destination available based on the algorithm specified in mod_oc4j.conf. Stateful HTTP requests are forwarded to the OC4J process that served the previous request using session identifiers, unless mod_oc4j determines through communication with OPMN that the process is not available. In this case, mod_oc4j forwards the request to an available OC4J process following the specified load balancing protocol.
By default, all OC4J instances have the same weight (all instances have a weight of 1), and mod_oc4j uses the round robin method to select an OC4J instance to forward a request to. An OC4J instance's weight is taken as a ratio compared to the weights of the other available OC4J instances in the topology to define the number of requests the instance should service. If the request belongs to an established session, mod_oc4j forwards the request to the same OC4J instance and the same OC4J process that started the session.
The mod_oc4j load balancing options do not take into account the number of OC4J processes running on an OC4J instance when determining which OC4J instance to send a request to. OC4J instance selection is based on the configured weight for the instance, and its availability.
To modify the mod_oc4j load balancing policy, set the Oc4jSelectMethod and the Oc4jRoutingWeight directives in the ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file:
In the mod_oc4j.conf file on each Oracle Application Server instance, within the <IfModule mod_oc4j.c> section, set the Oc4jSelectMethod directive to one of the values shown in Table 3-4.
If you set the Oc4jSelectMethod directive to either roundrobin:weighted or random:weighted, you may also need to set the Oc4jRoutingWeight directive to specify the weight (see the next step).
See "Choosing a mod_oc4j Load Balancing Algorithm" for tips on choosing a routing algorithm.
Table 3-4 Values for Oc4jSelectMethod
| Value | Description |
|---|---|
|
|
mod_oc4j places all the OC4J processes in the topology in a list, and it selects processes in order from the list. |
|
|
Similar to |
|
|
mod_oc4j distributes the total request load to each OC4J instance based on routing weight configured on each instance. It then selects OC4J processes from the local instance in a round robin manner. You configure the weight using the |
|
|
mod_oc4j randomly selects an OC4J process from a list of all OC4J processes in the topology. |
|
|
Similar to |
|
|
mod_oc4j selects an OC4J process based on the weight configured for each instance in the topology. You configure the weight using the |
|
|
mod_oc4j routes requests based on runtime metrics that indicate how busy a process is. |
|
|
Similar to metric, but mod_oc4j gives preference to local OC4J processes. If no local OC4J processes are available, then it routes to a remote OC4J process. |
Example:
Oc4jSelectMethod random:local
For information on how to set up metric-based load balancing, see the "Load Balancing Using mod_oc4j" appendix in the Oracle HTTP Server Administrator's Guide.
If you set the Oc4jSelectMethod directive to a weight-based method (that is, roundrobin:weighted or random:weighted), you may also need to set the Oc4jRoutingWeight directive to specify the weight.
If you do not set the Oc4jRoutingWeight directive, it defaults to 1.
Example: If you have a topology that consists of three instances (A, B, and C), and you want B and C to get twice as many requests as A, set the following directives for B and C:
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingMethod 2
For A, you can just set the Oc4jSelectMethod directive. Setting Oc4jRoutingMethod is optional because the default value is 1.
Restart Oracle HTTP Server on all instances in the topology for the changes to take effect.
> opmnctl @cluster restartproc ias-component=HTTP_Server
Choosing a mod_oc4j Load Balancing Algorithm
Use the following guidelines to help determine which mod_oc4j load balancing option to use:
In a topology with identical machines running Oracle HTTP Server and OC4J in the same Oracle home, the round robin with local affinity algorithm is preferred. In this case Oracle HTTP Server gains little by using mod_oc4j to route requests to other machines, except in the extreme case that all OC4J processes on the same machine are not available.
For a distributed deployment, where one set of machines runs Oracle HTTP Server and another set runs OC4J instances that handle requests, the preferred algorithms are simple round robin and simple metric-based. To determine which of these two works better in a specific setup, you may need to experiment with each and compare the results. This is required because the results are dependent on system behavior and incoming request distribution.
For a heterogeneous deployment, where the different Oracle Application Server instances run on nodes that have different characteristics, the weighted round robin algorithm is preferred. In addition to setting the weight for each instance, remember to tune the number of OC4J processes running on each Oracle Application Server instance to achieve the maximum benefit. For example, a machine with a weight of 4 gets four times as many requests as a machine with a weight of 1, but you need to ensure that the system with a weight of 4 is running four times as many OC4J processes.
Metric-based load balancing is useful when there are only a few metrics that dominate the performance of an application, for example, CPU or number of database connections.
For information on how to configure JMS for high availability, see chapter 3, "Java Message Service (JMS)", in the Oracle Containers for J2EE Services Guide.
Table 3-5 summarizes some of the high availability features in Oracle HTTP Server and OC4J.
Table 3-5 Summary of High Availability Features in Oracle HTTP Server and OC4J
| Item | Description |
|---|---|
|
Protection from Node Failure |
Oracle HTTP Server: A load balancer deployed in front of Oracle HTTP Server instances protects from node failure. The load balancer can be an external load balancer or OracleAS Web Cache (OracleAS Web Cache is from Release 2 (10.1.2)). OC4J: mod_oc4j routes requests only to OC4J instances that are alive. You should install and run OC4J instances on different nodes to provide greater probability that OC4J is alive and running on at least one node at any time. |
|
Protection from Service Failure |
Oracle HTTP Server: A load balancer deployed in front of Oracle HTTP Server instances sends request to another Oracle HTTP Server if first one does not respond or is deemed failed through URL pings. The load balancer can be an external load balancer or OracleAS Web Cache. OC4J: OPMN monitors OC4J processes and restarts them upon process failure. OPMN also notifies mod_oc4j if the restart was not successful so that mod_oc4j will send requests only to OC4J processes that are alive. |
|
Protection from Process Failure |
Oracle HTTP Server: OPMN monitors Oracle HTTP Server processes and restarts them upon process failure. Each Oracle HTTP Server is also notified by OPMN when another Oracle HTTP Server process in the topology fails. OC4J: OPMN monitors OC4J processes and restarts them upon process failure. OPMN also notifies mod_oc4j if the restart was not successful so that mod_oc4j will send requests only to OC4J processes that are alive. |
|
Automatic Re-routing |
Oracle HTTP Server: A load balancer deployed in front of Oracle HTTP Server instances automatically re-routes to another Oracle HTTP Server if the first one does not respond. OC4J: mod_oc4j automatically re-routes to another OC4J process if the first one does not respond. |
When EJB clustering is enabled, JNDI namespace replication is also enabled between the OC4J instances in a middle-tier OracleAS Cluster. New bindings to the JNDI namespace in one OC4J instance are propagated to other OC4J instances in the middle-tier OracleAS Cluster. Re-bindings and unbindings are not replicated.
The replication is done outside the scope of each OracleAS Cluster (OC4J). In other words, multiple OracleAS Clusterss (OC4J) in an OC4J instance have visibility into the same replicated JNDI namespace.
See the Oracle Containers for J2EE Services Guide for details on JNDI.
In EJB client routing, EJB classes take on the routing functionality that mod_oc4j provides between Oracle HTTP Server and servlets/JSPs. Clients invoke EJBs using the Remote Method Invocation (RMI) protocol. The RMI protocol listener is set up by in the RMI configuration file, rmi.xml, for each OC4J instance. It is separate from the Web site configuration. EJB clients and the OC4J tools access the OC4J server through a configured RMI port. OPMN designates a range of ports that the RMI listener could be using.
When you use the "opmn:ormi://" prefix string in the EJB look up, the client retrieves the assigned RMI port automatically. The load balancing and client request routing is provided by OPMN selecting the different OC4J processes available. The algorithm used for this load balancing is the random algorithm. Multiple OPMN URLs separated by commas can be used for higher availability.
Oracle Application Server Java Object Cache provides a distributed cache that can serve as a high availability solution for applications deployed on OC4J. The Java Object Cache is an in-process cache of Java objects that can be used on any Java platform by any Java application. It enables applications to share objects across requests and across users, and coordinates the life cycle of the objects across processes.
Java Object Cache enables data replication among OC4J processes even if they do not belong to the same OracleAS Clusters (OC4J), Oracle Application Server instance, or overall Oracle Application Server Cluster.
By using Java Object Cache, performance can be improved because shared Java objects are cached locally, regardless of which application produces the objects. This also improves availability; in the event that the source for an object becomes unavailable, the locally cached version is still available.
See the "Java Object Cache" chapter in the Oracle Containers for J2EE Services Guide for details on using Java Object Cache.
