Open Stack

Hi Julien,

I there are valid reasons why we can consider MQ approach for communicating
with VM agents. The first obvious reason is scalability and performance.
User can ask infrastructure to create 1000 VMs and configure them. With
HTTP approach it will lead to a corresponding number of connections to a
REST API service. Taking into account that cloud has multiple clients the
load on infrastructure will be pretty significant. You can address this
with introducing Load Balancing for each service, but it will significantly
increase management overhead and complexity of OpenStack infrastructure.

The second issue is connectivity and security. I think that in typical
production deployment VMs will not have an access to OpenStack
infrastructure services. It is fine for core infrastructure services like
Nova and Cinder as they do not work directly with VM. But it makes a huge
problem for VM level services like Savanna, Heat, Trove and Murano which
have to be able to communicate with VMs. The solution here is to put an
intermediary to create a controllable way of communication. In case of HTTP
you will need to have a proxy with QoS and Firewalls or policies, to be
able to restrict an access to some specific URLS or services, to throttle
the number of connections and bandwidth to protect services from DDoS
attacks from VM sides.
In case of MQ usage you can have a separate MQ broker for communication
between service and VMs. Typical brokers have throttling mechanism, so you
can protect service from DDoS attacks via MQ. Using different queues and
even vhosts you can effectively segregate different tenants.
For example we use this approach in Murano service when it is installed by
Fuel. The default deployment configuration for Murano produced by Fuel is
to have separate RabbitMQ instance for Murano<->VM communications. This
configuration will not expose the OpenStack internals to VM, so even if
someone broke the Murano rabbitmq instance, the OpenSatck itself will be
unaffected and only the Murano part will be broken.

Thanks
Georgy


On Thu, Mar 6, 2014 at 7:46 AM, Julien Danjou <julien at danjou.info> wrote:

> On Thu, Mar 06 2014, Dmitry Mescheryakov wrote:
>
> > So, messaging people, what is your opinion on that idea? I've already
> > raised that question in the list [1], but seems like not everybody who
> > has something to say participated. So I am resending with the
> > different topic. For example, yesterday we started discussing security
> > of the solution in the openstack-oslo channel. Doug Hellmann at the
> > start raised two questions: is it possible to separate different
> > tenants or applications with credentials and ACL so that they use
> > different queues? My opinion that it is possible using RabbitMQ/Qpid
> > management interface: for each application we can automatically create
> > a new user with permission to access only her queues. Another question
> > raised by Doug is how to mitigate a DOS attack coming from one tenant
> > so that it does not affect another tenant. The thing is though
> > different applications will use different queues, they are going to
> > use a single broker.
>
> What about using HTTP and the REST APIs? What's what supposed to be the
> world facing interface of OpenStack. If you want to receive messages,
> it's still possible to use long polling connections.
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; http://julien.danjou.info
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/168100c8/attachment.html>