Database Reference
In-Depth Information
may have an SLA of 100 ms execution time, a search request may have an SLA of
600 ms while a request of submitting an order information would have 1,500 ms).
Obviously, the variations in the SLA of different applications transactions is due to
their different natures and their differences in the consumption behaviour of system
resources (e.g. disk I/O, CPU time). In practice, each application transaction can
send one or more operations to the underlying database system. Therefore, in our
framework, consumer applications can define each transaction as pattern(s) of SQL
commands where the transaction execution time is computed as the total execution
time of these individual operations in the described pattern. Thus, the monitoring
module is responsible for correlating the received database operations based on
their sender in order to detect the transaction patterns [
203
]. Our framework also
enables the consumer application to declaratively define application-specific
action
rules
to adaptively scale out or scale in according to the monitored status of the
response times of application transactions. For example, an application can define to
scale out the underlying database tier if the average percentage of SLA violation for
transactions T
1
and T
2
exceeds 10 % (of the total number of T
1
and T
2
transactions)
for a continuous period of more than 8 min. Similarly, the application can define to
scale in the database tier if the average percentage of SLA violation for transactions
T
1
and T
2
is less than 2 % for a continuous period that is more than 8 min and the
average number of concurrent users per database replica is less than 25.
We conducted our experiments with 4 different rules for achieving elasticity and
dynamic provisioning for the database tier in the cloud. Two rules are defined based
on the average CPU utilization of allocated virtual machines for the database server
as follows: Scale out the database tier (add one more replica) when the average
CPU utilization of the virtual machines exceeds of 75 % for (
R1
) and 85 % for
(
R2
) over a continuous period of 5 min. Two other rules are defined based on the
percentage of the SLA satisfaction of the workload transactions (the SLA values
of the different transactions are defined as specified in the Cloudstone benchmark)
as follows: Scale out the database tier when the percentage of SLA satisfaction is
less than 97 % for (
R3
) and 90 % for (
R4
) over a continuous period of 5 min. Our
evaluation metrics are the overall percentage of SLA satisfaction and the number of
provisioned database replicas during the experimental time.
Figure
7.13
illustrates the results of running our experiments over a period of
1 h for the 80/20 workload (Fig.
7.13
a) and the 50/50 workload (Fig.
7.13
b). In
these figures, the
X-axis
represents the elapsed time of the experiment while the
Y-axis
represents the SLA satisfaction of the application workload according to
the different elasticity rules. In general, we see that, even for this relatively small
deployment, the incorporation of SLA-based rules can show improved overall SLA
satisfaction of different workloads of the application. The results show that the
SLA-based rules (
R3
and
R4
) are, by design, more sensitive for achieving the SLA
satisfaction and thus they react earlier than the resource-based rules. The resource-
based rules (
R1
and
R2
) can accept a longer period SLA violations before taking
any necessary action (CPU utilization reaches the defined limit). The benefits of
SLA-based rules become clear with the workload increase (increasing the number
of users during the experiment time). The gap between the resource-based rules
