| Oracle® Application Server High Availability Guide 10g Release 3 (10.1.3.2.0) Part Number B32201-01 |
|
|
View PDF |
| Oracle® Application Server High Availability Guide 10g Release 3 (10.1.3.2.0) Part Number B32201-01 |
|
|
View PDF |
This chapter describes active-active topologies. It contains the following sections:
An active-active topology consists of redundant Oracle Application Server 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 Oracle Application Server 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.
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.
If you are running WebCenter applications in active-active topologies, you should note the following:
Section 3.1.2.1, "Shared Storage for Oracle Metadata Services (MDS)"
Section 3.1.2.2, "Type and Location of Portlet Preference Stores"
In addition to the local drives on each node, you need a shared storage that can be accessed by all the nodes in an active-active topology. On the shared storage, you need to create a directory for Oracle Metadata Services (MDS). The MDS directory stores page customization data and portlet metadata for deployed WebCenter applications.
By having the MDS directory on the shared storage, you ensure that all Oracle Application Server instances access the same data and you do not have to worry about replicating the data.
The mount point for the MDS directory must be the same for all nodes in the active-active topology (for example, /oracle/mds on UNIX, or S:\oracle\mds on Windows). On Windows, the mount point, including the drive letter, must be the same on all nodes; for example, it cannot be S:\oracle\mds on one node and T:\oracle\mds on another node.
You do not need the shared storage during installation, but you need it when you deploy your applications. You specify the path to the MDS directory during application deployment.
Shared storage for the portlet preference store: For high availability topologies, the recommended approach is to use a database as the portlet preference store (which is different from MDS). However, if you choose to use a file-based portlet preference store, you can also place the file on the shared storage. See Section 3.1.2.2, "Type and Location of Portlet Preference Stores" for more information about portlet preference stores.
WebCenter applications consume portlets that can be hosted by a portlet producer on a remote computer. The portlet producers store portlet preferences, or customizations, in a preference store that can be either database-based or file-based.
Note:
The Web Clipping portlet does not use a preference store. Instead, it uses a repository to store clippings and clipping definitions. See Section 3.1.2.3, "Repository for the Web Clipping Portlet" for details.In a high availability topology, Oracle recommends that you use a database-based preference store, and the database should be configured for high availability, such as a Real Application Clusters database or a cold failover cluster database.
You specify the preference store type in the portlet producer's web.xml (for WSRP producers) or provider.xml (for PDK-Java producers) file.
Backing up the portlet preference store: The portlet preference store (file or database) should be included when you back up your Oracle Application Server environment. See the section "Performing a Portlet Producer Backup" in the Oracle Application Server Administrator's Guide for details.
Do not confuse the portlet preference stores with MDS. These are two separate concepts. Note that MDS is file-based only and is stored on a shared storage, as described in Section 3.1.2.1, "Shared Storage for Oracle Metadata Services (MDS)".
If you store the portlet preferences in a database, the database should be a high availability database, such as a Real Application Clusters database or a cold failover cluster database.
For the Web Clipping portlet, which uses a repository instead of a preference store, see Section 3.1.2.3, "Repository for the Web Clipping Portlet".
Note:
If you are using the Web Clipping portlet, you cannot use a Real Application Clusters database for its repository. You can use a cold failover cluster database instead.For specific steps in configuring a database-based preference store, see section 16.4.1, "Setting Up a Database Preference Store", in the Oracle WebCenter Framework Developer's Guide.
Note:
Portlet producers (both WSRP and PDK-Java) do not support Fast Connection Failover (FCF). This means that if a database instance fails, you may see the following error in your browser window: "Error occurred while rendering portlet - contact your system administrator".
In the log.xml file, you may see messages like this:
<MSG_TEXT>ERROR: PrefStorePersonalizationManager: Failed to read
customization for Portlet: 1163787272417/100/PI1163787272417_86327909/tom
Type: 2</MSG_TEXT>
<SUPPL_DETAIL><
This section provides an overview of the installation steps. For details, see the Oracle Application Server Installation Guide for your platform.
If you will be installing Oracle Content DB, you need a database. In high availability topologies, you should use high availability databases, such as Oracle Real Application Clusters database.
Check that the initialization parameters for your database are set appropriately. See the Oracle Application Server Installation Guide for your platform for details.
You also need to know the password for the SYS user.
If you want to store repository information in Oracle Internet Directory, have available an Oracle Internet Directory. This Oracle Internet Directory should be configured in a highly available manner.
If you do not have an Oracle Internet Directory, you can store repository information in a file.
Install the components that you need. You install the components on the local storage of each node.
To install all the components (Oracle HTTP Server, WebCenter Framework, and Oracle Content DB) in one Oracle home, use the "Basic Installation" option.
To install Oracle HTTP Server plus one of WebCenter Framework or Oracle Content DB, use the "Advanced Installation" option and select either the "Oracle WebCenter Framework with Oracle HTTP Server" option or the "Oracle Content Database" option.
You need to cluster the Oracle Application Server instances. You can do this during installation, or you can do it after installation.
After installation, perform these steps:
If you did not cluster the Oracle Application Server instances during installation, you can do so after installation. See Section 3.2.1, "Setting up OracleAS Clusters" for details.
Configure the load balancer to direct requests to all the nodes. Sticky sessions are not required.
This step is required only if you are using SSL.
Edit the ORACLE_HOME/Apache/Apache/conf/httpd.conf file on each node as follows:
Add the following line to load the certheaders_module.
If you are using Oracle HTTP Server 1.3 on UNIX, add the following line to the httpd.conf file:
LoadModule certheaders_module libexec/mod_certheaders.so
If you are using Oracle HTTP Server 2.0 on UNIX, add the following line to the httpd.conf file:
LoadModule certheaders_module modules/mod_certheaders.so
If you are using Oracle HTTP Server on Windows, add the following line to the httpd.conf file:
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
Add a virtual host directive.
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
Restart Oracle HTTP Server on all the nodes.
Update these domain properties using Application Server Control on each node:
Set IFS.DOMAIN.APPLICATION.ApplicationHost to the virtual hostname configured on the load balancer.
Set IFS.DOMAIN.APPLICATION.ApplicationPort to the port number configured on the load balancer.
To edit these properties using Application Server Control:
On the Cluster Topology page, expand OC4J_Content.
Click content located under OC4J_Content. This displays the "Application: content" page.
On the "Application: content" page, click Content DB Extension. This displays the "Content DB: content" page.
On the "Content DB: content" page, click the Administration tab.
Click the icon in the Go To Task column for Domain Properties.
On the Domain Properties page, click the IFS.DOMAIN.APPLICATION.ApplicationHost property, and set its value to the virtual hostname configured on the load balancer. Click OK.
On the Domain Properties page, click the IFS.DOMAIN.APPLICATION.ApplicationPort property, and set its value to the port number configured on the load balancer. Click OK.
Reload OPMN on each node.
> ORACLE_HOME/opmn/bin/opmnctl reload
Figure 3-2 shows a distributed active-active topology with Oracle HTTP Server, WebCenter Framework, and Oracle Content DB installed on separate nodes. You can use this topology if your nodes are separated into web and application tiers, and the nodes in the tiers are separated by firewalls.
Figure 3-2 Active-Active Topology with Oracle HTTP Server, WebCenter Framework, and Oracle Content DB in Separate Oracle Homes
Oracle HTTP Server runs on the web tier. To make Oracle HTTP Server highly available, you can run it in either an active-active or active-passive topology:
To configure Oracle HTTP Server in an active-active topology (shown in Figure 3-2), install it on nodes that are fronted by a load balancer. Install it on the local storage of each node, and configure the load balancer to distribute requests to the nodes. Clients send requests to Oracle HTTP Server using the virtual hostname configured on the load balancer.
Cluster the Oracle HTTP Server instances, the WebCenter Framework instances, and the Oracle Content DB instances in the same cluster so that Oracle HTTP Server can forward requests to any of the nodes.
To configure Oracle HTTP Server in an active-passive topology (shown in Figure 4-2), you have two nodes in a hardware cluster, and the two nodes are associated with a shared storage. The hardware cluster is associated with a virtual hostname and IP address. You install Oracle HTTP Server on the shared storage. One node in the hardware cluster is active, while the other node is passive. Clients send requests to Oracle HTTP Server using the virtual hostname.
You place the Oracle HTTP Server and the WebCenter Suite instances in the application tier in the same cluster so that Oracle HTTP Server knows the location of the nodes running WebCenter Suite.
You install WebCenter Framework and Oracle Content DB in separate Oracle homes on the local storage of nodes in the application tier. Since they are separate installations, you can install them on the same node or on different nodes. You do not need to install both WebCenter Framework and Oracle Content DB, unless you need both components.
All the Oracle homes in the web tier and application tier are in the same OracleAS Cluster. This enables the Oracle HTTP Server to send requests to any OC4J instance that belongs in the same cluster.
Nodes in the application tier need access to a shared storage. This shared storage contains the Oracle Metadata Services (MDS) directory. See Section 3.1.2.1, "Shared Storage for Oracle Metadata Services (MDS)" for details.
This section provides an overview of the installation steps. For details, see the Oracle Application Server Installation Guide for your platform.
If you will be installing Oracle Content DB, you need a database. In high availability topologies, you should use high availability databases, such as Oracle Real Application Clusters database.
Check that the initialization parameters for your database are set appropriately. See the Oracle Application Server Installation Guide for your platform for details.
You also need to know the password for the SYS user.
If you want to store repository information in Oracle Internet Directory, have available an Oracle Internet Directory. This Oracle Internet Directory should be configured in a highly available manner.
If you do not have an Oracle Internet Directory, you can store repository information in a file.
Install Oracle HTTP Server on nodes in the web tier. To install Oracle HTTP Server, select the "Advanced Installation" option in the installer, and then select the "Oracle HTTP Server" option.
You need to cluster the Oracle Application Server instances (running Oracle HTTP Server, WebCenter Framework, or Oracle Content DB). You can configure the cluster during installation, or you can do it after installation.
Install WebCenter Framework on nodes in the application tier. To install WebCenter Framework, select the "Advanced Installation" option in the installer, and then select the "Oracle WebCenter Framework" option.
Install Oracle Content DB on nodes in the application tier. To install Oracle Content DB, select the "Advanced Installation" option in the installer, and then select the "Oracle Content Database" option.
After installation, perform these steps:
If you did not cluster the Oracle Application Server instances during installation, you can do so after installation. You need to cluster all the Oracle Application Server instances in both web and application tiers. See Section 3.2.1, "Setting up OracleAS Clusters" for details.
Configure the load balancer in the application tier to direct requests to all the nodes in the application tier. Sticky sessions are not required.
Disable Oracle HTTP Server on the Oracle homes where you installed Oracle Content DB.
Set the status of Oracle HTTP Server to disabled in the ORACLE_HOME/opmn/conf/opmn.xml file:
<ias-component id="HTTP_Server" status="disabled">
Stop and restart all components in the Oracle home.
> ORACLE_HOME/bin/opmnctl stopall > ORACLE_HOME/bin/opmnctl startall
This step is required only if you are using SSL.
On the Oracle HTTP Server nodes, edit the ORACLE_HOME/Apache/Apache/conf/httpd.conf file as follows:
Load the certheaders_module.
If you are using Oracle HTTP Server 1.3 on UNIX, add the following line to the httpd.conf file:
LoadModule certheaders_module libexec/mod_certheaders.so
If you are using Oracle HTTP Server 2.0 on UNIX, add the following line to the httpd.conf file:
LoadModule certheaders_module modules/mod_certheaders.so
If you are using Oracle HTTP Server on Windows, add the following line to the httpd.conf file:
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
Add a virtual host directive.
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
Restart Oracle HTTP Server on all the nodes.
Update these domain properties using Application Server Control on each node:
Set IFS.DOMAIN.APPLICATION.ApplicationHost to the virtual hostname configured on the load balancer.
Set IFS.DOMAIN.APPLICATION.ApplicationPort to the port number configured on the load balancer.
To edit these properties using Application Server Control:
On the Cluster Topology page, expand OC4J_Content.
Click content located under OC4J_Content. This displays the "Application: content" page.
On the "Application: content" page, click Content DB Extension. This displays the "Content DB: content" page.
On the "Content DB: content" page, click the Administration tab.
Click the icon in the Go To Task column for Domain Properties.
On the Domain Properties page, click the IFS.DOMAIN.APPLICATION.ApplicationHost property, and set its value to the virtual hostname configured on the load balancer. Click OK.
On the Domain Properties page, click the IFS.DOMAIN.APPLICATION.ApplicationPort property, and set its value to the port number configured on the load balancer. Click OK.
Reload OPMN on each node.
> ORACLE_HOME/opmn/bin/opmnctl reload
All the Oracle Application Server instances in an active-active topology belong to the same cluster. Oracle HTTP Server can forward application requests to any OC4J instance in the same cluster. This is useful because the WebCenter Framework and Oracle Content DB components run in OC4J containers:
Table 3-1 WebCenter Framework and Oracle Content DB and their OC4J Instances
| Component | Runs in this OC4J Instance |
|---|---|
|
WebCenter Framework |
OC4J_WebCenter |
|
Oracle Content DB |
OC4J_Content |
You can group instances in a 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 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)
You need to add an empty <distributable/> tag to the web.xml file for all Web modules that are part of an application configured to use application clustering. After deployment, this J2EE standard Web module descriptor is in the ORACLE_HOME/j2ee/j2ee_instance_name/applications/app_name/web_module_name/WEB-INF directory.
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.
By placing OC4J instances in groups, you can perform some common administrative tasks at the group level. For example, from the Group page in Application Server Control, you can perform these tasks on all the members of a group:
Process management operations, such as start, stop, or restart
Deployment operations, such as deploy, undeploy, and redeploy
JDBC management operations, such as creating, modifying, or removing JDBC data sources and connection pools
JMS Provider operations, such as creating and removing JMS destinations, and creating, modifying, or removing JMS connection factories
To display the Group page, click the name of a group in the Group section of the Cluster Topology page.
Each OC4J instance must be in a group. A group called "default_group" is created automatically when you install Oracle Application Server.
Figure 3-4 shows three Oracle Application Server instances. Each of these Oracle Application Server instances has an OC4J instance called "home" and they belong to a group called "Apps". The figure also shows that two of the three Oracle Application Server instances have an OC4J instance called "sales", and these OC4J instances belong to a group called "finance".
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.
For more information on groups, see "Guidelines for Creating OC4J Instances and Groups" in the Application Server Control online help.
You can create groups using Application Server Control. The Cluster Topology page contains a "Groups" section that enables you to perform operations (such as starting, stopping, deleting, and creating) on groups.
You can also create groups when creating OC4J instances. If you create OC4J instances using Application Server Control, in addition to entering the name of the OC4J instance, you also have to specify which group the new OC4J instance should belong to. You can specify an existing group or a new group. See Section 3.1.9.2, "Creating Additional OC4J Instances".
If you create OC4J instances using the createinstance command, you specify the name of the group with the groupName parameter. Section 3.1.9.2, "Creating Additional OC4J Instances" shows the createinstance command.
For details on groups, including procedures for creating groups, creating OC4J instances, and removing OC4J instances, see the section "Creating and Managing OC4J Groups Within Oracle Application Server Clusters" in chapter 8, "Configuring and Managing Clusters and OC4J Groups", of the Oracle Containers for J2EE Configuration and Administration Guide.
You can create additional OC4J instances using Application Server Control or using the ORACLE_HOME/bin/createinstance command.
Using the Application Server Control
On the Cluster Topology page, click the name of the Oracle Application Server instance, which displays the "Application Server: instance_name" page. Click the Create OC4J Instance button to display the Create OC4J Instance page (Figure 3-5).
On the Create OC4J Instance page, enter the name of the OC4J instance that you want to create, and the group to which the OC4J instance should belong. You can specify an existing group or a new group.
Using the createinstance Command
You can create additional OC4J instances using the ORACLE_HOME/bin/createinstance command. The syntax is:
createinstance -instanceName name [-port httpPort] [-groupName groupName]
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.
The optional groupName parameter enables you to add the new OC4J instance to the specified group. If you do not specify this parameter, the instance is added to the default_group group. If the specified group does not exist, it creates the group.
For example, to create the "sales" OC4J instance and add it to the "finance" group, you can use the following command:
createinstance -instanceName sales -groupName finance
The command prompts you to set the password for the oc4jadmin user for the "sales" instance. This password can be different from the password for the "home" instance, but that is not recommended. You should set the password to be the same as the oc4jadmin user's password for the "home" instance to prevent problems with OPMN.
For details about passwords, see the section "Creating an OC4J Instance with the createinstance Utility" in chapter 8, "Configuring and Managing Clusters", of the Oracle Containers for J2EE Configuration and Administration Guide.
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 more information on the createinstance command, see the section "Creating and Managing Additional OC4J Instances" in chapter 8, "Configuring and Managing Clusters", of the Oracle Containers for J2EE Configuration and Administration Guide.
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-2 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-6.
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.8, "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-6 OracleAS Clusters and Load Balancing Directives
Oracle Application Server Release 3 (10.1.3.1.0) does not provide Oracle Identity Management, but you can use Oracle Application Server Release 3 (10.1.3.1.0) with Oracle Identity Management from Release 9.0.4, Release 2 (10.1.2), or Release 10.1.4.
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.1.0) 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.1.0) 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.1.0) instances, see the section "Configuring Instances to Use 10.1.4, 10.1.2, or 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 Oracle Identity Management instances to be highly available. This guide describes high availability for the Release 3 (10.1.3) instances only. For high availability for Oracle Identity Management, see the Oracle Application Server High Availability Guide for the Oracle Identity Management release you are using.
Figure 3-7 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-7 Oracle Application Server Middle Tiers with Oracle Identity Management
Instead of using Oracle HTTP Server from Release 3 (10.1.3.1.0), 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-7.
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 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.4, "Starting / Stopping Components in the Topology"
Section 3.2.6, "Adding Instances to an Active-Active Topology"
Section 3.2.7, "Removing Instances from an Active-Active Topology"
Section 3.2.9, "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.
Note:
If the nodes running the Oracle Application Server instances that you want to cluster are on different subnets or are separated by firewalls, you may need to configure the cluster using gateways. For details, see the section "Configuring Cross-Topology Gateways" in 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.1.0 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
You can set up replication in different ways:
You can define the replication policy, which specifies when replication occurs, and limit the number of nodes where data is replicated:
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.1.0 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.2.4, "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.
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.
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-3 describes supported values for this attribute:
Table 3-3 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 specifies which data is replicated. Table 3-4 describes supported values for the attribute:
Table 3-4 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
Note that the deployment procedure has changed for this release. In particular, you have to specify the path to the MDS directory on the shared storage. You do this by running the new "Predeployment tool".
Note that you run the Predeployment tool on one node only; you do not need to run it on each node in the topology.
For details on the deployment steps, see chapter 9, "Deploying Your WebCenter Application", in the Oracle WebCenter Framework Developer's Guide.
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-5.
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-5 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.
Oc4jRoutingWeight has the following syntax:
Oc4jRoutingWeight hostname weight
If you do not set the Oc4jRoutingWeight directive, it uses a default weight of 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 all instances:
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingWeight hostB 2 Oc4jRoutingWeight hostC 2
Setting Oc4jRoutingWeight for hostA 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 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 4, "Using Oracle Enterprise Messaging Service", in the Oracle Containers for J2EE Services Guide.
Table 3-6 summarizes some of the high availability features in Oracle HTTP Server and OC4J.
Table 3-6 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.
