| Oracle® Collaboration Suite High Availability Guide 10gRelease 1 (10.1.2) for Windows or UNIX Part Number B25481-03 |
|
|
View PDF |
| Oracle® Collaboration Suite High Availability Guide 10gRelease 1 (10.1.2) for Windows or UNIX Part Number B25481-03 |
|
|
View PDF |
This chapter gives an overview of the high availability configurations of Oracle Collaboration Suite. It explains the role of Oracle Real Application Clusters and Oracle Collaboration Suite high availability architectures.
An Oracle Collaboration Suite cluster is a set of Oracle Collaboration Suite nodes configured to act synchronously to deliver greater scalability and availability than a single node can provide. While a single Oracle Collaboration Suite node can only leverage the operating resources of a single host, a cluster can span multiple hosts and distribute application execution over a greater number of CPUs. While a single Oracle Collaboration Suite node 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, by hiding any such failure from clients.
Clusters leverage the combined power and reliability of multiple Oracle Collaboration Suite nodes while maintaining the simplicity of a single Oracle Collaboration Suite node. For example, browser clients of applications running in a cluster interact with the applications as if the applications were running on a single server. With appropriate front-end load balancing, any node in an Oracle Collaboration Suite cluster can serve client requests. This simplifies configuration and deployment across multiple nodes and enables fault tolerance among clustered nodes.
What are Oracle Real Application Clusters?
Oracle Real Application Clusters allows the Oracle database to run any packaged or custom application unchanged across a set of clustered servers. This capability provides the highest levels of availability and the most flexible scalability. If a clustered server fails, then the Oracle database will continue running on the surviving servers. When more processing power is needed, another server can be added without interrupting data access for users.
Oracle Real Application Clusters enables multiple instances that are linked by an interconnect to share access to an Oracle database. In a Oracle Real Application Clusters environment, the Oracle database runs on two or more systems in a cluster while concurrently accessing a single shared database. The result is a single database system that spans multiple hardware systems yet appears as a single unified database system to the application. This enables Oracle Real Application Clusters to provide high availability, scalability, and redundancy during failures within the cluster. Oracle Real Application Clusters accommodates all system types, from read-only data warehouse (DSS) systems to update-intensive online transaction processing (OLTP) systems.
High availability configurations have redundant hardware and software that maintain continuous operations by avoiding single points-of-failure. To accomplish this, Oracle Clusterware is installed as part of the Oracle Real Application Clusters installation process. Oracle Clusterware is a portable solution that is integrated and designed specifically for the Oracle database. In a Oracle Real Application Clusters environment, Oracle Clusterware monitors all Oracle components (such as instances and listeners). If a failure occurs, then Oracle Clusterware will automatically attempt to restart the failed component. Other non-Oracle processes can also be managed by Oracle Clusterware. During outages, Oracle Clusterware relocates the processing performed by the inoperative component to a backup component. For example, if a node in the cluster fails, Oracle Clusterware will cause client processes running on the failed node to reconnect and resume running on a surviving node.
Oracle Clusterware requires two files, the Oracle Cluster Registry (OCR) and the voting disk. To avoid single points-of-failure, these Oracle Clusterware files must be on shared storage accessible to each RAC node. Oracle Clusterware also enables you to replace a damaged copy of the OCR online. The recovery processes of Oracle Clusterware remaster resources, recover partial or failed transactions, and rapidly restore the system.
Oracle Real Application Clusters provides the following benefits:
Ability to tolerate and quickly recover from computer and instance failures
Fast, automatic, and intelligent connection and service relocation and failover
Rolling patch upgrades for subsequent qualified patch releases
Rolling release upgrades of Oracle Clusterware
Load balancing advisory
Run-time connection load balancing
Flexibility to scale up processing capacity using commodity hardware without downtime or changes to the application
Comprehensive manageability integrating database and cluster features
Oracle Real Application Clusters Configuration for Oracle Collaboration Suite
The Oracle Real Application Clusters configuration for Oracle Collaboration Suite consists of Oracle Collaboration Suite Database deployed on a cluster with two or more nodes. Each Oracle Collaboration Suite Database node has a local copy of the Oracle Collaboration Suite software installed. A single Oracle Collaboration Suite Database is shared by all the nodes.
Oracle database instances exist on each node and concurrently open the database for read or write operations. All Oracle Collaboration Suite database-related processes as well as the database listener on all the nodes use the same network port numbers for any communication. Thus each node is equivalent to another in terms of configuration and is active concurrently with other nodes.
Oracle Collaboration Suite Applications requests for Oracle Collaboration Suite Database services are equally met from all the nodes.
Oracle Real Application Clusters configuration for Oracle Collaboration Suite Database does not require load balancer. Oracle Net manages all database traffic and the traffic balanced across the nodes using Oracle Net connect descriptors that map to a single database service that contains multiple addresses in its address list. Oracle Real Application Clusters uses high-speed interprocess communication for internode communications. The connect descriptors are set at install time and maintained in the Oracle Internet Directory.
Oracle Calendar uses a file system based repository. So it does not support Oracle Real Application Clusters and Oracle database. But it can be installed in active-passive configuration that is described in the later section.
Outages in Oracle Real Application Clusters
Some of the unscheduled outages in Oracle Real Application Clusters can be due to Oracle instance failure or database node failure. In these failure cases, Oracle Net load balances and routes new connection traffic to the active nodes for the database service. Existing connections of Oracle Collaboration Suite Applications to the failed node will automatically reconnect to the surviving nodes upon any subsequent access.
Some scheduled outages in Oracle Real Application Clusters can be due to configuration changes on a node or maintenance of nodes. For node maintenance, all processes on the node, including the database instance, are brought down and Oracle Network services will route all access to the active database instances. Existing connections of Oracle Collaboration suite Applications to the failed node will automatically reconnect to the surviving nodes upon any subsequent access.
Oracle Collaboration Suite consists of different components deployed on multiple tiers. The availability of each component directly affects the availability of the system. Besides providing high availability features, Oracle Collaboration Suite must also be secure. So both intranet and the Internet users can use the system without compromising availability and security.
This section consists of the Oracle Collaboration Suite high availability requirements which are common to each Oracle Collaboration Suite architecture described later. Oracle Collaboration Suite high availability architecture consists of the following components:
When a node contains multiple Oracle homes, a single shared oraInventory directory is used on each node except for the Oracle Calendar server cold failover cluster installation, which must have its own oraInventory.
For high availability, Oracle recommends that Oracle Collaboration Suite Database be deployed as a Oracle Real Application Clusters database in an active-active configuration.
An Oracle home is on each node of the hardware cluster.
The hardware requirements for Oracle Collaboration Suite Database tier are as follows:
Hardware cluster with Oracle Cluster Ready Services (CRS)
Shared storage for the Oracle Real Application Clusters database files and CRS files. Oracle database files can be on raw devices, Network Attached Storage (NAS), Oracle Cluster File System (OCFS) for Linux, or use Oracle Automatic Storage Management (ASM).
A virtual IP address for each cluster node
Oracle Internet Directory and OracleAS Single Sign-On tiers together provide Oracle Identity Management.
For high availability, Oracle recommends that multiple instances of Oracle Internet Directory and OracleAS Single Sign-On tiers be deployed or that the deployment be designed to failover the service to any available system. An active-active deployment of these tiers require load balancers.
An Oracle home is on multiple nodes.
The hardware requirements for Oracle Identity Management tier are as follows:
Single node
Local storage
A load balancer is at the front end of the nodes to route requests to Oracle Identity Management on all nodes of the cluster.
For high availability, the Oracle Calendar server is placed on a cold failover cluster because it is a single point of failure. This cold failover cluster installation requires shared storage for the Oracle home and oraInventory directory trees. The Oracle Calendar server file-system database is contained under the Oracle home directory tree. To facilitate a cold failover cluster, a virtual IP address and host are required.
The Oracle home and the oraInventory directory trees are located on a dedicated shared storage of the hardware cluster. This Oracle home should have a separate oraInventory directory from the Oracle home of other components, so that when the shared file system is failed over, the oraInventory is also failed over with the same mount point.
The hardware requirements for the Oracle Calendar server are as follows:
Hardware cluster. The Oracle Calendar server can be on the same cluster as the Oracle Collaboration Suite Database, but in Linux, Oracle Cluster Ready Services and RedHat Cluster Manager cannot coexist. As a result, the failover must be manual or the Oracle Calendar server should be put on a cluster that is separate from the Real Application Clusters database.
Shared storage for the Oracle home and oraInventory of the Oracle Calendar server
A virtual IP address
The Oracle Calendar server can be installed on its own cluster that is separate from the Oracle Collaboration Suite Database cluster, if required.
Oracle Collaboration Suite Applications nodes can be deployed in demilitarized zone (DMZ). A load-balancer virtual server forms the front end for multiple application nodes. Client requests to the Oracle Collaboration Suite Applications nodes are load balanced across the Oracle Collaboration Suite Applications nodes by the load balancer using the load-balancer virtual server.
An Oracle home is on each Oracle Collaboration Suite Applications node.
The hardware requirements for the Oracle Collaboration Suite Applications node are as follows:
Single node
Local storage
Configured to work with a load-balancer virtual server that is at the front end to route requests to applications on both nodes
In the architectures documented in the following section, all Oracle Collaboration Suite Applications components are installed on each Oracle Collaboration Suite Applications node. As an alternative to installing all the Oracle Collaboration Suite Applications components on each Oracle Collaboration Suite Applications node, it may be necessary or desirable to separate some Oracle Collaboration Suite Applications components to their own set of nodes.
For example, when an installation has a very large number of e-mail users, you might want to separate the Oracle Mail component to its own set of nodes. This would add two nodes, both containing only the Oracle Mail component. The other two Oracle Collaboration Suite Applications nodes would contain all Oracle Collaboration Suite Applications components except for Oracle Mail. This is based on the assumption that each unique installation of Oracle Collaboration Suite Applications should have at least two nodes to ensure the availability of Oracle Collaboration Suite Applications. Therefore, if you do decide to separate an Oracle Collaboration Suite Applications component from the rest of the Oracle Collaboration Suite Applications, plan on at least two additional nodes.
With flexible installation, deployment, and security options, Oracle Collaboration Suite provides high availability solutions for maximum protection against any kind of failure. Three sample high availability architectures for Oracle Collaboration Suite defined in this section:
Oracle Collaboration Suite Single Cluster Architecture
Oracle Collaboration Suite Collocated Identity Management Architecture
Oracle Collaboration Suite Distributed Identity Management Architecture
Details of these architectures are discussed in the following subsections.
Table 2-1 summarizes the details of Oracle home in the high availability architectures.
Table 2-1 Oracle home details in high availability architectures
| Architecture | Oracle Collaboration Suite Database |
Oracle Internet Directory/Oracle Directory Integration and Provisioning | OracleAS Single Sign-On/Oracle Delegated Administration Services | Oracle Calendar Server | Oracle Collaboration Suite Applications |
|---|---|---|---|---|---|
|
Single cluster architecture with 2 nodes |
Separate Oracle homes are created on Node 1 and Node 2. |
Oracle homes are created on Node 1 and Node 2. Oracle Internet Directory/Directory Integration and Provisioning and Single Sign-On/Delegated Administration Services have the same Oracle homes. |
Same as the previous column. |
Oracle home is active on Node 1. Oracle home on Node 2 becomes active if failover occurs. |
Separate Oracle homes are created on Node 1 and Node 2. |
|
Collocated Identity Management architecture with 4 nodes
|
Separate Oracle homes are created on Node 1 and Node 2. |
Oracle homes are created on Node 3 and Node 4. Oracle Internet Directory/Directory Integration and Provisioning and Single Sign-On/Delegated Administration Services have the same Oracle homes. |
Same as the previous column. |
Oracle home is active on Node 1. Oracle home on Node 2 becomes active if failover occurs. Separate Oracle homes and |
Separate Oracle homes are created on Node 3 and Node 4. |
|
Distributed Identity Management architecture with 6 nodes
|
Separate Oracle homes are created on Node 1 and Node 2. |
Oracle homes are created on Node 3 and Node 4. |
Separate Oracle homes are created on Node 5 and Node 6. |
Oracle home is active on Node 1. Oracle home on Node 2 becomes active if failover occurs. Separate Oracle homes and |
Separate Oracle homes are created on Node 5 and Node 6. |
In single cluster architecture, as shown in Figure 2-1, all the following tiers are installed on a single cluster.
Oracle Collaboration Suite Database
Identity Management Service
Oracle Calendar Server
Oracle Collaboration Suite Applications
This architecture requires multiple installations of Oracle Collaboration Suite and manual postinstallation configuration. In this architecture, the high availability configuration is active-active or Oracle Real Application Clusters for Oracle Collaboration Suite Database 10.1.0.4.2. The database instance processes run on both nodes of the hardware cluster. For the Identity Management to be highly available, an active-active OracleAS Cluster for Identity Management is used and multiple active Identity Management instances provide continued availability in case of failure of one instance. The load balancer is placed at the front end of Identity Management nodes.
The cluster configuration for Oracle Collaboration Suite consists of Oracle Collaboration Suite Database deployed on a cluster with two or more nodes. Figure 2-1 shows Node1 and Node2 in the cluster. Each Oracle Collaboration Suite Database node has a local copy of the Oracle Collaboration Suite software installed. All file-system-based configuration files are local to each node as well. There is a single Oracle Collaboration Suite Database shared by all the database nodes. This Oracle Real Application Clusters database is installed on shared storage accessible to all Oracle Collaboration Suite Database instances.
Figure 2-1 Oracle Collaboration Suite single cluster architecture
Oracle database instances exist on each node and concurrently open the database for read or write operation. The database instance processes and Identity Management processes run on both nodes of the hardware cluster. Oracle home #1 and Oracle home #2 for Oracle Collaboration Suite Database are created in Node1 and Node2.
Oracle home #3 and Oracle home #4 are created for Oracle Identity Management. Oracle home #5 and Oracle home #6 are created for Oracle Collaboration Suite Applications and can include the following components:
Oracle Mail
Oracle Content Services
Oracle Collaboration Suite Search
Oracle Mobile Collaboration
Oracle Voicemail & Fax
Oracle Calendar
Oracle Calendar Web Client
Oracle Calendar Application System
Oracle Collaborative Portlets
Oracle Real-Time Collaboration
Oracle Discussions
Oracle Workspaces
The Oracle Calendar Server oraInventory, ORACLE_HOME, and the Oracle Calendar Sever data (in the ORACLE_HOME directory by default) are installed on a file system residing on shared storage, which is accessed by only one node of the cluster at any given time. So the Oracle Calendar server will only be running on cluster Node1 shown in Figure 2-1. Only after a failure of the Oracle Calendar server on Node1, will the Oracle Calendar server become active on cluster Node2. Oracle home #7 is created for Oracle Calendar server. In the event of a failover, the shared file system containing Oracle home #7 and the Oracle Calendar Server oraInventory is mounted on Node2. Oracle home #7 includes the file- system-level database that stores all calendar-related data. This database is not an Oracle database.
Collocated Identity Management architecture, as shown in Figure 2-2, separates the Oracle Collaboration Suite Database tier and the Identity Management tier rather than sharing nodes as in the Single Cluster Architecture. This architecture requires multiple installations of Oracle Collaboration Suite and manual postinstallation configuration.
In this architecture, the high availability configuration is active-active (Oracle Real Application Clusters) for Oracle Collaboration Suite Database 10.1.0.4.2 and Oracle Identity Management.
The Oracle Collaboration Suite Database tier is created by using Metadata Repository Configuration Assistant or the Oracle Collaboration Suite Database only install option. The Oracle Identity Management tier is installed separately against the Oracle Collaboration Suite Database on multiple nonclustered nodes.
Figure 2-2 shows Node1 and Node2 in the cluster. Oracle home #1 and Oracle home #2 are created for the existing Oracle 10g database with Oracle Collaboration Suite Database in Node1 and Node2 respectively.
Figure 2-2 Oracle Collaboration Suite Collocated Identity Management architecture
The Oracle Calendar server will store its data on a file system residing on a shared disk, which is accessed by only one node of the cluster at any given time. So the Oracle Calendar server will only be running on cluster Node1 shown in Figure 2-2. Only after a failure of the Oracle Calendar server on Node1, will the Oracle Calendar server become active on cluster Node2. Oracle home #7 is created for the Oracle Calendar server. It includes the file-system-level database that stores all calendar-related data. This database is not an Oracle database.
Oracle home #5 and Oracle home #6 are created for Oracle Identity Management on Node3 and Node4. On this tier, Identity Management includes the following components:
Oracle Internet Directory
Oracle Application Server Single Sign-On
Oracle Delegated Administration Services
Oracle Directory Integration and Provisioning
Oracle home #5 and Oracle home #6 for Oracle Collaboration Suite Applications are created.
A hardware load balancer is placed at the front end of the Oracle Identity Management nodes to balance the Oracle Identity Management traffic load.
Oracle Collaboration Suite Applications
In Collocated Identity Management architecture, the components of the Oracle Collaboration Suite Applications tier installed on separate nodes outside Oracle Collaboration Suite Infrastructure. Each installation of Oracle Collaboration Suite Applications will contain all the following components:
Oracle Mail
Oracle Content Services
Oracle Collaboration Suite Search
Oracle Mobile Collaboration
Oracle Voicemail & Fax
Oracle Calendar
Oracle Calendar Web Client
Oracle Calendar Application System
Oracle Collaborative Portlets
Oracle Real-Time Collaboration
Oracle Discussions
Oracle Workspaces
A load balancer is at the front end of the Oracle Collaboration Suite Applications tier to load balance the requests to all the Applications tier servers.
Distributed Identity Management architecture, as shown in Figure 2-3, is similar to the Collocated Identity Management architecture except that the Identity Management components (Oracle Internet Directory and Oracle Application Server Single Sign-On) are distributed across multiple nonclustered servers in a DMZ.
This architecture requires multiple installations of Oracle Collaboration Suite and manual postinstallation configuration.
In this architecture, the high availability configuration is active-active (Oracle Real Application Clusters) for Oracle Collaboration Suite Database, Oracle Internet Directory and OracleAS Single Sign-On.
In this configuration, Oracle Internet Directory and Oracle Directory and Integration Provisioning are deployed on multiple nonclustered servers in the intranet. OracleAS Single Sign-On and Oracle Delegated Administration Services are installed on multiple non-clustered servers in the DMZ. This configuration requires multiple installations of Oracle Collaboration Suite Infrastructure and manual postinstallation configuration.
Figure 2-3 shows Node1 and Node2 in the cluster. Oracle home #1 and Oracle home #2 are created for the existing Oracle 10g database with Oracle Collaboration Suite Database in Node1 and Node2 respectively.
Figure 2-3 Oracle Collaboration Suite distributed Identity Management architecture
Oracle home #1 and Oracle home #2 are created for the existing Oracle 10g database with Oracle Collaboration Suite Database 10.1.0.4.2 in Node1 and Node2 respectively.
The Oracle Calendar server will store its data on a file system residing on a shared disk, which is accessed by only one node of the cluster at any given time. So the Oracle Calendar server will only be running on cluster Node1 shown in Figure 2-3. Only after a failure of the Oracle Calendar server on Node1, the Oracle Calendar server becomes active on cluster Node2. Oracle home #7 is created for the Oracle Calendar server. It includes the file-system-level database that stores all calendar-related data. This database is not an Oracle database.
Oracle home #3 and Oracle home #4 are created for Oracle Identity Management. On the Oracle Internet Directory tier, Oracle Identity Management includes the following components:
Oracle Internet Directory
Oracle Directory Integration and Provisioning
Oracle home #5 and Oracle home #6 for Oracle Collaboration Suite Applications are created on Node5 and Node6.
Oracle home #8 and Oracle home #9 for Oracle Identity Management in Oracle Collaboration Suite Infrastructure are created on Node5 and Node6 as shown in Figure 2-3. On the OracleAS Single Sign-On tier, Oracle Identity Management includes the following components:
OracleAS Single Sign-On
Oracle Delegated Administration Services
The firewall ports to be opened are as follows:
Oracle Net
Oracle Internet Directory port
Oracle Internet Directory Secure Sockets Layer port
A load balancer is placed at the front end of the Oracle Internet Directory tier nodes of Oracle Identity Management. It balances the Oracle Internet Directory traffic load. Another load balancer is placed at the front end of the OracleAS Single Sign-On tier machines to balance the HTTP traffic load.
Oracle Collaboration Suite Applications
In Distributed Identity Management Architecture, the components of the Oracle Collaboration Suite Applications tier are installed on separate nodes outside Oracle Collaboration Suite Infrastructure. Each installation of Oracle Collaboration Suite will contain all the following components:
Oracle Mail
Oracle Content Services
Oracle Collaboration Suite Search
Oracle Mobile Collaboration
Oracle Voicemail & Fax
Oracle Calendar
Oracle Calendar Web Client
Oracle Calendar Application System
Oracle Collaborative Portlets
Oracle Real-Time Collaboration
Oracle Discussions
Oracle Workspaces
A load balancer is placed at the front end of the Oracle Collaboration Suite Applications tier to load balance the requests to all the Applications tier servers.
|
Note: For installation details of the Single Cluster architecture, Collocated Identity Management architecture and Distributed Identity Management architecture, refer to Chapter 9 in the following guides: |
Each high availability architecture option offers advantages and disadvantages.Table 2-2 summarizes the differences among the high availability architectures.
Table 2-2 Comparison of Architectures
| Single Cluster Architecture | Collocated Identity Management Architecture | Distributed Identity Management Architecture | |
|---|---|---|---|
|
Type of Configuration |
In this configuration, all the tiers are installed on a single cluster. |
Oracle Collaboration Suite Database tier, Oracle Collaboration Suite Applications tier and Oracle Identity Management tier are deployed separately. |
Oracle Collaboration Suite Database tier, Oracle Collaboration Suite Applications tier, Oracle Internet Directory and OracleAS Single Sign-On are deployed separately. |
|
Management |
More system resources are required because everything runs on only two nodes. Also, it is not easy to secure this setup. |
System usage is distributed because the Oracle Collaboration Suite Database tier is separated and network security can be stronger. |
System usage is distributed even further than Collocated because the Oracle Collaboration Suite Database tier, Oracle Internet Directory tier, and OracleAS Single Sign-On tier are separated and network security can be stronger. |
|
Cost |
Cheapest solution |
Cheaper than Distributed architecture. |
Expensive solution |
Load balancers play a key role in all the high availability architectures. Not only can load balancers balance the load across nodes, but they can also detect when a node or the necessary application on a node is down and reroute traffic to an active node. Where a hardware load balancer is required, it will be configured to direct incoming requests for OracleAS Single Sign-On, Oracle Internet Directory, and Oracle Collaboration Suite Applications. The load balancer will only be used for non-Oracle Net traffic such as HTTP, Lightweight Directory Access Protocol (LDAP), HTTPS and so on. It is configured with three virtual servers as indicated in the preceding figures:
Oracle Internet Directory or Oracle Directory Integration and Provisioning: Virtual server A, ldap.mydomain.com
OracleAS Single Sign-On or Oracle Delegated Administration Services: Virtual server B, sso.mydomain.com
Oracle Collaboration Suite Applications: Virtual server C, ocs_app.mydomain.com
This section describes the configuration requirements for the load balancer for all the high availability configurations of Oracle Collaboration Suite. For high availability, the recommendations for load balancers are as follows:
The load balancer should be deployed in a fault-tolerant configuration. Two load balancers should be used. These fault-tolerant load balancers should be identical in their configuration and capacity. Their failover should be automatic and seamless.
The load balancer type used should be able to handle both HTTP and LDAP traffic in the high availability configurations described in this chapter. Any load balancing mechanism that supports only one of the protocols cannot be used in the default configuration.
The load balancer should not drop idle connections. Any timeouts associated with dropping of connections should be eliminated.
Two load balancer settings are of primary importance for the high availability configuration:
The nodes to which the load balancer directs traffic
The persistence setting of the load balancer
The persistence mechanism used should provide session-level persistence. By default, HTTP and Oracle Internet Directory requests both use the same virtual host address configured for the load balancer. Hence, the persistence mechanism used is available for both kinds of requests.
The only virtual server that requires persistence is the OracleAS Single Sign-On or Oracle Delegated Administration Services load-balancer virtual server. Ideally, the Oracle Delegated Administration Services Uniform Resource Identifier (URI), /oiddas, is the only access point that requires active cookie persistence with the insert method and not a rewrite method with session-level timeout. These are common load balancer options that should be described in your load balancer documentation. If the load balancer allows for the configuration of different persistence mechanisms for different URIs for the same virtual server, then this is the recommended strategy. If the load balancer does not allow specification of different persistence mechanisms, then the recommended default persistence timeout is 60 seconds. It should be adjusted based on the nature of the deployment and the load balancing achieved across the Oracle Collaboration Suite nodes. It should be increased if session timeouts are experienced by Oracle Delegated Administration Services users. It should be decreased even if load balancing is not achieved.
Load balancers come in many types and each may have its own configuration mechanism. Consult your load balancer documentation for the specific instructions to achieve these configurations.
