Skip to main content

Onboarding for Veeam Recovery Orchestrator - Step 6 DataLabs and Virtual Labs

V

Correlation between DataLabs and Virtual Labs

Virtual Lab

Virtual Lab builds a Linux virtual machine (proxy appliance) that acts like a router and gateway between your production and Isolated Networks. Isolated network and Re-IP settings are configured in the Virtual Labs wizard. Virtual Labs is a standalone, independent feature in Veeam Backup & Replication. Veeam Recovery Orchestrator leverages this functionality for DataLabs.

DataLabs

DataLabs requires a Virtual Lab to be built in your Veeam Backup & Replication console. When you assign a DataLab in Veeam Recovery Orchestrator, it makes a one-to-one association between the Virtual Lab and DataLabs. DataLabs is an overlay on top of a Virtual Lab that extends recovery verification into Veeam Recovery Orchestrator.

DataLabs is an important feature in Veeam Recovery Orchestrator as it allows you to test Recovery Plans manually or automatically on a calendar schedule.

 

Understand and build a Virtual Lab

Virtual Lab Overview

The Veeam Virtual Lab is a powerful way to verify recoverability, do tests for configuration changes of critical applications, and more.

Learn how a virtual lab is configured with Veeam by watching the video below.

Application Groups are also covered in this video, but be aware they are not required for DataLab testing in Veeam Recovery Orchestrator. Application Groups are specifically used for SureBackup which is a core feature of Veeam Backup & Replication.

 

The Virtual Lab is an isolated virtual environment in which Veeam Backup & Replication can bring up protected workloads for testing. In the Virtual Lab, Veeam Backup & Replication connects VMs with vNFS protocol from a mount server to a selected ESXi host.

The Veeam Backup & Replication server needs to be on the same subnet as the Virtual Lab. This is required for Ping and Script validation over the Masquerade network, this network is defined in the settings of the Virtual Lab. Static routes are utilized to route traffic from the Veeam Backup & Replication server to the Virtual Lab, this is covered in more detail below.

Placement

A Virtual Lab can be placed at a source or target site, we will need to consider the use case of the Virtual Lab to define placement.

  • Source: Isolated testing and validation of backup Jobs.
  • The backup repository and the mount server are local to this site.
  • Target: Isolated testing and validation of Backup Copy Jobs, CDP, and Replication Jobs.
  • A mount server should be local to this site to mount backups to VMware via vNFS.
  • A mount server is not used for replicated workloads; these are stored directly on Datastores.

During the initial proxy appliance configuration, you will select the ESXi host, Datastore, and Networking for the proxy appliance.

 

Note: It may be worth having multiple Virtual Labs depending on specific use cases.

  • Such as having a different Virtual Lab in each location you plan to test replicated or backed-up workloads at that specific location.
  • A Virtual Lab should be placed at the source or target location on the Virtual Infrastructure where you are trying to test orchestration plans.
  • Note: This could be a singular ESXi host or Multiple, we will cover this in more detail below.

Networking

The Virtual Lab appliance requires the following items and prerequisites:

  • A production IP address.
  • Connectivity and routing to Veeam Backup & Replication is required for DataLabs testing.
  • Consider Hostname, DNS A record entries, DNS Server IPs, and a Gateway IP.

 

Networking Modes

There are three different network modes to choose from:

  • Basic Single-Host (VSS): the isolated Virtual Switch and Port Group names and networks are auto-generated.
  • Advanced Single-Host (VSS): the isolated Virtual Switch and Port Group names and networks are manually generated.
  • Advanced Multi-Host (VDS): isolated Port Groups are created on the target VDS for each isolated network.

This decision requires a few considerations and some requirements:

  • If you want to utilize multiple hosts easily during an isolated test, VDS is required.
  • Otherwise, a single host with VSS will be used for the isolated test.
  • Utilizing Virtual Distributed switching for a multi-host bubble test requires Enterprise Plus licensing on VMware.
  • Veeam requires this licensing to create the Port Groups on the VDS for the destination ESXi hosts.

 

It's important to note that no matter what you choose, when the Virtual Lab is created, it communicates with vCenter and the associated ESXi host(s) to deploy the isolated network settings.

  • For Virtual Standard Switching (VSS) a Virtual Switch is created for the Virtual Lab. This will also create Port Groups for each associated Isolated Network you've specified. No physical VMNICS will be associated with this vSwitch. Note: This is true for both Basic and Advanced Single-Host modes.
  • For Virtual Distributed Switching (VDS/DVS) a VDS is selected, and Distributed Port Groups are created. Since a Production Virtual Distributed Switch has physical uplinks, you will want to make sure you properly assign VLANs to the isolated networks. This means you will have to create non-routable networks for those Isolated Networks and modify the proper physical switch ports to isolate traffic to just the ESXi hosts. Note: You can create a new VDS in vCenter to be utilized for this, but will require physical port connectivity, mapping, and configuration. This can be a good option if you have open 1GbE NIC ports on the ESXi hosts.

 

Isolated Networks and Network Settings

Network Mappings

When configuring the Networking in your Virtual Lab you will select the source or target production networks that those VMs would be brought up on. During this selection, you are going to create an Isolated Port Group for each network mapping association.

 

Replication Example: If I am replicating a VM from Production to DR the objective is to bring the replica online for testing. My Virtual Lab would be deployed on a DR ESXi host. I would select the DR (Production Network) for my production network mapping and create an Isolated Network that during testing the VM would be brought up in.

