Cloud Federations

1. http://contrail-project.eu Cloud Federations • Patrizio Dazzi (ISTI-CNR) [Overall Presentation] • patrizio.dazzi@isti.cnr.it • Gaetano Anastasi (ISTI-CNR) [Hands-On] • gaetano.anastasi@isti.cnr.it contrail is co-funded by the EC 7th Framework Programme under Grant Agreement nr. 257438

2. Presentation Outline CloudFederations ContrailFederations ContrailFederation Architecture Federations and Resources A fewdetailsabout the current status of ContrailCloudFederations Introduction to the hands-on session

3. CloudFederations

4. WhatisCloud Computing ? • Computing as a public utility • Clouds are the computing “powerplants” • Do notmanageresources, just use them • Choose the interaction model: SaaS, PaaS, IaaS

5. PrincipalAdvantages of CloudComuting • Advantagesfor Tenants: • Pay just whatyouget • Payonlywhenyouget • Reduce costs for maintenance • Advantagesfor Providers • maximizing the effectiveness of the sharedresources. • dynamicallyre-allocationdepending on actualusage

6. Anyway… • Providers have: • A limitedamount of resources • A limitedrange of resourcetypes • Resourcesplacedonly in samecountries • Providers want: • to avoidthattheircustomersleavethem • To make (more) money • Userswant • To haveall the resourcestheyneed (possibly more) • To payless…. • How can wemanagethis ???

7. CloudFederations • A Federation of Cloudsis (maybe) the answer • By federating, providers can offer more resources • More resourcesmeans… • To be able to runbiggerapplications • To be more elastic • To provide (potentially more) differentresources • A federation (may) allowusers to • Chooseamong a widerrange of providers • Seamlessly use more providers for the sameapplication • Migrate from a provide to another

8. Federation of IaaS providers • Infrastructure as a Service • provide computation, storage and network • IaaS Providers • distinct Clouds may have different interfaces, access rules, capabilities, prices, … • Special Providers • Peculiar computational supports • Specific Storage capabilities • High performance networking

9. How Federation of IaaSimpacts on PaaS and SaaS • The background: • Platform and Software as a service offer an even more complex landscape • PaaS and SaaS provider may be distinct from IaaS ones • IaaS Federation can • Allow properly instrumented PaaSand SaaS to run on top of a huge amount of resources • Need to translate PaaS and SaaS requirements • To address heterogeneity of providers • Enforce QoS guarantees

10. Unified Identity and Billing management • Federations should be almost invisible from the point of view of users but: • User’s identity should be automatically managed • In a cross-cloud fashion • Creating and managing proper identities in each cloud (if needed) • Map by keeping proper capabilities and permissions • Users have to be properly billed • Unified monitoring • Unified accounting

11. Security Mechanisms • Authentication • Allow the access of users to Clouds • Exploit existing identity infrastructures • E.g. OpenID • Enact an identity federation • Authorization • Access Control • Usage Control • Particularly useful for long lasting applications

12. Cross-Cloud management of Service Level Agreements • Cloud Applications have QoS requirements • Performance, reliability, security • Typically expressed as SLAs • SLA management is a complex activity also in a single Cloud • Violations may occur and need to be managed • Even more complex in a Federation of Clouds • Not all providers provide the same degree of • guarantees • strictness • penalties • Compensation • An overall coordination activity shall be performed

13. Last butnotLeast: Brokering • Cloud Federations also behave as brokers • To find for each user’s application the best Cloud(s) depending on • Application structure and requirements • Cloud reputation • Cost • Splitting the user’s application in order to • Choose the best Cloud for each part of the application • Allow a better exploitation of Specialized Clouds

14. Contrail Federations

15. Contrail Iaas Federation A Contrail Federation integrates in a common platform multiple Clouds, both public and private ones. To perform this task it provides: A common support for authentication, authorization and billing Mechanisms for policy definition, monitoring, and enforcing for all the QoS-related aspects An automated selection of providers depending on the user applications A support for resource provisioning to applications able to deal with heterogeneous sets of resources

16. Contrail development methodology • Do not rebuild and reinvent • Contrail exploits Standards • OVF • OCCI • OpenID • Exploit existing platforms and functionalities • Open Nebula • SLA@SOI • Etc.

