Synchronisation of new clustered storage

Software-based VM-centric and flash-friendly VM storage + free version

Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)

Post Reply
robnicholson
Posts: 359
Joined: Thu Apr 14, 2011 3:12 pm

Wed Jun 18, 2014 7:03 pm

I've just created my first 100GB clustered storage system in the lab (yeah!). A question - there's a lot of disk activity going on my little Startech disk enclosure. When you create a clustered volume, is it immediately in sync or is it going to transfer 100GB (of nothing) one way or the other?

Hmm, possibly answering my own question of "no" because if you had a thin-provisioned disk of a large size, it hasn't got any blocks to synchronise first. In the lab, I've not created thin-provisioned disks - just flat IMG ones.

Answers on a postcard please as the disk enclosure is still chundering away after I finish this post.

Cheers, Rob.
robnicholson
Posts: 359
Joined: Thu Apr 14, 2011 3:12 pm

Wed Jun 18, 2014 7:35 pm

Answered own question. Found the properties display for the two servers and the second one is currently synchronising with an ETA of 10 hours. Okay, so my Startech lab disks are slow SATA-2 RAID-5 ;-)

I assume that the master was the first server when I added the servers against the new cluster storage? Have to make sure you get *that* right if switching from non-clustered IMG file to clustered. Assuming that is possible?

Cheers, Rob.
Last edited by robnicholson on Thu Jun 19, 2014 7:50 am, edited 1 time in total.
User avatar
anton (staff)
Site Admin
Posts: 4021
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Wed Jun 18, 2014 7:52 pm

We **LOVE** self-supporting customers :)
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
robnicholson
Posts: 359
Joined: Thu Apr 14, 2011 3:12 pm

Thu Jun 19, 2014 7:53 am

So next question, if you create clustered storage from scratch, is there anyway to prevent this initial mirror from taking place? Akin to fast-initialisation of a RAID array. Is there any practical reason the mirror needs to occur as it's mirroring an empty volume? Would mean both sides of the mirror are immediately available for MPIO set-up whereas one has to wait at the moment to do both sides before the mirror completes.

Cheers, Rob.
User avatar
anton (staff)
Site Admin
Posts: 4021
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Thu Jun 19, 2014 10:19 pm

Empty volumes are not empty. Except data there's also a metadata (hash sums, changed block bitmaps and so on). All of these things need to be verified and synced. Just ASSUMING empty volumes are identical is dangerous.
robnicholson wrote:So next question, if you create clustered storage from scratch, is there anyway to prevent this initial mirror from taking place? Akin to fast-initialisation of a RAID array. Is there any practical reason the mirror needs to occur as it's mirroring an empty volume? Would mean both sides of the mirror are immediately available for MPIO set-up whereas one has to wait at the moment to do both sides before the mirror completes.

Cheers, Rob.
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
robnicholson
Posts: 359
Joined: Thu Apr 14, 2011 3:12 pm

Fri Jun 20, 2014 8:22 am

Empty volumes are not empty. Except data there's also a metadata (hash sums, changed block bitmaps and so on). All of these things need to be verified and synced. Just ASSUMING empty volumes are identical is dangerous.
Dangerous? In what way? It one was playing around at block level, then yes I could see that the mirrors contained differing data then there could be a problem but I'm struggling to think of one.

You don't worry about the content when you create a flat IMG in non-clustered world - when you create those, a (say) 1TB file is created instantly. You don't zero it out. In a situation like that, what does the OS get back if it reads a random block? I assume the random garbage that was on the disk before. Is that dangerous? Not really as if you read random blocks, you expect to get random data.

Okay with a mirror system that was left with the random data in there, you'd get different random data if you read the same block twice and the first time it from one node and the next time from the other node. But what OS reads random blocks? The first thing you do is format the disk so that the data is in a known state by writing the empty file structure.

Are you saying that fast-initialization of RAID arrays is dangerous? Because I'd estimate 99% of arrays are created that way and it's a very similar discussion. I'm not that familiar with RAID controllers to know whether fast initialisation allows the mirror to be used immediately but then mirrors the blocks in the background. Possible but never seen that on a RAID user interface.

So please consider fast synchronisation. Give me the choice. Sure, I know other stuff needs to be mirrored across but not the entire 32TB disk...

Cheers, Rob.
User avatar
Anatoly (staff)
Staff
Posts: 1675
Joined: Tue Mar 01, 2011 8:28 am
Contact:

Wed Jul 02, 2014 9:52 am

Safety of the data is the #1 priority for us. We need to take care of all the possible options and circumstances. If someone will take the way that you`ve described, then yes, "Do not Synchronize: option would work like a charm. But if someone will create the first mirror, write some data on it, and then add the second mirror (I saw pretty much situations like this), then the synchronization is obviously required. "The Needs of the Many Outweigh the Needs of the Few" ©
Best regards,
Anatoly Vilchinsky
Global Engineering and Support Manager
www.starwind.com
av@starwind.com
robnicholson
Posts: 359
Joined: Thu Apr 14, 2011 3:12 pm

Mon Jul 07, 2014 4:19 pm

Don't disagree if you add a mirror to an existing image then mirroring obviously has to take place. But equally a large majority of uses will be creating a new mirror volume from scratch whereby sync is just a waste of time IMO. You must curse it in the lab all the time whereby you are creating new test volumes all the time.

I'm sorry, but your counter argument doesn't stack up because if what you said was true, then "Fast RAID initialise" wouldn't exist.

Cheers, Rob.
User avatar
Anatoly (staff)
Staff
Posts: 1675
Joined: Tue Mar 01, 2011 8:28 am
Contact:

Mon Jul 07, 2014 4:48 pm

We had that ability previously (I~m pretty sure that you remember), but we had different sequence of creating an HA. Previously user created whole entire device, while now he first creating one mirror, and then another.

Anyway, I think we will add this ability back and put exclamation mark near that option.
Best regards,
Anatoly Vilchinsky
Global Engineering and Support Manager
www.starwind.com
av@starwind.com
robnicholson
Posts: 359
Joined: Thu Apr 14, 2011 3:12 pm

Tue Jul 22, 2014 4:05 pm

Hang on... I created a 1GB clustered disk. It took about 15 minutes to synchronise - my lab is pretty slow.

But then I thought - hmm, that 1GB is a bit tight, I'll extend it to 5GB.

I expected a 4 x 15 minute wait whilst it re-synchronised the extension but nope - it expanded and didn't got into synchronisation.

So the argument that the sides must be synchronised when created from scratch fails in a poof of logic :)

A workaround is

1. Create a really tiny clustered disk (say 1MB)
2. After synchronisation (say a minute or two), expand to 4TB

Instantly expands, no re-sync needed and voila, a 4TB clustered image in 5 minutes.

Cheers, Rob.
User avatar
Anatoly (staff)
Staff
Posts: 1675
Joined: Tue Mar 01, 2011 8:28 am
Contact:

Wed Jul 23, 2014 2:25 pm

That is a great workaround!
You`ve got +1 in Karma from me :D

Just want to give you the heads u: we will definitely add the ability to create the HA without synchronization later.
Best regards,
Anatoly Vilchinsky
Global Engineering and Support Manager
www.starwind.com
av@starwind.com
Post Reply