Jump to content
Welcome to our new Citrix community!
  • 0

Zone behavior in a DR scenario

Scott Gibson


Hi all,


We have a Citrix LTSR 7.15 CU4 environment with 2 zones, Primary and Secondary, that are delivering PVS-based shared hosted desktops (Windows Server 2016).  We use these zones active/active in normal scenarios.  Each zone has its own set of delivery controllers and storefront servers, with Netscalers (running NS13.0 36.27.nc) in each zone that are configured with GSLB.  We then use AD groups based on the state the user is located in to decide whether they hit Primary or Secondary (this is the default "preferred" method, so if there are no VDAs available in the zone it kicks users over to the other zone).  This all works fine in day to day operations. 


We recently however performed a DR test and it did not go well.  Our main delivery group has 50 VDAs at Primary and 50 VDAs at Secondary.  We drop the connection between Primary and Secondary and force a branch to VPN over to the Secondary zone.  Our thin clients then are provided the IP address of the Netscaler at the Secondary zone due to the GSLB setup, which sends them to the Storefronts at the Secondary zone which then contacts the Delivery Controllers at the Secondary zone.  So far, all is well. At this point the Delivery Controllers are in Local Host Cache mode due to the loss of connectivity to both the primary zone and the DB.  As a user that is normally connecting to a primary zone VDA due to my group membership, the Delivery Controllers at the Secondary zone (in LHC mode) continue to try sending me to the Primary zone.  This, of course, fails, because those VDAs are not reachable.  No matter how many times I try, it continues to keep sending me to random VDAs at the primary zone.


I expected that the Delivery Controller at the Secondary zone would realize the VDAs at the primary zone were down and start sending users to VDAs at the secondary zone.  Obviously not.  We even tried adding the X-Citrix-ZonePreference header with the Secondary zone name to the Netscaler LB but that made no difference.  I have read that the header-based ZonePreference method is the lowest priority (by default).  If I changed that priority order, using the ZonePreferences property (e.g. {UserLocation, ApplicationHome, UserHome}), would that fix this issue?  Are there any other options or is something misconfigured that is causing this issue?


Would I just be way better off not using zones in this scenario and rather use 2 sites instead?  I must admit I am not crazy about not having Studio during a DR event...  We use Zerto for replication and we tried bringing the DB server over but that didn't make any difference.  I suppose we could bring over one of the primary zone's Delivery Controllers over too and then that would give us a bit more to work with (the Primary Zone Delivery Controller would know and be able to report that all of the VDAs at the Primary Zone are down, and I imagine everyone would be sent to the Secondary Zone at that point).  But that seems to defeat the purpose of Zones at that point and we might as well just be using separate sites.


Ideas?  Thoughts?  Recommendations?



 - Scott

Link to comment

3 answers to this question

Recommended Posts

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...