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.
Remote Copy Groups best practice
Re: Remote Copy Groups best practice
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.
We use sync mirroring and have groups with 60+ volumes.
I'd still apply some logic to them to give some flexibility.
Re: Remote Copy Groups best practice
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.
Re: Remote Copy Groups best practice
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.
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.
Re: Remote Copy Groups best practice
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?
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?
Re: Remote Copy Groups best practice
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.
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.
Re: Remote Copy Groups best practice
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.
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.
Re: Remote Copy Groups best practice
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.
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.
Re: Remote Copy Groups best practice
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
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
Re: Remote Copy Groups best practice
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!
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!