Cloud Federations in Contrail

Transcription

1 Cloud Federations in Contrail Emanuele Carlini 1,3, Massimo Coppola 1, Patrizio Dazzi 1, Laura Ricci 1,2, GiacomoRighetti 1,2 " 1 - CNR - ISTI, Pisa, Italy" 2 - University of Pisa, C.S. Dept" 3 - IMT Lucca, Italy " contrail is co-funded by the EC 7th Framework Programme under Grant Agreement nr

2 Overview What is Contrail Approach to Cloud Federations SLA and QoS in Contrail Security issues Federation as middle-man Architecture of the Federation support Application description model Current issues and Future work

3 Contrail FP7 IP, 11 partners from 6 countries Academic Industrial INRIA, CNR, ZIB, VUA, STFC HP-Italy, Tiscali, XLAB, EBM websourcing, Constellation, Genias Design, implement, validate and promote an open source software stack for Cloud Computing Federations Comprehensive Cloud platform integrating a full IaaS and PaaS offer Integrate resources from other Clouds with private infrastructures Provide trusted Clouds by advanced SLA management Break the current customer lock-in situation by allowing live application migration across Clouds

4

5 Contrail project 1 Project management SP5. Use cases and exploitation 12 SP4. System Engineering Applications and Use Cases 13 Testbeds SP3. Platform as a Service 8 High level services Exploitation Communication and and technology Dissemination Demonstrators transfer Text 9 Runtime environments 10 System Architecture 11 Integration, testing and release management SP1. Cloud federation management 2 3 SP2. Virtual Infrastructure layer 4 Virtual Computational 5 Resource Infrastructure Network Management for Virtual (VIN) Cluster Platforms (VCP) 6 7 Global Autonomous File System (GAFS)

6 Contrail Iaas Federation A Contrail Federation integrates in a common platform multiple Clouds, of public and private kind. User identities, data, and resources are interoperable within the federation, thanks to common supports for authentication and authorization common mechanisms for policy definition, monitoring, and enforcing of all aspects of QoS : SLA, QoP, etc. the basis of a common economic model

7 Federation WP Objectives Develop a Federation support that integrates and actively coordinates SLA management provided by single Cloud providers Do not disrupt provider s business model Cloud administration is not Federation management Allow exploiting a Federation as a single Cloud Cloudbursting to and from the Federation Federation Support must be scalable Number of apps running, providers, resources, users

8 Contrail Overall Architecture Abstract viewpoint Full providers and dedicated providers Resource providers based on Open Nebula Interfaces to Public Clouds Federation API Resource Provider Storage Provider Network Provider Resource Provider Public Cloud Storage Provider

9 Contrail Overall Architecture Coordinate deployment and management of application on multiple clouds Each app can exploit more providers Application Federation API A Resource Provider Storage Provider A Network Provider Resource Provider A Public Cloud A Storage Provider

10 Distributed Architecture Abstract API is replicated onto each Federation access point FAP act as brokers, but share a common view Security, provider status, user actions FAP not restricted to local provider F F F F Policies and auth/authz are common Contention issues Final resource allocation is on providers Shared info helps management AP either hosted by provider, or on independent HW

11 Contrail approach to SLA Reuse framework as a starting point Integration with Contrail internal interfaces and components Integration with domain-specific reasoning/monitoring plugins Extend SLA@SOI with: Federation support QoP support Integration of external providers Reputation model for providers Cost-based QoS enforcement

12 Holistic approach to QoS Extend the set of characteristics to be measured on the platform Protection Type of security mechanisms which are in place Auth. Protocols, Encryption mechanisms, Isolation Privacy Guarantees offered by storage holder, network infrastructure Geo-localization Can have deep legal implications More in the future E.g. power consumption: overall power, efficiency

13 SLA Requirement Summary Required QoS terms: availability for VMs and data network bandwidth web response time,... Required QoP terms: storage zeroing upon release encryption algorithms access control policies authentication and authorization requirements for services logging policies data confinement mechanisms data location recoverability Other requirements: penalties for SLA violations access control on map/ reduce intermediate data pub/sub for monitoring keep history of monitored data accounting and monitoring data isolation per user support custom monitoring metrics and events user to be notified of SLA violations automatic negotiation and automatic monitoring setup multi-turn negotiation and renegotiation negotiation timeout

14 Different ways of measuring services Observable properties User s perspective! Provider has direct control Performance of a VM can be directly verified You cannot check everything Zeroing unallocated space Physical location and security of machines Enforceable properties Provider perspective Beyond best-effort and static configuration The provider is also able to take measures to correct deviations Changing resource allocation, e.g. VM migration

