Contributions to Large Scale Distributed Systems The - - PowerPoint PPT Presentation
Contributions to Large Scale Distributed Systems The infrastructure view point Adrien Lebre September 1, 2017 President and Examiner: Reviewers: Claude Jard, Nantes Univ. Erik Elmroth, Ume Univ. Frdric Desprez, Inria Manish
Adrien Lebre September 1, 2017 President and Examiner: Claude Jard, Nantes Univ. Frédéric Desprez, Inria Reviewers: Erik Elmroth, Umeå Univ. Manish Parashar, Rutgers Univ Pierre Sens, UPMC
John Mc Carthy, Speaking at the MIT centennial in 1961 If computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system is a public utility...
ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt micro processor 1971
micro processor 1971 ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure
micro processor 1971 ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure
MSc/PhD - 2001/2006 Cluster (Storage/HPC)
micro processor 1971 ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure
MSc/PhD - 2001/2006 Cluster (Storage/HPC) PostDoctoral fellow - 2006/2008 (Storage/Grid)
micro processor 1971 ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure
MSc/PhD - 2001/2006 Cluster (Storage/HPC) PostDoctoral fellow - 2006/2008 (Storage/Grid)
Inria Researcher (2013-2017) Clouds and Beyond
micro processor 1971 ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure
MSc/PhD - 2001/2006 Cluster (Storage/HPC) PostDoctoral fellow - 2006/2008 (Storage/Grid)
Inria Researcher (2013-2017) Clouds and Beyond
VM PLACEMENT RESOURCE MGMT SYSTEMS
micro processor 1971 ENIAC 1946 Transistor 1947
Computation Communication
1999 - Salesforces SaaS Concept 1838 - Telegraph 1876 - Telephone 1896 - Radio 1957 - satellite 1969 - ARPANET 1973 - Ethernet 1985 - TCP/IP Adoption 1975 -Personal Computers SmartPhones 2007 1950/1990 - Mainframes 1950 - Batchmode 1960 - Interactive 1970 - Terminals (clients/server concepts) 1967 - First virtualisation attempt 2002- Amazon Initial Compute/Storage services 2006 - Amazon EC2 (IaaS) 2010 - Cloud democratisation 2015 Network/Computers Convergence Software Defined XXX 1999 - The Grid 1995 - Commodity clusters 2002 - Virtualised Infrastructure
MSc/PhD - 2001/2006 Cluster (Storage/HPC) PostDoctoral fellow - 2006/2008 (Storage/Grid)
Inria Researcher (2013-2017) Clouds and Beyond
VM PLACEMENT RESOURCE MGMT SYSTEMS
IN VIVO EXPERIMENTS
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Compute nodes
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Compute nodes
Storage nodes
(Distributed File System)
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Compute nodes
Storage nodes
(Distributed File System)
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Alice
Compute nodes
Storage nodes
(Distributed File System)
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Alice
Compute nodes
Storage nodes
(Distributed File System)
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Alice
Compute nodes
Storage nodes
(Distributed File System)
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Alice Alice Alice Alice Alice Alice
Alice
Compute nodes
Storage nodes
(Distributed File System)
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Alice Alice Alice Alice Alice Alice
Alice
Compute nodes
Storage nodes
(Distributed File System)
Bob
(both hardware and software) in a flexible, transparent, efficient, secured and reliable way
placements, isolation between applications, performance…)
5
Frontend
(Resource Management System)
Alice Alice Alice Alice Alice Alice
Alice
Compute nodes
Storage nodes
(Distributed File System)
Bob
Bob Bob Bob
? ? ?
10/2010 10/2008 10/2009 10/2013 10/2011 10/2012 10/2016 10/2014 10/2015
Cluster-Wide context switch J.M. Menaud
PhD - F. Quesnel Co supervised with M. Südholt Distributed VM Scheduler PhD - J. Pastor Co supervised with F. Desprez Locality Aware Placement
10/2017
IMT Atlantique Research activities mainly supported by Inria
10/2010 10/2008 10/2009 10/2013 10/2011 10/2012 10/2016 10/2014 10/2015
Cluster-Wide context switch J.M. Menaud
PhD - F. Quesnel Co supervised with M. Südholt Distributed VM Scheduler PhD - J. Pastor Co supervised with F. Desprez Locality Aware Placement
10/2017
IMT Atlantique Research activities mainly supported by Inria
and have to be scheduled
Although Jobs 2 and 3 have been backed filled, some resources are unused (dark gray areas)
Job 4 can be started earlier without impacting Job 1’s performance.
7
the queue
Processors Time
job Running in the queue 2nd
1st job in the queue
3rd job in the queue 4th job in 2nd 3rd job in the queue
Processors Time
4th job in Running the queue 1st job in the queue job in the queue the queue Running 2nd job in the 1st queue job in the queue
Processors Time
3rd job in the queue 4th job in
Jobs cannot be easily preempted (OS’s internal states) Even with preemption, some resources are still not wasted
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
VM 3
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor Hypervisor
VM 1 VM 2
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor Hypervisor
VM 1 VM 2 VM 3
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor Hypervisor
VM 1 VM 2 VM 3
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
physical machine thanks to a hypervisor (an operating system of OSes)
8
Hypervisor
VM 1 VM 2 VM 3
Hypervisor Virtual Machines (VMs) Physical Machine (PM)
several VMs
9
terminated running sleeping run stop resume suspend waiting ready migrate
several VMs
9
terminated running sleeping run stop resume suspend waiting ready migrate
several VMs
9
terminated running sleeping run stop resume suspend waiting ready migrate
several VMs
9
terminated running sleeping run stop resume suspend waiting ready migrate
credits: F. Hermenier, OSDI poster session 2008
PM 1
PM 2
Infrastructure
PM 3
cost: 3 cost: 2
Current Status Correct Status Non-viable manipulations
credits: F. Hermenier, OSDI poster session 2008
(leveraging the Entropy framework)
Cluster-Wide context switch
10
[VTDC2010]
(priority between jobs to prevent starvation)
11 Working nodes (22 CPUs) A queue of 8 vjobs (NASGrid benchmarks) Each job uses 9 VMs (9CPUs)
11
Cumulated completion times have been reduced by 40%
Hypervisor Hypervisor HypervisorPM 1
PM 2
Infrastructure
PM 3
PM 1
PM 2
Infrastructure
PM 3
(priority between jobs to prevent starvation)
11 Working nodes (22 CPUs) A queue of 8 vjobs (NASGrid benchmarks) Each job uses 9 VMs (9CPUs)
12
Cumulated completion times have been reduced by 40%
credits: A. Simonet, Introduction to Cloud Computing Lecture - Inside a Google DC
1 1 n
e s / 7 2 V M s … W h a t ’ s a b
t s c a l a b i l i t y / r e a c t i v i t y ?
PM 1
PM 2
Infrastructure
PM 3
(priority between jobs to prevent starvation)
11 Working nodes (22 CPUs) A queue of 8 vjobs (NASGrid benchmarks) Each job uses 9 VMs (9CPUs)
12
Cumulated completion times have been reduced by 40%
credits: A. Simonet, Introduction to Cloud Computing Lecture - Inside a Google DC
A Google Data Center…
1 1 n
e s / 7 2 V M s … W h a t ’ s a b
t s c a l a b i l i t y / r e a c t i v i t y ?
computing phase but… reconfiguring the infrastructure is time consuming too !
13
Timer
Time
credits: F. Quesnel, PhD defense 2013
1
2 3
computing phase but… reconfiguring the infrastructure is time consuming too !
CPU Load Time
VM 2 VM1
14
M
i t
C
p u t e R e c
fi g u r e
Is the configuration viable?
credits: F. Quesnel, PhD defense 2013
1
2 3
computing phase but… reconfiguring the infrastructure is time consuming too !
CPU Load Time
VM 2 VM1
14
M
i t
C
p u t e R e c
fi g u r e
Is the configuration viable?
credits: F. Quesnel, PhD defense 2013
1
2 3
computing phase but… reconfiguring the infrastructure is time consuming too !
CPU Load Time
VM 2 VM1
14
M
i t
C
p u t e R e c
fi g u r e
Is the configuration viable?
Can we reduce all phases?
credits: F. Quesnel, PhD defense 2013
1
2 3
hypervisors (no service node)
the system, created dynamically (nodes are reserved for an exclusive use by a scheduler, to prevent several schedulers from migrating the same VMs)
15
[CCPE2012] An Event occurs on a node Can current node scheduler calculate valid schedule? yes no Apply the schedule Contact neighbor and ask it to solve the problem
usage of resources
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
16
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
17
0! 20! 40! 60! 80! 100! 120! 140! 160! Griffon! Graphene! Paradent! Parapide! Parapluie! Sol! Suno! Pastel! Number of PMs! Cluster! 2000 VMs! 251 PMs! 3325 VMs! 309 PMs! 4754 VMs! 467 PMs! 10 20 30 40 50 Time to apply a reconfiguration (s) Mean and standard deviation 251 PMs 2000 VMs 309 PMs 3325 VMs 467 PMs 4754 VMs Entropy DVMS 5 10 15 20 Time to solve an event (s) Mean and standard deviation 251 PMs 2000 VMs 309 PMs 3325 VMs 467 PMs 4754 VMs DVMS
20 40 60 80 100 Duration of an iteration (s) Mean and standard deviation 251 PMs 2000 VMs 309 PMs 3325 VMs 467 PMs 4754 VMs Entropy DVMS
17
0! 20! 40! 60! 80! 100! 120! 140! 160! Griffon! Graphene! Paradent! Parapide! Parapluie! Sol! Suno! Pastel! Number of PMs! Cluster! 2000 VMs! 251 PMs! 3325 VMs! 309 PMs! 4754 VMs! 467 PMs! 10 20 30 40 50 Time to apply a reconfiguration (s) Mean and standard deviation 251 PMs 2000 VMs 309 PMs 3325 VMs 467 PMs 4754 VMs Entropy DVMS 5 10 15 20 Time to solve an event (s) Mean and standard deviation 251 PMs 2000 VMs 309 PMs 3325 VMs 467 PMs 4754 VMs DVMS
20 40 60 80 100 Duration of an iteration (s) Mean and standard deviation 251 PMs 2000 VMs 309 PMs 3325 VMs 467 PMs 4754 VMs Entropy DVMS
I t l
s p r
i s i n g … H
c a n w e t e s t i t a t s c a l e ? H
c a n w e c
p a r e w i t h
h e r s a p p r
c h e s ?
Lots of articles (too many ?)
Lots of articles (too many ?) Evaluations are performed either at a low scale for in vivo experiments or with ad-hoc simulators. How can we evaluate/compare them?
10/2010 10/2008 10/2009 10/2013 10/2011 10/2012 10/2016 10/2014 10/2015
Cluster-Wide context switch Distributed VM Scheduler Locality Aware Placement French ANR SONGS Project
10/2017
VMPlaceS
PhD Boot time model IMT Atlantique Hemera Inria Large Scale Initiative Discovery Inria Project Lab Research activities mainly supported by EU BigStorage Project
Postdoc/Invited researcher SimGridVM: VM abstractions
Postdoc Energy dimension Inria
10/2010 10/2008 10/2009 10/2013 10/2011 10/2012 10/2016 10/2014 10/2015
Cluster-Wide context switch Distributed VM Scheduler Locality Aware Placement French ANR SONGS Project
10/2017
VMPlaceS
PhD Boot time model IMT Atlantique Hemera Inria Large Scale Initiative Discovery Inria Project Lab Research activities mainly supported by EU BigStorage Project
Postdoc/Invited researcher SimGridVM: VM abstractions
Postdoc Energy dimension Inria
systems
same manner as in the real world (e.g., create/destroy, start/shutdown, suspend/resume and migrate)
20
manner)
generation/injection
Focus on the migration model
Source PM Destination PM VM (Running) Memory Pages
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
Source PM Destination PM VM (Running) Memory Pages
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
Source PM Destination PM VM (Running)
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
Source PM Destination PM VM (Running)
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
Source PM Destination PM VM (Running)
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
Source PM Destination PM VM (Running)
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
Source PM Destination PM VM (Restart)
21 20 40 60 80 100 120 140 160 180 200 220 20 40 60 80 100 120 Memory Update Speed (MB/s)
Migration time (in sec)
(but, keep in mind the VM is still running at source)
sufficiently small to meet an acceptable downtime (30ms in KVM).
according to the size of the VM
the longer the migration will be
Naive approximation
22
Apache Postgres SQL
5 10 15 20 25 30 35 40 45 20 40 60 80 100 Migration Time (s) CPU Utilization (%) Grid5000 Simulation (Precopy) Simulation (Naive)
(implementing the pre-copy strategy) The time and the resulting traffic of a migration should be computed by taking into account competition arising in the presence of resource sharing and the memory refresh rate.
[CloudCom 2013]
23
[TCC 2015]
Physical Machine (Capacity C) Task1 (X1) Task2 (X2)
problems at once. Eq1: X1 + X2 < C
Physical Machine (Capacity C)
Eq1: X1 + X2 + X3 < C
Eq2: X1,1 + X1,2 < X1 Eq3: X2,1 < X2
VM1 (X1) Task11 (X1,1) Task12 (X1,2) VM2 (X2) Task21 (X2,1) Task3 (X3) Virtual Machine Physical SimGrid with Virtual Machine Support SimGrid without Virtual Machine Support Extend
simulation programs and control VMs in the same manner as in the real world
machines (PMs) and VMs through the same SimGrid API, which will provide a seamless migration path to IaaS simulations for hundreds of SimGrid users
All extensions have been integrated into SimGrid
24
Initialization Phase Injector/Scheduling Phase Analysis Phase Injector Scheduler
Input: infrastructure topology, VM Nb, Workloads Injects events (CPU variations, node crashes…) Researchers should (only) develop their scheduling algorithm in JAVA (or SCALA) using the SimGrid MSG API and a more abstract interface provided by VMPlaceS Output: a JSON trace file which is then consumed by the statistics R system to deliver tables/graphs (VMPlaces records several metrics during the simulation execution)
25
informations
décision
la décision
Période 1 2 3 duréeTi
Period
Centralized Entropy [VEE’09]
GL GMs LCs
Hierarchical Snooze [CCGRID’12] Distributed DVMS [CCPE’12]
[EuroPar2015]
VMs: 1 core, 1GB, 1Gbps, memory footprint varies between 0 and 80% VM CPU load (μ=60, σ=20) 10 VMs per PM, Cluster infrastructure composed of 128/256/512/1024 PMs Duration: 1800 seconds Period of scheduling invocations: 30 seconds.
26
1280 vms 256 nodes 2560 vms 512 nodes 5120 vms 1024 nodes 10240 vms 10000 20000 30000 40000
Time (s)
Distributed Hierarchical Without scheduling
Cumulated violation time
The centralized strategy looks useless?
500 1000 1500 2000 2500 3000 3500 5 10 15 20 25 Time (s) Duration of the violation (s) Entropy first Entropy first false positive DVMS DVMS false positive 27
Another view focusing on Entropy and DVMS
(AVG | STD) (AVG | STD) (AVG | STD) (AVG | STD)
28
(AVG | STD) (AVG | STD) (AVG | STD) (AVG | STD)
28
DVMS outperforms the others !?
(AVG | STD) (AVG | STD) (AVG | STD) (AVG | STD)
28
While the centralized approach does not scale, both phases are constant from the time viewpoint for the two other approaches DVMS outperforms the others !?
(AVG | STD) (AVG | STD) (AVG | STD) (AVG | STD)
28
While the centralized approach does not scale, both phases are constant from the time viewpoint for the two other approaches DVMS outperforms the others !?
1./ Can we find a good partitioning size for Snooze ? 2./ What would be the benefit for Snooze of a reactive approach?
(AVG | STD)
29
1280 vms 256 nodes 2560 vms 512 nodes 5120 vms 1024 nodes 10240 vms 5000 10000 15000 20000 25000
Time (s)
Hierarchical4LCs Hierarchical8LCs Hierarchical32LCs
Cumulated violation time
(AVG | STD)
29
1280 vms 256 nodes 2560 vms 512 nodes 5120 vms 1024 nodes 10240 vms 5000 10000 15000 20000 25000
Time (s)
Hierarchical4LCs Hierarchical8LCs Hierarchical32LCs
Cumulated violation time
(AVG | STD)
29
1280 vms 256 nodes 2560 vms 512 nodes 5120 vms 1024 nodes 10240 vms 5000 10000 15000 20000 25000
Time (s)
Hierarchical4LCs Hierarchical8LCs Hierarchical32LCs
Cumulated violation time
(AVG | STD)
29
1280 vms 256 nodes 2560 vms 512 nodes 5120 vms 1024 nodes 10240 vms 5000 10000 15000 20000 25000
Time (s)
Hierarchical4LCs Hierarchical8LCs Hierarchical32LCs
Cumulated violation time
The smaller is the size of the partition, the bigger the probability to do not find a viable solution
(AVG | STD)
29
1280 vms 256 nodes 2560 vms 512 nodes 5120 vms 1024 nodes 10240 vms 5000 10000 15000 20000 25000
Time (s)
Hierarchical4LCs Hierarchical8LCs Hierarchical32LCs
Cumulated violation time
The smaller is the size of the partition, the bigger the probability to do not find a viable solution Other variants and possible improvements (for instance contact neighbours two by two in DVMS)
vivo conditions, lot of metrics to monitor, scalability/reactivity, …)
Execution support for their accurate simulation at large scale Means to analyze the collected traces
VM boot time VM image migrations (storage challenge) Workloads reproducing real traces (complex to get real traces) Provide similar abstractions for container technologies (must have)
30
[TPDS submission under review]
[PDP2017]
10/2010 10/2008 10/2009 10/2013 10/2011 10/2012 10/2016 10/2014 10/2015
Cluster-Wide context switch Distributed VM Scheduler Locality Aware Placement French ANR SONGS Project
10/2017
VMPlaceS
IMT Atlantique Hemera Inria Large Scale Initiative Discovery Inria Project Lab Research activities mainly supported by EU BigStorage Project Inria SimGridVM
Discovery vision OpenStack: From SQL to noSQL backends Discovery Inria Project Lab Research Eng. R-A Cherrueau
EnOS
From mainframes to …
…larger “mainframes”
Microsoft DC, Quincy, WA state
From mainframes to …
33
2 1 2
1 3 M a j
b r a k e s f
t h e a d
t i
t h e C C m
e l
network backbones (aka PoP) with servers
telecom companies, network institutions…
34
[Discovery2013] [VHPC2011] Geant Internet 2 RENATER
network backbones (aka PoP) with servers
telecom companies, network institutions…
34
[Discovery2013] [VHPC2011] Geant Internet 2
How operating/using such a massively distributed infrastructure from the software viewpoint?
RENATER
35
Alice Bob Charles
35
Alice Bob Charles
35
Alice Bob Charles
Advanced brokers must reimplement standard IaaS mechanisms while facing the API limitation
OpenStack (20Millions of LOC, 3M just for the core-services)
distributed infrastructures
Alice Bo Charle
36
(a research PoC, just the top of the iceberg, numerous challenges)
EnOS, A tool for diving into OpenStack and performing scientific investigations
[IC2E 2017] [CCGRID 2017]
10/2010 10/2008 10/2009 10/2013 10/2011 10/2012 10/2016 10/2014 10/2015
Cluster-Wide context switch Distributed VM Scheduler Locality Aware Placement French ANR SONGS Project
10/2017
VMPlaceS
IMT Atlantique Hemera Inria Large Scale Initiative Discovery Inria Project Lab Research activities mainly supported by EU BigStorage Project Inria SimGridVM
Discovery vision OpenStack: From SQL to noSQL backends Discovery Inria Project Lab EnOS STACK Proposal
(flexibility, portability) but with a cost…
What you may have! What you may expect ! What you expect !
Alice Alice Alice Alice Alice Alice
Map/Reduce framework (leverage attached storage facilities)
38
Alice
Frontend
(flexibility, portability) but with a cost…
What you may have! What you may expect !
38
Alice
Frontend
Alice Alice Alice Alice Alice Alice
(flexibility, portability) but with a cost…
What you may have!
38
Alice
Frontend
Alice Alice Alice Alice Alice Alice
Bob Bob Bob Bob Bob BobBob
(flexibility, portability) but with a cost…
What you may have!
38
Alice
Frontend
Bob Bob Bob Bob Bob BobBob
Alice
(flexibility, portability) but with a cost…
What you may have!
38
Alice
Frontend
Bob Bob Bob Bob Bob BobBob
(flexibility, portability) but with a cost…
39
(flexibility, portability) but with a cost…
39
P r
e t
s t h a t h e l p u s t
n d e r s t a n d t h i s c
p l e x i t y
(flexibility, portability) but with a cost…
39
P r
e t
s t h a t h e l p u s t
n d e r s t a n d t h i s c
p l e x i t y
Propose models to capture this complexity in advanced alg.
(Mainframe/Cluster vs Grid vs Cloud)
but edge/fog computing infrastructure significantly differ
40
Industrial Internet / Internet of Skills
(Mainframe/Cluster vs Grid vs Cloud)
but edge/fog computing infrastructure significantly differ
40
Internet Backbone
Industrial Internet / Internet of Skills
(Mainframe/Cluster vs Grid vs Cloud)
but edge/fog computing infrastructure significantly differ
40
Internet Backbone
Industrial Internet / Internet of Skills
41
Fog/Edge - What are the challenges?
(Mainframe/Cluster vs Grid vs Cloud)
requirements of IoT and NFV Applications.
but edge/fog computing infrastructure significantly differ
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ? H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ? H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ? H
c a n d e v e l
e r s e x p r e s s t h
e c
s t r a i n t s ? H
c a n t h e s y s t e m g u a r a n t e e t h e m d u r i n g r e c
fi g u r a t i
e r a t i
s ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ? H
c a n d e v e l
e r s e x p r e s s t h
e c
s t r a i n t s ? H
c a n t h e s y s t e m g u a r a n t e e t h e m d u r i n g r e c
fi g u r a t i
e r a t i
s ? H
s h
l d t h e s y s t e m a d d r e s s b i g d a t a a p p l i c a t i
s ( c
s i d e r i n g a s i g n i fi c a n t n u m b e r
g e
i s t r i b u t e d d a t a s
r c e s ) ?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ? H
c a n d e v e l
e r s e x p r e s s t h
e c
s t r a i n t s ? H
c a n t h e s y s t e m g u a r a n t e e t h e m d u r i n g r e c
fi g u r a t i
e r a t i
s ? H
s h
l d t h e s y s t e m a d d r e s s b i g d a t a a p p l i c a t i
s ( c
s i d e r i n g a s i g n i fi c a n t n u m b e r
g e
i s t r i b u t e d d a t a s
r c e s ) ? what’s about security aspects?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ? H
c a n d e v e l
e r s e x p r e s s t h
e c
s t r a i n t s ? H
c a n t h e s y s t e m g u a r a n t e e t h e m d u r i n g r e c
fi g u r a t i
e r a t i
s ? H
s h
l d t h e s y s t e m a d d r e s s b i g d a t a a p p l i c a t i
s ( c
s i d e r i n g a s i g n i fi c a n t n u m b e r
g e
i s t r i b u t e d d a t a s
r c e s ) ? what’s about security aspects? Energy footprint of such infrastructures?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ? H
c a n d e v e l
e r s e x p r e s s t h
e c
s t r a i n t s ? H
c a n t h e s y s t e m g u a r a n t e e t h e m d u r i n g r e c
fi g u r a t i
e r a t i
s ? H
s h
l d t h e s y s t e m a d d r e s s b i g d a t a a p p l i c a t i
s ( c
s i d e r i n g a s i g n i fi c a n t n u m b e r
g e
i s t r i b u t e d d a t a s
r c e s ) ? what’s about security aspects? Can μDCs benefit from renewable energy sources? Energy footprint of such infrastructures?
W h e r e s h
l d I d e p l
m i c r
C s ? O n e a c h P
? W h a t ’ s a b
t c
t r
s e r v i c e s ? a t w h a t s c a l e ? W h a t ’ s a b
t t h e p e r f
m a n c e / r e l i a b i l i t y c r i t e r i a ?
P l a c e m e n t a l g
i t h m s h a v e b e e n d e s i g n e d w i t h s t r
g a s s u m p t i
s ( i n fi n i t y
r e s
r c e s , d a t a l
a l i t y ) . H e r e r e s
r c e s a r e b
n d e d , a p p l i c a t i
s h a v e m
e c
s t r a i n t s t
e a l w i t h …
H
c
t r
s e r v i c e s s h
l d b e d e s i g n e d ? C e n t r a l i s e d / H i e r a r c h i c a l / P 2 P b a s e d ? G l
a l v s p a r t i a l v i e w s
t h e s y s t e m ? H
c a n d e v e l
e r s e x p r e s s t h
e c
s t r a i n t s ? H
c a n t h e s y s t e m g u a r a n t e e t h e m d u r i n g r e c
fi g u r a t i
e r a t i
s ? H
s h
l d t h e s y s t e m a d d r e s s b i g d a t a a p p l i c a t i
s ( c
s i d e r i n g a s i g n i fi c a n t n u m b e r
g e
i s t r i b u t e d d a t a s
r c e s ) ? what’s about security aspects? Can μDCs benefit from renewable energy sources? Energy footprint of such infrastructures?
STACK, a new research team to address Fog/Edge Infrastructures’ challenges
It does not matter how slowly you go as long as you do not stop. — Confucius
academic proposals
just because they operate them.
part to the evolution of major software stacks such as OpenStack like it has been
45
academic proposals
just because they operate them.
part to the evolution of major software stacks such as OpenStack like it has been
45 “Just good enough to publish a good paper” Francesco Lo Presti, Ass. Prof. University Di Roma, Italy ‘’…Optimality is not needed, it should just run…’’ Johan Ecker, Principal Researcher, Cloud Technology, Ericsson Research, Sweden CloudControl WS June 2017
47
32PMs, 4 cores/16GB/1Gbps per PM 192 VMs (6 per node) 1 core,1GB, 1Gbps Memory footprint (between 0 and 80% of 1Gbps) Average CPU load 60% The scheduling algorithm has been invoked every 60 seconds over a 3600 seconds execution A dedicated tool to inject the load in each VM running on top of G5K according to the events consumed by the injector
1 2 3
1000 2000 3000 4000 20 40 60
Computation Reconfiguration
Grid’5000
1000 2000 3000 4000 20 40 60
Computation Reconfiguration
VMPlaceS
47
32PMs, 4 cores/16GB/1Gbps per PM 192 VMs (6 per node) 1 core,1GB, 1Gbps Memory footprint (between 0 and 80% of 1Gbps) Average CPU load 60% The scheduling algorithm has been invoked every 60 seconds over a 3600 seconds execution A dedicated tool to inject the load in each VM running on top of G5K according to the events consumed by the injector
1 2 3
1000 2000 3000 4000 20 40 60
Computation Reconfiguration
Grid’5000
1000 2000 3000 4000 20 40 60
Computation Reconfiguration
VMPlaceS Difference between 6% and 18% (med: 12%) Worst case when multiple migrations are performed simultaneously to the same node
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
48
9 4 2 7 1 3 5 8 6
Partition
credits: J. Pastor, PhD Defense 2016
49
Partition
credits: J. Pastor, PhD Defense 2016
9 4 2 7 1 3 5 8 6
From SQL to NoSQL backend in OpenStack
51
51
/39
52
Non-Relational
ROME
Key/Value DB
Relational
SQLAlchemy
Nova Network Nova Compute Nova Scheduler Nova Conductor
db.api
MySQL DB
Nova (compute service) - software architecture
/39
Jonathan Pastor’s Phd
https://github.com/BeyondTheClouds/rome
interface as SQLAlchemy
to a KVS without being too intrusive
(dedicated) nodes
Key/value store cluster
53
AMQP bus AMQP bus AMQP bus
Key/Value Store
Nova Controller 3
n-sched n-cond n-api n-net n-cpu horizonNova Controller 2
n-sched n-cond n-api n-net n-cpu horizonNova Compute Nodes Nova Compute Nodes Nova Controller 1
n-sched n-cond n-api n-net n-cpu horizonNova Controller 5 n-sched
n-cond n-api n-net n-cpu horizonNova Controller 4 and compute node
n-sched n-cond n-api n-net n-cpu horizonNova Compute Node Site 1 Site 2 Site 3 Site 4
/39
⟹ Evaluate the overhead of using ROME/Redis and the network impact.
⟹ Determine the impact of latency. ⟹ Validate compatibility with higher level mechanisms validation
54
www.grid5000.fr 1500 servers, spread across 10 sites Full admin rights
/39
55
MySQL/SQLAlchemy ROME/Redis
(one dedicated node for the DB server/the REDIS server)
56
ROME requests are faster for 80% of requests SQLAlchemy is faster for 20% of requests
57
58
ROME+Redis SQLAlchemy+MySQL
(and 1 dedicated node in the case of REDIS).
more than 4 sites, results are not satisfactory enough to be discussed (RR available on demand)
59
(one SQL server for the whole infrastructure)
SQL scalability bottleneck
60
host-aggregates / availability zones
most of the existing features.
(without availability zones the distribution was respectively 26%, 20%, 22%, 32% of the created VMs for a 4 clusters experiments).
Geographical Site1 Geographical Site2 Geographical Site3 IaaS IaaS IaaS Iaas IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaSAvailability Zone 1 Availability Zone 2 Availability Zone 3
60
host-aggregates / availability zones
most of the existing features.
(without availability zones the distribution was respectively 26%, 20%, 22%, 32% of the created VMs for a 4 clusters experiments).
Geographical Site1 Geographical Site2 Geographical Site3 IaaS IaaS IaaS Iaas IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaS IaaSAvailability Zone 1 Availability Zone 2 Availability Zone 3
Interesting but …just the top of the Iceberg ! Glance, Neutron, Cinder…? Scalability of the AMQP bus? HA? Reify locality aspects at every level of the stack?
ASCOLA Follow-up
62
ICT infrastructures.
and by addressing cross cutting dimensions such as energy or security, to operate massively geo-distributed infrastructures
62
Compute
Storage
Networking
ICT infrastructures.
and by addressing cross cutting dimensions such as energy or security, to operate massively geo-distributed infrastructures
62
Compute
Storage
Networking
Building blocks
ICT infrastructures.
and by addressing cross cutting dimensions such as energy or security, to operate massively geo-distributed infrastructures
62
Compute
Storage
Networking Application management Programming Model/API, deployment and reconfiguration Engines (self*) Resource Management Capacity Planning / Deployment and reconfiguration
Building blocks
ICT infrastructures.
and by addressing cross cutting dimensions such as energy or security, to operate massively geo-distributed infrastructures
62
security / energy Compute
Storage
Networking Application management Programming Model/API, deployment and reconfiguration Engines (self*) Resource Management Capacity Planning / Deployment and reconfiguration
Building blocks
ICT infrastructures.
and by addressing cross cutting dimensions such as energy or security, to operate massively geo-distributed infrastructures
62
security / energy Compute
Storage
Networking Application management Programming Model/API, deployment and reconfiguration Engines (self*) Resource Management Capacity Planning / Deployment and reconfiguration
Building blocks
General: Revising such a stack to deal with geo-distributed constraints/opportunities
OpenStack 3Millions LoC (core components) 20Millions overall
ICT infrastructures.
and by addressing cross cutting dimensions such as energy or security, to operate massively geo-distributed infrastructures
security / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building block security / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blockBuilding blocks
security / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blockBuilding blocks
Resource management
security / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blockBuilding blocks
Resource management
Application management
security / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blockBuilding blocks
Scalability
Efficiency / Security / Reliability
Resource management
Application management
security / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blocksecurity / energy
Compute Storage NetworkingApp Mgmt - Programming Model/API, deployment and reconfiguration Engines (self*) Resource Mgmt - Capacity Planning / Deployment and reconfiguration
Building blockBuilding blocks
Scalability
Efficiency / Security / Reliability
Resource management
‘’Just’’ a distributed resource management system?
Application management
Synergy
Transfer the green micro/nano DCs concept to the network PoP Take the advantage of the geographical distribution
A promising way to deliver highly efficient and sustainable UC services is to provide UC platforms as close as possible to the end-users and to...
64
Deploy UC servers in medium and large institutions and use them as sources of heat inside public buildings such as hospitals or universities
http://parasol.cs.rutgers.edu https://www.qarnot.com
C P E R S e D u C e A N R G R E C O
65
Identify and revise core mechanisms/algorithms to enable scalability, distribution… while taking account fog/edge specifics.
Extend API and software programming abstractions (high level) and identify missing mechanisms (low-level) to benefit from geo- distribution opportunities.
Tightly coupled : synergy between all mechanisms composing the system.
Distributed systems Software programming (Component-based model, DSL, composition) Self-* mechanisms Performance evaluations (experiment driven research)
66
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
S t
a g e / B i g D a t a
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
S t
a g e / B i g D a t a L a r g e
c a l e p l a t f
m s m a n a g e m e n t
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
S t
a g e / B i g D a t a L a r g e
c a l e p l a t f
m s m a n a g e m e n t A p p l i c a t i
l i f e
y c l e m a n a g e m e n t
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
S t
a g e / B i g D a t a L a r g e
c a l e p l a t f
m s m a n a g e m e n t A p p l i c a t i
l i f e
y c l e m a n a g e m e n t E n e r g y
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
S t
a g e / B i g D a t a L a r g e
c a l e p l a t f
m s m a n a g e m e n t A p p l i c a t i
l i f e
y c l e m a n a g e m e n t E n e r g y S
t w a r e p r
r a m m i n g m
e l s
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
66
D e p l
m e n t / R e c
fi g u r a t i
S t
a g e / B i g D a t a L a r g e
c a l e p l a t f
m s m a n a g e m e n t A p p l i c a t i
l i f e
y c l e m a n a g e m e n t E n e r g y S
t w a r e p r
r a m m i n g m
e l s S e c u r i t y
the management and advanced usages of Utility Computing infrastructures (i.e., Cloud, Fog, Edge, and beyond). The team is interested by delivering appropriate system abstractions, from low (system) to high-levels (applications), and by addressing cross cutting dimensions such as energy or security, to
infrastructures (ASAP, AVALON, DATAMOVE, KERDATA…)
Discovery, SCALUS/BigStorage EU MCITN, EPOC CominLabs, ANR MyCloud, I/O Lab…)
Historical links with TASC/AtlanModels CRE Orange Entreprise du future (Helene Coullon) Complementarities/Collaborations opportunities with GDD, STR, RESTO/RIO (co-supervision of a Phd on Fog/Edge storage backends)
67
68
Entropy (Energy) [VEE09] DVMS (Scalability) [FGCS12] VMPlaceS (SimGrid) [TCC15, Europar16]
Autonomic models for Cloud Computing applications [IGI12, Closer17] DSLs (Quality of Service, Elasticity) [FGCS16, SAC17] Proportional Energy (use of renewable energy) [Computing17]
Compose security/privacy mechanisms [CloudCom13, RATSP15]
FSN HOSANNA (2015-2017) Inria Project Lab DISCOVERY (2015-2019)
69
EU EU
Ongoing
IPL Discovery (2015-2019) EU BigStorage (2015-2018) CPER SeDuCE (2016-2020) CominLabs PrivGen (2016-2019) ANR GRECO (2017-2020) FSN/PIA Hydda HPC/Cloud between distinct sites (2017-2020).
Proposal SILECS (TGIR/ESFRI, national/EU consortium)
GDR RSD: co-chair of the Virtualisation action (CloudDays,ResCom17)
IEEE ICFEC conference Chairs of Fog/Edge related tracks in EuroPar’16, CloudCom’16/’17 Chair of the Massively Distributed WG - OpenStack.
70