There are multiple methods that we can use for load balancing:

There are two options here that are specific for GSLB: STATICPROXIMITY and RTT. STATICPROXIMITY can use a custom location database to determine where to send clients, or we create our own custom entries.

In order to use a location database, we have to buy one from commercially configured third-party databases such as maxmind.com (https://www.maxmind.com/en/home), for instance.

In order to use custom entries, we just have to add an IP-range and set a location qualifier. By default NetScaler uses the following qualifiers for a location database:

continent.country.region.city.isp.organization

For instance if we have an IP-range that we know is in Norway we could add the following custom entries:

Add location 192.168.0.0 192.168.0.255
EU.NO.AKERHUS.OSLO.TELENOR.CITRIX

Now, after we have added the location, we have to set NetScaler to use the location parameter. So let's say that we want traffic coming from that particular IP address range to communicate with a particular NetScaler; we need to set the location parameter to use one of the qualifiers that we entered. This can be done using one of the six different qualifiers.

For instance:

set locationparameter -context custom –q2label NO

This will set up NetScaler to use a static, proximity-based decision and all addresses coming from within that range will get a response from the one with the location parameter set. If an IP address outside that range tries to communicate, NetScaler will fall back to round-robin-based load balancing.

RTT is a dynamic proximity load balancing method that measures the delay between a client's local DNS server and the data resource it is trying to access. After it has measured the RTT, NetScaler then exchanges the metric with the other sites using MEP and then sorts out the RTT between the different sites and the client. Then it makes its load balancing decision and will dynamically redirect the client request to the GSLB site that has the lowest RTT. NetScaler uses different probes to determine the RTT. By default it uses PING first; if that fails it tries a DNS UDP probe. If that does not work it tries a DNS TCP probe.

If all probes fail or RTT metrics are not available, NetScaler will fall back to round-robin load-balancing.

If we want to change the order of the probes we can do so using the following command:

set gslb parameter -ldnsprobeOrder DNS PING TCP

This might be necessary for instance if we do not allow external PING traffic via the firewall or UDP.

After we have configured the load balancing method we have to add a domain to the vServer. That can be done under the domain pane in the vServer options.

When we add the domain name, NetScaler will automatically create an A-record for it under DNS records. This will then be used by the ADNS service to respond with the domain name to clients.

Now after we have added a domain to the virtual server, we can verify that the services are up by using the command:

Show gslb domain test.local

We can also verify that the address record is set to a GSLB site by using the command:

Show addrec test.local

It is important that we also create the virtual server on the second site and add the same domain name, or else MEP might not work properly. As it might be cumbersome to do the same configuration on multiple NetScalers, Citrix has created a Sync option to sync configuration between a master NetScaler and other remote sites. This can be done using the command:

Sync gslb config

It is important to note that this option uses SSH to communicate and therefore if we have a dedicated site IP setup we need to enable that IP to use SSH, which is not enabled by default on GSLB IPs or SNIP addresses. This can be done in the GUI under System | Network | IPs. Choosing the GSLB site IP, Edit, choosing enable management access and adding SSH.

The option will also initiate from the NSIP from the master NetScaler (the one we initiate the synchronization from).

After the synchronization is done, we can verify the status by using the command:

Show gslb syncstatus

Now that this is done we can verify it by setting our client IP address DNS server to use the NetScaler ADNS IP. Then we can use nslookup, as shown in the following screenshot, to verify that the records we get are the virtual services in the GSLB setup.

Since my GSLB site setup is based upon round-robin I will get both of the records. If I set the persistence to static proximity and use the location parameter, I will be redirected to the one that has the closest qualifier set.

This setup used an active/active GSLB configuration, which means that traffic would be distributed between both sites. In some cases, we might also use an active/passive setup for disaster recovery purposes.

In order to set up an active/passive GSLB configuration, we first need to set up a GSLB site configuration

First we need to add the two sites that will act as active/passive, by using the following CLI commands:

add gslb site sitePRI LOCAL 192.168.0.200 -publicIP 192.168.0.200
add gslb site siteSEC REMOTE 192.168.0.100 -publicIP 192.168.0.100

Then we run the following command to add a vServer to the GSLB site located on the primary site:

add gslb vserver RPIserver http -lbmethod RTT

Now we need to add a service that will serve content from the primary site:

add service serverPRI 192.168.0.201
add lb vserver vserverPRI HTTP 192.168.0.202 80
bind lb vserver vserverPRI serverPRI

Now that we have a load-balanced vServer we need to bind this as a GSLB service and then attach it to the GSLB vServer on the primary site:

add gslb service gslb-srv-PRI 192.168.0.202 HTTP 80 -sitename sitePRI
bind gslb vserver PRIserver -servicename gslb-srv-PRI

And then lastly we attach a domain name to that particular vServer:

bind gslb vserver vserverPRI -domainname www.test.com

Now that we have successfully created the primary GSLB site and have configured it to have a GSLB service and respond to a domain name, we have to configure it to have a secondary site as backup. First we need to add a new GSLB vServer:

add gslb vserver SECserver HTTP

Then we need to attach a service to that GSLB vServer:

add gslb service gslb-srv-SEC 192.168.0.101
bind gslb vserver SECserver -serviceName gslb-srv-SEC

Then lastly we need to configure the backup parameter on the primary VServer:

set GSLB vserver PRIserver -backupVServer SECserver

Now we need to repeat the configuration on the secondary site; if we do not do this the information exchange will not happen and requests might fail if the primary goes down.

First we need to add the sites:

add gslb site sitePRI REMOTE 192.168.0.200 -publicIP 192.168.0.200
add gslb site siteSEC LOCAL 192.168.0.100 -publicIP 192.168.0.100

Next add a GSLB vServer that will act as the backup for the primary on the other site:

add gslb vserver SECserver http -lbmethod RTT

Now we need to add a local service on the NetScaler and then bind it to a load balanced vServer:

add service serverSEC 192.168.0.101
add lb vserver vserverSEC HTTP 80
bind lb vserver vserverSEC serverSEC

Now that we have created the load-balanced vServer we need to create it as a GSLB service:

add gslb service gslb-srv-SEC 192.168.0.101 HTTP 80 -sitename siteSEC
bind gslv vserver SECserver -servicename gslb-srv-SEC

And now we need to add the GSLB vServer on the primary site so we can reference it:

add gslb vserver PRIserver HTTP

Then we attach a service to it:

add gslb service gslb-srv-PRI 192.168.0.201
bind gslb vserver PRIserver -servicename gslb-srv-PRI

Now we need to bind a domain name to the GSLB vServer on the primary site:

bind gslb vserver PRIserver -domainname www.test.com

Lastly we configure the secondary vServer to act as a backup for the primary:

set GSLB vserver PRIserver -backupVServer SECserver

GSLB is a complex feature that might often lead to headaches if not properly configured. Therefore, it is crucial to know where to start if we need to troubleshoot a configuration.

Some basics to check for if GSLB is not working or if we cannot perform the configuration: