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. The Recovery Plans can then be used to test the DR setup and perform a planned Failover, or it can be initiated during a disaster recovery. SRM is a not a product that performs an automatic Failover, which means that there is no intelligence built into SRM that would detect a disaster/outage and Failover the VMs. The disaster recovery process should be manually initiated. Hence, it is not a high availability solution; it is purely a tool that orchestrates a Recovery Plan.
vCenter Site Recovery Manager is not a tool that works on its own. It needs to talk to other components in the vSphere environment. I will walk you through all the components involved in an environment protected using SRM.
The following are the components that will be involved in an SRM-protected environment:
|
Protected site |
Recovery site |
|---|---|
|
vCenter Server |
vCenter Server |
|
SRM instance |
SRM instance |
|
Array managers |
Array managers |
|
Storage Replication Adapter |
Storage Replication Adapter |
SRM requires both the protected and recovery sites to be managed by separate instances of the vCenter Server. It also requires an SRM instance at both the sites. SRM's functionalities are currently only available via the vSphere Client and not the vSphere Web Client. Hence, an SRM plugin needs to be installed on the same machine where the vSphere Client is installed. Refer to the following figure:
SRM as a solution cannot work on its own. This is because it is only an orchestration tool, and it 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 the 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 you add an array manager, you need to install an array-specific Storage Replication Adapter (SRA). This is because the array manager uses the SRA installed to collect replication information from the array. Refer to the following figure:
SRA is a storage vendor component that makes SRM aware of the replication configuration at the array. SRM leverages SRA's ability to gather information regarding the replicated volumes and direction of the replication from the array.
SRM also uses SRA for the following functions:
Test Failover
Recovery
Reprotection
This is illustrated in the following figure:
We will learn more about these functions in the next chapter. For now, it is important to understand that SRM requires 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 will look as is shown in the following figure:
SRM conceptually assumes that both the protected and recovery sites are geographically separated. However, such a separation is not mandatory. You could use SRM to protect a chassis of servers and have another chassis in the same datacenter as the recovery site. Now that we have a brief understanding of the SRM architecture, it is time to learn how to set up these components.