Skip Headers

Oracle9i Application Server Administrator's Guide
Release 2 (9.0.2)

Part Number A92171-02
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

14
Application Server Clustering

This chapter describes the concept of application server clustering and provides instructions on how to create and manage clusters.

It contains the following topics:

About Oracle9iAS Clustering

A cluster is a set of application server instances configured to act in concert to deliver greater scalability and availability than a single instance can provide. While a single application server instance can only leverage the operating resources of a single host, a cluster can span multiple hosts, distributing application execution over a greater number of CPUs. While a single application server instance is vulnerable to the failure of its host and operating system, a cluster continues to function despite the loss of an operating system or host, hiding any such failure from clients.

Clusters leverage the combined power and reliability of multiple application server instances while maintaining the simplicity of a single application server instance. For example, browser clients of applications running in a cluster interact with the application as if it were running on a single server. The client has no knowledge of whether the application is running on a single application server or in an application server cluster. From the management perspective, an application server administrator can perform operations on a cluster as if the administrator was interacting with a single server. An administrator can deploy an application to an individual server; the application is propagated automatically to all application server instances in the cluster.

The following sections discuss how application server clustering increases scalability, availability, and manageability.

Scalability

Oracle9iAS clustering enables you to scale your system beyond the limitations of a single application server instance on a single host. Figure 14-1 shows how a cluster unifies multiple application server instances spread over multiple hosts to collectively serve a single group of applications. In this way, clustering makes it possible to serve increasing numbers of concurrent users after the capacity of a single piece of hardware is exhausted.

Clients interact with the cluster as if they are interacting with a single application server. An administrator can add an application server instance to the cluster while the cluster is operating, increasing system capacity without incurring downtime.

Figure 14-1 Oracle9iAS Cluster

Text description of 9iasclus.gif follows.

Text description of the illustration 9iasclus.gif

Clients access the cluster through a load balancer, which hides the application server configuration. The load balancer can send requests to any application server instance in the cluster, as any instance can service any request. An administrator can raise the capacity of the system by introducing additional application server instances to the cluster, each of which derives its configuration from a shared Oracle9iAS Metadata Repository.

Availability

Oracle9iAS clustering enables you to achieve a higher level of system availability than is possible with only a single application server instance. An application running on a single instance of an application server is dependent on the health of the operating system and host on which the server is running. In this case, the host poses as a single point of failure because if the host goes down, the application becomes unavailable.

An application server cluster eliminates the single point of failure by introducing redundancy and failover into the system. Any application server instance in the cluster can service any client request, and the failure of any single instance or host does not bring down the system. Client session state is replicated throughout the cluster, thereby protecting against the loss of session state in case of process failure. The administrator can configure the extent of session state replication.

Figure 14-2 Application Server Instance Failure in a Cluster

Text description of clu_fail.gif follows.

Text description of the illustration clu_fail.gif

Figure 14-2 illustrates how application server clusters enable higher availability by providing redundancy and backup and eliminating a single point of failure. Clients access the cluster through a load balancer which can send requests to any application server instance in the cluster. In the case that an application server instance becomes unavailable, the load balancer can continue forwarding requests to the remaining application server instances, as any instance can service any request.

Manageability

Figure 14-3 demonstrates how managed clustering uses Oracle Enterprise Manager. While any clustered system requires all instances to be similarly configured in order to function properly, Oracle9iAS managed clustered instances synchronize their configurations automatically, relieving the administrator of the responsibility to manually update each individual instance. Using Oracle Enterprise Manager, the administrator can make configuration changes as if on a single application server instance. Applicable changes are propagated automatically to all instances in the cluster.

Oracle9iAS cluster management simplifies the tasks of creating and administering clusters and reduces the chance of human error corrupting the system. An administrator creates a cluster in a single management operation. Then, the administrator adds the initial application server instance to the cluster to define the base configuration for the cluster. Any additional instances automatically inherit this base configuration.

Figure 14-3 Oracle Enterprise Manager Manages a Cluster

Text description of clu_oem.gif follows.

Text description of the illustration clu_oem.gif

Component Support

Oracle9iAS clustering applies to the synchronization and management of Oracle HTTP Server (OHS) and Oracle9iAS Containers for J2EE (OC4J) components.

Other Oracle9iAS components, such as Oracle9iAS Web Cache, may support a component-specific clustering model or cluster-like functionality. This is separate from application server clustering and is not discussed in this chapter. Please see the component documentation for further details. For more information about Oracle9iAS Web Cache clustering, see Oracle9iAS Web Cache Administration and Deployment Guide.

Non-Managed Clustering

This chapter discusses managed application server clusters that offer scalability, availability, and manageability. Managed application server clusters require a metadata repository to stored shared configuration data.

Oracle9iAS also enables you to create non-managed application server clusters that do not require a metadata repository and therefore have no database dependency. Non-managed clusters provide scalability and availability, but not manageability. In a non-managed cluster, it is your responsibility to synchronize the configuration of the application server instances. Figure 14-4 illustrates that a non-managed cluster does not require a database, but you have to configure each application server instance yourself.

Figure 14-4 Non-Managed Clustering

Text description of cluste15.gif follows.

Text description of the illustration cluste15.gif

If you want to cluster J2EE applications and do not want to use a metadata repository, there are two types of non-managed clusters that you can use:

Non-Managed Application Server Cluster

Create a non-managed application server cluster if you want to use both OHS and OC4J. In a non-managed application server cluster, mod_oc4j will load-balance requests to all OC4J instances in the cluster.

For more information on non-managed application server clustering, see the Oracle9iAS page on OTN at http://otn.oracle.com/products/ias.

OC4J-Only Cluster

Create an OC4J-only cluster if you want to use the standalone OC4J that is available for download from OTN. In an OC4J-only cluster, the Java load balancer load-balances requests to all OC4J instances in the cluster. An OC4J-only cluster has a lightweight disk footprint, but the Java load balancer can be a single point of failure.

For more information on OC4J-only clustering, see the OC4J page on OTN at http://otn.oracle.com/tech/java/oc4j.

Architecture

A cluster coordinates several application server instances and its components. The roles of the components included in the cluster are described in the following sections:

Figure 14-5 shows the architecture of a farm and a cluster. There are three application server instances, where each instance shares the same Oracle9iAS Metadata Repository within an infrastructure. Thus, all three application server instances are part of the same farm.

Application server instances 1 and 2 are involved in a cluster together. In front of the cluster is a front-end load balancer. Included within each application server instance are its manageability features--Oracle Process Management and Notification (OPMN) and Dynamic Configuration Management (DCM)--and its installed components--Oracle HTTP Server and Oracle9iAS Containers for J2EE (OC4J).

Figure 14-5 Oracle9iAS Cluster Architecture

Text description of dcma.gif follows.

Text description of the illustration dcma.gif

Front-End Load Balancer

After you have created a cluster, you can add a load balancer in front of all application server instances in the cluster, which provides availability and scalability for the application server instances.

We recommend that you purchase and install a hardware load balancer for the best performance. Alternatively, you could use Web Cache as a load balancer, which could be a single point of failure.

See Also:

Oracle9iAS Web Cache Administration and Deployment Guide for instructions on how to set up Oracle9iAS Web Cache as your load balancer for your cluster

Metadata Repository in the Infrastructure

When you install Oracle9iAS, you have the option of installing the Oracle9iAS Infrastructure. An Oracle9iAS Infrastructure provides Oracle Internet Directory, Oracle9iAS Single Sign-On, and the Oracle9iAS Metadata Repository. The metadata repository is an Oracle9i database that is used to store the application server instance information and configuration. The application server instance tables are created in the metadata repository. Multiple application server instances can share the metadata repository of the infrastructure.

Application server instances associate with an infrastructure either during installation or through the Oracle Enterprise Manager after installation.

Farm

A farm is a group of multiple application server instances that associate with the same metadata repository. The application server instances that belong to a farm can be installed anywhere on the network.

Cluster

A cluster is a logical group of application server instances that belong to the same farm. Each application server instance may be part of only one cluster. If an instance is part of a cluster, then all of its configured components are implicitly part of that cluster. Each application server instance can only be configured with Oracle HTTP Server and OC4J components to be contained in a cluster. A cluster can include zero or more application server instances.

All application server instances involved in the cluster have the same "cluster-wide" configuration. If you modify the configuration on one application server instance, then the modification is automatically propagated across all instances in the cluster.


Note:

"Instance-specific" configuration parameter modifications are not propagated. For a description of these parameters, see "Cluster Configuration".


Application Server Instance

An application server instance consists of a single Oracle HTTP Server and one or more OC4J instances. It is a single installation in one Oracle home. If you have multiple application servers on a single host, each is installed into its own Oracle home and uses separate port numbers.

To manage clusters from Oracle Enterprise Manager, the application server uses a metadata repository for storing its tables and configuration. Each application server instance in the cluster has the same base configuration. The base configuration contains the cluster-wide parameters and excludes instance-specific configuration. If you modify any part of the cluster-wide configuration, the modifications are propagated to all other application server instances in the cluster. If you modify an instance-specific parameter, it is not propagated, as it is only applicable to the specified application server instance. See "Cluster Configuration" for a listing of the instance-specific parameters. The cluster-wide parameters are all other parameters.

In order for each application server instance to be a part of a cluster, the following must be true:

To cluster application server instances, do the following:

  1. Create an empty cluster in the farm. The only requirement for creating a cluster is a unique name.

  2. Add the first application server instance to the cluster. This application server instance must already belong to the farm. The configuration of this first instance is used as the base configuration for all additional application server instances. The base configuration overwrites any existing configuration of subsequent application server instances that join the cluster.

    The base configuration includes the cluster-wide properties. It does not include instance-specific properties. See "Cluster Configuration" for more information about instance-specific properties.

  3. Add other application server instances--even if they exist on another host--to the cluster. Each additional application server instance inherits the base configuration.

  4. If you add application server instances into a cluster, set the base configuration, then remove all application server instances from a cluster, the cluster is then empty and the base configuration is not set. Thus, the next application server instance that you add becomes the source of the base configuration.

  5. When added to or removed from the cluster, the application server instance is stopped. You can restart the added application server instances within the context of the cluster. You can restart the removed application server instance from the standalone instances section in the farm.

Once grouped in the same cluster, these application server instances have the following properties:

Management Features

Each application server instance contains management features that manage and monitor the application server instance, its components, and how it performs in a cluster. The management features do the following:

All of these activities are provided by the following management features:

Distributed Configuration Management (DCM)

Distributed Configuration Management (DCM) manages configuration by propagating the cluster-wide configuration for the application server instances and its components. When you add application server instances to the cluster, it is the DCM component that automatically replicates the base configuration to all instances in the cluster. When you modify the cluster-wide configuration, DCM propagates the changes to all application server instances in the cluster.

DCM is a management feature in each application server instance. However, it is not a process that exists at all times. DCM is invoked either by Oracle Enterprise Manager or manually by a user through dcmctl to do the following:

You can also manually execute the DCM command-line tool--dcmctl--to perform these duties. However, there are restrictions on how to use dcmctl, which are as follows:

Oracle Process Management and Notification (OPMN)

Oracle Process Management and Notification (OPMN) manages Oracle HTTP Server and OC4J processes within an application server instance. It channels all events from different components to all components interested in receiving them.

OPMN consists of the following two components:

Component Instances

The application server is installed with several different types of components. However, to be involved in a cluster, each application server instance can only contain one Oracle HTTP Server and one or more Oracle9iAS Containers for J2EE (OC4J) components. As noted above, Oracle9iAS Web Cache can be installed, but it will not be clustered within this environment. Oracle9iAS Web Cache has its own clustering model.


Note:

Other application server components, such as Oracle9iAS Web Cache, can be clustered independently from application server clusters. It is not recommended that a component be part of an independent cluster as well as an application server instance cluster. For information on components that can be clustered independently, see each component administrator's guide.


Oracle HTTP Server

The Oracle HTTP Server is a Web server for the application server instance. It serves client requests. In addition, it forwards OC4J requests to an active OC4J process. Because of this, Oracle HTTP Server is a natural load balancer for OC4J instances. When you have a single application server instance, the Oracle HTTP Server handles the incoming requests for all of the OC4J processes in this sole application server instance. However, in a clustered environment, the Oracle HTTP Server is updated with information about existing OC4J processes by OPMN in all application server instances in the cluster. Thus, the Oracle HTTP Server can do the following:

OPMN starts (or restarts) each OC4J process. OPMN notifies each Oracle HTTP Server in the cluster of each OC4J process. Thus, any Oracle HTTP Server can load balance incoming requests among any OC4J process in the cluster.

Figure 14-6 demonstrates how the two Oracle HTTP Servers in the cluster know about both of the OC4J processes. It does not matter that one OC4J process exists in a separate application server instance, which can be installed on a separate host. The OPMN components in each application server instance notifies both Oracle HTTP Servers of the OC4J processes when they were initialized.

Figure 14-6 OC4J Processes in Islands

Text description of oc4jis.gif follows.

Text description of the illustration oc4jis.gif

OC4J Instance

The OC4J instance is the entity to which J2EE applications are deployed and configured. It defines how many OC4J processes exist within the application server and the configuration for these OC4J processes. The OC4J process is what executes the J2EE applications for the OC4J instance.

The OC4J instance has the following features:

Within the application sever instance, you can configure multiple OC4J instances, each with its own number of OC4J processes. The advantage of this is for configuration management and application deployment for separate OC4J processes in your cluster.

Figure 14-7 demonstrates the OC4J_home default OC4J instance. In the context of a cluster, the OC4J instance configuration is part of the cluster-wide configuration. Thus, the OC4J_home instance, configured on the first application instance, is replicated on all other application server instances.

The number of processes in each OC4J_home instance is an instance-specific parameter, so you must configure the OC4J_home instance separately on each application server instance for the number of OC4J processes that exist on each application server instance. Figure 14-7 shows that the OC4J_home instance on application server instance 1 contains two OC4J processes; the OC4J_home instance on application server instance 2 contains only one OC4J process. Each OC4J instance defaults to having one OC4J process.

Figure 14-7 OC4J Processes in a Cluster

Text description of oc4jproc.gif follows.

Text description of the illustration oc4jproc.gif

OC4J Process

The OC4J process is the JVM process that executes J2EE applications. Each OC4J process is contained in an OC4J instance and inherits its configuration from the OC4J instance. All applications deployed to an OC4J instance are deployed to all OC4J processes in the OC4J instance.

You can define one or more OC4J processes within an OC4J instance, so that J2EE requests can be load balanced and have failover capabilities.

The configuration for the number of OC4J processes is instance-specific. Thus, you must configure each OC4J instance in each application server instance with the number of OC4J processes you want to start up for that OC4J instance. The default is one OC4J process.

Each host that you install the application server instances on has different capabilities. To maximize the hardware capabilities, properly configure the number of OC4J processes in each OC4J instance that will use these capabilities. For example, you can configure a single OC4J process on host A and five OC4J processes on host B.

When you define multiple OC4J processes, you enable the following:

Replicating Application State

The OC4J processes involved in the cluster can replicate application state to all OC4J processes. Once you configure replication, OC4J handles the propagation of the application state for you.

If one OC4J process fails, then another OC4J process--which has had the application state replicated to it--takes over the application request. When an OC4J process fails during a stateful request, the Oracle HTTP Server forwards the request in the following order:

  1. If another OC4J process is active within the same application server instance, Oracle HTTP Server forwards the request to this process.

  2. Otherwise, Oracle HTTP Server forwards the state request to an OC4J process in another application server instance in the cluster.

