From: P (pt_lbIZZAThotmail.com)
Date: Tue Jan 27 2004 - 13:02:35 EST
Giuseppe,
This is of course a very old problem, with many solutions out there, but
also many associated problems with those solutions.
The most recent solution is usually referred to as "DNS persistence". Alteon
(ACD) and F5 (3DNS) already have this feature, I'm quite certain Cisco and
everyone else will add it soon. It is definitely useful, only a slight
departure from existing functionality, and not a big deal to implement.
Older solutions include proxy/NAT (i.e. just load-balance the request to the
other site as if that site were a local real server), triangulation, and
HTTP redirection. Most GSLB solutions support at least a couple of these
older methods.
Here's how DNS persistence works in a nutshell:
The GSLB device uses a function similar to source IP address persistence in
local load balancing, remembering IP address affinities and distributing
those to all devices that act as authoritative nameservers for the sites to
be GSLBed. For example, if a client's DNS server ("local DNS server" or
whatever you want to call it - the one the client gets assigned at DHCP
time) has IP address 1.1.1.1, and DNS persistence is used, all subsequent
DNS requests from DNS server 1.1.1.1 will be directed to the same site for
some amount of time, usually a rolling timer that expires only after a
period of inactivity (also can work for network 1.1.1.x or 1.1.x.x or
whatever). Now of course DNS persistence can in theory be subject to all of
the problems that source IP address persistence is subject to ("AOL
problem", "megaproxy problem", details of which are widely available), but
in practice it is not nearly as likely that a client DNS request gets
"megaproxied". Also DNS persistence can be layered on top of another
persistence method such as 302 redirection, proxy, NAT, or triangulation,
and greatly reduce the side effects of these.
I don't recommend the 302 redirect, proxy/NAT, or triangulation solutions
standalone, especially for sites with typical session times longer than 30
minutes. All of these, especially proxy/NAT/triangulation, add significant
overhead. Here's why: they "only" redirect when a client ends up on the
wrong site, but if the application is such that the typical user session is
longer than the browser DNS cache timeout (30 minutes IE, 15 minutes
Netscape), then the number of clients that get
redirected/proxied/NATed/triangulated will quickly get very, very,
significant. (Note: Such persistence mechanisms are often used in
conjunction with proximity metrics, but proximity metrics do not in practice
select the same site with nearly enough consistency to be considered
reliable for persistence). All of these, especially NAT/proxy/triangulation
add overhead in such situations. The 302 redirect solution is slightly more
efficient than NAT/proxy/triangulation because it acts as a handoff rather
than a change in flow of all subsequent connections, but can be a bit messy
because it requires the use of unique FQDNs at each site. These unique FQDNs
cause client bookmark issues and, for sites that use SSL, requires the
purchase of additional certificates for each site (effectively doubling the
total certificate expense). Triangulation adds the additional headache of
convincing your provider, co-lo, etc. to allow your equipment to spoof
outbound IP address.
So I would suggest bugging Cisco until they give you DNS persistence in the
CSS!
Pete.
PS For anyone who is interested - I wrote up a paper when I worked at Alteon
that explains this issue in detail (information applies to any product,
obviously the punch line is "buy Alteon" but the general info is there). It
has diagrams, detailed step-by-step examples, etc. explaining all this. That
paper is the property of Alteon - if you are nice to him maybe our friend
Giles Scott will e-mail it to you.
-----Original Message-----
From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of Jay
Cedrone
Sent: Tuesday, January 27, 2004 6:32 AM
To: lb-lIZZATvegan.net
Subject: RE: [load balancing] Global Server Loadbalanicing with CISCO CSS
11503
Giuseppe,
There is a feature you can turn on the CSS call "location cookie" which
will set a cookie for the datacenter (slb) and if a user were to
re-resolve, and show up at the wrong datacenter, the CSS would then
either redirect (302) back to the correct datacenter or NAT the request
back to the correct datacenter.
- Jay
Jay Cedrone
CISCO SYSTEMS INC
Internet Systems Business Unit
TME
1414 Massachusetts Avenue
Boxborough MA 01719
Office 978-936-0930
Mobile 857-498-1818
EMAIL jcedroneIZZATcisco.com
EPAGE jcedroneIZZATepage.cisco.com
-----Original Message-----
From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of
casablancagIZZATpost.ch
Sent: Tuesday, January 27, 2004 8:39 AM
To: lb-lIZZATvegan.net
Subject: [load balancing] Global Server Loadbalanicing with CISCO CSS
11503
Hi
I have two aactive sites, where a make a global loadbalancing with two
Cisco CSS 11503. If I make a witch over of one site, the DNS Record will
be updated and the traffic will be directed too the other site. But If
the browser or the dns servers cache the DNS-Records then the client
still have the old record with the wrong Information and the traffic
will be directed too the old Site where no server will answer the
request. Does anybody have a suggestion ????
Thank you in advance
Giuseppe Casablanca
Dipl. Inf. Ing. FH
Network Access Solutions
Die Schweizerische Post
Information Technology Services
Webergutstrasse 12
CH-3030 Bern (Zollikofen)
Tel. +41 (0)31 338 67 73
Fax +41 (0)31 338 95 70
Mailto: casablancagIZZATpost.ch
Visit our homepages:
Intern: http://pww.post.ch/oe/IP/corp/index.htm
Extern: http://www.post.ch
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Tue Jan 27 2004 - 13:18:42 EST