Database Reference
In-Depth Information
it is not the main focus of this chapter to investigate different strategies for making
these decisions. This aspect will be left for future work.
In the last chapter, it has been noted that the effect of the configurations of
geographic location of the virtualized database replica server is not as significant
as the effect of the overloading workloads in increasing the staleness window of the
replica servers. Therefore, the control module can decide to stop an active replica
server when it detects a decreasing workload that can be served by less number of
replica servers without violating the application-defined SLAs in order to reduce the
monetary cost of the running application.
Action Module
The action module is responsible for adding a new virtualized database replica
server when it is triggered by the action module. In general, adding a new replica
server involves extracting database content from an existing replica server and
copying that content to a new replica server. In practice, the time of executing
these operations mainly depends on the database size. To provision virtualized
database replica servers in a timely fashion, it is necessary to periodically snapshot
the database state in order to minimize the database extraction and copying
time to that of only the snapshot synchronization time. There is a trade-off
between the time to snapshot the database, the size of the transactional log
and the amount of update transactions in the workload. This trade-off can be
further optimized by applying recently proposed live database migration techniques
[
96
,
128
].
In order to keep the experiments focused on the main concerns of the framework,
a set of hot backups, which are originally not used for serving the application
requests but kept synchronized, are used and then can be made active and used
by the load balancer for serving the application requests when the action module is
triggered for adding a new virtualized database replica server. The study of the cost
and effect of the live database migration activities will also be left as future work.
7.3
Implementation of SLA Management Framework
Figure
7.3
illustrates the setup of experiments for the SLA management framework
in the Amazon EC2 platform. Besides the SLA management framework, the
experiment setup also adopts the customized Cloudstone benchmark, MySQL
replication with a fine-grained time/date function, and MySQL Proxy,
2
as necessary,
components.
