Avoid full sync after servers location move

[alexpt]

Hi,

I need to shutdown our Hyper-V native cluster, to make a physical location move.

In my previous lab tests, a full sync always occur in this scenario. Is there any way to force a fast sync instead of a full sync?

Thanks

[anton (staff)]

There's an automatic calculation - would it be faster to run a blind full sync or a log-based fast sync. If quite a noticable amount of transactions were performed with a broken cluster - full sync is actually FASTER then fast sync. I'll ask engineers to look @ your perticular case however...

Hi,

I need to shutdown our Hyper-V native cluster, to make a physical location move.

In my previous lab tests, a full sync always occur in this scenario. Is there any way to force a fast sync instead of a full sync?

Thanks

[alexpt]

Hi,

Just to clarify:
- There will be no data differences at all between both nodes, since the cluster service and the VM's will be turned off before the servers shutdown.

- It would be very important for us to skip the full sync, since it will take many (unecessary) hours to complete, resulting in decreased performance and vulnerability due to the lack of high availability during that time.

Thanks & Regards

[Alex (staff)]

At the current time the most simple way to do this without synchonization is the following:
- delete HA devices, do not delete .img files;
- create HA devices again from existing .img files with "do not synchronize" option.

This solution has one side effect - serial number of the HA device will be changed.

[alexpt]

At the current time the most simple way to do this without synchonization is the following:
- delete HA devices, do not delete .img files;
- create HA devices again from existing .img files with "do not synchronize" option.

This solution has one side effect - serial number of the HA device will be changed.

What are the implications of serial number change? Will it cause a reconfiguration of the cluster services?

Thanks

[Alex (staff)]

What are the implications of serial number change? Will it cause a reconfiguration of the cluster services?

Yes, it's possible.
We have checked the way to restore the serial number:

1. Before deleting the HA device, copy starwind.cfg file. It contains serial numbers for HA devices.
Find string like <device name="HAImage1"..., it contains serialId value, for example
serialId="51e2c3b5-68e3-4a1e-ab6b-7ea2a8f28fed"
This value is reported to the system. These identifiers are equal for both nodes of one HA device.

2. Disconnect clients, delete HA devices, relocate servers and create devices again with "no synchronize" option.
You'll get synchronized HA devices with new serial numbers.
Make sure you are using the same target names for the devices.

3. Stop StarWind service on the first node, open starwind.cfg file with text editor and change serial numbers to values from old .cfg file.
Start StarWind service and wait for fast sync to be finished.

4. Stop StarWind service on the second node, open starwind.cfg file with text editor and change serial numbers to values from old .cfg file.
Start StarWind service and wait for fast sync to be finished.

5. Connect clients.

[DavidMcKnight]

For what it's worth, it would be a really nice option to be able to manually shut down an HA device until manually turned back on.

A couple times a year I want to bring down all my VMs, VMWare Hosts, and Starwind iSCSI datastores for patches and upgrades. It would be nice to be able click on the HA devices and tell Starwind to stop the HA. It would stop accepting data, disconnect any remote iSCSI target client connection, sync the data on all HA servers, and go offline, and stay offline. It can take 5 reboots to put in all the microsoft patches, scsi driver updates, starwind updates, etc. Once that's done and I'm ready, I could then tell Starwind to bring the HA datastores back online. It should then be a quick process of making sure that the HA haven't changed since being cleaning taken offline, and the HA device on linked Starwind servers make themselves available for connections again.

[Alex (staff)]

David,
Thank you for a suggestion! We are planning to implement an option like that.