HydraWEB technologies load balancers have a feature called "DNS Finesse"
that allows them to provide persistence for clients coming from
"mega-proxies" like AOL. Although it sacrifices some load balancing
granularity, this feature works without using either cookies or SSL
session ID - so it seems to meet your requirements.
Mega-proxies like AOL behave differently than a standard proxy. With a
standard proxy, multiple users appear to the Internet to originate from
a singe address - the address of the proxy. Persistence can be
maintained for each user by simply treating the proxy address as a
single user, although load balancing granularity is somewhat reduced.
Mega-proxies associate multiple users with multiple addresses (the block
of addresses owned by the mega-proxy). This causes problems for simple
load balancers since each user is not associated with a single source
address (not even one shared with other users).
HydraWEB's DNS Finesse feature solves this problem by allowing a block
of addresses (a subnet) to be aggregated and treated as a single source
address for purposes of persistence. A typical implementation would be
configured as follows:
The DNS Finesse feature would be configured to treat each block of
addresses associated with a mega-proxy as a single "user". Used by
itself, this will ensure that each mega-proxy block of addresses will be
persisted to a single server - thereby assuring the persistence of ever
user in that block.
The drawback of doing this is that load balancing granularity is reduced
quite a bit. The solution to this is to assign several (for example ten)
IP addresses to the cluster (on HydraWEB devices these can be alias
addresses). The entire group of addresses is then entered into the DNS
system for that URL. It now becomes likely that, for a large number of
users accessing the site from a given mega-proxy, approximately equal
numbers will be doing so using each of the ten addresses (cluster
addresses = destination addresses) available for that cluster.
HydraWEB's load balancers offer persistence based upon source AND
destination address so, if ten addresses are used for each cluster, each
mega-proxy is now split up into ten sub-groups (each with the same
source address {block} and a different destination address). Each of
these subgroups is treated separately for persistence purposes, which
gains back much of the granularity that is lost by aggregating the
address blocks.
Overall, this solutions is the best possible way of providing
persistence for mega-proxy situations without using either cookies or
SSL session ID. Load balancing granularity is slightly reduced, but
persistence is reliably maintained. This feature is supported on all of
HydraWEB's local SLB solutions.
This archive was generated by hypermail 2b30 : Thu Apr 05 2001 - 15:40:11 EDT