We developed a model named AutoElastic, joining the power from cloud computing and HPC applications. Here, we present the architecture, the parallel programming model, some metrics and an experimental evaluation.

1. Discussing new Ideas and presenting possibilities on joint-collaboration
Prof. Dr. Rodrigo da Rosa Righi
Contact: rrrighi@unisinos.br
Automatic Resource Elasticity
for High Performance
Applications in the Cloud

2. Agenda
Introduction
HPC applications and
Elasticity
AutoElastic Proposal
Evaluation Methodology
Results
Conclusion
Future Work and Collaboration

3. Introduction
The most common approach for
elasticity is the replication of stand-
alone virtual machines (VMs)
This mechanism was originally developed for dynamic scaling
server-based applications, such as web, e-mail and databases.
Load
Balancer
VM Replica
Request
Dispatching
Request Execution
VM Replica
User
Request
VM Replica
New VM
Replica

4. HPC Applications and Elasticity
HPC applications still have difficulty when taking advantage
of the elasticity because of their typical development in which
a fixed number of processes (or threads) are used.
MPI-2: Despite overcoming this limitation by providing
dynamic process creation, the applications with MPI 2.0 are
not ready, by default, to present an elastic behaviour, i.e., the
implementation must explicitly create or destroy processes
during execution.

5. In addition, we have problems with
sudden disconnections.
Anything else?
HPC Applications and Elasticity

6. We developed AutoElastic: AutoElastic acts at the PaaS level of
a cloud, not imposing either modifications on the application
source code or extra definitions of elasticity rules and
actions by the programmer.
HPC Applications and Elasticity

7. AutoElastic brings two contributions to the state-of-the-art in HPC
applications in the cloud:
Use of an Aging-based
technique for managing cloud
elasticity to avoid thrashing on
vir- tual machine allocation
and deallocation procedures.
An infrastructure to provide
asynchronism on creating
and destroying virtual
machines, pro- viding
parallelism of such
procedures and regu- lar
application execution.
HPC Applications and Elasticity

8. AutoElastic
Design Decisions
Users do not need to
configure the
elasticity mechanism;
programmers do not
need to rewrite their
application to profit
from the cloud
elasticity
AutoElastic
offers a reactive,
automatic and
horizontal
elasticity,
following the
replication
strategy to
enable it
Because it is a
PaaS-based
framework,
AutoElastic
comprises tools for
transforming a
parallel application
to an elastic
application
transparently to
users
AutoElastic
analyses the load
peaks and
sudden drops for
not launching
unnecessary
actions, avoiding
a phenomenon
known as
thrashing.

9. AutoElastic
rce reconfigurations by him-
ained earlier, this strategy re-
the programmer and would
ifferent cloud deployments.
PAAS-BASED MODEL
ASTICITY MANAGEMENT
utoElastic, which is an elas-
on high performance appli-
ased on reactive elasticity, in
ed without user intervention.
ty rules is not a trivial task
nvolves the setup of one or
resources, number of occur-
ks and monitoring windows.
ncommon to have situations
icity rules control the behav-
d present poor performance
and sudden drops for not launching unnecessary
actions, avoiding a phenomenon known as thrashing.
if metric > x
then A1
if metric < y
then A2
A1: Allocate
VM
A2: Deallocate
VM
#include<>
int main()
{….
}
ActionsRules Application
Rules Actions
(b)
AutoElastic Manager
Monitoring
Resource
Management
Cloud Front-End
AutoElastic
Middleware
Application
Resources
(a)
Cloud
Monitoring
Resource
Management
Cloud Front-End
Application
Resources
Rules Actions
Cloud
#include<>
int main()
{….
}
Application
Fig. 1. (a) Approach adopted by Azure and Amazon
AWS, in which the user must define elasticity rules and
configure metrics beforehand; (b) AutoElastic idea.
(a) Approach adopted by Azure and Amazon AWS, in which the user must
define elasticity rules and configure metrics beforehand; (b) AutoElastic

10. AutoElastic
to explore better efficiency for HPC applications.
VM
Master
Cloud
SM S
Node 0
M
S
Master
process
Slave
process
VM0 VMc-1
S S
Node m-1
VMc VMn-1
Area
for
Data
Share Cloud
Front-
End
Interconnection Network
AutoElastic
Manager
Appli-
cation
Virtual
Machines
Computational
Resources
Fig. 2. AutoElastic architecture. Here, c denotes the
number of cores inside a node, m is the number of
nodes and n refers to the number of VMs running slave
processes, being obtained by c.m.
m
t
t
o
e
w
I
2
r
p
w
i
t
a
f
b
AutoElastic architecture. Here, c denotes the number of cores inside a node,
m is the number of nodes and n refers to the number of VMs running slave
processes, being obtained by c.m.

11. AutoElastic
Elasticity model: Three actions.
Action 1: There is a
new resource with c
virtual machines which
can be accessed using
given IP addresses
Action 2: Request for
permission to
consolidate a specific
node, which encompasses
given virtual machines.
Action 3: Answer for
Action 2 allowing the
consolidation of the
specified compute
node.
Manager -> Master Manager -> Master Master -> Manager

12. AutoElastic
AutoElastic
Manager
Master
Process
Shared Data
Area Entity
Slave
Process
System
Load
greater
than the
Maximum
Threshold
Launch a
new VM
Is_there_Action1()
No Actions
Write Action1
Yes and this is
the process data
Connection
Request
Connection Reply
Application Task
Processing
Response
No Actions
VM
Create Slave
Process
loop: test =
false
Is_there_Action1()
Is_there_Action1()
Elasticity
Evaluation at
each
external loop
Get_Master_data()
Master IP
Asynchronous
Elasticity:
Concomitance between
VM launching and the
Master execution
is_VM_up()
Sequence diagram:
when detecting a
system load greater
than the maximum
threshold.

13. AutoElastic
alternative, to join both
. Regarding the consoli-
ain is always a compute
; as a result, all VMs that
own with such an action.
by the fact that a node is
rs and that this approach
on. In particular, Baliga et
er of VMs in a node is not
the energy consumption;
e is on or off is influential.
ed Data
a Entity
Slave
Process
VM
Elasticity
Evaluation at
Asynchronous
Elasticity:
Concomitance between
VM launching and the
RULE1: if CONDITION1 then ACTION1
RULE2: if CONDITION2 then ACTION2
CONDITION1: System load(j) > threshold1, where j means the last
monitoring observation
CONDITION2: System load(j) < threshold2, where j means the last
monitoring observation
ACTION1: Allocates a new node and launches n VMs on it, where n is
the number of cores inside the node
ACTION2: Finalizes the VM instances that are running inside a node
and performs the node consolidation afterwards
Fig. 4. Reactive-driven elastic model of AutoElastic.
System Load(j) =
1
n
.
n 1X
i=0
LP(i, j) (1)
such that
city as an alternative, to join both
fficient way. Regarding the consoli-
he work grain is always a compute
specific VM; as a result, all VMs that
e will go down with such an action.
s explained by the fact that a node is
ng other users and that this approach
consumption. In particular, Baliga et
at the number of VMs in a node is not
ial factor on the energy consumption;
that the node is on or off is influential.
Master
Process
Shared Data
Area Entity
Slave
Process
Is_there_Action1()
No Actions
VM
Create Slave
Process
Is_there_Action1()
Elasticity
Evaluation at
each
external loop
Get_Master_data()
Master IP
Asynchronous
Elasticity:
Concomitance between
VM launching and the
Master execution
)
RULE1: if CONDITION1 then ACTION1
RULE2: if CONDITION2 then ACTION2
CONDITION1: System load(j) > threshold1, where j means the last
monitoring observation
CONDITION2: System load(j) < threshold2, where j means the last
monitoring observation
ACTION1: Allocates a new node and launches n VMs on it, where n is
the number of cores inside the node
ACTION2: Finalizes the VM instances that are running inside a node
and performs the node consolidation afterwards
Fig. 4. Reactive-driven elastic model of AutoElastic.
System Load(j) =
1
n
.
n 1X
i=0
LP(i, j) (1)
such that
LP (i, j) =
( 1
2 L(i, j) ifj = t window + 1
1
2 LP (i, j 1) + 1
2 L(i, j) ifj 6= t window + 1
(2)
where t is the value of j when System load(j) is
called, and L(i,j) refers to the CPU load of VM i at

14. AutoElastic
• Values of load: 82, 78, 81, 80, 77, 93:
itoring activity is
r captures the val-
VM and uses them
m and maximum
vation entails the
ding (allowing the
og-rotate fashion.
anager repository.
model for the Au-
tem contemplates
only the actions
c Manager. In the
ystem Load(j) is an
oad Prediction) of
M, j is the current
of VMs that are
and 2 present the
with a parameter-
express the 1.56% and 0.78% percentages, respectively.
We employ the idea of Aging when addressing peak
situations, especially to avoid either false-negative or
false-positive elasticity actions. For example, assum-
ing a maximum threshold of 80%, a window equal
to 6 and monitoring values such as 82, 78, 81, 80,
77 and 93 (the most recent one), we have LP(i,j) =
1
2 .93+ 1
4 .77+ 1
8 .80+ 1
16 .81+ 1
32 .78+ 1
64 .82 = 84.53. This
value enables resource reconfiguration. In contrast to
the AutoElastic approach, Imai et al. [5] expect x
consecutive observations outside the margin of the
threshold. In this case, the use of x equal to either
2, 3 or 4 samples does not imply elasticity, and the
system will operate at its saturated capacity.
In addition to the aforementioned false-negative
scenario, a scenario of false-positive can be given as
follows. Taking as an example the situation depicted
in Figure 5 and systems that analyze the load as a
unique measure [36], elasticity actions are performed
EEE TRANSACTIONS ON CLOUD COMPUTING, VOL X, NO Y, JANUARY 2015
or thrashing avoidance. The use of time series is
pertinent for not launching reconfigurations when
unexpected peaks in performance are observed.
Load of observed metric
Application
execution
time
100%
Maximum
threshold
Minimum
threshold
Fig. 5. This scenario illustrates situations where alloca-
on and deallocation actions take place, but they could
1. size = initial_mapping(ports);
2. for (j=0; j< total_tasks; j++){
3. publish_ports(ports, size);
4. for (i=0; i< size; i++){
5. conection_accept(slaves[i],
6. }
7. calculate_load(size, work[j], in
8. for (i=0; i< size; i++){
9. task = create_task(work[j], int
10. send_assync(slaves[i], task
11. }
12. for (i=0; i< size; i++){
13. recv_sync(slaves[i], results
14. }
15. store_results(slave[j], results)
16. for (i=0; i< size; i++){
17. disconnect(slaves[i]);
18. }
19. unpublish_ports(ports);
20. }
(a)
This scenario illustrates
situations where
allocation and
deallocation actions take
place, but they could be
neglected for thrashing
avoidance.

15. AutoElastic
use of time series is
configurations when
ce are observed.
Application
execution
time
uations where alloca-
place, but they could
nce.
l
1. size = initial_mapping(ports);
2. for (j=0; j< total_tasks; j++){
3. publish_ports(ports, size);
4. for (i=0; i< size; i++){
5. conection_accept(slaves[i], ports[i]);
6. }
7. calculate_load(size, work[j], intervals);
8. for (i=0; i< size; i++){
9. task = create_task(work[j], intervals[i]]);
10. send_assync(slaves[i], task);
11. }
12. for (i=0; i< size; i++){
13. recv_sync(slaves[i], results[i];
14. }
15. store_results(slave[j], results);
16. for (i=0; i< size; i++){
17. disconnect(slaves[i]);
18. }
19. unpublish_ports(ports);
20. }
1. master = lookup(master_address, naming);
2. port = create_port(IP_address, VM_id);
3. while (true){
4. connection_request(master, port);
5. recv_sync(master, task);
6. result = compute(task);
7. send_assync(master, result);
8. disconnect(master);
9. }
(a)
(b)
1. int changes = 0;
2. if (action == 1){
3. changes += add_VMs();
4. }
5. else if (action == 2){
6. changes -= drop_VMs();
7. allow_consolidation();// enabling action3
8. }
9. if (action ==1 or action == 2){
10 reorganize_ports(ports);
11. }
12. size += changes;
(c)
Fig. 6. Application model in pseudo-language: (a)
Master process; (b) Slave process; (c) elasticity code
Application Model: (a) master code; (b) slave
code; (c) elasticity code.

16. Results
to the cloud middleware. AutoElastic Manager runs
outside the Cloud and uses the OpenNebula API to
control and launch VMs. Our SLA was set up for a
minimum of 2 nodes (4 VMs) and a maximum of 10
nodes (20 VMs). Finally, we adopt a window parameter
that is equal to 6 in the load prediction (LP) function
to ensure that the weight of each observation is larger
than 1% (see Subsection 3.3 for detail).
0
1
2
3
4
5
6
7
8
9
10
1
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
5500
6000
6500
7000
7500
8000
8500
9000
9500
10000
Numberofsubintervals
[load(x)]x100000
Iteration
Load Function along iterations
Constant
Ascending
Descending
Wave
generating the numerical integration
For the sake of simplicity, the same
ployed in the tests, but the number of
the integration varies.
the cloud infrastructure, OpenNebula
a cluster with 10 nodes. Each node
sors, which are exclusively dedicated
iddleware. AutoElastic Manager runs
ud and uses the OpenNebula API to
nch VMs. Our SLA was set up for a
nodes (4 VMs) and a maximum of 10
. Finally, we adopt a window parameter
6 in the load prediction (LP) function
he weight of each observation is larger
ubsection 3.3 for detail).
Inequality 7.
Cost = App Time . Resource (5)
such that
Resource =
nX
i=1
(i ⇥ Obs(i)) (6)
then, the goal is to obtain
Cost↵  Cost (7)
where ↵ and refer to the AutoElastic execution
with and without elasticity support, respectively.
• Analyzing Asynchronous Elasticity: the goal is
to present the benefits of asynchronous elasticity
and the master process behavior when resource
reconfiguration takes place. Regarding the mea-
sured metrics, we are observing both the times to
launch a VM and to deliver it to application.
4.3.1 Performance and Elasticity Viability
Table 4 presents the results when executing the nu-
Evaluation
Methodology

17. Resultse
n
s
g
-
-
.
)
)
-
d
,
mean the Ascending, Descending and Wave load
patterns. The times are expressed in seconds.Starting
VMs
Load Scenario i: AutoElastic
with elasticity support
Scenario ii: AutoElastic
without elasticity support
Time
Obser-
vations
Resource Cost Time
Obser-
vations
Resource Cost
4
A 1978 65
26*4+27*6+12*8
= 362
716036 2426 81
81*4 =
324
786024
D 1775 56
4*4+16*6+36*8 =
400
710000 2397 81
81*4 =
324
776628
W 1895 59
4*4+22*6+33*8 =
412
780740 2444 82
82*4 =
328
801632
8
A 1789 57 39*6+18*8 = 378 676242 1555 52
52*8 =
416
646880
D 1570 52 8*6+44*8 = 400 628000 1561 52
52*8 =
416
649376
W 1686 55 19*6+36*8 = 402 677772 1599 53
53*8 =
424
677976

18. ResultsIEEE TRANSACTIONS ON CLOUD COMPUTING, VOL X, NO Y, JANUARY 2015 12
IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL X, NO Y, JANUARY 2016 1
0
100
200
300
400
500
600
700
800
0
120
241
361
481
602
722
865
990
1111
1231
1352
1472
1613
1738
1862
1982
CPULoad
Time in Seconds
(a)
0
100
200
300
400
500
600
700
800
0
90
203
295
388
500
594
688
778
869
959
1050
1141
1231
1325
1416
1507
1597
1731
CPULoad
Time in Seconds
(b)
0
100
200
300
400
500
600
700
800
0
91
205
297
390
504
597
691
781
872
997
1088
1179
1293
1386
1480
1571
1662
1752
1864
CPULoad
Time in Seconds
(c)
Fig. 8. CPU load behavior when using the following starting configuration: 2 nodes, 4 VMs and 4 CPUs
IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL X, NO Y, JANUARY 2016 1
0
100
200
300
400
500
600
700
800
0
151
302
452
603
754
905
1056
1207
1358
1509
1660
1812
1963
2114
2265
2416
CPULoad
Time in Seconds
AutoElastic without Elasticity Support, starting with
2 nodes and 4 VMs
0
100
200
300
400
500
600
700
800
0
120
240
361
482
603
723
844
964
1085
1206
1327
1447
1568
1688
1808
1930
2051
2172
2293
CPULoad
Time in Seconds
AutoElastic without Elasticity Support, starting with
2 nodes and 4 VMs
0
100
200
300
400
500
600
700
800
0
150
302
452
603
754
906
1056
1208
1359
1509
1659
1810
1961
2113
2263
2415
CPULoad
Time in Seconds
AutoElastic without Elasticity Support, starting with
2 nodes and 4 VMs
Fig. 8. CPU load behavior when using the following starting configuration: 2 nodes, 4 VMs and 4 CPUs
(a) (b) (c)
IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL X, NO Y, JANUARY 2016 12
Allocated Used Maximum Threshold Minimum Threshold
Fig. 9. CPU behavior when starting with 2 nodes and the following load patterns: (a) Ascending; (b) Descending;
Fig. 8. CPU load behavior when using the following starting configuration: 2 nodes, 4 VMs and 4 CPUs
Fig. 8. CPU load behavior when using the following starting configuration: 2 nodes, 4 VMs and 4 CPUs

19. Results
0
Time in seconds
700690 710 720
CPUload%
20
40
60
80
100
Time in seconds
1760 1770 1780 1790 1800
(a) Impact of VM deallocation in running VMs
(b) Impact of VM allocation in running VMs
Moment where the master
establishes the connection
with two newer processes
680
CPU 1
CPU 2
Fig. 11. Impact in the running processes regarding
resource
the Grid,
[8] A. Ravee
elastic ex
Symp. on
Washingt
[9] G. Galan
puting el
Computin
[10] A. N. To
cloud co
survey,”
[11] D. Chiu
options o
(GRID), 2
[12] E. Lusk,
model,”
Working C
[13] D. Rajan,
a high p
tion,” in
Science, W

20. Conclusion
Main ideas
Asynchronous Elasticity
Weighted Moving Average = Aging concept
Limitations
Reactive Elasticity
Thresholds are fixed
Elasticity actions take place after
observing modifications in the
application’s demand. VM
launching is time consuming.

21. Future Work and Collaboration
Proactive Elasticity
Reinforcement learning
Time series
Neural networks
Cloud
Elasticity
+ HPC
CPU
Load
Execution
time
100%
Pattern
+ - -+
CPU
Load
Execution
Time
100%
Fase1 Fase2 Fase3 Fase1 Fase2 Fase3 Fase1 Fase2 Fase3
Pattern

22. Future Work and Collaboration
Adaptable thresholds
Covering Divide-and-Conquer
and Bulk-Synchronous Parallel
applications
Cloud
Elasticity +
HPC

23. Future Work and Collaboration
Internet of
Things -
Scalability
Internet of Things
Middleware
Collection and
Aggregation of Data
Processed Data
about IoT devices
IoT-Enabled DevicesUser Applications

24. Future Work and Collaboration
Internet of
Things -
Scalability

25. Future Work and Collaboration
EFT
Scenarios -
Load
Balancing
Cards
Prepaid
Phone
Transport
cards
Terminal
Configuration
Information
Security
Fraud
Prevention
Processing
Machine 1
Internal Subsystems
POS
ATM
X.25➝IP
Output
Systems 1
Output
Systems 2
Output
Systems m
Incomming
Transactions
Switch
DB DB DB DB
Auxiliary
Systems
EFT
Processing
Machine 2
Processing
Machine n
Optimized
Scheduler
GetLB Data
GetLB Data
GetLB Data
Scheduling
Data
Notification