Backup Job Example: If you intend to use Orchestration to bring back workloads to your Production network, then it would be viable for the Virtual Lab to be on a Production ESXi host. You would select a Production (Production Network) for your production network mapping.

 

Note: The Virtual Lab must be able to see these production networks that are selected in this phase, as the virtual lab is responsible for identifying this production network. When the Virtual Lab brings the recovered Virtual Machine online it communicates with vCenter/ESXi and re-maps to the Isolated Network for that VM. You will see errors on your DataLab testing for Network remap if this is not configured properly.

 

Network Settings

There will be an Isolated vNIC created for each network mapping you have chosen to bring into your Virtual Lab. This vNIC is going to be assigned to the Virtual Lab VM in VMware. Each VM vNIC will have an IP Address, Subnet, and Masquerade IP.

The virtual lab appliance isolated vNIC IP address should be the same as the source or target network Gateway IP address.

  • This depends on which network type of testing you are conducting, if you are testing a Replica Recovery Plan with Re-map and Re-IP settings, you will select that Target Gateway.
  • If you are testing a Restore Plan back to the same site it's protected on, you will make the isolated Virtual Lab vNIC IP Address the source Gateway IP address.
  • When the VM is brought online in the Isolated Network, it is going to be looking for whatever Gateway IP is assigned to its network adapter. You want the virtual lab to mirror this address in the isolated network so that VMs in the lab network can route traffic between each other.

Note: This is why it is important to consider the networking configuration of the VM. In a production Site failure setup to recover to a Target location, you may change Networks and IP addresses through Recovery Locations or Replication Job settings. This will also happen when we bring the Virtual Machine online during a DataLab test. In a DataLab test, we mirror that same event but in an isolated bubble. During a source-to-target site failover, the VM may no longer have its production IP address and may no longer be looking for the source site Gateway IP.

 

Static IP Mapping

Sometimes you want to give external access to developers or application owners direct access to a Virtual Machine inside of the Virtual Lab. This feature allows you to create a 1:1 IP mapping between a production Access IP and an IP address of a VM in the isolated network. The access IP must be an open and assignable IP address. Users can then use the production IP address to gain remote access (RDP) to the VM inside of the isolated network.

 

Current Limitations and Considerations

  • As of Veeam V12.1 we now have integration for NSX-T SDN. VMware NSX-T networking support — VMware VMs connected to NSX-T segments will now be handled properly inside virtual labs. Both production and isolated networks of a virtual lab itself can now also be set to an existing NSX-T segment.
  • vNFS is utilized for mounting an NFS datastore to the ESXi host in the form of an Instant Recovery. This is specific to testing Backup and Backup Copy jobs w/ DataLabs. As the underlying function to mount backups from Veeam repositories to vSphere is vNFS.
  • Both above limitations are major considerations when looking at VMware Cloud solutions. Continue reading.

 

Build a DataLab

Key Considerations:

  • Ensure your Virtual Lab is placed in the Virtual Infrastructure you plan to test and recover those protected workloads.
  • When testing Backups from a repository at the production location, you will want the Virtual Lab associated with one of those ESXi hosts in that on-site cluster.
  • When testing Backup Copies from a repository at the Target location, you will want the Virtual Lab associated with one of those ESXi hosts in that onsite cluster.
  • When testing replicated Virtual Machines, the Virtual Lab should be placed on the Target ESXi host specified in the Replication Job settings.
  • Note: Remember that if you are doing Re-IP validation on any workload, your isolated vNIC IP addresses assigned to the Virtual Lab should be the Gateway of the destination network.
  • Note: Remember if you are validating a workload that doesn’t require RE-IP validation, your isolated vNIC IP addresses assigned to the Virtual Lab should be the Gateway of the source network. This is captured in the backup of the .VMX file.

 

Connecting DataLabs (This is done in the Administration View):

  1. Navigate to DataLab Configuration.
  2. Select a DataLab and click Edit.
  3. Complete the Edit DataLab Configuration wizard:
  4. At the Scope step, click Assign. Select the required scope in the Available Scopes window and click Apply.
  5. The Recovery Location step is specifically for Lab Groups, which are used to restore via vNFS additional servers into the Virtual Lab when testing a Recovery Plan.
  6. Note: For a recovery location to be displayed in the list of available recovery locations, its compute resources must contain the host where the DataLab is deployed.
  7. At the Summary step, review the configuration information and click Finish.

Lab Groups

In most cases, a machine may depend on other services and components, such as Active Directory or DNS. To verify such a machine, the DataLab will have to supply all services on which this machine is dependent. For this purpose, Orchestrator uses lab groups.

Lab Calendar

DR plans are only good if you test them regularly. Veeam Recovery Orchestrator provides an option to schedule the plans once created. With the Lab Calendar and an email subscription, you can have a validation test of the DR Plan. The test provides documentation proving the success of the test, or if there are issues, an early warning to resolve the problem. Schedules can be created to run tests of the plans regularly.

Suggested resources:

 

Next up! We’ve built our DataLabs, which is a core component behind orchestration plan testing. This includes validation of Orchestration Plan Steps, as well as on-demand testing. It’s also important to understand you can conduct these tests automatically with the Lab calendar. We will now understand, create, and test Orchestration Plans in the next section.

 

If you need more help getting started, you can post your question in the comments section below or contact us at any time and someone from the Customer Success team will be there to assist you. 

 

Continue to Step 7 Testing orchestration plans & configuring reports

Return to Course Overview

    0 comments

    Be the first to comment!

    Comment


    Terms & Conditions