Sizing EMC VNX for VDI Workloads

1© Copyright 2012 EMC Corporation. All rights reserved.

Sizing EMC VNX for VDI WorkloadsVMware View and Citrix XenDesktop


Introduction This sizing guide is specifically targeted at

“Linked-Clone” or “Non-Persistent” users Presents a simple to use building block

approach to sizing VDI workloads Based on the EMC Whitepaper:

– http://www.emc.com/collateral/software/white-papers/h11096-vdi-sizing-wp.pdf


Important Items for Proper Sizing Read / Write ratios Linked-Clone vs. Persistent users Concurrency of logged in users Login and Logout behaviors of the users Steady State / Normal IOPS Image Optimization


Importance of Image Optimization Each desktop creates unique

storage IO Optimize the desktop

– Remove unneeded features– Offload antivirus w/ vShield

Endpoint Huge factor in shaping user

experience, performance & cost


Here Comes the IO Storm… IO Storms are the peaks that occur in the

VDI storage lifecycle Each “storm” has it’s own attributes that

make it nasty– Boot Storms – Read Intensive– Login Storms – Write Intensive– Logout Storms – Read Intensive


VDI Technology Overview VMware View

– View Composer Citrix XenDesktop

– Provisioning Server (PVS)– Machine Creation Services (MCS)– Personal Virtual Disk (pvDisk)


VMware View: Composer Overview View Manager works

with View Composer– Composer manages the

“Linked-Clones” Persona at the array or

network levels


VMware View: Storage Mapping Replica Images created

from a Master Image Replicas can be placed

on specific data stores Linked-Clones are related

to a replica


CITRIX: MCS Overview Storage Array stores

“linked-clones” Gold-Images

distributed to the data stores

Relies on Storage Array performance


CITRIX: MCS Storage Mapping Master Image Base Image

– Placed on every datastore Differencing Disk

– One created per desktop– Persistent OR Non-Persistent

Identity Disk for each VM


CITRIX: PVS Overview PVS Server “streams”

desktop images Storage array stores

the changes– Aka “Write Cache”

Relies on Network– TFTP, DHCP, DNS


CITRIX: PVS Storage Mapping Master Image

– Stored on or “behind” the PVS Server

– Streamed to the guest via the network

Write-Cache (aka “Linked-Clone”)– One created per desktop


IOPS Flow: View Composer & CITRIX MCS Read/Write ratios

are very important Slight overhead at

the Hypervisor DRAM and FAST

Cache absorb most of the IOPS


IOPS Flow: CITRIX PVS Most Read IOPS

from the PVS server ALL Writes go to

VNX DRAM & FAST Cache

absorb most IOPS


IOPS Distribution Differences


The VNX Platform


The VNX Building Block

Start with these calculations Add in drives for Hot Spares and VNX System

Based on 1000 Desktops @ 8 IOPS

DRIVESSSD/EFD 15K SAS

VMware View2 (RAID 1)

15 (RAID 5)Citrix (MCS) 20 (RAID 5)Citrix (PVS) 16 (RAID 10)


Adjusting SAS Tier for Capacity

Each customer can have different linked-clone capacities per virtual desktop

– Driven by optimizations, profile size, and duration of desktop use

Provisioning Method

Maximum Desktop Space / User300GB 15K SAS 600GB 15K SAS

VMware View 3GB (RAID 5) 6GB (RAID 5)CITRIX (MCS) 4GB (RAID 5) 8GB (RAID 5)CITRIX (PVS) 2GB (RAID 10) 4GB (RAID 10)


Selecting the RIGHT VNX Model… Consider your future scaling requirements

– Each array supports a maximum workload– Mixing workloads leads to unpredictable results

Using the VNX Building Block Approach…– A VNX 5300 can run 1,500 users @ 8.2 IOPS…– So…then it can run 750 users @ 16.4 IOPS

How do we figure that out for a VNX 5300?– IF: 1,500 users X 8.2 IOPS = 12,300 IOPS – THEN: 12,300 IOPS / 16.4 IOPS per User = 750 Users


