Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Exoscale: Operating a public cloud

November 22, 2013

Exoscale: Operating a public cloud

This is the talk I gave at the CloudStack Collaboration Conference Europe 2013 held in Amsterdam.

It focuses on how we operate our Cloudstack based "Open Cloud" offering and an overview of the complete ecosystem we've built around it.



November 22, 2013

More Decks by exoscale

Other Decks in Technology


  1. Opera&ng  a  public  cloud   Loic  Lambiel   Head  of

  2. #whoami   !    Loic  Lambiel   – Email  :  [email protected]

          !    Passionate  sysadmin   !    I’ve  been  working  in  IT  for  over  a  decade,  mainly  as  a  consultant  in  the  system   area   !    Head  of  Opera&ons  @  exoscale   –   Responsible  for  the  overall  exoscale  plaIorm  &  product  opera&on  
  3. Our  Cloud  recipe   !    To  provide  efficient  public

     cloud  services,  we  need  :   !    A  cloud     –   Cloudstack  backed  of  course  !   !    A  team   –   Devops  of  course  !   !    Third  party  tools  ecosystem   –   Open  Source  of  course  !    
  4. Our  Cloudstack  based  cloud   !    Running  version  4.0.x

      !    Linux  KVM  hypervisor  (Ubuntu  based)   !    Local  storage  only,  no  clustering   – Keep  it  Simple,  scalable  and  fast   !    Basic  networking  mode   – Means  one  public  IP  per  VM,  No  VLANs   – Secured  by  security  groups,  AWS  style  
  5. Opera&ng  means  also  people     !    Team  must

     be  kept  small   – Team  growth  ra&o  !=  number  of  virtual  machines  hosted     !    Devops  doctrine  applied     !    Development  is  opera&ons  aware   – What  impact  my  code  has  on  produc&on  ?   !    Opera&ons  is  managed  by  development  principles  and  tools   – Revert  (git)   – Documented  in  line  and  in  commits  (avoid  rewrite  and  informa&on  loss)   – Accountable:  who  did  what    
  6. User  Management  console   Visibility  stack   Configura7on  management  system

      User  backend  stack   Our  Cloudstack  Ecoystem  
  7. None
  8. Exoscale  management  console   !    Homemade  management  console  

    !    Na&ve  cloudstack  UI  not  suitable  for  our  needs     !    Simple,  fast  &  efficient     !    Hook  the  cloudstack  API   !    “AWS  style  console”      
  9. “User  backend  stack”   !    Homemade  user  backend  modules

      !    Provide  user  database,  billing/chargeback,  &cke&ng  and  knowledge  base   !    Used  by  Cloudstack  for  user  authen&ca&on   !    Cloudstack  does  not  offer  any  na&ve  billing/chargeback  capability   !    Cloudstack  only  provide  usage  data  which  must  be  processed  for  billing  
  10. Cloudstack  usage  record  sample  (Json)  

  11. Configura&on  management,  why  ?     !    FALSE  :

     “It  is  only  infrastructure,  it  does  not  change”   !    Repe&&ve  tasks  are  boring  and  cost  &me   !    Small  devops  team   !    Adding  &  managing  more  and  more   – Quickly  if  required  !   !    Deploy,  maintain  &  enforce  the  same  configura&on  everywhere   !    Adjust  con&nuously    
  12. Therefore  we  need  “good  ci&zens”   !    A  machine

     should:   Automa&cally  deploy  itself  (Almost)   Find  its  iden&ty  seings  (name,  networks,...)   Install  the  necessary  packages  for  which  it  was  intended   Register  itself  to  all  tools   Live  along  its  peers  and  respect  regula&ons   Report  to  cityhall  if  anything  goes  wrong  
  13. Configura&on  management  :  Puppet   !    We  use  the

     well  known  open  source  configura&on  management  tool  Puppet   !    Exoscalepuppet  :     – 40+  modules   – Each  applica&on  got  it’s  module   – Between  10  to  100  commits  per  week  
  14. Monitoring  vs  Visibility   !    Monitoring  is  part  of

     visibility   – Tradi&onally:  service  up,  CPU,  RAM,  network  &  disk  I/O     !    Are  we  genera&ng  business  value  ?   – Need  more  insight  into  applica&on  behavior  (who  using  what,  ...)  
  15. Trends   !    If  it  moves,  graph  it  

    !    If  it  doesn't  move,  graph  it  in  case  it  starts  moving   !    If  it  breaks  once,  monitor  it     !    Ques&on,  adapt  and  modify  thresholds  con&nuously  
  16. What  is  different  in  the  cloud  ?   !  

     Distributed  systems   !    Lots  of  moving  parts   !    Scale   !    Easy  tools  to  quickly  assess  produc&on  status  required  
  17. Visibility  stack:  Logstash   !    Open  Source  Log  collector

      !    Collects  every  logs  on  the  machine   – Rsyslogd,  Cloudstack,  Nginx,  Load  balancer,  tomcat,  java  etc…   !    Configura&on  managed  by  puppet   !    Backed  with  Elas&c  search  cluster    
  18. Visibility  stack:  Elas&c  search  /  Kibana   !    Open

     Source  distributed  resIul  search  and  analy&cs  system   !    Distributed,  NoSQL   !    Data  indexing  is  done  thru  HTTP  PUT  method,  search  by  HTTP  GET   !    We  store  all  our  logs  in  a  central  ES  cluster   !    Logs  kept  only  24  hours  locally  on  the  server   !    Open  Source  Kibana  used  as  search  portal  
  19. None
  20. Visibility  stack:  Graphite   !    Open  Source  real-­‐&me  graphing

     system   !    Store  numeric  &me-­‐series  data   !    Render  graphs  of  this  data  on  demand   !    Web  Dashboard  available    
  21. None
  22. Visibility  stack:  Riemann   !    Open  Source  monitoring  system

      !    “passive”  monitoring,  Events  stream  processor   !    Good  for  monitoring  distributed  systems   !    Well-­‐suited  for  infrastructure  with  lot  of  moving  parts    
  23. Visibility  stack:  Collectd   !    Open  Source  Sta&s&cs  collector

     with  many  exis&ng  plugins   !    Plugin  may  be  a  script   !    Collectd  @  exoscale   – Metrics  sent  to  graphite   – Metrics  sent  to  Riemann   – Metrics  sent  to  custom  dashboard  apps   – SNMP  polling  
  24. Visibility  stack:  Command  and  control   !    Private  IRC

     server  &  bots  used  as  a  «  control  tower  »   !    Central  view  of  our  infrastrcture  :   !    Monitoring  alarms   !    All  git  commits   !    Ability  to  pilot  our  servers  thru  IRC  bots:     – Puppet  apply,  apt-­‐get,  service  restart  etc…   – No  need  to  log  on  server   – Changes  can  be  performed  on  a  group  of  servers  very  quickly  
  25. CI:  Jenkins   !    Jenkins  is  an  Open  Source

     Con&nuous  integra&on  server   !    Almost  every  of  our  apps  are  built  with  Jenkins   !    Applica&on  build  may  be  piloted  from  IRC   !    Linked  with  IRC  and  Git   !    We  build  cloudstack  with  jenkins  
  26. Management  thru  IRC  

  27. Visibility  stack:  Dashboards   !    Extensive  use  of  dashboards

     on  TVs   !    Graphs,  network  maps   !    Monitoring  alerts   !    Custom  Dashboard  applica&on  with  Cloudstack  metrics   – Custom  Collectd  python  scripts    
  28. Prac&cal  use  case   !    Add  a  node  to

     our  Web  portal  frontend  infrastructure  :   !    Allocate  IP/name   !    Define  machine  belonging  to  the  service  plaIorm  (by  a  fact)   !    “press  deploy”   !    Let  puppet  deploy  the  configura&on  and  applica&on  on  the  host  :   – Nginx   – Web  app   !    Let  puppet  reconfigure  load  balancing  to  add  this  node  in  the  farm   !    Watch  logs,  graph  and  traffic  to  this  new  host  in  real  &me  on  dashboards  
  29. Conclusion   !    “just”  installing  Cloudstack  wasn’t  enough  for

     us   !    We’ve  built  a  complete  ecosystem  around  Cloudstack   !    Massive  automa&on  is  the  key     !    Required  to  be  scalable  and  being  operated  by  small  a  team   !    Give  it  a  try  :  hsps://portal.exoscale.ch    
  30. Ques&ons  ?  

  31. References  and  More   !  Links:     – hsp://graphite.wikidot.com  

    – hsp://logstash.net   – hsp://Riemann.io   – hsp://collectd.org   – hsp://puppetlabs.com   – hsp://kibana.org/   – hsp://github.com/exoscale/   – hsp://cloudstackcollab.org/