Installing VMware Site Recovery Manager (SRM) 5.5 in the Lab
Sam McGeown
I’ve been playing about with a compact SRM install in my lab - since I have limited resources and only one site I wanted to create a run-through for anyone learning SRM to be able to do it in their own lab too. I am creating two sites on the same IP subnet (pretend it’s a stretched LAN across two sites) and will be protecting a single, tiny Linux web server using vSphere Replication. I’m aiming to cover SAN based replication in a later post.
Below is the list of hosts and VMs running for this exercise:
- ESXi-01 - my “Protected Site” - this is running DC-01, VC-01, SRM-01 and VRA-01 (to be installed later)
- ESXi-02 - my “Recovery Site” - this is running VC-02, SRM-02 and VRA-02 (to be installed later)
- DC-01 – this is my domain controller, I’m only going to use one DC for both “sites” as I don’t have the compute resource available to have a second running. This is also my Certificate Authority.
- VC-01 – this is my primary Virtual Center server, it’s a Windows 2012 R2 server. It is managing ESXi-01.
- VC-02 – this is my “recovery site” and it’s a Virtual Center Server Appliance (VCSA). It is managing ESXi-02
- SRM-01 - “protected site” SRM server, base install of Windows Server 2012 at this point
- SRM-02 - “recovery site” SRM server, base install of Windows Server 2012 at this point
- WEB-01 - this is a really, really, basic Ubuntu web server I’ve deployed from a template to use for testing.
Right - without further ado, let’s get stuck in!
SRM-01
Preparing for SRM installation
- Install MS SQL Express 2012 and the Management Studio – I’m not going to go through that here, but it’s just a default install of SQL Express.
- Create a new database – for simplicity I’m going to call mine “srm”
- Create a new database schema with the same name as the database - “srm”
- Create a new SQL user for SRM called…you guessed it “srm”
- Security > Logins > New Login
- General > select SQL authentication and enter “srm” as the login name – ensure the password does not expire and set the default database to “srm”
- Under Server Roles > tick “bulkadmin”, “public” and “serveradmin”
- Under User Mapping > tick “srm” and map the user “svc_vmware_srm” to the “srm” schema. Tick all of the “database role membership” except db_denydatareader and db_denydatawriter.
- Modify the Schema “srm” to be owned by “svc_vmware_srm”
- Create a 64-bit ODBC system connection for SRM, I called mine “SRM”, use the SQL Server Native Client, integrated authentication and make sure to change the default DB to “srm”.
Installing SRM
Run through the standard wizard, accept the patents
Accept the EULA and select a disk to install on
Install vSphere Replication (it’s best to do this at the start unless you are 100% never going to use it) and then provide details of the vCenter server you’re connecting to.
Acknowledge any certificate warnings you might get here! I’m using CA certificates with my vCenters, so I don’t get the warning.
STOP! If you’re using CA certificates for vCenter servers then you need to generate an SSL certificate for SRM – luckily I covered that in my post Generating and Installing CA Signed Certificates for VMware SRM 5.5. Use the process here to avoid having to fiddle around later reconfiguring SRM. Similarly, if you use the FQDN rather than the IP address in the “Local Host” field of the “VMware vCenter Site Recovery Manager Extension” configuration, you can skip the section in that post about replacing the IP in extensions.xml – this will fix it.
Accept the default to automatically generate certificates, and then configure the vCenter SRM Extension – name the site (I just used the vCenter server name, but you could call it “Protected Site” or give it a geographical location name – it’s up to you. Enter an administrator email for notifications, and an optional secondary notification email address. For “Local Host”, you can enter the FQDN or the IP address – this gets used in the SRM configuration. Finally, leave the ports to default unless you have a really, really, compelling reason to change them.
Select the type of database server you’re using (SQL Server for me) and the DSN created earlier. Enter the credentials for the database user – the credentials in this screenshot are not correct (I was playing with using AD authentication at the time), make sure you use the DB user we created earlier (srm) and the password for that user. Finally, run the installer and wait to see the completion page.
SRM-02
Repeat the whole process for SRM-01 on SRM-02 – I have modified the database name, user and schema to “srmrecovery” and of course it’s pointed at VC-02 not VC-01 – but aside from that it’s exactly the same process.
Install the SRM plugin
The SRM plugin installs in the C# client like any other plugin – click the install link and click through.
Configuring SRM
Now, to take stock of where we’re at, I have installed SQL and SRM on two Windows 2012 R2 servers (SRM-01 and SRM-02). Both vCenter Servers are happy and there’s an SRM plugin installed in my vSphere Client. I have now logged onto VC-01 (my protected site) using the vSphere Client, and have clicked on “Site Recovery” from the home page. I am now presented with the SRM interface:
Connecting the sites
The first step is to connect the two SRM instances, known as connecting the sites. You can launch the Configure Connection wizard in a number of ways, but I just click on the link.
Enter the “recovery site” Virtual Center address
Configure Mappings
The next step is to configure mappings, either click on the Resource Mappings tab, or the link on the getting started tab. Here is where we map the resources of the Protected site to the Recovery site – e.g. we can create a mapping between my resource pool “High” and the recovery site’s resource pool “High”. You can map clusters, hosts and resource pools to their respective recovery site resources. At this point I’m just going to map the “High” and “Low” resource pools in my lab.
Folder mappings are very similar to Resource Mappings, except they provide a logical way to organise Virtual Machines as they are protected by SRM. I have created a folder in the Protected site “SRM-Protected” and one in the Recovery site “SRM-Recovery”. I will then map them together in the Folder Mapping view.
Finally, there’s the Networks to map – mapping the Protected site networks to Recovery site networks so that the VMs that are recovered are on the correct network. My mapping is very simple, just the one “VM-Default” network mapped to “VM Network” at the Recovery site.
Configure Placeholder Datastores
Each VM protected by SRM has a placeholder set of VM files (minus the VMDKs) created in the Recovery site – the placeholder datastore is where SRM stores these files. It doesn’t need to be huge since it’s only configuration files, but it does need to be visible to all hosts in the cluster. Note this isn’t a replicated datastore – in fact it should not be! I am going to map the local disk on my Recovery site host.
Configure replication
The next step is to configure either array based, or vSphere Replication – or both. I’m going to cover array based replication in a future post, so I’m going to configure vSphere Replication here.
The vSphere Replication appliance needs to be deployed at both sites, it can be done easily through the vSphere Replication pane within the SRM console. Select vSphere Replication and then click “Deploy the VR appliance”. It will launch the (hopefully) very familiar Deploy OVF wizard which has the URL for the OVF pre-populated.
As you can see, it’s not a huge appliance with only 512MB RAM required and 1.3/12GB for thin/thick provisioned disks.
Name the appliance and select a location, host…
…and storage location and format.
Configure a password and network IP address and accept the default vCenter binding.
Finally review the setup and click finish. Then repeat the process for your recovery site!
The vSphere Replication Appliances (VRA) can then be connected by clicking on the “Configure VR Connection” link. All you need to do is confirm you want to connect the two and it’s complete.
Protecting Virtual Machines
Now that vSphere Replication is configured, we can protect some virtual machines. Here I have a Linux VM called Web-01 which is in the SRM-Protected folder in my Protected site.
Creating Protection Groups
To quote the SRM documentation, “A protection group is a collection of virtual machines and templates that you protect together by using SRM.” It’s that simple! Creating a group is really easy:
You can then see the details of the protected VMs in the group, e.g. the resource mappings
Create a recovery plan
The final step is to create a Recovery Plan for the Protection Group
You can choose whether a test of the plan will use an isolated “bubble” network, or whether it will use a specific VM network on the destination host/cluster. Finally, name the group and write a description.
You can now see the recovery plan, and if needs be trigger a test or an actual recovery:
Perform a recovery
Finally, there’s not much point in doing all this work and not actually triggering a recovery, so here goes!
With the Recovery Plan selected click on the “Recovery” button
OK – a big red warning sign - this is important! If you fail over the protected VM it will shut down the protected one and boot the recovery one! Using vSphere Replication, there isn’t an easy fail-back option, so make sure you understand the implications before doing it! Tick the “I understand…” checkbox if you are happy to continue. I’m going to pretend it’s a real Disaster Recovery and select that option rather than the Planned Migration. The main difference is that the Planned Migration will try and replicate all the changes first, and fail if it can’t – the Disaster Recovery will make a best effort at replication but will fail over if it can’t.
That’s it! You can watch the recovery plan as it plays out:
Once completed, the VM on VC-01 is shut down, and the placeholder VM on VC-02 is powered on:
This has turned into a very long post! Hopefully it will help someone to see an end-to-end installation, and will give you some idea of how it’s possible to test in the lab.