Fwd: unresolvable host names as error
Sometimes it would be resolvable and other times not, it depends if the host has reported itself to the DNS server previously and it's still in the bind cache after going down. I suspect that this is happening if the host is down and there is no IP for it in the DNS tables, but that's just guess work on my part. 1.4.20 is the haproxy version we are running. The name lookup during health checks + not erroring out on start-up, seems like this would correct the problem. Currently, it seems haproxy is rather unsafe to use for a dynamic dhcp+dns farm setup. Thanks for the heads up. Cheers On Fri, May 11, 2012 at 3:32 PM, Baptiste bed...@gmail.com wrote: On Fri, May 11, 2012 at 6:09 PM, Andres Thomas Stivalet atstiva...@gmail.com wrote: Currently, if haproxy tries to start up and a webserver is down (and it's defined as a hostname in the config file) haproxy refuses to start. Looking at the previous change logs and announcements it seems this is by design. Why is this done and is there a way to circumvent this? I would consider this a rather large design flaw, I must be missing something. Cheers Hi, Is the hostname resolvable when the server is down? For now, HAProxy only tries to resolve a hostname at start up. Willy has plans to improve this by doing a name lookup during health checks, allowing a server to change its IP address. Maybe it ill fix the issue you're describing. By the way, which version of HAProxy are you running? cheers
Re: unresolvable host names as error
Hi Willy, I believe in previous versions of haproxy having an unresolvable host name at start up did not cause haproxy to error out. Bellow is the change log I found: 2010/03/30 : 1.3.24 - [BUG] config: report unresolvable host names as errors I wrongly assumed that haproxy performed DNS lookups after startup. After reading the past few emails I'm assuming that haproxy, on startup, performs a lookup for backends' hostnames, gets an IP address, and stores this IP for later use. If there is no IP, haproxy errors out, and haproxy does not perform DNS lookups other than at startup. It completely makes sense for static configurations, but it does limit haproxy in its application. I think an option for the backend works perfectly because, as you said, most people statically define their farms. Static is easier and less complicated, but limited. Everything has it's pros and cons. Cheers! Andres On Sat, May 12, 2012 at 4:27 AM, Willy Tarreau w...@1wt.eu wrote: On Sat, May 12, 2012 at 11:09:22AM +0200, Baptiste wrote: Well, I must say I'm unsure what we'll do upon startup, because if we accept to start with buggy host names, a number of admins will get trapped with errors in their configs causing servers to remain down forever. At least right now they know from the beginning that they have to fix their configs. Maybe we'll have to support a per-backend option to enable delayed host name resolution, I don't know yet. Regards, Willy I think that you should allow this kind of behavior for people using Amazon (or any cloud) or people, like Andreas, who uses DHCP+ automatic DNS update. So untill the server has startup, it does not know its own IP address and of course, the DNS resolver can't point to it. I understand this problem, but I mean that I don't want to make all other users (say 99.99% of users) suffer from a lack of control of configuration errors just because of a few ugly uses (because having a server dynamically addressed is ugly, no matter whatever good excuse you have for this). So I think it will be an option in the backend so that serious users doesn't suffer from this. Cheers, Willy
Re: Fwd: unresolvable host names as error
Given how the current farm toolset operates under the hostname assumption we're still going to have change hostnames etc. We're currently evaluating if we want to patch haproxy for our needs or track our machines some other way. Patching haproxy seems like the sane route. :) On May 12, 2012 3:17 PM, Willy Tarreau w...@1wt.eu wrote: On Sat, May 12, 2012 at 02:53:45PM -0500, Andres Thomas Stivalet wrote: That's why I've added this to the TODO list :-) Thanks Willy! For the same reason, you cannot safely install firewalls nor VPNs in such environments. I'd just like to mention that it's certainly possible to implement a safe dynamic dhcp+dns environment for a private network. Just to give you an idea of the structure we use, there are other machines sprinkled around the network, but this is basically it: Routers/fw - loadbalancers - proxies - backends (ws###) |-- app servers (app###) |-- db layer |-- storage layer We use the dynamic dhcp+dns to reassign app servers as backends and nice versa under different load conditions. So it's as simple as issuing a command to an app server to change it's hostname to a ws###, reboot, and voila. The proxies are the level where we're considering using haproxy, they do other stuff like partition certain traffic into buckets for the backends. Then if you have the control over all your servers, in stead of playing with the DNS, just change their IP address to be either app or backend and that's done. As long as each server always has the same IP for the same function there is no need for doing complex things. Anyway, I don't doubt with all this hype for the cloud you'll be seeing more dynamic dns usage. I'm fairly sure of this too ! Regards, Willy
unresolvable host names as errors
Currently, if haproxy tries to start up and a webserver is down (and it's defined as a hostname in the config file) haproxy refuses to start. Looking at the previous change logs and announcements it seems this is by design. Why is this done and is there a way to circumvent this? Cheers
