Site Recovery Manager SSL error

Recently had to regenerate the SSL certificates on my vCenter Server Appliance as I had noticed they were originally created with localhost.localdom as the DNS name.

Quite easy to regenerate the SSL certs, just log onto the admin page of the vCSA (http://ip-address:5480) and log in as root. Click on the Admin tab and by Certificate regeneration enabled select Yes.
When you next reboot the vCSA, the SSL certs will be regenerated – just be sure to change it back to No after it’s complete otherwise it will regenerate a new certificate every time you reboot!
srmerror3

A problem I discovered after regenerating the SSL certificate of my vCSA was that I could no longer connect to Site Recovery Manager using vSphere Client.
It would try to connect and then fail with a Connection Error.
srmerror1

As I knew this was working prior to regenerating the SSL certificate, I guessed that SRM was still trying to authenticate with the vCenter Server using the old SSL certificate.

Checking through the SRM logs (\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs\) confirmed that my assumption was correct:
srmerror2

The SRM logs show a certificate error:
Failed to connect: std::exception 'class Vmacore::Ssl::SSLVerifyException' "SSL Exception: Verification parameters:
.......
The remote host certificate has these problems:
.......

Quickest way I could think of in order to solve my issue was to modify the installation of SRM to update the certificates.
Log into the SRM server, open up Programs and Features from the Windows Control Panel. Select the entry for VMware vCenter Site Recovery Manager and click Change.
At the SRM wizard, select Modify.
srmerror4

You won’t be able to change the vCenter Server details but you will be able to change the authentication method. Regenerate the certificate by selecting Automatically generate certificate.
Ensure you select Use existing database, otherwise you will lose all your protection groups and recovery plans.

Once the SRM installer was finished, I was able to reconnect to SRM using vSphere client.

vCenter Site Recovery Manager – Shared Recovery Site

So a lot of customers use Site Recovery Manager as the tool to automate their Disaster Recovery Policy, usually it’s deployed on an one-to-one relationship – i.e. a single protected site and a single recovery site where the SRM/vCenter server on the protected site is paired to a SRM/vCenter server on the recovery site.

Not many people are aware that since SRM 4.0 you could actually set up a Shared Recovery Site which allows you to ‘fan-in’ your recovery from several protected sites (ie N-to-1 relationship).
This could be very useful if an organization has several remote/branch offices and requires them to be protected by a single shared site. Another example is where a service provider offers business continuity services to multiple customers – DR-as-a-Service.

In a shared recovery site configuration, you install one SRM Server instance on each protected site. On the recovery site, you install multiple SRM Server instances to pair with each SRM Server instance on the protected sites (so if you had two protected sites, in the recovery site you need to deploy two SRM servers).
All of the SRM Server instances on the shared recovery site connect to the same vCenter Server instance.

Similar to how standard SRM is deployed, you can use either array-based replication or vSphere replication.

Image
In the diagram above, you can see that there are two field offices protected by the their Head office.

SRM Server A (Field Office 1) is paired to SRM Server C (HO)
SRM Server B (Field Office 2) is paired to SRM Server D (HO)

So what are the limitations of a Shared Recovery Site?

  • You can’t reconfigure an existing standard SRM deployment to use a shared recovery site, this is because a custom installer is used when deploying SRM which allows you to set the SRM Identifier (which must be identical for the SRM pair).
  • Each instance of the SRM Server at the shared recovery site must be deployed on its own host machine, ie you can’t deploy multiple SRM servers on the same VM.
  • Each instance of the SRM server requires its own database.
  • You’re limited to a maximum of 10 protected sites per shared recovery site.
  • When accessing SRM through vCenter Server on the shared recovery site, you can view all the SRM extensions (and pairs) and hence see all the VMs, protection groups, recovery plans, etc.

One thing you need to be very careful with is how your solution is licensed if you’re thinking about using the Reprotect functionality of SRM (or bi-directional protection).
As with standard 1:1 SRM deployments, you can re-use your protected site SRM licenses at the recovery site (assuming they are no longer in use at the protected site) and invoke reprotect/failback.
However, if you use a new set of keys at the recovery site, then you need to ensure you have enough licenses to cover the VMs that need to be reprotected.

For example:
Site A – licensed to protect 20 VMs.
Site B – licensed to protect 10 VMs.
Shared Recovery Site – licensed to protect 25 VMs.

If you don’t transfer the licenses from the protected site to the shared recovery site, then you can only perform reprotect on 25 VMs. If you recover all of the VMs from sites A and B to the shared recovery site and attempt to perform reprotect, you have sufficient licenses to reprotect only 25 of the 30 VMs that you recovered!

The Operational Limits for SRM in a shared recovery site can be found here:
http://kb.vmware.com/kb/2008061

At some point before Christmas I’m hoping to get this all up and running in MTI’s demo centre…… =)