![](bg4.png)
4.1.1 Elasticity Controller Mock
The ECM is designed to reproduce the elastic behav-
ior. By default, ECM requires as input a sequence of
elasticity changes, denoted by E = {ec
1
, ec
2
, ..., ec
n
},
where each ec is a pair that corresponds to an elas-
ticity change. Elasticity change pairs are composed
of a required elasticity state (s
i
) and a workload (W
i
),
ec
i
=
h
s
i
, W
i
i
where 1 ≤ i ≤ n. A workload is charac-
terized by an intensity (i. e., amount of operations per
second), and a workload type (i. e., set of transactions
sent to the cloud system).
ECM reads elasticity change pairs sequentially.
For each pair, ECM requests resource changes to meet
elasticity state s
i
and requests the Workload Genera-
tor to apply the workload W
i
. Indeed, we have to send
the corresponding workload to prevent cloud infras-
tructure to provoke unexpected resource variations.
In particular, it could deallocate a resource that ECM
just allocated, because the workload has remained low
and under the scale-in threshold.
Instead of waiting for the cloud computing infras-
tructures for elasticity changes, it directly requests
to change the resource allocation (elasticity control).
Based on both, required elasticity state and workload
(elasticity change pair), ECM anticipates the resource
changes. To be sure CBS enters the expected elas-
ticity state, ECM queries the Cloud Monitor, which
periodically monitors the cloud infrastructure.
The ECM may also lead to a precise resource
deallocation (selective elasticity). Typically, elastic-
ity changes are transparent to the tester, managed by
the cloud provider. To set up the selective elastic-
ity, ECM requires a secondary input, i. e., Selective
Elasticity Requests (SER). SER is denoted by SER =
{(ec
1
, ser
1
), ..., (ec
n
, ser
n
)}, where ec
i
∈ E, and ser
i
refers to a selective elasticity request. A selective
elasticity request is a reference to an algorithm (freely
written by tester) that gets a resource’s ID. When ec
i
is performed by ECM, the algorithm referred by ser
i
is executed, and the resource with the returned ID is
deallocated by ECM.
ECM helps in ensuring all of elasticity testing re-
quirements. As earlier explained in this section, it de-
terministically requests resource variations (elasticity
control and selective elasticity), and helps on ensur-
ing the event scheduling providing information of the
current elasticity state to the Event Scheduler.
4.1.2 Workload Generator
The Workload Generator is responsible for generat-
ing the workload (W ). We base it on Albonico et
al. work (Albonico et al., 2016), which takes into
account a threshold-based elasticity (see Figure 1),
where resource change demand occurs when a thresh-
old is breached for a while (reaction time). Therefore,
a workload should result in either threshold breached
(for scaling states) or not breached (for ready state),
during the necessary time. To ensure this, the Work-
load Generator keeps the workload constant, either
breaching a threshold or not, until a new request ar-
rives.
Considering a scale-out threshold is set as 60% of
CPU usage, the workload should result in a CPU us-
age higher than 60% to request a scale-out. In that
case, if 1 operation A hypothetically uses 1% of CPU,
it would be necessary at least 61 operations A to re-
quest the scale-out. On the other hand, less than 61
operations would not breach the scale-out threshold,
keeping the resource steady.
The Workload Generator contributes with the
Elasticity Controller Mock to the elasticity control re-
quirement.
4.1.3 Event Scheduler
The Event Scheduler input is a map associating sets of
events to elasticity changes (ec
i
), i. e., the set of events
that should be sent to the cloud system when a given
elasticity change is managed by the ECM. Table 3 ab-
stracts an input where four events are associated to
two elasticity changes.
Table 3: Events Schedule.
Elasticity Change Event ID Execution Order Wait Time
ec
1
e1 1 0 s
e2 2 10 s
e3 2 0 s
ec
2
e2 1 0 s
e4 2 0 s
Periodically, the Event Scheduler polls the ECM
for the current elasticity change, executing the events
associated to it. For instance, when the ECM manages
the elasticity change ec
1
, it executes the events e
1
, e
2
,
and e
3
. Events have execution orders, which define
priorities among events associated to the same state:
event e
1
is executed before events e
2
and e
3
. Events
with the same execution order are executed in paral-
lel (e. g., e
2
and e
3
). Events are also associated to a
wait time, used to delay the beginning of an event. In
Table 3, event e
2
has a wait time of 10 s (starting 10 s
after e
3
, but nonetheless executed in parallel). This
delay may be useful, for instance, to add a server to
the server list a few seconds after the ready state be-
gins, waiting for data synchronization to be finished.
The Event Scheduler ensures the event scheduling
requirement.
CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science
498