Alternative Approaches to Meeting
VDI Storage Performance Req’ts
July 2012
Eric Burgener
VP, Product Management
Agenda

The storage challenge in VDI environments

Profiling VDI workloads

Focus on SSD

An alternative approach: the storage hypervisor

Customer case studies
July 2012
2
Hidden Storage Costs of Virtualization
❶
VM
Poor performance
• Very random, write-intensive workload
• Spinning disks generate fewer IOPS
• Storage provisioning trade-offs
VM
❷
Poor capacity utilization
VM
• Over-provisioning to ensure performance
• Performance trade-offs
VM
❸
Complex management
• Requires storage expertise
• Imposes SLA limitations
• Limits granularity of storage operations
Virtual Machines
July 2012
The VM I/O Blender
3
Hidden Storage Costs of Virtualization
❶
VM
Poor performance
• Very random, write-intensive workload
• Spinning disks generate fewer IOPS
• Storage provisioning trade-offs
VM
Can decrease storage
❷ Poor capacity utilization
• Over-provisioning to ensure performance
performance by 30%
- 50%
• Performance
trade-offs
VM
VM
❸
Complex management
• Requires storage expertise
• Imposes SLA limitations
• Limits granularity of storage operations
Virtual Machines
July 2012
The VM I/O Blender
4
VDI Environments Are Even Worse

Windows desktops generate a
lot of small block writes


Even more write-intensive
due to many more VMs/host

Much wider variability between peak and average IOPS

VIRTUAL DESKTOPS
July 2012
IOPS vs throughput needs

Boot, login, application, logout
storms
Add’l storage provisioning,
capacity consumption issues
5
As If It’s Not Already Hard Enough…
HIGH PERFORMANCE
Slow provisioning
Poor space utilization
SPACE-EFFICIENT
RAPID PROVISIONING
Poor performance
RAPID PROVISIONING
SPACE-EFFICIENT
Poor performance
Thick VMDKs
Fixed VHDs
Fully provisioned
Thin VMDKs
Dynamic VHDs
Thin provisioned
Linked Clones
Differencing VHDs
Writable clones
Hypervisor storage options force suboptimal choices
July 2012
6
Thick, Thin, and Snapshot Performance
July 2012
7
Sizing VDI Storage Configurations: The Basics
1. PERFORMANCE (latency, IOPS)
2. AVAILABILITY (RAID)
3. CAPACITY
July 2012
Steady state I/O
Peak I/O
Read/write ratios
Sequential vs random I/O
RAID reduces usable capacity
RAID increases “actual” IOPS
Appropriate RAID levels
Logical virtual disk capacities
Snapshot/clone creation/usage
Secondary storage considerations
Capacity optimization technology
8
Single Image Management

How can we take advantage of many common images?

vSphere: parent VMs, snapshots, replicas, linked clones
Linked Clones
Snapshot
Replica
…
Parent VM

•
•
•
•
Reads from replica
Changes to delta disks
Space efficient
Poor performance
Compose, re-compose and refresh workflows
July 2012
9
Reads vs Writes in VDI Environments
Understand read/write ratios for
steady state and burst scenarios
VDI is VERY write intensive (80%+)
Read caches do not help here
Logs or write back cache help
READ INTENSIVE: Boot, login, and application storms, AV scans
WRITE INTENSIVE: Steady state VDI IOPS, logout storms, backups*
GOLDEN MASTERS: Read only, great place to use “fast” storage
Steady state XP Desktops
Steady state W7 Desktops
Burst IOPS
7 – 15 IOPS
15 – 30 IOPS
30 – 300 IOPS
VMware recommendations, May 2012
July 2012
* Depending on how backups are done
10
What Are My Options?
BUY MORE STORAGE



Adding spindles adds
IOPS
Tends to waste storage
capacity
Drives up energy, backup
costs
July 2012
SOLID STATE DISK
BUY FASTER STORAGE



Add higher performance
drives (if available)
Upgrade to a higher
performance array
Increased storage
complexity

Add to host or SAN

Promises tremendously
lower I/O latencies

Easy to add

Focus on $/IOPS
11
Focus On SSD
July 2012

Extremely high read performance
with very low power consumption

Generally deployed as a cache
where you’ll need 5% - 10% of total
back end capacity

Deploy in host or in SAN

Deployment option may limit HA support

3 classes of SSD: SLC, enterprise
MLC, MLC

