This section describes the steps to enable health monitoring proxy.
Enabling Health Monitoring Proxy
A GSLB site optimizes health checks by identifying other GSLB sites as health-monitoring proxies. In the figure shown below, the drop-down menu of the Health Monitor Proxy field offers three NSX Advanced Load Balancer GSLB sites capable of performing local checks for the GSLB.
Localized Data-Plane-Based Global Application Health Monitoring
The following figure shows the transformation of DC3 into an active site through 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 and 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 Controller 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, options 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.
