UPDATE - December 2017: Before you start reading my rant, you may be pleased (or somewhat surprised) to know that - we've finally found a decent reason to use GSLB and why it might not suck after all!
UPDATE - August 2024: If you're after a comprehensive guide to GSLB, check this out:
OK, before I start to fan the flames, let me state the usual caveat, "GSLB don't ALWAYS suck. Just more often than you'd think".
It's 2011, and here at Loadbalancer.org we've toyed with the idea of selling a Global Server Load Balancer. After all, it wouldn't take long to hack a decent PowerDNS interface onto one of our appliances. But every time we look at how it might work, we keep coming back to the fact that it doesn't always work as the customer would expect.
Let me continue this rant by describing what customers probably want, before moving on to what GSLB actually does, before suggesting some simple alternatives.
What do most customers want when they talk about GSLB?
There's normally two things customers ask for:
- Active-Passive failover between two Internet sites (disaster recovery and high availability).
- Active-Active load balancing between two or more geographically dispersed sites i.e. Europe and USA (this uses the closest site for speed and high availability).
Sounds simple enough, doesn't it?
But let's briefly step back to what we should have done first, which is make sure our primary site (or all sites for that matter) is as indestructible as possible.
Have you already got the following?
- 2 x Internet feeds
- 2 x Switch fabrics
- 2 x Firewalls
- 2 x Load balancers (no persistence/sticky here please, we want high availability after all)
- 3+ x Web Servers
- 2+ x Database Servers (gee, I wonder if we could put the persistence here?)
Done that?
No? Then go and do that first before you think about GSLB.
Assuming you've done that already, then great, by all means explore GSLB.
Next, I'm going to explain what a GSLB is (and it's quite simple)...
What is a Global Server Load Balancer really?
GSLB (Global Server Load Balancer) = DNS (Domain Name Server)
That wasn't difficult, was it?
When a client requests "www.myGSLBsite.com", your DNS/GSLB replies saying "sure go to X.X.X.X".
Now this can all quickly get very complicated, with GSLB vendors saying "but we can do all this cool stuff as well". But I say "Hogwash", and agree with everything Pete Tenereillo says about GSLB (well almost).
So going back to customer request number 1...
Wasn't too hard, was it? On to request number 2...
Who spotted the deliberate mistake?
Err... OK so it doesn't give you the local provider/ shortest hops etc, but if you read Pete's blog (above) you would realize that that is impossible.
Akamai and others have made a lot of money by making sure your big files like picture and video's are replicated to edge networks around the world. And guess what? They know what they're doing!
BTW Amazon cloud front does this and it's dirt cheap...Who gives a monkey which application server they hit if the large datasets are served from an edge network?
Now, I have rushed this a bit (no, really?) and I've probably missed a lot of things (feel free to enlighten me!) but that's my personal point of view.
On a more positive note though, if you are still serious about wanting to do this GSLB-thingy then right at the bottom of Pete's famous rant you will find the possible answer. I'm sure it's the method that Google et al. do and it's this:
- Use a global network of top level domain name servers with proper BGP agreements, with all the other top level DNS providers + a simple health checking framework with least hop selection criterion.
- Then rapidly change BOTH the DNS entries and more importantly the physical IPs (BGP) depending on your geographical algorithms' etc.
Hang on though, isn't that a managed service provided by Neustar...?
Needless to say, the tech has evolved slightly since 2011!
This blog is fairly old and we have since written some shiny new ones about why GSLB doesn't always suck ; ) .
Check them out here: