How many times there are requirements to test software updates and it is difficult to provide a test bed environment in a timely manner? Same applies for Devs and Ops that might be using an environment closest to the Production data in order to create a tailored patch or customization. For all these scenarios and more Veeam DataLabs test provides the flexibility that modern IT organisations require to safely verify, test and provide changes without affecting the Live environment.
Another use case is about testing new Beta software. There’s no need to recreate a testing environment if this can be “mounted” from a backup. And this article is taking the chance to test the latest Veeam Backup for Microsoft Office 365 v3.0 (VBO) currently available as Beta version. So the question could be: would I need to create a new environment on purpose just to test VBO 3.0 Beta version or why not use Veeam DataLabs test and simply install the latest VBO Beta on a copy of the Production environment coming from a Veeam Backup? In particular, the idea is to test the latest VBO working in conjunction with Veeam Cloud Connect (VCC). This is a very common installation that Veeam Cloud Service Providers (VCSP) use to support multi-tenant environments. Typically, a Service Provider will install VBO on top of VCC Server. This type of installation has to main advantages:
- allows Service Providers to satisfy a multi-tenant environment
- allows tenants to leverage the existing infrastructure (including VCC Gateways) to securely restore and export Office 365 data to a separate location.
Between the two options, the latter is more promising indeed and this is exactly what this article is covering by showing the flexible configurations. In terms of main ingredients the recipe includes:
- a Backup of virtual machine with Veeam Cloud Connect installed
- a Backup of a virtual machine with Active Directory installed
- Veeam Backup and Replication 9.5 update 4
- a Veeam Virtual Lab configured
- a Veeam Application Group
The next part of the article provides the main configuration steps on how to configure Veeam DataLabs test.
Veeam DataLabs test software updates
The first step is to create a Veeam Virtual Lab. The Virtual Lab provides the isolated environment where the copy of the specified backup will run. In this case a Virtual Lab just to test updates has been created and it is ready to run. Next step is to create an Application Group. The Application Group determines which virtual machines or in general applications should be running in the isolated environment with the option to also specify dependencies for example from other applications like Active Directory, DNS, SQL, Oracle and more. For this example a new Application Group is created using the Active Directory application as a dependency. In this particular case a virtual machine with latest VCC application is used for testing. And will also be the environment where the VBO 3.0 Beta will be installed.
Next step is to choose the VMs from the current Backups, Replicas and even Storage Snapshots.
In this steps it is possible to add any application from any job to satisfy the dependencies of main VM. In this case Veeam Cloud Connect.
Next is possible to use the verification options. As soon as the VM is up and running in the isolated environment provided by the Virtual Lab, verification routines will happen based on the current selection.
For example the amount of memory to allocate to the VM booting in the isolated environment along with startup time and Boot verification like VM Heartbeat and Ping responses. It is highly recommended to have VMware tools (or equivalent in Linux like open-vm-tools) up and running.
In addition, either based on role selection or by uploading custom code it is possible to include the execution of bespoke scripts for further or advanced verification.
Indeed also the ability to select a specif account which will be used in the Guest OS to execute the commands provided in the scripts.
At this point it is possible to add also the other applications to satisfy the required dependencies. Considering the Virtual Lab provides a fully isolated environment by default, applications like Active Directory Services, Domain Name Servers and Database Server are usually key components for the correct functioning.
And finally a quick summary with the main details.
At this point everything is ready to create a Veeam SureBackup Job that essentially acts as a placeholder for the Application Group and Virtual Lab configurations. The example below shows the steps for the VBO 3.0 Beta testing.
Next is to select the desired Virtual Lab. It is recommended to create or choose one where the Internet traffic is allowed. This is because the VBO Server will need access to the Office 365 tenants on the the internet to run Backup and Restore operations.
Next is to choose the desired Application Group as created before. It is important to select the “keep the application group running after the job completes”. This will leave the Veeam DataLabs test running until stopped. This means the VMs in the DataLabs can be restarted many times as needed. As long as the Veeam DataLabs test job is running than the VMs with relative changes will always be available in the isolated environment.
From here the option to link jobs and even specific VMs from such jobs with individual settings per VM.
As of the Veeam Backup Update 4 a new functionality has been introduced which allows to scan the backup against viruses, malware and corruption.
There is ability to schedule the creation of Veeam DataLabs test at specific times for example after specific point in time or in conjunction with other backup jobs.
And finally a summary showing the main settings for the Veeam DataLabs test job creation.
As soon as the Veeam DataLabs test job is starting it shows the general operations log and also the detailed ones per application with the configured verification options.
For each one of the applications is also possible to directly connect using the VMware Remote Console by mean of the vCenter connection. Until the “Stop Session” is clicked all the applications in the isolated environment will run. This means that if required it is possible to power cycle them multiple times. Changes are never lost. In case the Veeam DataLabs test session is stopped all changes to the applications in the isolated environment are lost and discarded. Same test environment can be started multiple times and presented to different developers for example.
By default, Veeam DataLabs test isolated environment cannot access the Production or Live environment. Likewise with the exception of the Veeam Backup & Replication, no other machine from Production can access the isolated environment. But what if this is required by a certain number of developers needing access from their computers to the isolated environment? there are two options: either by creating static routes on such computers or simply add these static mappings to the Virtual Lab configuration.
The Isolated IP is the one that belongs to the verified application. The Access IP is a free address from the Production environment that can be used as a static mapping. Once configured, all the packets destined to the Access IP will be automatically redirected to the Isolated IP. This is extremely helpful as it is more granular and easier to configure and maintain per Virtual Lab.
So the end result should look similar to the screenshot below where access from any computer in the Production Network is allowed to the Isolated Network. A use case could be the following:
“a developer needs access from his computer (where the necessary tools are installed) to a specific point in time data of a specific application“.
Add Comment