15 User trust and Providers As the SLA is signed, the user should be able to trust resources from the platform But not all Providers may sport same reliability For non observable terms, trust is organisational User cannot efficiently detect / track violations Providers know all resource state Can optimize usage, but what if too much?

16 Federation as 3 rd party Federation sits in the middle Hierarchy of SLAs Hierarchical SLA negotiation (cfr. SLA@SOI) Aim serve the user, efficiently exploit providers Gains overall efficiency, features, intermediation Means Info from all users and applications can afford to test explicitly can trigger corrective actions over several providers

17 Architecture of a Federation Access Point Federation support Interface layer HTTP CLI REST Core layer Security SLA Organizer SLA Template Repository Federation Runtime Manager Mapping User Identity Authentication Attribute Authority SLA Negotiation Image Manager Image Registry Policy Administration Point SLA Coordination Provider Watcher State Policy Decision Point Adapters layer VEP driver GAFS driver VIN driver External Cloud adapters SLA Management SLA Management Contrail Provider External Provider

18 Federation support Interface layer HTTP Interface Layer REST CLI Core layer SLA mng. SLA Organizer SLA Template Repository SLA Negotiation SLA Coordination Adapters layer Runtime Core Layer Federation Runtime Manager Mapping P. Watcher Provider Watcher VEP driver Image Manager Image Registry Adapter Layer GAFS driver User Identity State State VIN driver External Cloud adapters Security. Security Authentication Attribute Authority Policy Administration Point Policy Decision Point SLA Management SLA Management Contrail Provider External Provider

19 Provider Reputation Management information Available resources per kind Features granted Amount of users/apps ongoing State of SLAs controlled by the federation Static level of trust given from federation to the provider Past History History of SLA violation per user / type of app Average level of satisfaction of SLA

20 Planning for SLAs Choose the best provider(s) and map the application on the virtual resources provided Beside constraints, multiple criteria choice Many user criteria Federation has its own goals balance user satisfaction balance provider satisfaction How do you choose the resources? What if one provider is not enough?

21 Application and SLA splitting Application deployment on multiple providers : a federation is more than the sum of its providers Type and amount of resources needed Sudden elasticity Peculiar resource dislocation Tough issue Multi-criteria and problem size Both at SLA negotiation and at run-time Matching application structure and SLA Identifying suitable set of providers and mapping

22 Matching SLA with VMs at IaaS level Application description formats for Clouds describe in detail VM images How to deploy them A detailed SLA can provide key information in order to to split the app We need to add structure to the application And link it to SLA requirements Also, stick with standards

23 Matching and OVF Exploit a combination of two properties In SLA@SOI, SLA parts can reference resources contained in the application description In OVF, VMs can be arranged in VirtualSystemCollections Used to represent data-center like structures, can be useful to describe applications Allows us to build a high-level Task Interaction Graphs of the application

24 Adding Extra Collections Additional VirtualSystemCollections allow to place constraints on group of machines Ordinary QoS terms Aggregate QoS terms (overall memory, elasticity) Reciprocal QoS terms (group comm. Bisection Bandwidth) No deep restructuring VSC VS Collection VS Collection VSC VSC VSC SLA

25 Benefits of adding structure in SLAs Increased granularity of constraints Delegate parts of SLA to provider Independent VMs on separate providers Finding resource mappings is a multi-criteria problem Size reduction (from VMs to Groups) Eases developing heuristics (solution space pruning) Makes splitting a group an explicit choice Known parallel structures can be represented Widespread PaaS services (ConPaaS) workflows, map&reduce, bag of tasks Components, skeletons More sources of heuristics for mapping and SLA management in federations

26 Conclusions Contrail Federation goals and architecture Still in early implementation Relying on standards and Open source Tight integration with SLA mng. and Security Leverage actual service/resource providers Distributed set of coordinated AP Global security & trust Scalability Potential gain from multi-provider applications Splitting applications

27 Future Work Implementation ongoing Security and state synchronization Extension and integration w. framework Integration with Contrail providers VCP (OpenNebula), GAFS, VIN Research ongoing on exploiting vertical integration with PaaS splitting and mapping heuristics to deal with multiple providers defining and exploiting provider reputation express user as well as federation optimality

28 Thanks for you attention Questions are welcome!

29 contrail is co-funded by the " EC 7th Framework Programme" Funded under: FP7 (Seventh Framework Programme)" Area: Internet of Services, Software & Virtualization (ICT )" Project reference: FP7-IST " Total cost: 11,29 million euro" EU contribution: 8,3 million euro" Execution: From till " Duration: 36 months" Contract type: Collaborative project (generic)"