Windows Server 2012 R2 Beefs Up Storage Spaces

I must admit I wasn’t terribly impressed when I first heard about Windows Server 2012 Storage Spaces. Microsoft was building direct-attached storage (DAS) support into applications like Exchange and SQL, and I viewed Storage Spaces as another way for Microsoft to shift IT costs from hardware to software. I looked at Storage Spaces as a cluster-aware volume manager: an easy way to turn a shared SAS JBOD and a pair of Windows Servers into a clustered NAS with software RAID. I sure never thought about it as a performance play.

But with Windows Server 2012 R2, scheduled for release later this year, Microsoft has improved Storage Spaces by adding the ability to use SSDs for automated tiering and/or write-back caching. It might be because I've seen a half-dozen "software-defined storage" packages in recent years and have become more open to the idea, but I find Storage Spaces a bit more impressive now. Let's take a look at the new functionality.

Microsoft beefed up Storage Space’s strengths, including the software RAID engine, which, like a Compellent or 3Par array, works by spreading the stripes data and parity information across all the drives in the storage space. The company added double parity using a Microsoft Research-developed algorithm that rebuilds with less I/O than the standard Reed-Solomon RAID-6. Microsoft also added support for new SAS JBODs with expanders and enclosure services, making Windows Servers aware of enclosure events and temperatures.

The automated tiering feature uses the SSDs and HDDs in a Storage Space as a pool. It then tracks the access frequency of data chunks at a 1-Mbyte granularity so it can dynamically promote and demote chunks based on their I/O “temperature.” Tiering is a scheduled Windows task that by default runs at 1 a.m. every day. Administrators can adjust the schedule and set limits on the amount of the SSD tier that can be replaced in each scheduled tiering adjustment.

In addition to the automatic tiering, administrators can pin high I/O, or otherwise latency sensitive files, like VDI “gold images” to the SSD tier without having to dedicate volumes for them. The tiering traffic is only sent to disks when the queue for that disk is one or less, limiting the performance impact of a tiering operation. However, like any other daily tiering system, it will be most effective with repeatable workloads.

The write-back caching feature creates a separate write-back cache for each accelerated volume from available SSDs in the Storage Spaces pool. The cache is intended to be stored on an SSD that’s shared in an external SAS JBOD to make the cache persistent across server failures in a Windows Server, including Hyper-V and clusters using cluster shared volumes (CSV). Microsoft has been careful to promote the write-back cache as being a solution for short write bursts, which leads us to believe that they’re only supporting a limited write-cache size in the initial release.

[SSDs have a range of storage uses, including supporting VDI performance. Find out how in "Solving VDI Problems With SSDs and Data Deduplication."]

Conspicuously missing is any form of read caching. When we asked the Microsoft folks about this, they pointed at the various RAM caches in Windows, but those are very small compared to a modern SSD read cache. I found it interesting that all the ISVs--such as FlashSoft, VeloBit and Intel--decided to build read caches, but Microsoft choose to do the trickier write back caching and automated tiering.

Storage Spaces is intended as a replacement for traditional SAN storage with the Windows Server directly addressing disk drives, SDDs and HDDs. While it may be theoretically possible to expose SDD and HDD logical drives from a SAN array to a Windows server, and to use Storage Spaces to create a tiered pool from those LUNs, this configuration is not supported by Microsoft. That leaves space in the marketplace for caching ISVs as an acceleration tool for SAN arrays.

Storage Spaces may turn out to be a perfectly good way to build a server cluster and storage. I’m afraid as good as it may be, it has two strikes against it:

1.It’s for shared SAS JBODs, not pooled internal server disks, which is becoming the new fashionable software defined storage model. Those SAS enclosures still cost some money.

2.Longtime storage administrators think of software RAID as a technology they’ve outgrown. Unless it’s in a shiny SDS, new technology wrapper, they’re not going to trust it. Frankly, for these guys, the new version of Windows isn’t that shiny of a wrapper.

Luckily, there are as many Microsoft loyalists as there are haters, and some of them will fire up Storage Spaces. I’d like to hear about your Storage Spaces experience--good, bad and especially ugly. Share your thoughts in the comment section below.