Database Reference
In-Depth Information
to predict the physical resource consumption, such as disk I/O, memory, and CPU,
for each query. Floratou et al. [
131
] have studied the performance and associated
costs in the relational database as a service environments. The results show that
given a range of pricing models and the flexibility of the allocation of resources in
cloud-based environments, it is hard for a user to figure out their actual monthly
cost upfront. Soror et al. [
211
] introduced a virtualization design advisor that uses
information about the database workloads to provide offline recommendations of
workload-specific virtual machines configurations.
In practice, it is a very challenging goal to delegate the management of the SLA
requirements of the customer applications to the cloud service provider due to the
wide heterogeneity in the workload characteristics, details and granularity of SLA
requirements, and cost management objectives of the very large number of customer
applications that can be simultaneously running in a cloud environment. Therefore,
it becomes a significant issue for the cloud customers to be able to monitor and
adjust the deployment of their systems if they intend to offer viable SLAs to their
customers. Failing to achieve these goals will jeopardize the sustainable growth of
cloud computing in the future and may result in valuable applications being moved
away from the cloud. In the following sections, we present our customer-centric
approach for managing the SLA requirements of virtualized database servers.
7.2
Architecture of SLA Management Framework
Figure
7.2
shows an overview of the framework architecture which consists of three
main modules: the
monitor module
,the
control module
and the
action module
.
In this architecture, the monitor module is responsible for continuously tracking
the replication delay of each virtualized database replica server and feeding the
control module with the collected information. The control module is responsible
for continuously checking the replication delay of each replica server against its
associated application-defined SLA of data freshness and triggers the action module
to scale out the database tier with a new virtualized database replica server when it
detects any SLA-violation in any current replica server.
The key design principles of the framework architecture are to be application-
independent and to require no code modification on the customer software applica-
tions that the framework will support. In order to achieve these goals, the framework
relies on a database proxying mechanism which forwards database requests to
the underlying databases and returns the results to the client transparently using
an intermediate piece of software, the proxy, without the need of having any
database drivers installed [
203
]. In particular, a database proxy software is a simple
program that sits between the client application and the database server that can
monitor, analyze or transform their communications. Such flexibility allows for a
wide variety of uses such as load balancing, query analysis and query filtering.
The implementation details for each of the three main modules of the framework
architecture will be discussed in the remaining part of the section.
