Jump to content
Welcome to our new Citrix community!

Is it possible to have clients access redundant, locally hosted, Citrix resources based upon location?

Greg Donham

Recommended Posts

Overall architecture question:

Is it possible to have clients access redundant, locally hosted, Citrix resources based upon location?



We have locally hosted Citrix farms in South America, North America, and Europe that are public facing.  Different locations use different access methods.  The North American facility uses 2 HA pair physical netscalers / ADC.  Europe and South America use the virtual appliance.   


The idea is that users would be routed to the nearest Citrix farm based on their location. Users in North Dakota would go to the North American farm, Users in Scotland would go to Kongsberg, etc.  The HDX protocol is good, but we've noticed some issues for users in North America accessing resources in the Kongsberg and other environments.  We are hoping this design would increase redundancy / reliability and performance.


I have some familiarity with networking, but not external networking.


ISO's for images and other resources would be shared by System Admins from general SMB file shares.  Not worried about setting up DFS-R between different continental sites at this time, but if it's preferred please let me know.


Citrix Cloud comparison:

I have seen something like what I'm talking about with Citrix Cloud, but we do not have anything in Citrix Cloud at this time. 



Link to comment
Share on other sites

To me this sounds like a simple GSLB deployment, load balancing using static proximity.


First of all, you have to set up 3 sites, one per data centre (this has to be done in every site). Create services for these sites and bind them to a GSLB-vServer. Bind a common name to it. Replicate it into all other data centres.

I would go with a cName deployment. So there would be 3 traditional A-Records: us.mycompany.com, eu.mycompany,.com and sa.mycompany.com, pointinting to these gateways. In the end we create a GSLB hostname (gateway.mycompany.com) with a TTL of (per default) 5 seconds and bind it to the GSLB-vServer. Manage the GSLB-vServer like any traditional lb-vServer. Select static proximity as a lb-methode.


The most tricky thing are the proximity tables.


There are built in location files in /var/netscaler/inbuilt_db/: Citrix_Netscaler_InBuilt_GeoIP_DB_IPv4 and Citrix_Netscaler_InBuilt_GeoIP_DB_IPv6. They have to get imported into ADC: add locationFile /var/netscaler/inbuilt_db/Citrix_Netscaler_InBuilt_GeoIP_DB_IPv4. This will create a location file at /var/netscaler/locdb/nslocation.db.


Alternatively you could also use dynamic round trip time calculation. With this methiod, each of the ADCs will send a nslookup to the DNS-Server sending the query and wait for a response. The fastest one is the nearest.


The downside of GSLB: The "client" is not user's PC but user's DNS server, as all of GSLB is based on DNS. That's fine, as long as users don't use Google's DNS services or similar ones. This will mess up things.




Johannes Norz


  • Like 3
Link to comment
Share on other sites



Excellent explanation Johannes!

Here's how we go around the possible issue of the proximity with GSLB alone:

We use a DNS hoster that is capable of providing dynamic responses, for instance, based on geolocation. You can still let the ADC do an extra proximity check, in case the DNS response was off somehow.







Link to comment
Share on other sites

  • 4 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...