Overview

Global Server Load Balancing (GSLB) is the method of load balancing applications/workloads that are distributed globally (typically, multiple data centers and public clouds). GSLB enables efficient distribution of traffic across application servers that are dispersed geographically. 

In a production environment, the corporate name server delegates one or more subdomains to NSX ALB GSLB, which then owns these domains, and provides responses to DNS queries from clients. DNS based load balancing is implemented by creating DNS Virtual Service. 

How GSLB Works?

Let’s understand the working of GSLB using the below example. 

There are 2 SDDC’s running in VMC and both the SDDC has local load balancing configured to load balance set of web servers in their respective SDDC. The 2 Virtual Services (SDDC01-Web-VS & SDDC02-Web-VS) have a couple of web servers as pool members and the VIP of the Virtual Service is translating to Public IP via NAT.  

Let’s assume the 4 web servers running across 2 SDDC are servicing the same web application and you are looking for doing a global load balancing along with local load balancing. 

To achieve this, you should have a common URL via which all 4 web servers can be accessed. When this URL is accessed, the load is distributed across all the web servers that are participating in GSLB. 

In this case, client requests will be sent to the GSLB Virtual Service which is a DNS based virtual service. The GSLB virtual service then checks its pool and based on the algorithm used, forwards requests to one of the local virtual services configured in the SDDC. The local VS then forwards the traffic to one or more pool members. 

GSLB Use Cases

Following are the few use cases of NSX ALB GSLB functionality:

• Provide optimal application experience by load balancing applications across 2 or more datacenters.
• Application high availability across the datacenters.
• Traffic redirection to the DR site in case of the primary site failure.

GSLB Deployment Topology in VMC on AWS

The below diagram taken from David Zhang’s blog shows a high-level topology of GSLB implementation across 2 SDDC (connected via vTGW) in VMC on AWS. 

As shown in the above diagram, applications (web servers) are deployed in SDDC1 and SDDC2. Local instance of NSX ALB is deployed in both the SDDC’s and is performing local load balancing in their respective SDDC. The 2 SDDC’s are in different availability zones, hence connectivity between the 2 SDDC’s is provided via VMware Transit Gateway (vTGW). The segments where applications are deployed, have reachability across SDDC’s. 

Pre-requisites for GSLB Implementation

• At least 2 SDDC’s are deployed and configured in VMC.
• The 2 SDDC should have connectivity with each other and the networks chosen for NSX ALB deployment should have reachability across SDDC’s.
• NSX ALB Controllers & Service Engines are deployed in SDDC. Steps for deploying and configuring NSX ALB in VMC is available here
• Local load balancing of applications inside individual SDDC is configured. Steps for configuring load balancing in VMC is available here
• DNS subdomain for applications is hosted either on-prem or Cloud DNS. The subdomain should be resolvable over the internet.
• NSX ALB Controllers and Service Engines should be able to resolve the DNS subdomain that is hosted outside of VMC.

GSLB Implementation Steps

The below table shows the various components and associated IP addresses that I will be using in my configuration.

Create DNS Virtual Service

GSLB is a DNS based solution and is implemented via DNS Virtual Service. To create DNS Virtual Service, login to the Avi controller of SDDC1 and navigate to Applications > Virtual Services > Create Virtual Service > Advanced Setup.

Configure the following settings:

• Name: Provide a name for the DNS Virtual Service. 
• FQDN/IPv4 Address: Provide a free IP address from the pool which you configured for NSX ALB VIP. If the IP address is DNS resolvable, you can provide FQDN instead. 
• Application Profile: Choose System-DNS profile. 
• TCP/UDP Profile: Accept the default for the TCP/UDP Profile field (System-UDP-Per-Pkt)
• Pool: No pool is required; the DNS service will run within the SE’s virtual machine. 
• Service Port: Select Port 53 by switching to advanced view under the Service Port sub-section. 

You can leave the other settings (Policies/Analytics/Advanced) to system default unless you want to turn on specific functionality.

Ensure that the newly created DNS Virtual Service is healthy and status is Up. 

Repeat the process of creating DNS Virtual Service in SDDC02. 

Configure GSLB Sites

NSX Advanced Load Balancer differentiates datacenters by categorizing them into sites. GSLB sites fall into two broad categories:

• Avi Sites: An Avi site refers to the environment that is running NSX ALB Controllers and Service Engines. 
• External Sites: An external site runs third-party ADCs from vendors such as F5, Citrix, etc.

Each Avi site is characterized as either an active or a passive site. Active sites are further classified into two types:

• GSLB leader
• GSLB followers 

