Tuesday, April 03, 2012 11:08 PM
In our environment, we have 42 XenApp servers. Most apps are delivered into the XenApp box via AppV, then published out to the users with Citrix. Currently, our AppV cache sits at 22GB (I have a 40GB VHD locally available for each of the 42 XA boxes. So yes, that's 42 X 40GB = 1.6TB of SAN disk....).
I'm looking at consolidating all of this into a single shared cache and was wondering what the best option would be for the shared cache location. Here's what I think:
Current AppV Management server:
Hyper-V VM 1 CPU, 2GB RAM, 1 Synthetic NIC, 1 VHD for the Content share.
What I propose:
Add 2nd NIC, add a PASSTHROUGH disk of XXGB of LUN, pop the shared cache on this share. Configure the AppV clients to point to the UNC path (either IP or DNS name) for this 2nd NIC. Theoretically, streaming traffic stays with NIC1...whilst cache traffic goes through NIC2.
Wednesday, April 04, 2012 6:39 AMModeratorI'm not aware if you can configure a multi-homed Windows machine to answer SMB connections with a different name to the primary hostname. If so, then you should be OK, otherwise configure a second VM to host the Shared Cache.
This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.
Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.
Wednesday, April 04, 2012 6:49 AM
I should probably point out that the AppV management server is in a Cisco UCS chassis with 10Gbps connectivity. Of which, ALL of the XenApp infrastructure sits in the same chassis.
My line of thinking was...pointing the AppV client to the IP of the 2nd NIC (\\188.8.131.52\sftfs.fsd) to access the read-only cache. However, I'd imagine that the single 10Gbps link would be more than sufficient to handle both the Management Server functions/traffic AND provide the RO Shared Cache. The dual NIC option, whilst nice to have, would require dropping the entire Hyper-V host (which contains other critical infrastructure) to make another NIC available to the host.
I think I'll do this:
Add another CPU and 2 more GB of RAM to the Management Server (2CPU and 4096MB RAM). Present an 80GB LUN to the server to hold the shared cache.
Tuesday, April 24, 2012 7:24 PM
Do you have any idea of what kind of scale you are trying? I mean, how many XenApp servers (with what amount of users?) are you planning to make use of a single shared cache file? I am intrested in how many connections a single cache file can take before the performance of the app-v clients will decrease.
I understand this has also to do with the type/kind/setup of your storage and links to that storage but still?
Are we talking about lets say 50-60 users per XenApp server and then 5-10 servers/shared cache file? 10-20? 20-40? Maybe just 2-5?
Stijn Maes Specialist Log ● in Consultants Belgium email@example.com http://www.loginconsultants.be | VAT: BE 0864.350.469 NEW RELEASE VSI 3.0: NOW AVAILABLE ON LOGINCONSULTANTS.COM
Wednesday, April 25, 2012 10:47 AM
42 XenApp servers designed around 550 users. At the moment, there are only about 100 users. I'm yet to find any documentation from Microsoft relating to any potential or possible implications of using a single shared file in such a setup.
Maintaining 42 local cache files was becoming a real pain. Hence why I needed to investigate this method which so far, has been very successful. Apps seen pretty snappy and load quickly. So far, more importantly (for me)...is the knowledge that the cache of each 42 servers is the same. Previously...it sometimes could be a case of App A 100% loaded on Server A....but only 30% loaded on Server B.