Server 2012 and 2012 R2 introduced the concept and tool of Windows “Storage Spaces”. To be frank, I was royally confused by what they were and what purpose they served until I sat through a 2012 R2 Jumpstart. Now I “see the light” so I hope to be able to share the light with you. (Oooo, I get to be evangelical about something Windows … imagine that!).
Storage Spaces, in a nutshell, is Microsoft’s method of giving you all of the benefits of of SAN’s (iSCSI, FibreChannel, you name it) without all of the attendant costs and headaches. When combined with other Microsoft technologies like SMB3 and clustering, Storage Spaces can give you an 800 pound gorilla from a storage perspective that you could NEVER have had before at such a low price point. The key to all of this is understanding what Storage Spaces are and how they work.
So, what IS a Storage Space??? A Storage Spaces is basically a “group” of storage that you put together based on directly-attached storage (DAS) that the Windows Server can see (preferably on a SAS connection but also works with SATA) that gets sliced up, provisioned for specific tasks and is then shared out. It really is no different in basic concept from what you do with SAN or NAS storage but it is all controlled from Windows and is specifically sliced up to support very specific Windows functions. The really big thing to get your head wrapped around is that you hand over RAW storage to Windows and let it manage things. In other words, if you have a server full of disks or that is connected to a box of external disks, you DON’T RAID the disks on the server controller EXCEPT for the twin disks you will use for the O/S drive! Storage Spaces will manage the RAID tasks for you except for the C: drive; in fact, Storage Spaces CANNOT be used for the O/S drive hence the requirement that you RAID your O/S disks at the controller level (if you want the redundancy and safety of RAID for your O/S drive – and you DO want this, don’t you?). You can add any disks you want into a Storage Space including disks on separate controllers as well as different sizes and types of disks including HDD’s and SSD’s.
2012 R2 Storage Spaces have been enhanced to provide “tiering” capabilities when you build a Storage Space with both HDD and SSD drives. The tiering capability will then manage “hot” and “cold” data automatically and move “hot” data to the SSD’s and “cold” data to the HDD’s, all “on the fly”. In fact, the tiering is smart enough to only move what is truly “hot” to the SSD’s meaning it is block oriented rather than file oriented. This means that if you have space from a Storage Space shared out via SMB3 and have Hyper-V VM’s VHD/VHDX stored on that share, only the actual “hot data” from the VHD/VHDX will be on the SSD! Therefore, a relatively small amount of SSD space can radically speed up a number of server operations as precious SSD space is not wasted on warm or cold data. This is pretty revolutionary stuff when you consider that a RAID card manufacturer like LSI will charge you anywhere from $5,000 to $10,000 for a controller card that does something somewhat similar. (There are a few caveats about choosing your disks types in this case, more on this later in the post).
When you add disks to a Storage Space there is no RAID just yet, the Storage Space just groups together the RAW disks. The Storage Space will list the aggregate of all the available disk space as the space you can play with without any sort of RAID applied. Therefore, if you add two 1TB drives to a Storage Space the available space will display as 2TB. This is also the case when you add in SSD’s as well as HDD’s; the Storage Space at this point is just the big “blob” of disk that you have given it. To use the space you need to create a “Virtual Disk”. When you create a virtual disk you define how much space you want, you define the RAID level you want (mirrored [RAID1], parity [RAID5] or simple [no RAID]) and, if using 2012 R2, you can also define if the Virtual Disk is tiered (if you have SSD’s and HDD’s). Once you do this the “carving up” of the space is performed and a useable “drive” of appropriate size and RAID type is available for sharing or for use on the local server. In theory and in practice, this Virtual Disk is not much different from the RAIDset or virtual disk that you can create at the controller level. The “goodness” comes from the ease at which you can build the virtual disk out of the various building blocks you supply (the disks and SSD’s) as well as from the tiering capability because all of this is “inbox” with Server 2012/2012 R2; there is nothing extra that has to be purchased. And given an appropriate amount of CPU and memory resources on the server, Storage Spaces can do quite a lot with disks and SSD’s attached to a cheap, dumb controller.
Let’s take a look at a Storage Space on my home lab boxen:
Just to refresh things, I have two whitebox servers each with an eval copy of Server 2012 R2 loaded. One of the servers has a bunch of SATA disks attached (a smallish boot disk and three 1TB drives) as well as a single SATA Crucial M500 SSD and it has the Storage role enabled.. This is the box that I am using to demo Storage spaces. The other box has a single 1TB boot drive and the Hyper-V role enabled and I am using it to host Hyper-V VM’s that will reside within the Storage Space on the first host and will be accessed over SMB3 links.
Here’s how the storage looks before I start to build a Storage Space:
The item in yellow is the SSD. At this point I have a 149GB boot drive as well as one of the 1TB drives split up into an E: and F: drive. The SSD and two of the 1TB drives are currently not used. Looking at Storage Pools I see the following:
Note the Storage Spaces and the term “Primordial”, this indicates that a Storage Space can be created as there is unallocated disk space available to be used in a Storage Space. In the Physical Disks pane you can see that there are 4 physical disks available. Disk0 is the SSD ad DIsks1 & 2 are the completely unused 1TB SATA drives (I know this from the previous screen). Disk4 has some unused space available but the disk is not completely unused. I’m now going to build out the Storage Space.
Right-click on the blue Primordial Pool and select New Pool:
Now you need to name the pool and give it a description:
Now you add the disks:
Note how the system knows the MEDIA TYPE and also note the total capacity. As I stated earlier, this is simply an aggregate total of all the disk space that is being added to the pool, it is not necessarily the amount of disk space that will be made available for use.
At this point the Storage Pool is created as can now be seen on the Storage Pool pane:
Note the Capacity and the Free Space for the pool are both 1.93TB and there is nothing showing as allocated. Now we have to “carve out” a Virtual Disk out of the space in order to be able to create a drive that can be shared out. To to this we have to run the New Virtual Disk Wizard from the Tasks drop down in the Virtual DIsks pane:
You need to highlight the desired Storage Pool (I only have one but there could be many to choose from):
This next screen is where things get “interesting”. I can name the disk and give it a description AND I can choose to create “Storage Tiers”. For the sake of example I’m going to go through this piece twice as there is a very important concept that comes into play at this point that you will need to grasp in order to understand what happens in the next few steps. The thing to remember is that when you create a virtual disk you are essentially creating a RAIDset from the building blocks in the storage pool itself. You can create a “Simple” layout meaning data is striped across disks (join them together for more disk space) but without ANY redundancy, You can create a Mirror (two-way meaning you need matching pairs of disks or three-way meaning matching trios of disk) which gives you redundancy in case of a disk failure (think RAID1). Finally, you can create a Parity set using at least three disks (think RAID5). The bigger thing to remember is that as soon as you add tiering into the mix you need to ensure you have enough matching SSD’s to fit the RAID model you are building. In other words, if you are going to mirror two HDD’s and you want to tier them then you will need to have two matching SSD’s in the storage pool that are selectable in order to be able to build the tiered mirror. You cannot build a tiered mirror or parity set with only a single SSD. To see what I mean let’s go through two examples.
Example 1: I will build a 1TB mirror out of my current storage pool that is NOT tiered
On the following screen I can provision space as THIN or FIXED. I won’t go into detail here as it is a whole other discussion but for this example I will pick Fixed.
If you are eagle-eyed you’ll note that I created the space smaller than what is actually available. This is so there is room available for a write-back cache as noted on the screen. I found by trial and error that it is a good idea to leave space for the cache.
OK, I cancelled the Volume Creation wizard. Now the Storage Pool pane shows this:
I now have a 900GB mirror that I can do something with, I’m going to delete the mirror and rerun the above steps and add in tiering. Keeping in mind my note about matching disk availability, given that I have 2 1TB HDD’s and a single SSD, what do you think I’ll be able to create? Let’s see …
Lots happening here! The system is only listing SImple and Mirror as my choices and it won’t let me create a Mirror? Why not?? Because I don’t have multiple SSD’s of matching capacity in the Pool! While I have the required number of HDD’s I’m woefully short on SSD’s so the system has blocked me. If I switch to a Simple layout (no redundancy) I should be able to proceed.
Now the next screen gets interesting!
Wow! This is cool! I can set space used for each tier size. Keep in mind that you are not ADDING SSD space to an overall volume size, you are setting the amount of SSD space to use for “hot data” within the tier. In other words, the Standard Tier (HDD) size will actually determine the overall size of the volume that you are creating. So, If you want a 1600GB useable volume (remember to save room for the cache) then you set that on the HDD tier. I am going to set 109GB on SSD and 1600GB on HDD:
And now I see I have a tiered disk:
And while it does list the Allocated space as 1.67TB the actual useable space will be 1.56TB (the HDD space) as the SSD is strictly for HOT data within the disk. So, allocated space is not the same as useable space.
Would I use a Simple tiered disk like this in production? No way! It could break far too easily (no redundancy). However, it is good enough for lab use and I will blog some more about the whole hot/cold data premise behind the tiering in follow up posts. Also, is it a good idea to mix super fast SSD’s in a tier with relatively slow 7200 RPM SATA disks? In terms of a production system, probably not, as the performance of the tier will be decidedly unbalanced. In a production environment you would probably want nothing slower than 10,000RPM SAS HDD’s mixed in your tier with your SSD’s in order to have a reasonable balance of performance. However, for a lab test system my tier is “good enough” to prove out the concept.
I hope this post helps with your basic understanding of Storage Spaces in Sever 2012/2012 R2. As usual, I’m only scratching the surface but I hope it helps you to see the possibilities of what you can do with this “in box” feature of Server 2012/2012 R2.