RESERVOIR Resources and Services Virtualization without Boundaries

1. RESERVOIRResources and Services Virtualization without Boundaries Benny Rochwerger Lead Architect IBM Haifa Research Lab.

2. Cloud Computing: A style of computing where massively scalable IT-enabled capabilities are delivered as a service to external customers using Internet technologies. Premise: No single cloud can create a seemingly infinite infrastructure capable of serving massive amounts of users at all times, from all locations RESERVOIR: Investigate technologies for advanced Cloud ComputingFocus on technologies that enable to build afederation of cooperating computing clouds

4. Goals of the Reservoir Project • Develop technologies for advanced Cloud Computing • Provide a software architecture where resources and services can be transparently and dynamically managed, provisioned and relocated like utilities – virtually “without borders” • Capabilities of service mobility and migration • Premise: No single cloud can create a seemingly infinite infrastructure capable of serving massive amounts of users at all times, from all locations • Federation of clouds • Leverage the diversity factor to achieve economies of scale • Leverage locality • Envisioned Impact • Optimize service delivery, relieving service consumers from awareness of IT attributes while providing QoS and security guarantees

5. Approach • Focus on technologies that enable to build cooperating computing clouds • Connect computing clouds to create an even bigger cloud • The Service Oriented Infrastructure (SOI) equation: • Start with grid computing concepts • Resource sharing across organizations and geographies • Add virtualization technologies • Use of virtual machines as the basic unit of work • Drive the system by new techniques for business service management

6. Design Driven by Real-World Scenarios • Scenario 1: SAP business application (SAP) • Business application oriented use cases and the opportunities to execute them on a flexible infrastructure. • Scenario 2: Telco application (TID) • Hosting web sites that deals with massive access (e.g., the Olympics games) • High degree of personalization and support for mashups • Scenario 3: Utility computing (Sun) • Classical grid computing on top of cloud infrastructure • Scenario 4: eGov application (Thales) • Automatic adjustment of resources and domains cooperation

7. Project Profile • 3 Years EU FP7 project started in February • Budget: € 17 million • 13 partners from across industry, academia and standards bodies • Selected as a NESSI strategic project • The Networked European Software and Services Initiative (NESSI) is an industrial consortium focusing on advancing research in the area Services Architectures and Software Infrastructures • Public web site • http://www.reservoir-fp7.eu/

8. A4: Service Management (TID) A6: Dissemination (CETIC) A5: Testbed and Scenarios (UniMe) A1: Architecture (IBM) A3: VEE Management (UCM) A2: VEE Infrastructure (IBM) Project Structure

9. Major Deliverables (First Year) [1] Deliverable numbers in order of delivery dates [2]IR = Internal Report R = Report P = Prototype D = Demonstrator O = Other [3]PU = Public PP = Restricted to other programme participants (including the Commission Services). RE = Restricted to a group specified by the consortium (including the Commission Services). CO = Confidential, only for members of the consortium (including the Commission Services). [4] Measured in months from the project start date (month 1).

10. Major Deliverables (First Year) [1] Deliverable numbers in order of delivery dates [2]IR = Internal Report R = Report P = Prototype D = Demonstrator O = Other [3]PU = Public PP = Restricted to other programme participants (including the Commission Services). RE = Restricted to a group specified by the consortium (including the Commission Services). CO = Confidential, only for members of the consortium (including the Commission Services). [4] Measured in months from the project start date (month 1).

11. The RESERVOIR Architecture Spec. • Use Cases • Requirements • Model • Security • Major Components • VEEH • VEEM • Service Manager • Testbed • Summary

12. Infrastructure Adaptive resource allocation Migration and elasticity transparency Cost-based optimization Autonomous local optimizations Minimal virtualization overhead Reasonable migration performance Service Management The Service Definition Manifest Template-Based Provisioning Flexible Virtualization Configurations Resource Consumption, Management and Enforcement Conflicts Resolution and Avoidance Requirements • General • Separation between Infrastructure and Services • Multi-Site Capabilities • Service Orientation • Virtualization Technology Independence • Security • Utility Computing Cost Model – Accountability

13. The Reservoir Architecture Service Provider supplies: • Pre-packed Service Components (VEEs) • Service Definition SLAs are established b/w Service Provider and Service Manager • Monitor service and enforce SLA compliance by managing capacity of Service Components (VEEs) or/and size of Service Tiers • Deals with translation/mapping of service concepts/metrics (response time) to infrastructure concepts/metrics (VEE size) • Responsible for accounting and billing • Monitors VEEs and finds optimal VEE placement that meets service constraints • Deals with federation of sites • Admission control • Translates generic commands into command specific to the virtualization platform it abstracts • Setting and maintaining isolated virtual networks • Enables efficient and secure access to remote storage • Performance optimizations

14. Major Deliverables (First Year) [1] Deliverable numbers in order of delivery dates [2]IR = Internal Report R = Report P = Prototype D = Demonstrator O = Other [3]PU = Public PP = Restricted to other programme participants (including the Commission Services). RE = Restricted to a group specified by the consortium (including the Commission Services). CO = Confidential, only for members of the consortium (including the Commission Services). [4] Measured in months from the project start date (month 1).

15. Market Analysis Report • Trends • Players • Challenges

16. Source: Insight Research Corporation Trends • Virtualization is widely recognized as a “must-have” technology • Initially driven by needs for server consolidation • Data center optimizations is quickly becoming the main driver • Policy driven resource utilization and/or power consumption • Cloud computing not widely accepted yet • Reluctance to lose control • What is a cloud (SaaS, PaaS, IaaS) • In some market SaaS is very popular • Who owns the cloud (Enterprise cloud, partner cloud, service cloud) • Private enterprise clouds seem attractive

17. Main Players

18. Coghead Eucaplyptus Flexiscale GoGrid Heroku IBM Joyent Longjump Mosso Oracle Q-Layer Rightscale Salesforce Sun Microsystems CiRBA Cisco Citrix Configuresoft eG Innovations Embotics Hyperic IBM MANAGEIQ Microsoft Novell Sun Microsystems VKERNEL VMLOGIX VMware Other Players – It is crowdy out there …

19. Challenges http://gigaom.com/2008/07/01/10-reasons-enterprises-arent-ready-to-trust-the-cloud/

20. Major Deliverables (First Year) [1] Deliverable numbers in order of delivery dates [2]IR = Internal Report R = Report P = Prototype D = Demonstrator O = Other [3]PU = Public PP = Restricted to other programme participants (including the Commission Services). RE = Restricted to a group specified by the consortium (including the Commission Services). CO = Confidential, only for members of the consortium (including the Commission Services). [4] Measured in months from the project start date (month 1).

21. First Year Prototype (Jan 09) • Focus on the integration between the different layers • Show end-to-end functionality even if it is partial • Selected use case • Sun Grid Engine on KVM • Scenarios • Initial deployment of complex service • Highlight separation of concerns between SP and IP • Smart placement • Move VEEs around to make room for new “big” VEE • Automatic capacity adjustment (elasticity) • Monitor application, add VEE when application is “in trouble”

22. Summary • Very aggressive project to create the next generation infrastructure for services • Bridge the gap between the services and infrastructure worlds • Focus on technologies that enable to build cooperating computing clouds • Explore, merge and extend technologies • Grid computing concepts (large scale federation)‏ • Virtualization • Business Service Management • Status • Done with the documents … • Architectural spec. (M4)‏ • Integration plan (M6) • High level design (M9) • Initial testbed in place • Sites in UNIME (Italy), UCM (Spain) and IBM (Israel)‏ • Full speed with implementation first year prototype • On track to first official demo (1Q09)‏

24. RESERVOIR in a Nutshell CloudWare Inc. 雲是我們

25. RESERVOIR in a Nutshell System should adapt to sudden increases in load … CloudWare Inc. … but there is not enough capacity locally 雲是我們

26. RESERVOIR in a Nutshell Adjust local utilization by migrating lower priority workloads to partner provider CloudWare Inc. 雲是我們

27. RESERVOIR in a Nutshell CloudWare Inc. 雲是我們

