Mapping is important for the SRM to work correctly as it specifies how VM resources at Protected Site are to be mapped to the resources at the Recovery Site. During the recovery, SRM uses the resources specified in the mapping at the recovery site to start the virtual machines. Bi-directional protection is also possible in the SRM and for this reverse mapping has to be configured.
SRM applies inventory mappings differently depending on whether you use protection groups from Array Based Replication or vSphere Replication or Storage Policy Based Replication.
Array Based and vSphere Replication Protection Groups
SRM applies inventory mappings to all the virtual machines in the protection group when a group is created.
SRM creates a placeholder virtual machine in Array Based and vSphere Replication protection group. SRM derives the resource assignments for the placeholder machines from the site-wide inventory mappings.
Though a site-wide inventory mapping is done, it is possible to reapply mappings to a protection group when needed; for example when a new VM is added to the existing protection group. Changes to the site-wide inventory mappings does not affect the existing protected machines and new mappings are applied only when the existing protected VMs are reconfigured. Site-wide inventory mappings can be over ride by folder and resource mappings for an individual VM.
Placeholder virtual machines do not support NICs and hence network configurations cannot be changed. We can only change the network of placeholder virtual machines in the inventory mappings. Changes made to the placeholder virtual machine override the settings configured during vm protection. SRM saves this config for the test and recovery.
Storage Policy Based Protection Groups
Unlike Array Based and vSphere Replication Protection groups, in Storage Policy Based Protection Groups, Inventory Mapping is dynamic and SRM applies inventory mapping when a recovery plan is run. Virtual Machine placement decisions are made based on the inventory mappings when a recovery plan runs and hence there is no concept of placeholder virtual machines on the recovery site. SRM uses site-wide inventory mappings for VMs using Storage Policy and Test Recovery, planned migration, disaster recovery of recovery plans that contain storage policy protection fail if inventory mappings are missing.
Note: Test recovery plans succeed with a warning when all the mappings are present except network mapping; SRM uses a auto-generated test network for this. The actual recovery and migration still fail as they do not use a test network mapping for actual recovery. Temporary placeholder mappings are created by SRM when the mappings are missing and protected site is offline.
PlaceHolder Virtual Machine
A placeholder virtual machine is a subset of virtual machine files. Site Recovery Manager uses that subset of files to register a virtual machine with vCenter Server on the recovery site. The files of the placeholder virtual machines are very small in size as they do not have any disks attached to them and they are not the full copy of the VM. The placeholder virtual machine reserves compute resources on the recovery site. When a recovery plan is tested or run, SRM replaces the placeholder with the recovered vm and powers it on. After the test finishes, SRM restores the placeholder VMs and powers off the recovered virtual machines.
The datastore designated on the recovery site for the SRM to use to store placeholder virtual machine files. PlaceHolder datastore must be configured on both sites for the bi-directional protection and to reprotect the VMs.
A protection group is a collection of virtual machines that Site Recovery Manager protects together. A recovery plan specifies how Site Recovery Manager recovers the virtual machines in the protection groups. Protection groups cannot be created with Virtual Machines protected by Array Based Replication and virtual machines protected by vSphere Replication or Storage Policy Based replication. However, it is possible to create a recovery plan with different protection groups protecting VMs either by Array based or vSphere replication or Storage policy based.
A consistency group is a collection of replicated datastores where every state of the target set of datastores existed at a specific time as the state of the source set of datastores. Informally, the datastores are replicated together such that when recovery happens using those datastores, software accessing the targets does not see the data in a state that the software is not prepared to deal with. Site Recovery Manager computes consistency groups when you configure an array pair or when you refresh the list of devices. You can also add virtual machines to the protection group by using Storage vMotion to move their files to one of the datastores in the datastore group. You can remove a virtual machine from an array-based replication protection group by moving the virtual machine’s files to another datastore.
If your storage array supports consistency groups, Site Recovery Manager is compatible with vSphere Storage DRS and vSphere Storage vMotion. You can use Storage DRS and Storage vMotion to move virtual machine files within a consistency group that Site Recovery Manager protects.
With some theoritical unuderstanding of the concepts, we can now better understand the implementations. In our next post, we will configure the mappings for network, resources, datastore and folders.
Hope this was informative. Thanks!