HPE Storage Users Group

A Storage Administrator Community




Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Remote Copy Groups best practice
PostPosted: Thu Jun 25, 2020 7:30 am 

Joined: Mon Mar 09, 2020 8:34 am
Posts: 67
I realise that with the RC groups its best to have them segmented by app/vague association etc etc, but for us thats a bit of a pain.

I was wondering what the opinion of the pro's on here would be, if we had a SINGLE RC group, tied to a prod volume set, that replicated say..~40 volumes over to the sister storage in another region, with an RPO of.... 12/24hrs.

Is this likely to screw things up long term? Will the Array snap 40 vv's at once and kill performance, or will it spread out the replication over the 24hr time period?

I've googled furiously, and cannot seem to find the answers to these questions.

If we cannot lump 40 vv's into a single RCP group for convenience, fair enough, but would be nice to know for sure.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Thu Jun 25, 2020 8:12 am 

Joined: Wed Nov 09, 2011 12:01 pm
Posts: 392
Snapshots would be all at once I believe, if you don't want to group down by application can just do by server/cluster.

We use sync mirroring and have groups with 60+ volumes.

I'd still apply some logic to them to give some flexibility.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Thu Jun 25, 2020 9:05 am 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 1570
Location: Europe
It will snap all volumes in the same RC group at the same time. RC group is like a consistency group and you need all volumes in the same group to be snapshot at the same time to be consistent.

_________________
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Thu Jun 25, 2020 9:21 am 

Joined: Mon Mar 09, 2020 8:34 am
Posts: 67
OK, then really if I am to do it right, I better break it down :)

Im all for doing it the right way, so thanks.

Cant break down by cluster really, as we have all the luns shared across single clusters in each site.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Fri Jul 17, 2020 6:28 pm 

Joined: Mon Mar 09, 2020 8:34 am
Posts: 67
I am still undecided about our Rcp strategy, well I was I think until tonight.

I started creating some test RCP groups and noticed that you cannot add a volume set to an RCP group, only individual luns.

On our current setup, we have ~40 luns on each array (maybe as simple as 20 or less on 3par), each lun is roughly approximate for the service it runs, for example, a LUN for SCCM, a LUN for Active Directory etc.

With this limitation of not being able to automatically have a VV-set auto add its volumes as and when to the RCP group, I can only currently think the tidiest way for us is to break 40 luns into three tiers of RCP group, Tier1-4hr sync, Tier2-8hr sync, Tier3-24hr sync.

Is there anything obviously stupid about the above approach?

Currently we have ALL luns enabled on our compellents for sync, but you cannot control the period, it just syncs them all as best it can, however at least it syncs the replay(snapshot) tree for each LUN, something which I cannot see the 3par doing easily?

:(


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Sat Jul 18, 2020 2:29 am 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 1570
Location: Europe
A remote copy group becomes a vvset. I don't think you can put a vvset into a vvset. It could be as simple as that.


And I'm just mentioning it. I don't think your RC design scales very well. You're doing async periodic which means that for each interval the 3PAR must snap all volumes in the RC group at the same time. That means it must queue all volumes in the group when it snaps the first volume and keep all queued until the last one is done. That isn't a problem as snapping 1 or 5 volume is done before you can blink, but if you need to snap 50 volumes some applications might notice. If you have an active DBA I can guarantee you that he will.

_________________
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Sat Jul 18, 2020 5:56 pm 

Joined: Mon Mar 09, 2020 8:34 am
Posts: 67
Thats why I thought breaking down into three might work..(asyncronous periodic of course)

For example, say 30 luns.

Tier1 4hr:
10 luns, maybe running ~15VMss

Tier2 8hr:
10 luns, maybe running 15 VMs

Tier3 24hr:
10 small luns, maybe running ~20VMs

Given the above, you would still do it more granular?

Let me give an better scenario:-

Current luns on provisional new infrastructure and ~VMs
1. Lun-esxi-scratch (12 esxi nodes writing logs)
2. Lun-esxi-ContentLibrary
3. Lun-prod-vmware (4 Vms)
4. Lun-prod-Hpe (3Vms)
5. Lun-prod-3par (3VMs)
6. Lun-prod-Azurebackup (1VM)
7. Lun-prod-Linux (15Vms)
8. Lun-prod-ActiveDirectory (6VMs)
9. Lun-prod-Wifi (4Vms)
10. Lun-prod-windows (20VMs)
11. Lun-prod-exchange (1VM)
12. Lun-prod-print (2VMs)
13. Lun-prod-radius (2VMs)
14. Lun-prod-sccm (5Vms)
15. Lun-prod-fileserver (2VMs)
16. Lun-prod-pki (2VMs)


Given the above,
This is not exactly how we have it, but as a serious 3par pro, how would you break down the RCP groups for AS LITTLE admin as possible? I kind of liked my idea for 4,8,24hr RPO, as say all the critical luns are 4hrs, as keeping the basic core system vms like vcenter, hpe appliances, AD etc, all sync'd up the same might help recovery with consistency perhaps?

My hunch tells me that you would see the above and maybe create an RCP group for each lun, but then assign the group a period like me above with 4/8/24 depending on importance.

Am I way out?

Thank you again btw, this forum has helped me so much.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Sun Jul 19, 2020 1:27 am 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 1570
Location: Europe
You just have to try and see how it works for you.

I've had one application, using one LUN that complained every time I triggered a snapshot (which is basically what async periodic does every sync).

And I've snapped 20 volumes at once where nothing seemed to care.

To be honest, when doing async periodic I would care to much about admin. To me the important thing is why do you have it? Why are you replicating? Remember that if you're going to failover to the other 3PAR, you failover the entire group. With async you either have to plan , shutdown and sync, or lose all changes since last sync.

Just saying, it isn't uncommon to have one volume per RC group. The only time you think of it is when you create it.

_________________
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Mon Jul 20, 2020 4:28 pm 

Joined: Tue Mar 29, 2016 9:32 pm
Posts: 136
Personally I would do the job properly :-)

Implement replication between the arrays, implement vvols on your ESX hosts (it will pick up replication capabilities), then create some polices that dictate how storage is to be done for VMs using the policy (ie. thin, CPG to use .. and replication!) .. then basically just assign your VMs to the policies, VMware + VASA magic will do the rest.

Read this document a few times, then follow it to get a working setup :

https://h20195.www2.hpe.com/V2/GetPDF.a ... 302ENW.pdf

Then when all done, congratulate yourself on doing it properly and become a lazy storage/VMware admin like me ;-)


Top
 Profile  
Reply with quote  
 Post subject: Re: Remote Copy Groups best practice
PostPosted: Tue Aug 18, 2020 5:39 pm 

Joined: Mon Mar 09, 2020 8:34 am
Posts: 67
I initially went down that route, and decided after much testing that VVols are simply not production ready as it stands.

We cannot have staff flapping about with powershell scripts during a serious outage, not to mention the absolute unreliability I had with VVols, with orphan files etc.

It was a real shock at how dreadful they were.

We are using VVols for dev VMs though, as the convenience factor of no messing with datastores/vmfs/sizing/anything is great, but prod has to be watertight for us, and VVols was just not it. Spent months going down that rabbit hole, and filled with regret!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next


Who is online

Users browsing this forum: Bing [Bot] and 70 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group | DVGFX2 by: Matt