Hello,
We have 3 new servers dual Quad Core (8 cores total) and 32GB of RAM. I plan to fill 700 users in them. We may use CITRIX XenApp 5.
I've read some threads here about the x64 TS that can fit on large hardware/RAM, but a single OS is not the best idea. I would like to virtualize Windows 2008 Enterprise Edition x86 using VMWare ESX on the hardware.
So the question is what could be the best to fill the memory and also allow user to have enough ram ? 8x4GB Windows 2008 Enterprise per server (native ram support of x86) or 4x8GB extended ? I'm affraid 4GB would be to low, too few users supported or bad performances for them. 200 users per box is a minimum. That mean 25 users max for 4GB. On the other side, it's 50 users max for 8GB.
I've read the Login Consultant benchmark, I think 4GB for Windows 2008 TS is too few, or using 2003 Enterprise would be a better idea.
If you have any opinion or idea, they would be welcome :)
Hi,
Is there any reason you cannot go 64-bit on the VM's? You can certainly get more users per instance of Windows with that route as well as simplify the RAM delegation. For example, 2 VM's per box with 16Gb of RAM each allowing for 6 total Terminal Servers.
Just a thought for you...
Jesse KornRKON Technologieshttp://twitter.com/TheCitrixNinja
That's a good idea. If I go for 64bits, do you think I'll get more users on 2x16GB virtualized than 1x32GB directly on hardware ?
I definitely recommend 64-bit if your apps support it. Virtualization is nice becuase it can provide you redundancy, portability, and a more ability for dynamic resource allocation scenarios. However, the hypervizor does have some overhead, although minimal, you will ultimately get more users on bare metal. I personally virtualize whereever possible however.
I think it's so dependent on your application more then anything. I think you're better off if you have the time to do some benchmarking on one of the servers. Also I would have to disagree with the 64 bit and I would go 32. The apps take up more ram on a 64 bit system and unless you are getting close to filling the kernel memory there is no advantage to going to 64 (IMO). It's definitely debatable and I'm not sure you can get an exact answer without testing your own app on that hardware.
Are the servers going to only run published apps or will users also have a published desktop?
Well, they will have published desktops.
Office 2007, Internet explorer (they want to surf on many sites), the ERP, Acrobat PDF Printer. A couple of small apps also.
But if CITRIX is too expensive, we will probably go for Quest Software EOP if we can buy it separatly, and then use Softgrid for streaming application on servers (so we can redeploy them from scratch easily).
So, Softgrid means 32 bits and nothing else. For the 32 bits, the question was : Because 32GB for a 32bit OS is not a good idea, is it better to deploy 8 servers 4GB RAM they naturally support (32 bits memory addressing) or is it OK to deploy 4 servers (1 license btw) with 8GB of RAM ?
8GB in 32bits, even Enterprise, I don't know if that will cause some memory stability issue, since 32 bits addressing is 4GB.
Thanks. Sure 64bit is nice but because our users want to have some liberty with their sessions (like surfing on the web) and I've read some compatibility issues. I think 64 bits need a stronger control over apps and general use of TS.
I will try 4x8GB Enterprise on a server, and VDI on the others (i'm interested by VDI, it seems to be also a good choice to publish desktops). But I'm sure virtualized TS can fit a lot more users than a lot of VDI desktops on same hardware.
There is no question you can get more users on a 64-bit OS as opposed to a 32-bit OS. Remember a 32-bit OS can only really address a 4GB address space even with Windows Server Enterprise, therefore you are potentially looking at more paging and performance hits to allow it to understand greater amounts of RAM. 64-bit OS's come with 32-bit and 64-bit versions of IE on them there is no problems with Web browsing on either.
Sorry, not trying to say 64-bit is the only way or always the right way, you certainly need to understand the implications, however, you can get more users per box this way.
This is what I'm affraid of (paging and poor perfs under heavy loads).
Ok, i'm good for a real benchmark of all that, 1st server will be a 4x8 32bits, second one VDI (I will try XenDekstop over XenServer) and third one I'm interested by Windows 2008 R2 beta x64.
Cool! I am interested in the results! What are you going to use to simulate user loads?
I could read that Login Consultants Login VSI tool can do the job... I may test it.
You can consider Citrix Edgesite for Load Testing as a tool to simulate user load.
CNE, MSCE+S, CCEA 4, CCIA 4
We offer professional services for XenDesktop and XenApp
I thought 64bit was going to help us increase our user counts per server. It is not the pancea I expected. We are testing specific apps and Published Desktop, including Softgrid streaming of apps. I get maybe 30-40% more users and the performance starts to suffer. That's comparing a 32bit Win2k3 2cpu/4gb server with a 64bit Win2k3 2cpu/8gb server. I'm going to test Win2k3 Enterprise w/8gb ram to see what that buys us.
I'm sure these numbers might change from app to app, where 64bit is maximized at the application level, but for this test I am comparing like for like applications.
I too am seeing incompatibility issues w/64bit that makes this move prohibitive for some of our applications. The 32 vs. 64bit ODBC configuration, print drivers, Adobe still doesn't have a 64bit driver.
I agree with Brian, Scaling out is my personal way of scaling.
I also agree that I don't think you're going to cram 700 users on those 3 servers, especially using published desktops. You might get close to that number if you only use published apps and something like XenApp PN agent.
Also, tuning your page file is an art... make it too big and you'll pound the disks with paging, make it to small and you'll run out of memory quickly...
Get a good baseline established, look at your commit limit and peak... tune accordingly.
Just food for thought,
--Mike