On 6/11/14, 2:43 AM, "Gordon Sim" <g...@redhat.com> wrote: >On 06/10/2014 09:57 PM, Janczuk, Tomasz wrote: >> Using processes to isolate tenants is certainly possible. There is a >>range >> of isolation mechanisms that can be used, from VM level isolation >> (basically a separate deployment of the broker per-tenant), to process >> level isolation, to sub-process isolation. The higher the density the >> lower the overall marginal cost of adding a tenant to the system, and >> overall cost of operating it. From the cost perspective it is therefore >> desired to provide sub-process multi-tenancy mechanism; at the same time >> this is the most challenging approach. > >Where does the increased cost for process level isolation come from? Is >it simply the extra process required (implying an eventual limit for a >given VM)? > >With sub-process isolation you have to consider the fairness of >scheduling between operations for different tenants, i.e. potentially >limiting the processing done on behalf of any given tenant in a given >period. You would also need to limit the memory used on behalf of any >given tenant. Wouldn't you end up reinventing much of what the operating >system does? >
Process level isolation is more costly than sub-process level isolation primarily due to larger memory consumption. For example, CGI has worse cost characteristics than FastCGI when scaled out. But the example closer to Marconi¹s use case is database systems: I can¹t put my finger on a single one that would isolate queries executed by its users using processes. Sub-process multi-tenancy is a not an easy problem, but it is not one that cannot be solved, especially in the context of a messaging system. A messaging system exposes a set of operations that is very well defined and constrained. The cost of these operations can be relatively easily assessed a priori and managed accordingly to provide a secure multi-tenant platform. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
