8 Load Balancing

This chapter provides an overview of load balancing and failover options for an Oracle WebCenter deployment. The purpose of this chapter is to assist in incorporating load balancing and redundancy into your network topology planning. Load balancing and redundancy options require third-party software or hardware and should be implemented with the aid of experts familiar with those third-party products. Oracle provides professional consulting services to assist in planning an Oracle WebCenter deployment. To engage Oracle professional services, contact your Oracle representative.

This chapter is divided into two sections:

Load Balancing Oracle WebCenter, covers load balancing and failover strategies for the portal and other Oracle WebCenter components.
Load Balancing Oracle WebCenter Applications, covers load balancing Oracle WebCenter applications such as Oracle WebCenter Collaboration and Oracle BPM Suite, and clustering for Oracle WebCenter Collaboration.

Load Balancing Oracle WebCenter

The following sections provide examples of load balancing strategies for Oracle WebCenter components.

Load Balancing the Oracle WebCenter Interaction Portal Component

A typical configuration for hardware load balancing is to put the load balancer network appliance in the DMZ and have it route requests to an Oracle WebCenter Interaction portal server farm, as illustrated in Figure 8-1.

Figure 8-1 Hardware Load Balancing Oracle WebCenter Interaction

Description of "Figure 8-1 Hardware Load Balancing Oracle WebCenter Interaction"

The Oracle WebCenter Interaction portal can be used with any load balancing system that supports sticky IPs, including Cisco LocalDirector, F5 Big-IP, and Windows NLB, as well as the Apache Web server. Oracle does not advocate any specific load balancer.

Session states are maintained by the portal Web servers themselves. If a portal server is taken out of the server farm, user sessions on that server are lost and users will need to log back into the portal.

It is possible for the portal to become unresponsive while the portal Web server is still operational. In this case, the load balancer will assume that the portal is still alive. The load balancer should perform content verification to ensure that the portal is actually available.

The load balancer should send requests to the host with the most available resources instead of performing round-robin distribution of requests. Users use the portal component in different ways, and some users will tax the portal server more heavily than others.

For maximum fault tolerance, load balancers should be clustered.

Another potential load balancing topology is illustrated in Figure 8-2.

Figure 8-2 Multiple Oracle WebCenter Interaction Instances on One Server

Description of "Figure 8-2 Multiple Oracle WebCenter Interaction Instances on One Server"

In this example, multiple instances of Oracle WebCenter Interaction are running on a single host, with each portal server listening to a different port. On each host, an instance of Apache balances the load between the instances of Oracle WebCenter Interaction. There are multiple hosts running this configuration, and these hosts are load-balanced by a hardware load balancer in the DMZ. Sticky IPs must be maintained throughout.

On hardware that supports a large number of users, this configuration minimizes the number of user sessions lost in the event of a portal failure.

Load Balancing the Image Service

The Image Service serves static content and does not require sticky IPs. Any number of Image Services can be load balanced.

Load Balancing the Document Repository Service

The document repository service can be load balanced using IP load balancing. This provides partial failover; however, all document repository hosts must share a single, writable file system backing store.

The backing store cannot be load balanced, but failover can be achieved by using a shared local disk with MSCS for failover or a network share implemented with NAS or MSCS.

Load Balancing the Automation Service

The Automation Service requires no additional technology for load balancing or failover. Install multiple Automation Services in the Oracle WebCenter system and designate jobs to run on any set of available servers.

If a server fails mid-job, the job will not complete on another server; however, if the job is scheduled to run periodically, another Automation Service will pick up and run the job.

Load Balancing Oracle WebCenter Applications

The following sections describe how to load balance Oracle WebCenter applications such as Oracle WebCenter Collaboration and Oracle BPM Suite.

The following Oracle WebCenter products should not be load balanced:

Oracle WebCenter Interaction Administrative Portal
Oracle WebCenter Interaction API Service
Oracle WebCenter Analytics

PPE-LB Load Balancing Oracle WebCenter Applications

The Oracle WebCenter Interaction portal component provides the Parallel Portal Engine Load Balancer (PPE-LB) to facilitate load balancing and failover services to Oracle WebCenter Collaboration, Oracle BPM Suite, and other portlet Web service providers utilizing HTTP messaging. This eliminates the need for third-party load balancers for middle-tier messaging.

To configure Oracle WebCenter Collaboration for clustering, see Clustering Oracle WebCenter Collaboration.

Caution:

Not all portlets can be load balanced. If the portlet caches data in memory with the assumption that the underlying database will not be modified, load balancing will cause issues. Consult the portlet documentation or portlet developer to determine if specific portlets can be load balanced.

Configuring the PPE-LB

The PPE-LB is configured by editing DNS so that one server name (the cluster name) resolves to each IP address in the cluster. Each remote server in the cluster must have a unique IP address and must have the same software installed.

Use nslookup from the portal server to verify that the cluster name resolves to all intended remote server addresses.

Caution:

Editing the hosts file on a Windows host is not equivalent to configuring DNS. Windows caches and returns only the first IP address instead of returning all IP addresses associated with the cluster.

