Posts Tagged ‘Windows 2012 R2’

Windows 2012 R2 Tiered Storage and Storage Spaces

Friday, January 3rd, 2014

In this post I shall walk you through deploying Storage Spaces and tiered storage using Windows 2012 R2.

Windows, as an operating system, has long been used to host and present shared storage. However, its management of disks has been pretty limited with Master Boot Record (MBR disks) being limited to 2TB in size and 4 primary partitions. This was improved by GUID Partition Table (GPT) disks allowing 128 partitions and 64TB disks (these limitations are imposed by Windows rather than the GPT standard). These stay in place. Storage Pools are really a replacement for the dynamic disk feature of Windows. Dynamic disks allowed for RAID arrays to be created in software for people who could not afford hardware array controllers. So, no-one used them right? After all, why would you put additional stress on your server when hardware array controllers are relatively cheap or even ship on board for most badged servers?

Again, that’s still true here with Storage Spaces but the scalability, resiliency, and optimization are improved beyond simply offering software RAID. What Storage Spaces provide in addition to RAID are two key items:

  1. Different RAID types across the same physical disks – very akin to a SAN and its ability to virtualise its disks
  2. Tiered storage between differing disks types so that files accessed more often are moved to faster storage

Now, I can see why most enterprise organisations may not be interested in the first item. After all, shared storage is probably done on a SAN which offers these facilities. I’m assuming though that this is part of Microsoft looking forward to the point when expensive shared storage is no longer required as it will be replaced by resilient server based storage presented by SMB3.

The second item is very intriguing though, even for standard file servers or other servers. What if a server contains two or more types of disks, SSD, SAS & SATA? The data can then be tiered across the disks locally with less often accessed data being placed on the slower storage. True, its Windows so this will not be block based, only file based but, if you are a smaller shop, or even an enterprise, it does allow for improved performance for some files while less often access files can be placed on larger, slower disks with the files moved between disks as needed.

NOTE: It is only possible to mark the disks as being either HDD or SSD and so only two levels of tiering are possible for any given server.

