Introduction

A-D-C, It’s easy as

1-2-3, as simple as

GSLB, A-D-C, 1-2-3

… yeah I’ll stop right there.

Big shout out to Robert Sampson resident LinkedIn Meme Lord for the cover photo ;).

Do you use Citrix GSLB, F5 GTM, or some other D-list DNS-based intelligent load-balancing solution in front of Citrix Gateway? Chances are you are not accommodating for numerous failure scenarios that will impact the integrity of Citrix Gateway availability.

When we design geo-redundant Citrix Gateway solutions for ICA proxy, we typically include a provision for a seldom talked about scenario when using Global Server Load Balancing (GSLB) on Citrix ADC to front Citrix Gateways. That scenario is compensating for the fact that almost nothing will take a Citrix Gateway vServer offline except for the appliance being down or otherwise unavailable due to a network outage, or someone unbinding a certificate from the vServer.

That can understandably pose problems if say… your local StoreFront server VIP became unavailable or another local dependency such as LDAP, RADIUS, XML, STAs, etc. (aka the “scenario” I eluded to). StoreFront ends up being the most common consideration as users might authenticate successfully to Citrix Gateway and then be dropped into a black hole with little recourse to get in and do their work, rendering default GSLB health monitoring via MEP pretty much useless unless the appliance was offline (power or network).

To rectify this operational “blind spot”, we recommend GSLB-centric monitors for Citrix Gateways to resolve this and ensure that an outage on key dependencies will ensure Citrix Gateway will fail over to another data centre. This is in alignment with Citrix Consulting’s design and auditing guidance as well, and something in and outside of Citrix our team looks for when conducting Citrix ADC audits.

Implementation

How do we monitor something that isn’t the direct service we’ve configured for GSLB? Ah, well that is one of the many virtues of GSLB. GSLB provides us an abstraction layer over the underlying service in terms of its health monitoring. Without custom monitors defined, MEP communication between GSLB Sites will communicate up/down states. But we can also add custom monitors to the “GSLB Services” config to override or compliment MEP telemetry to say… fail the service if a special monitor we’ve bound to the GSLB service fails, special in the sense that it does not need to monitor anything directly related to the underlying service, but something else entirely. Be it a custom monitor that is checking an external parameter for data that if not found, fails the monitor (and thus the service), or in our case, a Citrix Gateway dependency such as StoreFront by customizing the monitor to check a specific IP address.

The part is key here, as by default a monitor bound to a service or service group will monitor the IP of the server(s) associated with it. Also, this is entirely independent of the underlying service monitoring, it does not affect the health of the standard load-balanced VIP in From Traffic Management > Load Balancing > Virtual Servers.

In the following steps, I will illustrate how to configure this for StoreFront, but an administrator can add other custom monitors such as XML VIP, LDAPS VIP, RADIUS VIP, etc. to the GSLB service as well in a similar fashion, so should any of them fail (which may result in direct impact to the Citrix Gateway being able to process user logins and enumerating resources in that location) GSLB will fail the GSLB service and direct traffic elsewhere.

Step 1

We start out by crafting a custom GSLB monitor. In my case, I am continuing to use a StoreFront monitor. This may seem strange as it’s effectively an L7 monitor probing a StoreFront VIP that is already using an L7 monitor but this shouldn’t do any harm. With that said, I have been advised that it may be optimal to defer to basic and intelligent monitors for these GSLB health monitors in most cases. Technically for these GSLB custom monitors, a more primitive port probe may suffice provided the underlying destination IP is already being monitored by an L7 monitor. For APIPA VIPs, you may need a ping monitor, however, you’ll need to adjust the default ICMP Response behaviour on the IP of the ADC which you can quickly learn about here.

From Traffic Management > Load Balancing > Monitor

Click “Add”, and fill out a STOREFRONT monitor aligned to your environment specifications such as “Secure” (I’d hope!), Store Name.

In “Advanced Parameters”, in the first field “Destination IP”, put the IP address of your local data centre’s StoreFront VIP. This will direct the monitor to monitor that specific IP, and not whatever IP it inherits when bound to a service or service group.

Step 2

With the monitor created, navigate to Traffic Management > GSLB > GSLB Services. Edit the GSLB service that is dependent on the local StoreFront VIP’s availability, click “Monitor” under “Advanced Settings” on the right-hand side, and bind the custom monitor.

Step 3

Confirm the GSLB monitor state is “UP”. If it is not. Confirm the IP address entered in the monitor and the “Store” name is valid, and confirm ports are opened (if needed) for the monitor.

Step 4

Repeat for the other GSLB Site’s local GSLB services at each GSLB Site’s ADCs, and repeat the process for other custom monitors that might be relevant to add to the GSLB configuration to enhance availability monitoring and minimize user impacts from dependency failures within a location.

Final Thoughts

Another item I often add to these configurations is an https monitor (no custom destination IP needed, as we want to monitor the IP of the GSLB service) that accepts 302 messages. The reason being is as soon as we add these custom monitors, they take priority over MEP as documented in CTX251348. So if an administrator needs to force traffic to another data centre, disabling the Citrix Gateway vServer may not result in GSLB ceasing to send traffic to that disabled site (and an administrator may not remember to disable the GSLB service instead). By adding that https binding, we can ensure that the GSLB service does fail as the https service will fail, and MEP status will be properly communicated to other sites in the mesh.

I tend to only add the custom GSLB monitor configuration to the local appliance’s GSLB services. The logic being, MEP should communicate the “down” status if the GSLB service fails, to the other GSLB Sites in the mesh. If using GSLB Sync. this might be a problem out of consideration for firewall rules that might need to be in place in each GSLB Site to ensure NSIP or SNIP (depending on monitor type) can get to the local VIP of the remote Site’s service.. such as StoreFront. Something to bear in mind. I am not saying using GSLB Sync is bad, or anything of that nature (in large complex GSLB meshes we’ve been involved in, it’s the difference between consistent global operation and a total dysfunctional rat’s nest of human error), but if planning to use the monitoring configs on local and remote GSLB services across the mesh, bear in mind the need for monitor communication on L3.

Hopefully, this quick tip will assist customers and partners in enhancing their GSLB monitoring to detect more failure scenarios and avoid user impacts.

Subscribe