Follow the below steps to configure the GSLB service for the above scenario:

Configure using the individual VIP IP addresses, that is, VIP1 IP1, VIP2 IP2, and so on.

  • This permits configuring individual VIPs for the multi-VIP virtual service. If it is desired to add all the VIPs under GSLB service, then all the VIPs need to be added manually.

  • When a client sends a request for avi.app.gslb.com, the request first lands on the NSX Advanced Load Balancer DNS virtual service, which then selects the optimal endpoint based on the configured GSLB algorithm.

  • The DNS virtual service then responds with one of the VIPs’ IP addresses.

  • Since each VIP has been explicitly added in this method, NSX Advanced Load Balancer uses datapath health checks to monitor the health of each member individually.

The second method outlined has a few limitations:

  • A new VIP might be added to a multi-VIP virtual service (that is, VS1 IP3 is added to the pre-existing 2 IPs). In that case, one must manually edit the GSLB service and add the new VIP into the GSLB pool.

  • Being a multi-VIP virtual service, there might be a case where IP addresses of the VIP are changed, possibly leading to inconsistency, unless the pool is not manually changed in the GSLB service.

    An NSX Advanced Load Balancer GSLB pool member is a virtual service (with associated VIP:port_number). The configuration of such a member requires the user to uniquely identify the site-id, the virtual service within the site, and the corresponding VIP of the virtual service. The relevant parameters are cluster_uuid, vs_uuid, and GslbPoolMember.ip within the GslbPoolMember object.

    The site administrator changes the controller's local configuration of the particular virtual service such that its VIP1 is changed from IP2 to IP4.

    The situation: Though the local VIP IP4 is operational, its address is not (yet) known to the GSLB configuration. It is no longer advertised as part of the global app and references to IP2 are invalid.

    The GSLB leader and active members detect the discrepancy between the VIP (IP2) and VIP (IP4). The NSX Advanced Load Balancer then disables the GSLB pool member in question and notifies the administrator that the configured and operational VIPs are out of sync.

    For more information, see Changing NSX Advanced Load Balancer Controller Cluster Configuration in the VMware NSX Advanced Load Balancer Administration Guide.

    To avoid these situations, configuring the GSLB pool members for the Multi VIP scenario using the first method is recommended. The advantages of the first method are:

    • There is no need to add individual VIPs.

    • There is no inconsistency in the event, the IPs change on a virtual service level.