Advanced NetScaler Gateway GSLB Monitoring

I’ve seen a lot of high available NetScaler Gateway deployments configured with Global Server Load Balancing (GSLB) by now. However, I’ve rarely seen any of them being implemented properly in terms of monitoring on the GSLB level which resulted in the high availability being compromised in most cases.

  1. Background
  2. Solution
  3. Configuration

Now I won’t go into details about the general GSLB configuration here. If you need some background, there’s a article in the Citrix blogs that gives some good food for thoughts on the topic: Active/Active GSLB for XenDesktop – A Practical Approach

I’ll rather just focus on the GSLB monitoring part that actually watches the health of each datacenter and triggers a failover if required.


If you create a GSLB service you typically point to a virtual server configured on the NetScaler. The GSLB service will then go up or down based on the health status of the virtual server it’s pointing to.

Now that’s perfectly fine in a load balancing virtual server scenario as this server goes up or down based on whether it has backends available or not.

In a NetScaler Gateway scenario things are different though. A NetScaler Gateway is typically always up. However, a NetScaler Gateway has tons of dependencies on Active Directory, StoreFront, Secure Ticket Authorities, etc.

The following shows a typical NetScaler Gateway GSLB Monitoring setup:

Advanced NetScaler Gateway GSLB Monitoring: Typical Deployment
Typical NetScaler Gateway GSLB Monitoring Deployment

Now that’s what I’d call a single point of failure and a lot of deployments out there don’t address this.


The solution to this problem is, of course, to include all the dependencies in the GSLB load balancing decision. These dependencies are typically:

  • StoreFront
  • Active Directory (LDAP)
  • Desktop Delivery Controller (STA)
  • NetScaler Gateway availability itself

On NetScaler a monitor bound to a service by default monitors the target of the service only (as shown in the above diagram). However, you are actually able to alter that target for specific monitors and point them to different backends.

This gives you the ability to evaluate all the dependencies and could result in a setup similar to the following:

Advanced NetScaler Gateway GSLB Monitoring: Ideal Deployment
Ideal NetScaler Gateway GSLB Monitoring Deployment

All dependencies monitored, no single point of failure, great!


The configuration for this is actually very simple. The challenge is more about understanding the problem, awareness and tackling it.

To solve this just create and bind four monitors for the four dependencies and create them with the specific target IPs hard-coded into the monitor. This will cause the monitor to be triggered against that specific target IP rather then the GSLB service’s IP.

In the following example I’ve slightly simplified the monitoring using only TCP and HTTP monitors. This is sufficient as the load balancers for the dependencies itself have proper monitoring applied already. I’ve also raised the intervals and timeouts a little to give the failover some more tolerance before happening.

add lb monitor ngw.gslb.mon.ldaps.tcp.636 TCP -secure YES -destIP -destPort 636 -interval 60 -resptimeout 10
add lb monitor ngw.gslb.mon.storefront.ssl.443 HTTP -secure YES -destIP -destPort 443 -interval 60 -resptimeout 10 -respCode 200,302
add lb monitor ngw.gslb.mon.ddc-xml.ssl.443 HTTP -secure YES -destIP -destPort 443 -interval 60 -resptimeout 10 -respCode 200,404
add lb monitor ngw.gslb.mon.ngw.ssl.443 HTTP -secure YES -destIP -destPort 443 -interval 60 -resptimeout 10 -respCode 200,302


2 Replies to “Advanced NetScaler Gateway GSLB Monitoring”

  1. if you configure the netscaler with the gateway on it as a child gslb node, would you be able to just keep the monitors local instead of also configuring it on the gslb parent? Also, the next question is, does mep communicate the health of a gateways or is it just normal load balancing virtual servers? We’re looking at parent-child gslb configurations to elminate the need for monitors in both the gslb and the lb netscalers


  2. Hi Eric, configuring the monitoring on the child nodes should be sufficient. If the other node does not have local monitors configured it should take the status through MEP. Thats at least how it behaves between two regular GSLB nodes – I’m not 100% sure on parent-child. There is a setting in the GSLB site where you can change the monitoring behavior (see -triggerMonitor parameter here:

    The Gateway vServer status is communicated – same like LB. However, as stated here, the Gateway vServer Status says nothing about the actual health. Thats why I came up with this monitoring solution to have a vServer status within GSLB.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: