Hey there! With new versions coming up, it’s always a good practice to test the new features and get some hands on with them. I wanted to get some more insight into the VMware SRM and so i thought it would be a good thing to also blog my experience with lab. I am going to build a home lab for this and probably i may dedicate a separate blog post for the lab alone. So let’s get started with the SRM series.
VMware Site Recovery Manager is a disaster recovery solution provided by VMware, helps in plan , test and recover virtual machines between a Protected Site and Recovery Site. Replication across sites is managed by either third-party disk replication mechanisms or host based replication using vSphere Replication. SRM can be used to implement either Planned Migration or Disaster Recovery. In Planned Migration, both sites must be running and fully functional. SRM automates the recovery process and minimizes the data loss; VMs at the protected site are shut down and power on the machines at the recovery site.
A Recovery Plan specifies the order in which the virtual machines are powered on at the recovery site. It allows us to configure IP and other settings like start-up scripts that need to be executed that are to be used during the recovery. There can be any number of Recovery Plans depending on the VMs. SRM can be used to test the recovery plans and can be done without any interruption to the ongoing operations at both the sites.
SRM requires its own database to store the inventory information and data about the recovery plans. SRM provides an embedded vPostgreSQL database and also supports external databases like Microsoft SQL, Oracle. SRM cannot use the same database as vCenter Server’s as the schema is different, however, same server can be used for both and separate instance of Databases has to be ensured. Databases on the protected and recovery sites need not be identical and SRM can handle the things very well.
PSC handles the authentication between SRM and vCenter Server at the SSO level and all the communication takes place over transport layer security (TLS) and beginning from version 6 SRM only support TLS and SSL is not supported.
SRM can be installed with any deployment models that vCenter Server supports. Different vCenter deploy methods are discussed here by Jonathan McDonald. The vCenter Server Deployment model must be taken into consideration while installing SRM and all the components associated with the vCenter has to be up and running during the disaster recovery. Using a single instance of PSC for both protected and recovery site leads to single point of failure and neither protected site nor recovery site can be recovered if PSC goes offline.
SRM Deployment Models
One VC per PSC at each Site – The most common deployment model implemented and in this case PSC can be external or embedded with VC and PSC can be either federated or unfederated.
Multiple VCs per PSC at each Site – SRM can also deployed with PSCs having multiple vCenter Servers associated with them. PSCs here are external to vCenter Servers in this configuration.
Single Site Topology with common PSC – In this configuration, both the vCenter Servers connect to the same PSC, as discussed already this is not a very recommended implementation as this is a single point of failure for the PSC.
Yeah, i know that’s a lot of reading but hope this was informative. Thanks!