vCloud Automation Center and vSphere Data Protection Interop

vCAC-VCO-ExtensibilityThis post is a follow on to a previous post I did on vCops and VDP interop. In this scenario, I am going to try to use vSphere Data Protection (VDP), which is VMware’s Backup/Restore product, to back up and restore a vCloud Automation Center (vCAC) v6.0.1. and vCenter Orchestration (VCO) v5.5 deployment.

In this particular scenario, there are nine virtual machines making up my vCAC and VCO deployment. VCO has been deployed in a HA configuration, which accounts for two VMs. The others make up the DEM, Manager, Web, vCAC, SSO and various databases for vCloud Automation Center.

Like before, I want to do two separate tests. One is a ‘restore to original location’ and the second is a ‘restore to a new location’. To make this somewhat valid, I wanted to have a blueprint (albeit a very simple one) working before backing up and restoring the environment. To do this, I had to add a valid vCAC license, create the vSphere endpoint, create a fabric group, create machine prefixes, create a business group, setup a virtual reservation, create entitlements, create a service, create and publish a blueprint (virtual machine template for deployment) and assign the blueprint to the service. I successfully tested the deployment of the blueprint a number of times before backing up the vCAC deployment. I followed the very intuitive instructions on how to create a blueprint with vCAC 6.0 located on vmwaremine.com.

To verify VCO functionality, I created a simple workflow which would rename a VM and tested it a number of times before backing up.

Let’s look at restoring to a new location first.

Restoring vCAC/VCO deployment to a new location

I created a single backup job in VDP which includes all 9 of the VMs making up the vCAC/VCO deployment. The backup was relatively straight forward; I simply build my backup job and select which VMs to include in the backup. The 9 VMs took about 10 minutes to back up the very first time.

1. vcac-backupNow I decided to do a restore, and in VDP this is a bit of a drag for two reasons.

First, for the restore process, there is no way to select all those VMs that were part of the backup job. So you have to go in and select each of the VMs manually and add them to the restore job. Yes, I realize that this is not something that you would do very often, but it is still a bit of a pain.

The second is after the VMs have been chosen for restore, and you want to restore them to a different location and not the original location, you once again have to uncheck the ‘Restore to original location’ check-box and select a new location for every single VM. Again, a bit of a pain.

6. manual editingBy the way, both of these pain points with VDP have been fed back to the product team. I’m hoping these will get addressed in a future release.

The restore job now proceeds and we simply wait for the restore job to complete. In this case, we wait for the restore of the nine VMs to complete:

12. restore completeIt was now time to power down my current vCAC infrastructure and bring the new restored vCAC infrastructure online. I powered down my vCAC infrastructure in the following order:

  • DEM VM
  • Manager VM
  • vCAC VM
  • SSO VM
  • VCO (active) VM
  • VCO (passive) VM
  • Web Server
  • pSQL VM
  • SQL Server VM

Disclaimer: I don’t know if this is the correct order or not, as I am not a vCAC/VCO expert. However this seemed like the most intuitive approach.

When all original vCAC/VCO VMs were powered off, I  commenced powering on the restored vCAC/VCO VMs in the reverse order. When my restored vCAC/VCO VMs were up and running, I did the following tests:

  • I successfully logged in with my credentials.
  • I could see my catalog items/blueprints.
  • Under Infrastructure, my credentials and my Endpoint is still good.
  • Under Administration, my Services are still defined.

I submitted a new request to deploy a blueprint. The request was submitted successfully:

18. Requets successfulThe final test was to see if the VM is deployed…. Waiting on request to changed from In Progress to successful:

19. in progressAnd I see my new VM successfully deployed in vCenter. I was also able to carry out actions such as power down the VM from vCAC. So it certainly seems that I can restore a vCAC infrastructure from a given point in time to a new location using VDP.

To verify VCO functionality post restore, I tried to login to my VCO server. It however responded that it was no longer the active VCO in the HA configuration and that I should login to the active VCO (the other VCO server). When I did,  my script was still available. I ran the script to rename a VM, and it completed successfully. To conclude, VCO  works fine after being backed up and restored by VDP. The test also proved that the VCO HA functionality continues to work post restore.

 Restoring vCAC/VCO to the original location

With this test, I made sure that I had a number of VMs deployed via vCAC blueprints. I wanted to ensure that they could still be managed after restoring to the original location.

The creation of the backup job is identical to before. The difference is in the restore process, whereby we leave the ‘Restore to original location’ check box checked.

8. Restore to original locationNote: You cannot do a restore to original location if the virtual machines are powered on. You must power off the VMs in order to do the restore.  Unfortunately, VDP does not tell you to power off the VMs, nor does it prompt you to power them off; the restore job will simply fail. Once again, I have asked the VDP team to look at improving this behaviour going forward.

However, once the restore is completed and the vCAC/VCO VMs are powered on, vCAC and VCO provide full functionality as before. I was able to deploy VMs using blueprints in vCAC post restore. However any chances made since the time of the backup will of course be lost, and if you have deployed VMs since the last backup, there will be a discrepancy in what is deployed and what vCAC is managing. you may have to do some tidy-up directly from vCenter, and re-provision from vCAC to match everything up once again, as you would expect.

Summary

In summary, I could successfully do the following with vCAC/VCO using VDP:

  • Backup vCAC/VCO VMs
  • Restore vCAC/VCO VMs to a different location
  • Restore vCAC/VCO VMs to original location

Disclaimer

This was a very simple setup, as described above. I am also making the assumption that backups are being taken whilst the system is more or less quiesced, i.e. no blueprint are being deployed, no VCO workflows are in the middle of running. This is when I assume most people would be taking their backups. I can’t comment on whether or not the backup would still be good if it was taken while these activities were in flight. Perhaps I can look at that in a future test.

Question for readers?

How do you backup your vCloud Suite components? What tools/backup products do you use? How do you verify consistency and prove that your backups are valid. I’d really like to hear from you, so please leave a comment if you can.

One comment

Comments are closed.