soCloud : une plateforme multi-nuages distribuée pour la conception, le déploiement et l'exécution d'applications distribuées à large échelle
86
0
0
Texte intégral
(2) Cloud computing in nutshell Virtualization. On-demand. Pay-per-use. Elasticity. 2.
(3) Context and motivation Application fil rouge Compute%. View% Storage%. Developer. Go to the Cloud ! 3.
(4) So many problems ! Vendor Lock-in. Geo-location Cloud-specific services Failures 4.
(5) solution: Multi-Cloud Do not put all your eggs in one basket. Multi-Cloud Why not applying this precept of caution for cloud computing? 5.
(6) What is Multi-Cloud ? Definition •. Multi-Cloud Computing ✤ using multiple cloud providers ✤ independent ✤ no agreement between providers. 6.
(7) Multi-Cloud Context and motivation. 74%. Enterprises have a Multi-Cloud strategies 7.
(8) Context and motivation Towards Multi-Cloud Computing. Multi-cloud is supposed to be the solution but… 8.
(9) Outline 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 9.
(10) Challenges Multi-cloud Portability Multi-cloud Provisioning Multi-cloud Elasticity Multi-cloud High-Availability 10.
(11) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. Multi-cloud High availability. Write once, deploy anywhere " without any modification App. App. Your application/data App. App. App. 11.
(12) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. Multi-cloud High availability. Resources App Deployment 12.
(13) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. Provisioning. Resources Provisioning. Provisioning. 13. Multi-cloud High availability.
(14) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. App deployment. 14. Multi-cloud High availability.
(15) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. 15. Multi-cloud High availability.
(16) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. Multi-cloud High availability. HA. 16.
(17) Challenges Multi-cloud Portability. Multi-cloud Provisioning. Multi-cloud Elasticity. Multi-cloud High availability. HA. HA. HA. 17.
(18) Outline. 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 18.
(19) State of the art Approach. Layer. Multi-Cloud Portability. Multi-Cloud Provisioning. moSAIC. PaaS. +. +. +. -. STRATOS. IaaS. -. +. +. -. MODAClouds. PaaS. +. -. -. +. CompatibleOne. IaaS. +. +. -. +. Cloud4SOA. PaaS. +. +. -. -. soCloud. PaaS. +. +. +. +. 19. Multi-Cloud Multi-Cloud Elasticity High-Availability.
(20) State of the art Approach. Layer. Multi-Cloud Portability. Multi-Cloud Provisioning. moSAIC. PaaS. +. +. +. -. STRATOS. IaaS. -. +. +. -. MODAClouds. PaaS. +. -. -. +. CompatibleOne. IaaS. +. +. -. +. Cloud4SOA. PaaS. +. +. -. -. soCloud. PaaS. +. +. +. +. 20. Multi-Cloud Multi-Cloud Elasticity High-Availability.
(21) State of the art Approach. Layer. Multi-Cloud Portability. Multi-Cloud Provisioning. moSAIC. PaaS. +. +. +. -. STRATOS. IaaS. -. +. +. -. MODAClouds. PaaS. +. -. -. +. CompatibleOne. IaaS. +. +. -. +. Cloud4SOA. PaaS. +. +. -. -. soCloud. PaaS. +. +. ++. +. 21. Multi-Cloud Multi-Cloud Elasticity High-Availability.
(22) State of the art Approach. Layer. Multi-Cloud Portability. Multi-Cloud Provisioning. moSAIC. PaaS. +. +. +. -. STRATOS. IaaS. -. +. +. -. MODAClouds. PaaS. +. -. -. +. CompatibleOne. IaaS. +. +. -. +. Cloud4SOA. PaaS. +. +. -. -. soCloud. PaaS. ++. ++. ++. ++. 22. Multi-Cloud Multi-Cloud Elasticity High-Availability.
(23) Outline. 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 23.
(24) soCloud Overview EC2 soCloud" Platform. Azure. distributed applications Developer. Heroku. soCloud Model. 24.
(25) Outline 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 25.
(26) Objectives. ‘’Provides a model to design a distributed applications in a simple and concise manner for a Multi-Cloud environment’’. 26.
(27) Features Identify requirements for engineering distributed application for the Multi-Cloud environments. Multi-Cloud" Portability. Multi-Cloud" Provisioning. Abstraction" Standard" Structure. Placement" Resources" Granularity. Multi-Cloud" Elasticity. Multi-Cloud" High-availability. Failures" Diversity. DSL" Simple 27.
(28) soCloud Model. Extended SCA Model. 28.
(29) SCA •. Service Component Architecture (SCA). ✤ Set of OASIS specifications. ✤ Distributed applications. ✤ Using SOA Compute View. Storage. Legend Composite Service Property. Component. SCA Contribution Reference. ZIP File. Wire. 29.
(30) soCloud Model based on SCA Annota&on' Annota/on( +name& +name( +value& +value(. Property( +name( +mustSupply( 0..*( +many( +value( +element(. Implementa)on.Contribu)on1 Implementa/on.Contribu/on( +name& +name(. 0..1( Implementa/on( +requires( +policySets(. Implementa/on.Java( +class( Implementa/on.C++( +class(. 1..1(. 0..*(. Service( +name(. Implementa/on.BPEL( +process( 0..*(. 0..*(. 0..*(. 1..*(. PolicyIntent( requires(. 0..*( PolicySet(. 0..*( 0..*(. 1..*(. policySets( Component( +name( +autowire(. 0..*( requires(. 0..*( 0..*( 0..*(. policySets(. 0..*(. target(. Reference( policySets( +name( requires( +mul5plicity( 0..*( +wireByImpl(. requires(. Binding( 1..*( +uri( +name( Opera/on( +name( +requires( +policySets( 0..*( 0..*( Interface( +conversa5onal( 0..1(. +name( +autowire( +targetNamespace( +local(. Extension 2. Extension 1. 0..1( CallBack( +requires( 1..*( +policySets(. Interface.java( +callBackInterface( +interface( Interface.WSDL( +callBackInterface( +interface(. 0..*(. Composite( ConstrainingType(. Implementa/on.Composite( +name(. Wire( +source( 0..*( +target(. 30.
(31) soCloud Model based on SCA Why extend SCA model ? Implementa)on.Contribu)on1 +name&. Extension 1. Annota&on' +name& +value&. Extension 2 31.
(32) soCloud Model: implementation Implementa)on.Contribu)on1 +name& Extension 1 •. Provides high level conceptual view to a component. •. Allows the deployment of the component as execution unit. •. Structured components of distributed applications 32. component.
(33) soCloud Model: annotations @. Annota&on' +name& +value&. component. •. Allowing to associate non-functional requirements to a component. •. The SCA model does not allow us to take into account these non-functional requirements. Extension 2 33.
(34) soCloud Model: annotations Annotation +name +value. Placement " annotation. location. closer. Execution " annotation. vm. database. service 34. Availability " annotation. replication. Elasticity " annotation. elasticity.
(35) soCloud Model: annotations Annotation +name +value. Placement " annotation. location. closer. Execution " annotation. vm. database. service 35. Availability" annotation. Elasticity " annotation. replication. elasticity.
(36) soCloud Model: annotations Placement " annotation. location. closer. 1@location = ‘value’" 2 @closer = ‘value’. 36.
(37) soCloud Model: annotations 1@location = ‘value’ Clouds provider. Any. Amazon EC2 Windows Azure. Europe Oceania. (1). South Africa New york California Singapour Amazon Irland Irland France Australia. (2). Africa America Asia. Paris Roubaix. 37. (3).
(38) soCloud Model: annotations 2 @closer = ‘value’. @closer =‘C2’ C1. C2 Latency. 38.
(39) soCloud Model: annotations Annotation +name +value. Placement " annotation. location. closer. Execution " annotation. vm. database. service 39. Availability " annotation. replication. Elasticity " annotation. elasticity.
(40) soCloud Model: annotations Execution " annotation. 1 @vm = ‘type_vm’" 2 @database = ‘name -> version’" 3 @service = ‘name -> version’ Optional. vm. database. service. Example 1 @vm = ‘micro’" 2 @database = ‘MySQL’" 3 @service = ‘IronMQ -> 2.8.9’ 40.
(41) soCloud Model: annotations Annotation +name +value. Placement " annotation. location. closer. Execution " annotation. vm. database. service 41. Availability " annotation. replication. Elasticity " annotation. elasticity.
(42) soCloud Model: annotations 1 @replication = ‘number’. Availability " annotation. replication. Example. @replication=5 LB. C become. 42. C.
(43) soCloud Model: annotations Annotation +name +value. Placement " annotation. location. closer. Execution " annotation. vm. database. service 43. Availability " annotation. replication. Elasticity " annotation. elasticity.
(44) soCloud Model: annotations 1 @elasticity = ‘description’ Elasticity " annotation. C scale out. scale in. elasticity. C. A DSL for describing elasticity 44.
(45) soCloud Model: elasticity language Event Action Condition. scaling up when ( " average (cpuUsage,120s) > 80%" ) minimize availability when (" totalCost(costCompute,24 h) > 900 )" ) Elasticity is expressed on the Resources, Cost, Quality 45.
(46) soCloud Model: elasticity language Trigger. scaling in 5 at ( 20:00 Friday). 46.
(47) soCloud Model: annotations 3-Tiers Application @closer=‘’Storage ‘’" @vm=‘’xlarge->Ubuntu‘’. @elasticity=‘’Scaling in " When ( totalCost(computeCost, 24 h) > 900 200 )’’. Compute @database=‘’MySQL’’ " @location=‘’France’’" @location=‘’France‘’. ". View. Storage. 47.
(48) Summary We show how we use annotation to describe non-functional properties and manage each component as unit of execution • New language is proposed to effectively express the elasticity •. • Paraiso F, Merle P and Seinturier L : soCloud : A service- oriented component-based PaaS for managing portability, provisioning, elasticity et high availability across multiple clouds. Springer Computing Journal (Submitted)! • Haderer N, Paraiso F, Ribeiro C, Merle P, Rouvoy R and Seinturier L : A Cloud-based Infrastructure for Crowd-sourcing Data from Mobile Devices. Springer Book (To appear) 48.
(49) Outline 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 49.
(50) soCloud Platform. •. •. The expectations in term of execution support for distributed applications built with soCloud Model are differents We need to provide a Platform that manages: ✤ Multi-Cloud environments ✤ Distributed applications in Multi-Cloud environments. 50.
(51) soCloud Platform: concept We need to build Multi-Cloud Platform that: •. react to load. —> Scalable. •. react to event. —> Event-Driven. •. react to failure. —> Fault-Tolerance. •. react to change. —> Responsive. •. self management —> Autonomic is flexible —> Component-based. •. Reactive, flexible and self management platform. 51.
(52) soCloud Platform •. soCloud Platform is a distributed component-based PaaS for managing ✤ Portability ✤ Provisioning ✤ Elasticity ✤ High-availability. Components 52.
(53) soCloud platform high level view. User. soCloud agent. soCloud " master. …. soCloud applications. 53.
(54) soCloud Platform: Multi-Cloud centric Architecture Trend in the soCloud Platform Architecture single Cloud centric Architecture. Multi-Cloud centric Architecture. soCloud master. soCloud master. soCloud master. soCloud agent. soCloud agent. 54. soCloud agent. soCloud agent.
(55) soCloud Platform detail view soCloud master. Load Balancer. Service " Deployer. Controller. Constraint " Validator. Workload " Manager. Node Provisioning PaaS Deployment SaaS Deployment. Monitoring. soCloud agent 55.
(56) soCloud Platform: Fault Tolerance Let it Crash Application level. Platform level. Replication in different clouds. Replication in different clouds. 56.
(57) soCloud Platform: Fault Tolerance To achieve this 1. Transparency is the ultimate goal [Waldo et. al] ". 2. Automatic component and applications replication [Waldo et. al] ". 3. All replications are equal and deterministic [Waldo et. al]. [Waldo et. al]-Classic paper: A Note On Distributed Computing. 57.
(58) soCloud Platform: Replication features •. A cluster of N servers distributed across several Clouds" ". •. Any (exactly one) component can be leader" ". •. Active replication by the leader" ". •. Consensus election of the leader ". •. Automatic failover" ". •. Automatic recovery 58.
(59) soCloud Platform: deployment stack. master. SCA container Servlet container. agent. IaaS Java runtime. soCloud. Linux/OS Resources. 59.
(60) soCloud Platform: deployment stack. master SCA container. agent. PaaS. soCloud. 60. Servlet container.
(61) Summary • •. Runtime support for managing Multi-Cloud portability, provisioning, elasticity and high-availability Reactive Platform. • PARAISO Fawaz et.al : A federated multi-cloud PaaS infrastructure. In IEEE 5th International Conference on Cloud Computing (CLOUD), pages 392–399., Hawaii IEEE, 2012." • PARAISO Fawaz et al.: Managing elasticity across multiple cloud providers. In Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds, pages 53–60. ACM, 2013.. 61.
(62) Outline 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 62.
(63) Validation. soCloud Model soCloud Platform 63.
(64) Validation: soCloud Model Modeling of three concrete applications using the soCloud Model. 1. APISENSE application 2. DiCEPE application 3. P2P Monitoring application 64.
(65) Validation: soCloud Model 1. APISENSE application. [Nicolas Haderer]. Create task. APISENSE' Central(Node( Subscribe task. Send data. Sensing'Node' Send data. Sensing'Node'. Subscribe task. Publish task. Publish task. Reward. Download sensing task. store data. Send data Send data. 65. Sensing'Storage'.
(66) Validation: soCloud Model • •. Geo-location ✤ Paris Unpredictable growth of smartphones. •. Availability despite failures. •. Cost control. 66.
(67) Validation: soCloud Model <composite name="Application-APISENSE">. <component name="SensingNode"> . <implementation.contribution contribution="sensingnode.zip"/> . <reference name="compute" target="CentralNode/compute"/> . <reference name="storage" target="SensingStorage/storage"/> . <annotation name="location">Paris</annotation> . <annotation name="replication">2</annotation> . <annotation name="elasticity"> . scaling in when (totalCost(computeCost, 24h) > 1000) . . </annotation> . . </component> . </composite> 67.
(68) Summary •. The soCloud Model has enabled us to build an App for collecting data from smartphones, an App to integrate heterogenous CEP Engines and make Big Data, and finally a P2P distributed App. • PARAISO Fawaz et.al : A federated multi-cloud PaaS infrastructure. In IEEE 5th International Conference on Cloud Computing (CLOUD), pages 392–399., Hawaii IEEE, 2012." • PARAISO Fawaz et. al.: A Middleware Platform to Federate Complex Event Processing. In Sixteenth IEEE International EDOC Conference, pages 113–122, Beijing, China, septembre 2012. Springer.. 68.
(69) Validation: soCloud Platform 1. Portability 2. High-availability 3. Elasticity 4. Overhead introduced by soCloud. 69.
(70) Validation: soCloud Platform. Portability. 70.
(71) Validation: soCloud Platform Deployed on. 10 Clouds IaaS and PaaS 71.
(72) Validation: soCloud Platform. High-availability. 72.
(73) Validation: soCloud Platform. Availability =. MTBF*. MTBF + MTTR**. MTBF* = Mean Time Between Failure MTTR** = Mean Time To Recover [Marcus et. al.] : Blueprints for High availability 73. [Marcus et. al.].
(74) Validation: soCloud Platform. MTTR* (Hour). MTTR (Minute). Ratio. soCloud. 0.06 Hour. 3.6 Minutes. -. Public clouds [IWGCR]. 7.5 Hours. 450 Minutes. 125. MTTR* = Mean Time To Recover [IWGCR] = International Working Group on Cloud Computing Resiliency. http://iwgcr.org. 74.
(75) Validation: soCloud Platform If it is assumed that a failure occurs once per year MTBF = 8760 Hours Availability soCloud. 8760 = 99.999% 8760 + 0.06. Public clouds. 8760 = 99.914% 8760 + 7.5. 75.
(76) Validation: soCloud Platform. Elasticity. 76.
(77) Flash crowd effect 3-Tiers application was deployed on ten cloud providers 60000". Phase 1. Phase 2. Number%of%requests%. 50000". 40000". 30000". 20000". 10000". 0" 1". 11". 21". 31". 41". 51". 61". 71". 81". 91". 101". 111". 121". 131". Time%(slot"of"10"seconds)% (a)". 141". 151". 161". 171". Total Number of Request = 3020000 77. 181". 191".
(78) Flash crowd effect without soCloud elasticity Number'of'failed'requests'. 4500" 4000" 3500" 3000" 2500" 2000" 1500" 1000" 500" 0" 0". 20". 40". 60". 80". 100". 120". 140". Time'(slot"of"10"seconds)'. 160". 180". 1.3% of requests are failed that correspond to 34039 Response Time = 65.90 s 78. 200".
(79) Flash crowd effect with soCloud elasticity 70". Response'(me'(s)'. 60". Applica(on'replica(on'. 50". Balance'load'. 40" 30" 20" 10" 0" 1". 11". 21". 31". 41". 51". 61". 71". 81". 91". 101". 111". 121". 131". Time'(slot"of"10"seconds)'. 141". 151". 161". 171". 181". 191". No request has failed Without soCloud elasticity, the Response Time = 65.90 s Response Time = 37.3 s Phase 1. Response Time = 23.38 s Phase 2 79.
(80) Overhead introduced by soCloud APP APP. Implementation. Execution time. Overhead introduced by soCloud. (Application + FraSCAti). 10.85 sec. -. (Application + FraSCAti + soCloud). 11,10 sec. 2.3%. 80.
(81) Overhead introduced by soCloud Implementation. Execution time. Overhead introduced by soCloud. (Application + FraSCati). 10.85 sec. -. (Application + FraSCati + soCloud). 11,10 sec. 2.3%. The benefit provided by the soCloud Platform outweighs the difference in the execution time 81.
(82) Summary •. •. Reactivity face: ✤ Failures (High-availability) ✤ Flash crowd effect (Elasticity) Negligible Overhead introduced.. 82.
(83) Outline 1.Context and motivation. 2.Challenges. 3.State of the art. 4.Contributions. 4.1.soCloud Model. 4.2.soCloud Platform. 5.Validation. 6.Conclusion & Perspectives 83.
(84) Conclusion soCloud Model • • •. We use annotations to express non-functional requirements. New language is proposed to effectively express the elasticity. The soCloud Model is illustrated on three distributed applications deployed in Multi-Cloud environments. soCloud Platform. • • •. Multi-Cloud PaaS for deploying, executing and managing distributed application. It was deployed on ten IaaS/PaaS clouds providers. soCloud Platform is capable of providing Multi-Cloud high-availability and elasticity to applications deployed on it. 84.
(85) Perspectives Short-term further work • •. The high-availability management despite software bugs. The elasticity management using reinforcement learning. Further Research Directions. • • •. Security for Multi-Cloud. Sharing state between replicates. Take into account changes of the underlying platforms.. 85.
(86) Thank you !!! • PARAISO Fawaz, HADERER Nicolas, MERLE Philippe, ROUVOY Romain and SEINTURIER Lionel : A federated multi-cloud PaaS infrastructure. In IEEE 5th International Conference on Cloud Computing (CLOUD), pages 392–399. IEEE, 2012." • PARAISO Fawaz, HERMOSILLO Gabriel, ROUVOY Romain, MERLE Philippe, SEINTURIER Lionel : A Middleware Platform to Federate Complex Event Processing. In Sixteenth IEEE International EDOC Conference, pages 113–122, Beijing, China, septembre 2012. Springer. " • PARAISO Fawaz, MERLE Philippe and SEINTURIER Lionel : Managing elasticity across multiple cloud providers. In Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds, pages 53–60. ACM, 2013." • PARAISO Fawaz, MERLE Philippe and SEINTURIER Lionel : soCloud : A service- oriented component-based PaaS for managing portability, provisioning, elasticity et high availability across multiple clouds. Springer Computing Journal (To appear)!. • HADERER Nicolas, PARAISO Fawaz, RIBEIRO Christophe, MERLE Philippe, ROUVOY Romain and SEINTURIER Lionel : A Cloud-based Infrastructure for Crowd-sourcing Data from Mobile Devices. Springer Review (To appear). 86.
(87)
Documents relatifs
In our extension, called Fractal Aspect Component (FAC for short), we introduce the notions of aspect component, aspect binding and aspect domain to the component model itself and
MADONA consists of the follow- ing phases: (a) Requirement elicitation; (b) Application components discovery; (c) Integration of new compo- nents if necessary; (d) Composition
h-ubu is based on the notion of components with provided and required services, and on a hub, a specific component in charge with runtime components bindings.. 3.1
La présente étude a montré que, pour un niveau donné d’apport énergétique, l’impact carbone alimentaire journalier a tendance à être d’autant plus élevé que la
obstacle avoidance controller in figures (Fig. 6), it is noticed that the Lyapunov function of the proposed architecture of control converges faster than the architecture with
Une étude a analysé la progression à 5 ans de la maladie chez 876 patients inclus dans l’étude AREDS aux stades 3 ou 4, selon que les patients absor- baient ou non des
apr` es, nous illustrons le caract` ere adaptatif de l’approche SIRds propos´ ee. lorsque les t premiers blocs sont disponibles), nous estimons la. direction EDR avec les
