Windows Server 2012 introduces many, many, many new features. Just in the realm of storage it would be difficult to cover all storage features in appropriate detail within a single blog post. This post is just one installment about Windows Server 2012 storage features. Those of you with MSDN subscriptions may have noticed that the RTM ISO images for Windows Server recently landed in the download area. If you’re like me, this means it is time to update all the servers and virtual machines in the home lab to the latest Windows Server OS. Storage is such an important piece of any server deployment. Therefore, it is important to have a good understanding of the new features and capabilities for storage that Windows Server 2012 provides. This seems like a good opportunity to highlight one of the new Windows Server 2012 storage features known as Storage Spaces.
When I first loaded a beta build of Windows Server 2012, I noticed something new and thought, “What are Storage Spaces and when would I want to use them?” A seemingly valid question led to some research, experimentation, and delight. From a high level, Storage Spaces are all about provisioning storage based on a pooled model…while making management of some types of storage easier. By using Storage Spaces, you have the ability to organize storage in a different way.
Perhaps you have:
- Storage you’re not using yet and plan to use later
- Storage you’re using now and may later need to expand
- Storage that you want to be able to provide some resiliency for through parity or mirroring.
You may combine various types of storage for a single use. In fact, you may use individual disks (JBOD) for Storage Spaces…even if the disks are of different capacity. For instance, have you ever had a need for storage where you didn’t have a drive available that was large enough but you had a few others around of different sizes that when put together could address the need? Storage Spaces can help with these situations also.
Sample use of Storage Spaces
When installing Windows Server 2012 on my home server, I found an immediate use for Storage Spaces that so far has relieved a constant headache. The server contains a SATA based RAID controller with 9 1TB drives. (Doesn’t everyone need that many terabytes on their home server?) That controller periodically will kick a drive out of the array regardless of how I’ve configured it and sometimes does not allow regeneration. There’s nothing wrong with the drives. I very simply put all drives into a storage pool using Storage Spaces with two of them as spares. In 4 months of constant operation no drives have experienced issues and the spares have remained available as spares. Previously, when using the RAID controller with the vendor supplied software the server was lucky to make it a couple of weeks without incident or data loss. Being a location for storing backups and iSCSI targets from my home and lab network, this system doesn’t require enterprise level I/O performance. Storage Spaces provided much more flexibility for my storage needs. In fact, performance was better than when using the vendor’s software-based raid driver. This is likely a unique situation but illustrates one possilble use.
Is Storage Spaces a technology for every situation?
When advising my customers or teaching past Windows Server curriculum, my position has been that software fault tolerance was more of a medium to low-end solution and to always go with hardware fault tolerance (RAID) when available – especially for enterprise class situations. Software FT has not typically been something to rely on as an enterprise class solution when there is a real SAN available…although there are likely exceptions. Storage Spaces has something for many different situations and is available to the enterprise customer as well. My standard disclaimer regarding storage is that testing is a wonderful way to scope out how technology fits different situations and it is always wise to prove out how particular storage or storage configuration does or does not address the needs of applications.
If you’ve used Windows Home Server before, you may find that Storage Spaces seems somewhat familiar but is not exactly the same and should not be assumed to be the same thing. Storage Spaces brings some features formerly only available in enterprise class storage to the scene that may fit a number of situations well.
Storage Spaces: Benefits and Limitations
Some of the goals of Storage Spaces include the ability to:
- Obtain and easily manage reliable and scalable storage with reduced cost
- Aggregate individual drives into storage pools that are managed as a single entity
- Utilize simple inexpensive storage with or without external storage
- Provision storage as needed from pools of storage you’ve created
- Grow storage pools on demand
- Use PowerShell to manage Storage Spaces for Windows 8 clients or Windows Server 2012
- Delegate administration by specific pool
- Use diverse types of storage in the same pool: SATA, SAS, USB, SCSI
- Use existing tools for backup/restore as well as VSS for snapshots
- Designate specific drives as hot spares
- Automatic repair for pools containing hot spares with sufficient storage capacity to cover what was lost
- Management can be local, remote, through MMC, or PowerShell
It is also possible to utilize Storage Spaces with Failover Clusters. However, with clusters you are limited to Serial Attached SCSI (SAS) as a storage medium. Failover clustering does not support Storage Spaces using other storage technologies. Just because the list above mentions USB as a capability doesn’t mean use of USB storage on a server with other faster storage in the same pool is a good idea. Use of USB in a pool may be more practical on a Windows 8 client or while developing a proof of concept. Performance of this technology depends also on the performance capabilities of the storage you choose to pool together.
With goals in mind, below are some additional limitations:
- Not supported on boot, system, or CSV volumes
- Drives must be 10GB or larger
- When you introduce a drive into a storage pool, the contents of the drive being added will be lost.
- Add only un-formatted/un-partitioned drives
- A simple storage pool must consist of at least one drive
- A mirrored pool must have at least 2 drives. For 3-way mirroring there is an obvious need for more
- Three drive minimum for using Parity
- All drives in a pool must use the same sector size
- Fibre-channel and iSCSI are not supported
- Storage must be storport.sys compatible
- Virtual disks to be used with a failover cluster that emanate from a storage pool must use the NTFS file system. ReFS or third-party file systems may be used for other purposes
Creation of Storage Spaces is easy via the UI in File and Storage Services. Very simply choose to create the storage pool, select the disks and you’re done. After that, you may create volumes based on that pool. The UI can show you for each selected storage pool what virtual drives it provides and what physical drives provide the storage of the selected pool.
How does Storage Spaces work?
The volumes you create within a storage pool are basically virtual disks located on the storage pool that you may then partition, format, and assign drive letters as applicable. Storage Spaces maintains the health of these drives and any redundancy selected. Storage Spaces stores metadata on every volume within the storage pool that defines how data will be stored within the pool.
If you’re really technical and look at the device stack for a disk on occasion within a debugger, you would notice that access to a virtual disk that is part of a storage pool also utilizes the SpacePort.sys device driver. This is a necessary driver to provide the Storage Spaces functionality within Windows. You may also find this driver within Device Manager listed under Storage controllers as Microsoft Storage Spaces Controller. Further, when you look at an actual disk device with something like the System Information tool under System Tools, you will note the model as Microsoft Storage Space Device.
Typical provisioning for a volume that uses all available space is referred to as thick provisioning. It is possible to use thin provisioning with Storage Spaces which allows allocation of virtual drives larger than available space. With thin provisioning, blocks are only used from the pool as used by virtual disks. With thick provisioning, virtual disks will use and map all available space from the storage pool. However, be aware that when using thin provisioning, it is important to monitor disk usage closely to avoid the reality of an overcommitted pool. You may still add additional space to the pool as needed by adding additional drives. Also note that thin provisioning is not supported with failover clusters.
All storage that meets acceptable criteria for Storage Spaces will be placed in the Primordial Pool. This can be considered the default pool for devices from which any other pools will be created. Consider the following sample of a Primordial Pool:
Notice that there are no other virtual disks or pools at this point. The Primordial Pool will only consist of physical storage devices that do not belong to any other pools. What is nice is that when managing multiple servers within Server Manager, you can see available storage pools at a glance:
In a later post I plan to cover some of the PowerShell cmdlets that pertain to Storage Spaces. The Storage Spaces feature itself is definitely worth understanding as it provides some great features, capabilities, and flexibility within Windows Server 2012. Until then, I hope you will try out Storage Spaces.