SanDisk SSD Boot Storm Testing for Virtual Desktop Infrastructure (VDI)

(1)

SanDisk

®

SSD Boot Storm Testing

for Virtual Desktop Infrastructure (VDI)

(2)

(3)

Introduction

For virtualized desktops, Virtual Desktop Infrastructure (VDI) administrators rely on underlying storage performance to meet the necessary storage I/O (input/output) operations that become centralized when desktop operations move from the client-side flash or hard disk drives (HDDs) in laptops or desktops, to a centralized storage repository .

Fast response times from underlying storage for VDI are important to deliver productive end-user experiences . Prolonged or short spans of insufficient storage I/O during peak workloads can result in poor end-user satisfaction and the inability to perform end-user tasks .

Because VDI storage read/write operations are centralized, selection of underlying storage is critical to satisfy heavy I/O performance, such as boot storms, for end-user productivity and satisfaction .

To help VDI administrators understand the performance characteristic of solid state drives (SSDs) and the benefits, SanDisk® provides this lab validation report to highlight how VDI administrators may leverage SanDisk flash storage products to satisfy the unique read-intensive storage I/O requirements of VDI boot storms relative to traditional HDDs .

Deployment Strategy

VDI boot storm storage I/O requirements are much higher than steady state . Proper VDI architectural planning is required for successful deployment of the VDI environment .

From a VDI deployment perspective, a desktop pool could be persistent or non-persistent; both have their own use cases and are beyond the scope of this paper . In either case, if a boot storm storage peak demand is not properly sized, the overall performance and experience will not satisfy end-user productivity . From the SanDisk testing perspective, we created a stateless (non-persistent) desktop pool where a single master image is used to deploy the end-user desktops . In this case, there is one golden copy, and delta drives (linked clones) are created for each user desktop from this master image .

When boot storms occur, all users read from a single master drive to boot-up, thus creating the

aforementioned “boot storm” that is common in VDI deployment . It is the recommendation of SanDisk that the master drive image be placed on the SSD in order to address the boot storm issue .

Replica of Master Image Delta Drive Delta Drive Delta Drive Delta Drive

View Infrastructure Datastore Desktop Pool Datastore

Master Image (Snapshot)

(5)

Testing Process

VMware Horizon View™ environment is used to test the boot storm . Two VMware® Virtual Machine File

System (VMFS) datastores were created virtually, one on HDDs and one on SSDs, to deploy the Horizon View user desktops . A desktop pool of 50 virtual machines (VMs) was created in each datastore to measure the boot storm impact .

To measure the impact of boot storms, this datastore was recreated each time with one, two, four and eight drives in the backend, with a RAID 0 configuration for both the HDD- and SSD-backed datastore . Caching is disabled at the storage controller so that each time these 50 desktops are powered

on simultaneously, there is no cache data available at the storage controller layer and the master image (desktop operating system (OS) drive) is read from the drives configured in the backend . For convenience, the VMware Horizon View infrastructure was created on a separate datastore so that each time we redeploy the 50-VM desktop pool for a different number of drives, the whole environment does not need to be rebuilt .

Each time the datastore is recreated, the Horizon View pool is redeployed on the HDDs or SSDs datastore where the boot storm test was run .

VMware View™ Planner, VMware’s proprietary VDI workload generator tool, is used to power-on these

desktops simultaneously . The storage I/O and latency measurements were done by capturing the “esxtop” performance data in batch mode while the desktops were booted .

Complete boot time for each pool of 50 desktops is measured by using the VMware View Planner total boot time measurement script .

For the SSD used in this test, we selected our Optimus Ascend™ SAS SSD which is designed for typical mixed-use application workloads . Through a combination of unique and innovative IP, and the use of enterprise Multi-Level Cell (eMLC) flash, SanDisk’s newest generation of 19nm SSDs feature a native SAS 6Gb/s interface, outstanding performance metrics, and a comprehensive set of high-end features making them ideal to integrate with existing infrastructure for a wide variety of enterprise environments such as servers, external storage arrays, and storage area networks (SAN) where performance and high-availability are required .

(6)

Test Configuration A

VM VM VM VM

HDD VMFS Datastore Hosting VMware Horizon View Desktops

