- Date published:
- Author:Jorge Bujazan
- Category:Notes From the Field
As service providers, we have had the opportunity to start experimenting with Veeam 9.5 update 4 before it became generally available. Being a VMware multi-tenant Cloud operator that uses vCloud Director, we were very interested in what this “integration” would mean for our clients. Before we get into the new functionality, it may be pertinent to show how AIS has leveraged Veeam and enabled customers to “replicate” workloads to our San Diego and Phoenix clouds.
Prior to Veeam B&R 9.5 u4, AIS would create a Veeam Cloud Connect account per tenant interested in using us as a B&R repository, or as a replica target. This process could be completed through the Veeam Availability Console (VAC) or directly through the B&R fat client:
With this approach, our customers were able to replicate individual or groups of machines to our infrastructure. They were also able to leverage the Veeam Network Extension Appliance (NEA) to extend their L2 domain in a partial failover, or configure NAT rules and public IP addressing for a complete failover. The issue we had with this approach was due to the lack of control and visibility after the failover was initiated. Testing would go a long way; however, production failures come in multiple flavors. The lack of customer self-service ability to change the NEA’s behavior, or selectively start/stop re-configure VM HW after a failover was initiated, has prompted some challenges…
Enter Veeam 9.5 u4 and the new vCloud Integration functionality. This release has addressed the issue with self-service and post-failover customization. In essence, the functionality is very similar to how this worked in the past. The main difference is that VM resources are replicated directly into a customer’s vCloud virtual data center environment. This means that, at any point in time, our customers are able to spin-up, reconfigure, export, etc. their replicas through the vCloud director control panel. More importantly is the network aspect of a failover. The NEA is still an option, but customers are now able to introduce a vCloud NSX Edge appliance, or any other virtual security/routing appliance, into the mix providing a more customizable failover experience.
Service Provider Configuration
On the back-end, there are some fundamental differences when provisioning vCloud Director resources through Veeam Cloud Connect. Veeam has introduced a new Veeam Cloud Connect user type – traditional VCC users are now Standard Accounts, while we now have the option to create vCloud Director Accounts. As of this writing, the ability to create vCloud Director accounts is only possible through the Veeam B&R console (fat client). The Veeam Availability Console (in v2.0.2) continues to work with Standard Accounts, but is oblivious to the existence of this new type of user – we hope that this is addressed in VAC 3.0!
Veeam’s vCloud integration really shines when creating a vCloud Director user. We were initially afraid this would only allow us to expose resources from a single vCloud instance (à la Enterprise Manager), but to our surprise we were able to add multiple vCloud Director instances to the environment.
Another major benefit is that this functionality supports customers with multiple virtual data centers. We use this functionality to provide an Allocation based VDC where customers commit to a certain level of production resources, while they can have a Pay-as-you-go VDC for on demand resources within our DR cloud. WAN accelerator can be enabled/disabled per VDC (albeit we have not found a business case for doing this at the VDC level yet).
As you may have noticed, throughout setting up this vCloud Director Account, we have not had to specify the amount of resources available to the client. This is due to the fact that, with this modality, these limits are no longer imposed by Veeam, but pulled from the customer’s vCloud Director tenant VDC resource limits – this is awesome!
From a service provider side, this is all that needs to be done to configure the account. Very easy since a lot of the configuration items/limits are handled on the vCloud side.
From a customer perspective, configuration is very similar to what we would do in the past with one caveat. Note that this took us a couple of tries to figure out before official documentation for this functionality was made available. Before attempting this, customers need to be running Veeam B&R 9.5 update 4, as anything prior to this will produce an error when configuring the service. In order to add AIS as a replication partner, customers will still use the Add Service Provider functionality:
That caveat is how we would enter Veeam Cloud Connect credentials. In the past we would use the Standard Account credentials which were created in Veeam B&R or Veeam Availability Console. This time around, we’re using vCloud Director credentials when setting up the Service Provider Instance. The trick is that they need to be entered as follows: vCloudOrg\vClouduser. With previous versions of Veeam, this would be taken as a VCC tenant account and would throw an error:
With 9.5 update 4, the behavior is different:
This time the console will allow you to specify the user account in the vCloudOrg\vCloudUser fashion and proceed.
It will also display the available vCloud VDC(s) as replica resources (similar to what we saw on the SP side).
From a Veeam perspective, other than the format for the user account everything else appears to function similar to how it used to in the past. Here’s an example of how to create a new replication job to a vCloud Director enabled SP:
We’ve found the Separate virtual networks a good option for vCloud environments with multiple Org VDC Networks as it allows you to conveniently re-map origin to destination portgroups.
By default, Veeam will place all replicated VMs in a vAPP called Cloud Connect 1 – so you’ll need to create vApp containers prior to creating the replication jobs if you want to use something different.
Map those networks source -> destination
You’ll also have the opportunity to tell Veeam if it should add a suffix to the replica VMs, and how many restore points to keep (yes, you can choose to not add a suffix):
If you have Veeam Enterprise Plus licensing and a WAN accelerator deployed within your environment you have the opportunity to enable its use.
We’ve had this job running for some time now, so we’ve built up the 7 configured restore points:
Once the replica job finishes, the vApp and VMs are available through the vCloud Director interface:
Failovers can still be initiated through the Veeam B&R Console through the “Failover Now”, “Planned Failover” augmented by “Failover Plans”.
When performing a failover, you’re able to select which VMs, and a certain restore point (if available) for each one:
Veeam will then communicate to the SP infrastructure and initiate the operation as requested by the customer:
vCloud Director turns on the machines in the requested order, and from the requested restore point:
After the test or productive failover has concluded, the customer has the ability to Undo Failover, or to Failback to production
Again, outages come in different shapes and sizes. The big difference between the vCloud and the legacy approaches is that the customer is able to use the vCloud Director self-service portal to interact with these machines in a situation where the source Veeam B&R console is not available. vCloud Director machines are able to be powered on directly from the vCloud Director console:
There are a few features that we would like to be added on or addressed in a later release:
- As a Service Provider, we’re unable to control client resources for a vCloud Director Account as we used to with a Standard Account. When trying to get to the B&R console or Remote Desktop for this type of tenant we receive the following error:
- Veeam has made great progress in integrating the Veeam Cloud Connect (VCC) functionality into their Veeam Availability Console (VAC). At AIS, we had settled on using VAC to control most aspects of VCC, however, we are now going to have to “manage” vCloud integrated accounts through the fat client. I say “manage” as with this type of user, there is very little to do aside from creating/enabling the account – everything else is controlled through vCloud (resource limits, user/password creation, etc). Regardless, we would like to see the ability to create vCloud Integrated users on VAC in order to have a more integrated look and feel.
- Restore Points (in the form of snapshots) are not exposed through vCloud Director: At this point, customers can power-on replica VMs using their latest restore point, but are unable to self-service power-on a replica based on an older restore point.
- If an older restore point is required, customers can launch them through their Veeam B&R server, or if it is unavailable they can call our service desk and we can power-on the replicas using the requested restore point. These restore points are visible on the back-end vCenter tied to vCloud: