You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robert Greig <ro...@gmail.com> on 2009/12/11 21:26:01 UTC
Re: Clustering qpid without multicast?
2009/12/11 Carl Trieloff <cc...@redhat.com>:
> Clustering requires multicast, however you can setup a second broker and
> use queue replication
> to create a mirror for DR if that meets your requirements.
It would be good to be able to support clustering without multicast
(not just for EC2). Would other toolkits that claim to support virtual
synchrony with unicast (as well as multicast) be suitable as
replacements for openais? e.g. Spread http://www.spread.org
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Clustering qpid without multicast?
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> 2009/12/11 Carl Trieloff <cc...@redhat.com>:
>
>
>> Clustering requires multicast, however you can setup a second broker and
>> use queue replication
>> to create a mirror for DR if that meets your requirements.
>>
>
> It would be good to be able to support clustering without multicast
> (not just for EC2). Would other toolkits that claim to support virtual
> synchrony with unicast (as well as multicast) be suitable as
> replacements for openais? e.g. Spread http://www.spread.org
Ais/corosync supports RDMA in it's next release which will open up that
option without
coding on Qpid, just config on AIS. It also gets to IB and iWARP at
higher rates and
better latency on a cluster.
In early testing I've seen end-end (producer to consumer) latencies
through a cluster under load
at about 40us
It would be better to make additional requests on the corosync project,
as they have supported
Qpid quite well with fixes and enhancements.
Carl.
Re: Clustering qpid without multicast?
Posted by Alan Conway <ac...@redhat.com>.
On 12/11/2009 05:18 PM, Robert Greig wrote:
> 2009/12/11 Alan Conway<ac...@redhat.com>:
>
>> Currently the assumption of CPG is baked into qpidd but in principle we
>> could abstract the virtual synchrony layer and allow other another VS engine
>> to plug in. I've only worked with CPG to date so I don't have a good handle
>> on how big are the API differences might be so hard to say how much work it
>> would be.
>
> I think it would be useful - certainly if I were trying to sell Qpid
> derivatives commercially I would be looking at something that didn't
> require multicast (or RDMA for that matter). I don't know if multicast
> is on the EC2 roadmap but I certainly can't imagine that RDMA is. The
> latency is important for some users but for others the throughput is
> more important (along with easy hosting on services such as EC2).
>
I can't tackle that in the short term but if someone else takes it on I can
certainly advise & collaborate.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Clustering qpid without multicast?
Posted by Carl Trieloff <cc...@redhat.com>.
Andrew Stitcher wrote:
> On Fri, 2009-12-11 at 22:18 +0000, Robert Greig wrote:
>
>> 2009/12/11 Alan Conway <ac...@redhat.com>:
>>
>>
>>> Currently the assumption of CPG is baked into qpidd but in principle we
>>> could abstract the virtual synchrony layer and allow other another VS engine
>>> to plug in. I've only worked with CPG to date so I don't have a good handle
>>> on how big are the API differences might be so hard to say how much work it
>>> would be.
>>>
>> I think it would be useful - certainly if I were trying to sell Qpid
>> derivatives commercially I would be looking at something that didn't
>> require multicast (or RDMA for that matter). I don't know if multicast
>> is on the EC2 roadmap but I certainly can't imagine that RDMA is. The
>> latency is important for some users but for others the throughput is
>> more important (along with easy hosting on services such as EC2).
>>
>
> Just for clarity, there is no necessity for RDMA in any qpid deployment
> scenario. Specifically RDMA and clustering are not connected as far as
> qpid is concerned. I believe that running AIS on top of RDMA may be a
> possibility, but that is opaque/transparent (pick your preferred
> metaphor) to qpid itself.
>
> Of course if you want to use RDMA as a transport for the "manifest
> goodness" (tm) that it brings you can.
>
What I was talking about is that AIS/corosync has added support for RDMA
& thus now also
handles for non UDP transports. So if we want to add options for
clustering (CPG) other than
UDP then adding them to AIS/ corosync is probably better than doing so
via the Qpid code base.
Carl.
Re: Clustering qpid without multicast?
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2009-12-11 at 22:18 +0000, Robert Greig wrote:
> 2009/12/11 Alan Conway <ac...@redhat.com>:
>
> > Currently the assumption of CPG is baked into qpidd but in principle we
> > could abstract the virtual synchrony layer and allow other another VS engine
> > to plug in. I've only worked with CPG to date so I don't have a good handle
> > on how big are the API differences might be so hard to say how much work it
> > would be.
>
> I think it would be useful - certainly if I were trying to sell Qpid
> derivatives commercially I would be looking at something that didn't
> require multicast (or RDMA for that matter). I don't know if multicast
> is on the EC2 roadmap but I certainly can't imagine that RDMA is. The
> latency is important for some users but for others the throughput is
> more important (along with easy hosting on services such as EC2).
Just for clarity, there is no necessity for RDMA in any qpid deployment
scenario. Specifically RDMA and clustering are not connected as far as
qpid is concerned. I believe that running AIS on top of RDMA may be a
possibility, but that is opaque/transparent (pick your preferred
metaphor) to qpid itself.
Of course if you want to use RDMA as a transport for the "manifest
goodness" (tm) that it brings you can.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Clustering qpid without multicast?
Posted by Robert Greig <ro...@gmail.com>.
2009/12/11 Alan Conway <ac...@redhat.com>:
> Currently the assumption of CPG is baked into qpidd but in principle we
> could abstract the virtual synchrony layer and allow other another VS engine
> to plug in. I've only worked with CPG to date so I don't have a good handle
> on how big are the API differences might be so hard to say how much work it
> would be.
I think it would be useful - certainly if I were trying to sell Qpid
derivatives commercially I would be looking at something that didn't
require multicast (or RDMA for that matter). I don't know if multicast
is on the EC2 roadmap but I certainly can't imagine that RDMA is. The
latency is important for some users but for others the throughput is
more important (along with easy hosting on services such as EC2).
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Clustering qpid without multicast?
Posted by Alan Conway <ac...@redhat.com>.
On 12/11/2009 03:26 PM, Robert Greig wrote:
> 2009/12/11 Carl Trieloff<cc...@redhat.com>:
>
>> Clustering requires multicast, however you can setup a second broker and
>> use queue replication
>> to create a mirror for DR if that meets your requirements.
>
> It would be good to be able to support clustering without multicast
> (not just for EC2). Would other toolkits that claim to support virtual
> synchrony with unicast (as well as multicast) be suitable as
> replacements for openais? e.g. Spread http://www.spread.org
>
Currently the assumption of CPG is baked into qpidd but in principle we could
abstract the virtual synchrony layer and allow other another VS engine to plug
in. I've only worked with CPG to date so I don't have a good handle on how big
are the API differences might be so hard to say how much work it would be.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org