In this configuration, I deployed vCO in HA mode, meaning that there were two vCenter Orchestrator servers, one running and one in standby mode. The database for vCO was an external SQL Server database, running in its own VM. So there were three VMs to protect in this setup.
I am not going to repeat the detailed steps to set up vSphere Replication (VR) or Site Recovery Manager (SRM). Needless to say all the required steps such as pairing the sites, mapping resources, creating the protection group and recovery plan were all necessary. One point to note however is that the SQL server database can use VSS (Volume Shadow Service) for application quiescing during failover. I used that setting in this test. vCO servers do not have any quiescing abilities.
Like before, I used a ‘swing’ vCenter server so that this could also be failed over with the vCO configuration.
When it came to the recovery plan, the “configure recovery” step was necessary on a per VM basis to do the IP customization of the VMs. I also added dependencies on the VMs, so that standby vCO server has a dependency on the running vCO server being ready, and the running vCO server had a dependency on the SQL server database VM being ready. I also added a prompt step to the SQL Server DB start-up which gave me an opportunity to modify the IPAM entries of my VMs and update them with DNS with new IP addresses on the recovery site. This is what the recovery plan looked like:
However, I still could not login to either of the vCO servers via the client. This was because the Server Availability section had no nodes. At this point, I went to the Startup options and restarted the services. At this point both nodes appeared under Server Availability. The strange thing was that both servers showed as Running, whereas one should be Standby:
At this point I was able to successfully log into the vCO client, and add the vCO server back to my vCenter server.
To conclude, you can certainly do DR of your vCO environment using vSphere Replication and SRM, even with vCO configured in HA mode and using an external SQL server database. You will have to resolve the vCO configuration networking however post failover, and possibly flick the vCO configuration out of and back into cluster mode.
Note that I also did this test with the vCO servers referencing the SQL server database using IP address instead of FQDN. In that case, I had to change the vCO Configuration database settings on both servers and update the IP address to the new IP address on the recovery site. Once I did that, vCO once again appeared to work. However you can avoid this step by using FQDN like I mentioned earlier.