The objective of this blog post and corresponding whitepaper is to provide a better insight into the key figures for resources that are applicable to design of a VDI solution. The whitepaper also describes sizing guidelines and the impact of the use of local storage for VDI. We not only discuss the required amount of IOPS, but also the amount of storage capacity that is required for a successfully implemented VDI project. We, the A-Team at PQR, have written many articles since December of 2009 about VDI and Storage:
On a weekly basis we receive questions and feedback from customers, peers, and people within the community. We think that a new whitepaper highlighting "Local storage and sizing guidelines for VDI" is useful in the library, increasing the knowledge around "VDI and Storage".
The benefits that Virtual Desktop Infrastructure (VDI) can offer are numerous. It enables organizations to support BYO initiatives and to work everywhere, independent of the device, etc., etc. During the past few years, many Application and Desktop Delivery projects have been implemented with VDI. However, several of these projects have turned out to be rather disappointing. A key reason for this is the complete failure to assess the impact that VDI has on the storage. Although we were aware of this from the first large VDI project end 2008, we continue to see VDI projects (even late 2013) start up in which incorrect assumptions have been made. Consequently, this significantly reduces the chances of success for the end users as well as the IT organization.
Because the impact is so great, the storage component in the initial investment (CAPEX) can amount to more than 40% of the total solution. If the storage design is not optimal, the user experience will be disappointing and the acceptance of the VDI environment will present a major problem, from a technical as well as operational point of view. However, the emergence of SSD seems to present a viable solution for this problem.
SSD is known to be fast. SSD (or actually: flash) solutions supply so many Input/Output Operations Per Second (IOPS) that VDI will no longer experience IO bottlenecks. The term ‘fast’ principally refers to the number of IOPS. The processing speed is often limited by the interface to which the flash cells are connected. Thus, a USB interface is many times slower than a SAS or SATA6 connection that are, in turn, much slower than a flash solution based on PCIe.
SSD also has its downside, though. Cost is one, but it also breaks down relatively quickly (also see the white paper Spinning out of control). Current prices of flash in enterprise storage solutions are in the region of € 15/GB (~$20), whilst this is in the region of € 0.50/GB (~$0.70) for local hard disks in a server. In contrast, the price per IOPS for SSD is approximately € 1/IOPS (~$1.25), and in the region of € 5/IOPS (~$7) for local hard disks. This means that there is no optimum balance in terms of a moderately high workload with a moderately large storage requirement. The most efficient, especially in relation to VDI, seems to be local flash solutions for servers. However, local storage in a VDI host also presents some challenges. This so-called VDI Local Storage Server (VDI LSS) makes it difficult to move workstations between hosts. Special measures must also be taken to ensure that data is secure in the virtual machines. Thus, VDI LSS solutions currently are primarily intended for stateless workstations that do not contain persistent information. But this is not the only problem. Moreover, finding the optimal balance between space and IOPS is a challenge for local storage. We think that will change over time with the innovation of various (start-up) storage vendors and the movement, of vendors such as VMware with their yet to be released VSAN technology, to use local storage solutions for VDI and other workloads.
Flash storage is often considered for a VDI LSS. However, the SSD life expectancy has resulted in it virtually being classed as a disposable article. Enterprise solutions expect a minimum life expectancy of 3 years, often as much as 5 years. However, for VDI workloads, this cannot be expected from all SSD’s. Without any intelligence such as IO Optimization, Write Coalescing or Write Ordering, it is possible that via Write Amplification, much more data is written in the Flash cells of the SSD, than is sent as MB/s to the SSD. MLC SSD’s can thus fail within one or two years (or less) even though vendors promise that they, when full 1x per day, should last for 5 years. Vendors often word the text of the warranty provisions so that this is not covered by the warranty.
In other words, SSD must be regarded as a disposable article that could probably be replaced every year, thus significantly increasing the costs. Stating the life expectancy is very important. Predicting when a SSD fails, can significantly increase the uptime of the VDI infrastructure. BTW: setting-up your SSD's in RAID1 or RAID10 is not a good countermeasure..
The right balance
How can you obtain the right balance between Capacity/IOPS and Capacity/GB? When designing an environment and determining the required capacity, a number of scale factors must be taken into account:
- Temp files and temporary Internet files
- vSwap (esx) or saved state file (Hyper-V)
- Page file
- Split profile into app data, local/roaming and settings
- Application virtualization, sandboxes or caches
These factors are housed in a delta file of the stateless VDI solution. Thus, stateless workstations do not have the complete disk size required for their (Windows) workstation, but only the difference in relation to a basic image. By cleverly manipulating this basic image, the size of such a delta file can be limited to a few Gbytes.Technologies that enable this include:
- VMware Composer (linked clones)
- Citrix Machine Creation Services (differencing disks)
- Citrix Provisioning Service (write cache)
- Microsoft Image Management for VDI
Other rules are applicable to stateful workstations where the basic OS is also included in the storage per user.
During the past few years, IOPS has been a key success factor in the implementation of a VDI infrastructure. By making the correct calculation and deploying adequate disks/spindles, it can be ensured that adequate performance is available for the virtual desktops. As a result of this, many GB’s became available for storing temporary information, and the required storage capacity was also often available.
Moreover, the availability of new fast flash-based storage solutions has turned things around. The IOPS no longer present a problem, and the performance of the desktops is superb. However, the choice of a flash-based storage solution has an impact on the available storage capacity. Affordable solutions are available with a capacity varying from 320GB, 640GB to, for example, 1.2TB. IOPS is no longer a discussion point these solutions are so fast that other components have to do their utmost to keep pace. The storage capacity is however limited, thus oversizing of required storage capacity per VDI workstation can have an extremely negative impact on the total number of VDI workstations per host. Correct sizing of this required storage capacity is thus extremely important, but how much space is actually required per VDI workstation/user, and which options exist for optimizing this?
More More More
The detailed whitepaper explains the sizing guidelines for server resources such as CPU, Memory and Storage. It also explains the impact of storage on single image management, sizing delta disk/files, impact on Application Virtualization and more. Whether you're interested in VDI, in the process of designing VDI, increasing the amount of concurrent users or investigating why the End-user experience isn't great, this whitepaper is a good read!
When you have feedback on the whitepaper?! please let me know firstname.lastname@example.org or twitter @rspruijt
PS: It's on our 'ToDo' list to write a whitepaper about solutions leveraging local storage such as VMware VSAN, Pernixdata, Nexenta etc. so stay tuned.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.