Optimizing health checking of GSLB sites or service can be accomplished using the following:

  • Setting data-plane health monitor scope appropriately

  • Limiting the number of active sites

  • Health monitor sharding

Setting Data-plane Health Monitor Scope Appropriately

GslbService.health_monitor_scope

This parameter can be used for configuring the scope of the data health monitor as per the requirement. By default, it is set to GSLB_SERVICE_HEALTH_MONITOR_ALL_MEMBERS, in which case DNS SEs actively probe pool members at both NSX Advanced Load Balancer and external sites. However, the parameter can be set to GSLB_SERVICE_HEALTH_MONITOR_ONLY_NON_AVI_MEMBERS, such that external member status is collected in the only way possible, while the health checking is offloaded from DNS SEs to NSX Advanced Load Balancer Controllers local to the GSLB pool members.

Limiting the Number of Active Sites

When a large fraction of GSLB sites are configured to be active, the load on Controllers and the networks interconnecting them can be excessive. For example, consider two deployments, each with 10 NSX Advanced Load Balancer sites. One has 5 active Controllers, the other just 2. Each regularly scheduled remote-site health check from an active Controller collects health status from 9 remote sites. Compare the throughput consumed when 5 Controllers probe 9 sites each, versus when just 2 Controllers probe 9 sites. That’s 45 remote-site collections per unit of time compared to just 18. The latter is considerably more throughput-efficient, while still delivering reasonable GSLB DNS redundancy for HA.

Health Monitor Sharding

Health Monitor Sharding reduces the volume of health monitor traffic in large-scale deployments where the DNS Virtual Services are scaled out across multiple Service Engines within each site. For more information, see Health Monitor Sharding.

Use Case: Optimizing Health Monitoring

Only data-path health monitoring can be applied to third party members. Gathering GSLB pool external members into a third-party site enable easy optimization of health monitoring. First, identify an active NSX Advanced Load Balancer site from which health monitoring would be most efficient (proximity to the third-party site and other factors will influence the choice). Then use the GSLB third-party site editor to select the chosen NSX Advanced Load Balancer site from the Health Monitor Proxy drop-down menu.

For more information on health monitoring by proxy, see Localized Data-Plane-Based Global Application Health Monitoring.