4 Managing and Operating Middle Tier High Availability

4.1.1.1 Oracle Application Server Clusters Managed Using Database Repository

Oracle Application Server Clusters managed using a database repository utilize Oracle9i database to store configuration information and metadata, including both cluster-wide configuration information and instance-specific parameters.

Using a database repository protects configuration information by storing the information in the database. Using the database, combined with Oracle Application Server high availability solutions both protects configuration information and allows you to continue operations after system failures.

4.1.1.2 Oracle Application Server Clusters Managed Using File-Based Repository

Oracle Application Server Clusters managed using a file-based repository use the file system to store configuration information, including both cluster-wide configuration information and instance-specific parameters. Using Oracle Application Server Clusters managed using a file-based repository does not present a single point of failure; remaining Oracle Application Server instances within a cluster are available to service client requests when one or more Oracle Application Server instances is down.

Configuring and managing Oracle Application Server Clusters managed using a file-based repository requires that the administrator set up a farm and perform certain configuration tasks using the dcmctl command line utility.

4.1.1.3 Common Tasks for OracleAS Cluster Configuration

Figure 4-1 shows the cluster configuration hierarchy, starting with an Oracle Application Server top-level farm for an OracleAS Cluster. This figure applies to both types of OracleAS Clusters: those managed using a file-based repository and those managed using a database repository.

Figure 4-1 shows the OracleAS Clusters configuration hierarchy, including the following:

• Clusters that contain Oracle Application Server instances

• Oracle Application Server instances containing a single Oracle HTTP Server and one or more OC4J instances

• OC4J instances containing the following:

  • One or more OC4J islands

  • One or more OC4J processes within OC4J islands

  • Deployed applications

Figure 4-1 Application Server Console Cluster Configuration Tree

Description of the illustration conftree.gif

4.2.1.1 Associating an Instance with a Farm

If you have not already done so during the Oracle Application Server installation process, you can associate an application server instance with a farm using one of the following techniques:

• Associating an Instance to be Managed Using a Database Repository

• Associating an Instance to be Managed Using a File-Based Repository

4.2.1.2 Creating OracleAS Clusters Using Application Server Console

You create a new OracleAS Cluster using the Application Server Console Farm Home Page. Application Server Console only shows the Farm Home Page when an Oracle Application Server instance is part of a farm.

From the Farm Home page, create a new OracleAS Cluster as follows:

1. Navigate to the Farm Home Page.

2. Select the Create Cluster button.

   Application Server Console displays the Create Cluster page.

   Figure 4-2 shows the Create Cluster page.

   Figure 4-2 Create Cluster Page

   
   Description of the illustration creaclus.gif
   
   

3. Enter a name for the new cluster and click Create. Each new cluster name within the farm must be unique.

   A confirmation page appears.

4. Click OK to return to the Farm Home Page.

After creating a new OracleAS Cluster, the Farm Home page shows the cluster in the Clusters area. After creating a new cluster, the cluster is empty and does not include any application server instances. Use the Join Cluster button on the Farm Home page to add application server instances to the cluster.

4.2.1.3 Managing OracleAS Clusters Using Application Server Console

Figure 4-3 shows the Application Server Console Farm Home Page, including two clusters, cluster1 and cluster2.

Figure 4-3 Oracle Application Server 10g Farm Page

Description of the illustration farmclus.gif

Table 4–1 lists the cluster control options available on the Farm Home Page.

4.2.2.1 Adding an Application Server Instance to an OracleAS Cluster

To add an application server instance to a cluster:

1. Navigate to the Farm Home Page.

2. Select the radio button for the application server instance that you want to add to a cluster from the Standalone Instances section.

3. Click Join Cluster.

   Figure 4-4 shows the Join Cluster page.

   Figure 4-4 Join Cluster Page

   
   Description of the illustration joinclus.gif
   
   

4. Select the radio button of the cluster that you want the application server instance to join.

5. Click Join. OracleAS adds the application server instance to the selected cluster and then displays a confirmation page.

6. Click OK to return to the Farm Home Page.

Repeat these steps for each additional standalone application server instance you want to join the cluster.

Note the following when adding application server instances to an OracleAS Cluster:

