Cloud Intrusion and Autonomic Management in Autonomic Cloud Computing
Experimental,Analysis,on,Autonomic, Strategies,for,Cloud...
Transcript of Experimental,Analysis,on,Autonomic, Strategies,for,Cloud...
Experimental Analysis on Autonomic Strategies for Cloud Elas8city
by Simon Dupont
Jonathan Lejeune Frederico Alvares Thomas Ledoux
Summarized by: Abhishek Roy
Introduc8on • Cloud Elas8city – the degree to which a system is able to adapt to workload changes by provisioning and de-‐provisioning resources in an autonomic manner, such that at each point in 8me the available resources match the current demand as closely as possible
• IaaS provides infrastructure – Dynamically add or remove VMs – Human interven8on is imprac8cal – Does not have rapid scaling
• SaaS depends on IaaS to provide service with a guarantee to meet SLA
Mo8va8on
• IaaS scaling difficul8es – Resources are limited – Ini8a8on 8me may be too long – Par8al usage waste problem
• SaaS scaling advantages – Negligible overhead of soPware reconfigura8on – Different versions of the soPware may be deployed with different consump8on of resources
– An extra elas8city layer over IaaS
Infrastructure Elas8city
• Horizontal Scaling • Ver8cal Scaling • Limita8ons – Resources are limited – Ini8a8on 8me is significant
– Pricing is per instance-‐hour • use-‐as-‐you-‐pay policy
SoPware Elas8city in the Cloud
• SoPware Horizontal Scaling (HSso%) • SoPware Ver8cal Scaling (VSso%) • Benefits – Alleviate the use of infrastructure resources – Improve responsiveness of scaling – Improve expression capability of elas8city
An Illustra8ve Example
Proposed Elas8city Strategies
Proposed Elas8city Strategies
• Resources Model: managed system – n-‐8er we applica8on
• Monitor: events – collect and aggregate mul8ple sensor values over 8me
– Basic and Complex Event
Proposed Elas8city Strategies
• Execute: predefined ac8ons – using actuators, offers reconfigura8on capabili8es to the system
– Basic and Complex ac8ons
– CA provides a set of predefined ac8ons
Proposed Elas8city Strategies
• Reconfigura8on Decision – Tac8cs Filter – Event ac8on mapping – Constraint Filter – Context – Preference Filter – Strategy
Experimental SeWngs • Applica8on configura8on
– two 8ers: load balancing and business 8er – lbt uses Nginx 1.6.2 to distribute load across mul8ple workers of bt – bt uses Java applica8on and Je\y – lbt has soPware elas8city capability
• Infrastructure configura8on – Grid‘5000 Nancy: 7 PMs-‐ 2.8 GHz Xeon, 15 GB RAM, 20 Gbit/s
Ethernet switch – Openstack Grizzly 1.0.0: occupies one en8re PM
• Autonomic Manager – Runs on cloud controller machine – Monitors response 8mes by aggrega8ng logs – “High response 8me” (400 ms) and “Low response 8me” (20 ms)
event pa\erns
Experimental Evalua8on • Experiment 1
– SOinfra, SIinfra • Experiment 2
– SUso%, SDso%
• Experiment 3 – (SOinfra || SDso%); SUso% and
SIinfra • Workload scenarios
– First phase: medium inc (0.4 r/s2) 10 mins, dec 3 min
– Second phase: half inc 10 mins, dec 3 min
– Third phase: 3 peak (1.6 r/s2) load at regular interval
– lasts about 40 minutes
• Metrices – Infrastructure size: running
VMs – SoPware offering: 5 values – Number of failed requests – Average response 8me
Results
Results
Results
Related Work
• Cloud Elas8city Management – Predefined auto-‐scaling rules: Amazon, MS Azure, etc – Queueing Theory, Reinforcement learning, Game Theory can be used to do effec8ve capacity planning
– Technical limita8ons, conceptual limita8ons – Deals with only infrastructure layer
• Cross-‐layer Elas8city Management – Architecture based self-‐adapta8on: Rainbow – Rainbow maximizes QoS and minimizes infrastructure cost – This paper proposed a catalogue of reconfigura8on strategies driven by Cloud administrators preferences
Conclusion
• Pros – Highlighted a very important shortcoming of the cloud elas8city model and proposed a solu8on to it
– The soPware elas8city model is very similar to the hardware elas8city model: reusing exis8ng results
– Experimental test bed was a real system • Cons – Although they iden8fied 2 dimension of soPware scaling, they did not experiment with the horizontal dimension
– I would expect to see a plot with average performances of their schemes over a long period of workload