GSLB service is the representation of a global application deployed at multiple sites. The GSLB service configuration defines the FQDN of the application, the backing of virtual services in various sites, and the priority or ratios governing the selection of a particular virtual service at any given time. The configuration also defines the health-monitoring methods by which unhealthy components can be identified so that the best alternatives may be selected.

GSLB Service Health Monitoring

GSLB service health monitoring are of the following two catergories:

  • Control plane

  • Data plane

    • Default behavior

    • HM proxy

    • HM sharding

One or both can be applied on a per-application basis.

Control-Plane-Based Global Application Health Monitoring

Independent of NSX Advanced Load Balancer GSLB, every NSX Advanced Load Balancer Controller cluster routinely performs local health checks to collect the health scores and performance metrics of virtual services under its direct control. In addition, if GslbService.controller_health_status_enabled is True, active GSLB sites will also periodically query the NSX Advanced Load Balancer Controllers at all the other sites specified within the GSLB site configuration (both active and passive sites).

Note:

Control-plane health monitoring does not apply to virtual services configured on a third-party load balancer VIP or standalone servers.

The following image shows only the active Controller in DC1 is collecting health information from 3 other Controllers. DC1’s Controller passes a coalesced picture of health status to its local DNS (solid arrow). In reality, the active Controllers in DC2 and AWS update their respective local DNS virtual service with control-plane-based health status.

Data-Plane-Based Global Application Health Monitoring

This is the default behavior of data-plane-based health monitoring. In contrast to control-plane-based health monitoring, no site’s Controller cluster is queried. Instead, health checks go directly to participating services, i.e., to the data plane. At an active site, an SE hosting a GSLB DNS virtual service performs periodic health checks against all GSLB pool members (including the virtual services local to it). A dedicated SE should be configured to perform these health checks. Active monitors generate synthetic traffic from the DNS SE to mark a GSLB pool member up or down, based on its response. The following diagram shows the DNS in DC1 (the only active site) performing this function against its local virtual service (VS-A1), as well as VS-A2, VS-A3, and VS-A4. Similarly, if NSX Advanced Load Balancer DNS virtual service is running on other sites then those DNS SEs would perform the data plane health monitoring in the same way.

Ping, TCP, UDP, DNS, and HTTP(S) health monitors are supported as mentioned in the Configuring Health Monitoring section. Additionally, a custom monitor can be configured as per the requirement.

Note:

It is recommended to configure different SE groups for GSLB DNS and load balancing virtual services.

For more information on health monitors, refer to Health Monitors on NSX Advanced Load Balancer.

Localized Data-Plane-Based Global Application Health Monitoring

The following figure shows the transformation of DC3 into an active site via the deployment of an NSX Advanced Load Balancer DNS SE. This nominally adds four additional data-plane health checks, from DC3’s NSX Advanced Load Balancer DNS SE to each of the four-member virtual services.

Note the DC1 DNS check of VS-A4 as well as the DC3 DNS check of VS-A1. To avoid these checks for one or both of the following reasons:

  • The firewalls protecting DC1 and DC3 have been configured to permit the NSX Advanced Load Balancer Controllers to communicate, but they block direct access to VS-A4 (from DC1) and VS-A1 (from DC3)

  • We want to scale the performance of each NSX Advanced Load Balancer DNS SE by minimizing the number of health checks each must perform. Since each member virtual service is already being data-plane checked by a local DNS, the remote DNS does not have to replicate the checks.

To achieve the optimization shown in the figure below, option VS-A1 and VS-A4 for localized data-plane health checks. Two data-plane health checks are eliminated. Instead, each DNS SE gets the health information it needs by querying the remote site’s NSX Advanced Load Balancer Controller.

This hybrid approach, which combines control plane and data plane health checking, is enabled for a global service on an individual member virtual service basis. The only restriction is that the member virtual service runs on an active NSX Advanced Load Balancer site.

Refer to Health Monitor Sharding for more details on health monitor sharding.

DNS health monitors can be configured to monitor the health of DNS servers that are configured as DNS service pool members.

Refer to DNS Health Monitor for more details.

Refer to Interaction with the GSLB DNS for more details.

Refer to Options and Combinations for GSLB Service Health Monitoring for more details.