17. Exploit Providers’ SLA support Develop a Federation support that integrates and actively coordinates SLA management provided by single Cloud providers Do not disrupt provider’s business model Allow exploiting a Federation seamlessly Federation Support must bescalable

18. Main Contrail Federation Innovations (1) Federation = more than a simple broker, or portal, or decentralized cloud-bursting • Interoperability • Heterogeneous providers • Dynamically choosing best providers • At deploy time and at runtime • Allow to combine providers • Migration, elasticity • Security and privacy framework

19. Main Contrail Federation Innovations (2) • Sophisticated SLA/QoS • QoS via SLA • Via provider selection and integration • Enforcement mechanisms • Federation as a mediator and a 3rdparty • Federation also acts as a coordinator

20. ContrailFederationArchitecture

21. SimplifiedBlocksArchitecture

22. Distributed Federation Access Points • Hierarchical structure • Common Policies • Detailed resource allocation is on providers • AP may be hosted by providers F F F F • Several Federation access points (FAPs) • FAP act as brokers, but share a common view • Security, status of resources, users and providers reputation

23. Coarse-grain view of Contrail Federation Architecture Federation Interfaces SLA Federation Core Auth AuthZ Provisioning Manager Functionalities which extend horizontally in the platform

24. Concrete Architecture In the next slide Module View of a single Access point Interactions, some modules not shown Interfaces sit on top of this core Auth/AutZ mechanisms included

25. Contrailfederation Provisioning Manager Provisioning Manager

26. Federations and Resources

27. Basic concepts • What’s an application for IaaS? • A set of software entities which need to be deployed on a suitable set of resources for execution • The parties involved • User • Who submit applications • Provider • Any entity managing physical resources which may be used to run applications • Federation • The union of many providers under a common set of APIs and functionalities, which can be exploited as a single Cloud

28. Application Description • The requirements so far can be expressed as a Task Interaction Graph • An undirected graph G(N,E) can model a distributed application • Each Node in N is a task (needs a resource) • Edges imply relations between tasks (need links) • Heavily labeled graph • Nodes state all resource constraints and SLA measures • Edges labeled with communication needs • Cloud applications can gethard to describe

29. Types of resources • Computation resources • Available VMs slots on top of physical hardware • Storage resources • Shared filesystems • Shared Databases • Networking resources • Virtual networks connect machine within an application • Behaviour of the joining points between the internet and the federation is important

30. How resources are measured ? • Static specification by analogy with the physical counterparts • Memory size, CPU type and speed (peak) • Size, FS of storage • Nominal bandwidth and latency of networks • Dynamic specification • Available computing power, memory • Actual (average, peak, used) storage speed • Observed in-Cloud bandwidth and latency • Observed bw/lat to the outside • Application-specific metrics

31. Provider’s View on resources • Providers know exactly the layout and state of all physical (virtual) resources • Dedicated link bandwidths, physical memory… • They can greatly optimize resource management • Turn off unused resources, exploit cheapest • They have their own goal (revenues)

32. QoS properties of resources • 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 • Power consumption • Overall power, power efficiency

33. QoS expressed via SLAs • As the SLA is signed, the user should be able to trust resources from the platform • But not all Providers may offer the same reliability • How reliability can be measured ? • failures, SLA violations with different providers • lengthy task with poor reward for single users

34. 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

35. Contrail approach to SLA • Reuse SLA@SOI framework as a starting point • Integration with Contrail internal interfaces and components • Integration with domain-specific reasoning/monitoring plugins • Extend SLA@SOI with: • Federationsupport • Integration withexternal providers (andtheir SLA management systems) • Reputation model for providers • Cost-based QoS enforcement

36. Federation-level SLA Enforcing • Federation will act as a SLA coordinator over providers • As much as possible the single providers is in charge of the local SLA • Reduce reaction delay • Federation evaluates the provider and the app • Extend the SLA@SOI monitoring infrastructure to the federation • Keep track of main application parameters • Receive SLA violations from providers • Reallocate some resources on a provider basis • May require a new negotiation between federation and provider

37. What if… a SLA is violated in a single provider scenario ? The application is deployed on a single provider, which may still violate SLA • Actions: • The provider resize the set of allocated resources • If the application is no longer violating SLAs • The application will be up and running and that’s it • Otherwise • A renegotiation phase is conducted and if will not be successfully the application will be terminated

