Open Stack

On 6/11/14, 2:43 AM, "Gordon Sim" <gsim at 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.