Welcome to the (mini-)series on VNX Performance and how to leverage SSD in a VNX systems. You can find part one on skew and data placement over here. The second post discussed the improvements for FAST Cache in VNX OE 32. This third and final post will discuss some of the ideal use cases for SSD in a VNX.

If you’ve got SSD in a VNX you can use it in two ways: as FAST Cache or as an extreme performance tier in your storage pools (FAST VP). Either of these implementations has advantages and disadvantages and they can also be used concurrently (i.e. use FAST Cache AND FAST VP). It depends on what you want to do…

FAST Cache vs FAST VP

If you compare FAST Cache with FAST VP, a couple of things stand out:

• FAST VP uses 1GB slices, whereas FAST Cache uses a 64KB granularity. This basically means that FAST Cache will use the SSD much more efficiently: there’s a big chance the FAST VP 1GB slice has some cold data mixed with the hot data. 
• FAST VP moves data once a day (during a relocation window). FAST Cache promotes data to SSD in near real-time, which allows it to respond to changing workloads much more rapidly.
• FAST Cache uses RAID1 (write penalty of 2) whereas FAST VP uses RAID5 (write penalty of 4). Thus FAST Cache is more efficient with a lot of random writes.

If you want the most SSD bang for your buck, you’re usually better off adding a bit of FAST Cache first (which will handle I/O bursts quite well) and only then add SSD tiers to your existing pools.

Keep in mind that FAST VP can be manipulated a bit with the various data movement policies whereas FAST Cache is fully automated. That basically means that if you need SSD response times for a business critical application, any time and all the time, FAST Cache might not be the best fit. With FAST VP you can pin that LUN to the SSD tier and guarantee SSD performance till the world ends. With FAST Cache there is a big chance data that is idle for some time will be de-staged to rotating disk. The next time the application bursts again FAST Cache will first have to promote the data back to SSD, resulting in a temporary (possible unacceptable) higher response time.

FAST VP and Thin LUNs

Say you’ve got a pool with thin LUNs. As you undoubtedly already know thin LUNs are carved from 1GB slices which are allocated on demand. With all these slices roaming around in the storage pool, a fair amount of metadata is required to keep track of the location of all this data. If this metadata is not in memory/cache, it will have to be paged into memory from disk resulting in a delay. This is the main reason for the loss of performance compared to a thick LUN (worst-case up to 50% slower than a thick LUN).

The presenter at EMC World 2013 discussed an example where he then added a bit of flash to the storage pool. FAST VP will move the metadata for the thin LUNs to the flash tier. Now if the metadata is not in memory it will still be paged in from disk but it is coming from very fast drives. The end result was a thin LUN that approached 90-95% of thick LUN performance! Moral of the story: if you plan on using thin LUNs, add a tiny bit of flash to the storage pool!

Sizing your pool – IOps

So how do you size your pool? There are two approaches: IOps or Capacity. Let’s start with the IOps approach since this is the most accurate approach but does require a lot more information from your environment and takes a bit more work.

First determine how many IOps you’ve got to service as a whole. Let’s assume you’ve got a workload of 10.000 IOps at a 70:30 R:W ratio going to 10TB of data.

Next up: skew. You’ve determined your skew which is at 90% (90% of the performance is serviced by 10% of your capacity). This means your highest tier will be servicing 90% of the IOps, which is 9000 IOps.

• 70% of 9000IOps = 6300 IOPs read.
• 30% of 9000IOps = 2700 host IOps write = 10.800 back-end IOps write for RAID 5.
• Total BE IOps to flash = 17.100 IOPs. Divided by 3500IOps per SSD in a VNX we end up with 4,8 drives: round up to 5 drives.

We also need 1TB of capacity on that SSD tier (10% of total capacity). Calculating with 200GB drives won’t give us enough capacity with 5 drives so we’ll have to build a flash tier out of 10 drives or use 400GB drives. In this case I’d prefer the 10-drive option: we’re already close to the max performance of those drives.

The rest of the IOps are spread out across the SAS and NL-SAS tiers: a rule of thumb here is to put 80% of the remaining IOps on SAS and 20% on NL-SAS.

• Remaining IOPs: 1000 host IOps.
• SAS: 800 IOps of which 560 IOps read and 240 IOps write. Add a write penalty of 4 and your total SAS back-end IOps is 1520 IOps.
• NL-SAS: 200 IOps, spread over 140 IOps read and 60 IOps write. Assuming large drives and RAID6, add a write penalty of 6 to come to a total back-end load of 500 IOps.

Disk performance wise this would require 8,4 15krpm SAS drives @ 180IOps/disk and 6,25 7k2 rpm NL-SAS drives @ 80IOps/disk. Rounding up gives you 10 SAS drives (2x 4+1R5) and 8 NL-SAS drives (6+2R6). Pick your appropriate disk sizes to meet capacity demands and you’re done: in this case 600GB SAS drives and 2TB NL-SAS drives would meet the requirements.

Sizing your pool – Capacity

The example above started from an IOps perspective which requires you to know a lot about the environment you’re sizing. The alternative is sizing based on capacity: you need less information and it takes a fraction of the time. Be aware though: once you start using Rules of Thumb (RoT), you start assuming. There’s a fair amount of risk involved with this approach: it will work for a lot of environments but it is not as accurate and definitely no guarantee. Accepting that, let’s dive in.

For a 3-tier environment you could size with one of these two RoTs:

• 5% SSD, 10% SAS, 85% NL-SAS or
• 5% SSD, 20% SAS, 75% NL-SAS.

For a 2-tier environment, EMC provides the following RoTs:

• 5% SSD, 95% NL-SAS. Personally I’d never use this RoT since there’s no tier to bridge the performance difference between SSD and NL-SAS, but that’s just me…
• 25% SAS, 75% NL-SAS. Add some FAST Cache and you’ve got a pretty good starting point. to later extend into 3-tier solutions.

So lets use these RoTs with our previous example of 10TB w/ 10k IOps and a skew of 90%. We start with the highest performance tier:

• 10% SSD = 1TB.
  Our skew of 90% means we’ve got a 10% flash tier. This is more than the RoT figures which assume a skew of 95%. A lower skew means that workload is a less ideal use case for flash: the performance is spread out over more capacity. In this case I’d go for the slightly more SAS-heavy RoT to make sure we have enough of capacity in the SAS tier to bridge the gap between the extreme performance and capacity tiers.
• 20% SAS = 2TB.
• 70% NL-SAS = 7TB.

For additional information check out this Ask the Expert session my colleague Rob and I hosted on the EMC Community Network a while ago. And feel free to comment or ask questions!