Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems - CLOSER 2018 - Best Paper Award

77 views

Published on

Presented at Funchal, Portugal by Frederico Alvares (EasyVirt).
Full paper available from https://hal.archives-ouvertes.fr/hal-01705248

Published in: Software
  • Be the first to comment

  • Be the first to like this

A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems - CLOSER 2018 - Best Paper Award

  1. 1. A Model-based Architecture for Autonomic and Heterogeneous Cloud Systems Frederico Alvares EasyVirt, Nantes Zakarea Al Shara Berger-Levrault, Montpellier Jonathan Lejeune Université Sorbonne (Paris 6) Hugo Bruneliere, Thomas Ledoux IMT Atlantique & LS2N (CNRS), Nantes
  2. 2. Context and Motivation Challenges to efficiently design, (re)configure and monitor Cloud systems ● Cloud systems are heterogeneous ○ Many resources of varied natures (software and/or physical) ○ Need for support in a similar way resources coming from different layers ● Cloud systems are highly dynamic ○ Clients can book/release “elastic” virtual resources at any moment ○ Need for transparent reflection & support of this dynamicity/elasticity ● Cloud systems are becoming complex and cannot be handled manually ○ Configuration and monitoring, but also runtime behavior to guarantee SLA contracts ○ Need for decision-making and reconfiguration support 2
  3. 3. Motivating Example ● End-users: students, faculty members, admin. staff, etc. ● SaaS: keep low response times ● IaaS: keep resources available ● EaaS: promote green energy usage ● Dynamical environment ○ On-demand provisioning makes Cloud susceptible to short-term variations ○ e.g., overload situations during practical sessions SaaS Energy as a Service Cloud Client E-Learning BrownGreen IaaS Large VMSmall VM SLA: response time SLA: availability SLA: % green energy 3
  4. 4. Generalizing, the goal is to... ● Autonomically reconfigure the system to have the best balance between ○ Costs, which are related to services consumed/bought from providers ○ Revenues, which refer to services offered/sold to clients ● While complying with SLA Cloud Client SaaS IaaS Energy as a Service consume produce consume produce consume produce SLA SLA SLA produceconsume SLA SLA XaaS Layer n+1 Layer n-1 4
  5. 5. CoMe4ACloud Constraints and Model Engineering for Autonomic Clouds A generic and extensible solution for the autonomic management of Cloud services, independently from the Cloud layer(s) ● A constraint-based model has been proposed [Best Paper Award, CLOSER’2017] ○ But it lacks proper model-based architecture and a reusable modeling language Contributions ● A model-based architecture for generic autonomic XaaS management ● A related XaaS core modeling language, possibly supporting any of the possible Cloud layers ● An Eclipse-based tooling support 5
  6. 6. Outline 1. Architecture Overview 2. Core Modeling Language 3. Tooling Support and Implementation 4. Related Work 5. Final Remarks 6
  7. 7. Architecture Overview 7
  8. 8. Architecture Overview Topology Metamodel conforms to Constraint Program (SLA) Configuration Metamodel Topology Model t conforms to Configuration Model c0 refers to generation Configuration Model c1 refers to conforms to Cloud Expert Cloud Administrator Runtime Design time Cloud System s represents represents <<TOSCA>> Topo./Config. Model tcX’ TOSCA Tool CoMe4ACloud External Solution(s) transformation transformation 8 , cX
  9. 9. Core Modeling Language 9
  10. 10. Topology Metamodel Topology: ELearning-IaaS node_types: InternalComponent: PM: derived_from: InternalComponent properties: ... VM: derived_from: InternalComponent ... Cluster: derived_from: InternalComponent properties: constant ClusterConsOneCPU: type: integer constant ClusterConsOneRAM: type: integer constant ClusterConsMinOnePM: type: integer variable ClusterNbCPUActive: type: integer equal: Sum(Pred, PM.PmNbCPUAllocated) variable ClusterCurConsumption: type: integer equal: ClusterConsMinOnePM * NbLink(Pred) + ClusterNbCPUActive * ClusterConsOneCPU + ClusterConsOneRAM * Sum(Pred, PM.PmSizeRAMAllocated) 10
  11. 11. Topology Metamodel ... Power: derived_from: ServiceProvider properties: constant PowerCapacity: type: integer variable PowerCurConsumption: type: integer equal: Sum(Pred, Cluster. ClusterCurConsumption) constraints: PowerCurConsumption less_or_equal: PowerCapacity relationship_types: VM_To_PM: valid_source_types: VM valid_target_types: PM PM_To_Cluster: ... Cluster_To_Power: ... 11
  12. 12. Configuration Metamodel Configuration: identifier: ElarningSystem_0 topology: ELearning-IaaS ... Node Power0: type: ELearning-IaaS.Power properties: PowerCapacity: 1500 PowerCurConsumption: 0 ... Node Cluster0: type: ELearning-IaaS.Cluster properties: ClusterCurConsumption: 0 ClusterNbCPUActive: 0 ClusterConsOneCPU: 1 ClusterConsOneRAM: 0 ClusterConsMinOnePM: 5 ... Node PM0: type: ELearning-IaaS.PM ... Relationship PM_To_Cluster0: type: ELearning-IaaS.PM_To_Cluster constant: true source: PM0 target: Cluster0 12
  13. 13. Tooling Support 13
  14. 14. Tooling Support 14
  15. 15. Application to the Motivating Example ● Design of the SaaS layer ○ XaaS modeling language ● Interoperability ○ Eclipse Winery (TOSCA-based GUI) ● Runtime adaptation ○ Constraint-based decision-making architecture ○ Reconfiguration from current state c0 to another one c1 15
  16. 16. 16
  17. 17. Current Status & Related Work 17
  18. 18. Current Status ● Runtime (synchronization with the actual systems) ○ Implementation of a common adaptor interface for each target system ○ Currently implemented: Amazon EC2, OpenStack ● Scalability (vs. genericity) ○ Solutions found in < 10s for several hundreds of nodes (in a single model) ○ Alternative - hierarchizing the constraints to avoid combinatorial explosion ● Language V&V ○ The current version comes with support for basic syntactic validation ○ We plan to provide support to verify the correctness of the topologies and/or configuration ■ e.g., detect conflicting constraints ● Integration with Cloud standards ○ Possible proposition of XaaS language’s features to the TOSCA standardization group ■ e.g., support for (runtime) expressions/constraints 18
  19. 19. Related Work Genericity UI/ Language Interoperability Runtime Support APIs/DevOps ✅ ✅ Cloudify ✅ ✅ ✅ Brooklyn ✅ ✅ ~ 4CaaSt (Nguyen et al., 2011) ✅ ARTIST-CAML (Bergmayr et al., 2014) ✅ ✅ mOSAIC (Sandru et al., 2012) ✅ ~ Stratus ML (Hamdaqa and Tahvildari, 2015) ✅ ✅ CloudMF (Ferry et al., 2013, 2014) ✅ ~ PaaSage-CAML (Achilleos et al., 2015) ✅ ~ SRL (Domaschka et al., 2014) ~ ✅ ✅ Saloon (Quinton et al., 2016) ✅ ✅ ARCADIA (Gouvas et al., 2016) ✅ ✅ ~ Descartes (Kounev et al., 2016) ✅ ✅ MODAClouds (Pop et al., 2016) ✅ ✅ (Garcia-Galan et al., 2014) ✅ ✅ CoMe4ACloud ✅ ✅ ~ ~ 19
  20. 20. Final Remarks 20
  21. 21. Conclusions and Perspectives ● Contribution: an architecture for the autonomous runtime management of heterogeneous Cloud systems ○ Generic XaaS models that can possibly interoperate with standards (e.g., TOSCA) ○ Suitable interface, via a XaaS modeling language, to both Cloud experts and administrators ○ Constraint-based decision-making tool to automatically obtain system configurations respecting specified SLA contracts at runtime ● Perspectives: ○ Application our approach to other fields of Cloud Computing (e.g., Fog) ○ Machine Learning techniques to guide or assist the constraint specification process 21
  22. 22. Obrigado Thank you! Frederico Alvares frederico.alvares@easyvirt.com 22

×