On 08/05/2011 06:53 PM, Willy Tarreau wrote:
On Fri, Aug 05, 2011 at 11:17:16AM +0300, Piavlo wrote:
But why do a reload of haproxy in other situations (much more common  in
my use case and loose statistics and possibly some connections) if there
could be a config option that tells haproxy to re-resolve name to ip -
then backend health check fails?
It's not a matter of config option. You're supposed to run haproxy
inside a chroot. It will then not have access to the resolver.
There are simple ways to make the resolver work inside chroot without making the chroot less secure.
  I could ask the question the other direction : why try to resolve a
name to IP when a check fails, there is no reason why a server would
have its address changed without the admin being responsible for it.
I don't agree that admin is supposed to be responsible for it directly at all. Say backend server crashes/enters bad state - this is detected and new ec2 instance is automatically spawned and autoconfigured to replace the failed backend ec2 instance- which is optionally terminated. The /etc/hosts of all relevent ec2 instances is auto updated (or DNS with 60 seconds ttl is updated - by the way the 60 seconds ttl works great withing ec2). There is no admin person involved - all is done automatically.

Also, in your case it would not fix the issue : resolving when the
server goes down will bring you the old address, and only after
caches expires it would bring the new one.
If /etc/hosts is updated locally the is no need to wait for cache expiration. And if /etc/hosts is auto updated by appropriate tool - going one more step of restarting/reloading haproxy is not a problem at all - but this is what I want to avoid. If instead for example i could send a command to haproxy control socket to re-resolve all the names (or better just specific name) configured in haproxy - it would be much better - as since /etc/hosts is already updated it would resolve to correct ip address.

BTW afaiu adding/removing backends/frontends dynamically on the fly through some api / socket - is not something that is ever planned to be supported in haproxy?

Thanks
Alex
  In the mean time, someone
else might have got the old address before you have a new one, so
this means that it is still possible that only the old address is
used.

There is no way to reach a reliable behaviour with unreliable configuration
processes.

Regards,
Willy




Reply via email to