StoreVirtual Storage
1748136 Members
3409 Online
108758 Solutions
New Discussion

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 14
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" !
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?!