Citrix Zones

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.

1-min

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

Specify a name and the components you want to move to the zone. Click Save.

3-min

The new zone is created and shows the component members. You can move items to and from different zones if needed.   4-min


25 Comments

  • mak

    June 7, 2017

    We 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

    Reply
  • mak

    June 7, 2017

    We 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

    Reply
    • George Spiers

      June 7, 2017

      VDAs register with DDCs in the same zone, if possible. Are you saying that secondary zone VDAs re-register every day?

      Reply
  • Pavan Ayyagari

    July 13, 2017

    Hello 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

    Reply
    • George Spiers

      July 13, 2017

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

      Reply
      • Pavan

        July 13, 2017

        Thank you very much Gorge. Appreciate your advise here..

        Reply
  • Pavan

    July 13, 2017

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

    Reply
    • George Spiers

      July 13, 2017

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

      Reply
  • Pontus Holst

    March 13, 2018

    Optimal 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)

    Reply
    • George Spiers

      March 13, 2018

      You could configure GSLB so that connections from IPs within Zone 2 route to one of the two NetScaler’s in zone one.

      Reply
  • NickC

    May 10, 2018

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

    Reply
    • George Spiers

      May 13, 2018

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

      Reply
      • NickC

        May 14, 2018

        Thanks 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

        Reply
  • Raj

    September 28, 2018

    Hello 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

    Reply
    • George Spiers

      September 28, 2018

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

      Reply
  • Jeremy

    November 12, 2018

    George,

    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?

    Reply
    • George Spiers

      November 12, 2018

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

      Reply
  • Juan

    June 2, 2019

    Hello, 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

    Reply
    • George Spiers

      June 4, 2019

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

      Reply
      • Juan Ignacio Jimenez

        June 4, 2019

        Thanks 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

        Reply
        • Juan Ignacio Jimenez

          June 4, 2019

          Sorry, between 10 and 20ms…, 50/100 was between 2 PODs with the POD where is located the Shared Witness.

          Regards
          Juan

          Reply
          • George Spiers

            June 5, 2019

            No 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, 2020

    Hi 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 ?

    Reply
    • George Spiers

      July 14, 2020

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

      Reply
  • Nisar

    February 24, 2021

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

    Reply

Leave a Reply