none
Does ODX Work with Hyper V VHDX's on SMB3 shares presented from SOFS / Storage Spaces

    Question

  • Hi

    From my understanding for ODX to work you need a storage array which supports it.

    If you have a couple of Scale Out file servers in a clustered configuration connected to a couple of JBODs (Data On), utilising storage spaces and present SMB 3 shares for Hyper V VHDX's? Will i get the benefit of ODX?

    I am looking at designing a new storage platform and would like to move away from the "traditional SAN" setup. I would like to leverage ODX for live storage migrations as well as rapid deployment of VMs from an SCVMM library ( I know SCVMM has its own requirements to make ODX work for VM deployment)

    Is using JBOB > Storage Spaces > SOFS > SMB 3 > Hyper V a supported configuration for ODX to work?

    Thanks

    John



    • Edited by John Horne Tuesday, May 13, 2014 7:45 PM
    Tuesday, May 13, 2014 7:44 PM

Answers

  • ODX is a function of a storage array.  The high-speed copy is possible because the storage controller within a storage array has access to both the source and destination.  It can transfer the contents of the information without the data having to pass outside of the storage array.  What you are describing is software defined storage.  Your only possible way of getting it to work would be if DataOn provided the capability.

    . : | : . : | : . tim

    Friday, May 16, 2014 10:13 PM
  • Hi Tim

    Thanks for you reply

    I understand the requirement for ODX to work but essentially the combination of JBODs and SOFS "storage headers" is the storage array. Therefore it would only seem logical for a SOFS JBOD combination to support ODX?

    Cheers

    John. 

    It's not currently possible to have an ODX on a setup like that. Nothing inside referenced JBOD is going to help you as it's a very dumb piece of the hardware, there's no CPU or memory inside to actually parse SCSI commands and instead of just passing them to SAS drives (what SAS expanders inside a SAS JBOD actually do) do translate them into something different or handle the commands that are not passed to SAS drives at all (ODX extensions implemented @ block level). It's not a SAS-attached SAN or clustered SAS RAID controllers that handle any extra logic, it's where Storage Spaces software implementation kicks in.

    In the referenced stack (SMB 3.0 -> Storage Spaces -> SAS) it would be completely up to MSFT to support ODX somewhere in the transition of a file -> block stacks (I guess actually both). For now they just don't do it and I guess it's one of the few places where hardware SAN (Dell Compellent, EMC VNX, HP 3PAR etc) would work better (other place is scalability as active/active SANs with MPIO have bandwidth increased with any extra controller/head thrown in, compare to Scale-Out File Servers design where every single hypervisor "talks" to current SMB 3.0 share owner, one-at-a-time and number of SOFS nodes does not matter).

    So the only thing you need is just sit and wait when MSFT will release R3 or whatever update to Windows Server 2012 :)

    P.S. Just for reference, we do support VAAI for VMware and will support ODX in a "classic" (storage and compute layers are separated) and "converged" (storage co-existins with hypervisor on the same hardware) scenarios soon even in a free versions of our software. But unfortunately it's for iSCSI only, to do ODX with SMB 3.0 and SOFS we need more integration with MSFT.


    StarWind VSAN [Virtual SAN] clusters Hyper-V without SAS, Fibre Channel, SMB 3.0 or iSCSI, uses Ethernet to mirror internally mounted SATA disks between hosts.

    Tuesday, May 20, 2014 2:09 AM

All replies

  • Hi John,

    " If you have a couple of Scale Out file servers in a clustered configuration connected to a couple of JBODs (Data On), utilising storage spaces and present SMB 3 shares for Hyper V VHDX's? Will i get the benefit of ODX? "

    Rapidly import and export Hyper-V virtual machines that are stored on an ODX-capable storage array and accessed via iSCSI, Fibre Channel, or SMB file shares .

    Please refer to following link:

    http://technet.microsoft.com/en-us/library/hh831628.aspx

    Also here is the link regarding SOFS :

    http://blogs.technet.com/b/storageserver/archive/2013/10/19/storage-spaces-jbods-and-failover-clustering-a-recipe-for-cost-effective-highly-available-storage.aspx

    Hope it helps

    Best Regards

    Elton Ji


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Thursday, May 15, 2014 9:05 AM
    Moderator
  • Hi Elton

    Thanks for your reply.

    I have came across the articles before but I cant find anywhere that specifically states that the setup I have mentioned, JBOB > Storage Spaces > SOFS > SMB 3 > Hyper V, will perform ODX.

    Therefore if I deploy a JBOB > Storage Spaces > SOFS > SMB 3 > Hyper V platform will ODX work?

    Has anyone been able to test this in the past?

    Cheers

    John.

    Friday, May 16, 2014 2:47 PM
  • ODX is a function of a storage array.  The high-speed copy is possible because the storage controller within a storage array has access to both the source and destination.  It can transfer the contents of the information without the data having to pass outside of the storage array.  What you are describing is software defined storage.  Your only possible way of getting it to work would be if DataOn provided the capability.

    . : | : . : | : . tim

    Friday, May 16, 2014 10:13 PM
  • Hi Tim

    Thanks for you reply

    I understand the requirement for ODX to work but essentially the combination of JBODs and SOFS "storage headers" is the storage array. Therefore it would only seem logical for a SOFS JBOD combination to support ODX?

    Cheers

    John. 

    Monday, May 19, 2014 8:02 AM
  • Hi Tim

    Thanks for you reply

    I understand the requirement for ODX to work but essentially the combination of JBODs and SOFS "storage headers" is the storage array. Therefore it would only seem logical for a SOFS JBOD combination to support ODX?

    Cheers

    John. 

    It's not currently possible to have an ODX on a setup like that. Nothing inside referenced JBOD is going to help you as it's a very dumb piece of the hardware, there's no CPU or memory inside to actually parse SCSI commands and instead of just passing them to SAS drives (what SAS expanders inside a SAS JBOD actually do) do translate them into something different or handle the commands that are not passed to SAS drives at all (ODX extensions implemented @ block level). It's not a SAS-attached SAN or clustered SAS RAID controllers that handle any extra logic, it's where Storage Spaces software implementation kicks in.

    In the referenced stack (SMB 3.0 -> Storage Spaces -> SAS) it would be completely up to MSFT to support ODX somewhere in the transition of a file -> block stacks (I guess actually both). For now they just don't do it and I guess it's one of the few places where hardware SAN (Dell Compellent, EMC VNX, HP 3PAR etc) would work better (other place is scalability as active/active SANs with MPIO have bandwidth increased with any extra controller/head thrown in, compare to Scale-Out File Servers design where every single hypervisor "talks" to current SMB 3.0 share owner, one-at-a-time and number of SOFS nodes does not matter).

    So the only thing you need is just sit and wait when MSFT will release R3 or whatever update to Windows Server 2012 :)

    P.S. Just for reference, we do support VAAI for VMware and will support ODX in a "classic" (storage and compute layers are separated) and "converged" (storage co-existins with hypervisor on the same hardware) scenarios soon even in a free versions of our software. But unfortunately it's for iSCSI only, to do ODX with SMB 3.0 and SOFS we need more integration with MSFT.


    StarWind VSAN [Virtual SAN] clusters Hyper-V without SAS, Fibre Channel, SMB 3.0 or iSCSI, uses Ethernet to mirror internally mounted SATA disks between hosts.

    Tuesday, May 20, 2014 2:09 AM