HA & fast synchronisation

[Aitor_Ibarra]

Hi,

I've noticed that the delta file used for fast synchronisation is kept in the same location as the .img file.

I think there may be a problem when the img file almost fills the disk, what happens when the delta file ends up filling the disk and there's no more room for it to grow?

I had an img which almost fills the disk. After a twenty minute planned downtime on one node, the fast resync went very slowly - in short bursts rather than a continous copy, and eventually gave up at around 69% and about 8 hours. Doing a full synchronisation instead, the copy was much smoother (more or less at maximum drive speed, about 3 hours), and completed without error. I the issue with the fast synchronisation may have been due to the drive being full.

It would be good if

a) before doing a synch, Starwind could warn you if space ran out for the delta file and therefore fast synchronisation won't be possible,

and

b) Starwind allowed the user to specify the location of the sync file, so that it could be on a different drive. This should speed up writes when an ha node is down (because the write to the .img and the write to the delta can be done in parallel) and also make it more practical to fill a drive with an img.

cheers,

Aitor

[Aitor_Ibarra]

I'm not sure what was causing my problems with fast sync, but further tests have shown my assumption about the sync file was very wrong; it doesn't grow. It seems it's more a map of the img file, perhaps recording the time each block was last changed or a seq number for each change; in any case, it does not grow even if lots of data is written while a node is down. It always seems to be about 0.005% of the size of the .img file.

It would still be useful for it to be located on a different disk though, to reduce the IOPs penalty...

It may be that the problem I had with fast sync not working well when the disk is full is to do with NTFS not having enough free space on the drive, after the .img and .dat. Until I see some good guidance on the matter, I'm going to go with leaving 10% of the drive capacity unused, just to be on the safe side.

[Robert (staff)]

Hello Aitor,

According to our development:

Fast synchrinization log file creating when creating device and have fixed size.

Fast sync log file size in BYTES ~= ImageFileSizeInMBs*48

Regards,

[Aitor_Ibarra]

Hi Robert,

Thanks for the clarification on the size of the sync file - that will make it easier to provision space for imgs, although I still don't know whether it's a good idea to completely fill a disk with img + dat.

The issue is currently with support, as whatever the cause, I've had a few occasions now where resync has failed, sometimes with loss of data on both nodes. At this stage it's not clear if the problem is drive space, a bug in Starwind (the Starwind service sometimes fails), or an OS issue (this is on Windows 2008 R2, fully up to date).

Thanks,

Aitor

[Robert (staff)]

Aitor,

We are currently investigating you issue, and will update via email, as soon as I have finding of our R&D dept.

Thank you,