Veeam just released the new and latest patch for Backup & Replication 7.0, numbered Patch 4. The new patch can be installed on any previous version of 7.0 release, since as usual the patch is cumulative. The final build number after the upgrade will be now 184.108.40.2061.
There are as usual many improvements and fixes, and two big enhancements. The first one is the added support for Microsoft SQL 2014, but for sure the biggest news is with no doubt the support for VMware Virtual SAN, unofficially shorten VSAN by many. As you may know, Virtual SAN is not the usual VMFS or NFS datastore; instead, it uses a new datastore format based on an object storage.
Prior to this patch, if a virtual machine was stored on Virtual SAN the datastore did not show up in the list of detected datastores for Veeam proxies (the data movers responsible for the backup operations). After installing the patch, now proxies can see the datastores so it’s possible to backup VMs running off Virtual SAN.
But this is not it. It would have been enough to simply support Virtual SAN, but our R&D went even further. I quickly created a nested VSAN environment to show you how the advanced VSAN support works, because it’s really smart in my opinion. This is a small Virtual SAN environment, made with 3 ESXi servers, their internal disks, and some VMs on VSAN datastore.
First of all, you can see now how the VMs show up correctly in the VM list inside Veeam:
I then created a Backup Job accepting all the default values. The job was completed successfully, but the interesting part is the way it was managed by resource scheduler:
VMs on VSAN datastore cannot be processed using DirectSAN access to the datastore itself. The two available methods are Virtual Appliance (Hot Add) and Network Mode (NBD). Network mode acts as usual, a Veeam proxy connects to the ESXi where the VM to be saved is running, and extracts virtual disk data via the management interface. The interesting part comes with Virtual Appliance mode.
In the lab there are three proxies, one per each ESXi server. With all the default configurations like parallel processing enabled and default limits of concurrency settings in the backup repository of 4 jobs, you would expect all proxies to process the VM named ved-vsan-sql since it has three hard disk. Instead, what you can observe is that only one proxy is processing all the disks of this VM.
Why this has happened?
Patch 4 introduces a smart logic for processing VSAN datastores. Since VSAN is based on local storage resources of all participating ESXi hosts, it can be that a virtual proxy is sitting in the same host where most of the virtual disks data resides. To determine where most of the VM data resides, Veeam Backup & Replication obtains information about data distribution inside the VSAN datastore from vCenter.
If there is a hot add proxy local to the data, Veeam server gives priority to that proxy; this is a strict rule, so as in the previous example even if other proxies were free and able to process VMs, they were never used and all VM disks where processed by the virtual proxy sitting on the correct ESXI server.
How does the proxy selection works? Veeam will always choose the proxy where the majority of data is saved at the start of the backup, unless the difference between VM data is less than 5% between two proxies. Here are two quick examples:
Host A = 70% , Host B = 30 % , Host C = 0%, Only proxy running on Host A will be used
Host A = 40% , Host B = 41% , Host C = 19%, both proxies running on Host A and Host B will be used
The final result will be the least possible network consumption inside the VSAN cluster to retrieve VM data. Pretty smart isn’t it?
And obviously, a quick design rule derived from this behaviour, if you want to maximize backup performance and reduce impact from backup activities on VSAN cluster network, you want to install one virtual proxy on each ESXi host participating in a VSAN cluster.