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