• When adding application server instances to an OracleAS Cluster, the order that you add instances to the cluster is significant. The first application server instance that joins the cluster is used as the base configuration for all additional application server instances that join the cluster. The base configuration includes all cluster-wide configuration information. It does not include instance-specific parameters.

• After the first application server instance joins the cluster, the base configuration overwrites existing cluster-wide configuration information for subsequent application server instances that join the cluster. Each additional application server instance, after the first, that joins the cluster inherits the base configuration specified for the first application server instance that joins the cluster.

• Before an application server instance joins a cluster, Application Server Console stops the instance. You can restart the application server instance by selecting the cluster link, selecting the appropriate instance from within the cluster, and then selecting the Start button.

• An application server instance is removed from the Standalone Instances area when the instance joins a cluster.

• To add multiple standalone application server instances to a cluster in a single operation, use the dcmctl joinCluster command.

• When an application server instance contains certain Oracle Application Server components, it is not clusterable. Use the dcmctl isClusterable command to test if an application server instance is clusterable. If the application server instance is not clusterable, then Application Server Console returns an error when you attempt to add the instance to a cluster.

• To be clusterable, all application server instances that are to be members of an OracleAS Cluster must be installed on the same operating system (this includes the same variant of UNIX).

4.2.2.2 Removing an Application Server Instance from an OracleAS Cluster

To remove an application server instance from a cluster, do the following:

1. Select the cluster in which you are interested on the Farm Home Page. This brings you to the cluster page.

2. Select the radio button of the application server instance to remove from the cluster and click Remove.

To remove multiple standalone application server instances, you need to repeat these steps multiple times.

Note the following when removing application server instances from an OracleAS Cluster:

• Before an application server instance leaves a cluster, Application Server Console stops the instance. After the operation completes, you restart the application server instance from the Standalone Instances area of the Farm Home Page.

• The dcmctl leaveCluster command removes one application server instance from the cluster at each invocation.

• When the last application server instance leaves a cluster, cluster-wide configuration information associated with the cluster is removed. The cluster is now empty and the base configuration is not set. Subsequently, Oracle Application Server uses the first application server instance that joins the cluster as the base configuration for all additional application server instances that join the cluster.

• You can remove an application server instance from the cluster at any time. The first instance to join a cluster does not have special properties. The base configuration is created from the first instance to join the cluster, but this instance can be removed from the cluster in the same manner as the other instances.

4.3.1.1 Testing an Instance With whichFarm and Leaving a Farm

To create a file-based repository you need to start with a standalone application server instance. A standalone application server instance is an instance that is not associated with a farm. To verify that the Oracle Application Server instance that you want to use as the repository host for a file-based repository is a Standalone Instance, issue the following command:

% dcmctl whichFarm

This command returns the following when an instance is not associated with any farm:

Standalone OracleAS instance

Table 4–2 shows sample output from whichFarm. When an instance is not a standalone instance whichFarm returns information showing that the instance is part of a farm.

% dcmctl whichFarm
Standalone OracleAS instance

% dcmctl whichFarm
Farm Name: .private.904M13.dcm.repository
Host Instance: 904M13.sc-sun.us.oracle.com
Host Name: sc-sun.us.oracle.com
Repository Type: Distributed File Based (host)
SSL In Use: false

% dcmctl whichFarm
Farm Name: .private.904M13.dcm.repository
Host Instance: 904M13.sc-sun.us.oracle.com
Host Name: sc-sun.us.oracle.com
Repository Type: Distributed File Based
SSL In Use: false

% dcmctl whichFarm
Host Instance: 904M12infra.sc-sun.us.oracle.com
Host Name: sc-sun.us.oracle.com
Repository Type:  Database (host)

% dcmctl whichFarm
Farm Name: tv1.us.oracle.com
Host Instance: 904M12infra.sc-sun.us.oracle.com
Host Name: sc-sun.us.oracle.com
Repository Type: Database

When the instance that you want to use with a file-based repository is part of an existing farm, you need to first leave the farm before you can initialize a file-based repository.

Use the leavefarm command to leave the farm as follows:

% dcmctl leaveFarm

After you leave the farm, whichFarm returns the following:

% dcmctl whichFarm
Standalone OracleAS instance

There are restrictions on leaving a farm using dcmctl leaveFarm, including the following:

• If you attempt to use dcmctl leaveFarm on an Oracle Application Server Infrastructure system, dcmctl reports an error unless the Infrastructure system is the only Oracle Application Server instance that is part of the farm.

• Running the dcmctl leaveFarm command stops all the Oracle Application Server components running on the Oracle Application Server instance.

• You cannot use leaveFarm on an Oracle Application Server Infrastructure system that serves as the repository for any Oracle Application Server instances other than itself. To run leavefarm on the Oracle Application Server Infrastructure, you must first go the Oracle Application Server instances and run leaveFarm on those instances.

4.3.1.2 Initializing the Repository Host Instance for a File-Based Repository

After selecting the Oracle Application Server instance to be the repository host for the file-based repository, do the following to create a farm and initialize the file-based repository on the repository host instance:

1. Issue the following command on the Oracle Application Server instance that is to be the repository host instance for the file-based repository:

   dcmctl getRepositoryid
   
   

2. Using the repository ID that you obtain, issue the command:

   dcmctl joinFarm -r <repositoryID>
   
   

   Where repositoryID is the value returned from the previous step. The dcmctl joinFarm command sets up the repository host instance and initializes the farm managed using a file-based repository; Oracle Application Server stores the farm’s configuration information in a file-based repository on the repository host instance.

   
   

   Note: If you create a farm using the dcmctl command and you are using Application Server Console to view the changes, you need to restart Application Server Console for the changes to be shown. Use the emctl start and stop commands to restart Application Server Console.

   
   

4.3.1.3 Joining a Farm Managed Using a File-Based Repository

After selecting the repository host instance for the file-based repository and initializing the file-based repository, do the following to add additional application server instances to the farm:

1. Obtain the repository ID on the repository host instance. To do this, issue the following command:

   dcmctl getRepositoryId
   
   

   To obtain the repository ID for the repository host instance, you can issue the getRepositoryid command on any system which is part of the farm you want to join (that is, if another instance uses the same repository host instance, you can use the dcmctl getRepositoryid command on that system).

2. On the application server instance that you want to add to the farm, do the following:

   dcmctl joinFarm -r <repositoryID>
   
   

   Where the repositoryID you specify is the value returned in step 1.

   
   

   Note: In this step, do not specify the repository ID of the instance you are on. Rather, use the repository ID for the farm’s repository host instance, or use the repository ID of any instance that is already part of the farm you want to join (this value is the same for all Oracle Application Server instances that use the same file-based repository). Also, if you are using Application Server Console to view the changes after executing the dcmctl joinFarm command, you need to restart Application Server Console for the changes to appear. Use the emctl start and stop commands to restart Application Server Console.

   
   
   
   

   See Also: Distributed Configuration Management Reference Guide for information on dcmctl commands

   
   

4.3.2.1 Managing Oracle Application Server Instances and Clusters With a File-Based Repository

Once a farm is set up that is managed using a file-based repository, you can use the Application Server Console or dcmctl commands to create and manage OracleAS Cluster within the farm, and you can configure standalone instances within the farm to join a cluster.

4.3.2.2 Availability Issues for OracleAS Clusters With a File-Based Repository

An important consideration for using OracleAS Clusters with a file-based repository is determining which Oracle Application Server instance is the repository host.

Consider the following when selecting the repository host for a file-based repository:

• When the repository host instance is temporarily unavailable, an OracleAS Cluster that uses a file-based repository is still able to run normally, but it cannot update any configuration information.

• Since the Oracle Application Server instance that is the repository host instance stores and manages the cluster related configuration information in its file system, the repository host instance should use mirrored or RAID disks. If the repository host instance uses disk mirroring, this improves the availability of the OracleAS Clusters.

• When the repository host instance is not available, read-only configuration operations are not affected on any Oracle Application Server instances that are running (the farm’s cluster-wide configuration information is distributed and managed through local Oracle Application Server Java Object Cache),

• When the repository host instance is not available, operations that attempt to change configuration information in the file-based repository will generate an error. These operations must be delayed until the repository host instance is available, or until the repository host instance is relocated to another application server instance within the farm.

4.3.2.3 Exporting and Importing Configuration Information With a File-Based Repository

Oracle Application Server provides commands to save a file-based repository and prevent it from being permanently lost, when the repository host instance goes down or its file system is damaged. Using the exportRepository command you can save the entire file-based repository. After saving the configuration information using the exportRepository command, using importRepository, you can restore the saved configuration information to the repository host instance, or to a different instance in the farm.

To export the repository from the repository host instance, do the following:

dcmctl exportRepository -file <file_name>

To import a saved file-based repository, on the system that is to be the repository host instance for the farm, do the following:

dcmctl importRepository -file <file_name>

ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=dcm-daemon

The file_name is a previously saved file that was created using the dcmctl exportRepository command. When the file-based repository is restored to a different Oracle Application Server instance, the instance where the importRepository command runs becomes the new repository host instance.

To specify that the Oracle Application Server instance that was the old repository host instance for a file-based repository is no longer the repository host instance, issue the following command:

dcmctl repositoryRelocated

4.3.2.4 Moving an Instance Between Repositories

If you have an Oracle Application Server instance joined to a farm that uses a file-based repository, you can move that instance to another repository whether it is a file-based or database-based repository. The steps to move to another repository type involve the steps to leave a farm and join another farm.

When an OracleAS instance leaves a farm, it essentially becomes a standalone instance. The instance’s DCM-managed configuration metadata in the repository is moved to the instance. Any archives for the instance are also deleted. However, connections to the Infrastructure database that may exist for other components (Oracle Application Server Single Sign-On, JAAS, and Oracle Internet Directory) are not removed.

To leave a farm, execute the following command at the OracleAS instance:

dcmctl leaveFarm

The following sections provide instructions to move an OracleAS instance from a file-based repository to other repositories:

• Moving to a Database-Based Repository

• Moving to Another File-Based Repository

4.3.2.5 Enabling SSL For Communication Between Instances That are Using a File-Based Repository

When instances in a farm use a file-based repository, you can configure DCM so that configuration information that is sent between instances uses SSL. This feature provides for the security of messages sent between all instances in the farm and prevents unauthorized instances from joining the farm.

This section describes the steps required to setup SSL and certificate-based security for instances that use a file-based repository. The overall steps are:

• Generating the Keystore

• Shutdown Oracle Application Server Processes on Each Instance

• Set Up the Keystore Information File on Each Instance in the Farm

• Enable SSL By Configuring dcmCache.xml

• Verify that Configuration Changes are Effected

• Start Each Instance in the Farm

• Adding a New Instance to a SSL-Enabled Farm

http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/keytool.html

$ORACLE_HOME/bin/emctl stop iasconsole
$ORACLE_HOME/dcm/bin/dcmctl stopproc

%ORACLE_HOME%\bin\emctl stop iasconsole
%ORACLE_HOME%\dcm\bin\dcmctl shutdown

dcmctl getrepositoryid

<useSSL>
  true | false
</useSSL>

<sslConfigFile>
  sslfile
</sslConfigFile>

dcmctl getstate

$ORACLE_HOME/opmn/bin/opmnctl startall
$ORACLE_HOME/bin/emctl start iasconsole

%ORACLE_HOME%\opmn\bin\opmnctl startall
%ORACLE_HOME%\bin\emctl start iasconsole

4.4.2.1 Creating or Deleting OC4J Instances on OracleAS Clusters

You can create a new OC4J instance on any application server instance within managed OracleAS Clusters and the OC4J instance will be propagated to all application server instances across the cluster.

To create an OC4J instance, do the following:

1. Navigate to any application server instance within the cluster.

2. Select the Create OC4J Instance button. This brings up the page that requests a name for the new instance. Provide a name in the field.

3. Click create.

4. The Oracle Application Server distributed configuration management system propagates the new OC4J instance across the cluster.

A new OC4J instance is created with the name you provided. This OC4J instance shows up on each application server instance page across the cluster, in the System Components section.

To delete an OC4J instance, select the radio button next to the OC4J instance you wish to delete, then click Delete. The Oracle Application Server Distributed Configuration Management system propagates the OC4J removal across the cluster.

