Multi-Cloud Global Server Load Balancing (GSLB)

AviNetworks 1,188 views 16 slides Jun 13, 2019
Slide 1
Slide 1 of 16
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16

About This Presentation

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-...


Slide Content

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

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

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

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

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

Demo Configuration GSLB policy Analytics & visibility

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”
Tags