Remote Copy - Confirmation of a couple of things?

[Paul Hutchings]

OK so just to ensure I haven't misunderstood anything here, I need to:

Create new remote volumes on the remote P4000

Setup a new remote scheduled copy - what happens to the primary snapshot, does it need to exist forever?!

It seems fairly straightforward and probably will be when I have the new system and management group in front of me, for now I'm just a little unclear on how the primary snapshot for the remote volume works as I obviously don't want that snapshot to have to stay on my primary SAN forever.

EDIT - If I'm understanding correctly, I wouldn't need to bother trying to combine remote snapshots with regular scheduled snapshots on my production cluster, I'd just use remote scheduled snapshots on those volumes which would keep X primary snapshots on the production cluster automatically?

[oikjn]

sorry about that.  I think I rambled on there a bit.

Yes, the easy way to handle all the snapshots is simply click the setup to remote snapshot.  In there it will creat the volume on the remote group and you can define the frequency of the snapshots and how many are kept on each side.  I have mine set to snap every 6 hours and I retain 2 on the local volume and 8 on the remote.

I think what happens when you create a remove volume for snapshots is that it creats a logical "volume" where the snapshots can be seen on the remote site.  That locial volume is "thick", but takes up no spce.  Any snapshots put in the volume are provisioned thin.  - short story...  just use right click on your volumes you want to remote snapshot and use the "new schedule to remote snapshot a volume" option and everything will go fine and the space taken up on the remote site will be thin.

As for the question about how the volume can consume more space than the size of the volume, you have to remember that consumed space is raw space and not net space, so when using data protection such as network raid 10, every 1GB of data actually consumes 2GB of raw space so a THICK 100GB volume actually consumes 200GB of space.  My word of caution would be that while I would recomend using thinly provisioned drives for your volumes on your main cluster, you should initially assume that the volume will expand to the full size since I have found in practice that it WILL at some point and it will bite you in the ass if you can't quickly delete a snapshot or another volume in a pinch since all writes on all volumes will stop when the cluster runs out of room.  I had this happen to me and I had to delete a non-essential volume simply to get all my VMs back up and running.  I now adjusted the overcomitment to be a bit more conservative and I also keep a 20GB FULL volume provisioned just in case I ever run into that problem again so I can delete it quickly and get everything running again..

[Paul Hutchings]

Thanks, that does all make perfect sense and ties in with what I've just been reading in the remote snapshot manual.

I think what was confusing me a little was trying to work out how to use my current scheduled snapshots with remote scheduled snapshots - but I don't need to, the remote schedule should do it all.

The only bit that still has me a little concerned is the consumption.  Sure, a 100gb volume on RAID10 will consume 200gb, but how you explained it was that you only had 300gb in use, so NW RAID10 that's 600gb consumed - so how did you get up to 1600gb consumed on the remote cluster as the snapshots should cycle so even allowing for some overhead I don't get how you consumed that much space?

[oikjn]

I set my volume at 800GB THIN.  I only had 300GB of data on the volume.  In theory, with raid10, the sapce consumed should only be 600GB+whatever the snapshots are, but what I found was that it eventually expanded to 1600GB+snapshots (as if the entire drive was written to and using data). 

The drives in question were hyper-v drives used as CSV stores and I was moving around virtual machines.  I think was happened was simply that all the drive was actually written to at some point or another and since there is no real space reclemation on the thin volumes the drives just kept expanding. 

For example, don't use a hdd scrubber to wipe your free space on a thin volume becuase that thin volume will jump in size.

[Paul Hutchings]

Perfect thanks, that makes more sense on where the 'extra' came from.

One last thing if anyone does know as I can't see it covered anywhere - what's the simplest way to stage a remote copy and then move the remote system?

I ask as presumably it keeps track by using the IP address of the target system.