Sites vs Zones in XenApp/XenDesktop 7.x – Design Considerations When Choosing Between The Two

Introduction

Zones, a key design element that administrators and architects have learned to love in XenApp 6.5 was reintroduced in Xenapp and XenDesktop 7.7 FMA architecture. Prior to 7.7, building multiple sites was generally recommended when spanning multiple data centers or regions but now customers  now have the option of leveraging Zones. While Zones is a potential option, it might not always be the right option based on your situation. In this post, my goal is to review basic concepts around Sites and Zones and dig into design considerations to help choose between the two.

Primer on Sites and Zones

Sites

A site is what you define when you deploy XenApp or XenDesktop under the FMA architecture. It acts as a logical boundary with all objects defined being part of that site. It is also an administrative boundary. Each site has one or more delivery controllers and requires its own site configuration database. A site always have one primary zone defined by default. Sites can span multiple data centers and regions but there are a number of factors that need to be taken into consideration and we will review these a little later.

Zones

Zones are defined within a site to keep applications and desktops close to the user location while also simplifying administration by leveraging a single instance of Studio, Director and configuration database regardless of the number of zones. With zones, users in remote regions can get to their resources without having to traverse the WAN.

There are two types of zones – Primary zones and Satellite zones. Primary zones typically have two or more controllers and have the site configuration database locally whereas satellite zones can have a single controller or more. While similar, zones in the new FMA architecture in 7.x is not the same as XenApp 6.5. For instance, the concept of a zone data collector no longer exists.

With the introduction of Zone preference in conjunction with Optimal Gateway Routing, users can be homed to a specific zone when accessing their apps and desktops based on predefined conditions and rules. This greatly improves the user experience. Disaster recovery can also be handled intelligently.

For detailed information on Zones and Zone preference I would recommend you review the official documentation. Carl Stalhood has a very good blog on this topic as well.

There is also a great overview of Zone Preference in the XenDesktop 7.11 Master Class starting at the 58 minute mark.

When to use Sites

While zones simplifies overall administrative overheard and potentially infrastructure requirements, leveraging sites is a more prudent choice in certain scenarios. Lets look into these:

Latency

Latency will impact user performance. Latency and concurrent user requests should be taken into consideration and tested before deciding to use zones. See the chart above for different scenarios tested. There are two great blogs, one by Chris Gilbert and another by William Charnell on how latency affects brokering performance from satellite zones in XA/XD 7.7 where they collect metrics under various latency conditions. Definitely worth a read. However these metrics have improved significantly in 7.11 and above. In fact, 250 ms latency, XenApp and XenDesktop 7.11 outperforms the 7.7 code at 90 ms. With 7.11 or later, users experience quicker brokering of resources, even with latency between a broker and the SQL server. The official citrix documentation covers latency and the impact on zones, registration storm impact and how this can be tuned in great detail.

Fault Domains

When we talk about large deployments with greater than 5000 users, it is best practice to break the environment down into smaller PODs. This helps split the enviroment into multiple fault domains such that when any of the pods are affected, only a small set of users are impacted if any. Even when all users connect in to a single datacenter, it is still beneficial to break the infrastructure down to multiple sites and PODs. Here are the slides from a great session at Synergy 2015 that covered the benefits of a POD based architecture. This blog is also worth a read.

Administrative Boundaries/Regulatory Compliance

For environments that require complete administrative isolation between different regions or business units, going with separate sites is recommended. While Role Based Access Control is available, it does not meet the needs of every customer. In addition I have worked with customers that have gone with multiple sites so as to isolate environments to meet compliance requirements such as PCI or regulated environments where upgrades are not as frequent.

While multiple sites requires additional infrastructure, the resources from the various PODs can be aggregated from a user access perspective. Monitoring and troubleshooting can also be simplified as Director can manage multiple sites. A number of the tasks can also be automated by leveraging script. Image management can be greatly simplified by leveraging PVS.

When to use Zones

When designing a XenApp/XenDesktop infrastructure for an environment with multiple datacenters with latency being a non factor (within acceptable limits), zones can certainly be an option. The number of users per satellite zone can play a factor when making that determination as discussed earlier. Fault tolerance should also be taken into account as all the zones share one common site configuration database and connectivity issues could impact all the users. The resources that users connect to can be controlled based on zone preference and failover. 

Using a combination of Sites and Zones is also an option. For instance if a customer environment is spread across the globe but also has multiple datacenters within each region, they could use Sites for each region and the leverage Zones for the datacenters within each region assuming low latency between the datacenters. This would help reduce the overall complexity and administrative overheard when compared to deploying a site per datacenter.

From The Field

Here is some feedback from Jason Samuel, one of our CTP‘s based on his experience.

“Most of my customers completed their migrations from 6.5 to 7.x when either zones weren’t available in FMA yet or was still new.  They went with a site per data center.  My bigger customers embraced localized pods within each datacenter itself.  This is often self contained pods built on HCI as the backend.  Application and image management is controlled through PowerShell scripts to help with administration of multiple sites.  Since these customers have been using this model for a few years now and it is a mature process for them, they continue with this approach.  My customers that are doing greenfield 7.x deployments are the ones that really consider zones vs. doing individual sites.”

Ryan Mcclure, Senior Architect at Citrix Systems had this to say: 

“So armed with this data and information, what should you do? Stick to multiple sites? Design with zones wherever possible? Some scenarios just beg for zones, while others are obvious use cases for sites/pods, but more commonly, both are technically viable and it is a matter of weighing the pros and cons. If your workload is mission critical and your deployment lives in one or two datacenters, multiple sites are probably a good option for you. They provide additional fault tolerance, shrink failure domains and increase flexibility during upgrades. If, on the other hand, you have a number of semi-well connected locations where application back-ends reside, one site per location may prove prohibitive from an administrative perspective. These sorts of deployments are where zones should really be considered. The combination of sites and zones also shouldn’t be overlooked. The geographic distribution cited above is one example, but sites and zones can also be combined to strike a balance between manageability and availability. Rather than all VDAs in a zone mapping to a single primary site, multiple primary sites can be deployed.

When the decision isn’t obvious, our most successful customers ask the same question:

“What are other customers in similar situations doing?”

The strategy around sites and zones definitely isn’t one size fits all, but up until now, most of our large enterprise customers have gravitated towards separate sites. Many do so based on their desire to shrink failure domains and minimize risk wherever possible. You may have even heard recommendations to skip zones because sites have been available longer in the FMA world. At the time, this recommendation may have made sense, but the IT space is as dynamic as ever and leading practices need to be updated with the times. Over the last few months, this trend around steering clear of zones has started to shift, and more customers are taking a hard look at how zones can help simplify environment management. In most scenarios, zones shouldn’t be viewed as a total replacement for sites, but if your deployment can be simplified and/or management streamlined by implementing zones where the make sense, now is the time to give them a good look.”

Final Thoughts

Zones in XenApp/XenDesktop 7.9+ is a welcome addition and offers greater flexibility when planning out deployments. However, it is not necessarily the solution for every use case as discussed above. Latency, number of users/location, concurrent logins etc need to be carefully considered before deciding whether to go with multiple sites or leverage zones instead.