28. RESERVOIR in a Nutshell CloudWare Inc. 雲是我們

29. RESERVOIR in a Nutshell CloudWare Inc. 雲是我們

30. RESERVOIR in a Nutshell When load decreases … CloudWare Inc. 雲是我們

31. RESERVOIR in a Nutshell When load decreases … … system releases local resources … CloudWare Inc. 雲是我們

32. RESERVOIR in a Nutshell … migrates back workloads that were temporarily handled by another provider … CloudWare Inc. 雲是我們

33. RESERVOIR in a Nutshell CloudWare Inc. 雲是我們

34. RESERVOIR in a Nutshell … and pays for the service CloudWare Inc. 雲是我們

35. A2: VEE Infrastructure • Virtual Machine Technologies (IBM) • Improve performance of VEE execution for typical RESERVOIR workloads • Provide VEEMS enablement layer for virtual machines • Relocation Enablement (IBM) • Network Virtualization • Storage Virtualization • Java Service Containers (Sun) • Provide VEEMS enablement layer for virtual java service containers

36. A3: VEE Management • VEE Provisioning and Supervision (UCM) • Image management • Monitoring • Allocation Policy Management (Elsag-Datamat) • Policy based placement and migration • Federation of Management Domains (UCM) • Built atop WSRF interfaces to access remote VEE Supervisors • Push new and leverage existing OGF/DMTF/OASIS standards • Interoperability between administrative domains and scheduling heuristics on federated and utility architectures.

37. A4: Service Management • Service Definition (UCL) • Design a new service description language that will allow the description of service interfaces, service lifecycle, interface bindings to implementations, service deployment, SLA requirements for a service, rules for VEEs (re)configuration and (re)organisation and service components distribution and configuration • Revisit the service lifecycle definition and extend it to accommodate the influence of virtualisation • Extend tools available for service design (for example the Eclipse Web Tools Platform) • Standardize the service description language • Service Management (TID) • SLA monitoring across administrative domains settings and service-oriented architectures. • Integrate monitoring with resource allocation and scheduling and take explicit account of the potentially synchronous nature of service invocations. • Automatic deployment of services based on complex service definition • Accounting, Billing and Payment (TID) • Accounting and billing arrangements for outsourced services are based on raw machine resource consumption (CPU-time, storage capacity etc) • RESERVOIR will pursue the definition of a framework that allows accounting and billing in terms of the services that were completed, taking into consideration the quality of service that was provided.

38. A5: Experimentation and Validation • Testbed (UniMe) • Create the necessary environment for testing and validation • Support the execution of use cases • Scenario 1: eGov application (Thales) • Automatic adjustment of resources and domains cooperation. • Scenario 2: SAP business application (SAP) • Business application oriented use cases and the opportunities to execute them on a flexible infrastructure. • Scenario 3: Utility computing (Sun) • Deploy arbitrary operating system and application stacks on remote resources. Provide secure and seamless access to them. Adjust resource allocation on-demand without the end user noticing disruption of service • Scenario 4: Telco application (TID) • Hosting web sites that deals with massive access (e.g., the Olympics games) • High degree of personalization and support for mashups

39. Technical Challenges Addressed by the Project • From service (high level, business concepts) to infrastructure (low level, IT concepts) • A service definition language that captures in functional requirements of the service • Mapping of high level service requirements and metrics (e.g., response time) to infrastructure level requirements and metrics (e.g., CPU utilization) • Policy-based management across administrative domains (clouds) • Multi-level SLA management (service consumer, services provider/s, infrastructure provider) • Separation of functional responsibilities and collaborative reconciliation • Service level utility analog of electricity power, • Dynamically automatically hire additional 'power‘ from a another cloud • Enable intra-site and inter-site workload optimization, HA and SLA management • The capability of creating fully isolated virtual organizations spread across geographies and management domains. • Through an integrated approach to virtualization of servers, network and storage • Introduce capabilities for mobility of virtual resources and services across different administrative domains, and for management of disparate virtualized environments • End to end performance of virtualized systems • Identify “typical service workload” for which Reservoir-like infrastructure is advantageous • Pinpoint causes of performance degradation, for the selected service workload(s), in virtualized environments • Introduce service workload-specific optimizations to relevant virtualization layer

