Re: 2 Colo's
Kenneth Salchow <[email protected]>
| Newsgroups | gmane.comp.programming.load-balancing.general |
|---|---|
| Message-ID | <4B18A8F75A6384449755BC7784073E93603D33F367@exch11.olympus.f5net.com> |
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: [email protected] [mailto:[email protected]] 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 [email protected] 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
smime.p7s
(application/x-pkcs7-signature, 3 KB) - not displayed