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