40. The RESERVOIR Architecture Spec. • Model • Use Cases • Requirements • Security • Major Components • VEEH • VEEM • Service Manager • Testbed • Summary

41. The Reservoir Architecture • Monitor service and enforce SLA compliance by managing capacity of Service Components (VEEs) or/and size of Service Tiers • Deals with translation/mapping of service concepts/metrics (response time) to infrastructure concepts/metrics (VEE size) • Monitors VEEs and finds optimal VEE placement that meets service constraints • Deals with federation of sites • Translates generic commands into command specific to the virtualization platform it abstracts • Setting and maintaining isolated virtual networks • Enables efficient and secure access to remote storage • Performance optimizations

42. VEE Infrastructure Challenges • Distinct VHI implementations • Prove validity of “generic” VEEM placement algorithms • Performance optimizations • For real applications virtualization overhead may be a barrier to adoption • Support for Virtual Administrative Domains • Network virtualization • Isolated virtual networks • Support VEE migration with minimal traffic disruption • Storage Virtualization • Efficient access to “home” images and data

43. Virtualize the Network Create virtual networks connecting VEEs regardless of physical server location

44. Virtualize the Network and the Storage Enable secure access to relevant data regardless of storage location

45. A Closer Look at the VEEH Layer …

46. The Reservoir Architecture • Monitor service and enforce SLA compliance by managing capacity of Service Components (VEEs) or/and size of Service Tiers • Deals with translation/mapping of service concepts/metrics (response time) to infrastructure concepts/metrics (VEE size) • Monitors VEEs and finds optimal VEE placement that meets service constraints • Deals with federation of sites • Translates generic commands into command specific to the virtualization platform it abstracts • Setting and maintaining isolated virtual networks • Enables efficient and secure access to remote storage • Performance optimizations

47. VEE Management Challenges • Dynamic scaling of the physical infrastructure • Support changes in capacity demands • Dynamic scaling-out of the infrastructure (federation) • Meet fluctuation demands for resources • Infrastructure allocation based on SLA parameters • Support SLAs negotiated in framework agreements • Support for elastic services • Meet dynamic capacity requirements from services • High availability • Protect systems from failures • Heuristics for capacity provision to meet SLA commitments • Heuristics for capacity provision across infrastructure sites 47

48. Internal Architecture • Allocation Policy Management • Control the execution of VEEs according to infrastructure capacity provisioning policies to ensure SLA compliance in different use cases Activity 4: Service Management VMI VMI VEE Core VEE Policy Engine VMI VHI plug-in VHI • VEE Provisioning and Supervision • Manage the discovery and preparation of physical resources, and dynamic deployment, allocation, monitoring and termination of VEEs • Accessing to remote virtualization technology • Translate management orders from VEE core to protocols supported by specific virtualization platforms, including remote sites Virtualizer Virtualizer Activity 2: VEE Infrastructure Enablement Presentation Title 48

49. The Reservoir Architecture • Monitor service and enforce SLA compliance by managing capacity of Service Components (VEEs) or/and size of Service Tiers • Deals with translation/mapping of service concepts/metrics (response time) to infrastructure concepts/metrics (VEE size) • Monitors VEEs and finds optimal VEE placement that meets service constraints • Deals with federation of sites • Translates generic commands into command specific to the virtualization platform it abstracts • Setting and maintaining isolated virtual networks • Enables efficient and secure access to remote storage • Performance optimizations

50. Service Manager Components and Functionality LifeCycle Management Service Request Dispatching Accounting Payment and Billing Orchestrates the Service Manager Components, managing the initial deployment of the Service and the dynamic configuration and redeployment process targeted to protect some SLA objective criteria Load balancing and efficient request dispatching are implemented taking into account SLA objectives and the Service architecture. Support new utility computing business models (based in pay-per-use schemas) dealing with several infrastructure providers, services business models and commercial offers.