The underlying “physical” disks can still be RAIDed using hardware RAID (item 1) with tiering provided by the operating system. Couple this with data deduplication and Windows Resilient File System (ReFS – http://msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx) and you now have a 21st Century method of storing files that maximises performance, reduces storage requirements and maximises the quantity of data that a single set of disks can hold.

In short, while it may seem that the changes to storage that Windows 2012 R2 brings are, once again, not for the Enterprise, the truth is that there is something here that everyone can benefit from.

To demonstrate Storage Spaces and Tiered Storage for you I have created a VM named FILE1 in my lab and have attached 10 virtual disks to that VM – each disk is a 10GB fixed size VHDX file.

 

These disk are exposed in the operating system as offline disks.

 

As I have said, in my lab these are just stand alone VHDs. In a production environment, these physical disks may have already been grouped together in one or more RAID sets for item 1 of the Storage Spaces functionality.

We can now work with these disks to create one or more Storage Spaces. Storage Spaces are accessed from the Server Manager console under “File and Storage Services”.

 

 

Where disks have not been initialised they will have an “unknown” partition table. Ones that have previously been used will be shown with however they have been configured.

 

 

All disks that are currently unused will be placed into a “Primordial” Storage Pool. This is a default built-in pool that exists to represent unused disks within the GUI and PowerShell – i.e. all unused disks will appear here and get moved to a different pool when you assign them to that other pool.

To create a storage pool, simply click on the Storage Pools link and select “New Storage Pool” from the Tasks menu.

 

 

 

The wizard will start.

 

Give the Storage Pool a name.

 

 

And assign physical disks to the pool. We will later, when we create Virtual Disks within the pool, set which level of RAID should be used. We can set the disk to three types of allocation “Automatic”, Manual” or “Hot Spare”.

 

 

In my Pool I have two hot spares that can be bought online if one of the disks fails (an improvement over dynamic disks which did not provide for hot spares). Volumes will automatically be allocated to disks. If I had selected “Manual” for the Allocation type then volumes would need to be manually assigned to individual disks within the pool providing greater control but increased administrative overhead.

Our storage space is then created.

 

 

Note the choice to automatically launch the virtual disk creation wizard. This creates what you and I would think of as being a volume on the disk if you will. It is a virtual disk but gets presented within the operating system as a physical disk. At this point, we have allocated 8 of our 10 spare disks to the storage pool. Looking at Disk Manager you can see that these are now no longer available for use by the operating system.

 

 

Our Primordial storage space also has only two disks still available for allocation with the balance of disks participating in our new storage pool.

 

 

In my lab the disks are of media type “Unknown” (right click the disk and select properties).

 

 

We can issue a PowerShell command to instruct the operating system that some of our disks will be standard hard drives and some will be SSD drives.

Set-PhysicalDisk –FriendlyName <MyDiskName> -MediaType <MediaType>

Where MediaType is either SSD or HDD. For example:

 

 

We can repeat this for each disk in the pool. To demonstrate Storage Tiering I have marked 4 of the drives as SSD and 4 of the drives as standard HDD.

 

 

NOTE: Running the above command before the disks have added to a storage pool results in an error. Adding the disk to a storage pool allows the media type to be set.

 

 

After assigning media types to the disk, close and reopen Server Manager to refresh the disk information. With our storage pool created we can now run our “New Virtual Disk” task.

 

 

 

This starts a wizard.

 

 

We select the pool of storage we want to create the virtual disk on.

 

 

We provide a meaningful name for the VHD to be created. This could indicate the type of data the drive will hold or could, as I have done, indicate which disk is allocated to which drive letter. I have NOT chosen to use tiering for this disk but will for the disk I create next so that you can see the difference in subsequent screens.

 

 

 

We then get to assign a RAID level to the VHD to be used across the portions of the physical disks that we will be using.

 

 

The layout values are roughly similar to

  • Simple = RAID0
  • Mirror=RAID10 + JBOD
  • Parity=RAID50 + JBOD

Here, we have not used a hardware load balancer as there would be little benefit in RAIDing already raided drives in software. The above is merely to demonstrate the power of storage virtualisation provided within windows.

Next we select to use a thick or thin provisioned virtual disk.

 

 

If we use a fixed size VHD we consume the space on the disks now, whether we will use it or not. Thin provisioning, while more economical with our disk space, does come at a price though and that this the overhead associated with expanding the disk out as more data is added. As the effect of this is lessened once files begin to be deleted (are they ever on a file server?) this will affect performance of the whole. Whether this is noticeable to users will depend on a number of factors such as network speeds, server speeds, physical disk speeds etc. but it will be slower than using a fixed disk.

Here I have selected to use a thinly provisioned image. Our pool contains 8 disks each of 10GB. 2 of those were marked as Hot Spares leaving a maximum of 60GB available for allocation. After overhead, we have as little as 55.5GB available for use (6 x 9.25GB).

NOTE: The Server Manager GUI reports ALL disk space available for use even though some of the disks are allocated as Hot Spares

 

 

We can then specify a size for our virtual disk. Note that I have set mine to be 500GB in size, even though our Storage Pool only has 72GB of free space.

 

 

We can increase the free space simply by adding more disks to the Storage Pool. Disks can also be of different sizes and different speeds (unlike with hardware RAID) as they are seen as JBOD with the storage being carved up. We can then follow the wizard to the end at which point of virtual disk will be created.

NOTE: Additional space will be consumed as storage will be allocated for use as a write cache. The quantity of storage used for write cache can be set when creating the disk using PowerShell. For example:

$HDD = Get-StorageTier -FriendlyName HDDTier

Get-StoragePool “user Data” | New-VirtualDisk -FriendlyName “F Drive” -ResiliencySettingName Parity –StorageTiers $HDD -StorageTierSizes 8GB -WriteCacheSize 1GB

 

Once our virtual disk has been created then, by default, we will be asked to create a volume on that disk.

 

 

Again, this is a wizard driven exercise.

 

 

The disk available to use is the one we created above. Note that the disk number is 11, the next available disk number along. Even though the physical disks are not surfaced within Disk Management the disk numbers are still allocated and in use.

 

 

The same as when we are working within Disk Management, we can allocate a size to the volume created.

 

 

And present it as a drive letter or mount point.

 

 

We then select the file system to be used, NTFS or ReFS together with a block size. ReFS only allows for 64K blocks whereas NTFS can take advantage of the 4K block size.

 

 

Note also that short file name generation is disabled by default to speed up writing to disk. This is also disabled for Windows 8 which may cause issues for you if you have software that relies on the short file name format being present. For example, the legacy versions of the Citrix Access Gateway Secure Client relies on this and will no work on volumes created with Windows 8 (for example, Windows 7 images created using SCCM 2012 SP1). Note also that, while I have named the drive “Slow User Data” this is not totally true as we have used automatic allocation for the space used and so, inevitably, some will be allocated on the faster drives in the storage space.

Following the wizard to the end now creates the drive for us which is exposed in Windows Explorer and in Disk Management.

 

 

 

As you can see, the operating system believes that it has 499GB of storage (of the 500GB allocated to the drive) after overhead demonstrating that the drive is thin provisioned.

We can follow the same process once more but, this time, choose to create tiered storage. Tiered storage is only supported with fixed disks.

 

 

In addition, Parity striping is not supported. Only simple volumes or striped volumes can be used.

 

 

As discussed above, if hardware array controllers are in use managing RAID within hardware, it may be worth considering deploying the storage as “Simple” to maximise the space on the basis that hardware failure at the disk level is already catered for by the array controller.

As tiered storage cannot be thinly provisioned, this choice is greyed out.

 

 

Note that we are now presented with a different screen to configure the tiered storage.

 

 

The virtual disk will be split between the two types of storage in these quantities which also sets the fixed disk size. Note also that the creation of our thinly provisioned disk from the previous step consumed ~ 15GB of storage even without data being written to the disk. This overhead should be taken into account for any sizing exercise for new deployments.

Again we can follow the wizard to the end at which point we will be asked to create a volume on the disk as previously. We can then continue to create additional disks, either fixed size or thinly provisioned, until our disk space in the Storage Pool is fully consumed. As with any disk, monitoring should be enabled to alert when disk space is getting low but this is especially true for Storage Pools where thinly provisioned disks can rapidly consume any spare space leaving no writable area available.

When creating our pool, we can also set the disk allocation to Manual.

 

This does prevent the use of Storage Tiering though.

Microsoft do not recommend mixing and matching automatic and manual allocation of disks in the same pool.

 

 

If we do set all disks to be manually allocated then two new screens are added to the virtual disk creation wizard. The first asks which disks should be used to store the data.

 

 

The second sets performance setting for the virtual disk.

 

 

As you can see, Storage Spaces are an exciting addition to the Windows Operating System which now allows you to virtualise and optimise your storage whatever your budget.