From: Jesper Srensen (jesIZZATmaerskdata.dk)
Date: Tue Apr 06 2004 - 04:44:56 EDT


Pete,

>Firstly, the objective of this paper was to get information out. I'm not
>selling anything, or competing with any of these products. If customers are
>informed of these caveats/tradeoffs, and still decide to purchase a pair of
>GSLB devices for $60K, great! Then the objective of this paper would be met.
>The customer would have made an informed decision. Problem is, in most cases
>customers are being told they can use multiple A records and simultaneously
>have "control" (as you put it), and/or are not being told about the browser
>caching issue. I'm guilty of personally telling customers this, many who
>listen on this list. (Again, sorry about that, I didn't know!).

I know, I was merly trying to tell people that this can be used, albeit with some drawbacks.

>Secondly, after speaking with hundreds of customers about SLB/GSLB over the
>years, I can't think of a single customer that is both in the market for a
>multi-site H/A (or "business continuity") solution, and is also OK with
>potentially every user having to restart their browser or reboot their
>computer upon a site, Internet connection, power, or SLB-pair, failure -
>especially a high-end customer that would be able to afford such a device.
>Users just don't think "hey, the problem is probably my browser". Clearly
>single sign-on is lost if the server/site blows up (that's in the paper).
>For most sites, that session loss happens even if a single server in a farm
>fails (not even considering multi-site). In that case the user is prompted
>to log on again, and can recover transactions from a shared database.
>Unfortunately, there's no practical way to prompt a user to restart their
>browser, so without multiple A records, for all such users (maybe all
>users), the entire global site appears to be off the Internet.

I know of one company that needs this, unfortunately I can’t tell you the name of that company.

As to the side effects, there are ways of designing your DC's and whole system architecture, so that
this will happen very rarely. You cant get the probability to 0% but you can do 0.1%.

>Thirdly, multiple A records were in use well before Alteon or Cisco or F5 or
>RadWare had GSLB products, and many marquee sites use multiple A records
>(for both multi-site and multi-homed single site), so although what you say
>about "some browsers" is probably technically correct, I think it may
>obfuscate the point in this context - that multiple A records are a
>fundamentally sound and well tested approach.

I totally agree to this, as long as one keeps in mind that some browsers / proxys could (and do) use
those a-records simultaneously. But I think it's safe too assume this is a non issue now and in the
future (crossing my fingers)

>Fourthly, the "control" that can actually be achieved with a DNS based GSLB
>device is way overrated (even ignoring the H/A issue). I purposely avoided
>that topic in this paper, primarily because most GSLB customers these days
>just want active/backup ("business continuity"), don't have a site in
>Zimbabwe, and could care less about proximity/load/etc., but also because
>it's a different subject altogether - maybe a good reason to do a "Why DNS
>Based GSLB Doesn't Work - Part II".

I totally agree.

Basically we agree, stick with multi a-records, dont buy GSLB for GSLB features, they wont work for
you unless you do a lot of redesigning on the frontend / backend side and use a lot of money to
ensure individual DC uptime. And odds are you dont need it anyway.

Best Regards

Jesper Sørensen
----------------------------------------
Mærsk Data A/S
Tlf : + 45 39 11 22 37
Fax : + 45 39 11 27 45
Cell : + 45 29 49 54 90
MCS : CPHMDATA,COM
----------------------------------------

                                                                                                                             
              "P T"
              <pt_lbIZZAThotmail.c To: lb-lIZZATvegan.net
              om> cc:
              Sent by: Subject: Re: [load balancing] The GSLB Page of Shame
                                                                                                                             
                                                                                                                             
              owner-lb-lIZZATvegan
              .net
                                                                                                                             
                                                                                                                             
              05-04-2004 17:09
              Please respond
              to lb-l
                                                                                                                             
                                                                                                                             
                                                                                                                             

Jesper,

Firstly, the objective of this paper was to get information out. I'm not
selling anything, or competing with any of these products. If customers are
informed of these caveats/tradeoffs, and still decide to purchase a pair of
GSLB devices for $60K, great! Then the objective of this paper would be met.
The customer would have made an informed decision. Problem is, in most cases
customers are being told they can use multiple A records and simultaneously
have "control" (as you put it), and/or are not being told about the browser
caching issue. I'm guilty of personally telling customers this, many who
listen on this list. (Again, sorry about that, I didn't know!).

Secondly, after speaking with hundreds of customers about SLB/GSLB over the
years, I can't think of a single customer that is both in the market for a
multi-site H/A (or "business continuity") solution, and is also OK with
potentially every user having to restart their browser or reboot their
computer upon a site, Internet connection, power, or SLB-pair, failure -
especially a high-end customer that would be able to afford such a device.
Users just don't think "hey, the problem is probably my browser". Clearly
single sign-on is lost if the server/site blows up (that's in the paper).
For most sites, that session loss happens even if a single server in a farm
fails (not even considering multi-site). In that case the user is prompted
to log on again, and can recover transactions from a shared database.
Unfortunately, there's no practical way to prompt a user to restart their
browser, so without multiple A records, for all such users (maybe all
users), the entire global site appears to be off the Internet.

Thirdly, multiple A records were in use well before Alteon or Cisco or F5 or
RadWare had GSLB products, and many marquee sites use multiple A records
(for both multi-site and multi-homed single site), so although what you say
about "some browsers" is probably technically correct, I think it may
obfuscate the point in this context - that multiple A records are a
fundamentally sound and well tested approach.

Fourthly, the "control" that can actually be achieved with a DNS based GSLB
device is way overrated (even ignoring the H/A issue). I purposely avoided
that topic in this paper, primarily because most GSLB customers these days
just want active/backup ("business continuity"), don't have a site in
Zimbabwe, and could care less about proximity/load/etc., but also because
it's a different subject altogether - maybe a good reason to do a "Why DNS
Based GSLB Doesn't Work - Part II".

Pete.
http://www.tenereillo.com/GSLBPageOfShame.htm
(score - 2 people guessed Tasmanian Devil, nobody guessed Bing)

>From: Jesper Sørensen <jesIZZATmaerskdata.dk>
>Reply-To: lb-lIZZATvegan.net
>To: lb-lIZZATvegan.net
>Subject: Re: [load balancing] The GSLB Page of Shame
>Date: Mon, 5 Apr 2004 09:52:16 +0200
>
>
>
>
>
>I've been following the discussion, and I feel the urge to jump into it :D
>
>Let's assume that the application is statefull.
>
>What happens in a multi a-record setup, when a single site has a disaster?
>- Well any user currently
>connected to that site, will have to relogon and everything they did is
>properly gone.
>
>Let's assume we have some backend replication, so that in case of a site
>disaster the user is able
>to connect to a different site without having to relogon.
>
>Site fails, user don’t even know it.
>
>Let’s do the same with a GLSB setup.
>
>Site fails; user has to restart browser. And then relogon and redo what he
>/ she was doing.
>
>So why would anyone do GSLB? Simply put: Control
>
>Who needs control? Or why would anyone need that kind of control?
>
>Well the Internet spans the World, and in many countries, especially
>emerging economies, the
>connections to the rest of the world are painfully slow. If these countries
>are important to you,
>then you need control. If not then go with a multi a-record setup, and live
>happily ever after (with
>a bit of luck)
>
>One last thing, multi a-records aren’t all that good - Some browsers will
>happily connect
>simultaneously to two or more of the IP’s returned.
>
>Best Regards
>
>Jesper Sørensen
>----------------------------------------
>Mærsk Data A/S
>Tlf : + 45 39 11 22 37
>Fax : + 45 39 11 27 45
>Cell : + 45 29 49 54 90
>MCS : CPHMDATA,COM
>----------------------------------------
>
>
>
> "P T"
> <pt_lbIZZAThotmail.c To: lb-lIZZATvegan.net
> om> cc:
> Sent by: Subject: Re: [load balancing] The
>GSLB Page of Shame
>
>
> owner-lb-lIZZATvegan
> .net
>
>
> 05-04-2004 01:30
> Please respond
> to lb-l
>
>
>
>
>
>
>
>Jay,
>
>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.
>
>
>Pete.
>http://www.tenereillo.com/GSLBPageOfShame.htm
>
>
>
> >From: William Bivens <wjbivensIZZATdigitalme.com>
> >Reply-To: lb-lIZZATvegan.net
> >To: lb-lIZZATvegan.net
> >Subject: Re: [load balancing] The GSLB Page of Shame
> >Date: Sun, 4 Apr 2004 15:56:07 -0400
> >
> >Pete,
> >
> >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
> >describe.
> >
> >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 properly...to 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
> >Triangulation
> >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.
> >
> >Sincerely,
> >
> >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.
> >>
> >>
> >>
> >>Pete.
> >>
> >>
> >>>From: William Bivens <wjbivensIZZATdigitalme.com>
> >>>Reply-To: lb-lIZZATvegan.net
> >>>To: lb-lIZZATvegan.net
> >>>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.
> >>>
> >>>Sincerely,
> >>>
> >>>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.
> >>>>
> >>>>
> >>>>
> >>>>http://www.tenereillo.com/GSLBPageOfShame.htm
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Pete.
> >>>>
> >>>>
> >>>
> >>>
> >>>____________________
> >>>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
> >>>
> >>
> >>_________________________________________________________________
> >>Free up your inbox with MSN Hotmail Extra Storage. Multiple plans
> >>available.
>http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/
> >>onm00200362ave/direct/01/
> >>
> >>____________________
> >>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
> >
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar – get it now!
>http://toolbar.msn.com/go/onm00200415ave/direct/01/
>
>____________________
>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
>

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN
Premium!
http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/

____________________
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 : Wed Jun 16 2004 - 17:28:58 EDT