6.1 Assign vSphere replication resources

The service provider can offer the service to an existing customer already consuming backup resources, or on-board a new tenant only willing to consume replica resources. In this example, we are showing the first option, but please remember both are possible:

Assign replication resources to a tenant

6.1: Assign replication resources to a tenant

Once replication resources are assigned to a tenant, new steps in the Tenant wizard are enabled. First, service provider configure replica resources:

Add a hardware plan to a tenant

6.2: Add a hardware plan to a tenant

Here the service provider selects the hardware plan that has been previously created for a given tenant, and assigns the plan itself to this tenant.

NOTE: we assume during the entire guide that a service provider is going to use Veeam built-in network capabilities via Network Extension Appliances. If a service provider disables this option for a tenant in this step of the wizard, different technologies need to be put in place, but they are out of the scope of this guide.

Then, the service provider configures the network extension appliance that is going to be deployed at the service provider side: Configure networking for the Network Extension Appliance

6.3: Configure networking for the Network Extension Appliance

Here there are some information that the service provider has to correctly fill in:

  • name: every appliance should have a unique name in order to be easily identified and managed. We suggest to use a naming convention that should then be followed throughout the deployments. In our example, we used “NEA-nameofthetenant”;
  • External network: every NEA has one external network and one or more internal network. The internal networks are configured creating different port groups, each tagged with a unique VLAN ID as explained in this guide. The external network is instead the internet-facing network of the appliance, and via this interface the NEA allows virtual machines to reach internet, and to be reached from internet (if the tenant has configured his public IP publishing rules). This external interface has to be connected to a port group that can reach internet, and where the subnet in use can be applied. In our case, we are connecting this interface on the same port group used for the external interface of the cloud gateways. In this way, during a partial failover the two components can communicate with each other, as this is a requirement to make partial failover work;
  • IP address: after the port group has been selected, an IP address should be configured in accordance with the port group: here we are using a public IP address in the same subnet used by the cloud gateways. This IP address should not be in the pool configured during the creation of the Replication service, as the risk is that it could be assigned as an additional IP address to another NEA. Ideally, service providers should have two different pools, one loaded into the Cloud Connect configuration so that they can be assigned as public IP to tenants that need to publish their VMs over the internet, and another pool not loaded into Cloud Connect, but just used to configure the primary IP of each NEA.

As a recap, in our example our pool of public IPs has been divided like this:

scope IP
gtw1 185.62.37.98
gtw2 185.62.37.99
gtw3 185.62.37.100
portal 185.62.37.101
Tenant pool 185.62.37.102 to 107
NEA pool 185.62.37.108 to 110

After the network extension appliance has been configured, the service provider can assign one or more public IPs to the tenant:

Allocate public IP addresses

6.4: Allocate public IP addresses

When all settings are confirmed and applied, as you can see in figure 4.12 the first available IP address is automatically assigned to Tenant1, the Cloud Host is created, and the NEA for the tenant is deployed in the virtualized environment:

NEA deployed in the vSphere environment

6.5: NEA deployed in the vSphere environment

We can see in the information of the VM that there are two interfaces, as we configured this hardware plan to have 1 network with internet access. External interface is connected to portgroup “DPG-vcc_public” (the shared VLAN where all the public IPs are published) while internal interface is connected to portgroup tenant.Tenant1.vlan112.

This is a completely new port group that Cloud Connect created for this tenant, and the naming scheme is self-explaining: this is a portgroup created for tenants, specifically for Tenant1, and is using VLAN 112. If you check figure 4.11, VLAN 112 is the first ID of the pool assigned to network with internet access.

NOTE: the port group where the external interface is connected is considered, form security point of view, an external and untrusted area. Connections happening outside of the external interface are considered unprotected and unfiltered, unless a service provider is using additional security procedures to monitor and protect this network.

NEA deployment at the tenant side

Depending on the different scenario a tenant may fall under, there are different moments when the corresponding Network Extension Appliance will be deployed at the tenant side:

  • on a new customer consuming only replication resources, the NEA is deployed during the service provide setup wizard;
  • on an existing customer already consuming backup resources, the NEA deployment is requested by Veeam Backup & Replication during the first partial failover attempt, otherwise there would be no tenant-side NEA to initiate the VPN tunnel:

No estension appliance warning at tenant side

6.6: No extension appliance warning at tenant side

Reagardless the scenario, Veeam Backup & Replication brings the customer to the corresponding section of the service provider setup wizard, where the tenant can configure his local Network Extension Appliance:

Network extension step during service provider setup wizard

6.7: Network extension step during service provider setup wizard

The wizard tries to automatically choose the best network to connect the Network Extension Appliance too, but it’s extremely important that the tenant edits the configuration of the NEA so that it is going to be connected to the same network of the VM’s he wants to replicate towards the service provider:

Configure networking for the tenant NEA

6.8: Configure networking for the tenant NEA

Note: Tenant NEA has only ONE network interface. If the tenant has received from the service provider multiple networks, one NEA will be deployed for each network. At the service provide however only one NEA with multiple interfaces will be deployed.

The NEA is deployed in the tenant vSphere environment, ready to be powered on for any partial failover activity:

Tenant NEA as seen from local vSphere environment

6.9: Tenant NEA as seen from local vSphere environment