Selecting the RIGHT VNX ModelModel: VNX 5300 VNX 5500 VNX 5700 VNX 7500

Max Users1: 1500 3000 4500 7500Data Movers2: 1 or 2 1,2, or 3 2, 3, or 4 2 to 8

Min form Factor: 7U 7U-9U 8U-11U 8U-15UMax Drives: 125 250 500 1000Drive Types: 3.5” EFD, 15K SAS, 7.2K NL-SAS, 2.5” 10K SAS

Block Protocols: FC, iSCSI, FCoEFile Protocols: NFS, CIFS, MPFS, pNFS

1 Max users @ 8.2 IOPS / User2 Required for NFS Datastores


Sizing the Data Movers for NFS Each Data Mover is good for about

12,300 IOPS Don’t forget to apply redundancy

– Always use N+1 When in doubt, round up Number of Data Movers will be a

factor in selecting the right array


Sizing and Scaling the Configurations Not all sizing requests are going to match the

Reference Architecture metrics How can we use the building blocks to

accommodate different sizing scenarios? Multiply the “Building Blocks” to account for

increases in Users or IOPS


How to use the VNX Building BlocksFirst Scenario (Base Building Block):1000 users @ 8.2 IOPS [1]

In this Scenario, we need • 1000 concurrent users• 8.2 IOPS / User

That matches our Base VNX Building Block…so we don’t need to calculate that any further

The VNX Building Block (for View) is made up of:• 2 EFDs • 15 SAS Drives

(Plus Hot Spares)


How to use the VNX Building BlocksSecond Scenario (Lets Increase the concurrent users):3000 users @ 8.2 IOPS


That is 3x the user count from our base building block, so we can pretty much just use 3 “VNX building blocks”…

That would be 6 EFDs and 45 SAS Drives


(Plus Hot Spares)


How to use the VNX Building BlocksThird Scenario (Lets Increase the concurrent users & the IOPS):3000 users @ 16.4 IOPS


That is 3x the user count & 2x the IOPS/User from our base building block, so we can pretty much just use 6 (3 x 2) “VNX Building Blocks” to handle the increased users and IOPS

That would be 12 EFDs and 90 SAS Drives


(Plus Hot Spares)


How to use the VNX Building BlocksLet’s put some math to the building blocks to make

it a bit easier to size for even more scenarios…

We know that the base example is:1000 Users

8.2 IOPS / User


How to use the VNX Building Blocks

1500 users @ 20 IOPS [4]

1500 Users / 1000 Users per VNX block = 1.5 20 IOPS / 8.2 IOPS per User per VNX block = 2.5

Let’s put those 2 calculations together…1.5 x 2.5 = 3.75 VNX blocks


Don’t forget about User Data…

Number of Users

DRIVES Maximum user data w/ Drive Capacity7.2K NL-SAS 1 TB 2 TB 3TB

1000 16 (RAID 6) 10 GB 20 GB 30 GB

Home Directories and Persona need network storage– Remember all of the data that sits on the legacy desktop

HAS to go somewhere– Personal Cloud storage may be a good fit for the Home

Directories and User Shares (but not Profiles) Sizing for User Data is about Capacity…mostly


Factors that can affect your sizing… Lot’s of Master Images / Pools

– If you have more than 8 Pools, you need more storage

Persistent Desktops– Fully provisioned desktops are a totally different

workload as they don’t efficiently leverage FAST Cache


Simplifying the VNX Building Blocks

Calculate the numbe

r of deskto

p drives`

Calculate

additional

application

storage requirements

Choose the

appropriate

desktop drive based

on capacity

Calculate the

number of Data Movers required if using

NFS

Choose the

appropriate user

data drives based

on capacity

Choose the appropriate VNX

Model

Add additio

nal Flash drives based

on VNX Model

Add additional Flash drives due to

multiple Master/B

ase Images

See the VNX Sizing Guide companion XLS file to do the math for you(Get the file from: http://comunity.emc.com/docs/doc-14069)

Documents

Sizing EMC VNX for VDI Workloads