Citrix NetScaler… The basics continued, part five. Global Server Load Balancing!

From a NetScaler perspective Global Service Load Balancing (GSLB) can seem pretty intimidating. In short, GSLB is used as a way to manage and control the traffic flow between two (or more) separate physical locations (data centers) that are, in most cases, geographically dispersed. This can be for either load balancing purposes, high availability, fault tolerance, disaster recovery and so on. The mechanism behind GSLB is based on Microsoft DNS.

Other (related) articles from these series include:

1. Citrix NetScaler Gateway, the basics!
2. Citrix NetScaler (10.5) licensing. What’s new with Access Gateway!
3. Citrix NetScaler… The basics continued, part one. VIP’s, Monitors and other objects!
4. Citrix NetScaler… The basics continued, part two. Static routes, SNIP and MIP!
5. Citrix NetScaler… The basics continued, part three. High Availability!
6. Citrix NetScaler… The basics continued, Part four. What about SSL?
7. Citrix NetScaler… The basics continued, Part six. Content Switching!
8. Citrix NetScaler… The basics continued, part seven. Split Tunneling!

In this post I’m not going to show you how and where to physically configure GSLB on your NetScalers. Instead I want to focus on what GSLB actually is, what it can do for you, the concepts involved and so on.

Domain Name System

Since GSLB is based on Microsoft DNS, it’s important to understand how DNS works from a high level perspective before looking at GSLB in more detail. Below are the steps involved when a user / client tries to connect to a resource, by typing in a URL for example. The below overviews does not include any of the DNS caching mechanisms, which I will leave out entirely throughout this article since GSLB can be daunting enough to get you head around.

1. The local DNS client will first contact the locally configured DNS server.
2. When it does not know the answer it will forward the request to a so-called root nameserver, which handles resolution for all domains on the Internet.
3. The root nameserver also doesn’t know the answer. As a result it will contact another nameserver, the Top Level Domain (TLD) nameserver to be exact, for the “.com” subdomain.
4. The TLD nameserver doesn’t know either. Next it will contact the authoritative nameserver for the requested address.
5. The authoritative nameserver does know the address and will send it over to the client / user.
6. A connection can now be established.

Global Services Load Balancing general overview

As we’ve just established, NetScaler GSLB is based on DNS. In fact, when configuring GSLB the NetScaler will serve as an authoritative (or sub domain) nameserver for the address, or domain (there can be multiple of course) you would like to control between multiple locations.

Other setups include the NetScaler serving as a proxy for the authoritative nameservers on the internal network. So that’s why it is important to at least have an idea on what happens with regards to DNS. For the purposes of this article we’ll assume that the NetScalers will operate as authoritative nameservers and that we have two separate geographically dispersed sites, location A and B.

As a side note, to be able to make use of GSLB you will need Enterprise or Platinum licensed NetScalers.

Use cases, you have a few options

GSLB is meant to load balance traffic between multiple sites, based on DNS as we’ve learned earlier. This can be in an active / active setup or active / passive just as easy, for DR scenarios, maintenance, scale out capacity when needed and so on. Otherwise it is used to share the load between multiple locations (datacenters) or to make sure that users will always be connected to the datacenter that is closest, improving the overall user experience.

When setting up GSLB between two sites (or more) it is important to note that you shouldn’t enable HA between the local and remote NetScalers, they should be able to function independent from each other.

Components & services

No matter why we might want to implement GSLB it will always consist out the following components and services.

1. A GSLB domain, which will consist of the following…
2. Multiple GSLB sites (at least two) representing multiple datacenters and/or locations.
3. Each site will have one or multiple NetScalers, they will treat their own site as local and any of the other sites as remote.
4. MEP (Metric Exchange Protocol) and SNPM between NetScalers to keep each other up to date on
5. A GSLB service on each NetScaler (one local (max) and multiple remote when needed) this will be bound to either a load balancing or content switching vServer. Note that this could also be a NetScaler Gateway vServer.
6. A GSLB vServer, this will refer to one of GSLB services and balances the traffic between them.
7. The authoritative DNS service (ADNS), this provides the actual answers to the DNS queries made and hands it over to the GSLB vServer. Both, or multiple, NetScalers will function as authoritative nameservers within a so-called GSLB domain.

When implementing GSLB in combination with NetScaler Gateway vServers, a load balance or content switching vServer won’t be needed. The GSLB service will then point to one of the two (or more) Gateway vServers directly.

The metrics used

The GSLB selection process (Load Balancing) can be based on multiple metrics like Round Robin, Least Connection, Least Bandwidth, SourceIPhash, random and a few more. Users can also be bound to a specific location / data center if needed using a method called Static Proximity. When using RTT, Round Trip Time it will calculate the distance between the local NetScaler and the DNS server from where the initial request originated. The RTT is then used to determine the site closest to the user.

When considering GSLB, also think about where the user data is located and if both (or more) locations are equally configured and set up, which will be important if you want to load balance your users between multiple locations. While in a DR scenario it is not uncommon to only offer business critical and core applications combined with MS DFSR (remember, multiple active targets are not supported) for example.

Metric Exchange Protocol

When Load Balancing gets applied, no matter which metric is used, there must be a mechanism in place through which the NetScalers can communicate, so that they know what is going on at the remote sites. Based on the information that gets send back and forth load-balancing decisions can be made. This is where MEP, or the Metric Exchange Protocol, comes in.

I quote: MEP is a proprietary protocol used by the NetScaler appliances to exchange site metrics, network metrics, and persistence information to other sites participating in GSLB. There is a separate CTX document on MEP, which can be found here. MEP can also determine the availability of a resource, so it also detects if and when a NetScaler isn’t reachable, which also comes in handy when dealing with a DR Gateway setup for example. All traffic will then be automatically routed to the (still) active NetScaler, assuming a GSLB setup of two Sites.

In short this is what happens

After the authoritative nameserver (one of your NetScalers hosting the ADNS service) has been contacted, see the section on the DNS process mentioned earlier, the GSLB vServer will select (this is where the actual GSLB magic happens) a GSLB service representing either a load balance, content switching or Gateway vServer to reply with (the VIP). Next, the client device from where the DNS request originated will contact the VIP address and will eventually end up on one of the load balanced web servers or the NetScaler Gateway login page for example.

Visual overview

Wrap up

Hopefully this kind of gives you an idea on what GSLB is about and how it technically works from a NetScaler components perspective. As mentioned at the beginning there is a bit more to it when it comes to configuring and testing your GSLB set up with regards to DNS caching and ‘time to live’ configurations but this should get you stared for sure.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.