Network Functions Virtualization and CloudStack

2,962 views

Published on

NFV promises to do to carrier networks what Cloud has done to enterprise computing. NFV has been a part of CloudStack in order to scale and perform effectively. This presentation gives an overview of how and why NFV is used in CloudStack. This was presented at the NFV and SDN Summit on March 20, 2014 in Paris

  • Be the first to comment

Network Functions Virtualization and CloudStack

  1. 1. Network  Func-on  Virtualiza-on   in  IAAS  Clouds       Chiradeep  Vi;al   @chiradeep   Commi;er,  Apache  CloudStack  Project    
  2. 2. Agenda •  Overview of Apache CloudStack •  How and Why of NFV in CloudStack •  Does NFV deliver on its promise?
  3. 3. Apache CloudStack is a •  scalable, •  multi-tenant, •  open source, •  purpose-built, •  cloud orchestration platform for •  delivering turnkey Infrastructure-as-a- Service clouds Apache CloudStack
  4. 4. •  Several  hundred  produc-on  clouds   •  Largest  clouds  in  10’s  of  thousands  of   hypervisors   •  Sectors:   • Hos-ng   • Enterprise  &  Educa-on   • Service  Providers   • Web  2.0   Commercial  and  Open  Source  Success  
  5. 5. Most  Ac-vely  Developed  Apache   Project     Source:  h;p://www.ohloh.net/orgs/apache  retrieved  3/11/2014  
  6. 6. Apache  CloudStack  State  Of  Union  –   March  2014   •  Apache  Commi;ers  –  74     •  Total  Apache  Contributors  All-­‐ Time  -­‐    799   •  Individual  Companies  involved   in  ACS  -­‐  ~284  (by  unique   domain  much  lower  than  actual   based  on  Gmail  and  other  non-­‐ company  addresses)     •  Average  Monthly  contributors   >150   •  Lines  of  Code  -­‐      1,521,161   •  Total  commits  –  22,169   •  Years  of  Effort  ( COCOMO  Model)  –  434  years   Stats  through  2/1/2014   Companies  
  7. 7. How can you build your cloud? Servers Open Source Xen Hypervisor Amazon Orchestration Software AWS API (EC2, S3, …) Amazon eCommerce Platform Hypervisor CloudStack Orchestration Software Optional Portal CloudStack or AWS API StorageNetwork
  8. 8. Networking  Principles  in  Apache   CloudStack   •  Flexibility   –  Allow  various  combina-ons  of  technology  for  L2-­‐L7   network  services   –  Allow  different  providers  (vendors)  for  the  same   network  service  in  a  Cloud  POP   •  Pluggability   –  Plugins  allow  vendors  to  drop  in  vendor-­‐specific   configura-on  and  lifecycle  management  code   •  Service  scalability   –  Scale  out  using  virtual  appliances  when  possible   –  Scale  up  using  hardware  appliances  if  needed  
  9. 9. Network Flexibility Network Services •  L2 connectivity •  IPAM •  DNS •  Routing •  ACL •  Firewall •  NAT •  VPN •  LB •  IDS •  IPS
  10. 10. Network Flexibility Network Services •  L2 connectivity •  IPAM •  DNS •  Routing •  ACL •  Firewall •  NAT •  VPN •  LB •  IDS •  IPS Service Providers ü  Virtual appliances ü  Hardware firewalls ü  LB appliances ü  SDN controllers ü  IDS /IPS appliances ü  VRF ü  Hypervisor
  11. 11. Network Flexibility Network Services •  L2 connectivity •  IPAM •  DNS •  Routing •  ACL •  Firewall •  NAT •  VPN •  LB •  IDS •  IPS Network Isolation •  No isolation •  VLAN isolation •  Overlays •  L3 isolation Service Providers ü  Virtual appliances ü  Hardware firewalls ü  LB appliances ü  SDN controllers ü  IDS /IPS appliances ü  VRF ü  Hypervisor
  12. 12. NFV in Apache CloudStack •  Built-in VNFs for IAAS network services –  Out of the box experience – no additional installation –  Lifecycle managed by CloudStack –  Debian 7.0 hardened appliance •  Vendor VNFs also supported –  Pooled model, no explicit instantiation –  License and initial configuration resist automation –  Citrix Netscaler ADC , Cisco ASA1000v firewall, Cisco Nexus 1000v •  Software defined networking –  Built-in GRE/VxLAN controller –  Plugins for NSX, Contrail, OpenDaylight, etc
  13. 13. Computing Hardware Storage Hardware Network Hardware Hardware resources Virtualisation Layer Virtualised Infrastructure Manager(s) VNF Manager(s) VNF 2 OrchestratorOSS/BSS NFVI VNF 3VNF 1 Execution reference points Main NFV reference pointsOther reference points Virtual Computing Virtual Storage Virtual Network NFV Management and Orchestration EMS 2 EMS 3EMS 1 Service, VNF and Infrastructure Description Or-Vi Or-Vnfm Vi-Vnfm Os-Ma Se-Ma Ve-Vnfm Nf-Vi Vn-Nf Vl-Ha ETSI  NFV  Func-onal  Blocks  
  14. 14. Computing Hardware Storage Hardware Network Hardware Hardware resources Virtualisation Layer Virtualised Infrastructure Manager(s) VNF Manager(s) VNF 2 OrchestratorOSS/BSS NFVI VNF 3VNF 1 Execution reference points Main NFV reference pointsOther reference points Virtual Computing Virtual Storage Virtual Network NFV Management and Orchestration EMS 2 EMS 3EMS 1 Service, VNF and Infrastructure Description Or-Vi Or-Vnfm Vi-Vnfm Os-Ma Se-Ma Ve-Vnfm Nf-Vi Vn-Nf Vl-Ha CloudStack  NFV  func-ons  
  15. 15. NFV  func-ons  in  CloudStack   •  Similar  to  ETSI,  but  not  iden-cal   –  VirtualNetworkApplianceManager  =  VNF  Manager   –  NetworkServiceManager    =  NFV  Orchestrator   –  VirtualRouter  =  VNF   •  Purpose-­‐built  for  IAAS  today   – Can  be  generalized   – Need  external  APIs  (currently  internal)    
  16. 16. Example:  VNF  Lifecycle  Management   GREKey2724 DB VM 1! Web VM 1! Web VM 3! Web VM 2! GREKey1001 App VM 1! App VM 2! GREKey398 ! Virtual Router! Internet! Customer! Premises! IPSec VPN! Private Gateway!Loadbalancer   (HW  or   Virtual)   Network Services! •  IPAM! •  DNS! •  LB [intra]! •  S-2-S VPN! •  Static Routes! •  ACLs! •  NAT, PF! •  FW [ingress & egress]! LB VM ! Automated  Lifecycle:  Instan-a-on,  HA,  scaling upgrade,  decommission  
  17. 17. Example:  VNF  Lifecycle  Management   •  IAAS  API  calls  result  in  VNF  instan-a-on  and   destruc-on   – Create  a  subnet  with  NAT,  firewall  and  LB  service   •  Results  in  instan-a-on  of  virtual  router  VM  and  LB  VM   – Remove  LB  service   •  Results  in  LB  VM  gemng  garbage  collected   – Destroy  subnet   •  Results  in  virtual  router  gemng  destroyed  /  garbage   collected    
  18. 18. Example:  Network  Service  onboarding  
  19. 19. The  NFV  Promise   •  Scalability   •  Large-­‐scale  network  automa-on   •  Cost  reduc-on   •  Rate  of  innova-on   •  Disaster  recovery  
  20. 20. Scaling  with  CloudStack  NFV   •  Scale  out  models   – Flexible  mapping  of  VNF  instances  to  unit  of  scaling   •  Per  N  tenant,  per  N  network,  per  service  instance,  per  N   applica-on,  per  POP   •  Scaling  model  can  be  tuned  on  the  fly   – Instan-ate  on  demand,  or  pool-­‐based   – VNFs  are  stateless  and  disposable   •  Scale  up  model   – Configurable  memory,  CPU,  network  and  storage   capacity  for  a  VNF.  
  21. 21. Scaling:  Caveat   •  Effec-ve  scaling  requires  appropriate  network   topology   – Designed  for  predominantly  east-­‐west  traffic   – Firewall,  ACL  provided  at  the  VM  or  hypervisor   level   – ECMP  for  increased  bandwidth  /  availability   •  VNF  need  to  be  stateless     – Recreate  a  VNF  by  re-­‐impor-ng  config.   – Applica-ons  should  tolerate  VNF  scaling  ac-ons   •  Scale  up  limited  by  hypervisor  overhead  
  22. 22. NFV  Promise:  Network  Automa-on   •  Everything  in  CloudStack  is     – API-­‐driven   – Self-­‐service   •  No  chance  of  misconfigura-on   •  Configura-on  changes  are  atomic  across  VNF  
  23. 23. Network  Automa-on:  Caveats   •  VNF  are  unnecessarily  hard  to  configure   – Usually  have  no  APIs   – Varying  models  for  reconfigura-on:   •  Impera-ve  (e.g.,  iptables)   •  Configura-on  file  based  (usually  not  hitless)   •  CLI  screen  scrape   •  Netconf/YANG  etc   – Rollback  is  hard   •  Out-­‐of-­‐band  changes  are  hard  to  reconcile   – Network  admins  s-ll  have  remote  access  to  VNF!  
  24. 24. Cost  reduc-on   •  Capex     – Replace  proprietary  firewalls,  routers,  NAT,  LB,   VPN  with  (free)  Linux  appliances   •  Opex   – Instan-ate  complex  network  topologies  and  VNF   forwarding  graphs  in  seconds   •  Development   – Reuse  and  improve  open  source    
  25. 25. Cost  reduc-on:  Caveats   •  None  
  26. 26. Rate  of  innova-on   •  Open  source  is  key   – Knowledge  is  just  a  Google  search  away   •  Closed  source  VNFs  are  harder  to  integrate   2010  2009   2011   2012   2013   2014   #  of  core  dev   1   4  
  27. 27. Rate  of  Innova-on  :  Caveats   •  Development  model   – Solving  problems  or  marke-ng  claims?   •  OSS  License  minefield   •  Niche  needs  may  not  be  met  in  OSS   •  Standardiza-on  /  Conven-ons  for  VNF   ini-aliza-on,  scaling,  metrics,  etc  are  needed  
  28. 28. Rate  of  Innova-on:  caveat   •  Avoid  NIH     •  Focus  on  customer  value  not  vendor  value   •  Clear  vision  required   •  Requires  fast  itera-on  and  frequent  releases  
  29. 29. Disaster  Recovery   •  Advantage:  Very  low  MTTR   •  Keys:   – Stateless  VNF   – Automated  VNF  configura-on   – Awareness  of  shared  fate  (rack  /  POP)   – Immutable  object  store  with  an  API  (e.g.,  S3)  
  30. 30. DR:  caveats   •  Focus  on  state   – Where  it  is  stored,  backed  up  and  recovered  from   – Decouple  it  from  VNF  
  31. 31. Futures   •  CloudStack  liaison  with  ETSI  NFV  MANO  WG   •  Iden-fy  gaps   •  Proof  of  concepts  (POC)  with  non-­‐IAAS   workloads  

×