GSLB: Practical Approach to GSLB Management and Scaling Your Application Delivery Platform

The 2020 global pandemic changed many business models. While remote work became the norm, there was a gigantic effort made to make the transition successful. Many of the businesses had to organize additional resources and schedule downtime to make their applications available. The one thing this change taught us is we need an agile, reliable, and scalable application delivery platform.

Why is GSLB required?

VMware's NSX Advanced Load-balance[1] r, also known as Avi, provides the finest consumer experience to clients who are in geographically distributed areas with global server load balancing (GSLB). Amidst growing business, many of the enterprises have their consumer base and datacenters in various geographic areas. With GSLB, these enterprises obtain resiliency. Businesses who have hybrid cloud deployment models or who are looking into migrating to the cloud, from their on-prem deployments, get seamless and non-disruptive app migrations with the use of GSLB

.

Avi can service organizations with multiple datacenters, be it on-prem or in-cloud or a hybrid model. Applications on all these sites can be serviced using GSLB. Each site will have its own Avi controller cluster. All the configurations will be done at the leader controller site, which will be synchronized across all the other sites. So even if site 3 goes through some failures, site 1 and site 2 will continue servicing the traffic. Monitoring is a big part of GSLB

, it uses this monitored data to make load-balancing decisions and chooses the location, on-prem or cloud, to steer client requests. Avi uses the Domain Name System (DNS) for providing the optimal destination information to the user clients. When a client (typically a browser) performs a DNS query on fully qualified domain names (FQDNs), Avi GSLB responds with the IP address (VIP) of the optimal application instance. The optimal address can and will change based on the load balancing algorithm, the health of the application instances, and the location of the clients.

What Does the Workflow Look Like?

Let's take an example, Avi is running in 4 sites in a hybrid fashion. Every site has its own controller cluster. Application "shop" has virtual service (VS) on all 4 sites, VS-shop1 to VS-shop4. All the sites have global DNS services and are authoritative for the subdomain shop.avi.com.

Step 1: FQDN resolution

Client requests shop.avi.com. This request comes to the corporate DNS. Since the shop.acme.com domain is delegated to Avi's global DNS, the request will be forwarded to one of the DNS services. This DNS service will choose one of the VS from VS-shop1 to VS-shop4 based on load balancing algorithm, health, client location, etc. Let's say it choose VS-shop1. The VIP of VS-shop1 will be sent to the original client.

Step 2: App Traffic

The client will use the VIP of VS-shop1 to send its HTTP request

Step 3: Local Load Balancing

The service engine [SE] will receive the request that is directed to VIP of VS-shop1. It then load balances to one of the servers of VS-shop1. VS-shop1 will then respond directly to the client. You may find a brief video that walks through configuring GSLB in just a few clicks.
https://youtu.be/uUShrSYeskk

In the newer Avi releases, we support continuous as well as manual replication methods. In continuous replication, the configuration synchronization to all the follower sites gets initiated from the leader site automatically. Any faulty configuration can impact all the follower sites as changes are pushed to all the sites immediately. In manual replication, the configuration sync is initiated based on the pull request by a specific follower site. The manual replication method uses a checkpoint on the leader site, which defines the configuration that followers can safely consume and uses as the reference point for the last saved configuration. When there is a pull request from the follower site for replication for a specific checkpoint, the leader pushes the configuration until the specific checkpoint only, not the complete configuration.

Take a quick look at this video which walks you through Canary updates on GSLB Deployments.

To get hands-on experience, please check out our workshops, here.

Public link

Please use the above public link if you want to share this noodl on another website.