Feature

VDI storage basics and persistent versus non-persistent desktops

Virtual desktop infrastructure (VDI) storage requires careful consideration, chiefly because of the potential I/O bottleneck that can arise when many virtual desktops try to access storage simultaneously.

In this article we will discuss the issues involved in picking a suitable storage strategy for your VDI project.

Thin client.jpg

VDI takes the user's desktop computer and migrates it into the datacentre. This is attractive to IT departments as it enables centralised management and control of desktop applications, including patching and automated deployment, while delivering a consistent experience for the user.

Storage for persistent and non-persistent desktops

Virtual desktops can be deployed in two modes – persistent and non-persistent.

Persistent desktops each have a separate disk image, which means the user retains the personalisation of their configuration each time they log in. Non-persistent desktops do not retain configuration information and are reset back to the standard master image each time the user logs off.

Persistent desktops require higher data protection and availability features from storage compared with their non-persistent counterparts.

Virtual desktops consolidate workload

In the distributed, physical desktop model, issues with storage – whether performance or failure related – only affect the individual user.

But, as desktops are consolidated with VDI, users share the same physical infrastructure in a multi-tenant configuration, making the effects of any performance problem or outage more significant.

VDI therefore needs to be treated like any other enterprise application and the storage component designed accordingly. This means giving consideration to performance, capacity and availability.

Virtual desktop performance

To size the disk performance requirements for VDI, best practice is to sample a typical desktop using performance tools and to measure the actual IOPS required over a set period of time.

Typically, a single Windows 7 desktop will require, on average, around 20 IOPS, depending on the client applications being used. This figure will peak at certain times of the day, for instance as users log in (when most of the activity is read I/O) and when the user logs out (resulting in write I/O). These are known as boot or login/logout storms.

VDI data is well suited to data reduction technologies such as thin provisioning and data deduplication

Virtual desktop I/O can be heavily write I/O orientated, which is not typical of enterprise applications and so can present a problem when designing VDI storage solutions. It can also make sense to optimise desktop I/O by disabling background search, drive encryption and virus scanning functions.

One other point to remember is that consolidation of desktops into a VDI system creates a highly random workload profile because it is impossible to predict the I/O demands of any single desktop user. Random I/O is more challenging to deal with on disk-based storage, especially for read I/O, which must come from physical disk rather than being cached or pre-fetched.

Virtual desktop storage capacity

A typical user desktop can require anything from 10GB to 20GB or higher, depending on the applications deployed. Large VDI deployments may therefore scale to terabytes of storage, which has significant cost implications.

Fortunately, VDI data is well suited to data reduction technologies such as thin provisioning and data deduplication. Deduplication rates can be as high as 90%, as most data is simply a copy of the master operating system image.

Virtual desktop availability

As with any deployment that consolidates distributed data into a central solution, data availability becomes a significant consideration. For VDI, the level of availability required depends on the implementation type.

Non-persistent desktops are dependent on the master image only, as the user desktop is rebuilt each time the user logs in. In the event of a server failure, the VDI user can connect to another server in the VDI farm. Although this is an irritation, it does not mean data loss.

Persistent desktops, however, require more care because they retain user configuration information. In this case, data needs to be protected and maybe remotely replicated to ensure a high level of availability is maintained.

Deployment models

Exactly what type of storage is right for VDI environments? There are a number of configurations and each has specific considerations. 

The deployment models discussed here refer to the storage required for the user desktop only. We assume that shared locations such as team folders and home drives will be handled separately on storage platforms managed independently, on a dedicated NAS appliance, for example.

Direct-attached storage (DAS) local to the VDI server is potentially cheaper to deploy than a shared storage solution. However, direct-attached disks provide no resiliency in the case of hardware failure, unlike a shared storage solution.

With persistent desktop solutions, shared storage is a better choice, as it provides protection of user data in the event of a server-level failure, with access to data and the desktop achieved through another server.

For non-persistent desktop implementations, DAS can be used, but the solution may be limited in IOPS density without using large numbers of fast drives.

Flash storage is particularly suited to random I/O environments as there is no mechanical latency involved.

Most storage array makers have reference architectures for VDI, and all-flash arrays are available from many storage suppliers – the big six and startups. Flash can be deployed directly into the server, either as flash drives or in PCIe format, and most of the flash suppliers have VDI reference architectures.

Of course, the problem with flash is the higher cost compared with hard drive solutions when looking purely at the cost per terabyte metric. As an alternative, hybrid flash platforms combine solid state and hard drives, making them more cost effective than all-flash solutions.

There are also suppliers that offer converged solutions, such as Nutanix and Pivot3, that combine storage and hypervisor in scale-out architectures that can allow VDI solutions to be deployed without the need for separate virtual server and virtual desktop hardware.

Arrays based solely on spinning disk can be impractical for VDI as the IOPS density of hard drives is not high enough to sustain the throughput required, especially during I/O storms.

Software for VDI

As an alternative to hardware solutions, there are a number of software options to optimise VDI workloads.

Atlantis Computing’s ILIO supports persistent and non-persistent desktops and can be used with DAS because of the reduction in disk I/O it achieves by storing frequently accessed data in RAM. The software is deployed as an appliance on the VDI hypervisor and for persistent implementations replicates data to another VDI environment, which could be in a geographically dispersed location.

GreenBytes’ vIO is also deployed as a virtual storage appliance in the hypervisor. It can support block (iSCSI) and NAS storage as well as locally deployed flash solid state drives (SSDs) and PCIe SSDs. Greenbytes also offers a hardware appliance that runs the same vIO code for customers which prefer a dedicated hardware solution.

Virsto (acquired by VMware in 2013) is another software product that optimises the I/O stream. This is achieved by organising random I/O into sequential writes through the use of a log-structured file process. Sequential writes are much easier to manage on traditional spinning media, making the system applicable for deployment with traditional storage arrays.


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in January 2014

 

COMMENTS powered by Disqus  //  Commenting policy