Zones – We had zones in 6.5 IMA and now we have zones for the first time under the newer FMA architecture with XenApp/XenDesktop 7.7+.
The reason for zones has got to do with the complexity involved with managing a large site covering different parts of the globe. Where is the best place for components such as DDCs and VDAs. Do you have one or two datacenters or do you have to spread out further? Who manages all these components? Should VDA’s stay as local as possible to each region? Should I just deploy different Citrix sites for the large regions? Many enterprise organisations have multiple Citrix sites spread out across the globe, as doing so overcomes latency issues where components are dependant on other components that aren’t in the same datacentre, for example SQL server.
Now with 7.7+ you can separate components such as DDCs, Machine Catalogs, and Hypervisor connections in to zones. These zones could represent your companies office locations/datacentres to further help meet the needs of the users working there.
Your site will have a primary zone, followed by secondary zones that represent your needs such as secondary zone per datacentre.
The primary zone must contain the site SQL database and atleast one DDC. The DDC should be local to the SQL database i.e. in the same datacentre so latency is low.
The secondary zone can contain DDCs, Hypervisor connections and Machine Catalogs containing VDAs that should be local to that zone. Connectivity between these components must be good, and as a result are expected to be local to eachother. When it comes to power management, VDA registration etc. the DDCs located in the same zone are preferred. VDA machines although prefer to register with DDCs in their own zone, do have the ability to register with DDCs in the primary zone (fallback) but will not register with DDCs in other secondary zones.
Primary zone components are expected to have some connectivity to all secondary zones, it is important especially when I have just mentioned that VDA machines can fallback from secondary zones to primary. However secodary zones are not expected to have any communication with other secondary zones.
Secondary zone DDCs will communicate with SQL and the site database directly so there should be reasonable connectivity in place, remember SQL resides in the primary zone. How good the connectivity is depends on the number of VDAs and users etc. that will exist in the zone. Citrix have posted some best estimate guidelines on connection requirements based on number of VDAs and sessions up to XenApp & XenDesktop 7.11.
Picture from Citrix.com
When XenApp and XenDesktop 7.11 was released, Citrix improved the way DDCs spoke with SQL, and such the SQL code was optimised. This allows for greater latency between the DDC and SQL than ever before. Tests showed how 7.11 with 250ms latency to the SQL server outperformed a 7.7 version with 90ms latency to SQL. These tests involved brokering requests and launching sessions. You can read more here https://www.citrix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements/
Zones make use of the Locah Host Cache feature. This means that if the site SQL database server goes offline the DDCs in your respective secondary zones will retain the ability to broker users on to applications and desktops as long as the VDAs are still accessible from the DDCs in the secondary zone.
It is recommended that StoreFront is deployed to each secondary zone you create. This is so that primary zone outage will not affect the secondary zones. A maximum of 10 zones is recommended to avoid performance degradation.
To create a zone, navigate to Studio -> Zones -> Create Zone.
Specify a name and the components you want to move to the zone. Click Save.
The new zone is created and shows the component members. You can move items to and from different zones if needed. 
mak
June 7, 2017We have Windows 2008 R2 running XD 7.9 and VDA running with Xen Desktop 7.13 . Every day once the Xen Desktop 7.13 Initiates a reregister with the Delivery Controller This happens in the Secondary Zone. Primary Zone in Cloud.
VMware tools are updated. CPU and Memory Utilization policy set to 90 % . Validated if there are no trailing name spaces & Disabled the Auto Client reconnect as Session Reliability is On . Still no fix . Sent logs to Citrix Vendor . Still no fix .
Any help is appriciated
mak
June 7, 2017We have Windows 2008 R2 running XD 7.9 and VDA running with Xen Desktop 7.13 . Every day once the Xen Desktop 7.13 Initiates a reregister with the Delivery Controller This happens in the Secondary Zone. Primary Zone in Cloud.
VMware tools are updated. CPU and Memory Utilization policy set to 90 % . Validated if there are no trailing name spaces & Disabled the Auto Client reconnect as Session Reliability is On . Still no fix . Sent logs to Citrix Vendor . Still no fix .
Any help is appreciated
George Spiers
June 7, 2017VDAs register with DDCs in the same zone, if possible. Are you saying that secondary zone VDAs re-register every day?
Pavan Ayyagari
July 13, 2017Hello George,
Thank you for the great article. I’m trying to setup the same kind of scenario between two sites having SQL AAOG, DDC,SF in the primary site and DDC,SF at the secondary. I have site-site VPN between two sites and the ping response is about 26-28ms. Do you think the latency between both sites is acceptable and will have no issues in terms of failover etc?
Hope to hear from you soon.
Thanks&Regards,
Pavan Ayyagari
George Spiers
July 13, 2017Hi Pavan, performance factors on the number of VDAs and users that will be on your farm and brokering connections that occur concurrently throughout the day. For example Citrix state that 50ms RTT latency is acceptable for 500-1000 sessions. Performance also depends on your version of XenApp/XenDesktop. Versions 7.11 Curent Realease and 7.6 CU3 LTSR and above come with SQL/DDC communication improvements and perform better under higher latency than previous versions did. I wouldn’t expect you to have any problems with this latency however it is always advisable to test yourself.
Pavan
July 13, 2017Thank you very much Gorge. Appreciate your advise here..
Pavan
July 13, 2017One more thing is that I have a standalone esxi host and no vcenter in the satilite zone and want to check can I manually create the VDS’s and add it to the delivery group? I think having vcenter might be a over kill in this situation? Thanks Gorge.
George Spiers
July 13, 2017Yes you can add machines manually built to a Machine Catalog and likewise machines provisioned through MCS/PVS. Without vCenter you will lose power management functions.
Pontus Holst
March 13, 2018Optimal HDX NetScaler routing at a zone level thats clear but not how we solve “routing at netscaler” level with ONE netscaler in Primary zone.
We dont know where the users are coming from (location) – Primary zone or secondary zone (zone2)
We are using GSLB.
SCENARIO
Primvary zone (Zone1)
2 netscaler
2 ddc
2 storefront
sql
hypervisor connection
Secondary zone (zone2:
2 DDC
hyrpervisor connection
:0)
George Spiers
March 13, 2018You could configure GSLB so that connections from IPs within Zone 2 route to one of the two NetScaler’s in zone one.
NickC
May 10, 2018Hi George, quick question about a specific configuration. This is a XA6.5 migration to 7.15LTSR. Due to many reasons I can’t go into here, some of the infrastructure was unsuccessfully migrated to Azure (not by myself btw 🙂 ), so currently some apps and desktops are running from XA6.5 servers in Azure, with separate apps and desktops running from on-prem XA servers. This configuration has to remain due to a lot of backend services being in Azure, although the desire is to move back to on-prem where possible onto a Nutanix platform.
My question is, if there is no crossover of desktops and applications (ie no published resource spans both Azure and on-prem) what would you do with zones? Zone preference isn’t required in this instance. NetScalers are physical on-prem appliances. All users are on-prem, or remote via the NSG. My thoughts are single XD site, with single zone, 2 host connections (1 Nutanix, 1 Azure), with respective machine catalogs on the relevant hosts in Azure or on-prem, and therefore the VDAs/published resources on the respective host platform. I would probably put a single Delivery Controller in Azure for the VDAs there to register against first. I *could* use 2 zones, but in my mind I don’t think they’re necessary, other than for tidiness. Any thoughts? Happy to be convinced either way. Thanks.
George Spiers
May 13, 2018Hi Nick. Since you have resources localised to datacentres then I would personally use one single site with no zones. It does not seem that your deployment is too complex. Factors can also depend on latency between on-premises and Azure, and the size of the deployment, how many VDAs and Delivery Controllers you have and so on. You might want to keep 10k VDA registrations against Azure Delivery Controllers, but if you only have a handful of VDAs the concern may not be so serious.
Hope this helps.
NickC
May 14, 2018Thanks George. I could have been convinced either way; 1 site with 2 zones or 1 site with 0 zones. As the eventual plan is to move it all the VDAs back on-prem 2 sites would have been overkill. There are only about 20 VDAs in Azure with max about 200 users. The bulk of the VDAs/users are on-premise. This is an interim phase to basically upgrade what they have to 7.x as 6.5 goes end of life in less than 2 months so they’re panicking to get the upgrade done. Thanks again. Nick
Raj
September 28, 2018Hello George I am reading about zone and trying to find out what happenes to vda in primary zone when primary zone goes offline. According to citix documents it says connection will degraded but it does not mention about if vda will go to unregistered state or will it still be registered. Will it keep trying to register with DDC in primary zone or stay unregistered until primary zone comes online. Thanks for your help
George Spiers
September 28, 2018If all the DDCs have failed then it will ultimately become unregistered. If one of the DDCs remains available or comes online, the VDA will register with that DDC.
Jeremy
November 12, 2018George,
I’m having trouble finding documentation on Storefront servers and zones. How does a client know to connect to the local storefront if WAN connectivity fails?
George Spiers
November 12, 2018Well there is nothing in Zones that needs configured when it comes to StoreFront.
If you have a secondary Zone that represent a remote datacentre, install StoreFront servers inside the datacentre, and configure them to speak to Delivery Controllers in the same datacentre. Repeat for other Zones, or use something like GLSB.
Juan
June 2, 2019Hello, very interesting article. I have a question about that…As we have the problem like the principal zone could down and we would have problem to access when the new users are trying logon.. Can we have a principal zone across PODs without workers (VDAs) and several zones distributed in all PODs with the VDAs? Similar like a lot of architectures of Active directory, a domain for control and other domains for resources..
I mean, if the principal zone is only a CPD and this CPD is down, we would haven’t access to Studio, etc..So if we have this principal zone across CPDs and if we haven’t VDAs into principal zone, we would have access to Studio and no have problem with the registration VDAs because all VDAs will be in the satellite zones. It’s works?
Thanks
Juan
George Spiers
June 4, 2019Hello. You could have a Primary zone spanning multiple PODs. Just keep in mind the latency between each of these PODs. I’m not sure if your PODs are regionally close or not. I do know some customers do deploy a Primary zone with no VDAs, and VDAs only exist in the Secondary zones.
Note that you can only have one SQL instance though, preferably in an AlwaysOn configuration. This SQL instance will have to reside in the primary zone. If it goes down, your users should continue to have access to their applications and desktops as VDAs maintain a registration to the DDCs in their respective Secondary zone, and Local Host Cache mode would be initiated.
Juan Ignacio Jimenez
June 4, 2019Thanks George!,
My customer don’t have problem with their PODs about latency, between 50 and 100ms between PODs. My idea about the AlwaysOn was one node in each PODs and the ShareWitness in a third POD.
Thanks
Juan
Juan Ignacio Jimenez
June 4, 2019Sorry, between 10 and 20ms…, 50/100 was between 2 PODs with the POD where is located the Shared Witness.
Regards
Juan
George Spiers
June 5, 2019No problem Juan. Local Host Cache is your friend in the event that SQL goes down. Just be sure to at least double-up on your Delivery Controllers at each secondary zone.
vrajesh.r
April 9, 2020Hi George,
Thanks for the wonderful article.
I am planning to build a Citrix Farm in AWS Environment EU West1. The requirement is to build with Active-Active-Passive mode between 3 Availability zone EUwest1a,b,c. The plan is to Put AZ1 and AZ2 as Single primary Zone and Az3 in passive a DR zone in Citrix. I don’t have requirements for user sessions to start from a specific zone. They can launch from either AZ1 or 2. Only when Both AZ goes down Az3 should take the load.
I am expecting about 200 odd Concurrent users .
My questions
1. Do you think this approach to use Citrix Zones is correct? All Availability zones sit in single EuWEST1 and expecting latency below 50 MS.
2. How do I make sure the application is starting only from Primary zone VDA and only when All primary zone VDA is down, the session should start from DR zone VDA.
3. In an Application Properties, in Group section I have delivery groups of Primary and secondary zone with Primary taking priority zero and DR taking priority 1. Does this mean always primary DG is prefered when an application is launched ?
George Spiers
July 14, 2020Yes given the latency I think that is OK.
To make sure sessions are launched in the DR zone only when Primary goes down, when you create an Application, in the Application Settings dialog box under the ‘Zone’ section, select the ‘Use the selected zone to determine where this application launches’ to select your Primary zone, and do not check the box ‘Launch the application only in the selected zone’.
Nisar
February 24, 2021Hello George,
We are in the process of setting up Citrix remote PC delivery model 2000 physical desktop residing at LAN network all branches are having connectivity with DC and DR simultaneously requirement is to set up disaster recovery environment for Physical desktop when all the management component failed at DC my physical desktop should be able to register at DR DDC without any manual intervention can Zones fulfill my requirement what is the best approach with less manual intervention since all are physical VDA also what all management component I should place at DR i.e. SQL, DDC, SF, NS, etc.