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