# Networking and Authentication Guide

# Load Balancing

This chapter provides an overview of load balancing and failover options for an AquaLogic User Interaction 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. BEA provides professional consulting services to assist in planning an AquaLogic User Interaction deployment. To engage BEA professional services, contact your BEA representative.

This chapter is divided into two sections:

- Load Balancing AquaLogic Interaction covers load balancing and failover strategies for the portal and other AquaLogic Interaction components.
- Load Balancing Activity Services covers load balancing AquaLogic User Interaction Activity Services and clustering for Collaboration.

## Load Balancing AquaLogic Interaction

The following sections provide examples of load balancing strategies for AquaLogic Interaction components.

### Load Balancing the AquaLogic 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 AquaLogic Interaction Portal server farm, as illustrated in Figure 4-1.

Figure 4-1 Hardware Load Balancing AquaLogic Interaction

The AquaLogic 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. BEA 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 4-2.

Figure 4-2 Multiple AquaLogic Interaction Instances on One Server

In this example, multiple instances of AquaLogic 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 AquaLogic 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 AquaLogic Interaction 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 Search

Search performance can be improved by installing multiple Search instances. Dedicate one instance for indexing jobs and the remaining instances for queries. The indexing instance cannot be load balanced and does not support failover.

There are three levels of load capacity:

1. A single server performing both indexing and query services.
2. One server performing indexing and one server providing query services.
3. One server performing indexing and multiple servers providing query services. The query servers can be proxied through a third-party load balancer.

## Load Balancing Activity Services

The following sections describe how to load balance AquaLogic User Interaction Activity Services.

The following AquaLogic User Interaction products should not be load balanced:

- AquaLogic Interaction Administrative Portal
- AquaLogic Interaction API Service
- Analytics
- Publisher
- Studio

### PPE-LB Load Balancing Activity Services

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

To configure AquaLogic User Interaction Collaboration for clustering, see Clustering AquaLogic Interaction 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, contact BEA Customer Support for Windows registry settings that can provide equivalent functionality.

#### PPE-LB and SSL

When using SSL between the AquaLogic Interaction Portal and the remote servers, create a single SSL certifiate 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 ALI portal component by editing <PT_HOME>/settings/common/serverconfig.xml.

The following settings are configurable:

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 AquaLogic Interaction Logging. 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.
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.

### Clustering AquaLogic Interaction Collaboration

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

##### Configuring the Portal for 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 Collaboration server to be clustered must be provided. Use this name as the portlet remote server name.

##### Configuring Collaboration for Clustering

You configure Collaboration by editing two files, config.xml and cluster.xml. The files are located in <PT_HOME>/ptcollab/<ver>/settings/config

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

1. In config.xml, change the following:

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

to

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

2. Save config.xml and restart the Collaboration server.

By default, 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 Collaboration to use UDP unicasting.

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

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

2. Change the cluster profile to lan-cluster:

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

to

    <profiles profile=’lan-cluster’>

3. Save cluster.xml and restart the Collaboration server.

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

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

1. In cluster.xml, add one or more Collaboration instances to the `<hosts>` node. For example, if there are three 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.

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

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

to

    <profiles profile=’wan-cluster’>

3. Save cluster.xml and restart the Collaboration server.