This post is more than 5 years old
24 Posts
0
2377
June 27th, 2014 12:00
Recoverpoint consistency groups and vmware 5.x
I'm looking for anyone who's using the EMC RecoverPoint appliances for the array based replication in a VMWare 5.x environment.
Recently we went through an update of our VNX5700 that we use with VSphere 5.1. As part of the upgrade, we purchased two of the RecoverPoint appliances to replicate the LUNS/datastores to our D/R facility (another 5700). Previously, we used the MirrorView product but went with the appliances to reduce the load on the VNX processors.
We have about 18 hosts at the primary site, all sharing a group of 19 datastores (each datastore is in its own LUN). this will be growing in the future, both the number of hosts and the number of LUNs.
When the reseller (not EMC) did the initial configuration, he said that since all the hosts see all 19 datastores, all the LUNS had to be in a single consistency group..
The problem we're seeing with this is that when we need to add a new LUN, when we add it to the consistency group, we basically lose the replicas at the remote site until the new lun is replicated.
In almost all cases a given VM is all on the same LUN; we typically don't split VM's over multiple datastores. I could understand keeping all the VMDK's of a VM in the same consistency group, but do we really need all LUNS that all the VMWare hosts see to be in the same consistency group?
Is there a problem if we create a number of smaller consistency groups, as long as we don't have VM's "span" across different groups?
We have VMWare SRM for our D/R site, but we're still in the process of setting it up and hadn't gone live with it, and haven't reconfigured it since we changed from MirrorView to RecoverPoint.
Any comments would be appreciated.
etaljic81
1K Posts
0
June 27th, 2014 13:00
"Do we really need all LUNS that all the VMWare hosts see to be in the same consistency group?" - No, you don't. You can spreads them across multiple CGs. As long as the VMs don't have to be consistent (i.e. failover at the exact point in time) you can do that. For example, a db and log LUN need to be in the same CG since those have to be failed over at the exact same time. If you don't have that requirement for VMs, spread them across multiple CGs.
"Is there a problem if we create a number of smaller consistency groups, as long as we don't have VM's "span" across different groups?" - Besides what I already stated above, no. Keep in mind that you will need Journal volumes for each CG so just make sure you have LUNs for the Journal volumes.
VMware SRM will work with multiple CGs, no worries on that.
Anonymous User
375 Posts
0
June 28th, 2014 04:00
From your statement, it seems that we didn't mind about load balancing at storage end. Have you overloaded one SP with all CG. What I believe is that once you share them between both SPs, you will not face any issue of latency. If one is almost idle as compared to the other SP, it will create problems.
msodonnell
24 Posts
0
June 30th, 2014 06:00
Thanks for all the replies. This matches pretty much what I found out, that all the LUN's don't need to be in the same consistency group, just keep any VM's with drives on different datastores together..
I don't want to slam the vendor too much, the Recoverpoint setup was only a small part of the total work; we were adding something like 100 drives to multiple arrays, reconfiguring storage pools, upgrading/expanding the SAN switches, etc. The scope of work for the RPA's was basically to replace the Mirrorview configuration with RecoverPoint. I figure he took the safest route and just made all the VM's the same consistency group.