Re: [load balancing] 2 Colo's

From: Kenneth Salchow <k.salchow [izzat] f5.com>
Date: Wed May 27 2009 - 16:05:05 EDT

First off-I HATE that 'gslb page of shame' thing. It is 5 years old (that's
half a decade-in TECHNOLOGY). Second, on this list as well as probably
hundreds if not thousands of other places, the entire premise of that
document/post/whatever has been completely ripped to shreds. Lastly, if
that wasn't enough, I hate when someone says that something won't work
because it's not 100% perfect but then fails to suggest anything that is
even remotely close in terms of a solution. Really, it bugs me. J I
would have preferred a competitor pushing their solution-but the squeaky
wheel to be a squeaky wheel thing, eh.

 

Second, despite that lingering presence, there are probably thousands of
sites that use GSLB effectively every single day (and I'm not talking about
just those supplied by my employer). In fact, I would bet that if you
bought ANYTHING off the internet or did any online banking any time recently
(or even updated your operating system)-you've used GSLB yourself. Not only
have these solutions *always* provided significant value, but in the 5 years
since that heresy was published, many things about DNS have changed; most
modern systems accept the concept of a 0 TTL completely. In a nutshell,
since GSLB was the only even remotely successful solution-and people needed
a solution-most, if not all of the issues that prevented it from being
perfect have been addressed.

 

Ok-to your question:

 

It was my intent to use 2 A records to the WWW lookup. Then, use GSLB to
control the traffic.
 
This works fine when both sites are up and running, but what happens when
one goes down - rely on the built-in failover mechanism is DNS (the second A
record)?

 

So, first, do you really want both sites active at all times? That's a
basic question that really revolves around being able to maintain
persistence (keeping user "a" on site "a" for the duration) and/or
replication of state if necessary. Many folks simply use the secondary site
for BC/DR. However, if you need the second site for expansion then having
both sites online makes sense. Deciding why you are adding the second site
and how you are going to use it is important as it impacts how you configure
things. Adding the third or fourth site is very similar.

 

Second-as for the A records-your GSLB solution will handle that. See,
unlike traditional DNS, GSLB solutions can actually hand out only 1 A record
at a time and only the one you want or makes sense-this is how they control
the traffic. So, when the both sites are running normally, the GSLB can
alternate handing out the IP address of each datacenter (for a typical round
robin setup) and it can remember who requested the lookup so it always gives
back the same IP if necessary. Then, if one site falls down-the GSLB can
quit handing out that IP. Or, if a site starts to get slow or overburdened,
the GSLB can start cutting back on how often it hands out that IP-even
temporarily not sending any new traffic there. It's really quite simple.
We even have one customer that actually routes all "Write" traffic to one
datacenter, but allows "Read" traffic (80-90% of their total traffic) from
one of several in order to improve performance. While this is not simply a
GSLB solution (it involves local Application Delivery Controllers as well),
the GSLB's capabilities are an integral part of the solution.

 

This same technique is used by many organizations to swing traffic away from
a datacenter in order to perform maintenance. Once no new or persistent
connections are going to the data center-you can safely perform any kind of
maintenance without impacting live traffic. You can even (by IP) test the
site before letting users return to it. It is quite handy. J

 

The big thing here is a question of how long you set your TTL for. Setting
it to 0 provides you the most dynamic and responsive GSLB solution (0
essentially means - don't cache, resolve each time). That being said,
resolving names on every connection/use can potentially have a negative
impact on the user experience as well as significantly increasing the amount
of bandwidth used just for name resolution. Depending on your
application(s) you will have to play with this to see what works best for
you.

 

In the end-what you are shooting for is that if a datacenter goes down-by
the time the user hits 'refresh' they are already being sent to your new
site. Depending on your system, they may lose their existing session-but
it's better than watching your cursor sit and spin.

 

Wow-I hope that helps?? If not-fire back a response and I'm sure someone
(or me) will give it another shot!!!
 

 

 

 

KJ (Ken) Salchow, Jr. | Manager, Technical Marketing

D 651.423.1133

M 612.868.12588

P 206.272.5555

F 206.272.5555

 <http://www.f5.com/> www.f5.com

 

 

From: lb-l-bounces@vegan.net [mailto:lb-l-bounces@vegan.net] On Behalf Of
Dane Ruyle
Sent: Wednesday, May 27, 2009 2:01 PM
To: Load Baalancing
Subject: [load balancing] 2 Colo's

 

Hi all,
 
I'd like to hear your input on the best way to bring a second collocation
facility online. We are a SAAS company. Basically, our service is all tied
to a domain name; the www record.
 
It was my intent to use 2 A records to the WWW lookup. Then, use GSLB to
control the traffic.
 
This works fine when both sites are up and running, but what happens when
one goes down - rely on the built-in failover mechanism is DNS (the second A
record)?
 
There's a GSLB Page of Shame http://www.tenereillo.com/GSLBPageOfShame.htm
 
Would love to hear your input as I am going to be bringing a second one
online.
 
Thanks for your time,
dane
 

  _____

Windows LiveT: Keep your life in sync. Check it out.
<http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009>

_______________________________________________
lb-l mailing list
lb-l@vegan.net
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki

Received on Wed May 27 16:05:20 2009

This archive was generated by hypermail 2.1.8 : Wed May 27 2009 - 16:05:21 EDT