This article explores the configuration of a simple, single-site GSLB (global server load balancing) using citrix netscaler. While a single site GSLB may not seem to be extremely useful considering that the normal use case for GSLBs are geographically distributed datacenters, smaller setups will find it useful if they use two ISPs with separate IP address spaces. GSLB works on the foundation of DNS resolution, so this lends itself nicely to having to serve different IP addresses according to server health or number of connections, etc…
For the purposes of the article, I will leave out the details of having dual ISPs, the NAT setup to support this, and instead focus on the citrix setup. The testlab setup consisted of the following:
In this particular exersizie, I have setup the netscaler as a single GSLB site, using a DNS proxy setup. The aim of this exersize is to have the netscaler return different IP addresses according to the health of the GSLB services in question (in the example above, these are 192.168.11.104, 126.96.36.199 and 188.8.131.52) for a given FQDN (which in this case will be blog123.davidvassallo.me). Further, I preferred the DNS proxy setup over the Authoritive DNS setup to allow system administrators to continue to administer DNS as they normally would, using their windows or linux DNS servers. In such a DNS proxy setup, the citrix netscaler will answer for any records that are manually configured on the appliance, while passing any unknown queries to the backend DNS servers.
1a. Setup a normal load balancing setup using DNS servers.
This will result in a load balanced setup using two backend DNS servers. TO do this, follow the normal citrix procedure for defining load balancers, and you should end up with something a normal, virtual server which loadbalances to one or more backend DNS servers using your load balancing algorithm of choice. In my case, the DNS virtual server was given an IP of 192.168.11.102
1b. Setup a proxy DNS zone with appropriate records.
Since we defined a cluster of DNS servers, we do not need to define all records for the domain. Any unknown queries will be forwarded to the DNS cluster. So, in this setup we only need to define those DNS records that will be used by the GSLB setup… in this case, blog123.davidvassallo.me. To do this we first define a proxy DNS zone:
Traffic management > DNS > zones
Add a new zone, and ensure that proxy mode is enabled, for example:
2. Setting up the GSLB site
A GSLB site requires either a SNIP or a ADNS IP. Since we are not using ADNS, we first configure a SNIP which will be later assigned to the GSLB site. To do this:
System > Network > IPs > IPv4 > Add
Define a new IP and as an IP Type select “Subnet IP” . In my case, we set this to 192.168.11.108. To setup the actual GSLB site, first ensure that the GSLB feature is enabled (system > settings > configure advanced features) and then configure the IP address set above via:
Traffic management > GSLB > Sites > Add
Note that the metric exchange sessions have all been disabled, and that the site IP address is the same as that configured for the SNIP configured previously.
3. Define GSLB services.
These are very similar to the normal load balancing services. However, a GSLB service can be either a standalone server, another netscaler, or a previously defined Virtual Load Balancing server. In my example below, I have defined two standalone servers (blog_1 and blog_2), and one previously defined virtual server (blog_3).
Note how the standalone servers have “effective state” marked as down. This state is read from the state of the virtual load balancer server – but only if such a server exists. In the case of blog_1 and blog_2, there are no virtual loadbalancer services defined since they are standalone servers. Blog_3 on the other hand, is actually pointing towards a virtual server I had previously defined under Traffic Management > LoadBalancing and so the effective state is green. However, state in GSLB overrides effective state, so all three servers are considered healthy
4. Defining GSLB virtual servers
The virtual server is responsible for two things:
- Binding the GSLB services together
- Defining which FQDNS these services will respond to.
To define a new GSLB virtual server, go to:
Traffic management > GSLB > Virtual Servers
Add a new server, and in the services tab, select all the previously defined services that will make up part of this virtual server. Since we are serving up a website, ensure the DNS record type is set to “A” and the service type is set to “HTTP”. Under the domains tab, add an FQDN entry that this virtual server will respond to, such as:
For the purposes of demonstration, I set the method to round robin. Apply all the settings
Testing can be accomplished by simply setting your DNS IP to the IP address of the DNS virtual server defined in step 1 (in my case, 192.168.11.102), and running DNS queries against it. If this were an ADNS setup, you would set the DNS server Ip to be the GSLB site IP (192.168.11.108). So for example, in the below you can see that querying for blog123.davidvassallo.me returns a different IP each time, each address belonging to one of the GSLB services we previously defined:
Further testing to make sure the DNS proxy is working can be achieved by sending a DNS query for a record that is not defined on the citrix appliance, such as blog.davidvassallo.me