vCenter Site Recovery Manager (SRM) is an orchestration software that is used to automate disaster recovery testing and failover. It can be configured to leverage either vSphere replication or a supported array-based replication. With SRM, you can create protection groups and run recovery plans against them. These recovery plans can then be used to test the Disaster Recovery (DR) setup, perform a planned failover, or be initiated during a DR. SRM is a not a product that performs an automatic failover, which means there is no intelligence built into SRM that would detect a disaster/outage and cause failover of the virtual machines (VMs). The DR process should be manually initiated. Hence, it is not a high-availability solution either, but purely a tool that orchestrates a recovery plan.
vCenter SRM is not a tool that works on its own. It needs to communicate with other components in your vSphere environment. I will walk you through all the components involved in an environment protected by SRM.
The following are the components that will be involved in an SRM-protected environment:
SRM requires both the protected and the recovery sites to be managed by separate instances of vCenter Server. It also requires an SRM Instance at both the sites. SRM now uses PSC as an intermediary to fetch vCenter information.
The following are the possible multiple topologies:
As mentioned previously, SRM cannot work on its own. This is because it is only an orchestration tool and does not include a replication engine. However, it can leverage either a supported array-based replication or VMware's proprietary replication engine, vSphere Replication. We have separate chapters covering vSphere Replication.
Each SRM instance needs to be configured with an array manager for it to communicate with the storage array. The array manager will detect the storage array using the information you supply to connect to the array. Before adding add an array manager, you will need to install an array specific Storage Replication Adapter (SRA). This is because the array manager uses the installed SRA to collect the replication information from the array:
The SRA is a storage vendor provided component that makes SRM aware of the array's replication configuration at the array. SRM leverages the SRA's ability to gather information regarding the replicated volumes and direction of the replication from the array.
SRM also uses the SRA for the following functions:
Test Failover
Recovery
Reprotect
We will learn more about these functions in the next chapter. For now, it is important to understand that SRM requires an SRA to be installed for all of its functions leveraging array-based replication.
When all these components are put together, a site protected by SRM would look as depicted in the following figure:
SRM conceptually assumes that both the protected and the recovery sites are separate, regardless of their geographical location. But such a separation is not mandatory. You can use SRM to protect a chassis of servers and have another chassis in the same data center as the recovery site. Now that we have a brief understanding of the SRM architecture, it is time to learn how to setup these components.