Excerpts from Janczuk, Tomasz's message of 2014-06-11 10:05:54 -0700: > 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.
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." _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev