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