The active site from which the initial GSLB site configuration is performed is the designated GSLB leader. Changes to GSLB configuration are permitted only from the leader node, which propagates those changes to all accessible followers. The only way to switch the leadership role to a follower is by overriding the configuration of the leader from a follower site. This override can be invoked in the case of site failures or for maintenance.

Note: GSLB implementation in VMC leverages Avi Sites. 

To configure GSLB sites, log in to the Controller node which will be designated as the leader and navigate to Infrastructure > GSLB, and use the pencil button to edit the GSLB settings and define GSLB sites. 

Configure the following settings:

• Name: Provide a name for the GSLB Site.
• Credentials: Provide the credentials of the controller node. 
• IP Address: Provide IP address of individual controller nodes and select port as 443.

Note: You can either enter the Controller Cluster IP address or specify an individual node when configuring controller information.

Under GSLB Subdomain, enter the publically resolvable URL which will be used to access the application servers. This URL will be the single point of entry for all application servers that are going to be load balanced via GSLB. 

Note: In my lab, I have the domain vmclab.net hosted in AWS. 

Click on the Save and Set DNS Virtual Services button. 

Under DNS Virtual Service, select the Virtual Service that you have created earlier and map it with the GSLB Subdomain, and hit save.

The first GSLB site is always added as Active and is designated with a Leader role. Subsequent sites can be added as Active or Passive depending upon the infrastructure needs.

To add a new site click on Add New Site button. 

Configure the following settings: 

• Name: Provide a name for the GSLB Site.
• Credentials: Provide the credentials of the controller node. 
• IP Address: Provide the VIP address of the controller cluster from the second SDDC and enter port 443.
• Active Member: Selected. 

Click on Save and Set DNS Virtual Services to map the DNS Virtual Service with the GSLB Subdomain and hit the save button to finish the site addition wizard. 

At this point, the two Avi sites are talking to each other, and configuration synchronization is enabled.

NAT Private VIP with Public VIP

Typically, the IP address used in the VIP configuration for local virtual service is a private IP address. These IP addresses are not reachable by the client over the Internet. To sort this out, you have to enable the NAT aware Public-Private GSLB feature. This feature has been described in detail Here

To configure this, navigate to Infrastructure > GSLB > Active Members and edit the settings of the Leader Site. Under Advanced Settings, select Client Group IP Address Type as Private and enter the following parameters:

• 10.0.0.0/8
• 172.16.0.0/15
• 192.168.0.0/16

Enable GSLB Service and Configure GSLB Pools

To enable GSLB service, navigate to Applications > GSLB Services > Create > Advanced Setup

Configure the following settings:

• Name: Name for the GSLB service.
• Application Name: www
• Subdomain: Select the GSLB subdomain that you created while performing the GSLB site configuration. 
• Health Monitor: Appropriate health monitor as per your application. The commonly used health monitors for web-based applications are System-GSLB-HTTP and System-GSLB-HTTPS
• Health Monitor Scope: All Members
• Controller Health Status: Enabled

Next is to create GSLB Pool members.

Under GSLB Pool, Click on the Add Pool option and enter the following parameters:

• Name: Name for the GSLB Pool.
• Pool Members Load Balancing Algorithm: Round Robin (Note this means the client will be sent to the local load balancer in both SDDC01 and SDDC02)

Under Pool Members, select the type as Virtual Service and configure the following settings:

• Site Cluster Controller: GSLB Leader Site.
• Virtual Service: Web Virtual Service that has been configured in the leader site (SDDC01).
• Public IP Address: Public IP address serving as VIP for the web server in SDDC01.
• Ratio: A ratio of 1 means all pool members will get an equal load.
• Enabled: Selected.

Repeat the process for adding SDDC02 GSLB pool members.

Configure the number of IPs returned by DNS Server to 1 and set TTL to 300.

Click on the save button to finish the GSLB Pool configuration. 

The configuration of Active-Active GSLB for the web-based application server is now completed.

Configure Public IP and NAT/Firewall Rules for DNS Virtual Service

To create NAT/Firewall rules for DNS Virtual Service, you have to first request a Public IP. Please refer to the VMC on AWS official documentation to learn about how to Request a Public IP and create NAT/firewall rules. 

Configure DNS Subdomain

For hosting DNS subdomain in Public Cloud, please refer to the service provider documentation. A sample DNS subdomain configuration in AWS is shown in the below screenshot.

Verify Global Load Balancing

To test the GSLB working, open a web browser and enter the application name that you have configured in your GSLB configuration.

In my lab, the application url is configured as www.sddc.vmclab.net. This is a publicly resolvable URL created via AWS Route 53 service. 

On hitting the application URL, you should be able to see the response from each pool member. 

And that’s it for this post. 

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing