One of the biggest hurdles to implementing VDI is creating a storage architecture. Step one: Determine whether you want direct-attached or shared storage for your virtual desktops.
Deploying and managing storage for virtual desktop infrastructure (VDI) is so difficult because VDI is extremely I/O intensive. While you can reduce the I/O overhead by providing each virtual desktop with sufficient RAM — so as to reduce the Windows operating system’s dependency on the Pagefile.sys file — you can’t reduce virtual desktop I/O to the point that it becomes insignificant.
That is particularly true during busier periods of the day. For instance, large numbers of users powering up their virtual desktops in the morning can trigger an I/O storm. It may be tempting to dismiss boot storms as a once-a-day occurrence, because even that can be avoided by leaving virtual desktops powered up.
But there are other types of I/O storms. For instance, the user logon process can cause a major I/O spike, as can launching an application. Your VDI storage infrastructure needs to be efficient enough to effectively deal with these and other types of I/O storms that occur throughout the day.
When choosing VDI storage, you have two primary choices: local direct-attached storage or shared storage. Here are the differences between the two options.
Local direct-attached storage
The least expensive and easiest VDI storage option to configure is direct-attached storage (DAS). With DAS, the main advantage is that the hypervisor can communicate directly with the storage. That means network bandwidth limitations or latency don’t constrain storage communications.
Another advantage is that when direct-attached storage is used, another host will not affect disk I/O. In a shared storage environment, all of the host servers must share disk resources. If a host happens to carry an unusually heavy workload, that host’s tasks can potentially rob other hosts of disk I/O. This is not a problem when each host has its own storage.
Despite the benefits of direct-attached storage for VDI, it isn’t always reliable. DAS offers no provision for failover. If the host server fails, then any storage devices that are attached to the host become inaccessible. For this reason alone, many of the VDI platforms on the market do not even support DAS.
Depending on which platform you are using, it might be possible to create a pool of host servers, each with its own local storage. If a server in the pool fails, the connection broker can redirect sessions to another host. The problem with this approach is that it lacks support for personal virtual desktops. The only way this type of failover can work is if each host maintains an identical collection of virtual machines.
The preferred method for providing storage to virtual desktops is shared storage. In this architecture, each virtualization host connects to a centralized storage pool where the individual virtual hard disk files reside. Because all hosts are connected to a centralized storage pool, the infrastructure is protected against host server failure. If a host fails, its workload can be moved to a different host within the cluster.
Although using shared storage for VDI is a better architecture for most deployments (there are exceptions), shared storage is not without its drawbacks. For one thing, it can be expensive to implement. This is especially true if you are using a storage area network.
Even if you use iSCSI network-attached storage, cost can be an issue because the underlying storage hardware must be fault tolerant so that it does not risk becoming a single point of failure. Just as important, the storage hardware must be able to meet the I/O demands of the entire VDI environment. This means using a large number of spindles and possibly even investing in solid-state storage for VDI.