SSD is expensive ($60-$65/GB) so
you’ll want to deploy it efficiently
12
Understanding SSD Performance
100% read max IOPS
100% write max IOPS
100% random read max IOPS
100% random write max IOPS
July 2012
115,000
70,000
50,000
32,000
13
What They Don’t Tell You About SSD


The VDI storage performance problem is mostly about writes

SSD is mostly about read performance

But there are VDI issues where read performance helps
Write performance is not predictable




Can be MUCH slower than HDDs for certain I/Os
Amdahl’s Law problem: SSDs won’t deliver promised performance,
it just removes storage as the bottleneck
Using SSD efficiently is mostly about the software it’s packaged
with
Sizing is performance, availability AND capacity
July 2012
14
Good Places To Use SSD


Cache

In host: lowest latencies but doesn’t support failover

In SAN: still good performance and CAN support failover
Golden masters



July 2012
Where high read performance is needed for various “storms”
Tier 0

To primarily boost read performance

If you don’t use SSD as a cache
Keep write performance trade-offs in mind when
deploying SSD
15
The Storage Hypervisor Concept
…
STORAGE HYPERVISOR
SERVER HYPERVISOR

Server hypervisors increase
server resource utilization and
virtualize server resources

Storage hypervisors increase
storage utilization and virtualize
storage resources

Increases resource utilization
and improves flexibility

Increases storage utilization and
improves flexibility
Performance, capacity and management implications
July 2012
16
Introduction of a Dedicated Write Log Per Host

…
HOST
Log turns random writes into a
sequential stream

HYPERVISOR

Optimized Writes
Acknowledgements
De-staging allows data to be laid out
for optimum read performance

Optimized
Reads
Dedicated
write log

Optimized
asynchronous
de-staging Tier 1

Minimizes fragmentation issues
Requires no add’l hardware to
achieve large performance gains

Tier n
Storage devices can perform up to 10x faster
The more write intensive, the better the speed up
Excellent recovery model for shared
storage environments
Tiered Storage
July 2012
17
Log De-Couples High Latency Storage Operations
THESE OPERATIONS
NO LONGER IMPACT
…
HOSTS
HYPERVISOR
VM PERFORMANCE
THIN PROVISIONING
Write Logs
ZERO IMPACT SNAPSHOTS
Storage Pool
HI PERFORMANCE CLONES
Shared Storage
July 2012
INSTANT PROVISIONING
18
The Virsto Storage Hypervisor
Fundamentally changes the way
hypervisors handle storage I/O
Improves performance of existing
storage by up to 10x
Thin provisions ALL storage with
NO performance degradation
Reduces storage capacity
consumption by up to 90%
Enables almost instant provisioning of high performance storage
Reduces storage provisioning times
by up to 99%
Allows VM-centric storage management on top of block-based storage
Enables safe provisioning and deprovisioning of VMs by anyone
July 2012
19
Virsto Architecture
Server Host

Virsto
VSA
Integrates log architecture
transparently into hypervisor

Hypervisor

Speeds ALL writes ALL the time
Read performance speedups

Storage tiering, optimized layouts
Sequential
I/OI/O
Slow,
random
Optimized
de-staging

Instant provisioning of space-efficient,
high performance storage

Scalable snapshots open up
significant new use cases

Software only solution that requires
NO new hardware
Virsto
vLog
Virsto vSpace
Block Storage Capacity
(RAID)
July 2012
Primary Storage
20
Multi Node Architecture For Scalability
Host 1
Host 2
Virsto
VSA
Host N
Virsto
VSA
…
Virsto
VSA
Hypervisor
Hypervisor
Hypervisor
Sequential I/O
Sequential I/O
Sequential I/O
Virsto
vLog
Virsto
vLog
Virsto
vLog
Virsto vSpace
Block Storage Capacity
(RAID)
July 2012
Block Storage Capacity
(RAID)
Multiple Different Arrays
21
Integrated Virsto Management

Install and configure through
Virsto Console


Uses standard native workflows


July 2012
Provision Virsto ONCE up front
vSphere, Hyper-V
Transparently uses Virsto storage

Higher performance, faster
provisioning, lower capacity
consumption, cluster-aware

Works with native tools so
minimal training
22
Virsto And SSD

Virsto achieves 10x performance speedups WITHOUT SSD and
with what you already own

But Virsto logs and storage tier 0 are great places to use SSD

Easily uses 50% less SSD than caching approaches to get
comparable speedups

July 2012

Logs are only 10GB in size per host

We make random writes perform 2x+ faster on most SSD

Very small tier 0 to get read performance (for golden masters, certain VMs)
If you want to use SSD, you spend a lot less money to
implement it
23
Proof Point: Higher Education
Baseline Environment
341 IOPS
Native VMDKs
July 2012
Performance with Virsto
10X more IOPS
24% lower latency
9x CPU cycle reduction
3318 IOPS
Virsto vDisks
Virsto for vSphere
December 2011 Results
24
Proof Point: State Government
165 IOPS
Native VMDKs
July 2012
18X more IOPS
1758% better throughput
94% lower response time
2926 IOPS
Virsto vDisk
25
Proof Point: Desktop Density
Virsto vDisks vs Native Differencing VHDs
90000
With Virsto, each host supports
over 2x times the number of VDI
sessions, assuming the same
storage configuration
80000
Weighted response time
70000
60000
50000
40000
830
401
30000
20000
10000
0
0
200
400
600
800
1000
1200
VDI session count
VSIIndex_avg - Virsto
VSIIndex_avg - DVHD
2000
July 2012
26
Case Study 1: Manufacturing
REQUIREMENTS

1200 Windows 7 desktops

Common profile


Steady state: 12 IOPS

Read/write ratio: 10/90

Peak load: 30 IOPS

25GB allocated/desktop
Need vMotion support now

HA as a possible future

Windows updates 4/year

Already own an EMC VNX
July 2012

40U enclosure w/4 trays

10K rpm 900GB SAS

100 drives = 90TB

Would like to maximize desktop
density to minimize host count

Target is 125-150 desktops/host

Will be using vSphere 5.1

Spindle minimization could
accommodate other projects

Open to using SSD in VNX

400GB EFDs

Asked about phasing to minimize
peak load requirements

Asked about VFcache usage
27
Comparing Options Without SSD
Metric
Storage Config
w/o Virsto
Storage Config
w/ Virsto
Virsto Savings
IOPS
Needed: 36,000 IOPS
Delivered: 36,010 IOPS
Drive count: 277 drives
(130 IOPS/drive)
Needed: 36,000 IOPS
Delivered: 39,000 IOPS
Drive count: 30 drives
(1300 IOPS/drive)
247 drives
Capacity
249TB (raw)
206.7TB (w/RAID 5)
(34TB needed)
27TB (raw)
22.4TB (w/RAID 5)
Thin provisioned
Easily looks like 80TB+
222TB (raw)
184.3TB (w/RAID 5)
Provisioning time
83 hrs per compose
1 min VM creation
100MB/sec network
17 hrs per compose
1 min VM creation
66 hrs savings per
compose operation
4 x 66 = 256 hrs/yr
Incremental Cost (list)
$309,750 (177 add’l
drives) + 5700 upgrade
$0
70 drives freed up
$309,750 + savings on
other projects
July 2012
28
Virsto Single Image Management
vSnap of
golden master
vClones
vClone 0
Stabilizes at 2GB*
25GB logical
12GB (Windows)

With EZT VMDKs, native consumption was
25GB x 1000 = 25TB

With thin VMDKs, native consumption
would be 25GB + (14GBx1000) = 14TB
vClone 1
Stabilizes at 2GB*
And would require 5x as many spindles for IOPS

Not workable, too many drives/arrays, etc.

With View Composer linked clones, space
consumption would be the same as Virsto
but you’d need 5x the spindle count
vClone 999
Stabilizes at 2GB*

Virsto provides better than EZT VMDK
performance with space savings of linked
clones
…
vClone 2
Stabilizes at 2GB*
12GB + 2TB = 2TB
Actual Space Consumed for Virsto
July 2012

* Based on 8 different LoginVSI runs with 1000-2000 desktops
29
Virsto Single Image Management
vSnap of
golden master
vClones
vClone 0
Stabilizes at 2GB*
25GB logical
12GB (Windows)

With EZT VMDKs, native consumption was
25GB x 1000 = 25TB

With thin VMDKs, native consumption
would be 25GB + (14GBx1000) = 14TB
vClone 1
Stabilizes at 2GB*
And would require 5x as many spindles for IOPS
Virsto 92% better than thick
VMDKs
vClone 2
Stabilizes at 2GB*



Not workable, too many drives/arrays, etc.
With View Composer linked clones, space
…
Virsto 86% better even than
thin VMDKs
consumption would be the same as Virsto
but you’d need 5x the spindle count
vClone 999
Stabilizes at 2GB*
12GB + 2TB = 2TB
Actual Space Consumed for Virsto
July 2012

Virsto provides better than EZT VMDK
performance with space savings of linked
clones
* Based on 8 different LoginVSI runs with 1000-2000 desktops
30
Assumptions



