Samuel Bercovici - lbaaS for Havana

3,544 views
3,271 views

Published on

Samuel Bercovici's slide deck from his presentation at OpenStack Israel May 2013

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,544
On SlideShare
0
From Embeds
0
Number of Embeds
490
Actions
Shares
0
Downloads
0
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

Samuel Bercovici - lbaaS for Havana

  1. 1. LBaaS for HavanaSamuel Bercovici - Radware
  2. 2. Why should I care?• Load balancing as a services (LBaaS) areexpected from cloud services targeting criticalapplications.• Load balancers are crucial part of– Availability– Scalability– Manageability
  3. 3. Radware Involvement inOpenStack• Radware Joined OpenStack on Dec 2011• Planning of LBaaS for Grizzly and Havana• Contributor to the Networking/LBaaSprojectSlide 3
  4. 4. Agenda• LBaaS History• LBaaS in Grizzly• Focus Areas for Havana– Multivendor Support– Tenant API– Network Topologies
  5. 5. LBaaS History
  6. 6. OpenStack LBaaS History• OpenStack Essex (April 2012)– Compute (Nova)– Objects Storage (Swift)– Images Storage (Glance)– Identity Management (Keystone)– Dashboard GUI (Horizon)• OpenStack Folsom: (September 2012)– Network (Quantum)– IP Management (Mélange)• OpenStack Grizzly: (April 2013)– Quantum Network Services– LBaaS• HA Proxy• OpenStack Havana: (November 2013)– LBaaS• Multi vendor supportLoad Balancing as a Service (Atlas-LB) a community projectEvaluate approaches for LoadBalancing as a ServiceLBaaS 1st releaseLBaaS Multi vendor
  7. 7. LBaaS in Grizzly
  8. 8. Grizzly - Tenant API• VIP• Pool• Pool Member• Health MonitoringVIP PoolPoolMemberPoolMemberPoolMemberSubnet SubnetHealthMonitor
  9. 9. Grizzly - ImplementationQuantum Server Network NodeLBaaSLBaaS -callbackLBaaS AgentHA ProxyProcessHA ProxyProcessHA ProxyProcessHA ProxyProcessHA ProxyProcess
  10. 10. Notes• HA Proxy process per VIP• VIP / Pool Members on the same network /subnet• Nat only• Model is actionable on the Device/Instancewhen all the model is completely defined• Does not support multi network nodes• Does not support HA for the service
  11. 11. Focus Areas for Havana
  12. 12. OpenStack/Networking/LBaaS –Highlights for Havana• Multiple load balancing technologies and vendors could beused in parallel• Service Types as a way to specify the required service (ex:Platinum, Gold, Silver)• Solution can be used out of the box with a default opensource load balancer driverSlide 12
  13. 13. Multi Vendor Support• Vendor/Driver selection should be done in the LBaaS Plug-in running inside Quantum– Based on Service Type– Based on the decision how to handle service insertion• Device provisioning and selection (AKA Scheduling) is theresponsibility of the Driver.– Shared libraries could assist but should not be mandatory (ex:scheduling library)• Should allow different service models– NS based– Service VM based– HW appliance based– Other
  14. 14. Proposed ArchitectureQuantum PluginLBaaS PluginHA Proxy NS DriverHA Proxy ServiceVM DriverVendor 1 Ns DriverVendor 2 DriverVendor 3 HWAppliance DriverHA Proxy NS AgentHA Proxy ServiceVM AgentVendor 1 Ns AgentVendor 2 LB FabricManagerVendor 3 HW On-Appliance APIAMQPAMQPRESTAMQPREST / SOAP
  15. 15. LBaaS Driver• The Driver API is similar to the LBaaS Plugin API,the Plugin delegates handling of the Message tothe Driver and pass itself as parameter.• HA is complex and should be managed by eachvendor per his needs:– Allocating QPorts and managing IP adress allocationmust be done in the LBaaS Plugin / Driver and not onan Agent - Some of the capabilities exists only whenembedded in the Quantum Plug-in
  16. 16. LBaaS Driver• Handling a-sync operations– Message Queues with Driver <->Agent– Callback threads with ITC queue• Connecting Physical appliances to theQuantum network is still missing APIcapabilities that allow for example connectinga VLAN based appliance to Quantum via L2/L3network gateway.
  17. 17. Tenant API• Support Multiple vendors at the same time• How to expose LBaaS vendors’ uniquecapabilities• Validate/Update the Grizzly Tenant API
  18. 18. Remarks on current model• Health Monitor as global entity– The model was derived from vendors who canreuse Health Monitor on the boundary of a device– Managing Health Monitor over multiple instancesis an error prone experience since updates shouldbe done “atomically”– Options• Use Health Monitor definition globally but whenconnect to a Pool, do a copy• Manage Health Monitor on the Pool and not global
  19. 19. Remarks on current model• Since the model is actionable only when fullydefined, does it make sense to still manage itas different “flat” model or should it behierarchical under VIP?
  20. 20. Network Topologies• LB between two networks - the case when Vipand Pool are assigned to different subnets• Adding SNAT and DSR on top of the currentNAT implementation (extension to L3 agent?)• Can the LB replace the L3 GW?
  21. 21. Thank you!

×