Re: DNS Based Load Balancers
There is a new player on the block that I see more and more http://www.infoblox.com/company/ -Henry - Original Message From: Paul Vixie [EMAIL PROTECTED] To: nanog@merit.edu Sent: Wednesday, July 5, 2006 11:16:39 AM Subject: Re: DNS Based Load Balancers As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. since works flawlessly could just mean that you don't have any reported problems with the technology -- no complaints from your users, no bugs logged with your vendor, etc, i have two bracketing questions. first, have you measured the improvement you got -- in terms of min/max/avg/stddev of TTFB/TTLB (time to first byte / last byte) with the appliances turned on vs. turned off? second, have you measured the dns damage your gslb might cause or contribute to, due to things not responding to unhandled QTYPES ( comes to mind) or use of abnormally low DNS TTL? i'm not as much interested in whether a technology causes no problems for its operator as whether its cost:benefit is worthwhile to the internet community. -- Paul Vixie
Re: DNS Based Load Balancers
There is a new player on the block that I see more and more http://www.infoblox.com/company/ infoblox isn't new. i'm familiar with them since they use BIND as their DNS protocol engine, and are long time members of the ISC BIND Forum. i recently did colour commentary for an o'reilly/infoblox webinar (see http://infoblox.market2lead.com/go/dnsbind5 for more info on that.) most importantly to this thread, infoblox doesn't offer GSLB, they just do network identity (dhcp, dns, ldap, that kind of thing) on an appliance platform. folks seem to like it pretty well. (i wonder if ISC should print up some BIND Inside stickers? :-))
RE: DNS Based Load Balancers
Title: RE: DNS Based Load Balancers What would be a better solution then? -Original Message- From: Lincoln Dale [mailto:[EMAIL PROTECTED]] Sent: Tue Jul 04 18:30:00 2006 To: 'Rodrick Brown'; 'Sam Stickland' Cc: 'Matt Ghali'; 'Patrick W. Gilmore'; nanog@merit.edu Subject: RE: DNS Based Load Balancers As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. GSLB based on DNS have one significant shortcoming that moone here has yet mentioned: they are performing their magic on the location of the _nameserver_ that issued the query. this can be VERY different to that of the ACTUAL location of the client. for example, Akamai always sends to off to a serverfarm in Northern California, because that's where my DNS query is originating from. that is almost the exact opposite side of the planet from where I'm coming from... irony is that there is an akamai cluster about 10 feet away from where my [subsequent] http requests originate from... sure - perhaps this isn't the norm - split-tunnel VPNs being what they are - but it's a perfect example of why GSLB based on DNS ain't perfect. cheers, lincoln.
RE: DNS Based Load Balancers
but it's a perfect example of why GSLB based on DNS ain't perfect. What would be a better solution then? utopia would be for DNS to be enhanced in some manner such that the 'end user ip-address' became visible in the DNS request. utopia would have NAT devices which actually updated that in-place so an authoritive nameserver always authoritively _knew_ the public ip-address of where the request was coming from. alas, we don't live in utopia and have to settle for alternate solutions. one such approach is rely on protocol-specific mechanisms. e.g. if its HTTP, then something at HTTP. oh wait - that won't deal with HTTP proxies either - but at least there is some standardization on HTTP headers that proxies insert giving a hint of the original client ip-address. there are other approaches also. a few years back when i spent a fair bit of time in this area, my experience is that a hybrid system based on specific protocol and generic solution (dns) worked best. this simply isn't an area where one solution fits all cases. there are public companies whose business model depends on this being 'hard' to do right. them being capable of doing something 'better' than not all all is the reason they are still in business. i did a fair bit of research in this area as part of work i used to do a few years back. much of that research belongs to my employer - i thought it was documented publicly in the form of a patent i am a co-inventor of - but alas, i can't seem to find it on uspto.gov .. perhaps it hasn't been issued yet .. i haven't tracked these things for years. in either case, i guess its an example of where even commercial entities whose business model depends on 'getting it right' most of the time do indeed 'get it wrong' also. cheers, lincoln.
RE: DNS Based Load Balancers (redux)
Stepping back for a moment...Many (most) popular services end up in multiple data centers first because they want to get diversity (of data centers, of ISPs, maybe of pricing). All mission critical sites will be designed such a subset of these data centers can take their entire load if need be.Once spread out this way - you may need to run some or all of them in an active/active configuration so you need to balance load between them in some fashion between them.If you are going to split the load - a natural desire is to split it such that it actually increases performance for users. You figure network proximity (of the end user to the serving destination) ought to be a criteria -but the load on your cluster may be more important for personalization intensive sites.You start with round robin DNS but it leaves you unsatisfied along the way. You play around with souped up DNS servers that are fed with monitoring tools that measure reachability as well as some measure of load. You also discover that the most popular browser will gladly ignore your TTL settings and insist on sending your traffic to the data center that is down. You are frustrated when you find out that users of ISP A are being served out of your Data Center at ISP B, even though you have a data center connected to ISP A. You think Anycast might be the answer but not everyone is set up to do Anycast. You find some clever people have been aggregating data that will offer to geolocate your callers IP addresses and maybe there is a way to use that information to find the nearest server. You realize the accuracy of this list is dubious, the exchange points for several countries may actually be on the coasts of the United States, and how would you integrate this into your DNS or HTTP redirector, while still doing 2 shift day job.You turn to alternatives, and find the shiny boxes and/or services called the GLBS. They perform 2 main services.First, they hand out answers, which may vary in time and space, to your clients as to where to find the service they are looking for.Second, they decide what this "right" answer is.You post to NANOG and you get admonished about their efficacy on both counts. This is initially wrapped in appeals to love of God and country and general harm that might befall mankind but no one says what or why.On reflection, objections to the first part of this are usually along the "strict constructionist" point of view. No real harm comes from returning changing answers but when the Man who wrote the book jumps in with both feet you take pause. He chides people for using stupid tricks. You wonder if they are stupid in the same way as the "For Dummies" series of books is not really for dummies.Objections to the determination of what the "right" answer is are more vociferous. Some immediately take the view that since the question was about DNS based load balancers, the inference was that the GLBS must be using DNS logistics to decide what the right answer is, even though DNS may simply be used to "right communicate the right answer ( the first part) , but not calculated ( the second part).The GLBS may indeed be using some measure of server load, or even BGP derived network maps, or some other knowledge of topology or proximity but that gets drowned in the "the proximity of the DNS resolver to the GLBS is not a proxy for the actual end user". The latter is actually strictly true, and it is difficult to argue given the specific examples of where it fails, but no one is able to say how many times in normal use this technique actually returns a bad answer.You even hear from a man with one leg in US and one in Europe using a split tunnel VPN who wonders why when he orders Pizza using his tunnel to the HQ back in Europe, he doesn't get greasy satisfaction back in the US. You wonder what happens when he calls 911 on his VOIP phone, without having manually configured his PSAP in that configuration, but you have other problems to worry about at the moment. You also hear about the "AOL Proxy" effect masking all users behind it. Well actually you don't hear that, but someone should have chimed in about that.You hear some mumbling about the use of AS path lengths or a geo-location database of end user IPs not being a true measure. Yet you wonder if the Internet is actually not getting more stable everyday and that the nominal topology and the AS Paths for the more heavily trafficked routes may actually not change that rapidly in normal course.You also hear from others who have been using variations of GLBS for several years, and have even created large businesses by serving their customers this way. Their web sites are full of gleaming testimonials from these customers. Some one says no one got fired for using the GLBS... You wonder if those customers just bought insurance. You scratch your head some more. You w
Re: DNS Based Load Balancers
On Jul 5, 2006, at 5:18 AM, Lincoln Dale wrote: but it's a perfect example of why GSLB based on DNS ain't perfect. What would be a better solution then? utopia would be for DNS to be enhanced in some manner such that the 'end user ip-address' became visible in the DNS request. utopia would have NAT devices which actually updated that in-place so an authoritive nameserver always authoritively _knew_ the public ip- address of where the request was coming from. That would kill all cacheability of DNS. Split tunnel VPNs do somewhat break the DNS GSLB model, but I don't think that's as bad as anti-DNS GSLB people claim it is. If you were on a full- tunnel VPN, you would expect to be sent to nocal, right? This could also be fixed in split tunnel VPNs with a local DNS proxy that only used the DNS cache on the other side of the VPN for the internal domains, and your ISP's DNS cache for everything else. That proxy could even be built into your VPN client. With wide open recursive nameservers getting such bad press lately, I would expect to see client - caching nameserver proximity getting a lot closer.
RE: DNS Based Load Balancers
GSLB based on DNS have one significant shortcoming that moone here has yet mentioned: they are performing their magic on the location of the _nameserver_ that issued the query. this can be VERY different to that of the ACTUAL location of the client. Systems that infer stuff make errors, at least DNS GSLB fails working I've seen problems with DRM that assumed the IP requesting http would be the same as that requesting rtsp, neither of which were the actual client after some ISP caching. for example, Akamai always sends to off to a serverfarm in Northern California, because that's where my DNS query is originating from. that is almost the exact opposite side of the planet from where I'm coming from... That's more a failure of your systems than Akamai, depending on something the other side of the planet for something best done locally irony is that there is an akamai cluster about 10 feet away from where my [subsequent] http requests originate from... yes, like a free ride when you've already paid I don't see any point arguing over DNS GSLB. It exists, it can work, and no surprise some products aren't well designed. We've used a DNS GSLB system since 1997, it does the job we designed it to, it has the edge cases we expected, we're happy with it. Don't try using one without adult supervision The hardware SLB products we've tried have caused more down time than our DNS LB brandon
RE: DNS Based Load Balancers
John Payne wrote: On Jul 5, 2006, at 5:18 AM, Lincoln Dale wrote: utopia would be for DNS to be enhanced in some manner such that the 'end user ip-address' became visible in the DNS request. utopia would have NAT devices which actually updated that in-place so an authoritive nameserver always authoritively _knew_ the public ip- address of where the request was coming from. That would kill all cacheability of DNS. Only if you envision an extension that adds an 'end user IP address' to the query and doesn't add a 'scope of cacheability' to the reply. I admit it's possible that an extension could be bungled that badly, but not likely. DS
Re: DNS Based Load Balancers
As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. since works flawlessly could just mean that you don't have any reported problems with the technology -- no complaints from your users, no bugs logged with your vendor, etc, i have two bracketing questions. first, have you measured the improvement you got -- in terms of min/max/avg/stddev of TTFB/TTLB (time to first byte / last byte) with the appliances turned on vs. turned off? second, have you measured the dns damage your gslb might cause or contribute to, due to things not responding to unhandled QTYPES ( comes to mind) or use of abnormally low DNS TTL? i'm not as much interested in whether a technology causes no problems for its operator as whether its cost:benefit is worthwhile to the internet community. -- Paul Vixie
Re: DNS Based Load Balancers
What would be a better solution then? multiple A RR's for your web service, each leading to an independent web server (which might be leased capacity rather than your own hardware), each having excellent (high bandwidth, low latency, etc) connectivity to a significant part of the internet. the law of averages is a good friend to those who can adequately provision, so the likely outcome is that you won't need anything fancy. but if you need something fancy, use session level redirects to tell a web browser or sip client that there's a better and closer place for them to get their service. pundits please note that the fancy thing i'm recommending sit perfectly on top of the non-fancy thing i'm recommending. -- Paul Vixie
Re: DNS Based Load Balancers
On Sun, 2 Jul 2006, Patrick W. Gilmore wrote: Would you mind giving us a little more to go on than the love of god before making strategic architectural decisions? Just in case we like to decide things for ourselves. :) Patrick, I am sorry if I have hit a nerve with you- it seems you've got a vested interest in the answer to this question, and I appreciate your position. For instance, was F5's implementation flawed, or do you have a reason to dislike the basic idea? And why? For the record, what I _should_ have advised the OP was for the love of god, don't try to do this yourself with an appliance. I wholeheartedly encourage him to give his local Akamai sales rep a call. I am sorry for the confusion and angst my brevity has caused. cheers, matto [EMAIL PROTECTED]darwin Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
RE: DNS Based Load Balancers
Matt, A few quick questions for you, if you got the time to answer it would be appreciated (questions inline): -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ghali Sent: 04 July 2006 07:21 To: Patrick W. Gilmore Cc: nanog@merit.edu Subject: Re: DNS Based Load Balancers On Sun, 2 Jul 2006, Patrick W. Gilmore wrote: Would you mind giving us a little more to go on than the love of god before making strategic architectural decisions? Just in case we like to decide things for ourselves. :) Patrick, I am sorry if I have hit a nerve with you- it seems you've got a vested interest in the answer to this question, and I appreciate your position. For instance, was F5's implementation flawed, or do you have a reason to dislike the basic idea? And why? For the record, what I _should_ have advised the OP was for the love of god, don't try to do this yourself with an appliance. I wholeheartedly encourage him to give his local Akamai sales rep a call. I am sorry for the confusion and angst my brevity has caused. We work with a couple of different technologies here - our own GSS's, cache farms and also external CDNs (for overflow). This is currently and area that is currently under evaluation for a quite significant expansion. Are you able to give some kind of description as to the problems you experienced whilst using your own appliances? It would be very useful to be able to avoid making the same mistakes. Sam
Re: DNS Based Load Balancers
On 7/4/06, Sam Stickland [EMAIL PROTECTED] wrote: Matt, A few quick questions for you, if you got the time to answer it would be appreciated (questions inline): -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ghali Sent: 04 July 2006 07:21 To: Patrick W. Gilmore Cc: nanog@merit.edu Subject: Re: DNS Based Load Balancers On Sun, 2 Jul 2006, Patrick W. Gilmore wrote: Would you mind giving us a little more to go on than the love of god before making strategic architectural decisions? Just in case we like to decide things for ourselves. :) Patrick, I am sorry if I have hit a nerve with you- it seems you've got a vested interest in the answer to this question, and I appreciate your position. For instance, was F5's implementation flawed, or do you have a reason to dislike the basic idea? And why? For the record, what I _should_ have advised the OP was for the love of god, don't try to do this yourself with an appliance. I wholeheartedly encourage him to give his local Akamai sales rep a call. I am sorry for the confusion and angst my brevity has caused. We work with a couple of different technologies here - our own GSS's, cache farms and also external CDNs (for overflow). This is currently and area that is currently under evaluation for a quite significant expansion. Are you able to give some kind of description as to the problems you experienced whilst using your own appliances? It would be very useful to be able to avoid making the same mistakes. Sam As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. -- Rodrick R. Brown
RE: DNS Based Load Balancers
As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. GSLB based on DNS have one significant shortcoming that moone here has yet mentioned: they are performing their magic on the location of the _nameserver_ that issued the query. this can be VERY different to that of the ACTUAL location of the client. for example, Akamai always sends to off to a serverfarm in Northern California, because that's where my DNS query is originating from. that is almost the exact opposite side of the planet from where I'm coming from... irony is that there is an akamai cluster about 10 feet away from where my [subsequent] http requests originate from... sure - perhaps this isn't the norm - split-tunnel VPNs being what they are - but it's a perfect example of why GSLB based on DNS ain't perfect. cheers, lincoln.
Re: DNS Based Load Balancers
On Jul 3, 2006, at 12:09 AM, Paul Vixie wrote: well, i see that fezhead is dead. but 3-party TCP is alive and well: http://www.cs.bu.edu/~best/res/projects/DPRClusterLoadBalancing/. see also http://www.tenereillo.com/GSLBPageOfShame.htm and http://www.tenereillo.com/GSLBPageOfShameII.htm. Paul - I'm still eagerly waiting your reply to Patrick's questions. Here at least we finally have something to read other than relying on blind faith, but the author is so convinced DNS based GSLB doesn't work[1] (and gives good examples of why it doesn't). However, these are all pretty much theoretical examples, and there's no explanation of why DNS based CDNs do in fact work so well in practice[2]. [1] FSVO doesn't work that is... [2] I was going to say appear to work so well, but that's unfair use of sarcasm - I know just how well at least one CDN works :)
RE: DNS Based Load Balancers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Monday, July 03, 2006 12:09 AM To: nanog@merit.edu Subject: Re: DNS Based Load Balancers The problem being that most of what you linked to below is either A) out of date, or B) the only way to get proximity based load balancing (GSLB type stuff) with them is with DNS tricks. =20 most of, huh? let's have a looksie. Breaking it down in order: The IBM solution hasn't been updated since 1999. It also seems relatively proprietary. the ibm white paper i referred you to was writteh in 1999. websphere is quite current, and its implementation of GSLB functionality has been updated plenty since 1999. and the competitors james baldwin said he was eval'ing (cisco, f5) are certainly patent-holders offering proprietary solutions. The Cisco solution relies on either doing HTTP redirects (which is useless if you're not doing HTTP) or DNS. =20 james baldwin said he was using the cisco solution today, so clearly HTTP is the main target. i can't think of a protocol requiring GSLB that isn't HTTP based (either web browsing or web services). FTP just isn't a growth industry and the transaction processing systems i know of (the ones that aren't based on HTTP, that is) have GSLB hooks built into them. IOW, either you can do GSLB with session redirects, or you don't need GSLB. Both Foundry and Radware rely 100% on DNS to do their GSLB. You can do local load balancing on both boxes without, however. did you read the same radware white paper i did? in http://www.radware.com/content/products/library/faq_wsd.pdf it says that they can do session level redirects. so, less than 100% of radware is dns. i can see that i misread the foundry whitepaper i ref'd (perhaps we both saw most readily that data which fit our preconceptions?) The last link is an outdated thesis paper that makes reference moreso to local load balancing and not global. why is it outdated? as a survey of the desired functionality it's still pretty good background. no new GSLB has been invented since then, surely? It seems that in lieu of a real, currently produced solution, the only option is presently DNS to meet the requirements. Others have sent me off-list stuff they're working on, but none of it's ready for prime time. =20 well, i see that fezhead is dead. but 3-party TCP is alive and well: http://www.cs.bu.edu/~best/res/projects/DPRClusterLoadBalancing/. see also http://www.tenereillo.com/GSLBPageOfShame.htm and http://www.tenereillo.com/GSLBPageOfShameII.htm. the references sections of those last three are particularly informative. -- Paul Vixie Without getting into a massive back and forth, I just want to make 3 points: 1) Websphere is proprietary to IBM and requires their servers. It's not scalable to other applications. It's also not targeted to the same market as, say, F5. 2) There are definitely protocols that require GSLB that aren't HTTP. Off the top of my head: RTSP/MMS, VoIP services. I'd say that, at the very least, VoIP protocols are the killer app for GSLB moreso than HTTP. Surely the internet isn't only the web, right? 3) TCP-redirect solutions, such as the Radware one you pointed out, do not work in large scales. Have you ever met anyone who's actually implemented that in a large scale? The solution they point to they don't even sell anymore (the WSD-DS/NP). If you talk to their sales, they'll point you at the DNS based solution because they know that doing Triangulation is a joke. Triangulation and NAT-based methods both crumble under any sort of DoS and provide no site isolation. Pete Tenereillo's papers are interesting, but they're also slanted and ignore other implementation methods of DNS GSLB. How about handing out NS records instead of A records? That's an method that would make large parts of his papers irrelevant. My main point here is that each solution has it's evils, and when faced with a choice, he needs to evaluate what method works best for him. Anyone could just as easily say that Triangulation and NAT are a hack just the same as GSLB DNS is a hack. Akamai and UltraDNS will actually sell you GSLB without even buying localized hardware to do it - are these bad services, too? Patrick said it best: Just in case we like to decide things for ourselves. -Dave
Re: DNS Based Load Balancers
Without getting into a massive back and forth, I just want to make 3 points: as long as the back-and-forth remains informative and constructive, i'll play: 1) Websphere is proprietary to IBM and requires their servers. It's not scalable to other applications. It's also not targeted to the same market as, say, F5. websphere is a trade name for a family of products and services. the GSLB component is able to play as a proxy to someone else's web server. (don't take my word for it, call an ibm salesweenie.) 2) There are definitely protocols that require GSLB that aren't HTTP. Off the top of my head: RTSP/MMS, VoIP services. I'd say that, at the very least, VoIP protocols are the killer app for GSLB moreso than HTTP. Surely the internet isn't only the web, right? according to http://www.isc.org/pubs/tn/isc-tn-2004-2.html, the internet is much larger than the web. but i'm not sure what you're replying to. i said that session level redirection would be possible in all cases where GSLB was needed. voip has session level redirection (several kinds). 3) TCP-redirect solutions, such as the Radware one you pointed out, do not work in large scales. Have you ever met anyone who's actually implemented that in a large scale? The solution they point to they don't even sell anymore (the WSD-DS/NP). If you talk to their sales, they'll point you at the DNS based solution because they know that doing Triangulation is a joke. Triangulation and NAT-based methods both crumble under any sort of DoS and provide no site isolation. i did not know radware has given up on wsd. but i don't see an explaination of what you mean by not work in large scales beyond radware gave up. i gave another reference to third-party TCP, have you looked at it or surveyed the rest of the field to find out how assymetric IP (satellite downlink, terrestrial uplink) and third-party TCP is working for the various pacific islands who depend on it? Pete Tenereillo's papers are interesting, but they're also slanted and ignore other implementation methods of DNS GSLB. How about handing out NS records instead of A records? That's an method that would make large parts of his papers irrelevant.=20 just as one can always find an example that supports one's preconceptions, one can always find a single counterexample that will support one's prejudices. i'm sure that any technology can be successfully demo'd or successfully counter-demo'd. this conversation started out as what DNS GSLB should i use? and then if DNS GSLB is such a bad idea then what do you propose as an alternative? and now it's every alternative has known failure modes that are as bad as DNS GSLB's worst case. does that mean we're done with the informative and constructive part of this thread? My main point here is that each solution has it's evils, and when faced with a choice, he needs to evaluate what method works best for him. Anyone could just as easily say that Triangulation and NAT are a hack just the same as GSLB DNS is a hack. Akamai and UltraDNS will actually sell you GSLB without even buying localized hardware to do it - are these bad services, too? Patrick said it best: Just in case we like to decide things for ourselves. nobody ever got fired for buying akamai's or ultradns's DNS GSLB services, that's for sure. -- Paul Vixie
RE: DNS Based Load Balancers
just as one can always find an example that supports one's preconceptions, one can always find a single counterexample that will support one's prejudices. i'm sure that any technology can be successfully demo'd or successfully counter-demo'd. this conversation started out as what DNS GSLB should i use? and then if DNS GSLB is such a bad idea then what do you propose as an alternative? and now it's every alternative has known failure modes that are as bad as DNS GSLB's worst case. does that mean we're done with the informative and constructive part of this thread? I don't think anyone disagrees with you there. I just felt that any comprehensive answer should go beyond DNS GSLB is broken, don't use it. As someone who administers a rather large both appliance and service provider based GSLB network, as well as someone who's administered triangulation and BGP-based methods in the past, I can honestly say that thus far the DNS implementation has been far less broken.. Does that mean that someone else feels differently? I sure hope so. My main point here is that each solution has it's evils, and when faced with a choice, he needs to evaluate what method works best for him. Anyone could just as easily say that Triangulation and NAT are a hack just the same as GSLB DNS is a hack. Akamai and UltraDNS will actually sell you GSLB without even buying localized hardware to do it - are these bad services, too? Patrick said it best: Just in case we like to decide things for ourselves. nobody ever got fired for buying akamai's or ultradns's DNS GSLB services, that's for sure. Very true, but does that mean they're a viable alternative for him? Or are they just as broken as hardware vendor GSLB? The local load balancing piece can be served by any number of hardware appliances or software products. -Dave
RE: DNS Based Load Balancers
So, you guys have been pretty clear on what he shouldn't do. What should he do as an alternative to using DNS for a proximity based solution? -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ghali Sent: Saturday, July 01, 2006 10:43 PM To: Paul Vixie Cc: nanog@merit.edu Subject: Re: DNS Based Load Balancers On Sat, 1 Jul 2006, Paul Vixie wrote: I'm soliciting recommendations for DNS based load balancers. my recommendation is: don't do it. for background, see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02168. html http://www.cctec.com/maillists/nanog/current/msg03572.html http://www.cctec.com/maillists/nanog/current/msg00671.html -- Paul Vixie Having implemented F5's 3DNS product for a large entertainment company, I'd like to wholeheartedly agree with Paul. Please, for the love of god, don't do it. matto [EMAIL PROTECTED]darwin Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
Re: DNS Based Load Balancers
On Jul 1, 2006, at 2:53 PM, Paul Vixie wrote: I'm soliciting recommendations for DNS based load balancers. my recommendation is: don't do it. for background, see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg02168.html http://www.cctec.com/maillists/nanog/current/msg03572.html http://www.cctec.com/maillists/nanog/current/msg00671.html In the above posts, you claim it is a protocol violation. Would you mind pointing out exactly which part of the protocol has been violated? Specifically, I do not see where offering back a different rrset based on criteria like source ip address ... is a protocol violation [quote from Paul Vixie, second URL above] violates the protocol. However, I do admit you know more about the protocol than I do, so could you please educate us? Also, I note that Stupid DNS tricks have been in use for at least a decade now and seem to work just fine. A significant fraction of Internet traffic is based on these tricks, so it can't be horrifically bad. Of course, the 'Net is resilient, so the fact doing X has not killed the Internet does not prove X is good. However, Paul saying X is bad does not prove X is bad either. So let's have the logic behind your statement that these tricks are somehow bad for the Internet. One strong way to say things are bad is if everyone did it, it would take down the Internet. I submit that the Internet would not die if everyone did this. I also submit it is better than relying on BGP to load balance. If you care to argue any of those points, I'll be happy to explain my reasoning. Otherwise, I think the onus is on you to support your claim. -- TTFN, patrick
Re: DNS Based Load Balancers
[EMAIL PROTECTED] (David Temkin) writes: So, you guys have been pretty clear on what he shouldn't do. What should he do as an alternative to using DNS for a proximity based solution? http://www.redbooks.ibm.com/redbooks/pdfs/sg245858.pdf http://www.cisco.com/univercd/cc/td/doc/product/iaabu/distrdir/dd2501/ovr.htm http://www.radware.com/content/products/library/faq_wsd.pdf http://www.foundrynet.com/solutions/appNotes/GSLB.html http://www.ifi.unizh.ch/ifiadmin/staff/rofrei/DA/DA_Arbeiten_2000/Masutti_Oliver.pdf note that several of these describe or offer a dns-based solution as an option, but they all describe session-level redirection and most recommend that (as i do) and some even say using dns for this is bad (as i do, but for different reasons.) -- Paul Vixie
RE: DNS Based Load Balancers
The problem being that most of what you linked to below is either A) out of date, or B) the only way to get proximity based load balancing (GSLB type stuff) with them is with DNS tricks. Breaking it down in order: The IBM solution hasn't been updated since 1999. It also seems relatively proprietary. The Cisco solution relies on either doing HTTP redirects (which is useless if you're not doing HTTP) or DNS. Both Foundry and Radware rely 100% on DNS to do their GSLB. You can do local load balancing on both boxes without, however. The last link is an outdated thesis paper that makes reference moreso to local load balancing and not global. It seems that in lieu of a real, currently produced solution, the only option is presently DNS to meet the requirements. Others have sent me off-list stuff they're working on, but none of it's ready for prime time. -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Sunday, July 02, 2006 2:03 PM To: nanog@merit.edu Subject: Re: DNS Based Load Balancers [EMAIL PROTECTED] (David Temkin) writes: So, you guys have been pretty clear on what he shouldn't do. What should he do as an alternative to using DNS for a proximity based solution? http://www.redbooks.ibm.com/redbooks/pdfs/sg245858.pdf http://www.cisco.com/univercd/cc/td/doc/product/iaabu/distrdir /dd2501/ovr.htm http://www.radware.com/content/products/library/faq_wsd.pdf http://www.foundrynet.com/solutions/appNotes/GSLB.html http://www.ifi.unizh.ch/ifiadmin/staff/rofrei/DA/DA_Arbeiten_2 000/Masutti_Oliver.pdf note that several of these describe or offer a dns-based solution as an option, but they all describe session-level redirection and most recommend that (as i do) and some even say using dns for this is bad (as i do, but for different reasons.) -- Paul Vixie
Re: DNS Based Load Balancers
On Jul 1, 2006, at 10:42 PM, Matt Ghali wrote: On Sat, 1 Jul 2006, Paul Vixie wrote: my recommendation is: don't do it. for background, see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg02168.html http://www.cctec.com/maillists/nanog/current/msg03572.html http://www.cctec.com/maillists/nanog/current/msg00671.html Having implemented F5's 3DNS product for a large entertainment company, I'd like to wholeheartedly agree with Paul. Please, for the love of god, don't do it. Would you mind giving us a little more to go on than the love of god before making strategic architectural decisions? Just in case we like to decide things for ourselves. :) For instance, was F5's implementation flawed, or do you have a reason to dislike the basic idea? And why? -- TTFN, patrick
RE: DNS Based Load Balancers
On Sun, 2 Jul 2006, David Temkin wrote: So, you guys have been pretty clear on what he shouldn't do. What should he do as an alternative to using DNS for a proximity based solution? was it proximity or just loadbalancing he was trying to accomplish? I didn't hear/see which was the purpose actually :(
Re: DNS Based Load Balancers
The problem being that most of what you linked to below is either A) out of date, or B) the only way to get proximity based load balancing (GSLB type stuff) with them is with DNS tricks. =20 most of, huh? let's have a looksie. Breaking it down in order: The IBM solution hasn't been updated since 1999. It also seems relatively proprietary. the ibm white paper i referred you to was writteh in 1999. websphere is quite current, and its implementation of GSLB functionality has been updated plenty since 1999. and the competitors james baldwin said he was eval'ing (cisco, f5) are certainly patent-holders offering proprietary solutions. The Cisco solution relies on either doing HTTP redirects (which is useless if you're not doing HTTP) or DNS. =20 james baldwin said he was using the cisco solution today, so clearly HTTP is the main target. i can't think of a protocol requiring GSLB that isn't HTTP based (either web browsing or web services). FTP just isn't a growth industry and the transaction processing systems i know of (the ones that aren't based on HTTP, that is) have GSLB hooks built into them. IOW, either you can do GSLB with session redirects, or you don't need GSLB. Both Foundry and Radware rely 100% on DNS to do their GSLB. You can do local load balancing on both boxeswithout, however. did you read the same radware white paper i did? in http://www.radware.com/content/products/library/faq_wsd.pdf it says that they can do session level redirects. so, less than 100% of radware is dns. i can see that i misread the foundry whitepaper i ref'd (perhaps we both saw most readily that data which fit our preconceptions?) The last link is an outdated thesis paper that makes reference moreso to local load balancing and not global. why is it outdated? as a survey of the desired functionality it's still pretty good background. no new GSLB has been invented since then, surely? It seems that in lieu of a real, currently produced solution, the only option is presently DNS to meet the requirements. Others have sent me off-list stuff they're working on, but none of it's ready for prime time. =20 well, i see that fezhead is dead. but 3-party TCP is alive and well: http://www.cs.bu.edu/~best/res/projects/DPRClusterLoadBalancing/. see also http://www.tenereillo.com/GSLBPageOfShame.htm and http://www.tenereillo.com/GSLBPageOfShameII.htm. the references sections of those last three are particularly informative. -- Paul Vixie
Re: DNS Based Load Balancers
I'm soliciting recommendations for DNS based load balancers. my recommendation is: don't do it. for background, see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02168.html http://www.cctec.com/maillists/nanog/current/msg03572.html http://www.cctec.com/maillists/nanog/current/msg00671.html -- Paul Vixie
Re: DNS Based Load Balancers
On Sat, 1 Jul 2006, Paul Vixie wrote: I'm soliciting recommendations for DNS based load balancers. my recommendation is: don't do it. for background, see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02168.html http://www.cctec.com/maillists/nanog/current/msg03572.html http://www.cctec.com/maillists/nanog/current/msg00671.html -- Paul Vixie Having implemented F5's 3DNS product for a large entertainment company, I'd like to wholeheartedly agree with Paul. Please, for the love of god, don't do it. matto [EMAIL PROTECTED]darwin Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
DNS Based Load Balancers
I'm soliciting recommendations for DNS based load balancers. Currently, we have Cisco Global Site Selectors deployed buy have reached a limit for the number of active HTTP HEAD checks we can perform. This lack of scalability is restricting us severely with regards to the number of customers we can deploy for our product, which requires a separate HTTP HEAD check per IP per customer. I am hoping to receive recommendations for devices which allow for DNS based load balancing (round robin and proximity based) as well as HTTP health checks (including content based health checks). It must be scalable to, at least, 2000 active checks and active answers. I am currently investigating the Netscaler DNS offering as well as F5's 3DNS (or whatever they've changed the name to).
Re: DNS Based Load Balancers
F5 BigIP appears quite good. If you add their 3DNS software, you get wide-IP's as well. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
