Open Stack

Excerpts from Janczuk, Tomasz's message of 2014-06-11 10:05:54 -0700:
> 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. 

There's at least one, and it is fairly popular:

http://www.postgresql.org/docs/9.3/static/tutorial-arch.html

"The PostgreSQL server can handle multiple concurrent connections from
clients. To achieve this it starts ("forks") a new process for each
connection. From that point on, the client and the new server process
communicate without intervention by the original postgres process."