Storage Implications for VDI – IOPS Can Drag You Down

In a recent Wikibon Peer Incite on VDI, Rob Peglar, Senior Fellow at Xiotech Corporation joined the call and outlined why storage is such a difficult challenge for successful VDI deployments. Here is video of that segment of the call:

A summary of his experience follows:

Most of the problems encountered with VDI implementations center around storage. When users try to apply their well behaved centralized, shared storage, performance often becomes unacceptable. The main problem is not capacity, but a bottleneck in I/Os per second (IOPS). Not only does consolidating hundreds of desktops onto one server result in high IOPS demand, the access patterns change dramatically. Normally, one desktop presents a fairly sequential load and a read/write ratio of 80/20. When many desktops are combined with VDI, the pattern shifts to mostly random and the read/write ratio shifts to 50/50 or worse. Since write I/Os take longer than reads, this shift can be fatal.

A second major issue is boot storms – when lots of users try to startup their virtual desktops at the same time. A clean Windows 7 boot can generate 150K to 200K disk I/Os, while adding anti-virus of anti-virus and other background services might take 1M I/Os (with up to half of those writes especially to the paging file). Given that users want their VDI experience to be no less than their existing desktop environment, boot storms can ruin that experience with storage a key component of that equation. Even when virtual desktops are pre-booted, user logins and logouts are the second largest cause problems and letting users save their desktops also will strain storage performance.

And IOPS performance is not limited to virtual desktops consolidated with VDI. Remote desktop services (RDS), mobile devices such as iPads, etc. are also a major concern. Indeed, for every $1 spent on virtual desktop deployments, $3-$10 is spent on storage.

To avoid these pitfalls it is crucial that users plan and test carefully. A typical steady state demand is 5-10 IOPS per seat though some users see 20-30 IOPS per seat. Consequently, scaling tests are mandatory. The key is to test, verify and measure with a small number of seats – say one dozen seats doing random access. This will provide benchmark I/O profiles suitable for use in sizing storage to handle the IOPS demand. Then, scale up carefully.

The bottom line according to Mr. Peglar is it’s not the bytes that will kill you, it’s the IOPS