Anyone ?<br><br><div class="gmail_quote">On Thu, Apr 15, 2010 at 11:38 AM, Gustavo Aquino <span dir="ltr"><<a href="mailto:aquino.gustavo@gmail.com">aquino.gustavo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Alexis,<br><br><div class="gmail_quote"><div class="im">On Thu, Apr 15, 2010 at 7:51 AM, Alexis Richardson <span dir="ltr"><<a href="mailto:alexis.richardson@gmail.com" target="_blank">alexis.richardson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Gustavo,<br>
<br>
On Wed, Apr 14, 2010 at 9:35 PM, Gustavo Aquino<br>
<div><<a href="mailto:aquino.gustavo@gmail.com" target="_blank">aquino.gustavo@gmail.com</a>> wrote:<br>
> Alexis,<br>
</div><div>> Why not one HA OOTB can be provided ?<br>
<br>
</div>As I mentioned, we are about to release an HA Guide which provides our<br>
recommendation for HA today, that we can stand behind. In other words<br>
- you can trust us to commercially support that solution and provide<br>
SLAs.<br>
<br></blockquote><div> </div></div><div>I trust you, you know, but we need to know what will be the road map for it.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You are correct that we *could* provide a single configuration OOTB<br>
for HA. The question is: which one.<br>
<br>
Bear in mind that HA behaviour combines:<br>
<br>
* Immediate acceptance<br>
* Immediate delivery<br>
* Eventual acceptance<br>
* Eventual delivery<br>
<br>
Note that:<br>
<br>
(a) these requirements are in tension with one another; so it is<br>
expensive to provide a system that is able to provide all of them at<br>
once so that, somehow, the system works out what each message needs<br>
and reacts accordingly based on need.<br>
<br>
(b) more importantly, the requirements are based on a notion of TIME.<br>
This is problematic because time based guarantees are<br>
non-deterministic. For some systems an unavailability window of 1ms<br>
is fine because the client can wait. For others it is too big. Many<br>
things can affect this. For example you could be running a messaging<br>
system on a real time Linux kernel, but still have variance in your<br>
failover window due to how your network and disk hardware is behaving<br>
based on (eg) load and contention.<br>
<br>
This is all ok, but we need to make our assumptions *explicit* for any<br>
one HA OOTB solution.<br>
<div><br>
<br></div></blockquote><div><br></div></div><div>You are right. But some situations are the same of ppl, I think that a good solution is We have this ways to do HA OOTB it's part of product, but if you not attend you we can optimize it soing something like X,Y or Z approaches... (your commercial support).</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
> do you have one HP OOTB solution why<br>
> not HA ? May be one HA OOTB is not the best solution, and may be not attend<br>
> 100% of users but may be 70% and it's sounds good for me not for you ?.<br>
<br>
</div>Yes that's fine Gustavo, but as soon as you make a promise about one<br>
configuration being "HA" then people immediately expect that you can<br>
do things that break the laws of physics.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
> We know about one AMQP product that have a HA OOTB solution, and we are<br>
> trying this "HA OOTB" and this product will be used in CME. But can't do the<br>
> same with RabbitMQ.<br>
<br>
</div>Why don't you describe the main HA parameters that you need, on this<br>
list, and we can talk about them.<br>
<br></blockquote><div><br></div></div><div>Sure, here is.</div><div><br></div><div>We have two scenarios for HA:</div><div>- Cluster</div><div>- "Federation"</div><div><br></div><div>Cluster:</div><div><div style="line-height:1.29em;padding-top:0px;margin-top:0.3em;padding-bottom:0px;margin-bottom:1em;font-size:12px">
<br></div><div style="line-height:1.29em;padding-top:0px;margin-top:0.3em;padding-bottom:0px;margin-bottom:1em;font-size:12px">
A<em> Cluster</em> will be a group of brokers that act as a single broker. Changes on any broker are replicated to all other brokers in the same Messaging Cluster, so if one broker fails, its clients can fail-over to another broker without loss of state. The brokers in a Messaging Cluster may run on the same host or on different hosts. </div>
<div style="line-height:1.29em;padding-top:0px;margin-top:0.3em;padding-bottom:0px;margin-bottom:1em;font-size:12px">
Clusters need to provide a reliable multicast protocol, tools, and infrastructure for implementing replicated services.</div></div><div><span style="font-size:12px;line-height:15px">Clusters need to uses an Active/Active model. In this model, all possible brokers are active at all times. Producers and consumers can be connected to any broker in the cluster. Additionally, any broker can be killed and restarted, and the cluster will retain its operational state to provide scalability and enhanced load-balancing.</span></div>
<div><span style="font-size:12px;line-height:15px"><br>
</span></div><div><br></div><div>"Federation":</div><div><br></div><div><span style="font-size:12px;line-height:15px">Federation will be used to provide geographical distribution of brokers. A number of individual brokers, or clusters of brokers, can be federated together. This will allows client machines to see and interact with the federation as though it were a single broker. Federation will be used where client machines remain on a local network, even though their messages have to be routed out.</span></div>
<div><span style="font-size:12px;line-height:15px"><br>
</span></div><div><span style="font-size:12px;line-height:15px"><div style="line-height:1.29em;padding-top:0px;margin-top:0.3em;padding-bottom:0px;margin-bottom:1em">
Federation will be used for connecting disparate locations across a wide area network. Full connectivity across an enterprise can be achieved while keeping local message traffic isolated to a single location. Departmental brokers can be specified with individual policies that control inter-departmental message traffic flow.</div>
<div style="line-height:1.29em;padding-top:0px;margin-top:0.3em;padding-bottom:0px;margin-bottom:1em">Client produces data that must be delivered reliably but connectivity can not be guaranteed. In this case, a co-resident broker provides queueing and durability that is not available in the client on its own.</div>
</span></div><div><br></div><div>RabbitMQ provide a part of "Federation" but the problem is node dow all others don't see more the queue and it broke all the process, and RabbitMQ "route" don't guarantee delivery if one node is down out of local network, today if one node is down all process fail.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also: Do you want to see a copy of the HA Guide?<br></blockquote><div><br></div></div><div>I would like so much to get a copy of this guide.</div><div class="im"><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> I understand you, and you know my case, we are working in<br>
> microseconds/nanoseconds, may be this HA don't attend our requirements, but<br>
> it is one solutions and until now we don't have a good solution for HA using<br>
> Rabbit, about HP we don't need nothing to talk about RabbitMQ is very good<br>
> Broker routing 2.000.000 messages per second just inboud. But one good HA<br>
> solution is getting my sleep.<br>
<br>
</div>I'm sorry to hear that we are keeping you awake at night.<br></blockquote><div><br></div></div><div>No worry it's not your fault, it's part of IT skill :)</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
<br>
> Do you know what we need,we talked about that is just one HA solution from<br>
> RabbitMQ with a very low latency, SLA and guarantee that no messages will be<br>
> loosed. O.S cluster or putting HA logic in our application is not a good<br>
> solution in our case.<br>
<br>
</div>Actually, doing dedup on the consumer could be a very good solution<br>
based on what you have told me in the past. But, let's keep<br>
discussing it.<br>
<font color="#888888"><br>
alexis<br></font></blockquote><div><br></div></div><div>Great. let's discussing about.</div><div><br></div><div>Regards.</div><div><br></div><font color="#888888"><div>Gustavo</div></font><div><div></div><div class="h5">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888">
</font><div><div></div><div><br>
<br>
<br>
> Regards.<br>
><br>
><br>
><br>
> On Wed, Apr 14, 2010 at 4:56 PM, Alexis Richardson<br>
> <<a href="mailto:alexis.richardson@gmail.com" target="_blank">alexis.richardson@gmail.com</a>> wrote:<br>
>><br>
>> Gustavo<br>
>><br>
>> We are about to release an HA Guide including recommendations. It's<br>
>> just being reviewed.<br>
>><br>
>> It is not possible to provide "HA OOTB" because each system is<br>
>> slightly different. If someone tells you that they can support HA<br>
>> OOTB, they are misleading you. What is possible, and desirable, is a<br>
>> much simpler and more "OOTB like" experience for the main four or five<br>
>> HA cases. For example, the Beetle project aims to solve for cases<br>
>> where idempotency is desired. Your case might require a different<br>
>> optimisation. E.g. sometimes latency needs to be below X<br>
>> microseconds, and sometimes it does not.<br>
>><br>
>> We are in the business of providing long term commercial support for<br>
>> RabbitMQ based solutions, including where an SLA is in use. Just let<br>
>> us know what solution or solutions you need.<br>
>><br>
>> alexis<br>
>><br>
>><br>
>><br>
>> On Wed, Apr 14, 2010 at 8:43 PM, Gustavo Aquino<br>
>> <<a href="mailto:aquino.gustavo@gmail.com" target="_blank">aquino.gustavo@gmail.com</a>> wrote:<br>
>> > Alexis,<br>
>> > I know that it's not the unique, you know how much I'm looking for a<br>
>> > good HA<br>
>> > solutions using RabbitMQ. The problem is RabbitMQ doesn't have a default<br>
>> > solution out of the box for HA, and do you know companies need it, need<br>
>> > a<br>
>> > commitment from product owner about HA. Do my own solution means,<br>
>> > the responsible of maintenance and evolution of this solutions is my,<br>
>> > and it<br>
>> > is not my business it will be yours. Understand why I do this question<br>
>> > about<br>
>> > support ?<br>
>> > I'm a community enthusiast, and work hard of lot of open projects and is<br>
>> > a<br>
>> > pleasure if I can help to Rabbit HA, the point is today all products<br>
>> > inclusive cloud products need to have one HA solutions OTB, It's is the<br>
>> > best<br>
>> > ? may be not but need to have it, and today we have a problem of using<br>
>> > RabbitMQ because it don't have it. So how can I put Rabbit on my core if<br>
>> > cannot guarantee a single SLA, or without putting responsible in side<br>
>> > like<br>
>> > O.S cluster solution, OpenaIS, LVS shared storage or whatever.<br>
>> > Do you know any about the overhead in throughput using this Xing's<br>
>> > Solution<br>
>> > ?<br>
>> ><br>
>> > Best Regards.<br>
>> ><br>
>> > On Wed, Apr 14, 2010 at 4:08 PM, Alexis Richardson<br>
>> > <<a href="mailto:alexis.richardson@gmail.com" target="_blank">alexis.richardson@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Thanks Salvatore.<br>
>> >><br>
>> >> Gustavo,<br>
>> >><br>
>> >> We and the community will support good solutions and 'things that<br>
>> >> work'. I like the approach, but as Salvatore suggested - it is not<br>
>> >> unique.<br>
>> >><br>
>> >> alexis<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Wed, Apr 14, 2010 at 7:37 PM, Salvatore Sanfilippo<br>
>> >> <<a href="mailto:antirez@gmail.com" target="_blank">antirez@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > On Wed, Apr 14, 2010 at 8:34 PM, Gustavo Aquino<br>
>> >> > <<a href="mailto:aquino.gustavo@gmail.com" target="_blank">aquino.gustavo@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> >> So if RabbitMQ is a VMWare product and Redis it too, so do Rabbit<br>
>> >> >> support<br>
>> >> >> this HA approach ? :-)<br>
>> >> ><br>
>> >> > I think that surely it helps that this feature depends from another<br>
>> >> > VMWare product ;)<br>
>> >> > But my guess is that the way to go is to have such a support built-in<br>
>> >> > for RabbitMQ.<br>
>> >> ><br>
>> >> > Ciao,<br>
>> >> > Salvatore<br>
>> >> ><br>
>> >> >> Regars.<br>
>> >> >><br>
>> >> >> On Wed, Apr 14, 2010 at 2:09 PM, Jason J. W. Williams<br>
>> >> >> <<a href="mailto:jasonjwwilliams@gmail.com" target="_blank">jasonjwwilliams@gmail.com</a>> wrote:<br>
>> >> >>><br>
>> >> >>> Been reading the page since y'all started tweeting about it. :)<br>
>> >> >>> It's<br>
>> >> >>> hard to tell how it works.<br>
>> >> >>><br>
>> >> >>> -J<br>
>> >> >>><br>
>> >> >>> On Wed, Apr 14, 2010 at 11:02 AM, Alexis Richardson<br>
>> >> >>> <<a href="mailto:alexis.richardson@gmail.com" target="_blank">alexis.richardson@gmail.com</a>> wrote:<br>
>> >> >>> > Hi everyone,<br>
>> >> >>> ><br>
>> >> >>> > It looks like Xing's Beetle project is up on Github:<br>
>> >> >>> > <a href="http://github.com/xing/beetle" target="_blank">http://github.com/xing/beetle</a><br>
>> >> >>> ><br>
>> >> >>> > There is a project page here: <a href="http://xing.github.com/beetle/" target="_blank">http://xing.github.com/beetle/</a><br>
>> >> >>> ><br>
>> >> >>> > Please take a look and share any comments you may have here :-)<br>
>> >> >>> ><br>
>> >> >>> > alexis<br>
>> >> >>> ><br>
>> >> >>> > _______________________________________________<br>
>> >> >>> > rabbitmq-discuss mailing list<br>
>> >> >>> > <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>> >> >>> ><br>
>> >> >>> > <a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>> >> >>> ><br>
>> >> >>><br>
>> >> >>> _______________________________________________<br>
>> >> >>> rabbitmq-discuss mailing list<br>
>> >> >>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>> >> >>> <a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Salvatore 'antirez' Sanfilippo<br>
>> >> > <a href="http://invece.org" target="_blank">http://invece.org</a><br>
>> >> ><br>
>> >> > "Once you have something that grows faster than education grows,<br>
>> >> > you’re always going to get a pop culture.", Alan Kay<br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>