This used to be a very popular topic in the day, so I'm sure MetaFrame and CPS admins "old school" will appreciate this Article . It also makes me happy to write good 'ol XenApp, because it seems that I spend most of my time these days working with new products such as XenDesktop, Provisioning Services and XenMobile. And the reason I am writing this article is because I received two nearly identical requests this week on this subject. And while most of the concepts around the farm and the design of the area have not changed in a decade, a number of things and that's why I affixed the title of this article because it is "Version 2013". Before reviewing the different options for the design of large XA environments with distributed data, first let me tell you about the 2 customers or inquiries that you have a little more context ...
the first client is a major oil company with global operations - they have data distributed worldwide in seven places. The second survey came to one of my colleagues in Asia-Pacific - the customer has data in 10 or 11 regions. So almost identical scenario and both asked the question - how should we design the farm and XenApp areas? Ah - a good question, but a loaded question. I replied at once with something along the lines of the following:
You have 4 options of how I see things:
- single farm with 10 areas - essentially a zone site
- single firm with maybe 5 zones - the premise being here to sites "group" with each other for the collapse of the areas
- regional farms - one per continent (ie Americas, APAC, EMEA)
- Several farms - mostly 1 for each farm site
I'll start by saying that I did the options 2, 3 and 4 before with success. I've never designed a farm with more than 5 zones, so 10 would certainly push the envelope. Remember, XenApp uses a topology stars for replication between areas. So, the more areas you or these controllers, traffic over the network (and it becomes exponentially since we use a star topology). But the last time I did one of those World XA designs myself, the product was not version 6.5 with all architectural improvements. So, while we used to advise customers not to create more than 5 zones in a single farm, which was 6.5 pre-advice (ie MPS 3.0, 4.0 CPS, CPS 4.5, XA 5/6). With new enhancements to the data store, LHC, IMA and XML Services in v6.5, we may be able to push this zone boundary a little more. So maybe the magic number could be more like 7 or 8 with the improvements (by the way - we still say not to exceed 5 zones in our documentation 6.5). But I really do not know what the magic number is and it would be something that you would certainly want to test before continuing Option 1 - that is honestly my least favorite option personally
I ' did option 2 for a large. communications company a few years - they had about 15 sites in the United States. I basically grouped the smaller sites with the "best" larger neighbor site. And note that I "better" put in quotes there - it's all about the network bandwidth and latency - not necessarily the closest geographical distance! In the end, I went down to like 4 or 5 zones in total. To illustrate this "hub and spoke" a little consolidation area design better, let me give you an example - the site New Orleans the customer had a small number of users and data (within 10 XA servers required) and was connected "best" for a large data center in Atlanta via ~ 20 ms link, so I form an area called 'South' or something for these two sites.
I did Option 3 a few times, but most recently for a large pharmaceutical company. This regional agricultural design quite well for them, because they had three primary data centers on each continent (Chicago, Belgium and Singapore). But we actually could have gone with a single global firm with 3 zones in this case, but we do not. Why? Because they had 3 different teams (some internal, some subcontracting) managing 3 different data centers ... so 3 regional farms was the way forward for them. I give this example because it illustrates an important point - just because you can technically make a single global firm does not mean it is always the best way to go. Sometimes things like organizational structure, operational procedures and regulatory requirements / compliance could be several farms a better fit. Which brings us to the last option ...
I did Option 4 probably the most. I'm a big fan of "horizontal scalability" with Citrix products and most of the technology in general (I've been meaning to do an article on this subject, so stay tuned for that). And before that I agree with this particular option, please let me stress that I fully understand this option comes with the possibility of additional overhead, cost and management. After all, it could mean 10 farms as opposed to 1 firm in this case. But I would say the following:
- We virtualize all infrastructure components these days (These controllers, etc.), so there is not a ton of additional costs to rise several more batteries (in physical days, this could definitely be a deal-breaker). But the vast majority of our customers use hypervisors these days, so an extra box could mean $ 500 as opposed to 5k.
- You can manage all farms in a single console these days. That did not use to be the case with some of our products older MetaFrame, but now we MMC snap-ins and you can break in several farms in a single view, etc.
- Since XA 6.0, we use the full armor of strategies and can apply Citrix policies through Active Directory (or locally via IMA). But if you have multiple farms, you can have a single base AD GPO with a basic set of Citrix policies applied to different OUs with servers in different farms.
- XA farms are pretty darn "static" in -Etat constant. What I mean is you after the initial config, publish applications, and policies in place, you do not access the console much, except to introduce new applications or modify policies. In addition, we have MFCOM scripts for older versions and POSH scripts to latest versions (cmdlets XA) to automate the management of several farms very easily. Most of our major customers have multiple farms and use scripts and whatnot to publish things without even opening a console.
- You avoid the complications of transactional replication SQL.
- We can aggregate multiple batteries via the web. Interface (or StoreFront) so it is invisible to the end user
- Many farms allow us to mitigate the inherent risk - failure of a single farm can only take down 10% of the population the user, as opposed to 100% if one farm is used.
So what is the best option and will work for these 2 clients? I'm probably a little more information about the configuration of their network, the number of users (or the amount of data), they each site and that their organizational structure looks like. Once I know these things, I usually walk the customer through the advantages and disadvantages of each option and help them make an informed decision. But as you can tell, I lean towards the option 4, 3, 2 and 1 -. In this
Anyway, I hope you enjoyed this journey through memory lane with me. It was a discussion the consulting architects were having email the last few days, but I thought that this information could benefit the Community. You might also have noticed that I included some links below - I'll include them again below with their official titles for the comfort of all (these are must read resource if you make this kind of design work in the domain).
Hope this helps. Send me a note below if you have comments or questions. . Thank you for reading
-Nick
Nick Rintalan, Senior Architect, Citrix Consulting
References and Resources:
areas design for XenApp deployment
- http://support.citrix.com/proddocs/topic/xenapp65-planning/ps-planning-zones-wans-v2. html
- http://community.citrix.com/display/xa/The+ + Definitive Guide + to + Area + design
When designing multiple XenApp Farms
- http://community.citrix.com/display / xa / When to + + + design + XenApp Farms
XenApp 6.5 Enterprise Scalable Citrix deployments
- + multiple http: // support. citrix.com/article/CTX131102
2013 Oregon Football Schedule 😉
- http://espn.go.com/college-football/ team / calendar / _ / id / 2483 / oregon ducks
0 Komentar