4.4.2.2 Deploying Applications on OracleAS Clusters

Using OracleAS Clusters, when you deploy an application to one application server instance, the application is propagated to all application server instances across the cluster.

To deploy an application across a cluster, do the following:

1. Select the cluster you want to deploy the application to.

2. Select any application server instance from within the cluster.

3. Select an OC4J instance on the application server instance where you want to deploy the application.

4. Deploy the application to the OC4J instance using either Application Server Console or dcmctl commands.

5. The Oracle Application Server Distributed Configuration Management system then propagates the application across the cluster.

   
   

   See Also: Oracle Application Server Containers for J2EE User's Guide for complete information on deploying applications to an OC4J instance.

   
   

4.4.2.3 Configuring Web Application State Replication for OracleAS Clusters

To assure that Oracle Application Server maintains, across OracleAS Clusters, the state of stateful Web applications you need to configure state replication for the Web applications.

To configure state replication for stateful Web applications, do the following:

1. Select the Administration link on the OC4J Home Page.

2. Select Replication Properties in the Instance Properties column.

3. Scroll down to the Web Applications section. Figure 4-5 shows this section.

4. Select the Replicate session state checkbox.

   Optionally, you can provide the multicast host IP address and port number. If you do not provide the host and port for the multicast address, it defaults to host IP address 230.0.0.1 and port number 9127. The host IP address must be between 224.0.0.2 through 239.255.255.255. Do not use the same multicast address for both HTTP and EJB multicast addresses.

   
   

   Note: When choosing a multicast address, ensure that the address does not collide with the addresses listed in http://www.iana.org/assignments/multicast-addresses Also, if the low order 23 bits of an address is the same as the local network control block, 224.0.0.0 – 224.0.0.255, then a collision may occur. To avoid this provide an address that does not have the same bits in the lower 23 bits of the address as the addresses in this range.

   
   

5. Add the <distributable/> tag to all web.xml files in all Web applications. If the Web application is serializable, you must add this tag to the web.xml file.

   The following shows an example of this tag added to web.xml:

   <web-app>
     <distributable/>
     <servlet>
     ...
     </servlet>
   </web-app>
   

Figure 4-5 Web State Replication Configuration

Description of the illustration repli.gif

4.4.2.4 Configuring EJB Application State Replication for OracleAS Clusters

To create an EJB cluster, you specify the OC4J instances that are to be involved in the cluster, configure each of them with the same multicast address, username, and password, and deploy the EJB, which is to be clustered, to each of the nodes in the cluster.

Unlike HTTP clustering, EJBs involved in a cluster cannot be sub-grouped in an island. Instead, all EJBs within the cluster are in one group. Also, only session beans are clustered.

The state of all beans is replicated at the end of every method call to all nodes in the cluster using a multicast topic. Each node included in the EJB cluster is configured to use the same multicast address.

The concepts for understanding how EJB object state is replicated within a cluster are described in the Oracle Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide.

To configure EJB replication, you must do the following:

1. Select the Administration link on the OC4J Home Page.

2. Select Replication Properties in the Instance Properties column.

3. In the EJB Applications section, select the Replicate State checkbox.

   Figure 4-6 shows this section.

4. Provide the username and password, which is used to authenticate itself to other hosts in the cluster. If the username and password are different for other hosts in the cluster, they will fail to communicate. You can have multiple username and password combinations within a multicast address. Those with the same username/password combinations will be considered a unique cluster.

   Optionally, you can provide the multicast host IP address and port number. If you do not provide the host and port for the multicast address, it defaults to host IP address 230.0.0.1 and port number 9127. The host IP address must be between 224.0.0.2 through 239.255.255.255. Do not use the same multicast address for both HTTP and EJB multicast addresses.

   
   

   Note: When choosing a multicast address, ensure that the address does not collide with the addresses listed in http://www.iana.org/assignments/multicast-addresses Also, if the low order 23 bits of an address is the same as the local network control block, 224.0.0.0 – 224.0.0.255, then a collision may occur. To avoid this provide an address that does not have the same bits in the lower 23 bits of the address as the addresses in this range.

   
   

5. Configure the type of EJB replication within the orion-ejb-jar.xml file within the JAR file. See "Configuring Stateful Session Bean Replication for OracleAS Clusters" for full details. You can configure these within the orion-ejb-jar.xml file before deployment or add this through the Application Server Console screens after deployment. To add this after deployment, drill down to the JAR file from the application page.

Figure 4-6 EJB State Replication Configuration

Description of the illustration repejb.gif

4.4.2.5 Configuring Stateful Session Bean Replication for OracleAS Clusters

For stateful session beans, you may have you modify the orion-ejb-jar.xml file to add the state replication configuration. Since you configure the replication type for the stateful session bean within the bean deployment descriptor, each bean can use a different type of replication.

Stateful session beans require state to be replicated among nodes. In fact, stateful session beans must send all their state between the nodes, which can have a noticeable effect on performance. Thus, the following replication modes are available to you to decide on how to manage the performance cost of replication:

<session-deployment replication="EndOfCall" .../>

<session-deployment replication="VMTermination" .../>

4.4.3.1 Configuring OC4J Islands and OC4J Processes

To provide a redundant environment and to support high availability using OracleAS Clusters, you need to configure multiple OC4J processes within each OC4J instance.

Using OracleAS Clusters, state is replicated in OC4J islands with the same name within OC4J instances with the same name across the cluster. To assure high availability, with stateful applications, OC4J island names within an OC4J instance must be the same in corresponding OC4J instances across the cluster. It is the administrator’s responsibility to make sure that island names match where session state replication is needed in a cluster.

The number of OC4J processes on an OC4J instance within a cluster is an instance-specific parameter since different hosts running application server instances in the cluster could each have different capabilities, such as total system memory. Thus, it could be appropriate for cluster to contain application server instances that each run different numbers of OC4J processes within an OC4J instance.

To modify OC4J islands and the number of processes each OC4J island contains, do the following:

1. Select the Administration link on the OC4J Home Page of the application server instance of interest in the cluster.

2. Select Server Properties in the Instance Properties area.

3. Scroll down to the Multiple VM Configuration section. This section defines the islands and the number of OC4J processes that should be started on this application server instance in each island.

   Figure 4-7 displays the Multiple VM Configuration Islands section.

   Figure 4-7 OC4J instance Island and Number of Processes Configuration

   
   Description of the illustration island2.gif
   
   

4. Create any islands for this OC4J instance within the cluster by clicking Add Another Row. You can supply a name for each island within the Island ID field. You can designate how many OC4J processes should be started within each island by the number configured in the Number of Processes field.

4.4.3.2 Configuring Port Numbers and Command Line Options

Figure 4-8 shows the section where you can modify these ports and set command line options.

To modify OC4J ports or the command line options, do the following:

1. Select the Administration link on the OC4J Home Page of the application server instance of interest in the cluster.

2. Select Server Properties in the Instance Properties area.

3. Scroll down to the Multiple VM Configuration section. This section defines the ports and the command line options for OC4J and for the JVM that runs OC4J processes.

Figure 4-8 shows the Ports and Command line options areas on the Server Properties page.

Figure 4-8 OC4J Ports and Command Line Options Configuration

Description of the illustration oc4jport.gif

4.5.1.1 Load Balancing Overview

Using OracleAS Clusters, the Oracle HTTP Server module mod_oc4j load balances requests to OC4J processes. The Oracle HTTP Server, using mod_oc4j configuration options, supports different load balancing policies. By providing configurable load balancing policies, OracleAS Clusters can provide performance benefits along with failover and high availability for different types of systems, depending on the network topology and host machine capabilities.

By default, mod_oc4j uses weights to select a node to forward a request to. Each node has a default weight of 1 unless specified otherwise. A node’s weight is taken as a ratio compared to the weights of the other available nodes to define the number of requests the node should service compared to the other nodes in the cluster. Once a node is selected to service a particular request, by default, mod_oc4j uses the roundrobin policy to select OC4J processes on the node. If an incoming request belongs to an established session, the request is forwarded to the same node and the same OC4J process that started the session.

The OC4J load balancing policies do not take into account the number of OC4J processes running on a node when calculating which node to send a request to. Node selection is based on the configured weight for the node, and its availability. The number of OC4J processes to run is configured using Application Server Console.

4.5.1.2 Setting Load Balancing Options

To modify the mod_oc4j load balancing policy, Administrators use the Oc4jSelectMethod and Oc4jRoutingWeight configuration directives in the mod_oc4j.conf file.

To configure the mod_oc4j.conf file, using Application Server Console, select the HTTP_Server component in an application server instance. Then, select the Administration link and select the Advanced Server Properties link. On the Advanced Server Properties page, select the mod_oc4j.conf link. On the Edit mod_oc4j.conf page, within the <IfModule mod_oc4j.c> section, modify Oc4jSelectMethod and Oc4jRoutingWeight to select the desired load balancing option.

If you do not use Application Server Console, then edit mod_oc4j.conf and use the dcmctl command to propagate the changes to other mod_oc4j.conf files across the OracleAS Clusters as follows:

% dcmctl updateconfig -ct ohs
% opmnctl @cluster:<cluster_name> restartproc ias-component=HTTP_Server             process-type=HTTP_Server

The opmnctl restartproc command is required to restart all the Oracle HTTP Server instances in the OracleAS Clusters for the changes to take effect.

4.7.2.1 Opening Intranet Communication through the OracleAS Port Tunnel

Instead of opening multiple ports on the intranet firewall, you can use the OracleAS Port Tunnel. The Port Tunnel is a process that facilitates the communication between Oracle HTTP Server and OC4J, including the communication for DCM, OPMN and mod_oc4j, using a single port exposed on the intranet firewall. Thus, you do not have to expose several ports for communication for a single OC4J process. Instead, the Port Tunnel exposes a single port and can handle all of the port requirements for several OC4J processes.

All communication between the Oracle HTTP Servers and the Port Tunnel is encrypted using SSL.

Figure 4-10 shows how three Oracle HTTP Servers communicate with three OC4J processes through the Port Tunnel. Only a single port is exposed on the intranet firewall. The Oracle HTTP Servers exist on a single machine; the Port Tunnel and OC4J processes exist on a separate machine.

Figure 4-10 OracleAS Port Tunnel

Description of the illustration porttun.gif

However, if you have only a single process managing the communication between the Oracle HTTP Servers and the OC4J processes, you cannot guarantee high availability or failover. You can add multiple Port Tunnel processes, each listening on their own port, to manage the availability and the failover. We recommend that you use two Port Tunnel processes for each machine. You want to minimize the number of ports exposed on the intranet for security, but you also should provide for failover and availability.

Once the Port Tunnel processes are configured and initialized, then the Oracle HTTP Servers automatically balance the load among the port tunnel processes, just as they would among OC4J processes.

While you are risking exposure of a single port for each Port Tunnel process, the number of ports exposed using the Port Tunnel are much less than if you expose all of the ports needed for straight communication between Oracle HTTP Server and OC4J processes, as you can see in "Opening OracleAS Ports To Communicate Through Intranet" .

All of the details for configuring and initializing Port Tunnel processes are documented in the HTTP Security chapter in the Oracle Application Server 10g Security Guide.

4.7.2.2 Opening OracleAS Ports To Communicate Through Intranet

You can route between Oracle HTTP Servers and OC4J processes that are located on either side of an intranet firewall by exposing each of the OracleAS component ports through the firewall that are needed to communicate between the OC4J components.

The ports that should be opened on the firewall depend on the services that you are using. Table 4–6 describes the ports that you should open for each service.

At installation time, the Oracle Installer picks available ports and assigns them to relevant processes. You can see the assigned ports for all components by selecting Ports in the default home page using Application Server Console.

You can view all of the ports that are in use through Application Server Console. From the OracleAS Home Instance, select Ports at the top left corner of the page. Figure 4-11 shows all of the ports in use for this OracleAS instance, including all Oracle HTTP Server and OC4J instances. See the "Managing Ports" chapter in the Oracle Application Server 10g Administrator's Guide for more information on managing ports.

Figure 4-11 Ports used in OracleAS

Description of the illustration ports_em.gif