On Fri, 05 Aug 2011 11:17:16 +0300, Piavlo wrote:
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.
That's the thing: If you run your EC2 environment in a VPC and not in
regular EC2 infrastructure, you have full control of the subnet, you
chose the private IP of each of your instances, and the IPs are
conserved upon reboots
Julien
