VMware vSphere proxies

[perjonsson1960]

Folks,

We have nine Esxi hosts in our VMware vSphere environment. So far we have been using our physical Veeam backup servers as proxies, but now we are considering using VMs as proxies instead. Is it best practice to deploy one proxy in each Esxi host? Is B&R so smart that it uses the proxy in the same Esxi host as the VM being backed up, if there is one? Or doesn't it matter where the proxy is located? My thought was to reduce the amount of data that needs to be sent over the physical network during backups of VMs.

Best,
Per Jonsson
Sweden

[Gostev]

Hello Per,

Normally it is sufficient to have 1-2 hot add proxies per vSphere cluster, unless the cluster size is extreme. The only scenario where you want to have a proxy on each host is when you don't have shared storage (using local storage in ESXi servers) AND have 1Gb Ethernet AND your protected VM disks have significant change rate (such as from database applications).

In general, according to our observations, the majority of Veeam customers tend to over-provision backup proxies (deploy more than needed, not adequate to the rest of their production and backup infrastructure).

Thanks!

[perjonsson1960]

Thanks!

[perjonsson1960]

Folks,

We have now set up two backup proxies in each VMware cluster, and we are allowing max 4 concurrent tasks in each proxy. But just now I came to think of the max concurrent tasks for the backup repositories, which is currently set at 4, as well, which I think is the default value. We have 4 identical repositories incorporated into one scale-out. I there something we should tweak in order to get the best performance during backups? More/less tasks in the proxies? More/less tasks in the repositories? Normally we run only one backup job at a time.

Best,
PJ

[nitramd]

Hello Per.

I would suggest experimenting by changing the concurrent tasks on your repos and proxies then monitoring and analyzing the results you get.

[perjonsson1960]

Quite frankly, so far I don't see any real benefits from using virtual proxies as opposed to using our physical B&R backup/repository servers as proxies, as we did before. Before, the job that I have been experimenting with, took about 10 minutes for an incremental backup. Now it takes about 30 minutes. And that is due to the hotadd of the hard disks, which takes between one and two minutes for each hard disk. And as I understand it, this is one of the cons for the hotadd scenario. What are the pros in our case? Is it that less data needs to be sent over the physical network between VMware and our physical repository servers?

[wishr]

Hi Per,

The performance will be lower with NBD due to the nature of the network data processing. Hot-add mode is definitely more reliable and offers better performance at the only cost of virtual resources required for spinning up backup proxy servers. I would recommend checking the UG section describing proxy Transport Modes and that BP portal article for additional information.

Thanks

[perjonsson1960]

Okay, thanks!

One more thing, about our physical servers; We have three identical physical backup/repository servers. One of them is the main B&R server, and I noticed that the proxy setting "Max concurrent tasks" is set to only 2 in the main server, while it is set to 16 in the other two servers. This is something that B&R has set. Is there a good reason why the setting is not higher than 2 in the main server? 16 is the number of cores in all three servers.

[wishr]

Are you talking about the setting of the concurrent task limit on the proxy or repository? Anyway, both of them can only be changed manually and the default values B&R sets are equal to the number of cores on the server you assign the proxy/repository role to (determined at the point when you add a proxy/repository). So I suspect these changes were implemented by someone else or initially the "main" server had only two cores upon adding.

Btw, we offer a handy Backup Objects Change Tracking report in Veeam ONE that could help you to keep a track of configuration changes in your backup infrastructure.

Thanks

[perjonsson1960]

I am talking about the concurrent tasks for the backup proxy. The concurrent number of tasks for the repositories is 4, which I think is the default. I noticed, in the article you linked to, that it is not recommended that the numbers overlap, so if I am using a 16 core machine for both proxy and repository, then in this case, it is not recommended to set the maximum number of proxy tasks to more than 12.

[foggy]

Right, if the server holds several Veeam B&R roles (i.e. runs several components), you should keep that in mind while sizing it - system requirements for all of them will sum up.

[jtfox]

Please check out this site. It's geared to 9.5 u4 but a lot of the concepts for tasks will still apply. From my experience, I would avoid hot add.

https://www.veeambp.com/proxy_servers_intro

[PetrM]

Hello!

In most cases, Hot Add gives higher read speed than "Network" mode because data read is performed from a disk directly attached to a proxy.
In the "Network" mode, data is retrieved via the ESXi host over LAN using the Network Block Device protocol (NBD).

And that is due to the hotadd of the hard disks, which takes between one and two minutes for each hard disk.

I would recommend to test Hot Add manually, you could take a non-production VM for the test. As a next step, it makes sense to examine ESXi logs and vmware.log of proxy itself for errors/timeouts if manual disk attach takes a long time.

Thanks!