6.2 vSphere replication jobs
Now that the service provider has set up the Cloud Host for the tenant, it’s time for the latter to start consuming his replication resources. In Veeam terms, a Cloud Host is the abstracted view of the multi-tenant environment offered by the service provider, and seen by the tenant as a remote Virtualized Host that can be used as a replication target.
In order to guarantee the most transparent user experience, Veeam Cloud Connect allows to replicate VM’s towards the service provider by using the well known replication jobs. Exactly like in a backup or backup copy job used to consume Veeam Cloud Connect Backup, also in this case jobs are configured in the same exact manner, and just the target is different.
Once the customer has been assigned Replication resources in his subscription, first thing he can do is to rescan the services offered by the service provider:
6.10: Rescan service provider
First, the tenant can notice that replication resources are now available by the fact that Manage default gateways… is enabled:
6.11: Manage default gateways is now enabled
By going into the Backup Infrastructure node, the tenant can see the Cloud Host listed under the available VMware resources, side by side with his local vSphere environment:
6.12: An overview of the Cloud Host
In the properties of the Cloud Host, the tenant can verify that the amount of resources are those requested upon subscribing the the Hardware Plan (10 Ghz of cpu, 12 GB of memory, 500 GB storage and 1 network with internet access in our example), and he can verify that the service provider is using VMware vSphere 6.0.
Everything is ready for the first replication job towards Cloud Connect.
The new replication job is configured first by setting a name for the job itself:
6.13: Create a new replication job
It’s important to select Separate virtual networks (enable network mapping). This option enables the Network settings of the replication job, that will be important to correctly map tenant networks to the networks created inside Cloud Connect. Re-IP, on the other side, is not needed (and not available) in Cloud Connect.
Next step, a tenant selects the virtual machines that he wants to replicate towards Veeam Cloud Connect:
6.14: Select one or more VMs to replicate
In our example, we are replicating a Windows 2012 VM (“test-2012”) and a Linux VM (“lamp”). Next, we select the destination:
6.15: Specify destination of the replication job
This is the only difference between a local replication and the one towards Veeam Cloud Connect. The tenant selects the Cloud Host as a target and then chooses the Cloud Host published by the service provider:
6.16: Select Clod Host
Then, it’s time for the network mapping:
6.17: Network mapping
Here, a tenant is going to see the source network of any replicated VM, and be able to map each network to a network created at the service provider. In this simple case, the tenant has only one network with internet access, so every VM is going to be mapped to the single network made available in the Hardware Plan by the Service Provider. In more complex environments, there will be multiple source and target networks to be coupled.
The rest of the job configuration follows the same steps of any replication job. We are only showing here the configuration of the WAN Acceleration:
6.18: Enable replication through WAN Accelerators
Once the job is saved and scheduled, VM’s are replicated to Veeam Cloud Connect, and the service provider can see them in the vSphere environment, under the resource pool created for the specified tenant:
6.19: Virtual machines in tenant’s resource pool
Virtual machines are named with also the tenant’s name as a prefix, so no confusion or name conflict can be generated inside the shared vSphere environment.
In the tenant environment, replicated virtual machines show up in Ready state in Veeam Backup & Replication, ready to be used for failover activities:
6.20: Virtual machine replicas in ready state