[rabbitmq-discuss] RabbitMQ Cluster, option "-setcookie cookie" + EC2 experiences

Mon Mar 16 21:04:00 GMT 2009

> 
> My inclination is to avoid making this a client side
> concern - it seems more complicated to try to juggle all the (coming and going)
> Rabbit cluster IPs, and try to pass this info to my clients in some ad hoc way -
> but I'm not exactly sure... any opinion on this?
> 
> The /etc/hosts solution sounds better, but you say "it might work", is there
> anyone using this solution with success?  I get the feeling from other mailing
> list posts that I should try to avoid using "known_hosts".
> 
>> Also, here is a link to a potentially related thread:
>> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-September/001901.html
> Yes, thanks, I saw that before.  In it you say "...the best approach
> is not to rely on known_hosts at all...",
> do you still hold this to be true?

In general case, yes, I still believe that known_hosts mechanism as described in AMQP 0-8 
will not make it easy for you to run some clients from inside NAT and some clients from 
outside NAT at the same time and rely on known_hosts field of redirect method.

However, EC2 has one property that can help. Public DNS names (ec2*.amazonaws.com) resolve 
  to a public IP outside of EC2 and to a private IP inside EC2. If you manage to convince 
each broker that its cluster peers are ec2*.amazonaws.com, it's the name broker will put 
in known_hosts field (I would hope).

You can first try to use public DNS names when setting up a cluster and see if it forces 
rabbit to use public DNS names in known_hosts.

If that doesn't work, by associating public DNS name with an internal IP in /etc/hosts, 
you force OS to return ec2*amazonaws.com name for a 10.X.X.X lookup. This will override 
EC2 internal DNS, which associates 10.X.X.X with *.internal. I said it *might* work 
because it depends on the order in which various naming services are tried by your OS - 
usually /etc/hosts is tried before DNS, but this is not a rule.

You may need to restart nscd and wait a bit or even reboot. Use "getent hosts 10.X.X.X" to 
see which name your OS currently returns for a given IP.

Please note that I have not had a chance to try either of these myself.

HTH,
Dmitriy