In this blog post we will show you how to configure the JBOD storage space in Windows Server to create a failover cluster. This cluster can then be used to create a small Hyper-V cluster or an SMB 3.0 Scale-Out File Server (SOFS). The following example has been done using Windows Server 2012 R2, but the instructions include Windows Server 2012.
In this solution we will deploy two clustered servers with a single JBOD (Just a Bunch of Disks or Just a Bunch of Drives) tray. Storage space will be created on the JBOD and be made available to applications, such as a SOFS (to share using SMB 3.0 to other servers) or Hyper-V which will be running on the two servers.
The first step will be to acquire the servers and the storage. Please consult the Windows Server Catalog to find a selection of storage that is supported for Storage Spaces. Use the guidance of that vendor to purchase disks and to cable the storage to the servers. And then you will create a normal Windows Server Failover Cluster; do not add the disks of the JBOD to the cluster during this step. The disks will be managed by Storage Spaces as a single entity.
Note that in Windows Server 2012 R2, the use of hot spares will not be recommended. Instead, a storage pool with sufficient free space can automatically perform a parallel repair process to copy redundant slabs to the remaining active disks in the pool. This parallelism allows a repair process to be completed more quickly than using a single hot-spare disk where that disk’s solo IOPS become a bottleneck … and there’s a potential risk of data loss during that recovery period if other disks fail at the most inopportune time. A new disk is added to replace the dead drive and the pool uses it simply as new capacity.
A new cluster pool will appear under Pools in Failover Cluster Manager once the New Storage Pool Wizard is completed. You don’t have usable storage just yet; you need to provision virtual disks with your chosen type of fault tolerance first.
The next step is to select the disk fault tolerance of the new virtual disk. You have three choices:
Note that WS2012 clusters only support Simple and Mirror virtual disks. Support for parity was added in WS2012 R2. It is recommended that you label the volume with the same name as the virtual disk to make this design self-documenting. The volume will eventually be used as a Cluster Shared Volume either by the Scale-Out File Server cluster role, or directly by Hyper-V running on the cluster members.
You will have resiliency options if you have chosen to create either a mirror or a parity virtual disk.
Do not assign a drive letter; there is no point in doing this because the resulting volume will eventually be used as a Cluster Shared Volume (CSV) either in a SOFS or a Hyper-V cluster. In Windows Server 2012 R2 you have a newly supported option to format this future CSV with ReFS instead of NTFS; this is great for huge volumes because there is no CHKDSK in ReFS.
The new disk will appear under Available Disks in Failover Cluster Manager. Once again, it is a good idea to rename this disk (under properties) to match the volume label and virtual disk name to make troubleshooting and documentation easier. Once done, you can convert the volume into a CSV by right-clicking on the disk and selecting Add To Cluster Shared Volumes.
The resulting CSV appears in C:\ClusterStorage as a mount point called Volume1 on every host in the cluster. This means the new virtual disk is active on every server in the cluster at once, making it a cluster file system. You can rename the anonymous sounding Volume 1, once again to match the cluster disk, the volume label, and the virtual disk name.
A useful rule of thumb is to have one CSV for each node in the cluster. WS2012 R2 will automatically balance the CSVs across each node.
This cluster and storage can now be engineered into:
This implementation is the simplest possible architecture of Storage Spaces. It can use: