Transcript The Virtual Resource Market

The Virtual Resource Market –
SLAs as derivatives contracts for
the data centre
Date: 8 May 2007
Produced by: Chris Swan
The materials may not be used or relied upon in any way.
0
Agenda
A financial metaphor for the data centre
Where virtualisation fits into the picture
The virtual resource market
SLAs – the cornerstone to success
Integrating SLAs into the software development lifecycle
Questions
1
OGF technical reference model – axes only
Business process /
service
Virtualized Platform
Platform Instance
Virtualized Operating
Environment
Operating
Environment
Virtualized Physical
Physical
Storage
Compute
Network
2
OGF reference model – top and bottom layers only
Service
Reference data
Risk Management
Customer Portal
Assets
Storage
Compute
IO
3
OGF reference model - A financial metaphor
Derivative
Assets
Listed
OTC
Exotic
Cash
Bonds
Equities
4
A layered view (from OGF technical reference model)
Reference Data
Risk Management
Customer Portal
Virtualized Platform
Data Grid
Compute Grid
Server Farm
Platform Instance
Database
App Server
Web Server
NFS, SMB, NAS
Virtual Machine
Load balancing, VIPs
Business process /
service
Virtualized Operating
Monitors
Environment
Operating
Environment
Virtualized Physical
Physical
File systems
Operating Systems
Network protocols
e.g. NTFS, Ext3
e.g. Linux, Windows
e.g. TCP/IP, UDP
LUNs
Hypervisors
VLANs
Disks, Array
Servers,
Switches,
Controller, SAN
Blades etc.
Routers etc.
Compute
Network
switches etc.
Storage
Each physical layer provides Abstraction to the layer above
Each Virtualized layer provides a flexible mapping/management point
5
Balancing the infrastructure
Service Level Agreements (SLAs)
Business process /
service
Reference Data
Risk Management
Customer Portal
Virtualized Platform
Data Grid
Compute Grid
Server Farm
Platform Instance
Database
App Server
Web Server
Virtualized Operating
Environment
NFS, SMB, NAS
VMMs
Load balancing,
VIPs
Operating
Environment
File systems
e.g. NTFS, Ext3
Operating Systems
e.g. Linux, Windows
Network protocols
e.g. TCP/IP, UDP
LUNs
Hypervisors
VLANs
Management
Disks, Array
Controller, SAN
switches etc.
Servers,
Blades etc.
Switches,
Routers etc.
(VRM)
Storage
Compute
Network
Virtualized Physical
Physical
Capacity & Performance
Assets
6
Virtual Resource Market - Details
$ for SLAs (Budget)
$/Fabric
$/Virtual Unit Performance $/Unit Performance
Match
Compute
Fabric C1
Bid for Compute Fabric
Offers of C1
Compute
Fabric C2
Bid for Network
Fabric
Canonical
Architecture A
n-tier application
Offers of C2
Bid for Storage
Fabric
Bid for Compute Fabric
Virtual
Resource
Market
Bids
Canonical
Architecture B
Compute Farm
Bid for Storage
Fabric
Bid for Compute Fabric
Canonical
Architecture C
Canonical Application
Architectures
Offers
Bid for Network
Fabric
Bid for Network
Fabric
Time Slice
Bids
Network
Fabric N1
Offers of N1
Network
Fabric N2
Offers of N2
SLA
Storage
Fabric S1
Offers of S1
Storage
Fabric S2
Offers of S2
Minimize $/Unit Performance
Maintain SLAs
Time Slice
Offers
Virtualized
Resources
Compute Fabrics Network Fabrics Storage Fabrics
$ for SLA to $/Virtual Unit
Performance
Message Hub
Physical Resources
7
SLAs work just like any other piece of software
From the classic waterfall process (or SDLC+):
Initiation (Concept)
If we are going to have a system then we will need an SLA
Requirements definition
Identify at a coarse level what the parameters covered by the
SLA
will be
System and software design
Determine high level metrics (key performance indicators) then
refine to get specific metrics
Implementation and unit testing
This creates and verifies the functional parts of the SLA
Integration and system testing
At this stage it should be possible to validate that the non
functional aspects are achievable
These stages are where
efforts are typically focused
with existing performance
management tools.
}
Deployment / maintenance
Ensure that the system performs within the SLA and respond to
exceptions
Evaluation
Does the SLA actually represent the service to fit the business
need that drove the original concept?
Many systems are integrated
and tested for ‘ultimate’
performance because no SLA
has been defined, designed or
developed earlier in the cycle.
8
Tools and technology
XML has become increasingly popular for modelling derivatives, with FPML emerging to cover
most of the common ground
We need standard XSDs for SLAs
Composition is crucial – we don’t code from scratch, so we won’t build SLAs from scratch
Common models (canonical forms) can be reused
 These may well have repeatable behaviour as well as shape
Components and frameworks have yet to emerge
 SLAng (UCL) shows the way, WS-CDL may help with behaviour
Eclipse plugin for SLAs – coming soon?
9
Questions?
10
11