As a consultant, I implement many different solutions, be they pilot, production, or proof-of-concept. In any organization of any size, it is important to test the implementation, functionality, and management of a new solution before the production environment is touched. To do this we use a test lab. Generally, there are three types of labs:

  1. Sandbox: A sandbox is typically isolated, with internet connectivity separate from the production network, and contain a series of VMs with any mix of forests/domains/services. They are often for educational purposes and do not contain any representation of the production environment. Several people have administrative privileges and changes are not tracked.
  2. Dev/Test: These environments are typically isolated, though may connect to production for data import/export functionality. They are a scaled version of the production infrastructure with select configurations to simulate production configuration and includes a few test users. The Dev/Test lab is utilized for creating/troubleshooting custom applications and architecture, and changes to the environment are monitored.
  3. Staging: Staging environments consist of an exact, or near replica of a production solution. Utilizing database availability and/or backup solutions, and often a significant amount of manual effort, they are used as a place to access production data off-line (ie: reporting), and to test application upgrades, OS patches, and major configuration changes. Depending on whether the staging lab is more for testing or pre-production work, isolation is on a case-by-case basis.

A staging environment is a wonderful thing, but until a couple of years ago I would only ever see them when working with large enterprises. To have a third production implementation of a solution (we also have DR) is a significant cost in hardware alone, even before we look at the effort of maintaining consistency between environments. Often, these companies I dealt with would have one or two people fully dedicated to keeping the lab data current!

So what changed? How is it now cost-effective and not so time-consuming to deploy (and maintain) a staging environment? It’s actually a bundled feature that comes with Veeam Backup & Replication. It goes like this: Your Domain Controller VM is backed up, so is your SQL and application servers. Using some compute from configured Hyper-V/VMWare hosts, the VMs are started from their location on the backup target and loaded into an isolated network. It then creates differencing disks to store all subsequent changes in the lab, so your backup data is only accessed, not written. When you’re done upgrading the application or moving to Server 2016, reset the Virtual Lab…the changes are discarded and the host resources are reclaimed by the host server(s). There are also scripts that can be used to use Virtual Labs to automate the backup validation process, also known as SureBackup.

If that’s all about as clear as mud, let’s go through the setup of a Virtual Lab. It only takes a few minutes.

For this example, I’m going to use my ADFS setup, which includes a SQL Server, WebApp Server, and Proxy Server. It requires Active Directory, so my virtual lab will also contain a Domain Controller to complete the group.

First thing’s first. We’re going to want to ensure that we have a fresh backup of each VM, and find out if they’re on the same subnet or not (by the simple method of pinging each server). Its subnet will affect how we create the lab later on.

Now that we’ve confirmed a recent backup, let’s go into the Backup and Replication workspace and click on the SureBackup node. In the main window, click Add Virtual Lab.

In the New Virtual Lab wizard, we’ll give our lab an appropriate name and click Next.

On the Destination page, we’ll select the Host server that we want to use to store the Virtual Lab configuration, which gets created as a Virtual Machine. The VM is very small, so I’m just going to stick it on the C: drive.

The proxy screen is very important for SureBackup, as it will allow Veeam Backup & Replication to access the Virtual Lab machines to validate backup consistency. Just for the Virtual Lab, or to do manual (ick) backup validation, it’s not required. For this guide we’ll uncheck the Use proxy appliance in this Virtual Lab (recommended) option.

On the Networking page, we only have two options…Basic or Advanced. For this example, we have front-end and back-end servers on different subnets, which will take a little extra configuration. We’re going to select Advanced, giving us more control over creation of the lab’s network layer and access to create multiple subnets.

This is going to open up a few more pages for us to configure, so let’s move right along to Isolated Networks. This will allow us to set the VLAN ID of the network, and map the production VMs vSwitch to the one we’ll use for its corresponding subnet in the Lab. Furthermore, since I’m just using my laptop as the compute node, the vSwitch is different from the production cluster. To configure this, we’re going to edit the default mapping, and browse for the correct vSwitch that is used in production.

If your production VMs reside on different vSwitch names, you will need to create a new network mapping for each unique vSwitch.

Once this has been completed, we’ll move on to the Network Settings page where we will create the subnet information for the lab. The most important part here is to NOT use an IP range that already exists in your network. The first step is to edit the default setting and add in the IP for our Domain Controller…which also serves as our DHCP and DNS server. If your VMs all have Static IPs, this step is not necessary.

After clicking ok a half dozen times we’ll end up back to the Network Settings page. Now if your lab has multiple subnets, and you want to be able to route traffic between these subnets, you need to check the Route network traffic between vNICs button before clicking Next, Next, Finish. As the proxy appliance VM is Linux based, the entire creation process should take less than a minute.

Now that we have the core of our Lab environment built, the next step is to select the Virtual Machines we will be adding. This is performed using what Veeam calls an Application Group. Back in the Backup Infrastructure workspace of the Veeam Backup and Replication Console, we’re going to click the SureBackup Node and select Add Application Group.

In the New Application Group wizard, we’ll give the group an appropriate name and click Next. On the Virtual Machines page, we’re going to click Add VM and Ctrl+Click the VMs we want to add to the lab and click Add.

Once the VMs are listed, you can click on each one and specify its role from a pre-defined and customizable list. This important for when we are using this environment to automatically validate backups. When finished, click Finish.

The last configuration portion is to merge the Virtual Lab with the Application Group, which is performed using a SureBackup Job. In the same window where we created the Application Group, we’re going to select Add SureBackup Job and give the job an appropriate name in the wizard that appears. After clicking Next, we’re given the option to select the Virtual Lab…we’re just going to click on by as we only have one.

On the Application Group page, we’re going to click the drop-down and select the Application Group created in the previous step. Notice that all the VMs are populated automagically. At the bottom of the window, ensure to click
Keep the application group running after the job completes to ensure that the VMs do not automatically shut down as soon as they’re operational. Then we’re going to just click Next past the remaining screens, and ultimately Finish.

To taste the fruits of our labour, in the Console we’re going to go to the Backup & Replication workspace and under the Jobs node, click SureBackup. Select our Test Lab and click Start.

You can double-click on the job and monitor the startup process, or jump over to Hyper-V Manager where you will ultimately connect to the isolated VMs that look, work, and appear exactly as they do in production. The only caveat is since the VHDs are ultimately running on our backup storage, the VMs don’t perform as fast as normal. This is a small price to pay for a feature that gives you a plethora of backup, restore, and testing capabilities.

All of Veeam’s solutions are riddled with useful stuff like Virtual Labs. Their Availability conference, VeeamOn (http://www.veeamon.com), is in May this year and is being held in New Orleans. It’s the biggest conference of its type in the world, and is the ultimate place to go to learn about modern virtualization, DR practices, and more ways to benefit from included features like SureBackup.

É