StoreVirtual Storage
cancel
Showing results for 
Search instead for 
Did you mean: 

Remote Copy - Confirmation of a couple of things?

SOLVED
Go to solution
Paul Hutchings
Super Advisor

Remote Copy - Confirmation of a couple of things?

With remote copy, is the remote copy definitely thinly provisioned please?

 

Presumably best practise is to have the remote copy P4000 in its own management group separate from the main production P4000 nodes so that if quorum is lost for that management group, your DR P4000 is still available?

 

Do you actually need a management group with just a single P4000 VSA?!

14 REPLIES
Bart_Heungens
Honored Contributor

Re: Remote Copy - Confirmation of a couple of things?

Hi,

 

Remote copy is based on snapshots and snapshots are always thin provisioned...

 

You can put it in another management group, it can be the same... As long that there is at least 1 node available with a manager running (and a FOM in case of a disaster), your management group and cluster stays online so that shouldn't be an issue...

 

You always need a management group and a cluster, otherwise you cannot create a volume...

 

 

Kr,

Bart

--------------------------------------------------------------------------------
If my post was useful, clik on my KUDOS! "White Star" !
My blog: http://blog.bitcon.be
bryan_hadzik
Frequent Advisor

Re: Remote Copy - Confirmation of a couple of things?

I would highly recomend having the DR unit in its own management group. You don't want the 2 sides dependant on each other. If the DR plan actually kicks in, you may have to access to your primary site nodes, and quorum will be offline. There are almost no drawbacks to 2 seperate management groups.

BulkRate
Occasional Advisor
Solution

Re: Remote Copy - Confirmation of a couple of things?

Running your DR VSAs in their own management group will allow you to upgrade them seperate from any other mananagement group's systems.  On the flip side, if you want your DR manmagement group to be fault-tolerant then you'll either need to run and odd number of  VSA nodes (greater than 2) or the familliar 2 nodes + FOM.  From what I understand, FOM's are specific to the management group they're in.

 

Like just about everything in P4000-land...go with what works best for your setup and meets your requirements.  In ours it's to control VM-sprawl and the need to upgrade all nodes in lockstep isn't considered that big a drawback.

 

For what it's worth, I've run our inital DR setup off one single node assigned to its own cluster within a managemnt group containing the cluster used by our hub site physical nodes,  Mixing VSAs/pnodes is a bad plan within a given cluster, but in seperate clusters it seems to work wel enough.  With only one VSA node it reports that it's not running a manger, but all volumes are up and seem happy. 

 

As for thick/thin provisioning...it's weird.  If your remote primary volume's thick, then so will the snapshot on the remote primary's VSA (at least if the management group's Use Summary screen's telling the truth).  Depending on how you create the remote snapshot on your DR cluster, that remote volume could end up thick (if created through the New Remote Snapshot/Schedule dialogs) or thinly provisioned if done namually and then used as the desitination volume of your Rempte Copy.  One quirk...you can change the provisioning method on the fly for your primary volume, but are appear to be stuck with whatever provisioning method youv'e choosen for the remote volume once the inital remote copy's made.

 

However, in all cases I've seen regardless of what you choose above, the snapshots attached to your remote volume at your DR cluster will be thiny provisioned...so I suspect the only thing up for grabs in all of this is how much storage space utilitzation you want at your remote, primary volume's setup.

Paul Hutchings
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

Thanks, that would make sense - I only did a remote copy once to a VSA and that was just in some really quick lab testing and I noticed it showed as thick, but as you point out I created the remote volume from the wizard.

 

My "plan" right now is a dedicated management group - as you say no point having to care about things like quorum if my main nodes (and FOM) are down.

 

Bit of a separate question but does anyone have any experience of routing with the P4000?

 

I have our main P4000 nodes/clusters sat off an L3 interface on a firewall.  The physical storage LAN doesn't extend to where I'd probably stick this DR box so I'm thinking why couldn't I just replicate using routed iSCSI through the firewall?

Paul Hutchings
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

Another quick follow-up if I may - what experiences have people had with differing amounts of bandwidth?

 

Basically we have our production P4000 clusters on a dedicated storage LAN on dedicated switches which connect to a router/firewall.

 

The intention is that the "remote copy" P4000 will go somewhere on our campus that has no connectivity to the storage LAN.

 

So to my mind the production P4000 can route to the DR P4000, the only question is how much of an issue bandwidth (100mbps) may be?

 

I don't know the exact snapshot change rates but I'm not envisaging much.

 

Thanks,

Paul

BulkRate
Occasional Advisor

Re: Remote Copy - Confirmation of a couple of things?

Not sure about your routing question.  For what its worth, I have P4000 VSAs scattered all over the place that replicate back to a pair running on a dedicated, routed L3 VLAN off of one of our core switches.  Over remote segments of our MPLS, behind ASA55x0 lan-to-lan VPN tunnels...you name it.

 

As long as you can reach the VSA's management IP from a CMC session, and all nodes in question can reach managers involved in the management groups you shold be golden.

 

Remote copy BW shouldn't be very tricky...you only need enough to meet your remote copy recurrence/retention schedule.  I.E be able to finish scanning and copying a snapshot before it's scheduled deletion.  I tend to run two snapshots deep on my consolidated backup, so that an interruption of service doesn't have the chance of leaving me with a half-replicated copy as my sole backup for a remote site.  Your initial two remote copy recurrences will be the problematic ones, depending on initial size and change rates.

 

What size volumes are you looking at RC'ing?  I only have 200-350GB volumes at each office, with 3mbps links handling a nightly snapshot (2-6GB each).  Initial sync took about 7-8 days, albeit with only 1/2 this bandwidth allocated to allow user's to get something done during the day.  It sounds like you've got significantly more to work with, but may have significantly more to get done.

Paul Hutchings
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

I think the question was just confirming that routing traffic is no big deal - couldn't see why it would be but you never know... so thanks for covering that one off.

 

The firewall interfaces are gig ethernet but the firewall is rated for 250mbps throughput - either way a fair bit.  Volumes are a mixture of LUNs allocated for VMFS and NTFS usage and range from 500gb or so to 1tb or so.

 

I could do the seed with the box on the storage network.  Not sure yet how I'd go about changing the IPs and telling the RC about the change of target IP though?

 

Tbh I think there will be a fair bit of playing involved once the kit lands, just trying to avoid any unpleasant surprises.

 

oikjn
Honored Contributor

Re: Remote Copy - Confirmation of a couple of things?

as for the remote bandwidth question (I think there was one in there).  I have a setup w/ two managementgroups doing "DR" remote replication across.  Its not really remote (just other sides of my building) so its all on 1G copper, but once you setup the two mgt. groups and setup a remote replication between the two, you can configure the remote bandwith to be whatever you like.  I typically keep mine at 100Mb, but it lets you pick any value you want.

 

As for the thin/thick provisioning deal.  I simply created my remote snapshots by right clicking on the volume in question and using the create new schedule to remote snapshot wizard.  I used that to create the new volume on the remote management group and when all was done, the remove mgt group volume says that it is FULL provisioned and REMOTE.  Then each snapshot in that volume shows up as THIN....   Actual usage is completely THIN so you can ignore that reporting of the provisioning.

 

Side comment:  I have found that after a couple months all of my thin volumes have completely expanded.  I provisioned 800GB volumes and each only have 300GB data with a typical change rate of ~4GB/day, but after a few months my consumed space on each drive was 1600GB (raid10)!  (This is all for hyper-v CSV stores)

Paul Hutchings
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

oikjn you've lost me there?  The remote volume is thin even thought it reports as full?  

 

And the disk consumption on the remote volume expands beyond the actual space consumed on the source + snapshots?!

Paul Hutchings
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

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
Honored Contributor

Re: Remote Copy - Confirmation of a couple of things?

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
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

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
Honored Contributor

Re: Remote Copy - Confirmation of a couple of things?

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
Super Advisor

Re: Remote Copy - Confirmation of a couple of things?

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.