[rabbitmq-discuss] RabbitMQ 2.6.0 is released

[Jason J. W. Williams]

Hi Matthew,

> The problem there is where do you stop? You're programming into your
> group definition the fact that you know that these nodes are in
> different racks, behind different switches, on different machines,
> possibly on different UPSs. One problem is that Rabbit knows none of
> this. If you were doing this in a cloud, or on EC2, you have no such
> knowledged. The last thing you want to end with is all your queue
> replicated between nodes that turn out to be different guests on the
> same physical machine! Where do you think Rabbit should draw the line in
> terms of load balancing - what should it try to monitor and what is
> considered unreasonable? Even monitoring CPU usage is rabbit looking
> around at its host, but should it go further and try to detect
> hypervisors? From TTLs on network packets try to detect whether other
> nodes are under the same switch etc?

In my opinion you stop at leaving it to the user define the
availability "separation" groups/areas. If they're defined incorrectly
because the user doesn't understand their environment, that's not
Rabbit's fault and that responsibility is pretty standard. This is how
it works with Cassandra for example. For folks running physical
servers like ourselves, we have knowledge of which servers are in
different racks and different data centers. We're about to stand up a
new cluster split between data centers in Manhattan and Staten Island
with < 1ms latency between them. With EC2 your unit of availability
separation is the availability zone, and it's up to you to make sure
your nodes are split between them. In the case of an availability
group for Rabbit, I assume EC2 users would define their Rabbit
"availability groups" to map to the availability zones they purchase.

Does that explain what I'm trying to say?

-J