EMC VNX SSD performance

12K read IOPS, 3K write IOPS per SSD

With 2 SPs, can max out a tray w/o limiting performance
VM creation time depends on busy-ness of vCenter Server

Observed 30 sec - 1 min baseline across both Virsto and non-Virsto configs

5 min VM+storage creation time w/o Virsto, 1 min w/Virsto
Customer had chosen thick VMDKs for performance/spindle minimization


Customer RAID 5 overhead was 17%


Provisioning comparisons were EZT VMDKs against Virsto vDisks (which outperform EZTs handily)
(5 + 1) RAID
Pricing for EMC VNX 5300

200GB EFD $12,950

900GB SAS 10K RPM $1,750
July 2012
31
Case Study 1: Other Observations

Virsto vClones do not have the 8 host limit


Performance + capacity considerations limit applicability of SSD to this
environment


View Composer linked clones in VMFS datastores limited to 8 hosts
Using RAID 5, minimum capacity required is 33.9TB
Customer could not have met storage requirement with VNX 5300

Would have to upgrade to VNX 5700 or buy extra cabinets

Thin provisioned Virsto vDisks provide significant capacity cushion

Virsto vClones expected to save 66 hours provisioning time for high
performance storage on each re-compose

July 2012
That’s up to 256 hours per year clock time for provisioning (4 Windows updates)
32
Case Study 2: Financial Services
REQUIREMENTS

1000 Windows 7 desktops

Common profile


Steady state: 20 IOPS

Read/write ratio: 10/90

Peak load: 60 IOPS

30GB allocated/desktop
Need vMotion support now

Windows updates 6/year

Would be buying new SAN
storage
Would like to maximize desktop
density to minimize host count

Target is 125-150 desktops/host

Will be using vSphere 5.1

Spindle minimization could
accommodate other projects

Wants to use a SAN and open to
using SSDs

Asked about phasing to minimize
peak load requirements
HA as a possible future

July 2012

33
Comparing Options
Metric
Storage Config
w/o Virsto
Storage Config
Virsto
IOPS
Needed: 60,000 IOPS
18 x 200GB EFD 54K IOPS
62 x 600GB 10K SAS
8060 IOPS
Delivered: 62,060 IOPS
60,000 IOPS
8 x 200GB EFD 48K IOPS
16 x 600GB 10K SAS
20,800 IOPS
Delivered: 68,800 IOPS
4 x 200GB EFD
26 x 600GB 10K SAS
Capacity
37.2TB (raw)
30.9TB (w/RAID 5)
(30TB needed)
10.4TB (raw)
8.6TB (w/RAID 5)
Easily looks like 35TB+
26.8TB (raw)
22.3TB (w/RAID 5)
Provisioning time
100 hrs/compose
1 min VM creation
100MB/sec network
17 hrs/compose
1 min VM creation
83 hrs savings per
compose operation
6 x 83 = 498 hrs/yr
Cost (list)
$233,100 for EFDs
$133,000 for array/SAS
$366,100
$103,600 for EFDs
$64,000 for array/SAS
$167,600
$198,500
July 2012
w/
Virsto Savings
34
Assumptions



IBM DS5000 SSD performance

12K read IOPS, 3K write IOPS per SSD

With 2 SPs, can max out a tray w/o limiting performance
VM creation time depends on business of vCenter Server

Observed 30 sec - 1 min baseline across both Virsto and non-Virsto configs

6 min VM+storage creation time w/o Virsto, 1 min w/Virsto
Customer had chosen thick VMDKs for performance/spindle minimization


Customer RAID 5 overhead was 17%


Provisioning comparisons were EZT VMDKs against Virsto vDisks (which outperform EZTs handily)
(5+1) RAID
Pricing for IBM DS5000

200GB EFD $12,950

600GB SAS 10K RPM $1,500, DS5000 frame $40K
July 2012
35
Case Study 2: Other Observations


Virsto makes SSD perform twice as fast

Makes all writes sequential

Need 50% less SSD

10GB log in RAID 1 across 8 hosts = 160GB for logs, leaves 1.4TB available for Fast Cache/tier 0 use
Virsto cuts required raw storage capacity by 78%


Space savings conservative at only 70%


And can accommodate an additional 300+ desktops w/o more storage hardware purchases
Generally we see 80% - 90% space savings over the long term
Virsto vClones expected to save 83 hours provisioning time for high
performance storage on each re-compose

July 2012
That’s 498 hours per year across 6 Windows updates
36
Demonstrated Customer Value
July 2012
37