Prepare your network storage for desktop virtualization

The popularity of VDI (virtual desktop infrastructure) is growing as enterprises both large and small start to realize the operational and environmental benefits it can offer. Centralizing the desktop operating environment in the data center, though, can lead to unexpected challenges — such as a wallop of transactional stress on expensive centralized network storage.

Failure to plan and test for the VDI load can result in poor performance and uncomfortable budget overruns. Here’s a quick guide to provisioning the network storage necessary to do VDI right.

Setting requirements

Before you start with any form of VDI deployment — even a pilot program — be absolutely sure to define a complete set of requirements. This will be vital as you deploy a pilot and start pushing it into production. (Most critically, do not allow the feature set of any particular VDI solution to drive your requirements.) If nothing else, your requirements list may serve as a litmus test that indicates VDI isn’t a good solution for your users. If that happens, don’t try to make the requirements fit the technology — wait until the technology fits the requirements.

At a minimum, the requirements should include everything you expect users to be able to do with their virtualized desktops. Will they need to install software on their own? Do they need to view full-motion video and/or audio? Do they use real-time client-side devices such as microphones or webcams? Is remote access or access over a low-bandwidth WAN necessary?

Some of these requirements may have important storage consequences. For example, the best TCO can be delivered by deploying nonpersistent virtual desktop pools in which each user will have his or her user state loaded into a “fresh” virtual machine at every login. This is extremely beneficial in that it ensures users enjoy a completely clean environment free of malware and “Windows rot.”

It also means that capacity-saving approaches such as VMware’s linked clone technology can be used. However, a fresh virtual machine makes it nearly impossible for users to install their own software and expect it to be there the next time they log in. Maintaining desktop persistence generally requires that each user must have a dedicated desktop — which removes a big chunk of the desktop management benefit VDI can offer, as well as dramatically increasing your network storage capacity requirements.

Building a pilot

After you’ve carefully defined your VDI requirements, match them to a specific VDI product offering and invest some resources to build a pilot. This pilot environment should be large enough for you to test a meaningful cross-section of users of varying types during normal day-to-day activity. This is important not only to gauge user impressions of the functionality VDI offers, but also to give you a chance to determine what kind of server and storage resources you’ll need to run a full-blown deployment.

During your pilot phase, there are a lot of metrics you’ll want to keep an eye on, so don’t skimp on data collection. Aside from the obvious ones such as CPU and memory utilization (most hypervisors make these easy to track), you’ll want to keep a very close eye on the amount of transactional storage resources are being used by your pilot users. This information can be gathered in a number of different ways: from within the guest operating system through Windows-based tools like perfmon, sometimes through the hypervisor, and most reliably, from whatever SAN management tools your storage vendor offers.

Reviewing storage requirements

If your current environment includes desktop systems with large storage requirements — say, for rich media — a prospective switch to VDI may cause you to obsess over exactly how much network storage capacity your VDI deployment may require. Fair enough — but don’t lose sight of the transactional load, which is what will end up costing real money. Network storage capacity is fairly cheap, while IOPS (I/Os per second) are not, especially when combined with high-capacity requirements.

For example, let’s say you’re designing for a base of 500 users and want to gauge how much centralized storage will cost. If you’re able to deploy using linked clones or other such space-saving technology, you might need around 2.5TB of disk space. If you can’t, you might need as much as 7.5TB or more depending upon what operating system you’re planning to use (keep in mind that a Windows 7 deployment will eat more than twice the disk space of a Windows XP deployment).

Even given a worst-case capacity scenario, you may be tempted to go for an inexpensive shelf of high-capacity SATA disk. But if the data you collect from your pilot environment shows that your VDI users are each burning an average of 5 IOPS daily — yielding an average of around 2,500 IOPS for a full deployment — that shelf of SATA will be woefully inadequate for the load. Instead, you may need a few shelves of higher-speed SAS disk to grant you both the capacity and transactional throughput you’ll require.

Beware the boot storm

Another thing to keep an eye on — both in persistent and nonpersistent deployments — is the disk load exerted during boot or reboot of your virtual machines. It should come as no surprise that the VMs will consume far more transactional disk resources during boot than during normal operation. Keep in mind that there are several virtual desktop management scenarios (such as updating software in your base image) that may cause you to boot large numbers of virtual machines in very short periods of time. The resulting disk load has the potential to overwhelm almost any network storage platform that isn’t designed specifically to deal with it.

In cases where you need a fairly small amount of storage, an SSD-based or hybrid SSD/disk storage platform will often provide the best balance of capacity and transactional throughput. Hybrid products are especially well-suited to VDI workloads, because they’re usually capable of shifting heavily used storage blocks to SSD while leaving less-used data on much slower (and cheaper) spinning disk. The result is often that the heavily used gold image is retained in SSD, where it can be quickly read, while less-performance-critical user data is stored on cheaper disk; essentially, this boils down to transparent storage tiering.

VDI is an exciting technology that I think will only improve as it continues to mature. Though it still suffers some user experience challenges — especially video/audio quality over WAN circuits and and support for client-side peripherals — it has improved dramatically over the past few years and will continue to do so. Whatever choices you make regarding which VDI platform to use, expect to see a significant load land on your network storage resources. Failing to deploy a realistic pilot environment and perform rigorous testing may leave you high and dry.

This article, “Prepare your network storage for desktop virtualization,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in network storage and information management at InfoWorld.com.