StarWind Software

Hi,

I'm continuing to setup a trial of HA for hosting VMWare ESXi datastores, and have a question about how the replication works. (Simple) answers to any of the following may help to clear this up for me:

• Does HA always run in active-passive mode? If not how do you control this?
• If active-passive, for my ESXi datastores would it be recommended to distribute the primary target between my HA nodes?
• How do disk writes get replicated when both nodes are synchronised (ie both are available)? Is replication always a synchronisation of the .img virtual disk (ie what has already been written), or does Starwind write data separately to each node from the inbound connection? I'm looking at this from a write-error point of view (ie should I be concerned about errors to one .img disk being replicated to the secondary?)
• My currently live environment uses two unclustered Openfiler hosts, and I'm trying to identify how to migrate to clustered Starwind hosts using the same server hardware. This can be done by moving all current datastores to one current SAN, and building the (now) spare server as Starwind. However, as Starwind HA disks are not compatible with non-HA disks, is it an option to create an HA pair on this single server, and then when the second server is available, move the partner .img over to the second node. Or are there any recommendations on how best to move from a non-HA environment?

Many thanks.

1) StarWind HA just *NEVER* runs in active-passive mode! We're not OpenXxx targets and don't allow half of the hardware just sit and wait while other node is overloaded processing requests. We're full-blown active-active solution so both storage nodes split I/O and virtually any load between them.

2) It seems to me you do confuse "storage HA" and "hypervisor HA" here. You can have StarWind HA configured as active-active Round Robin and hypervisor HA configured as simple fail over. These things are not linked to each other in any case.

3) I would not talk much about the way StarWind works as there's quite a lot of know-how there... From your point of view you should be interested in one question only. "Do I have ACK status for my write when BOTH nodes have data written?". In this case the answer is "YES, ABSOLUTELY". You cannot run into a situation when confirmed write was delivered to one node only.

4) In your case I'd expect you to provide a very basic interconnection diagram to our support, also clarify how much spare disk space you have and what downtime you can allow, how much data you want to migrate etc and then we'll be able to provide you with a best working scenario.

mstarr wrote:Hi,

I'm continuing to setup a trial of HA for hosting VMWare ESXi datastores, and have a question about how the replication works. (Simple) answers to any of the following may help to clear this up for me:

• Does HA always run in active-passive mode? If not how do you control this?
• If active-passive, for my ESXi datastores would it be recommended to distribute the primary target between my HA nodes?
• How do disk writes get replicated when both nodes are synchronised (ie both are available)? Is replication always a synchronisation of the .img virtual disk (ie what has already been written), or does Starwind write data separately to each node from the inbound connection? I'm looking at this from a write-error point of view (ie should I be concerned about errors to one .img disk being replicated to the secondary?)
• My currently live environment uses two unclustered Openfiler hosts, and I'm trying to identify how to migrate to clustered Starwind hosts using the same server hardware. This can be done by moving all current datastores to one current SAN, and building the (now) spare server as Starwind. However, as Starwind HA disks are not compatible with non-HA disks, is it an option to create an HA pair on this single server, and then when the second server is available, move the partner .img over to the second node. Or are there any recommendations on how best to move from a non-HA environment?

Many thanks.