Hyper-V, Clustered Storage Spaces & Scale Out file Server – What do they do and what can I mix tohether?

In Windows 2012 a lot of emphasis was put into storage. Multiple technologies were introduced including SMB 3.0 – File share for large workloads (Mainly Hyper-V & SQL), ODX – Offloading storage commands directly to storage, VHDX file format and more.

Along with these came Clustered Storage Spaces and scale out file server. Both are cluster technologies that allow you in some form or another to build your own storage. Now there is a bit of confusion between the differences of these two technologies, when to use which, and when to use them together. So I’m going to try to help clear this up.

Lets start with Clustered Storage Spaces:
Clustered Storage Spaces allows you to connect a Jbod (Just a bunch of disks) directly to your clustered servers using SAS and use that Jbod as shared disk space for your cluster.

A few points:

  1. A Jbod is a raidless array of disks. So it’s fairly cheap. Windows 2012 storage spaces will create a redundant array of disks for you.
  2. The Jbod has to be connected directly to all servers in the cluster using a SAS connection.

Windows 2012 will create a redundant array out of the Jbod disks. The disks don’t even have to be the same size. Windows 2012R2 will even allow you to add SSD’s to the mix as tiered disks. Hot blocks will be automatically moved to the SSD’s for better performance.
Now clustered storage spaces is meant to be used in conjunction with an existing cluster as it presents shared disks to the cluster. So you can enable it on any windows cluster. This includes Hyper-V, SQL server, Exchange Server, File servers…

Your Clustered storage space is going to look something like this:

CSP1

Now you could even use 2 Jbods and span the array between them. This will improve resiliency as you could lose an entire Jbod and still have a fully working cluster.

Scale Out File Server:
Scale out file server, often refered to as SoFS, is a clustered file server-based on the new SMB 3.0 protocol. It is intended for storing Hyper-V VM’s and SQL server databases. It is not intended to be used as an actual file server. Once presented with shared disks the SoFS created a redundant Active/Active (Yes that is correct Active/Active) SMB 3.0 Share. The Share as already stated can be used for Hyper-V VM’s. I’ll state the benefits of this in a future post.

Now as SoFS is a cluster role it is not supported to install SoFS on the same cluster as your Hyper-V Servers. It is possible (for a lab) but not supported. You can as previously stated use Clustered storage pools and Sofs together. For use with Hyper-V you need 2-4 servers for SoFS Cluster and 2 or more servers for your Hyper-V Cluster.

So to summarize:
You can Install a Clustered Storage Pool along with a Hyper-V Cluster or a SoFS Cluster.
You may not install a SoFS cluster together with a Hyper-V CLuster. You need separate Servers for this.

If you don’t have an SMB 3.0 capable storage I highly recommend deploying a SoFS server either with your existing block storage or a Jbod and Clustered storage space and using this as your Hyper-V VM storage. It requires an extra couple of servers but the advantages of SMB 3.0 are well worth it.

Advertisements

12 thoughts on “Hyper-V, Clustered Storage Spaces & Scale Out file Server – What do they do and what can I mix tohether?

  1. Thank you for your post
    I have a quick question please.
    Could you please clarify the deployment steps in more details for above scenario?

    Traditionally, we used to point each Hyper-V node to iSCSI target or FC shared storage and then build the cluster, however with SMB we have SoFS cluster 2 or 4 nodes with shared JBOD storage and then Hyper-V compute nodes 2 or 4…

    The Scale-Out File server requires a shared storage and Hyper-V requires a shared storage as well.

    The Virtual Machines are Saved on SoFS \\VMShare\TEST.vhdx

    How the Hyper-V compute cluster is built? Where is the Quorum disk and CSV?

    The SoFS is sharing the JBOD and the cluster is easy to be built, what about the Hyper-V cluster?

    Thank you.

    Kind regards,

    • Hi Charbel,

      gladly.

      First of all the Sofs requires shared storage as you stated. This can be Iscsi or Fiber, and the 3rd option is using a jbod and clustered storage space.
      These are the same options that can be used on Hyper-V aswell.
      Now once you’ve set up a SoFS your hyper-v no longer requires traditional shared storage. in affect the Sofs (which is a file share based on SMB 3) is your shared storage. So Hyper-V no longer requires a CSV.
      Regarding the Quoram, when you set up the Cluster you have the option to place the quoram on a file share, I think it states for special deployments, so this is the option that you’ll choose.
      Basiucally as you stated the Sofs will share the Jbod or another form of storgae and the Hyper-v cluster will use this share as its shared storage.
      I hope this clears it up for you?

  2. Thank you dear Gil for your kind reply,

    Now the concept is clear.

    If possible please when you have time to develop a step by step installation plan end to end with Hyper-V cluster over SMB to understand the design in practice?

  3. Great article, did you manage to get dedup to run in the live VHDx files? Was planning on testing this in our lab next week

    • Yes, it works fine on live VHDX files. As long as they are hosted on a SOFS 2012R2 server (R2 being the key here).
      Also, it is only officially supported for VDI though it will ofcourse work on any form of Virtual machine.

  4. Great article Gil !
    I have exact the same setup as in the picture (2 Hyper-V nodes, 1 JBOD storage). My goal is build a Hyper-V 2012R2 cluster using SMB 3 file shares. I want to use the benefit of SoFS using a file share for the VMs. But I haven’t got the SoFS as physical machines. Can I deploy the SoFS cluster nodes (one of them on each Hyper-V node) as a VM? Does it make sense. I am not clear on this.

    Thanks,
    Joerg

  5. We are looking to implement this type of solution, but with 2 JBOD enclosures for redundancy. In my testing, I have not been able to figure out how to make sure they are redundant to each other.

    • The disks are presented to the OS as indepenedant disks. When you create your pool choose an equal amount of disks from both Jbods this will mirror the data between the two.

      • Is it not the case that a third JBOD is required for enclosure resiliency, in order to act as a quorum? Two JBODs will allow for mirrored data across them, but a single failed JBOD will take the whole lot down as it cannot reach quorum.

      • No, The servers running the clustered storage space need to reach Quorum. This can be achieved with a 3rd server or a Quorom Disk or file share. The JBOD itself has no awarness of clustering or the actuall enviroment it is running in. All of that is handled by the servers running the cluster.

  6. Hi Joreg, You technically use a VM as a SOFS server but this is unrecomended and unsuported. As in this kind of scenario your going to have the SMB traffic from the Hyper-V host pointing to a VM that it is hosting…. I think you get my jist that this is going to cause perfromance issues. So no it isn;t a good idea to uses Vm’s as your SOFS.

  7. Pingback: Gil Gross on Microsoft | Step By Step – Setting Up A Scale Out File Server For Hyper-V

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s