HP-UX OSRA for Web Services 2.5 Blueprint and Configuration Guide

Figure 3-2 DNS Load Balancing
When compared to hardware load balancing, there are several potential shortfalls when using
a DNS load balancing configuration:
• The DNS named server does not consider the status of the application servers when it
resolves the virtual server name. Requests can be routed to a server that is busy or is no
longer available.
• The DNS named server has no sticky sessions. Subsequent requests from the same client to
resolve the virtual server name can receive a different IP addresses. This causes problems
if the application is keeping session state information on the application server. The
application does not work properly because subsequent client requests are routed to different
servers unless the application server takes steps to propagate the state information.
Approaches to propagate state information do not scale well and can defeat the advantages
gained by using a server cluster. In a DNS load balancing configuration, applications must
not store state information in the application server unless it is propagated.
Figure 3-2 shows a single database server. All session data must be written to the database
server or returned to the client in an HTTP session cookie or URL encoded query string,
with each request. All application servers must share the same database server, or the
database must instantly replicate session state data to all database servers used by the farm.
• The web client often caches the IP address returned by the DNS. This resolves the sticky
session problem, but the client does not respond to changes in the DNS round-robin
configuration in a timely manner. In addition, the same client can not load balance over
several application servers, but always uses the same server until the DNS-to-IP-address
cache is flushed. You can use techniques to reduce or eliminate the time a name spends in
28 Load Balancing and Cluster Configuration