<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>We have not yet seen any performance issues. All traffic between instances in different availability zones within a region is charged: $.01/GB in us-east-1. So there is a cost, and the volume of traffic through your HA queues has an impact.</div><div><br></div><div>In us-east-1, the increase in latency by going across zones is < 10ms, in our small sample. We will add some continuous testing of this in the future across all zones.</div><div><br></div><div>Regions may vary in the amount of latency. And latency may vary (jitter).</div><div><br></div><div>*Rather then LAN vs WAN, it would be useful to know the design envelope for rabbitmq clusters in terms of latency and jitter, as these are measurable. Also if there is tuning that can be done.</div><div><br></div><div>All that said, I may choose to use federation rather than clustering across zones, because the rabbitmq response to a net split is so catastrophic, apparently, and I am not sure I want to live with that uncertainty in production. We are architected in such a way that we can do either with minor modifications. We would run a cluster in each zone and federate the clusters. It's more expensive though and more moving parts.</div><div><br></div><div>We use DynamoDB and Riak as reliable KV stores, as well as s3. Riak seems to have good tolerance of net splits. (*Why is it better than rabbitmq in this respect?)</div><div><br></div><div>The 'usual' failure mode in an AWS region is that a zone becomes 'compromised', meaning that some or all instances become unreachable and/or unresponsive. We would normally have 3 clustered nodes in different zones in the region. In this scenario, we would expect to lose a node completely and have it drop from the 'wholesale' Elastic Load Balancers. We would also lose all the other instances in that zone depending upon that node – they would drop from the 'retail' Elastic Load Balancers.</div><div><br></div><div>An often under-reported syndrome of zone failure in a region is that the regional 'control plane' is usually compromised as well. This means that one cannot create new instances, load balancers, volumes, etc. <u>across the entire region</u> (all zones). Hence you cannot rely on being able to add new resources to the zones that have not failed. This affects your capacity planning etc.</div><div><br></div><div>Hence, in the 'short' term, both wholesale and client apps reconnect via the ELBs to existing resources in the 'good' zones, which have been sized to handle this scenario.</div><div><br></div><div>At the same time, we start re-routing new connections to other healthy regions by automatically adjusting Route 53 weighted routing parameters, which are normally set to route only using least latency. The other regions will autoscale resources to handle the load. For example, us-east-1 is backed up by splitting its load between us-west-2 and eu-west-1. If necessary, we will also gradually shed the existing load from the compromised region by causing clients to reconnect.</div><div><br></div><div>Best regards,</div><div><br></div><div>Michael</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> ¤ý«Tªi <<a href="mailto:wangjunbo924@gmail.com">wangjunbo924@gmail.com</a>><br><span style="font-weight:bold">Reply-To: </span> rabbitmq <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>><br><span style="font-weight:bold">Date: </span> Thu, 13 Dec 2012 20:14:09 -0500<br><span style="font-weight:bold">To: </span> rabbitmq <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>><br><span style="font-weight:bold">Subject: </span> Re: [rabbitmq-discuss] RabbitMQ Cluster On AWS VPC<br></div><div><br></div>Hi Laing, Is there any performance issue? <div>And I believe that it's much more expensive to build cluster across AWS zones. Does it?</div><div>One another question, I'm wondering how to connect to the cluster in your experience? A Load Balancer before cluster or DNS Round Robin or the Java Client Libraries only?</div><div class="gmail_extra"><br><br><div class="gmail_quote">2012/12/13 Laing, Michael P. <span dir="ltr"><<a href="mailto:Michael.Laing@nytimes.com" target="_blank">Michael.Laing@nytimes.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Clustering across AWS availability zones works fine in our experience so<br>
far.<br><br>
ml<br><div><div class="h5"><br>
On 12/13/12 5:48 AM, "Simon MacMullen" <<a href="mailto:simon@rabbitmq.com">simon@rabbitmq.com</a>> wrote:<br><br>
>On 13/12/12 10:44, ¤ý«Tªi wrote:<br>
>> We are going to build RabbitMQ cluster with HA on AWS VPC. Suppose there<br>
>> are two subnets in the VPC, and they are in different available zones(<br>
>> for more info about AWS available zone, please visit:<br>
>><br>
>><a href="http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-regions-a" target="_blank">http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-regions-a</a><br>
>>vailability-zones.html).<br>
>> Then I launch instances in both subnets:<br>
>> instance X in subnet1(in AWS zone us-east-1a)<br>
>> instance Y in subnet2(in AWS zone us-east-1b)<br>
>><br>
>> So can I create a RabbitMQ cluster with HA consisting of both X and Y?<br>
><br>
>This is a bad idea - RabbitMQ clusters do not tolerate network<br>
>partitions well. Read <a href="http://www.rabbitmq.com/partitions.html" target="_blank">http://www.rabbitmq.com/partitions.html</a> for more<br>
>information.<br>
><br>
>> Another question is about federation plugin. If I build federation links<br>
>> for X and Y symmetrically with max-hop=1, is there any way that whenever<br>
>> a message is consumed from node X then the corresponding one in node Y<br>
>> is dequeued automatically with no client actually consuming it?<br>
><br>
>No, I'm afraid not.<br>
><br>
>Cheers, Simon<br>
><br>
>--<br>
>Simon MacMullen<br>
>RabbitMQ, VMware<br></div></div>>_______________________________________________<br>
>rabbitmq-discuss mailing list<br>
><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br></blockquote></div><br></div></span></body></html>