6

I'm setting a test lab to evaluate best solution for future production use. The production farm intended for an SMB, so budget is present, but it is also limited.

Goal for production: 3 hyperconverged servers with Windows Server 2012 R2 failover virtualization cluster and Software Defined Storage solution as shared storage. In short term the cluster will be expanded to total of 5 servers. SAN network is dedicated.

Goal for test lab: find an SDS solution, that meets following criteria:
1. Provides shared storage for Hyper-V cluster.
2. Scale-Out: can add-remove disks (and preferably - nodes as well) without shutting down the cluster.
3. Fault-tolerant. Available after loss of 1 node (if recoverable after losing 2 nodes - it is great!).
4. Low network overhead/latency (will be used for SQL Server as well).
5. Have reasonable pricing (Storage Spaces Direct is not acceptable for this reason).

After reading and looking at some products, my short-list is EMC ScaleIO and Starwind Virtual SAN.

I tried them both, and found that Starwind VSAN provides quite limited HA: as I understood it, this solution only mirrors virtual disk (namely, a file) across nodes, and only allows expanding capacity within limits of hosting disk. ScaleIO, on the contrary, spreads data across nodes, and allows adding new storage and rebalancing volumes.

So, my questions are:

  • Are my assumptions correct, or Starwind VSAN allows creating an HA volume across several disks in every node and add disks later?
  • What solution is better for my application in your opinion (please explain)?
  • What are drawbacks of advised solution?

Thank you in advance!

7

There's no good or bad here: both ref'd solutions are just very different in the way how they scale out, how they distribute data among cluster nodes and how they handle component failures.

1) Wide striping Vs Data Locality. SIO does what's called "wide striping": they keep volume data on all the cluster nodes (same way VMware VSAN & HPE VSA do) more or less equally, while StarWind takes care of that's called "data locality" (same way Nutanix NDFS and SimpliVity/HPE do) and keeps data on a limited amount of a "partners". There are pros and cons for both approaches actually.

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-data-locality.pdf

https://www.nutanix.com/2013/12/03/data-locality-sql-vdi-on-the-same-nutanix-cluster/

https://www.simplivity.com/blog/2016/05/importance-data-locality/

https://www.starwindsoftware.com/data-locality-page

2) Single Unified Address Space Vs Virtual Disks. SIO can indeed create a single unified address space but the reality is it's a useless (at least! bad idea at best!) feature in your environment: Microsoft / Hyper-V really needs AT LEAST one CSV / virtual LUN per cluster node so in your case an optimal amount of a virtual LUNs is the same and doesn't matter you use SIO or StarWind.

https://technet.microsoft.com/en-us/library/jj612868%28v=ws.11%29.aspx

https://www.petri.com/how-many-csvs-should-a-scale-out-file-server-have

https://blogs.msdn.microsoft.com/clustering/2013/12/02/cluster-shared-volume-csv-inside-out/

3) Number of Nodes and Fault Tolerance. SIO is a very similar to Ceph here: it needs quite a lot of nodes (8-10) to get a reasonable performance (thanks to "wide striping"). Also make sure you understand SIO is replication only and final capacity is (N-1)/2 so five nodes will give you 2 nodes capacity usable with a 2-way replication and an ability to lose one node only (N+1). StarWind is using a combination of a replication and a local reconstruction codes (erasure coding) to survive multiple failures at the same time thanks to the multiple fault domains, there's not only cross-node replication protection but also local "RAID" like protection, same way SimpliVity and similar to what Microsoft does in Azure/S2D.

https://www.emc.com/collateral/white-papers/h15148-emc-scaleio-deployment-guide.pdf

https://www.simplivity.com/blog/2016/10/data-storage-built-resiliency/

https://www.microsoft.com/en-us/research/publication/erasure-coding-in-windows-azure-storage/

https://www.starwindsoftware.com/grid-architecture-page

TL;DR: In general I'd suggest to build a P.O.C. for the both shortlist candidates and see how well everything goes.

  • 1
    Thank you, Baron! You gave me some good points to think about. Great links either! Went reading. – Eugene May 17 '17 at 22:37
  • 1
    If I understand your statement at 2) correctly, making one csv per node is intended for lowering traffic forwarding from VM owner node to csv owner node? Am I correct? – Eugene May 20 '17 at 14:10
  • 1
    Yes, absolutely. VMFS3/5 is a proper clustered file system, and NTFS/ReFS with a CSVFSv1/v2 bolt-on isn't, so while data transfers are direct block (well, at least they are supposed to be...), metadata transfers are always file over SMB3 redirect. – BaronSamedi1958 May 21 '17 at 11:25
  • 1
    Does this redirection produces significant load on the network and nodes? Is it best to avoid it in any environment or only in high-performance one? – Eugene May 23 '17 at 13:05
  • It isn't that much in terms of allocated bandwidth but it's huge when you hunt for low NVMe latency: these are extra hops and coordination locks/unlocks. – BaronSamedi1958 May 23 '17 at 16:12
5

The short answer is: both solutions will meet your requirements.

As already mentioned by the previous poster, they just work in a different way.

If you'd like to know about benefits / drawbacks of each solution, just contact both vendors and ask their pre-sales techs everything you'd like to know. After that, deploy a PoC and double-check what they told you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.