There are two types of failure that you want to protect against: software failure and hardware failure. Table 14-1 lists their differences.

Table 14-1 Failure Types
Failure Types Avoidance Technique

Software failure occurs when the OC4J process fails.

Multiple OC4J processes in the same OC4J instance. When one OC4J process fails, the Oracle HTTP Server forwards the request to another OC4J process in the same OC4J instance.

Hardware failure occurs when the host goes down.

OC4J processes in the cluster configured on separate hosts. When the first host dies, the OC4J process on another host can take over the request. This requires that you have installed an application server instance on another host, which is a part of the cluster, and the OC4J instance has at least one OC4J process.

Islands

An island is a logical grouping of OC4J processes that allows you to determine which OC4J processes replicate state.

In each OC4J instance, you can have more than one OC4J process. If we consider state replication in a situation where all OC4J processes tried to replicate state, then the CPU load can increase significantly. To avoid a performance degradation, the OC4J instance enables you to subgroup your OC4J processes. The subgroup is called an island.

To ensure that the CPU load is partitioned among the processes, the OC4J processes of an OC4J instance can be partitioned into islands. The state for application requests is replicated only to OC4J processes that are grouped within the same island. All applications are still deployed to all OC4J processes in the OC4J instance. The only difference is that the state for these applications is confined to only a subset of these OC4J processes.

The island configuration is instance-specific. The name of the island must be identical in each OC4J instance where you want the island to exist. When you configure the number of OC4J processes on each application server instance, you can also subgroup them into separate islands. The OC4J processes are grouped across application server instances by the name of the island. Thus, the application state is replicated to all OC4J processes within the island of the same name spanning application server instances.

The grouping of OC4J processes for the state replication is different for EJB applications than for Web applications. Web applications replicate state within the island sub-grouping. EJB applications replicate state between all OC4J processes in the OC4J instance and do not use the island sub-grouping.

Figure 14-8 demonstrates OC4J processes in islands within the cluster. Two islands are configured in the OC4J_home instance: default-island and second-island. One OC4J process is configured in each island on each application server instance. The OC4J islands, designated within the shaded area, span application server instances.

Figure 14-8 Island Description

Text description of island.gif follows.

Text description of the illustration island.gif

J2EE Applications

J2EE applications are deployed in all cases to the OC4J instance--whether the application server instance is included in a cluster or not. However, when the application is deployed to an OC4J instance that is in a cluster, certain configuration details must be accomplished:

Oracle Enterprise Manager Configuration Tree

Oracle Enterprise Manager uses a hierarchical approach for configuring and managing your cluster.

Figure 14-9 demonstrates the configuration tree for a cluster.

Instance-Specific Parameters

The following parameters are not replicated across the cluster.

Examples

No matter how many application server instances you add within the cluster, the cluster-wide configuration is replicated within the cluster. You control protecting against software and hardware failure with how you configure island and OC4J processes, which are instance-specific parameters.

Software Failure

Suppose you configure more than one OC4J process within your OC4J instance, then if one of these processes fails, another process can take over the work load of the failed process. Figure 14-10 shows application server instance 1, which is involved in the cluster. Within this application server instance, there are two OC4J processes defined in the default-island in the OC4J_home instance. If the first OC4J process fails, the other can pick up the work load.

Both of these OC4J processes are on the same host; so, if the host goes down, both OC4J processes fail and the client cannot continue processing.

Figure 14-10 Software Failure Demonstration

Text description of ex1.gif follows.

Text description of the illustration ex1.gif

Hardware Failure

To protect against hardware failure, you must configure OC4J processes in the same OC4J instance across hosts. Figure 14-11 shows OC4J_home instance in application server instance 1 and 2. Within the default-island, two OC4J processes are configured on application server instance 1 and three are configured in application server instance 2. If a client is interacting with one of the OC4J processes in application server 1, which terminates abnormally, the client is redirected automatically to one of the OC4J processes in the default-island in application server 2. Thus, your client is protected against hardware failure.

Figure 14-11 Hardware Failure Demonstration

Text description of ex2.gif follows.

Text description of the illustration ex2.gif

State Replication

If the client is a stateful application, then the state is replicated only within the same island. In the previous example, there is only a single island, so the state of the application would be preserved.

To enhance your performance, you want to divide up state replication among islands. However, you must also protect for hardware and software failure within these islands.

The optimal method of protecting against software and hardware failure, while maintaining state with the least number of OC4J processes, is to configure at least one OC4J process on more than one host in the same island. For example, if you have application server instance 1 and 2, within the OC4J_home instance, you configure one OC4J process in the default-island on each application server instance. Thus, you are protected against hardware and software failure and your client maintains state if either failure occurs.

As demand increases, you will configure more OC4J processes. To guard against a performance slowdown, separate your OC4J processes into separate islands. For example, if fifteen OC4J processes utilize the hardware efficiently on the two hosts and serve the client demand appropriately, then you could divide these processes into at least two islands. The following shows the fifteen OC4J processes grouped into three islands:

Island Names Application Server 1 Application Server 2

default-island

two

three

second-island

two

three

third-island

three

two

Cluster Configuration

The following sections describe how to create a cluster and add application server instances to this cluster using Oracle Enterprise Manager:

Managing an Oracle9iAS Cluster

From the Oracle9iAS Farm Home Page, you can view a list of all the application server instances that are part of the farm. These application server instances can be clustered.

For more information, see the following topics:

Associating an Instance with an Oracle9iAS Infrastructure

If you have not already done so during installation, you can associate an application server instance with an infrastructure, as follows:

  1. Navigate to the Oracle9iAS Instance Home Page.

  2. Scroll down to the Administration section and click Use Infrastructure.

  3. Follow the instructions provided by the Use Infrastructure wizard.

    See Also:

    "Associating an Instance with an Infrastructure (Joining a Farm)" for more information

Creating the Cluster

Use the Oracle9iAS Farm Home Page to create a new cluster. The Farm Home Page appears when you open the Oracle Enterprise Manager Web site on a host computer that contains an application server instance that is part of a farm.

To create a cluster:

  1. Navigate to the Farm Home Page.

    Figure 14-12 shows the Farm Home Page with a single application server instance.

    Figure 14-12 Oracle9iAS Farm Home Page

    Text description of farm_clu.gif follows.

    Text description of the illustration farm_clu.gif

  2. Click Create Cluster.

    Oracle9iAS displays the Create Cluster page. Figure 14-13 shows this page.

    Figure 14-13 Create Cluster Page

    Text description of creclus.gif follows.

    Text description of the illustration creclus.gif

  3. Enter a name for the cluster and click Create.

    A confirmation message appears.

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

    The new cluster is listed in the Clusters table.

Managing the Cluster

Figure 14-14 shows the Farm Home Page after a cluster is created.

Figure 14-14 Oracle9iAS Farm Page

Text description of farm_clu.gif follows.

Text description of the illustration farm_clu.gif

Table 14-2 lists the options available on the Farm Home Page.

Table 14-2 Oracle9iAS Farm Page Options
If you want to... Then...

Start all application server instances in a cluster

Select the radio button next to the cluster and click Start.

Restart all application server instances in a cluster

Select the radio button next to the cluster and click Restart.

Stop all application server instances in a cluster

Select the radio button next to the cluster and click Stop.

Delete a cluster, including any application server instances still included in the cluster.

Select the radio button next to the cluster and click Delete.

Managing Application Server Instances in a Cluster

The following sections discuss how you can manage application server instances in a cluster:

Adding an Application Server Instance to a Cluster

To add an application server instance to a cluster:

  1. Navigate to the Farm Home Page, which is shown in Figure 14-14.

  2. Select the radio button of the application server instance in the Standalone Instances section that you want to add to a cluster. In Figure 14-14, the radio button by the inst1 application server instance is selected.

  3. Click Join Cluster. Figure 14-15 shows the Join Cluster page.

    Figure 14-15 Join Cluster Page

    Text description of join_clu.gif follows.

    Text description of the illustration join_clu.gif

  4. Select the radio button of the cluster that you want the application server instance to join. In Figure 14-15, the test cluster is selected.

  5. Click Join.

    Oracle9iAS 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. This moves the application server instance from the standalone instances into the cluster. In doing so, the instance is stopped. You can restart the instance within the context of the cluster.

You will notice that the application server instance disappears from the Standalone Instances section. Also, the number of application server instances displayed for the cluster increases by one. If you display the cluster, you will see that the application server instance was moved into the cluster. Thus, the Standalone Instances section displays only those application server instances that are not a part of any cluster.

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

Removing an Application Server Instance from a Cluster

To remove the application server instance from the 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.

When you add or remove an application server instance to or from a cluster, the application server instance is stopped.

OC4J Instance Configuration

The Oracle9iAS Containers for J2EE User's Guide describes how to configure an OC4J Instance. The following sections describe how to configure your OC4J Instance for clustering:

Configuring Islands and Processes

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

  1. Scroll down to the Administration section of the OC4J Home Page.

  2. Select Server Properties in the Instance Properties column.

  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 14-16 displays the Multiple VM Configuration section.

    Figure 14-16 Island and Process Configuration

    Text description of cluster1.gif follows.

    Text description of the illustration cluster1.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.

Configuring Web Application State Replication

Configuring state replication for stateful applications is different for Web applications than for EJB applications. To configure state replication for Web applications, do the following:

  1. Scroll down to the Administration section of the OC4J Home Page.

  2. Select Replication Properties in the Instance Properties column.

  3. Scroll down to the Web Applications section. Figure 14-17 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.

    Figure 14-17 Web State Replication Configuration

    Text description of rep.gif follows.

    Text description of the illustration rep.gif

  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>
    

Configuring EJB Application State Replication

The concepts for understanding how EJB object state is replicated within a cluster are described in the Oracle9iAS Containers for J2EE Enterprise JavaBeans Developer's Guide and Reference. To configure EJB replication, you must do the following:

  1. Scroll down to the Administration section of the OC4J Home Page.

  2. Select Replication Properties in the Instance Properties column.

  3. Scroll down to the EJB Applications section. Figure 14-18 shows this section.

  4. Select the Replicate State checkbox.

  5. 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.

    Figure 14-18 EJB State Replication Configuration

    Text description of rep1.gif follows.

    Text description of the illustration rep1.gif

  6. Configure the type of EJB replication within the orion-ejb-jar.xml file within the JAR file. The type of configuration is dependent on the type of the bean. See "EJB Replication Configuration in the Application JAR" for full details. You can configure these within the orion-ejb-jar.xml file before deployment or add this through the Oracle Enterprise Manager screens after deployment. If you add this after deployment, drill down to the JAR file from the application page.

EJB Replication Configuration in the Application JAR

Modify the orion-ejb-jar.xml file to add the configuration for stateful session beans and entity beans required for state replication. The following sections offer more details:

Stateful Session Bean Replication Configuration

You configure the replication type for the stateful session bean within the bean deployment descriptor. Thus, each bean can use a different type of replication.

Entity Bean Replication Configuration

Configure the clustering for the entity bean within its bean deployment descriptor.

Modify the orion-ejb-jar.xml file to add the clustering-schema attribute to the <entity-deployment> tag, as follows:

<entity-deployment ... clustering-schema="asynchronous-cache" .../>

Configuring Single Sign-On

In order to participate in Single Sign-On functionality, all Oracle HTTP Server instances in a cluster must have an identical Single Sign-On registration.

