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-...
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
Size: 2.94 MB
Language: en
Added: Jun 13, 2019
Slides: 16 pages
Slide Content
Multi-Cloud Global Server Load Balancing (GSLB) Ashwin Manekar, Avi Networks Sr. Product Manager Mittali Chawla, Avi Networks Technical Marketing Engineer
GSLB Overview Pre-requisites: basic understanding of DNS and GSLB Why Multi-Cloud GSLB and health monitoring Requirements of enterprise-grade GSLB
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
Challenges of Existing GSLB Solutions DC 1 Public / Private Cloud DC 2 GSLB Hard to deploy in multi-cloud Lack of analytics Architectural resiliency Separate feature
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 A ppA.gslb.avinetworks.com AppB.gslb.avinetworks.com A ppC.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
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-A 4 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-B 3 Active Follower Site - DC 2 VS-A2 DNS Passive Follower Site Azure VS-B2 VS-A3
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
Use Cases Multi-cloud deployments Cloud bursting Failure handling / recovery
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
Hybrid C loud W ith C loud B ursting Applications are deployed across private / public clouds. Under unusually high request load, Avi GSLB “bursts” to the public cloud and autoscale.
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-B 2
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
Next Steps Schedule a custom demo GSLB whitepaper Contact us for anything “Multi-Cloud”