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.

Domestics This Time - Leaky HomePlug Networks

A bit of a domestic diversion this time: I've been using HomePlugs to feed my Squeezeboxes, TVs, DS etc. for approximately 3 years and they've been completely reliable to date. I use a mix of TP-Link single plugs and Zyxel multi-port units.

Just in the last week I've started to have reliability issues with my network - weird stuff was happening like the wifi recycling every 2 to 3 minutes and having trouble logging into my EE router from my PC. Re-setting the router to factory default seem to resolve the problem for up to half a day or so then everything started going wobbly again.

Then, just yesterday, I did a factory default reset of the router and as I was trying to log into it, the router suddenly flipped from an EE log in page to a Huawei log in page. Weird as I don't have an Huawei router in the house, never mind plugged in. Access to the internet continued OK, but the devices plugged into the HomePlugs were not connecting properly with the network and the DS started doing that fading then coming back thing every couple of minutes which happens only when there's a network problem. Removing all the HomePlugs and running only on wifi made the whole thing stable, but the hifi very quiet of course.

I decided on a process of elimination by plugging in one HomePlug at a time to see which one was causing the problem. But this wasn't consistent - sometimes the problem arose with one device, then with another. Then, the weirdest thing happened - McAfee on my PC popped up with a warning that I had about 10 devices on my network that "are not protected by McAfee". One of these was a laptop named "CHRIS". A Chris lives over the road from me! This only happened when a HomePlug was connected up - any of them - but not when only running wifi.

A bit of Googling later and I find that the general concensus on "leakage" of HomePlug signals beyond the house circuit breaker box / consumption meter has changed significantly compared to 3 years ago. When I first started with these things, leakage beyond the consumer unit was "extremely unlikely". Now, its reckoned to be virtually certain in an apartment block, and "fairly likely" in houses.

In order to make these devices "plug and play" they all present themselves to a default network grouping of HomePlug devices called "HomePlugAV". So any of these devices that stick with this default name will talk to each other. I think one of my near neighbours must've recently decided to use HomePlugs when they haven't before, and our 2 networks are talking to each other. And because many routers default to the same network IP address, I was getting access to my neighbour's Huawei router. For some reason, that was "over powering" the IP address of my own router. So not surprising that my HomePlug devices and the rest of the network was getting confused - the DHCP server and default gateway were probably flipping between my own router and that of my neighbour.

So the resolution was to install the HomePlug management software on my PC and rename the network name on all the devices away from HomePlugAV and to something unique to my own house.

Now all seems to be well and stable - across HomePlug and wifi. Will keep an eye on how it goes and I have a list of the MAC addresses of the outsider HomePlugs so I can go and advise whichever neighbour they belong to to secure his/her own network.

So there you go. Take note and make the changes to your own HomePlugs before things start to go a bit wobbly in your network too.TP