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.
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).
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?