In my previous article on the Veeam Data Lab I highlighted why you would utilise this functionality with a couple of real world examples. In the next few posts I intend to show how you would accomplish this.
The first step in any Data Lab deployment, or the automated testing for backup (SureBackup) and replication (SureReplica), should always be the requirements gathering phase. This phase is critical for the Data Lab as it identifies what you want to test, and the VMs required. Once the VM or group of VMs to be utilised in the Data Lab have been identified it becomes quite easy to map out any dependancies on other VMs, as well as networking dependancies.
Let’s look at a fairly simple setup for a SharePoint environment. The SharePoint environment to be tested is made up of:
A WEB server (192.168.2.16);
An APP server (192.168.2.15); and
A SQL server (192.168.2.14).
They have dependancies on DNS, and Active Directory, both provided by a Domain Controller.
All servers have been configured with static IP addresses, with the SharePoint servers inside of one subnet, and the DC in another.
For testing purposes a single static IP address within the Production environment that can provide access to the WEB server is configured sufficient.
In our example the two networks in the Production environment to be emulated are 192.168.2.0/24 on VLAN 302 (SharePoint) and 192.168.3.0/24 on VLAN 303 (DC), and the user network is 192.168.1.0/24 on VLAN 301, and all gateway servers are x.x.x.254.
The emulated environment inside the Data Lab will be:
WEB 192.168.2.16/24 on VLAN 3302
APP 192.168.2.15/24 on VLAN 3302
SQL 192.168.2.14/24 on VLAN 3302
DC 192.168.3.240/24 on VLAN 3303
WEB access IP 192.168.1.216 on VLAN 301
This means that the emulated environment and the real servers will have the same IP addresses, and this is key as SharePoint servers will be looking for connectivity between each other and the DC on these IP addresses through DNS lookups. To achieve this the Data Lab will deploy a virtual Proxy Appliance to provide network address translation on virtual NICs.
Data Lab diagram
Now that we have a basic design it can be applied to the environment as shown in Part Three.
Veeam has two versions of Cloud Connect, Veeam Cloud Connect (VCC) and Veeam Cloud Connect for the Enterprise (VCC-E). So what’s the difference?
Veeam Cloud Connect
VCC is aimed at SPs and VARs who want to create a single (or set of) serviced offering’s to many independent customers. The end users add the service provider supplied details to their console with the option of allowing remote management. The offering is consumed as a service, with costs set by the service provider for any resources and licenses that are required.
When you sign up with the Service Provider they will supply you three things. A location to connect to, a username, and a password. An example configuration can be found here. The services on offer through the SP/VAR include a Backup Repository as a Service (RaaS), managed Backup as a Service (BaaS), and Disaster Recovery as a Service (DRaaS).
My previous post on the Plug-in for Pure Storage has definitely been the most read and shared across the globe. As mentioned in that post I wanted to install the Plug-in within an environment that had a Pure Storage array and thanks to one of the local resellers I managed to spend some time doing just that earlier in the week. This post will cover adding in a single array (labspa02), with Part Two to cover configuring a job.
Veeam announced today that the storage plug-in for Pure Storage arrays has been made Generally Available (GA). I’ve been waiting for this for a while and am absolutely delighted that it has gone GA, and that it is the second of the storage plug-ins to make it to market. I decided that similar to the Infinidat article that I published a few weeks ago, it would be worth showing how to deploy this plug-in.
I was at a VMware User Group in Perth recently and started discussing the Veeam Data Lab with two consultants, and how much of a hidden secret it is. For those of you who don’t know the Data Lab (previously Virtual Lab) provides an isolated sandbox for testing of Virtual Machines in an isolated network environment. The Virtual Machines in question could be a single VM, or an application group, and can have dependancies on other VMs as well. The discussion that I had around how useful this could be highlighted a use case that I thought I should share.