button-print-blu20 SAN Fine Tuning v’s Fat Tuning

The Nimble Storage feature set allows for per-Volume based Storage Profiles, this  “Fine Tuning”  allows the creation of multiple Datastores, each with different Performance Profiles. Caching, Compression and Snapshoting (Protection Profiles) can all be enabled independently, even different Block sizes can be defined on a per volume level. The best feature is that these attributes can be changed at any point in the future. Below you can see an image of the GUI when you first define a Volume.

button-print-blu20 SAN Fine Tuning v’s Fat Tuning  Nimble-Performance-Policy-300x152 SAN Fine Tuning v’s Fat Tuning

 

This is in stark contrast to the traditional process of designing Storage Arrays where-by you have to use a ‘crystal ball’ to look forward and assign RAID groups and Tiering levels at the point of ordering your SAN. I appreciate that additional Drive Trays can be added in the future, but generally speaking what you order on day one is what you get. Hopefully these devices will have been specified by size, spindle count and RPM to give the best price/performance for the customer. In essence, you now have your flag nailed to the cross and it is not an easy job to reconfigure the LUN sizes or performance profiles. This is what I refer to as ‘Fat Tuning’ a SAN.

As an example, below you can see the ‘design’ for a VNX5300 (where the spindle count and RAID groups are defined at the outset).

button-print-blu20 SAN Fine Tuning v’s Fat Tuning  Nimble-Performance-Policy-300x152 SAN Fine Tuning v’s Fat Tuning  Fat-Tuning-228x300 SAN Fine Tuning v’s Fat Tuning

Compromises are always made, over allocation of particular resources are the norm. Ultimately, when the space runs out on your High Performance RAID volume or SQL gives way to VDI in the data centre,  you are forced to extend in to another storage tray and do the whole RAID guessing game again. Worse still some vendors insist on selling you a complete new Head Unit – non of this is necessary with Nimble Storage.

IOPS are never in question either, as these is handled by the CPU on the controller, de-coupled from the spindle count and physical disk performance. No more fancy calculations on IOPS per disk… remember these?

button-print-blu20 SAN Fine Tuning v’s Fat Tuning  Nimble-Performance-Policy-300x152 SAN Fine Tuning v’s Fat Tuning  Fat-Tuning-228x300 SAN Fine Tuning v’s Fat Tuning  Fat-Tuning-IOPS-300x99 SAN Fine Tuning v’s Fat Tuning

3 thoughts on “SAN Fine Tuning v’s Fat Tuning

  1. I remember the conversations with customers during pre-sales engagements when working with the traditional vendors. How much capacity do you require? How many IOPs do you need? Now let’s break this out by applications and decide which will sit on which raid group. Now balance capacity with performance for that application and plan the raid groups, pools, etc. Now update the number of disks you might need. Wait, we now need to add another disk shelf. Hold on, can we add more shelves to this loop? No, do we have any more ports? No, do we have an empty slot to add another card? It was a lengthy process that often went through many iterations when requirements changed .Now we sell Nimble, the questions are simply, how much capacity do you need and roughly how many IOPs. In some cases, I don’t even have to ask the IOPs question because these things are so darned fast!

Leave a Reply

Your email address will not be published. Required fields are marked *

WordPress spam blocked by CleanTalk.