VM VM VM VM VM VM VM VM

SSD VMFS Datastore Hosting VMware Horizon View Desktops

VM VM VM VM

Figure 2 (B): Eight HDDs and SSDs are configured in storage controllers 1 and 2

Test Configuration B

VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM

HDD VMFS Datastore Hosting VMware Horizon View Desktops SSD VMFS Datastore Hosting VMware Horizon View Desktops

Figure 2 (B): Four HDDs and SSDs are configured in storage controllers 1 and 2

Figure 2 (C): Two HDDs and SSDs are configured in storage controllers 1 and 2

Figure 2 (D): One HDD and SSD are configured in storage controllers 1 and 2

As shown in the above figures, the server is powered down each time the drives’ configuration needed to be changed . Once reconfiguration is done, the server is powered on and then the desktops’ pool is recreated on top of that particular storage profile and a boot storm test for 50 VMs is executed .

Test Execution and Results

Following are the test results of 50-VM simultaneous boot time . The total boot time for the boot storm is measured using the View Planner time measurement script .

(7)

50-VM Simultaneous Boot

Eight HDDs/SDDs Four HDDs/SDDs Two HDDs/SDDs One HDD/SDD

Total Boot T ime ( sec ) 1,200 1,000 800 600 400 200 0 HDD SSD 263 70 75 76 74 471 595 1,072

Figure 3. Total boot time of 50 VMs

As we can observe from the above total boot time bar graph, the total time taken for 50 VMs to boot-up is almost the same for each of the four SSD test combinations . Below the graph shows comparison of one SSD vs eight HDDs storage results while the boot storm is occurring in the server . The below measurements were made at the adapter level to accommodate all 50 VMs concurrent operations .

Drive IOPS

Eight-HDD IOPS One-SSD IOPS

0 50 100 150 200 250 0 50

Time (sec) Time (sec)

10,000 8,000 6,000 4,000 2,000 0 30,000 25,000 20,000 15,000 10,000 5,000 0

(8)

Drive Latency

Drive Throughput—Read Throughput (MB/sec)

Eight-HDD Read Latency One-SSD Read Latency

0 50 100 150 200 250 0 50 Time (sec) Millisec Millisec Time (sec) 90 80 70 60 50 40 30 20 10 0 3.5 3.0 2.5 2.0 1.5 1.0 0.5 0

Figure 5 (A): 50-VM read latency during boot storm operation

Drive Throughput—Write Throughput (MB/sec)

Eight-HDD Write Latency One-SSD Write Latency

0 50 100 150 200 250 0 50 Time (sec) Millisec Millisec Time (sec) 100 80 60 40 20 0 2.5 2.0 1.5 1.0 0.5 0

Figure 5 (B): 50-VM write latency during boot storm operation

The above charts show that the read latency is 30x lower and write latency is 50x lower during the boot storm for the SSD compared to the HDDs . Low latency is an important SSD benefit and is what provides the faster boot time of the compared user desktops .

High latency limits the IOPS of each HDD when all the VMs tried to read the OS image at the same point in time, whereas for the SSD; very low latency could drive high IOPS without any issue .

(9)

Drive Throughput—Read Throughput (MB/sec)

Eight-HDD Read Throughput One-SSD Read Throughput

0 50 100 150 200 250 0 50 Time (sec) MB/ sec MB/ sec Time (sec) 160 140 120 100 80 60 40 20 0 400 350 300 250 200 150 100 50 0

Figure 6 (A): 50-VM read throughput during 50-VM boot storm

Drive Throughput—Write Throughput (MB/sec)

Eight-HDD Write Throughput One-SSD Write Throughput

0 50 100 150 200 250 0 50 Time (sec) MB/ sec MB/ sec Time (sec) 14 12 10 8 6 4 2 0 60 55 50 45 40 35 30 25 20 15 10 5 0

Figure 6 (B): 50-VM write throughput during 50-VM boot storm

From the throughput charts, we have a similar observation . As the latency in the SSD is much lower than the HDDs, it can drive higher throughput thus enabling quicker availability of end-user desktops for usage .

Test Result Observations

(10)

Test Bed

