Comprehensive data protection for all workloads
Post Reply
isolated_1
Enthusiast
Posts: 44
Liked: 5 times
Joined: Apr 09, 2015 8:33 pm
Full Name: Simon Chan
Contact:

True Automatic Proxy Selection

Post by isolated_1 »

Hello Fellow Veeamers,

Here is my situation. I have an all-in-one Veeam Backup and Replication physical server. As we are creating more backup jobs, I have created two VM backup proxies to handle the extra load. Rather than scaling up the physical server, we wanted to scale out and that is why creating extra proxies to do the extra work sounds so great. My problem stems from the fact that only the physical server/proxy has Direct San access while the two VM proxies do not. With the Automatic proxy selection selected in each backup job, my assumption is that each VM that is being processed will use any of the three available proxies available. Obviously if the physical proxy is free of resources, it will choose that one first as it has Direct San access. If not, it will fallback to using either of the two VM proxy, which will do NBD. However, this isn't what I'm seeing.

After opening a case with Veeam support (case #01720091), I am told that the VM will look to see which available proxy offers the fastest and best transport method and it will wait until that one is available rather than falling back to another. In my case, this will usually be the physical server. The thing is though, I want it to be able to do a "true" automatic selection of the proxy. If the preferred one is not available, choose another regardless if it has to fall back to NBD. Otherwise, what's the point? I cannot connect my two VM proxies to our SAN network and so therefore, it will never be able to do Direct San transport mode! Currently, I have to manually set the proxy selection of some jobs to ONLY use either of the two VM proxies. If I manually select all three, I will be stuck with the same problem. This works for now but by doing so, these backup jobs will now never be able to use the physical server as a proxy anymore.

Most of our jobs are reverse incremental and so our bottleneck really is at the target repository. I want to be able to have all jobs running at the same time rather than have some needlessly waiting for the proxy "resources" to be available even if another proxy is able to service it albeit not using the best transport method.

Thanks!
tsightler
VP, Product Management
Posts: 6012
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: True Automatic Proxy Selection

Post by tsightler » 1 person likes this post

Is your physical proxy overloaded with CPU/memory? If not you could probably just bump up the tasks on the physical proxy above the default 1 per core if you just want more backups running with a target bottleneck.

Regardless, I'm a little curious about the reason that your virtual proxies only use NBD mode as I believe this is the source of your issues. Virtual proxies should ideally use hotadd mode. When it comes to selecting the transport mode Veeam prefers Direct SAN/NFS first, Hotadd second, and NBD as a "last resort". In a normal scenario, if a VM is able to be backed up by both Direct SAN and Hotadd, it will prefer the Direct SAN proxy, but it will use a hotadd proxy if the Direct SAN proxies are busy.

However, the rule for NBD mode is different. Because NBD mode is slower, and pulls data across the host management interface, Veeam first determines if a given VM has a proxy that can backup that VM in one of the other two modes and, if so, it will wait for that proxy to become available. Only if a VM has no proxy that can reach it with Direct SAN/NFS or Hotadd will it choose to use NBD mode. In other words, if your virtual proxies could do hotadd, you should see exactly the behavior you are requesting, the Direct SAN proxy would be used first, then the hotadd proxies.

That being said, you might want to simply consider switching to one of the faster backup modes, such a forever forward with per-VM chains. This will most likely reduce the actual time of the backup by a considerable amount over reverse incremental, and allow parallel merge operations after the job based solely on the repository task limit. Most likely you wouldn't even need the extra proxies in this case.
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 155 guests