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

Mon Mar 16 18:44:36 GMT 2009

>> I've gotten to the root of the problem - it has to do with the fact
>> that the second
>> rabbit broker is doing a redirect, i.e, from
>> /var/log/rabbitmq/rabbit.log I see:
>>
>> INFO REPORT==== 14-Mar-2009::00:18:55 ===
>> connection <0.16842.0> redirecting to
>> <<"domU-12-31-39-00-7E-16.compute-1.internal:5672">>
>
> This name (*.internal) is an
> internal DNS name that resolves only in EC2 region where your brokers are
> running. Clients
> connecting from another region (regions are US or EU) or from Internet will
> not be able to
> resolve this
Yes, of course the *.internal are not resolvable from outside of the
current ec2 availability zone -
but what I (naively) didn't realize is that dns that I see in the logs
are actually being passed to the client
(and hence the client errors I'm seeing) - thanks for setting me
straight on that one!

> they should be using the instance's public DNS name.

So, is this behavior 'configurable' in RabbitMQ any way (i.e. make
Rabbit redirect to the public DNS, not the private)
or should I be solving this problem in a different way?

>
> Python on my mac does raise gaierror 8 when I tried to connect to
> unresolvable name (see below). Interestingly, python in Linux raised
> gaierror -2 'Name or service not known'.
>
> $ python
> Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import socket
>>>> sock = socket.socket()
>>>> sock.connect(('foo.bar.internal', 5672))
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<string>", line 1, in connect
> socket.gaierror: (8, 'nodename nor servname provided, or not known')
>
>
>
> You *might* get rabbit to put right name into known_hosts field by
> associating public DNS name of rabbit instance (ec2*.amazonaws.com) with its
> private IP address (10.X.X.X) in /etc/hosts. Or do client side load
> balancing with insist=True, like you said.
I guess this sort of answers my above question about configuring Rabbit to
redirect to the public DNS.

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?  I'm a bit unclear of my remaining
options, but I'm going to keep researching.
Any advice is appreciated.

thanks very much,
Alex

>
>
>
>
> - Dmitriy
>

-- 
Alex Clemesha
clemesha.org