4 research outputs found
Performance Isolation in Multi-Tenant Applications
The thesis presents methods to isolate different tenants, sharing one application instance, with regards to he performance they observe. Therefore, a request based admission control is introduced. Furthermore, the publication presents methods and novel metrics to evaluate the degree of isolation a system achieves. These insights are used to evaluate the developed isolation methods, resulting in recommendations of methods for various scenarios
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
Architecting the deployment of cloud-hosted services for guaranteeing multitenancy isolation.
In recent years, software tools used for Global Software Development (GSD) processes (e.g., continuous integration, version control and bug tracking) are increasingly being deployed in the cloud to serve multiple users. Multitenancy is an important architectural property in cloud computing in which a single instance of an application is used to serve multiple users. There are two key challenges of implementing multitenancy: (i) ensuring isolation either between multiple tenants accessing the service or components designed (or integrated) with the service; and (ii) resolving trade-offs between varying degrees of isolation between tenants or components. The aim of this thesis is to investigate how to architect the deployment of cloud-hosted service while guaranteeing the required degree of multitenancy isolation. Existing approaches for architecting the deployment of cloud-hosted services to serve multiple users have paid little attention to evaluating the effect of the varying degrees of multitenancy isolation on the required performance, resource consumption and access privilege of tenants (or components). Approaches for isolating tenants (or components) are usually implemented at lower layers of the cloud stack and often apply to the entire system and not to individual tenants (or components). This thesis adopts a multimethod research strategy to providing a set of novel approaches for addressing these problems. Firstly, a taxonomy of deployment patterns and a general process, CLIP (CLoud-based Identification process for deployment Patterns) was developed for guiding architects in selecting applicable cloud deployment patterns (together with the supporting technologies) using the taxonomy for deploying services to the cloud. Secondly, an approach named COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) was developed together with supporting algorithms and then applied to three case studies to empirically evaluate the varying degrees of isolation between tenants enabled by multitenancy patterns for three different cloud-hosted GSD processes, namely-continuous integration, version control, and bug tracking. After that, a synthesis of findings from the three case studies was carried out to provide an explanatory framework and new insights about varying degrees of multitenancy isolation. Thirdly, a model-based decision support system together with four variants of a metaheuristic solution was developed for solving the model to provide an optimal solution for deploying components of a cloud-hosted application with guarantees for multitenancy isolation. By creating and applying the taxonomy, it was learnt that most deployment patterns are related and can be implemented by combining with others, for example, in hybrid deployment scenarios to integrate data residing in multiple clouds. It has been argued that the shared component is better for reducing resource consumption while the dedicated component is better in avoiding performance interference. However, as the experimental results show, there are certain GSD processes where that might not necessarily be so, for example, in version control, where additional copies of the files are created in the repository, thus consuming more disk space. Over time, performance begins to degrade as more time is spent searching across many files on the disk. Extensive performance evaluation of the model-based decision support system showed that the optimal solutions obtained had low variability and percent deviation, and were produced with low computational effort when compared to a given target solution