[openstack-dev] Zero MQ remove central broker. Architecture change.
Li Ma
skywalker.nick at gmail.com
Tue Nov 18 08:27:58 UTC 2014
On 2014/11/17 23:03, Eric Windisch wrote:
>
> On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny <ipekelny at mirantis.com
> <mailto:ipekelny at mirantis.com>> wrote:
>
> We want to discuss opportunity of implementation of the p-2-p
> messaging model in oslo.messaging for ZeroMQ driver. Actual
> architecture uses uncharacteristic single broker architecture
> model. In this way we are ignoring the key 0MQ ideas. Lets
> describe our message in quotes from ZeroMQ documentation:
>
>
> The oslo.messaging driver is not using a single broker. It is designed
> for a distributed broker model where each host runs a broker. I'm not
> sure where the confusion comes from that implies this is a
> single-broker model?
>
> All of the points you make around negotiation and security are new
> concepts introduced after the initial design and implementation of the
> ZeroMQ driver. It certainly makes sense to investigate what new
> features are available in ZeroMQ (such as CurveCP) and to see how they
> might be leveraged.
>
> That said, quite a bit of trial-and-error and research went into
> deciding to use an opposing PUSH-PULL mechanism instead of REQ/REP.
> Most notably, it's much easier to make PUSH/PULL reliable than REQ/REP.
Hi Eric. In our production deployment, We rely on ZeroMQ driver much
because we have more than one thousand physical machines to run
OpenStack. The distributed nature of ZeroMQ provide more scalable
messaging plane than RabbitMQ.
However, as you know, the driver codebase is not that mature and stable.
The first problem we faced is that we cannot guarantee the status when
delivering messages via PULL/PUSH. Because there's no ACK for this
model. We are discussing the possibility to change from PULL/PUSH to
REQ/REP. But here you said that it is much easier to make PUSH/PULL
reliable than REQ/REP. Do you have some idea or concern to improve the
reliability of the current model?
cheers,
Li Ma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/7d650cba/attachment.html>
More information about the OpenStack-dev
mailing list