Confused between StarWind clustering & Windows clustering

[robnicholson]

I'm confused again

The white paper on http://www.starwindsoftware.com/white-papers/ entitled "Creating a Windows Server 2012 R2 Failover Cluster using StarWind SAN V8 NEW" documents creating a Windows failover cluster. I'm aware of what how this works as we currently use a failover cluster in our W2012 Hyper-V farm.

However, that whitepaper doesn't actually document anywhere using the StarWind "Cluster" feature in v8. Am I missing something obvoius here? It talks about heartbeats and sync at the top but doesn't actually document them.

So I've tried watching this video:

http://www.starwindsoftware.com/only-tw ... tion-video

But I've fallen at the first hurdle as the screenshot in that video doesn't match the dialogue when it comes to setting up a cluster. See sshot-5.png. The video just has "Sync & Heartbeat" and "Heartbeat only" but the dialog really has "Sync & Heartbeat", "Heartbeat only" and "Sync". I can manage to get through in my lab set-up but I haven't a clue what I'm doing!

Can somebody please explain what this dialog is attempting to configure as it's VERY confusing. I know what sync and heartbeat are - the former is the network used to synchronise between the two SANs (mirroring) and the heartbeat is the network used to see if the otherside is alive.

So I assumed I could just check "Sync and heartbeat" on one network, i.e. put everything down one NIC (yes I know bad practise, but this is just a lab). However, if you just check "Sync and heartbeat" on 192.168.1.3, it says "Select Networks for Heartbeat Channels". Confused again because I've said "use the same network for both". So I check the "Heartbeat only" box on the same network but that unchecks "Sync and heartbeat" and I still can't move on. I check "Heartbeat only" & "Sync" on the same network but it still says "Select Network for Synchronisation channel".

Only way I can get through this box is to check one network for "Sync and heartbeat" and another for "Heatbeat only". That lets me through as in sshot-6.png. I can also check "Sync" on the 2nd network as well and that let's me through.

But I have zero idea what I'm configuring here... so an explanation of what one is actually choosing here is desparately needed.

Also why I can't just work on one NIC in the lab (I know the best practise side) because that whitepaper suggests that three NICs are optional. And if I do the configuration as shown in sshot-7.png (all three on separate networks), what exactly have I set-up?

Having something called "Sync and heartbeat" and then separate "Sync" and "Heartbeat" checkboxes is very confusing.

Cheers, Rob.

[robnicholson]

PS. Also, the video really needs updating to show the correct dialog that was in the release version.

[anton (staff)]

There's no relationship between Windows Cluster and StarWind Cluster. StarWind has absolutely own separated and independent implementation. Back to video - we'll update (there are still many changes in UI).

Back to other questions I'm leaving open to the support ppl.

[robnicholson]

Hi Anton,

After I'd got mirroring working in Starwind in the lab, this dawned upon me. The whitepaper caused more confusion than it helped as it didn't cover setting up the Starwind cluster side.

So as you say, they are separate but used together:

1. Starwind clustering to mirror the disk system and act gracefully when the host server is in trouble
2. If used on Hyper-V, failover clustering is used to automatically move the VMs to the other side in case of failure

So in a simple (but surprisingly effective) two Hyper-V host system with "serverless" SAN (i.e. Starwind runs on the hosts), then Starwind HA blended with Hyper-V failover clustering gives a pretty hardware resilient system for not a lot of money. Only caveat is that you must have enough RAM in the hosts to allow all VMs to temporarily run on one host.

I like it!

Cheers, Rob.

[anton (staff)]

1) These are not just "disks mirrored". Whole thing is MUCH more complex. For storage we also keep caches and lock tables coherent. For cluster we also run own heartbeat networks and use special algorithms to distinguish between failed node and failed network path. So Windows cluster needs witness to avoid brain split issue - we don't. VMware VSAN needs 3+ physical nodes, HP VSA and other VSAs need clustering service running on a third node - we don't.

2) For VM HA in case of an unplanned downtime VM would re-boot on the other physical node, to have zero downtime and no data loss guest VM cluster should be configured (easy with 2012 R2).

You're correct, 2-node configs should be under provisioned (40% or less) so one physical host stayed alive could handle the load (that's why we recommend at least 3 physical hosts and also 3-way replica for LUs and appropriate CSVs).

[robnicholson]

For storage we also keep caches and lock tables coherent.

I understand this now - see other post where light dawned and when you understand the architecture, it makes obvious sense. I was thinking about power-outages where blocks were still in the write-back cache. By keeping them coherent, this is not a problem as the other SAN will have a copy of the block in it's write-back cache and will get it to disk that route. Nice!

Cheers, Rob.

[anton (staff)]

Yes, exactly. That's why having UPSes (they serve as a HUGE RAID on-board batteries or capacitors) help.