Why Column Size does matter with Storage Spaces

I get this question a lot from customers when I’m on the road to implement and teach Windows Storage Spaces / JBOD solutions.

“How many disks should we use to start, and what’s the perfect amount of columns we should configure?” Well although this is a simple question, there is no simple answer. I’m sorry to say that here, but.. IT DEPENDS 🙂

However I’d like to highlight some facts that could help others with the descision how to size their Storage Spaces solution to prevent performance and scaling issues. Typically configurations use a “dual-mirror” or “triple-mirror” resiliency setting for virtual disks (aka spaces) on Storage Pools. So the two most important facts to be aware of here is the configuration you start with, when implementing Storage Spaces are….

Extension / Scalability

Let’s take a little example

Consider a single 24-bay JBOD filled with 8 SSDs and 16 HDDs. You Create a Storage Pool across 8 disks per type. On top you create a dual-mirrored, tiered space. It doesn’t matter if you use the Server Manager GUI or Powershell, by default you will have a column size of 4. This means, that data is written and read to/from 4 disks simultanously while the other 4 disks per type keep the copy of each data stripe on the space. So what if you want to extend the column size at a later stage to have more disks accessed at a time? This doesn’t work, You can’t change the column size for an exsiting space, so think wise before you click or run your Powershell Scripts. So what if you just want to extend the size of your tiered space? Of course you can do that. But in the scenario above, you’re limited to extend just the HDD tier by another 8 disks. The SSD tier can’t be extended referring to the image above. If you want to extend just the SSD tier, you could replace the unused 8 HDDs with SSD, but then there is no way to extend the HDD tier in the mean time? Why’s that?

A space or virtual disk has always to be extended with respect to the resiliency- and the column size setting. You cannot just replace two HDDs with SSDs and extend the SSD tier. So what’s the way here to extend both tiers?

You just add another JBOD enclosure and stick the same amount of disks per type in. This enables you to to extend the Storage Pool and the tiered Space. Remember that the column size doesn’t change by adding a second enclosure. We just have more space now.

Performance

What is the best sizing for columns? To check the performance gains between different column sizes I run a few tests. In traditional SAN or Raid Controller based setups, the more spindles you have in an so called array group the more performance you can get out. But does this apply to Storage Spaces too? The following performance report shows something interesting.

I was able to proof that changing the column size from 4 to 8 provided almost three times more IOPS as well as throughput, while increasing the columns to 8, 16 or 32 seems to always double the values.

Conclusion

More columns means more performance, but also a limited flexibility with expanding existing virtual disks, especially in tiered configurations. So what’s the best size for columns for a dual-mirror Storage Space? I tend to say, the more the better in terms of performance, the less the better in terms of flexibility for expansion. So again, it depends 🙂

One thing that I like to mention here. Unfortunately I was not in luck to have 64 SSDs to run the tests against plain SSD spaces, but I’m pretty sure that having 32 columns could produce a bottle neck on the SAS Bus side. A single SAS connection can transfer up to 6Gbps.

In a future post I will show differences regarding Interleafe Sizes, Allocation Block Sizes and file system type.