Solving customer VDI boot storm without taking rip-and-replace approach

When customers face VDI boot storm problems, your storage vendor partners might pressure you to suggest an entirely new storage system. But there’s a simpler, easier solution.

In a recent article, “How to avoid VDI boot storm problems using SSD,” Eric Siebert does a good job of reviewing some of the challenges of and solutions for a desktop virtualization phenomenon called a boot storm, which is caused when a large population of virtual desktop infrastructure (VDI) users boot up.

It’s often presumed that these boot storms happen only in the morning or when a shift changes, but they can also occur during a virus scan or when a system update forces a system-wide reboot. There are also some I/O problems during logout. The point is that while VDI images are typically very modest consumers of storage I/O, there are multiple times in the day where they can become very demanding.

When you come across a customer that has deployed VDI and is experiencing boot storms, you may be tempted to suggest ripping out the current storage system and replacing it with a new one. You may also feel pressure to do so from the primary storage manufacturers that you work with, since they often have no additive solutions that can fix the problem without replacing the whole storage system. Of course, it is in the vendor’s best interest to replace the whole storage system, but is it in yours?

The reality is that you can almost always solve the boot storm problem with a third-party solid-state storage solution, without replacing the existing storage system. In short, you can save customers money (compared with installing a whole new storage system) and solve their problems, solidifying your role as a trusted storage advisor.

The easiest way to accomplish this is to leverage a cache-based solid-state solution from companies such as FalconStor, Dataram, CacheIQ and Violin Memory. Each of these products has a specific use case: Some work well for block-based storage and others for NFS-hosted VDI environments. Another interesting solution comes from Marvell, which offers a cache card; the card is installed inside the virtual host yet still can maintain high availability.

The other option is to permanently place the desktop images on a solid-state disk system. Using VMware’s Linked Clones or XenDesktop’s Machine Creation Services, you can create a base image that is sourced for many of the virtual desktops’ boot information. In fact, most of the virtual desktops’ boot activity comes from those files. Oftentimes, there are few enough of these files that the images can be comfortably loaded onto a dedicated SSD appliance. Then the minor differences caused by user personalization can be stored on mechanical hard disk.

Of the two approaches to fixing boot storms using SSD, cache systems have the advantage of broad use. Once the boot storm activity is over, they can be used for something else, like a busy Oracle or SQL application. And provisioning to the next-most-busy task is often automatic. Fixed SSD systems, on the other hand, don’t require “warm-up” time, meaning that the data is already in solid-state and there is no wait time to copy information back and forth.

George Crump is president of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments.

Dig Deeper on Primary and secondary storage

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.