How Many Is Too Many VDI Sessions?

I was reading through some reference architectures this morning and I noticed a (non-Dell) offering for 7,000 VDI user sessions. This was billed as a large scale reference architecture for 7,000 VDI sessions - i.e. a fairly typical medium sized deployment.

Dig deeper and we find the testing was performed on 7,000 running sessions, but only 80% of the sessions actually running any application activity within the sessions - so that's 5,600 sessions. User density per server (in this example) drops from an apparent 145 sessions to a more realistic 116 per server.   Allocation of resources to VDI sessions was 1 vCPU and 2GB RAM.  The servers used were each deployed with 256GB RAM.  At a user density of 116 per server, that's a total of 232GB RAM - add on the requirement for the vSphere hypervisor and that's taking the server to its maximum memory.  With the 7,000 users meaning 145 sessions per server, then the actual server specification was not sufficient to support the allocation per user (145 x 2GB = 290GB + an allowance required for vSphere).  Reported memory utilisation in the report was fine, but there is a risk of over commitment of memory

The tests were conducted using the industry standard LoginVSI activity simulation tool. With 7,000 users the CPUs were maxed out and the VSIMax score was reached which indicates users sessions that will be suffering performance degradation, something to be avoided.

Storage is reported to be very low at around 3.5TB which is an impressive level of compression delivered through the use of linked cloned images, data reduction techniques and thin provisioning. However, the system deployed in the testing comprised just under 60TB of storage. This would appear to mean the storage footprint could be much smaller than that deployed, but its not clear if the storage volume would still be required to deliver the required level of IOPs. VDI sessions were all non-persistent which typically gives greater storage efficiency than would be seen with persistent sessions.

So here are some points to think about when looking at reference architectures for VDI:

• How many sessions are deployed?
• How many sessions are concurrently active?
• How much CPU is being consumed during peak concurrent activity (85% is a reasonable maximum)?
• How much memory is being consumed during peak concurrent activity?
• Is the server memory configuration high enough to avoid memory contention / over-commitment for the resources allocated to the VDI sessions?
• How large are the VDI sessions - vCPU and memory allocations?  Do these match your actual requirements?  If not, how will this affect density per server when they are matched to your requirements?
• How many IOPs are available when the system is under stress?
• Are industry standard tools being used to generate load and measure performance?
• If LoginVSI is in use, consider the point at which the VSI Index curve starts to climb steeply - this is when session performance is starting to degrade and is often well before reaching VSIMax.  If VSIMax is reached, performance is likely to be well beyond acceptability for users.
• Are sessions persistent or non-persistent?  Does this match your users' need?
• Is the volume of storage required there to provide storage capacity or is it there to provide IOPs capacity?  If volume of storage is matched to utilisation, will IOPs available suffer?
• What IOPs have been assumed per user?  Will this reflect realistic IOPs in use?
• Check IOPs proportions. Typcially 75% / 25% or  80% / 20% write / read ratios are seen as reasonable for VDI sessions.
• Has user experience been measured and reported (either subjectively or via a tool such as Stratusphere UX or similar)?
• In a typical hypervisor environment - what will happen when a host is lost within the cluster design?  Will there be headroom on the surviving servers to handle the re-distributed workload?
• What density will be achieved once you have applied your disaster recovery standards?

Explore the white papers and reference architectures very carefully as each one takes a different approach to deployment and reporting.  They are very useful papers, they give very strong indications as to what you can expect to be able to deploy.  Make sure when you compare between vendor papers, that it truly is an apples for apples comparison, and apply lots of "what if?" analysis and ensure you understand the differences between the papers and the actual deployments that will work for you in the real World.