bonfire tridentcom presentation
DESCRIPTION
The BonFIRE architecture was presented at the TridentCom Conference. These are the slides for the paper, which describes the key components and principles of the architecture and also some specific features offered to experimenter that are not available elsewhere.TRANSCRIPT
Building service testbeds on FIRE
BonFIRE: A Multi-cloud Test Facility for Internet of Services Experimentation
Ally Hume, EPCC, University of Edinburgh
Tridentcom 2012
BonFIRE2 Tridentcom 2012 2
The BonFIRE project is designing, building and operating a multi-cloud facility to support research across
applications, services and systems targeting services research community on Future Internet.
BonFIRE Project
BonFIRE3 Tridentcom 2012 3
Three Scenarios
1. Multi-site clouds connected through normal internet
2. Cloud scenario with emulated network
3. Extended Cloud scenario with controlled network (implies federation with network facility)
BonFIRE4 Tridentcom 2012 4
Permanent (>450cores / 45TB) & On-Request (+3000 cores) infrastructures
Note: network links not representative
BonFIRE scenarios and sites
EPCC (Edinburgh)
HP (Bristol)
PSNC (Poznan)
IBBT (Ghent)
HLRS (Stuttgart)
INRIA (Rennes)
Scenario 2
Emulab (Virtual Wall)
Scenario 3
GEANT AutoBAHN and SFA, Federica
Scenario 1
(normal internet)
BonFIRE5 Tridentcom 2012 5
Example experiment categories
1. Service applications experiments (non-cloud)– Including distributed peer to peer applications
2. Cloud (or multi-cloud) applications– e.g. cloud busting scenarios with private and public clouds.
3. Cloud infrastructure experiments– e.g. schedulers on top of BonFIRE, new live-migration strategies,
contention minimisation
4. Application-and-network experiments– Experimenters configuring network to support applications
– Bandwidth on demand
– Application specific routing
BonFIRE6 Tridentcom 2012 6
Four pillars of BonFIRE
BonFIRE7 Tridentcom 2012 7
Observability
• To understand the behaviour of the system you need to see inside the abstractions normally provided by clouds.
BonFIRE8 Tridentcom 2012 8
Application, VM and Physical machine metrics
Physical Machine
VirtualMachine
VirtualMachine
VirtualMachine
BonFIRE9 Tridentcom 2012 9
Infrastructure metrics
BonFIRE10 Tridentcom 2012 10
Observing inside the cloud
bonfire.epcc.ed.ac.uk
OpenNebula v 2.0.1
Xen Hypervisor v 3.0.33.6 TB
vmhost1
vmhost2
128 GB RAM, 48 2.3 MHz cores
128 GB RAM, 48 2.3 MHz cores
vmhost1 metrics
vmhost2 metrics
OpenNebulaevent logs
BonFIRE11 Tridentcom 2012 11
Experiments supported
• Passive use of infrastructure metrics– Understanding of contention and its impact on:
• Application performance
• General VM performance
• Active use of infrastructure metrics:– by a cloud scheduler to co-locate VMs to minimise contention
• e.g. by collecting statistics of the previous usage patterns of an image
– by a cloud application to react to the contention currently in the system
BonFIRE12 Tridentcom 2012 12
Control
• Observing is good but control is even better.
BonFIRE13 Tridentcom 2012 13
Exclusive physical machines and controlled placement
INRIA
node1 node2 node3
node7node6
node8 node9
OpenNebula
ResourceManager
ReservationSystem
Give me3 physical machines
from 26/4/12 10:00 to
28/4/12 20:00
Cluster: 34563P23P40p92
Location: inriaCluster: 34563
p23 p40
p92
Cluster: 34563
Location: inriaCluster: 34563
Host: p40
node5
BonFIRE14 Tridentcom 2012 14
Supported Experiments
• Exclusive use of physical machine and controlled placement
– Supports elimination of unwanted contention– Increases experiment repeatability– Supports the implementation of controlled contention
• possible via common contention templates
Physical Machine
VM undertest
Contentiongenerator
Contentiongenerator
ContentionTemplate 1
ContentionTemplate 2
ContentionTemplate 1
BonFIRE15 Tridentcom 2012 15
BonFIREResourceManager
MyExclusiveCluster
PM1 PM2 PM3ApplicationScheduler
(External to BonFIRE)
Supported Experiments
• Exclusive use of physical machine and controlled placement
– Experiments using external schedulers
Instance type: liteLocation: inria
Cluster: MyExclusiveCluster
Host: PM2
Instance type: lite
BonFIRE16 Tridentcom 2012 16
Controlled (EMULAB) networks with Virtual Wall
Network DBandwidth: 1Gbps
Latency: 100msLoss rate: 20%
Traffic: 200 Mbps
Network DBandwidth: 1Gbps
Latency: 100msLoss rate: 20%
Traffic: 200 Mbps
SoftwareRouter
SoftwareRouter
SoftwareRouter
SoftwareRouterClientClient
SoftwareRouter
SoftwareRouter
Network ABandwidth: 1 Gpbs
Latency: 0Loss rate: 0
Traffic: 250Mbps
Network ABandwidth: 1 Gpbs
Latency: 0Loss rate: 0
Traffic: 250Mbps
Server 2Server 2
Server 1Server 1Network B
Bandwidth: 1 GbpsLatency: 0
Loss rate: 0Traffic: 100Mbps
Network BBandwidth: 1 Gbps
Latency: 0Loss rate: 0
Traffic: 100MbpsNetwork CBandwidth: 100 Mbps
Latency: 10msLoss rate: 1%
Traffic: 10 Mbps
Network CBandwidth: 100 Mbps
Latency: 10msLoss rate: 1%
Traffic: 10 Mbps
last mile client
connectionThe internet
high bandwidth
server connection
BonFIRE17 Tridentcom 2012 17
Private Cloud
PublicCloud
Hybrid Cloud
Supported Experiments
• Controlled network quality of service– Testing streaming applications– Testing Internet of Services distributed applications– Multi-cloud applications
• Experiments into how bandwidth on demand services could be used by cloud applications
BonFIRE18 Tridentcom 2012 18
FEDERICA offering
• FEDERICA is an e-Infrastructure based on virtualization of compute and network resources
• BonFIRE experimenters will be able to request slices of network resources and are able to:– Select network topology
– Decide IP Configuration
– Configure static routes and dynamic routing protocols (OSPF, BGP)
FEDERICA Router
FEDERICA Router
FEDERICA Server
FEDERICA Server
FEDERICA Router
FEDERICA Server
Controlled Network
BonFIRE cloud site BonFIRE cloud site
BonFIRE19 Tridentcom 2012 19
FEDERICA interconnection
• We will have:– A pair of BonFIRE sites connected to
FEDERICA PoPs
– Access to resources from four FEDERICA PoPs.
• BonFIRE implementing SFA adaptor to request FEDERICA slices. – NOVI is developing an SFA interface
on top of FEDERICA Web Services.
– GÉANT3 will deploy the NOVI SFA interface.
– We are using NOVI to test the SFA adaptor.
BonFIRE20 Tridentcom 2012 20
Integration with AutoBAHN
• Integrate BonFIRE with the GÉANT Bandwidth-on-Demand interfaces (AutoBAHN)
• This will allows network-aware experiments with requirements for guaranteed bandwidth
• Control• Future service
EPCC BonFIRE Site
PSNCBonFIRE Site
• Why AutoBAHN?– Reference BoD system for European NRENs and GÉANT– Most mature solution in terms of specification, implementation and
deployment in the multi-domain environment interconnecting some of the sites
– Handles both on demand and advance requests
BonFIRE21 Tridentcom 2012 21
Advanced features
BonFIRE22 Tridentcom 2012 22
Advanced features
• Vertical elasticity– Scale up or down a virtual machine
– For some applications scale up may be better than scale out
• video transcoding
• Bandwidth on demand services– As well as control tool BoD services can also be used by network-
aware applications
• Application and network– e.g. OpenFlow for application specific routing
BonFIRE23 Tridentcom 2012 23
Architecture
XInterface or API accessible by end users, user-agents or the layer above
XBonFIRE internal interface or API accessible only by the layer above
BonFIRE internal API accessible from multiple layers of the architecture or user agents running on BONFIRE VMs
VM BonFIRE virtual machine
Key
Layer of the BonFIRE architecture
Component of BonFIREarchitecture used by multiple layers
X
SSHGateway
Monitoring
VM(MonitoringAggregator)
VM
Testbed
SSHGateway
API
SSH
VM
OCCI Scheduling
Enactor
OCCI Scheduling
ResourceManager
Experiment Manager
MessageQueue
PortalGUI
IdentityServer
(Used by Portal, Experiment
Manager, Resource Manager and
Testbeds)
OCCI
LDAP
Read/Write
MonitoringGUI
MonitoringAPI
Accounting
Accounting
AccountingScheduling
Reservation
Reservation
Monitoring dashboard
Reservation
BonFIRE24 Tridentcom 2012 24
SFA Adaptor implementation
• OCCI: one request per each resource.
• Rspec: one single request per experiment (including all resources).
• Extensions:– Add an Enactor DB to batch
the OCCI requests belonging to one experiment.
– Add a SFAAdaptorEndPoint to convert and map the OCCI requests to a RSpec request.
– SFA dialog with the Aggregate Manager (AM).
BonFIRE25 Tridentcom 2012 25
Summary
• Multi-cloud test facility for services community
• Focus on:– Observability
– Control
– Advanced Features
– Usability
• Supports a wide range of experimenters
• Not targeting network experimenters but network is key part of experiments
• Uses a broker architecture for federation
• Being used by open call experiments
• Open for general use by around October 2012
BonFIRE26 Tridentcom 2012 26
Acknowledgements
Copyright © 2012, EPCC, The University of Edinburgh, on behalf of the BonFIRE Consortium.
Licensed under Creative Commons “Attribution-NoDerivs”
BonFIRE is funded by the European Union Seventh
Framework Programme (FP7/2007-2013) under grant agreement number 257386.
www.bonfire-project.eu