Not long ago, VDI environments could only handle relatively lightweight applications. Today, you can run almost...
any application, but delivering high-demand apps requires some planning.
The key to delivering high-demand applications in a VDI environment -- with an acceptable level of performance -- is to tune your VDI system to provide the required resources at the times users need them.
That means you need enough hardware and storage, and you have to keep an eye out for bottlenecks. Also consider using full clones and finding ways to mitigate the effects of boot storms. Here's how:
Don't skimp on hardware
It goes without saying -- rule No. 1 of enabling high-demand applications is that you can't skimp on the hardware.
In a VDI environment, virtual desktops share a pool of server resources, and it may be tempting to stretch those resources and squeeze in a few more virtual machines (VMs). This is a bad idea. Remember, an application's requirements do not change simply because it runs on a virtual desktop. If a particular application consumes 4 GB of memory on a physical desktop, it will consume 4 GB of memory on a virtual desktop, too.
Watch out for resource bottlenecks
Bottlenecks can come in many different forms, but there are two types you should be on the lookout for.
The first type of bottleneck is related to resource overcommitment. Overcommitment is a common practice that seeks to maximize the usefulness of a host server. It is unlikely that all your virtual desktops will be in use at the same time, so some admins think it's OK to overcommit the host's resources.
Overcommitment does have its place, but it can cause problems for high-demand applications. My advice is to move virtual desktops containing high-demand apps to a dedicated resource pool allocate the proper amount of resources.
The other type of bottleneck that frequently causes problems for high-demand applications is a storage bottleneck. Even if virtual desktops are correctly provisioned, they can still suffer from poor performance if storage infrastructure can't deliver the required IOPS.
I have seen a number of organizations attempt to address storage bandwidth by implementing a solid-state drive (SSD) tier within their storage infrastructure. Although SSDs usually help, it is just as important to make sure that the SAN (or whatever storage connectivity you use) can provide adequate bandwidth.
Be careful about using linked clones
Virtual desktops are almost always clones of a virtual desktop image -- either full clones or linked clones.
A full clone is a complete copy of a virtual desktop image, whereas a linked clone is based on a snapshot of the original virtual desktop image.
Most virtual desktop deployments I have seen use linked clones. They share a common virtual hard disk (VHD), which means you can create them rapidly, and they consume far less physical disk space than full clones (not accounting for deduplication). But that shared VHD also means linked clones tend to have worse performance than full clones.
If your virtual desktops must run high-demand applications, you might be better off using full clones. If that is not an option, make sure the parent VHD to your linked clones is stored in a location that delivers optimal performance. For example, you might place a linked clone on flash storage. Some organizations even go so far as to copy the parent VHD to a RAM disk to ensure optimal performance.
Minimize demand spikes
One of the issues that has long plagued VDI environments is demand storms. For instance, when all your users arrive at 9:00 a.m., there probably will be a huge load on the virtualization infrastructure as everyone boots their VMs.
Some organizations attempt to counter this demand with a scheduled process to pre-boot VMs before users' arrival. You can apply the same concept to high-demand applications.
In most cases, you can't preload applications, but you might be able to adjust some settings to lessen the demand spikes' effect. For instance, if you know that everyone will launch a high-demand application at 9:15 a.m., you should configure malware scanning so that it does not occur at this time. The key is to do anything that you can to lighten your VDI infrastructure's load during anticipated demand spikes.