The document outlines advanced networking services, specifically Load-Balancing as a Service (LBaaS), detailing features such as high availability, session persistence, and global server load balancing. It discusses the evolution of LBaaS in OpenStack, from the initial Neutron LBaaS APIs to the current Octavia project, highlighting enhancements and limitations along the way. Additionally, it describes Avi Networks' software-defined application services, emphasizing enterprise-level capabilities for multi-cloud environments and integrated analytics.

1. Advanced Networking Services:
Load-Balancing as a Service
(LBaaS)
Praveen Yalagandula & Anant Patil
Avi Networks

2. Load Balancers
Core goals: High Availability and Performance
Internet
Web
Server
Users

3. Load Balancers
Core goals: High Availability and Performance
Internet
Web Servers
Users

4. Load Balancer: Advanced features
Application Delivery
• Session Persistence
• Policy-based Switching
• SSL Termination
• Rate Limiting, User Auth, …
Internet
Web Servers
User A User
B

5. Load Balancer: Advanced features
Application Delivery
Internet
Pool 1: Media Servers
Users
Pool 2: Secure
Servers
https://foo.com/img/car.jpg
https://foo.com/checkout/pay
• Session Persistence
• Policy-based Switching
• SSL Termination
• Rate Limiting, User Auth, …

6. Load Balancer: Advanced features
Application Delivery
Internet
Pool 1: Media Servers
Users
Pool 2: Secure
Servers
https://foo.com/img/car.jpg
https://foo.com/checkout/pay
SSLv3 
TLSv1.2 
• Session Persistence
• Policy-based Switching
• SSL Termination
• Rate Limiting, User Auth, …

7. Global Server Load Balancing
High Fault Tolerance, Geolocation based LB, Session Persistence
Copyright © 2018 Avi Networks
Datacenter 1
Datacenter 2

8. OpenStack LBaaS APIs

9. LBaaS Evolution in OpenStack
• Neutron LBaaS v1.0 API
– Introduced in Grizzly
– Lacked several key advanced features: SSL support, rules based switching
– Deprecated in Liberty
• Neutron LBaaS v2.0 API
– Introduced in Kilo
– Deprecated in Queens
• Octavia
– LBaaS as a separate project; out of Neutron
– Superset over LBaaS v2.0 API
– Default since Queens

10. LBaaS v1.0 Model
VIP
Pool
Health
Monitor
Member 1 Member N…
IP:Port
No support for multiple ports
Most HTTP apps run on both 80 and 443
No support for SSL termination
No support for Policy-Based
Switching

11. LBaaS v2.0 Model
LB
Listener 1 Listener MListener 2 …
Default Pool
Health
Monitor
Member 1 Member N…
Virtual IP
Port

12. LBaaS v2.0 Model: TLS Support
LB
Listener 1
Default Pool
Health
Monitor
Member 1 Member N…
Default TLS
ID
SNI 1 SNI M…
Barbican
Store for
Secrets

13. LBaaS v2.0 Model: L7 rules
LB
Listener 1
Default Pool
Health
Monitor
Member 1 Member N…
Default TLS
ID
SNI 1 SNI M…
Barbican
Store for
Secrets
Policy 1
Policy K
Rule1 … RuleX
..
Action

14. LBaaS v2.0 APIs: Limitations
(Not a comprehensive list)
• Missing protocols
– UDP
– Non-HTTP SSL termination
• Limited SSL Support
– Missing support for backend (client) SSL cert
• Use case: Pools with backend servers that require client SSL certs
– SSL protocol and cipher-list control
• E.g., SSLv3 is broken and should not be used for external applications
• Prefer EC ciphers over RSA: Perfect-Forward Secrecy
– Support for only one default cert
• Lack of custom health monitoring
– E.g., Monitor on a different port than the port configured for members
– Non-http protocols: e.g., MySQL

15. Octavia: Current LBaaS Project
• Superset over LBaaS v2 APIs
• Several Enhancements
– Support for UDP, in Rocky
– Statistics over each listener
– Quotas on objects
– Alternate Monitor port/address for pool members
– …

16. Initial Implementations
1 Hypervisor-process based
E.g., Reference LBaaS
implementation using HAProxy
2 Appliance-based E.g., Traditional ADC solutions

17. Reference Implementation using HAProxy
• One HAProxy process per
Pool/VIP
• Running on Network Node
Compute NodesNetwork Node(s)
Keystone
Controller Node(s)
Neutron w/LBaaS
……
LBaaS Agent
HAProxy
HAProxy
HAProxy
HAProxy
North-South Traffic
East-West Traffic
Limited Scalability
No in-built HA
Best-effort Tenant Isolation
Not suitable for enterprise-grade clouds

18. Appliance-based Implementation
• Appliances located
“next” to OpenStack
servers
• Plug into underlay
o Need to understand
underlay protocols
Compute NodesNetwork Node(s)
Keystone
Controller Node(s)
Neutron w/LBaaS
……
L3 Agent
router
router
router
router
North-South Traffic
East-West Traffic
Complex & Expensive

19. Service-VM Architecture

20. Service-VM Architecture
Distributed load balancer with a centralized control plane
Controllers
Service
Engine

21. Octavia: OpenStack LBaaS

22. Software Defined Application Services
Elastic Load Balancing | Application Security | Application Analytics

23. Avi Networks Overview
Software load balancer, web application firewall, and service mesh, with built-in predictive analytics
UNIVERSAL SOLUTION
For Modern and
Traditional Use Cases
Multi-Cloud and SaaS
G2000 CUSTOMERS
20% of F50
10% of F500
Across Industries
EXPONENTIAL GROWTH
3x YoY Growth
5x Increase in Customers
Strategic Partnerships (Cisco)
Copyright © 2018 Avi Networks

24. BARE METAL VIRTUALIZED CONTAINERSON PREMISES PUBLIC CLOUDVIRTUALIZED CONTAINERS
Modern, Scalable, Multi-Cloud Architecture
CONTROLLER
(SaaS / Customer-Managed)
SERVICE ENGINE
SEPARATE CONTROL
& DATA PLANE
ELASTICITY
INTELLIGENCE AUTOMATION
Copyright © 2018 Avi Networks
MULTI-CLOUD

25. Avi and OpenStack Integration
H Heat
LBaaS

26. Avi LBaaS Overview
Ignoring a lot of details
Admin creates
1) Avi Controller VM
2) SE Management Network
Admin configures Avi Controller
with OpenStack credentials
Avi
Controller
SE Mgmt
Network

27. Avi LBaaS Overview
Ignoring lot of details
User has two servers and requests LB
service
Avi
Controller
Server 1
Server 2
SE Mgmt
Network
Server
Network
Service
Engine2
Service
Engine1
Avi Controller dynamically creates SEs as needed to
• Ensure high availability
• Meet performance SLAs
traffic

28. Avi LBaaS Overview
Ignoring lot of details
User has two servers and requests LB
service
Avi
Controller
Server 1
Server 2
SE Mgmt
Network
Server
Network
Service
Engine2
Service
Engine1
traffic
Service
Engine3
Strong isolation guarantees possible by
separating out the service engines of
different tenants

29. Service-VM Architecture: Flexible Deployments
• SEs in a user’s tenant context
• SEs in a common Service tenant
context
– Exclusive SEs per tenant
– Shared SEs
Avi
Controller
Server 1
Server 2
SE Mgmt
Network
Server
Network
Service
Engine2
Service
Engine1
Service
Engine3
Tenant 1
Tenant 2
Server 3

30. Service-VM Architecture: Flexible Deployments
• SEs in a user’s tenant context
• SEs in a common Service tenant
context
– Exclusive SEs per tenant
– Shared SEs
Avi
Controller
Server 1
Server 2
SE Mgmt
Network
Server
Network
Service
Engine2
Service
Engine1
Service
Engine3
Tenant 1
Tenant 2
Server 3

31. Service-VM Architecture: Flexible Deployments
• SEs in a user’s tenant context
• SEs in a common Service tenant
context
– Exclusive SEs per tenant
– Shared SEs
Avi
Controller
Server 1
Server 2
SE Mgmt
Network
Server
Network
Service
Engine2
Service
Engine1
Service
Engine3
Tenant 1
Tenant 2
Server 3

32. Service-VM Architecture: Flexible Deployments
• SEs in a user’s tenant context
• SEs in a common Service tenant
context
– Exclusive SEs per tenant
– Shared SEs
Avi
Controller
Server 1
Server 2
SE Mgmt
Network
Server
Network
Service
Engine2
Service
Engine1
Tenant 1
Tenant 2
Server 3

33. High Availability
Active-Standby HA
App-1 App-2
Client Requests to
App-1

34. High Availability
Active-Standby HA
App-1 App-2
Client Requests to
App-1
Active-Active HA
App-1 App-2
Client Requests to
App-1

35. High Availability
Active-Standby HA
App-1 App-2
Client Requests to
App-1
Active-Active HA
App-1 App-2
Client Requests to
App-1
Cluster N+M HA
App-1 App-2 App-3 App-4 App-5
Client Requests to App-
1

36. Elastic increase Capacity - Auto-Scale
Active-Active HA
App-1 App-2
Client Requests to
App-1 Policy and Machine Learning based
AutoScale
If CPU > 80% or Available Capacity < 10%
increase scale

37. Active-Active
HA
App-1 App-2
Client Requests to
App-1
OpenStack: Getting around throughput limitations
OpenStack Neutron Restriction:
A single IP can only be served by a one vNIC
• No concept of ECMP
• Bottleneck: PPS Limits on single vNIC

38. Active Active
HA
App-1 App-2
Client Requests to
App-1
OpenStack: Getting around throughput limitations
Upstream
Router
OpenStack Neutron Restriction:
A single IP can only be served by a one vNIC
• No concept of ECMP
• Bottleneck: PPS Limits on single vNIC
Workarounds
• Some plugins have API to place same IP on multiple vNICs (e.g., Contrail)
• BGP peering with upstream router

39. DC 1
Global Server Load Balancing (GSLB)
Benefits
• Centralized provisioning
– Automated discovery of applications across sites
• Centralized visibility
– Application health, logs and analytics
• Hybrid cloud support
– Across private clouds and public clouds
Public Cloud
DC 2
Central Management
and Monitoring
GSLB
Features
• DNS-based load balancing
• Active/DR and Active/Active
• Geo-location based routing (custom DB
support)
• Site-persistence with cookies

40. Avi’s Analytics from within Horizon

41. Demo

42. 100% API driven
• REST APIs,
architecturally similar
to OpenStack APIs.
• OpenStack optimized
tenant management
• Heat modules
available
Controller-based
Distributed LBs
• Controller manages
full life cycle of service
VMs and
configuration
• Provides ease of
management &
operations
Multi-tenancy with
Keystone Integration
• OpenStack tenants can
use Avi controller for
their apps for
advanced features
• Tenants can access to
monitoring data
End-to-end Visibility
and App Insights
• Enables quick issue
resolution
• Helps with capacity
planning and
optimization
Avi = Enterprise Grade Cloud ADC and Analytics Engine
Avi Vantage benefits in OpenStack
Elastic LBaaS with Integrated Analytics

43. Thanks!
https://avinetworks.com/
Please visit us at our Booth in Market
Place Expo