Watch on-demand https://info.avinetworks.com/webinars/global-server-load-balancing
GSLB has been traditionally deployed across multi-site data centers for disaster recovery and faster app response time. Increasingly, GSLB is applied across on-prem data centers and public clouds to better serve geo-distributed users. However cloud load balancing is lacking in terms of enterprise-class GSLB support. With distributed containerized applications and microservices deployed in Kubernetes clusters, visibility and health monitoring becomes ever more critical.
In this webinar, learn how Avi Vantage:
- Support DR scenarios for both Active / Standby and Active / Active applications
- Provision centrally with automated discovery of applications across sites
- Perform non-disruptive migration / expansion / consolidation of data centers
- Address use cases: multi-cloud deployments, cloud bursting, and site failure handling / recovery
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
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
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
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”