Note:

If the DNS server cannot be configured, edit the openhttp component section of the configuration.xml file to provide this information. Here is an example for configuring Oracle WebCenter Interaction to use clustered Oracle WebCenter Collaboration instances:

<setting name="openhttp:LoadBalancedHost0">
<value xsi:type="xsd:string">collab:11930</value>
</setting>
<setting name="openhttp:LoadBalancedIPs0">
<value xsi:type="xsd:string">###.###.###.###:11930;###.###.###.###:11930</value>

PPE-LB and SSL

When using SSL between the Oracle WebCenter Interaction portal and the remote servers, create a single SSL certificate by name and add it to each machine in the remote server cluster.

PPE Configuration Settings

The PPE is implemented with the OpenHTTP standard. OpenHTTP settings are configured in the Oracle WebCenter Interaction portal component by editing PT_HOME/settings/configuration.xml and modifying the openhttp component node.

The following settings are configurable:

Setting	Description
ProxyURL	Specifies the URL for a proxy host.
ProxyUser	Specifies an authentication user name for the proxy connection.
ProxyPassword	Specifies an authentication password for the proxy connection.
ProxyBypass	Contains a list of hosts accessed directly instead of through the proxy.
ProxyBypassLocal	Boolean flag specifies that hosts in the same domain should not be accessed through the proxy. If a hostname has no "." (dots) in its name it is considered local and in the same DNS domain.

The following settings can be added:

Setting	Description
ForceHttp10	Sends HTTP/1.0 requests instead of HTTP/1.1. The sockets are closed after sending a single request.
TraceBodyAndHeaders	For debugging only. Traces the values of headers and some parts of the body of the requests/responses to Oracle WebCenter Logging Utilities. Turned off by default because headers might contain passwords in cleartext.
HttpCacheSizeMb	Defines maximum size of the cached data. Cache uses an LRU algorithm to decide which old entry should be kicked out in order to accommodate newer data.
ConnectionCacheTimeoutSec	Defines the time that the socket remains unused in the cache before being closed by OpenHTTP.
MinimumDNSThreads	Specifies the minimum number of threads that are used to perform DNS lookups.
MaximumDNSThreads	Specifies the maximum number of threads that are used to perform DNS lookups.

Clustering Oracle WebCenter Collaboration

Oracle WebCenter Collaboration supports clustering to provide load balancing and fail over. In clustering mode, multiple instances of Oracle WebCenter Collaboration communicate with each other to maintain a single, consistent logical image.

Configuring the Portal for Oracle WebCenter Collaboration Clustering

The portal provides load balancing through mapping one domain name to multiple IP addresses. A single domain name that contains the IP addresses of each Oracle WebCenter Collaboration server to be clustered must be provided. Use this name as the portlet remote server name.

Configuring Oracle WebCenter Collaboration for Clustering

You configure Oracle WebCenter Collaboration by editing two files, config.xml and cluster.xml. The files are located in PT_HOME/ptcollab/version/settings/config

To enable clustering, perform the following steps on each Oracle WebCenter Collaboration server to be clustered:

In config.xml, change the following:

<cluster enabled="no">cluster.xml</cluster>

<cluster enabled="yes">cluster.xml</cluster>

Save config.xml and restart the Oracle WebCenter Collaboration server.

By default, Oracle WebCenter Collaboration uses UDP multicasting for communicating between servers. This is the most efficient option and is appropriate for most deployments. In environments where UDP multicasting is not allowed, configure Oracle WebCenter Collaboration to use UDP unicasting.

To configure Oracle WebCenter Collaboration to use UDP unicasting, perform the following steps on each Oracle WebCenter Collaboration server to be clustered:

In cluster.xml, nominate one of the machines in the cluster to be the coordinator:
```
<coordinator-host>machine.name</coordinator-host>
<coordinator-port>9990</coordinator-port>
```
Note:

The port number can be any free port number.

Change the cluster profile to lan-cluster:

<profiles profile='lan-multicast-cluster'>

<profiles profile='lan-cluster'>

Save cluster.xml and restart the Oracle WebCenter Collaboration server.

Another optional configuration is to use the wan-cluster profile. The wan-cluster profile uses TCP to communicate directly with specific Oracle WebCenter Collaboration instances.

To enable wan-cluster, perform the following steps on each Oracle WebCenter Collaboration server to be clustered:

In cluster.xml, add one or more Oracle WebCenter Collaboration instances to the <hosts> node. For example, if there are three Oracle WebCenter Collaboration instances, collab01, collab02, and collab03, edit the collab01 cluster.xml to include the other two instances:
```
<hosts>collab02[$port],collab03[$port]</hosts>
```
Note:

The $port string will be automatically replaced with the <port> setting already configured in cluster.xml.

In cluster.xml, change the cluster profile to wan-cluster:

<profiles profile='lan-multicast-cluster'>

<profiles profile='wan-cluster'>

Save cluster.xml and restart the Oracle WebCenter Collaboration server.