The document provides an overview of multi-cloud global server load balancing (GSLB) by Avi Networks, highlighting its use cases such as multi-cloud deployments, cloud bursting, and failure handling. It discusses the architecture, health monitoring requirements, and the challenges of existing GSLB solutions, emphasizing the benefits of resilience, non-disruptive operations, and analytics. The document also outlines the roles of leader and follower sites in GSLB configurations and the implications of site failures on traffic management.

1. Multi-Cloud Global Server Load
Balancing (GSLB)
Ashwin Manekar, Avi Networks
Sr. Product Manager
Mittali Chawla, Avi Networks
Technical Marketing Engineer

2. Agenda
GSLB Overview
Use Cases
1. Multi-Cloud deployments
2. Cloud bursting
3. Failure handling
Demo: config / policy / analytics

3. GSLB Overview
- Pre-requisites: basic understanding of DNS and GSLB
- Why Multi-Cloud GSLB and health monitoring
- Requirements of enterprise-grade GSLB

4. What and Why GSLB?
• Geo distributed applications
• Serve global traffic in the most efficient way
• Traffic distribution across multiple locations
Santa Clara Boston London
• End user experience
– Best application experience to global users
• Resiliency
– Loss of a data center or network connection.
Support blue/green deployment
• Non-disruptive operations
– Bring down servers for routine
maintenance/migration

5. Challenges of Existing GSLB Solutions
DC 1
Public / Private Cloud
DC 2
GSLB
1. Hard to deploy in multi-cloud
1. Lack of analytics
2. Architectural resiliency
1. Separate feature

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

7. Avi GSLB Terminology
Sub-domains
• Add sub-domains in Avi DNS
GSLB Sites
• Avi Sites: Location of Avi controller
• 3rd Party Sites: Location of 3rd party
app modules
• Leader Site: Initiate the configuration
• Follower Site: Config synchronized with
the Leader Site
• Active Site: Respond to DNS query
• Passive Site: Host app instances
AppA.gslb.avinetworks.com
AppB.gslb.avinetworks.com
AppC.gslb.avinetworks.com
GSLB Services ( GS)
DNS VS
GSLB Pool GSLB Pool Members
Pool 1
Pool 2
M1
M2
Avi VS
3rd party
IP address
FQDN
Avi DNS VS
• System DNS
• UDP Network profile
• GSLB and DNS LB
• Static DNS entries
• VS DNS hosting
GSLB Service
• Global app instance
• App Name and FQDN
GSLB Pool & GSLB Pool Members
• Avi VS
• IP Address
• FQDN
• 3rd Party Site
Health Monitoring
• Monitor health of app instances
• Route traffic to healthy entities

8. GSLB Deployment Example
• “GSLB Active” sites: DC1, DC2 , AWS
– Synchronize GSLB state
– Run DNS service
– All config through “GSLB Leader” DC1
• “GSLB Passive” site: Azure
– No GSLB state or DNS service
– Local VS ( VS-A3/VS-B2) can be member
of a GSLB Service
Leader Site - DC 1
VS-A1 VS-B1
DNS
VS-A4
DNS
All GSLB configuration is performed
at the “Leader” Controller
“Leader” Controller syncs the
configuration to all the “Follower”
sites
Active Follower Site - AWS
Admin
VS-B3
Active Follower Site - DC 2
VS-A2
DNS
Passive Follower Site Azure
VS-B2
VS-A3

9. GSLB Health Monitoring
• Control plane health checks
• Data plane only health checks
• Control + data plane health checks
Advanced Health Monitoring:
• HM Proxy
• HM Sharding
Leader Site
VS-A1
DNS
Active Follower Site 2
VS-A1
DNS
VS-A1
DNS
Active Follower Site 1
Control Plane HM
Data Plane HM

10. Use Cases
- Multi-cloud deployments
- Cloud bursting
- Failure handling / recovery

11. Multi-Cloud GSLB Across Third-Party Sites
• External sites only perform
actual processing of requests
• Data-path health monitoring
can be applied to 3rd party
Leader Site - DC 1
VS-A1 VS-B1
DNS
Citrix NetScaler LB
F5 LTM
DC 2 - Chicago
VS-A2
DNS
Any IP endpoint

12. Hybrid Cloud With Cloud Bursting
• Applications are deployed
across private / public clouds.
• Under unusually high request
load, Avi GSLB “bursts” to the
public cloud and autoscale.

13. Failure Handling Scenarios
GSLB Follower Site Failure handling
• Leader detects failure
• CP and DP HM marks the GS members as down
GSLB Leader Site Failure handling
• GSLB configuration cannot be updated
• Active sites detect failure of leader
• DP HM marks the GS members as down
Control plane health monitoring failure
• Controllers are unreachable from each other
• No impact on traffic; Site will run in headless mode
Data plane health monitoring failure
• GS members of remote sites will be marked as down
• Config changes can be made
Leader Site - DC 1
VS-A1 VS-B1
DNS
DC 3 - NY
DNS
DC 2 - Chicago
VS-A2
DNS
VS-B2

14. Demo
- Configuration
- GSLB policy
- Analytics & visibility

15. Summary
• Resilient to the loss of a data center or network connectivity
• Support non-disruptive operations by allowing maintenance/migration
• Easy to deploy in multi-cloud
• Real-time health monitoring
• Distributed architecture provides better failure handling
• Not a separate feature

16. Next Steps
- Schedule a custom demo
- GSLB whitepaper
- Contact us for anything “Multi-
Cloud”