StarWind Virtual SAN

We have been using a StarWind Virtual SAN (VSAN) on two production locations with a Hyper-V Cluster for almost 7 years now in my current company but have 10 year of experience with the product. It has given us very good performance and we haven't had any issue with it in the past years. StarWind support is excellent, very fast and has very good knowledge of the StarWind and Hyper-V Cluster software. What we like best about it is that it's the only true two-node Hyper-V cluster solution that's available. On both production locations, we have a 2-node setup over 2 different server rooms. Our main goal was that we want to have all VM servers available on one Cluster host, in case of a disaster in one of our server rooms. Microsoft SSD (Storage Space Direct) always needs a 3rd witness (SMB or Cloud) but in ours a two-node solution this is not ideal. Direct connected fiber connections between the nodes makes everything fast and makes the chance of a Cluster split-brain fault less likely.

We will not change the selection. We also checked Microsoft SDS for our new servers but StarWind matched more with our wishes.

By Remotly viewing how the install it and with the help of there documentation you have a good idea how everything works

no

no

Yes, because it the best way to do when you have third-party software.

They always get in contact after a couple of days after they implement the software.

We are an SMB that can't be bothered paying tens of thousands of dollars just to get a proper HA storage for a two-node failover cluster. Therefore StarWind's vSAN was financially attractive from the start. The reviews you can find all over the web incentivised us to research this solution deeper (e.g. just check all the great posts vom Kooler on Stackoverflow), leading to us actually implementing it. We were coming from an S2D implementation which already gave us a ridiculous amount of headaches (bugs, performance stalls, "we know what's best for you" automatisms) IN ADDITION to being slow AND annoying to administrate/debug WHILE ALSO having the most annoying documentation ever to be created by mankind. Just the usual MS crap basically. Rush out some code and ship it and never fix anything (but break it every few weeks with patches)... The initial tests were easily implementable (without begging some sales folks for a POC, due to a free version being available) as well as proper documentation *that you actually LIKE to read due to it having been typed by a tech* (and that also isn't behind a pay/registration wall). As close to perfect as the documentation is, do read the blog posts e.g. the 2 node HA setup as well - some minute details were only found in those. No showstoppers, and not many things in general, just a few hints here and there. The installation itself is easy as pie, the config file is properly documented (you can do most things via GUI, just some things are set in the main config file). Do help yourself to the iSCSI Powershell commands (Windows defaults from MS) when implementing, way more attractive than clicking via GUI! (New-IscsiTargetPortal, Connect-IscsiTarget etc.) Some things must be done via GUI though since iSCSI has been implemented way back and "making scripting available" wasn't that widespread for developers back then. This being a Microsoft topic, not StarWind though...they would have had to make their very own iSCSI implementation otherwise. For testing, you should use a proper tool like https://docs.microsoft.com/en-us/azure-stack/hci/manage/diskspd-overview since "Windows copy from within the VM running on the test setup" can be flakey. Not as in "the results aren't valid real-world performance if you check with the Windows copy within a VM" but rather "non-scientific" since you can't extract much data from that process aside from size/time. Feature-wise we are only waiting for the release of a... let's call it "planned disaster"...feature that would allow us to patch a hypervisor node without having to take the full storage offline. Atm (20220609) this is still necessary since taking a node offline without properly activating maintenance mode on the vSAN would trigger a full sync of the vSAN nodes. This is fine and a good thing! since it ensures data integrity. But there is something in the making that would ensure integrity without a full sync after a node goes down...which, as stated above, one could "abuse" to patch (and boot = take down) the hypervisors during business hours. Other than that the thing is rock stable and chugging along without issues. Like I said we are an SMB so we "only" have around 50 VMs on our FO cluster, which is a medium load for SSDs. So if you plan to go more to the "max" side of performance use, do proper testing! Price-wise this is very attractive, the support is great (little that we needed due to the good docs) and I would expect you to reach very good performance just like we did. The next-best solution from my research back then - that you would actually want to use, so no S2D crap or anything - would have started at 7x or 8x the price. Started! So...since StarWind's solution has served us very well over the last two years already...you get who I would recommend.

Aside from possible feature/price changes on the vendor side, I wouldn't change my process.

Vendor documentation is proper, so that's all you need.

Yep, because you can't be on your on with such a critical solution.

Wasn't needed since the product works very well since implementation.

Physical to virtual environment migration, requiring a VSAN storage for data center we had an old BLC 460 gen 6 blades with physical storage attached, so basically if we had any issues with the hardware or operating system the downtime for production would be for hours, so we created a virtual data center with VMware vSphere and added 3 20TB storage on each host then created 3-node StarWind scenario being shared on all 3 hosts, and creating virtual machines on 3 hosts and now running on StarWind storage.

By letting the support team do it next time, as based on their knowledge we have the correct configurations.

yes,
due to how critcal our storage is, i would like to have the support from starwind in case of disaster,

for initial deployment, they reviewed our network to make sure compatibility and best performance.

We use the StarWind Virtual SAN in a HA stack. We then use readily available HPE servers (DL380DL - 26 disk) to be the hardware. This allows use to have reliable hardware with reliable software and no downtime. It also drives cost down to almost nothing compared to hardware based SAN devices. Year after year cost are also down with not needing to keep hardware warranties up, due to part being available easily. Overall we have saved many thousands of dollars by going this way. We see no difference in IOPS or any other performance metrics. We have also tested the high availability a few times (once on purpose and a few not) - it seems to work flawlessly.

would be the same - compared all of our current hardware to this.

Yes - I save enough money that I like to have support incase I need it. When I am running my entire environment on this, I want to ensure that I have everyone's attention if needed. So far I have not needed it, and we have been running for I think 6 years - but just incase.

I had some theoretical questions and they entertained me just as if they were a system down. Very impressed.