On Thu, Mar 06 2014, Georgy Okrokvertskhov wrote: > 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.
Uh? I'm having trouble imagining any large OpenStack deployment without load-balancing services. I don't think we ever designed OpenStack to run without load-balancers at large scale. > The second issue is connectivity and security. I think that in typical > production deployment VMs will not have an access to OpenStack > infrastructure services. Why? Should they be different than other VM? Are you running another OpenStack cloud to run your OpenStack cloud? > 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. This really sounds like weak arguments. You probably already do need firewall, QoS, and throttling for your users if you're deploying a cloud and want to mitigate any kind of attack. > 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. Yeah and I'm pretty sure a lot of HTTP servers have throttling for connection rate and/or bandwidth limitation. I'm not really convinced. > Using different queues and even vhosts you can effectively segregate > different tenants. Sounds like could do the same thing the HTTP protocol. > 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. It really sounds like you already settled on the solution being RabbitMQ, so I'm not sure what/why you ask in the first place. :) Is there any problem with starting VMs on a network that is connected to your internal network? You just have to do that and connect your application to the/one internal messages bus and that's it. -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
