On 08/05/2011 06:51 AM, Julien Vehent wrote:
On Fri, 05 Aug 2011 01:08:22 +0300, Piavlo wrote:
Hi Jens,
I'm using names which resolve to internal EC2 addresses in haproxy
configs - the /etc/hosts of all instances are auto updated then new
instance is added/removed.
But the problem manifests then the instance is stoped and then
started - this makes the internal ip to change.
I can also use DNS CNAMES to public instance ip with very low TTL -
which get auto updated then instance boots by using route53 - but it's
still the same problem - the ip changes in DNS and not in /etc/hosts
(getnameinfo does not really care from where from the name is
resolved) - in both cases haproxy will not know it has changed since
it probably uses getnameinfo once only on startup/reload. And never
later rechecks if the ip has changed.
Hi,
Haproxy resolves names into addresses at startup, so using names is
just an ugly way, and probably confusing, to define an ip address.
Names are less confusing and less ugly for me. I understand I can use a
combination of automation tool like puppet/chef with zookeper like tool
to rebuild the haproxy configuration and reload haproxy - in some
situations like add/removal of backend server - that's unavoidable.
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?
The only reliable way to work with IP addresses in EC2, without
messing with the whole /etc/hosts and applications reload, is to use
static LAN addresses, like in a real network. And you can do that just
fine in a VPC environment.
DO NOT use elastic IPs for internal traffic. Elastic IPs are routed
through the external network of EC2, so you will get charged $$$, your
interconnections will be slower and you don't even know where the hell
your packets are going....
I never said that I'm using elastic IPs. But I don't think it matters if
it's an elastic/static ip or just a normal public ip which can/will
change on stop/start of ec2 instance.
There is a well know trick in EC2 - if you do dns lookup on public ec2
hostname from within ec2 - you will get and internal ip instead of
public ip.
So you are not charged because you are effectively working with internal
ip's - if you have a CNAME to public A records - it ends up resolving
to internal ec2 ip from within ec2 and to public ip from outside of ec2.
Thanks
Alex
Just the result of my personal experience... :)
Julien