As with all cluster-wide configuration, the Single Sign-On configuration is propagated among all Oracle HTTP server instances in the cluster. However, the initial configuration is manually configured and propagated. On one of the application server instances, define the configuration with the ossoreg.jar tool. Then, DCM propagates the configuration to all other Oracle HTTP Servers in the cluster.

If you do not use a network load balancer, then the Single Sign-on configuration must originate with whatever you use as the incoming load balancer--Web Cache, Oracle HTTP Server, and so on.

See Also:

Oracle9iAS Single Sign-On Administrator's Guide

To configure a cluster for Single Sign-On, execute the ossoreg.jar command against one of the application server instances in the cluster. This tool registers the Single Sign-On server and the redirect URLs with all Oracle HTTP Servers in the cluster.

Run the ossoreg.jar command with all of the options as follows, substituting information for the italicized portions of the parameter values.

The values are described fully in Table 14-3.

Table 14-3 SSORegistrar Parameter Values  
Parameter Value

-oracle_home_path <path>

Absolute path to the Oracle home of the application server instance, where you are invoking this tool.

-host <sso_host>

Database host name where Single Sign-On server resides.

-port <sso_port>

Database port where Single Sign-On server resides.

-sid <sso_SID>

Database SID where Single Sign-On server resides.

-site_name <site>

Hostname and port (host:port) of the Web site. You can provide a logical name; however, the hostname and port are helpful to the administrator.

-success_url <URL>

Redirect URL (host.domain:port) for the routine that establishes the partner application session and session cookies. Use HTTP or HTTPS.

-logout_url <URL>

Redirect URL (host.domain:port) for the routine that logs out of the application session.

-cancel_url <URL>

Redirect URL (host.domain:port) to which users are redirected when they cancel authentication.

-home_url <URL>

Redirect URL (host.domain:port) for home. This should be a public host.domain and port: HTTP or HTTPS..

-admin_id <name>

(Optional) User name of the mod_osso administrator. This shows up in the Single Sign-On tool as contact information.

-admin_info <text>

(Optional) Additional information about the mod_osso administrator, such as e-mail address. This shows up in the Single Sign-On tool as contact information.

The SSORegistrar tool establishes all information necessary to facilitate secure communication between the Oracle HTTP Servers in the cluster and the Single Sign-On server.

When using Single Sign-On with the Oracle HTTP Servers in the cluster, the KeepAlive directive must be set to OFF. The reason is because the Oracle HTTP Servers are behind a network load balancer. Thus, if the KeepAlive directive is set to ON, then the network load balancer maintains state with the Oracle HTTP Server for the same connection, which results in an HTTP 503 error. Modify the KeepAlive directive in the Oracle HTTP Server configuration. This directive is located in the httpd.conf file of the Oracle HTTP Server.

Configuring Instance-Specific Parameters

The manageability feature of the cluster causes the configuration to be replicated across all application server instances in the cluster, which is defined as a cluster-wide configuration. However, there are certain parameters where it is necessary to configure them separately on each instance. These parameters are referred to as instance-specific.

The following parameters are instance-specific parameters, which are not replicated across the cluster. You must modify these parameters on each application server instance.

OC4J Instance-Specific Parameters

The following are instance-specific parameters within each OC4J instance:

All other parameters are cluster-wide parameters, which are replicated across the cluster.

Figure 14-19 shows the section where you can modify these parameters. These sections are located in the Server Properties off the OC4J Home Page.

Figure 14-19 Non-Replicated Configuration

Text description of cluster1.gif follows.

Text description of the illustration cluster1.gif

In the Command Line Options section, you can add debugging options to the OC4J Options line. For more information about debugging in the OC4J process, see http://otn.oracle.com/tech/java/oc4j.

Oracle HTTP Server Instance-Specific Parameters

The following are instance-specific parameters in the Oracle HTTP Server.

You can modify the HTTP Server ports and listening addresses on the Server Properties Page, which can be accessed from the HTTP Server Home Page. You can modify the virtual host information by selecting a virtual host from the Virtual Hosts section on the HTTP Server Home Page.


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index