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.

Background

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:

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

Solution

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:

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

Configuration

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 10.100.100.101 -destPort 636 -interval 60 -resptimeout 10
add lb monitor ngw.gslb.mon.storefront.ssl.443 HTTP -secure YES -destIP 10.100.100.102 -destPort 443 -interval 60 -resptimeout 10 -respCode 200,302
add lb monitor ngw.gslb.mon.ddc-xml.ssl.443 HTTP -secure YES -destIP 10.100.100.103 -destPort 443 -interval 60 -resptimeout 10 -respCode 200,404
add lb monitor ngw.gslb.mon.ngw.ssl.443 HTTP -secure YES -destIP 10.100.100.100 -destPort 443 -interval 60 -resptimeout 10 -respCode 200,302