A couple years ago, I wrote an article called “XenApp Farm and Zone Design,” which was based on the IMA architecture and was specific to XenApp, as the article’s name implies. This is, essentially, “Part 2″ of that article, so if you haven’t had a chance to read the first one (or you can’t remember what I was arguing in that article), then please go check out Part 1 first.
Here, I am going to talk about FMA Site Design, which applies to both XenApp & XenDesktop 7.x, which use the FMA architecture. And really I’d like to shed some light on some interesting designs we’re doing in the field when there is more than one data center. Because you actually have options, despite what you’ve probably been told.
The Absence of Zones in FMA
No, the current shipping version of XenApp & XenDesktop (7.6 FP1) does not have a “zone” feature similar to what we had in IMA. And a “site” in FMA is really analogous to a farm in the IMA world. So, when there are multiple data centers in the mix, we have to implement multiple FMA sites, right? That is certainly what our documentation says (buried towards the bottom of this page in eDocs we essentially tell you to implement 1 site per data center and leverage StoreFront aggregation). And if you call Support, that is probably what they’ll tell you as well (“you have to create a separate site for each data center to be officially supported”).
But what if you have 2 data centers that are connected via dark fiber? What if those 2 data centers are in the same city, but literally across town from each other? What if the latency between your data centers is sub-5 ms? What if it is 50 ms? 100 ms? Where does the VDA-DDC and DDC-SQL communication within FMA really break down and start to cause performance degradation? Those are the questions a few of our customers have been wondering as they make the transition from IMA to FMA, so our Consulting and Product teams decided to dig a little deeper and figure it out.
As it turns out, we have quite a few customers with “well-connected” data centers within close proximity of one another and we really can get away with a single site.
This is the tricky part: defining just what the heck “well-connected” means. Because if you’ve got 2 data centers that are well-connected to each other, you absolutely can get away with a single FMA site (and I would argue it is fully supported if it meets the requirements I’m about to lay out). Most vendors and industry experts seem to agree that well-connected means they are connected via high-speed link and that link has very low latency. But what does “high” and “very low” mean in this context? What does “close proximity” really mean? It will vary slightly depending on who you talk to, but most folks seem to agree on the following:
- High Speed Network Link = 1 Gbps+
- Very Low Network Latency = sub-5 ms
- Close Proximity = 50 miles or less
So, if you have 2 data centers connected via dark fiber and they are, say, 15 miles apart and the average network latency is 3 ms, then you can definitely treat those as one logical data center if you so choose (and implement 1 FMA site). We’ve done this a number of times already in the field and there are honestly no performance issues whatsoever. And again, I think this is a fully supported scenario and you can point to this article if someone tells you otherwise.
Where it becomes a little grayer is when you have two data centers that are connected via 10 Mbps and say 30 ms latency (or even 1 Mbps and 100 ms latency). What is the tipping point and when should you definitely implement multiple FMA sites?
First off, I have to say that if you don’t meet the requirements I outlined above, then you’re not going to be officially supported by Citrix. This may change in a future version of XenApp/XenDesktop, but with 7.6, if you decide to do what I’m about to tell you, then you’re taking a risk, as you’re relegated to “best effort” support.
Now that the disclaimer is out there … we have a few customers who have the classic branch office scenario or “mini” data centers (DCs). These branches or mini DCs have data that can’t be migrated to a central office/DC, but at the same time, it’s neither a ton of data nor users, so we don’t need a ton of workers/VDAs to support the load. These scenarios are perfect for extending a single FMA site to distributed sites that are not-so-well connected to the main DC (where SQL and the Brokers live).
So, what does “not-so-well-connected” mean and where does it fall over? After running this through the lab with a WAN Emulator testing, literally, dozens of different link speeds and latency combinations (and also proving this out in the field at a few willing customers!), we found that things start to deteriorate if you exceed 50 ms latency or have less than 256 kbps bandwidth. And while I mentioned bandwidth/speed there, it really didn’t play as big a factor as we thought and we were even getting decent results with ~100 kbps! Like most applications, it’s really all about the latency.
So, what did we test exactly and what should you expect if you do this? Well, that’s a bit out of scope for this article (and maybe I can do a follow-up article with all the gory details if folks are interested), but a few things I’ll highlight: