Windows Server 2012 R2 – Storage tiering (TechEd Europe – part 2)

NOTE: while I’m still keeping the current posts live as they still seem to help, currently my focus has changed and new activity moved to the new site

One of the features I told you about earlier is the new storage tiering. Since the near death of fileservers in favour of storage area networks the use-cases in which an environment would draw its storage from a serverfarm has been limited except for the lower part of the SMB segment. Understandably Microsoft wants to get back onto that market and comes up with new features to get Windows storage server farms back in the picture.

The first feature is the automatic storage tiering. When having to cope with increased IOPS there are a few options:

  • Increasing the number of disk spindles, preferrably without increasing the amount of data on those disks so you’re going to use smaller capacity disks or leaving a lot of diskspace unused.
  • Buying more expensive disks (f.e. moving from SATA to SAS to FC to SSD)
  • Buying some expensive disks and using them only for hot-blocks

The latter is of course the most cost-effective: putting high-IO-intensive applications on fast disks and the rest on your normal pool. Storage pools were already available in the R1 release of Windows Server 2012 but now there’s a new sheriff in town: auto tiering. We all know auto tiering from storage vendors like NetApp, EMC, HP, Dell etc but now your local Windows machine can do the same, putting hot blocks on f.e. SSD’s and the less frequently accessed blocks on cheaper disks.

Some figures were shown and some fancy meters started jumping up and down… Unfortunately the demos at TechEd Europe were scripted, unverifiable and a bit “propagandist”. No doubt the performance boosts are considerable but the used test methods were unclear and the architecture of the setups used was not outlined. There’s also one big issue that is overlooked: hardware cost… The disk prices are the same whether you buy a SAN or a piece of compute hardware so I’ll leave that out of the equation. But to do the necessary computing (tiering algorithms, block statistics, perhaps some protocol specific offloading (software iSCSI f.e.)) will require hardware that might be too overscaled. How many Intel Xeons will we have to buy and how much RAM for each of those machines? How much power and rackspace will those machines consume in regard to a SAN?  And we all know that is the single biggest cost of your datacenter: power, cooling (getting rid again of that power consumption) and floorspace. Possibly all too much to make its TCO lower per gigabyte per month than a SAN.

Once you scale up, SAN is imho still the way to go (with some exceptions for applications that benefit from fusionIO cards or local SSD disks due too extremely high IO utilization).

If you’re looking for a solution for very small environments however then this feature will certainly break some old speed records. As long as you only use a few terrabytes then the CAPEX of a Windows storage cluster will indeed be lower than the upfront investment in expensive SAN hardware. The SMB segment might very well adopt this quite fast.


Update (27/06/2013)

In another session, specifically about HyperV and SMB storage, it became more clear how they managed to get that amount of IOPS.


A blocksize of 8KB was used. Although f.e. backupapplications benefit from large block sizes, not all applications do. If you have some services working with a lot of small files, then a smaller blocksize is more space-efficient. Large blocksizes (f.e. 8KB vs the more commonly used 4KB) will of course allow for a larger throughput in MB/s.

Network / throughput:

  • 3x 56Gb/s Infiniband multichannel, each HyperV host and each fileserver was equiped with multiple adapters to aggregate into a 168 Gb/s multichannel connection.


  • 48 SSDs and 6 JBOD arrays requiring 12 SAS interfaces on server side and an equal amount on the JBOD side.
  • Massive amounts of RAM so they could serve all data from the RAM

(Possible) conclusion

The test was just a mindblower but actually not representative. If I make a quick calculation then this “testenvironment” costs several hundreds of thousands of euro’s, including servers capable of handling terrabytes of RAM, Infiniband adapters and Infiniband switches, SAS adapters. Handling 400k IOPS and having that much bandwith might require an investment that is much bigger than buying solutions from vendors like Whiptail, Violin or some of the more traditional storage vendors. Perhaps not the same CAPEX when starting small but certainly more expensive when rolling out / migrating your entire production and upscaling to keep up with increasing storage demand.

On top of that: you’ll be 100% responsible for the uptime yourself when building such a storage cluster. No support from your hardware vendor (except for the hardware itself ofcourse) so expect to do more work yourself.

A storage cluster at this scale does not seem cost-effective imho if you start looking at the TCO including risks, maintenance mantime etc. If anyone got effective figures or another view, feel free to comment!

I’m hoping to see some third party (reliable) testresults soon with representative hardware and budgets…

(this is part 2 of several posts from Microsoft TechEd)

About Geert Baeten
IT service architect - cloud infrastructure solutions - datacenter infrastructure solutions - service design / governing processes

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: