This used to be a very popular topic back in the day, so I’m sure “old school” MetaFrame and CPS admins will appreciate this article.  It also makes me happy to write about good ‘ol XenApp, because it seems like I spend most of my time these days working with newer products like XenDesktop, Provisioning Services and XenMobile.  And the reason I am writing this article is because I received 2 almost identical inquiries this week about this topic.  And while most of the concepts around farm and zone design haven’t changed in a decade, a few things have and that’s why I’ve appended the title of this article, since it’s the “2013 version”. Before we review the various options for designing large XA environments with distributed data, first let me tell you about the 2 customers or inquiries so you have a bit more context…

The first customer is a large oil company with global operations – they have data distributed around the world in 7 locations.  The second inquiry came in from one of my colleagues in APAC – the customer has data in 10 or 11 regions.  So almost identical scenarios and both asked the question – how should we design the XenApp farm and zones?  Ah – a good question, but a loaded question.  I responded to both with something along the lines of the following:

You have 4 options the way I see it:

  1. Single farm with 10 zones – essentially a zone per site
  2. Single farm with maybe 5 zones – the premise here being to “group” sites with each other to collapse zones
  3. Regional farms – one per continent (i.e. Americas, APAC, EMEA)
  4. Multiple farms – essentially 1 farm for each site

I’ll start by saying I’ve done options 2, 3 and 4 with success before.  I’ve never designed a farm with over 5 zones, so 10 would certainly be pushing the envelope.  Remember, XenApp uses a star topology for replication among zones.  So the more zones or ZDCs you have, the more network traffic (and it becomes exponential since we’re using a star topology).  But the last time I did one of these global XA designs myself, the product was not version 6.5 with all the architecture improvements.  So while we used to advise customers to not create more than 5 zones in a single farm, that was pre-6.5 advice (i.e. MPS 3.0, CPS 4.0, CPS 4.5, XA 5/6).  With the new enhancements to the Data Store, LHC, IMA and XML services in v6.5, we might be able to push that zone limit a bit more.  So maybe the magic number might be more like 7 or 8 with the improvements (by the way – we still say not to exceed 5 zones in our 6.5 documentation).  But I really don’t know what the magic number is and that would be something you’d definitely want to test before pursuing option 1 – that’s honestly my least favorite option personally.

I did option 2 for a large communications company a few years back – they had about 15 sites in the US.  I essentially grouped the smaller sites with the “best” larger site nearby.  And notice I put “best” in quotes there – it’s all about network bandwidth & latency – not necessarily the closest geographical distance!  In the end, I got down to like 4 or 5 zones total.  To illustrate this “hub and spoke” zone consolidation design a bit better, let me give you an example – the customer’s New Orleans site had a small number of users and data (less than 10 XA servers required) and was connected “best” to a large data center in Atlanta via ~20 ms link, so I would form a zone called “South” or something for those 2 sites.

I’ve done option 3 a few times, but most recently for a large pharmaceutical company.  That regional farm design worked really well for them since they had 3 primary data centers on each continent (Chicago, Belgium and Singapore).  But we actually could have gone with a single global farm with 3 zones in this case, but we didn’t.  Why?  Because they had 3 different teams (some internal, some outsourced) managing the 3 different data centers…so 3 regional farms was the way to go for them.  I bring this example up because it illustrates an important point – just because you can technically do a single global farm doesn’t mean it’s always the best way to go.  Sometimes things like organizational structure, operational procedures or regulatory/compliance requirements might make multiple farms a better fit. Which brings me to the last option…

I’ve done option 4 probably the most.  I’m a huge fan of “horizontal scalability” with Citrix products and most technologies in general (I’ve been meaning to do an article on this topic, so stay tuned for that).  And before I endorse this particular option, please let me point out that I totally understand this option comes with the potential for additional overhead, cost and management.  After all, it might mean 10 farms as opposed to 1 farm in this case.  But I would argue the following:

  • We virtualize all infrastructure components these days (ZDCs, etc.), so it’s not a ton of extra cost to stand up multiple farms anymore (in the physical days, this could certainly be a deal-breaker).  But the vast majority of our customers employ hypervisors these days, so an extra box might mean 500 bucks as opposed to 5k.
  • You can manage all farms in a single console these days.  This didn’t use to be the case with some of our older MetaFrame products, but now we have MMC snap-ins and you can snap in multiple farms to a single view, etc.
  • Since XA 6.0, we use Full Armor policies and can apply Citrix policies via Active Directory (or locally via IMA).  But if you have multiple farms, you can have a single AD-based GPO with a set of baseline Citrix policies applied to different OUs with servers from different farms.
  • XA farms are pretty darn “static” in the steady-state.  What I mean by that is after you do the initial config, publish apps, and set up policies, you don’t access the console that much, except to set up new apps or tweak policies.  Plus, we have MFCOM scripts for older versions and PoSh scripts for newer versions (XA cmdlets) to automate the management of multiple farms very easily.  Most of our large customers have multiple farms and use scripts and whatnot to publish things without even opening a console.
  • You avoid the complications of SQL transactional replication.
  • We can aggregate multiple farms via Web Interface (or StoreFront) so it’s invisible to the end-user.
  • Multiple farms allows us to inherently mitigate risk – an outage to a single farm might only take down 10% of the user population as opposed to 100% if a single farm is employed.

So which option is best and will work for these 2 customers?  I probably need some more info about their networking setup, how many users (or how much data) they have at each site and what their organizational structure looks like.  Once I know those things, I typically would walk the customer through the pros and cons of each option and help them make an informed decision.  But as you can probably tell, I lean towards options 4, 3, 2 and 1 – in that order.

Anyway, I hope you enjoyed this trip down memory lane with me.  This was a discussion the Consulting Architects were having via email the last couple days, but I thought this info might benefit the Community. You also might have noticed I included a few hyperlinks above – I’m going to include them again below with their formal titles for everyone’s convenience (these are must-read resources if you’re doing this type of design work in the field).

Hope this helps.  Drop me a note below if you have any comments or questions.  Thanks for reading.

-Nick

Nick Rintalan, Senior Architect, Citrix Consulting
Resources & References:

Designing Zones for a XenApp Deployment

The Definitive Guide to Zone Design