Configuring the Load Balancer

In a Gateway cluster, a Load Balancer provides vital load balancing and failover protection functions. This provides a unified interface to the cluster and enhances its reliability, scalability, and processing power.
In a Gateway cluster, a Load Balancer provides vital load balancing and failover protection functions. This provides a unified interface to the cluster and enhances its reliability, scalability, and processing power.
This topic does not provide Load Balancer configuration information or instructions. Only the specialized configuration settings that are required to connect the Load Balancer to a Gateway cluster are provided. Consult your Load Balancer device documentation for detailed configuration instructions.
In a Gateway cluster, the Load Balancer device specifically:
  • Listens for incoming network messages on its external interface.
  • Distributes workload to the gateway processing nodes.
    While even load distribution is a goal, it is not a guarantee, as there are several factors that contribute to uneven loading.
  • Provides (mostly) client-transparent TCP connectivity for the Gateway cluster.
  • For appliance Gateways, the Load Balancer provides failover functionality:
    • Failover detection:
      The Load Balance detects service availability by periodically polling the Gateway processing nodes. ICMP detection is minimal, and HTTP polling is preferred.
    • Failover protection:
      If a Gateway processing node in the cluster fails, then the Load Balancer automatically directs incoming request messages to another processing node in the cluster.
To connect to the Gateway cluster, the Load Balancer device must contain special settings in four configuration areas:
  • IP address determination
  • virtual server configuration
  • session persistence configuration
  • service availability determination configuration
Use the following sections with your Load Balancer documentation to help you configure the Load Balancer device.
Choosing a Load Balancing Strategy
Load balancing on back-end servers involves guesswork on the part of the Load Balancer, as it tries to extrapolate from the current state. There are several strategies that you can use. The strategies listed here are referred to generically and may be known by different names within your organization.
  • Least Connections:
    This method selects the service with the least number of active connections to ensure that the load of active requests is balanced on the services and nodes. This is a common strategy that is simple to implement and understand, and it works well in most instances.
  • Average Response Time:
    This method uses the average Gateway response times to determine which node has the least load. This strategy is useful in that the response time metric gives a rough indication of the actual load on individual Gateway nodes. This strategy may not be available on standard Load Balancers.
  • Round Robin:
    This method rotates incoming requests across the different Gateway nodes, regardless of the load. This strategy is less desirable especially for SSL, as it causes a large increase in the number of SSL negotiations. It also can prevent HTTP 'keepalive' from working, depending on the particular Load Balancer implementation. Lastly, this strategy does not consider the account server load.
  • SSL Persistence:
    This method may not be available on all load balancers and only applies to SSL connections. This method resembles the Round Robin strategy, but it specifically deals with the SSL negotiation problem. It also does not consider the account server load.
Choosing a Session Persistence Strategy
Session persistence is the converse of load balancing. Load balancing distributes the workload across all cluster nodes, while session persistence routes information back to the same cluster node. This may improve performance under certain conditions.
Several options are available when choosing a session persistence strategy. CA Technologies recommends IP-based strategies, though this is not optimal when there relatively few nodes in the Gateway cluster. Other common methods are cookie-based and there are proprietary methods. Cookie-based strategies have disadvantages in that they assume the back-end systems also support the cookies. This requires support for cookie pass-through in the service policy for it to work.
Session persistence is recommended, though it is strictly not necessary for most features in the 
Layer7 API Gateway
. A few scenarios may benefit from persisted sessions; your service policy determines whether persistence is required.
Example 1:
The Require WS-Secure Conversation Assertion fails if the Load Balancing Strategy is "Round Robin" and no persistence is configured. This is because the assertion sets up a persistent token session on the Gateway. When the client machine is routed to another Gateway node, this invalidates the persistent token for the request, preventing the session negotiation from completing.
Example 2:
SSL negotiation also has a persistent token that is reused wherever possible. When the "Round Robin" Load Balancing Strategy is used, the tokens are discarded, causing additional SSL RSA negotiations. This impacts Gateway performance, but does not cause a communication failure as with the Require WS-Secure Conversation assertion.
Example 3:
Without session persistence, you may receive a "Inactivity timeout reached" message immediately upon logging in with the Policy Manager. This is due to the Load Balancer choosing a random node to respond to the Policy Manager and this node does not have the admin login cookie. To avoid this issue, either configure session persistence or connect to a specific Gateway node by IP address, rather than using the cluster hostname.
Determining the IP Address
IP addresses for the cluster and cluster nodes must be determined by and set in the Load Balancer.
Cluster IP Addresses
The Gateway cluster is accessed by the XML VPN Client, the Policy Manager, and external client systems at a single network address. The Network Administrator determines this static IP address, commonly on the non-secure client-facing side of the enterprise network.
Cluster Node IP Address
The Load Balancer delegates workload evenly to the individual Gateway processing nodes in a cluster. This means each processing node in the cluster must have a unique static IP address within the secure subnet of the Load Balancer. Define and set these IP addresses, as necessary, in the Load Balancer. For example, with a cluster origin IP address of "", the cluster node IP addresses are "" and "" for the Gateway processing nodes "SSG1" and "SSG2", respectively.
In more secure network configurations, a second IP address is required for the Gateway cluster to connect to back-end services. This secure network is not routable by the Load Balancer, preventing insecure messages from entering the back-end secure network. If a secure network exists, then assign the back-end service IP address to "eth0" in the Load Balancer. Assign less secure network IP addresses to "eth1". By default, the Gateway cluster uses the more secure network for inter-node communication if available; otherwise, the cluster uses the Load Balancer.
Configuring the Virtual Server
The load balancer for the Gateway cluster listens for incoming messages on TCP ports 8080 and 8443. It forwards the traffic to the processing nodes at the static IP addresses defined in "Cluster IP Addresses".
Use the IP addresses defined in "Determining the IP Address" when configuring forwarding for ports 8080 and 8443. Do not use secure network IP addresses, if they exist.
Configuring Session Persistence
When the Load Balancer transmits an incoming message to a particular processing node, a session is opened between the client application and the node. Session persistence ensures that the session remains open during the transaction. To ensure session persistence, configure the Load Balancer session timeout limit to 30 minutes.
Load Balancer Health Check
To check service availability when a load balancer is present, create a simple policy containing a single Return Template Response to Requestor Assertion, with these properties:
  • Response HTTP Status:
  • Send Response Immediately:
  • Response Content Type:
  • Response Body:
Ensure that you have the service URI "/
/ping" enabled.
Send a request to "/
/ping". You should see "OK" as the response.