38. …and whatif the violationoccurs in a multi-provider scenario ? The applicationhasbeensent by the federation to a provider for the execution and a SLA violationoccurs • Actions: • Previous slide shows whathappenswhen the provider isable to manage the violation by itself • Ifitisnotable, the federation can still migrate (part of) the application to a different provider Contrail S. School 2012 – P. Dazzi- Cloud Federations

39. Applications Running inMultiple Providers Some applications could be also decomposed in parts and each deployed in a different provider • Actions • resize part(s) • managed by providers • migrate part(s) • may need to stop the application • violate constraints • By leveraging the whole federation we push away the limit where a violation is unavoidable • rebalance constraints • By renegotiating with more providers, overall SLO may be achieved • Increase resource availability where they are cheaper/more available at the moment

40. Anyway SLA splitting is still an open issue • Necessary to leverage SLA management at single providers • How to derive a combination of SLA for separate parts of the application which allow to manage the application overall • Not yet addressed in literature • Not hard if providers are specialized • Compute, network, storage = SLA aspects • As the user expresses SLA terms on parts of the application (task groups) this will become easier

41. Contrail Federation, the 3rd Player • A Contrail Federation sits in the middle • Aims • Serving the users • Exploit efficiently the providers • If economic gain is sought, it comes form intermediation • Can efficiently gather provider information • Gathers from all users and all providers • Can make better informed choices than users • Can afford to launch directed tests in doubt • Can trigger corrective actions impossible to single providers

42. A fewdetailsabout the current status of ContrailCloudFederations

43. Howitisused • Federation Interfaces use REST • The Web portal and command line tools access the REST layer • Different roles • federation coordinator • cloud administrator • end user • Main steps • account creation • SLA formation • Application upload (VMs and descriptor) • SLA negotiation and agreement • Deploy

44. Whatisimplementedtoday • User management • Registration, mapping are working • some integration activities are still ongoing • SLA Management • Negotiation with providers counterpart is working • A complete integration is expected in the next release • Application management • Applications can be submitted and executed • So far only one provider at a time can be used for a single application

45. Aligning with standard formats • OVF (Open Virtualization Format) • Open format for describing application • Allows to describe structured applications • Directly expresses only HW constraint and deployment information • Partially overlaps with full SLA specification • OVF is extendable • As of v1.1.0 it does not target Application Management • SLA@SOI provides a general formalization • Includes monitoring hierarchy and negotiation • Exploit a combination of OVF and SLA@SOI mechanisms

46. “Securing” the implementation • The currentimplementation of federationauthentication • Support for OpenID • Additionaldetails in Jens’skeynote • The currentimplementation of federationauthorization • Advanced support to access control • Ongoingwork to finalize the support to usage control

47. Ongoing work aboutadvancedfeatures • Multi-criteriamappingalgorithms • Geneticalgorithms for applicationmapping • Evolvingmappingplans to achievebetterallocations • Application splitting • Interplay with SLA splitting • Monitoring data aggregation and filtering

48. Introduction to the hands-on session Contrail S. School 2012 – P. Dazzi- Cloud Federations

49. Sample Application <VirtualSystemovf:id="VirtualSystem1"> <VirtualHardwareSection> <Item> <rasd:Description>Number of virtual CPUs</rasd:Description> <rasd:ElementName>1 virtual CPU</rasd:ElementName> <rasd:InstanceID>1</rasd:InstanceID> <rasd:ResourceType>3</rasd:ResourceType> <rasd:VirtualQuantity>1</rasd:VirtualQuantity> </Item> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:Description>Memory Size</rasd:Description> <rasd:ElementName>512 MB of memory</rasd:ElementName> <rasd:InstanceID>2</rasd:InstanceID> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>512</rasd:VirtualQuantity> </Item> OVF Representation 2 Appliances Contrail S. School 2012 - M. Coppola - Cloud Federations

50. Simplified Deployment Chain • Users submit an OVF • Federation mapping phase: • Which provider(s) for the application? • Federation Application Submission • Provider Deployment • Provisioning Manager: receives requests coming from the federation • VEP: manages provider resources for deployment • For simplicity do not consider SLAs Contrail S. School 2012 - M. Coppola - Cloud Federations