In this next test of vSphere Data Protection (VDP) interoperability, I wanted to see if a restored vCenter Server appliance would still be able to work with pre-configured vCloud Suite products such as vCenter Operations (vCops), vCloud Automation Center (vCAC), vSphere Orchestrator VCO and Network Virtualization (NSX). All of these products were running to some extent in my environment; vCAC had a simple blueprint for VM deployment, VCO had a simple workflow for renaming a VM and NSX included an Edge device providing a DHCP service. If all of this functionality was still in place post restore, then the backup and restore will have worked. Testing was done with vCenter Server appliance version 5.5U1 and VDP version 188.8.131.52.
In this third article in the series of backing up the vCloud Suite, we turn our attentions to NSX, VMware’s Network Virtualization product. Before starting, I should point out that NSX has a recommended way of backing up and restoring configuration information via the use of an FTP server, which you need to configure in your infrastructure to hold this exported metadata. However this exercise looks at how you might be able to use VDP to back up and restore an NSX configuration using image level backups. Once again, I wanted to see whether I could restore the NSX environment to a particular point in time, in-place and also by restoring to a new location. This is the same infrastructure that I used for backing up and restoring vCops and backing up and restoring vCAC and VCO. On this occasion, I was using NSX version 6.0.4, vCenter 5.5U1 and VDP version 184.108.40.206.
This 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.
I just recently received my credentials to VMware’s vCloud Hybrid Services. One of the first things I was interested in testing out was the Disaster Recovery Service, which uses VMware’s vSphere Replication technology to protect VMs in your on-premise DC to vCHS. The following post provides the steps to configure the replication target as your vCHS VDC (virtual data center), and then configuring replication on a VM.
Although I didn’t attend EMC World this year, there were a lot of interesting announcements. I managed to catch up with Matt Cowger (who sorts of sits between both the EMC & VMware camps) and ran through some of the main highlights from this year’s conference. There has been a lot written about EMC World already (and I mean a lot) so I’m going to try to keep the highlights to a minimum, and provide links to where you can read more.
Another feature which was introduced in vSphere 5.1 & vCloud Director 5.1 was the interoperability between vCloud Director & Storage DRS. Now vCloud Director can use datastore clusters for the placements of vCloud vApps, and allow Storage DRS do what it does best – choose the best datastore in the datastore cluster for the initial placement of the vApp, and then load balance the capacity and performance of the datastores through the use of Storage vMotion.
In my 10 part series of posts on the new vSphere 5.1 Storage Features, I called out in part 3 that there was now even greater interoperability between features like Profile Driven Storage and vCloud Director. The purpose of this blog is to highlight this particular interoperability in even more detail.