At home I typically purchase storage based on my requirements for storage capacity.  For a laptop or desktop, the question might be, “ will the 250GB drive be enough for all my kids stuff, or do they need something larger?”…or,” How large a USB disk do I need to backup all my pictures?”

I spent a number of years “back in the day” working with Exchange, so at work I’m much more sensitive to the performance of a storage platform or solution, with the storage capacity sometimes being a secondary consideration. 

Storage subsystems for high-performance applications like databases and messaging are sized and purchased for their ability to support a particular peek load of IOs Per Second (IOPS) based on the anticipated read and write behavior of applications. 

Storage Used to Be Easy, but IOPS Were not Cheap

When selecting a storage subsystem storage architects have traditionally considered the IOPS that a particular model of disk will support, overall number of disks, the impact of the “protection level” (RAID 1 / RAID 5 / RAID other) on performance, and the bandwidth of the disks and the end-to-end system.

Generally speaking, if you wanted twice the performance from storage, you would double the number of spinning disks in the system.  You could also perhaps purchase “faster” drivers.  Perhaps your server  or sub-system was using SATA attached disks rotating at 7,200 RPM.  If you replaced them with drives spinning twice as fast (like much more expensive 15,000 RPM SAS attached drivers) you would be able to support more IOPS (at a much higher cost).

Yes, of course there are other considerations (impact of things like controller-based caching, replication technologies, cloning and snapshots, backup tools, rebuild speed), but IOPS per disk has always been a core consideration, and performance of many storage subsystems is ultimately bound by the IOPS of the attached, individual spinning disks.  The performance of subsystems based upon traditional spinning disk is something that can be estimated, and has been for years.

Storage Is Still Easy, and IOPS are Getting Less Expensive

You really don’t need that high IOPS capacity for all your data – not all of your files or their chunks are being used all at once.

What if you could use those same spinning disks…or less expensive slower disks for the same workloads, but still meet the same peek IOPS-related demands?  That is exactly what the tiered storage capabilities in Windows Server 2012 R2 can do!

Tiered Storage will let you deploy Windows Server 2012 R2 file services  for exceptional $ / IOPS, by allowing you to do the following:

• Define virtual disks made up of fast SSDs and slower, less expensive spinning hard drives
• Automatically Identify key, active files and pin them to the super-fast SSD drives – improving overall performance
• Manually pin key files to fast SSD drives, using simple PowerShell 
• Cache peek file and database writes to the same virtual disk (the SSDs) to smooth out write IO until later, when things calm down 

Must See TV:  TechEd Session on Exceptional $/IOPS

There was a great session at TechEd this past June, 2013 titled,
”Deploying Windows Server 2012 R2 File Services for Exceptional $/IOPS”.

This is a MUST WATCH SESSION if you work with Windows and storage.  The presenter went into great detail on the economics of IOPS, as well as how to use Storage Spaces with Tiered Storage…this is what motivated me to create that high-performance, coffee-table-based SAN (yeah, SAN is a stretch) that I showed you in my last blog post.

Next up, I’ll go into details about my cool table-top storage rig.

-John