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 seperate 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 perfer 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 and 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 Connection Leasing 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

 


8 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

Leave a Reply