Re: [load balancing] The GSLB Page of Shame

From: P T (
Date: Sun Apr 04 2004 - 17:21:36 EDT


BGP convergence doesn't GSLB happen quick enough to avoid connection
failure, and therefore cannot replace multiple A records for H/A. That's why
most customers use multiple A records. Problem is, multiple A records break
GSLB, and most customers (or vendors) don't know that.

>>It's obvious that GSLB works or vendors wouldn't be selling it,

Vendors are making claims that are technically incorrect, exactly specific
to this issue. The claims are on their Web sites, in their manuals, in their
sales pitches, etc. You are saying all this is well known, but you are
wrong. Look for yourself.


>From: William Bivens <>
>Subject: Re: [load balancing] The GSLB Page of Shame
>Date: Sun, 4 Apr 2004 15:56:07 -0400
>First off, let me state quite simply that my response has nothing to do
>with my current employment, however I'm (NetScaler) on the side of the
>right in that NetScaler doesn't charge for the functionality that you
>As a vendor system engineer my first statement is that in your examples of
>a catastrophic event (Internet connection, power, switching, and/or server
>load balancing failures) without a doubt anyone would be best served using
>BGP4 for high availability.
>Now let me back track a little so you can get a better understanding on my
>position. First, the feature/product is called Global Server Load
>Balancing (GSLB) not Global Site High Availability. Pointing to GSLB as a
>failed HA solution for catastrophic failures is equal to saying that SLB
>(Server Load Balancing) is a complete failure due to a site Database
>failure. So I feel that in general your document has very valid points on
>the High Availability aspects of GSLB however I'm a firm believer that it
>should be combined with BGP4 for any sensitive transactional environment
>where time equals lots of money and I would bet that any
>ReallyBigWellTrustedFinancialSite's have probably rolled out an EBGP
>routed environment before doing a GSLB installation.
>The problem is that your document assumes that the "overwhelmingly most
>compelling reason that Internet sites are hosted in multiple locations is
>high availability". However there are several reasons that companies
>choose GSLB: even load distribution across multiple links, risk
>mitigation to spread Internet load across multiple POPs, site maintenance
>(through planned fail-over), reduce data center costs (colocation
>competition), site/application scalability, and of course site high
>availability to name the majority of reasons but in general I wouldn't
>call it the most compelling reason.
>The reality is most sites/companies/customers don't perform real time data
>synchronization (assuming the application requires it) between
>geographically dispersed data centers without a BGP4 implementation. In
>the last 3 GSLB conversations I've had customers are asking that GSLB NOT
>provide automatic site fail-over and the majority of reasons stated is due
>to the fact that Database work (primarily sycronization) needs to be
>completed before bringing up the cold site online. Anyone who's been
>quoted an EMC SRDF solution and the bandwidth requirements (especially
>across the country/globe) will probably know that real time data
>synchronization in addition to automagic site fail-over on catastrophic
>failure is the design goal, but often times is more costly then the
>application revenue generation during the 30 minute black out of the
>existing IE customers with a DNS cache.
>Now for the business side. Your document states that it's "the
>responsibility of the manufacturer, not the customer, to determine if a
>product adds value remotely close to what is represented in marketing
>claims." Now in general I believe that in all cases marketing claims
>should be responsible, however, to think that "customers" should not be
>responsible for making vendor product selection when the sole purpose of
>the IT/Technical Operations personnel who are being paid by the company to
>provide technical solutions to business problems is a completely
>irresponsible statement on your part, a manufacture cannot know every
>business requirement that will be needed for the entire market that they
>service. If the people that are hired by a company don't take the time to
>do due diligence to evaluate, speak with "like" customer references, and
>have business discussions with Vendor account executives they (customer)
>should be liable for not doing their job. And if the vendor can't provide
>an evaluation or customer references then customer should move on but I
>can't feel responsible for people who make technical decisions off a
>marketing product feature list.
>So for a little constructive criticism on your document, like I've stated
>previously the technical details are pretty tight in general but seem to
>be bias and during my reading I called it a manifesto. Either way it
>comes across as a sort of personal vendetta or a technical sales pitch
>which isn't objective. The biggest problem overall is the there seems to
>be no continuity between the initial claim that no "DNS based GSLB
>solution can function also provide high availability" (which
>probably should be sidenoted/caveated with "during a catastrophic
>failure") and it continues to expand and try to address topics such as:
>Proximity based GSLB on the Internet
>Multiple A records for HA (but at the same time doesn't work for a
>Active-Standby sites)
>HTTP Redirects (which works fine, except someone COULD bookmark)
>GSLB Advertisement Flapping
>IP proxy
>Backup redirection
>Now it's perfectly fine to discuss other topics, the problem is that most
>of these solutions weren't designed to address the catastrophic failures
>that were mentioned in your document so it's entirely unfair to pull out
>the almighty trump-card of "it doesn't work in a catastrophic failure" or
>in the case of GSLB Advertisement Flapping by changing the game to talk
>about outages outside of catastrophic to discredit GSLB health checking.
>It's obvious that GSLB works or vendors wouldn't be selling it, or more
>importantly, companies wouldn't be buying it. The old adage, if you're
>not part of the solution your a part of the problem definitely applies to
>this document. I'd love to see it updated as an informative document that
>shows both sides and tries to propose solutions to a particular scenario,
>but in its current state of "I'm going to pee on all the cheerio's by
>dragging them into unrelated discussions" although informative is not very
>helpful in general.
>Jay Bivens
>NetScaler, Inc.
>System Engineer
>On Apr 1, 2004, at 7:04 AM, P T wrote:
>>Jay, that's just it... there are _no_ workarounds that fix the issues! I
>>thought the paper did a pretty thorough job of explaining why the state
>>of the art workarounds are not sufficient. Did you read it?
>>It's not like any one piece of this information is new, but the sum total
>>of it is definitely not widely known within SLB vendors. For example,
>>several of them, including the current market share leader, have
>>information on their Web sites explaining how they return DNS A records
>>in a list with the "best" IP address first. That doesn't work on the
>>Internet! The DNS gurus laugh in our faces. (Hey, I didn't know it
>>either, how embarrassing!). It's OK to be wrong. As technologists we just
>>learn from mistakes, fix the stuff we build, sell stuff that works,
>>right? So GSLB doesn't work as we all had hoped, and we can't fix it.
>>There's no sense pointing fingers or lamenting about how browser software
>>should change to observe TTLs or SRV records or whatever... even if such
>>fixes were released in software today we would have to live with the
>>installed client base for years. Now we know that, and move on. I hope
>>your company, NetScaler, takes such higher ground.
>>What would really be shameful is for vendors to, after realizing issues
>>such as these, continue promoting features and products that do not work
>>as advertised.
>>>From: William Bivens <>
>>>Subject: Re: [load balancing] The GSLB Page of Shame
>>>Date: Wed, 31 Mar 2004 19:38:08 -0500
>>>It's a shame the GSLB manifesto couldn't be more neutral, it makes some
>>>very valid point. There are several reasons to use GSLB and several
>>>workarounds for the specific problems, it just seems that the author
>>>chose not to highlight or know them.
>>>Jay Bivens
>>>On Mar 30, 2004, at 2:01 PM, P wrote:
>>>>A paper that describes why DNS based GSLB solutions cannot work
>>>>reliably for browser based clients.
>>>The Load Balancing Mailing List
>>>MRTG with SLB:
>>>Hosted by:
>>Free up your inbox with MSN Hotmail Extra Storage. Multiple plans
>>The Load Balancing Mailing List
>>MRTG with SLB:
>>Hosted by:
>The Load Balancing Mailing List
>MRTG with SLB:
>Hosted by:

Watch LIVE baseball games on your computer with MLB.TV, included with MSN

The Load Balancing Mailing List
MRTG with SLB:
Hosted by:

This archive was generated by hypermail 2.1.4 : Wed Jun 16 2004 - 17:28:58 EDT