6 research outputs found
Implementing the required degree of multitenancy isolation : a case study of cloud-hosted bug tracking system
Implementing the required degree of isolation between tenants is one of the significant challenges for deploying a multitenant application on the cloud. In this paper, we applied COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) for a cloud-hosted Bug tracking system using Bugzilla. The study revealed among other things that a component deployed based on dedicated component offers the highest degree of isolation (especially for database transactions where support for locking is enabled). Tenant isolation based on performance (e.g., response time) favoured shared component (compared to resource consumption (e.g., CPU and memory) which favoured dedicated component). We also discuss key challenges and recommendations for implementing multitenancy for application components in cloud-hosted bug tracking systems with guarantees for isolation between multiple tenants
Evaluating degrees of tenant isolation in multitenancy patterns : a case study of cloud-hosted Version Control System (VCS)
One of the key concerns of implementing multitenancy (i.e., serving multiple tenants with a single instance of an application) on the cloud is how to enable the required degree of isolation between tenants, so that the required performance of one tenant does not affect other tenants. There is little research which provides empirical evidence on the required degree of isolation between tenants under different cloud deployment conditions. This paper applies COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by multitenancy patterns for cloud-hosted Version Control System (VCS). We implemented three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) by developing a multitenant component using the FileSystem SCM plugin integrated within Hudson. The study revealed that dedicated component provides the highest degree of isolation between tenants (compared to shared component and tenant-isolated component) in terms of error% (i.e., the percentage of errors with unacceptably slow response times) and throughput. System load of tenants showed no variability, and hence did not influence the degree of tenant isolation for all the three multitenancy patterns. We also provide some recommendations to guide an architect in implementing multitenancy isolation on similar VCS tools like Subversion and CVS
Degrees of tenant isolation for cloud-hosted software services : a cross-case analysis
A challenge, when implementing multi-tenancy
in a cloud-hosted software service, is how to ensure that the
performance and resource consumption of one tenant does
not adversely affect other tenants. Software designers and
architects must achieve an optimal degree of tenant isolation
for their chosen application requirements. The objective
of this research is to reveal the trade-offs, commonalities,
and differences to be considered when implementing
the required degree of tenant isolation. This research uses
a cross-case analysis of selected open source cloud-hosted
software engineering tools to empirically evaluate varying
degrees of isolation between tenants. Our research reveals
five commonalities across the case studies: disk space reduction,
use of locking, low cloud resource consumption,
customization and use of plug-in architecture, and choice of
multi-tenancy pattern. Two of these common factors compromise
tenant isolation. The degree of isolation is reduced
when there is no strategy to reduce disk space and customization
and plug-in architecture is not adopted. In contrast,
the degree of isolation improves when careful consideration
is given to how to handle a high workload, locking of
data and processes is used to prevent clashes between multiple
tenants and selection of appropriate multi-tenancy pattern. The research also revealed five case study differences:
size of generated data, cloud resource consumption, sensitivity
to workload changes, the effect of the software process,
client latency and bandwidth, and type of software process.
The degree of isolation is impaired, in our results, by
the large size of generated data, high resource consumption
by certain software processes, high or fluctuating workload,
low client latency, and bandwidth when transferring multiple
files between repositories. Additionally, this research
provides a novel explanatory framework for (i) mapping tenant
isolation to different software development processes,
cloud resources and layers of the cloud stack; and (ii) explaining
the different trade-offs to consider affecting tenant
isolation (i.e. resource sharing, the number of users/requests,
customizability, the size of generated data, the scope of control
of the cloud application stack and business constraints)
when implementing multi-tenant cloud-hosted software services.
This research suggests that software architects have
to pay attention to the trade-offs, commonalities, and differences
we identify to achieve their degree of tenant isolation
requirements
Optimal deployment of components of cloud-hosted application for guaranteeing multitenancy isolation
One of the challenges of deploying multitenant cloud-hosted
services that are designed to use (or be integrated with) several
components is how to implement the required degree
of isolation between the components when there is a change
in the workload. Achieving the highest degree of isolation
implies deploying a component exclusively for one tenant;
which leads to high resource consumption and running cost
per component. A low degree of isolation allows sharing of
resources which could possibly reduce cost, but with known
limitations of performance and security interference. This
paper presents a model-based algorithm together with four
variants of a metaheuristic that can be used with it, to provide
near-optimal solutions for deploying components of a
cloud-hosted application in a way that guarantees multitenancy
isolation. When the workload changes, the model based
algorithm solves an open multiclass QN model to
determine the average number of requests that can access
the components and then uses a metaheuristic to provide
near-optimal solutions for deploying the components. Performance
evaluation showed that the obtained solutions had
low variability and percent deviation when compared to the
reference/optimal solution. We also provide recommendations
and best practice guidelines for deploying components
in a way that guarantees the required degree of isolation
Recommended from our members