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.
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.
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:
- 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:
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.
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.