StarWind Software

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.

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.

We **LOVE** self-supporting customers

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.

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.

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.

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" ©

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.

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.

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.

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

Just want to give you the heads u: we will definitely add the ability to create the HA without synchronization later.