The following tables describe the test bed used for the testing:

ESXi Host and Storage Configuration

Hardware Specification

Servers • 2-socket 8-core Intel®_{Xeon CPU E5-2667 v2 @ 3 .30GHz} • 256GB of RAM

Storage • 15K RPM HDD

• Optimus Ascend™_{SAS SSDs from SanDisk}_®

Table 1. ESXi host hardware

Software Configuration

Software Installed

• VMware vSphere® 5 .5

• VMware Horizon View™ 5 .3

• VMware View™ Planner 3 .x

• Win 7—64bit OS for Desktop • Windows® 2008 R2 for View

Infrastructure

Table 2. Software installed for swap-to-host cache testing

Conclusion

VDI is a type of workload that needs different drive sizing strategy at different times . As we saw, the boot storm is a read-intensive operation, whereas when the user desktops are in a steady state, it becomes a more write-intensive than read-intensive operation .

It is important that each of these unique requirements be addressed in its own way to have a successful VDI deployment . Other VDI administrative operation such as pool creation, recompose of pool, anti-virus patch updates, etc ., need similar attention for the right drive sizing and deployment .

It’s very clear from the boot storm study that the SSD solution is the key for a successful deployment of VDI desktops . If we delve into the details of the study, we can see that for a pool of 50 user desktops, eight HDDs are not good enough to have an acceptable boot time service level agreement (SLA) . As we scale more and desktop density increases in a given server, the individual and total boot time of all desktops will be significantly higher, leading to failure of VDI success .

Since boot storm management is one of the critical administrative operations in the VDI environment, a detailed cost analysis will not make a significant impact unless all required sizing parameters are considered .

(11)

Acknowledgments

The following groups helped in executing the tests and preparing the document: • SanDisk Technical Marketing

• SanDisk Product Marketing • SanDisk Outbound Marketing

Resources

Customers can find more information about SanDisk and VMware via the links listed below:

SanDisk Resources

• SanDisk official website: www .sandisk .com

• SanDisk ESS Products: www .sandisk .com/business-solutions/#virtualization VMware Resources

• VMware official website: www .vmware .com • VMware memory management technique:

www .vmware .com/files/pdf/perf-vsphere-memory_management .pdf • VMware customer study on memory overcommitment:

http://blogs .vmware .com/virtualreality/2008/10/memory-overcomm .html

Products, samples and prototypes are subject to update and change for technological and manufacturing purposes .

SanDisk Corporation general policy does not recommend the use of its products in life support applications wherein a failure or malfunction of the product may directly threaten life or injury . Without limitation to the foregoing, SanDisk shall not be liable for any loss, injury or damage caused by use of its products in any of the following applications:

• Special applications such as military related equipment, nuclear reactor control, and aerospace • Control devices for automotive vehicles, train, ship and traffic equipment

• Safety system for disaster prevention and crime prevention • Medical-related equipment including medical measurement device

Accordingly, in any use of SanDisk products in life support systems or other applications where failure could cause damage, injury or loss of life, the products should only be incorporated in systems designed with appropriate redundancy, fault tolerant or back-up features . Per SanDisk Terms and Conditions of Sale, the user of SanDisk products in life support or other such applications assumes all risk of such use and agrees to indemnify, defend and hold harmless SanDisk Corporation and its affiliates against all damages .

Security safeguards, by their nature, are capable of circumvention . SanDisk cannot, and does not, guarantee that data will not be accessed by unauthorized persons, and SanDisk disclaims any warranties to that effect to the fullest extent permitted by law .

This document and related material is for information use only and is subject to change without prior notice . SanDisk Corporation assumes no responsibility for any errors that may appear in this document or related material, nor for any damages or claims resulting from the furnishing, performance or use of this document or related material . SanDisk Corporation explicitly disclaims any express and implied warranties and indemnities of any kind that may or could be associated with this document and related material, and any user of this document or related material agrees to such disclaimer as a precondition to receipt and usage hereof . EACH USER OF THIS DOCUMENT EXPRESSLY WAIVES ALL

(12)

At SanDisk, we’re expanding the possibilities of data storage . For more than 25 years, SanDisk’s ideas have helped transform the industry, delivering next