A GSLB service is the representation of a global application. It front ends instantiations of the application that are deployed at multiple sites.
The following are key elements of a global service:
The global application service’s name, by which administrators reference the GSLB configuration.
The application's FQDN, by which end user clients reference it. A list of domain names can be provided for aliasing (e.g., www.foo.com and foo.com).
Backing services running in various GSLB sites, organized into one or more GSLB pools. A backing service is usually an NSX Advanced Load Balancer virtual service. However, it can be a third-party ADC’s virtual service, or even an IP: port on some solitary server.Note:
A GSLB pool is different from a server pool. The former aggregates backing services, while the latter aggregates servers.
Health monitoring methods by which unhealthy components can be identified so that alternatives may be selected.
A time-to-live (TTL) ranging from 1-86400 seconds determines the frequency with which clients need to obtain fresh steering information for client requests. If none is specified for a particular GSLB service, the TTL value defaults to the one specified in the DNS application profile (default value is 30 seconds).
It is recommended to use caution when using very low values of TTL since some DNS or operating systems will discard a very low TTL.
Interaction with the GSLB DNS
When it is determined a GSLB service pool member (i.e., some participating virtual service) is down, one of four standard responses is returned by the GSLB DNS. In the GslbService object, set the GslbService.down_response parameter to select one of these four: GSLB_SERVICE_DOWN_RESPONSE_NONE – the default option, simply drops the request.
GSLB_SERVICE_DOWN_RESPONSE_FALLBACK_IP – respond with a single preset fallback IP address, which typically would point to an error page.
GSLB_SERVICE_DOWN_RESPONSE_ALL_RECORDS – return all IP addresses of all members of all pools.
GSLB_SERVICE_DOWN_RESPONSE_EMPTY – return an empty DNS response; can be used to make the client retry in certain cases.
Options and Combinations for GSLB Service Health Monitoring
Control-plane health checking only – Active data-plane health monitors are not configured for this mode. All active Controllers are configured to combine health status collected locally with the statistics collected from remote Controllers.
Combined stats are then passed from each active Controller (cluster) to its local DNS. This method is only available for members implemented as NSX Advanced Load Balancer virtual services.
Data-plane health checking only – Set
GslbService.controller_health_status_enabledto false. Each GSLB DNS performs health checks on all GSLB member virtual services (including those hosted on external sites).
Both control plane and data plane health checking – For a member virtual service to be marked UP, both control and data health should report UP. If the control-plane health check is failing due to a remote Controller being down or inaccessible, but data-plane health checking is still possible, then it alone determines the status of the member virtual service.