Internet of Things (IoT) is experiencing a huge hype these days, thanks to the increasing capabilities of embedded devices that enable their adoption in new fields of application (e.g. Wireless Sensor Networks, Connected Cars, Health Care, etc.). On the one hand, this is leading to an increasing adoption of multi-tenancy solutions for Cloud and Fog Computing, to analyze and store the data produced. On the other hand, power consumption has become a major concern for almost every digital system, from the smallest embedded circuits to the biggest computer clusters, with all the shades in between. Fine-grain control mechanisms are then needed to cap power consumption at each level of the stack, still guaranteeing Service Level Agreements (SLA) to the hosted applications. In this work, we propose DockerCap, a software-level power capping orchestrator for Docker containers that follows an Observe-Decide-Act loop structure: this allows to quickly react to changes that impact on the power consumption by managing resources of each container at run-time, to ensure the desired power cap. We show how we are able to obtain results comparable with the state of the art power capping solution provided by Intel RAPL, still being able to tune the performances of the containers and even guarantee SLA constraints. Full paper: http://ieeexplore.ieee.org/document/7982228/

1. DockerCap: a software-level power capping
orchestrator for Docker containers
A. Asnaghi, M. Ferroni, M. D. Santambrogio
2016 IEEE 14th International Conference on Embedded and Ubiquitous Computing (EUC)

2. Outline 2
• Introduction on Cloud and Fog Computing requirements
• Problem definition and proposed solution
• DockerCap design
• Resource control and partitioning policies
• Experimental results
• Conclusion and future work

3. 3
Cloud
Fog
IoT
• Internet of Things (IoT) is experiencing a huge
hype these days
• IoT devices produce a massive amount of data
that need to be processed and stored
• This needs lead to the adoption of Cloud
Computing, but it may be not enough for
latency-sensitive and security-critical
applications
• Fog Computing takes the computation “at the
edge of the Cloud” by exploiting fog nodes
Introduction

4. 4
➡ Power management techniques to control
power consumption
➡ Group applications inside
software containers
• Applications needs to be PORTABLE
between the Cloud and the Fog
• Nodes may be POWER CONSTRAINED
Cloud
Fog
Requirements
• Proposed approach:
➡ Resource management to tune applications’ performances with
respect to power consumption requirements

5. Heterogeneity
• Different hardware in both Cloud and Fog nodes
• Different applications patterns and requirements
• Colocation of many applications on the same node
5
Performance Power
Limit the
power consumption
of the machine
Guarantee
performance
for each application
Tradeoff: Power vs Performance

6. • Limit power consumption of a machine to a fixed “cap”
• Power capping allows to:
• increase server density in a cluster
• change the cap based on energy cost, that may
vary during the day
• non uniform capping used to improve cluster-level
efficiency
6
A first step: power capping

7. 7
Hardware Power Capping
(i.e. Intel RAPL[1])
Software-level resource
management
Description
Exploits DVFS to control
power consumption
Manage the load of the system
to achieve the desired power
consumption
PRO
Very fast
(~350ms [1])
It is possible to control
performances of
applications
CONS
No control over
performances of
applications
Slow compared to RAPL
(double digit degradation)
Power capping solutions
[1] Efraim Rotem, Alon Naveh, Avinash Ananthakrishnan, Doron Rajwan and Eliezer Weissmann. Power-management
architecture of the intel microarchitecture code-named sandy bridge. IEEE micro, (2):20–27, 2012
PROPOSED APPROACH

8. 8
Proposed solution
• A power-aware orchestrator for Docker containers
• Manage resources to meet the power
consumption goal
• A policy-based system
• Guarantee performances of the containers
while staying under the power cap

9. 9
Background - Docker containers
• Group the application and all its dependencies
in a single entity
• The host operating system sees a Docker
container as a group of processes
• Lightweight footprint and minimal overhead
• Version control and component reuse
• It exploits some kernel features to provide its
functionalities
(e.g. cgroups, namespaces, unified file system)

10. 10
System design
Observe
Queue Act
Queue
Act Component
CGroup
Observe Component
Docker
Containers
RAPL
Decide Component
Policy1 Policy2 Policy3

11. 11
Observe phase
Power samples from
Intel RAPL
Resource allocation of the
containers from Docker and
cgroups
Observe
Queue Act
Queue
Act Component
CGroup
Observe Component
Docker
Containers
RAPL
Decide Component
Policy1 Policy2 Policy3

12. 12
Decide phase
Resource Partitioning
Observe
Queue Act
Queue
Act Component
CGroup
Observe Component
Docker
Containers
RAPL
Decide Component
Policy1 Policy2 Policy3
Resource Control

13. 13
Act phase
Observe
Queue Act
Queue
Act Component
CGroup
Observe Component
Docker
Containers
RAPL
Decide Component
Policy1 Policy2 Policy3
Actuation through the
cgroup hierarchy for
each container

14. 14
System design
Observe
Queue Act
Queue
Act Component
CGroup
Observe Component
Docker
Containers
RAPL
Decide Component
Policy1 Policy2 Policy3

15. 15
Decide phase
Resource Partitioning
Observe
Queue Act
Queue
Act Component
CGroup
Observe Component
Docker
Containers
RAPL
Decide Component
Policy1 Policy2 Policy3
Resource Control

16. 16
{
Control theory

17. 17
Resource control
100%
CPU quota cap
available resource
With the feedback control loop logic, we find the
allocation of resources that ensures the power cap

18. 18
Resource partitioning
Containers: C1 C2 C3 C4
?
We explore three different partitioning policies:
• Fair resource partitioning
• Priority-aware resource partitioning
• Throughput-aware resource partitioning
100%
CPU quota cap
available resource

19. • The quota Q is evenly partitioned across all the containers
• No control over the throughput of a single container
19
1. Fair resource partitioning
100%
CPU quota cap
Containers: C1 C2 C3 C4
Q/4 Q/4 Q/4 Q/4

20. 20
2. Priority-aware partitioning
100%
CPU quota cap
Containers:
• The quota Q is partitioned following the priority of each container
• The quota of the single container is estimated through a weighted mean,
where every priority has its own associated weight
High priority:
Low priority:
C1
HIGH LOW
C2 C3 C4
LOW LOW

21. 21
Throughput-aware resource partitioning
C3 C4Best effort:
+ SLO1
+ SLO2
SLO1 SLO2
100%
CPU quota cap
Containers:
High priority:
Low priority:
C1
C2
BE BE
• The quota Q is partitioned following the priority of each container and its
Service Level Objectives (SLO)
• SLO is here defined as the Time-To-Completion (TTC) of the task

22. 22
Experimental setup
All the benchmark containers run simultaneously on the same node
HW OS
CONTAINER
ENGINE
RUNTIME
Intel Xeon
E5-1410
32GB RAM
Ubuntu 14.04
Linux 3.19.0-42
Docker 1.11.2 Python 2.7.6
BENCHMARK CONTAINERS
PARSEC DESCRIPTION
fluidanimate fluid dynamics simulation generic CPU-bound
x264 video streaming encoding e.g., video surveilance
dedup compression cloud-fog communication

23. 23
Goals of the experiments
The comparison is done with the state of the art power capping solution RAPL by Intel[1]
PERFORMANCES OF THE
CONTAINERS
PRECISION OF THE POWER
CAPPING
allocate resource to meet
containers’ requirements
manage machine
power consumption

24. 24
Precision of the power capping
• Comparable results in terms
of average power
consumption under the
power cap
• As expected, RAPL provides
a more stable power capping
•Fair
•Priority-aware
•Throughput-aware
•RAPL

25. 25
Performances: Fair Partitioning vs RAPL
• Comparison between the
performance-agnostic approaches
• Performance metric:
Time To Completion
(lower is better)
Power cap: 30W
Power cap: 20W
Power cap: 40W
•dedup
•fluidanimate
•x264

26. Power cap: 30W
Power cap: 20W
Power cap: 40W
26
Performances: all policies
•dedup
•fluidanimate
•x264
• Comparison with the
performance-aware
approaches
• fluidanimate is set to
High Priority with a SLO
of 400s
• Performance metric:
Time To Completion
(lower is better)

27. Power cap: 30W
Power cap: 20W
Power cap: 40W
26
Performances: all policies
•dedup
•fluidanimate
•x264
• Comparison with the
performance-aware
approaches
• fluidanimate is set to
High Priority with a SLO
of 400s
• Performance metric:
Time To Completion
(lower is better)

28. Power cap: 30W
Power cap: 20W
Power cap: 40W
26
Performances: all policies
•dedup
•fluidanimate
•x264
• Comparison with the
performance-aware
approaches
• fluidanimate is set to
High Priority with a SLO
of 400s
• Performance metric:
Time To Completion
(lower is better)

29. 27
Conclusion and future work
✓We presented DockerCap, a power-aware orchestrator
that manages containers’ resources
✓We showed how DockerCap is able to limit the power
consumption of the machine
✓We discussed three distinct partitioning policies and
compared their impact on containers’ SLO
FUTURE DIRECTIONS
• Exploit both HW and SW power capping
• Improve the precision of the power capping with
more refined modeling techniques [2]
• Compute the right allocation of resources online by
observing the performance of the containers
[2] Andrea Corna and Andrea Damiani. A scalable framework for resource consumption modelling: the MARC approach.
Master’s thesis. Politecnico di Milano, 2016.

30. Any questions? 28

31. 29
Resource-performance model
• We need to model the behaviour of the performance (Time-To-Completion)
with respect to the resources given (CPU Quota)

32. Static VS Dynamic resource management
• Static resource management:
• find an optimal allocation of resources for each tenant
• Dynamic resource management:
• manage at runtime the resources to satisfy your constraints
• In a multi-tenant context, static resource management could not
be a good choice:
• SLA may vary during time
• We may deploy at a different time other containers, thus
reconsidering the previous allocations
30

33. Backup - cgroups 31
Students, Professors are
cgroups, part of different
hierarchies (cpu, memory,
disk..)
A resource controller is
associated with a
hierarchy and handles a
specific task on a specific
resource
Control Groups [3] provide a mechanism for aggregating/partitioning sets of
tasks, and all their future children, into hierarchical groups with specialized
behaviour.
[3] https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt