VM disks residing in two different array's can be protected by SRM or not?
Scenario 1. Both array's are of one vendor (EMC-EMC)
Scenario 2. Both array's are from different vendor (Netapp-EMC)
This is possible with vSphere Replication, not with array-based replication. It's the same regardless of if they are the same or different vendors. See: Storage and Availability Technical Documents (SRM FAQ) and Site Recovery Manager 6.1 Documentation Center
(from SRM FAQ)
Can multiple storage replication adapters be used with Site Recovery Manager simultaneously?
Yes. Multiple replication adapters can be installed in Site Recovery Manager to enable it to communicate with multiple arrays simultaneously. Keep in mind that a VM with VMDKs stored on multiple arrays cannot be protected with SRM. All VM files must be located on the same array.
what is the technical reason of not supporting it?
Having the SRA communicating and interacting with multiple arrays adds a lot of/too much complexity. Just think about it from a consistency standpoint, how could you make sure that the two parts of a VM were replicated in a consistent manner with multiple arrays? You would need some kind of cross-array consistency group. If you need this capability why not use vSphere Replication?
There are some other limitations with vsphere replication due to this we cannot go for the vsphere replication.
Ok. Did my responses answer your questions?
Few questions from the statement given above:-
- Lets assume my both the arrays are consistently replicating the data then what could be the issue?
- Is SRM uses any mechanism to check the consistency even if single array is used?
- What if single array has multiple datastores and each one created from different lun and then VM is using the multiple datastores coming from the same array, then how replication consistency is checked in this case?
- Lets assume my both the arrays are consistently replicating the data then what could be the issue? - This isn't possible without a replication solution that supports this (recoverpoint may be such a solution, as it handles replication rather than the array). If you have 2 arrays that support cross array consistency groups and can be managed with a single SRA this would work, otherwise not. You're talking about 2 different arrays working together to replicate multiple LUNs and maintain write order consistency between them. I don't see how this would be possible without something sitting in front of both arrays providing this capability, and even then I'm not positive it's possible.
- Is SRM uses any mechanism to check the consistency even if single array is used? - SRM is not a replication solution. It relies on the array to tell it what LUNs/datastores are in consistency groups and then makes sure that all of the disks of a VM are located on the same consistency group.
- What if single array has multiple datastores and each one created from different lun and then VM is using the multiple datastores coming from the same array, then how replication consistency is checked in this case? - See above. Array consistency groups are defined when configuring replication between arrays. For details on how consistency groups are created and operated check with your array vendor.
could you please give us more information regarding the RecoverPoint solution with SRM to protect VMs has two VMDK on different array.
our scenario, we have Two array ( Unity , VMAX ) both of them ( LUNs ) are protect by RecoverPoint Solution.
do you think if we integrate RP cluster with SRM by SRA the Protected group & Recovery plan will working fine.
I don't have any additional information on this. I suggest contacting DellEMC about it. In my message I was just suggesting that it was possible that RecoverPoint supported this, I don't know that definitively. Generally, SRM doesn't support protecting a VM with disks on more than one array. Because of the way RP works it may be possible that it supports this and presents it to SRM such that it appears that all disks are on the same array. I don't know this, it is me hypothesizing.